SQS and Lambda SQL Injection

This hard lab demonstrates that serverless applications are just as vulnerable to classic web flaws such as SQL injection as traditional stacks. Starting with leaked AWS keys, you enumerate IAM permissions, brute force a hidden Lambda event parameter, and craft messages to an SQS queue that a Lambda consumes and passes into a database query. The result is a second-order SQL injection that exfiltrates sensitive customer data.

During a red team engagement you discovered hardcoded AWS credentials and a reference to the eu-north-1 region. With the engagement wrapping up, you want to determine what infrastructure and sensitive data those keys unlock for one more impactful finding.

• Basic Linux command-line knowledge
• Familiarity with the AWS CLI and basic SQL

• Enumerate IAM permissions from access keys using aws-enumerator
• Enumerate and invoke Lambda functions and read and send SQS messages with the AWS CLI
• Brute force a required Lambda event parameter name using a wordlist and a bash script
• Craft SQS messages with custom attributes to control data that Lambda later processes
• Identify a second-order SQL injection where stored input is used in a later database query
• Determine column counts and extract data with UNION SELECT against a MySQL or MariaDB backend
• Enumerate the schema via INFORMATION_SCHEMA and exfiltrate customer records with CONCAT

Pairing Lambda with SQS to process untrusted messages is common in serverless designs, and when that message data reaches a database query without sanitization it opens the door to second-order SQL injection that leaks sensitive records. Parameterized queries and least-privilege IAM are the core defenses.