Memory Forensics - GrrCon2015 CTF

It is common that during any forensic investigation, different responders and forensic investigators can reach to the same conclusion using different approaches.

While searching for memory forensic challenge CTFs, I came across the GRR Conf 2015 memory forensic challenge and its solution writeup by ghettoforensics. Yes it is an old CTF, but I thought of working out the solution to questions in my own way and see how much does it differ from the solution provided by the ghettoforensics.

There are 3 memory images: target1, target2, pos01 and ex01. The passwords to the zip files are mentioned in the question boxes below:

So the first few plugins I run on a mem image are related to processes, network connections and cmd (scan/lines) to quickly identify suspicious processes. The idea is to identify strange and unexpected commandlines, for example, powershell.exe running with a lengthy commandline or base64 encoded stuff in the commandline, rundll32.exe with a strange dll or abnormal path for a dll in the commandline, unexpected process genealogy for example explorer.exe running as a child process of svchost.exe, misspelled processes, hidden processes, process making outbound network connections to suspicious/malicious ip addresses, processes listening on unexpected ports, processes running from unusual paths (appdata, temp etc), etc.

In order to answer Q1, I pslisted and discovered the outlook.exe process was running, so the next step would be to dump the memory space of this process using the memdump plugin. This will give us the total memory space of what the outlook.exe processes sees for itself. Now we can use strings on the output of memdump and grep for the “update” keyword. This gives us the email headers and the subject line containing the “update” keyword. The From email header is the answer.    
# -f Target1-1dd8701f.vmss --profile=Win7SP0x86 pslist

# -f Target1-1dd8701f.vmss --profile=Win7SP0x86 -p 3196 memdump -D 3196_memdump/

# strings 3196.dmp | grep -i update -A20 | more

The Q2 and some other questions in the CTF were somewhat ambiguous. However, from our screenshot from Q1 we can see that the attached file name was AnyConnectInstaller.exe. We can also see the URL to the malicious installer file (hxxp://

So in Q3, we need to provide the malware name. “filescan” is a very cool plugin, which can help us in identifying all of the directories and files, which were opened and being used by processes at the time memory image was taken. These files would be fully or partially mapped in the memory space and can be dumped.

I grepped the output of filescan for “anyconnect” string, hoping to find the malicious exe file in there. I found multiple instances of it as can be seen from the screenshot below. It seems that the users “frontdesk” and “anyconnect” were phished and downloaded the malicious file and then there were at least 2 instances of execution of the malicious file from different locations. We can see the physical offsets where these files are located in the memory image. Using these physical offsets we can dump the files from memory image using the “dumpfiles” plugin. Once the files are dumped we can calculate md5sum for the files and look up the hash on platforms like VT, which will give us the name of the malware “Xrat”.

$ cat filescan.txt | sort -k5 | grep -i Anyconnect

Physical offsets ^

sudo -f Target1-1dd8701f.vmss --profile=Win7SP0x86 dumpfiles -D dumpfiles/ --physoffset=0x000000003df12dd0

sansforensics@siftworkstation -> ~/D/m/G/t/dumpfiles

$ md5sum file.Non*
b05e889e8436ed89157a2aa0cb8cdaa6  file.None.0x85d0ed60.dat
23a9329505c6eb16840901524ca7bdc9  file.None.0x85d12b18.dat
e4fd2c7a7fe9dc6ec6e9fa825f8100d1  file.None.0x85d1c6c0.img



Beside the anyconnectinstaller.exe file, I also discovered some batch files under the Users\frontdesk folder:

0x000000003e056f80      8      0 RW-rw- \Device\HarddiskVolume2\Users\frontdesk\1.bat
0x000000003efaabc0      8      0 RW-rw- \Device\HarddiskVolume2\Users\frontdesk\a.bat

It turns out that the intruder had executed wce.exe to dump credentials into a file w.tmp under c:\users\gideon.

I also discovered some files under Windows\Temp, where a suspicious binary can be seen that the intruder dump their toolset. The toolset was simple comprising of wce.exe and related files, rar.exe to create archive, nbtscan.exe for scanning network range with UDP 137 packets to discover machines for the purpose of lateral movement.

0x000000003fc69308      1      1 R--rw- \Device\HarddiskVolume2\Windows\Temp
0x000000003fca6de8      1      1 R--rw- \Device\HarddiskVolume2\Windows\Temp
0x000000003fcb0f10      1      1 R--rw- \Device\HarddiskVolume2\Windows\Temp
0x000000003e1eee10      7      0 R--r-d \Device\HarddiskVolume2\Windows\Temp\getlsasrvaddr.exe
0x000000003fcaa598      8      0 -W-rw- \Device\HarddiskVolume2\Windows\Temp\MpCmdRun.log
0x000000003fdb7808      8      0 -W-r-- \Device\HarddiskVolume2\Windows\Temp\nbs.txt
0x000000003fc3fb80      6      0 R--r-d \Device\HarddiskVolume2\Windows\Temp\nbtscan.exe
0x000000003fdd4ca0      7      0 R--r-- \Device\HarddiskVolume2\Windows\Temp\nbtscan.exe
0x000000003fa633f0      1      0 R--rw- \Device\HarddiskVolume2\Windows\Temp\Rar.exe
0x000000003fc5af80      7      0 R--r-d \Device\HarddiskVolume2\Windows\Temp\Rar.exe
0x000000003df31038      8      0 R--r-- \Device\HarddiskVolume2\Windows\Temp\wce.exe
0x000000003e25eca8      5      0 R--r-d \Device\HarddiskVolume2\Windows\Temp\wce.exe
0x000000003eca37f8      8      0 -W-r-- \Device\HarddiskVolume2\Windows\Temp\w.tmp
It is always a good idea to dump suspicious looking files, calculate their hash and look em up on VT or similar for threat intelligence and/or to understand tool’s usage. This helps in shaping up a hypothesis about what were the activities carried out by the intruder on the host.
$ file file.None.0x8* | sort -k2
file.None.0x83eda598.dat: ASCII text, with CRLF line terminators
file.None.0x8587fef0.dat: ASCII text, with CRLF line terminators
file.None.0x85b684b0.dat: ASCII text, with CRLF line terminators
file.None.0x85cf87d8.dat: ASCII text, with CRLF line terminators
file.None.0x85d0ed60.dat: ASCII text, with CRLF line terminators
file.None.0x83ec85d8.dat: data
file.None.0x83e64960.img: PE32 executable (console) Intel 80386, for MS Windows
file.None.0x8407be50.dat: PE32 executable (console) Intel 80386, for MS Windows
file.None.0x84e2def8.dat: PE32 executable (console) Intel 80386, for MS Windows
file.None.0x85b2c008.img: PE32 executable (console) Intel 80386, for MS Windows
file.None.0x85b3e508.img: PE32 executable (console) Intel 80386, for MS Windows
file.None.0x85b3e620.img: PE32 executable (console) Intel 80386, for MS Windows
file.None.0x85c0d4f0.dat: PE32 executable (console) Intel 80386, for MS Windows
file.None.0x85d12b18.dat: PE32 executable (GUI) Intel 80386, for MS Windows

file.None.0x85d1c6c0.img: PE32 executable (GUI) Intel 80386, for MS Windows







To look for evidence of code injection, the plugins which are usually used are malfind, malfinddeep and hollowfind. However, from the first look at the output of pstree plugin, I could see a cmd.exe child process spawned by an iexplore.exe parent process. This can happen due to some reasons: either there is a browser helper object (BHO) or IE add-on installed or an exploitation of the browser or some component of browser has resulted in remote code execution and a shell is spawned by shellcode in memory of the process, or it could be an instance of malicious code injection inside iexplore.exe and running malicious code. I investigated further by running hollowfind and I could see that the same process id (2996) was seen in the results of these plugins.

The discrepancy between base address from VAD (kernel) point of view and PEB point of view indicates that this could be a hollowed process. 0x12d0000 from VAD (try ldrmodules plugin) and 0x13400000 from PEB (try dlllist plugin). This basically means that the baseaddress of the loaded binary iexplore.exe in memory is told to be different by PEB and VAD outputs.
The next thing I did was to dump the hollowed process 2996 (iexplore.exe) by using “procdump” plugin and calculated the hash and looked up the hash in VT and we can see that it is Xrat. Could mean that once the malicious file initially downloaded by phished user and was executed, it started iexplore.exe process in suspended mode, hollowed it and injected itself inside the suspended process and then resumed the suspended thread from the new offset. Since this is a RAT (Remote Access Tool), it would have provided remote access to the intruder who would have issued a command to spawn a cmd.exe and therefore we see cmd.exe as the child process of the iexplore.exe.  

Pstree ouput

$ sudo -f Target1-1dd8701f.vmss --profile=Win7SP0x86 hollowfind

Hollowed Process Information:
        Process: iexplore.exe PID: 2996
        Parent Process: NA PPID: 2984
        Creation Time: 2015-10-09 11:31:27 UTC+0000
        Process Base Name(PEB): iexplore.exe
        Command Line(PEB): "C:\Program Files\Internet Explorer\iexplore.exe"
        Hollow Type: Process Base Address and Memory Protection Discrepancy

VAD and PEB Comparison:
        Base Address(VAD): 0x12d0000
        Process Path(VAD): \Program Files\Internet Explorer\iexplore.exe
        Vad Protection: PAGE_EXECUTE_WRITECOPY
        Vad Tag: Vad

        Base Address(PEB): 0x13400000
        Process Path(PEB): C:\Program Files\Internet Explorer\iexplore.exe
        Memory Protection: PAGE_READWRITE
        Memory Tag: VadS

$ mkdir 2996
sansforensics@siftworkstation -> ~/D/m/G/target1
$ sudo -f Target1-1dd8701f.vmss --profile=Win7SP0x86 memdump -p 2996 -D 2996/
Volatility Foundation Volatility Framework 2.6
Writing iexplore.exe [  2996] to 2996.dmp
sansforensics@siftworkstation -> ~/D/m/G/target1
$ sudo -f Target1-1dd8701f.vmss --profile=Win7SP0x86 procdump -p 2996 -D 2996/
Volatility Foundation Volatility Framework 2.6
Process(V) ImageBase  Name                 Result
---------- ---------- -------------------- ------
0x85d0d030 0x13400000 iexplore.exe         OK: executable.2996.exe

$ md5sum executable.2996.exe

bdb1570310f44eeff0368057a687a3ab  executable.2996.exe

$ strings executable.2996.exe | more

I used the printkey plugin to print out the autorun registry key used by a lot of malicious code to remain persistent on the compromised host. I can see the persistence value in the key called “MrRobot”. It seems to be pointing to the Anyconnectinstaller.exe binary.

$ sudo -f Target1-1dd8701f.vmss --profile=Win7SP0x86 printkey -K "Software\Microsoft\Windows\CurrentVersion\Run"

REG_EXPAND_SZ MrRobot         : (S) c:\users\anyconnect\AnyConnect\AnyConnectInstaller.exe
Registry: \??\C:\Users\Administrator.front-desk-PC\ntuser.dat
Key name: Run (S)

Last updated: 2015-10-09 06:33:42 UTC+0000

Since the Q6 is asking about CnC server, I first wanted to check out netscan output and I can see the previously discovered malicious process 2996 (iexplore.exe) making an outbound connection to on port 22. I decided to dump the memory space of this process and look for suspicious strings. I know that the password will be in memory space of this process as this process is responsible for communicating with the C2 server. I noticed several suspicious keywords and it turns out that one of them “GrrCon2015” was the password.

I am sure there must be a more efficient way to reach to this password though.

$ sudo -f Target1-1dd8701f.vmss --profile=Win7SP0x86 netscan

0x3e0eedf8         TCPv4          ESTABLISHED      2996     iexplore.exe

$ strings 2996.dmp | grep -i 180.76 -A150 -B150 | sort | uniq -c | sort -n -k1

Q7 is asking about the mutex, which is created by the malware. I used the handles plugin to find various kind of handles which the process 2996 has created. I looked specifically for Mutants and I could see some candidates. “fsociety0.dat” is the mutex. -f Target1-1dd8701f.vmss --profile=Win7SP0x86 pstree

$ -f Target1-1dd8701f.vmss --profile=Win7SP0x86 -p 2996 handles | sort -k5

Q8 is  pretty open question. In such cases we might have to try various plugins and look at the output to find the answer. The output of cachedump showed a user “zerocool” whose domain cache was dumped. Zerocool is a character from the 1995 “Hackers” movie. I was not aware of this movie ;)
$ -f Target1-1dd8701f.vmss --profile=Win7SP0x86 cachedump

Using hashdump I got the NTLM password hash for the Administrator account.
$ -f Target1-1dd8701f.vmss --profile=Win7SP0x86 hashdump

When an intruder attain a shell into the compromised host, they usually execute various commands, perform internal recon, upload their toolset, perform lateral movement etc. Cmd.exe is the native shell usually used by intruder to run commands that is why cmdscan plugin can shows us the commands executed on the shell and consoles plugin shows us the commands and the entire screen buffer (input and output). Since the intruder executed the command “dir.exe” after uploading their toolset on to the compromised host, we can see the contents of the Windows\Temp folder where intruder uploaded their tools to and we can see the files existing on this folder.
$ -f Target1-1dd8701f.vmss --profile=Win7SP0x86 consoles

Once the intruder dumps the credentials, they intend to use them for lateral movement or for defence evasion. Again we can use consoles plugin to see what were the credentials dumped.
$ -f Target1-1dd8701f.vmss --profile=Win7SP0x86 consoles


There is a cool plugin called “mftparser” which can be used to carve out MFT records from the memory. I used this plugin and grepped for nbtscan keyword and found out the MACB timestamps

$ -f Target1-1dd8701f.vmss --profile=Win7SP0x86 mftparser | grep -i nbtscan

2015-10-09 10:45:12 UTC+0000

This was pretty straightforward. Used filescan and grepped for nbs to identify physical offset in memory. Dumped the file and then cat it to see the first entry in the file.
$ cat filescan.txt | grep -i nbs

0x000000003fdb7808      8      0 -W-r-- \Device\HarddiskVolume2\Windows\Temp\nbs.txt

Q14 was answered from the analysis of netscan plugin output and we knew that 2996 PID was malicious and it was communicating with the following ip on ssh. This is the C2 ip address and port.

From the output of process plugins we could see that teamviewer was running. Usually to maintain secondary access to the environment, the intruders can use secondary backdoors, legitimate software like remote access software or legit channels like VPN or even inbound RDP.


 I used the netscan plugin to identify the connection to on port 3389 (RDP) from the compromised host.

The intruder used wce to dump cred from memory and used the dumped credentials to move laterally. I used mftparser plugin to understand the various artifacts around the intrusion timestamp and I could see that nearby wce.exe a file called w.tmp was created in an abnormal location. I then used filescan plugin to get the physical offset of the file w.tmp and used dumpfiles to dump this file. The file contained the clear text password of the user Gideon.

$ -f target2-6186fe9f.vmss --profile=Win7SP0x86 dumpfiles -D dumpfiles/ --physoffset=0x000000003fcf2798

 Could not solve this one.

Next, were set of questions related to target2 memory image

The question is asking us about an intrusion activity and that is why we run the consoles plugin and we can see the rar tool used to zip all text files present in the working directory to a rar file named “crownjewlez.rar”

$ -f target2-6186fe9f.vmss  --profile=Win7SP0x86 consoles

So we know from the output of consoles the name of the rar files and that all files with extension .txt were part of the rar archive and the rar was password protected. What I did next was to list the processes and find all conhost processes. These processes are console host processes and are spawned for every cmd.exe and these are container processes. I have high chance of getting further information from the memory space of these processes. I string searched the memory space of the process PID 3048 (but used “l” encoding for UTF encoded strings). I was able to find the name of all the .txt files which were added to the rar archive.

Cmd #16 @ 0xf2478: rar crownjewlez.rar *.txt -hp123qwe!@#
Cmd #17 @ 0xf24d0: rar a -hp123!@#qwe crownjewlez.rar *.txt

$ -f target2-6186fe9f.vmss --profile=Win7SP0x86 pslist | sort -k2

$ strings --encoding=l 3048.dmp | grep -i crown

Again for answering such questions, we can try to discover malicious artifacts around the time of intruder activities and discover additional files dropped/created etc. This can be done using the filescan plugin. I was able to see the at1.job file created under the tasks folder. This is a scheduled task created using at.exe. We can also see some event created in the windows event logs taskscheduler/operational. I was able to dump this file and look at its content, which clearly shows the file 1.bat to be executed.  

The following set of questions now pertain to the memory image from a machine pos01.

So to answer this question I used the netscan plugin. I found the following outbound network connections to public ips. However this was not sufficient to answer the question. I went with executing malfind plugin to discover that there is code injection in process 3208 (iexplore.exe). This behavior also matched with what we saw earlier while analyzing target2, where iexplore.exe was hollowed out and malicious code injected in it. These facts can be used as substantial evidence and we can say that the ip is the C2 server.

0x3e135df8         TCPv4            CLOSE_WAIT       3208     iexplore.exe
0x3e24c7d0         TCPv4         CLOSE_WAIT       2464     jusched.exe
0x3e611b10         TCPv4    -:49887               CLOSED           536      lsass.exe
0x3ed37490         TCPv4    -:58752                     CLOSED           1116     svchost.exe
0x3f1461d8         TCPv4    -:58753                 CLOSED           1116     svchost.exe
Malfind output:
$ -f POS-01-c4e8f786.vmss --profile=Win7SP0x86 malfind
·        Process: iexplore.exe Pid: 3208 Address: 0x50000
Flags: CommitCharge: 11, MemCommit: 1, PrivateMemory: 1, Protection: 6

0x00050000  4d 5a 90 00 03 00 00 00 04 00 00 00 ff ff 00 00   MZ..............
0x00050010  b8 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00   ........@.......
0x00050020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0x00050030  00 00 00 00 00 00 00 00 00 00 00 00 d8 00 00 00   ................


To answer this question, this time I used the shimcachemem plugin to see execution evidence of malware. I was able to find the following binary allsafe_update.exe executed from Downloads folder under user “pos”. Using filescan plugin I discovered the following binary kdcpr.exe under appdata folder. These were good candidates for further investigation. I also grepped the keyword allsafe from the filescan output and discovered further pieces of evidence, including potential data exfiltrated (AllSafeCustomerData.csv and AllSafeCustomerData.txt files). I can also see that the same file name allsafe_update.exe under the IE temporary internet files, which is in line with the execution of the file with same name allsafe_update.exe from Downloads folder. I used the dumpfiles plugin to extract the allsafeupdate.exe and kdcpr.exe binaries from memory. I calculates the hash for these files and looked the hash up in VT showing me that this is the Dexter PoS malware.

$ -f POS-01-c4e8f786.vmss --profile=Win7SP0x86 shimcachemem | sort -k2

    3 2015-10-09 12:35:54                         True                  \??\C:\Users\pos\Downloads\allsafe_update.exe
    2 2015-10-09 12:35:57                         True                  \??\C:\Users\pos\Downloads\allsafe_update.exe
$ -f POS-01-c4e8f786.vmss --profile=Win7SP0x86 filescan | sort -k5 >> filescan.txt

0x000000003e786960      2      0 RWD--- \Device\HarddiskVolume2\Users\pos\AppData\Roaming\kdcpr\kdcpr.exe
0x000000003f0647c0      2      0 RW-rwd \Device\HarddiskVolume2\Users\pos\AppData\Roaming\kdcpr\kdcpr.exe

$ cat filescan.txt | grep -i allsafe

0x000000003fda7ee8      8      0 RW-r-- \Device\HarddiskVolume2\Users\Administrator\Desktop\AllSafeCusto
0x000000003e03ea40      1      1 RW-r-- \Device\HarddiskVolume2\Users\Administrator\Desktop\AllSafeCustomerData.csv
0x000000003fd8cc30      8      0 RW-rw- \Device\HarddiskVolume2\Users\Administrator\Desktop\AllSafeCustomerData.csv
0x000000003e5f9f80      1      1 RW-r-- \Device\HarddiskVolume2\Users\Administrator\Desktop\AllSafeCustomerData.txt
0x000000003fd56038      1      1 R--rw- \Device\HarddiskVolume2\Users\Administrator\Desktop\AllSafeCustomerData.txt
0x000000003fdd7f80      2      1 R--rw- \Device\HarddiskVolume2\Users\Administrator\Desktop\AllSafeCustomerData.txt
0x000000003e6f9bc0     14      6 RW-r-- \Device\HarddiskVolume2\Users\pos\AppData\Local\Microsoft\Outlook\
0x000000003fc9ff80      5      0 RW-r-- \Device\HarddiskVolume2\Users\pos\AppData\Local\Microsoft\Outlook\
0x000000003ecf1280      6      1 RW-rw- \Device\HarddiskVolume2\Users\pos\AppData\Local\Microsoft\Outlook\
0x000000003e7ab038      8      0 -W-rwd \Device\HarddiskVolume2\Users\pos\AppData\Local\Microsoft\Windows\Temporary Internet Files\Low\Content.IE5\NEQ2CLDX\allsafe_update[1].exe

$ -f POS-01-c4e8f786.vmss --profile=Win7SP0x86 dumpfiles -D . --physoffset=0x000000003e786960
Volatility Foundation Volatility Framework 2.6
DataSectionObject 0x3e786960   None   \Device\HarddiskVolume2\Users\pos\AppData\Roaming\kdcpr\kdcpr.exe
sansforensics@siftworkstation -> ~/D/m/G/pos01
$ -f POS-01-c4e8f786.vmss --profile=Win7SP0x86 dumpfiles -D . --physoffset=0x000000003f0647c0
Volatility Foundation Volatility Framework 2.6
DataSectionObject 0x3f0647c0   None   \Device\HarddiskVolume2\Users\pos\AppData\Roaming\kdcpr\kdcpr.exe

$ md5sum file.None.0x85a3*
99349d277cc5bcb138f4239151fb8370  file.None.0x85a37988.dat
b05e889e8436ed89157a2aa0cb8cdaa6  file.None.0x85a38d60.dat

$ -f POS-01-c4e8f786.vmss --profile=Win7SP0x86 dumpfiles -D . --physoffset=0x000000003e6f9bc0
Volatility Foundation Volatility Framework 2.6
DataSectionObject 0x3e6f9bc0   None   \Device\HarddiskVolume2\Users\pos\AppData\Local\Microsoft\Outlook\
SharedCacheMap 0x3e6f9bc0   None   \Device\HarddiskVolume2\Users\pos\AppData\Local\Microsoft\Outlook\
sansforensics@siftworkstation -> ~/D/m/G/pos01
$ -f POS-01-c4e8f786.vmss --profile=Win7SP0x86 dumpfiles -D . --physoffset=0x000000003fc9ff80
Volatility Foundation Volatility Framework 2.6
DataSectionObject 0x3fc9ff80   None   \Device\HarddiskVolume2\Users\pos\AppData\Local\Microsoft\Outlook\
SharedCacheMap 0x3fc9ff80   None   \Device\HarddiskVolume2\Users\pos\AppData\Local\Microsoft\Outlook\
sansforensics@siftworkstation -> ~/D/m/G/pos01
$ -f POS-01-c4e8f786.vmss --profile=Win7SP0x86 dumpfiles -D . --physoffset=0x000000003ecf1280
Volatility Foundation Volatility Framework 2.6
DataSectionObject 0x3ecf1280   None   \Device\HarddiskVolume2\Users\pos\AppData\Local\Microsoft\Outlook\
sansforensics@siftworkstation -> ~/D/m/G/pos01
$ -f POS-01-c4e8f786.vmss --profile=Win7SP0x86 dumpfiles -D . --physoffset=0x000000003e7ab038
Volatility Foundation Volatility Framework 2.6
DataSectionObject 0x3e7ab038   None   \Device\HarddiskVolume2\Users\pos\AppData\Local\Microsoft\Windows\Temporary Internet Files\Low\Content.IE5\NEQ2CLDX\allsafe_update[1].exe

13af79a3e133ebdff13117d2f55577af  file.None.0x83fb1568.dat
d41d8cd98f00b204e9800998ecf8427e  file.None.0x84efd2a8.vacb
99349d277cc5bcb138f4239151fb8370  file.None.0x8559cf78.dat

Q24 was a bit tricky to understand. I remember from the little malware analysis experience I have is that sometimes there is a list of process names, which are stored by malware as a list (whitelist list) and this list is then checked periodically against running processes. If any additional process is seen executed, it is terminated by the malware. This is for anti-analysis purpose. I simply ran strings command on the Dexter malware and I could conveniently see the list of processes, which were whitelisted by malware. This included allsafe_protector.exe, which is the answer to this question.

This is an interesting question. To answer this I need to find out the initial infection vector (IIV). The best way to do this is to run the mftparser plugin and to trace back to IIV. I exported mftparser output into a csv file and while tracing back I discovered two potential scenarios. Either download of allsafe_update.exe as it can be seen in the IE temporary files, which lead to infection. Or, execution of ssvagent.exe binary lead to the infection. However, correlating the output with previous findings supports the IIV that allsafe_update.exe downloaded and executed resulted in the infection.

$ -f POS-01-c4e8f786.vmss --profile=Win7SP0x86 mftparser --output=body -D . --output-file=pos01.body
$ mactime -b pos01.body -d -z UTC >> pos01.csv 

The following questions are related to the memory image of the MS Exchange server ex01:

The Q26 is basically asking us the name of the webshell which is being used to have remote access to the Exchange server. The webshell is a type of backdoor, which is used by intruder to have remote access on a server hosting a web server. In this case the web server is an IIS server and most probably the webshell will be an aspx file. The first thing I did was to figure out the processes running and to see if any suspicious child process spawned from the IIS server w3wp.exe parent process. I could see the cmd.exe spawned by w3wp.exe, which itself spawns net.exe process. This is definitely suspicious and requires further investigation. Now I want to know more about the cmd.exe and net.exe processes so I executed the plugin called “cmdlines”, which shows the command lines for these processes. It is confirmed that someone is using a webshell to remotely execute commands on the web server. Next, I dumped the memory space of process 5492 w3wp.exe and hunted for keyword “.aspx” (not a very efficient method though). I see a very suspicious keyword “frombase64string” which is base64 decoding a base64 encoded blob. I also see “/owa/auth/error1.aspx” right before this blob. I took this blob and decoded this, which shows that this is part of the malicious code of the webshell, as we can see it is taking parameter from request and executing as a process.

$ -f Ex01-bb228ae5.vmss --profile=Win2012x64 pstree

$ -f Ex01-bb228ae5.vmss --profile=Win2012x64 cmdline

$ -f Ex01-bb228ae5.vmss --profile=Win8SP0x64 -p 5492 -D . memdump

$ strings 5492.dmp | grep -i .aspx -A5 -B5 | more

This question was a bit tricky. First I tried to hunt for IIS logs and see if I can find any requests to error1.aspx webshell. Maybe hunting for the request URI form could help me to help identify the C2 communication pattern of a malware. I could not find anything useful from this approach. Next what I did was that I googled for some keywords from the piece of webshell code I discovered during string search and it pointed me to article on chinachopper webshell.

This is again an open question, which require some thought to be put to device a strategy to answer it. For example, we can go the string way, or do some research on chinachopper and understand how decryption works or we could go the filescan plugin way. The output showed me some files under \owa\auth folder, which contains a file called th3k3y.txt, which gives it away. So I use dumpfiles plugin to dump this file and read the key stored in it. However in real life, we might have to study a malware analysis report for this malware and also maybe reverse the sample in hand to understand what file is it trying to open to read the key from and then hunt for that file.

0x0000000145595070  32768      1 R--rwd \Device\HarddiskVolume2\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\15.0.847
0x0000000136003310  32768      1 R--rwd \Device\HarddiskVolume2\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\15.0.847\scripts
0x0000000119c02f20  32768      1 R--rwd \Device\HarddiskVolume2\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\15.0.847\scripts\premium
0x0000000135ed5560      1      0 R--rwd \Device\HarddiskVolume2\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\15.0.847\scripts\premium\flogon.js
0x00000001f550cf20  32768      1 R--rwd \Device\HarddiskVolume2\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\15.0.847\themes
0x000000003069edb0  32768      1 R--rwd \Device\HarddiskVolume2\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\15.0.847\themes\resources
0x000000006cb04d90      2      0 RW-r-- \Device\HarddiskVolume2\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\th3k3y.txt

$ -f Ex01-bb228ae5.vmss --profile=Win2012R2x64 dumpfiles -D . --physoffset=0x000000006cb04d90
Volatility Foundation Volatility Framework 2.6
DataSectionObject 0x6cb04d90   None   \Device\HarddiskVolume2\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\th3k3y.txt


Some further findings:

Some other findings I made using the mftparser plugin that the crownjewlez.rar file was moved to the Exchange server under the owa\auth\ folder of Exchange server for exfiltration (download by the attacker).


Popular Posts