AN2029: Analytic 2029
Process execution without GUI context (e.g., powershell.exe, wscript.exe) generates HTTP traffic with a spoofed User-Agent mimicking a legitimate browser. No corresponding UI application (e.g., msedge.exe) is active or in parent lineage. The User-Agent deviates from known enterprise baselines or contains spoofed platform indicators. User-Agent strings can be gathered with API calls such as `ShellExecuteW` to open the default browser on a socket to receive an HTTP reply, or by hard coding the User-Agent string for a specific browser.
Analyst context for executives and security teams
This analytic matters because it looks for Windows processes that should not normally behave like a user-driven web browser but are generating HTTP traffic with a browser-like, potentially spoofed User-Agent. For leaders, the decision value is whether the organization can distinguish normal browser activity from script or command-line activity impersonating a browser, which is often important for SOC triage and incident response confidence.
Executive priority
Prioritize validation where Windows endpoint visibility and network/proxy telemetry intersect. The business question is not just whether HTTP traffic is logged, but whether teams can prove which process generated it and whether a real browser session was present. This supports better incident decisions, reduces blind spots in managed detection, and provides evidence for control assurance around endpoint monitoring and web activity review.
Technical view
Validate on Windows that detections can correlate process execution context with outbound HTTP metadata. The analytic describes cases where processes such as powershell.exe or wscript.exe generate HTTP traffic using a User-Agent that mimics a legitimate browser, while no corresponding GUI browser process such as msedge.exe is active or present in the parent lineage. Detection engineering should focus on correlation between process lineage, active UI/browser context, outbound HTTP events, and enterprise User-Agent baselines. No ATT&CK tactic or relationship context was supplied, so this should be treated as a detection analytic rather than mapped to a specific intrusion phase based on the provided object alone.
Likely telemetry
- Windows process execution events including process name, command line where available, parent process, and process lineage
- Network or proxy HTTP logs containing User-Agent values and destination metadata
- Endpoint telemetry linking network connections to originating process
- Evidence of active browser/UI processes during the same time window
- Enterprise baseline of expected browser User-Agent strings and platform indicators
Detection direction
- Correlate outbound HTTP requests with the originating Windows process and its parent lineage rather than relying only on network-layer User-Agent inspection.
- Flag non-browser or non-GUI processes generating browser-like User-Agent strings when no corresponding browser process is active or in lineage.
- Tune against known administrative scripts, software updaters, automation tools, and enterprise applications that legitimately make HTTP requests with browser-like User-Agent values.
- Maintain and review enterprise User-Agent baselines so deviations or spoofed platform indicators can be assessed in local context.
- Account for a key blind spot: network logs without process attribution may show the User-Agent but not whether it came from a browser or another process.
Mitigation priorities
- Ensure endpoint telemetry can capture Windows process execution and process-to-network associations.
- Ensure web proxy, network, or HTTP inspection logs retain User-Agent values needed for correlation.
- Define expected User-Agent baselines for managed browsers and approved automation so alerts can be prioritized.
- Review scripting and administrative tool usage policies where non-browser processes commonly initiate HTTP traffic.
- Use this analytic as a validation point for SOC and IR workflows: analysts should be able to pivot from HTTP activity to the responsible process and lineage.
Analyst notes and limits
The supplied object is an ATT&CK detection analytic for Windows. It provides a behavioral description but no official detection logic, no tactics, and no relationship context. The strongest use is as a coverage test for endpoint-network correlation and User-Agent baseline quality.
This take is limited to the supplied STIX fields and external reference. It does not establish active exploitation, actor attribution, impact, or guaranteed detection. Local baselines are required to separate suspicious spoofing from legitimate non-browser HTTP clients.
Analytic 2029
Process execution without GUI context (e.g., powershell.exe, wscript.exe) generates HTTP traffic with a spoofed User-Agent mimicking a legitimate browser. No corresponding UI application (e.g., msedge.exe) is active or in parent lineage. The User-Agent deviates from known enterprise baselines or contains spoofed platform indicators. User-Agent strings can be gathered with API calls such as `ShellExecuteW` to open the default browser on a socket to receive an HTTP reply, or by hard coding the User-Agent string for a specific browser.
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 | df3523c0bac4… |
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 AN2029Open 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.