DFIR Research Ideas

I'm enrolled in Champlain College's M.S. in Digital Forensic Science program, and I'm coming up on my capstone research thesis and project, which I'll begin in the Summer of 2016. The intent is to conduct original research, or expand on existing research, into a problem related to the digital forensics or incident response fields.

I'd like to tackle a useful, immediately practical research topic rather than something more academic or theoretical. So, with that, I'm soliciting research ideas from the DFIR community. What problems have you experienced in your work where you thought more research was needed? Have you ever encountered a situation that you wish you had a better understanding of? Are there any emerging technologies or issues you regularly encounter but for which limited research or understanding exists? Ideas might be related to an operating system, and OS artifact, an application, a forensic technique, etc.

I'm aware of the ForensicWiki research topics and Forensic Focus project ideas pages. I'm considering some of those, although they are of varying ages and some may be of lesser relevance than when they were originally proposed.

Please feel free to leave your comments below. There's no reason to be overly detailed; I'm not asking you to do the research for me! Just a brief statement of what you are interested in will suffice. If I use anyone's idea, or a variation thereof, I'll be sure to provide appropriate attribution.

Write-Up of JIIR "Triage Practical – Malware Event – Prefetch $MFT IDS"

Introduction

Corey Harrell (@corey_harrell) recently tweeted about a malware triage challenge he posted on his Journey Into Incident Response (jIIr) blog:

new jIIr post: Triage Practical – Malware Event – Prefetch $MFT IDS https://t.co/2WB8owCw5M <- scenario to practice triaging #DFIR

— Corey Harrell (@corey_harrell) November 23, 2015

In this blog post, Corey provided some context to the scenario and also posed the following questions:

• Is this a confirmed malware security event or was the junior analyst mistaken?
• What type of malware is involved?
• What potential risk does the malware pose to your organization?
• Based on the available information, what do you think occurred on the system to cause the malware event in the first place?

This write-up outlines my analysis of the provided evidence files and answers to Corey's questions. All timestamps are shown in GMT time zone.

Analysis

Processing evidence files

Before getting started, I converted the $MFT to a comma-separated values (CSV) file so that I could view the file in Microsoft Excel and also manipulate it using text parsing tools. First I created a bodyfile from the MFT using analyzeMFT:

$ analyzeMFT.py -f \$MFT -b MFT.body --bodyfull

where '-f' designates the file to read from (the '$' must be escaped so that bash shell does not interpret '$MFT' as a variable name), '-b' specifies output in bodyfile format with the output file name, and '--bodyfull' specifies to include full file paths.

I then converted the bodyfile to a CSV using mactime from The Sleuth Kit:

$ mactime -d -b MFT.body -m > MFT.timeline

where '-d' specifies comma-delimited format, '-b' specifies the bodyfile to read from, '-m' designates months in the timestamps as numbers instead of letters and '>' redirects standard output to a file.

All of the other evidence files provided were already in a useable form, so I did not have to process them before using them in my analysis, other than to replay the PCAP through Snort (using Security Onion) to see any generated alerts.

Is this a confirmed malware security event?

In a word, yes. The malware was executed, which installed a keylogger and exfiltrated data to an external FTP server.

Before analyzing the full scope of activity, I wanted to quickly identify any malicious indicator that would suggest further investigation was warranted and to serve as an anchor point from which to pivot for additional analysis. I started with the prefetch files, since if this were really a malware infection, the malware would have executed and I might find this in the prefetch. Additionally, I had a general time frame to look ("early...on August 15, 2015"). I mounted the Prefetch.ad1 file with AccessData's FTK Imager, opened the prefetch with NirSoft's WinPrefetchView utility, then sorted on the "Created Time" column. I quickly found a suspicious looking executable named Overdue Invoice Documents for Payment 082015.exe, shown in Figure 1:

Figure 1: Prefetch file for "Overdue Invoice Documents for Payment 082015.exe".

The following lists the full prefetch file details for this executable:

Process EXE:               OVERDUE%20INVOICE%20DOCUMENTS%20FOR%20PAYMENT%20082015[1].EXE
File Size:                 56,400
Created Time (PF file):    8/15/2015 5:33:58 AM
Modified Time (PF file):   8/15/2015 5:33:58 AM
Last Run Time (EXE file):  8/15/2015 5:33:55 AM
Process Path:              C:\USERS\LAB\APPDATA\LOCAL\MICROSOFT\WINDOWS\TEMPORARY INTERNET FILES\CONTENT.IE5\TSFMVXQM\OVERDUE%20INVOICE%20DOCUMENTS%20FOR%20PAYMENT%20082015[1].EXE
Run Count:                 1
Missing Process:           Yes
Prefetch Filename:         OVERDUE%20INVOICE%20DOCUMENTS-BB3C03FD.pf

This file caught my eye for two reasons. First, the file name suggests it is some sort of document (e.g., a word processing document, spreadsheet, etc.), yet it has an executable file extension. Second, I've seen many phish with "overdue invoice" themes to increase the urgency to open them. In order to confirm what this file was, I searched for the file name in the file hash list provided with the evidence files, and found the following:

MD5: ea0995d9e52a436e80b9ad341ff4ee62
SHA1: 0601740b14494a983ed0281f34443b439855724c
FileName: win7x32.vmdk\Partition 1 [8190MB]\NONAME [NTFS]\[root]\Users\lab\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\TSFMVXQM\Overdue%20Invoice%20Documents%20for%20payment%20082015[1].exe

Searching for this MD5 hash on VirusTotal returned a 44/56 anti-virus detection ratio, a very strong indication that this file is malicious (VirusTotal, 2015). Now, just because a malicious file was downloaded does not mean it was executed or the host was actually compromised. In this case, however, the prefetch for this file shows it was executed on 8/15/2015 at 5:33:55 AM, so we can assume for now the host was probably compromised. 

What type of malware is involved?

Most of the VirusTotal detections refer to this file as a generic Trojan, backdoor, or password stealer. Based on the PCAP provided, however, the malware appears to be the HawkEye Keylogger program, as shown in Figures 2 - 4.

Figure 2: "ET TROJAN HawkEye Keylogger FTP" Snort alert.

Figure 3: HawkEye Keylogger exfiltrating log file via FTP.

Figure 4: Contents of HawkEye Keylogger log file exfiltrated via FTP.

Note that the local system time stamp in the exfiltrated file in Figure 4 is 1:34:15 AM (Local) or 5:34:15 AM GMT, which is only 20 seconds after the malware was executed. I did not find the filename HawkEye_Keylogger_Stealer_Records_WIN-DBO1FC9QSDG 8.15.2015 1:34:20 AM.txt in either the $MFT or file hash list.

Malwr.com (2015) has a sandbox analysis of this specific malware sample (by MD5 hash). I wasn't able to locate any artifacts in the MFT timeline of file hash list similar to those in the Mawlr.com analysis, so the malware may have had some type of cleanup routine. I also did not download the sample from Malwr.com for further static or dynamic analysis since this is just a triage scenario, and I wanted to limit my findings based on the provided evidence files and what I could quickly find through Google searches.

What potential risk does the malware pose to your organization?

This malware poses a very high risk to the organization due to its ability to steal a variety of credentials, which could in turn be used to steal additional data, access other systems, facilitate lateral movement, launch more credible phishing or spear phishing campaigns through compromised email accounts, and a plethora of other possibilities. iSIGHT Partners reported previously on the Hawkeye Keylogger's capabilities (Eitzman, 2015).

What do you think occurred on the system to cause the malware event in the first place?

There is no way to determine with certainty how the malware got on the machine in the first place based on just the information provided. However, I think a reasonable hypothesis is that it was delivered via a phishing email, either as an embedded link or a file attachment. There are at least two reasons that suggest this was a phish: 1) the malware file name is a common them in phishing emails, and 2) the MFT timeline indicates a user on the computer was logged into the Yahoo! Mail web mail service at least three minutes prior to the malware being created on the system. Figure 4 depicts some relevant portions of the MFT timeline showing Yahoo! and Yahoo! Mail artifacts that suggest the user may have been logged into his or her web mail account:

Figure 4: Yahoo! activity in MFT timeline.

The previously mentioned iSIGHT Partners report discusses confirmed Hawkeye Keylogger campaigns that use phish emails with "payment" or "invoice" themes that supports this hypothesis. With that said, it would be necessary to examine this machine's web browsing history and web browsing cache files, and possibly speak to the user to confirm or deny this hypothesis.

I couldn't tell whether any exploits were involved, although this seems like it was a standalone executable, as I did not find any related prefetch information or any other potentially malicious files in the MFT timeline or file hash list (I admit I didn't review the file hash list on its own very thoroughly). Based on the MFT timeline, there was some Java and Adobe application activity before and after the malware was executed that could be related, and the machine was running vulnerable Java version 1.7.0_10 per the Snort alert in Figure 2 and the corresponding transcript in Figure 5. However, it looks like this might just be normal Java/Adobe operation. Additional file system analysis would be required to confirm this.

Figure 5: Transcript showing vulnerable Java version.

Another hypothesis is that the user was redirected during normal web browsing to a site hosting this file. I think this is less likely, as the file name seemed intended for a user to see and manually open it rather than through automated means (redirects, exploit kit, etc.).

References

Eitzman, R. (2015). Hawkeye keylogger campaigns affect multiple industries. Retrieved from http://www.isightpartners.com/2015/06/hawkeye-keylogger-campaigns-affect-multiple-industries/.

Malwr.com. (2015). Analysis of file with MD5 hash ea0995d9e52a436e80b9ad341ff4ee62. Retrieved from https://malwr.com/analysis/ZWU0ZmJmOWE4OGFhNDlhN2EwZmZmM2UyZTc0ODk3MjQ/.

VirusTotal. (2015). Analysis of file with MD5 hash ea0995d9e52a436e80b9ad341ff4ee62. Retrieved from https://www.virustotal.com/en/file/96716cf198502bdeeb0c0fccd8d01e46bccb2d03eaf0537d16f51851333d5247/analysis/.

Solution to Jack Crook's Memory Analysis Challenge

Jack Crook tweeted last month about a memory analysis challenge he put together:

Here's a memory dump related to a webserver compromise I put together a few months ago. Enjoy. #DFIR https://t.co/EfwTiJriLT

— Jack Crook (@jackcr) September 26, 2015

I had prior access to this image and originally put all my analysis findings in a Word document. I finally got around to transferring it to my blog. I apologize for any formatting errors - it's a pain to transfer well-formatted word processing documents to a blog post.

Introduction

The investigation of this host was initiated based on a Windows batch file being created in the C:\Windows directory. This host was at IP address 192.168.56.30; any IP addresses not on the 192.168.56.x network are considered external to this host.

Summary 

On 6/11/2015, an attacker at IP address 58.64.141.245 connected to the Apache Tomcat server on this host and logged in with default Tomcat credentials. The attacker then uploaded a web shell to the server that gave him the ability to execute system commands and upload additional files with Tomcat’s SYSTEM level access.  The attacker uploaded the Windows Credential Editor (WCE) tool and a Windows batch file, then created a Windows scheduled task to execute the batch file, which in turn executed WCE. Credentials for a single administrator account were dumped to a file on the server in a web-accessible directory, and the attacker retrieved this file via an HTTP GET request. No lateral movement to other internal machines was identified, so it is believed this web server was the only machine compromised in this attack. All attacker activity took place on 6/11/2015.

Technical Details

Image md5 hash 

$ md5sum WIN-CEKM08E74HR-20150611-222930.raw

17754bc58dffa7d2887af8ddfae40698

Volatility imageinfo output

$ vol.py –f WIN-CEKM08E74HR-20150611-222930.raw imaginfo

Determining profile based on KDBG search...

          Suggested Profile(s) : VistaSP1x86, Win2008SP1x86, Win2008SP2x86, VistaSP2x86

                     AS Layer1 : IA32PagedMemory (Kernel AS)

                     AS Layer2 : FileAddressSpace (/lr/users/mgregory/WIN-CEKM08E74HR-20150611-222930.raw)

                      PAE type : No PAE

                           DTB : 0x122000L

                          KDBG : 0x8190ac98

          Number of Processors : 1

     Image Type (Service Pack) : 2

                KPCR for CPU 0 : 0x8190b800

             KUSER_SHARED_DATA : 0xffdf0000

           Image date and time : 2015-06-11 22:29:32 UTC+0000

     Image local date and time : 2015-06-11 18:29:32 -0400

Attacker Activity

Initial access.

Based on Apache access logs found in memory strings, the attacker first accessed the web server on June 8th at 18:08:45 and last accessed it on June 11^th at 18:27:51: 

$ grep -C10 "58\.64\.141\.245" strings

<…snip…>

346077722 58.64.141.245 - - [08/Jun/2015:19:38:12 -0400] "GET /webfiles/ HTTP/1.1" 404 969

<…snip…>

210019860 58.64.141.245 - - [11/Jun/2015:18:27:51 -0400] "GET /webfiles/?sort=1&downfile=C%3A%5Cinetpub%5Cwwwroot%5Csm.gif HTTP/1.1" 200 97

<…snip…>

However, the attacker still may have accessed the web server before or after these times since these logs were resident in memory and may not reflect all logs or system activity.

It appears the attacker obtained initial access by logging into a web-facing Apache Tomcat portal with default Tomcat credentials:

525512804 Accept: */*

525512817 Referer: http://192.168.56.30:8080/webfiles/?sort=1&dir=C%3A%5C

525512882 Accept-Language: en-us

525512906 User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0)

525512983 Accept-Encoding: gzip, deflate

525513015 Host: 192.168.56.30:8080

525513041 Connection: Keep-Alive

525513065 Cookie: JSESSIONID=D4BB0A17D08FE321DF87835231D79824

525513123 \nection: Keep-Alive

525513145 Cookie: JSESSIONID=9E2D9B938AD0C27816C03A5CA54F9515

525513198 Authorization: Basic dG9tY2F0OnRvbWNhdA==

The highlighted base64 encoded data in the above HTTP header decodes to the default Tomcat credentials of tomcat:tomcat:

$ echo "dG9tY2F0OnRvbWNhdA==" | base64 -d

tomcat:tomcat

Web shell uploaded.

Next, the attacker uploaded a web shell called “jsp File Browser version 1.2”, likely via the Tomcat interface. Fragments of the web shell are resident in memory as seen below, where you can identify specific commands being executed, such as "dir" and "sort":

$ egrep -i -C20 "jsp file browser" strings.sorted

<…snip…>

196513988       out.write("\t\t<input type=\"hidden\" name=\"sort\" value=\"");

196514130       out.print(sortMode);

196514186       out.write("\">\n");

196514240       out.write("\t\t<input type=\"hidden\" name=\"command\" value=\"\">\n");

196514398       out.write("\t\t<input title=\"Launch command in current directory\" type=\"Submit\" class=\"button\" id=\"but_Lau\" name=\"Submit\" value=\"");

196514700       out.print(LAUNCH_COMMAND);

<…snip…>

196515250       out.write("\t\t<small>jsp File Browser version ");

196515366       out.print( VERSION_NR);

196515428       out.write(" by <a href=\"http://www.vonloesch.de\">www.vonloesch.de</a></small>\n");

196515612       out.write("\t</center>\n");

196515682       out.write("</body>\n");

196515744       out.write("</html>");

<…snip…>

--

<…snip…>

517899879 <body><center>

517899894 <h2>(L)aunch external program</h2><br />

517899935 <form action="/webfiles/" method="Post">

517899976 <textarea name="text" wrap="off" cols="85" rows="30" readonly>

517900040 06:25 PM

517900052 </textarea>

517900064     <input type="hidden" name="dir" value="C:\inetpub\wwwroot">

517900125     <br /><br />

517900139     <table class="formular">

517900165     <tr><td title="Enter your command">

517900202     Command: <input size="80" type="text" name="command" value="">

517900266     </td></tr>

517900278     <tr><td><input class="button" type="Submit" name="Submit" value="Launch">

517900353     <input type="hidden" name="sort" value="1">

517900398     <input type="Submit" class="button" name="Submit" value="Cancel"></td></tr>

517900475     </table>

517900485     </form>

517900494     <br />

517900502     <hr>

517900508     <center>

517900518             <small>jsp File Browser version 1.2 by <a href="http://www.vonloesch.de">www.vonloesch.de</a></small>

517900622     </center>

517900633     </center>

517900644 </body>

517900652 </html>

517900660 /html>

517900670             <input type="file" class="textfield" onKeypress="event.cancelBubble=true;" name="myFile">

517900762             <input title="Upload selected file to the current working directory" type="Submit" class="button" name="Submit" value="Upload"

517900891             onClick="javascript:popUp('/webfiles/')">

517900935     </form>

517900948     <form class="formular2" action="/webfiles/" method="POST">

517901011             <input type="hidden" name="dir" value="C:\Windows">

517901065             <input type="hidden" name="sort" value="1">

517901111             <input type="hidden" name="command" value="">

517901159             <input title="Launch command in current directory" type="Submit" class="button" id="but_Lau" name="Submit" value="(L)aunch external program">

517901303     </form>

517901312     </div> 

This web shell is available at http://www.vonloesch.de/node/31 and has a default file name of “Browser.jsp”; however, the Volatility filescan plugin did not detect this file, and it was not located in the MFT. As seen below, this file name was resident in memory as a string that is also found in the web shell downloaded from the above link, but only in reference to code within the JSP file itself and not actually designating a file:

$ grep –i “browser\.jsp” strings.sorted

61628190         *      @param browserLink web-path to Browser.jsp

63058164                                //If this dir also do also not exist, go back to browser.jsp root path

<…snip…>

Strings output and the MFT listing show a number of other JSP files in the Program Files\Apache Software Foundation\Tomcat 7.0\webapps\webfiles\ directory; however, none of these files were resident in memory so they could not be dumped to see if the attacker simply renamed the web shell. Later HTTP access from the attacker’s IP address to the webfiles directory further indicates this is the location of his web shell. Pivoting off this directory in strings output and the MFT identified a Java Web Application Archive (.war) being deployed on the server at approximately 18:07 (22:07 UTC):

$ grep -i "webfiles" strings.sorted

<…snip…>

99623387 INFO: Deploying web application archive C:\Program Files\Apache Software Foundation\Tomcat 7.0\webapps\webfiles.war

99623578 INFO: Deployment of web application archive C:\Program Files\Apache Software Foundation\Tomcat 7.0\webapps\webfiles.war has finished in 190 ms

<…snip…>

$ grep -i "webfiles" mactimeline.csv

<…snip…>

Thu Jun 11 2015 22:07:04,368,macb,---a-----------,0,0,48015,"[MFT FILE_NAME] Program Files\Apache Software Foundation\Tomcat 7.0\webapps\webfiles.war (Offset: 0x286c00)"

Thu Jun 11 2015 22:07:04,368,macb,---a-----------,0,0,48015,"[MFT STD_INFO] Program Files\Apache Software Foundation\Tomcat 7.0\webapps\webfiles.war (Offset: 0x286c00)"

<…snip…>

Based on this information, it is possible, if not likely, the attacker deployed the web shell via webfiles.war, which in turn was probably uploaded via the Apache Tomcat interface.

Batch file created.

A file named 12.bat was created in C:\Windows on 20150611 at 18:12 (22:12 UTC):

$ grep "12.bat" mactimeline.csv

Thu Jun 11 2015 22:12:16,288,macb,---a-----------,0,0,47995,"[MFT FILE_NAME] Windows\12.bat (Offset: 0x11089650)"

Thu Jun 11 2015 22:12:16,360,macb,---a-----------,0,0,47995,"[MFT FILE_NAME] Windows\12.bat (Offset: 0x11d06c00)"

Thu Jun 11 2015 22:12:16,288,macb,---a-----------,0,0,47995,"[MFT STD_INFO] Windows\12.bat (Offset: 0x11089650)"

Thu Jun 11 2015 22:12:16,360,macb,---a-----------,0,0,47995,"[MFT STD_INFO] Windows\12.bat (Offset: 0x11d06c00)"

The file 12.bat was located in memory and executes a command line utility when executed:

# Find 12.bat physical offset with filescan plugin

$ vol.py –f WIN-CEKM08E74HR-20150611-222930.raw filescan | grep "12.bat"

<…snip…>

0x1ee373f8      8      0 -W-rw- \Device\HarddiskVolume1\Windows\12.bat

# Dump 12.bat with dumpfiles plugin using physical offset

$ vol.py -f WIN-CEKM08E74HR-20150611-222930.raw dumpfiles -Q 0x1ee373f8 -D .

Volatility Foundation Volatility Framework 2.3.1

DataSectionObject 0x1ee373f8   None   \Device\HarddiskVolume1\Windows\12.bat

# get 12.bat hash

$ md5sum file.None.0x8362e730.dat

38f76497a613a14a7600695300e12ce1  file.None.0x8362e730.dat

# View contents of 12.bat

$ cat file.None.0x8362e730.dat

@echo off

c:\inetpub\wwwroot\bg.jpg -e -o c:\inetpub\wwwroot\sm.gif

As seen above, the 12.bat batch file executes a file located in the web server’s web-accessible directory named bg.jpg, followed by command line parameters –e and –o, and finally a path to a file named sm.gif in the same directory. At one point it looks like the attacker checked for the presence of this file before later possibly uploading it via a POST:

$ egrep -i -C20 "12\.bat" strings.sorted

9901378 58.64.141.245 - - [11/Jun/2015:18:12:16 -0400] "GET /webfiles/?first&uplMonitor=C%3A%5Cfakepath%5C12.bat HTTP/1.1" 200 865

Scheduled task created.

The fact that bg.jpg was launched as a scheduled task is further indicated by the fact bg.jpg is a child process of cmd.exe, which in turn is a child process of taskeng.exe (see pstree output above). The scheduled task (At job) was resident in memory:

# the highlighted “0” exit code indicates the command was successful

$ vol.py -f WIN-CEKM08E74HR-20150611-222930.raw filescan | grep -i "At1.job"

Volatility Foundation Volatility Framework 2.3.1

0x1f297ad8      8      0 -W-r-d \Device\HarddiskVolume1\Windows\Tasks\At1.job

$ vol.py -f WIN-CEKM08E74HR-20150611-222930.raw dumpfiles -Q 0x1f297ad8 -D .

Volatility Foundation Volatility Framework 2.3.1

DataSectionObject 0x1f297ad8   None   \Device\HarddiskVolume1\Windows\Tasks\At1.job

$ strings -el file.None.0x8363fd10.dat

c:\windows\12.bat

SYSTEM

Created by NetScheduleJobAdd.

Strings ouput of At1.job (file.None.0x8363fd10.dat) shows that this scheduled task is set to execute the 12.bat file with SYSTEM credentials, which in turn executes bg.jpg (WCE). Windows Task Scheduler errored out when trying to open this At job to view the actual time the job was scheduled to run, although further metadata could possibly be parsed with a script written to interpret the file format (I tried Harlan Carvey’s jobparse.pl script, but that too had errors and was unsuccessful). This shows how the attacker was able to execute bg.jpg. It’s not entirely clear how the attacker was able to run tasking.exe or at.exe to create the At job in the first place, but it was likely via system command execution either via the Tomcat interface or the attacker’s web shell. There were no at.exe command line arguments found.

The Windows Task Scheduler log (Schedlgu.txt) was also resident in memory; however, it contained no record of executing 12.bat or bg.jpg:

$ vol.py -f WIN-CEKM08E74HR-20150611-222930.raw filescan | grep -i "schedlgu.txt"

Volatility Foundation Volatility Framework 2.3.1

0x1f22da78     10      1 RW-r-- \Device\HarddiskVolume1\Windows\Tasks\SCHEDLGU.TXT

$ vol.py -f WIN-CEKM08E74HR-20150611-222930.raw dumpfiles -Q 0x1f22da78 -D .

Volatility Foundation Volatility Framework 2.3.1

DataSectionObject 0x1f22da78   None   \Device\HarddiskVolume1\Windows\Tasks\SCHEDLGU.TXT

SharedCacheMap 0x1f22da78   None   \Device\HarddiskVolume1\Windows\Tasks\SCHEDLGU.TXT

$ cat file.None.0x8322d7e0.dat | grep -i "bg\.jpg|12\.bat"

<no_output>

Credentials dumped.

The file bg.jpg is a running process based on pstree output. It was executed with the same command line arguments found in 12.bat:

$ vol.py -f WIN-CEKM08E74HR-20150611-222930.raw pstree -v | grep -C10 bg\.jpg

<---snip--->

..... 0x8362fca0:bg.jpg                              3580   3572      1     61 2015-06-11 22:25:00 UTC+0000

         audit: \Device\HarddiskVolume1\inetpub\wwwroot\bg.jpg

         cmd: c:\inetpub\wwwroot\bg.jpg  -e -o c:\inetpub\wwwroot\sm.gif

         path: c:\inetpub\wwwroot\bg.jpg

bg.jpg was also located in memory and is actually the Windows Credential Editor (WCE) tool:

# find bg.jpg physical offset

$ vol.py -f WIN-CEKM08E74HR-20150611-222930.raw filescan | grep "bg.jpg"

Volatility Foundation Volatility Framework 2.3.1

0x1ede1ba0      8      0 -W-rw- \Device\HarddiskVolume1\inetpub\wwwroot\bg.jpg

0x1f2dc170      7      0 R--r-d \Device\HarddiskVolume1\inetpub\wwwroot\bg.jpg

# dump bg.jpg using physical offset

$ vol.py -f WIN-CEKM08E74HR-20150611-222930.raw dumpfiles -Q 0x1f2dc170 -D .

Volatility Foundation Volatility Framework 2.3.1

ImageSectionObject 0x1f2dc170   None   \Device\HarddiskVolume1\inetpub\wwwroot\bg.jpg

DataSectionObject 0x1f2dc170   None   \Device\HarddiskVolume1\inetpub\wwwroot\bg.jpg

# verify file type

$ file file.None.0x8362fb20.img

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

# get md5 hash of file

$ md5sum file.None.0x8362fb20.img

0bfb070177356c0905f013416aba1af1  file.None.0x8362fb20.img

# strings in file indicate this is the WCE tool

$ strings file.None.0x8362fb20.img

<…snip…>

%.2X

something terrible happened! could not allocate memory for new list!

WCE %s (Windows Credentials Editor) - (c) 2010,2011,2012 Amplia Security - by Hernan Ochoa (hernan@ampliasecurity.com)

Use -h for help.

Options: 

        -l              List logon sessions and NTLM credentials (default).

                        Optional: -r<refresh interval>.

        -s              Changes NTLM credentials of current logon session.

                        Parameters: <UserName>:<DomainName>:<LMHash>:<NTHash>.

        -o              saves all output to a file.

bg.jpg can also be seen in the running processes:

$ vol.py –f WIN-CEKM08E74HR-20150611-222930.raw pstree

. 0x83139650:services.exe                             596    520      6    234 2015-06-11 22:05:29 UTC+0000

<---snip--->

.. 0x831bb8b8:svchost.exe                             876    596      7    244 2015-06-11 22:05:39 UTC+0000

.. 0x831e5820:svchost.exe                            1012    596     30    781 2015-06-11 22:05:40 UTC+0000

... 0x82a3f530:taskeng.exe                           2448   1012      9    226 2015-06-11 22:27:17 UTC+0000

... 0x83116ad8:wuauclt.exe                           3360   1012      2    142 2015-06-11 22:27:32 UTC+0000

... 0x835913b8:taskeng.exe                           2032   1012      6    141 2015-06-11 22:05:59 UTC+0000

.... 0x830e9d90:cmd.exe                              3572   2032      1     17 2015-06-11 22:25:00 UTC+0000

..... 0x8362fca0:bg.jpg                              3580   3572      1     61 2015-06-11 22:25:00 UTC+0000

Although it is apparent based on strings and command line parameters that the file bg.jpg is the WCE tool, the file’s md5 hash was not found in VirusTotal or via a Google search. Based on the WCE documentation, the command line options used to execute bg.jpg were to continuously dump NTLM credentials (-e option) and to save the dump file to c:\inetpub\wwwroot\sm.gif (-o option).

Dumped credentials retrieved.

The attacker connected to the web server from IP address 58.64.141.245 and retrieved the dumped credentials (sm.gif) via a GET request, as shown in the below Apache log:

210018644 58.64.141.245 - - [11/Jun/2015:18:27:51 -0400] "GET /webfiles/?sort=1&downfile=C%3A%5Cinetpub%5Cwwwroot%5Csm.gif HTTP/1.1" 200

Based on the MFT, the first and only access of the file bg.jpg occurred on 20150611 at 18:09 (22:09 UTC):

$ vol.py egrep -i -C10 "bg.jpg" mactimeline.csv

<…snip…>

Thu Jun 11 2015 22:09:26,360,macb,---a-----------,0,0,48038,"[MFT FILE_NAME] inetpub\wwwroot\bg.jpg (Offset: 0x136fa800)"

Thu Jun 11 2015 22:09:26,360,macb,---a-----------,0,0,48038,"[MFT FILE_NAME] inetpub\wwwroot\bg.jpg (Offset: 0x1ef2d800)"

Thu Jun 11 2015 22:09:26,360,macb,---a-----------,0,0,48038,"[MFT STD_INFO] inetpub\wwwroot\bg.jpg (Offset: 0x136fa800)"

Thu Jun 11 2015 22:09:26,360,macb,---a-----------,0,0,48038,"[MFT STD_INFO] inetpub\wwwroot\bg.jpg (Offset: 0x1ef2d800)"

Thu Jun 11 2015 22:09:55,344,m.c.,---a-----------,0,0,30461,"[MFT STD_INFO] Windows\System32\spool\spooler.xml (Offset: 0x2d66400)"

<…snip…>

This correlates to Apache logs showing this file being accessed at 18:09, which appears to be the file being uploaded via a POST request to /webfiles followed by an immediate download via a GET request, likely to verify the upload was successful, which it was as indicated by the 200 response code:

$ egrep -i -C20 "GET|POST" strings.sorted | egrep -i -C10 "bg.jpg"

9900047 58.64.141.245 - - [11/Jun/2015:18:08:41 -0400] "GET /webfiles/?Javascript HTTP/1.1" 200 3714

9900141 58.64.141.245 - - [11/Jun/2015:18:08:45 -0400] "GET /webfiles/?sort=1&dir=C%3A%5Cinetpub HTTP/1.1" 200 8270

9900250 58.64.141.245 - - [11/Jun/2015:18:08:45 -0400] "GET /webfiles/?Javascript HTTP/1.1" 200 3714

9900344 58.64.141.245 - - [11/Jun/2015:18:08:50 -0400] "GET /webfiles/?sort=1&dir=C%3A%5Cinetpub%5Cwwwroot HTTP/1.1" 200 8098

9900463 58.64.141.245 - - [11/Jun/2015:18:08:50 -0400] "GET /webfiles/?Javascript HTTP/1.1" 200 3714

9900681 58.64.141.245 - - [11/Jun/2015:18:09:26 -0400] "POST /webfiles/ HTTP/1.1" 200 8973

9900557 58.64.141.245 - - [11/Jun/2015:18:09:26 -0400] "GET /webfiles/?first&uplMonitor=C%3A%5Cfakepath%5Cbg.jpg HTTP/1.1" 200 865

9900681 58.64.141.245 - - [11/Jun/2015:18:09:26 -0400] "POST /webfiles/ HTTP/1.1" 200 8973

9900765 58.64.141.245 - - [11/Jun/2015:18:09:26 -0400] "GET /webfiles/?Javascript HTTP/1.1" 200 3714

9900859 58.64.141.245 - - [11/Jun/2015:18:09:28 -0400] "GET /webfiles/?uplMonitor=C%3A%5Cfakepath%5Cbg.jpg HTTP/1.1" 200 574

9900977 58.64.141.245 - - [11/Jun/2015:18:11:59 -0400] "GET /webfiles/?sort=1&dir=C%3A%5C HTTP/1.1" 200 13384

9901080 58.64.141.245 - - [11/Jun/2015:18:11:59 -0400] "GET /webfiles/?Javascript HTTP/1.1" 200 3714

9901174 58.64.141.245 - - [11/Jun/2015:18:12:01 -0400] "GET /webfiles/?sort=1&dir=C%3A%5CWindows HTTP/1.1" 200 48086

9901284 58.64.141.245 - - [11/Jun/2015:18:12:01 -0400] "GET /webfiles/?Javascript HTTP/1.1" 200 3714

9901378 58.64.141.245 - - [11/Jun/2015:18:12:16 -0400] "GET /webfiles/?first&uplMonitor=C%3A%5Cfakepath%5C12.bat HTTP/1.1" 200 865

9901502 58.64.141.245 - - [11/Jun/2015:18:12:16 -0400] "POST /webfiles/ HTTP/1.1" 200 48896

9901587 58.64.141.245 - - [11/Jun/2015:18:12:16 -0400] "GET /webfiles/?Javascript HTTP/1.1" 200 3714

9901681 58.64.141.245 - - [11/Jun/2015:18:12:18 -0400] "GET /webfiles/?uplMonitor=C%3A%5Cfakepath%5C12.bat HTTP/1.1" 200 574

9901799 58.64.141.245 - - [11/Jun/2015:18:12:42 -0400] "POST /webfiles/ HTTP/1.1" 200 2245

9901883 58.64.141.245 - - [11/Jun/2015:18:13:16 -0400] "POST /webfiles/ HTTP/1.1" 200 2278

Windows event logs.

I was able to extract and open the Windows Security event log (*.evtx) from the memory image, but analysis of this log is not included here. The Windows Application and System event logs extracted from the memory image were corrupted, and Windows Event Viewer could not open them (I didn't attempt to parse them with any other tools, such as log2timeline).

Lateral movement.

There were no other internal or external connections identified; therefore, no lateral movement is believed to have occurred. The following is the complete Volatility netscan plugin output showing only the connection from the attacker’s external IP address:

$ vol.py -f WIN-CEKM08E74HR-20150611-222930.raw netscan

Volatility Foundation Volatility Framework 2.3.1

Offset(P)  Proto    Local Address                  Foreign Address      State            Pid      Owner          Created

0x1ed95048 TCPv4    0.0.0.0:445                    0.0.0.0:0            LISTENING        4        System        

0x1ed95048 TCPv6    :::445                         :::0                 LISTENING        4        System        

0x1edd4848 TCPv4    0.0.0.0:49157                  0.0.0.0:0            LISTENING        596      services.exe  

0x1edd4848 TCPv6    :::49157                       :::0                 LISTENING        596      services.exe  

0x1edd7498 TCPv4    0.0.0.0:49157                  0.0.0.0:0            LISTENING        596      services.exe  

0x1ede2638 TCPv4    0.0.0.0:8009                   0.0.0.0:0            LISTENING        1728     Tomcat7.exe   

0x1ede2638 TCPv6    :::8009                        :::0                 LISTENING        1728     Tomcat7.exe   

0x1ede2f60 TCPv4    0.0.0.0:8080                   0.0.0.0:0            LISTENING        1728     Tomcat7.exe   

0x1ede2f60 TCPv6    :::8080                        :::0                 LISTENING        1728     Tomcat7.exe   

0x1edf2f60 TCPv4    127.0.0.1:8005                 0.0.0.0:0            LISTENING        1728     Tomcat7.exe   

0x1f0db3d0 TCPv4    192.168.56.30:139              0.0.0.0:0            LISTENING        4        System        

0x1f1c0158 TCPv4    0.0.0.0:135                    0.0.0.0:0            LISTENING        876      svchost.exe   

0x1f1c0158 TCPv6    :::135                         :::0                 LISTENING        876      svchost.exe   

0x1f1c0e70 TCPv4    0.0.0.0:135                    0.0.0.0:0            LISTENING        876      svchost.exe   

0x1f1c43a0 TCPv4    0.0.0.0:49152                  0.0.0.0:0            LISTENING        520      wininit.exe   

0x1f1c43a0 TCPv6    :::49152                       :::0                 LISTENING        520      wininit.exe   

0x1f1c5008 TCPv4    0.0.0.0:49152                  0.0.0.0:0            LISTENING        520      wininit.exe   

0x1f1df188 TCPv4    0.0.0.0:49153                  0.0.0.0:0            LISTENING        968      svchost.exe   

0x1f1e2eb8 TCPv4    0.0.0.0:49153                  0.0.0.0:0            LISTENING        968      svchost.exe   

0x1f1e2eb8 TCPv6    :::49153                       :::0                 LISTENING        968      svchost.exe   

0x1f22d738 TCPv4    0.0.0.0:49154                  0.0.0.0:0            LISTENING        1012     svchost.exe   

0x1f22e470 TCPv4    0.0.0.0:49154                  0.0.0.0:0            LISTENING        1012     svchost.exe   

0x1f22e470 TCPv6    :::49154                       :::0                 LISTENING        1012     svchost.exe   

0x1f2905b0 TCPv4    0.0.0.0:49155                  0.0.0.0:0            LISTENING        608      lsass.exe     

0x1f291f60 TCPv4    0.0.0.0:49155                  0.0.0.0:0            LISTENING        608      lsass.exe     

0x1f291f60 TCPv6    :::49155                       :::0                 LISTENING        608      lsass.exe     

0x1f2c6758 TCPv4    0.0.0.0:5357                   0.0.0.0:0            LISTENING        4        System        

0x1f2c6758 TCPv6    :::5357                        :::0                 LISTENING        4        System        

0x1f2cea58 TCPv4    0.0.0.0:49156                  0.0.0.0:0            LISTENING        1596     svchost.exe   

0x1f2cea58 TCPv6    :::49156                       :::0                 LISTENING        1596     svchost.exe   

0x1f2d6a48 TCPv4    0.0.0.0:49156                  0.0.0.0:0            LISTENING        1596     svchost.exe   

0x1f30a4f8 TCPv4    0.0.0.0:80                     0.0.0.0:0            LISTENING        4        System        

0x1f30a4f8 TCPv6    :::80                          :::0                 LISTENING        4        System        

0x1eda4db0 TCPv4    -:8080                         58.64.141.245:1057   CLOSED           1728     Tomcat7.exe   

0x1edd0cb0 UDPv4    0.0.0.0:3702                   *:*                                   1080     svchost.exe    2015-06-11 22:06:12 UTC+0000

0x1edde570 UDPv4    0.0.0.0:3702                   *:*                                   1080     svchost.exe    2015-06-11 22:06:12 UTC+0000

0x1edde570 UDPv6    :::3702                        *:*                                   1080     svchost.exe    2015-06-11 22:06:12 UTC+0000

0x1ee01f58 UDPv4    0.0.0.0:0                      *:*                                   820      VBoxService.exe 2015-06-11 22:29:05 UTC+0000

0x1ee3bf58 UDPv4    0.0.0.0:0                      *:*                                   820      VBoxService.exe 2015-06-11 22:30:30 UTC+0000

0x1ee8dd88 UDPv6    fe80::dd13:57ed:2d56:5b23:546  *:*                                   968      svchost.exe    2015-06-11 22:27:10 UTC+0000

0x1ee93ae8 UDPv4    0.0.0.0:0                      *:*                                   1160     svchost.exe    2015-06-11 22:26:21 UTC+0000

0x1f0d1150 UDPv4    192.168.56.30:138              *:*                                   4        System         2015-06-11 22:05:25 UTC+0000

0x1f21c3a8 UDPv4    0.0.0.0:0                      *:*                                   1184     svchost.exe    2015-06-11 22:05:44 UTC+0000

0x1f21c3a8 UDPv6    :::0                           *:*                                   1184     svchost.exe    2015-06-11 22:05:44 UTC+0000

0x1f21d510 UDPv4    0.0.0.0:5355                   *:*                                   1184     svchost.exe    2015-06-11 22:05:44 UTC+0000

0x1f21e008 UDPv4    0.0.0.0:5355                   *:*                                   1184     svchost.exe    2015-06-11 22:05:44 UTC+0000

0x1f21e008 UDPv6    :::5355                        *:*                                   1184     svchost.exe    2015-06-11 22:05:44 UTC+0000

0x1f25d608 UDPv4    0.0.0.0:3702                   *:*                                   1080     svchost.exe    2015-06-11 22:06:12 UTC+0000

0x1f25d608 UDPv6    :::3702                        *:*                                   1080     svchost.exe    2015-06-11 22:06:12 UTC+0000

0x1f2a5518 UDPv4    0.0.0.0:500                    *:*                                   1012     svchost.exe    2015-06-11 22:05:54 UTC+0000

0x1f2a5518 UDPv6    :::500                         *:*                                   1012     svchost.exe    2015-06-11 22:05:54 UTC+0000

0x1f2ab5f0 UDPv4    0.0.0.0:500                    *:*                                   1012     svchost.exe    2015-06-11 22:05:54 UTC+0000

0x1f2af8c0 UDPv4    0.0.0.0:4500                   *:*                                   1012     svchost.exe    2015-06-11 22:05:54 UTC+0000

0x1f2b1290 UDPv4    0.0.0.0:0                      *:*                                   1012     svchost.exe    2015-06-11 22:05:54 UTC+0000

0x1f2b1290 UDPv6    :::0                           *:*                                   1012     svchost.exe    2015-06-11 22:05:54 UTC+0000

0x1f2b1f58 UDPv4    0.0.0.0:0                      *:*                                   1012     svchost.exe    2015-06-11 22:05:54 UTC+0000

0x1f2d72b8 UDPv4    0.0.0.0:0                      *:*                                   1596     svchost.exe    2015-06-11 22:05:55 UTC+0000

0x1f2daf58 UDPv4    0.0.0.0:0                      *:*                                   1596     svchost.exe    2015-06-11 22:05:55 UTC+0000

0x1f2daf58 UDPv6    :::0                           *:*                                   1596     svchost.exe    2015-06-11 22:05:55 UTC+0000

0x1f2deaf8 UDPv4    0.0.0.0:3702                   *:*                                   1080     svchost.exe    2015-06-11 22:06:12 UTC+0000

0x1f2dfbb8 UDPv4    0.0.0.0:55678                  *:*                                   1080     svchost.exe    2015-06-11 22:05:56 UTC+0000

0x1f2e0b50 UDPv4    0.0.0.0:55679                  *:*                                   1080     svchost.exe    2015-06-11 22:05:56 UTC+0000

0x1f2e0b50 UDPv6    :::55679                       *:*                                   1080     svchost.exe    2015-06-11 22:05:56 UTC+0000

0x1f2e9160 UDPv4    0.0.0.0:0                      *:*                                   1080     svchost.exe    2015-06-11 22:05:57 UTC+0000

0x1f2e9160 UDPv6    :::0                           *:*                                   1080     svchost.exe    2015-06-11 22:05:57 UTC+0000

0x1f2ea008 UDPv4    0.0.0.0:0                      *:*                                   1080     svchost.exe    2015-06-11 22:05:57 UTC+0000

0x1f2f9008 UDPv4    0.0.0.0:123                    *:*                                   1080     svchost.exe    2015-06-11 22:05:57 UTC+0000

0x1f2f9008 UDPv6    :::123                         *:*                                   1080     svchost.exe    2015-06-11 22:05:57 UTC+0000

0x1f2f9228 UDPv4    0.0.0.0:123                    *:*                                   1080     svchost.exe    2015-06-11 22:05:57 UTC+0000

0x1fa2fb40 UDPv4    192.168.56.30:137              *:*                                   4        System         2015-06-11 22:05:25 UTC+0000

Other attacker activity.

The following activity attributable to the attacker was also noted:

Executing the Windows time command via the web shell

527519808 POST /webfiles/ HTTP/1.1

527519834 Accept: image/gif, image/jpeg, image/pjpeg, image/pjpeg, application/x-shockwave-flash, */*

527519927 Referer: http://192.168.56.30:8080/webfiles/

527519973 Accept-Language: en-us

527519997 User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0)

527520074 Content-Type: application/x-www-form-urlencoded

527520123 Accept-Encoding: gzip, deflate

527520155 Host: 192.168.56.30:8080

527520181 Content-Length: 95

527520201 Connection: Keep-Alive

527520225 Cache-Control: no-cache

527520250 Cookie: JSESSIONID=D4BB0A17D08FE321DF87835231D79824

527520305 text=06%3A24+PM%0D%0A%0D%0A&dir=C%3A%5Cinetpub%5Cwwwroot&command=time+%2Ft&Submit=Launch&sort=1X

time+%2Ft is the URL-encoded version of time /t, which returns system time in the HH:MM AM|PM format.

Executing the Windows tasklist command via the web shell 

526843968 POST /webfiles/ HTTP/1.1

526843994 Accept: image/gif, image/jpeg, image/pjpeg, image/pjpeg, application/x-shockwave-flash, */*

526844087 Referer: http://192.168.56.30:8080/webfiles/

526844133 Accept-Language: en-us

526844157 User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0)

526844234 Content-Type: application/x-www-form-urlencoded

526844283 Accept-Encoding: gzip, deflate

526844315 Host: 192.168.56.30:8080

526844341 Content-Length: 78

526844361 Connection: Keep-Alive

526844385 Cache-Control: no-cache

526844410 Cookie: JSESSIONID=D4BB0A17D08FE321DF87835231D79824

526844465 text=%0D%0A&dir=C%3A%5Cinetpub%5Cwwwroot&command=tasklist&Submit=Launch&sort=1H

This finding is supported by Volatility pstree output, which shows tasklist.exe running as a child process of cmd.exe, which in turn is a child process of Tomcat7.exe:

$ vol.py -f WIN-CEKM08E74HR-20150611-222930.raw pstree

<…snip…>

. 0x83139650:services.exe                             596    520      6    234 2015-06-11 22:05:29 UTC+0000

.. 0x832dc560:Tomcat7.exe                            1728    596     28    360 2015-06-11 22:05:56 UTC+0000

... 0x835eba10:cmd.exe                               3604   1728      0 ------ 2015-06-11 22:25:15 UTC+0000

... 0x836407b0:cmd.exe                               3612   1728      0 ------ 2015-06-11 22:25:24 UTC+0000

.... 0x830e2d90:tasklist.exe                         3620   3612      0 ------ 2015-06-11 22:25:24 UTC+0000

... 0x831f3d90:cmd.exe                               3248   1728      0 ------ 2015-06-11 22:21:49 UTC+0000

.... 0x8363c7f0:tasklist.exe                         3256   3248      0 ------ 2015-06-11 22:21:49 UTC+0000

<…snip…>