Build, Attack, Defend, Fix – Paving the way to DA

While most of us in the world of offensive security love getting domain administrator (DA) when doing assessments. How many of you know how the issue occurs, how to defend against it and how to properly remediate it? Well this blog series is for you; the plan is to look at each of these five common techniques take a deep dive into each look at creating the vulnerability, then exploit it, add some defence in there for detection and response then finally pair that with resolving said issues!

The primary objective of most internal engagements is to prove access and sometimes leverage this access for further gains. At times it can be a challenging path based on the environment setup thus these next techniques are worth looking for to help you emulate an attacker.  The techniques are:

·         Passwords in SYSVOL also known as GPP Passwords

·         Kerberoasting/ASREP Roasting

·         Golden Ticket/Pass the hash/Pass the ticket

·         LLMNR Spoofing

·         Passwords inside files

While this isn’t a definitive list of the ways to domain admin, they are sometimes the most common paths. Not all will be present in an engagement, but they are chained often!

So with all of these attacks in this series the plan is to discuss how the issue is introduced into an environment, showing you how to recreate it and explain why it is an issue. Then move onto attacking it then defending/fixing it.

The lab setup for this environment will consist of:

• STREAM-DC = Windows Server 2008 R2
• WS04 = Windows 7 Enterprise

Domain: purplehaze.offense

If you're unsure where to start when it comes to building a lab, check out my friend myexploit2600's blog post about it.

Part 1: Passwords in SYSVOL

A well documented flaw in the way Group Policy Preferences works can enable access to local administrator and other distributed accounts.  This is a feature of Windows Group Policy that can be used to create local users on machines, by design the Groups.xml will store the local administrator account user and password hash.  

The password is AES 256 encrypted and then Base64 encoded before being added to the groups.xml file.   However, Microsoft decided to publish the key required to decrypt this hash, meaning it is trivial to reveal any password stored in this file regardless of complexity.

The 32-byte AES key is as follows:

4e 99 06 e8  fc b6 6c c9  fa f4 93 10  62 0f fe e8  f4 96 e8 06  cc 05 79 90  20 9b 09 a4  33 b6 6c 1b

It's worth noting that as this issue affects Servers that are  2008 R2 and below, the baseline for the domain needs to support that otherwise it is likely that this issue has been patched(which is a good thing for defenders!).

Learn to build before you break

We'll come back to that key later on, first lets build the environment and show how the issue is introduced.  

We will use Group Policy Preferences to set password on local user account, the steps below will enable you to introduce the same issue to test out.

On the domain controller navigate to : Start – All programs – Administrative Tools – Group Policy Management.

• Create or Edit Group Policy Objects.

• Expand Computer Configuration – Preferences – Control Panel Settings.

• Right-click Local Users and Groups – New – Local User.

• Ensure the Action is Update and enter the new password as shown above in red.

Then navigate to an endpoint on the connected domain and run:

gpupdate /force from cmd or powershell.

By running this, the DC will force the update out to the workstations and thus apply the newly created password. Now enter the fun part where we get to exploit this issue!

Building is Cool.. but hax plz!

With all attack methods, there are often multiple ways to do them. Here I'll explain how the attack works then walk through how to perform in both windows and Linux. It is worth noting that both methods are likely to trigger endpoint detection and response solutions, while this post will touch on the defensive tactics that can be followed it should be understood and assumed there's no one fix for all.

PowerShell Attacks

There are multiple tools out there written in PowerShell to do this attack, my favorite is Get-GPPPassword which is included in PowerSploit. It needs to be run in the context of the domain therefore can be done in one of two ways, either via runas or via a domain connected machine:

Metasploit

In an instance where you don't have access to the domain via the methods described above but you have managed to gain a set of credentials, there is a metasploit module for enumerating GPP.

auxiliary/scanner/smb/smb_enum_gpp

Simply set the RHOSTS, SMBDomain, SMBUser and SMBPass then run the module and it will fetch any XML files within the sysvol of the primary domain controller as shown below:

With all attack paths there are multiple other ways to do this, CrackMapExec also has a module called GPP_Password which will do this attack, it works similar to metasploit, however I've found it to  be less reliable in lab environments when metasploit and powershell work as expected :D.

Defend & Fix

The defense and fix for this issue is fairly simple, there are two options to properly protect and monitor for the issue. The first primary fix would be to prevent this type of vulnerability happening in future, whereby to apply MS14-025 or Install KB2962486.

Now after applying this patch you will prevent future slip ups but to correct current ones the first thing to do is to delete the groups.xml file from SYSVOL. An easy command to find them is:

findstr /S /I cpassword \\<FQDN>\sysvol\<FQDN>\policies\*.xml

Replace <FQDN> with your domain, so in my case the command would be:

findstr /S /I cpassword \\purplehaze.offense\sysvol\purplehaze.offense\policies*.xml

Once you've found them you can delete to fix existing issues. From a defensive perspective, we can create a honeypot file whereby placing an empty Groups.xml file in the respective paths and changing the permissions to deny, then setup alerts within event viewer for failed attempts to access this file.

To change the permissions simply create Groups.xml then navigate to properties -> Security -> Edit -> Add -> Everyone -> Check Names.

Then select deny access to all, this will deny access to the file and now when an attacker attempts to get access to the file they will be denied.

Once this is set, the file is now restricted, it's time to look at how to monitor logs for potential access denied against our newly created honey pot.

If following guides isn't for you I've also created a video that walks through building, hacking and fixing.

Replacing GPP with Deploying Local Administrator Password Management (LAPS)

Now a few of you may be wondering, if you can't deploy local admin via GPP 'how on earth am I meant to deploy my local admin accounts and manage them?!', well LAPS may be the solution for you.

Starting off we need to download the packages from Microsoft which can be downloaded from here

A lot of businesses will use the same local administrator password across the entire estate, which is a bad idea for lots of reasons. At a simple level, if this password is discovered, it allows anyone to install software as an administrator – at a higher level it facilitates further attacks on machines such as pass the hash(which I'll be covering in a later blog post), mimikatz(which can be used to extract passwords from memory) and general enumeration against your domain.

LAPS solution features include:

• Sets a unique randomly generated password PER machine which alleviates the issue that GPP Passwords creates
• Automatically change the Local Administrator Password every x number days
• Password is protected in AD by AD ACL, so granular security model can be easily implemented
• Stores Local Administrator Passwords as an attribute of the Computer Object in Active Directory
• Password is protected during the transport via Kerberos encryption(more on this in a later post)

Right now we have a bit of background, onto the fun(ish) part, actually deploying it. Instead of re-inventing the wheel it's probably better to check out this guide for deployment which I've found to be extensive and a good guide to follow.

If you've found this post useful hopefully share it with others so they can learn to build break and fix the same issues. Stay tuned for part 2 which will be all about kerberoasting and ASREP roasting!