Active Directory Pentesting Methodologies

Question

I would like to ask about steps and methodologies for Active Directory pentesting. I used tools like responder, powerview, pingcastle and mimikatz, but maybe there are other methods that are useful.

Answer 1

In most scenarios, Windows Server Forest targets, are hardened quite well, but usually because of the existence of an EDR and/or NIPS that prevents initial entry access.

The whole concept of Active Directory testing, as you say it, is to expand access * after * that initial entry point, or foothold, is proven.

The book, Mastering Kali Linux for Advanced Penetration Testing, 3rd Edition, is one great resource on what you ask for -- hone into its chapter called Action on the Objective and Lateral Movement.

The Hacker Playbook 3: Practical Guide to Penetration Testing, Red Team Edition -- is also a great resource for some baseline techniques along with demonstrations on how or where to evolve them.

You'll find that any-given cybersecurity conference has a few training courses that specifically teach Active Directory testing or some variation (or even a subset, e.g., there was even a class just on mimikatz and nothing else). A lot of these courses have their own methodology, but the methods are always the same: gain access, keep access, and expand access.

In order to gain access, you'll require a carefully-planned Pre-ATT&CK scenario with a series (or chain) of tactics, each backed up by one or more underlying techniques. Since I'm sure this is not what you're asking about, I'll move on.

In order to maintain access, you will need that Pre-ATT&CK scenario to stand the test of time, and if it uses reverse-https/etc payloads that connect to your remote handlers, then all of that will need not to stand out. Of course some scenarios could position C2 inside the network, over say, ARP daemons, or MS-RPC Named Pipes, or any sort of covert channel. However, others just hide in plain sight, such as Domain Fronting or BC-SECURITY's Empire fork, where evasions such as ones for JA3/S (a popular detector in 2019), are available.

A lot of times this involves finding computers (i.e., AD Computer Objects) that are not in Sites (an AD concept) because they also may lack a full EDR stack or have other exceptions. The IT and Cybersecurity staff don't seem to know the computer is there and that AV or basics aren't installed or properly-working. Look for overlaps in Windows Server Domains and Forests as well. You have to explore or know the target environment(s).

The book, Advanced Infrastructure Penetration Testing, has an entire chapter dedicated to Active Directory Exploitation. The section on SPN Scanning is unique in that it simplifies much internal AD recon with one PowerShell command: setspn -Q */*. You might not get this data in this exact way (because it might set off a detection right away -- or even much later it could be discovered during a hunting op), but you are going to need to know how to parse and understand it. SPN data is an Active Directory targeting goldmine.

Low-hanging fruit in an Active Directory are usually the SharePoint accounts even when you're not targeting the SharePoint sites (sometimes SharePoint has been replaced but the legacy accounts remain!). This is where techniques surrounding the BloodHound tool can come into focus.

Even better are lone or anomalous installs of IIS found via SPN or some other means. Any means of landing a payload to an IIS server could reveal apppools leading to hidden pivots via creds that are usually otherwise-undiscovered. A command to do this (as well as working with apppools in general) can be found in the book, Internet Information Services (IIS) 7.0 Administrator’s Pocket Consultant in the section on Working with Application Pools: [drive:]\windows\system32\inetsrv\appcmd list apppool <AppPoolName> /text:*

MS-SQL Server services are also found in SPN, and the services that are tied to them (e.g., SAP ECC) may also be visible. I recall PowerUpSQL and PowerSAP pentest tools, but there are hundreds of these projects when 2 years ago there were only ten or so. I think you're starting to understand that the reason there isn't a one-size fits all Active Directory pen test (or an easy-to follow flowchart) is because it's all dependent on the target environment(s).

Play around with the PowerShell modules specific to administration of each of these Microsoft Server Forest Services, like those apppools above, but often closer to the implementation. For example, Get-Webconfig and Get-ApplicationHost, but there are countless others. MS Exchange Server has a lot of these, be careful, though! It's also possible to look for the tools that come with these services, for example Exchange Admin Center has GUI tools but it also has a web portal (try IP addresses and the /ecp URI to find them).

There are also some point tools I could be missing and that are worth mention, such as Vibe. There are really lots of ways to skin this cat. An army of cybersecurity pros would never run out of ideas. Azure AD will change things but will probably open new doors. Just keep testing it and get the value that you want out of it.