Elastic high stable eql

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.

View Source

Detection Logic

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")

False Positives

⚠ Cross-account invoke permissions are used for legitimate multi-account architectures and partner integrations. Verify the granted account in `aws.cloudtrail.request_parameters`, the function, and the `principal` value in `aws.cloudtrail.request_parameters` against approved cross-account access. Known partner or internal account ids can be excluded after validation. This rule cannot distinguish a grant to the function's own account from an external account, so same-account resource-policy grants (uncommon, since same-account invocation normally uses IAM identity-based policies) will also alert.

Field Validations

Loading…

Comments (0)

Loading comments...