This article is part of the series "Koadic Post-Exploitation Rootkit". Check out the rest:
Mshta and rundll32, the Windows binaries that Koadic leverages, have been long known to hackers. If you take a peek at Mitre’s ATT&CK database, you’ll see that rundll32 has been the basis for attacks stretching over years. Pen-testing tools, such as Koadic, have formalized established hacking wisdom, thereby helping IT people (and bloggers) to understand threats and improve defenses.
I’ll add that it makes sense to also take a deeper dive into Koadic’s design to gain even more insights into possible defense strategies. With that in mind, let’s go over a few ideas from last time.
Playing Pen Tester (and Blue Teamer)
We saw how Koadiac, like all command and control or C2 servers, lets us send commands from its console to the targeted computer on which a small-footprint JavaScript shell (more on that below) launches the actual Windows commands.
As a pen tester, one of the first things you want to learn is whether there’s interesting data that you can access and then copy or exfiltrate. For my pretend AWS environment, you can see below how I used legacy findstr to zoom into a file containing sensitive data.
I then used implant/util/download_file to bring it back home.
Switching to my “blue team” persona, let’s now take a quick look at the Windows Event logs.
To begin to understand what’s happening, I enabled very granular logging. I was doing this for educational purposes — and isn’t this what pen testing is about? — but you may not be able to depend on detailed logs in real-world post-exploitation analysis. However, as we’ll soon see, Koadic does leak information into the file world — it’s not completely fileless. And this provides an opening for a different kind of defense.
The first interesting log entry is one showing rundll32 pulling in a remote script – which I discussed back in my LoL series. This is not, clearing throat, a standard use of this utility, and should raise flags. By the way, Windows Defender (in Windows 10) can spot some of the dark uses of this LoL-ware.
And then a little further on in the log is this revealing entry:
Of course, this is the result of the findstr command that I previously sent to my zombie. The larger point is that it’s being run indirectly via the launching of a cmd shell to then run findstr. It’s actually what happens when you run a shell command within JavaScript: you use ActiveX to create a shell session and then pass it the command, something like this:
Did you notice the 1> and 2>1& part of the command in the log entry? Those of us of a certain vintage immediately recognize that it’s Unix/Linux for directing standard output to a file and redirecting standard error to standard output.
Sure, there are legit reasons for doing all this, but it’s also the way you would relay output from a command (launched by malware) back to the hacker’s attacker server —save it to a file, read the file, and then delete it. This is in fact what Koadic does.
Detailed event logging, though potentially containing useful information, may not be always be available. But it doesn’t matter! If you can relate these short burst of file creation and deletion activity with access to executable files that are rarely visited by the user, such as rundll32, and the copying of files containing sensitive information, then you’re on the way to detecting and stopping an attack.
In short: there’s a little bit of file noise often generated by malware that can be detected by those security defenses that are capable of monitoring abnormal file activity on a user basis.
Real-World Pivots With Koadic
Last time, I began to show you how to configure Koadic for a lateral move or pivot. Let’s finish this up and do a real pivot.
Assuming there are other domain credentials available, Koadic provides the implant/inject/mimikatz_dynwrapx module to pull out the cached hashes and, when possible, actual passwords. If you then enter the creds command, you can reference the credentials using a numeric identifier.
Let’s assume I’ve learned that masa is another server in the acme.corp domain, and that I’m using the credentials of the user named lex. I’m now ready to run implant/pivot/exec_psexec.
I set the pathname to the psexec executable, which I previously uploaded, provided the credid of lex’s credential, and for the remote command to execute, I supplied the initial mshta stager that landed me on the victim’s computer. You leapfrog to the next computer by simply implanting another Koadic Javascript client.
That should have been enough to get this started.
But … Koadic didn’t seem to properly pull out the fully qualified domain name of the credential from the cache, so I had to tweak the JavaScript code. I was forced to override the cached domain information through whatever was explicilty configured through the set command.
My headaches didn’t end there: my lateral move was initially blocked. Psexec experts probably know this, but I learned the hard way that you have to provide the –h option for “elevated credentials” (even if aleady have the plaintext password). More code changes.
On the bright side, Koadic’s script-based environment makes code updates relatively painless. Note to Sean and Zach: I think you need to take a closer look at the exec_psexec implant.
Once psexec runs successfully with the mshta payload, Koadiac establishes another zombie. (Yes, that’s quite a sentence.)
I now had two zombies: one controlling pepper.corp.acme, my initial target, and the second one handling masa.corp.acme. I’m now a zombie master!
To communicate with the new zombie, I just needed to make sure I set the appropriate zombie number, and then run the command. You can see my zombie sorcery below:
Diving Into the Koadic Kode and Kraziness
I will be merciful and end this post soon enough! Before we break until next time, I wanted to start a dive into Koadic’s architecture. It’s helpful – I think –in terms of really understanding your pen testing and in getting insights into real-world post-exploitation malware.
The one word that describes the Koadic (and other malware creations) is obfuscatory. There’s nothing straightforward to the way it runs commands. Some of this is intentional to throw off the defense, but C2 environment are also inherently complicated.
I’ll go into this in more detail next time, but here’s the $.10 tour.
The mshta stager that pulls in the initial payload doesn’t hang around very long. It then launches rundll32, which loads the main Koadic client code. At this point, the client is in a loop waiting for commands from the Koadic server – the client console that I showed above.
Once it receives a command, say to execute “ipconfig”, the client-side of Koadic acts like a Unix/Linux shell — forking and execing commands. In our case, the Koadic client then launches another rundll32 whose sole function is to connect back to the Koadic server and pull in specially served up JavaScript — essentially the ActiveX code to launch a Windows shell session to run ipconfig. This child rundll32 is transient, exiting after it completes its execution of a single command and leaving the parent rundll32 to carry out the next commands.
Basta, for now!
If you’re looking for a homework assignment, you should study this section of the Koadic’s github. Hint: stdlib.js forms the core of the Koadic client.
