Deploying detection solutions on an endpoint host comes with constraints – limited availability of CPU, memory, disk and other resources, stability constraints, policy adherence and restrictions, the need to be non-intrusive to the user, the host OS and other applications on the host.
In response to this, Juniper Threat Labs research presents HoneyProcs, a new deception methodology (patent pending) and an all user space method that extends existing deception honeypot technology on endpoint hosts. HoneyProcs complements existing deception technology by using forged, controlled decoy processes to catch info stealers, Banking Trojans, rootkits and other generic malware, and it does so by exploiting a common trait exhibited by these malwares – code injection.
By limiting its inspection footprint to only these decoy processes, HoneyProcs effectively addresses efficacy and performance concerns that otherwise constrain endpoint deployments. Throughout this article, we further explain how the reduced and targeted inspection footprint can be leveraged to turn HoneyProcs into an intelligence gathering toolkit that can be used to write automated signatures for other antivirus and detection solutions to remediate infections on the system.
Turning Malware Behavior Against Itself
A common trait shared by most malware is code injection – HoneyProcs exploits this trait and uses it to form the foundation of its detection methodology.
Malware injects code into other processes for the following reasons:
- Malware can inject its payload into an existing clean system process like svchost or explorer in order to avoid detection by solutions looking for suspicious process names.
- Malware can inject into explorer and task manager to create user mode rootkits in order to hide their artifacts, like their files and processes.
- Information stealers and banking malware inject into browsers in order to intercept and steal user credentials when they log into a website of interest.
While there are malware that spawn new processes and inject into them, the above mentioned categories of malware like info stealers, Banking Trojans, rootkits and some other generic malware inject their malicious code into existing, running benign processes without necessarily breaking their functionality.
Info Stealers
Malware that steals credentials and other important data from your computer are called info stealers. Info stealers can steal credentials from your social engineering sites and many of the info stealers, like Zeus, inject their malicious code into browsers. Keylogging can be considered one of the oldest methods for stealing data, so why is there a need to complicate the process by injecting code into browsers? There can be multiple reasons for this. One can be the introduction of virtual keyboards. By injecting code into browsers, malware can hook APIs that are responsible for sending and receiving HTTP(s) requests and responses. Malware would gain the capability to intercept, steal and manipulate the HTTP(s) requests and responses. This kind of attack is sometimes categorized as “man in the browser attack”.
Banking Trojans
Banking malware is a type of info stealer that has seen a rise of 50 percent in 2018. Banking trojans target stealing banking credentials. It can be done by installing keyloggers on a machine, stealing data from browsers or redirecting the victim to phishing sites. The most common technique used these days is stealing data from the browsers. This is done by injecting a malware module into the browser. The module is mostly used for API hooking, a technique that can manipulate the functionality of a legitimate API. As an example, one common API hooked by banking trojans is HttpSendRequest() from wininet.dll on a Windows machine. The API can be used by an application to send an http request to a server. After hooking the API, the malware can intercept the http requests sent from the browser to the banking site. The http request can contain username, password and other credentials. The hooked function can send the intercepted data to the attacker’s command and control server. This technique is called “form grabbing”.
Another popular technique used by banking malware is “web inject”. In this method, the injected malicious code in the browser modifies the response from a legitimate site. Most of the time, malware injects javascript code into the html page in the browser. And, note that there are no changes in the server code. The victim only sees a forged view of the original page.
Some famous banking trojans like zbot, spyeye, trickbot and kronos use web injects.
Rootkits
Rootkits are used to hide malware artifacts on the system such as files, process, network and registry entries on Windows. Rootkits can be both User mode and Kernel mode. User mode rootkits are usually created by API hooking while kernel mode is done by injecting kernel drivers that can hook kernel APIs/system calls or manipulate kernel data structures related to process, files and network.
A regular Windows user browses the file system using “explorer”. So, in order to hide its files, a malware injects code into explorer.exe process. FindFirstFile(), FindNextFile() are Windows APIs that are used to traverse the files. Malware can hook these APIs in explorer.exe process and manipulate the results returned by the APIs in order to hide their files.
Similarly, in order to hide a particular process in task manager, malware hooks Process32First and Process32Next in the Windows task manager process. So, a regular user who tries to view the list of running processes using task manager cannot locate the malware’s processes.
HoneyProcs – A New Dawn in Deception Technology for Endpoints
HoneyProcs is a new deception methodology that complements and extends existing honeypot technology on endpoint hosts. It works by exploiting a important trait of Banking Trojans and rootkits – code injection – and extends to all kinds of malware that inject into legitimate processes.
HoneyProcs works by using forged controlled decoy processes that mimic other legitimate processes that are usually targeted by aforementioned malware for injecting code. By controlling the state and properties of these decoy processes and using this fixed state as a baseline, and by monitoring for any changes to this state, we are able to effectively track the presence of infections on the system.
Our solution consist of two components: The Decoys and The Scanner.
The Decoys
To start, we have forged multiple programs whose processes are the usual targets of Banking Trojans and Rootkits – Chrome, Firefox, Internet Explorer, explorer and svchost.
Each of the forged programs has been developed to have its processes mimic and look similar to its corresponding original benign counterpart’s processes. Some of the methods used by HoneyProcs to mimic their corresponding benign counterparts include loading the same dependent libraries and using the same file size on disk, similar amount of memory, similar PE properties, a similar directory location on disk, the same working directory and the same number of threads, etc.
The screenshot below shows the loaded libraries for the benign processes on the left hand side and its corresponding HoneyProc decoy processes on the right hand side. As you can see, the loaded libraries are similar.
The forged processes have also been developed to go into a fixed, non-modifying state after starting up, which is either achieved by having the process go into a sleep loop or by carrying out some other NO-OP type of activity that keeps the threads running without leading to a change in the process state or properties. Each of these forged processes also don’t have a UI, so there are no chances for a regular user to interact with them and modify their state.
The forged processes have been created to handle all exceptions, in order to handle the scenario where the process might crash due to a faulty injection by a malware. While a crash of the decoy process can indicate the possibility of some meddling with the process, an exception handler can also aid in helping the scanner (explained in the next section) accurately figure out the presence of an injection and also extract other intelligence on the injection and the infection.
The Scanner
Post deploying the forged decoy processes and once they reach their steady state, the scanner process monitors these decoy processes. The scanner stores a baseline of the process state for each of these decoys. The baseline state stored includes a snapshot of the memory map including the size, properties, permissions of the memory pages, number of threads, etc. The properties can be expanded to include a hash of each page, but in light of keeping the scanning lightweight, it may not be necessary.
Post saving a baseline, the scanner continuously monitors these decoy processes, where periodically it snapshots the decoy processes’ properties and compares it to the baseline state it saved earlier at the start of the decoy process. If a change in state is noticed, it indicates a code injection from a malware infection on the system and generates an alert.
HoneyProcs: Case in Point
The screenshots below show HoneyProcs in action in combination with Feurboos trojan.
We have set up a decoy process mimicking the Chrome browser process. On the left hand side we show the memory map of the decoy process before injection. On the right hand side, we see the memory map post the malware’s code injection.
The malware starts up, goes through the list of currently running processes on the system until it finds the decoy process for “Chrome” and injects its code into it via a new memory block allocation at 0x1910000 with RWX(Read Write Execute) permission.
The scanner detects the injection and alerts with the MessageBox alert “INJECTION DETECTED”
Code injection remains a vital component for malware. Even more so for Banking Trojans, rootkits and certain categories of malware where code injection is the focal point of their functionality. Effective detection of such malware on endpoints is important while keeping the solution lightweight, efficient, non-intrusive and stable. On a deception front, although we do see solutions, the number of solutions that target endpoint host deployments are few.
HoneyProcs opens the door for a new deception technique that is lightweight, non-intrusive and efficient. It complements existing honeypot technologies and extends the detection net laid out by other solutions. Also being an all user space solution, it addresses stability and complexity issues that otherwise concern kernel based solutions.
Catching malware is a cat and mouse game and we do expect malware to get smart and add armoring against HoneyProcs on the system. Such armoring enhancements from malware have to be dealt with on a case by case basis. Some of our future research will focus on tackling possible armoring directions.
