Get A Handle On Indicators Of Compromise

It's been a while since our latest blog post. Being busy with customer projects and growing our company, the available time to blog about our research sometimes falls a bit short. Nevertheless, I'm happy to write this short blog post about a recent topic that has come up during a recent engagement. This blog post will take a look at how the usage of a tool could lead to indicators of compromise (IoC) by writing files to the local disc and how an operator could see this while testing the tool in a lab.

Recently, we sometimes had the problem that SharpHound and SOAPHound did not execute properly when run in our C2 agent's process. As an alternative, we wanted to use SharpView, the C# implementation of PowerView. However, I remembered reading about an IoC in SharpView from this MDSec blog post on Active Directory enumeration for red teams. While the executable can be run in memory, due to its usage of a certain library (PCRE.NET), a folder is created in the %TEMP% folder of the executing user and a DLL is created in it. Security products could monitor for this event and alert on it, as the DLL always has the same name. See also this tweet for the IoC.

Looking at how SharpView utilizes PCRE.NET shows that it is only used in two methods to find regex matches. This functionality can also be achieved by using .NET's Regex.Match function, eliminating the need for an external library. An updated version of SharpView (including some pull requests from the original repo as well as other small fixes and additions) can be found on my GitHub fork.

Testing to see if these changes had the desired effect, I first checked the %TEMP% folder after running the executable which uses PCRE.NET. As can be seen, the directory and the DLL are created.

I removed the DLL and the folder, then executed the new SharpView executable that does not reference the external library anymore.

And indeed, no new items have been created in the folder.

This is all fine, but what if there wasn't a tweet or a blog post warning us about this IoC? Could we see that a process writes something to disk, even though we try to stay in memory only? One way that came to mind was using Process Hacker (now System Informer) to see which handles the process has open. This could give us an indicator or even show directly that a file has been written to disk, including its path. Case in point, running the PCRE.NET version of SharpView shows the following handles.

The DLL's path is shown and it would even be visible, if you were to step through the execution, which command led to this file's creation. Browsing to the directory, we find the DLL.

With the changes to SharpView, no such handle is present anymore.

This example works fine when we know what to look for and have our Process Hacker at hand. I wanted to have the possibility to monitor specific processes a bit more programmatically than with Process Hacker and potentially even in memory as well, for example if we try to monitor a process on an engagement instead of in our lab.

Thus, I put together HandleMonitor. The code is almost entirely based on functionality in a fork of MceController (DetectOpenFiles.cs) and periodically queries a process for its open handles. The tool logs these handles, so even if they are closed again, they will still be visible in the tool's output.

The tool is very much just a proof of concept, so if you encounter any bugs, please feel free to open a GitHub issue or even a pull request! I might add HandleMonitor as a task to Covenant (we're so back...) in the future if it proves to be helpful to us.

Thanks for reading and as always, please feel free to send any questions or remarks to research@avantguard.io or contact me in the BloodHoundGang slack (user @jannlemm0913).