As reported by Elastic Security Labs, a CyberStrikeAI server spent 16 days operating across four AWS accounts using eight compromised identities, generating only low and medium severity alerts that individually looked routine but collectively revealed a sophisticated intrusion pattern.

Cloud Security Alert: As reported by Elastic Security Labs, a CyberStrikeAI server spent 16 days operating across four AWS accounts using eight compromised identities, generating only low and medium severity alerts that individually looked routine but collectively revealed a sophisticated intrusion pattern.

The Detection Problem Nobody Wants to Acknowledge

The most striking finding isn't that 56 EC2 user data requests happened in 141 milliseconds — that's a machine speed signature, and it's useful. The genuinely alarming signal is that 78 alerts were generated across four days of activity spread over 16 calendar days, and no single detection rule captured the full picture. Six rules each caught a fragment. The attack survived because defenders are still operating with correlation windows measured in hours when adversaries operate across weeks.

This is the core failure mode of contemporary cloud detection engineering. AWS CloudTrail logs every API call, but the overwhelming majority of those calls are legitimate infrastructure automation. An attacker who validates credentials, reads Secrets Manager values, pulls EC2 user data, and issues SSM commands is executing a playbook that looks identical to a Terraform run or an Ansible deployment. The difference isn't in what happens — it's in who does it, when, and from where.

The 14-day gap between burst sessions did more damage than the initial reconnaissance. Fixed correlation windows cannot span that distance, which means the most dangerous phase of the intrusion was effectively invisible to standard detection logic.

Why Source IP Correlation Should Be Your First Pivot

Elastic's analysis makes clear that all 78 alerts only became coherent when correlated by source IP address. This should not be a revelation in 2026, but it remains underutilized in practice. Most SIEM correlation rules group by identity or resource ARN. When an attacker rotates across eight identities and four accounts, identity-based correlation fragments the story. Source IP correlation, combined with user-agent analysis and temporal clustering, reconstructs it.

The three tied infrastructure IPs (43[.]240[.]29[.]11, .28, and .33) sharing a self-signed certificate is the kind of pivot that threat hunting teams should be building into retrospective queries today. These IPs are no longer serving the CyberStrikeAI interface, but the indicators are valid for historical threat hunts across your CloudTrail data.

Who Is Most Exposed

Why Source IP Correlation Should Be Your First Pivot
Multi-account AWS organizations with shared IAM patterns and cross-account role trusts — the lateral movement between four accounts exploited exactly this architecture
Teams using EC2 user data scripts with embedded secrets or bootstrap logic — the 141ms burst targeted these specifically
Organizations relying on SSM Run Command without command logging or SSM Session Manager auditing — CloudTrail does not capture the command content
Environments where Secrets Manager access is broadly granted rather than scoped to specific secret ARNs

The AI Attribution Question

Elastic is appropriately cautious about calling this an LLM-driven attack. CyberStrikeAI pairs language model agents with offensive tooling, but CloudTrail cannot prove an LLM was making decisions. What the logs do prove is machine-speed execution of a recognizable cloud attack playbook. Whether a human, a script, or a model was orchestrating matters less than the operational reality: the tooling exists, it is open-source, and it is now being pointed at cloud infrastructure. Expect more of this.

Shield53 Recommendations

  • Extend correlation windows to 30 days minimum for identity-based detections across all AWS accounts in your organization. The 14-day gap in this intrusion would have been caught.
  • Hunt by source IP immediately. Query your CloudTrail for any API calls from 43[.]240[.]29[.]11, .28, and .33. Look for the same pattern: DescribeInstances followed by GetUserData or GetSecretValue within seconds.
  • Scope Secrets Manager access. Replace broad "secretsmanager:GetSecretValue" on wildcard resources with resource-level permissions tied to specific secret ARNs and KMS keys.
  • Enable SSM command auditing. CloudTrail logs that SendCommand was issued but not what the command contained. Configure SSM Session Manager with full command logging and route it to your SIEM separately.
  • Build behavioral baselines per identity. If an IAM user or role that typically makes 20 API calls per day suddenly makes 56 in 141 milliseconds, that deviation should generate an alert regardless of whether each individual call is "legitimate."
  • Monitor for new source IPs hitting your AWS API endpoints. Any identity accessing AWS from a previously unseen IP should trigger a review, especially if that IP is associated with known offensive tooling infrastructure.

The fundamental lesson from this intrusion is architectural: detection rules that operate on individual events within fixed time windows will always lose to attackers who spread low-signal actions across multiple identities, accounts, and days. The defense is correlation — by source, by identity, by behavioral baseline, and by threat intelligence — applied across the full attack timeline, not just the moment a rule fires.