Response playbooks, investigation guides, and Atomic Red Team tests are Pro-only. Upgrade to unlock the full detection package for THREAT-CloudTrafficMirroring-Exfil.
Upgrade to ProDetect Cross-Account/Cross-Tenant Cloud Traffic Mirror Target Redirection for Passive Exfiltration in Splunk
The base T1020.001 technique detection alerts on any creation, modification, or deletion of an AWS Traffic Mirroring, Azure Virtual Network TAP, or GCP Packet Mirroring resource — a necessarily broad signal that fires just as often on legitimate NDR/IDS sensor deployments as it does on adversary activity, since the API calls themselves are identical in both cases. THREAT-NetworkTap-RogueSPANExfil.json separately covers the on-premises SPAN/RSPAN/ERSPAN control-plane equivalent for physical network devices. This scenario targets a materially different and higher-fidelity signal that neither file covers: the account, subscription, or project boundary that the mirrored traffic crosses to reach its collector. All three cloud providers support pointing a traffic mirror/vTAP/packet-mirroring destination at a collector that lives in a different AWS account, Azure subscription, or GCP project than the one being mirrored — a legitimate pattern for centralized security-tooling accounts reached over Transit Gateway, VPC peering, or Shared VPC, but also the exact mechanism an adversary with compromised cloud credentials would use to redirect duplicated production traffic to infrastructure they own outside the victim's security boundary, where it is invisible to the victim's own logging, IAM, and network controls once the copy leaves the account. A cross-account/cross-project mirror target is not inherently malicious (it is how MDR and NDR vendors are legitimately onboarded), so this scenario correlates it with the second-order signal that made it possible: a newly established cross-account network path (VPC peering acceptance, Transit Gateway attachment, AWS RAM resource share, or a first-seen destination subscription/project for a given source) created shortly before the mirror session — a pairing that is rare for sanctioned architectures (provisioned once, well in advance, via IaC) but characteristic of an attacker standing up exfiltration infrastructure end-to-end in a single compromised session.
MITRE ATT&CK
- Tactic
- Exfiltration
SPL Detection Query
index=aws_cloudtrail sourcetype="aws:cloudtrail" eventName IN ("CreateTrafficMirrorTarget", "CreateTrafficMirrorSession")
| rex field=responseElements.trafficMirrorTarget.networkLoadBalancerArn "arn:aws:elasticloadbalancing:[a-z0-9-]+:(?<TargetAccountId>\d{12}):"
| where isnotnull(TargetAccountId) AND TargetAccountId!=recipientAccountId
| join type=inner recipientAccountId
[ search index=aws_cloudtrail sourcetype="aws:cloudtrail" eventName IN ("AcceptVpcPeeringConnection", "CreateTransitGatewayVpcAttachment", "AcceptTransitGatewayVpcAttachment", "AssociateResourceShare")
| eval ConnTime=_time, ConnEventName=eventName
| fields recipientAccountId, ConnTime, ConnEventName ]
| where ConnTime < _time AND ConnTime > _time - 86400
| table _time, eventName, userIdentity.arn, sourceIPAddress, recipientAccountId, TargetAccountId, ConnTime, ConnEventName, awsRegion
| sort - _timeSPL equivalent of the cross-account correlation: extracts the target account ID from the traffic mirror target's NLB ARN, filters for a mismatch against the calling account (recipientAccountId), then joins against a subsearch for VPC peering/Transit Gateway/RAM events in the same account within the preceding 24 hours. Field/index names assume the standard AWS CloudTrail Splunk Add-on ingestion; adjust to your actual sourcetype and index configuration.
Data Sources
Required Sourcetypes
False Positives & Tuning
- Approved centralized security-tooling landing-zone architectures where mirror sessions intentionally target a shared-services account's NLB reached over Transit Gateway provisioned as part of account vending
- Newly onboarded AWS accounts where Transit Gateway attachments and RAM shares to the security account are created as part of routine account-vending automation
- Managed detection and response (MDR) or NDR vendor onboarding establishing VPC peering to a vendor-owned collector account under a signed data processing agreement
- Disaster recovery failover testing that temporarily peers a DR account's VPC to replicate mirrored traffic for validation
Other platforms for THREAT-CloudTrafficMirroring-Exfil
Testing Methodology
Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1AWS Cross-Account Traffic Mirror Target via Peered VPC
Expected signal: AWS CloudTrail logs AcceptVpcPeeringConnection followed by CreateTrafficMirrorTarget and CreateTrafficMirrorSession events from the same userIdentity.arn within minutes, each with recipientAccountId set to the victim account and, for the mirror target event, a responseElements.trafficMirrorTarget.networkLoadBalancerArn containing the attacker account ID (999999999999).
- Test 2Azure vTAP Destination NIC in a Different Subscription
Expected signal: Azure Activity Log records Microsoft.Network/virtualNetworkTaps/write with the destination field referencing a resource ID whose subscription GUID (ATTACKER_SUBSCRIPTION_ID) differs from the calling subscription, followed by Microsoft.Network/networkInterfaces/tapConfigurations/write for the source NIC attachment.
- Test 3GCP Packet Mirroring Collector in a Different Project via Shared VPC
Expected signal: GCP Cloud Audit Log records a compute.packetMirrorings.insert method call in the victim-service-project's Admin Activity log, with the request body's collectorIlb self-link referencing attacker-project — a different project ID than either the calling project or the mirrored subnetwork's host project (victim-host-project).
- Test 4AWS RAM Resource Share Immediately Followed by Cross-Account Mirror Session
Expected signal: AWS CloudTrail logs AssociateResourceShare (principal 999999999999) followed within minutes by CreateTrafficMirrorSession, both attributed to the same userIdentity.arn and recipientAccountId (123456789012).
References (8)
- https://attack.mitre.org/techniques/T1020/001/
- https://docs.aws.amazon.com/vpc/latest/mirroring/traffic-mirroring-considerations.html
- https://docs.aws.amazon.com/vpc/latest/mirroring/traffic-mirroring-target.html
- https://docs.aws.amazon.com/ram/latest/userguide/what-is.html
- https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html
- https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-tap-overview
- https://cloud.google.com/vpc/docs/packet-mirroring
- https://cloud.google.com/vpc/docs/shared-vpc
Unlock playbooks & atomic tests with Pro
Get the full detection package for THREAT-CloudTrafficMirroring-Exfil — response playbook and atomic red team tests, plus investigation guidance and hunting queries.
df00tech Pro — £29/user/month
Related Detections
Tactic Hub
Detection Variants (1)
Different telemetry and tradecraft for the same technique — pick the one that matches the data you collect.