AN1252: Analytic 1252
Detects behavioral chains where PowerShell is launched with encoded commands, unusual parent processes, or suspicious modules loaded, potentially followed by network connections or child process spawning. Supports detection of both direct (powershell.exe) and indirect (.NET automation) invocations.
Analyst context for executives and security teams
This analytic matters because suspicious PowerShell use on Windows is often a pivot point between initial access, hands-on-keyboard activity, payload execution, and outbound command activity. For leaders, the value is not simply “detect PowerShell,” but confirming whether the SOC can see risky execution patterns: encoded commands, unexpected parent processes, suspicious module loading, network activity, and child process creation, including indirect invocation through .NET automation.
Executive priority
Prioritize this as a Windows endpoint visibility and response-readiness check. It helps answer whether security teams can investigate script-driven activity quickly enough to support containment decisions, audit evidence, and incident response. Budget and control discussions should focus on whether endpoint telemetry, PowerShell logging, process lineage, and network correlation are complete and usable, not just whether PowerShell is allowed or blocked.
Technical view
Validate coverage for Windows behavioral chains involving powershell.exe and indirect .NET automation. Detection engineering should correlate command-line content, encoded command indicators, parent-child process relationships, loaded modules, subsequent network connections, and spawned child processes. Because no ATT&CK tactic or formal detection logic is supplied, teams should treat AN1252 as a detection design pattern rather than a ready-to-deploy rule.
Likely telemetry
- Windows process creation events with full command line
- Parent and child process lineage
- PowerShell execution and script/module logging where enabled
- Image/module load telemetry
- Endpoint network connection events tied to process identity
Detection direction
- Tune for chains of suspicious behavior rather than single indicators, such as encoded PowerShell plus unusual parent process plus network activity.
- Validate that telemetry preserves full command lines and process ancestry; missing command-line or parent process data is a major blind spot.
- Include both direct powershell.exe execution and indirect automation paths, as described by the analytic.
- Baseline legitimate administrative, software deployment, and security tooling activity to reduce false positives from encoded commands or automation.
- Use child process spawning and outbound connections as risk escalators when reviewing PowerShell alerts.
Mitigation priorities
- Establish strong endpoint logging first: process command line, PowerShell logs, module loads, and network connections.
- Restrict or govern PowerShell use through approved administration patterns where operationally feasible.
- Review administrative tooling and automation accounts so legitimate PowerShell activity is identifiable and attributable.
- Harden endpoint execution controls and script governance based on business need and exception management.
- Ensure incident response playbooks cover triage of encoded PowerShell, suspicious parents, module loads, child processes, and outbound connections.
Analyst notes and limits
The supplied object is a detection analytic for Windows only. It describes behavioral detection scope but does not provide official detection logic, tactic mapping, relationships, aliases, or labels. Local baselining is required because PowerShell and .NET automation can be legitimate in administrative environments.
This take is limited to the official STIX fields, external reference, and absence of relationship context provided. It does not infer adversary use, active exploitation, specific ATT&CK techniques, impact, or guaranteed detection coverage.
Analytic 1252
Detects behavioral chains where PowerShell is launched with encoded commands, unusual parent processes, or suspicious modules loaded, potentially followed by network connections or child process spawning. Supports detection of both direct (powershell.exe) and indirect (.NET automation) invocations.
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 | 92a0560ff933… |
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 AN1252Open 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.