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 Microsoft Sentinel
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
KQL Detection Query
// Requires AWS CloudTrail management events ingested into Sentinel's AWSCloudTrail table (via the AWS S3/SQS connector), covering EC2 Traffic Mirroring, VPC Peering, Transit Gateway, and RAM API calls
// Signal 1: a Traffic Mirror Target is created whose backing resource (NLB or Gateway Load Balancer endpoint) resolves to an AWS account ID different from the account making the call
let AwsCrossAccountMirrorTargets =
AWSCloudTrail
| where TimeGenerated > ago(24h)
| where EventName in ("CreateTrafficMirrorTarget", "CreateTrafficMirrorSession")
| extend TargetArn = tostring(ResponseElements.trafficMirrorTarget.networkLoadBalancerArn)
| extend TargetAccountId = extract(@"arn:aws:elasticloadbalancing:[a-z0-9-]+:(\d{12}):", 1, TargetArn)
| where isnotempty(TargetAccountId)
| where TargetAccountId != RecipientAccountId
| project TimeGenerated, EventName, UserIdentityArn, SourceIpAddress, RecipientAccountId, TargetAccountId, TargetArn, AWSRegion;
// Signal 2: a cross-account network path (VPC peering, Transit Gateway attachment, or RAM resource share) was established in the preceding 48h, making the cross-account target reachable
let AwsCrossAccountConnectivity =
AWSCloudTrail
| where TimeGenerated > ago(48h)
| where EventName in ("AcceptVpcPeeringConnection", "CreateTransitGatewayVpcAttachment", "AcceptTransitGatewayVpcAttachment", "AssociateResourceShare")
| project ConnTime = TimeGenerated, ConnEventName = EventName, ConnAccountId = RecipientAccountId, ConnUserIdentityArn = UserIdentityArn;
// Correlate: cross-account mirror target created within 24h of new cross-account connectivity in the same account
AwsCrossAccountMirrorTargets
| join kind=inner (AwsCrossAccountConnectivity) on $left.RecipientAccountId == $right.ConnAccountId
| where ConnTime < TimeGenerated and ConnTime > TimeGenerated - 24h
| project TimeGenerated, EventName, UserIdentityArn, SourceIpAddress, RecipientAccountId, TargetAccountId, TargetArn, ConnTime, ConnEventName, ConnUserIdentityArn, AWSRegion
| sort by TimeGenerated descCorrelates AWS CloudTrail Traffic Mirror Target/Session creation events whose destination NLB/Gateway Load Balancer endpoint ARN resolves to a different AWS account ID than the calling account (extracted from the ARN's embedded account ID field) with a newly established cross-account network path — VPC peering acceptance, Transit Gateway attachment, or an AWS RAM resource share — created in the same account within the preceding 24-48 hours. The pairing of 'new cross-account network path' plus 'mirror target pointed across that path' in a short window is rare for sanctioned security-tooling onboarding (which is provisioned well in advance via IaC) and characteristic of an attacker assembling exfiltration infrastructure in a single session. Requires AWS CloudTrail management events ingested into the AWSCloudTrail table; account-ID extraction from the target ARN works for NLB targets, ENI-backed targets require an enrichment lookup against a network-interface-to-account inventory table.
Data Sources
Required Tables
False Positives & Tuning
- Approved centralized security-tooling landing-zone architectures where mirror sessions intentionally target a shared-services/security account's NLB or Gateway Load Balancer endpoint reached over a Transit Gateway provisioned by platform engineering as part of account vending
- Newly onboarded AWS accounts under AWS Organizations/Control Tower where Transit Gateway attachments and RAM shares to the security or network account are created as part of routine account-vending automation, coincidentally near an unrelated mirror session
- Managed detection and response (MDR) or NDR vendor onboarding where the customer establishes VPC peering or a Transit Gateway attachment to the vendor's collector VPC in a vendor-owned AWS 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 before cutover
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.