AN1177: Analytic 1177
Multi-stage Windows DACL manipulation behavioral chain: (1) Process creation of permission-modifying utilities (icacls.exe, takeown.exe, attrib.exe, cacls.exe) or PowerShell ACL cmdlets, (2) Command-line analysis revealing privilege escalation intent through suspicious parameters (/grant, /takeown, /T, Set-Acl), (3) DACL modification events (4670) correlating with process execution, (4) Subsequent file access attempts (4663) indicating successful permission bypass, (5) Potential follow-on persistence or lateral movement activities
Analyst context for executives and security teams
This analytic matters because Windows file and object permissions are often part of the path from initial access to control of sensitive data, persistence, or movement. The supplied ATT&CK description focuses on a behavioral chain: permission-changing tools or PowerShell ACL activity, suspicious command-line options, Windows security events showing DACL changes, and later file access that may indicate the permission change succeeded.
Executive priority
Treat this as a control-validation item for Windows monitoring and incident readiness. Leaders should ask whether the organization can prove who changed sensitive permissions, which process made the change, whether access followed, and whether SOC/IR teams can connect those events quickly enough to support containment and audit evidence. It is especially relevant where unauthorized permission changes could affect business-critical files, privileged administration paths, or compliance-sensitive data.
Technical view
For Windows environments, validate collection and correlation across process creation, command-line arguments, DACL modification event 4670, and file access event 4663. The analytic specifically names permission-modifying utilities such as icacls.exe, takeown.exe, attrib.exe, cacls.exe, and PowerShell ACL cmdlets such as Set-Acl. Detection value comes from chaining these signals rather than alerting on any single administrative command in isolation.
Likely telemetry
- Windows process creation telemetry for permission-modifying utilities
- Command-line arguments for icacls.exe, takeown.exe, attrib.exe, cacls.exe, and PowerShell ACL cmdlets
- Windows Security Event 4670 for permission changes
- Windows Security Event 4663 for subsequent file access attempts
- Follow-on activity telemetry that may indicate persistence or lateral movement, where available
Detection direction
- Confirm that command-line logging is available for Windows process creation events; without arguments, parameters such as /grant, /takeown, /T, or Set-Acl may be missed.
- Correlate permission-modifying process execution with Event ID 4670 and later Event ID 4663 against the same or related objects.
- Tune for administrative false positives, such as approved maintenance, software deployment, backup operations, or help desk remediation workflows.
- Prioritize sensitive paths, privileged-access locations, and business-critical file stores to reduce noise and increase decision value.
- Because no ATT&CK relationships or tactics were supplied, avoid over-mapping this analytic to a specific intrusion stage without local incident context.
Mitigation priorities
- Establish baselines and change-control expectations for legitimate Windows permission changes.
- Limit who can modify DACLs on sensitive systems and data locations through least-privilege administration.
- Ensure Windows audit policy and endpoint logging are configured to capture permission changes and file access where operationally feasible.
- Create IR playbooks for unauthorized permission changes, including ownership validation, access review, and rollback decision points.
- Use periodic access reviews and configuration validation to identify permission drift before it becomes an incident.
Analyst notes and limits
This is a detection analytic object, not a technique description. The strongest use is as a validation pattern for Windows SOC content: process execution plus command-line intent plus security event correlation plus post-change access. The supplied object has no relationship context, no tactic assignment, and no official detection text beyond the description, so local environment baselines are required for prioritization and tuning.
The supplied ATT&CK fields only support Windows coverage and the described DACL manipulation behavioral chain. There is no supplied attribution, active exploitation claim, mitigation mapping, relationship context, or official detection procedure. Confidence in the general defensive interpretation is moderate, but environment-specific coverage depends on local logging, audit policy, and correlation capability.
Analytic 1177
Multi-stage Windows DACL manipulation behavioral chain: (1) Process creation of permission-modifying utilities (icacls.exe, takeown.exe, attrib.exe, cacls.exe) or PowerShell ACL cmdlets, (2) Command-line analysis revealing privilege escalation intent through suspicious parameters (/grant, /takeown, /T, Set-Acl), (3) DACL modification events (4670) correlating with process execution, (4) Subsequent file access attempts (4663) indicating successful permission bypass, (5) Potential follow-on persistence or lateral movement activities
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 | 6f0a0d184fe4… |
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 AN1177Open 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.