Amazon GuardDuty now supports enhanced threat detection for ECS, so I tried it out #AWSreInvent
This page has been translated by machine translation. View original
Hello! This is takakuni (@takakuni_) from the Cloud Business Division Consulting Department.
Finally, Amazon ECS Extended Threat Detection has been released at re:Invent 2025.
Amazon ECS Extended Threat Detection
A new Finding called AttackSequence:ECS/CompromisedCluster has been introduced, enabling us to view activity across an entire Amazon ECS cluster at once.
Until now, ECS Runtime Monitoring has focused on threats at the ECS task level, but being able to see these consolidated across the entire cluster is very exciting.
It detects threats using the following data sources:
- Runtime Monitoring for Amazon ECS Fargate
- Runtime Monitoring for EC2 Instances in Amazon ECS
- GuardDuty Malware Protection for Amazon EC2
Trying it out
Let's actually detect some threats.
Test Events
For those thinking "preparing the environment seems like a lot of work," creating test events is recommended.
You can issue test events for Extended Threat Detection Findings as well.
aws guardduty create-sample-findings \
--detector-id $(aws guardduty list-detectors --query 'DetectorIds[0]' --output text) \
--finding-types "AttackSequence:ECS/CompromisedCluster"
Running actual tests
For those who want to see real events.
I prepared two Amazon Linux 2023 containers with functioning ECS Exec.
Bitcoin-related (First container)
I used the first container to detect Bitcoin-related Findings.
Following the blog post below, I triggered BitcoinTool.B and BitcoinTool.B!DNS Findings.
dnf -y install bind-utils
nslookup pool.supportxmr.com
curl pool.supportxmr.com
Reverse shell/privilege escalation
The second container was used for reverse shell and privilege escalation detection.
To simulate privilege escalation, I created a TestUser.
dnf install -y shadow-utils
useradd TestUser
usermod -p 'P@ssw0rd' TestUser
I used scripts from the amazon-guardduty-tester published by awslabs.
dnf install -y git
dnf install -y nc nmap
git clone https://github.com/awslabs/amazon-guardduty-tester.git
cd amazon-guardduty-tester/lib/common/testResources/scenarios/runtime
sh ReverseShell.sh
Looking at the detection results
Now that the scripts have finished running, let's look at the detection results.
Test Events
First, let's look at the test events. Two Findings with different content were created.
Findings with 3 detected Signals
The Findings with 3 detected Signals were sample Findings for containers running on AWS Fargate.
It states that Execution, Command and Control, and Impact were detected in sequence.
The AI summary described the following situation:
The AWS GuardDuty detection result (JSON file) you provided indicates a **very high severity (Severity 9)** attack sequence suggesting a compromised ECS cluster.
Here's a summary of this alert broken down into sections:
---
## 1. Detection Overview
- **Title**: Potential ECS cluster compromise of ecs-demo-cluster indicated by a sequence of actions.
- **Severity**: **9 / 10 (Critical)**
- **Target Resources**:
- **ECS Cluster**: `ecs-demo-cluster`
- **AWS Account**: `111122223333`
- **Region**: `us-east-1`
- **Occurrence Date/Time**: December 31, 2025 03:29:08 (UTC)
---
## 2. Attack Timeline and Component Signals
This alert recognizes an "attack sequence" by integrating the following three signals that occurred within a short timeframe:
1. **Backdoor Communication (Backdoor:Runtime/C&CActivity.B)**
- Container communicated with a known **C&C (Command & Control) server**.
2. **Cryptocurrency Mining Tool Detection (CryptoCurrency:Runtime/BitcoinTool.B)**
- Communication with Bitcoin-related IP address (1.2.3.4) was confirmed.
3. **New Library Loading (Execution:Runtime/NewLibraryLoaded)**
- New shared libraries that are not typically observed were loaded in the running container.
---
## 3. Identified Attack Techniques (MITRE ATT&CK)
The attacker employed the following tactics and techniques:
- **Tactics**: Execution, Impact, Privilege Escalation, Command and Control
- **Key Techniques**:
- **T1496 (Resource Hijacking)**: Resource hijacking through cryptocurrency mining.
- **T1071 (Application Layer Protocol)**: C&C communications using application layer protocols.
- **T1543**: Modification of container services.
- **T1129**: Abuse of shared modules.
---
## 4. Evidence Details
- **Suspicious Processes**:
- `xmrig` (cryptocurrency mining binary, path: `/usr/share/xmrig`)
- Suspicious execution of standard commands like `curl`, `touch`.
- **Involved Container Image**: `demo-container-image1`
- **Suspicious Connection Destinations**:
- IP: `10.0.0.1` (recorded as a Tor exit node)
- IP: `1.2.3.4` (mining and C&C server)
---
## Recommended Next Steps
This alert indicates a high likelihood that resources have already been hijacked (mining) and are being operated externally.
- **Immediate Termination of Affected ECS Tasks**: Stop the identified task (ID: `90c32764...`) and prevent its restart.
- **Investigation of Container Image**: Check if `demo-container-image1` has vulnerabilities or malicious code.
- **Security Group Verification**: Confirm that unnecessary external communications (especially to ports like 33333) are not permitted.
Findings with 4 detected Signals
Next is the Findings with 4 detected Signals. This is a sample for ECS running on EC2.
This one states that only Command and Control and Impact were detected.
The summary is as follows:
This second JSON file is also an AWS GuardDuty report of an **extremely severe (Severity 9)** attack sequence. Similar to the first file, but this time **"cryptocurrency mining" related communications (DNS queries) and IP addresses** are identified in more detail.
Here's a summary of the key points:
---
## 1. Detection Overview
- **Title**: Potential ECS cluster compromise of ecs-demo-cluster indicated by a sequence of actions
- **Severity**: **9 / 10 (Critical)**
- **Target Cluster**: `ecs-demo-cluster` (Account: `111122223333`)
- **Detected Attack Phases**: Execution, Impact, Privilege Escalation
---
## 2. Four Signals Comprising the Attack
This sequence is based on the following four suspicious activities:
1. **Suspicious DNS Query**: Query to mining-related domain `crypto.guarddutyc2activityb.com`.
2. **Mining Program Execution**: Detection of known mining tool `xmrig`.
3. **Bitcoin-Related Communication**: Communication with known Bitcoin-related IP address (`1.2.3.4`).
4. **C&C Server Communication**: Outbound communication to external Command & Control (C&C) server.
---
## 3. Evidence of Compromise and Technical Details
- **Suspicious Processes**: `/usr/share/xmrig`, `/usr/bin/curl`, `/usr/bin/touch`
- **Involved Connection Destinations**:
- **IP Address**: `1.2.3.4` (mining and C&C)
- **Tor Node**: `10.0.0.1` (access via anonymous network)
- **Target Resource**: ECS task with EC2 launch type (Task definition: `ec2-instance-test`)
---
## 4. Main Differences from the Previous Report
Compared to the previous file, the following points are more specific:
- **DNS-Level Evidence**: Access to mining-specific domains is clearly recorded.
- **Increased Number of Signals**: Increased from 3 to 4 signals, strengthening the evidence of mining activity.
- **Infrastructure Format**: This time, tasks running on **EC2 instances** are targeted rather than FARGATE.
---
### Recommended Response
1. **Force Stop the Task**: Immediately stop `arn:aws:ecs:us-east-111122223333:task/default/90c32764...`.
2. **Isolate the Host EC2**: Isolate the EC2 instance (`i-a188560f`, etc.) where this task was running and conduct a detailed investigation.
3. **Rotate Credentials**: Consider invalidating and updating credentials as IAM roles assigned to instances or tasks may have been compromised.
Script Results
Now let's look at what was actually detected by the script.
I had expected Findings to appear for each cluster, but the Findings also included another cluster that I had been testing before writing this blog.
Also, the ECS tasks within the cluster are counted among the resources.
As expected, the Attack sequence detected Execution (ReverseShell execution), Privilege Escalation (useradd and usermod), Command and Control, and Impact (mining-related operations).
The summary is as follows:
Here's a summary of the AWS GuardDuty detection result (JSON file) you provided.
This alert reports an attack sequence (series of suspicious behaviors) with a "high (Severity: 9.0)" severity indicating a **potential compromise of Amazon ECS clusters**.
---
### ## Detection Overview
- **Detection Type**: Potential ECS cluster compromise (AttackSequence:ECS/CompromisedCluster)
- **Severity**: 9.0 (High)
- **Target Account**: 123456789012
- **Target Resources**:
- **ECS Clusters**: `guardduty-extended-cluster` and `gd-extended-cluster`
- **Tasks/Containers**: A total of 3 tasks and 3 containers are affected, including `busybox-td`
- **Occurrence Period**: December 31, 2025 02:28:18 - 05:02:44 (UTC)
---
### ### Observed Attack Traces
GuardDuty detected a total of 9 signals across the following 4 MITRE ATT&CK tactics:
| Item | Content |
| --- | --- |
| **Execution** | Detection of reverse shells (`/amazon-guardduty-tester/.../reverseShell`, etc.) |
| **Privilege Escalation** | Suspicious account operations with `usermod` command (unlocking locked users) |
| **Command & Control** | DNS queries to malicious domains (`guarddutyc2activityb.com`) |
| **Impact** | Communication with cryptocurrency mining-related domains (`supportxmr.com`) and IP addresses (`15.235.229.127`, etc.) |
---
### ### Detected Suspicious Processes and Communications
- **Involved Processes**:
- `usermod` (account operations)
- `nslookup`, `curl` (reconnaissance/communication)
- `1767149246-reve` (reverse shell script)
- **Communication Destinations (partial)**:
- `15.235.229.127`, `15.235.229.148` (mining-related IPs)
- `pool.supportxmr.com` (mining pool)
> **Note**: This detection is identified as a sequence of events (attack sequence) rather than a single event, showing a storyline of an attacker infiltrating the system, taking over permissions, and performing mining and external communications.
Summary
That concludes "Testing Amazon GuardDuty's new Extended Threat Detection for ECS."
Being able to view activities from scattered ECS tasks in a single, chronological Finding is extremely convenient.
Additionally, the fact that Findings are grouped at the account level (not separated by cluster) helps in identifying the scope of compromise.
This was takakuni (@takakuni_) from the Cloud Business Division Consulting Department!
