Insecure AWS EC2 VPC Security Group Ingress Rule Added
Identifies when a specified inbound (ingress) rule is added or adjusted for a VPC security group in AWS EC2. This rule detects when a security group rule is added that allows traffic from any IP address or from a specific IP address to common remote access ports, such as 22 (SSH) or 3389 (RDP). Adversaries may add these rules to allow remote access to VPC instances from any location, increasing the attack surface and potentially exposing the instances to unauthorized access.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2024/04/16"
3integration = ["aws"]
4maturity = "production"
5updated_date = "2024/07/23"
6
7[rule]
8author = ["Elastic"]
9description = """
10Identifies when a specified inbound (ingress) rule is added or adjusted for a VPC security group in AWS EC2. This rule
11detects when a security group rule is added that allows traffic from any IP address or from a specific IP address to
12common remote access ports, such as 22 (SSH) or 3389 (RDP). Adversaries may add these rules to allow remote access to
13VPC instances from any location, increasing the attack surface and potentially exposing the instances to unauthorized
14access.
15"""
16false_positives = [
17 """
18 Administrators may legitimately add security group rules to allow traffic from any IP address or from specific IP
19 addresses to common remote access ports.
20 """,
21]
22from = "now-60m"
23index = ["filebeat-*", "logs-aws.cloudtrail-*"]
24interval = "10m"
25language = "kuery"
26license = "Elastic License v2"
27name = "Insecure AWS EC2 VPC Security Group Ingress Rule Added"
28note = """## Triage and Analysis
29
30### Investigating Insecure AWS EC2 VPC Security Group Ingress Rule Added
31
32This rule detects the addition of ingress rules to a VPC security group that allow traffic from any IP address (`0.0.0.0/0` or `::/0`) to sensitive ports commonly used for remote access, such as SSH (port 22) and RDP (port 3389). This configuration change can significantly increase the exposure of EC2 instances to potential threats, making it crucial to understand the context and legitimacy of such changes.
33
34#### Possible Investigation Steps:
35
36- **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. Investigate whether this actor has the necessary permissions and typically performs these actions.
37- **Review the Request Details**: Examine the `aws.cloudtrail.request_parameters` to understand exactly what changes were made to the security group. Check for any unusual parameters that could suggest a misconfiguration or malicious intent.
38- **Analyze the Source of the Request**: Look at the `source.ip` and `source.geo` fields to determine the geographical origin of the request. An external or unusual location could indicate compromised credentials.
39- **Contextualize with Timestamp**: Use the `@timestamp` field to check when the change occurred. Modifications outside of typical business hours might warrant additional scrutiny.
40- **Correlate with Other Activities**: Search for related CloudTrail events before and after this change to see if the same actor engaged in other potentially suspicious activities.
41
42### False Positive Analysis:
43
44- **Legitimate Administrative Actions**: Verify if the ingress rule change aligns with scheduled updates, maintenance activities, or legitimate administrative tasks documented in change management tickets or systems.
45- **Consistency Check**: Compare the action against historical data of similar actions performed by the user or within the organization. Consistency with past legitimate actions might indicate a false alarm.
46- **Verify through Outcomes**: Check the `aws.cloudtrail.response_elements` and the `event.outcome` to confirm if the change was successful and intended as per policy.
47
48### Response and Remediation:
49
50- **Immediate Review and Reversal if Necessary**: If the change was unauthorized, revert the security group rules to their previous state to close any unintended access.
51- **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar security group changes, especially those that open access to well-known ports from any IP address.
52- **Educate and Train**: Provide additional training to users with administrative rights on the importance of security best practices concerning security group management.
53- **Audit Security Groups and Policies**: Conduct a comprehensive audit of all security groups and associated policies to ensure they adhere to the principle of least privilege.
54- **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.
55
56### Additional Information:
57
58For further guidance on managing security group rules and securing AWS environments, refer to the [Amazon VPC Security Groups documentation](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) and AWS best practices for security.
59
60"""
61references = [
62 "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_AuthorizeSecurityGroupEgress.html",
63 "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_AuthorizeSecurityGroupIngress.html",
64 "https://www.linkedin.com/pulse/my-backdoors-your-aws-infrastructure-part-3-network-micha%C5%82-brygidyn/",
65]
66risk_score = 47
67rule_id = "25e7fee6-fc25-11ee-ba0f-f661ea17fbce"
68severity = "medium"
69tags = [
70 "Domain: Cloud",
71 "Data Source: AWS",
72 "Data Source: Amazon Web Services",
73 "Data Source: AWS EC2",
74 "Use Case: Threat Detection",
75 "Tactic: Defense Evasion",
76]
77timestamp_override = "event.ingested"
78type = "query"
79
80query = '''
81event.dataset: "aws.cloudtrail"
82 and event.provider: ec2.amazonaws.com
83 and event.action: AuthorizeSecurityGroupIngress
84 and event.outcome: success
85 and aws.cloudtrail.flattened.request_parameters.cidrIp: ("0.0.0.0/0" or "::/0")
86 and aws.cloudtrail.flattened.request_parameters.fromPort: (
87 21 or 22 or 23 or 445 or 3389 or 5985 or 5986)
88'''
89
90
91[[rule.threat]]
92framework = "MITRE ATT&CK"
93[[rule.threat.technique]]
94id = "T1562"
95name = "Impair Defenses"
96reference = "https://attack.mitre.org/techniques/T1562/"
97[[rule.threat.technique.subtechnique]]
98id = "T1562.007"
99name = "Disable or Modify Cloud Firewall"
100reference = "https://attack.mitre.org/techniques/T1562/007/"
101
102
103
104[rule.threat.tactic]
105id = "TA0005"
106name = "Defense Evasion"
107reference = "https://attack.mitre.org/tactics/TA0005/"
Triage and Analysis
Investigating Insecure AWS EC2 VPC Security Group Ingress Rule Added
This rule detects the addition of ingress rules to a VPC security group that allow traffic from any IP address (0.0.0.0/0
or ::/0
) to sensitive ports commonly used for remote access, such as SSH (port 22) and RDP (port 3389). This configuration change can significantly increase the exposure of EC2 instances to potential threats, making it crucial to understand the context and legitimacy of such changes.
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. Investigate whether this actor has the necessary permissions and typically performs these actions. - Review the Request Details: Examine the
aws.cloudtrail.request_parameters
to understand exactly what changes were made to the security group. Check for any unusual parameters that could suggest a misconfiguration or malicious intent. - Analyze the Source of the Request: Look at the
source.ip
andsource.geo
fields to determine the geographical origin of the request. An external or unusual location could indicate compromised credentials. - Contextualize with Timestamp: Use the
@timestamp
field to check when the change occurred. Modifications outside of typical business hours might warrant additional scrutiny. - Correlate with Other Activities: Search for related CloudTrail events before and after this change to see if the same actor engaged in other potentially suspicious activities.
False Positive Analysis:
- Legitimate Administrative Actions: Verify if the ingress rule change aligns with scheduled updates, maintenance activities, or legitimate administrative tasks documented in change management tickets or systems.
- Consistency Check: Compare the action against historical data of similar actions performed by the user or within the organization. Consistency with past legitimate actions 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 as per policy.
Response and Remediation:
- Immediate Review and Reversal if Necessary: If the change was unauthorized, revert the security group rules to their previous state to close any unintended access.
- Enhance Monitoring and Alerts: Adjust monitoring systems to alert on similar security group changes, especially those that open access to well-known ports from any IP address.
- Educate and Train: Provide additional training to users with administrative rights on the importance of security best practices concerning security group management.
- Audit Security Groups and Policies: Conduct a comprehensive audit of all security groups 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 security group rules and securing AWS environments, refer to the Amazon VPC Security Groups documentation and AWS best practices for security.
References
Related rules
- AWS RDS DB Instance Made Public
- AWS RDS DB Instance or Cluster Password Modified
- EC2 AMI Shared with Another Account
- AWS Lambda Function Policy Updated to Allow Public Invocation
- AWS Lambda Layer Added to Existing Function