AWS EC2 Security Group Configuration Change

Identifies a change to an AWS Security Group Configuration. A security group is like a virtual firewall, and modifying configurations may allow unauthorized access. Threat actors may abuse this to establish persistence, exfiltrate data, or pivot in an AWS environment.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2021/05/05"
  3integration = ["aws"]
  4maturity = "production"
  5updated_date = "2025/01/10"
  6
  7[rule]
  8author = ["Elastic", "Austin Songer"]
  9description = """
 10Identifies a change to an AWS Security Group Configuration. A security group is like a virtual firewall, and modifying
 11configurations may allow unauthorized access. Threat actors may abuse this to establish persistence, exfiltrate data, or
 12pivot in an AWS environment.
 13"""
 14false_positives = [
 15    """
 16    A security group may be created by a system or network administrator. Verify whether the user identity, user agent,
 17    and/or hostname should be making changes in your environment. Security group creations by unfamiliar users or hosts
 18    should be investigated. If known behavior is causing false positives, it can be exempted from the rule.
 19    """,
 20]
 21from = "now-9m"
 22index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 23language = "kuery"
 24license = "Elastic License v2"
 25name = "AWS EC2 Security Group Configuration Change"
 26note = """## Triage and analysis
 27
 28> **Disclaimer**:
 29> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. 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.
 30
 31### Investigating AWS EC2 Security Group Configuration Change
 32
 33AWS EC2 Security Groups act as virtual firewalls, controlling inbound and outbound traffic to instances. Adversaries may exploit changes in these configurations to gain unauthorized access, maintain persistence, or exfiltrate data. The detection rule monitors successful modifications to security group settings, such as rule changes or new group creation, to identify potential security breaches and unauthorized access attempts.
 34
 35### Possible investigation steps
 36
 37- Review the CloudTrail logs for the specific event.dataset "aws.cloudtrail" to identify the exact changes made to the security group configuration.
 38- Examine the event.provider "ec2.amazonaws.com" and event.action fields to determine the type of action performed, such as "AuthorizeSecurityGroupEgress" or "ModifySecurityGroupRules", to understand the nature of the change.
 39- Check the event.outcome field to confirm the success of the action and correlate it with any suspicious activity or unauthorized access attempts.
 40- Investigate the IAM user or role associated with the change to verify if the action aligns with their typical behavior and permissions.
 41- Analyze the timing and context of the change to see if it coincides with any other unusual activities or alerts in the AWS environment.
 42- Assess the impact of the security group change on the overall security posture, including potential exposure of sensitive resources or data.
 43- If necessary, consult with the responsible team or individual to validate the legitimacy of the change and ensure it was authorized.
 44
 45### False positive analysis
 46
 47- Routine administrative changes to security groups by authorized personnel can trigger alerts. To manage this, maintain a list of known IP addresses and users who regularly perform these tasks and create exceptions for their activities.
 48- Automated scripts or tools used for infrastructure management may frequently modify security group settings. Identify these tools and exclude their actions from triggering alerts by using their specific identifiers or tags.
 49- Scheduled updates or deployments that involve security group modifications can result in false positives. Document these schedules and adjust the monitoring rules to account for these expected changes during specific time windows.
 50- Changes made by cloud service providers as part of their maintenance or updates might be flagged. Verify these changes through official communication from the provider and consider excluding them if they are part of standard operations.
 51
 52### Response and remediation
 53
 54- Immediately isolate the affected EC2 instances by removing them from the compromised security group to prevent further unauthorized access.
 55- Revert any unauthorized changes to the security group configurations by restoring them to their last known good state using AWS CloudTrail logs for reference.
 56- Conduct a thorough review of IAM roles and permissions associated with the affected security groups to ensure that only authorized personnel have the ability to modify security group settings.
 57- Implement additional monitoring and alerting for any future changes to security group configurations, focusing on the specific actions identified in the detection rule.
 58- Escalate the incident to the security operations team for further investigation and to determine if there are any broader implications or related threats within the AWS environment.
 59- Review and update the AWS security group policies to enforce stricter rules and minimize the attack surface, ensuring that only necessary ports and protocols are allowed.
 60- Conduct a post-incident analysis to identify the root cause and implement measures to prevent similar incidents, such as enhancing logging and monitoring capabilities or applying stricter access controls.
 61
 62### Investigating AWS EC2 Security Group Configuration Change
 63
 64This rule identifies any changes to an AWS Security Group, which functions as a virtual firewall controlling inbound and outbound traffic for resources like EC2 instances. Modifications to a security group configuration could expose critical assets to unauthorized access. Threat actors may exploit such changes to establish persistence, exfiltrate data, or pivot within an AWS environment.
 65
 66#### Possible Investigation Steps
 67
 681. **Identify the Modified Security Group**:
 69   - **Security Group ID**: Check the `aws.cloudtrail.flattened.request_parameters.groupId` field to identify the specific security group affected.
 70   - **Rule Changes**: Review `aws.cloudtrail.flattened.response_elements.securityGroupRuleSet` to determine the new rules or configurations, including any added or removed IP ranges, protocol changes, and port specifications.
 71
 722. **Review User Context**:
 73   - **User Identity**: Inspect the `aws.cloudtrail.user_identity.arn` field to determine which user or role made the modification. Verify if this is an authorized administrator or a potentially compromised account.
 74   - **Access Patterns**: Analyze whether this user regularly interacts with security group configurations or if this event is out of the ordinary for their account.
 75
 763. **Analyze the Configuration Change**:
 77   - **Egress vs. Ingress**: Determine if the change affected inbound (ingress) or outbound (egress) traffic by reviewing fields like `isEgress` in the `securityGroupRuleSet`. Unauthorized changes to outbound traffic can indicate data exfiltration attempts.
 78   - **IP Ranges and Ports**: Assess any added IP ranges, especially `0.0.0.0/0`, which exposes resources to the internet. Port changes should also be evaluated to ensure only necessary ports are open.
 79
 804. **Check User Agent and Source IP**:
 81   - **User Agent Analysis**: Examine the `user_agent.original` field to identify the tool or application used, such as `AWS Console` or `Terraform`, which may reveal if the action was automated or manual.
 82   - **Source IP and Geolocation**: Use `source.address` and `source.geo` fields to verify if the IP address and geolocation match expected locations for your organization. Unexpected IPs or regions may indicate unauthorized access.
 83
 845. **Evaluate for Persistence Indicators**:
 85   - **Repeated Changes**: Investigate if similar changes were recently made across multiple security groups, which may suggest an attempt to maintain or expand access.
 86   - **Permissions Review**: Confirm that the user’s IAM policies are configured to limit changes to security groups only as necessary.
 87
 886. **Correlate with Other CloudTrail Events**:
 89   - **Cross-Reference Other Security Events**: Look for related actions like `AuthorizeSecurityGroupIngress`, `CreateSecurityGroup`, or `RevokeSecurityGroupIngress` that may indicate additional or preparatory steps for unauthorized access.
 90   - **Monitor for IAM or Network Changes**: Check for IAM modifications, network interface changes, or other configuration updates in the same timeframe to detect broader malicious activities.
 91
 92### False Positive Analysis
 93
 94- **Routine Security Changes**: Security group modifications may be part of regular infrastructure maintenance. Verify if this action aligns with known, scheduled administrative activities.
 95- **Automated Configuration Management**: If you are using automated tools like `Terraform` or `CloudFormation`, confirm if the change matches expected configuration drift corrections or deployments.
 96
 97### Response and Remediation
 98
 99- **Revert Unauthorized Changes**: If unauthorized, revert the security group configuration to its previous state to secure the environment.
100- **Restrict Security Group Permissions**: Remove permissions to modify security groups from any compromised or unnecessary accounts to limit future access.
101- **Quarantine Affected Resources**: If necessary, isolate any affected instances or resources to prevent further unauthorized activity.
102- **Audit IAM and Security Group Policies**: Regularly review permissions related to security groups to ensure least privilege access and prevent excessive access.
103
104### Additional Information
105
106For more details on managing AWS Security Groups and best practices, refer to the [AWS EC2 Security Groups Documentation](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-security-groups.html) and AWS security best practices.
107"""
108references = ["https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-security-groups.html"]
109risk_score = 21
110rule_id = "29052c19-ff3e-42fd-8363-7be14d7c5469"
111severity = "low"
112tags = [
113    "Domain: Cloud",
114    "Data Source: AWS",
115    "Data Source: Amazon Web Services",
116    "Data Source: AWS EC2",
117    "Use Case: Network Security Monitoring",
118    "Resources: Investigation Guide",
119    "Tactic: Persistence",
120    "Tactic: Defense Evasion"
121]
122timestamp_override = "event.ingested"
123type = "query"
124
125query = '''
126event.dataset: "aws.cloudtrail"
127    and event.provider: "ec2.amazonaws.com"
128    and event.action:(
129            "AuthorizeSecurityGroupEgress" or
130            "CreateSecurityGroup" or
131            "ModifyInstanceAttribute" or
132            "ModifySecurityGroupRules" or
133            "RevokeSecurityGroupEgress" or
134            "RevokeSecurityGroupIngress")
135    and event.outcome: "success"
136'''
137
138[rule.investigation_fields]
139field_names = [
140   "@timestamp",
141   "user.name",
142   "aws.cloudtrail.user_identity.arn",
143   "aws.cloudtrail.user_identity.type",
144   "user_agent.original",
145   "aws.cloudtrail.flattened.request_parameters.instanceId",
146   "event.action",
147   "event.outcome",
148   "cloud.region",
149   "event.provider",
150   "aws.cloudtrail.request_parameters",
151   "aws.cloudtrail.response_elements"
152]
153
154
155[[rule.threat]]
156framework = "MITRE ATT&CK"
157
158[rule.threat.tactic]
159id = "TA0003"
160name = "Persistence"
161reference = "https://attack.mitre.org/tactics/TA0003/"
162[[rule.threat]]
163framework = "MITRE ATT&CK"
164[[rule.threat.technique]]
165id = "T1562"
166name = "Impair Defenses"
167reference = "https://attack.mitre.org/techniques/T1562/"
168[[rule.threat.technique.subtechnique]]
169id = "T1562.007"
170name = "Disable or Modify Cloud Firewall"
171reference = "https://attack.mitre.org/techniques/T1562/007/"
172
173
174
175[rule.threat.tactic]
176id = "TA0005"
177name = "Defense Evasion"
178reference = "https://attack.mitre.org/tactics/TA0005/"
...
toml

Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. 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.

AWS EC2 Security Groups act as virtual firewalls, controlling inbound and outbound traffic to instances. Adversaries may exploit changes in these configurations to gain unauthorized access, maintain persistence, or exfiltrate data. The detection rule monitors successful modifications to security group settings, such as rule changes or new group creation, to identify potential security breaches and unauthorized access attempts.

  • Review the CloudTrail logs for the specific event.dataset "aws.cloudtrail" to identify the exact changes made to the security group configuration.
  • Examine the event.provider "ec2.amazonaws.com" and event.action fields to determine the type of action performed, such as "AuthorizeSecurityGroupEgress" or "ModifySecurityGroupRules", to understand the nature of the change.
  • Check the event.outcome field to confirm the success of the action and correlate it with any suspicious activity or unauthorized access attempts.
  • Investigate the IAM user or role associated with the change to verify if the action aligns with their typical behavior and permissions.
  • Analyze the timing and context of the change to see if it coincides with any other unusual activities or alerts in the AWS environment.
  • Assess the impact of the security group change on the overall security posture, including potential exposure of sensitive resources or data.
  • If necessary, consult with the responsible team or individual to validate the legitimacy of the change and ensure it was authorized.
  • Routine administrative changes to security groups by authorized personnel can trigger alerts. To manage this, maintain a list of known IP addresses and users who regularly perform these tasks and create exceptions for their activities.
  • Automated scripts or tools used for infrastructure management may frequently modify security group settings. Identify these tools and exclude their actions from triggering alerts by using their specific identifiers or tags.
  • Scheduled updates or deployments that involve security group modifications can result in false positives. Document these schedules and adjust the monitoring rules to account for these expected changes during specific time windows.
  • Changes made by cloud service providers as part of their maintenance or updates might be flagged. Verify these changes through official communication from the provider and consider excluding them if they are part of standard operations.
  • Immediately isolate the affected EC2 instances by removing them from the compromised security group to prevent further unauthorized access.
  • Revert any unauthorized changes to the security group configurations by restoring them to their last known good state using AWS CloudTrail logs for reference.
  • Conduct a thorough review of IAM roles and permissions associated with the affected security groups to ensure that only authorized personnel have the ability to modify security group settings.
  • Implement additional monitoring and alerting for any future changes to security group configurations, focusing on the specific actions identified in the detection rule.
  • Escalate the incident to the security operations team for further investigation and to determine if there are any broader implications or related threats within the AWS environment.
  • Review and update the AWS security group policies to enforce stricter rules and minimize the attack surface, ensuring that only necessary ports and protocols are allowed.
  • Conduct a post-incident analysis to identify the root cause and implement measures to prevent similar incidents, such as enhancing logging and monitoring capabilities or applying stricter access controls.

This rule identifies any changes to an AWS Security Group, which functions as a virtual firewall controlling inbound and outbound traffic for resources like EC2 instances. Modifications to a security group configuration could expose critical assets to unauthorized access. Threat actors may exploit such changes to establish persistence, exfiltrate data, or pivot within an AWS environment.

  1. Identify the Modified Security Group:

    • Security Group ID: Check the aws.cloudtrail.flattened.request_parameters.groupId field to identify the specific security group affected.
    • Rule Changes: Review aws.cloudtrail.flattened.response_elements.securityGroupRuleSet to determine the new rules or configurations, including any added or removed IP ranges, protocol changes, and port specifications.
  2. Review User Context:

    • User Identity: Inspect the aws.cloudtrail.user_identity.arn field to determine which user or role made the modification. Verify if this is an authorized administrator or a potentially compromised account.
    • Access Patterns: Analyze whether this user regularly interacts with security group configurations or if this event is out of the ordinary for their account.
  3. Analyze the Configuration Change:

    • Egress vs. Ingress: Determine if the change affected inbound (ingress) or outbound (egress) traffic by reviewing fields like isEgress in the securityGroupRuleSet. Unauthorized changes to outbound traffic can indicate data exfiltration attempts.
    • IP Ranges and Ports: Assess any added IP ranges, especially 0.0.0.0/0, which exposes resources to the internet. Port changes should also be evaluated to ensure only necessary ports are open.
  4. Check User Agent and Source IP:

    • User Agent Analysis: Examine the user_agent.original field to identify the tool or application used, such as AWS Console or Terraform, which may reveal if the action was automated or manual.
    • Source IP and Geolocation: Use source.address and source.geo fields to verify if the IP address and geolocation match expected locations for your organization. Unexpected IPs or regions may indicate unauthorized access.
  5. Evaluate for Persistence Indicators:

    • Repeated Changes: Investigate if similar changes were recently made across multiple security groups, which may suggest an attempt to maintain or expand access.
    • Permissions Review: Confirm that the user’s IAM policies are configured to limit changes to security groups only as necessary.
  6. Correlate with Other CloudTrail Events:

    • Cross-Reference Other Security Events: Look for related actions like AuthorizeSecurityGroupIngress, CreateSecurityGroup, or RevokeSecurityGroupIngress that may indicate additional or preparatory steps for unauthorized access.
    • Monitor for IAM or Network Changes: Check for IAM modifications, network interface changes, or other configuration updates in the same timeframe to detect broader malicious activities.
  • Routine Security Changes: Security group modifications may be part of regular infrastructure maintenance. Verify if this action aligns with known, scheduled administrative activities.
  • Automated Configuration Management: If you are using automated tools like Terraform or CloudFormation, confirm if the change matches expected configuration drift corrections or deployments.
  • Revert Unauthorized Changes: If unauthorized, revert the security group configuration to its previous state to secure the environment.
  • Restrict Security Group Permissions: Remove permissions to modify security groups from any compromised or unnecessary accounts to limit future access.
  • Quarantine Affected Resources: If necessary, isolate any affected instances or resources to prevent further unauthorized activity.
  • Audit IAM and Security Group Policies: Regularly review permissions related to security groups to ensure least privilege access and prevent excessive access.

For more details on managing AWS Security Groups and best practices, refer to the AWS EC2 Security Groups Documentation and AWS security best practices.

References

Related rules

to-top