Memory Forensics - Detecting Galileo RCS on Windows


Author Joe Greenwood

Date 6 August 2015

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 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 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. 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.

Share:

About The Author

Joe Greenwood

Security Consultant at 4ARMED. Specialising in Adversary Simulation and targeted attacks, I’m a CREST registered Penetration Tester who enjoys taking things apart. I also have experience in Incident Response, Digital Forensics, Malware analysis and ICS/SCADA technical assessments.


Related Articles