Multi-factor authentication does not protect most Windows logons — and attackers know it.
When a user signs into a domain-joined workstation or server, authentication runs through Active Directory via Kerberos or NTLM, not through a cloud identity provider. That means Microsoft Entra ID, Okta, or Google Workspace MFA policies — however well configured — never enter the picture. An attacker with a stolen password or NTLM hash can authenticate as a valid user without triggering a single MFA prompt, according to the report.
The gap is structural, not accidental.
Where the Coverage Ends
Hybrid environments are particularly exposed. Even when Entra ID enforces MFA for cloud apps, traditional Windows logons to on-premises domain-joined systems are validated by local domain controllers. Unless Windows Hello for Business, smart cards, or another integrated mechanism is deployed, no additional factor exists in that authentication flow.
Remote Desktop Protocol compounds the problem. RDP sessions to internal servers do not automatically pass through cloud-based MFA controls, leaving logons dependent entirely on the underlying AD credential. Attackers frequently reach internal RDP endpoints through lateral movement after an initial foothold — exposure to the internet is not a prerequisite.
NTLM, though deprecated in favor of Kerberos, persists across Windows environments for compatibility reasons. It enables pass-the-hash attacks, where the attacker authenticates using a captured credential hash rather than the plaintext password. MFA offers no defense at that layer because the system accepts the hash as proof of identity. Internal NTLM traffic often goes unmonitored until an incident or audit surfaces it.
More Read
Kerberos introduces its own attack surface. Threat actors steal tickets from memory or forge them after compromising privileged accounts — techniques that enable persistent lateral movement and reduce repeated logon activity, which lowers detection probability. These attacks can survive password resets if the underlying compromise is not fully remediated.
Local Accounts, Service Accounts, SMB
Local administrator accounts present a separate problem. They authenticate directly to endpoints, bypassing MFA controls entirely — Entra ID conditional access policies do not apply. Where local admin passwords are reused across endpoints, a single compromised machine can quickly become many.
Service accounts extend the risk further. They typically carry broad permissions, stable credentials, and long lifetimes. Password expiration is rarely enforced, and monitoring is minimal in many organizations. The combination makes them high-value targets that MFA was never designed to cover in traditional configurations.
Server Message Block protocol rounds out the lateral movement toolkit. Attackers with valid credentials use SMB to reach administrative shares and interact with systems remotely. Because SMB traffic is treated as internal, MFA enforcement at that layer is uncommon.
Tools such as Specops Secure Access address part of this by enforcing MFA specifically for Windows logon, RDP, and VPN connections, extending coverage to offline logins through one-time passcode authentication. The broader point, though, is architectural: MFA deployed only at the identity provider layer leaves the majority of Windows authentication paths unguarded, and attackers have long oriented their techniques around exactly that gap.
Photo by Markus Spiske on Pexels
This article is a curated summary based on third-party sources. Source: Read the original article
