Making Windows Users 'Invisible'

Technical - Blog Post

Once an attacker gains access to a machine, the timer starts ticking for the defender to notice their activity and kick them off the system. This could be done by terminating a network connection or changing the password on a compromised account. Because of this, threat actors are always trying to find ways to persist in an environment, in other words leaving a backdoor unlocked to let themselves back in. An easy way to do this is to create a new account on a machine to log back into at a later time. The downside to this method is that a user may notice a previously unseen user on their computer and remove the account, leaving the attacker without a way back in.

Enter the need for attackers to mask the existence of user accounts! This can be easily done through a simple edit in the Windows Registry. Let’s get into it.

First, I created a new account called SusanStorm.

By default, this account was visible from the login screen as expected.

Invisiblity ([ON] OFF)

To hide this account the steps are fairly straightforward but it is important to note that you need to be logged in as a local admin to pull this off.

  1. Load up Registry Editor (regedit) and navigate to the following key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

  2. From here create two new keys nested under Winlogon:

    • SpecialAccounts
      • UserList

  1. Create a new DWORD value under the newly created HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\Userlist key

  1. Name that value the same name as the account you need to hide and set the value to 0. Changing this value to 1 would make the account visible again.

Invisible Artifacts

The change should take place immediately, but you can log out of your account and the hidden account should not appear on the list of available users.

I was under the impression that the login page was the only place that would be affected but as I was switching users, I noticed that SusanStorm was missing from the user list on the Start Menu too. This got me curious about where else she had become invisible.

There was no sign of SusanStorm in the list of users within the Settings Menu, despite the fact that I was logged in as a local admin
The account was also not populated in the list of users in the share menu for folder preferences

Visible Artifacts

The next thing I wanted to know was where you COULD find evidence of SusanStorm

Home Directory

  1. The registry change did nothing to the visibility of the user directory for the account, which didn’t surprise me as NTFS doesn’t offer a way for a file to be more than “hidden” as far as I know.

What I did learn during this research was that a home directory is not actually required for users.

  1. If the user has not yet logged into the machine, a user home directory hasn’t been created yet.
  2. Manually deleting the SusanStorm home directory caused an error when I logged back in but it still took me to a working desktop logged in as SusanStorm. More research would be required to learn if there were any limitations to this account.

User Account Pictures

There is also evidence under C:\ProgramData\Microsoft\User Account Pictures. This artifact may be one that attackers overlook even after they delete a hidden user’s home directory. Interestingly enough, this artifact persisted after I had removed her account.

SAM Registry

Windows keeps most things straight and in order using registry files so I wasn’t too surprised when I found evidence of the account in the SAM hive. (SAM\Domains\Account\Users\) Because the hidden state is something that can be turned on and off, Windows doesn’t remove any of the critical pieces of data required to maintain and store this account. This is just one example of where I found evidence in the Registry but am sure that you could uncover this account in countless registry locations.

Conclusion

Overall this technique is not intended to remove any and all forensic data about an account’s existence. The purpose is to simply hide a new user from the standard user to avoid detection. The intended target for this deception is your average user and not a DFIR analyst diving into obscure directories/registry keys.

Unless an organization is closely watching account creations (which they should be) and modifications/additions to specific registry keys, I think that this is a wildly powerful evasion technique for an attacker to lay low until they need to utilize the account again.