Capturing NetNTLM V2 hashes Via Outlook Signatures

This blog post was written by Dharmik Karania.

Introduction

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.

What is NTLM?

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.

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.

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.

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.

In this blog, I will explain the concept of Windows ‘Trust Zones’, 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.

Weaponization using SMB:

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.

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 “Attach File”.

Then click on New Email and add the “Attach File” to the ribbon of New Email. Click on File and then Options, the click on Customized Ribbon. Then “Add” the “Attach File” to the New Mail menu.

We then compose a new email and attach the HTML file created as text by clicking on the new “Attach File” component just added to the ribbon. I also write a small message “This is a test. Dharmik”.

Before I send the message, I start Responder on my Kali Linux terminal by typing the command:

Responder -I eth0 -v

-I = specifies the interface

-v= specifies it to be verbose

Responder runs listening for events. The email is then sent to the recipient.

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:

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:

Note the NTLMv2 Hash:

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.

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.

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.

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.

The hash is copied on a txt file. Here “result.txt”. I then use Hashcat to crack it as shown below:

The command I use is:

Hashcat.exe -m 5600 -a 3 result.txt password.txt

-m 5600 specifies that the hash is an NTLMv2 hash

-a 3 specifies the attack mode. In this case it is a brute force attack

Result.txt contains the hash captured

Password.txt contains the list of common passwords with which hashcat will brute force.

As we can see, the password was easily cracked by hashcat.

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’t use tags to capture hashes though, it just needs to be over HTTP.

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’s password. The image below demonstrates this:

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.

The trust zones include:

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.

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.

When a HTTP resource is requested, the resulting outcomes are displayed below:

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.

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.

Weaponization using HTTP:

Lab requirements

• Windows Server 2016 completely set up.
• Windows 10 machine

In this report, I will not cover on how to set up the Domain Controller and how to join the User’s machine (Windows 10) machine to the Domain.

I took a more practical and realistic approach when setting up this lab and carrying out the attack. What If we do not have GUI access and the user’s settings have prevented any form of code from interacting with Outlook, then how would we be able to attach the HTML file as text and get the hash? Furthermore we also want to make it stealthier and ensure there is no room for suspicion with HTTP because with SMB as we saw earlier, generates messages telling the user that the resource is not available. So how would we do it?

We first set up the Outlook signature by clicking on Options, followed by Mail, and then clicking on the Signatures Menu and then setting up the signature.

Click on new and add the signature and then click on save, followed by ok.

This is shown below:

When an Outlook Signature is created, three files are created. These files are stored in the AppData folder as shown below:

These files are then transferred in the registry and depending on the whether the signature has been created by a policy or the end-user, the files are referenced in different places as shown below:

In this way, we can know whether a user has set their signatures or not. If it is not set, then a signature can easily be set by creating the relevant files in the signatures folder (C:\Users\User\AppData\Roaming\Microsoft\Signature\MySignature.htm) or modify an existing signature if one is already set.

In order for a hash to be captured, an image needs to be uploaded along with the signature. We saw that with SMB we manually tried to do that using the HTML code. When we do it manually, an error message is displayed, and this creates suspicion for the user and therefore does not meet the requirements of stealth.

To automate the process of modifying the signature, uploading the image, and starting the corresponding listener, I use a tool called Sigwhatever.

The Sigwhatever tool is written in C# and it borrows code heavily from Seatbelt and Inveigh projects. Seatbelt is a C# project that performs a number of security-oriented “safety checks” relevant from both offensive and defensive security perspectives. It is an enumeration tool for Windows. Inveigh is a PowerShell ADIDNS/LLMNR/NBNS/mDNS/DNS spoofer and man-in-the-middle tool designed to assist penetration testers/red teamers that find themselves limited to a Windows system.

The Sigwhatever tool automates and performs the following process:

• Queries the firewall for suitable ports to listen on (Uses some seatbelt code)
• Cross references HttpQueryServiceConfiguration for any usable URL ACLs
• Starts TCP/HTTP server for hash capture (Uses Inveigh code)
• Signature Detection (to modify the appropriate registry settings and signatures)
• Modification of Signature
• Option to send mail to a specific AD group (e.g. domain admins)
• Option to create encrypted logs on disk.
• Cleanup (Reverts changes in signature settings and existing signature)

The tool ensures that the user experience is not impacted in any way. The tool cleans up and reverts the changes back to the original and that is why when the email is sent, the uploaded image is not seen by the recipient. This makes the process smooth and stealthy.

To run Sigwhatever, use the following command:

The AUTO switch means that it will perform all the above steps. I then run this command:

Once it runs, it will set up the listener and wait for an email to be sent and opened by the recipient.

We then send an email and Sigwhatever performs the above steps and we get the hash as shown below: Notice no pop-up appears and the email looks from a legitimate sender.

The email received is shown below: Notice the image icon upload is not displayed and there is no room for suspicion as no pop-up appears but a hash has been captured as shown below:

As soon as the message is sent, a hash is received. We then crack the hash using Hashcat as shown below:

The command I use is

Hashcat.exe -m 5600 -a 3 result.txt password.txt

-m 5600 specifies that the hash is an NTLMv2 hash

-a 3 specifies the attack mode. In this case it is a brute force attack.

Result.txt contains the hash captured.

Password.txt contains the list of common passwords with which hashcat will brute force.

There are some limitations of using the Sigwhatever tool:

• External recipients would also receive the tracking image in the signature, revealing an internal hostname. If the email is sent outside the local intranet zone, then the recipient receives the tracking image as shown below:

The email is received in spam and the tracking image is also displayed. Therefore, this attack is best done within an internal network/ organizational network (Intranet).

• If targeted users access the emails at a later date – this will still trigger a request to be sent, so this could be picked up by another attacker at a later date (in the highly unlikely event that the same host is compromised, and an attacker decides to attempt hash capture on the same port).
• It may be suspicious to speed up the attack by sending unsolicited emails with the modified signatures may be suspicious.

The benefits of HTTP over SMB to carry out this attack include that with HTTP, elevated permissions are not required, and therefore a HTTP server can listen on any port. HTTP is a running service, and it does not capture communications to an existing service as Inveigh does with SMB.

These attacks are usually successful because:

• We can perform this attack when we get initial foothold on a machine or when we get access to a low privileged end user device.
• Most organizations have a flat network. A flat network is a one where all users can communicate with each other even over a Virtual Private Network (VPN).
• Host based firewalls are often configured permissively or are turned off and therefore these attacks are not detected. A host-based firewall is a piece of firewall software that runs on an individual computer or device connected to a network. These types of firewalls are a granular way to protect the individual hosts from viruses and malware, and to control the spread of these harmful infections throughout the network.

Preventive Measures

There are a number of preventive measures that would prevent this attack from happening. This includes:

1. Host based firewalls- they should be turned ON, and they should be configured in a way to prevent additional services from listening.
2. Network segregation- internal network segregation can help to reduce the effectiveness of this kind of technique. Allowing only essential communication between end user devices would make the service listening for hashes inaccessible. Another term to use is hardening which means to remove unnecessary services which the user does not need to conduct their daily business.
3. Turn off auto-download of images, or default to plain text email (this is default for emails from outside the organization, but HTML is displayed for email sent within the same organization). This can be done by clicking on File -> Options -> Trust Center -> Trust Center Settings -> Click on the checkbox “Don’t download pictures automatically in standard HTML email messages or RSS items.”
4. Plain text email- ensuring that the email is displayed in plain text for both the composition of emails and received communications. This will prevent Outlook from rendering the HTML in the signature. This can be achieved through:
   • Composition of emails- click on New Email -> File -> Options -> Mail -> from the drop down of “Compose message in this format” select “Plain Text.”
   • Received email- Click on File -> options -> trust center -> Trust center Settings -> Email security -> click on the checkbox which states “Read all standard mail in plain text.”

Detection Mechanism

Monitor for changes to the relevant registry keys from processes other than Outlook.exe

References

https://www.ired.team/offensive-security/initial-access/netntlmv2-hash-stealing-using-outlook

https://research.nccgroup.com/2021/01/15/sign-over-your-hashes-stealing-netntlm-hashes-via-outlook-signatures/

https://github.com/Kevin-Robertson/Inveigh&lt

https://github.com/GhostPack/Seatbelt

https://medium.com/@petergombos/lm-ntlm-net-ntlmv2-oh-my-a9b235c58ed4

Disclaimer

The MacroSec blogs are solely for informational and educational purposes. Any actions and or activities related to the material contained within this website are solely your responsibility. The misuse of the information on this website can result in criminal charges brought against the persons in question. The authors and MacroSec will not be held responsible in the event any criminal charges be brought against any individuals misusing the information in this website to break the law.