T1564.002: Hidden Users
Adversaries may use hidden users to hide the presence of user accounts they create or modify. Administrators may want to hide users when there are many user accounts on a given system or if they want to hide their administrative or other management accounts from other users.
In macOS, adversaries can create or modify a user to be hidden through manipulating plist files, folder attributes, and user attributes. To prevent a user from being shown on the login screen and in System Preferences, adversaries can set the userID to be under 500 and set the key value Hide500Users to TRUE in the /Library/Preferences/com.apple.loginwindow plist file.[1] Every user has a userID associated with it. When the Hide500Users key value is set to TRUE, users with a userID under 500 do not appear on the login screen and in System Preferences. Using the command line, adversaries can use the dscl utility to create hidden user accounts by setting the IsHidden attribute to 1. Adversaries can also hide a user’s home folder by changing the chflags to hidden.[2]
Adversaries may similarly hide user accounts in Windows. Adversaries can set the HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList Registry key value to 0 for a specific user to prevent that user from being listed on the logon screen.[3][4]
On Linux systems, adversaries may hide user accounts from the login screen, also referred to as the greeter. The method an adversary may use depends on which Display Manager the distribution is currently using. For example, on an Ubuntu system using the GNOME Display Manger (GDM), accounts may be hidden from the greeter using the gsettings command (ex: sudo -u gdm gsettings set org.gnome.login-screen disable-user-list true).[5] Display Managers are not anchored to specific distributions and may be changed by a user or adversary.
Analyst context for executives and security teams
Hidden Users is a stealth behavior where an adversary hides local user accounts from normal login or user-management views on Linux, macOS, or Windows. The business issue is not just a hidden account; it is the possibility that persistence or unauthorized administration remains invisible to routine help desk, audit, and SOC review processes.
Executive priority
Prioritize this where local administrator accounts, shared workstations, servers, or regulated systems depend on accurate account inventories. Leaders should ask whether endpoint baselines and access reviews verify actual OS account records and login configuration, not only what appears in graphical user interfaces. This matters for incident scoping, privileged access governance, audit evidence, and operational resilience because a hidden account can undermine confidence in account deprovisioning and recovery decisions.
Technical view
This sub-technique belongs to Hide Artifacts and applies to Linux, macOS, and Windows. Validate whether detections and hardening cover OS-specific hiding mechanisms: macOS loginwindow preferences, user attributes, and hidden home-folder attributes; Windows Winlogon SpecialAccounts UserList registry values; and Linux display-manager or greeter settings such as GDM user-list behavior. ATT&CK provides no official detection text, but the relationship to DET0353 indicates a detection strategy exists for hidden user accounts. Relationship context also shows prior macOS-focused T1147 content was revoked into this sub-technique, and that Dragonfly, Kimsuky, and SMOKEDHAM have ATT&CK relationships to this behavior.
Likely telemetry
- Authoritative local user and group account inventories from endpoints
- Windows registry monitoring for Winlogon SpecialAccounts UserList changes
- macOS plist monitoring for com.apple.loginwindow and related login display settings
- macOS directory service/user attribute change evidence
- macOS file or folder attribute changes affecting user home directories
Detection direction
- Compare displayed login users against authoritative local account data; do not rely only on what appears in GUI login or preferences screens.
- Tune for changes to the specific OS configuration locations identified by ATT&CK, especially when paired with new or modified local accounts.
- Separate legitimate administrative hiding of management accounts from unexpected changes by requiring approved baselines, change tickets, or configuration policy evidence.
- For Linux, account for display-manager variation; a detection focused only on one greeter may miss systems using another display manager.
- For macOS, include both login-window visibility settings and user attributes, because hiding may involve more than one artifact.
Mitigation priorities
- Start with operating system configuration hardening consistent with M1028: define approved local accounts, approved hidden-account use, and expected login-screen behavior.
- Enforce configuration baselines through endpoint management or compliance tooling so unauthorized account-hiding settings are detectable as drift.
- Limit who can create or modify local accounts and OS login configuration, especially on administrator workstations and high-value servers.
- Include hidden-account checks in incident response triage and privileged access reviews before declaring account cleanup complete.
- Document legitimate exceptions so SOC and audit teams can distinguish sanctioned administrative configurations from suspicious stealth changes.
Analyst notes and limits
This object is a sub-technique of T1564 Hide Artifacts and is explicitly scoped to Linux, macOS, and Windows. The relationship set provides useful context: M1028 is the listed mitigation, DET0353 is a related detection strategy, T1147 was revoked into this object, and Dragonfly, Kimsuky, and SMOKEDHAM are related as users of the technique/software behavior in ATT&CK. Treat those relationships as ATT&CK context, not proof of current activity in any environment.
The official ATT&CK object does not provide a detection section, so detection guidance must be validated against local telemetry, endpoint management coverage, and approved administrative practices. The supplied data does not support claims of active exploitation, customer exposure, guaranteed detection, or impact beyond stealth and account visibility risk.
Hidden Users
Adversaries may use hidden users to hide the presence of user accounts they create or modify. Administrators may want to hide users when there are many user accounts on a given system or if they want to hide their administrative or other management accounts from other users.
In macOS, adversaries can create or modify a user to be hidden through manipulating plist files, folder attributes, and user attributes. To prevent a user from being shown on the login screen and in System Preferences, adversaries can set the userID to be under 500 and set the key value Hide500Users to TRUE in the /Library/Preferences/com.apple.loginwindow plist file.[1] Every user has a userID associated with it. When the Hide500Users key value is set to TRUE, users with a userID under 500 do not appear on the login screen and in System Preferences. Using the command line, adversaries can use the dscl utility to create hidden user accounts by setting the IsHidden attribute to 1. Adversaries can also hide a user’s home folder by changing the chflags to hidden.[2]
Adversaries may similarly hide user accounts in Windows. Adversaries can set the HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList Registry key value to 0 for a specific user to prevent that user from being listed on the logon screen.[3][4]
On Linux systems, adversaries may hide user accounts from the login screen, also referred to as the greeter. The method an adversary may use depends on which Display Manager the distribution is currently using. For example, on an Ubuntu system using the GNOME Display Manger (GDM), accounts may be hidden from the greeter using the gsettings command (ex: sudo -u gdm gsettings set org.gnome.login-screen disable-user-list true).[5] Display Managers are not anchored to specific distributions and may be changed by a user or adversary.
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.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1147 | Hidden Users | Hidden Users revoked by this object. |
| Enterprise | T1564 | Hide Artifacts | This object subtechnique of Hide Artifacts. |
Groups, software, and campaigns
G0035: Dragonfly
Dragonfly is a cyber espionage group that has been attributed to Russia's Federal Security Service (FSB) Center 16.[1][2] Active since at least 2010, Dragonfly has targeted defense and aviation companies, government entities, companies related to industrial control systems, and critical infrastructure sectors worldwide through supply chain, spearphishing, and drive-by compromise attacks.[3][4][5][6][7][8][9]
G0094: Kimsuky
Kimsuky is a Democratic People's Republic of Korea (DPRK)-based cyber espionage group that has been active since at least 2012. The group initially targeted South Korean government agencies, think tanks, and subject-matter experts in various fields. Its operations expanded to include the United Nations and organizations in the government, education, business services, and manufacturing sectors across the United States, Japan, Russia, and Europe. Kimsuky has focused collection on foreign policy and national security issues tied to the Korean Peninsula, nuclear policy, and sanctions. Kimsuky operations have overlapped with those of other North Korean state-sponsored cyber espionage actors as a result of ad hoc collaborations or other limited resource sharing.[1][2][3][4][5][6]
Kimsuky was assessed to be responsible for the 2014 Korea Hydro & Nuclear Power Co. compromise; other notable campaigns include Operation STOLEN PENCIL (2018), Operation Kabar Cobra (2019), and Operation Smoke Screen (2019).[7][8][9] In 2023, Kimsuky was observed using commercial large language models (LLMs) to assist with vulnerability research, scripting, social engineering and reconnaissance.[10]
DPRK threat actor cluster boundaries overlap in open source reporting, with some security researchers consolidating all attributed North Korean state-sponsored cyber activity under Lazarus Group, rather than tracking operationally distinct subgroups.
S0649: SMOKEDHAM
All related ATT&CK context
Mitigation direction
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 | 2.0 | Current bundle | 40db9d3dab1f… |
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]
Cybereason OSX Pirrit
Amit Serper. (2016). Cybereason Lab Analysis OSX.Pirrit. Retrieved December 10, 2021.
Open source URL -
[2]
Apple Support Hide a User Account
Apple. (2020, November 30). Hide a user account in macOS. Retrieved December 10, 2021.
Open source URL -
[3]
FireEye SMOKEDHAM June 2021
FireEye. (2021, June 16). Smoking Out a DARKSIDE Affiliate’s Supply Chain Software Compromise. Retrieved September 22, 2021.
Open source URL -
[4]
US-CERT TA18-074A
US-CERT. (2018, March 16). Alert (TA18-074A): Russian Government Cyber Activity Targeting Energy and Other Critical Infrastructure Sectors. Retrieved June 6, 2018.
Open source URL -
[5]
Hide GDM User Accounts
Ji Mingkui. (2021, June 17). How to Hide All The User Accounts in Ubuntu 20.04, 21.04 Login Screen. Retrieved March 15, 2022.
Open source URL -
[6]
mitre-attack T1564.002Open 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.