In the evolving landscape of cloud security, a new tool named AWSDoor has emerged, posing significant risks to Amazon Web Services (AWS) environments. This sophisticated tool enables attackers to establish and maintain covert access within AWS accounts by exploiting Identity and Access Management (IAM) configurations and resource-based policies, all without deploying traditional malware.
Understanding AWSDoor’s Mechanisms
AWSDoor automates various persistence techniques, allowing adversaries to embed themselves within AWS infrastructures seamlessly. Its primary methods include:
1. IAM-Based Backdoors and Rogue Policies
AWSDoor manipulates AWS IAM to create stealthy backdoors. By injecting AccessKeys into compromised IAM users, attackers can secure command-line interface (CLI) persistence. This involves generating new AccessKey pairs that grant attacker-controlled credentials, which blend with legitimate traffic. To evade detection, AWSDoor can list existing keys, deactivate unused ones, and remove evidence of its activities.
Beyond AccessKeys, AWSDoor modifies TrustPolicy documents to backdoor IAM roles. By updating a role’s trust policy to include attacker-controlled principals, adversaries ensure a persistent cross-account AssumeRole capability. This method injects statements allowing `sts:AssumeRole` from an external account, granting durable, credential-less access that escapes simple credential logs.
2. Resource-Based Persistence via Poisoned Lambda Layers
AWSDoor’s resource-based persistence modules exploit AWS services themselves. For instance, the AdminLambda module provides a malicious Lambda function or layer with an over-privileged role attachment. By deploying a Lambda Layer containing poisoned libraries that override legitimate functions (e.g., a backdoored `requests.get()`), AWSDoor ensures code execution each time the function runs. Exposed via API Gateway or Function URL, this Lambda becomes a remote shell. This tactic conceals malicious code outside the main function body, bypassing routine console inspections and evading inline code reviews.
Mitigation Strategies
To defend against threats like AWSDoor, security teams should implement the following measures:
– Continuous Monitoring of IAM Policy Changes: Regularly monitor CloudTrail events such as `CreateAccessKey`, `UpdateAssumeRolePolicy`, and `PutRolePolicy` to detect unauthorized modifications.
– Implement AWS Config Custom Rules: Establish rules to flag rogue `NotAction` statements that grant near-administrator privileges.
– Audit Lambda Layer Attachments: Review `UpdateFunctionConfiguration` events and validate any externally accessible function URLs to ensure they haven’t been tampered with.
– Deploy Cloud Security Posture Management (CSPM) and Endpoint Detection and Response (EDR) Solutions: Utilize these tools to detect anomalous IAM modifications and unusual runtime behaviors.
As AWSDoor illustrates, attackers are increasingly shifting towards configuration-based persistence. Therefore, vigilant policy auditing and maintaining the integrity of telemetry data are essential to securing AWS environments.
