Analyzing documents leaked from the Anonymous attack on HBGary sheds light on interesting technical aspects of rootkit development.
Numerous rootkit technologies are discussed, some of which might have never seen the light but could have well been developed by knowledgeable attackers.
They are designed to evade or bypass mainstream detection software and in some cases, circumvent protections thought to be unbreakable by design. Here is a list of the different rootkit technologies discussed and how we think they can be mitigated.
Hide in Plain Sight Rootkit
This basic rootkit detailed in a Feb 2010 email installs a driver on the target computer without hiding its files or registry entries. The reason being that hiding might raise suspicion by rootkit detection tools and personal firewalls.
By using a simple driver file named like a normal Windows file and by using legitimate API calls, this rootkit can effectively conceal its presence on the system and be very hard to locate for the untrained eye.
Mitigation: Since all the rootkit files are visible, it is possible to run the list of installed files against different data sources to confirm they are legitimate. Some of these sources are:
- Known Good Hash Databases: The NIST NSRL and Bit9 File Advisor online lookup service are good sources to help remove the noise created by known good entries and to help focus on unknown entries.
- Environment Correlation: By looking for the prevalence of a file within a given environment, unique files like those used in targeted attacks and by polymorphic malware can be quickly identified, especially in a homogeneous corporate environment.
- Code Signing Validation: Most major vendors "stamp" their release files with a code signing certificate so it is possible to validate the integrity of the files and their creator. Although this validation technique has its weaknesses, as shown by the Stuxnet worm that used a stolen certificate, it can be of great help when combined with other validation techniques.
The "Catch Me if You Can" Rootkit
Detailed extensively in the press under the names of "12 Monkeys" or "Magenta", this rootkit has the main characteristic of constantly moving in memory in order to make the analysis process harder for an investigator.
Also, it doesn't communicate through standard command and control (C&C) channels. Instead, it uses blended HTTP traffic disguised as ad clicks in order to ex-filtrate information and bypass network-based detection systems.
The rootkit gets its commands by scanning the system's memory, looking for byte patterns sent by the controller. These commands can be delivered in multiple ways that are not specifically described but can be assumed to be spam, web pages or network packets sent directly to the system.
Even when blocked by a firewall, they usually end up somewhere in the system's memory. It is not clear if development of this rootkit was completed or not.
Mitigation: Although moving the rootkit payload in memory might increase the analysis time in some cases, there are ways automated tools can use to mitigate this.
First, detecting a payload moving in memory should be in itself a good indicator of compromise and should prompt the system quarantine.
Second, an analysis tool could automatically capture the suspicious payload as it is detected and store it so it can be analyzed at a later time.
Third, by monitoring the memory allocations made within the kernel and the processes memory, it is possible to trace back the allocator of the memory block containing the moving payload. Having a kernel module allocating memory within a user-mode process is rather unusual and should be flagged as such.
In real life, this rootkit would also need to receive external payloads from the C&C. Simply moving in memory is not the ultimate goal and like most malware, this one would need more code running in order to capture keystrokes, screenshots or steal documents, enhancing the chances of detection.
This project packs two interesting components. The first one is a deployment tool using the target machine's Firewire port. It is used to inject code within the computer's memory while it is running and locked.
Another component of this project is the development of a loading mechanism that uses the MBR (Master Boot Record) or other pre-load functions like the BIOS. Using such a mechanism allows the rootkit to be loaded at boot time, before the OS, and doesn't require a permanent file on disk. This technique is already used by mainstream rootkits like Mebroot or TDL4.
Mitigation: Creating a MBR signature and comparing it to a baseline MBR can help in detecting some of these infections. As for the Firewire port, disabling or removing it is probably the best way to protect the computer against this attack.
The Air Gap Rootkit
This is certainly the most impressive rootkit description from HBGary. It is not clear if this was carried out but the mere thought that this could even exist should keep anyone responsible for securing highly sensitive networks from getting a wink of sleep.
In order to protect their network from Internet attacks, some organizations simply group their most strategic systems in a separate network and disconnect it from their Internet connected network, creating an "air gap" between them.
Each employee uses two computers (one connected to each network) and they manually transfer data from one system to the other by either retyping text, scanning images or in some cases, transferring data through USB sticks.
Although this protection can seem like a good idea at first, it is worth noting that attackers have quickly adapted. More than 25% of malware is now created to propagate through USB. The Stuxnet worm is the best example of such malware.
The neat thing with the HBGary "air gap" rootkit is that it is designed to bridge the two networks without having to go through an external media. Installed on computers in close proximity and connected on both networks, one system encodes data by generating high level frequencies that are captured by the other computer's microphone. This would allow attackers to ex-filtrate data from the secure network to the Internet.
Mitigation: Again, the best way to capture this kind of activity is through live memory analysis and behavior monitoring in order to find integrity violations of trusted processes or the Windows kernel. No matter how advanced the ex-filtration technique is, in the end, you have malware code running in memory and creating anomalies or behaviors that can be identified.
By combining these different approaches to zero-day exploits detailed in other emails, we can see that skilled attackers have the means to bypass most, if not all protection technologies currently available like antivirus, personal firewalls and network IDS.
Malware like this also renders disk encryption, DLP and SIEM solutions mostly irrelevant since it inherits the user's rights, credentials and blends within its activity.
Organizations must look at alternative detection technologies focused on large scale live memory and behavior analysis and develop the knowledge required to detect and block these advanced targeted threats.
Cross-posted from siliciumsecurity.com