Don’t stress about a bit of stress testing

What if… we added 100K HKCU\…\Run keys to the Registry?

What will be the impact on the system? What will be impact on the EDR tools? Sysmon? Windows Event Logs? Autoruns? Regedit?

I prepared a test Reg file with 100K dummy HKCU\…\Run entries – click to download it. I then imported them to the Registry.

It actually took a while.

During this time the GUI version of Regedit.exe pointing to HKCU\…\Run entries was DoSd. I am not sure if it was because of slow enumeration of the Run key entries at that moment (while they key was being updated), or it was simply locked due to a second instance of regedit.exe running (and busy adding entries) – perhaps the program is using some blocking mechanism e.g. mutex to avoid concurrent access to the same resources. In any case, this took a few minutes.

Sysmon was running in the background, and intercepted all the entries with no problem. All good.

Unfortunately, EDR tests are harder, because tools are not available to public. You should perhaps try to test it with your EDR, because it may show some interesting gaps…

Running GUI version of Autoruns takes a long time – it is not only a large number of items to enumerate, Autoruns populates GUI as it reads the values – perhaps updates should be done in one go? with the window painting temporarily disabled(?).

When ran from command line, autorunsc.exe ran for less than 30 seconds to enumerate everything which is pretty good. I believe that it would change dramatically if the dummy files actually existed on the system (in my test entries point to non-existing files).

I guess a similar test could be run with processes. Grab a dummy file, rename and run it 100K times and see what happens…

Beyond good ol’ Run key, Part 100

It’s actually 99th, because I forgot one part on the way 🙂

This is one more persistence method based on a built-in set of features. This time the culprit is the Policy Manager.

Browsing through the PolicyManager key located here:

  • HKLM\Software\Microsoft\PolicyManager\

we can spot many interesting entries, often multiple-level deep:

Some of them include entries that are of our interest:

  • PreCheckDLLPath
  • transportDllPath

The good news is that not all entries have them a.k.a. they are optional. And it turns out that these allows to provide additional utility libraries that in turn will be loaded by Policy Manager components (policymanager.dll) when this DLL itself is utilized.

I couldn’t come up with a quick& dirty way to load the test dll, so I cheated by starting the procmon, setting up the filters, and letting it go for some time. After awhile I caught the first process accessing these entries:

The harvesting may be easier on a system connected to the domain (policies deployment/access is more frequent).