The Danger of Invisible Adversaries. Understand how they operate in the Windows system

The Danger of 'Invisible' Adversaries: Understand how they operate in the Windows system and learn how to identify them

By Ícaro César: In this report you will follow a Security Research - Emulation and Detection, with the 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, we need to understand: what is LLMNR and NBT-NS Spoofing/Poisoning? LLMNR is the successor to NBT-NS and was introduced to the Windows ecosystem starting 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 hostname resolution on a network when DNS-based hostname resolution fails.

This process of hosts reverting to LLMNR or NBT-NS transmissions to find particular 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 like Pass-The-Hash on other devices, or, crack the intercepted hashes offline.

A typical scenario for attacking LLMNR or NBT-NS transmissions, these work 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. As "intrnet" cannot be resolved by DNS, since it is a host and share that does not exist, Host A again sends an LLMNR or NBT-NS broadcast message, asking the entire network segment for the IP address of the previously erroneously requested host/share"intrnet".

3. The Adversary(Host B) responds to this broadcast message by claiming to be the system that contains the "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 for Host B to perform the validation process of authorizing access to the "requested resource".

Technique Emulation - T1557.001

To be able to perform the Procedures of this Technique, we can use the tools Answertool, developed in Pythonor the Inveightool, developed in Powershell. In this emulation, we use the Responder tool to execute this procedure, but regardless of the tool used to execute the procedures, the LLMNR and NBT-NS Poisoning/Spoofing attack still has the same result.

The lab in which we will perform the emulation of this technique contains the following topology:

Responder contains a configuration file that allows us to configure which services will run to perform Capture, Spoofing and Poisoning of the packets trafficked on that network segment. This allows the attacker to upload exactly the services he needs to execute the Man-in-the-Middle attack.

When running Reply on the network (as illustrated in the image below), the adversary will run servers of various services specified in the configuration file, which will listen for certain broadcast requests on the network so that it can then reply and impersonate the resource of that request in order to capture information regarding users. In the context of our emulation, the adversary's goal is to capture hash NTLMv2 hash from users.

As illustrated in the images above, the adversary has run Responder on his device, on which he has upended several servers, including an SMB Server, and Poisoners that will 'poison' the packets of the protocols indicated in the image above.

By simply running Reply, the adversary now only needs to wait for some user to type the wrong host/sharing name so that the user's device sends LLMNR and/or NBT-NS broadcasts in order to find that host/sharing. Then the adversary listening to the broadcast traffic will capture this packet and reply to it, in order to impersonate the requested host/sharing, and ultimately capture the user's hash.

Another way to execute 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 network share, or execute malicious code via a document so that the user's device sends LLMNR and NBT-NS broadcasts over the network segment.

In our scenario, the hash acquisition was caused by a typo by the user.

In the screenshot above we can see that there is an active share on DC01 that can be accessed via 's\DC01\Production\'.

By lack of attention, the user in order to access this share typed in his Windows Explorer just 'spoonProduction'. This simple mistake gave the adversary his hash NTLMv2 hash.

From this point on, the opponent can try to perform hash cracking offline, or conduct procedures referring to Lateral Movement Techniques such as Pass-The-Hashwhere the adversary will try to perform authentications on other devices, using the captured hash.

Technique execution detection

The technique we are addressing is extremely complex to detect through Event IDs, because theoretically it is normal network behavior, with the adversary subverting its operation to achieve its goals.

In this topic we will cover detection solutions, demonstrating the importance of packet capture, and detection through proactive Hunting, in order to find devices that are running Fake Servers in order to capture critical user information.

NOTE: This Detection and Hunting exercise was also performed in the same laboratory infrastructure illustrated above.

Package Capture

Packet capture is important since it allows us to identify the behavior of the execution of this Technique, analyzing requests to DNS and, during the name resolution failure, the sending of LLMNR broadcast to the network segment, which consequently leads us to the adversary's response.

Below we can observe the behavior of the name resolution attempt for the host/resource###### accidentally requested by the user. As in the image above, we can identify that he tries to do the resolution through DNS and, since 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. Upon receiving the broadcast (because it is on the same network segment), we can see in the image above that it replies to the one from the user's device, and soon after its reply, the user tries a connection through port 445 (SMB).

In the image above, we see the second phase of the execution of this technique. We can observe that, after the adversary responds to the broadcast, a negotiation is started through 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 have access to the requested resource. Upon receiving this NTLM Challengethe user sends its hash to the destination host to validate that the user is authorized to access the requested resource.

After receiving the user's hash, the adversary reports that the user is not allowed 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 his opponent.

Possible detection through packet capture

To create detections for this technique using packet capture, your SIEM must first be enabled to perform this type of activity. You must also be aware of what devices you have in the infrastructure, so that you can identify when a device answers a request for a resource that does not exist.

We suggest that detection should be done by analyzing the unresolved process through DNS, being followed by sending an LLMNR broadcast to the network segment and then detecting the device that responds to this broadcast.

If the DNS server did not perform name resolution for a device that is hosting a shared resource on the network, it is because it should not exist or otherwise respond. Therefore, the analysis to develop detection should be focused on this aspect of the attack.

Conveigh - threat hunting tool

If you don't have the infrastructure to perform large package captures, or if Hunter wants to adopt a more proactive approach during your hypothesis validation process, the Conveigh is a great buy for detecting devices that are hosting Servers with fake services on the network, with the goal of capturing hashes of as many users as possible.

Next, let's look at how this tool can help us find the adversary performing the Technique on your infrastructure.

Hunter creates the hypothesis that an adversary may be performing the Request Poisoning and Spoofing Technique LLMNR and/or NBT-NS requests, and the analyst can use tools designed to send LLMNR REQUESTS and/or NBT-NS REQUESTS requests.

This is an example of use for the Conveigh tool. However, the same tool can be used in several contexts such as during the Identification and Analysis phase in an Incident Response, or the periodic execution of this tool on a device that is in a strategic point of the network, with its network card in promiscuous mode, either to perform packet capture, 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:

  1. Run Powershell as Administrator;
  2. Enable the execution of scripts in Powershell, using the '-ep bypass' options ;
  3. Import the Conveigh module, into the Powershell session context;
  4. Run Conveigh via the 'Invoke-Conveigh' command without parameters, by default.

In the following image, we can observe 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 the fake LLMNR and NBT-NS requests sent by Conveigh, denouncing its presence in the infrastructure.

Mitigation

The mitigations for performing Technique T1557.001 are based on disabling features of Windows environmentsenvironments, and the acquisition of security software for Desktops that perform packet-level attack inspection. Below are our suggestions for mitigations:

- Disabling LLMNR and NetBIOS in the local computer security settings or by group policy if they are not needed in an environment.

- Enable SMB Signing to stop NTLMv2 retransmission attacks (Pass-The-Hash, SMB Relay etc).

- Acquisition and implementation of desktop security software to block traffic LLMNR/NetBIOS traffic.

- Performing a review regarding network segmentation can be useful in isolating critical infrastructure devices, and devices that do not require extensive 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 for blocking known tool hashes.

References

  1. Conveigh: https://github.com/Kevin-Robertson/Conveigh
  2. Pyramid of Pain: http://detect-respond.blogspot.com/2013/03/the-pyramid-of-pain.html
  3. LLMNR/NBT-NS Poisoning and SMB Relay: https://attack.mitre.org/techniques/T1557/001/
  4. Responder Toolkit: https://github.com/lgandx/Responder
  5. Link Local Multicast Name Resolution: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-llmnrp/6806998e-034d-4c39-8398-5af8bfd52d7e
  6. SMB Signing: https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/overview-server-message-block-signing
  7. Wireshark: https://www.wireshark.org/

Leave a Comment

Your e-mail address will not be published. Required fields are marked with *