Government Grade Malware: a Look at HackingTeam ’s RAT
Government Grade Malware: a Look at HackingTeam’s RAT
“On the fifth day of Christmas Bromium sent to me a malware analysis B-L-O-G” – You
This is a very interesting situation we’ve found ourselves in. We have our hands on the code repositories of HackingTeam, and inside of them we’ve found the source code for a cross-platform, highly-featured, government-grade RAT (Remote Access Trojan). It’s rare that we get to do analysis of complex malware at the source-code level, so I couldn’t wait to write a blog about it!
The first thing I noticed when I dove into the repositories was a bunch of projects for “RCS Agents”, and each of these agents seems to be a malware core for the HackingTeam RAT called Remote Control System, or RCS.
Each of the cores is made for a different OS and, together, they comprise a multi-platform malware that works on Windows, Windows Phone, Windows Mobile, Mac OSX, iOS, Linux, Android, BlackBerry OS, and Symbian. In this blog, I’ll cover the core-win32 repository, but you can assume that the functionality in the Windows agent is present on every other platform.
The code in this repository makes up a 32-bit DLL that is injected system-wide on Windows, enabling the malware to exist in the process space of many potential target applications. There’s also a core-win64 repository that contains the tools to compile this DLL for 64-bit systems.
When the DLL is injected into a process, it will unlink itself from the PEB (Process Environment Block) module list and start an IPC channel to communicate with other instances of the malware and, ultimately, to a root instance that is responsible for talking to the C&C server.
RCS contains dozens of run-of-the-mill spying tools, similar to the ones found in tools like Blackshades and DarkComet. Here’s a look at the source code:
From a quick glance, we can see a number of ‘interesting’ tools:
- HM_Pstorage.h and HM_PWDAgent (folder): grabs stored passwords from Firefox, Internet Explorer, Opera, Chrome, Thunderbird, Outlook, MSN Messenger, Paltalk, Gtalk, and Trillian.
- HM_IMAgent.h and HM_IMAgent (folder): records conversations from Skype, Yahoo IM (versions 7 through 10), MSN Messenger (versions 2009 through 2011, now discontinued), and ICQ (version 7 only).
- HM_SocialAgent.h and Social (folder): grabs session cookies for Gmail, Facebook, Yahoo Mail, Outlook (web client), and Twitter from Firefox, Chrome, and IE.
- HM_MailCap.h, HM_Contacts.h, HM_MailAgent (folder) and HM_ContactAgent (folder): captures emails and contacts from Outlook and Windows Live Mail.
- HM_AmbMic.h and HM_MicAgent (folder): records ambient noise picked up by any attached microphones.
- wcam_grab.h and wcam_grab.cpp: periodically snap and save photos from attached webcam.
- HM_Clipboard.h: grabs any data that is stored on the clipboard.
- HM_KeyLog.h: logs all keystrokes.
- HM_MouseLoh.h: logs all mouse movements and clicks.
- HM_UrlLog.h: records visited URLs in Firefox, Chrome, IE, and Opera.
There’s nothing really novel in the code, and the methods mostly utilize standard API calls. This functionality is pretty common in most RATs, but we should consider that most of these files were checked into the repository as early as 2011, meaning RCS may have pioneered some of these features.
Some closer analysis of the code reveals that RCS does have some rarer features, though. In HM_SkypeRecord.h and HM_SkypeACL (folder), for instance, we can see that they use the DirectSound API to capture active Skype calls and save the audio using the Speex codec.
Additionally, we see that RCS can monitor printed documents (HM_PrintPool.h) and even grab private keys, balances, and transactions from Bitcoin, Litecoin, Feathercoin, and Namecoin wallets (HM_Money.h).
RCS uses the WLAN (wireless LAN) API functions from WLANAPI.DLL to enumerate nearby WiFi hotspots. Many hotspots expose geolocation information and RCS looks for this information so it can determine where the infected machine is, even when it is hiding behind a VPN or proxy.
Since HackingTeam seems to have a stockpile of 0days for lateral movement, you would think RCS wouldn’t employ any features with that specific purpose. You’d be wrong, though. They seem to have an infector that can infect USB drives, phones running Windows Mobile, and VMWare disks. This infector is located in HM_PDAAgent.h.
The USB infector is pretty standard. RCS polls for new USB drives, drops an installer on them, and infects the autorun.inf file to run that installer.
The Windows Mobile infector works in much the same way, copying the malware from the core-winmobile repository to the phone as a file called autorun.exe. Afterwards, it drops an infected autorun.zoo file on the phone. All of this is done using functions from the standard Windows Phone API, RAPI.DLL.
The VMWare installer is a bit trickier. First, it will search for any VMWare disks (.vmdk) that aren’t in use. When it finds one, it will mount it to an open drive letter and then drop a RCS installer in either C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\ (Windows 7 and above) or C:\Documents and Settings\All Users\Start Menu\Programs\Startup\ (Windows XP). This code is a bit too bulky to post, but it starts on line 731 of HM_PDAAgent.h, in case you get your hands on the code and want to take a look.
RCS has a myriad of self-protection mechanisms, including AV detection, API call obfuscation, and API hook evasion. For starters, the AV detection is capable of detecting twenty-six different AV tools. Here’s a snippet from av_detect.h:
RCS detects these AVs either by looking for their drivers or checking the environment for certain variables. It’s smart enough to know which of its features will trigger alerts with which AVs, and will selectively disable features to remain hidden.
The malware also uses obfuscated API calls to prevent any form of static analysis from understanding what it is doing. In the file DynamiCall\obfuscated_calls.h, the malware has encoded strings that represent DLL names and API function names that it calls.
From there, DynamiCall\dynamic_import.h and DynamiCall\dynamic_import.cpp take care of decoding the strings, loading the DLLs, and resolving the addresses of the functions. Additionally, RCS has a set of API functions that it will only call if it can confirm that they aren’t being monitored: ReadProcessMemory, WriteProcessMemory, CreateRemoteThread, CreateThread, GetProcAddress, VirtualAllocEx, GetWindowText, SendMessageTimeout, and VirtualProtectEx. Every time one of these functions is called, RCS will grab the DLL that contains the function, manual-map it into memory, locate the target function in the manually-mapped library, and copy the first five bytes from the manually-mapped library over the first five bytes of the function in the actual library. If any step in this process fails, the malware will not call the function. The code that does this is pretty bulky, but you can find it in HM_SafeProcedures.h, HM_SafeProcedures.cpp, HM_PreamblePatch.h, and HM_PreamblePatch.cpp.
One of the most telling pieces of code in the malware, though, is an unfinished snippet starting on line 48 of format_resistant.cpp, which suggests the team was developing a way for RCS to persist through UEFI infection. Though the code is unfinished, it is telling of their future ambitions.
Note: Other repositories also contain some kernel-mode rootkits to hide the malware, but this blog is already getting pretty beefy.
HackingTeam’s RCS is a fully-featured RAT with the ability to intercept large amounts of personal information, record conversations, access cameras, propagate to peripheral devices, and do it all without triggering any alarms. The source-code shows that the malware was developed by a very ambitious team, and the repository logs make it clear that it was under active development. The implications this carries are huge, especially considering HackingTeam’s customer list.