Lesson 07 — AWS Lambda & Serverless Security

Learning Objectives

By the end of this lesson, you will be able to:

Understand AWS Lambda architecture.
Identify the AWS Lambda attack surface.
Assess Lambda execution roles.
Review event sources and triggers.
Identify serverless security weaknesses.
Understand Lambda privilege escalation risks.
Perform enterprise AWS Lambda security assessments.

Introduction

Serverless computing has transformed the way modern cloud applications are built.

AWS Lambda enables developers to execute code without managing servers.

Today, thousands of enterprise workloads use Lambda for:

APIs
Data Processing
Event Automation
CI/CD
Security Automation
Image Processing
Scheduled Jobs
File Processing
Machine Learning Pipelines

Although Lambda removes server management, it does not eliminate security risks.

Instead, attackers focus on:

IAM Roles
Environment Variables
Event Sources
Secrets
Vulnerable Dependencies
Third-party Libraries
API Integrations

Understanding these risks is essential for every Cloud Penetration Tester.

Enterprise Scenario

CloudNova Technologies has been contracted to perform a security assessment of FinSecure Bank Ltd.

The organization operates:

340 AWS Lambda Functions
Amazon API Gateway
Amazon EventBridge
Amazon S3 Triggers
Amazon DynamoDB Streams
AWS Step Functions
Amazon SNS
Amazon SQS

Management wants to determine whether attackers could abuse serverless workloads to compromise the AWS environment.

AWS Lambda Architecture

User Request

↓

Amazon API Gateway

↓

AWS Lambda

↓

Execution Role

↓

AWS Services

↓

Amazon S3

↓

DynamoDB

↓

Secrets Manager

↓

CloudWatch Logs

The security of a Lambda function depends heavily on its execution role and configuration.

AWS Lambda Components

Each Lambda function consists of:

Function Code
Runtime
Execution Role
Environment Variables
Event Sources
Layers
Dependencies
Resource Policy
CloudWatch Logs

Every component should be reviewed during an enterprise security assessment.

AWS Lambda Attack Surface

Cloud Penetration Testers typically review:

Execution Roles
Environment Variables
Secrets
Lambda Layers
Function URLs
API Gateway Integration
IAM Policies
Event Sources
Logging Configuration
Third-party Libraries

Weaknesses in any of these components may enable privilege escalation or data exposure.

Common Lambda Misconfigurations

Frequently observed issues include:

Administrator execution roles
Secrets stored in environment variables
Hardcoded AWS credentials
Public Lambda Function URLs
Outdated runtime versions
Vulnerable dependencies
Excessive IAM permissions
Missing logging
Unrestricted invocation permissions
Shared execution roles

Lambda Execution Roles

Every Lambda function executes using an IAM Role.

Example:

Lambda Function

↓

Execution Role

↓

Amazon S3

↓

Secrets Manager

↓

Amazon DynamoDB

↓

Amazon SNS

Review:

Attached policies
Trust policy
Administrator permissions
Wildcard actions
Least privilege

Execution roles are often the most valuable target in serverless environments.

Event Sources

Lambda can be triggered by numerous AWS services.

Examples:

Amazon API Gateway
Amazon S3
Amazon EventBridge
Amazon SNS
Amazon SQS
DynamoDB Streams
AWS Step Functions
CloudWatch Events

Review whether event sources are properly restricted and authenticated.

Environment Variables

Environment variables commonly contain:

API Keys
Database URLs
Configuration Values
Feature Flags
Third-party Tokens

Example:

DB_HOST

API_KEY

SECRET_TOKEN

AWS_REGION

Sensitive values should never be stored in plaintext.

Use AWS Secrets Manager or AWS Systems Manager Parameter Store instead.

Lambda Layers

Layers allow reusable libraries to be shared across functions.

Review:

Outdated libraries
Vulnerable packages
Third-party dependencies
Untrusted code

Compromised layers may affect multiple Lambda functions simultaneously.

Lambda Function URLs

AWS Lambda supports direct HTTPS endpoints.

Review:

Authentication
Authorization
Public accessibility
Resource policies

Unrestricted Function URLs may expose internal business logic.

Resource Policies

Lambda resource policies define who may invoke a function.

Example:

{
  "Effect": "Allow",
  "Principal": "*",
  "Action": "lambda:InvokeFunction"
}

Review for:

Wildcard principals
Cross-account access
Public invocation
Missing conditions

Dependency Security

Review:

Open-source libraries
Runtime versions
Vulnerable packages
Software supply chain risks

Use tools such as:

Trivy
Syft
Grype
Dependabot

to identify outdated or vulnerable dependencies.

Logging & Monitoring

Review:

CloudWatch Logs
CloudTrail
AWS Config
GuardDuty Findings

Verify:

Invocation logging
Error logging
Security monitoring
Audit trail retention

Proper logging supports incident response and forensic investigations.

Enterprise Attack Path

Public API

↓

AWS Lambda

↓

Execution Role

↓

Secrets Manager

↓

Database Credentials

↓

Amazon RDS

↓

Sensitive Customer Data

A vulnerable Lambda function can become the initial entry point into an AWS environment.

Lambda Enumeration Commands

List Lambda functions

aws lambda list-functions

Retrieve function configuration

aws lambda get-function-configuration \
--function-name FUNCTION_NAME

Retrieve function policy

aws lambda get-policy \
--function-name FUNCTION_NAME

List event source mappings

aws lambda list-event-source-mappings

List Lambda layers

aws lambda list-layers

Review IAM role

aws iam get-role \
--role-name ROLE_NAME

Enterprise Assessment Workflow

Professional consultants generally follow this process.

Enumerate Lambda Functions

↓

Review Execution Roles

↓

Review Event Sources

↓

Review Environment Variables

↓

Review Function URLs

↓

Review Layers

↓

Review Resource Policies

↓

Review Logging

↓

Identify Attack Paths

↓

Document Findings

Common Enterprise Findings

Examples include:

Administrator execution roles
Wildcard IAM permissions
Secrets in environment variables
Public Lambda Function URLs
Missing CloudWatch logging
Outdated runtimes
Shared execution roles
Vulnerable third-party libraries
Weak resource policies
Excessive cross-account invocation permissions

Security Best Practices

Apply least-privilege execution roles.
Store secrets in AWS Secrets Manager.
Enable CloudWatch logging.
Enable CloudTrail auditing.
Restrict Lambda Function URLs.
Review event source permissions regularly.
Keep runtimes and dependencies updated.
Scan Lambda packages before deployment.
Use separate execution roles for different functions.

Common Mistakes

Avoid:

Using AdministratorAccess for Lambda execution roles.
Storing secrets in environment variables.
Leaving Function URLs publicly accessible.
Ignoring dependency vulnerabilities.
Sharing execution roles across unrelated workloads.
Disabling logging.
Failing to rotate secrets.

Knowledge Check

1. What is the primary security component of an AWS Lambda function?

Answer: The Lambda execution role, as it determines which AWS resources the function can access during execution.

2. Why should secrets not be stored in Lambda environment variables?

Answer: Environment variables may be exposed to users with configuration access. Sensitive information should instead be stored securely in AWS Secrets Manager or AWS Systems Manager Parameter Store.

3. What are Lambda Layers?

Answer: Lambda Layers are reusable packages that contain libraries, dependencies or runtime components shared across multiple Lambda functions.

4. Why should Function URLs be reviewed during a security assessment?

Answer: Publicly accessible Function URLs without proper authentication or authorization may expose internal application logic and increase the attack surface.

5. Why are execution roles frequently targeted during AWS penetration tests?

Answer: Execution roles often grant access to other AWS services. Compromising a function with excessive permissions may allow attackers to access storage, databases, secrets or additional cloud resources.

Key Takeaways

AWS Lambda introduces a unique serverless attack surface centered on identities, event sources and application dependencies.
Execution roles are the most critical security control for Lambda functions.
Secrets should be managed using dedicated secret management services rather than environment variables.
Reviewing event sources, resource policies and logging provides a comprehensive view of Lambda security.
Enterprise serverless assessments should evaluate the entire execution chain, from invocation through downstream AWS service access.

What’s Next?

In the next lesson, you will explore Lesson 08 — Amazon EKS Offensive Security, where you will learn how attackers assess Kubernetes clusters running on Amazon EKS, enumerate workloads, analyze RBAC, service accounts, secrets and identify Kubernetes-specific attack paths in enterprise AWS environments.

➡️ Next Lesson: Lesson 08 — Amazon EKS Offensive Security