WeirdAAL: The AWS Attack Library That Shows You What Compromised Credentials Can Really Do

Hook

A single compromised AWS access key with 'read-only' permissions can often escalate to full account takeover within minutes. WeirdAAL proves this by automating the exact attack chains adversaries use.

Context

Cloud penetration testing has always had an identity problem. Traditional network-based security tools don't translate well to API-driven infrastructure where the attack surface is defined by IAM policies rather than firewall rules. When security teams get valid AWS credentials during an engagement—through phishing, exposed .aws directories, or hardcoded keys in repositories—they face a critical question: what can an attacker actually do with these?

Before frameworks like WeirdAAL emerged around 2017-2018, AWS penetration testing was largely manual work. Security researchers would write one-off scripts to enumerate permissions, check for specific misconfigurations, or attempt privilege escalation. There was no systematic way to answer 'what's the blast radius of these compromised credentials?' WeirdAAL changed this by creating a library of real-world AWS attack patterns—organized by service, automatable, and designed to simulate actual adversary behavior rather than just check for compliance violations.

Technical Insight

WeirdAAL's architecture is refreshingly straightforward: it's a collection of Python modules that authenticate using boto3 and execute specific attack scenarios against AWS services. Each module represents a discrete attack technique, from enumerating IAM permissions to exploiting Lambda functions for code execution. The framework doesn't try to be clever with obfuscation or evasion—it focuses on demonstrating what's possible with given credentials.

The entry point is weirdAAL.py, which loads your AWS credentials from environment variables, credential files, or instance profiles. Attack modules are organized in the libs/ directory by AWS service. Here's how a typical reconnaissance flow works:

# Example from the IAM enumeration module
import boto3

def iam_bruteforce(key_id, secret_key, region):
    client = boto3.client(
        'iam',
        aws_access_key_id=key_id,
        aws_secret_access_key=secret_key,
        region_name=region
    )
    
    # Attempt to enumerate users
    try:
        users = client.list_users()
        print(f"[+] Found {len(users['Users'])} users")
        return users
    except client.exceptions.NoSuchEntityException:
        print("[-] No users found or no permission")
    except Exception as e:
        print(f"[-] Error: {e}")

What makes WeirdAAL valuable isn't sophisticated code—it's the curated collection of attack patterns based on real penetration tests. The framework includes modules for common privilege escalation paths like creating new IAM users with elevated permissions, attaching policies to existing roles, or exploiting iam:PassRole to gain Lambda execution context. Each module essentially asks: 'if I have permission X, what's the worst thing I can do?'

The S3 modules demonstrate this philosophy well. Rather than just listing buckets (defensive tools do this), WeirdAAL includes modules for exfiltrating data, checking for buckets with public write permissions that could be used for malware distribution, and identifying buckets that could be used for ransomware scenarios by testing deletion permissions. The s3_get_object_acls module specifically hunts for objects with overly permissive ACLs that differ from bucket policies—a common misconfiguration that's easy to miss in manual reviews.

One particularly interesting module is dynamodb_escalation.py, which tests whether compromised credentials can create new DynamoDB tables and use them as a persistence mechanism. Adversaries have used this technique to maintain access by storing backdoor credentials or exfiltrated data in tables that blend in with legitimate application infrastructure:

# Simplified DynamoDB persistence concept
def create_persistence_table(client, table_name):
    try:
        response = client.create_table(
            TableName=table_name,
            KeySchema=[{'AttributeName': 'id', 'KeyType': 'HASH'}],
            AttributeDefinitions=[{'AttributeName': 'id', 'AttributeType': 'S'}],
            BillingMode='PAY_PER_REQUEST'
        )
        # Store backdoor credentials
        client.put_item(
            TableName=table_name,
            Item={'id': {'S': 'backdoor'}, 'data': {'S': 'encoded_payload'}}
        )
        print(f"[+] Persistence established in {table_name}")
    except Exception as e:
        print(f"[-] Could not create table: {e}")

The framework also includes recon modules that map IAM permissions to potential attack paths. The iam_get_credential_report module generates AWS's own credential report, which shows password ages, MFA status, and access key rotation data—essentially a roadmap of the weakest authentication points in an account. Combined with iam_enumerate_roles, you can quickly identify service roles with trust relationships that might be exploitable for privilege escalation.

WeirdAAL's modular structure means you can chain operations together in Python scripts for more complex attack scenarios. A typical red team engagement might start with recon_all.py to map the environment, then selectively run privilege escalation modules based on discovered permissions, and finally execute persistence modules to maintain access. The framework logs all actions, which is critical for generating post-engagement reports that explain exactly how an attacker progressed through the environment.

Gotcha

The elephant in the room is that WeirdAAL hasn't seen significant updates since 2019-2020, and AWS has evolved dramatically since then. Services like AWS Security Hub, enhanced GuardDuty detections, and new services like Control Tower aren't covered. More critically, AWS has fixed several of the specific permission combinations that WeirdAAL's privilege escalation modules exploited. If you're testing modern AWS environments with mature security tooling, you'll find that many attack techniques trigger immediate alerts or simply don't work anymore due to service-level controls.

The framework is also incredibly noisy from a detection perspective. Every module makes direct API calls with no attempt at throttling or mimicking normal application behavior. In any environment with CloudTrail logging and basic SIEM integration, WeirdAAL will light up dashboards like a Christmas tree. The ec2_describe_all module, for instance, rapidly enumerates all EC2 resources across regions—a pattern that GuardDuty explicitly flags as reconnaissance behavior. This makes WeirdAAL unsuitable for realistic adversary simulation where stealth matters. It's better understood as a 'can we do this?' testing tool rather than a 'how would an attacker actually do this?' simulation framework. For truly stealthy testing, you'd need to manually execute specific techniques with proper timing and blending, which defeats the purpose of using an automation framework.

Verdict

Use if you're conducting authorized AWS penetration tests and need to quickly demonstrate the blast radius of compromised credentials, especially in environments without mature security monitoring. WeirdAAL excels at answering 'what's the worst case scenario?' during security assessments and provides a great learning resource for understanding AWS attack patterns. It's particularly valuable for red team engagements where you've already gained initial access and need to map out privilege escalation paths for reporting purposes. Skip if you need modern AWS service coverage (use Pacu instead, which is actively maintained), require stealthy operations that won't trigger GuardDuty, or are looking for preventive scanning rather than active exploitation. Also skip if you're testing environments with mature security postures—you'll spend more time figuring out why modules fail than gaining useful insights. WeirdAAL is best viewed as a teaching tool and rapid assessment framework for AWS security fundamentals, not a production-ready red team toolkit for sophisticated engagements.