AWS Lambda Function Invoked Cross-Account
Identifies an AWS Lambda function invoked by a principal whose AWS account differs from the account that owns the function (a cross-account invocation). The caller's account is parsed from the invoking principal's ARN and compared to the function account. Adversaries who have been granted invoke permission on a function from an external account, or who operate from a separate attacker-controlled account, can use cross-account invocation to execute functions or retrieve the data they return. This is the data-plane counterpart to detecting the cross-account grant itself, and relies on AWS Lambda data event logging, which is not enabled by default.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2026/06/18"
3integration = ["aws"]
4maturity = "production"
5updated_date = "2026/06/18"
6
7[rule]
8author = ["Elastic"]
9description = """
10Identifies an AWS Lambda function invoked by a principal whose AWS account differs from the account that owns the
11function (a cross-account invocation). The caller's account is parsed from the invoking principal's ARN and compared to
12the function account. Adversaries who have been granted invoke permission on a function from an external account, or who
13operate from a separate attacker-controlled account, can use cross-account invocation to execute functions or retrieve
14the data they return. This is the data-plane counterpart to detecting the cross-account grant itself, and relies on AWS
15Lambda data event logging, which is not enabled by default.
16"""
17false_positives = [
18 """
19 Multi-account architectures and partner integrations legitimately invoke functions across account boundaries. Verify
20 the caller account, the principal in `aws.cloudtrail.user_identity.arn`, and the function against approved
21 cross-account access, and exclude known trusted accounts or identities after validation.
22 """,
23]
24from = "now-61m"
25interval = "60m"
26language = "esql"
27license = "Elastic License v2"
28name = "AWS Lambda Function Invoked Cross-Account"
29note = """## Triage and analysis
30
31### Investigating AWS Lambda Function Invoked Cross-Account
32
33A Lambda function invoked by a principal from a different AWS account indicates cross-account invocation - the data-plane realization of a cross-account resource-policy grant. CloudTrail data events record the invoking principal's ARN (which contains the caller's account) and the function's owning account. When these differ, an external account executed the function. This can be a legitimate multi-account integration or an adversary using granted or attacker-controlled cross-account access.
34
35#### Possible investigation steps
36
37- Review `Esql.caller_account` (the invoking principal's account) versus `Esql.function_account` (the invoked function's owning account) and confirm whether the caller account is a known, trusted account.
38- Identify the principal in `aws.cloudtrail.user_identity.arn` and pivot to the raw CloudTrail events (for the same principal/time window) to identify the invoked function(s) in `aws.cloudtrail.request_parameters`.
39- Determine whether a corresponding `AddPermission` cross-account grant exists for the function and whether it was expected (correlate with the cross-account resource-policy rule).
40- Review `Esql.source_ips` and recent activity from the caller account for other cross-account actions.
41
42### False positive analysis
43
44- Cross-account invocation is common in multi-account architectures and partner integrations. Confirm the caller account is approved and exclude known trusted accounts or identities after validation.
45
46### Response and remediation
47
48- If the cross-account access is unauthorized, remove the function's cross-account resource-policy statement (`RemovePermission`) and review what the function accessed or returned.
49- Constrain `lambda:InvokeFunction` grants to approved accounts and review the function's execution-role permissions.
50
51### Additional information
52
53- [Lambda resource-based policies](https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html)
54- [Logging Lambda data events with CloudTrail](https://docs.aws.amazon.com/lambda/latest/dg/logging-using-cloudtrail.html)
55"""
56references = [
57 "https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html",
58 "https://docs.aws.amazon.com/lambda/latest/dg/logging-using-cloudtrail.html",
59]
60risk_score = 47
61rule_id = "49002bbe-7aea-4146-91eb-b2b683bf5ed5"
62setup = """## Setup
63
64This rule requires AWS Lambda data events to be logged in CloudTrail and ingested via the AWS integration. Lambda
65invocation (`Invoke`) is a data-plane event and is NOT logged by default; enable data event logging for Lambda functions
66in the trail (optionally scoped to sensitive functions to manage volume).
67"""
68severity = "medium"
69tags = [
70 "Domain: Cloud",
71 "Data Source: AWS",
72 "Data Source: Amazon Web Services",
73 "Data Source: AWS Lambda",
74 "Use Case: Threat Detection",
75 "Tactic: Execution",
76 "Resources: Investigation Guide",
77]
78timestamp_override = "event.ingested"
79type = "esql"
80
81query = '''
82from logs-aws.cloudtrail-*
83
84| where
85 event.provider == "lambda.amazonaws.com"
86 and event.action like "Invoke*"
87 and event.outcome == "success"
88 and aws.cloudtrail.user_identity.arn IS NOT NULL
89 and aws.cloudtrail.user_identity.invoked_by IS NULL
90 and aws.cloudtrail.request_parameters IS NOT NULL
91
92| grok aws.cloudtrail.user_identity.arn """:(?<Esql.caller_account>[0-9]{12}):"""
93| grok aws.cloudtrail.request_parameters """functionName=arn:aws:lambda:[a-z0-9-]*:(?<Esql.function_account>[0-9]{12}):"""
94
95| where Esql.caller_account IS NOT NULL and Esql.function_account IS NOT NULL and Esql.caller_account != Esql.function_account
96
97| stats
98 Esql.invocation_count = count(*),
99 Esql.source_ips = values(source.ip),
100 Esql.function_arns = values(aws.cloudtrail.resources.arn)
101 by
102 aws.cloudtrail.user_identity.arn,
103 Esql.caller_account,
104 Esql.function_account
105
106| keep
107 aws.cloudtrail.user_identity.arn,
108 Esql.caller_account,
109 Esql.function_account,
110 Esql.function_arns,
111 Esql.invocation_count,
112 Esql.source_ips
113
114'''
115
116
117[[rule.threat]]
118framework = "MITRE ATT&CK"
119[[rule.threat.technique]]
120id = "T1648"
121name = "Serverless Execution"
122reference = "https://attack.mitre.org/techniques/T1648/"
123
124
125[rule.threat.tactic]
126id = "TA0002"
127name = "Execution"
128reference = "https://attack.mitre.org/tactics/TA0002/"
129
130[rule.investigation_fields]
131field_names = [
132 "aws.cloudtrail.user_identity.arn",
133 "Esql.caller_account",
134 "Esql.function_account",
135 "Esql.function_arns",
136 "Esql.invocation_count",
137 "Esql.source_ips",
138]
Triage and analysis
Investigating AWS Lambda Function Invoked Cross-Account
A Lambda function invoked by a principal from a different AWS account indicates cross-account invocation - the data-plane realization of a cross-account resource-policy grant. CloudTrail data events record the invoking principal's ARN (which contains the caller's account) and the function's owning account. When these differ, an external account executed the function. This can be a legitimate multi-account integration or an adversary using granted or attacker-controlled cross-account access.
Possible investigation steps
- Review
Esql.caller_account(the invoking principal's account) versusEsql.function_account(the invoked function's owning account) and confirm whether the caller account is a known, trusted account. - Identify the principal in
aws.cloudtrail.user_identity.arnand pivot to the raw CloudTrail events (for the same principal/time window) to identify the invoked function(s) inaws.cloudtrail.request_parameters. - Determine whether a corresponding
AddPermissioncross-account grant exists for the function and whether it was expected (correlate with the cross-account resource-policy rule). - Review
Esql.source_ipsand recent activity from the caller account for other cross-account actions.
False positive analysis
- Cross-account invocation is common in multi-account architectures and partner integrations. Confirm the caller account is approved and exclude known trusted accounts or identities after validation.
Response and remediation
- If the cross-account access is unauthorized, remove the function's cross-account resource-policy statement (
RemovePermission) and review what the function accessed or returned. - Constrain
lambda:InvokeFunctiongrants to approved accounts and review the function's execution-role permissions.
Additional information
References
Related rules
- AWS Lambda Function Invoked from an Unusual Source ASN
- AWS Lambda Function Invoked by an Unusual Principal
- AWS Lambda Layer Shared Externally
- AWS Lambda Layer Added to Existing Function
- AWS Lambda Function Policy Updated to Allow Cross-Account Invocation