Another quick time saver script

Now that I've started using yara signature scanning in my memory forensics, I've found out that anti-virus processes come with an absurd number of false positives (makes sense, as they probably contain the same or similar signatures that yara is looking for). So, when I run the yara module, I cut out the offending pids with a whitelist approach. So, after about the third time I manually entered a command like the below

cat pslist.txt | awk {'print $3'} | grep -vi "pid1\|pid2\|pid3\|" | tr "\n" ", "

to then copy paste the 3-5 lines of pids into the command line (making a big ugly mess,) I decided it was high time to make things a little simpler (and cleaner).

I started out writing a script that prompted me for the pids I wanted to exclude, which would then just dump the entire mess into the command line, for me to still then copy/paste into the volatility command. Saves me a bit of typing, but wasn't quite as clean as I wanted. So, I figured it was high time I learn how to use options in bash. This is a simple but functional script so that instead of pasting a zillion pids into volatility's -p option, I can do something cleaner like

volcommandstuff -p $(getpid -p "pid1 pid2 pid3") and it'll dump the edited list in for me. I'm kind of proud of this one, probably for no good reason, but whatever.

Here's the script

#!/bin/bash
#Script to pull all the PIDs from volatility pslist output stored in a text file, excluding specified PIDs supplied by the user
#This script assumes you're in a directory with the appropriate pslist.txt output file
set -e

#check to see if an option was entered
if [ $OPTIND -eq 0 ]; then
    echo 'Useage: thisScript.sh -p "space seperated pid list"'
    exit 1
fi

while getopts "p:" userInput; do
    case "$userInput" in
        "p") read -a pids <<< "${OPTARG}"
            for item in ${pids[@]}; do
                string+="$item\|"
            done
            modString=(${string:0:${#string}-2})

            string=$(cat pslist.txt | awk {'print $3'} | tail -n +3 | grep -vi "$modString" | tr "\n" ",")
            modString=(${string:0:${#string}-1})
        ;;
        *) echo 'Useage: getpid -p "space seperated pid list"'
        ;;
    esac
done

echo $modString

The Macro enabled Doc, a deeper dive

With the potential threat of trying to come up with presentation material (still not sure I want to brave the stage,) I decided to try and make a macro document Dridex infection chain work locally (so as to not rely on URLs that don't live for a full 24 hours) and as a result ended up learning a lot more about the behind the scenes of the sample I was playing with.

First off, to step through the macro code, we'll need more than just oledump. The easiest way to step through a macro, is within Word's own developer tools. However, most threat actors password protect their macros (big shock, eh?) Fortunately, there's a VERY easy workaround. Simply load the document in a hex editor of choice, search for DPB (or the bytes 44 50 42) and change it to DPX (or 44 50 58). Then open the document, load developer tools (alt+f11), click past the errors, right click on the project, select properties, project protection, then uncheck "Lock project for viewing" save, re-open, and viola!

The next step is enabling macros, otherwise Word won't let you step through it. This can get dicey, since enabling the macro will also run it when you open the document. I get around this by disabling the network adapter until the macro times out.

Now we get to the fun parts. Stepping through and modifying the code to allow local file use. Initially I was trying to use literal local files (e.g. "C:\Users\User\Desktop\malfile.txt"), but trying to rewrite the function that normally uses an object.response() call on an HTTP request turned out to be a Royal pain. I pretty much had it, and realized my error, but then after sleeping on it, I came up with a much more elegant solution. Host the files on a different VM with python -m SimpleHTTPServer, then modify the macro code to simply call those URLs. Works like a charm!

So, as we step through, there's a lot of junk, and random functions and variable assignments that serve no purpose except to make things look confusing and possibly change the signature of the file. The first important part to look at (in this sample) is where the first URL gets set.












As we can see in the code above, I've already modified it to use the text file hosted on my local machine (although I forgot the port :8000). Originally it set PBIn = STT1 + CDDD + TSTS, which from the above code is pretty easy to see what it's doing.




The next part of code to edit, is where it sets the URL for the second file pull. This file (rara.txt) simply contains a dropbox link that downloads an executable file. I had already pulled this file down, and so set the link of rara.txt to be "http://172.16.2.138:8000/ose08.exe" instead of the dropbox link.

Now, in this sample there are some Module2.Crispy(1) calls which are nothing but delayed time wasters, if you're stepping through the code, you can just comment them out with a single tick.

There comes a function that simply parses out the text of a variable (which was set to the text of the first file we downloaded, the 7777etc.txt file), set a breakpoint at the first line after the loop, and hit continue. It's splitting up the text file into two separate files, a .vbs and .bat script. The .vbs script is responsible for using the link found in rara.txt to download the executable, and the .bat executes it and does some cleanup, removing the scripts from disk. The function that calls them passes the file path of the script file to Shell(filepath, 0).

Lastly it runs some junky code that basically hangs Word. Why it does this, I'm not entirely sure, but I suppose it's already done its job.

There's also this interesting "hidden" white text in the body of the document, but near as I can tell it serves no purpose. Perhaps the .exe uses it at some point for unpacking or something. I'll try reversing the .exe some more later.

A word of warning (WordPress and plugins)

To preface, through some various info sharing lists, I get to see the constantly evolving exploit kit landing pages. Quite often the link structures change, and even more frequently the referring sites change. The scary part? Every last one of those referring pages were exploited in some fashion. Many of them likely in an automated fashion through some kind of scripted scanner/exploit module.

The event that prompted me to write this, was an AV hit off of a JS/Redir from a page that shall remain unnamed. I kind of figured it was an EK (exploit kit, ie Nuclear or Angler), but I almost never see these in my cyber-travels, so I just had to go poking around. So, I fire up Wireshark, ZAP, Virtualbox, and start going for a stroll down malware lane. Two things immediately catch my attention: there's a comment in the page response about "This site is optimized with the Yoast WordPress SEO plugin v2.2.1", and a nasty little iframe referencing hxxp://recoltentadelphiamcld2.discounthillsdalefurniture.com/civis/viewtopic.php?t=31w&f=lwmxs.o70b8&. For those in the know, viewtopic.php is a super common URI for the Angler exploit kit. A correspondent, when presented with the above link (but not the information about Yoast,) his first statement included an assumption that the site was running WordPress or Joomla. Why? Because they're notoriously insecure, particularly when it comes to plugins.

WordPress is nice because it's open source, and is actually supported well enough that WordPress in and of itself isn't TOO dangerous to run, if you keep it up to date, but the myriad of plugins make for a pretty diverse attack footprint. The more you throw on there to make managing a website easier, the more potential holes you open up, and since this tends to be web-facing, rather than a private network, the entire world can see/scan/poke around your site. I would highly suggest making your employee's lives difficult, and make them go through the web developer for content updates. Or maybe hire someone specifically who is half way between web developer and business unit to handle content updates. Lastly, if you DO insist on using WordPress (believe me, I am sympathetic to resource restrictions,) get your site tested properly. Hire a firm to do a vulnerability assessment. It'll serve you better than having to deal with the mess of infecting your clients/visitors, getting your webpage blocked as a malware site, and potentially having to rebuild your website to make sure it doesn't happen again in the future.

The site www.wordpressexploit.com has a pretty significant list of WordPress exploits (including a couple stored XSS vulns in SEO, which is probably how the above iframe was injected). This site is a good reference to check against your versions of WordPress and plugins to see if there are any known vulnerabilities.

Don't just surf safe, build safe, for those of you who are builders. The internet being cobbled together with duct tape and bubble gum (from a coding standpoint) does not help the current state of information security affairs.