AWS Lambda Function Policy Updated to Allow Cross-Account Invocation

edit

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

AWS Lambda Function Policy Updated to Allow Cross-Account Invocation

edit

Identifies a change to an AWS Lambda function resource policy that grants invoke permissions to an AWS account principal. Using AddPermission, an adversary can authorize a principal in another account to call a function, creating a cross-account backdoor for execution or for relaying data to attacker-controlled infrastructure without modifying the function’s code. This rule excludes public grants (principal set to "*"), which are covered by a separate rule, and grants to AWS service principals, which are common for legitimate event triggers.

Rule type: eql

Rule indices:

logs-aws.cloudtrail-*

Severity: high

Risk score: 73

Runs every: 5m

Searches indices from: now-6m (Date Math format, see also Additional look-back time)

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
Tactic: Defense Evasion
Resources: Investigation Guide

Version: 1

Rule authors:

Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating AWS Lambda Function Policy Updated to Allow Cross-Account Invocation

AWS Lambda resource policies control which principals may invoke a function. AddPermission granting lambda:InvokeFunction to a principal in another AWS account creates a cross-account invocation path. Adversaries use this to maintain execution access or to relay function output to infrastructure they control, without changing the function code that defenders typically scrutinize.

This rule detects grants of invoke permission to a specific external account, excluding public grants (handled by the related public-invocation rule) and AWS service principals used for normal event triggers.

Possible investigation steps

Inspect aws.cloudtrail.request_parameters for the functionName, the action granted, and the principal account id receiving access; confirm whether that account is known and trusted.
Identify the actor in aws.cloudtrail.user_identity.arn and aws.cloudtrail.user_identity.type, and review source.ip and user_agent.original to understand how the change was made.
Determine whether the function processes or has access to sensitive data that the external account could now reach.
Correlate with other activity by the same principal, including function code or configuration changes and additional policy modifications.
Verify whether the cross-account grant aligns with an approved integration or change request.

False positive analysis

Multi-account architectures and partner integrations legitimately grant cross-account invoke permissions. Confirm the grant is approved and exclude known trusted account ids or service roles on aws.cloudtrail.user_identity.arn after validation.

Response and remediation

If the grant is unauthorized, remove the statement from the function’s resource policy (RemovePermission) and review the function’s code, configuration, and execution role.
Determine whether the external account invoked the function while the grant was in place and assess data exposure.
Rotate or restrict credentials for the principal if compromise is suspected, and constrain lambda:AddPermission to a small set of trusted roles.

Additional information

Rule query

edit

any 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 not stringContains(aws.cloudtrail.request_parameters, "principal=\\*")
    and not stringContains(aws.cloudtrail.request_parameters, ".amazonaws.com")

Framework: MITRE ATT&CK^TM

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 Invoked from an Unusual Source ASN AWS Lambda Function Policy Updated to Allow Public Invocation »