AWS Lambda Function Policy Updated to Allow Public Invocation | Elastic Security [8.19] | Elastic

AWS Lambda Function Policy Updated to Allow Public Invocation

IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

AWS Lambda Function Policy Updated to Allow Public Invocation

Identifies when an AWS Lambda function policy is updated to allow public invocation. This rule detects use of the AddPermission API where the Principal is set to "*", enabling any AWS account to invoke the function. Adversaries may abuse this configuration to establish persistence, create a covert execution path, or operate a function as an unauthenticated backdoor. Public invocation is rarely required outside very specific workloads and should be considered high-risk when performed unexpectedly.

Rule type: eql

Rule indices:

filebeat-*
logs-aws.cloudtrail-*

Severity: medium

Risk score: 47

Runs every: 5m

Searches indices from: now-6m ( Date Math format, see also [Additional look-back time](/content/guide/en/security/8.19/rules-ui-create.html#rule-schedule "Set the rule’s schedule"/index.html))

Maximum alerts per execution: 100

References:

Tags:

Domain: Cloud
Data Source: AWS
Data Source: Amazon Web Services
Data Source: AWS Lambda
Use Case: Threat Detection
Tactic: Persistence
Resources: Investigation Guide

Version: 8

Rule authors:

Elastic

Rule license: Elastic License v2

Investigation guide

Triage and analysis

Investigating AWS Lambda Function Policy Updated to Allow Public Invocation

AWS Lambda policies control who can invoke a function. When the Principal is set to *, the function becomes publicly invokable by any AWS account. Adversaries may modify Lambda permissions to create a stealthy execution backdoor or to maintain persistence inside an AWS environment. This activity is uncommon in most production environments and should receive careful scrutiny when detected.

Possible investigation steps

Identify the actor - Identify the actor who made the change by reviewing aws.cloudtrail.user_identity.arn and access key ID. Determine whether this principal typically administers Lambda functions.

Review request details - Review request details in aws.cloudtrail.request_parameters to understand the exact permission added: - Confirm that the Principal is set to "*". - Note the Action (lambda:InvokeFunction) and any SourceArn restrictions (sometimes present, often missing in malicious cases).

Analyze source context - Check the source of the request using source.ip, geo information, and user agent. Unexpected networks, automation tools, or CLI usage may indicate credential compromise.

Correlate timing and related events - Evaluate timing and sequence by correlating @timestamp with other events. Look for surrounding actions such as: - Creation or update of Lambda function code. - Publishing new Lambda layers. - Changes to roles attached to the function.

Assess function sensitivity and impact - Assess the function’s role and data sensitivity. Determine whether public invocation could: - Enable unmonitored code execution, - Trigger access to internal resources via the function’s IAM role, - Be chained with persistence or privilege escalation behavior.

Validate operational intent - Validate the operational context. Confirm with the function owner whether the permission change was intentional, part of a deployment, or unexpected.

False positive analysis

Public invocation may be intentional for certain workloads (e.g., webhook handlers, openly accessible compute functions). Compare the event with documentation, IaC templates, or the deployment pipeline.
Some teams may regularly modify permissions during testing or refactoring; check whether this aligns with existing workflows.
Evaluate whether the function already had permissive invocation policies and whether the update is part of expected configuration drift.

Response and remediation

Remove unauthorized public invocation permissions immediately by reverting the Lambda function policy to the approved baseline.
Investigate for follow-on activity: execution of the function, updates to code, modifications to IAM roles, or API calls issued using the function’s role.
Rotate or disable credentials associated with the identity that issued the AddPermission call if compromise is suspected.
Enable or refine monitoring for Lambda policy updates, layer additions, and code changes to detect future unauthorized modifications.
Conduct a security review of the Lambda function and any downstream resources it can access to ensure no misuse has occurred.
Work with the application team to enforce least-privilege invocation policies and deploy guardrails (e.g., SCPs, IAM Conditions, or automated compliance checks) preventing public invocation unless explicitly authorized.

Additional information

Rule query

info where data_stream.dataset == "aws.cloudtrail"
    and event.provider == "lambda.amazonaws.com"
    and event.outcome == "success"
    and event.action : "AddPermission*"
    and stringContains(aws.cloudtrail.request_parameters, "lambda:InvokeFunction")
    and stringContains(aws.cloudtrail.request_parameters, "principal=\\*")

Framework: MITRE ATT&CKTM

Tactic:
Name: Persistence
ID: TA0003
Reference URL: https://attack.mitre.org/tactics/TA0003/
Technique:
Name: Event Triggered Execution
ID: T1546
Reference URL: https://attack.mitre.org/techniques/T1546/
Tactic:
Name: Defense Evasion
ID: TA0005
Reference URL: https://attack.mitre.org/tactics/TA0005/
Technique:
Name: Modify Cloud Compute Infrastructure
ID: T1578
Reference URL: https://attack.mitre.org/techniques/T1578/
Sub-technique:
Name: Modify Cloud Compute Configurations
ID: T1578.005
Reference URL: https://attack.mitre.org/techniques/T1578/005/

« AWS Lambda Function Policy Updated to Allow Cross-Account Invocation AWS Lambda Function URL Created with Public Access »

On this page

a18132920325.cdn.optimizely.com is blocked

This page has been blocked by an extension

Try disabling your extensions.

ERR_BLOCKED_BY_CLIENT

Reload

This page has been blocked by an extension