September 25, 2021

Malware Protection

Dedicated Forum to help removing adware, malware, spyware, ransomware, trojans, viruses and more!

GrrCon 2015 – Memory Forensics – Grabbing all the Flags…

GrrCon 2015 – Memory Forensics – Grabbing all the Flags…
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:



In October 2015 Google put on the GrrCon 2015 CTF challenge which was open to all who wanted to attempt the challenge. My colleague “The Brian Baskin” @bbaskin let me know it was going on & I wanted to test out my memory forensics skills so I gave it a shot. This was one of the most fun & valuable CTFs that I’ve ever done. I want to give a huge shout out the the Volatility team for their awesome product & for the GrrCon 2015 CTF team for having a semi real world challenge that made you think outside of the box. The following blog post is my walkthrough of how I got through the challenge. There are most likely far better ways to go about doing most of these & I don’t claim to be a memory forensic expert but I hope this helps out anyone who got stuck on any of the questions &/or anyone looking for an explanation. 

Question #1

We start out with a question letting us know that user opened a “strange” email that appeared to be a security update, kudos to the CTF creators because who hasn’t seen that happen… All we need to provide is the sender’s email address. As with all of these questions there are about a million different approaches that we could take to find the answer, however, the way my lazy mind works I wanted to start by finding all the email addresses within the memory dump, then use that list to grep through the memory dump for these email addresses to hope for an email that would resemble the user’s . So to start with I utilized Garfunkel amazing tool, the Bulk Extractor. Among several other options this tool can provide you with a histogram of email addresses which will provide us a starting point to start looking through the memory dump.

# 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)
As I quickly looked over the top 5 highest counts a couple of the email addresses looked suspicious. However “th3wh1t3r0s3@gmail.com” stood out the most to me. Regardless how suspicious they might look to me now I had email addresses I could start to search for. 
Now we have a start but nothing to search through so I had to create a Volatility strings file. The instructions to complete this step are in this link. Once I created this file I simply started searching for the email addresses I had found in the Bulk Extractor output while looking for an email that resembled what the user had been sent. Lo and behold, remnants of an email from the suspicious email address concerning an update to the user’s VPN software.

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 

The next question was kind of tricky, only due to the wording of the question.  Essentially the question only asked what was the file that was delivered in the previous email. Since I had already done the work to find the email this was as simple as referring back to the link in the email.

Answer: AnyConnectInstaller.exe

Question #3

The CTF creators knew they took it a bit easy on the last question so they get a bit tricker in this one. Now that I had the filename I needed to figure out where and what it is. One of the Volatility plugins that I thought of to help me find the location of the file was FileScan. This nifty little tool scans the memory dump for FILE_OBJECTs with the output rendering the physical offset of the FILE_OBJECT, file name, number of pointers to the object, number of handles to the object, and the effective permissions granted to the object. At this point I could have added some regex searching to my command to search for only the filename I was looking for but I wasn’t sure if there would be any other files I’d have to come across later in the challenge so I ran FileScan to search for all FILE_OBJECTS it could find in the memory dump. 

Now that I had that output I could search it to see if the “AnyConnectInstaller.exe” had any FILE_OBJECTS open. It turned out that there were a few entries for AnyConnectInstaller.exe which were the file itself & two Prefetch Files, which led me to believe the file had been executed on the host. 
Now that I knew the location of file I could use another Volatility plugin that could carve the files out using the Physical Offset location called DumpFiles
Voila, I now had the suspicious file in my possession, now what? Next I did some quick static analysis of the file only to be dismayed that it was a Borland executable, this wouldn’t be as simple as I thought it could be. Strings of the executable showed that there might be a correlation to the XTREME, however upon trying the “XTREME” I was denied… 
The next thing I did was run in a sandbox tool made by Brian Baskin, Noriben, to get a feel for what the executable does. 
Through the process information I saw that the upon execution the file attempts to inject itself into iexplore.exe as well as the creation of a “TempXtremeServerSource.dat”. At this point I was getting a bit frustrated with the analysis as I was no closer to getting the answer to the question. I decided to fire up Process Hacker and look at the memory of the injected iexplore.exe to see if I could glean anything from that before having to open up some debugging tools. I searched for the injected file name to begin with to see if I’d have any luck…
As soon as I searched for the file I found several interesting strings that led me down the right path and what I had been missing. The question stated that the answer would be one word and no spaces. While I had tried Xtreme… I had not tried XtremeRAT. I rolled the dice & jackpot…
Answer: XTREMERAT

Question #4

In this question the CTF creator wanted to know what process that the suspicious file was attempting to inject into. In the quest to find out what the “malware name” of the suspicious file we determined that if the file executed it would attempt to inject into iexplore.exe, so the next step would be to determine what process ID iexplore.exe had. A quick run of Volatility’s PSXVIEW would quickly give me that answer. 
The process iexplore.exe has the PID of 2996… Put it in and… BOOM!!!

Question #5

In the question they wanted to know the value of persistence that the malware was using. Due to my   analysis of the suspicious file from earlier with Noriben I knew that the file was creating Registry entries in the CurrentVersionRun so it was just a matter of determining the value that stored the file path.

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

I only noticed one legitimate FTP site in the list so I clicked on that to drill into it’s memory section. When I reviewed it saw everything I learned about the Config file from the blog posts including the Mutex, FTP information, & Directory Location. I then saved out that portion of the memory section & ran strings on it. After removing the obvious garbage I was left with the following output.
I was looking for a C2 password in this entire list of strings. I removed out the Xtreme RAT references, the Mutex, the Registry Input, the addresses, the Directory Locations, & errors to down to 7 possibilities. After reviewing the question I had 10 possible tries so I went through them all. I was starting to get a bit nervous as I reached the end of the list however upon trying “GrrCon2015” I was given the green light & I wiped the sweat from my forehead. Now is there a way better & more accurate way to do this? Absolutely. You could follow the Malware.lu’s blog post & completely reverse the executable to find the correct answer. After the contest I went back to do which I recommend everyone try out to see the little nuance in this Xtreme Rat executable but that’s for another blog post & another time.
Answer: GrrCon2015

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.

Answer: fsociety0.dat

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

This question was fairly straightforward and simple, get the Administrator’s NTLM hash. This can be completed by running the hashdump plugin on the memory dump, which gave me the answer.
Answer: aad3b435b51404eeaad3b435b51404ee:79402b7671c317877b8b954b3311fa82

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.

There lay the answer to the question.
Answer: flagadmin@1234

Question # 12

This question was asking for the $STD Creation time for the NBTSCAN.EXE tool. Since we already ran the MFTParser tool we have access to the answer already. 
Look under the $STD information & we see the answer. 

Answer: 2015-10-09 10:45:12

Question #13

This question ended up being easier than most of the other questions because the file name that needs carved out was already given. I followed the same methodology as all of the previous carves. 
                Filename ->; FileScan Output ->; Physical Offset ->; DumpFile

Question #14

So finally the competition switches to the network side of things. To first get a glimpse at the network connections I ran the netscan plugin. After seeing the results I knew the PID of the injected process  (iexplore.exe) that the malware was using (2996) so I re-ran the command, this time grepping for just the PID I needed. 
The result was a single connection to ” “. I took my chances and input it as the answer, BINGO.
Answer: 180.76.254.120:22

Question #15

This question appeared to quite simple after running the last netscan as in the results of that output we saw a few connections out to TeamViewer servers, but how could I be sure that it was installed after the attackers got in? I quickly referenced the MFT Parser Timeline csv I created earlier to see what was put on the system AFTER the attackers got in. Sure enough a TeamViewer installer was found in directly after a few Prefetch files for the “Attacker” tools earlier as well as an AT command. 

Answer: Teamviewer

Question #16

This question was another fairly simple question as long as you understood the Windows OS basics. A builtin remote access too huh? I went straight to the netscan output to look for remote desktop connections either using mstsc.exe or over the default port 3389.

Answer: 10.1.1.21

Question #17

Looks like I had finished up with the Target 1 host & moved on to Target 2 for this next question. “Laterally” btw… 😉 Anywho we needed to figure out what Gideon’s actual password was. Since we had already seen the attackers use WCE on the target 1 host I assumed that like most attackers that would be the tool they’d use across the board so I took the same approach. I looked for WCE in the strings to see if I could find the entire command. 
Now that I had that I could run FileScan to see if the file had a FILE_OBJECT. Sure enough it did and then I could run dumpfiles against it to drop out the file and then open it to find out the answer
Answer: t76fRJhS
[Ed. Note: I failed to get this one 🙂 But in retrospect I now see it in my notes for #18]

Question #18

This next question was a little tricky as well only because of the wording of the question. At first glance I assumed that the question was what Windows credentials were being used to pivot to the domain controller, however that must have been the previous questions answer so I moved on. My next thought went to what I would do if I got creds and wanted to move forward, well I’d probably already have a shell open. Fortunately Volatility has just the plugin to show us that input with cmdscan.
Looking at the output I saw the wce.exe being executed so I felt pretty confident this was the conhost.exe I was looking for. Looking further into the output I saw bad guy run “whoami” to figure out what user he was using at the time then the Z: get mapped with the current credentials (gideon). Once mapped I saw him/her then copying over rar.exe, most likely to archive whatever files the attacker is attempting to exfil. Then we see what’s really interesting… the attacker use the RAR command to archive all text files in their current directory with the password 123qwe!@#. Notice that  I didn’t include the -hp which is actually just part of the parameters to include a password for RAR files. Once I input this as the answer and I was on my way to success.
Answer:  123qwe!@#

Question #19

As I started this question I already had the answer from the previous output which was the password protected “crownjewlez.rar”.
Answer: CrownJewlez.rar 

Question #20

This next question we have is what are the files that were archived inside the RAR file. In order to answer this one I had to think about what actually happened. A conhost.exe was the root of what showed me that the RAR file was created so maybe if I looked more into that process I would find what files were added into them. The easiest way to do this was to look at the strings for this process for clues to see where I could go next. I ran the Volatility strings process that was explained earlier then grep’ed for just the process in question 3048. The result was pretty interesting in that I could see the exact file names that we added to the RAR file. 
In the clear text strings I could see 3 files being added to the RAR file after the command was run, similar to what would have been in the output of the command on a terminal. I inputed these filenames in the order they got added and the right format then… boom, winning…
Answer: SecretSauce1.txt,SecretSauce2.txt,SecretSauce3.txt
[Ed. Note: I failed to get this one :)]

Question #21

This question ended up being a basic IR question. A scheduled job was created on the machine to which we have to find the file name that is associated with it, most likely the file that is being run through the task. I knew that scheduled tasks are created in the WindowsTasks directory & I had already created an output file from the FileScan plugin so it was just a matter of grepping that file for all the files which we located in that directory.
There were three files found in that directory. The first being the default SCHEDLGU.TXT file, then a GoogleUpdateTask, and finally an At1.job file. By default if no other name is given to a scheduled job utilizing at.exe it will name itself At1.job but this only gets us the file so I carved the file out utilizing the process I had been using previously to see what was in this Job file. The job file is actually not human readable and needed to be parsed utilizing Jamie Levy’s jobparse.py. Once the file was parsed it was easy to see that 1.bat was being called during the scheduled time.
Answer: 1.bat 

[Ed. Note: I didn’t carve files out but instead expected to find the full contents within the MFT. I displayed each out and eyeballed it:
> grep -i “.job” target2_mftparser.txt -A50 | grep “$DATA” -A10
$DATA
0000000000: 01 06 01 00 01 e0 b4 20 f7 a5 f4 43 8d f5 25 57   ………..C..%W
0000000010: 7f 5f a1 48 46 00 d2 00 00 00 00 00 3c 00 0a 00   ._.HF…….<…
0000000020: 20 00 00 00 00 14 73 0f 01 00 00 00 00 13 04 00   ……s………
0000000030: 02 00 e0 21 df 07 0a 00 05 00 09 00 08 00 00 00   …!…………
0000000040: 00 00 8f 00 00 00 16 00 63 00 3a 00 5c 00 75 00   ……..c.:..u.
0000000050: 73 00 65 00 72 00 73 00 5c 00 67 00 69 00 64 00   s.e.r.s..g.i.d.
0000000060: 65 00 6f 00 6e 00 5c 00 31 00 2e 00 62 00 61 00   e.o.n..1…b.a.
0000000070: 74 00 00 00 00 00 00 00 07 00 53 00 59 00 53 00   t………S.Y.S.
0000000080: 54 00 45 00 4d 00 00 00 1e 00 43 00 72 00 65 00   T.E.M…..C.r.e.
0000000090: 61 00 74 00 65 00 64 00 20 00 62 00 79 00 20 00   a.t.e.d…b.y…]

Question #22

For this next question we moved onto something pseudo new to most IR analysts which is a POS system. The first question was what is the CNC of the malware that we didn’t even know was running on the system. Where to start here??? The question asked about a connection so that’s where I began my hunt. There must be an outbound connection from the host to something so a quick NETSCAN plugin output showed me there were a few outbound connections. 
Seeing there were only a few processes that had an outbound connection I listed those PIDs & IPs to start to track down what the culprit was. The first seen outbound connection was 10.1.1.3 with several connections associated with Outlook.exe. At first glance I moved past this one as it appeared to be an internal exchange server, but I could have been wrong. The next thing in my plan was to see if there were any injected code in the processes I saw with network connections using the MALFIND plugin. 
After running the MALFIND plugin the only networked connection was the PID 3208.  Looking at the output for this process we see an MZ header which is an indication that the process might be injected into. In order to test this theory out I ran the same command specifying the port & a -D to dump out any process we find.
What did it dump out? 
Very nice… Let’s see what’s in this thing. I submitted the hash of the executable to VirusTotal & what returned as a Dexter variant of POS malware. I felt pretty confident that this was the process’s network connection was the communicating to the C2 server. 
Answer: 54.84.237.92

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.

Answer: allsafe_protector.exe

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

In the past I’ve dealt with several Exchange servers with OWA being owned, the base64 encoded variables & variable names that we used in this particular webshell hinted me towards one particular piece of malware, China Chopper. See https://www.fireeye.com/blog/threat-research/2013/08/breaking-down-the-china-chopper-web-shell-part-ii.html
Answer: chinachopper

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.

I found some interesting files located within this directory including the webshell, an earlier found RAR file, a test file, and th3k3y.txt. The last one seemed interesting to me but I ended up running FILESCAN to see if I could carve out all of these files. The only file I found to be resident in memory was the th3k3y.txt so I carved it out. What I found inside of the file was a single string.
eNpzLypyzs/zyS9LLfYtCspPyi9xzEtxKzZIzkwtqVRUVAQAybULlw==
I put it in and sadly… the journey was over…