Hunting Event Logging Coverup

After my last post, there were some points, rightly raised by some friends, on how to detect execution of PS based tool like Invoke-Phant0m, which basically look for the event log service process (svchost.exe) and related threads which are responsible for event logging, after locating these threads, the tool terminates them. As a result, no more logs are recorded, no System, Security, Application, neither Sysmon or enhanced powershell logging etc. 

This pose a serious challenge as the adversary can easily execute this script first on the victim and then go about performing his/her malicious activities without registering any logs whatsoever. 

So in this post, we will look into 3 different scenarios and see how we can detect adversaries messing with event logging.

Scenario 1: 

Clearing the logs manually (when the adversary is able to use various mechanisms using local scrip execution, remote clearing of logs using meterpreter clearev or interactively right clicking the logs and clearing them)

On doing this, both Security and System logs record EventID 1102 and EventID 104. This is a significantly suspicious event to monitor and alert upon:

Scenario 2:

Killing Event log service threads (not the process itself, which means the service keeps running. However no event collection is done)

Killing Event Collection threads using Invoke-Phant0m and detecting it

Ref: https://www.youtube.com/watch?v=PF0-tZWCmpc

https://github.com/hlldz/Invoke-Phant0m

So this is before I run the Invoke-Phant0m script. We can see that adding/deleting local user register logs in the event logs and in sysmon operational logs (net command).

Let us invoke the Invoke-Phant0m:

Now we try adding/deleting users and in turn NO logs are recorded whatsoever. Not in security events and neither in Sysmon Operational events.

Execute notepad.exe but nothing in sysmon. All threads are killed.

From this point onwards, the adversary can basically perform post-compromise activities, without creating any alerts at least if the alerts are based on event logs.

But Wait! We gotta look at the Enhanced Power shell logging logs. What can we find there.

Ok we can see the  EventID 800 (pipeline execution) where we see the Invoke-Phant0m script being executed and the string "I`m here to blur the line...." being printed on the console. However all of this can be changed by the adversary so basically are not reliable ways to detect this.

The following are the high fidelity alerts (EventID 800) we should focus on. Below we can see Event 800 indicating WMI query for process which are linked to the "eventlog" service. The HostApplication can be any process.

Here also EventId 800, where there is PS code to trace the threads which are linked to the process grabbed before (eventlog service related process)

We can see here another EventID 800, killing the threads of the eventlog service processes.

Now I will look at PS ScriptBlock logging logs. Since there are like 6000 events created in a matter of time when Invoke-Phant0m was executed, I decided to export these logs to csv and go through them to identify important alerts. I searched only for Executing pipeline and executing a remote command task categories.

EventId 4104: We can see deobfuscated PS code in the memory, which is trying to suspend eventlog process threads:

Scenario 3:

Running the command to clear up all logs from command prompt:

Strangely when I execute the following command to clean up all logs from windows event logs

for /F "tokens=*" %1 in ('wevtutil.exe el') DO wevtutil.exe cl "%1"

The logs are all cleared. However, the following two events are still generated even after the threads have been killed.

Scenario 4:

Next I use meterpreter's clearev, which only clears System,Security and Application and do not touch Sysmon or PS logs:

Again critical events are generated indicating malicious clearing of logs:

I hope this can help you to create detection and alerting rules/logic in SIEM/EDR/ELK etc.

In Part 3 of the series we will try some other adversary TTPs and then try to identify detection mechanisms.