, , , , , , , , , , ,

An SMB Relay Race – How To Exploit LLMNR and SMB Message Signing for Fun and Profit

Jordan Drysdale//

This is basically a slight update and rip off of Marcello’s work out here: https://byt3bl33d3r.github.io/practical-guide-to-ntlm-relaying-in-2017-aka-getting-a-foothold-in-under-5-minutes.html

/tl;dr – Zero to DA on an environment through an exposed Outlook Web App (OWA) and a single factor VPN. An overview of the techniques is chopped from further down, and the attack summary, exists twice in this document:

  1. Identify network systems that do not require SMB message validation
  2. Configure Impacket’s NTLMrelayx to target those systems
  3. Disable SMB and HTTP request/response poisoning in Responder and launch
  4. Wait for creds

We are approaching the topic of NTLM relay via “SMB authentication poisoned reflection” with something more in mind. We are going to execute this whole thing from zero with nothing but an OWA portal, a list of users, and a smile.

LLMNR, NBNS, NBT-NS – what is what and how do we differentiate from the attacker’s perspective and the defender’s? NBT-NS and NBNS are the same thing and operate on UDP/137 and are also known as NetBIOS and WINS. These services are flawed by design and allow an easy attack path via response races; thus an SMB relay race.

NBNS/NBT-NS (heretofore referred to as NBNS) is a fallback mechanism for name resolution. When a system is unable to identify a destination host IP via standard DNS resolutions, the system will broadcast at layer 2 in the OSI (MAC destination all F’s – FF:FF:FF:FF:FF:FF), a request for someone to aid in the IP to hostname mapping process. This broadcast packet is contained by the subnet and VLAN boundary. This is the moment when an attacker can respond and gain access to credential material. If the fallback request was intended to resolve a file server, the attacker system can present a response and an authentication challenge in subsequent packets, thus gaining access to a victim’s hashed or cleartext password in certain situations.

LLMNR is short for link-layer multicast name resolution and operates almost exactly as described in the long version. This name resolution technique is also a fallback mechanism for systems unable to resolve hostname via standard DNS. The link layer reference in the name keeps the packet on subnet, except in exceptional circumstances, including broadcast forwarding and IGMP PIM configurations, which are way more common when deploying solutions like remote system imaging or tele-casting. The destination MAC address for this request is defined as 01:00:5E:00:00:FC on TCP/5355. The reference to multicast in the protocol defines the destination IP of the resolution request’s packet in the multicast reserved space at 224.0.0.252. Similar to NBNS, LLMNR requests can be compromised by responding to these requests faster than anyone else. Thus, the following screenshot from @krelkci’s blog about turning this off on your network.

SMB message signing is the process of validating the source of requests against a system’s SMB services. When SMB message checks are enforced, the relay attack is rendered ineffective. Via group policy modifications, we can effectively eliminate this risk by enabling the “Digitally sign communications (always)” setting. There have been discussions that this setting can cause an impact to network performance. While we have not tested this under controlled circumstances, if you are considering whether or not this is a risk worth eliminating, you should consider a penetration test from Black Hills Information Security. Our consulting team can build a package just right for your needs; they stand ready to discuss our service options at [email protected].

Now, armed with some background knowledge about the protocols, let’s attack our contrived environment first via OWA, in through the VPN, on to a Linux box, and over to the DCs.

Attacks start with reconnaissance. We are skipping over this today. Have fun though, and maybe try these against your own organization. You will likely be terrified by what you find if you invest some effort.

  • Recon-ng
  • theHarvester / InSpy
  • Burp and LinkedIn
  • DNSDumpster / DNS UltraTools
  • MXToolbox
  • Metadata Tools
  • Credential Harvesting
  • Pastebin
  • Shodan
  • Data brokerage firm reports (Acxiom, BeenVerified, Epsilon)

Anyway, you want something like the following when you are done running recon.

For us, we will download MailSniper from here, import it and execute! We used the next command to recover a valid domain account. As usual, if the population is sufficiently large (a few hundred users), and the password policy is weak (8-10 character minimum), recovering credentials is just a matter of time. 

Invoke-PasswordSprayOWA -ExchHostname mail.domain.com -UserList C:\users.txt -Password Spring2019! -OutFile .\creds.txt

We also went ahead and downloaded the global address list with the following command.

Get-GlobalAddressList -ExchHostname mail.domain.com -UserName wlabv2\maxine.james -Password Spring2019! -OutFile .\GAL.txt.

Next, using some interesting hosts we found during DNS recon, we were able to access and download a configuration file for our recovered user account.

And we could authenticate!

Note: the OpenVPN client will display networks to which a profile has access. Those networks should be scanned for interesting things.

Now, we run Nmap to find things and score a direct hit. 

nmap -p22 --script=ssh-brute.nse --script-args userdb=users.lst,passdb=pass.lst 10.55.100.0/24

The results demonstrate victory and we have recovered the first flag in this environment and landed a host from which we can stage further attacks against the network.

Let’s discuss SMB relay in the context of LLMNR and why this is such an important vulnerability to not overlook in your scan results. First, the vulnerability is known as “SMB Message Signing Disabled” to Nessus. Because the lab is ours to do with what we will, we scanned it. There were 36 systems discovered with SMB message integrity validation checks disabled.

As mentioned in Tenable’s vulnerability write-up, this vulnerability allows attackers to conduct MiTM attacks against an identified SMB server. More specifically, this vuln allows an attacker with an inside position to reflect poisoned LLMNR and NBNS request/response pairs toward this list of systems. When the reflected NetNTLMv2 hashes land on systems where the poisoned “requester” has sufficient permissions, the SAM is dumped and new credentials are unlocked.

The attack, in summary:

  1. Identify network systems that do not require SMB message validation
  2. Configure Impacket’s NTLMrelayx to target those systems
  3. Disable SMB and HTTP response poisoning in Responder and launch
  4. Wait for creds

The following screenshot is the result of two commands, all that’s required for this attack. In one window: 

ntlmrelayx.py -t 10.55.100.190

And, in the Responder pane, remember to set SMB and HTTP to ‘Off’ in the Responder.conf file:

./Responder.py -I eth0 -rdw

In a matter of minutes, we have the contents of SAM from our targeted system.

When these vulnerabilities are combined, which is more often than not in the wild, the results can be devastating. In our environment, we now steal resting NTLM hashes and begin the crackmapexec-based pillaging. 

crackmapexec smb 10.55.100.0/24 -u winlab -H 
5120d0cb0df939e3044c5843e37b2c5f --local --lsa

Because why wouldn’t we run through an entire subnet and dump LSA? As seen below, we capture a couple more users, one of which turned out to be a DA.

Well then.

What can you do to reduce these risks?

  1. Enforce SMB Message Integrity checks on all systems (this is only part of solving this problem) via group policy – “Digitally Sign Communications – Always”
  2. Review network systems and DNS configuration specifically
    1. Because LLMNR and NBNS are fallback mechanisms, a well-configured DNS infrastructure can reduce the need for name lookups over these weak protocols
    2. Update your gold system images to include NBNS set to “Disabled”
  3. Configure group policy preferences that disable NBNS / NetBIOS / WINS on network adapters
  4. Configure a group policy that disables LLMNR
  5. Limit user privileges on your network as this attack also relies on the reflected NetNTLMv2 “authenticator” to have sufficient privileges for SMB login

Want to learn more mad skills from the person who wrote this blog?

Check out this class from Kent and Jordan:

Defending the Enterprise

Available live/virtual and on-demand!