Detekt is a free tool that can detect sophisticated monitoring programs such as, FinFisher a.k.a FinSpy and Hacking Team RCS. This tool doesn't guarantee detection of all spyware, so don't consider this as an alternative to the anti-virus/anti-spyware software. I'm just hosting this on YouTube because their website is slow. Update: HT was hacked.
This is the next installment in our series on Hacking Team's 'Galileo' Remote Control System (RCS). After defeating the license restrictions, we're able to install the full backend system, and operate it as if we were a HackingTeam customer. (See my post Here for details).
As covered previously on this blog, there are a number of elements to a deployment of the 'Galileo RCS'.
RCS Architecture from the leaked Sysadmin manual
The main element is the master node, which stores evidence in a MongoDB instance, and handles agent deployments and building. The 'Collector' node is the interface between the master node and the chain of 'Anonymizers' that lead to the agent itself. The anonymisers create a chain of connections, obfuscating the location and identity of the final Collector node.
The anonymiser essentially acts as an HTTP proxy, and runs on CentOS. We can therefore setup a virtual machine in our Galileo Lab and provision it as an Anonymiser.
Galileo RCS Lab
To provision the Anonymiser, we create a new anonymiser on the console, then export the installer. This creates a zip file which we copy to the CentOS instance. After un-zipping it, we have an 'install' file, which we can run with:
We then need to either disable the default iptables firewall, or create an exception. As this is just in my lab, I ran:
Once we've done this, we then go back to our console and drag the Anonymiser onto the Collector to create a chain. Clicking 'Apply Configuration' then pushes this to the collector and the anonymiser, setting up the chain.
Completed anonymiser chain
Rcs Hacking Team Download Windows 10
So we now have our infrastructure setup, but we won't be able to run the implants in their current form on virtual machines. As mentioned previously, all of the implants have an 'AntiVM' function which checks to see if the implant is virtualised, and exits if it is.
When we were compiling from source, we could just comment out this check, but the leaked source code is only for version 9.2 of the software. We'd like to use version 9.6 to explore any new features added. Therefore we need to patch the windows agents in use.
The first stage is identifying where the base executables that the backend uses are located. When the system is installed, the 'cores' are extracted to 'C:RCSDBcores'. Each of these is a zip file containing the base images for all of the various agents.
Compressed agent cores
When the master node starts it checks to see if there are any files in this directory, and loads them into the MongoDB database if so. Therefore if we want to update the windows core, we need to create a new 'windows.zip' containing our patched agents that will run inside VMs, and then load them into the master node.
The 'windows.zip' has the following contents:
It looks like 'scout' and 'soldier' are the two base images that we want to patch.
We have the source code for the 'AntiVM()' function, but we need to find what it looks like in the compiled code. Starting with the scout agent, we can open it up in IDA (A reverse engineering tool) and find the code segments that correspond to the AntiVM code.
The 'AntiVBox' and 'AntiVMware' functions both use WMI queries in order to identify a virtual environment. These queries use the 'CoCreateInstance', 'CoInitialise' and 'CoSetProxyBlanket' functions from the Windows API.
In addition, we have these string arrays containing the actual queries to be run; The 'AntiVMWare' query is: 'SELECT * FROM Win32_Bios', and the 'AntiVBox' query is: 'SELECT * FROM Win32_PnPEntity'. These aren't stored as strings though, but as character arrays, which makes it slightly harder to locate them in IDA.
However, we can still narrow it down, and eventually find the code segments that load and execute these queries
Anti VirtualBox WMI Query
Tracing backwards, this allows us to identify the whole 'AntiVM' function:
'AntiVM()' function
Rcs Hacking Team Download Free
So if virtualisation is detected, then the value of EAX is set to 1, otherwise it's set to zero (XOR-ing anything with itself results in zero).
It's now fairly trivial to locate the specific assembly instruction 'mov eax, 1' and patch it instead to be 'mov eax, 0', so that the function always returns zero.
Patched AntiVM function in Immunity Debugger
So we've now patched the scout implant (finally...), but what about the next level up?
The 'Soldier' agent actually shares the same code as the scout to detect virtual environments. The compiled code is slightly different however, probably due to a compiler optimisation.
'Soldier' Implant AntiVM function
.
Whereas the scout sets EAX to 1 using 'mov eax, 1', the soldier instead sets EAX to zero, then increments it by one ('INC EAX'). Regardless, we can still patch the function to always return zero by replacing the 'INC EAX' with a 'NOP' (No-operation) instruction. This does nothing, and leaves EAX set to zero.
'INC EAX' instruction to be patched to NOPs in Soldier implant AntiVM() function
.
Now we need to load these updated agents into the database. We copy our updated 'scout' and 'soldier' files into 'windows.zip', then copy that into 'C:RCSDBcores'. Lo and behold, the next time the database starts our updated core is loaded:
2015-07-20 12:26:49 +0100 [INFO]: Loading cores into db...
2015-07-20 12:26:49 +0100 [INFO]: Loading core: windows...
2015-07-20 12:26:49 +0100 [INFO]: Load core: 'windows' | version 2015032101 | sha1 1daaeece8c9a7c624b9f26147562b052fb691e44
So after all of that work, we should be able to run an agent on a virtual machine to try out its features. We first create an 'Operation' that will contain all of our targets.
Operations Page
We then create a 'Factory' to build our agents. This allows us to configure what features we want enabled, as well as the frequency of call-backs.
Configuration options within an agent factory
Rcs Hacking Team Download Pc
Once we've decided on our configuration, we then click 'Build' and are presented by this mildly amusing pop-up:
I think they might have bigger problems now...
Clicking on, we get to choose what the infection vector will be (i.e. how the agent will be executed). Each of these vectors is a post on its own, so for the moment we're just going to generate an executable to be run by the victim (i.e. Us).
Selection of infection vector
Clicking 'create' gives us an executable on our local machine under 'RCS Downloads'.
We can then copy this to our target machine and run it, installing the implant. As mentioned previously, the 'scout' implant (which this agent is) sends back device information and screenshots so that the operator can determine if the target is valid or not. When the implant calls home, a new 'target' is created in the operation, allowing viewing of evidence obtained from that agent. After we've decided that the target is valid, we can upgrade the agent to allow collection of much more data.
Rcs Hacking Team Download
All of the evidence is displayed in an easy-to-view format. Some examples of evidence are shown below, including keystroke logs and device information.
Keystroke logging
Gathered Device Information
Another interesting feature is Optical Character Recognition (OCR). This aims to recognise text in images and convert it into actual text. This feature allows recognition of text in screenshots. This is also coupled with a translation feature, allowing the translation of text in screenshots.
Captured Screenshot
OCR of previous screenshot
So to wrap up, we've managed to deploy an operational infrastructure, patch the implants so they'll run in our virtual lab and finally run a mock operation on our 'targets' and gathered intelligence. Using all of this information, we can start to put together a picture of what an attack using this toolset would look like, and how we could defend against it.
In future, we're going to look in more depth at the persistence mechanisms available in the platform, as well as what 'backdoors' Hacking Team may have included to monitor their client's activities.