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.