Once an adversary has obtained an initial entry point into your environment, they typically pivot around in the AD, looking to escalate their privileges further and eventually gain access to your crown jewels.
One of the most common attack flows looks something like this:
An adversary compromises a low-privileged user (through a phishing mail with a malicious attachment, for example), to get an initial foot in the door of your network.
If the user isn't already assigned administrative rights, the adversary exploits a local privilege escalation issue to get them. To pivot further in the network, the adversary attempts to steal the credentials of administrative domain accounts, knowing they'll provide access to additional domain resources.
Once they have administrative domain account credentials, the adversary can dump them from memory and further compromise the environment (example: a typical Mimikatz attack). Tools like Bloodhound will map out where administrators are connected, often giving adversaries exactly the information they need.
If BloodHound doesn't provide the "path to domain admin," another common trick involves disabling or breaking something small on a compromised machine to lure help-desk or IT staff to a machine controlled by the adversary.
With Domain Administrator access, the adversary can attempt to persist his administrative access to the domain (by generating a Golden Ticket, for example).
What kind of controls can we implement to prevent these attacks from succeeding?
- Use separate accounts for all administrative purposes.
- Design your environment using Privileged Access Workstations.
- Use domain protected users.
- Deploy CredentialGuard on Windows 10 and protected processes on Windows 8.
- Deploy Local Administrator Password Solution (LAPS).
1. Use separate accounts for all administrative purposes
- Use accounts with the minimum privileges necessary to do specific jobs.
- Create fine-grained administrative accounts, such as database server, web server, and workstation administrators.
- Educate your staff on how administrative privileges should be used.
- Don't give helpdesk users Domain Administrator accounts so they can fix small issues on an employee's workstation?never give access that isn't absolutely needed.
- Finally, have administrators create a separate account for administrative use and a normal account for day-to-day use. (This is highly recommended.)
Controls such as UAC (User Account Control) aim to limit when the administrative token (for example, administrative privileges) can be used, but how could those controls be bypassed?
An excellent overview of current UAC bypass methods is listed on Github.
2. Design your environment using Privileged Access Workstations
This practice, recommended by Microsoft, mainly applies to highly privileged accounts that administer the AD management of the active directory (and use of highly privileged accounts). The process should only be performed from a dedicated system that can be seen as an administrative "jump box." (Never allow direct administrative access to the Domain Controllers from normal "internal network zones.")
Microsoft labels these "jump boxes" as "Privileged Access Workstations." Make sure to subject these systems to additional security hardening, such as the full implementation of Credential Guard, and dedicate them exclusively to administrative functionality?don't use them to run software such as email applications, web browsers, or productivity software like Microsoft Office.
In Best Practices for Securing Active Directory, Microsoft describes three core principles for these administrative hosts:
- Never administer a trusted system (that is, a secure server such as a domain controller) from a less-trusted host (a workstation that isn't secured to the same degree as the systems it manages, for example).
- Don't rely on a single authentication factor when performing privileged activities. User name and password combinations aren't acceptable authentication, because only a single factor (something you know) is represented. Consider where credentials are generated and cached or stored in administrative scenarios.
- Although most attacks in the current threat landscape leverage malware and malicious hacking, don't omit physical security when designing and implementing secure administrative hosts.
For more on this, see:
Implementing Secure Administrative Hosts
Privileged Access Workstations
3. Use domain protected users
Domain protected users are defined at the AD level, and enforce a number of security controls to protect sensitive credentials for a user or group. They can be configured as of Windows 8.1/Windows Server 2012 R2. They enforce:
Credential delegation (CredSSP) and Windows Digest (Wdigest — as of Windows 8.1 and Windows Server 2012 R2) will not cache the user's plain text credentials.
Kerberos will no longer create DES or RC4 keys. It will also not cache the user's plain text credentials or long-term keys after the initial TGT (Ticket Granting Ticket) is acquired. This control is mainly aimed at Kerberoasting attacks.
Credentials are never locally cached to allow offline authentication.
When the domain is a Windows Server 2012 R2 domain, the user cannot authenticate with NTLM authentication?only Kerberos.
4. Deploy CredentialGuard on Windows 10 and protected processes on Windows 8
With Windows Server 2012 (and Windows 8), the LSA can be configured to have its lsass.exe process hosted as a protected process. With the correct privileges, accounts can access the memory of any Windows process?but not with protected processes.
Protected processes and their memory cannot be accessed by other processes, regardless of the account. Protected processes were introduced with Windows Vista for DRM purposes (to make media players), but repurposed for security boundaries when Windows 8 was introduced.
If you run the lsass.exe process as a protected process, tools like Mimikatz cannot access the process to extract credentials. However, protected processes are implemented in the Kernel software and can be defeated. Mimikatz includes a function to remove protection by requiring its kernel driver to be installed.
You can, however, detect and respond to installation of this kernel driver.
Credential Guard was introduced with the enterprise editions of Windows Server 2016 and Windows 10. It requires modern CPUs that provide virtualization functionality.
When Credential Guard is enabled, Windows still runs on top of the hypervisor and the hardware, and the LSA process still runs in userland. The difference is that the credentials are now stored in the Isolated LSA process (LsaIsol.exe), which does not run under Windows, but in the Virtual Secure Mode. This is a separate, virtualized environment separated from the other environments (like Windows) via hardware.
It's impossible for processes in the Windows environment to access processes in the Virtual Secure Mode environment, even by manipulating kernel data structures. All operations requiring credentials, like checking NTML hashes, do so by the Isolated LSA?upon request of the LSA. The credentials never leave the Isolated LSA.
5. Deploy Local Administrator Password Solution (LAPS)
In some cases, environments have the same local administrator password configured for all systems (for "recovery" reasons). From a security perspective, this is a horrible idea?if an adversary gets access one local admin credential, he can reuse it across the entire enterprise.
Local Administrator Password Solution (LAPS) is a free Microsoft utility that helps manage local administrator accounts securely. It generates a secure random password for the default local administrator account (500) and stores it in the AD.
LAPS can configure a maximum of two local administrator accounts per system; the randomized local administrator passwords are protected using ACLs in the AD. (The passwords are stored in clear text in the Active Directory, though, so be sure the ACLs are thoroughly reviewed to ensure they're properly configured.)
LAPS is supported on the majority of Windows systems, as of Windows 7 (both x86 and x64 systems). To read more about LAPS, check out this article on Technet.
SANS instructor Jason Fossen, whose work is highly focused on Windows security, also provides an interesting alternative to LAPS here.
How can I learn more about how to defend my environment against adversaries?
Take SEC599: Defeating Advanced Adversaries - Purple Team Tactics & Kill Chain Defenses. In this course, Purple Team Tactics & Kill Chain Defenses will arm you with the knowledge and expertise you need to detect and respond to today's threats. Recognizing that a prevent-only strategy is not sufficient, course authors Erik Van Buggenhout & Stephen Sims, both certified GIAC Security Experts, will introduce security controls designed to stop advanced adversaries. With more than 20 labs, plus a full-day "Defend-the-Flag" exercise, SEC599 presents students with real world examples to face modern attacks head-on.
