<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Aws-Lambda - CraftedSignal Threat Feed</title><link>https://feed.craftedsignal.io/tags/aws-lambda/</link><description>Trending threats, MITRE ATT&amp;CK coverage, and detection metadata. Fed continuously.</description><generator>Hugo</generator><language>en</language><managingEditor>hello@craftedsignal.io</managingEditor><webMaster>hello@craftedsignal.io</webMaster><lastBuildDate>Fri, 03 Jul 2026 15:55:55 +0000</lastBuildDate><atom:link href="https://feed.craftedsignal.io/tags/aws-lambda/feed.xml" rel="self" type="application/rss+xml"/><item><title>AWS Lambda Function Invoked Cross-Account</title><link>https://feed.craftedsignal.io/briefs/2026-07-aws-lambda-cross-account-invocation/</link><pubDate>Fri, 03 Jul 2026 15:55:55 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2026-07-aws-lambda-cross-account-invocation/</guid><description>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.</description><content:encoded><![CDATA[<p>This 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 (<code>aws.cloudtrail.user_identity.arn</code>) and the invoked function's owning account ARN (<code>aws.cloudtrail.request_parameters</code>). This behavior, while potentially legitimate in multi-account architectures, warrants investigation when observed.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>An adversary gains control over an AWS account or secures <code>lambda:InvokeFunction</code> permissions for a target Lambda function in a different AWS account.</li>
<li>The adversary initiates an <code>Invoke</code> API call to the target Lambda function from their external or controlled AWS account.</li>
<li>The AWS Lambda service processes the cross-account invocation request, authenticating the invoking principal.</li>
<li>The invoked Lambda function executes, performing its defined operations within the victim's AWS environment.</li>
<li>AWS CloudTrail logs the successful <code>Invoke</code> data event, including the ARN of the invoking principal and the ARN of the function.</li>
<li>The 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.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>If 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.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Enable AWS Lambda data event logging in CloudTrail, as described in the <code>setup</code> section of the source rule, to ensure the necessary telemetry is captured for this detection.</li>
<li>Implement the detection logic outlined in the provided Elastic rule within your SIEM to identify cross-account Lambda function invocations.</li>
<li>When an alert triggers, review the <code>aws.cloudtrail.user_identity.arn</code> and <code>aws.cloudtrail.request_parameters</code> fields to determine the caller and function accounts, validating against known, trusted cross-account access.</li>
<li>Investigate recent activity from the <code>Esql.caller_account</code> and <code>Esql.source_ips</code> identified by the detection for other suspicious cross-account actions.</li>
<li>If an unauthorized cross-account invocation is confirmed, promptly remove the <code>lambda:InvokeFunction</code> permissions using <code>RemovePermission</code> and review what the function accessed or returned, as suggested in the <code>response and remediation</code> section of the source.</li>
</ul>
]]></content:encoded><category domain="severity">medium</category><category domain="type">advisory</category><category>cloud</category><category>aws</category><category>aws-lambda</category><category>execution</category><category>cloud-security</category></item></channel></rss>