By Ícaro César: In this report you will follow a Security Research - Emulation and Detection, with the Technique of LLMNR(Link Local Multicast Name Resolution) and NBT-NS(NetBIOS Name Service), Spoofing e Poisoningwhich are two very effective methods for capturing NTLMv1, NTLMv2 or LM(Lan Manager) users. This type of attack is categorized as Man-in-the-Middle.
First of all, we need to understand: what is LLMNR and NBT-NS Spoofing/Poisoning? LLMNR is the successor to NBT-NS and was introduced into the Windows ecosystem with Windows Vista.
Both LLMNR and NBT-NS allow machines within a Windows network to find each other, and is essentially a "fallback" protocol used for resolving hostnames on a network when DNS hostname resolution fails.
This process of hosts reverting the flow to LLMNR or NBT-NS transmissions to find certain hosts on the network results in NTLMv1/v2 hashes being sent over the network, offering an adversary on the same network segment the opportunity to intercept and reproduce attacks such as Pass-The-Hash on other devices, or to crack the intercepted hashes offline.
A typical attack scenario for LLMNR or NBT-NS transmissions works as follows:
1. Host A requests an SMB share on the network identified as "intranet", but instead of typing "intranet" it mistakenly types "intrnet".
2. How to "intrnet" can't be resolved by DNS because it's a host and a share that doesn't exist, Host A sends an LLMNR or NBT-NS broadcast message again, asking the entire network segment for the IP address of the "intrnet" host/share, which was wrongly requested earlier.
3. The Adversary(Host B) responds to this broadcast message by claiming to be the system containing the resource "intrnet".
4. Host A, upon receiving the response from the Adversary(Host B), sends Host B (the adversary) its username and the NTLMv1 or v2 hash so that Host B can carry out the authorization validation process for access to the "requested resource".
Technique emulation - T1557.001
In order to carry out the Procedures of this Technique, we can use the tools Answertool, developed in Pythonor the Inveightool, developed in Powershell. In this emulation, we used the Responder tool to execute this procedure, but regardless of the tool used to execute the procedures, the LLMNR and NBT-NS Poisoning/Spoofing attacks still have the same result.
The laboratory in which we will be emulating this technique has the following topology:
Responder contains a configuration file that allows us to configure which services will be run to capture, spoof and poison the packets traveling on that network segment. This allows the attacker to upload exactly the services he needs to carry out the Man-in-the-Middle attack.
By running Responder on the network (as illustrated in the image below), the adversary will run servers from various services specified in the configuration file, which will listen for certain broadcast requests on the network so that it can then respond and impersonate the resource of that request in order to capture information about users. In the context of our emulation, the adversary's goal is to capture hash NTLMv2 hash of users.
As illustrated in the images above, the adversary has run Responder on his device, on which he has uploaded several servers, including an SMB Server, and Poisoners that will 'poison' the packets of the protocols indicated in the image above.
By simply executing Responder, the adversary now just needs to wait for a user to type in the wrong host/sharing name so that the user's device can send LLMNR and/or NBT-NS broadcasts in order to find that host/sharing. The adversary listening to the broadcast traffic will then capture this packet and reply to it, with the aim of impersonating the requested host/share and finally capturing the user's hash.
Another way of executing this technique would be through the development of an adversary's phishing campaign, in which it can induce the user to click on a link that can open a non-existent share on the network, or execute malicious code through a document so that the user's device sends LLMNR and NBT-NS broadcasts over the network segment.
In our scenario, the acquisition of hashes was caused by a user typo.
In the image above, we can see that there is an active share on DC01 that can be accessed via '\\DC01\Production\'.
As a result of inattention, the user, in order to access this share, typed in his Windows Explorer just '\\Production\'. This simple mistake gave the adversary his hash NTLMv2.
From this moment on, the opponent can try to crack the hash offline, or conduct procedures relating to Lateral Movement Techniques such as Pass-The-Hashwhere the adversary will try to authenticate on other devices using the captured hash.
Technique execution detection
The technique we are discussing is extremely complex to detect using Event IDs, as it is theoretically normal network behavior, with the adversary subverting the way it works in order to achieve their goals.
In this topic, we will look at detection solutions, demonstrating the importance of packet capture, and detection through proactive hunting, with the aim of finding devices that are running servers with fake services in order to capture critical user information.
NOTE: This detection and hunting exercise was also carried out in the same laboratory infrastructure as illustrated above.
Packet capture
Packet capture is important as it allows us to identify the behavior of the execution of this technique, analyzing DNS requests and, during name resolution failure, sending LLMNR broadcasts to the network segment, which consequently leads us to the adversary's response.
Below, we can see the behavior of the name resolution attempt for the host/resource\\Production\, accidentally requested by the user. As shown in the image above, we can see that the user tries to do the resolution through DNS and, as this host/resource does not exist, the device sends an LLMNR broadcast to the network segment, requesting that the host/resource respond.
This is where our adversary comes into play. When it receives the broadcast (because it's on the same network segment), we can see in the image above that it responds to the one from the user's device and, immediately after its response, the user tries to connect via port 445 (SMB).
In the image above, we see the second phase of the execution of this technique. We can see that, after the adversary responds to the broadcast, a negotiation is initiated via the SMB protocol, where the adversary informs the user's device that it will need a NTLM Challenge so that the user's device can access the requested resource. On receiving this NTLM Challengethe user sends its hash so that the destination host can validate that the user is authorized to access the requested resource.
After receiving the user's hash, the adversary informs the user that they do not have permission to access the resource, and then terminates the connection.
To the user, this seems like a minor inconvenience, but he has just given his credentials to the adversary.
Possible detection through packet capture
To create detections for this technique using packet capture, your SIEM must first be enabled to carry out this type of activity. You must also be aware of which devices you have in the infrastructure, so that you can identify when a device responds to a request for a resource that doesn't exist.
We suggest that detection should be done by analyzing the non-resolution process through DNS, followed by sending an LLMNR broadcast to the network segment and then detecting the device that responds to this broadcast.
If the DNS server has failed to resolve the name of a device that is hosting a shared resource on the network, it is because it shouldn't exist or is otherwise unresponsive. Therefore, the analysis to develop detection must focus on this aspect of the attack.
Conveigh - threat hunting tool
If you don't have the infrastructure to carry out large packet captures, or if the Hunter wants to adopt a more proactive tactic during its hypothesis validation process, the Conveigh tool is a great acquisition for detecting devices that are hosting servers with fake services on the network, with the aim of capturing hashes from as many users as possible.
Next, let's see how this tool can help us find the adversary running the Technique on your infrastructure.
The Hunter hypothesizes that an opponent may be performing the Request Poisoning and Spoofing Technique LLMNR and/or NBT-NS requests, and the analyst can use tools developed to send LLMNR and/or NBT-NS requests.
This is an example of how the Conveigh tool can be used. However, the same tool can be used in various contexts, such as during the Identification and Analysis phase of an Incident Response, or periodically running this tool on a device that is at a strategic point in the network, with its network card in promiscuous mode, either to capture packets, or to run tools such as Conveigh to send false requests to that network segment, and then record logs for future analysis or forwarding to a Log Server.
To run Conveigh, we must first follow a few procedures:
- Run Powershell as Administrator;
- Allow the execution of scripts in Powershell, using the '-ep bypass' options ;
- Import the Conveigh module into the Powershell session context;
- Run Conveigh using the 'Invoke-Conveigh' command without parameters, by default.
In the following image, we can see the execution of the procedures detailed above, and consequently the detection of our adversary identified with the IP address 10.0.0.107.
Below we can see that the adversary received and responded to fake LLMNR and NBT-NS requests sent by Conveigh, denouncing its presence on the infrastructure.
Mitigation
The mitigations for the execution of Technique T1557.001 are based on disabling features of environments Windowsand the acquisition of desktop security software that inspects attacks at packet level. Below are our suggested mitigations:
- Disabling LLMNR and NetBIOS in the local computer's security settings or by group policy if they are not needed in an environment.
- Enable SMB Signing to stop NTLMv2 relay attacks (Pass-The-Hash, SMB Relay etc).
- Acquisition and implementation of desktop security software to block traffic LLMNR/NetBIOS.
- Carrying out a network segmentation review can be useful for isolating critical infrastructure devices, and devices that do not require broad network access. This can mitigate, or at least alleviate, Man-in-the-Middle attacks.
- It is also possible for an EDR to detect the presence of known software such as Responder. It is important to create policies to block hashes from known tools.
References
- Conveigh: https://github.com/Kevin-Robertson/Conveigh
- Pyramid of Pain: http://detect-respond.blogspot.com/2013/03/the-pyramid-of-pain.html
- LLMNR/NBT-NS Poisoning and SMB Relay: https://attack.mitre.org/techniques/T1557/001/
- Responder Toolkit: https://github.com/lgandx/Responder
- Link Local Multicast Name Resolution: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-llmnrp/6806998e-034d-4c39-8398-5af8bfd52d7e
- SMB Signing: https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/overview-server-message-block-signing
- Wireshark: https://www.wireshark.org/