303 – Memory Analysis of an Infected HMI
Objectives
- Demonstrate Skills Related to Identifying Malware in a Memory Image of an Infected HMI.
Background: For this challenge you will use the memory image provided identified as “Infected-Memory-Image”. Note that there is real malware inside the memory image. It cannot infect your system as it is however if you carve out the malware and execute it on your system it will infect it. This takes work to do and thus without intentionally performing these steps you run no risk of being infected.
Often, incident response in ICS requires lightweight acquisition, such as acquiring memory vs. the entire disk, and requires timely analysis of Windows control systems such as an HMI. Using any memory analysis tools you would like analyze the image and answer the questions below.
Questions
- What is the IP address of the system?
- When was the digital acquisition performed?
- What malicious process was running on the system at the time of acquisition?
- (Open-ended) What other interesting activity can be observed on the image?
Answers
- The IP Address of the system is: 172.16.192.200.
- The digital acquisition was performed on 1-23-2015 at 01:25:34 AM UTC.
- The malicious process that was running on the system at the time of acquisition was bddd4e2b84fa2ad61eb065e7797270ff.exe with a PID of 1976
- There are some ICS protocols in the netscan, namely Ethernet/IP on port 44818, and Modbus on port 502. A process called “Runtime.exe” with a PID of 1476 established a connection from the local machine to another machine using the Modbus protocol.
The machine being analyzed is a Virtual Machine. VMWare tools was installed on it. It also has VMWare drivers.
I found an interesting plugin called, “ethscan” that produced a pcap of potential traffic between this machine and other machines. I’ve read that it can have a lot of false positives. This particular network was made up of 4 Raspberry devices, 1 ASUS, and one Virtual Machine. It looks as though one of the Raspberry devices was configured to pretend to be a traffic control light. I saw it mentioned in the “shellbags” plugin.
Registry: \??\C:\Users\Robert Lee\AppData\Local\Microsoft\Windows\UsrClass.dat
Key: Local Settings\Software\Microsoft\Windows\Shell\BagMRU\2\0\0
Last updated: 2015-01-22 18:15:01 UTC+0000
Value Mru File Name Modified Date Create Date Access Date File Attr Path
------- ----- -------------- ------------------------------ ------------------------------ ------------------------------ ------------------------- ----
0 0 CYBATI~1 2015-01-22 13:01:24 UTC+0000 2015-01-22 13:01:24 UTC+0000 2015-01-22 13:01:24 UTC+0000 DIR Users\CYBATI\Desktop\CybatiWorks_RASPI_5_TrafficLight
I was warned that this image has malware on it that could infect my machine if I’m not careful. I went ahead and extracted the files using the “dumpfiles” plugin. I made sure that I didn’t open anything. I was also on a VM without VMWare tools installed, and no Internet Connection. I had the network interface disabled. I made a snapshot to return to the previous settings, just in case. The risk was worth it in my estimation. In one of the PID 1976 files, which is the malicious process, I found this: (I cut the output that wasn’t interesting to me.) *I don't know what normal is. This looked odd to me at the time. I've since learned that some processes can have this in them.*
strings file.1976.0xfffffa801a04f1c0
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="asInvoker" uiAccess="false"></requestedExecutionLevel>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>PAPADDINGXXPADDINGPADDINGXXPADDINGPADDINGXXPADDINGPADDINGXXPADDINGPADDINGXXPAD
This looks suspicious to me, especially considering that Havex is known to use xml. I uploaded the file to Virus Total, and it indicated that it is a trojan. Nano Antivirus: Trojan.Win32.Havex.dyufsj , Kaspersky: Trojan-Spy.Win32.HavexNetscan.b
It looks like the virtual machine may have been infected with the Simda A Rootkit. I checked some names of drivers because I’m not familiar with most of them, and Virus Total showed that this driver, Wdf01000.sys, may indicate the presence of a rootkit.
https://www.virustotal.com/en/file/aed8575924b627281fee830a078399ed41550434cae4fd72d763324b871c88ee/analysis/
I also followed the directions from the SANS forensics poster about how to detect a rootkit, and I’m not certain, but I think that it indicated that there is a rootkit on the image.
vol.py -f Infected-Memory-Image --profile=Win7SP0x64 ssdt | egrep -v 'ntosk|win32k'
Volatility Foundation Volatility Framework 2.4
[x64] Gathering all referenced SSDTs from KeAddSystemServiceTable...
Finding appropriate address space for tables...
SSDT[0] at fffff800028cf300 with 401 entries
SSDT[1] at fffff96000151f00 with 827 entries
I looked for hooked SSDT functions.
vol.py --profile=Win7SP0x64 -f Infected-Memory-Image driverirp --regex=tcpip | grep IRP | egrep -vi '(tcip|ntos)'
Volatility Foundation Volatility Framework 2.4
0 IRP_MJ_CREATE 0xfffff880019de070 tcpip.sys
2 IRP_MJ_CLOSE 0xfffff880019de070 tcpip.sys
14 IRP_MJ_DEVICE_CONTROL 0xfffff88001917fd0 tcpip.sys
15 IRP_MJ_INTERNAL_DEVICE_CONTROL 0xfffff880019de070 tcpip.sys
18 IRP_MJ_CLEANUP 0xfffff880019de070 tcpip.sys
0 IRP_MJ_CREATE 0xfffff880019de070 tcpip.sys
2 IRP_MJ_CLOSE 0xfffff880019de070 tcpip.sys
14 IRP_MJ_DEVICE_CONTROL 0xfffff88001917fd0 tcpip.sys
15 IRP_MJ_INTERNAL_DEVICE_CONTROL 0xfffff880019de070 tcpip.sys
18 IRP_MJ_CLEANUP 0xfffff880019de070 tcpip.sys
0 IRP_MJ_CREATE 0xfffff880019de070 tcpip.sys
2 IRP_MJ_CLOSE 0xfffff880019de070 tcpip.sys
14 IRP_MJ_DEVICE_CONTROL 0xfffff88001917fd0 tcpip.sys
15 IRP_MJ_INTERNAL_DEVICE_CONTROL 0xfffff880019de070 tcpip.sys
18 IRP_MJ_CLEANUP 0xfffff880019de070 tcpip.sys
0 IRP_MJ_CREATE 0xfffff880019de070 tcpip.sys
2 IRP_MJ_CLOSE 0xfffff880019de070 tcpip.sys
14 IRP_MJ_DEVICE_CONTROL 0xfffff88001917fd0 tcpip.sys
15 IRP_MJ_INTERNAL_DEVICE_CONTROL 0xfffff880019de070 tcpip.sys
18 IRP_MJ_CLEANUP 0xfffff880019de070 tcpip.sys
0 IRP_MJ_CREATE 0xfffff880019de070 tcpip.sys
2 IRP_MJ_CLOSE 0xfffff880019de070 tcpip.sys
14 IRP_MJ_DEVICE_CONTROL 0xfffff88001917fd0 tcpip.sys
15 IRP_MJ_INTERNAL_DEVICE_CONTROL 0xfffff880019de070 tcpip.sys
18 IRP_MJ_CLEANUP 0xfffff880019de070 tcpip.sys
I’m wondering if the host machine was infected as well as the guest. A couple of the dlls, dnsapi.dll and RPCRT4.dll, associated with the malicious Havex process was doing something with the vmtoolsd.exe PID 1244. The malicious process may have just been checking for the presence of a VM. Some are programmed not to run if they encounter a VM. Other malicious processes are programmed to do some nasty things. The ethscan traffic showed an Asus computer, which could be the host. So, if the host and guest were running in bridged mode, it’s possible, although unlikely, for the host to be infected as well as the guest. I unfortunately, don’t know what to look for for proof of that.
The “uninstallinfo” plugin text file that I made showed a bunch of unicode characters when opened with gedit. Most of them were Chinese characters. I used the terminal to try to read the same file, and this is what printed on the screen. If you look closely, you can see that some files were reported to have been removed on 7-14-2009. I think that the removed files were from the Havex malware trying to keep itself from being detected. Malware puts false dates on creation and removal to hinder analysis. The same dates are on the registry keys created by the malware, and the autoruns created by the malware.
cat uninstallinfo.txt
Legend: (S) = Stable (V) = Volatile
----------------------------
Registry: \SystemRoot\System32\Config\SOFTWARE
Key name: Uninstall (S)
Last updated: 2015-01-22 13:03:30 UTC+0000
Subkeys:
Subkey: AddressBook
LastUpdated : 2009-07-14 04:58:36 UTC+0000
Subkey: Connection Manager
LastUpdated : 2009-07-14 04:58:36 UTC+0000
Subkey: Fontcore
LastUpdated : 2009-07-14 04:58:36 UTC+0000
Subkey: IE40
LastUpdated : 2009-07-14 04:58:36 UTC+0000
Subkey: IE4Data
LastUpdated : 2009-07-14 04:58:36 UTC+0000
Subkey: IE5BAKEX
LastUpdated : 2009-07-14 04:58:36 UTC+0000
Subkey: IEData
LastUpdated : 2009-07-14 04:58:36 UTC+0000
Subkey: MobileOptionPack
LastUpdated : 2009-07-14 04:58:36 UTC+0000
Subkey: SchedulingAgent
LastUpdated : 2009-07-14 04:58:36 UTC+0000
Subkey: WIC
LastUpdated : 2009-07-14 04:58:36 UTC+0000
I searched for any DNS entries using the “yarascan” plugin
vol.py -f Infected-Memory-Image --profile=Win7SP0x64 --output-file=www.txt yarascan -Y “/[a-zA-Z0-9\-\.]+\.(com|org|net|mil|edu|biz|name|info)/"
It found some adult websites in the search. I’m assuming that this machine may have a Porn Dialer, or had one at one time. *I later found out that antivirus software can bring up false results with yarascan.*
I found the mutexes described below in the Infected memory image.
3a886eb8-fe40-4d0a-b78b-9e0bcb683fb7 that is associated with a backdoor: Backdoor:MSIL/Bladabindi.BH. It’s supposed to be a Flash Player exploit, but I can’t find the files associated with it. Other scanners call it a trojan.
This mutex: !PrivacIE!SharedMemory!Mutex is associated with a trojan.
This mutex: {A3BD3259-3E4F-428a-84C8-F0463A9D3EB5} has a password stealing trojan associated with it. It is an e-mail worm. Interestingly, it goes to the baidu.com domain, which was in the yarascan plugin when I scanned for urls.
Owner: Process svchost.exe Pid 1656
0x027837b0 77 77 77 2e 62 61 69 64 75 2e 63 6f 6d 00 00 00 www.baidu.com
It’s interesting because the infected image also contains mutexes that are similar to Zeus.
Zeus Mutexes
_!MSFTHISTORY!_
c:!documents and settings!user!local settings!temporary internet files!content.ie5!
c:!documents and settings!user!cookies!
c:!documents and settings!user!local settings!history!history.ie5!
WininetStartupMutex
WininetConnectionMutex
WininetProxyRegistryMutex
Infected Machine Mutexes Similar to Zeus
_!MSFTHISTORY!_
c:!users!robert lee!appdata!local!microsoft!windows!temporary internet files!content.ie5!
c:!users!robert lee!appdata!roaming!microsoft!windows!cookies!
c:!users!robert lee!appdata!local!microsoft!windows!history!history.ie5!
WininetStartupMutex
WininetConnectionMutex
WininetProxyRegistryMutex
I also found these mutexes that were associated with a Zeus-bot infection according to VirusTotal.
MSDTC_Perf_Library_Lock_PID_4dc
MSDTC Bridge 3.0.0.0_Perf_Library_Lock_PID_4dc
PerfDisk_Perf_Library_Lock_PID_4dc
PerfNet_Perf_Library_Lock_PID_4dc
PerfOS_Perf_Library_Lock_PID_4dc
PerfProc_Perf_Library_Lock_PID_4dc
RemoteAccess_Perf_Library_Lock_PID_4dc
ServiceModelEndpoint 3.0.0.0_Perf_Library_Lock_PID_4dc
ServiceModelOperation 3.0.0.0_Perf_Library_Lock_PID_4dc
ServiceModelService 3.0.0.0_Perf_Library_Lock_PID_4dc
SMSvcHost 3.0.0.0_Perf_Library_Lock_PID_4dc
Spooler_Perf_Library_Lock_PID_4dc
TapiSrv_Perf_Library_Lock_PID_4dc
Tcpip_Perf_Library_Lock_PID_4dc
TermService_Perf_Library_Lock_PID_4dc
Windows Workflow Foundation 3.0.0.0_Perf_Library_Lock_PID_4dc
WmiApRpl_Perf_Library_Lock_PID_4dc
This mutex: RasPbFile, is associated with “SpyEye”. SpyEye is the Zeus competitor that is rumored to have purchased Zeus.
Walkthrough (Show How You Got Your Answers)
https://isc.sans.edu/forums/diary/Suspect+Sendori+software/16466
I used volatility on a SIFT VM to analyze the Infected-Memory-Image image. This was the first time that I have ever used Volatility. The only reason that I was aware of its existence was because I’d read about it on the SANS blog, and I have a SIFT VM. I Googled how to use it and looked at the help options.
vol.py -h
The first plugin that I ran was to determine what profile to use.
vol.py -f Infected-Memory-Image image info
It actually output a few profiles. I decided to try Win7SP0x64. It worked.
I also tried to use the kdbgscan plugin to determine what profile to use, but it showed a lot of different profiles. I found out that it was because there were some VMWare drivers and tools installed that might trip up the kdbgscan plugin, for instance, “VMWare Vista Physical Disk Helper”
I then made .txt files of any Volatility plugin scans that I thought might be useful. Specifically: apihooks, apihooksdeep, atoms, auditpol, autoruns, bioskbd, cmdline, cmdscan, consoles, driverbl, driverirp, dumpcerts, envars, filescan, getservicesids, getsids, hashdump, hivelist, kdbgscan, malfind, malprocfind, malsysproc, mimikatz, mutantscan, netscan, printkey, privs, pslist, pscan, pstree, psxview, services, sessions, shellbags, ssdt, timeliner, timers, truecryptsummary, trust records, uninstallinfo, userhandles, usn, wintree, wndscan, yarascan.
vol.py - -profile=Win7SP0x64 -f Infected-Memory-Image -output-file=<plugin>.txt <plugin> <options>
- I found the IP by using the “netscan” Volatility plugin.
vol.py --profile=Win7SP0x64 --output-file=netscan.txt -f Infected-Memory-Image netscan
The IP Address is 172.16.192.200. There is a link local ipv6 address of fe80::6090:beb3:9385:1c79, but I’m not certain that you were looking for that.
Offset(P) Proto Local Address Foreign Address State Pid Owner Created
0x3d89d350 TCPv4 172.16.192.200:139 0.0.0.0:0 LISTENING 4 System
0x48fb3c70 UDPv6 fe80::6090:beb3:9385:1c79:1900 *:* 2688 svchost.exe 2015-01-22 18:16:16 UTC+0000
2. When I did the “imageinfo” plugin, it showed the date and time of the image acquisition. That was confirmed later, when I used the “consoles” plugin.
vol.py --profile=Win7SP0x64 --output-file=consoles.txt -f Infected-Memory-Image consoles
When I looked at the consoles command, I noticed that the Red Line software had been used to analyze the image. So, I looked up the user manual for Red Line so that I could see how a memory acquisition date could be found. It looks like the memory acquisition was imported utilizing Memorize as evidenced by finding the “Red Line” path in the consoles.txt file. In the consoles.txt, it states that that audit started on 1-22-2015 at 19:25:34 EST. However, Memorize saves the folder in a date/time format, showing that the acquisition started on 1-23-2015 at 01:25:34 AM UTC. 1-22-2015 at 19:25:34 EST is the same time as 1-23-2015 at 01:25:34 AM UTC. UTC is the common time format for memory analysis.
Loading the script from '..\MemoryzeAuditScript.xml'.
Beginning local audit.
Audit started 01-22-2015 19:25:34
Successfully created output folder E:\Redline Collector\Sessions\AnalysisSession
1\Audits\WIN-LTVU8E9RBON\20150123012534\
Executing command w32memory-acquisition, 1.4.62.0
3. Some legitimate processes have code injected into them, which causes them to unwittingly become pawns of the malware, but I think that you want the process that’s doing the bad stuff. The processes that have code injected into them according to the “malfind” plugin are:
explorer.exe PID 1092
Runtime.exe PID 1476
svchost.exe PID 1656
My solution to find the malicious process was simple. I found the name of the file that was being analyzed. The file name was bddd4e2b84fa2ad61eb065e7797270ff.exe. I first saw it in the “filescan" plugin file that I had made by searching for the process name with command-f keyboard shortcut in gedit. I found it in the “timeliner" text file as well. That span of number and characters looked like the digital hash that was given to me in the last problem. So, I uploaded it to Virus Total. Sure enough, 35 out of 55 antivirus software found it as malicious. It looks like the Havex network scanner module.
To confirm my finding, I used the “netscan” plugin text file that I had made. This is what I saw:
cat netscan.txt | grep "bddd4e2b84fa2a"
0x38c8dcf0 TCPv4 -:49926 172.16.192.214:12401 SYN_SENT 1976 bddd4e2b84fa2a
0x3a642a20 TCPv4 -:49928 172.16.192.164:12401 SYN_SENT 1976 bddd4e2b84fa2a
0x3a89d010 TCPv4 -:49924 172.16.192.14:12401 SYN_SENT 1976 bddd4e2b84fa2a
0x3accacf0 TCPv4 -:49926 172.16.192.214:12401 SYN_SENT 1976 bddd4e2b84fa2a
0x40942cf0 TCPv4 -:49926 172.16.192.214:12401 SYN_SENT 1976 bddd4e2b84fa2a
0x43770160 TCPv4 -:49927 172.16.192.64:12401 SYN_SENT 1976 bddd4e2b84fa2a
0x460ad350 TCPv4 -:49925 172.16.192.114:12401 SYN_SENT 1976 bddd4e2b84fa2a
0x59dba160 TCPv4 -:49927 172.16.192.64:12401 SYN_SENT 1976 bddd4e2b84fa2a
0x65f1da20 TCPv4 -:49928 172.16.192.164:12401 SYN_SENT 1976 bddd4e2b84fa2a
0x667e2cf0 TCPv4 -:49926 172.16.192.214:12401 SYN_SENT 1976 bddd4e2b84fa2a
0x7ce079f0 TCPv4 -:50258 172.16.192.214:44818 SYN_SENT 1976 bddd4e2b84fa2a
0x7d4e2ba0 TCPv4 -:50257 172.16.192.114:44818 SYN_SENT 1976 bddd4e2b84fa2a
0x7d613500 TCPv4 -:50260 172.16.192.164:44818 SYN_SENT 1976 bddd4e2b84fa2a
0x7f805cf0 TCPv4 -:50256 172.16.192.14:44818 SYN_SENT 1976 bddd4e2b84fa2a
0x7faa3180 TCPv4 -:50259 172.16.192.64:44818 SYN_SENT 1976 bddd4e2b84fa2a
So, it looks like a bunch of SYN packets are being sent out over the port 12401 and over port 44818. Port 12401 is the port utilized by the Interactive Graphical SCADA System (IGSS), which is utilized for monitoring and controlling industrial processes. Port 44818 is the port that is used for the Ethernet/IP or RSLink protocols. Both of these ports are targeted by the Havex malware. Also, SYN scans are commonly used in enumerating information about hosts or causing a denial of service condition.
I found the following privileges that this process has suspicious. This process has given itself shutdown privileges as evidenced by the “privs.txt” file that I had made. Malicious processes commonly do this because they require a restart to do the things that they wish to do, so they’ll give themselves this privilege to shut down sooner. I don’t understand why it would give itself these following privileges. It has the Undock, Increase Working Set Privilege, and Time Zones privileges as well.
1976 bddd4e2b84fa2a 19 SeShutdownPrivilege Present Shut down the system
1976 bddd4e2b84fa2a 25 SeUndockPrivilege Present Remove computer from docking station
1976 bddd4e2b84fa2a 33 SeIncreaseWorkingSetPrivilege Present Allocate more memory for user applications
1976 bddd4e2b84fa2a 34 SeTimeZonePrivilege Present Adjust the time zone of the computer's internal clock
The “timeliner” text file that I had created stated that a new registry key was created by PID 1976. If you’ll notice, the creation date does not match up with when the process was first created. If I’m not mistaken, it shows that the parent process, explorer.exe with PID 1092, had created these entries, even though it was actually child process, PID 1976 that made them. Remember that explorer.exe with the PID 1092 had code injected into it. That is a common practice of Havex.
Registry: \??\C:\Windows\ServiceProfiles\NetworkService\NTUSER.DAT
Key name: CMI-CreateHive{D43B12B8-09B5-40DB-B4F6-F6DFEB78DAEC} (S)
Last updated: 2009-07-14 04:50:57 UTC+0000
Subkeys:
(S) AppEvents
(S) Console
(S) Control Panel
(S) Environment
(S) EUDC
(S) Network
(S) Printers
(S) Software
(S) System
Registry: \??\C:\Windows\ServiceProfiles\LocalService\NTUSER.DAT
Key name: CMI-CreateHive{D43B12B8-09B5-40DB-B4F6-F6DFEB78DAEC} (S)
Last updated: 2009-07-14 04:50:57 UTC+0000
Subkeys:
(S) AppEvents
(S) Console
(S) Control Panel
(S) Environment
(S) EUDC
(S) Network
(S) Printers
(S) Software
(S) System
In the “autoruns” scan txt file that I had made, there is evidence that the malware has added a couple of entries to start itself on boot. I think that it’s the malware because it’s the registry keys that the malware had created, as well as the same creation date.
Hive: \??\C:\Windows\ServiceProfiles\NetworkService\NTUSER.DAT
Software\Microsoft\Windows\CurrentVersion\Run (Last modified: 2009-07-14 04:50:57 UTC+0000)
Sidebar : %ProgramFiles%\Windows Sidebar\Sidebar.exe /autoRun (PIDs: -)
Software\Microsoft\Windows\CurrentVersion\RunOnce (Last modified: 2015-01-22 14:50:17 UTC+0000)
mctadmin : C:\Windows\System32\mctadmin.exe (PIDs: -)
Hive: \??\C:\Windows\ServiceProfiles\LocalService\NTUSER.DAT
Software\Microsoft\Windows\CurrentVersion\Run (Last modified: 2009-07-14 04:50:57 UTC+0000)
Sidebar : %ProgramFiles%\Windows Sidebar\Sidebar.exe /autoRun (PIDs: -)
Software\Microsoft\Windows\CurrentVersion\RunOnce (Last modified: 2015-01-22 14:50:17 UTC+0000)
mctadmin : C:\Windows\System32\mctadmin.exe (PIDs: -)
I also checked to see if the behavior matched that of the file being analyzed. For example, were the files that Virus Total stated would be created, created?
According to the “filescan" plugin, the tracedscn.yls file was created. It matches the reported behavior on Virus Total.
0x0000000049837470 16 0 -W--w- \Device\HarddiskVolume1\Users\ROBERT~1\AppData\Local\Temp\~tracedscn.yls
The dlls, that Virus Total stated would be present if this malware was present were there as well. According to the “dlllist" plugin. These dlls could be legitimate dlls. Their presence is required for this particular sample to work, though. So, even though it’s not a definitive indicator, this along with the other evidence points to Havex being present on this particular image.
c:\windows\system32\mswsock.dll
dnsapi.dll
rpcrt4.dll
c:\windows\system32\winrnr.dll
rasadhlp.dll
hnetcfg.dll
c:\windows\system32\wshtcpip.dll
It also stated that a mutex called “WriteMutex” would be created. So, I checked the “mutantscan" plugin text file that I made, and it was created.
0x000000003c505e00 2 1 1 0x0000000000000000 WriteMutex
I also found this mutex: _SHuassist.mtx, which is known to be associated with a trojan.
0x0000000001c8be70 2 1 1 0x0000000000000000 _SHuassist.mtx
0x0000000015090e70 2 1 1 0x0000000000000000 _SHuassist.mtx
0x000000005d1a1e70 2 1 1 0x0000000000000000 _SHuassist.mtx
0x000000007cc02e70 2 1 1 0x0000000000000000 _SHuassist.mtx
Ethscan has a checksum option to validate packets. Whoever is saying it has high false positives isn't helping anyone.
ReplyDelete