AN0705: Analytic 0705
Monitor for use of native utilities such as wevtutil.exe or PowerShell cmdlets (Get-WinEvent, Get-EventLog) to enumerate or export logs. Unusual access to security or system event channels, especially by non-administrative users or processes, should be correlated with subsequent file export or network transfer activity.
Analyst context for executives and security teams
This analytic matters because Windows event logs are often the evidence trail for intrusions, misuse, and compliance investigations. Monitoring native tools such as wevtutil.exe and PowerShell cmdlets used to enumerate or export logs helps security leaders understand whether sensitive audit data is being accessed in unusual ways, especially by non-administrative users or unexpected processes.
Executive priority
Treat this as an evidence-protection and incident-readiness control. If attackers or unauthorized users can enumerate or export security and system logs without detection, investigations may lose context and sensitive operational details may be exposed. Leaders should ask whether Windows log access is monitored, whether unusual exports are reviewed, and whether SOC and IR teams can correlate log access with file creation or network transfer activity.
Technical view
For Windows environments, validate monitoring for native log utilities and PowerShell cmdlets named in the ATT&CK description: wevtutil.exe, Get-WinEvent, and Get-EventLog. Focus on unusual access to Security or System event channels, especially when initiated by non-administrative users or unexpected processes. Correlate log enumeration or export activity with subsequent file export behavior and network transfer activity, as specified by the analytic description.
Likely telemetry
- Windows process creation telemetry for wevtutil.exe and PowerShell execution
- PowerShell command-line or script block visibility where available
- Windows event log access or query activity involving Security and System channels
- File creation or export artifacts following log enumeration
- Network connection or transfer telemetry after log export activity
Detection direction
- Confirm that command-line visibility is sufficient to identify wevtutil.exe usage and PowerShell cmdlets such as Get-WinEvent and Get-EventLog.
- Baseline legitimate administrative log collection, troubleshooting, and audit workflows to reduce false positives.
- Prioritize alerts where non-administrative users, unusual parent processes, or unexpected hosts access Security or System event channels.
- Correlate log access with later file export and network transfer activity rather than alerting only on a single command.
- Review blind spots where PowerShell logging, process command lines, or network transfer telemetry are not collected or retained.
Mitigation priorities
- Restrict access to sensitive Windows event channels to appropriate administrative and service accounts.
- Define and document approved log collection and export workflows so SOC teams can identify deviations.
- Ensure endpoint and Windows logging policies preserve process, PowerShell, file, and network evidence needed for correlation.
- Review account privileges and administrative group membership that allow broad log access.
- Include this behavior in incident response evidence-handling and compliance-readiness checks.
Analyst notes and limits
No tactic, technique relationship, or broader relationship context was supplied, so this take is limited to the analytic description and Windows platform field. The key defensive value is validating whether log enumeration or export by native Windows utilities can be observed and correlated with export or transfer behavior.
Official detection content was not provided, and no relationships were supplied. Local baselines are required to distinguish legitimate administration, audit collection, troubleshooting, and backup activity from suspicious behavior.
Analytic 0705
Monitor for use of native utilities such as wevtutil.exe or PowerShell cmdlets (Get-WinEvent, Get-EventLog) to enumerate or export logs. Unusual access to security or system event channels, especially by non-administrative users or processes, should be correlated with subsequent file export or network transfer activity.
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 | 236c699c4fbb… |
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 AN0705Open 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.