AWS Lambda Function Policy Updated to Allow Public Invocation

  1[metadata]
  2creation_date = "2024/04/30"
  3integration = ["aws"]
  4maturity = "production"
  5updated_date = "2025/12/11"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies when an AWS Lambda function policy is updated to allow public invocation. This rule detects use of the
 11AddPermission API where the Principal is set to "*", enabling any AWS account to invoke the function. Adversaries may
 12abuse this configuration to establish persistence, create a covert execution path, or operate a function as an
 13unauthenticated backdoor. Public invocation is rarely required outside very specific workloads and should be considered
 14high-risk when performed unexpectedly.
 15"""
 16event_category_override = "event.type"
 17false_positives = [
 18    """
 19    Some organizations may legitimately expose Lambda functions for cross-account or anonymous invocation (e.g., custom
 20    public APIs, integrations, or legacy architectures). Validate whether the function owner explicitly intended to make
 21    the function publicly invokable. Routine CI/CD deployments or IaC templates may also temporarily set permissive
 22    policies; confirm this is expected behavior before treating it as suspicious.
 23    """,
 24]
 25from = "now-6m"
 26index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 27language = "eql"
 28license = "Elastic License v2"
 29name = "AWS Lambda Function Policy Updated to Allow Public Invocation"
 30note = """## Triage and analysis
 31
 32> **Disclaimer**:
 33> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. 
 34> While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
 35
 36### Investigating AWS Lambda Function Policy Updated to Allow Public Invocation
 37
 38AWS Lambda policies control who can invoke a function. When the `Principal` is set to `*`, the function becomes publicly invokable by any AWS account. Adversaries may modify Lambda permissions to create a stealthy execution backdoor or to maintain persistence inside an AWS environment. This activity is uncommon in most production environments and should receive careful scrutiny when detected.
 39
 40### Possible investigation steps
 41
 42**Identify the actor**
 43- Identify the actor who made the change by reviewing `aws.cloudtrail.user_identity.arn` and access key ID. Determine whether this principal typically administers Lambda functions.
 44
 45**Review request details**
 46- Review request details in `aws.cloudtrail.request_parameters` to understand the exact permission added:
 47  - Confirm that the `Principal` is set to `"*"`.
 48  - Note the `Action` (`lambda:InvokeFunction`) and any `SourceArn` restrictions (sometimes present, often missing in malicious cases).
 49
 50**Analyze source context**
 51- Check the source of the request using `source.ip`, geo information, and user agent. Unexpected networks, automation tools, or CLI usage may indicate credential compromise.
 52
 53**Correlate timing and related events**
 54- Evaluate timing and sequence by correlating `@timestamp` with other events. Look for surrounding actions such as:
 55  - Creation or update of Lambda function code.
 56  - Publishing new Lambda layers.
 57  - Changes to roles attached to the function.
 58
 59**Assess function sensitivity and impact**
 60- Assess the function’s role and data sensitivity. Determine whether public invocation could:
 61  - Enable unmonitored code execution,
 62  - Trigger access to internal resources via the function’s IAM role,
 63  - Be chained with persistence or privilege escalation behavior.
 64
 65**Validate operational intent**
 66- Validate the operational context. Confirm with the function owner whether the permission change was intentional, part of a deployment, or unexpected.
 67
 68### False positive analysis
 69
 70- Public invocation may be intentional for certain workloads (e.g., webhook handlers, openly accessible compute functions). Compare the event with documentation, IaC templates, or the deployment pipeline.
 71- Some teams may regularly modify permissions during testing or refactoring; check whether this aligns with existing workflows.
 72- Evaluate whether the function already had permissive invocation policies and whether the update is part of expected configuration drift.
 73
 74### Response and remediation
 75
 76- Remove unauthorized public invocation permissions immediately by reverting the Lambda function policy to the approved baseline.
 77- Investigate for follow-on activity: execution of the function, updates to code, modifications to IAM roles, or API calls issued using the function's role.
 78- Rotate or disable credentials associated with the identity that issued the `AddPermission` call if compromise is suspected.
 79- Enable or refine monitoring for Lambda policy updates, layer additions, and code changes to detect future unauthorized modifications.
 80- Conduct a security review of the Lambda function and any downstream resources it can access to ensure no misuse has occurred.
 81- Work with the application team to enforce least-privilege invocation policies and deploy guardrails (e.g., SCPs, IAM Conditions, or automated compliance checks) preventing public invocation unless explicitly authorized.
 82
 83### Additional information
 84- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)** 
 85- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)** 
 86- **[AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/)**
 87"""
 88references = [
 89    "https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence",
 90    "https://stratus-red-team.cloud/attack-techniques/AWS/aws.persistence.lambda-backdoor-function/",
 91    "https://docs.aws.amazon.com/lambda/latest/api/API_AddPermission.html",
 92]
 93risk_score = 47
 94rule_id = "151d8f72-0747-11ef-a0c2-f661ea17fbcc"
 95severity = "medium"
 96tags = [
 97    "Domain: Cloud",
 98    "Data Source: AWS",
 99    "Data Source: Amazon Web Services",
100    "Data Source: AWS Lambda",
101    "Use Case: Threat Detection",
102    "Tactic: Persistence",
103    "Resources: Investigation Guide",
104]
105timestamp_override = "event.ingested"
106type = "eql"
107
108query = '''
109info where event.dataset == "aws.cloudtrail" 
110    and event.provider == "lambda.amazonaws.com" 
111    and event.outcome == "success" 
112    and event.action : "AddPermission*" 
113    and stringContains(aws.cloudtrail.request_parameters, "lambda:InvokeFunction") 
114    and stringContains(aws.cloudtrail.request_parameters, "principal=\\*")
115'''
116
117
118[[rule.threat]]
119framework = "MITRE ATT&CK"
120[[rule.threat.technique]]
121id = "T1546"
122name = "Event Triggered Execution"
123reference = "https://attack.mitre.org/techniques/T1546/"
124
125
126[rule.threat.tactic]
127id = "TA0003"
128name = "Persistence"
129reference = "https://attack.mitre.org/tactics/TA0003/"
130
131[rule.investigation_fields]
132field_names = [
133    "@timestamp",
134    "user.name",
135    "user_agent.original",
136    "source.ip",
137    "aws.cloudtrail.user_identity.arn",
138    "aws.cloudtrail.user_identity.type",
139    "aws.cloudtrail.user_identity.access_key_id",
140    "target.entity.id",
141    "event.action",
142    "event.outcome",
143    "cloud.account.id",
144    "cloud.region",
145    "aws.cloudtrail.request_parameters",
146    "aws.cloudtrail.response_elements",
147]