How Do Hackers Gain Initial Access on an Active Directory Network

Active Direcory is filled with services with bad security designs by default. Many attackers don’t even have to exploiting patchable vulnerability found in the code to gain total control over the domain. In this article, I will demostrate how an attacker would gain initial access to an Active Directory Domain by obtaining the first set of credentials on the network. Specifically, I will cover attacks like LLMNR Poisoning and SMB relay attack.

Lab setup

Before we start, I just want to briefly go over the set up I will be using to demonstrate these attacks. All of the following machines, except for my Desktop, are virtualized on my Proxmox server.

I went over the exact process of setting up my lab in another article, but here is a brief overview of my network anyways.

Network

ad_network

  • PfSense Firewall: I decided to simulate a real enterprise AD network by cordoning it off from the rest of my network. So the attacks demonstrated here are very much limited to internal ones.

  • DOMCON: The domain controller. This is where all the credentials are stored, and all authentication on the AD network have to go through this guy. This is the target the hackers would eventually go for.

  • EIGHTY-SIX and STEINS;GATE: These two are workstations that are a part of the AD network. They have access domain users.

  • The Kali Linux attacker: This is the machine we will demonstrate the most of our attacks through. It is connected to our active directory network via the PfSense firewall.

  • The Wireguard VPN. This acts as a gateway for computers to access machines inside the network. However, the problem is that a VPN does not allow you to listen on the network. So it’s not really useful here, but I decided to include it reguardless.

On the workstations:

  • Make sure Windows Defender Anti-Virus and Firewall is turned OFF
  • On one of the workstations, Map a network drive to the share we created in the tutorial, but log in with the Domain Administrator’s credential.

Users

users.png

  • Administrator: The boss of the domain, has pretty good password security.
  • Guest: Disabled
  • SQL Service: A service account that has the same privileges as the administrator (people do this pretty often!), and the password is written in the discription
  • Lena Milize: A domain user, also is local admin on EIGHTY-SIX and STEINS;GATE workstations (this is to demonstrate SMB relay attacks), has password: Password1
  • Suzuha Amane: A domain user, also is local admin on STEINS;GATE, has password: Password1

On the local user front, make sure the Administrator account on each machine is enabled, and the password is simple and reused (imagine being an IT person setting up a bunch of computers). I set it to Password1!.

With our environment laid out, let’s get into our first attacks!

LLMNR Poisoning

LLMNR stands for Link-Local Multicast Name Resolution. It is a name resolution protocol that is used in place of DNS if DNS cannot resolve the domain name on Active Directory domains. For example, if a user had a typo in the share they try to access, a LLMNR broadcast will be send. Suppose we, as the attacker, respond to that broadcast, say that the non-existent share is on our computer. The client will then send the user’s NetNTLMv2 hash of their password to us. This then allow us to crack the password and obtain our first set of domain credentials.

llmnr.png

One may say it’s not bad for security to send the hash since all an attacker can do is to guess the password, which takes exponetial time to complete. Well, that’s only true if the users are picking totally random password. People in general like easy-to-remember passwords that are easy to crack. I think any network protocol that requires the user to send over the hash of their password, no matter how secure the hashing algorithm is, is inherently insecure. Fortunately, Microsoft has already began phasing out this protocol in favor of mDNS, but I guarantee you can still find companies leaving this protocol enable on their network.

Demonstration

  1. In order to respond to the LLMNR broadcast, we want to use the responder tool provided in Kali Linux. This is that is designed specifically to poison NBT-NS, LLMNR and mDNS. So run the following command on your attacker machine:
$ sudo responder -I <LISTENING_INTERFACE>
  1. We then pretend to be the user, and try to access the shares on DOMCON, but we made a typo. Instead, we are now trying to access DOCOM. This will trigger a LLMNR broadcast. fat_finger.png
  2. If we check back on our Kali Linux attacker, we would see that the NetNTLMv2 hash is already captured! We can then copy this hash to file so we can crack it. llmnr_hash_captured.png
  3. To crack the hash, we want to transfer it on to a machine running a bare metal since using virtual machines to crack passwords generally gives us subpar performance. We can then use hashcat to crack this password, with mode 5600 for NetNTLMv2.
$ hashcat -m 5600 <HASH_FILE> <WORDLIST> -O
  1. We have successfully obtained our first set of credentials: lmilize:Password1.

Mitigation

It would be the best if LLMNR is turned off in its entirety. However, if we can’t we should enforce some sort of network access control so that attackers can’t join our network willy-nilly. In addition, there should be strong passwords policy for the users.

SMB Relay attack

Instead of cracking the hashes, we can also gain access to machines by relaying these hashes. If we are unable to crack these hashes, SMB relay attack might be a good option for us.

However, there are several requirements to pull off this attack:

  • SMB signing must be disabled or not enforced on the target. SMB signing can prevent this attack by create a cryptographically secure signature for each SMB requests. In other words, we can’t simply take the hash from somewhere else and hope that it will work. This is a default on Windows Desktops.
  • A domain user must be a local admin on more than one machines.
  • Relay user credentials must be admin on the machine for the attack to really mean anything. Our access would be very limited with the crendential of a non-admin user.
  • For the purpose of this demonstration, Windows Firewall and Defender are turned off. There are certainly AV and firewall evasion techniques used by real pentesters to make this attack work with these security features turned on.

Demonstration

  1. First, we can run a Nmap script to identify which machines does not have SMB signing enabled and enforced. Indeed, since we did no additional configuration, SMB signing is not enforced on those two machines.
$ nmap --script=smb2-security-mode.nse -p445 <IP_ADDRESSES>

smb_signing_scan.png

  1. Responder also needs to be slightly reconfigured for this to work. So in /usr/share/responder/Responder.conf, turn off SMB and HTTP. This is because we are using something else to handle SMB. smb_relay_responder_config.png

  2. Run responder.

$ sudo responder -I <LISTENING_INTERFACE>
  1. On a new tab, we want to set up our SMB relay using ntlmrelayx.py provided by Impacket v0.9.19. This version seems to be more consistent. Before running, make sure you write down a list of your targets in a file. When run, the command below will dump the SAM database on the target machine. If you want a interactive shell, use the -i option, and a shell session will be opened up on a local port.
$ sudo ntlmrelayx.py -tf <TARGETS> -smb2support
  1. We can trigger this attack again by trying to access a host name the does not exist on the network from a workstation. If we check back on the attacker machine, we will see that the hash is successfully relayed to the STEINS;GATE workstation (10.10.0.104), and since lmilize is a local admin on both machines, we are able to dump the SAM hash on STEINS;GATE. We can then either crack these hashes, or simply use then in pass-the-hash attacks. smb_relay_success

Mitigation

  1. Enable SMB signing all devices, including workstations. This will make sure that attacker cannot access other machines using the hash. However, this could lead to decreased performance when copying files from and to the SMB shares.
  2. Disable NTLM authentication on the network. Attackers can no longer use the captured hashes to authenticate for SMB. However, if Kerberos stops working, Windows will default back to NTLM authentication regardless of our configuration, making the attack viable again.
  3. Account tiering: A domain admin account should not be logged into a Workstation. This is simply following the security principle of least privileges.
  4. Local Admin restriction: Domain users should not be admins on Workstations. This means the damage of an SMB attack will be very limited. However, this might give the IT team more work because now users have to ask for their permission to install software, or do anything the involves local admin privileges.
  5. Mitigate against LLMNR poisoning. This way attacker’s can’t obtain the hash that used in the SMB relay attacks in the first place.

Summary

LLMNR poisoning and SMB replay attacks are both powerful attacks against active directory networks that can give attackers an initial set of credentials on the network. The key to preventing these kinds of attack is to disable unused services and enforce strict access control.

#homelab #Pentesting #Active Directory #windows