Fortifying Your Cloud Against Cross-Service Confused Deputy Attacks

Gartner predicts that worldwide end-user spending on public cloud services will exceed $720 billion in 2025, up from $595.7 billion in 2024. As cloud investments grow, so does reliance on cloud-native architectures, introducing new layers of complexity and risk. One often-overlooked but serious threat in these environments is the Cross-Service Confused Deputy Attack, which can expose critical services through unintended trust relationships among cloud components.

Below, we’ll explore how this attack can manifest in AWS services like AWS Elastic Load Balancing (ELB) logging configurations, analyze the underlying vulnerability, map it to relevant MITRE ATT&CK tactics, and outline comprehensive strategies for mitigation and prevention.

Understanding Cross-Service Confused Deputy Attack

In cloud environments, services often interact across accounts and boundaries. Misconfigurations or overly permissive trust policies can expose systems to unauthorized access or unintended data flows.

A Cross-Service Confused Deputy Attack occurs when a trusted service (the “deputy”) is tricked into performing actions on behalf of an untrusted principal, often due to misconfigured or insufficiently scoped permissions. This class of vulnerability is particularly insidious because the malicious action is executed by a trusted AWS service, bypassing basic access controls.

One example of a Cross-Service Confused Deputy Attack involves CloudTrail, an AWS service that records all activity across an organization’s AWS environment. These logs are important for regulatory audits and security assessments; however, the tool can also be exploited by attackers if permissions aren’t carefully governed.

CloudTrail’s logging feature can be used to write logs into a victim’s S3 bucket if the instance lacks account-specific condition keys. Because the service itself is authorized, AWS assumes the action is legitimate, even if a malicious actor initiated it.

Key points to consider:

• The attack abuses legitimate AWS service integrations.
• It often bypasses traditional permission boundaries.
• It can be hard to detect, as logs and actions are attributed to trusted services.

Understanding this type of attack is vital for building secure cloud architectures that assume trust boundaries can be blurred, if not explicitly enforced.

In-depth Example: AWS ELB and Logging to S3

Another common (and often overlooked) place this attack arises is AWS Elastic Load Balancing (ELB). Much like CloudTrail, AWS ELB can be configured to store access logs in Amazon S3 buckets for auditing and monitoring. This feature is particularly useful when aggregating logs from multiple services or accounts into a centralized audit account. To enable ELB logging, a specific bucket policy must be attached that permits the ELB service to write to the bucket. This process typically uses either a service principal (like logdelivery.elasticloadbalancing.amazonaws.com) or a region-specific AWS account ID.

Example Bucket Policy (Service Principal):

To understand where the risk lies, it’s helpful to look at how ELB logging permissions are typically configured. Here’s a common bucket policy that allows the ELB service to write logs to an S3 bucket:

Attack Analysis and Observation

While seemingly straightforward, the configuration above can introduce a confused deputy problem. The flaw lies in overly permissive bucket policies that do not restrict requests to originate from a specific AWS account. As a result, any AWS account could configure ELB to write logs to a bucket they do not own if they know the bucket name and the path structure.

This makes it possible for malicious actors to abuse AWS ELB to deliver logs (and thus write data) to a victim’s S3 bucket, a textbook Cross-Service Confused Deputy Attack.

Potential Attack Path

STEP 1: The victim sets up an S3 bucket for ELB logging with a generic bucket policy allowing logdelivery.elasticloadbalancing.amazonaws.com.

STEP 2: An attacker using another AWS account configures their ELB to write logs to the victim’s bucket.

STEP 3: AWS ELB service acts as a deputy and writes logs into the victim’s bucket under AWSLogs/<attacker-account-id>/….

STEP 4: Data written by the attacker may include misleading or malicious content, polluting logs, or wasting storage.

MITRE ATT&CK Framework Mapping

To help teams classify and respond to a Cross-Service Confused Deputy attack, we’ve mapped them to relevant information in the  MITRE ATT&CK Framework. These mappings provide additional context and support for detection and defense efforts:

T1530 – Data from Cloud Storage Object

Even though this attack only writes to a victim’s S3 bucket, if misconfigured, it may eventually allow read-back or manipulation of logs, which means attackers could hide their activity, mislead forensic investigations, or exfiltrate sensitive data.

T1190 – Exploit a Public-Facing Application

If the attacker identifies a flaw in the ELB logging mechanism, it could be combined with public endpoints to trigger unexpected behavior.

T1560.001 – Archive Collected Data: Archive via Utility

While not a direct match, if logs from multiple accounts are aggregated, an attacker may use this to exfiltrate or hide data in victim buckets.

T1659 – Content Injection

Attackers can use the ELB logging mechanism to insert unauthorized or misleading log data into a victim’s S3 bucket.

Impact of Potential Attack

While the impact of a Cross-Service Confused Deputy Attack may seem limited, it can have far-reaching consequences. This subtle manipulation can undermine the business’s security functions, increase operational expenses, and hinder the ability to meet compliance requirements.

Potential negative outcomes include:

• Deceptive Logging: Altering log integrity can hinder forensic analysis.
• Storage Bloat: The victim’s S3 storage may incur unexpected costs due to unauthorized or excessive log data.
• Compliance Risks: Undocumented log entries from unverified sources can lead to violations of regulatory or internal compliance standards.
• Denial of Audit: Loss of log fidelity can disrupt audits and incident response.

Strategies for Defending Against Cross-Service Confused Deputy Attacks

Fortunately, effective defenses against Cross-Service Confused Deputy Attacks can be achieved with a multi-layer security strategy. By implementing granular user permissions policies, strong data protections, and company-wide security best practices, developers can safeguard critical assets.

1. Secure Resource Policies and Identity and Access Management (IAM) Conditions

By prioritizing identity and access management best practices, you can control who can access and write logs to your S3 bucket.

Use Strict Resource ARNs

Always define precise Acquirer Reference Numbers (ARNs) in your bucket policy to narrow the allowed write path. This ensures only the intended logs are written and prevents abuse from other AWS accounts.

Example: “arn:aws:s3:::my-bucket/AWSLogs/111122223333/*”

Enforce aws:SourceAccount Condition

Add a condition to your bucket policy to validate that the request was initiated by your account, blocking unauthorized cross-account service interactions.

Example: “Condition”: { “StringEquals”: { “aws:SourceAccount”: “111122223333” } }

Apply the Least Privilege Principle

Avoid using broad permissions, such as s3:* or wildcards, in Resource. Grant only the required s3:PutObject permission to the ELB service.

2. Data Protection and Logging Integrity

Protecting the data logs and the storage container itself adds another layer of defense against Cross-Service Confused Deputy Attacks.

Enable Encryption

Use Amazon’s server-side encryption, SSE-KMS, to encrypt log files at rest. Also, ensure that logs are transmitted securely via HTTPS.

Use S3 Object Lock

Activate Object Lock in compliance or governance mode to make log objects immutable, which protects against tampering or accidental deletion.

Monitor Bucket Activity

Leverage AWS CloudTrail, CloudWatch, and Amazon GuardDuty to monitor access patterns. Set alerts for unusual write attempts or unknown service principals.

Enforce Secure S3 Defaults

AWS provides settings to block overly permissive access by default. The following configuration checks help ensure your buckets are protected from common misconfigurations:

• CID-59 Ensure Block new public bucket policies for a bucket is set to true.
• CID-379 Ensure S3 bucket must not allow WRITE permission for server access logs from everyone on the bucket.
• CID-60 Ensure that Block public and cross-account access if bucket has public policies for bucket is set to true.
• CID-61 Ensure block new public Access Control Lists (ACLs) and uploading public objects for a bucket is set to true.
• CID-63 Ensure Block new public bucket policies for an account is set to true.

3. Preventive Controls and Operational Practices

By thoroughly documenting and testing your security controls, you can contribute to the organization’s overall security hygiene.

Test and Verify IAM Policies

Use identity and access management tools, like AWS’s IAM Access Analyzer, and policy simulators to detect overly permissive or misconfigured policies before they’re deployed.

Document and Automate Best Practices

Embed secure configuration patterns into infrastructure-as-code (IaC) templates. Update internal documentation and onboarding materials so new team members follow these practices from day one.

Audit Third-Party Integrations

Review and validate IAM roles granted to third-party services to ensure they comply with internal security baselines and don’t introduce escalation paths.

Harden S3 Buckets for Logging Security

To ensure the integrity of your logging infrastructure, enable the following security settings across your S3 buckets:

• CID-57 Ensure S3 Bucket Policy is set to deny HTTP requests
• CID-67 Ensure all S3 buckets employ encryption-at-rest
• CID-47 Ensure access logging is enabled for S3 buckets

Granularity and Precision: Secure by Design

Cross-Service Confused Deputy Attacks highlight the importance of granular IAM controls, policy precision, and cloud-native security best practices. AWS ELB’s logging capability, while valuable, can become a vector for misuse if not properly secured. By enforcing condition keys, path restrictions, and vigilant monitoring, you can effectively mitigate these threats and ensure your likely growing cloud infrastructure remains secure and auditable.

Understanding the nuance of service integrations and trust boundaries is key in today’s interconnected cloud environments. As always, secure by design is the best strategy for managing the associated risks.

To learn more about preventing Cross-Service Confused Deputy Attacks, talk to a Qualys expert today.

References:

AWS doc explaining attack