AN0267: Analytic 0267
Modifications to user accounts via `dscl`, `pwpolicy`, or System Preferences CLI (`sysadminctl`) that alter user groups, enable root, or bypass MDM restrictions.
Analyst context for executives and security teams
This analytic focuses on macOS account-administration changes made through command-line or system tools that can materially affect control of an endpoint: changing group membership, enabling root, or weakening management restrictions. For leaders, the value is not just detecting a command; it is validating whether the organization can see and explain high-risk local account changes that could affect device trust, privileged access, and endpoint manageability.
Executive priority
Treat this as a readiness check for macOS identity and endpoint governance. Security leaders should ask whether privileged local account changes are logged, reviewed, and tied to approved administration workflows, especially where MDM controls are relied on for compliance, configuration enforcement, or incident containment. Gaps here can weaken audit evidence and complicate incident response because responders may not be able to determine when local privileges or management restrictions changed.
Technical view
For SOC and IR teams, validate visibility into macOS activity involving `dscl`, `pwpolicy`, and `sysadminctl` when those activities modify user accounts, alter user groups, enable root, or affect MDM restrictions. Because ATT&CK provides no formal detection logic for this analytic, teams should build environment-specific baselines for legitimate administration and investigate changes that occur outside expected management tooling, maintenance windows, or approved administrator identities.
Likely telemetry
- macOS process execution telemetry for `dscl`, `pwpolicy`, and `sysadminctl`
- Command-line arguments or equivalent execution context where collected
- Local user and group change records
- Root account enablement or privileged account state changes
- MDM or endpoint management logs showing policy or restriction changes
Detection direction
- Confirm whether macOS endpoint telemetry captures process execution and command context for the named tools; without command context, triage value may be limited.
- Correlate account and group modifications with approved change records, MDM activity, and known administrator workflows.
- Prioritize review of events that enable root, change privileged group membership, or affect MDM restrictions.
- Tune for expected IT administration to reduce false positives while preserving alerts for unusual users, hosts, timing, or unmanaged execution paths.
- Document blind spots where local account changes are not centrally logged or where MDM logs are unavailable to the SOC.
Mitigation priorities
- Restrict local administrative privileges to approved users and workflows.
- Use MDM or endpoint management policy to enforce macOS account and restriction baselines where applicable.
- Require change control and auditability for privileged account, group, root, and management-policy changes.
- Ensure incident response procedures include validation of local macOS accounts, group membership, root status, and management enrollment state.
- Retain sufficient endpoint and management logs to support investigation and compliance evidence.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic for macOS only. It names the relevant tools and behavior categories but does not include ATT&CK tactics, related techniques, relationships, or official detection logic. Local baselining is essential because the same tools can be used for legitimate administration.
No relationship context or official detection text was supplied, so this take cannot infer adversary use, specific ATT&CK tactics, detection coverage, severity, or impact beyond the described macOS account and management-control modifications.
Analytic 0267
Modifications to user accounts via `dscl`, `pwpolicy`, or System Preferences CLI (`sysadminctl`) that alter user groups, enable root, or bypass MDM restrictions.
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 | ef322c904940… |
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 AN0267Open 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.