AN1452: Analytic 1452
Detection of processes executing system environment inspection operations followed by access to OS configuration APIs or registry locations that expose OS version, architecture, patch level, or hardware characteristics. Defenders observe process execution retrieving system configuration metadata immediately after process startup.
Analyst context for executives and security teams
This analytic is about spotting Windows processes that, immediately after starting, inspect the host environment and query operating system configuration details such as version, architecture, patch level, or hardware characteristics. For leaders, the value is not that this behavior is always malicious; it is that early environment inspection can help distinguish ordinary software startup from activity that may be preparing to adapt to a specific system. That makes it useful for SOC triage and incident response context when investigating suspicious process launches.
Executive priority
Prioritize this as a coverage-validation item for Windows endpoint monitoring rather than as a standalone high-confidence alert. Security leaders should ask whether endpoint telemetry can show process startup followed by access to OS configuration APIs or relevant registry locations, and whether analysts can use that sequence to enrich investigations. Its business value is in improving early triage, reducing uncertainty during incidents, and supporting evidence that Windows host behavior is monitored beyond simple process execution.
Technical view
For SOC and detection engineering teams, validate that Windows telemetry can correlate process creation with near-immediate system environment inspection activity and access to OS configuration APIs or registry locations exposing OS version, architecture, patch level, or hardware characteristics. Because no ATT&CK tactic, technique relationship, or official detection logic is supplied, this should be treated as a behavioral enrichment or suspicious-sequence analytic that requires local baselining. Pay special attention to newly started or unusual processes performing these queries, but expect legitimate software, installers, management agents, inventory tools, and compatibility checks to generate similar behavior.
Likely telemetry
- Windows process creation events, including process name, path, command line where available, parent process, user, and timestamp
- Endpoint telemetry showing API access or system calls related to OS configuration metadata
- Registry access telemetry for locations that expose Windows version, architecture, patch level, or hardware characteristics
- Process start timing correlated with subsequent configuration queries
- Host inventory or endpoint detection data that can distinguish common software startup behavior from unusual process behavior
Detection direction
- Validate whether telemetry captures both sides of the behavior: process startup and subsequent access to OS configuration metadata.
- Tune around timing, focusing on configuration inspection immediately after process start as described by the analytic.
- Baseline legitimate Windows software, installers, update tools, hardware/asset inventory agents, and security tools that commonly inspect OS or hardware details.
- Use this behavior as supporting context with other suspicious signals rather than as a standalone malicious indicator, because the supplied object provides no tactic, relationship context, or official detection logic.
- Confirm registry and API visibility gaps; process-only logging may not be sufficient to reproduce the analytic as described.
Mitigation priorities
- Ensure Windows endpoint logging and EDR configuration capture process creation and relevant registry or OS configuration access events.
- Document expected administrative, inventory, update, and compatibility-checking tools to support alert tuning and incident triage.
- Use the analytic to improve investigation playbooks: when an unusual process performs early environment inspection, analysts should pivot to parent process, user context, binary reputation, persistence indicators, and subsequent activity.
- Review retention and correlation capability so responders can reconstruct the sequence from process startup to configuration access during an incident.
- Avoid blocking solely on this behavior unless combined with additional locally validated malicious indicators.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic for Windows with a descriptive behavior but no official detection logic, tactics, technique relationships, or related objects. The strongest use is as guidance for validating endpoint visibility and building a locally tuned suspicious-sequence analytic.
This take is limited to the supplied STIX fields and external reference. No relationship context, tactic mapping, implementation query, data source list, or mitigation text was provided. Local environment baselining is required to determine whether this behavior is common, suspicious, or actionable.
Analytic 1452
Detection of processes executing system environment inspection operations followed by access to OS configuration APIs or registry locations that expose OS version, architecture, patch level, or hardware characteristics. Defenders observe process execution retrieving system configuration metadata immediately after process startup.
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.1 | Current bundle | 187378c99834… |
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 AN1452Open 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.