{"id":1245,"date":"2021-05-17T09:00:09","date_gmt":"2021-05-17T06:00:09","guid":{"rendered":"https:\/\/macrosec.tech\/?p=1245"},"modified":"2021-05-24T15:36:57","modified_gmt":"2021-05-24T12:36:57","slug":"capturing-netntlm-v2-hahes-via-outlook-signatures","status":"publish","type":"post","link":"https:\/\/macrosec.tech\/index.php\/2021\/05\/17\/capturing-netntlm-v2-hahes-via-outlook-signatures\/","title":{"rendered":"Capturing NetNTLM V2 hashes Via Outlook Signatures"},"content":{"rendered":"

CAPTURING NET-NTLM V2 HASHES VIA OUTLOOK SIGNATURES<\/span><\/strong><\/h2>\n<\/div>
\"Haystack<\/span><\/div><\/div><\/div><\/div>
<\/div><\/div><\/div><\/div><\/div>
<\/div>
<\/div>
<\/div>

This blog post was written by Dharmik Karania<\/a>.<\/p>\n<\/div>

<\/div>
<\/div><\/div>
<\/div>

Introduction<\/strong><\/h2>\n

Today, it is possible to craft a malicious email that allows an adversary to capture NetNTLMV2 hashes without requiring any form of interaction with the user. The user only has to click open the email and the hashes will be captured.<\/p>\n

What is NTLM?<\/strong><\/h3>\n

This is the way passwords are stored on modern Windows systems and can be obtained by dumping the Security Account Manager (SAM) database or using Mimikatz. They are also stored on domain controllers in the NTDS file. These are the hashes you can use to pass-the-hash.<\/p>\n

NetNTLMV2 is a protocol used as an authentication mechanism on Windows environments. This is an improved version of the (New Technology Lan Manager) NTLM Protocol and therefore it is a little harder to crack. This uses the (New Technology) NT-Hash algorithm and therefore the hashes can be brute forced to recover the password.<\/p>\n

Capturing NetNTLM hashes from network communications is nothing new. There are several ways of doing this. The most common way is via SBM. SMB is a protocol for file sharing purposes, and we can force SMB communications to an attacker using tools to capture the authentication attempt and extract the password hash.<\/p>\n

Sniffing SMB traffic requires elevated permissions that typically are not available when you first get command and control and therefore sometimes it can a little difficult to get the hash. Furthermore, it can be a noisy when we are sniffing SMB Traffic and therefore this may impact the user experience or even create suspicion to a user.<\/p>\n

In this blog, I will explain the concept of Windows \u2018Trust Zones\u2019, how email signatures are configured in Outlook and how the combination of the two can result in the capture of hashes with minimal impact to the user experience through http. I will show both the methods, the first with SMB and then with HTTP.<\/p>\n

Weaponization using SMB:<\/strong><\/h3>\n

The first step is to create a simple html file with the following lines of code. The IP address in the image source is the IP address of my Kali Linux machine. This code behaves an Outlook signature.<\/p>\n<\/div>

<\/span><\/div><\/div>

 <\/p>\n

When sending an email, this file should be attached as text so that it can act as an Outlook Signature. In order to do this, the ribbon in Outlook must be customized. Click on File, then Outlook Options and then select Customize Ribbon. From the All-Commands list select \u201cAttach File\u201d.<\/p>\n<\/div>

<\/span><\/div><\/div>

 <\/p>\n

Then click on New Email and add the \u201cAttach File\u201d to the ribbon of New Email. Click on File and then Options, the click on Customized Ribbon. Then \u201cAdd\u201d the \u201cAttach File\u201d to the New Mail menu. <\/p>\n<\/div>

<\/span><\/div><\/div>

 <\/p>\n

We then compose a new email and attach the HTML file created as text by clicking on the new \u201cAttach File\u201d component just added to the ribbon. I also write a small message \u201cThis is a test. Dharmik\u201d.<\/p>\n<\/div>

<\/span><\/div><\/div>

 <\/p>\n<\/div>

<\/span><\/div><\/div>

 <\/p>\n

Before I send the message, I start Responder on my Kali Linux terminal by typing the command: <\/p>\n

Responder -I eth0 -v<\/p>\n

-I = specifies the interface <\/p>\n

-v= specifies it to be verbose <\/p>\n<\/div>

<\/span><\/div><\/div>

\u00a0<\/p>\n

Responder runs listening for events. The email is then sent to the recipient.<\/p>\n

The tag does not point to a valid resource, accessible over SMB by the target, and therefore Outlook sends a pop-up message telling the user that it is struggling to get the resource and retrieve the data but the connection attempt is enough to capture the hash. However this is only possible if the user has administrative access on the machine. The pop-up which appears is shown below:<\/p>\n<\/div>

<\/span><\/div><\/div>

 <\/p>\n

The email is received by the recipient and upon clicking on the email by the recipient, the NTLM hash will be captured by Responder as shown below:<\/p>\n<\/div>

<\/span><\/div><\/div>

 <\/p>\n

Note the NTLMv2 Hash:<\/p>\n

The first 8 bytes of the NTLMv2 hash is the 8-byte Server Challenge. This is randomly generated. The next 8 bytes is the 8-byte Client Challenge which is also randomly generated. For this reason, the first 16-bytes of all the hashes in the image are different and the rest of the hash is the same. <\/p>\n

NTLM is a challenge-response style authentication protocol. This means that to authenticate a user, the server sends a challenge to the client. The client then sends back a response that is a function of the challenge, the user’s password, and possibly other information.<\/p>\n

The NTLMv2_CLIENT_CHALLENGE structure defines the client challenge in the AUTHENTICATE_MESSAGE. This structure is used only when NTLM v2 authentication is configured and is transported in the NTLMv2_RESPONSE. <\/p>\n

Once Responder captures the hash, we then copy the hash to a text file and crack it using Hashcat. I use a wordlist with common passwords and other passwords can be added after performing social engineering on the victim.<\/p>\n

The hash is copied on a txt file. Here \u201cresult.txt\u201d. I then use Hashcat to crack it as shown below:<\/p>\n<\/div>

<\/span><\/div><\/div>

 <\/p>\n

The command I use is: <\/p>\n

Hashcat.exe -m 5600 -a 3 result.txt password.txt<\/p>\n

-m 5600 specifies that the hash is an NTLMv2 hash<\/p>\n

-a 3 specifies the attack mode. In this case it is a brute force attack<\/p>\n

Result.txt contains the hash captured<\/p>\n

Password.txt contains the list of common passwords with which hashcat will brute force.<\/p>\n<\/div>

<\/span><\/div><\/div>

 <\/p>\n

As we can see, the password was easily cracked by hashcat. <\/p>\n<\/div>

<\/span><\/div><\/div>

 <\/p>\n

Using SMB links does not satisfy the requirements for stealth, or the ability to act without already elevated permissions. This does not mean we can\u2019t use tags to capture hashes though, it just needs to be over HTTP. <\/p>\n

NetNTLM authentication via HTML can be requested by the server, and the web browser will engage in a challenge\/response communication and this enables the hash to be captured. The hash can then be cracked offline in order to obtain the user\u2019s password. The image below demonstrates this:<\/p>\n<\/div>

<\/span><\/div><\/div>

 <\/p>\n

This type of authentication is sufficient to retrieve the hash and therefore to prevent nefarious servers on the internet, Windows established the concept of Trust Zones.<\/p>\n

The trust zones include:<\/p>\n<\/div>

<\/span><\/div><\/div>

 <\/p>\n

If you try to authenticate via the local intranet zone, then you will receive the hash allowing single sign on, but if for example stealth.com requests for the hash, it will not receive the hash because it is classified under Internet Zone which is the second most restrictive zone.<\/p>\n

So how does Windows know whether the server which is requesting the hash is within the intranet zone? The Internet Options have default options set that enables the resource to be classified as the intranet zone. The image below shows the default settings of the Intranet zone that is accessed from Internet Options. <\/p>\n<\/div>

<\/span><\/div><\/div>

 <\/p>\n

When a HTTP resource is requested, the resulting outcomes are displayed below:<\/p>\n<\/div>\n

\n\n\n\n\n\n\n\n
Type<\/th>\nURL<\/th>\nZone Classification<\/th>\nOutcome<\/th>\n<\/tr>\n<\/thead>\n
IP Address<\/td>\nhttp:\/\/192.168.10.10\/index.html<\/td>\nInternet<\/td>\nThe user is required to enter in a username and a password.<\/td>\n<\/tr>\n
Fully Qualified Domain Name (FQDN)<\/td>\nhttp:\/\/webserver.targetorg.local\/index.html<\/td>\nInternet<\/td>\nThe user is required to enter in a username and a password.<\/td>\n<\/tr>\n
NetBIOS Name<\/td>\nhttp:\/\/marvel.local<\/td>\nIntranet<\/td>\nA NTLM authentication is attempted with the currently authenticated user\u2019s credentials.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

 <\/p>\n

We want to force a HTTP request using a NetBIOS name from a domain joined machine to a web server that captures authentication attempts, then we end up with a password hash to crack.<\/p>\n

We will use the local intranet zone to capture the hash because it is the second least restrictive and also in organizations, computers are in a domain or within a local intranet and therefore I decided to set up a local intranet zone to make it more realistic.<\/p>\n

Weaponization using HTTP:<\/strong><\/h2>\n

Lab requirements<\/h3>\n