detecting-serverless-function-injection

Detects code injection, event poisoning, and IAM privilege escalation in AWS Lambda functions.

954|172|Updated Mar 13, 2026
One-click install
npx skills add https://github.com/xalgord/xalgorix --skill detecting-serverless-function-injection
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: detecting-serverless-function-injection
Source: https://github.com/xalgord/xalgorix/tree/main/internal/tools/skills/data/cloud-security/detecting-serverless-function-injection
Command: npx skills add https://github.com/xalgord/xalgorix --skill detecting-serverless-function-injection

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires boto3, bandit, semgrep.

What problem does it solve?

Serverless functions process untrusted event data from S3, SQS, API Gateway, and DynamoDB Streams, creating injection paths that traditional scanners miss. This Skill gives security analysts a structured workflow to find code injection sinks, malicious Lambda layers, and privilege escalation paths before attackers exploit them.

Core Features & Use Cases

  • Static Injection Analysis: Scan function code with Semgrep and Bandit to find event data flowing into eval, exec, os.system, and child_process sinks across Python and Node.js runtimes.
  • CloudTrail Threat Detection: Query CloudTrail and CloudWatch Logs Insights for unauthorized UpdateFunctionCode events, malicious layer attachments, and PassRole-based privilege escalation.
  • Runtime Prevention Controls: Deploy input validation decorators, least-privilege execution roles, SCPs, and EventBridge alerting rules to block injection at execution time.
  • Use Case: A SOC analyst investigating a GuardDuty credential exfiltration alert uses this Skill to trace a modified Lambda function, identify the injected code, find the exfiltrated role credentials, and deploy preventive SCPs.

Quick Start

Audit my AWS Lambda functions for code injection vulnerabilities and privilege escalation paths using static analysis and CloudTrail event correlation.

Frequently Asked Questions about detecting-serverless-function-injection

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I detect code injection in AWS Lambda functions?

Download the function deployment package and scan it with Semgrep and Bandit to find event data flowing into eval, exec, os.system, or subprocess with shell=True. Then correlate with CloudTrail events like UpdateFunctionCode20150331v2 to detect unauthorized modifications.

What is Lambda event source poisoning and how do I find it?

Event source poisoning injects malicious payloads through S3 object keys, SQS message bodies, API Gateway headers, or DynamoDB Stream records that the function processes unsafely. Detect it by mapping event source mappings, reviewing handler code for unsanitized event fields, and querying CloudWatch Logs for injection error patterns.

Why does CloudTrail not show Lambda Invoke events by default?

Lambda Invoke is a CloudTrail data event, which is disabled by default, so you only see management events like UpdateFunctionCode. Enable data events for AWS::Lambda::Function in your trail's event selectors to capture malicious invocations carrying injection payloads.

How can attackers escalate privileges through Lambda functions?

An attacker with lambda:UpdateFunctionCode and iam:PassRole can modify a function to run with a higher-privilege execution role, then exfiltrate its temporary credentials from environment variables. Detect this by monitoring PassRole events and API calls from assumed Lambda role sessions.

Can a malicious Lambda layer persist after reverting function code?

Yes, layers attach via UpdateFunctionConfiguration and survive code-only reverts, intercepting imports like boto3 through /opt/python or /opt/nodejs/node_modules. Audit layer ARNs for external accounts and inspect layer contents for suspicious network or subprocess code.

When should I not run serverless injection testing?

Avoid testing against production functions processing live customer data without explicit authorization, and do not modify IAM policies in shared accounts without change management approval. This workflow is for authorized assessment and detection, not load testing or denial-of-service simulation.