CyberStrikeAI turned on AWS: Elastic reads one server's 16 days across eight identities in four accounts, 56 user-data reads in 141 milliseconds, and why six detections each rated medium or low and only the source address tied them together

Between 2026-09-30 and 2026-10-16 one server serving a CyberStrikeAI web interface used the credentials of eight AWS identities (five IAM users and three EC2 instance roles) across four accounts and generated 78 alerts, the first case Elastic has seen of this tooling turned on AWS (Elastic Security Labs, 2026-11-13). It started by validating identities: GetCallerIdentity on four IAM users in three accounts within 51 minutes, three of the calls in the same second (Elastic Security Labs, 2026-11-13). An instance role then read a secret, made one user-data request and fired 56 more in 141 milliseconds, spacing Elastic says fits tooling working through a prepared list of instance IDs (Elastic Security Labs, 2026-11-13). On 2026-10-02 another instance role read an encrypted Systems Manager parameter and issued a SendCommand 29 seconds later, which Elastic calls the highest-risk activity; the audit log does not show the command or its outcome (Elastic Security Labs, 2026-11-13). After 14 quiet days the server returned and revalidated credentials, including a user in a fourth account (Elastic Security Labs, 2026-11-13). Elastic does not know how the credentials were obtained and infers that the instance-role sessions, used from an outside address, were taken from the instances, for example through SSRF or host compromise (Elastic Security Labs, 2026-11-13). Team Cymru counted 21 unique addresses running CyberStrikeAI between 2026-01-20 and 2026-02-26 (Team Cymru, 2026-03-02).

Triage: each call is one a legitimate role makes every day, so the discriminators are the source address, the number of distinct identities, accounts or instances one address touches in minutes, and the decrypt-then-SendCommand pairing (Elastic Security Labs, 2026-11-13).