AWSDoor: Hiding malware in the AWS Cloud Environment

Attackers are leveraging sophisticated techniques to maintain long-term access to cloud environments, and a new tool called AWSDoor is emerging as a significant threat. AWSDoor automates a series of IAM and resource-based persistence methods, allowing attackers to hide inside AWS accounts without deploying traditional malware.

IAM-Based Backdoors and Malicious Policies

AWSDoor abuses AWS Identity and Access Management (IAM) to create hidden backdoors. By injecting AccessKeys into compromised IAM users, attackers can gain persistent CLI presence. AWSDoor creates a new AccessKey pair, providing credentials that are controlled by the attacker and combined with legitimate traffic. To avoid detection, the tool can log existing keys, disable unused ones, and remove evidence.

See also: SmokeLoader: New capabilities for data theft and DoS attacks

In addition to AccessKeys, AWSDoor manipulates TrustPolicy documents to backdoor IAM roles. By updating a role's trust policy to include attacker-controlled principals, the adversary gains a persistent cross-account AssumeRole capability. The new policy introduces a statement that allows sts:AssumeRole from an external account, providing persistent, credential-free access that escapes simple CloudTrail credential logs.

Resource-based persistence modules

AWSDoor's resource-based persistence modules exploit AWS services themselves. For example, the AdminLambda module provides a malicious Lambda function or layer with an over-privileged role attachment. This module deploys a Lambda Layer containing poisoned libraries that replace legitimate functions, ensuring code execution every time the function is executed.

Exposed via API Gateway or Function URL, this Lambda becomes a remote shell. This tactic hides malicious code outside the main function body, bypassing routine console inspections and avoiding built-in code reviews.

Security teams should continuously monitor IAM policy changes, especially CloudTrail events such as CreateAccessKey, UpdateAssumeRolePolicy, and PutRolePolicy. Custom AWS Config rules can flag malicious NotAction statements that grant near- administrative privileges. Additionally, defenders should inspect Lambda layer attachments and validate any externally accessible function URLs.

See also: The AISURU Botnet behind the massive 11.5 Tbps DDoS attack

Using Cloud Security Posture Management (CSPM) and Cloud EDR solutions will allow detection of strange IAM modifications and unusual execution behaviors.

In conclusion, with AWSDoor, attackers are showing a shift towards configuration-based persistence. This situation makes security teams’ vigilance imperative.

The new AWSDoor threat

AWSDoor comes to confirm a new reality in cloud security: attacks are no longer based solely on traditional malware, but on “creative” abuse of the very tools provided by the platform. In the case of AWS, this means exploiting IAM settings, roles, and resource-based policies so that the attacker can turn legitimate infrastructure into a hidden base.

AWSDoor's innovation is that it turns identity and role management into an attack surface. Instead of hiding binaries or rootkits, it builds "shadow" credentials and hidden assume-role capabilities, making detection extremely difficult. Thus, the defender can look at an environment that appears perfectly legitimate, while in fact it hosts permanent access routes for the attacker.

See also: Maranhão Stealer is distributed through pirated software

This development also signals a shift in defense strategies. Monitoring must focus not just on endpoints or network traffic, but on the cloud settings themselves. Events that were previously considered “routine” — such as the creation of a new AccessKey or a change in trust policy — can now be the defining indicator of a major breach.

The message is clear: the cloud is not just infrastructure, but a living, shaping organization. And as adversaries exploit this fluidity, defense requires constant surveillance, automated controls, and a culture of zero trust, even within AWS itself.