Loading

AWS Lambda Function Policy Updated to Allow Cross-Account Invocation

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-*

Rule Severity: high
Risk Score: 73
Runs every:
Searches indices from: now-6m
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

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.

  • 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.
  • 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.
  • 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.
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

Framework: MITRE ATT&CK