CyberStrikeAI in AWS: A 16-Day CloudTrail Trail

CyberStrikeAI AWS intrusion CloudTrail records show a fast credential-led operation that unfolded over 16 days, according to Elastic Security Labs’ November 13 investigation. One role made 56 EC2 user-data requests in 141 milliseconds, yet the same server returned after a 14-day quiet period. The central defender problem is connecting ordinary-looking API calls across identities, accounts and time.

Elastic linked one CyberStrikeAI server to activity in four AWS accounts using eight identities between September 30 and October 16, 2026. Its telemetry produced 78 medium- or low-severity alerts across six rules. Elastic attributes the server to the platform but says the logs cannot prove an LLM agent made the decisions. Its report also leaves the credential acquisition path and the outcome of a later remote command unresolved.

CyberStrikeAI AWS Intrusion CloudTrail: The Sequence

The evidence begins with use of existing credentials, not a demonstrated software flaw. Elastic saw five IAM users and three EC2 instance roles, with the roles’ sessions named after EC2 instance IDs. External use of those role sessions is consistent with credentials taken from instances. Elastic offers server-side request forgery or host compromise as possible routes, but does not identify which occurred.

1. CyberStrikeAI-linked serverExternaluses existing credentials
2. IAM users and instance rolesAWS Identityauthenticate AWS API calls
3. Secrets and EC2 user dataAWS Resourcesretrieves stored material
4. SSM parameter and commandAWS Resources

On September 30, the server called GetCallerIdentity for four IAM users across three accounts within 51 minutes. Three calls occurred in the same second across three accounts. That pattern suggests automated credential validation, while the API call itself is common in legitimate administration. Elastic also recorded two GetSessionToken calls by one user.

The investigation then moves to an instance role in one account. The role accessed Secrets Manager, requested EC2 user data once and later made 56 more user-data requests within 141 milliseconds. EC2 user data is the startup material attached to an instance and can contain credentials if administrators have placed them there. The observed requests establish retrieval attempts; they do not establish that every script contained a usable secret.

On October 1, the server revalidated credentials and accessed more secrets, including through a second instance role associated with a nonproduction environment. Cross-environment secret reuse would raise the impact, but Elastic does not show that reuse happened here. On October 2, a third role requested an encrypted SSM parameter and issued SendCommand 29 seconds later. CloudTrail records the command request, while the report says it does not reveal the command’s content or whether it succeeded.

The server returned on October 16 after 14 quiet days. It requested a session token for a user in a fourth account and repeated GetCallerIdentity calls for users seen earlier. Elastic describes this as consistent with checking whether access survived. The record does not distinguish a planned pause from an operator returning after other work.

Why Did Six Detection Rules Need Correlation?

Elastic’s six rules saw pieces of the sequence: first-time identity calls, secret access, EC2 user-data retrieval, SSM parameter decryption and a rare SendCommand. They generated 78 alerts, all rated medium or low. The 58 user-data retrieval alerts dominated the total, so an analyst reviewing only counts could miss the later SSM activity. Source-IP correlation connected the phases in Elastic’s retrospective analysis.

The timing is as important as the volume. Elastic counted 65 alerts on September 30, eight on October 1, two on October 2 and three on October 16. A short fixed correlation window would separate the burst, the command request and the return visit. The appropriate investigation unit is the identity’s activity over time, with source IP and account as joining fields.

That lesson extends beyond this particular platform. A credential used from an unexpected location can make authorized API operations part of an intrusion. In this case, the researcher associated the server with CyberStrikeAI through its exposed interface and certificate, then matched that server to the CloudTrail source. The association supports tool attribution, while it does not identify the human operator or prove autonomous decision-making.

For context on the tool’s earlier reported use, see our CyberStrikeAI platform overview. This AWS case asks a narrower question: how should a security team connect legitimate-looking cloud actions after credentials have escaped? A cyber threat intelligence platform fits that correlation and prioritization workflow when teams combine external context with their own identity and cloud telemetry.

Where Should an AWS Hunt Start?

Start with your CloudTrail coverage and the identities allowed to retrieve user data or secrets. Elastic recommends looking for a burst of DescribeInstanceAttribute requests for userData from one role session, especially when many distinct instances are queried rapidly. Its published bulk enumeration rule uses more than 20 distinct instances in ten minutes as a detection threshold. That number describes Elastic’s rule, not a universal definition of compromise.

Next, join first-time GetCallerIdentity calls from several identities or accounts when they share an unexpected source IP. Elastic’s companion rule looks for three or more distinct non-role identities from the same external IP and ASN in ten minutes. The rule makes a pattern visible that an individual identity check does not. Teams should tune expected automation and shared network addresses against their own environment.

Review instance-role sessions whose API requests appear from outside the expected instance or network path. This is especially relevant when the same session reads Secrets Manager values or EC2 user data. A stolen temporary role credential may expire, but the underlying host can keep issuing fresh credentials if its original exposure remains. Investigating that host is therefore part of containment, not a later clean-up task.

Finally, pair GetParameter requests with decryption enabled and subsequent SendCommand calls by the same role. Elastic saw those operations 29 seconds apart in its case. Inspect the SSM command history and affected managed nodes to determine what actually ran. CloudTrail alone should not be treated as proof of command execution or host compromise.

• Join identity checksGroup GetCallerIdentity and GetSessionToken by source, identity and account.
• Review secret accessExamine unusual GetSecretValue and decrypted GetParameter calls by the same sessions.
• Count user-data readsFind rapid DescribeInstanceAttribute requests for userData across distinct instances.
• Verify SSM outcomeCompare SendCommand events with command history and managed-node records.
• Extend the lookbackRetain the related identities and source context across the quiet period.

This checklist is our defensive workflow based on Elastic’s observed sequence. It is not a claim that every matching event is malicious. The source’s individual alerts were low or medium severity because legitimate roles can perform each operation. The decision to escalate should follow the combination of unusual origin, repetition, sensitive access and command activity.

How Should Teams Contain and Verify Exposure?

Elastic recommends rotating credentials for affected identities and revoking active sessions, including temporary credentials. Prioritize identities that accessed secrets, user data or SSM command functions. For an exposed instance role, replacing the instance profile or instance can prevent a compromised host from reissuing credentials. Verify which secret values and scripts the role could read before closing the incident.

Inspect EC2 user data for embedded keys, certificates and bootstrap secrets. If such material was present, treat it as exposed and rotate it. Move secrets into an appropriate managed store and narrow the roles that can read them. Restrict permission to retrieve userData to roles that need that operation.

Check whether the nonproduction role can access material that also works in production. This is an exposure review, not evidence that the reported operator crossed that boundary. Validate SSM command history and endpoint records before deciding whether remote execution occurred. If a command ran, scope affected nodes and any credentials available to them.

Network blocking may help with a known source, but the server address is less durable than the behavior. Elastic notes that the associated interfaces were no longer served as of November. A new server could repeat the same credential-validation and retrieval pattern. Preserve a long enough lookback to connect a quiet return with earlier access.

What Does This Case Prove About AI-Assisted Intrusions?

Elastic observed a server attributable to CyberStrikeAI and a machine-speed request burst. Those facts support its description of an AI-assisted intrusion, but they cannot show whether an LLM selected the actions. The report does not name an actor or demonstrate how the credentials were obtained. It also stops short of confirming the SSM command’s result.

The agentic threat intelligence guide explains the wider concept. The practical lesson in this case is the value of identity-centered correlation. A fast burst may warrant immediate investigation, while a subsequent quiet period does not close the case.

Security teams need to preserve the relationship between credentials, source context and sensitive API calls across days. That relationship is more useful than treating 78 individually modest alerts as 78 separate events.