How Stealthy Malware Avoids Detection in Corporate Networks

Despite best efforts, enterprises remain a prime target for hackers, thanks to these techniques hackers are using to hide malware.

The Windows Registry is large and complex, leaving several places where malware can insert itself to remain undetected. A good example of this behavior is Poweliks. Poweliks sets a null entry utilizing the built-in Windows APIs, ZwSetValueKey, which allows it to create a registry key with an encoded data blob. This is one of the many ways malware can utilize the Windows Registry to hide out, autostart and maintain persistence on many systems.

Process injection is exactly what it sounds like; it injects 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 malware into known good processes, malware writers use built-in Windows APIs—for example, setting debug. When a process sets debug, it gains access to many of the debug API calls, such as attaching to other processes and instructing that process to allocate additional memory. After the process allocates more memory, the 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 inflicts damage by sharding, which is a type of database portioning. Imagine that instead of having one giant memory block, it has a number of tiny memory blocks split among various processes, which makes analyzing Poison Ivy more of a pain and reverse-engineering it more difficult and a much longer process.

Another technique related to process injection is called process hollowing. Hollowing is when a known, good process is started in a suspended state. When the code is loaded and preparing to execute, the good code is scooped out (think of an ice cream scoop) so there is space for the bad guys to input code of their choice and change headers on the top and bottom. This makes it appear as though the code is good and then the process is restarted. To the untrained eye, this appears to be a normal system process started by Windows. It is, therefore, more difficult for reverse-engineers and memory forensics people to analyze. Dridex is a good example of a malware family that often uses process hollowing.

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 manipulating the “process list,” which is a doubly linked list that contains all “active” processes. It’s important because unlinking will result in the process being hidden from all “active” tools. This can be done using ZwSystemDebugControl() or by mapping DevicePhysicalMemory.

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 write over that bit of memory, so that even with memory forensics investigators won’t be able to locate that process. There are tools security researchers use to find hidden malicious code, such as PsAc4veProcessHead traversal; Pool tag scanning for processes; and Pool tag scanning for threads?PspCidTable

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.

Kernel modules are the next level down. A kernel module includes any of the modules that are 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 kernel 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 a 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 and then drop 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.