TeamSpy - MemProcFS
Today we will take a brief look at a Cyberdefenders.org challenge with the goal of learning more about a memory forensics tool called MemProcFS and memory forensics in general. If you have not yet stumbled upon cyberdefenders.org I’d recommend checking it out. Its a fantastic resource for anyone looking to learn, validate, and advance the cyber defense skills.
MemProcFS facilitates a hierarchical representation of the analysed memory dump (or live acquisition) as processed by the tool. Roughly equivalent to running a number of Volatility plugins including dumping interesting processes, memory and files whilst organising them for easy access through a virtual file system.
For this post I’ll be using vanilla Windows 10 install running https://github.com/mandiant/flare-vm post installation scripts. A number of auxiliary tools deployed as part of the FlareVM installation scripts will be used to further investigation and supplement investigation across memory artifacts,.
To keep this on the shorter side I’ll be tackling the first part of the challenge focusing on the first memory dump (win7ecorpoffice2010-36b02ed3.vmem).
Getting started with MemProcFS:
MemProcFS is easy to setup and start using, download the latest binary from https://github.com/ufrisk/MemProcFS/releases/latest and extract. The only prerequisite is Dokany, a user mode file system library for windows that can be downloaded from https://github.com/dokan-dev/dokany/releases/latest
Once the above has been completed run memprocfs -device <memory dump> -forensic 1. The -forensics 1 is optional and will perform additional analysis tasks including timelining, extended mft analysis, leveraging yara rules for detection and more. Results will be placed in the forensic folder as part of the virtual file system.
When run the terminal used to execute MemProcFS will need to remain open, from here we can browse through the memory dump like you would a normal file system.
TeamSpy Challenge Questions:
Challenge: TeamSpy
Difficultly: Difficult
Tags: Memory Windows GrrCon
Download package: 1bc677daf51be254c8bfb9085f7375bbf1ee8e3b
The files we are provided as part of this challenge are below.
tree /F
Folder PATH listing
Volume serial number is C0000100 5216:D797
C:.
├───ecorpoffice
│ win7ecorpoffice2010-36b02ed3.vmem (3d99af34ad6389c774a3eb9cd2483376182f1dcfbb4d77ed4233783ae7cae42a)
│ win7ecorpoffice2010-36b02ed3.vmss (45c47820c4042604e79086aa7ff0580fd262ed7355acad903e10a347d8243b58)
│
└───ecorpwin7
ecorpwin7-e73257c4.vmem (f3b76436f7236955f45d3f169dbac1cc481fcdb19c1299aed735ae92e7d80578)
ecorpwin7-e73257c4.vmss (24e7896fb8af44dbd8b898cb480aa87741e5dd81c63caa5d92628886e4055e5d)
Initial setup
To begin we run memprocfs -device win7ecorpoffice2010-36b02ed3.vmem -forensic 1. Once run we should be able to navigatge to the mount point and are ready to get started.
With setup complete the below runs through questions asked as part of the challenge and how these could be answered using MemProcFS and auxiliary tools. Where appropriate I’ve also included the equivalent Volatility commands.
Question #1 - What is the Pid the malicious file is running under?
Lets get started by looking at what we have available within the mounted file system. To get a lay of the land we can look in the \sys\proc folder at the proc.txt file. This will show us an output of all processes at the time of capture. This part should be familiar to most and will look similar to the pstree output from volatility.
Process Pid Parent Flag User Create Time Exit Time ------------------------------------------------------------------------------------------------------------------ - System 4 0 SYSTEM 2016-10-04 12:05:22 UTC *** -- smss.exe 280 4 SYSTEM 2016-10-04 12:05:22 UTC *** - csrss.exe 360 344 SYSTEM 2016-10-04 12:05:22 UTC *** -- conhost.exe 1940 360 T SYSTEM 2016-10-05 03:05:11 UTC 2016-10-05 03:05:11 UTC - wininit.exe 412 344 SYSTEM 2016-10-04 12:05:23 UTC *** -- services.exe 460 412 SYSTEM 2016-10-04 12:05:23 UTC *** --- svchost.exe 372 460 LOCAL SERVICE 2016-10-04 12:05:24 UTC *** --- svchost.exe 644 460 SYSTEM 2016-10-04 12:05:24 UTC *** ---- WmiPrvSE.exe 1580 644 NETWORK SERVICE 2016-10-04 12:05:59 UTC *** --- vmacthlp.exe 708 460 * SYSTEM 2016-10-04 12:05:24 UTC *** --- svchost.exe 752 460 NETWORK SERVICE 2016-10-04 12:05:24 UTC *** --- svchost.exe 816 460 LOCAL SERVICE 2016-10-04 12:05:24 UTC *** --- sppsvc.exe 860 460 NETWORK SERVICE 2016-10-04 12:07:51 UTC *** --- svchost.exe 900 460 SYSTEM 2016-10-04 12:05:24 UTC *** ---- dwm.exe 2460 900 U phillip.price 2016-10-04 12:06:11 UTC *** --- svchost.exe 924 460 NETWORK SERVICE 2016-10-04 12:05:24 UTC *** --- svchost.exe 928 460 SYSTEM 2016-10-04 12:05:24 UTC *** --- spoolsv.exe 1112 460 SYSTEM 2016-10-04 12:05:24 UTC *** --- svchost.exe 1144 460 LOCAL SERVICE 2016-10-04 12:05:24 UTC *** --- VGAuthService. 1280 460 * SYSTEM 2016-10-04 12:05:24 UTC *** --- vmtoolsd.exe 1336 460 * SYSTEM 2016-10-04 12:05:24 UTC *** ---- cmd.exe 1920 1336 T SYSTEM 2016-10-05 03:05:11 UTC 2016-10-05 03:05:11 UTC --- dllhost.exe 1772 460 SYSTEM 2016-10-04 12:05:59 UTC *** --- msdtc.exe 1996 460 NETWORK SERVICE 2016-10-04 12:05:59 UTC *** --- svchost.exe 2232 460 SYSTEM 2016-10-04 12:06:06 UTC *** --- taskhost.exe 2380 460 U phillip.price 2016-10-04 12:06:11 UTC *** --- svchost.exe 2940 460 LOCAL SERVICE 2016-10-04 12:06:14 UTC *** --- SearchIndexer. 3180 460 SYSTEM 2016-10-04 12:06:17 UTC *** ---- SearchProtocol 3692 3180 32 U phillip.price 2016-10-05 03:05:07 UTC *** ---- SearchFilterHo 3924 3180 SYSTEM 2016-10-05 03:05:07 UTC *** --- OSPPSVC.EXE 3532 460 * NETWORK SERVICE 2016-10-04 12:06:21 UTC *** -- lsass.exe 476 412 SYSTEM 2016-10-04 12:05:23 UTC *** -- lsm.exe 484 412 SYSTEM 2016-10-04 12:05:23 UTC *** - csrss.exe 428 404 SYSTEM 2016-10-04 12:05:23 UTC *** - winlogon.exe 552 404 SYSTEM 2016-10-04 12:05:23 UTC *** - ipconfig.exe 3348 1920 T SYSTEM 2016-10-05 03:05:11 UTC 2016-10-05 03:05:11 UTC - explorer.exe 2492 2436 U phillip.price 2016-10-04 12:06:11 UTC *** -- OUTLOOK.EXE 2692 2492 32 U* phillip.price 2016-10-05 03:05:06 UTC *** -- vmtoolsd.exe 2708 2492 U* phillip.price 2016-10-04 12:06:11 UTC *** -- chrome.exe 2896 2492 TU* phillip.price 2016-10-04 12:06:14 UTC 2016-10-05 02:55:38 UTC - SkypeC2AutoUpd 1364 2528 32 U* phillip.price 2016-10-04 12:07:51 UTC ***
Reviewing the above process tree the last process in the list stands out as being abnormal and likely to warrant further investigation. Research on the SkypeC2AutoUpd string reveals its likely carries malicious intent however we should attempt to confirm through further analysis.
To help build confidence in our hypothesis we can look for other indicators that might confirm our suspicions. Looking in the M:\pid\1364\files\modules folder for this process we see the SkypeC2AutoUpdater.exe (MD5 - 0AFE32F11F6376C4FCE67672D1CF0876) file. A quick lookup in VirusTotal reveals this is likely TeamViewer.
Investigating further, we can look into M:\pid\1364\memmap\vad-v for this process and can investigate the _vad-v.txt file revealing the below files run from Local\Temp
SkypeC2AutoUpdate.exe
tv_w32.dll
avicap32.dll
TeamViewer_Resource_en.dll
Within _vad-v.txt we don’t have a user folder however navigating to M:\pid\1364\modules\TeamViewer_Resource_en.dll\fullname.txt we are able to reveal the full path of C:\Users\PHILLI~1.PRI\AppData\Local\Temp\TeamViewer_Resource_en.dll. We can also see this through M:\pid\1364\win-environment.txt.
We can get additional details including relevant version info from M:\pid\1364\modules\modules-versioninfo.txt and unloaded modules from unloaded_modules.txt.
Taking the above into account this process (PId 1364) is likely malicious.
Volatility Command Equivalent
volatility -f win7ecorpoffice2010-36b02ed3.vmem imagineinfo
volatility -f win7ecorpoffice2010-36b02ed3.vmem --profile=Win7SP1x64 pslist
Question #2 - What is the C2 server IP address?
Looking for a C2 IP address was challenging, I ended up digging into the M:\pid\1364\minidump\minidump.dmp file with findstr i was able to pull out the below IP addresses by looking for SkypeC2AutoUpdate and associated strings.
http://54.174.131[.]235/getinfo.php?id=528812561&stat=1&tout=10&osbt=2&osv=6.1&osbd=7600&ossp=0.0&ulv=2&elv=0&rad=0&agp=1&devicea=0&devicev=0&uname=phillip.price&cname=WIN-191HVE3KTLO&vpn=0&tvrv=0.2.2.2
54.174.131[.]23
If you’re not fond of using findstr or parsing the file via commands and you’ve deployed the flareVM post install scripts you can also right click on the minidump file and select strings. This will allow you to search through the dump of 1364 using Strings ( a GUI driven strings tool).
There is also a folder called M:\sys\net within the mounted file system where you could also get this information from the netstat-v.txt or netstat.txt files however in this case this file was partially populated and didn’t contain the info needed.
Confirming this with Volatility:
λ volatility_2.6_win64_standalone.exe -f ..\cd\c74-TeamSpy\ecorpoffice\win7ecorpoffice2010-36b02ed3.vmem --profile=Win7SP1x64 netscan | findstr Skype Volatility Foundation Volatility Framework 2.6 0x7d7812e0 TCPv4 127.0.0.1:6039 0.0.0.0:0 LISTENING 1364 SkypeC2AutoUpd 0x7d416010 TCPv4 -:0 120.122.236.3:0 CLOSED 1364 SkypeC2AutoUpd 0x7d709220 TCPv4 -:0 -:0 CLOSED 1364 SkypeC2AutoUpd 0x7d79e010 TCPv4 10.1.1.122:54905 54.174.131.235:80 CLOSED 1364 SkypeC2AutoUpd 0x7dd99240 TCPv4 127.0.0.1:49275 127.0.0.1:49276 ESTABLISHED 1364 SkypeC2AutoUpd 0x7dd997c0 TCPv4 127.0.0.1:49276 127.0.0.1:49275 ESTABLISHED 1364 SkypeC2AutoUpd 0x7e0db7e0 TCPv4 10.1.1.122:54847 54.174.131.235:80 CLOSED 1364 SkypeC2AutoUpd 0x7fdb3880 TCPv4 10.1.1.122:54845 54.174.131.235:80 CLOSED 1364 SkypeC2AutoUpd
Volatility Command Equivalent
volatility -f win7ecorpoffice2010-36b02ed3.vmem --profile=Win7SP1x64 netscan
Question #3 - What is the Teamviewer version abused by the malicious file?
This one is fairly straight forward because of the strings we pulled put with looking for the C2 server IP, by looking at some of the web requests observed as part of question #2 we are able to determine the team viewer version number as its listed in a request.
http://54.174.131[.]235/getinfo.php?id=528812561&stat=1&tout=10&osbt=2&osv=6.1&osbd=7600&ossp=0.0&ulv=2&elv=0&rad=0&agp=1&devicea=0&devicev=0&uname=phillip.price&cname=WIN-191HVE3KTLO&vpn=0&tvrv=0.2.2.2
Volatility Command Equivalent
volatility -f win7ecorpoffice2010-36b02ed3.vmem --profile=Win7SP1x64 memdump -p 1364 -D <output>
volatility -f win7ecorpoffice2010-36b02ed3.vmem --profile=Win7SP1x64 procdump -p 1364 -D <output>
Question #4 - What password did the malicious file use to enable remote access to the system?
Typically we might get this from edit controls using the Volatility editbox plugin. Again looking output from the minidump.dmp file we found using MemProcFS we see an interesting string that is likely the password we are after C:\Users\PHILLI~1.PRI\AppData\Local\Temp\SkypeC2AutoUpdate.exe --PWU P59fS93m
Volatility Command Equivalent
Check this out: https://volatility-labs.blogspot.com/2015/08/recovering-teamviewer-and-other.html
volatility --plugin=/opt/volatility/volatility/plugins -f win7ecorpoffice2010-36b02ed3.vmem --profile=Win7SP1x64 editbox
Question #5 - What was the sender's email address that delivered the phishing email?
Assisting us in answering this question is the -forensic 1 option we specified when launching memProcFS. Navigating to M:\forensic\files\files.txt we are able to quickly assess if there are any .pst or .ost files that might be of interest. We see the below which gives us a good place to start.
\Users\phillip.price\AppData\Local\Microsoft\Outlook\~phillip.price@e-corp.biz.pst.tmp \Users\phillip.price\AppData\Local\Microsoft\Outlook\phillip.price@e-corp.biz.pst \Users\phillip.price\AppData\Local\Microsoft\Outlook\~phillip.price@e-corp.biz.pst.tmp
when navigating to M:\forensic\files\ROOT\Users\phillip.price\AppData\Local\Microsoft\Outlook we do indeed find a .pst file called fffffa8003d2b520-phillip.price@e-corp.biz.pst which we will grab for analysis.
To extract the contents we will use libpff which can be found on https://github.com/libyal/libpff . Once obtained extract the contects using the following command: pffexport.exe fffffa8003d2b520-phillip.price@e-corp.biz.pst
The output we get will look like this:
λ tree Folder PATH listing Volume serial number is C0000100 5216:D797 C:. ├───ItemProcSearch ├───Reminders ├───Search Root │ ├───MS-OLK-FGPooledSearchFolder54F0A06BBC4A8948B8111274DD039E3E │ └───MS-OLK-FGPooledSearchFolder82AEAEAE7D3E7F409D9441108194AA79 ├───SPAM Search Folder 2 ├───To-Do Search ├───Top of Outlook data file │ └───Inbox │ ├───Message00001 │ ├───Message00002 │ ├───Message00003 │ ├───Message00004 │ ├───Message00005 │ ├───Message00006 │ ├───Message00007 │ ├───Message00008 │ ├───Message00009 │ ├───Message00010 │ ├───Message00011 │ │ └───Attachments │ ├───Sent │ │ ├───Message00001 │ │ ├───Message00002 │ │ ├───Message00003 │ │ └───Message00004 │ └───Trash └───Tracked Mail Processing
Poking around the email messages we identify a suspect email message within the Message00011 folder. The only email with an attachment. Spoiler alert, other emails seen reveal conversations regarding ransom payment.
λ tree /F
Folder PATH listing
Volume serial number is C0000100 5216:D797
C:.
│ ConversationIndex.txt
│ InternetHeaders.txt
│ Message.txt
│ OutlookHeaders.txt
│ Recipients.txt
│
└───Attachments
1_bank_statement_088452.docFrom here we peak into the OutlookHeaders.txt file to reveal the senders email address.
λ type OutlookHeaders.txt Message: Client submit time: Oct 04, 2016 12:02:04.000000000 UTC Delivery time: Oct 04, 2016 12:02:19.000000000 UTC Creation time: Oct 04, 2016 12:01:44.887000000 UTC Modification time: Oct 04, 2016 12:09:09.708000000 UTC Size: 61494 Flags: 0x00030011 (Read, Has attachments, Unknown: 0x00030000) Conversation topic: E COIN Invoice Subject: E COIN Invoice Sender name: karenmiles@t-online.de Sender email address: karenmiles@t-online.de Sent representing name: karenmiles@t-online.de Sent representing email address: karenmiles@t-online.de Importance: Normal
questions #6 - What is the MD5 hash of the malicious document?
MD5 hash of the attached doc is straight forward.
c2dbf24a0dc7276a71dd0824647535c9
Question #7 - What is the bitcoin wallet address that ransomware was demanded?
Again looking around the email messages sent and received we find Message00002 contains discussion of a ransom payment with a provided bitcoin address of 25UMDkGKBe484WSj5Qd8DhK6xkMUzQFydY.
Questions #8 - What is the ID given to the system by the malicious file for remote access?
Going back to the same request we saw in question 3 we are also able to pull out the system id id=528812561.
http://54.174.131[.]235/getinfo.php?id=528812561&stat=1&tout=10&osbt=2&osv=6.1&osbd=7600&ossp=0.0&ulv=2&elv=0&rad=0&agp=1&devicea=0&devicev=0&uname=phillip.price&cname=WIN-191HVE3KTLO&vpn=0&tvrv=0.2.2.2
Question #9 - What is the IPv4 address the actor last connected to the system with the remote access tool?
Similar to finding the previous C2 IP address we can further parse the dump of Pid 1364 to get all IP addresses which reveals 31.6.13[.]155 as the IP address that connected to the system last. This was essentially a manual process and a bit of deduction.
There were a lot of version numbers that matched loosely written regex to find IP addresses. Once I had a list of all IP addresses I had to then go through them to determine which ones were used for remote connection via manual analysis of the 1364 dump.
Question #10 - What Public Function in the word document returns the full command string that is eventually run on the system?
On FlareVM we have the oletools available to us, using oleid we see that its flagging this file as potentially having suspicious VBA macros. THis warrants further investigation.
λ oleid 1_bank_statement_088452.doc
oleid 0.60.1 - http://decalage.info/oletools
THIS IS WORK IN PROGRESS - Check updates regularly!
Please report any issue at https://github.com/decalage2/oletools/issues
Filename: 1_bank_statement_088452.doc
WARNING For now, VBA stomping cannot be detected for files in memory
WARNING For now, VBA stomping cannot be detected for files in memory
--------------------+--------------------+----------+--------------------------
Indicator |Value |Risk |Description
--------------------+--------------------+----------+--------------------------
File format |MS Word 2007+ Macro-|info |
|Enabled Template | |
|(.dotm) | |
--------------------+--------------------+----------+--------------------------
Container format |OpenXML |info |Container type
--------------------+--------------------+----------+--------------------------
Encrypted |False |none |The file is not encrypted
--------------------+--------------------+----------+--------------------------
VBA Macros |Yes, suspicious |HIGH |This file contains VBA
| | |macros. Suspicious
| | |keywords were found. Use
| | |olevba and mraptor for
| | |more info.
--------------------+--------------------+----------+--------------------------
XLM Macros |No |none |This file does not contain
| | |Excel 4/XLM macros.
--------------------+--------------------+----------+--------------------------
External |0 |none |External relationships
Relationships | | |such as remote templates,
| | |remote OLE objects, etc
--------------------+--------------------+----------+--------------------------
From here we can use the olevba -c "1_bank_statement_088452.doc" > suspect_doc.vba --decode --reveal command to pull out VBA macros for further analysis.
We get a whole lot of what looks to be obfuscated VBA. Looking for the “run” which indicates it may run an executable file or a system command". Looking for this reveals the function used to run the final command which in this case is UsoJar.
Public Sub xvkBjM()
On Error GoTo DoWhOs
onTriEc
PdSnMAm
vBhkpG
oADSc
suDVZ
Set gDFGB = CreateObject(pEEyJqs)
WFCWFf gDFGB.Run(UsoJar, 0)
MsgBox ("Invalid Macro Format")
Exit Sub
For now, I’ll leave it there, Part 2 will tackle additional questions.
Resources:
https://github.com/ufrisk/MemProcFS
https://github.com/libyal/libpff
https://github.com/dokan-dev/dokany/releases/latest