Windows Registry Internal finding

Posted on June 15, 2022 · 3 mins read

Today whilst investigating some SolarMarker malware at a customer I discovered something really interesting about the user hive inner workings (NTUSER.dat).

As most of you dear readers will know, the NTUSER.dat holds the user hive and is mounted at HKEY_USER/<SID>/. But there is a trick to one section of this that is not widely known.

File extension associations can be configured at a machine level or on a per user basis. SolarMarker uses this to its advantage and registers a file extension associated with the file it drops into the user’s startup folder. As part of this registration a program is required to be configured. SolarMarker again uses this to its advantage and registers a powershell script that will load the file in the user’s startup folder and decrypts it using hardcoded AES key and IV. The script then loads the .net module into memory for execution. More information on the persistence mechanism is in Sophos’s blog post on it.

Why am I going into this detail and what does this have to do with this so called finding?


Im getting there :satisfied:

This file association is located at HKU/<SID>/Software/Classes. Normally when the user is logged into the machine, you can query this with reg query and be done with it. But what about when the user isn’t logged in. What about when the user’s registry hive has been unloaded and you have to load it manually?

Well TIL that loading the users NTUSER.DAT file does not load the Classes keys. These are actually loaded into a different location in the registry. the whaaaat

Yep this was my reaction when I learnt this today. Completely dumbfound.

It turns out that the location HKU/<SID>/Software/Classes is basically a symbolic link to HKU/<SID>_classes


This is automatically setup by windows on logon. But if we manually load the NTUSER.dat then how can we load the _classes location as well I hear you ask. Well this was my exact question I asked my team today. No one seemed to have a clear answer as no one had come up against this before. Off to google I go…

Stack overflow to the rescue. Hidden away in the depths of stack overflow was the answer I was looking for.

There is another section of the registry located within the user hive.


This is the location of this data. Loading this file in with reg load to the _classes location does not automatically link the location to HKU/<SID>/Software/Classes but it is at least loaded to be able to query.

Ultimately if you are doing forensics or IR on a machine with SolarMarker or any other malware that uses file extensions to maintain persistence, then you should make sure that you are checking the HKU/<SID>/Software/Classes location. Removing the file might be enough but without removing these registry keys, you are leaving a risk to the machine.

Tweet me @parker607 with your favorite eureka moment!