Expanding upon Hlldz's Invoke-Phant0m
27 Aug 2017 - Jonathan Echavarria
Antiforensics is an area of extreme interest to me, so I decided to pull it down and start experimenting with it.
The idea of it killing logging is great, and I love the fact that it leaves it as a running process. However, my initial testing sort of killed it flat.
|Invoke-Phant0m killing event log threads|
It successfully killed the threads, and I did note that the event log viewer service is running. However, to test this, I’d have to generate an event… So of course, the easiest way to do that is though PowerShell’s
|Using write-eventlog to create an event|
But when I went to go look in the event log for the events, they were there!
|Output of Event Viewer showing event exists|
So… why didn’t that work?
Looking at the MSDN article for write-eventlog, we can see that it describes the cmdlet as
writes an event to an event log, which must mean that it writes to the actual file itself, and doesn’t actually make use of the event log service. If whatever application you use writes to the event-log service in this way, it should bypass the protections provided by this tool.
I attempted a few actions I normally did that would generate logs (privilege escalations, etc), and it DID successfully prevent writing of events to the event log that way.
The only other caveat I noticed with this was that occasionally the threads can restart, so this needs to be ran periodically on the endpoint to ensure the threads stay down.
That being said, killing threads of a process to prevent it from functioning, while still keeping the process running is a pretty novel way to bypass security measures. I got curious and start to think of other ways this could be used on an engagement.
Eventually, I ended up creating a modified version of Invoke-Phant0m that has the ability to provide you with a list of threads for a given process, and can kill those threads for you.
The classic target to demonstrate this with is Windows Defender. Installed by default on practically every modern Windows system, defender is more of an annoyance than anything. A good first step, it filters out a fair amount of malware that’s “not even trying”, but fails to detect most things with just a little bit of thought put into them.
To start, I enumerated all of the threads running for the
WinDefend service. The modified script supports this by specifying the process name with
-processname and adding the
|Enumerating WinDefend threads|
The threads that I was interested in appeared, and are highlighted below:
invoke-phant0m normally works is that it will look for any thread that matches the name
*evt* in the process
I applied the same logic to my modification, so by specifying Mp, any thread matching
*Mp* in the specified
WinDefend process should be killed, which will be all of the threads highlighted above.
By passing the
-threadfilter parameter, you can tell the script which threads to kill for the specified process:
|Killing all of the relevant WinDefend threads|
Windows Defender was technically still running, but it certainly wasn’t detecting anything.
Of course, I had to attempt this on an actual EDR tool, and for this, I chose Carbon Black Defense.
Enumerating the threads for the
carbonblack service, I could see the ones that I’d be interested in killing are
|Carbon Black threads|
invoke-phant0m with a thread filter for
cb and eagerly awaited the results:
|Killing all of the relevant Carbon Black threads|
Finally, using Process Explorer, I verified that all of the threads in Carbon Black were killed:
|Viewing Carbon Black with Process Explorer|
Normally, this would be pretty exciting. Unfortunately however, looking at the Carbon Black console revealed a telling matter:
|Sensor Status on the CB Response Console|
Unfortunately, the sensor status was marked offline, and a tamper alert was generated on the console for the sensor, so while further actions couldn’t be detected or alerted upon anymore, this one was caught, which should make any competent IR/HUNT team suspicious. Realistically though, in most environments, these alerts are generated often, and rarely investigated, so it’s entirely possible it could be ignored.
It’s entirely possible that only killing specific threads will kill just the monitoring portion of the process, but that would require some further experimentation.
I’m confident that not many tools are well defended against having their threads killed in this fashion. Feel free to give my modified version of Invoke-Phant0m a spin against whatever you have and see how it holds up. This is a great utility, and I foresee it being used extensively in all of our further campaigns.