How to Secure Active Directory from Common Attacks

Share on linkedin
Share on facebook
Share on twitter

Table of Contents

Microsoft’s Active Directory (AD) is ubiquitous among organizations and is a common target for hackers. Compromising AD can lead to the deployment of ransomware and theft of sensitive information, which can be costly to an organization and negatively impact their public image.

As a team of pentesters, we at Vumetric Cybersecurity regularly attack (and compromise) our clients’ Active Directory environments as a means to improving their security. In doing so, it has become clear that AD’s default implementation is often insecure and subject to common misconfigurations that increase risk. Windows networks often favor compatibility over security, leaving them open to attacks.

This post will cover the most common attacks and how to secure Azure Directory against them by using real examples from our pentesting methodology. The focus will be on traditional Active Directory implementations – not Azure AD – although some concepts will overlap.

What real-world attacks look like

We assume that attackers have gained some level of access, such as the following:

  • A phishing campaign that has compromised a low privileged user’s workstation
  • A hacker who has compromised an external system with internal network access
  • A malicious actor with internal access such as a disgruntled employee
  • An attacker with physical or wireless access to the internal network

From a simple foothold, further attacks can be launched. Ultimately, the goal is to gain credentials of higher privileged users and eventually a Domain Administrator (DA) to gain complete control over the AD environment. From there, ransomware can be deployed, sensitive information can be exfiltrated, and extortion attempts can begin.

We simulate this type of scenario during our pentests by working from a low privileged foothold with the goal of escalating privileges using the following attack paths.

Poisoning the Network

The Attack

Using our initial foothold, we target specific Windows protocols to man-in-the-middle attacks in an attempt to capture the password hashes of users on the network; specifically, name-resolution protocols for file and web resources, such as LLMNR, NetBIOS Name Resolution, and WPAD, which are typically enabled by default and inherently insecure.

Here is an example of hashes being capture using the Python tool Responder:

Securing Active Directory

This type of attack can also be launched from Windows using a suite of PowerShell scripts called Inveigh.

This gets us the password hashes of network users that will let us move laterally or escalate our privileges. The password hashes can be cracked offline, or used in more advanced pass-the-hash and relay attacks to accomplish this.


Prevention of this attack involves disabling the insecure protocols via Group Policy…

  • LLMNR (Multicast Name Resolution)
  • NetBIOS Name Resolution (NBNS)
  • WPAD (Web Proxy Auto-Discovery)

…and enforcing required SMB signing while disabling support for the insecure SMBv1 protocol. Removing support for these legacy protocols and configurations should be at the top of every sysadmin’s list of how to secure Active Directory.

Please note: These protocols and configurations may be required to support certain network services and legacy systems. An investigation should be performed into the potential impact before deploying these policies. This applies to all recommendations made in this post.

Dumping Memory

The Attack

Windows stores hashed and sometimes plaintext passwords in memory, thus preventing users from repeatedly having to re-enter their password to access network resources.

Unfortunately, it also means that attackers can retrieve these credentials for all users with sessions on a compromised host.

If a Domain Admin is logged into a system an attacker has access to, that could mean Game Over in terms of a network’s security.

To retrieve credentials from memory, an attacker must have local administrative access to the system they are targeting.

This may be granted to them:

  • as part of their current Domain User’s permissions by exploiting a vulnerability in the underlying system.
  • or through the reuse of local administrative passwords – a common practice among sysadmins.

A tool such as mimikatz can be used to extract credentials from the memory of a Windows system:

Securing Active Directory

This can also be done at-scale over the network using another tool called CrackMapExec:

Securing Active Directory From Attacks

Like with our previous attack path, these hashes can be cracked or replayed to escalate our privileges, move laterally in the network, or launch additional attacks.


Preventing this type of attack can be hard, but the following can help:

  • Don’t reuse local administrative passwords; use a solution like Microsoft’s LAPS instead.
  • Implement memory-dumping mitigations, such as LSA Protection and CredGuard.
  • Practice proper Domain Admin hygiene – DAs should only log into non-shared systems like Domain Controllers; Administrators should use separate “technician” accounts for their day-to-day duties.
  • Deploy an antivirus with Tamper Protection that cannot be disabled or removed even by users with local administrative access.

Want to know how Vumetric has helped hundreds of organizations secure their Active Directory?

No matter the complexity of your Azure infrastructure, our experts understand the most intricate risks you face on a daily basis that could potentially be disastrous if a hacker exploited them.

Kerberos Weaknesses

The Attack

Kerberos is a ticket-based authentication protocol used on Windows networks. Two misconfigurations in Kerberos can allow attackers to request password hashes for the associated accounts, which may be highly privileged or even Domain Admins. From there, attackers can try to crack the password hashes in an offline attack in order to gain access to the accounts.

The first attack, known as “Kerberoasting”, requires the attacker to have at least Domain User access to retrieve the password hashes of an AD account with a Service Principal Name (SPN) assigned to it. SPNs are used to associate a service with an AD account (and grant its associated permissions) but also exposes that account to password hash disclosure via Kerberoast:

Here we see a password hash retrieved via Kerberoast by using GetUserSPNs from Impacket. Several other tools such as Mimikatz can also perform this attack. From that point on, we can attempt to crack this user’s password to gain access to their account.

An additional attack targets accounts with Kerberos pre-authentication disabled – typically done for the sake of compatibility. Similar to the preceding scenario, an attacker with access to at least a Domain User account – or with no domain access and a list of valid usernames – can retrieve the associated accounts’ password hash:

Securing Active DirectoryOnce again, we’re using Impacket and GetNPUsers to retrieve the hashes while something like Rubeus can do this from Windows. This is known as “ASREPRoasting.”

We often see these misconfigurations during pentests and attackers are sometimes able to gain access to sensitive accounts (including Domain Admins) this way, leading to a quick compromise of the associated AD domain.


The following steps can prevent and mitigate these attacks:

  • Minimize the use of SPNs where possible.
  • When using SPNs, practice the principle of least privilege with respect to the access they grant.
  • Never associate SPNs with Domain Admins.
  • Do not disable Kerberos pre-authentication, especially for sensitive accounts, such as Domain Admins.
  • For any scenarios where SPNs must be used or pre-auth disabled, enforce the use of extremely complex passwords. Assume that the password hashes of the associated accounts are essentially public, so it should not be feasible to crack them with any realistic amount of resources.

Enumeration and Exploitation

The Attack

If we’ve been unable to escalate our privileges by the previously described means during a pentest, it’s time to look for other options. There are three attack paths that are often fruitful and leading to the compromise of an Active Directory environment:

  1. Vulnerability Scanning: This is straightforward – unpatched services lead to the compromise of sensitive accounts and resources. A common target is hypervisors because they must be patched manually and doing so creates downtime for all associated virtual hosts. This means that they are often neglected and remain vulnerable to critical exploits, such as CVE-2021-21972 for VMWare.
  2. Default Credentials: As a rule during pentests, at least one service will be accessible using a default username and password, such as “admin” / “admin”. More than once, this has directly led to compromising a Domain Admin account.
  3. Checking Network Shares: We routinely find unmapped network shares that are accessible to regular Domain Users, including “IT” shares that often contain plaintext passwords, licenses, configuration files, and other information that can be used to access additional accounts and services on the network.

Basically, we’ll enumerate as much information as possible about what’s accessible on the network, then leverage any weaknesses to our advantage.


The basics! Change default passwords and never store passwords in plaintext – especially not in network shares accessible by regular users; password managers should be used to track this information. Keep systems patched including network devices, virtual machine hosts, software dependencies, and anything else that is not being updated automatically. It’s easy to neglect manual updates that may require scheduled downtime, which can leave critical systems exposed to attacks. In both these cases, it’s about doing what’s secure – not what’s convenient.

Summarizing How to Secure Active Directory

As cyberattacks on organizations become more prevalent and sophisticated, system hardening and proactive defense become essential. Let’s summarize the basic steps you can take:

  • Disable LLMNR/NetBIOS Name Resolution/WPAD to prevent poisoning attacks.
  • Enforce SMB Signing and disable SMBv1 to mitigate man-in-the-middle attacks.
  • Implement LAPS and memory-dumping mitigations to protect accounts and resources if a limited compromise has occurred.
  • Secure your Kerberos configuration.
  • Enforce the use of strong passwords and password hygiene, especially for sensitive accounts.
  • Do the needful: Patch your systems, run and monitor an IPS, audit your network resources and access control scheme, watch the logs, maintain robust backups, and stay abreast of the latest threats and attack methods.

While these items are a good start, they only represent the tip of the iceberg in the rapidly evolving field of cybersecurity. For peace of mind and a more thorough approach to network hardening, organizations should routinely engage the experts for a security audit or penetration test – and that’s where we at Vumetric Cybesecurity come in. If you’d like more information, reach out directly to a specialist.

A penetration test is a simulated hacking attempt that identifies opportunities for real hackers to break through your defences and perform various malicious acts. It generally leverages tools used by hackers and various professional methodologies to replicate the steps that modern hackers would take to intrude into your IT systems.

A pentest attempts to exploit your vulnerabilities to determine their potential impact, should they be used in a real hacking scenario. They provide a list of vulnerabilities with their respective level of severity, as well as technical recommendations to help your team apply corrective measures and focus on the most critical vulnerabilities.

These services allow your organization to answer the following questions, among several others:

  • Can a hacker gain access to any sensitive information?
  • Can a hacker hijack my technologies for any malicious acts?
  • Could a malware infection spread through the network?
  • Can an attacker escalate access to an administrative user?

Learn more about penetration testing →

There are many contexts in which a penetration test should be performed.

Here are some common use cases for a pentest:

  • As part of the development cycle of an application. (To test the security of a new feature/app)
  • To comply with security requirements. (3rd-parties, PCI, ISO27001, etc.)
  • To secure sensitive data from exfiltration.
  • To prevent infections by malware. (Ransomware, spyware, etc.)
  • To prevent disruptive cyberattacks. (Such as denial of service)
  • As part of a cybersecurity risk management strategy.

All businesses are advised to conduct a penetration test at least once a year, as well as after any significant upgrades or modifications to the company network. Given the rapid rate at which new exploits are discovered, we generally recommend that quarterly tests are performed.

Various steps are taken over the course of the project to prevent the potential impact of our tests on the stability of your technological environment and the continuity of your business operations.

For this reason, a communication plan will be put in place at the beginning of the project to prevent and mitigate any potential impact. A representative of your organization will be identified to act as the main point of contact to ensure rapid communication in the event of a situation directly impacting the conduct of your daily operations, or if any critical vulnerabilities are identified, for which  corrective measures need to be implemented quickly.

While we use a simple 4 levels risk rating approach (Critical, High, Moderate, Low), our risk assessment is actually based on the Common Vulnerability Scoring System (CVSS) standard. Two main criteria are considered when  assessing the risk level of each vulnerability:

  • Potential impact: The potential impact of an attack based on a vulnerability, combined with its  potential effect on the availability of the system, as well as the confidentiality and integrity of  the data.
  • Exploitability: The potential exploitability of a vulnerability; a vulnerability that is easier to  exploit increases the number of potential attackers and thus the likelihood of an attack.  Different factors are considered when evaluating the exploitability potential of a vulnerability  (e.g.: access vector, authentication, operational complexity, etc.)

Related Vumetric Blog Posts

Cyberattack impact

How Cyberattacks Impact Your Organization

A cyberattack is a malicious assault by cybercriminals aiming to damage a computer network or …

Read The Article
penetration test vs bug bounty

Penetration Testing vs Bug Bounty

Due to the recent spate of ransomware incidents, organizations and nervous IT administrators are wondering …

Read The Article
How Wordpress Gets Hacked and How to Prevent

How WordPress Sites Get Hacked And Fixes to Prevent it

WordPress sites get hacked on a regular basis, as it is by far the most …

Read The Article


We've Earned Internationally-Recognized Certifications

Contact a Certified Expert

Talk with a real expert. No engagement. We answer within 24h.
penetration testing provider

Stay Updated on Cyber Risks!

Subscribe to the Vumetric Monthly Bulletin to keep up with breaking news in the cybersecurity industry.

Need Help Securing Your Active Directory?

or give us a call directly at: