{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","feed_url":"https://feed.craftedsignal.io/tags/aws-lambda/feed.json","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["AWS Lambda"],"_cs_severities":["medium"],"_cs_tags":["cloud","aws","aws-lambda","execution","cloud-security"],"_cs_type":"advisory","_cs_vendors":["AWS"],"content_html":"\u003cp\u003eThis brief details a detection for cross-account AWS Lambda function invocations. Adversaries may leverage previously granted invoke permissions on a Lambda function, or operate from a separate attacker-controlled AWS account, to execute functions in a victim's environment. This activity, often a data-plane realization of an earlier cross-account resource-policy grant, allows an attacker to execute arbitrary code or retrieve sensitive data controlled by the function. The detection relies on capturing AWS Lambda data events through CloudTrail, which is not enabled by default, and identifying discrepancies between the invoking principal's account ARN (\u003ccode\u003eaws.cloudtrail.user_identity.arn\u003c/code\u003e) and the invoked function's owning account ARN (\u003ccode\u003eaws.cloudtrail.request_parameters\u003c/code\u003e). This behavior, while potentially legitimate in multi-account architectures, warrants investigation when observed.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn adversary gains control over an AWS account or secures \u003ccode\u003elambda:InvokeFunction\u003c/code\u003e permissions for a target Lambda function in a different AWS account.\u003c/li\u003e\n\u003cli\u003eThe adversary initiates an \u003ccode\u003eInvoke\u003c/code\u003e API call to the target Lambda function from their external or controlled AWS account.\u003c/li\u003e\n\u003cli\u003eThe AWS Lambda service processes the cross-account invocation request, authenticating the invoking principal.\u003c/li\u003e\n\u003cli\u003eThe invoked Lambda function executes, performing its defined operations within the victim's AWS environment.\u003c/li\u003e\n\u003cli\u003eAWS CloudTrail logs the successful \u003ccode\u003eInvoke\u003c/code\u003e data event, including the ARN of the invoking principal and the ARN of the function.\u003c/li\u003e\n\u003cli\u003eThe adversary potentially receives the function's output, allowing for data retrieval, or benefits from actions performed by the function, such as resource manipulation or further compromise.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eIf an unauthorized cross-account Lambda invocation succeeds, adversaries can execute arbitrary code within the context of the Lambda function's permissions, potentially leading to privilege escalation, data exfiltration from resources accessible by the function, or unauthorized modification of the victim's AWS environment. This can result in significant data breaches, service disruption, or complete compromise of the affected AWS account. While this activity can be legitimate in multi-account environments, unauthorized instances represent a critical security breach impacting data confidentiality, integrity, and availability.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable AWS Lambda data event logging in CloudTrail, as described in the \u003ccode\u003esetup\u003c/code\u003e section of the source rule, to ensure the necessary telemetry is captured for this detection.\u003c/li\u003e\n\u003cli\u003eImplement the detection logic outlined in the provided Elastic rule within your SIEM to identify cross-account Lambda function invocations.\u003c/li\u003e\n\u003cli\u003eWhen an alert triggers, review the \u003ccode\u003eaws.cloudtrail.user_identity.arn\u003c/code\u003e and \u003ccode\u003eaws.cloudtrail.request_parameters\u003c/code\u003e fields to determine the caller and function accounts, validating against known, trusted cross-account access.\u003c/li\u003e\n\u003cli\u003eInvestigate recent activity from the \u003ccode\u003eEsql.caller_account\u003c/code\u003e and \u003ccode\u003eEsql.source_ips\u003c/code\u003e identified by the detection for other suspicious cross-account actions.\u003c/li\u003e\n\u003cli\u003eIf an unauthorized cross-account invocation is confirmed, promptly remove the \u003ccode\u003elambda:InvokeFunction\u003c/code\u003e permissions using \u003ccode\u003eRemovePermission\u003c/code\u003e and review what the function accessed or returned, as suggested in the \u003ccode\u003eresponse and remediation\u003c/code\u003e section of the source.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-07-03T15:55:55Z","date_published":"2026-07-03T15:55:55Z","id":"https://feed.craftedsignal.io/briefs/2026-07-aws-lambda-cross-account-invocation/","summary":"Adversaries leverage cross-account access to invoke AWS Lambda functions from a different account than the function owner, enabling code execution or data retrieval, which requires AWS Lambda data event logging to detect.","title":"AWS Lambda Function Invoked Cross-Account","url":"https://feed.craftedsignal.io/briefs/2026-07-aws-lambda-cross-account-invocation/"}],"language":"en","title":"CraftedSignal Threat Feed - Aws-Lambda","version":"https://jsonfeed.org/version/1.1"}