After watching an excellent presentation about “Red Teaming in the EDR Age” by @joehowwolf I immediately started thinking of other ideas that could be used to evade EDR one way or another. This is not to help the bad guys, but to learn more about how we all rely on data inputs that can be, and actually are often a subject to manipulation by whoever has the rights to do so… Also, seeing the talk, the other take away is that red teams have a really hard time fighting the blue now, so perhaps it’s good for once to be ahead of a curve and… still keep pushing for even more blue successes…

I wrote about sysmon log manipulation and other abuse a couple of times before so we let it rest for a moment. Instead, let’s have a quick look at the Event 4688. It is a precious source of process creation logs for many orgs. Orgs that either can’t install sysmon, EDR solution… or, one that actually works. (again, not talking about OSX, Linux as it’s a subject to different rules).

If we look at the way the process auditing is implemented in Windows, it becomes quickly apparent how easy it is to make some quick changes to the system to bypass the logging, even if partially. Obviously, you need admin/system rights to do so, but obtaining these is an exercise for the reader^H^H^H^H^H^Hred team 🙂

So… the quick ideas…

• One can patch the code of EventWrite API in all processes and the events will stop being recorded, but it’s too brutal and will immediately raise questions (lack of events from the system is kinda easy to spot – see last paragraph of this post)
• Obviously, event deletion is an option too, but it’s cumbersome and not really worth it, unless you are a 3-letter agency and need it for some reason
• Clearing logs creates an event itself, so it’s also not a good avenue to pursue, besides… there is the whole business of event forwarding that perhaps can be manipulated, but it’s non-trivial (see the discussion below)
• Finally, we can implement a more advanced hook of EventWrite to only log stuff that doesn’t include our processes. A kinda good ol’ stealth/rootkit way (i.e. is it something about my process? then ignore writing, otherwise write).
• If we know of some clean processes that spawn other processes, we can actually execute these to feed the log monster; the cmd line args should change randomly (but still make sense) so that they cannot be easily regexpable (to make it harder to add these to the whitelists)

But there is more.

While the 4688 event configuration is a bit harder to access or manipulate directly (Audit Policies are stored in a Security hive file; see the Regripper plug-in auditpol.pl for more in-depth information on how to access the data inside the blob e.g. index 0x4E is for the process creation on Win10), the auditing of process creation including command line data depends on this single Registry entry:

• HKLM\SOFTWARE\Microsoft\Windows\
  CurrentVersion\Policies\System\Audit\
  ProcessCreationIncludeCmdLine_Enabled=0|1

Interestingly, changes to the key are observed in real-time, since the OS (lsasrv.dll) registers a notification callback for Registry changes to the parent Audit key listed above (via RegNotifyChangeKeyValue API). Anytime the policy changes, the data will be written to the Audit key, then it will be read and interpreted again when the callback kicks off (policy setting refresh). So, we can temporarily disable command line logging! And since most of blue team rules rely on these command line logs being present you may bypass some of these rules by making the command line field empty, at least temporarily!

And of course, if one wants to temporary disable/enable the whole 4688 there is always this set of commands available:

• auditpol /set /subcategory:”Process Creation” /success:disable /failure:disable
• auditpol /set /subcategory:”Process Creation” /success:enable /failure:enable

Or, if you want to query the system audit policy for 4688 just run:

• auditpol /get /subcategory:”Process Creation”

But there is more…

While I have not researched it yet, I believe the event forwarding activity can also be disabled, suspended temporarily, or even monitored/tunneled through an API hook, and/or only selected data could be allowed to go through. This can happen on many layers of the OS/EDR stack, and depending on what tools, protocols, and monitoring APIs, or tracing functionality is being used, and how (e.g. is it the ‘log everything approach’ or just snapshots taken at regular intervals, or data provided on-demand). Again, one can simply kill, or (better) suspend processes related to EDR or event forwarding (e.g. Splunk Forwarder process). Same goes for native Windows processes supporting Event forwarding. Or we can rely on the aforementioned audit policy disabling via auditpol.exe. And nothing stops the attacker (as long as s/he has the rights) from patching any process in memory to modify the event forwarding behavior. While killing services, tasks, or changing their properties is a bad idea in general (may be blocked by the anti-tampering mechanisms or can trigger additional Events), there is always some room for abuse. And yes, I guess anyone can write to these logs too? There is always a way to introduce some dummy entries. They can both help with the enforced log rotation (erasing evidence), and throw some bad info into the mix.

This is certainly a fertile area for further research (i.e. how to suspend, disable, patch, reconfigure or DoS specific process, or make it randomly crashing, or change the destination for the forwarded logs or other settings in the configuration, patch data in memory /e.g. change data inside the buffers passed to EventWrite/, etc.).

I guess, as long as Event writing is happening, or can be influenced from the user mode, there is always a way to toy around with it…

Still, let’s try to make red team’s life a misery 🙂

And just one last minute update for the blue teams: manipulation of the event logging process can be potentially spotted by ‘availability’ or ‘heart beat’ queries. It’s good to have such queries at hand as data may stop arriving to our threat hunting well for many reasons…

I have written about other Anti-Blue attacks in the past, so feel free to read them as well.