A few more Anti-BlueTeam ideas

Posted on by

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.

Analyzing Word Documents via VBA/VBS

Posted on by

Analyzing malicious Word documents usually focuses on using 2 different types of tools. Some can analyze a file structure with the intention of extracting macros for further analysis. Others support dynamic analysis with the aim of extracting the run-time IOCs. Some sandboxes and reversers try to deobfuscate the VBA code as well, but it’s quite a tedious job if done manually. Luckily, this area of research is now so advanced that reversing tools supporting this mundane task exist, and sandboxes (e.g. Joe Sandbox) use this approach to trace the VBA code execution in a manner similar to a classic API Monitor for a while now.

There is one more approach, or should I say, one more additional avenue we can pursue – and it is by using the VBA code itself. I used it many times in the past and found it pretty useful.

Once you load a malicious document into Word and access the malicious VBA code (and provided there is no trickery that prevents or makes it harder), you can inject your own snippet of code into the analyzed document. You can then run it in a context of the active document structure. It’s super trivial – just add a new module, or paste the code in the same module where the malware code is present. While such injected code cannot answer all the reversing questions, sometimes it can help to extract, and also attribute certain values to specific objects (e.g. strings or blobs seen in the file can be hidden in some less-obvious property) – it’s an important association that otherwise may be much harder to establish.

For instance, the below snippet walks through all shapes in the document and prints out all URLs associated with them:

Dim S As Shape
Dim ish As InlineShape

For i = 1 To ActiveDocument.Shapes.Count
Set S = ActiveDocument.Shapes.Item(i)
Debug.Print i & " " & S.LinkFormat.Type
On Error Resume Next
Debug.Print S.LinkFormat.SourceFullName
Next i

For i = 1 To ActiveDocument.InlineShapes.Count
Set ish = ActiveDocument.InlineShapes.Item(i)
Debug.Print i & " " & ish.LinkFormat.Type
On Error Resume Next
Debug.Print ish.LinkFormat.SourceFullName
Next i

One can easily expand this snippet to add all the possible objects that include URL-related properties. And of course, we can go a step further and add enumeration of all major document objects and their properties in general (e.g. normal and custom or advanced properties, their names, values, including blobs of data that may be well hidden in some objects’ properties, etc.). As such, bypassing the UI limitations (plus, it is much faster to do it this way).

Apart from the specifically malicious items, such script can help with a possible actor attribution as well. Some of the file properties may be stored in different languages, or refer to a different language (names of the properties, text encodings, hidden texts, historical entries, etc.) – they are normally not that easy to discover using the UI, yet with the direct access to the document structure they become immediately available, once enumerated.

And we don’t need to use VBA all the time. Using VBS to open Office documents is a trick as old as Office itself. We can open malicious documents via the word application object and apply the data extraction code immediately. (note that it will obviously trigger the execution of malware in most cases).

Some examples of useful VBS code that can be re-purposed for this task are here, and here. Lots of old code doing this sort of stuff can be easily found via Google.

Of course, the technique can be used for all Office documents supporting automation / VBA.

Last, but not least – I mentioned in my older post that sometimes opening macro-malware  in Office 2003 version will help accessing data more than we can get through the eye-candy interface of the latest Office versions (newer versions remove access to some properties that you could still see in the Office 2003 via GUI). Using VBS we can run a quick scripted conversion to other formats so a malware could be opened and saved as .rtf, .doc, .docx, .txt in one a simple batch job. The resulting files can be made available to other tools for further processing.