- Elastic Security Labs says one CyberStrikeAI server used eight stolen AWS identities over 16 days and set off 78 alerts, all medium or low severity.
- Each alert looked routine alone. Elastic says only the shared source IP tied them together, and a 14-day pause would split them under short fixed windows.
- Check who can read EC2 user data, treat secrets stored there as exposed, and group alerts by source IP over weeks.
Small alerts, one intruder
Picture an analyst on a quiet shift. One AWS account shows an identity check from a new source. Another shows a secret being read. A third shows a command sent to a server. Each alert is medium or low severity.
Elastic Security Labs says these alerts were not separate events. Between September 30 and October 16, 2026, one server running CyberStrikeAI used credentials from eight AWS identities in four accounts. Five were IAM users, which are named human or service logins. Three were EC2 instance roles, which are permissions attached to cloud servers. The server set off 78 alerts.
The lesson here is that the unit of defense has changed. An alert describes one action. An intrusion run by automated tooling shows up only as a pattern across identities, accounts and weeks.
Elastic adds that each step is something a legitimate role does on an ordinary day. That is why nothing looked urgent at the time.
What the logs show
CyberStrikeAI is an open-source tool that combines AI language-model agents with offensive security software. Team Cymru's Will Thomas tracked 21 IP addresses running it in early 2026. All of them targeted Fortinet network devices. Elastic reports this is its first sighting of the tool used against AWS.
Elastic is careful about its claim. It calls the activity AI-assisted because of the tool's identity and the machine-speed behavior. It says it cannot prove an AI agent made the decisions. It also does not know how the attacker got the credentials.
The speed evidence is specific. One role, which Elastic calls app-role, sent 56 requests for EC2 user data in 141 milliseconds. Three identity checks hit three different accounts within a single second. Elastic says 65 of the 78 alerts, or 83%, came on day one. After that, the pace fell to a few targeted actions a day.
How the attack works
EC2 user data is the startup script attached to a server instance. Elastic says these scripts often contain hardcoded API keys, database passwords, SSH keys or certificates. A role that can read them can collect those secrets without touching the server itself.
Three of the sessions carried names matching EC2 instance IDs. That tells Elastic the credentials came from instance profiles. Yet the sessions were used from an external IP address. So Elastic concludes the credentials were taken from the instances. It names a server-side request forgery flaw or a compromised host as examples.
The sequence began by testing which credentials still worked. It moved on to pulling secrets from Secrets Manager, then to the burst of user data reads. On October 2, a role read an encrypted SSM parameter. Twenty-nine seconds later it sent an SSM SendCommand, which runs a command on managed servers. The audit log records that a command was sent. It does not show what the command was or whether it worked.
Elastic also saw secrets from a non-production environment. It says such environments sometimes share secrets with production.
Why the 14-day pause matters
After October 2 the server went quiet for 14 days. It came back on October 16 and rechecked credentials, including a user in a fourth account. Elastic says this fits a check on whether access survived. It could also be a deliberate cool-down, or an operator who was busy with other targets. The data does not say which.
Elastic's point is that a short, fixed correlation window would have split this intrusion into unrelated alerts. Its six detection rules covered every phase between them. The source IP was the only thread that tied them together.
Elastic offers a two-part answer. First, rules with few false alarms should trigger action at once. Elastic added two of these. One fires when a principal reads user data from more than 20 distinct instances in 10 minutes. The other fires when three or more distinct non-role identities run the identity check from one external IP in 10 minutes. Second, medium and low alerts should be grouped by source IP, using flexible time windows.
What to ask your team
Elastic's guidance gives leaders concrete questions.
First, who can read user data? Elastic advises limiting the ec2:DescribeInstanceAttribute permission for user data to roles that need it. Second, which secrets sit in user data today? Elastic says to treat them all as exposed if a role was compromised. It advises moving them to Secrets Manager or Parameter Store.
Third, can we see credentials used from outside expected IP ranges? Elastic says to alert on exactly that. Also ask how long we keep that history and whether anyone links it across weeks. Fourth, who reviews SSM SendCommand history when an unexpected command appears? Fifth, do non-production roles share secrets with production?
Blocking the three IPs Elastic lists helps only a little. Elastic says the attacker can change servers, so behavior-based detection lasts longer. As of November, none of the three IPs serves the CyberStrikeAI page. Elastic suggests using them to hunt back through old logs.
A single alert is a sentence. Elastic's case shows that the intrusion reads as a story only when someone keeps the whole page open for weeks.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Elastic Security Labs.
