Back in 2014, when I worked as a Security Administrator at a tribal casino, I was in the position of defending against our very first penetration test. At the time, I was adamantly against it. I had been in my position for less than a year, and until my arrival the IT Director was insisting to senior management that we were "very secure", a statement that gave me hives. Additionally, I had yet to get any kind of vulnerability management program or significant traction in remediating some low hanging fruit (10-yo simple 6 char passwords, anyone?) after a year of working there. From an industry perspective, we were not ready for this level of assessment. A good penetration test will show you vulnerabilities that you're not aware of and the impact of those vulnerabilities being exploited. It didn't make sense for us to have a pentest when we didn't even have an inventory of vulnerabilities yet.
The security firm's sales team came in and did a bang up job of selling our C-suite on a penetration test, however. They even went so far as to brag that their team had "never NOT gotten domain administrator" on an engagement at the various casino's they assessed. With no choice in the matter and hearing a challenge, I set to work.
What I discovered over the months leading up to the engagement is that the pentest became great political tool for remediating problems. The other thing I did to prepare was visit some colleagues of mine who were regularly performing penetration tests at clients across the country. When I asked for advice, they gave me the following suggestions. These are backed by my own experience over the past few years as well.
If you've never had a penetration test done, your final report will almost certainly include the following suggestions:
1. Manage Legacy Protocols
Disable LLMNR, NBNS, SMBv1. This one comes up every single time. Even if you've been doing vulnerability assessments and patching all your stuff, these vulnerabilities often show up because Nessus rates LLMNR and NBNS protocol use as "informational." However, the presence of these broadcast name resolution protocols leaves open a large vulnerability that attackers are all too willing to attack. The problem is that with an attacker connected to the network, or even with a compromised computer on the network, an attacker can respond to any broadcast requests for name resolution as the owner of the requested name. It's a classic poisoning attack, and more often than not provides the attacker with password hashes that can be cracked offline.
Remediation: Disable the use of LLMNR, NBNS, and WPAD protocols in group policy which should have minimal to no impact on your day to day production environment. Specifically test WPAD which is used for auto-configuring a proxy server for Internet Explorer, which you may or may not be using. These are largely legacy protocols that are not used in an enterprise environment. Disabling SMBv1 will probably require some testing before completely phasing out, as there are some pieces of current software that may still rely on this older protocol.
2. Disable LM, NTLMv1
There is no good reason in 2017 why LM hashes should be a thing. Where I've seen this is in networks that have been around since the 90's. These settings have carried over as Domain Controllers were upgraded over the past few decades. LM hashing is wildly inadequate for today's computing power. To give you an example, I have a dirt-cheap home password cracking machine and cracked the entire LM key-space in less than an hour. 40,000 passwords cracked in the time it took me to watch an episode of "Vikings". Friends of mine have done this in less than 10 minutes with far better cracking setups. Think about that - no matter how complex or long your password is, if it's stored as LM, it can be cracked in less than 10 minutes.
Remediation: disable LM hashing, and, unfortunately, require a password reset for all your accounts if it was enabled. Until the password reset occurs, the LM hash will be available in the domain controller. While you're at it, disable NTLMv1 as well. It too is an outdated hashing algorithm and while not as easy to crack as LM, it doesn't have modern cryptographic features to defend against password cracking. Microsoft has information published on this as well.
3. Don't Use Common Passwords
It used to be the case that changing your password every 90 days was considered good practice. Additionally, password complexity is being enforced by default in most enterprises and users have by and large accepted these new conditions. Unfortunately, one very common habit we see users fall into is a common password algorithm that is easy to remember, complies with a 90 day password change, and complies with complexity rules. Allow me to demonstrate: Summer2017! , Fall2017! , Winter2018! and so on. In an engagement, I will often try one or more of those passwords for every user I discover. This is a breadth-first password brute-force and is tuned so as not to disable any accounts through the "too many password attempts" lockout feature.
Remediation: user education, increase default password length requirement from 8 to 12+, and add simple password brute-forcing as part of your vulnerability management program to check for weak or known passwords. Additionally, consider changing your password policy to require longer passwords 15+ and remove the cyclical password change requirement. Check out the NIST website for more information on the NIST password guidelines.
4. Enforce SMB Signing for Servers and Workstations
Back in the day, in the early '00's, Microsoft warned about enabling SMB signing and possible performance hits to SMB file transferring. I've yet to find an article or post that addresses this performance concern that is newer than 2012, let alone any empirical data to support the claims. It is my understanding that modern protocols and processors largely make this issue moot. Furthermore, SMB signing is now enabled by default for all server-to-server communications. SMB signing eliminates the ability of attackers to capture and relay hashes intended for one host to another host. This technique is extremely effective at getting administrative or SYSTEM level permissions on systems throughout a network, especially when paired with LLMNR.
Remediation: force SMB signing for all domain-joined computers. I will caution that this may disrupt legacy services and systems in unexpected ways. Proper testing is highly encouraged.
5. Deploy LAPS
The Local Administrator Password Solution (LAPS) from Microsoft addresses the issue of using the same local administrator password on all workstations. This is a highly common practice in IT, and yet leaves all systems open to compromise should one workstation get compromised. If a single workstation is compromised, and the attacker is able to get a highly privileged session and subsequently the local administrator password - any machine that shares that password can be considered compromised. Furthermore, it is a highly common technique to "hunt" for domain administrators and other highly privileged accounts once local admin rights have been gained. Using this local admin password, an attacker can often steal the credentials of the user they are targeting.
Remediation: Deploy LAPS, which rotates and stores the local administrator password in the domain controller. Every workstation is given a unique local administrator password. Should you need the local administrator password for offline maintenance, it can be retrieved from the workstation properties in the "Active Directory Users and Computer" tool or through PowerShell. Additionally, prevent local computer accounts from authenticating over the network.
6. Anonymous Enumeration Allowed
For whatever reason, some Domain Controllers have been setup to allow anonymous, or non-domain joined users, to query the Active Directory. With this simple setting, anyone connecting to the network can get a listing domain users, computers, and groups. With this list, a breadth-first password brute force can be performed against all users, an attacker gains knowledge of privileged accounts and possibly where those accounts are logged in, the domain password policy is revealed, and a host of other helpful information is divulged for the reconnaissance phase of an attack.
Remediation: Disable anonymous enumeration of SAM accounts and Shares
7. Remove Stored Passwords in Group Policy Preferences (GPP)
This one isn't as common, though when it does exist, it can be extremely effective. This problem rears its ugly head when a group policy preference is set to map a printer, or perform some administrative task on a workstation or server at login. The password to temporarily elevate privileges and perform this action is stored with the GPP as an encrypted string. Microsoft published the private key for those settings and anyone can decrypt the stored password.
Remediation: Review your group policy preferences and ensure no passwords are used or stored, you can use a script provided by Microsoft to search SYSVOL for any GPPs that have stored passwords
8. Have a good inventory of hardware and software, make sure default user/pass isn't in use
Another common finding is default usernames, passwords, and installs. Twice I've found a video conferencing system installed with default credentials, and both times these systems were connected to active directory for single-sign on. In one case I was able to retrieve all the users and groups from the domain controller over the internet. In another case, I got all the user and groups, as well as the credentials used for querying the domain controller. Other common systems are network switches, printers (so, many, printers) which are joined to the domain, and default application installs which provide some kind of code execution on the machine the software is installed on.
Remediation: know what you have deployed on the network, and verify that no system is setup to use its default credentials. Change any default credentials to a unique password and use a password manager to store those credentials.
9. Use MFA for any remote access, or to sensitive networks like CDE or OT
In the above case, where I got credentials from a default system install, the only thing that prevented me from logging into the network through their VPN with the discovered account was multi-factor authentication. Two other controls failed or were non-existent, and the third prevented deeper penetration into the network. This is defense in depth. We can't rely on user credentials NOT getting stolen, and by adding a second factor authentication mechanism (something you have, something you are) you increase the difficulty and potentially stop the attacker from fully executing their attack.
Remediation: deploy multi-factor authentication at minimum for all remote access solutions and all cases where a security boundary is being crossed (IT network to Operational Technology or Cardholder Data Environment). Better yet, use MFA for your IT network as well.
10. If you can't completely rip & replace legacy hardware & software, segment it like it's Hannibal Lecter in "Silence of the Lambs"
We've all been there. That red-headed stepchild system from 2003 still in production. The multi-million dollar radiology system. The stupid PoS software solution for a deeply vertical field. Or the system purchased because the CEO's brother owns the company. None of these systems have even considered security as a requirement. Maybe the manufacturer of the system is now out of business, or acquired, or charges an insane amount of money for patches. The point is, you have a system on your network that is for all intents and purposes "Swiss cheese" and you're in charge of keeping it running and keeping it from getting completely pwn'd.
Remediation: if you've seen "Silence of the Lambs", think Hannibal Lecter in his cell, in a strait jacket, wearing a mask. He's been rendered incapable of hurting anyone around him or even himself for that matter. What this looks like is a strongly segmented system, possibly in its own subnet and VLAN with restrictive firewall rules and solid monitoring. Firewall rules that only allow exactly the kind of communication it needs to operate, and absolutely nothing else. Solid logging and monitoring should also be included to detect the inevitable attacks it will be the target of.
Final words
If you're able to pull all of these off, you'll stymie many a penetration tester, as I did. Our assessor showed up and spent three days pulling his hair out trying to find a way in. In the end, he reluctantly accepted defeat, and we were the first organization this firm was unable to compromise. My boss was ecstatic, and our CEO was proud. I, on the other hand, was disappointed. Unable to find exploitable weaknesses in our network, the pentester showed management that my work was "done". In other words, my political capital all but evaporated for getting new projects accepted and approved as we were demonstrably "secure". My credibility was through the roof, however.
Applying these remediations will move you from a "beginner" penetration test that tells you about low-hanging fruit and into the realm of discovering insecure windows configuration defaults, group permissions, and windows hardening suggestions. These will offer direction that more accurately reflects today's threat actor tactics, techniques, and procedures (TTPs).
If you want more tips on hardening your Active Directory domain, I highly recommend Sean Metcalf's blog adsecurity.org