Vault 7, WannaCry, and the Case for Cyber CCTV
The Veramine team has been hard at work developing our new security monitoring, detection, and response platform. Our product is deployed now at various corporations around the world and we are delighted each time a customer is able to use it to detect and repel a determined adversary out of their network. This week we posted a couple examples showing how the Veramine platform can be used to “hunt”. We have also started documenting the platform’s automatic detection capabilities.
We are starting this new blog to talk more about our technology and how it can be used to detect and respond to APT-style threats, such as those released in the recent Wikileaks Vault 7 dump.
Vault 7 User-mode Code Injection and Persistence
An attacker has many choices to inject code and persist in user-mode. Microsoft provides the CreateRemoteThread API to facilitate code injection. Security researchers have also discovered numerous undocumented and stealthy techniques, such as Code-less Code Injections and 0-Day Techniques and HookingNirvana. The simplest persistence mechanism involves adding an entry to the “Run” registry key to have an arbitrary command executed during Windows logon. One can also add a DLL to the “AppInit_DLLs” list to have it injected into every process . Yet another method is to use the ShimEngine infrastructure to inject a DLL into every process. These are only a small list of possibilities.
The Vault 7 Wikileaks leaks revealed that this attacker is both practical and creative when it comes to user-mode code injection and persistence. They used several practical code injection and persistence methods: DLL hijacking, Run key, and Service DLLs. DLL hijacking is simply replacing a legitimate DLL that an application is known to load with a malicious one. One instance pointed out in the leak was replacing “scilexer.dll” with a trojaned version so that malicious code would be executed by the “Notepad++” process. This evades detection because it is a by-design behavior for that application. The Vault 7 threat actor is not the only one using this technique. It is also used by the PlugX malware family. Ironically, both are associated with nation state malware from opposing continents. Service DLL is another simple persistence technique that bypasses detection. Windows services can be hosted inside the service hosting process (svchost.exe); to do this, you simply create a DLL with the appropriate entry points and register it with the service control manager and it will be loaded. This is how native Windows services are developed.
There is no technical eliteness in these techniques. In fact, some security engineers have pooh-pooh’d the lack of novelty. However, one creative technique did catch our attention — the use of icon overlays for persistence. It turns out that icon overlays are actually COM DLLs loaded by the shell. This method is publicly documented on MSDN but we had never heard of it until the leak. We subsequently added automatic detection for this operation.
These types of techniques are effective because they help the attackers “hide in plain sight”. They blend in with normal application behavior and consequently make it difficult for both security software and human analysts to identify malicious intention. One might ask, why not alert when applications load DLLs from the current directory or “Downloads” folder (or any other place that may seen out of the ordinary)? If there were some standard on how DLLs should be loaded, that idea might have some merit. In real life, application developers can do whatever they want with their code; if this rule were to be applied, the analyst would be overloaded with spurious alerts. For example, we have seen security software injecting a DLL into every process and mapping random executables into the host process - from Windows’ perspective, this will look like the process is loading thousands of DLLs. As for the service DLLs, they blend in because all hosted services are loaded the exact same way. We often see legitimate svchost.exe processes loading DLLs from seemingly odd locations.
Clearly there is no “silver bullet” detection strategy for DLL hijacking or service DLL persistence. However it does not mean we should give up. We can instead approach the problem from multiple different angles. First, we can filter the events using heuristics learned from human analysis. The Veramine Detections wiki shows an example of a rules-based heuristic algorithm detecting an instance of DLL hijacking. Secondly, we can also apply machine learning models on the collected data. We will write more in a future blog post about our approach to profile known good behavior using ML techniques (as compared to detecting known bad).
The Case for Cyber CCTV
Third, we assume that all current detection techniques by humans and machines at some point will fail, and that we — and more importantly, our customers — will learn about a new malicious technique after-the-fact (via Wikileaks or otherwise). When that happens, we will want to retroactively apply this newfound knowledge to all previous events. At Veramine, we call this capability “time travel incident response.” And we feel like this capability will be the minimum baseline for the mature IR teams of the future. Time travel incident response is a core competency provided by the Veramine platform. We enable this scenario by structuring and storing all event data sent by the Veramine sensor to the Veramine server in such a way that it can be “replayed” to enable analysts to find something that may have been missed when processing events the first time. You can think of this like Cyber CCTV. Today’s Veramine customers will be able to replay today’s security-relevant raw events years in the future to detect the attack techniques revealed in the Great Wikileaks Dump of 2022, for example. Here are a few concrete examples of how this capability could be leveraged today.
First, suppose you read Symantec’s blog about the Vault 7 malware and learned that one of the backdoors used the service DLL as the primary persistence mechanism (“Graphics Utility Mgmt Service”). Naturally you want to know if this service ever existed anywhere on your network. The only way to answer this question is to look at the service instrumentation logs. The Veramine platform tracks all service creation and deletion events and conveniently stores them in a log file that can be replayed later. These logs are compact and can be stored indefinitely (limited only by disk space). Naturally, we also log all DLL load events so you can “go back in time” to investigate.
As a second example, let’s say you want to know if any of your file servers were attacked by the MS17–010 exploit in today’s “WannaCry” SMB ransomware attack. The successful exploit executes code in the svchost.exe context to perform the kind of post-exploitation techniques we already detect — registry-based Run key persistence, new scheduled tasks, file permission changes, vssadmin.exe usage, etc. These activities are described by Kaspersky and Payload Security. But successful exploits also install ransomware so detection is less useful when your files are all encrypted. It would be more interesting to find the unsuccessful attacks. Security researchers worldwide are busy investigating this attack right now and will be sharing its unique indicators over the next few hours and days. The Veramine sensor provides deep visibility into the SMB protocol and those events could be replayed to “go back in time” to evaluate SMB protocol message of the particular type to look for the indicators of this attack. With this visibility, we may be able to find the attack systems in an environment that is already fully-patched. A future blog entry will provide more details about the Veramine SMB protocol visibility and whether it could used to detect un-successful attacks such as this one.
Finally, you might like to investigate every instance of the icon overlay persistence mechanism described in the Wikileaks articles. The Veramine endpoint client sends interesting registry writes to enable detection, search, and response related to registry writes. One such algorithm we recently added highlights every new icon overlay. Using the TortoiseSVN from the Wikileaks article, we see the following detection result added:
The defender can click on the msiexec.exe hyperlink to see how the msiexec.exe (PID 5364) was launched that created this new icon overlay:
The same page also shows all the binaries loaded by this process. In this case, here were the four most recent:
Clicking on any of these binaries reveals this was likely a legitimate software install and not an APT implant to spy on us. For extra verification, one could click the Download link to get a copy of this binary. The Veramine platform saves a single copy of every binary loaded by any process across the corporate network. And, of course, we save these binaries forever (or as long as a self-hosted customer is willing to allocate storage space).
Service operations, DLL loads, and registry writes are only a few of the events we collect. In the future we will discuss other events we collect and how they can be used in daily “threat hunting”, IR, and forensic analysis operations.
This type of visibility is certainly achievable in a number of different ways and via a number of different tools and products. If you are interested in trying out our product, please reach out to us to request a free trial of the platform. You can send an email to contact@veramine.com or DM one of us on Twitter (where we lurk). We would be happy to send you a copy of the Veramine sensor to test the Veramine cloud-hosted offering or get you set up with a self-hosted single server evaluation on your own network. Our host-based sensor install is a single Windows binary pre-configured for a particular customer. To get started with the Veramine-hosted offering, you just run the single exe on as many hosts as you’d like visibility and then log into the Veramine portal with the credentials that correspond to that sensor. Or, if you’d prefer to evaluate the Veramine platform as a self-hosted option, that’s easy too. If you can allow inbound ssh, we will scp over the server-side installation package, deploy it for you, and send you the sensor with the crypto built-in that only your server can decrypt. Or you can download a pre-built VM image and run it using your existing infrastructure.
It’s still early days for Veramine as a company. We are excited about the initial response to the platform and the way customers are beginning to use it. We have exciting news coming in the weeks ahead, including innovative offerings by Veramine partners (*) that we never would have thought to build ourselves. We are eager to share more soon!
Bruce Dang and Jonathan Ness (Veramine)
(*) If you are a managed services provider or network-centric provider interested in consuming host-based data for any combination of collection, detection, search, discovery, or response, we want to talk with you. Our platform can provide exactly the type of Windows host-based data you want and deliver it to human or machine in exactly the format you want. We have built integrations so far for partners via AWS SQS, AWS Kinesis, AWS ElasticSearch Service, AWS S3 periodic upload, JSON over HTTPS, and a simple REST API.
