This container will create detections and preventions only on Linux hosts, container platforms (e.g. OpenShift), and containers themselves, which are protected by a CrowdStrike sensor.
Automated detections currently available include:
| Name | Description |
|---|---|
| Defense Evasion via Rootkit | This script will change the group owner of /etc/ld.so.preload to 0, indicative of a Jynx Rootkit. |
| Execution via Command-Line Interface | Emulate malicious activity related to suspicious CLI commands. Runs the command sh -c whoami '[S];pwd;echo [E]'. |
| Exfiltration Over Alternative Protocol | Attempts to exfiltrate data using DNS dig requests that contain system data in the hostname. |
| Command & Control via Remote Access Protocol * | Attempts to connect to a remote IP address and will exit at fork. Falcon Prevent will kill the attempt. |
| Collection via Automated Collection | Attempts to dump credentials from /etc/passwd to /tmp/passwords. |
| Credential Access via Credential Dumping | Runs mimipenguin and tries to dump passwords from inside the container environment. |
| Webserver Suspicious Terminal Spawn | Executes a command injection, which writes a file to local webserver then executes that script. |
| Webserver Unexpected Child of Web Service | Executes command injection to dump MySQL Server tables of database running inside the detection container. |
| Webserver Bash Reverse Shell * | Executes command injection that creates a reverse shell over the web server running in the detection container. |
| Webserver Trigger Metasploit Payload ** | Simulates a malicious file upload, which executes a reverse TCP meterpreter to Kali. Please review the script for details on how to trigger this detection. |
| Reverse TCP Trojan (inert) * | Inert Trojan, written by CrowdStrike, that will attempt to connect to 192.168.0.1 on TCP port 4444. Tnis will be detected and killed by CrowdStrike's on-sensor machine learning with the aggressive policy settings. |
Note
(*) eligible for Prevention if configured in policy
(**) container starting using exposed port (-p 8080:80) required and a Kali attack host ready. Please note that a detection will only occur once you execute commands via meterpreter!
Container images hosted at https://quay.io/repository/crowdstrike/detection-container are automatically rebuilt as mult-architecture images with every merged pull request. Pull this container with the following Docker (or podman!) command:
Using Docker CLI:
docker pull quay.io/crowdstrike/detection-containerUsing Podman CLI:
podman pull quay.io/crowdstrike/detection-containerIf a specific architecture is desired to be used, add the --platform flag with the desired architecture(s): linux/arm64,linux/amd64,linux/s390x,linux/ppc64le
Clone this repository and build the container using docker build or podman build:
With Docker CLI:
docker build -t <your_repository>/detection-container .Podman CLI:
podman build -t <your_repository>/detection-container .Multi-architecture Build (requires Docker with BuildKit):
make docker-buildxThe detection-container operates in one of two modes, suitable for both Docker and Kubernetes environments:
This mode exposes a text-based user interface (TUI) for selecting pre-canned scripts to generate simple detections (e.g., "hit #1 for credential dumping!").
An example of running in interactive mode is shown below:
For Docker, use the following command to run the detection container interactively:
sudo docker run --rm -it quay.io/crowdstrike/detection-containerFor Kubernetes environments, refer to the vulnapp project for running the detection container interactively.
In this mode, detections are randomly generated with pauses between each to ensure uniqueness in the Falcon console. The pause duration ranges from 100 to 1800 seconds (approximately 1.5 to 30 minutes).
Output will be sent to the console (via stdout) regarding what detections are being generated. An example of running in non-interactive mode, plus output, is shown below:
For Docker, use the following command to run the detection container non-interactively:
sudo docker run --rm quay.io/crowdstrike/detection-containerFor Kubernetes environments, use the following command to run the detection container non-interactively:
kubectl create -f https://raw.githubusercontent.com/CrowdStrike/detection-container/main/detections.example.yamlFor AWS ECS Fargate, use the following commands to run the detection container:
-
Create the CloudWatch log group if it doesn't already exist. Make sure to replace the region with your own:
AWS_REGION="us-east-1" aws logs create-log-group \ --log-group-name /ecs/detection-container \ --region $AWS_REGION
-
Update and register the task definition:
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text) # Update task definition with your account ID and region sed -i "s/ACCOUNT_ID/$ACCOUNT_ID/g" ecs-task-definition.json sed -i "s/AWS_REGION/$AWS_REGION/g" ecs-task-definition.json # Register the task definition aws ecs register-task-definition \ --cli-input-json file://ecs-task-definition.json
-
Run the task. Make sure to replace
YOUR_CLUSTER,YOUR_SUBNET, andYOUR_SGwith your own values:aws ecs run-task \ --cluster YOUR_CLUSTER \ --task-definition detection-container \ --launch-type FARGATE \ --network-configuration "awsvpcConfiguration={subnets=[YOUR_SUBNET],securityGroups=[YOUR_SG],assignPublicIp=ENABLED}" -
View the logs in CloudWatch:
# View logs in real-time (replace region if needed) aws logs tail /ecs/detection-container --follow --region us-east-1
Note
For ECS Fargate deployment, ensure:
- The ECS execution role has permissions to pull images and write to CloudWatch Logs
- The CloudWatch log group is created before running the task
- CrowdStrike Falcon Container Sensor is deployed for detections to appear in the console