The Windows Service Control Manager (services.exe) is a juicy target for adversaries who want to run highly privileged executables. Perhaps not surprisingly, we detected an adversary using it to create a new account and establish persistence via Windows Management Instrumentation (WMI) consumers in an environment we were monitoring as part of an incident response engagement over the summer.
Our detection engineers described the event as follows:
The Windows Service Control Manager (services.exe) executed a command that issues multiple subsequent commands, including the creation of a new user account and the establishment of persistence via WMI consumers.
Of course, we weren’t really looking specifically for persistence. However, in the process of releasing this environment from a Smominru cryptocurrency mining outbreak—one that used ETERNALBLUE for initial access —we encountered this novel persistence mechanism.
Hopefully we can provide enough context and behavioral indicators in this blog that other security teams can develop methods for observing and detecting when adversaries persist similarly.
It starts with services.exe
Most of the activity that matters for this detection emanated from a single, lengthy command.
The command contained a number of IP addresses that the adversaries used to download binaries relating to regsvr32.exe and PowerShell commands, to name a couple things.
It’s worth noting at this point that our adversary appears to have obtained local, SYSTEM-level privileges, which is essentially the most privileged level of access possible, granting an attacker full control over an infected system.
After the command
Upon execution, the adversary used their administrative access to create their own user account (admin$) protected by their own password, adding this account to the local admin group. Doing so enables the attacker administrative level access if they ever need to logon to this machine in the future.
Interestingly, this adversary also tried to get administradores (Spanish for “administrators”) level privileges, which could say something of who is being targeted or it could reveal that the adversary doesn’t know exactly who they are targeting.
You can see the process metadata associated with these actions in the following image:
What is WMI, anyway?
WMI is a native Windows subsystem that carries out all sorts of actions relating to performance telemetry, system management, and configuration. It’s basically mission critical on Windows systems, so you can’t just disable it, dust off your hands, and call it a day.
It’s also got a feature called event subscription. To leverage this technique, an adversary must define an event filter to specify criteria of interest in a manner similar to Scheduled Tasks. Next, an event consumer is created to describe an action taken when the filter criteria is met (such as executing PowerShell). Finally, the filter and consumer are bound together using a binding object. Adversaries often use this persistence mechanism, and it can be tricky to find with endpoint detection and response (EDR) tools. This obscurity is due to the fact that adversaries can store information in a WMI command and that information gets executed directly via WMI without affording EDR tooling the opportunity to observe it.
As a brief sidebar for existing customers…
It’s worth noting that Automate includes a feature that lets users collect forensics packages, offering even greater visibility into their endpoints. WMI consumers and filters are one of the many artifacts included in a forensics package. In this way, existing customers would have an additional opportunity to catch this behavior.
Out with the old; in with the new
However, here we can see that someone deleted a WMI event filter. Adversaries often clean up an environment before they start implementing their own persistence, and it’s possible that they were trying to remove some existing persistence mechanism associated with another strain of malware. This illustrates the visibility boundary of EDR well. Since this adversary specified all their commands in a single long command line, we can observe the actions taken. If they had passed a script or a .NET binary to the system instead, we would not have observed the manipulation of the WMI Event Subscription persistence. However, to do so would increase the attacker’s footprint and risk discovery by defenders via other means.
At the risk of stating the utterly obvious and insulting the collective intellect of our dear readers, it’s worth pointing at that adversaries attempt to establish persistence via WMI events that are easy to trigger and occur all the time. However, they are not commonly used in wmic.exe commands as shown in this post.
A note on detection
As we suggested above, it is hard to catch persistence via WMI events from the perspective of IR or IT. You have to enumerate all of the WMI objects and root out the ones that are evil. As such, when we do find this flavor of persistence with EDR, it’s incredibly valuable. Discovering a potential persistence mechanism early in the investigation can save incident responders time and accelerate remediation when they’d normally need to use a tool like Sysinternals Autoruns to enumerate objects.
It’s not as obvious as scheduled tasks, Registry autorun keys, or startup items. However, when an adversary creates a WMI event subscription for persistence, there is a multi-part process where they have to define what event is needed, define commands, and make sure that everything is bound together. Fortunately, we can see the whole chain here in this detection, but there are ways to make this happen that don’t involve wmic.exe.
Post persistence
Upon establishing persistence, the adversary starts executing other things. We can see regsvr32 download a script and pass it into scrobj.dll for execution. This process relationship—affectionately known as Squiblydoo—is almost always malicious. It’s such a well known and effective application whitelisting bypass that it’s almost a given that it gets used exclusively for that purpose.
In the end, the threat seemed to pull down something that may well be a driver (or could be installed as one).
Conclusion
We talk a lot about detection viability here at Red Canary. The crux of the issue is this: having the ability to observe activity doesn’t necessarily mean that you can provide enough context to reliably detect it as malicious. For example, we could achieve 100 percent coverage of PowerShell attacks simply by creating a detector that triggers every time PowerShell spawns. Doing so would allow us to catch all the evil PowerShell (eventually), but it would also saddle our detection engineering team with a nearly endless stream of false positives.
To that point, we weren’t looking explicitly for persistence here, and, in fact, none of the detectors that initiated tip-offs for this event even map back to a persistence mechanism. However, there were at least six distinct opportunities for detection here:
- The command line contained an admin share
- PowerShell downloaded a remotely hosted file
- Regsvr32 made a network connection
- Regsvr32-scrobj.dll application bypass
- Regsvr32 had a URL in the command line
- Cmd.exe spawned from services.exe
Each of these detectors is imperfect on its own, but they led to human analysis that could rely on an abundance of endpoint visibility to find additional evil. Ultimately, our IR partners could then remove this persistence mechanism and more expediently clean up the affected environment.