An attacker can make a Window service disappear from view through careful application of discretionary access control lists (DACL). Fortunately for us, these services can still be found, though we’ll need to apply some unconventional methods to enumerate them.
In the previous article, I wrote about a technique that can be used to hide a Windows service from view using standard service enumeration techniques including Get-Service, sc query, and services.exe:
After establishing access to a system, an attacker can use this as a means to obtain persistent access to the host using the Command & Control (C2) mechanism of their choosing, evading typical service enumeration techniques.
Knowing advanced techniques as a red team analyst is great, but to be truly effective you need to be able to also inform the blue team about what they can do to stop or detect your ministrations.
If an attacker hides a service using the sc sdset technique, Windows will generate a logging event: Security log Event ID 4674:
Using the Splunk Boss of the SOC v3 data (courtesy of the amazing Dave Herrald), it appears that Security Event ID 4674 An operation was attempted on a privileged object events are pretty rare indeed, particularly when applied to the services.exe process. This seems like a good candidate for a DeepBlueCLI event detect.
First, you’ll need to download DeepBlueCLI. This is easiest if you’ve already installed Git on your system:
By default, DeepBlue.ps1 reads from the local Security log, which will identify this attack:
A sample EVTX log capture is also available for testing.
This detect is useful since it also reveals the target service name. You can confirm that the service is hidden by attempting to enumerate it and to interrogate it directly. First, we confirm that the service is hidden:
In this output we see that the service name is not displayed in the output of Get-Service. Since we know the name of the service from the DeepBlueCLI output though, we can attempt to control the service using Set-Service:
Notice how in the Set-Service command, the error message is Access is denied. Compared to a service that really does not exist, shown below:
The message Service … was not found indicates that there really is no service, while the message Access is denied tells us that it does exist, and is hidden on the local system.
This detection mechanism is useful, but is still problematic. What if an attacker clears the event log? What if an attacker purges the log entry? What if the event log information rolls over prior to detection?
Fortunately, Windows also maintains a registry key for each service in HKLM\System\CurrentControlSet\Services. We can cross-reference the registry key list with the service name list from Get-Service to identify any outliers. This gets a little complicated since there are multiple entries in the Services registry key for Windows drivers (not services) and duplicate per-user services with a locally unique identifier (LUID) at the end of the service name.
A single-line version of this script (easier to cut-and-paste) is available here.
By enumerating the registry for services and comparing against the output of Get-Service, we can identify hidden services. The output here reveals SWCUEngine as hidden, but it also reveals WUDFWpdFs (Microsoft Windows Portable Devices file system driver) as hidden as well. We can confirm this by using the Set-Service command as shown earlier in this article:
Again here, we can confirm that WUDFWpdFs is a service from the lack of a was not found on computer error message.
Hiding Windows services is a nice opportunity for an adversary to try to avoid detection, but once defenders know that this is possible, then it becomes an easy detect. Consider adding the checkhiddensvc.ps1 script to your next threat-hunting exercise.
More and more I feel the like best way to get caught is by trying to hide. –Tim Medin
Special thanks to Jon Gorenflo for help in researching detection methods for this article!
