AN1389: Analytic 1389
Detects the execution of non-browser processes establishing outbound encrypted network connections using uncommon symmetric encryption protocols (e.g., AES via PowerShell or custom scripts) to alternate external destinations.
Analyst context for executives and security teams
This analytic is about spotting Windows systems where a non-browser process, such as PowerShell or a custom script, makes outbound encrypted connections using uncommon symmetric encryption patterns to external destinations. For leaders, the value is not that encryption is inherently bad; it is that unusual encrypted outbound traffic from scripting or non-browser processes can reduce visibility and complicate incident response if the organization cannot connect network activity back to the responsible endpoint process.
Executive priority
Prioritize this as a validation question for SOC and incident response readiness: can the organization distinguish normal encrypted business traffic from unusual encrypted outbound activity initiated by non-browser Windows processes? This matters for business continuity and audit evidence because gaps in endpoint-to-network correlation can delay containment decisions, weaken investigation timelines, and obscure whether controls are monitoring script-driven outbound communications.
Technical view
For Windows coverage, defenders should validate whether endpoint and network telemetry can correlate process execution with outbound encrypted connections and destination context. Because the official object provides no detection logic and no tactic mapping, teams should treat AN1389 as a detection engineering requirement rather than a ready rule: build baselines for expected browser, application, administrative, and scripting traffic, then review non-browser processes that initiate encrypted outbound sessions to unusual or alternate external destinations. PowerShell and custom script execution deserve specific scrutiny because they are explicitly referenced in the analytic description.
Likely telemetry
- Windows process execution telemetry, including process name, command line, parent process, user, and host
- Network connection telemetry correlated to endpoint process identity
- Outbound destination metadata such as IP, domain, port, protocol, and connection timing
- Proxy, firewall, DNS, EDR, or NDR logs that can distinguish browser from non-browser outbound activity
- Script execution telemetry where available, especially for PowerShell or custom scripts
Detection direction
- Confirm that network logs are not process-blind; the analytic depends on knowing that the encrypted outbound connection came from a non-browser process.
- Baseline approved encrypted outbound activity from legitimate non-browser software to reduce false positives from update agents, security tools, management platforms, and business applications.
- Tune for Windows hosts where PowerShell or script interpreters initiate encrypted outbound connections to destinations not typical for that host, user, or application role.
- Review whether uncommon symmetric encryption indicators are observable in available telemetry; if not, use process-to-destination anomaly logic as a compensating detection approach rather than claiming full analytic coverage.
- Because no ATT&CK relationships or official detection query are supplied, validate detections through local testing and investigation playbooks before using them as compliance or coverage evidence.
Mitigation priorities
- Establish or verify endpoint logging for process execution and script activity on Windows systems.
- Ensure outbound network controls and logging can associate connections with hosts and, where possible, originating processes.
- Restrict or monitor unnecessary script interpreter use according to business need and administrative workflows.
- Maintain allowlists or baselines for expected non-browser encrypted outbound traffic and review exceptions periodically.
- Integrate SOC triage guidance so analysts can quickly separate legitimate administrative or application traffic from suspicious script-driven external communications.
Analyst notes and limits
AN1389 is a detection analytic, not a technique description. Its practical value is in forcing a coverage check across endpoint, network, and script telemetry: can analysts prove which Windows process initiated unusual encrypted outbound traffic and whether the destination is expected? The absence of relationship context means it should not be mapped to a specific adversary behavior or campaign without additional evidence.
The supplied ATT&CK fields include a description, Windows platform, and external reference, but no official detection logic, tactics, related techniques, mitigations, or relationships. Any concrete thresholds, destination reputation judgments, encryption fingerprinting methods, or claims of detection coverage require local telemetry and engineering validation.
Analytic 1389
Detects the execution of non-browser processes establishing outbound encrypted network connections using uncommon symmetric encryption protocols (e.g., AES via PowerShell or custom scripts) to alternate external destinations.
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 | c0ff687763fd… |
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 AN1389Open 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.