Attacking Active Directory by LLMNR/NBSN

NOTE: It is recommended that you read our previous article first: "DNS: The blind spot in the PCI DSS compliance strategy."

What is it and what functions does Active Directory provide?

The almost omnipresent Active Directory is by far the most widely used identity management service in the world: over 95% of major companies use it on their networks, and despite or perhaps because of its great success, it continues to be a major focus of attacks today, and often due more to configuration deficiencies than unpatched vulnerabilities.

To summarize, the Active Directory service consists of a server with the role of "Domain Controller" whose main functions are:

• Centralized data repository:
  Active Directory stores user, application, and resource identity information in a multi-master database based on the Joint Engine Technology (JET) database engine, which is nothing more than a file called ntds.dit.
• Data replication and high availability:
  In complex organizations, usually with several locations, some redundancy is required, which is achieved through multiple domain controllers. Replication connections (from and to whom) and the replication schedule can be modified based on business requirements.
• Security:
  Active Directory allows the use of different types of authentication, group policies, and workflows to protect the company's network resources, helping administrators to build different rules based on organizational structure, groups, and roles while forcing users to follow established security rules.
• Audit capability:
  Active Directory allows auditing of events occurring in the identity management infrastructure related to user authentication, directory service modifications, or access violations
• Single sign-on:
  In an organization, there are different applications in use, and each may have a different authentication mechanism, making it more difficult to maintain different user credentials to authenticate in each of the applications. Most application providers today support integration with Active Directory for authentication, which means that they can delegate this process to Active Directory, using the session already initiated by the user with the credentials managed by Active Directory, without requiring the user to re-enter a username and password to gain access.

As you can see, these features are critical, so if they were to be violated, many organizations would grant access to their main applications and databases to someone unauthorized.

The following is one of the main attacks from which we must protect ourselves, and which is usually the first step for more complex and critical attacks (SMB Relay, Pass the Hash, etc.).

What is LLMNR/NBNS and how does it work?

By default, Windows systems use the following prioritized list of services to attempt to resolve name resolution request:

1. Local host file
2. Domain Name Service (DNS)
3. Link-Local Multicast Name Resolution (LLMNR)
4. NetBIOS Name Service (NBNS/WINS)

LLMNR (Link-Local Multicast Name Resolution), is a name resolution protocol over IPv4 and IPv6 that is enabled by default on Windows systems and uses the following connections:

• Destination IP address (multicast): 
  • IPv4: 224.0.0.252
  • IPv6: ff02::1:3
• Port: UDP 5355

On the other hand, NBNS/WINS (NetBIOS Name Service or also known as Windows Internet Name Service), is also an old name resolution protocol, in this case only over IPv4 and which uses the following connections:

• Destination IP address: IPv4 broadcast address of the network.
• Port: UDP 137

LLMNR on comes in first and NBNS second, will come into play when for any circumstance DNS resolution fails for a request from a network resource that requires authentication, or directly when there is no DNS service for that network; when that happens, the flow is as follows:

1. Using these protocols, the requesting client sends a multicast or broadcast message (under LLMNR or NBNS respectively) to its entire network asking for the address of the resource it needs. The protocol assumes that any host on the internal network is reliable and therefore the requester will accept a response from whomever it comes.
2. A second host (which could be an attacker) responds by claiming to know it and providing a destination IP address to the requester.

Exploiting LLMNR/NBNS

Server Message Block (SMB)

A particular, well-known case of exploitation typically occurs when the victim requests a shared network resource via Server Message Block (SMB), which is non-existent or the IP of which is unknown, and where access authentication is performed using the challenge/response protocol NTLM (NT LAN Manager); although Kerberos authentication has been around for many years and the default protocol in the latest Windows distributions, the use of NTLMv2 is still widely used in corporate enterprise systems today because it must be used for authentication on systems configured as members of a workgroup, for local login authentication on non-domain drivers, or non-Microsoft applications.

In this case, the attacker will have responded to the name resolution query initiated by the victim via LLMNR, naming himself as the recipient, and receiving the victim's credentials: username and password hash. This password hash corresponds to the hash of the credentials in clear using an MD4 hash algorithm without a jump and is therefore considered cryptographically insecure.

Web Proxy Autodiscovery Protocol

Another particular case occurs when a client on the local network enters an unknown URL address in its browser, and the browser is configured with the network option "Automatic configuration detection" (or similar depending on the browser); in this case, the browser will try through LLMNR to find a host called WPAD (Web Proxy Autodiscovery Protocol) from which to request a file named wpad.dat containing the proxy's automatic configuration data. In this case, the requesting client is tricked by the attacker who shows him a false authentication window to obtain the requested file, thus providing his credentials in clear. Likewise, the attacker could impersonate the network proxy and thus have access to the entire data flow of the victim's network traffic.

Conclusion

Thus, as we have seen very briefly in the cases mentioned, from the moment the attacker (the host we have called ATTACKER in the image above) has supplanted the legitimate recipient via LLMNR/NBNS, he will already know the username and at least the hash of the victim's password.

As we have seen, this type of attack requires having previously gained access to the internal network. Once the attacker is on the internal network, he will use and leave acting for hours or even days some tool such as Responder or Inveigh, which will capture all possible network traffic, responding fraudulently to LLMNR/NBNS requests, and simulating services that require credentials, such as SMB, DNS, LDAP, IMAP, FTP, SQL, HTTP, HTTPS, etc., in an attempt to capture that traffic and respond by its known ports.

As a result of the execution of these tools, the attacker will obtain the user and usually the password hash. With this, the only thing left to do is to recover the password with a specific tool, usually HashCat.

Once a network user's full credentials have been obtained (username + password), a potential attacker will resort to exploiting other types of attacks that require prior authentication, to gain access to the rest of the network's credentials and the resources they protect.

How to protect yourself?

To avoid this series of vulnerabilities due to poor configurations and their consequences, we should establish the following secure configuration whenever possible:

1. Whenever possible migrate all services and resources to be able to disable as authentication protocols of our Active Directory any other than the default Kerberos v5 (i.e. disable LAN Manager and NTLM).
2. Disable LLMNR as name resolution protocol:
   1. Open Group Policy Editor.
   2. Go to Local Computer Policy > Computer Configuration > Administrative Templates > Network > DNS Client 
   3. In DNS Client, check the "Turn OFF Multicast Name Resolution" option as Enabled.
3. Disable NBNS as name resolution protocol:
   1. Open the Network Connections Panel and go to the adapter properties.
   2. Select “Internet Protocol Version 4 (TCP/IPv4)” and go to Propierties. 
   3. In the General tab go to Advanced, open the WINS tab.
   4. In NetBIOS setting, select “Disable NetBIOS over TCP/IP.

If technical requirements make it essential to keep these two services active (e.g. when we don't have a DNS service deployed), we should at least reduce the impact of this vulnerability by applying controls such as the following:

• Restrict the admission to the network by any device through the use of some Network Access Control (NAC) functionality, which allows at least to identify and authorize if applicable the device by its MAC.
• Strengthen the password policy (length and complexity) of users in order to make it as difficult as possible to recover the password from its hash.

1. Enable the network resource sharing service packages signature, Server Message Block (SMB) in all cases and for all computers in our network:
   1. Open Group Policy Editor. 
   2. Go to Local Computer Policy > Computer Configuration > Windows Settings > Security Settings > Local Policies 
   3. In Security Options, check the following options as Enabled:
      1. Microsoft network client: Digitally sign communications (always) 
      2. Microsoft network server: Digitally sign communications (always)
   
   5. Set a static proxy configuration for the browsers used in all clients on the network. In the case of Internet Explorer set the following options:
   a. Open Group Policy Editor.
   b. Go to Local Computer Policy > Computer Configuration > Administrative Templates > Windows Components > Internet Explorer
   c. Check the following options as Enabled:
   i. Disable caching of Auto-Proxy scripts
   ii. Disable changing Automatic Configuration settings
   iii. Prevent changing proxy settings
   

6. Create your own DNS entry for the WPAD host, even if you do not deploy a proxy server in your network.

a. In Domain Controller go to DNS.

b. In the existant domain: add New Zone, Primary Zone:

i. Zone name: wpad.

c. In the new zone, right click it and select New Host:

ii. Name: wpad

iii. IP address: IP of our server hosting the file wpad.dat

Advantio has the necessary expertise to help you with all things security! Focus on your core business, and let us be your security partner.

References:

[1] Dishan Francis (2017). Mastering Active Directory. Packt Publishing Ltd.

[2] https://tools.ietf.org/html/rfc4795 [2] https://docs.microsoft.com/en-us/previous-versions//bb878128(v=technet.10)

[3] https://cccsecuritycenter.org/remediation/llmnr-nbt-ns

[4] https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/b38c36ed-2804-4868-a9ff-8dd3182128e4

[5] https://docs.microsoft.com/en-us/archive/blogs/josebda/the-basics-of-smb-signing-covering-both-smb1-and-smb2