Active Directory - advanced topics - Wiki

Active Directory - advanced topics - A Red-Team informed Wiki on Active Directory security

Microsoft Active Directory is among one of the least understood technologies in small-medium organizations especially. These orgs may even be in a monoculture of Microsoft-developed (or at least branded) products for their daily business.

MS Active Directory puts it all together. It’s like the patch panel on a network level. And if you don’t pay attention you are going to create a mess no one can ever clean up :wink:

What is Microsoft Active Director(y)

Active Directory Domain Services (AD DS) directory service is the distributed directory service that is included with Microsoft Windows Server operating systems. AD DS enables centralized, secure management of an entire network, which might span a building, a city, or multiple locations throughout the world.
(Source: Microsoft)

Typologies and features

  • Windows (and Linux via the AD LDAP connection as well) servers and clients
    • Account infos, Management profiles, printers, file shares, …
  • VPN systems look at AD for policies (network permissions per user group for example)
  • Email Servers (incl. address book services) / Business Collaboration

Non-Microsoft systems may also use some parts of the Active Directory protocols.


  • Schema – defines AD objects and attributes
  • Query and index mechanism – search and publish objects and properties
  • Global Catalog – info about every object in the directory
  • Replication Service – AD info distribution across AD DCs

Installation of Microsoft Active Directory Services via Powershell

This isn’t an Administrator Wiki, but Powershell is generally helpful:

Add-WindowsFeature AD-Domain-Services

Defaults and backwards-compatibility

Lanman and NTLM(v2)

Lanman by default is not enabled on Windows Server 2019 (Standard). It’s for older systems, and today it is uncommon.

Here is the default for the encryptions that are enabled for Kerberos (see below):

The larger the network, the more likely it is that some legacy components require these old authentication hash functions: Lanman and NTLM(v2).

  • RC4 tickets (see below) are atypical in any case (suspicious, may indicate Kerberos attacks called Kerberosting)

Ideally, this is AES only; but this should not imply that just setting the encryption options is enough to harden an AD environment in a Windows Enterprise setting.


Kerberos is the main authentication mechanism of an AD Domain. It’s a network authentication protocol based on tickets. It allows two parties to authenticate to each other; client-server usually. This may happen over an insecure network channel, assuming that both parties trust the Kerberos server.

In case Kerberos isn’t available by default (information status: Q2 2021) Windows AD will fallback to NTLMv2 (older protocol)

Components of Kerberos

Three heads of the Cerberus:

  • Key Distribution Center (Kerberos server / Domain Controller)
  • client
  • server

Steps of a Kerb auth workflow (simplified)

Scenario: The client wants to authenticate to a server of the AD Domain.

  1. Ticket Granting Service --request–> Domain Controller (Authentication Server)
  2. DC --reply–>


Scenario: Local Privilege escalation via an LDAP relay attack and AD Kerberos Resource-based Constrained Delegation

In this lab’s Active Directory Domain (cqure) I added a user “hackerman”. Man Hacker is a common employee with a Windows 10 system. He likes computers.


For reference: this lab uses Windows Server 2019 for the Domain:

Screenshot 2022-05-12 at 16.26.05

Hackerman is just a user on a Windows 10 endpoint. Not a (local) Admin. No local vulnerability is being abused here. No server remote exploit even. The Windows AD server uses the default configuration (where LDAP signing is disabled, because many devices do not support this).

Via some kind of attack surface (Microsoft Office Macro, Outlook Email attachment, Social Engineering, …) an AD attack is executed on the local Windows 10 endpoint by our unsuspicious user Hacker Man:

This attack succeeds because the requirements are met. LDAP Signing is disabled on the respective Active Directory Domain Controller. It’s important to mind that this is not some kind of User Account Control (UAC) bypass. This is a Kerberos Relay to LDAP abuse at its core, an architectural issue on Active Directory services level is being abused. Without the initial target machine being a member of the cqure AD Domain this attack path cannot succeed of course.

I think it’s obvious that with SYSTEM level access post-exploitation steps to prepare for lateral movement can be deployed. Once privileged Kerberos tokens are being acquired (via LSASS memory), the AD Domain and the connected systems are lost to the attackers. Needless to say, local AntiVirus / Endpoint Protection services can be disabled.

– This a PoC. In a Red Team or Pentest engagement, Cobalt Strike or an equivalent could be used to gain persistence. Threat actors would probably use something similar.

– Modern AntiVirus / Endpoint Security like Windows Defender can initiate a cat-and-mouse game where intruders use obfuscation techniques to evade signature-based detection. More sophisticated approaches like Intrusion Detection Systems need to be tested with PoCs like this to determine their efficiency in real-world scenarios.

– Another way to remain stealthy is of course to either extract / refactor / port the relevant parts of the source code or to make trivial changes. It’s just a Visual Studio project after all.

Even though LDAP Signing can block the attack path, it’s evident that AD is architecturally broken.