AN1182: Analytic 1182
Process execution that probes user activity artifacts (e.g., desktop files, registry history) following recent user login/unlock events.
Analyst context for executives and security teams
This analytic is about spotting Windows processes that look at user-activity artifacts, such as desktop files or registry history, shortly after a user logs in or unlocks the workstation. For leaders, the practical value is that this can indicate software or activity attempting to learn whether a real user is present, what they recently used, or how to time follow-on actions around human activity. It matters because these signals can support early investigation before a suspicious process turns into broader compromise, but the ATT&CK entry does not provide a ready-made detection rule.
Executive priority
Treat this as a coverage-validation item for Windows endpoint monitoring and SOC readiness. Security leaders should ask whether the organization can correlate recent login or unlock events with process execution and access to user artifacts. The priority is not a standalone control purchase; it is confirming that endpoint telemetry, identity/session events, and investigation workflows can answer: what ran, under which user, shortly after which interactive session event, and what user artifacts did it inspect?
Technical view
For SOC and detection engineering teams, the core validation is correlation on Windows between recent user login/unlock activity and process execution that probes user activity artifacts such as desktop content or registry history. Because no official detection logic is supplied, teams should define local baselines for legitimate processes that commonly enumerate desktop files or read user-history registry locations after sign-in. Investigation should focus on unusual parent-child process chains, unexpected users or hosts, rare binaries, suspicious command lines, and timing tightly coupled to unlock or login events. Tactics are not specified in the supplied object, so this should be handled as a behavior-level analytic rather than mapped to a guaranteed attack phase.
Likely telemetry
- Windows process creation events, including image path, command line, parent process, user, host, and timestamp
- User login and workstation unlock events with user, host, session, and timestamp context
- Registry access or registry auditing for user-history locations where available
- File access or endpoint telemetry showing enumeration or access to desktop/user-profile artifacts
- Endpoint detection and response metadata for process reputation, prevalence, lineage, and host/user rarity
Detection direction
- Validate that process execution telemetry and login/unlock telemetry can be joined reliably by user, host, and time window.
- Build baselines for legitimate post-login activity, such as shell, profile, desktop management, backup, indexing, and enterprise management tools, to reduce false positives.
- Prioritize alerts where the probing process is rare, unsigned or unexpected, launched from unusual paths, spawned by unusual parents, or appears shortly after an unlock/login without a clear business purpose.
- Tune carefully because many benign Windows and enterprise tools inspect desktop files or registry history during normal user-session initialization.
- Document blind spots where registry/file access auditing is unavailable, endpoint telemetry is sampled, command lines are missing, or unlock events are not centrally collected.
Mitigation priorities
- Ensure Windows endpoint logging captures process creation and relevant command-line context.
- Centralize login and unlock/session events so SOC teams can correlate process behavior to recent user activity.
- Where feasible, enable or validate endpoint telemetry for registry and user-profile file access related to activity artifacts.
- Harden investigation playbooks to triage suspicious post-login processes using parent process, binary prevalence, user context, and host role.
- Use findings from detection tuning to improve application allowlisting, least privilege, and endpoint control policy where abnormal tools repeatedly access user artifacts.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic for Windows only. It describes a behavioral pattern but provides no official detection query, no tactic mapping, and no relationship context. A useful implementation therefore depends heavily on local telemetry quality, normal software inventory, and the organization’s ability to correlate endpoint and session events.
This take is limited to the official STIX fields, external reference, and supplied relationship context. It does not assert active exploitation, actor usage, impact, or detection coverage. The object does not specify exact registry paths, file paths, event IDs, thresholds, or supported data sources, so local engineering decisions are required.
Analytic 1182
Process execution that probes user activity artifacts (e.g., desktop files, registry history) following recent user login/unlock events.
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 | 2cb668af3d85… |
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 AN1182Open 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.