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.
The images can be downloaded from: https://drive.google.com/drive/folders/0Bz3L4ZnVlUY8ZmFmajQ3TUo0V1k
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.
# vol.py -f Target1-1dd8701f.vmss --profile=Win7SP0x86
pslist
# vol.py -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://180.76.254.120/AnyConnectInstaller.exe)
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 vol.py -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
e4fd2c7a7fe9dc6ec6e9fa825f8100d1:
23a9329505c6eb16840901524ca7bdc9:
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
e5e4fc9e9d06cfc3ed71ddcfa9000f5f
35279818d9f6d3c361613ad66b1d87bf:
d6d466a879120a6cc40ce2a444e1ac41:
f01a9a2d1e31332ed36c1a4d2839f412:
e4fd2c7a7fe9dc6ec6e9fa825f8100d1:
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 vol.py
-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 vol.py -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 vol.py -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 vol.py
-f Target1-1dd8701f.vmss --profile=Win7SP0x86 printkey -K
"Software\Microsoft\Windows\CurrentVersion\Run"
Subkeys:
Values:
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 180.76.254.120 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 vol.py
-f Target1-1dd8701f.vmss --profile=Win7SP0x86 netscan
0x3e0eedf8 TCPv4 10.1.1.20:49205 180.76.254.120:22 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.
vol.py -f
Target1-1dd8701f.vmss --profile=Win7SP0x86 pstree
$ vol.py -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 ;)
$ vol.py -f Target1-1dd8701f.vmss
--profile=Win7SP0x86 cachedump
$ vol.py -f
Target1-1dd8701f.vmss --profile=Win7SP0x86 hashdump
Administrator:500:aad3b435b51404eeaad3b435b51404ee:79402b7671c317877b8b954b3311fa82:::
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.
$ vol.py -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.
$ vol.py -f
Target1-1dd8701f.vmss --profile=Win7SP0x86 consoles
Administrator\front-desk-PC:flagadmin@1234
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
$ vol.py -f
Target1-1dd8701f.vmss --profile=Win7SP0x86 mftparser | grep -i nbtscan
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.
180.76.254.120:22
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.
Teamviewer.exe
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.
$ vol.py -f
target2-6186fe9f.vmss --profile=Win7SP0x86 dumpfiles -D dumpfiles/
--physoffset=0x000000003fcf2798
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”
$ vol.py -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
$ vol.py -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 54.84.237.92 is the C2 server.
0x3e135df8
TCPv4 10.1.1.10:58751 54.84.237.92:80 CLOSE_WAIT 3208
iexplore.exe
0x3e24c7d0 TCPv4 10.1.1.10:49201 23.203.149.112:443 CLOSE_WAIT 2464
jusched.exe
0x3e611b10 TCPv4 -:49887 108.162.232.200:49155
CLOSED 536
lsass.exe
0x3ed37490 TCPv4 -:58752 23.3.96.251:80 CLOSED 1116
svchost.exe
0x3f1461d8 TCPv4 -:58753 108.162.232.201:80 CLOSED 1116
svchost.exe
Malfind
output:
$ vol.py -f
POS-01-c4e8f786.vmss --profile=Win7SP0x86 malfind
·
Process: iexplore.exe Pid: 3208 Address: 0x50000
Vad Tag: VadS Protection: PAGE_EXECUTE_READWRITE
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.
$ vol.py -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
$ vol.py -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\pos@allsafecybersec.com.ost
0x000000003fc9ff80 5
0 RW-r--
\Device\HarddiskVolume2\Users\pos\AppData\Local\Microsoft\Outlook\pos@allsafecybersec.com.ost
0x000000003ecf1280 6
1 RW-rw- \Device\HarddiskVolume2\Users\pos\AppData\Local\Microsoft\Outlook\~pos@allsafecybersec.com.ost.tmp
0x000000003e7ab038 8
0 -W-rwd
\Device\HarddiskVolume2\Users\pos\AppData\Local\Microsoft\Windows\Temporary
Internet Files\Low\Content.IE5\NEQ2CLDX\allsafe_update[1].exe
$ vol.py -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
$ vol.py -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
$ vol.py -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\pos@allsafecybersec.com.ost
SharedCacheMap 0x3e6f9bc0 None
\Device\HarddiskVolume2\Users\pos\AppData\Local\Microsoft\Outlook\pos@allsafecybersec.com.ost
sansforensics@siftworkstation ->
~/D/m/G/pos01
$ vol.py -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\pos@allsafecybersec.com.ost
SharedCacheMap 0x3fc9ff80 None
\Device\HarddiskVolume2\Users\pos\AppData\Local\Microsoft\Outlook\pos@allsafecybersec.com.ost
sansforensics@siftworkstation ->
~/D/m/G/pos01
$ vol.py -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\~pos@allsafecybersec.com.ost.tmp
sansforensics@siftworkstation ->
~/D/m/G/pos01
$ vol.py -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
Dexter malware. Ref: https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/the-dexter-malware-getting-your-hands-dirty/
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.
$ vol.py -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.
$ vol.py -f Ex01-bb228ae5.vmss
--profile=Win2012x64 pstree
$ vol.py -f Ex01-bb228ae5.vmss
--profile=Win2012x64 cmdline
$ vol.py -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
$ vol.py -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
eNpzLypyzs/zyS9LLfYtCspPyi9xzEtxKzZIzkwtqVRUVAQAybULlw==
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).
Comments
Post a Comment