Breaching Active Directory

Techniques and tools for acquiring AD credentials and enumerating AD.

Overview

Before AD misconfigurations can be exploited, initial access is required. Due to the huge number of AD services & features, the attack surface for gaining initial access is significant. When looking for initial access, the permissions are not relevant, we are looking for a way to further enumerate AD.

The following techniques will be covered:

• NTLM Authenticated Services

• LDAP Bind Credentials

• Authentication Relays

• Microsoft Deployment Toolkit

• Configuration Files

OSINT and Phishing

Both are common methods for gaining initial AD access, these are covered more in Phishing and under OSINT. In the context of AD credentials, OSINT can lead to publicly disclosed information for several reasons, such as:

• Users asking questions in public forums, accidentally disclosing credentials in the process.

• Developers uploading scripts to GitHub with hardcoded credentials.

• Credentials being disclosed in other breaches, sites like HaveIBeenPwned and DeHashed are good resources to determine this.

NTLM and NetNTLM

New Technology LAN Manager (NTLM) is used to authenticate users' identities in AD. NTLM is used for authentication by using a challenge-response scheme called NetNTLM. Services that use this can be exposed to the internet, for example:

• Internally-hosted Exchange servers which expose an OWA (Outlook Web App) login portal.

• RDP service of a server being exposed to the internet.

• Exposed VPN endpoints that were integrated with AD.

• Web apps that are internet facing using NetNTLM.

NetNTLM allows an app to play the middle man between the client and AD. All authentication material is forwarded to the DC as a challenge, and if successful, the app will authenticate the user. This method of authentication prevents the app from storing AD credentials, which should only be stored on a Domain Controller.

Brute-force Login

Exposed services can provide avenues to test credentials that may have been discovered via other means. Brute-forcing typically won't work as AD environments (for the most part) have account lockout configured. Instead, password spraying can be used. This is where one password is chosen and tried against numerous accounts. Due to the amount of failed logins this generates, this is easily detectable.

LDAP

Another authentication method AD apps use is LDAP (Lightweight Directory Access Protocol). In LDAP, the app directly verifies the user credentials. LDAP is popular in third-party apps which integrate with AD such as:

• GitLab

• Jenkins

• Custom web apps

• Printers

• VPNs

As LDAP services require a set of AD credentials, this opens additional attack avenues, we can attempt to recover AD credentials from the service used to gain access to AD. Gaining a foothold on the right host, like a GitLab server, could mean its as easy as reading out a configuration file.

LDAP Pass-back Attack

LDAP pass-back is common against devices like printers. This can be performed when we gain access to a device's configuration with LDAP parameters specified. From a device such as a printer with this configured, the LDAP configuration can be modified to point LDAP authentication to a rogue device, the communication can then be intercepted for credentials. The default port of LDAP is 389.

Hosting Rogue LDAP Server

OpenLDAP can be used to configure a rogue LDAP server. This can be installed with:

sudo apt-get update && sudo apt-get -y install slapd ldap-utils && sudo systemctl enable slapd

The LDAP server can then be configured with:

sudo dpkg-reconfigure -p low slapd

The settings should be configured as follows:

• Skip Server Configuration: No

• DNS Domain Name: Target domain

• Organisation Name: Same as the DNS Domain Name

• Administrator Password: Whatever you want

• Database Backend to Use: MDB

• Remove Database when Slapd is Purged: No

• Move Old Database: Yes

The server must then be downgraded to ensure it only supports PLAIN and LOGIN authentication methods. To do this, create a new file called olcSaslSecProps.ldif with the following:

dn: cn=config
replace: olcSaslSecProps
olcSaslSecProps: noanonymous,minssf=0,passcred

Once this is created, the following can be used to apply the patch to your rogue LDAP server:

sudo ldapmodify -Y EXTERNAL -H ldapi:// -f ./olcSaslSecProps.ldif
sudo service slapd restart

To verify the configuration, run:

ldapsearch -H ldap:// -x -LLL -s base -b "" supportedSASLMechanisms

The returned LDAP credentials can then be captured with nc -nvlp 389 or sudo tcpdump -SX -i [INTERFACE] tcp port 389.

SMB (Server Message Block)

SMB allows clients to communicate with a server, in AD networks, SMB governs everything from file sharing to remote admin to the "out of paper" alert your PC receives. Earlier versions of SMB were deemed insecure as several vulnerabilities were discovered that could be leveraged to discover credentials, two of these are:

• NTLM challenges can be intercepted, therefore, offline password cracking can be used to recover the associated password.

• A MITM attack can be staged, relaying the SMB authentication from client to server, which provides access to an active, authenticated session.

LLMNR, NBT-NS & WPAD

Responder allows you to perform MITM attacks by poisoning the responses during NetNTLM authentication, making the client talk to you instead of the actual server they want to talk to. In a LAN, Responder will try to poison any Link-Local Multicast Name Resolution (LLMNR), NetBIOS Name Service (NBT-NS) and Web Proxy Auto-Discovery (WPAD) requests that are detected. Typically, if these requests hit our machine, they would be dropped, however, Responder sends poisoned responses to tell the host that our IP is associated with the correct hostname.

Intercepting NetNTLM Challenge

Responder tries to win a race condition by poisoning connections to make sure you intercept it. This normally limits Responder to local networks. It is important to note that this behaviour is disruptive and can be detected, poisoning requests prevents normal authentication attempts from succeeding.

Relaying Challenge

This is more difficult than capture, as it requires prior knowledge of the permissions of the associated account. The following things must be in your favour:

• SMB Signing should be disabled or not enforced. If this is enabled, we can't forge the message signature.

• The associated account needs the correct permissions on the server to access the resources.