Summary of Initial Attack Vectors to Active Directory

In this blog post, I will describe the following three attack vectors to Microsoft Active Directory: LLMNR Poisoning, SMB Relay Attack and IPv6 Attack.

In this blog post, I will describe the following three attack vectors to Microsoft Active Directory: LLMNR Poisoning, SMB Relay Attack and IPv6 Attack. These notes of mine come from the online course “Practical Ethical Hacking” by Heath Adams (aka The Cyber Mentor) where we disabled Windows Defender for demonstrative purposes.

Active Directory Initial Attack Vectors

LLMNR Poisoning

This attack misuses the Link-Local Multicast Name Resolution (LLMNR). LLMNR is a protocol that allows name resolution without the requirement of a DNS server. It sends a request across the network asking all listening Network-Interfaces to reply if they are authoritatively known as the hostname in the query, thus providing a hostname-to-IP service.

This service can be exploited by setting up a node on the network that pretends to be whoever the query is looking for. The client requesting the information will trust whatever machine answers first, because the protocol specifies that all received responses are authoritative and trustworthy.

In our attack situation, the victim machine will request to connect to a non-existing file share and Windows will use LLMNR to identify this file server. Our attacking machine will reply to this request with Responder.py and Windows will send us the credential hash of the current user for that victim machine, thus disclosing those credentials.

Check out this post by Black Hills Information Security (BHIS) where they show how to disable LLMNR with AD Group Policy.

Afterthought: NBT-NS is another fallback mechanism for name resolution. This service is flawed by design and should be disabled too.

SMB Relay Attack

This attack extracts a user’s credential hash from a machine and relays it to another in order to get system access on it. In order for this to work, there are two requirements. The first requirement is that SMB message signing – that is, the process of validating the source of requests against a system’s SMB services – is not enforced. The second requirement is that the user, whose credentials we relay across, is a local administrator on the machine receiving the hash.

Before starting the attack, we check which machines on the network do not enforce SMB message signing. To do this we run an nmap scan (other scan solutions are available too). If under smb2-security-mode you read “Message signing enabled but not required”, then that machine is a potential target!

The SMB Relay attack is similar to LLMNR poisoning in that we are listening for resolution requests. However, this time we won’t dump the credential hash. Instead we will reflect user authentication attempts against systems on the network. The relay mechanism we use is called ntlmrelayx.py. When ntlmrelayx.py makes a successful connection, it dumps all the local hashes on the target machine.

In this video by BHIS, John shares with us why we have to relay the hash. Spoiler alert: Microsoft doesn’t let you reflect the hash back to the source system it came from.

IPv6 Attack

This attack abuses the default IPv6 configuration in Windows networks to spoof DNS replies by acting as a malicious DNS server and redirecting traffic to an attacker specified endpoint, and by then exploiting the WPAD (Windows Proxy Auto Discovery) feature with the goal of relaying credentials and authenticating to various services within the network.

The most known implementation of this attack is called mitm6. It starts with listening to the requests for an IPv6 configuration via DHCPv6 that each Windows machine makes regularly. Then mitm6 replies to these requests and sets the attacker’s IP as the default IPv6 DNS server for the victim. This is very convenient, because Windows prefers IPv6 DNS servers over their IPv4 counterpart.

Now the victim machine will start querying for the WPAD configuration of the network1. As the location of this configuration is only requested via DNS, the victim will connect to the attacker machine which will prompt authentication. The credentials will be then relayed by ntlmrelayx.py to other services in the network. ntlmrelayx.py will dump all juicy information, such as a list of domain users by group, after a successful connection.

This dumped html file lists the domain users by group. In the list, we see the SQL Service which has its own password in plain text under Description.

I hope you liked this post. If you have any question, feel free to leave a comment in the comment section. Never stop learning!

How to verify the integrity and authenticity of a Kali Linux OVA image

You downloaded an image to install Kali Linux and you want to make sure that this file is an integral and authentic copy? This post is for you!

You have downloaded an image to install Kali Linux1 as a virtual machine (VM) on your hypervisor and you want to make sure that this file is an integral and authentic copy? If the answer to this question is yes, keep reading! In this blog entry, I will describe how to verify the integrity and authenticity of a Kali Linux OVA image with Windows 10.

There are two ways to install Kali Linux on a virtual machine. The first is to create a new VM and manually configure it on the hypervisor2. Once this is done, the Kali ISO image3 needs to be attached to the virtual CD-ROM and then the VM can be booted. The second method is to import a copy of an existing virtual machine into the hypervisor. Such copy is distributed as an OVA4 package, which is an archive file that contains metadata for the VM – such as name or hardware requirements – and at least one disk image, among other things. Before importing the OVA image into the hypervisor, we need to make sure that this file wasn’t damaged during the download and perhaps more importantly that this is an authentic copy. This process is what I present next.

The first step of this process is to download the OVA image. In order to do this, go the official website of Offensive Security5: https://www.offensive-security.com/kali-linux-vm-vmware-virtualbox-image-download/. Here you should choose the OVA image compatible with your hypervisor. As I use VirtualBox6, I downloaded the VirtualBox 64-bit file. While downloading, take note of the checksum (SHA256Sum) written next to the file that you selected:

OVA images and SHA256Sums on offensive-security.com

The next step is to open the Windows PowerShell and cd7 into the directory where you saved the OVA image. Here run the following command (modify it with the name of the file that you downloaded): Get-FileHash kali-linux-2020.3-vbox-amd64.ova -Algorithm sha256. If everything worked well, you should see something like this:

Get the hash from the OVA file

The alphanumeric string under the column Hash is the information we need to compare to the SHA256Sum that we took note of before in this tutorial. As I’m lazy – and thus efficient 😀 – I did this with the Python Shell (see Screenshot below; modify the command with your checksum data). If the result of running this command is True, you are ready to go8: