Live Active security incident? Get immediate response
MITRE ATT&CK® Analytic

AN0878: Analytic 0878

Detects creation of traffic mirroring sessions (e.g., AWS VPC Traffic Mirroring, Azure vTAP) that redirect traffic from critical assets to other virtual instances, often followed by file creation or session establishment.

EnterpriseAN0878AnalyticObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

This analytic matters because cloud traffic mirroring can turn infrastructure into a surveillance point. In IaaS environments, a newly created mirroring session that redirects traffic from critical assets to another virtual instance may indicate unauthorized monitoring, data exposure risk, or preparation for follow-on activity. For leaders, the practical question is whether cloud teams can quickly prove who created mirroring, which assets were targeted, where traffic was sent, and whether the action was authorized.

Executive priority

Prioritize this as a cloud security and incident readiness control area for critical workloads. Traffic mirroring is legitimate for troubleshooting and monitoring, so the business risk is not the feature itself but unmanaged use: sensitive traffic could be copied outside expected inspection paths, complicating compliance evidence, data protection assurances, and incident scoping. Executives should ask whether creation of mirroring sessions on critical assets requires approval, is logged centrally, and can be reviewed quickly during an investigation.

Technical view

The supplied ATT&CK analytic is for IaaS platforms and detects creation of traffic mirroring sessions such as AWS VPC Traffic Mirroring or Azure vTAP that redirect traffic from critical assets to other virtual instances, with possible follow-on file creation or session establishment. SOC and cloud detection teams should validate that control-plane events for mirroring session creation are collected, correlated to the source asset and destination instance, and enriched with identity, account/subscription/project, region, and asset criticality. Because no official detection logic is provided, local implementation should focus on detecting new or modified mirroring configurations involving high-value assets or unusual destinations.

Likely telemetry

  • Cloud control-plane audit logs for traffic mirroring or virtual tap creation and modification
  • Cloud identity and access management audit events showing the principal that created or changed the mirroring session
  • Cloud asset inventory identifying critical source assets and destination virtual instances
  • Network or flow metadata showing traffic redirected from protected workloads to another instance
  • Endpoint or workload telemetry for follow-on file creation or session establishment where available

Detection direction

  • Alert on creation or modification of traffic mirroring sessions involving critical assets, especially when the destination instance is new, uncommon, outside approved monitoring infrastructure, or owned by an unexpected identity or account boundary.
  • Tune against approved network monitoring, packet capture, troubleshooting, and security tooling workflows to reduce false positives.
  • Validate that detections include enough context for triage: creator identity, time, source interface or workload, destination target, region, account/subscription, and change history.
  • Review for blind spots where cloud audit logs are not centralized, asset criticality is missing, or mirroring events are retained for too short a period.
  • If follow-on file creation or session establishment telemetry is available, correlate it after mirroring creation to help prioritize investigation, while avoiding assumptions that every mirroring event is malicious.

Mitigation priorities

  • Define and document approved use cases for IaaS traffic mirroring, including authorized teams, destinations, and change processes.
  • Restrict permissions to create or modify traffic mirroring sessions to a small set of approved roles using least privilege.
  • Maintain an inventory of approved mirroring destinations and critical assets so detections can distinguish expected monitoring from risky changes.
  • Centralize cloud audit logs and retain them long enough to support incident response and compliance review.
  • Periodically review mirroring configurations for orphaned, unauthorized, or undocumented sessions.
Analyst notes and limits

No ATT&CK tactics, relationships, or official detection logic were supplied for this analytic. The most defensible implementation is therefore a cloud control-plane detection and governance review around creation or modification of traffic mirroring sessions in IaaS environments, with prioritization based on asset criticality and whether the destination is approved.

This take is limited to the supplied ATT&CK fields for AN0878. It does not establish attacker attribution, active exploitation, impact, or guaranteed detection coverage. Exact event names, APIs, permissions, and telemetry availability must be validated in the organization’s specific cloud environments.

Official MITRE ATT&CK definition

Analytic 0878

Detects creation of traffic mirroring sessions (e.g., AWS VPC Traffic Mirroring, Azure vTAP) that redirect traffic from critical assets to other virtual instances, often followed by file creation or session establishment.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

How security teams should use this page

Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.

Relationship explorer

All related ATT&CK context

No relationships are available in the current normalized data for this object.

Change history

Object version and sync metadata

The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
f309cb8b22025978...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle f309cb8b2202…
Raw source

Mirrored ATT&CK source object

The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack AN0878
    Open source URL
Source and licensing

Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.