Late 2019, early 2020, I was given the opportunity to familiarize with SentinelOne and chose to conduct some ad hoc threat hunting. Since then, SentinelOne’s capabilities have significantly increased and Ursnif (more on that later) has evolved. Having finally received clearance to publish a sanitized version of my report in 2021, I felt that the process and findings were still relevant and could be useful to some. That shortened report follows.
Background
LOLBAS are binaries, scripts, and libraries that are typically found as a part of a normal Windows installation that can be used by an attacker for malicious purposes. It can be difficult to detect because it uses trusted, legitimate (and generally digitally signed) tools that are used by Windows. Protective measures like application whitelisting will often trust activity from these programs since they’re a normal part of the system’s operations, and a defender must comb through legitimate uses of each program in order to identify any malicious usage. Ultimately, if malicious activity is identified, it can be difficult to identify the attacker since they are using a Windows binary instead of their own malware.
One of the behaviors that was searched for was misuse of the Windows Management Instrumentation (WMI) Command line (WMIC) binary, wmic.exe. This maps to the MITRE ATT&CK Enterprise Technique T1218 (Signed Binary Proxy Execution) and to the MITRE Cyber Analytics Repository (CAR) Analytic CAR-2016-03-002 (Create Remote Process via WMIC).
Using the CAR or information from the LOLBAS Project , we know that one way to identify suspect WMIC behavior is by looking through command line logging for instances of wmic.exe that include the string “process call create.” For example:
wmic.exe process call create calc
In this instance, wmic.exe is being used to execute calc.exe.
The Hunt
Searching
Within SentinelOne, using the Visibility tool, we can identify similar activity with the following query:
ProcessName ContainsCIS "wmic.exe" AND ProcessCmd ContainsCIS "process call create"
This query will look for processes with a name that contains “wmic.exe” regardless of letter-case (it will match both “wMiC.exe” as well as “wmic.exe” and any other combination of cases) and a process command that contains the string “process call create” regardless of letter-case (CIS meaning “case insensitive”). With the time frame for our search set to “Last 3 Months” we get results like the following:

Identification
At this point, we don’t know whether we have identified malicious activity, but we know that our search for suspicious WMIC activity has returned results. Using Sentinel One Visibility, we can view the details of each of these processes by clicking on them.

Reviewing the “Command Line” details for the process, we can see here that wmic.exe is being utilized to create a new PowerShell process. That PowerShell process is executing a command via “iex” (abbreviation for “Invoke-Expression”).

That command is derived from the value of the registry key named
This is not a command that you would expect to see in a normally functioning Windows machine and is very likely malicious code being run on the device. The next item to note is the frequency with which this code is running.

It is running each morning on an almost daily basis, with recurring gaps on Sundays and Wednesdays, suggesting that the malicious code is executing every time the user logs into their workstation. This hypothesis seems to be supported by the process tree, showing winlogon.exe as the great-grandparent to our process.

Persistence
There are a couple of different methods for executing instructions on a Windows device any time a user logs on. One is via scheduled tasks , and another is via registry run keys. Depending on agent version, SentinelOne can provide us with insight into registry key data and scheduled task execution. We know the time for each process, so we can run a new search for that time window to see what the device is doing.

Since there are only four in the relevant time window, it’s easy to review all the scheduled tasks to see if any look suspicious. None do. There is far more registry activity than scheduled task activity, so we will need to refine our search a bit. An example query can be seen below. Sadly, while the registry logging feature of SentinelOne is an exciting new addition, it doesn’t seem to quite capture all usage, particularly registry reads.

For example, we know that the suspicious wmic.exe command is reading the value of a registry key, however we see no such read reflected in the results above.
Understanding now that the registry activity data in SentinelOne, while great, is incomplete at best, we can next take advantage of an extremely powerful (if somewhat frightening) feature that now exists in SentinelOne: Remote Shell. If enabled via policy, and access is granted to the researcher as a user, then this will allow you to open an Administrative shell directly on the device in question. All commands and results are recorded during the session and made available in an encrypted archive for download later.
Using this shell, we can directly query the registry on the device with PowerShell. Knowing that the suspicious WMIC.exe process is running under the local user’s account, we will need to query their specific HKCU hive. Because our shell is an administrative shell and not running under the user in question, this means that we actually need to query
PS C:\WINDOWS\TEMP> Get-ItemProperty-Path Registry::HKEY_USERS\[SID]\Software\Microsoft\Windows\CurrentVersion\Run.
...
Cameplua: C:\WINDOWS\system32\wbem\wmic.exe /output:clipboard process call create "powershell -w hidden iex([System.Text.Encoding]::ASCII.GetString((get-itemproperty 'HKCU:\Software\AppDataLow\Software\Microsoft\[UID]').CfgSedui))"
...
The value of
Execution
Turning our attention next to the registry location mentioned in our process (
PS C:\WINDOWS\TEMP> Get-ItemProperty-Path Registry::HKEY_USERS\[SID]\Software\AppDataLow\Software\Microsoft\[UID]
...
Cameplua: C:\WINDOWS\system32\wbem\wmic.exe /output:clipboard process call create "powershell -w hidden iex([System.Text.Encoding]::ASCII.GetString((get-itemproperty 'HKCU:\Software\AppDataLow\Software\Microsoft\[UID]').CfgSedui))"
...
Here we see the exact same value as in the Run registry. Looking at other keys in the same location, there are some other items of interest.
PS C:\WINDOWS\TEMP> Get-ItemProperty Registry::HKEY_USERS\[SID]\Software\AppDataLow\Software\Microsoft\[UID]\
...
Client32: {133, 184, 78, 156...}
Client64: {133, 184, 78, 156...}
CfgSedui: {36, 119, 100, 98...}
Cameplua: C:\WINDOWS\system32\wbem\wmic.exe
/output:clipboard process call
create "powershell -w hidden iex([Sys
tem.Text.Encoding]::ASCII.GetString((
get-itemproperty 'HKCU:\Software\AppD
ataLow\Software\Microsoft\[UID]
[UID-cont]').CfgSedui)
)"
Client: {89, 12, 0, 0...}
...
The value of the key
$wdbhynwlgv="hpxrkfbtfp";function twqmjhkpphn{$hcxf=[System.Convert]::FromBase64String($args[0]);[System.Text.Encoding]::ASCII.GetString($hcxf);};
Note, too, the registry keys

Findings
At this point, we’ve identified a Windows Registry Run key (T1547.001) using wmic.exe (T1218) to run PowerShell (T1059.001) which reads values from other registry keys (T1012) and executes code on the system. This is not behavior that you would find from benign programming but are clear signs of a fileless malware infection on the system. Googling various indicators leads to numerous analyses of Ursnif infections utilizing the same techniques, suggesting that we are dealing with the same on the client system. Assuming, for a moment, that this hypothesis is correct, that would suggest that the infection vector was via a malicious Microsoft Office document that was delivered via phishing email.