AN0404: Analytic 0404
Flows showing encrypted payloads with high entropy not matching TLS handshake patterns, particularly when occurring on non-standard ports. Defender observes NetFlow/IPFIX byte distribution anomalies or IDS/IPS detecting symmetric encryption patterns without associated key exchange.
Analyst context for executives and security teams
This analytic is about spotting network flows that look encrypted but do not look like normal TLS, especially on unusual ports. For leaders, the value is not in identifying a specific threat actor, but in validating whether the organization can notice covert or non-standard encrypted communications that may bypass controls expecting web/TLS traffic patterns.
Executive priority
Prioritize this as a coverage question for network visibility and SOC readiness: can teams distinguish sanctioned encrypted business traffic from anomalous encrypted payloads on network devices? This matters for incident triage, audit evidence around monitoring, and resilience against activity that hides inside opaque traffic. Because no ATT&CK tactic or relationship context is supplied, treat it as a detection engineering validation item rather than a standalone risk conclusion.
Technical view
SOC and detection teams should validate whether NetFlow/IPFIX, IDS/IPS, or equivalent network-device telemetry can surface high-entropy payload patterns that do not match TLS handshake behavior, particularly on non-standard ports. Tuning should account for legitimate encrypted protocols, custom applications, VPN-like traffic, and scanning or testing tools that may create similar entropy patterns. The supplied object does not provide a formal detection query, so implementation requires local baselining and protocol-aware analysis.
Likely telemetry
- NetFlow or IPFIX records from network devices
- IDS/IPS alerts or protocol analysis events
- Byte distribution or payload entropy indicators where available
- Destination port and protocol metadata
- TLS handshake presence or absence indicators
Detection direction
- Confirm whether network devices and sensors retain enough flow and protocol metadata to identify encrypted-looking payloads without TLS handshakes.
- Baseline legitimate encrypted traffic on non-standard ports before alerting aggressively.
- Tune for combinations of high entropy, non-standard ports, and missing TLS negotiation rather than any single signal alone.
- Review false positives from approved custom applications, tunnels, VPNs, backup tools, or administrative protocols.
- Use this analytic as supporting evidence for investigation, not as proof of malicious activity by itself.
Mitigation priorities
- Improve network visibility first: ensure flow collection, IDS/IPS inspection, and protocol metadata are available where policy permits.
- Reduce unnecessary encrypted services on non-standard ports through network governance and service inventory.
- Document approved exceptions for custom encrypted protocols so SOC teams can suppress known-good behavior safely.
- Use segmentation and egress control to limit unexpected outbound encrypted communications from sensitive environments.
- Feed confirmed findings into incident response playbooks and compliance evidence for monitoring coverage.
Analyst notes and limits
This is an ATT&CK detection analytic, not a technique description. The object is limited to Network Devices and describes anomalous encrypted payloads that do not match TLS handshake patterns. No tactic, relationship context, aliases, or official detection logic were supplied, so the take focuses on validation, telemetry, and operational use rather than adversary behavior or attribution.
The supplied ATT&CK fields do not identify associated techniques, threat groups, campaigns, procedures, or an exact query. Local network architecture, approved encrypted applications, sensor placement, and retention determine whether this analytic is practical or reliable.
Analytic 0404
Flows showing encrypted payloads with high entropy not matching TLS handshake patterns, particularly when occurring on non-standard ports. Defender observes NetFlow/IPFIX byte distribution anomalies or IDS/IPS detecting symmetric encryption patterns without associated key exchange.
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 | d39bddcf9b8a… |
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 AN0404Open 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.