Connect this data source on your own, using the Hunters platform.
TL;DR
Supported data types | 3rd party detection | Hunters detection | IOC search | Search | Table name | Log format | Collection method |
---|---|---|---|---|---|---|---|
sysdig-next-gen-activity-commands | ✅ | sysdig_next_gen_activity_commands | NDJSON | S3/API | |||
Sysdig-next-gen-activity-file-accesses | ✅ | ✅ | sysdig_next_gen_activity_file_accesses | NDJSON | S3/API | ||
Sysdig-next-gen-activity-kubernetes | ✅ | ✅ | sysdig_next_gen_activity_kubernetes | NDJSON | S3/API | ||
sysdig-next-gen-activity-networks | ✅ | ✅ | ✅ | sysdig_next_gen_activity_networks | NDJSON | S3/API | |
sysdig-next-gen-secure-events | ✅ | ✅ | ✅ | sysdig_next_gen_secure_events | NDJSON | S3/API |
Overview
Sysdig is a cloud-native security and monitoring platform designed to help organizations secure and optimize their containerized environments, Kubernetes clusters, and cloud infrastructure. It provides real-time threat detection, vulnerability management, and compliance enforcement by leveraging deep visibility into runtime activity. Sysdig’s platform enables security teams to detect and respond to threats, enforce least-privilege access, and monitor application performance. With capabilities like container runtime security, forensic analysis, and policy-driven compliance, Sysdig helps organizations protect their cloud workloads while maintaining operational efficiency.
In 2025 April they’ve released their new API which is based on the same logs, with different namings, and different REST endpoints.
Supported data types, Expected Format, Log Examples:
Activity Commands
Table name: sysdig_next_gen_activity_commands
Function: Captures every command executed in the environment, whether from host, container, or Kubernetes tools like kubectl exec.
Use cases: Useful for understanding user actions, auditing, investigating incidents, and ensuring compliance
{"cmdline": "csi-node-driver --kubelet-registration-path=/var/lib/kubelet/plugins/disk.csi.test.com/csi.sock --mode=kubelet-registration-probe", "comm": "csi-node-driver", "containerId": "f51c78861b68", "cwd": "/", "hostname": "abc-main-11066336-vvss000000", "id": "1856a0da15e54e1815ec2679c5095640", "labels": null, "loginShellDistance": 0, "loginShellId": 0, "pcomm": "runc", "pid": 3667718, "ppid": 3667712, "procExepath": "", "timestamp": 1753765963438050840, "tty": 0, "type": "command", "uid": 0, "userLoginName": "", "userLoginUid": 0, "username": "root"}
Learn more here.
Activity File Accesses
Table name: sysdig_next_gen_activity_file_accesses
Function: Logs file access events associated with commands executed via interactive sessions (e.g., via shell or exec).
Use cases: Critical for detecting data exfiltration, unauthorized modifications, and supporting forensic investigations
{"comm": "python3", "containerId": "ab123a4e1221", "directory": "/tmp/", "filename": "ifw3r87r", "hostname": "ip-10-20-30-40.example.internal", "id": "1856a1e0add3ed04cf9664d8389", "labels": null, "permissions": "rw", "pid": 3406381, "timestamp": 1753767011268480260, "tty": 34816, "type": "fileaccess"}
Learn more here.
Activity Kubernetes
Table name: sysdig_next_gen_activity_networks
Function: Captures Kubernetes-specific activities extracted from audit logs, such as kubectl exec and kubectl attach commands.
Use cases: Helps trace which user or process executed actions inside pods—vital for securing and auditing Kubernetes environments
{"id":"15cbf54e34df95404caad1c988cf7c42","timestamp":1546300800000000000,"type":"kubernetes","hostname":"ip-12-12-12-12","containerId":"f8d4f71ab80b","resource":"pods","subResource":"exec","namespace":"sysdigcloud","name":"sysdigcloud-redis-12345f6789","sourceAddresses":["12.12.12.1","12.12.12.2"],"user":{"username":"kubernetes-admin","groups":["system:masters","system:authenticated"]},"userAgent":"kubectl/v1.13.5 (linux/amd64) kubernetes/2166996","args":{"command":"bash","container":"redis"},"labels":{"additionalProp1":"foo","additionalProp2":"foo","additionalProp3":"foo"}}
Learn more here.
Activity Networks
Table name: sysdig_next_gen_activity_networks
Function: Tracks TCP network connections initiated during interactive sessions (e.g., those started by shell commands or kubectl exec).
Use cases: Facilitates investigation of suspicious connections, lateral movement, or data exfiltration attempts
{"clientIpv4": "10.20.30.40", "clientPort": 11223, "cmdline": "", "comm": "test-operato", "containerId": "cf184a4e1234", "direction": "in", "dnsDomains": [], "hostname": "ip-10.20.30.40.example.internal", "id": "1234a0fcb92d7a647c0d5678e901a2b3", "l4protocol": "tcp", "labels": null, "pid": 121212, "processName": "test-operato", "serverIpv4": "10.20.40.30", "serverPort": 2211, "timestamp": 1757766112206655044, "tty": 0, "type": "connection"}
Learn more here.
Secure Events
Table name: sysdig_next_gen_secure_events
Function: Records real-time security events and policy violations occurring in container or cloud-native environments.
Use cases: Supports threat detection, policy compliance monitoring, and security alerting functionality
{"category": "runtime", "content": {"fields": {"container.id": "b222f2d0b21f", "container.image.repository": "registry.io/amq-streams/kafka-35-rhel8", "container.image.tag": "<NA>", "container.name": "kafka", "evt.res": "SUCCESS", "evt.type": "execve", "group.gid": "0", "group.name": "root", "proc.aname[2]": "crio", "proc.aname[3]": "systemd", "proc.aname[4]": "<NA>", "proc.cmdline": "bash -c /opt/kafka/bin/kafka-groups.sh --bootstrap-server main-kafka-bootstrap:1122 --all-groups --describe ", "proc.cwd": "/opt/kafka/", "proc.exepath": "/usr/bin/bash", "proc.hash.sha256": "f420671b28650f60f5461c63353ca0a123b9ded83643f068a88e", "proc.name": "bash", "proc.pcmdline": "runc --root /run/runc --systemd-cgroup exec --process /tmp/exec-process-1227349045 b526f2d0b28feca54baaaab2056a99988067ce81e4c493bee1b40", "proc.pid": "2960268", "proc.pid.ts": "1753611457840371321", "proc.pname": "runc", "proc.ppid": "2960258", "proc.ppid.ts": "1753611457828838916", "proc.sid": "1011022", "proc.tty": "34816", "user.loginname": "<NA>", "user.loginuid": "-1", "user.name": "1001240000", "user.uid": "1001240000"}, "origin": "Secure UI", "output": "A shell was spawned by runc in container kafka with image registry.io/amq-streams/kafka-35-rhel8 with an attached terminal ", "policyId": 796399, "ruleName": "Terminal shell in container", "ruleSubType": 0, "ruleTags": ["container", "container_best_practices", "container_immutability", "shell", "SOC2", "oss"], "ruleType": 6, "type": "workloadRuntimeDetection"}, "description": "Terminal shell has been created in a project container", "engine": "falco", "id": "1556644d8e88550133b0cd222dc8de55", "labels": {"container.image.digest": "sha256:ba01a2ec488da6ddc84aa5ee15a27344a8dba7a1cae362fca", "container.image.id": "333250ba250e", "container.image.repo": "registry.io/amq-streams/kafka-35-rhel8", "container.label.io.kubernetes.container.name": "kafka", "container.label.io.kubernetes.pod.name": "main-kafka", "container.label.io.kubernetes.pod.namespace": "stev-fat", "container.name": "kafka", "host.hostName": "preprod-broker-xyz", "host.mac": "11:55:66:bb:33:ee", "kubernetes.cluster.name": "preprod", "kubernetes.namespace.name": "stev-fat", "kubernetes.node.name": "preprod-broker-rldt4", "kubernetes.pod.name": "main-kafka-0", "kubernetes.service.name": "main-kafka-brokers", "kubernetes.workload.name": "main-kafka-0", "kubernetes.workload.type": "pod"}, "name": "Terminal shell in container (project)", "originator": "policy", "rawEventCategory": "runtime", "rawEventOriginator": "linuxAgent", "severity": 4, "source": "syscall", "sourceDetails": {"subType": "container", "type": "workload"}, "timestamp": 1753699457892910337, "host_region": "api.sysdig.com"}
Learn more here.
Send data to Hunters
You can collect logs using 2 methods:
- API - follow a few simple steps to connect logs to Hunters using API.
- S3 storage - route logs to an S3 bucket and provide Hunters with the details.
Using API
Hunters supports the collection of logs from Sysdig using API.
To connect Sysdig logs:
Log in to the Sysdig portal to retrieve your API host and API token.
Locate the URL you logged into. This is your API host. Example -
app.us4.sysdig.com
To retrieve the token, from the user menu navigate to Settings > User Profile.
The Sysdig Monitor or Sysdig Secure API token is displayed.
Locate your API token and copy it. Example -
87090758-60a0-4294-ba02-666bd0895eb8
Add the host without the
https://
prefix, and also without the endpoint URI/secure/activity-audit/v1/entries
, we would expect -https://{host}
Complete the process on the Hunters platform, following this guide.
.png?sv=2022-11-02&spr=https&st=2025-09-09T15%3A37%3A11Z&se=2025-09-09T15%3A50%3A11Z&sr=c&sp=r&sig=5l%2F87YFL5vMyaTKbQXJCd%2FtvuHdF%2BTc0cx0VLqWHOu8%3D)
Using S3 storage
Alternatively, you can collect the these logs from your network to a shared storage service (e.g. to an S3 bucket) shared with Hunters. Click here for further instructions.
📘Note
When using the S3 collection method, the host_region
field can only be added manually in order to retrieve the alert console URL in the alert (see the sample below). This field is not mandatory.