Detect unauthorised local user account creation by alerting on new local accounts, membership changes in privileged groups, and account enablement outside approved workflows. Review the creating process, source host, and associated command line or management tool. Compare changes against join, support, and provisioning processes, and investigate any account created soon before lateral movement or persistence.
How local account creation shows up in Windows telemetry
On Windows, unauthorised local user creation is usually visible as a change event, not a single obvious alert. The most useful signals are the creation of a new local account, a local account being enabled, and that account being added to an elevated local group. That matters because attackers often combine account creation with privilege changes to preserve access.
Watch the creating process and the host that initiated it. A legitimate join, support, or provisioning workflow should have a clear origin and an expected management path. If the account appears from an interactive session, an unexpected admin tool, or a remote source host that does not match your normal workflow, treat it as suspicious rather than assuming it was routine administration.
Process context is often the difference between noise and a real incident. A new account created through a known endpoint management channel is different from one created by a shell, script runner, remote execution utility, or unknown parent process. Review command line details, source host, and the surrounding audit trail together so you can distinguish approved automation from unauthorised creation.
Which account changes matter most
The highest-value detections are the ones that show the new account can actually be used. A newly created local account is more concerning when it is immediately enabled, placed into local administrators, Remote Desktop Users, or another privileged group, or used to establish persistence on a system that was already under active hands-on-keyboard activity. That sequence often tells you more than the creation event alone.
Local Administrator Password Solution (LAPS) Guide is useful context here because local account monitoring and local admin governance should be linked. If local admin control is weak, an attacker who creates or enables a local account can turn a single foothold into durable access. Tighten detection around privileged local groups, especially where local admin rights are intentionally limited.
Endpoint Privilege Management Guide helps frame why account creation should be evaluated alongside elevation patterns. If your environment allows on-demand privilege changes, your detections need to distinguish approved elevation from a newly minted account being used as a backdoor into a workstation or server.
MITRE D3FEND Guide is relevant because the defender task is to correlate account creation with process lineage, local account changes, and authorisation evidence. The control goal is not just to spot an account object, but to understand whether the activity fits the expected identity and access workflow.
How to separate admin activity from persistence attempts
The practical question is whether the change matches your approved provisioning path. Compare the event against onboarding, help desk, break-glass, support, and imaging workflows. If there is no matching ticket, no known automation, or no normal maintenance window, you have a candidate incident even if the account name looks ordinary.
Persistence Techniques Guide is a good navigation point when you are checking whether local account creation is part of an access-preservation pattern. New local users are commonly paired with later logon, group membership changes, or other persistence steps, so detection should look for the full chain rather than a single event.
For Windows environments, also compare the activity to other local account and privilege artefacts on the same host. A new account created shortly before lateral movement, remote service use, or repeated logons on the same system deserves higher priority than an isolated account created during a routine maintenance window. The timing often reveals whether the account is a convenience account or a foothold.
When the account is tied to a privileged local group, the exposure is larger because the account can be used without additional escalation. In that case, validate whether the identity was meant to exist at all, whether it was enabled by the right workflow, and whether the operator who created it had an approved administrative reason to do so.
Risk and Threat Considerations
Unauthorised local account creation is risky because it can create a durable, low-visibility access path that survives password changes on other identities. Attackers often prefer it when they want persistence on a specific host, especially if the new account is hidden inside normal-looking administration activity or immediately granted local administrative rights.
Failure mechanism: The defender sees an account object appear, but misses the surrounding enablement, group membership change, or process context that proves the account was created for access rather than routine administration. That gap lets an attacker retain access even after the original entry point is remediated.
Impact: The host can become a persistence anchor for later lateral movement, remote administration, or follow-on credential abuse. If the account is privileged, the attacker may not need to return through the original vulnerability to keep operating.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1136.001 — Local Account | Models local account creation as an adversary persistence and access technique. |
| T1098 — Account Manipulation | Covers account enablement and group changes used to preserve access. | |
| Recommendation — Alert on new local account creation and correlate it with privilege changes and process lineage. Correlate account creation with enablement and local group membership changes. | ||
| CIS Controls v8 | CIS-5 — Account Management | Requires controlled account lifecycle and review of local account changes. |
| Recommendation — Review and approve local account creation through formal account management processes. | ||
| NIST SP 800-53 Rev 5 | AU-12 — Audit Record Generation | Supports logging of account creation, enablement, and group changes for detection. |
| IA-4 — Identifier Management | Applies to managing local identities and their lifecycle on Windows systems. | |
| Recommendation — Ensure audit logs capture local account creation and privilege changes. Manage local account identifiers through approved lifecycle controls. | ||
Practitioner Guidance
What to verify: Confirm that every local account creation event maps to a known join, support, imaging, or provisioning workflow, and that any privileged group membership change has an approved change record. If you cannot tie the event to a business reason quickly, treat it as suspicious until proven otherwise.
What to measure: Track the rate of local account creation outside approved workflows, the number of creations followed by privilege elevation, and the time from account creation to first suspicious logon or remote execution. Those three measures show whether you are detecting the behaviour early enough to matter.
Practitioner takeaway: The strongest detections do not stop at “a new local user exists”, they prove whether the account fits an approved process and whether it was turned into a privilege-bearing access path.