You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[Rule Tuning] AWS EC2 Full Network Packet Capture Detected (#5244)
* [Rule Tuning] AWS EC2 Full Network Packet Capture Detected
**AWS EC2 Full Network Packet Capture Detected**
Alert telemetry is low in general however the alerts that do exist are unnecessarily duplicative in nature. When a traffic mirror session is created (CreateTrafficMirrorSession), it is typcially created alongside A filter and filter rules (CreateTrafficMirrorFilter, CreateTrafficMirrorFilterRule) which determines what traffic will be mirrored. There is also a traffic mirror target (CreateTrafficMirrorTarget), which is the destination for the mirrored traffic to go. The original scope of this rule included all of those APIs when really the only API needed here is `CreateTrafficMirrorSession`, which is the actual network mirroring behavior. The rest of those calls can be used as additional context during alert triage, but I've significantly reduced the scope of this rule to only capture the actual traffic mirroring behavior.
- reduced the query scope to `CreateTrafficMirrorSession` only
- reduced the execution window
- update description and investigation guide
- replaced API reference link
- added highlighted fields
* updating mitre technique
updating mitre technique
* updated Mitre mapping
adding network sniffing technique
* updating references to include relevant threat blog
updating references to include relevant threat blog
* adding EC2 tag
adding EC2 tag
* updating EC2 tagging
Identifies potential Traffic Mirroring in an Amazon Elastic Compute Cloud (EC2) instance. Traffic Mirroring is an Amazon
11
-
VPC feature that you can use to copy network traffic from an Elastic network interface. This feature can potentially be
12
-
abused to exfiltrate sensitive data from unencrypted internal traffic.
10
+
Detects successful creation of an Amazon EC2 Traffic Mirroring session. A session copies full packets from a source
11
+
Elastic Network Interface (ENI) to a mirror target (e.g., an ENI or NLB) using a mirror filter (ingress/egress rules).
12
+
While used for diagnostics and NDR/IDS tooling, adversaries can abuse sessions to covertly capture and exfiltrate
13
+
sensitive, potentially unencrypted, traffic from instances or subnets.
13
14
"""
14
15
false_positives = [
15
16
"""
@@ -18,9 +19,8 @@ false_positives = [
18
19
should be investigated. If known behavior is causing false positives, it can be exempted from the rule.
19
20
""",
20
21
]
21
-
from = "now-60m"
22
+
from = "now-6m"
22
23
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
23
-
interval = "10m"
24
24
language = "kuery"
25
25
license = "Elastic License v2"
26
26
name = "AWS EC2 Full Network Packet Capture Detected"
@@ -31,41 +31,73 @@ note = """## Triage and analysis
31
31
32
32
### Investigating AWS EC2 Full Network Packet Capture Detected
33
33
34
-
Traffic Mirroring in AWS EC2 allows copying of network traffic for monitoring and analysis, crucial for security and performance insights. However, adversaries can exploit this by capturing unencrypted data, leading to potential data exfiltration. The detection rule identifies successful creation of traffic mirroring components, signaling possible misuse for unauthorized data collection.
35
-
36
-
### Possible investigation steps
37
-
38
-
- Review the CloudTrail logs for the specific event actions: CreateTrafficMirrorFilter, CreateTrafficMirrorFilterRule, CreateTrafficMirrorSession, and CreateTrafficMirrorTarget to identify the user or role that initiated these actions.
39
-
- Check the event.outcome field to confirm the success of the traffic mirroring setup and gather details about the time and source IP address of the request.
40
-
- Investigate the associated Elastic Network Interface (ENI) to determine which EC2 instance is involved and assess its role and importance within the network.
41
-
- Analyze the network traffic patterns and data flow from the mirrored traffic to identify any signs of data exfiltration or unusual data transfer activities.
42
-
- Verify the encryption status of the network traffic being mirrored to assess the risk of sensitive data exposure.
43
-
- Cross-reference the involved AWS account and IAM roles with known threat actor profiles or previous security incidents to identify potential insider threats or compromised accounts.
34
+
This alert fires on a successful `CreateTrafficMirrorSession`, which enables full-packet Traffic Mirroring from a
35
+
source ENI to a mirror target under a given filter. Because sessions immediately begin sending packets once active,
36
+
treat unexpected creations as high priority.
37
+
38
+
#### Possible investigation steps
39
+
40
+
**Identify the actor and execution context**
41
+
- **Principal**: Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and
42
+
`aws.cloudtrail.user_identity.access_key_id` to determine who created the session (human IAM user vs. assumed role vs. automation).
43
+
- **Caller metadata**: Check `user_agent.original`, and `source.ip` for unusual tools, hosts, or locations.
44
+
- **Account/Region/Time**: Validate `cloud.account.id`, `cloud.region`, and `@timestamp` against change windows or tickets.
- Routine network monitoring activities may trigger the rule if legitimate traffic mirroring is set up for performance analysis. To manage this, identify and document authorized traffic mirroring configurations and exclude them from alerts.
48
-
- Security audits or compliance checks might involve creating traffic mirroring sessions. Coordinate with audit teams to schedule these activities and temporarily suppress alerts during these periods.
49
-
- Development and testing environments often use traffic mirroring for debugging purposes. Maintain a list of such environments and apply exceptions to avoid unnecessary alerts.
50
-
- Automated infrastructure management tools might create traffic mirroring components as part of their operations. Review and whitelist these tools to prevent false positives.
51
-
- Ensure that any third-party services with access to your AWS environment are vetted and their activities are monitored to distinguish between legitimate and suspicious traffic mirroring actions.
71
+
- **Authorized monitoring**: Approved NDR/IDS tooling or troubleshooting playbooks may legitimately create sessions.
72
+
- **Ops/diagnostics**: Short-lived sessions during incident handling or performance analysis.
73
+
- **Automation**: Infrastructure pipelines that stand up temporary mirroring for validation.
52
74
53
75
### Response and remediation
54
76
55
-
- Immediately isolate the affected EC2 instance to prevent further data exfiltration. This can be done by removing the instance from any network access or security groups that allow outbound traffic.
56
-
- Review and terminate any unauthorized Traffic Mirroring sessions, filters, or targets that were created. Ensure that only legitimate and necessary mirroring configurations are active.
57
-
- Conduct a thorough audit of the AWS CloudTrail logs to identify any other suspicious activities or unauthorized access attempts related to Traffic Mirroring or other sensitive operations.
58
-
- Rotate and update any credentials or access keys that may have been exposed or compromised during the incident to prevent further unauthorized access.
59
-
- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. Escalate to higher management if the data exfiltration involves sensitive or critical data.
60
-
- Implement additional network monitoring and intrusion detection measures to enhance visibility and detect similar threats in the future. Consider using AWS GuardDuty or similar services for continuous threat detection.
61
-
- Review and update security policies and access controls to ensure that Traffic Mirroring and other sensitive features are only accessible to authorized personnel with a legitimate need.
77
+
**1. Contain**
78
+
- If unauthorized, terminate the session immediately (use the `TrafficMirrorSessionId` from `aws.cloudtrail.response_elements`)
79
+
and block creation permissions for the offending principal.
80
+
- Quarantine or restrict egress from the target if you suspect it is forwarding captured traffic outside approved destinations.
81
+
82
+
**2. Investigate**
83
+
- Enumerate all active sessions in the affected account/region; verify there aren’t additional rogue sessions.
84
+
- Review related target and filter resources (and recent `Modify*` calls) to understand captured scope and recipients.
85
+
- Trace the source ENI back to the EC2 instance and validate whether sensitive workloads were mirrored.
86
+
87
+
**3. Recover & harden**
88
+
- Remove or lock down unapproved targets/filters; enforce least privilege on `ec2:CreateTrafficMirrorSession/Target/Filter`.
89
+
- Consider SCPs or IAM conditions limiting who/where sessions can be created (e.g., only into designated monitoring VPCs).
90
+
- Ensure monitoring targets are controlled, logged, and not internet-reachable.
62
91
63
-
## Setup
92
+
**4. Improve**
93
+
- Add correlation logic to automatically surface CreateTrafficMirrorSession alongside Create/Modify Target/Filter calls by the same actor.
94
+
- Require tags on approved mirroring resources; alert on untagged/unticketed creations.
95
+
- Update playbooks to include a standard validation checklist (principal, source ENI, target, filter rules, destination path).
64
96
65
-
The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
0 commit comments