AWS Lambda Function Invoked from an Unusual Source ASN

Identifies an AWS Lambda function invoked directly by a principal from a source network (ASN) not seen for that principal in the prior 10 days, excluding common cloud provider networks. Direct invocation from an unfamiliar external network can indicate use of stolen execution-role or user credentials from attacker-controlled infrastructure to execute functions or retrieve the data they return. This rule 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 directly by a principal from a source network (ASN) not seen for that
 11principal in the prior 10 days, excluding common cloud provider networks. Direct invocation from an unfamiliar external
 12network can indicate use of stolen execution-role or user credentials from attacker-controlled infrastructure to execute
 13functions or retrieve the data they return. This rule relies on AWS Lambda data event logging, which is not enabled by
 14default.
 15"""
 16false_positives = [
 17    """
 18    Operators and automation may legitimately invoke functions from new networks (new offices, VPNs, home IPs, or new
 19    egress infrastructure). Verify the principal in `aws.cloudtrail.user_identity.arn`, the source network, and the
 20    function, and exclude known operator networks or identities after validation.
 21    """,
 22]
 23from = "now-6m"
 24index = ["logs-aws.cloudtrail-*"]
 25interval = "5m"
 26language = "kuery"
 27license = "Elastic License v2"
 28name = "AWS Lambda Function Invoked from an Unusual Source ASN"
 29note = """## Triage and analysis
 30
 31### Investigating AWS Lambda Function Invoked from an Unusual Source ASN
 32
 33Lambda execution-role credentials and user credentials are frequently abused after theft (for example via SSRF or RCE against a function, or leaked access keys). When such credentials are replayed from attacker infrastructure, the resulting direct `Invoke` calls originate from a network the legitimate principal has not used. This rule uses a new terms approach over the source ASN organization and the principal, excluding common cloud provider networks, to surface invocation from unfamiliar external networks.
 34
 35### Possible investigation steps
 36
 37- Review `source.ip`, `source.as.organization.name`, and `source.geo` for the invoking network and determine whether it is expected for the principal in `aws.cloudtrail.user_identity.arn`.
 38- Inspect `aws.cloudtrail.request_parameters` for the `functionName` and `user_agent.original` for the client used.
 39- Determine whether the credential (`aws.cloudtrail.user_identity.access_key_id`) was recently seen used elsewhere or outside the Lambda runtime, which would corroborate credential theft.
 40- Correlate with other activity by the same principal from the same network, including data-plane access, IAM, or STS calls.
 41
 42### False positive analysis
 43
 44- New legitimate networks (offices, VPNs, home IPs, new egress) will generate this alert. Confirm the principal and network are expected and exclude known operator networks or identities after validation.
 45- If source ASN is legitimate and expected, add as an exclusion to reduce false-positives.
 46
 47### Response and remediation
 48
 49- If credential abuse is confirmed, rotate or revoke the affected credentials and execution-role permissions, and review what the invoked function accessed or returned.
 50- Constrain `lambda:InvokeFunction` to expected identities and, where possible, restrict invocation to known networks using IAM conditions.
 51
 52### Additional information
 53
 54- [Invoke API](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html)
 55- [Logging Lambda data events with CloudTrail](https://docs.aws.amazon.com/lambda/latest/dg/logging-using-cloudtrail.html)
 56"""
 57references = [
 58    "https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html",
 59    "https://docs.aws.amazon.com/lambda/latest/dg/logging-using-cloudtrail.html",
 60]
 61risk_score = 47
 62rule_id = "c8cc8192-f4f5-4ed3-8368-544ca738d506"
 63setup = """## Setup
 64
 65This rule requires AWS Lambda data events to be logged in CloudTrail and ingested via the AWS integration
 66(`aws.cloudtrail` data stream). Lambda invocation (`Invoke`) is a data-plane event and is NOT logged by default; enable
 67data event logging for Lambda functions in the trail (optionally scoped to sensitive functions to manage volume). Source
 68ASN enrichment (`source.as.organization.name`) must be available on the ingested events.
 69"""
 70severity = "medium"
 71tags = [
 72    "Domain: Cloud",
 73    "Data Source: AWS",
 74    "Data Source: Amazon Web Services",
 75    "Data Source: AWS Lambda",
 76    "Use Case: Threat Detection",
 77    "Tactic: Execution",
 78    "Resources: Investigation Guide",
 79]
 80timestamp_override = "event.ingested"
 81type = "new_terms"
 82
 83query = '''
 84data_stream.dataset: "aws.cloudtrail"
 85    and event.provider: "lambda.amazonaws.com"
 86    and event.action: Invoke*
 87    and event.outcome: "success"
 88    and not aws.cloudtrail.user_identity.invoked_by: *
 89    and source.as.organization.name:(* and not (Amazon* or AMAZON* or Google* or GOOGLE* or Microsoft* or MICROSOFT*))
 90'''
 91
 92
 93[[rule.threat]]
 94framework = "MITRE ATT&CK"
 95[[rule.threat.technique]]
 96id = "T1648"
 97name = "Serverless Execution"
 98reference = "https://attack.mitre.org/techniques/T1648/"
 99
100
101[rule.threat.tactic]
102id = "TA0002"
103name = "Execution"
104reference = "https://attack.mitre.org/tactics/TA0002/"
105
106[rule.investigation_fields]
107field_names = [
108    "@timestamp",
109    "user.name",
110    "user_agent.original",
111    "source.ip",
112    "source.as.organization.name",
113    "source.geo.country_name",
114    "aws.cloudtrail.user_identity.arn",
115    "aws.cloudtrail.user_identity.type",
116    "aws.cloudtrail.user_identity.access_key_id",
117    "aws.cloudtrail.user_identity.session_context.session_issuer.arn",
118    "aws.cloudtrail.request_parameters",
119    "event.action",
120    "cloud.account.id",
121]
122
123[rule.new_terms]
124field = "new_terms_fields"
125value = ["source.as.organization.name", "cloud.account.id", "user.name"]
126[[rule.new_terms.history_window_start]]
127field = "history_window_start"
128value = "now-10d"

Triage and analysis

Investigating AWS Lambda Function Invoked from an Unusual Source ASN

Lambda execution-role credentials and user credentials are frequently abused after theft (for example via SSRF or RCE against a function, or leaked access keys). When such credentials are replayed from attacker infrastructure, the resulting direct Invoke calls originate from a network the legitimate principal has not used. This rule uses a new terms approach over the source ASN organization and the principal, excluding common cloud provider networks, to surface invocation from unfamiliar external networks.

Possible investigation steps

  • Review source.ip, source.as.organization.name, and source.geo for the invoking network and determine whether it is expected for the principal in aws.cloudtrail.user_identity.arn.
  • Inspect aws.cloudtrail.request_parameters for the functionName and user_agent.original for the client used.
  • Determine whether the credential (aws.cloudtrail.user_identity.access_key_id) was recently seen used elsewhere or outside the Lambda runtime, which would corroborate credential theft.
  • Correlate with other activity by the same principal from the same network, including data-plane access, IAM, or STS calls.

False positive analysis

  • New legitimate networks (offices, VPNs, home IPs, new egress) will generate this alert. Confirm the principal and network are expected and exclude known operator networks or identities after validation.
  • If source ASN is legitimate and expected, add as an exclusion to reduce false-positives.

Response and remediation

  • If credential abuse is confirmed, rotate or revoke the affected credentials and execution-role permissions, and review what the invoked function accessed or returned.
  • Constrain lambda:InvokeFunction to expected identities and, where possible, restrict invocation to known networks using IAM conditions.

Additional information

References

Related rules

to-top