Today we bring you a special guest posting by Tony “@captcook32” Cook. Late last year GrrCon hosted their anticipatory excellent set of challenges which included an in depth memory forensics challenge by Wyatt Roersma. Tony and myself took a few days on a down week to try our hand at the challenge. I lacked the answers to two questions while Tony knocked them all out quickly.
While the scoreboard was reset to before our scores were posted, I’d like to present Tony’s write-up on the challenge. The challenge files are still available for download, so feel free to try the challenge on your own and return for hints. Next to each question is the file required to answer it and the password needed to open the archive.
And so follows Tony Cook:
Question #1
# BULK_EXTRACTOR-Version: 1.5.2 ($Rev: 10844 $) # Feature-Recorder: email # Filename: C:UsersAdminDesktoptarget1copy.raw # Histogram-File-Version: 1.1 n=448 4b05e584-8dc6-4554-84cf-53ec8e59b175@allsafecybersec.com (utf16=164) n=382 frontdesk@allsafecybersec.com (utf16=356) n=171 cps-requests@verisign.com (utf16=1) n=42 th3wh1t3r0s3@gmail.com (utf16=37) n=24 test@allsafecybersec.com (utf16=20) n=12 hernan@ampliasecurity.com (utf16=4) n=9 support@teamviewer.com (utf16=9) n=8 uxcyieztisogfmcq@mail.gmail.com (utf16=8) n=6 front-desk@www.ms (utf16=6) n=6 rontdesk@allsafecybersec.com (utf16=6) n=6 someone@microsoft.com n=5 front-desk@www.bi (utf16=5) n=4 b05e584-8dc6-4554-84cf-53ec8e59b175@allsafecybersec.com (utf16=4) n=4 certificate@trustcenter.de n=4 efrontdesk@allsafecybersec.com (utf16=4) n=4 front-desk@c.ms (utf16=4) n=4 frontdesk@c.ms (utf16=4) n=4 gtk-devel-list@gnome.org n=3 frontdesk@www.ms (utf16=3) n=3 ftp@example.com n=3 smtpth3wh1t3r0s3@gmail.com (utf16=3) n=3 user@domain.microsoft.com (utf16=3) n=2 4cf-53ec8e59b175@allsafecybersec.com n=2 anonymous@discussions.microsoft.com (utf16=1) n=2 cps@netlock.net n=2 e584-8dc6-4554-84cf-53ec8e59b175@allsafecybersec.com (utf16=1) n=2 ellen@contoso.com (utf16=2) n=2 ellenorzes@netlock.net n=2 front-desk@c.bi (utf16=2) n=2 frontdesk@c.bi (utf16=2) n=2 frontdesk@www.bi (utf16=2) n=2 g.j@g.jtg.jp n=2 gtkmm-list@gnome.org n=2 jane@dstc.edu.au n=2 lagoze@cs.cornell.edu n=2 me@xyz.com (utf16=2) n=2 p.johnston@ukoln.ac.uk n=2 rb05e584-8dc6-4554-84cf-53ec8e59b175@allsafecybersec.com (utf16=2) n=2 t-cole3@uiuc.edu n=2 tdesk@allsafecybersec.com (utf16=2) n=2 test@allsafecybersec.com.ost.tm (utf16=2) n=2 thabing@uiuc.edu n=1 1dbb1f52d09c41deb0219406e46b6d81@ex01.al (utf16=1) n=1 4-8dc6-4554-84cf-53ec8e59b175@allsafecybersec.com (utf16=1) n=1 53ec8e59b175@allsafecybersec.com (utf16=1) n=1 584-8dc6-4554-84cf-53ec8e59b175@allsafecybersec.com n=1 59b175@allsafecybersec.com (utf16=1) n=1 6-4554-84cf-53ec8e59b175@allsafecybersec.com n=1 6e6@machine.in (utf16=1) n=1 75@allsafecybersec.com (utf16=1) n=1 84-8dc6-4554-84cf-53ec8e59b175@allsafecybersec.com n=1 8e59b175@allsafecybersec.com (utf16=1) n=1 8rontdesk@allsafecybersec.com (utf16=1) n=1 allsafecybersec.localcf-53ec8e59b175@allsafecybersec.com (utf16=1) n=1 b175@allsafecybersec.com (utf16=1) n=1 c14e99c7-44bb-44ef-9f1d-5342c0afce0c@live.com (utf16=1) n=1 com@machine.in (utf16=1) n=1 controsts@verisign.com n=1 d_1@machine.in (utf16=1) n=1 defaultuser@defaultdomain.de (utf16=1) n=1 dev@acpi.in (utf16=1) n=1 e59b175@allsafecybersec.com (utf16=1) n=1 ec8e59b175@allsafecybersec.com n=1 effrontdesk@allsafecybersec.com (utf16=1) n=1 en@cpu.in (utf16=1) n=1 esmtpth3wh1t3r0s3@gmail.com (utf16=1) n=1 f5515863b958724ebfb72c5011bfddcc@allsafecybersec.com (utf16=1) n=1 frontdesk@allsafecybersec.co n=1 g2v@machine.in (utf16=1) n=1 h1t3r0s3@gmail.com (utf16=1) n=1 i8e59b175@allsafecybersec.com n=1 ieuser@microsoft.com (utf16=1) n=1 inf@machine.in (utf16=1) n=1 info@incomedia.it (utf16=1) n=1 ins@oem1.in (utf16=1) n=1 ion@machine.in (utf16=1) n=1 ip6@cpu.in (utf16=1) n=1 ipm.microsoft.contactlink.timestampfrontdesk@allsafecybersec.com (utf16=1) n=1 jeffsmith@redmond.co (utf16=1) n=1 le@machine.in (utf16=1) n=1 le@oem1.in (utf16=1) n=1 led@machine.in (utf16=1) n=1 nodtse@klaslfacebyrees.co (utf16=1) n=1 ntdesk@allsafecybersec.com (utf16=1) n=1 ontdesk@allsafecybersec.com n=1 outlook2.ostfrontdesk@allsafecybersec.com (utf16=1) n=1 pfrontdesk@allsafecybersec.com (utf16=1) n=1 rai@machine.in (utf16=1) n=1 rnan@ampliasecurity.com n=1 rya@machine.in (utf16=1) n=1 sk@allsafecybersec.com (utf16=1) n=1 snmpinfo@microsoft.com n=1 someone@example.com (utf16=1) n=1 ssr@umbus.in (utf16=1) n=1 t3r0s3@gmail.com (utf16=1) n=1 ta@rdpbus.in (utf16=1) n=1 tuhtmhhttht@ht.ht n=1 vista@gn.microsoft.com n=1 vshubin@ntdev.microsoft.com n=1 whit3r0s3th3wh1t3r0s3@gmail.com (utf16=1) n=1 wm@machine.in (utf16=1) n=1 wotdiityitmit@it.it n=1 x-user-identityfrontdesk@allsafecybersec.com n=1 y4cf-53ec8e59b175@allsafecybersec.com (utf16=1)
Notice that there is a PID associated with the strings thanks to the Volatility strings command, so just to ensure what process these strings are under I ran a psxview on the memory file to get that information.
Now that I confirmed that these strings came from the Outlook.exe process. I rolled the dice and put in the suspect email address as the answer.
Answer: th3wh1t3r0s3@gmail.com
[Ed. Note: I took a different approach here. I knew it was an email, so my first step was a simple Volatility `yarascan -Y “From: “` which immediately produced the email address from the OUTLOOK.EXE process]
Question #2
Answer: AnyConnectInstaller.exe
Question #3
Question #4
Question #5
Mr Robot. Just as the question eluded to, you’ll know it when you see it, I felt comfortable this was the answer.
Answer: MrRobot
Question #6
This question required me to do a bit of malware analysis as I couldn’t quite understand what was happening with the malware just by the memory image. I didn’t have a whole lot of knowledge about how XtremeRat worked so after a bit of OSINT I came across a few blog posts that helped me understand how it worked.
https://malware.lu/articles/2012/07/22/xtreme-rat-analysis.html
https://www.fireeye.com/blog/threat-research/2014/02/xtremerat-nuisance-or-threat.html
After reading through this I understood that the malware injects the Config file into memory then RC4 decodes it’s data. I also knew that this config file should be allocated all at once meaning that all of the information “should” be together in a memory section. I also knew that it should contain the Name of the executable, the Directory File Location, & FTP information. So now I had a starting point to look through the memory point.
Since I had the malware already in hand I moved it over to a VM with some Process Monitoring tools to see how it worked. I used the information I ascertained about the malware injecting into an Internet Explorer process to filter down using Process Hacker. Then I ran strings on the memory of the process & filtered for “FTP”.
Question #7
This question was essentially just asking for the mutex of the file. Utilizing the handles plugin I was able to filter down to only mutant objects as well as only objects associated with the process where the malware was running 2996. Leaving me only a couple of options to try and find the right answer.
Question #8
This question was a little tough for me at first because I was looking for all the clues in all the wrong places. What I ended up doing was trying to look for accounts that had previously been on the box even though their account might have been deleted. This led me to dumping the MFT and looking for old profiles. In looking for this I found ol “zero cool” from Hackers.
Answer: Hackers
[Ed. Note: I did a very ghetto cmdline here 🙂
grep -i “Users” target1_mftparser.txt | gawk “{print $NF}” | grep -o “^Users……….” | sort | uniq]
Question #9
Question #10
Here’s where the analysis starts to get interesting. Wow we are being asked to find some tools being used after the initial compromise. How do we start here? My first thought was run the MFT plugin from Volatility and see what had been put onto the system after the original suspicious file.
Upon opening up the MFT output I immediately searched for the creation time of the AnyConnectInstaller.exe to determine the date and where the rest of my search should continue. Luckily I didn’t have to go too far below those entries to find 3 files that I’ve seen on several IR engagements. “Rar.exe, nbtscan.exe, wce.exe” were all created mere minutes behind the suspicious file. I threw those in alphabetical order and I was off to the races.
ANSWER: nbtscan.exe,rar.exe,wce.exe
Question #11
This question was also pretty straightforward, I had already seen WCE.exe be put on the box so there should be an associated dumped credential file so the attacker could move the credentials around. In previous memory forensic work I had seen wce work & I knew that I had seen the entire executed command before through the basic strings output for the memory dump. I attempted the same philosophy here & lightening stuck twice.
I now knew the output file of the WCE command was “w.tmp” I could either use my MFT output or my FileScan output to determine the location of the file & carve it out to see what treasures it held.
I opted to use FileScan’s Physical location so I could then use the dumpfiles plugin on the address space.
Then it was just a matter of opening the file and seeing what was inside.
Question # 12
Answer: 2015-10-09 10:45:12
Question #13
Question #14
Question #15
Answer: Teamviewer
Question #16
Answer: 10.1.1.21
Question #17
Question #18
Question #19
Question #20
Question #21
Question #22
Question #23
This one was a bit tricky again because of the naming but once I submitted the hash to VirusTotal (See below image) there were really only a couple of options to go with. I tried “SYd!fg” unsuccessfully then tried Dexter FTW.
Answer: Dexter
Question #24
Luckily for this question during my search for the identification of the Dexter malware I found an interesting article from the Volatility blog that dealt precisely with this particular malware.
http://volatility-labs.blogspot.com/2012/12/unpacking-dexter-pos-memory-dump.html
After following the steps shown in the blog I had two very similar DLLs. Looking at the blog and its references I knew that the malware enumerating processes and was comparing them against a list, which was conveniently located at the beginning of the strings. There was one oddity in the blogs version of the strings & the strings I created that was very specific to the Allsafe CyberSec company.
Question #25
In this question the creators wanted you to track back the attack to the initial infection vector. In order to do that I needed to create a timeliner, in hopes to find what happened just before these connections were made. I ran the necessary commands found on the Volatility cheat sheet to create the timeline, and searched for the IP connection that I new had occurred. Boom… It looked as though I had found a file that had been downloaded from the same malicious IP.
After the file is executed we even see the DLLs get loaded into the malicious PID. Safe to say this appears to be the correct file. allsafe_update.exe .
Answer: allsafe_update.exe
[Ed. Note: Using what artifacts I had, I went another route and found the initial executable allsafe_update sitting in Temporary Internet Files. I removed the IE [1] to get the answer:
pos_filescan.txt:0x000000003e7ab038 8 0 -W-rwd DeviceHarddiskVolume2UsersposAppDataLocalMicrosoftWindowsTemporary Internet FilesLowContent.IE5NEQ2CLDXallsafe_update[1].exe]
Question #26
At last I had reached the final memory image, which was an Exchange Server & the question was what was the filename used by the attackers to control the server. I’m sure me & everyone else who were using a limited resourced VM felt the pain of this 9GB memory image. It felt as though a generation had passed by the time any of my commands were completed. Anyway back to the task at hand… I knew it was an Exchange server and no idea where the compromise might have happened. I knew they were trying to control the server so the first thing I did was run the Netscan command to see if any open connections would get me anywhere.
BOOM… The only external IP was an IP we had seen in the previously in the challenge being used maliciously. That’s a start. Not much to go off of because it looks like the PID was System.
So first thing I did was try to stay simple and create/search through strings for the memory dump for the IP. What I found was several pretty interesting POSTs to a file /owa/error1.aspx.
I thought that was pretty interesting to have POSTs to this file so I then searched for just that file in the strings file.
Well now… that’s interesting… After seeing this full post I decided to decode this garbage.
After decoding it I saw that this was actually a webshell that is trying to run remote commands on the server. Now I could safely input this file as the answer.
Answer: error1.aspx
Question #27
Question #28
This last question was fairly complicated however after decoding the strings I had a starting point. I saw that there was a call to change directories to a “C:Program FilesMicrosoftExchange ServerV15FrontEndHttpProxyowaauth” so I began my search there. I didn’t have much luck searching through strings so I ended up running MFTParser to see what all was located in that directory.
Question7
Answer: fsociety.dat
screenshot says: fsociety0.dat
Q27: Lucky you had experience. Would Yara or VirusTotal told us plebs?
Thanks for that catch. Question #7 was a simple typo.
For Question #27 I apologize for not having a more in-depth answer on the explanation. If there was a signature from any AV vendor then VirusTotal would have been a good way to go or if you had a great yara rule set for webshells that would have been another great way to go. Even another way to go would have been to Google the variable names "z1 z2 malware" to see if anything comes up.
I wanted to focus on the functionality and exactly what areas to look at to find answers. Each person will have their own experience to guide them from there, even if it's just manually looking at hundreds of lines of output, this will get you there.
Thank you very much for this great post! I enjoyed reading and learning from it.
Thank you! Can you paste the passwords of this challange files (ad01, packetcapture)? I want to try my self
Regards
The respective archive and password for each is in the image below each question. I'll transcribe them as text later today, but for now you can type off the image.
Yep, but not for all files, right? ad01 and packetcapture are not in questions 😕
Ah, correct. I'll check Tony's notes but I don't believe I ever accessed AD01 or the packet captures. They weren't part of the initial challenge. I'll update when I know better.
It appears those files were not in play. Maybe they'll be used for a follow-up set of questions, we'll have to wait and see.