I saw a webcast done by Peter Ewane and Javvad Malik recently. The summary of what Peter had to say and Q&A follows; you can also view the recorded webcast.
What is Malware?
Malware can be a lot of things. It can be a virus, a worm, spyware, a Trojan horse, or ransomware. It’s basically any malicious program that you would not want on your computer.
Lately it has become common to see malware hide in the Windows Registry. Why the Windows registry? The Windows registry is quite large and complex, which means there many places where malware can insert itself to achieve persistence. A good example of this behavior is Poweliks. Poweliks sets a null entry utilizing one of the built-in Windows APIs, ZwSetValueKey, which allows it to create a registry key with an encoded data blob. I’m not sure why the Windows API allows a null entry, but it does. This is one of the many ways that malware can utilize the Windows registry to hide out, autostart, and maintain persistence on many systems.
Here’s an OTX pulse on Poweliks: https://otx.alienvault.com/browse/pulses/?q=POWELIKS
Process injection is exactly what it sounds like. It is injecting some bits of code into a running process. Malware leverages process injection techniques to hide code execution and avoid detection by utilizing known “good” processes such as svchost.exe or explorer.exe. To inject itself into known good processes, malware writers use built-in Windows APIs. One of them is setting debug. When a process sets as debug, it gains access to many of the debug API calls, such as attaching to other processes and instructing processes to allocate additional memory. Once a process has allocate more memory, then a malicious process can inject whatever code it wishes into that process.
A great example of malware that uses process injection is Poison Ivy. Poison Ivy's process injection is one of my favorites not only because it is very well known but also because it is used in many campaigns, and does process injection slightly differently than other kinds of malware. When malware allocates a chunk of memory, normally that chunk of memory is “contiguous”, so at the end of a memory block, it will allocate another memory block and inject code there. Poison Ivy does what we call “sharding.” Instead of having one giant memory block, it has a whole bunch of tiny memory blocks split all over the process and sometimes in various processes. A great example of malware that uses process injection is Poison Ivy. Poison Ivy's process injection is one of my favorites not only because it is very well known but also because it is used in many campaigns, and does process injection slightly differently than other kinds of malware. When malware allocates a chunk of memory, normally that chunk of memory is “contiguous”, so at the end of a memory block, it will allocate another memory block and inject code there.
Here’s an OTX pulse on Poison Ivy: https://otx.alienvault.com/browse/pulses/?q=poison%20ivy
Another technique related to process injection is process hollowing. ‘Hollowing’ is a process where you take a known good process and start it in a suspended state. When that code is loaded and about to execute, you scoop some of the good code out (like with an ice cream scoop). Now there is available space where a bad guy can place whatever code they like, maybe change a few headers on the top and bottom to make everything seem okay, and then restart the execution process. As far as a user knows, this process looks like a normal system process started by Windows. It is therefore much more difficult for reverse engineers and memory forensics people to analyze.
Dridex is a very good example of a malware family that often uses process hollowing. Here’s an OTX pulse on Dridex:
Process List Unlinking
Process List Unlinking is another key concept. A process is anything that is running on your computer, whether it be in user space or kernel space. Process List Unlinking involves a double-linked list that contains all “active” processes. It’s important because unlinking will result in a process being hidden from all “active” tools. This can be done using ZwSystemDebugControl() or by mapping DevicePhysicalMemory. Inside the process list is a list of every single process that is running and inside the process object is forward-pointed and backwards-pointed into the process in front of it or the process behind it to make a double-linked list.
A Flink to the process before it and then Blink to the one in front of it effectively removes the process from the list. More advanced malware will take this a step further and after they remove that process from the list, they will also write over that bit of memory, so even with memory forensics you wouldn't be able to locate that process.
There are tools that security researchers can use to find hidden malicious code, such as
- PsAc4veProcessHead traversal
- Pool tag scanning for processes
- Pool tag scanning for threads
This is an example bit of code that somebody would use to unlink from the process list.
DLL List Unlinking
Malware can also hide by manipulating the DLL list. Just like the process list, a DLL list has a double-linked list that points to the DLL in front and behind, and again just like the process lists are APIs that can be called to rewrite entries in the DLL list, remove that DLL entry and wipe out that bit of memory to help hide the malware from memory forensics or from backup tools. This is used a lot in rootkit activity. Here’s a graphic explaining DLL lists:
Here we have another example of code used to unlink from the DLL list:
You can see where it is writing over the one in front, the one behind, and then wiping out the memory and the zero memory function call. One other thing to remember about DLL and process list linking is that all that can be done from the user space, so I don't need kernel-level administrative rights.
Kernel Module List Unlinking
Kernel modules are the next level down. A kernel module is any of the modules that is loaded into the kernel. Like the DLL and process list, the kernel modules have their own list that can be queried with APIs and return every kernel module that is loaded. There are also debug APIs that can remove one DLL module from the list and zero it out. This is especially important because at the kernel level when something is zeroed out it makes it lot harder to find. This access is like ring zero access - definitely associated with rootkit activity. Generally, a piece of malware will execute in user space and then try a kernel-level exploit to get kernel administrative access; it then drops the main rootkit, which would then zero itself out inside the kernel module list process list. At this point, the malware is very well hidden and it will be very difficult to find.
How Kernel Module List Unlinking Works:
Questions from the Audience:
JAVVAD: So most malware sandboxes can’t deal with samples that remain dormant for a considerable amount of time before execution, such as Keranger. Have any new techniques been developed to overcome this?
PETER: Yes, there are a couple of different ways to overcome that. One way to tell malware remains dormant involves a certain amount system time. One way to manipulate that is to make the time go faster on the virtual machine, so every millisecond is actually ten minutes or every millisecond is actually five hours, defeating the dormant malware by waiting it out.
JAVVAD: How can AlienVault detect the malware hiding techniques that were described in the presentation?
PETER: Excellent question. One of the ways we can detect various hiding techniques described in the presentation, is based upon Windows logging. One example of such detection would be a processes acquiring the ability to utilize the built in Windows debug capabilities. There are known "Good" applications that use those functions, but outside of them it looks suspicious when other processes outside that circle utilize those debug capabilities which when then can alert on.
JAVVAD: Do you have anything to detect CryptoLocker or any other similar type family of ransomware?
PETER: Yes, we have correlation rules for CryptoLocker and various ransomware families.
JAVVAD: Is it anything specific that makes Ransomware different to look for compared to other sorts of malware, or is it pretty much the same techniques that you use?
PETER: These techniques are more about hiding. Ransomware generally is not very good at hiding, that is not its job. Its job is to be loud and in your face. So generally we can look for that being loud and in your face or any sort of network detector, so like it is connecting to known bad domains, etcetera.
JAVVAD: Is there a tool that can utilize OTX to scan a raw memory image file for IoCs?
PETER: What I would personally recommend is while you can't import memory images into OTX yet, you can use a tool such as Volatility to pull out IP and/or domains depending on what you want to scan, and then you can cross-reference with OTX based on the information that you pull up from the memory image.
JAVVAD: What is the general turnaround time between the AlienVault team capturing a sample of the zero-day attack and actually producing signatures?
PETER: That is hard to give an exact answer to because every bit of malware is different and every zero-day is different. Sometimes it can be a couple of hours, sometimes it may take longer than that.
JAVVAD: Yes. I will just add to that, actually. Last year, Adobe released a zero-day, and actually because the IoCs were being reused from previous campaigns, effectively we were blocking that zero-day three months prior to Adobe actually publicly announcing it. So it is not always the case that zero-days produce effects.
About Peter and Javvad
Peter Ewane is a security researcher at AlienVault. Follow him on Twitter https://twitter.com/eaterofpumpkin
Javvad Malik is the security advocate at AlienVault. Follow him on Twitter https://twitter.com/J4vv4D