Koadic: LoL Malware Meets Python-Based Command and Control (C2) Server, Part I

In my epic series on Windows binaries that have dual uses– talkin’ to you rundll32 and mshta — I showed how hackers can stealthy download and launch remote script-based malware. I also mentioned that pen testers have been actively exploring the living-off-the land (LoL) approach for post-exploitation. Enter Koadic.

I learned about Koadic sort of by accident. For kicks, I decided to assemble a keyword combination of “javascript rundll32 exploitation” to see what would show up. The search results led me to the Koadic post-exploitation rootkit, which according to its description “does most of its operation using Windows Script Host.” I was intrigued. By the way, Koadic is hacker-ese for COM Command and Control.

A good starting point for learning about Koadic is a Defcon presentation given by its two developers, Sean Dillon and Zach Harding. Koadic looks and acts like PowerShell Empire with script-based stagers and implants. The key difference, though, is that Koadic instead relies on JavaScript and VBScript on the victim’s computer.

As they note in their presentation, IT defenders are now more attuned to the fact that PowerShell can be used offensively. In other words, security teams are looking for unusual PS activity in the Windows event logs. They are not as focused (yet) on scripts run by the Windows Script Host engine. And that was some of the inspiration behind Koadic, which I suppose can be called JavaScript Empire.

Microsoft has also helped matters by adding PowerShell-only logging modules, a topic I explored in my amazing mini-series on obfuscation techniques.

Defenders can selectively turn on PS logging. They can not do the same for JavaScript.

To analyze Koadic’s script activity, you have to bite the bullet and enable detailed logging, which results in an entry for each process launched in Windows. Let’s just say the Windows log ain’t a pretty place after that’s done, and this event fog helps hide Koadic’s activities.

Start Me Up With a Mshta Stager

Thankfully, I had malware analysis help from our amazing NYC-based summer intern, Daniel Vebman, who sanity checked my ideas and did some valuable exploring of his own.

In this first post, let’s take a shallow dive into Koadic’s capabilities and architecture. One of the major themes to keep in mind with Koadic is that its script-based approach gives the attackers the ability to change code on the fly, and adapt quickly to new environments.

How do you detect stealthy post-exploitation activities of Koadic-style attacks in the real world? I’ll come to that later on in the series, but clearly you’ll need to move beyond the Windows event log and, ahem, focus on the underlying file system.

To get started, we installed the software from Github on an Ubuntu instance in our AWS environment. We hit a few snags  but this was quickly solved by the ever-resourceful Daniel, who reinstalled Koadic’s Python modules (and did it right).

Yes, the server-side of Koadic is Python-based.

To do its work, Koadic leverages Windows binaries that sneakily pull in remote JavaScript or VBScript. Essentially, the ones I covered in my living-off-the land series: mshta, rundll32, and regsvr32.  It appears, though, from reading the notes that only mshta works, so that’s the stager we used in our testing.

Let’s assume the mshta stager was delivered to a victim via, say, a phish mail. Once activated, Koadic then creates a “zombie”. It’s their way of saying it has control over the victim’s machine. The zombification — it’s a word — is accomplished through a library of JavaScript-based implants.

In a realistic pen-testing scenario, the first task is to answer the who and where questions. After all, the payload has landed somewhere on laptop or server of a random user in the Intertoobz.

Koadic’s implant/manage/exec_cmd does as advertised: lets you run individual shell commands remotely. As with all the implants, you enter the “info” command to see what the basic parameters are and then set them accordingly.

For exec_cmd, I had my zombie execute whoami, hostname, and ipconfig on my pretend victims’ computer — a Windows Server 2012 in my AWS instance.

Let’s Look Around

Once you have the basics, it’s then helpful to discover the full qualified domain name (FQDN) of the Windows environment you’ve landed in. As we’ll see, you’ll need the domain name to move off the initially hacked computer.

For that I need to resort to PowerShell by setting the cmd parameter to GetHostByName($env:computerName). It’s a benign PS cmdlet, so in theory it shouldn’t raise any eyebrows if it’s logged.

What about scanning the network to learn about IP addresses?

That’s where implant/scan/tcp comes into play. There’s also the implant/gather/user_hunter  to discover users who are currently logged in.

In short: Koadic has built-in support for getting essential environmental information and, of course, the ability to run shell commands to fill in the gaps. By the way, a description of all its commands can be found on the Github home page.

Doing the Psexec Pivot

Unless a hacker is very lucky and lands on a server that has millions of unencrypted credit card numbers, she’ll need to leapfrog to another computer. The way this is done is to harvest domain-level credentials, eventually find one that has elevated permissions, and then perform a lateral move.

Once upon a time, I wrote about how to use mimikatz and psexec do just that. Koadic has conveniently provided a mimikatz-based implant to retrieve credentials from SAM memory and another one to support psexec. Small quibble: you have to explicitly upload the psexec executable to the victim’s computer and set the path name.

For example, to retrieve credentials I ran implant/inject/mimikatz_dynwrapx:

You can see the NTLM hashes, which you can crack offline if need be. But because of the infamous wdigest security hole, you also get the plain text passwords. Eureka!

I won’t show how to do an actual lateral move or pivot in this post, but you can see the setup for the implant/pivot/psexec below:

I’ll explain next time how to do a real-word pivot by filling in the cmd parameter with the initial mshta stager, thereby creating another zombie. The idea is to continue the pattern of harvesting credentials with mimikatz and then pivoting. Yeah, you end up controlling an army of zombies. Evil!

A Little JavaScript Plumbing

That’s the quick $.50 tour of Koadic. One last bit of business is a high-level view of the architecture.

Koadic is essentially a remote access trojan or RAT. Nowadays, we give it the fancier name of a command and control (C2) server. In any case, the principles are easy enough to grasp: the client side executes the commands from the remote server.

In the case of Koadic, the client side is not a binary — as they were for the early RATs — but instead it’s 100% JavaScript. The client’s sole function is to loop and pull in remote implants—written in either JavaScript or VBScript — from Koadic’s Python-based server, run them, and send the results back.

By the way, there’s some clever programming in Koadic wherein the server-side Python crafts the actual JavaScript implant. I’ll get into more details further on in the series.

Let me draw back the curtain to remove some of the mystery around the implants. Here’s the raw JavaScript in Koadic that actually launches psexec:

try
  {
    var rpath = "~RPATH~"
    var UNC = "~RPATH~\\psexec.exe ";
    var domain = "~SMBDOMAIN~";
    var user = "~SMBUSER~";
    var pwd = "~SMBPASS~";
    var computer = "\\\\~RHOST~ ";
  

    UNC += computer;
  

    if (user != "" && pwd != "")
    {
        if (domain != "" && domain != ".")
        {
          user = '"' + domain + "\\" + user + '"';
        }
  

        UNC += "-u " + user + " -p " + pwd + " ";
    }
  

    UNC += " -accepteula ~CMD~";
  

    // crappy hack to make sure it mounts
    var output = Koadic.shell.exec("net use * " + rpath, "~DIRECTORY~\\~FILE~.txt");
  

    if (output.indexOf("Drive") != -1)
    {
      var drive = output.split(" ")[1];
      Koadic.shell.run("net use " + drive + " /delete", true);
    }
  

    Koadic.WS.Run("%comspec% /q /c " + UNC, 0, true);
  

    Koadic.work.report("Complete");
  }
  catch (e)
  {
    Koadic.work.error(e);
  }

Yeah, those tilde encased variables are replaced with the real thing before it’s shipped off to the target system.

The key point is that this is a flexible environment. In fact, this infosec blogger (and former UNIX programmer) successfully made a few tweaks to the psexec data module to get it to work in our AWS environment.

Note to Shawn and Zach: I think there are issues in the way a fully qualified domain name is parsed by the mimikatz implant. Just sayin’.

For Next Time

I’ll cover this material again, and I’ll do an actual psexec pivot and get deeper into my pen-testing persona. I’ll also analyze the events produced by Koadiac so that we can see that it ain’t so easy to detect unusual activity from the raw logs.

One last thought: wouldn’t it be great for pen testing purposes if we were able to wangle Koadic to pull in Activity Directory information, say domain groups and their members? Kind of like what PowerView does.

Hold that thought, and next time we’ll also start on the task of creating our own implants. In the meantime, if you want to get ahead of the curve, you might want to study the Koadic modules in Github.