Detecting and Mitigating Hidden User Accounts (T1564.002)

An account that does not appear on the login screen is not the same as an account that does not exist. Hidden Users (T1564.002) is a Stealth technique for Linux, macOS and Windows, and a subtechnique of Hide Artifacts.

How attackers use it

MITRE explains that administrators sometimes hide users, for example when there are many accounts or to keep management accounts out of view. Adversaries use the same mechanism to hide accounts they create or modify.

• macOS. Adversaries can create or modify a user to be hidden by manipulating plist files, folder attributes and user attributes. To keep a user off the login screen and out of System Preferences, they can set the user ID under 500 and set the Hide500Users key to TRUE in the /Library/Preferences/com.apple.loginwindow plist. Users with an ID under 500 then do not appear. With the dscl utility they can create hidden accounts by setting the IsHidden attribute to 1, and they can hide a home folder by setting chflags to hidden.
• Windows. They can set the value for a specific user to 0 under the HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList registry key, which keeps that user off the logon screen.
• Linux. They can hide accounts from the login screen, also called the greeter. The method depends on the display manager. MITRE's example is an Ubuntu system using GDM, where gsettings can set disable-user-list for the login screen. Display managers can be changed by a user or an adversary, so the method varies.

Hiding an account does not stop it from working. It only removes it from places a casual observer would look.

How to detect it

MITRE's analytics, by platform:

• Windows. Registry changes under the SpecialAccounts UserList key that set a user's visibility to 0, correlated with account creation.
• Linux. gsettings or direct display manager changes that hide users from the greeter, such as commands modifying the login screen settings.
• macOS. User creation or modification through dscl with IsHidden set to 1, user IDs under 500, or plist edits to the loginwindow Hide500Users flag.

An account created and hidden within minutes of each other is the strongest version of the signal.

Why hidden accounts are a good persistence tool

An account is a durable foothold. It survives reboots, patches and malware cleanup. If it is also invisible to the people who look at the login screen or the System Preferences list, it can survive a casual review. That is why MITRE treats this as a distinct technique and not just as part of account creation.

The mechanisms differ by platform, but one idea repeats: the account is real, and only the display is changed. So any control that enumerates accounts from the source of truth, such as the directory, the password file or the local account database, will find it, while a control that relies on what the login screen shows will not.

Make account review a data question

Instead of looking, compare. Export the local account list from each system on a schedule and diff it against an approved list. On Windows, the Security log records account creation as event ID 4720, so an alert on that event for unexpected hosts catches the creation itself. On macOS and Linux, the same idea applies with the account database and configuration management.

For hidden status specifically, check the settings MITRE names: the SpecialAccounts key on Windows, the Hide500Users value and the IsHidden attribute on macOS, and the login screen settings on Linux. A change to any of them on a machine that does not normally use them is a lead.

When you find a hidden account

1. Record the account name, ID, group memberships, creation and last logon times.
2. Find out when and how it was created, from audit logs and shell history where available.
3. Check what the account has done: logons, processes, files and network connections.
4. Disable it, then remove it once evidence is preserved.
5. Look for the process or credential that created it, because the account is a symptom of earlier access.

How to reduce the risk

MITRE lists one mitigation: operating system configuration. On a domain-joined computer, group policy can help restrict the ability to create or hide users. On macOS, preventing modification of the Hide500Users value in the loginwindow plist forces all users to be visible.

The deeper control is to compare accounts against an approved list instead of relying on what the login screen shows.

Check your own environment

These commands only read state.

# Windows (cmd): list local user accounts
net user

# Windows (cmd): read the hidden-account registry key, if present
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList"

# macOS: list accounts with their user IDs, then check the hide setting
dscl . -list /Users UniqueID
defaults read /Library/Preferences/com.apple.loginwindow Hide500Users

# Linux: list real accounts (user IDs 1000 and above)
awk -F: '$3 >= 1000 {print $1, $3, $7}' /etc/passwd

Then ask:

• Does every account in the listing belong to a person or a documented service?
• Is anything present in the registry key, or any macOS user with an ID under 500 that you did not create?
• Does your configuration management compare local accounts to an approved list and alert on differences?

Common mistakes

• Treating the login screen as the list of accounts.
• Comparing account lists only on servers, and ignoring laptops and workstations.
• Removing a hidden account without asking how it got created. The creation path is the real hole.

Quick check

Sources

• MITRE ATT&CK T1564.002: Hidden Users