Experiments with Invoke-Phant0m

Halil Dalabasmaz recently released Invoke-Phant0m, a PowerShell script that walks the thread stacks of the event-log service process and kills event log service threads.

Antiforensics is an area of extreme interest to me, so I decided to pull it down and start experimenting with it.

Killing Event Logs

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 write-eventlog:

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.

Expanding on thread killing

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.

Windows Defender

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 -enumonly switch:

Enumerating WinDefend threads

The threads that I was interested in appeared, and are highlighted below:

WinDefend threads

The way invoke-phant0m normally works is that it will look for any thread that matches the name *evt* in the process eventlog.

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.

Carbon Black Response

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 cb.exe:

Carbon Black threads

I ran 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.