This is the next post in our series on Hacking Team’s ‘Galileo Remote Control System’. In our previous posts we’ve been looking at the capability of the software suite, and using it in our lab to spy on test machines. This allows us to build a picture of what the attacker can do, and what their limitations are. In this post, we’ll be using that knowledge to detect the system installed on a Windows computer using the Volatility memory forensics framework.
If you’ve been following our previous posts, you’ll know that the Galileo RCS checks whether it’s running in a virtualised environment before running. This allows it to evade anti-virus scanning and malware analysis software. In our previous posts we covered patching the implants to run in a virtual lab environment, to allow us to use the software as an attacker would. Our target machine is a Windows XP computer, running service pack 2. As we’re running the implant in demo mode, we can see that the implant has initialised by the pop-up window that appears.
Demo popup
Can we find any other evidence of the implant on the target? By looking at the source, we know that the ’elite’ level implant is actually a DLL that is loaded at runtime by ‘rundll32.exe’, so we should be able to spot this in the Task Manager.
Task Manager running on compromised host
So there is no ‘rundll32.exe’ there, which is interesting. Also contained within the dump is a kernel rootkit for windows, named “DeepFreeze”, although it seems like this is not used in the latest version of the implant. This rootkit contains functionality for hiding processes, so it’s unlikely we’ll be able to spot anything on the compromised computer.
The next stage is to capture a RAM dump of the target machine. As this is a virtual machine (And we’re using VirtualBox), this is fairly easy to do using the debugging capabilities.
Random Access Memory (RAM) is the working memory of the system that is used by programs. It is considerably quicker to read from RAM than from the hard drive, so programs will copy themselves into RAM to speed up their execution. This means that when we take a copy of all of the RAM on a system while it is running, we have a copy of every program running on the system, as well as vital information about each program that is not available when it is shut down. From a malware analysis perspective, lots of families of malware will encrypt their files on the hard drive (to prevent analysis). However, these need to be decrypted in order to be used, and will therefore be present in RAM when the malware is running.
Our tool of choice for analysing the RAM of a system is the Volatility Framework. Written in Python, this allows us to extract useful information about the target system from a memory image.
The first thing we want to do is to list all of the processes on the system. As we believe there to be a rootkit on the system, we don’t trust the normal Windows APIs to give valid results. The Volatility ‘psxview’ module uses a number of different methods to determine which processes are running on a system, then correlates them to see if there are any discrepancies. So if our rootkit is hiding from some APIs and not others, then we should be able to detect it.
# volatility --profile=WinXPSP2x86 -f test.raw psxview
Volatility Foundation Volatility Framework 2.4
Offset(P) Name PID pslist psscan thrdproc pspcid csrss session deskthrd ExitTime
---------- -------------------- ------ ------ ------ -------- ------ ----- ------- -------- --------
0x06ba4500 NmspHost.exe 1900 True True True True True True True
0x06b6f180 IPROSetMonitor. 1864 True True True True True True True
0x06aeeda0 svchost.exe 1032 True True True True True True True
0x06a45b88 wmiprvse.exe 1596 True True True True True True True
0x06b70410 RSOBSERV.EXE 1812 True True True True True True True
0x069df960 RNADiagnosticsS 2012 True True True True True True True
0x06a04da0 RnaDirServer.ex 1708 True True True True True True True
0x06b775d0 RNADirMultiplex 2244 True True True True True True True
0x06a78798 wuauclt.exe 3416 True True True True True True True
0x06bec020 vmacthlp.exe 904 True True True True True True True
0x06b4c790 explorer.exe 2896 True True True True True True True
0x06bae928 winlogon.exe 676 True True True True True True True
0x06b4ada0 VBoxTray.exe 2992 True True True True True True True
0x06c33020 svchost.exe 1296 True True True True True True True
0x06b8a2c8 EventClientMult 1672 True True True True True True True
0x069e6da0 svchost.exe 940 True True True True True True True
0x06628a10 msmsgs.exe 3064 True True True True True True True
0x06aef7b8 UsbCipHelper.ex 2980 True True True True True True True
0x06baeda0 EventServer.exe 1796 True True True True True True True
0x06b259a0 lsass.exe 732 True True True True True True True
0x06b46c10 19pivy.exe 3016 True True True True True True True
0x06c57020 VBoxService.exe 884 True True True True True True True
0x069cb3c8 spoolsv.exe 1480 True True True True True True True
0x06b805d0 svchost.exe 1124 True True True True True True True
0x06bb4138 rundll32.exe 3072 True True True True True True True
0x06baa158 RsvcHost.exe 736 True True True True True True True
0x06c23460 svchost.exe 1180 True True True True True True True
0x06a08150 alg.exe 580 True True True True True True True
0x06a40020 iexplore.exe 3328 True True True True True True True
0x06a61868 RSLINX.EXE 2036 True True True True True True True
0x06b2e670 ctfmon.exe 3032 True True True True True True True
0x06cbf928 wscntfy.exe 2584 True True True True True True True
0x06b8f578 services.exe 720 True True True True True True True
0x06a7fda0 RdcyHost.exe 1936 True True True True True True True
0x06bed6c8 csrss.exe 652 True True True True False True True
0x06dc67c0 System 4 True True True True False False False
0x06c21528 smss.exe 588 True True True True False False False
So whilst there are some discrepancies, these are in system processes that behave differently. However, there are processes here that don’t appear in our task listings on the host. For instance, the ‘rundll32.exe’ is now visible, along with an ‘iexplore.exe’ that was previously not present. We can see which processes started other processes using the ‘pstree’ plugin.
# volatility --profile=WinXPSP2x86 -f test.raw pstree
Volatility Foundation Volatility Framework 2.4
Name Pid PPid Thds Hnds Time
------------------------------- ----- ------ ------ ------ ----
0x86d4c790:explorer.exe 2896 2868 14 298 2015-07-29 14:42:11 UTC+0000
. 0x86db4138:rundll32.exe 3072 2896 21 202 2015-07-29 14:42:12 UTC+0000
. 0x86c40020:iexplore.exe 3328 2896 3 89 2015-07-29 14:42:18 UTC+0000
. 0x86d4ada0:VBoxTray.exe 2992 2896 8 85 2015-07-29 14:42:12 UTC+0000
. 0x86d46c10:19pivy.exe 3016 2896 2 28 2015-07-29 14:42:12 UTC+0000
. 0x86d2e670:ctfmon.exe 3032 2896 2 68 2015-07-29 14:42:12 UTC+0000
. 0x86cef7b8:UsbCipHelper.ex 2980 2896 3 39 2015-07-29 14:42:12 UTC+0000
. 0x86828a10:msmsgs.exe 3064 2896 5 166 2015-07-29 14:42:12 UTC+0000
0x86fc67c0:System 4 0 61 1075 1970-01-01 00:00:00 UTC+0000
...SNIP...
So our ‘rundll32.exe’ was started by Explorer.exe. This process isn’t inherently malicious however, but merely loads a malicious Dynamic Link Library (DLL). We can find out what DLLs are loaded into a process using the ‘dlllist’ plugin, and we get one interesting result for PID 3072.
# volatility --profile=WinXPSP2x86 -f test.raw dlllist -p 3072
Volatility Foundation Volatility Framework 2.4
************************************************************************
rundll32.exe pid: 3072
Command line : "C:\WINDOWS\system32\rundll32.exe"
Service Pack 2
Base Size LoadCount Path
---------- ---------- ---------- ----
...SNIP...
0x01420000 0x34000 0x2 C:\DOCUME~1\ADMINI~1\LOCALS~1\MICROS~1\qjphWVcY\e_uC-RXA.sSK
...SNIP...
This DLL is obviously obfuscated, indicating that this is indeed the malicious process that we’ve been looking for. Digging further, we can identify handles that processes have open, as well as files that the executable is accessing. The most interesting handles for this DLL are shown below:
# volatility --profile=WinXPSP2x86 -f test.raw handles -p 3072
Volatility Foundation Volatility Framework 2.4
Offset(V) Pid Handle Access Type Details
---------- ------ ------ ---------- ---------- -------
...SNIP...
0xe1e3b570 3072 0x6c 0xf0007 Section 3OqZ1N5a
0xe1e78500 3072 0x70 0xf0007 Section 3OqZ1N5
...SNIP...
0x86c40020 3072 0xdc 0x1f0fff Process iexplore.exe(3328)
...SNIP...
0xe2546998 3072 0x384 0xf0007 Section DirectSound Administrator shared thread array
0x86de05b8 3072 0x388 0x1f0001 Mutant DirectSound Administrator capture focus array (lock)
0xe2612e90 3072 0x38c 0xf0007 Section DirectSound Administrator capture focus array
As we can see from this, the malicious DLL maps a shared memory section with a 7 or 8 character identifier. This shared memory is used by the implant to identify if there are other versions of the implant running on the same target. The ‘scout’ implant will not run on a target if there’s another ’elite’ implant detected by the ‘ExistsEliteSharedMemory’ function.
BOOL ExistsEliteSharedMemory()
{
HANDLE hMem;
PCHAR pName;
BOOL uRet = FALSE;
pName = GetEliteSharedMemoryName();
hMem = OpenFileMappingA(FILE_MAP_READ, FALSE, pName);
if (hMem)
{
uRet = TRUE;
CloseHandle(hMem);
}
free(pName);
return uRet;
}
With the shared memory section name generated by the function below:
PCHAR GetEliteSharedMemoryName()
{
PCHAR pName = (PCHAR)malloc(16);
memset(pName, 0x0, 16);
memcpy(pName, WMARKER, 7);
return pName;
}
Where ‘WMARKER’ is the implant watermark. Therefore the identifying feature of an ’elite’ infection is a shared memory section with the first seven characters of the watermark. As memory sections with names like this are relatively rare, we can use this as an Indicator of Compromise (IoC).
In addition, we also have a complete list of client watermarks from the ‘rcs-kill.rb’ script found in the previous post on the ‘Kill Switch’ embedded in the Galileo RCS. This means that we can match a shared memory section to a watermark, and therefore attribute the infection to a particular actor. Of course as the watermarks are all public knowledge now there exists the potential for ‘false flag’ operations - i.e. groups claiming to be a different group to avoid correct attribution of an attack.
However, the existance of these shared memory sections still serves as a useful indicator. We have therefore created a plugin for Volatility to detect the presence of these memory sections, and to attribute them using the list of watermarks. The module is shown in operation on our memory image here:
# volatility --plugins=volatility-attributeht --profile=WinXPSP2x86 -f test.raw attributeht
Volatility Foundation Volatility Framework 2.4
Hacking Team Galileo RCS Implant Detection - 4ARMED Ltd
PID Detected Watermark Process Name Implant Type Threat Actor
2584 3OqZ1N5a wscntfy.exe Elite/Soldier FAE-FURLAN
2584 3OqZ1N5 wscntfy.exe Elite/Soldier
2896 3OqZ1N5a explorer.exe Elite/Soldier FAE-FURLAN
2896 3OqZ1N5 explorer.exe Elite/Soldier
2980 3OqZ1N5a UsbCipHelper.ex Elite/Soldier FAE-FURLAN
2980 3OqZ1N5 UsbCipHelper.ex Elite/Soldier
2992 3OqZ1N5 VBoxTray.exe Elite/Soldier
2992 3OqZ1N5a VBoxTray.exe Elite/Soldier FAE-FURLAN
3016 3OqZ1N5 19pivy.exe Elite/Soldier
3016 3OqZ1N5a 19pivy.exe Elite/Soldier FAE-FURLAN
3032 3OqZ1N5a ctfmon.exe Elite/Soldier FAE-FURLAN
3032 3OqZ1N5 ctfmon.exe Elite/Soldier
3064 3OqZ1N5a msmsgs.exe Elite/Soldier FAE-FURLAN
3064 3OqZ1N5 msmsgs.exe Elite/Soldier
3072 3OqZ1N5a rundll32.exe Elite/Soldier FAE-FURLAN
3072 3OqZ1N5 rundll32.exe Elite/Soldier
3328 3OqZ1N5 iexplore.exe Elite/Soldier
3328 3OqZ1N5a iexplore.exe Elite/Soldier FAE-FURLAN
This also tells us that the DLL is injected into multiple processes, as it appears in perfectly legitimate processes (such as the Virtualbox guest additions ‘VBoxTray.exe’).
If you’d like to try the plugin, you can find it on our GitHub at https://github.com/4ARMED/volatility-attributeht.
It is very difficult to make a ‘catch-all’ tool to detect spyware of this calibre. For instnance, the ‘milano’ tool (https://www.rooksecurity.com/hacking-team-malware-detection-utility/) aims to identify a Hacking Team infection through hash and file signatures. Unfortunately spyware of this calibre evades host detection very easily as shown below, and this demonstrates the importance of memory forensics in the malware analyst’s toolset.
The ‘Milano’ tool run on our infected system, next to the implant Demo box.
Otherwise, if you’re concerned about the prevalence of the Galileo RCS then the best advice is to engage a professional security firm to conduct a thorough analysis.
