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 \Device\PhysicalMemory. 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:
Original Post: https://www.alienvault.com/blogs/labs-research/malware-hiding-techniques-to-watch-for-alienvault-labs