The following is what I learned from playing around with Active Directory over the past several weeks. I wanted to present something more than a handful of Windows tricks, and relate how it fits into a much larger picture.
Basically a small group of us were tasked with setting up and enumerating an Active Directory network about two months ago, consisting of a Domain Controller running Windows Server 2012, a client desktop and an attacker machine. The latter (my pen testing netbook) would then be used to read the Active Directory database and the traffic going across the network. At least that’s how it was supposed to work.
Honest to God! It’s not the Router!
The first problem was I had literally no experience of Windows Server until then, let alone Server 2012, and there were entirely new concepts and terminology that had to be learnt on the job, not to mention an interface most people haven’t used yet.
When it came to the specifics of configuring the server, finding whatever option was like searching for a needle in a haystack. Even if the admin is an experienced Server Core person, the latest version has roughly an extra 2,000 commands, depending on how Microsoft defines ‘commandlets’. For us it meant many hours of troubleshooting and bitching before we had a working domain.
Why bother to enumerate Active Directory in the first place? The answer’s pretty much the same as someone gathering detailed information on any target network: it makes the difference between an attack that’s detected early and intrusions that remain undiscovered over a much longer period. It’s the difference between amateur attack and a targeted ‘Advanced Persistent Threat’ (APT). A more recent buzzword I’ve been hearing lately, mainly from vendors, is ‘Advanced Evasive Threat’, which I assume means the exploitation of several vulnerabilities on the same network.
For example, we want to break into a company’s network and install a Remote Access Tool: where should it be installed? Ideally on a server that generates the largest volumes of traffic to the most IP addresses, and we’d have to find that. From there, an occasional connection to a C&C server would blend in nicely with everything else in the target’s logs.
As it turns out, physical access to the network is needed prior to enumerating Active Directory, unless there’s a public sub-domain that maps to a Domain Controller, and there’s a Guest account enabled that allows this. An organisation might well do the latter, to make it compatible with some legacy system. Apart from that, an attacker has four options:
* Connect to the Wireless Access Point, which would usually involve cracking the WEP or WPA security.
* Search the target organisation’s premises for an unused Ethernet port.
* Search the target organisation’s premises for an unsecured and unattended desktop computer on the domain.
* Gain physical access to the Domain Controller
I didn’t bother with wireless cracking here. Everyone knows they should have WAP/WPA2 enabled, a strong key, MAC filtering, etc. etc. and anyone thinking like a hacker will also consider scouting the area for other options – sometimes there are ways around wireless security such as unused Ethernet points and unsecured desktop PCs. This was certainly the case on a couple of large sites I’ve worked in the past, where practically any random person wearing a suit could hook up a laptop without drawing suspicion. These just happened to be places where roughly 80% of the departments’ servers were installed in heavily frequented storage/stationery rooms, and there were no records of who was entering and leaving.
I called this the ‘direct method’ here because it involves using a client program to read the NTDS.DIT file off the Domain Controller. Theoretically it should be extremely simple to do, but I know half a dozen people who also tried this without success from an ‘attacker machine’ against a Windows Server 2012 system.
I had no problems doing it on another network I was actually logged into. The simplest method was to just browse the Network folder in Windows Explorer. Depending on how the network’s configured, it might also be possible to access services and files on other machines listed.
There is also an executable called services.msc, which not only allows someone with admin privileges to enable/disable Windows services, but view what appears to be a cache of domain service requests in the DNS Client entry.
One of the things I very stupidly forgot to mention in my report is the Active Directory Diagnostic Tool (ntdsutil.exe), which is used for manipulating the NTDS.DIT file.
In addition to stuff we’d find in a typical Windows desktop, there are freely-available clients for reading Active Directory databases through LDAP queries. The official client program is ldp.exe, which is included with Windows Server 2003 Support Tools. A third-party application that does the same thing is JXplorer, with versions available for both Linux and Windows operating systems.
Indirect Enumeration, the Quick(ish) and Dirty Way
Having failed like a total lamer to read the NTDS.DIT file directly, I eventually hashed together an ‘indirect’ method for enumerating the system. Experienced hackers will no doubt have a better and more thorough way of doing this, but here we go:
If we can’t get a list of resources from NTDS.DIT, we can instead use Wireshark or tcpdump to capture packets being exchanged on the network, then use that to manually compile a list of IP addresses and guess their functions. Expect this to take much longer on a real corporate network with a dozen services and hundreds of clients. Wireshark has several features that present and filter information from the captures in various ways to make the job easier. Maybe that’s a subject for another post.
Then I did a cursory nmap scan against the IP addresses of interest for open/listening ports and running services. The nmap file also tells us a little more about the software running on those IP addresses, and it even gives us the router’s firmware. Alternatively, we could go back to the original Wireshark/tcpdump capture and examine the payload text for software versions.
Although a Domain Controller might be a single point of failure, if it somehow got hacked, the security of an Active Directory system is heavily dependent on the overall physical security of the network – particularly for the server, wireless points, Ethernet points and client machines.
We could also make some guesses about the threat: it’s most likely going to be someone from outside the target organisation who’s knowledgeable enough about Active Directory and Domain Controllers.