Detecting Lateral Movement 101 (Part-2): Hunting for malcode Execution via WMI using Windows Event Log Analysis

imp hash
5 min readJul 22, 2020

--

MITER ATT&CK Reference
Tactic: Execution
Technique ID: T1047 — Windows Management Instrumentation (WMI)

Windows Management Instrumentation (WMI) has been favorites of Adversaries as WMI can do it ALL for them — malware/code execution, lateral movement, persistence, defence evasion, discovery, collection, exfiltration. Rarely, you get such a technique/service that can be used in almost any/every phase of attack lifecycle and it is included by default (native binary) in all versions of Windows. Therefore, adversaries and various threat groups have been using WMI heavily in their various TTPs.

In this article, we are going to talk about how WMI is used for “Remote Execution” cum “Lateral Movement” by the adversaries and we will understand the various footprints it leaves in the environment. That will eventually help us to build the detection or hunt capabilities for this technique.

How WMI is used by the Attackers for Lateral Movement?

Once the attackers escalate their privileges after gaining initial access to the victim organization, their goal is to move laterally in the organization either to propagate their malware/malicious code or to get in to the target machine/s for the information that they are looking for. As I said earlier, WMI can be used for gathering information (Discovery Phase — Internal Reconnaissance) from the remote machine OR it can be used to execute the code/binary on the remote machine. However, the footprints that we are going to discuss will help us to hunt for both discovery and execution.

Adversaries most often use WMI’s “Process call create” argument to execute code remotely on the machine. Please have a look on the following snippet that shows the indicative use of WMI by the adversaries for the remote execution/lateral movement.

Figure 1. Indicative use of wmic from Attackers’ perspective

In the above snippet, /node & Process Call Create are important arguments to note. We can hunt or build the detection capability based on these. In this snippet, ipconfig is run on a remote machine (192.168.189.155) using process call create argument.

How to hunt for WMI Remote Code Execution / Lateral Movement?

There are quiet a few footprints left behind when above WMI command gets executed on source and the target machines. We will focus on Windows Event Logs as they will provide most comprehensive information than other artifacts on the machines.

EventLogs on Source Machine
Following are the key event logs are generated for this activity on the source machine.
EventCode 4648 — A logon was attempted using explicit credentials
EventCode 4688 / SysmonID 1 — Process Creation (wmic.exe)
Event 4648 is generated because of explicit use of credentials while using wmic for code execution. In the snippet above, the explicit user is dfiruser. 4648 looks like as following.

Figure 2. 4648 at the Source

Look at the juicy information it has provided to us. It provides information about original account(kirtar) & switched account (dfiruser). Moreover, it provides the hostname of the Target Server, Process Information (wmic.exe) and the destination/target IP address (192.168.189.155). Please note the logged time as well for correlation on the destination side.

The second key log that is generated on the source is Sysmon ID 1 (Process Creation). This log also provides very critical information that can be useful in extending the investigation further. The full command line is captured along with the binary name and path. (have a look on the following snippet)

Command line tells us what has been executed. In our case, ipconfig is run on the remote system using dfiruser. That implies “dfiruser” is compromised. Moreover, we can see that (and we saw in 4648) that current user is “kirtar” hence I is implied that this user is also compromised. (it can be inferred that kirtar may have limited privileges and dfiruser has admin privileges)

Figure 3. Sysmon ID 1 at the Source

Moreover, current directory, hash of the image and parent process along with the command lines are captured. This is really important; we will see the importance of capturing parent process command line at the destination.

I have observed that, 4648 gets logged after a few seconds (here 12 seconds) of SysmonID 1. This behavior is persistent.

Event Logs at the destination

As we discussed in the part 1 (previous article), we get local admin user authentication trilogy (4776,4672,4624 (Type3)) at the destination as wmic gets authenticated over the network using local admin account.

Figure 4. Privileged local account authentication triology at destination

Observe the time, all of them are nearly same time and it is in match with the (4648) event at the source. All of these logs provide various types of information that can be seen in the details of each log.

Another, very important log that will reveal the complete story on the destination side is Security 4688 / Sysmon ID 1.

We will get 4688 event logs at the destination. In our case, we have got 3 of them. One for each process that has been generated by the command wmic at the source. I will showcase the process that we should track during our hunting and detection.

Figure 5. 4688 at the destination

When wmic has been invoked remotely on the machine, the process called wmiprvse.exe gets created on that machine. Have a look at the following snippet and look at the parent process & parent command lines — that are exactly similar to what we have invoked from the source machine. The process is wmiprvse.exe and it has a child process cmd.exe and then we have a ipconfig.exe with cmd.exe as parent. So , we have 3 4688 ( one for each cmd.exe, conhost.exe and ipconfig.exe). conhost.exe is an associate process of cmd.exe — we may not need to pay much attention in this case.

Figure 6. 4688 at the destination

Now, this log will not tell us from where this event is been triggered. For that, we need to look at the 4624-logon event on the same time. That will give us the source information. Look at the following snippet of 4624 of the same time, it provides the information about the source (192.168.189.1) and the account(dfiruser) that is used to authenticate.

Figure 7. 4624 at the destination

By combining all this information, we will have solid information about what is executed, by whom and from where.

That’s it for now, folks!! Happy hunting, fellas!!

--

--