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

One of the advantages of examining the gears inside Koadic is that you gain low-level knowledge into how real-world attacks are accomplished. Pen testing tools allow you to explore how hackers move around or pivot once inside a victim’s system, and help you gain insights into effective defensive measures.

Block that Hash Passing

Pass the Hash (PtH) is one approach, not the only, for moving beyond the initial entry point in the targeted system. It’s received lots of intention, so it’s worth looking at more closely.

The key assumption behind PtH is that you already have local administrative privileges, which is required by mimikatz and other hash passers. Koadic conveniently provides mimikatz in one of its  implants.

Is getting admin privileges for PtH an issue for hackers?

Generally not! They hackeratti have found that obtaining local admin privileges is not a major barrier. They’ve been able to take advantage of special exploits, guess default Administrator passwords, or get lucky and land on an account that already has higher privileges.

Koadic, for example, includes a few implants that can raise privilege levels. The one I tried is based on Matt Nelson’s work involving the auto elevation capabilities of the Windows binary, eventvwr.exe, which is, somewhat ironically, the WIndows Event Viewer. Anyway, Microsoft has since come out with a patch for this exploit in Windows 10.

At one point during my initial testing over the summer, Koadic’s bypassuac_eventvw implant seemed to have been working on my Amazon instance. In my last test, it failed, and I’ll assume I got lucky working with an unpatched system in my first go around.

There’s a lesson here: in the wild, not every system is going to be patched, and hackers will hunt around until they find one!

UAC Helps!

Microsoft has written a long and comprehensive white paper on preventing PtH. It’s worth your time to scan through it. However, there’s also been much written by security wonks on what Microsoft has done (or not done) in preventing PtH. And after reading more in-depth analysis, I’m not sure I understand all the subtleties!

In any case, one of Microsoft’s recommendations is User Access Controls, UAC for short, which was a security control added at the time of Vista. It prevents privileged accounts from automatically doing what they want until their actions are approved (on a secure console) by a human. You may have seen the UAC dialog show up on your office laptop when you try to download and execute a binary from the Intertoobz.

You can find the UAC settings in Group Policy Objects under Policies\Windows Settings\Local Polices\Security Options (below). The MS honchos recommend, at a minimum, enabling Admin approval mode. In my testing, I got carried away and liberally enabled a few other UAC options.

I set up a scenario where the Koadic stager is directly launched from a local Administrator account. Even in this obvious case, you eventually have to deal with UAC. You can still run commands remotely from the Koadic console, but if you try to engage in a PtH pivot, you’re blocked (below).  I checked the event log, and sure enough there’s an entry showing the UAC was activated.

In short: UAC prevents hackers from getting to domain-level credentials and easily hopping from one computer to another.

The Horror of Local Administrator Accounts

One of the root enablers of lateral movement are the local Administrator accounts that once upon a time Windows set up automatically. To make life easier, IT admins have often configured these accounts with the same easily guessable passwords across many machines.

For hackers, that’s like throwing gasoline on the fire: once in, they can effortlessly navigate around the victim’s system without even a PtH. They just run psexec, supplying it explicitly with the Administrator’s password, say admin123.  Easy peasy.

There’s another bad practice of giving some users — often executives — local Administrator privileges on the mistaken belief they need these extra privileges to do special tasks. In other other words, their users accounts are added to the local Administrator group on their laptops.

Lucky hackers that land on one of these machines can then hit the ground running: they already have elevated permissions so they can PtH from the get go.

What are some ideas for lessening the risks with local accounts?

The aforementioned PtH white paper document suggests removing ordinary domain users from the local Administrator group. A good idea, and I approve of this message.

If you do keep local Administrator accounts, then make sure they have high entropy passwords. It can be a major heachache to go back and update bad admin passwords for larger sites. Microsoft generously provides Local Administrator Password Solution (LAPS) and Restricted Groups to allow companies to central manage these accounts. It’s topic I took up in this post.

You could then follow this up by preventing local accounts from logging in remotely. There’s a GPO setting under Policies\Windows Settings\Local Policies\User Rights Assignment called “Deny access to this computer from the network”. By configuring with a local SID, as explained here, you should be able to block any local account from networking.

[Updated]

So even if hackers have gained a privileged local account, we can stop them from moving around with this GPO setting. I’ve not tried this particularly efficient way of stomping out PtH, but I’ll  update this post as soon as I give it a test ride

I did get a chance to try this recent patch, which makes it incredibly convenient to disable local Administrator accounts from networking on a domain level by providing this new SID, “NT AUTHORITY\Local account and member of Administrators group”. You just need enter this loooong string into the deny networking GPO setting:

This is not necessarily a bad idea. Yes, you’ve prevented hackers from networking with, say, psexec, if they happen to guess the local Administrator password correctly. And probably inconveniencing and making some admins more than a little angry along the way.

If you don’t want to inconvenience your own team, and assuming they have a good, hard-to-guess passwords, there’s another possibility. But therein lies a tale, which is covered in this extensive post by the awesome Will “harmj0y” Schroeder. To turn off the token passing that allows the PtH attack to succeed, you have to deal with two regedit settings found under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System (below).

After some trial and error, I think I finally got what harmj0y was saying. In short, you can allow admins to network with their high-entropy, hard-to-guess passwords while stopping hackers from PtHing. l’ll talk more about this in another post.

Closing Thoughts on LoL Defense

Keeping the hackers contained on a single machine is a practical way to reduce risks. Sure they’re inside and still can do some reconnaissance, but at least you’ve contained them.

Koadic shows how hackers can use existing Windows binaries — mshta, rundll32 — to download scripts. But you can turn off this remote script loading capability, and shut down the attack from the start with Windows Firewall!  There’s no reason these binaries should be accessing the Internet, and Firewall let’s you disable their outbound connections.

Finally, Windows 10 will, no doubt, lead us all into a more secure future. Its Windows Defender has powerful malware detection capabilities, and Credential Guard seems to have a more comprehensive solution to dealing with hashes and Kerberos tickets. I’ll take this up in a future post.