AWS Lambda Function Policy Updated to Allow Public Invocation
Identifies when an AWS Lambda function policy is updated to allow public invocation. This rule specifically looks for
the AddPermission
API call with the Principal
set to *
which allows any AWS account to invoke the Lambda function.
Adversaries may abuse this permission to create a backdoor in the Lambda function that allows them to execute arbitrary
code.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2024/04/30"
3integration = ["aws"]
4maturity = "production"
5updated_date = "2024/07/23"
6
7[rule]
8author = ["Elastic"]
9description = """
10Identifies when an AWS Lambda function policy is updated to allow public invocation. This rule specifically looks for
11the `AddPermission` API call with the `Principal` set to `*` which allows any AWS account to invoke the Lambda function.
12Adversaries may abuse this permission to create a backdoor in the Lambda function that allows them to execute arbitrary
13code.
14"""
15false_positives = ["Lambda function owners may legitimately update the function policy to allow public invocation."]
16from = "now-60m"
17index = ["filebeat-*", "logs-aws.cloudtrail-*"]
18interval = "10m"
19language = "kuery"
20license = "Elastic License v2"
21name = "AWS Lambda Function Policy Updated to Allow Public Invocation"
22note = """## Triage and Analysis
23
24### Investigating AWS Lambda Function Policy Updated to Allow Public Invocation
25
26This rule detects when an AWS Lambda function policy is updated to allow public invocation. It specifically looks for the `AddPermission` API call with the `Principal` set to `*`, which allows any AWS account to invoke the Lambda function. Adversaries may abuse this permission to create a backdoor in the Lambda function that allows them to execute arbitrary code. Understanding the context and legitimacy of such changes is crucial to determine if the action is benign or malicious.
27
28#### Possible Investigation Steps:
29
30- **Identify the Actor**: Review the `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` fields to identify who made the change. Verify if this actor typically performs such actions and if they have the necessary permissions.
31- **Review the Request Details**: Examine the `aws.cloudtrail.request_parameters` to understand the specific changes made to the Lambda function policy. Look for any unusual parameters that could suggest unauthorized or malicious modifications.
32- **Analyze the Source of the Request**: Investigate the `source.ip` and `source.geo` fields to determine the geographical origin of the request. An external or unexpected location might indicate compromised credentials or unauthorized access.
33- **Contextualize with Timestamp**: Use the `@timestamp` field to check when the change occurred. Modifications during non-business hours or outside regular maintenance windows might require further scrutiny.
34- **Correlate with Other Activities**: Search for related CloudTrail events before and after this change to see if the same actor or IP address engaged in other potentially suspicious activities.
35
36### False Positive Analysis:
37
38- **Legitimate Administrative Actions**: Confirm if the update to allow public invocation aligns with scheduled updates, development activities, or legitimate administrative tasks documented in change management systems.
39- **Consistency Check**: Compare the action against historical data of similar actions performed by the user or within the organization. If the action is consistent with past legitimate activities, it might indicate a false alarm.
40- **Verify through Outcomes**: Check the `aws.cloudtrail.response_elements` and the `event.outcome` to confirm if the change was successful and intended according to policy.
41
42### Response and Remediation:
43
44- **Immediate Review and Reversal if Necessary**: If the change was unauthorized, update the Lambda function policy to remove the public invocation permission and restore it to its previous state.
45- **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar actions, especially those involving sensitive functions or permissions.
46- **Educate and Train**: Provide additional training to users with administrative rights on the importance of security best practices concerning Lambda function management and the use of permissions.
47- **Audit Lambda Functions and Policies**: Conduct a comprehensive audit of all Lambda functions and associated policies to ensure they adhere to the principle of least privilege.
48- **Incident Response**: If there's an indication of malicious intent or a security breach, initiate the incident response protocol to mitigate any damage and prevent future occurrences.
49
50### Additional Information:
51
52For further guidance on managing Lambda functions and securing AWS environments, refer to the [AWS Lambda documentation](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) and AWS best practices for security. Additionally, consult the following resources for specific details on Lambda persistence techniques:
53- [AWS Lambda Persistence](https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence)
54- [AWS Lambda Backdoor Function](https://stratus-red-team.cloud/attack-techniques/AWS/aws.persistence.lambda-backdoor-function/)
55- [AWS API AddPermission](https://docs.aws.amazon.com/lambda/latest/api/API_AddPermission.html)
56
57
58"""
59references = [
60 "https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence",
61 "https://stratus-red-team.cloud/attack-techniques/AWS/aws.persistence.lambda-backdoor-function/",
62 "https://docs.aws.amazon.com/lambda/latest/api/API_AddPermission.html",
63]
64risk_score = 47
65rule_id = "151d8f72-0747-11ef-a0c2-f661ea17fbcc"
66severity = "medium"
67tags = [
68 "Domain: Cloud",
69 "Data Source: AWS",
70 "Data Source: Amazon Web Services",
71 "Data Source: AWS Lambda",
72 "Use Case: Threat Detection",
73 "Tactic: Persistence",
74]
75timestamp_override = "event.ingested"
76type = "query"
77
78query = '''
79event.dataset: aws.cloudtrail
80 and event.provider: lambda.amazonaws.com
81 and event.outcome: success
82 and event.action: AddPermission*
83 and aws.cloudtrail.request_parameters: (*lambda\:InvokeFunction* and *principal=\**)
84'''
85
86
87[[rule.threat]]
88framework = "MITRE ATT&CK"
89[[rule.threat.technique]]
90id = "T1546"
91name = "Event Triggered Execution"
92reference = "https://attack.mitre.org/techniques/T1546/"
93
94
95[rule.threat.tactic]
96id = "TA0003"
97name = "Persistence"
98reference = "https://attack.mitre.org/tactics/TA0003/"
Triage and Analysis
Investigating AWS Lambda Function Policy Updated to Allow Public Invocation
This rule detects when an AWS Lambda function policy is updated to allow public invocation. It specifically looks for the AddPermission
API call with the Principal
set to *
, which allows any AWS account to invoke the Lambda function. Adversaries may abuse this permission to create a backdoor in the Lambda function that allows them to execute arbitrary code. Understanding the context and legitimacy of such changes is crucial to determine if the action is benign or malicious.
Possible Investigation Steps:
- Identify the Actor: Review the
aws.cloudtrail.user_identity.arn
andaws.cloudtrail.user_identity.access_key_id
fields to identify who made the change. Verify if this actor typically performs such actions and if they have the necessary permissions. - Review the Request Details: Examine the
aws.cloudtrail.request_parameters
to understand the specific changes made to the Lambda function policy. Look for any unusual parameters that could suggest unauthorized or malicious modifications. - Analyze the Source of the Request: Investigate the
source.ip
andsource.geo
fields to determine the geographical origin of the request. An external or unexpected location might indicate compromised credentials or unauthorized access. - Contextualize with Timestamp: Use the
@timestamp
field to check when the change occurred. Modifications during non-business hours or outside regular maintenance windows might require further scrutiny. - Correlate with Other Activities: Search for related CloudTrail events before and after this change to see if the same actor or IP address engaged in other potentially suspicious activities.
False Positive Analysis:
- Legitimate Administrative Actions: Confirm if the update to allow public invocation aligns with scheduled updates, development activities, or legitimate administrative tasks documented in change management systems.
- Consistency Check: Compare the action against historical data of similar actions performed by the user or within the organization. If the action is consistent with past legitimate activities, it might indicate a false alarm.
- Verify through Outcomes: Check the
aws.cloudtrail.response_elements
and theevent.outcome
to confirm if the change was successful and intended according to policy.
Response and Remediation:
- Immediate Review and Reversal if Necessary: If the change was unauthorized, update the Lambda function policy to remove the public invocation permission and restore it to its previous state.
- Enhance Monitoring and Alerts: Adjust monitoring systems to alert on similar actions, especially those involving sensitive functions or permissions.
- Educate and Train: Provide additional training to users with administrative rights on the importance of security best practices concerning Lambda function management and the use of permissions.
- Audit Lambda Functions and Policies: Conduct a comprehensive audit of all Lambda functions and associated policies to ensure they adhere to the principle of least privilege.
- Incident Response: If there's an indication of malicious intent or a security breach, initiate the incident response protocol to mitigate any damage and prevent future occurrences.
Additional Information:
For further guidance on managing Lambda functions and securing AWS environments, refer to the AWS Lambda documentation and AWS best practices for security. Additionally, consult the following resources for specific details on Lambda persistence techniques:
References
Related rules
- AWS Lambda Layer Added to Existing Function
- AWS RDS DB Instance Made Public
- AWS RDS DB Instance or Cluster Password Modified
- AWS IAM Roles Anywhere Profile Creation
- AWS IAM Roles Anywhere Trust Anchor Created with External CA