AN0302: Analytic 0302
Atypical processes (e.g., powershell.exe, regsvr32.exe) encode large outbound traffic using Base64 or other character encodings; this traffic is sent over uncommon ports or embedded in protocol fields (e.g., HTTP cookies or headers).
Analyst context for executives and security teams
This analytic highlights a Windows-focused behavior where unusual processes such as PowerShell or regsvr32 generate large outbound data streams that appear encoded, including Base64-like content, and send it through uncommon ports or hidden inside protocol fields such as HTTP headers or cookies. For leaders, the value is not the tool name; it is whether the organization can recognize suspicious outbound data movement from processes that should not normally be producing high-volume encoded network traffic.
Executive priority
Prioritize this as a validation point for SOC visibility and incident response readiness around potential data movement and command-and-control-like traffic patterns. Executives should ask whether endpoint and network telemetry can be joined well enough to answer: which Windows process sent the traffic, how much data left, what destination and port were used, and whether encoded content appeared in protocol fields. This also supports audit and compliance evidence for monitoring outbound traffic and investigating abnormal data flows.
Technical view
For Windows environments, validate whether detections can correlate process identity with outbound network traffic characteristics. Focus on atypical processes named in the analytic, including powershell.exe and regsvr32.exe, but avoid limiting coverage only to those examples. Detection engineering should test for large outbound payloads with Base64 or similar character-encoding patterns, especially when transmitted over uncommon ports or embedded in HTTP cookies, headers, or comparable protocol fields. Because the ATT&CK object provides no official detection logic and no tactic mapping, teams should treat this as a behavior pattern requiring local baselining rather than a ready-to-deploy rule.
Likely telemetry
- Windows process creation events with command line, parent process, user, and host context
- Endpoint network connection telemetry linking process to destination IP, domain, port, and byte counts
- Proxy, web gateway, firewall, or network flow logs showing outbound volume and uncommon destination ports
- HTTP request metadata, especially headers and cookies where available and legally permitted
- DNS and destination reputation/context logs to support triage
Detection direction
- Baseline which Windows processes normally generate outbound traffic and expected data volumes, then alert on atypical processes producing large encoded-looking outbound content.
- Correlate endpoint process telemetry with network flow or proxy records; network-only alerts may miss the originating process, while endpoint-only telemetry may miss payload or protocol-field indicators.
- Tune for Base64-like or other high-entropy/character-encoded strings in HTTP headers, cookies, or unusual protocol fields, while accounting for legitimate applications that encode tokens, telemetry, or session data.
- Prioritize uncommon ports and unusual destinations, but do not assume standard ports are safe because encoded traffic may still traverse common web protocols.
- Use process ancestry, user context, destination history, and byte volume to reduce false positives from administrative scripts, software updaters, and enterprise management tooling.
Mitigation priorities
- Establish outbound traffic baselines for Windows hosts and high-risk administrative utilities.
- Restrict or monitor script interpreters and living-off-the-land binaries according to business need, with special attention to processes that do not normally initiate external connections.
- Ensure egress controls, proxy logging, and firewall policy can identify uncommon ports and unexpected destinations.
- Improve endpoint-to-network correlation so incident responders can quickly identify the responsible process, user, host, destination, and data volume.
- Review logging retention and privacy/legal constraints for HTTP header and cookie inspection before relying on that evidence source.
Analyst notes and limits
This object is a detection analytic, not a technique description. The supplied ATT&CK fields specify Windows as the platform and describe encoded large outbound traffic from atypical processes over uncommon ports or within protocol fields. No tactic, relationship context, aliases, labels, or official detection logic were supplied, so the take emphasizes defensible validation questions and telemetry requirements rather than asserting a specific ATT&CK technique, adversary use, or guaranteed detection method.
Coverage depends heavily on local telemetry quality, especially process-to-network correlation and visibility into protocol fields. Encrypted traffic, limited proxy logs, lack of EDR network events, or privacy restrictions on header/cookie inspection can materially reduce detection fidelity. The object does not provide relationships, tactics, or formal detection logic, so local baselining and testing are required.
Analytic 0302
Atypical processes (e.g., powershell.exe, regsvr32.exe) encode large outbound traffic using Base64 or other character encodings; this traffic is sent over uncommon ports or embedded in protocol fields (e.g., HTTP cookies or headers).
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 40ec955fad61… |
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.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN0302Open source URL
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.