Hijacking Amazon EventBridge for launching Cross

Cross-account EventBridge configurations facilitate legitimate service-to-service communication but introduce security risks when not secured. This architecture allows for the flow of events between accounts, which can be exploited for infiltration and exfiltration by attackers. Infiltration occurs when untrusted accounts send events that trigger processing in target accounts, bypassing network controls. Exfiltration involves sending sensitive data out through EventBridge to external accounts, potentially evading traditional data loss prevention measures due to the nature of event payloads.
Six specific attack patterns leverage these capabilities: Persistent Beaconing for maintaining presence, Command and Control for bidirectional communication, Reconnaissance for mapping infrastructure, Data Exfiltration by smuggling small chunks of data within events, Cross-Account Movement via account hopping by leveraging trust relationships, and API Borrowing where event processing logic is vulnerable to executing arbitrary AWS API calls.
Effective security requires a layered approach: preventive controls like Service Control Policies (SCPs) to restrict cross-account access, granular IAM permissions, and resource policies applied to EventBridge targets. Detection strategies must focus on monitoring specific metrics like PutEvents API calls, analyzing CloudTrail for rule modifications, implementing content validation in processing functions, and establishing behavioral baselines for event activity.

* EventBridge enables integrations across multiple AWS accounts.
* A typical setup involves a Source Account, Destination Account, Event Rules, Event Targets (e.g., Lambda, SQS), and IAM Roles.
* Attack 1 involves sending regular "check-in" events to establish persistence via EventBridge.
* Attack 2 uses EventBridge for bidirectional Command and Control by sending commands and receiving responses in event payloads.
* Attack 3 involves creating an EventBridge rule to capture all events within an account and target an attacker-controlled resource.
* Attack 4 involves exfiltrating data by breaking sensitive information into small chunks and sending them as disguised telemetry events.
* Attack 5 involves "Account Hopping" by exploiting cross-account EventBridge rules and roles to move between accounts.
* Attack 6 involves an API Borrowing attack where a vulnerable Lambda processes event data to execute unintended AWS API calls, using trust relationships to exfiltrate secrets.
* Preventive controls include SCPs, IAM permissions following least privilege, and resource policies on event buses.
* Detection strategies involve monitoring CloudWatch metrics for EventBridge API calls, analyzing CloudTrail for rule changes, content analysis of events, behavioral analytics, and cost monitoring.

The narrative of EventBridge vulnerability highlights a fundamental tension between the architectural benefits of decoupled, event-driven systems and the security requirement for strict boundary enforcement. The core vulnerability lies in treating the data plane (event flow) as inherently trusted, particularly across organizational boundaries where implicit trust is often configured via IAM relationships. Attacks like Persistent Beaconing and Command and Control reveal that legitimate service integrations can be repurposed into covert communication channels, leveraging services like EventBridge which are often overlooked by traditional perimeter defenses.
The infiltration patterns demonstrate a systemic risk in relying solely on network controls when data flows across logical AWS boundaries. The ability to leverage cross-account rules for lateral movement, as seen in Account Hopping, suggests that configuration drift and inherited trust policies become exploitable attack surfaces. Furthermore, the API Borrowing attack exposes a critical failure point: the blind trust placed in event payloads flowing between accounts; if an intermediary service lacks rigorous input validation, it becomes an execution vector for privileged actions across account boundaries.
The recommended defense structure—combining preventative controls (SCPs denying cross-organizational access), architectural segmentation (using resource policies to enforce explicit source accountability), and continuous detective monitoring (analyzing EventBridge API calls and event content)—addresses the full spectrum of risk. The challenge lies in consistently applying these layered controls across complex, evolving architectures, ensuring that the operational efficiency gained from cross-account events does not inadvertently create new vectors for sophisticated threat activity. What assumptions about trust mechanisms within large organizations are being implicitly accepted when designing cross-account flows? How can organizations architecturally mandate verifiable data provenance rather than relying on assumed identity to mitigate these pervasive risks?