You are browsing the archive for EDR.

Don’t stress about a bit of stress testing #2

January 25, 2019 in Anti-*, EDR, Random ideas

Yesterday I tested 100K Run keys, today I test 100K Sysmon rules.

Sysmon is visibly struggling:

The CPU goes high, and the logs are not being added. I let it ran for a couple of minutes, but this state has not changed. No idea if it just takes that long to ingest so many rules? So… not sure if Sysmon has any upper limits for the number of rules, but I guess we can assume it is not 100K, but less. Why? I tried 1K, 10K, and 25K of identical rules and for these numbers sysmon worked pretty well. Once sysmon digested the rules the logs started appearing almost immediately.

Update:

It looks like 100K is definitely a killer number. After ~20 minutes the program bailed out stating that there is not enough memory:

The test was not very methodical, I used a bit of a naughty rule that was testing a presence of a long substring within a string representing an image of each created process. Assuming that sysmon has to test 1K, 10K, 25K, 100K rules on each process, it should affect the processing speed.

It’s obviously not a biggie, because one needs to modify config to disrupt the processing so much, but it is good to know that too many rules may not be a very healthy idea. Still, since a typical config won’t cross 1-5K rules it should work for you like a charm…

Don’t stress about a bit of stress testing

January 24, 2019 in Anti-*, EDR, Random ideas

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…