You are browsing the archive for Anti-*.

Too much % makes Event Viewer drunk

January 27, 2019 in Anti-*, Anti-Forensics, Forensic Analysis, Incident Response, Malware Analysis

Update:

After I posted it Daniel Bohannon provided a link to his earlier research (March 2018) where he described the very same problem. He has some interesting examples so please have a look!

Old Post:

This is a short post about a funny side effect of using the % sign and how these are being interpreted by Windows Events Log Viewer.

When you use this character as a part of a file name, or as a Registry data the program will assume these % signs are referring to actual parameters and will resolve them into actual strings.

I know it doesn’t make any sense, so let’s do a test.

Name your program %1.exe. Run it. This is what the Viewer will show:

Now try to add this Registry value:

reg add HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run /v Foo /t reg_sz /d test%1%2%3%4%5%6%7%8%9%10%100

The result? Very strange details:

What about naming the program %1%2%3.exe?

Look at the image and the command line. One is: C:\Test\2019-01-27 22:28:29.601{670b5bbc-308d-5c4e-0000-00105f407c03}.exe, and the other “C:\Test\Incorrect function.The system cannot find the file specified.The system cannot find the path specified..exe”.

Only the viewer is fooled, because the actual data is logged properly (although there is an inconsistency in the way %s are doubled in command line) — one just needs to go to Details tab and see what it really shows:

That’s it. Yet another quirky behavior to be aware of.

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…