Where does MFA stop and credential abuse begin?

Organizations typically implement multi-factor authentication (MFA) and assume that stolen passwords are no longer enough to access systems. In Windows environments, this assumption is often incorrect. Attackers still breach networks every day using valid credentials. The problem is not MFA itself, but the cover-up.

See also: Fake Google Security site steals MFA codes

Enforced through an identity provider (IdP) such as Microsoft Entra ID, Okta, or Google Workspace, MFA works well for cloud applications and federated logins. However, many Windows logins rely solely on Active Directory (AD) authentication paths that never trigger MFA prompts. To mitigate credential-based compromise, security teams need to understand where Windows authentication occurs outside of their identity stack.

Seven Windows authentication paths used by attackers

1. Interactive Windows logon (local or domain-joined). When a user logs in directly to a Windows computer or server, authentication is typically handled by AD (via Kerberos or NTLM), not by a cloud IdP. In hybrid environments, even if Entra ID enforces MFA for cloud applications, traditional Windows logons to domain-joined systems are validated by local domain controllers. Unless Windows Hello for Business, smart cards, or another built-in MFA mechanism is implemented, there is no additional factor in this flow.

If an attacker obtains a user's password (or NTLM hash), they can authenticate to a domain-joined machine without enabling MFA policies that protect SaaS applications or federated single sign-on. From the domain controller's perspective, this is a standard authentication request.

2. Direct RDP access bypasses conditional access. RDP is one of the most targeted methods of access to Windows environments. Even when RDP is not exposed to the internet, attackers often reach it through lateral movement after an initial compromise. A direct RDP session to a server does not automatically pass cloud-based MFA checks, meaning the login can be based solely on the underlying AD credential.

See also: Starkiller: New phishing kit bypasses MFA

3. NTLM Authentication. NTLM is an old-school authentication protocol that, despite being deprecated in favor of the more secure Kerberos protocol, still exists for compatibility reasons. It is also a common attack vector because it supports techniques such as pass-the-hash. In pass-the-hash attacks, the attacker does not need the plaintext password.

Instead, it uses the NTLM hash to authenticate. MFA doesn’t help if the system accepts the hash as proof of identity. NTLM can also appear in internal authentication flows that organizations may not actively monitor. Only an incident or audit will bring it to the attention of security teams.

4. Kerberos Ticket Abuse. Kerberos is the primary authentication protocol for AD. Instead of stealing passwords directly, attackers steal Kerberos tickets from memory or create fake tickets after compromising privileged accounts. This allows for techniques that allow long-term access and lateral movement, and also reduces the need for repeated logins, which reduces the likelihood of detection.

These attacks can persist even after passwords are reset if the underlying breach is not fully addressed.

See also: MFA is required for logins to the Microsoft 365 admin center

5. Local Administrator Accounts and Credential Reuse. Organizations still rely on local administrator accounts for support tasks and system recovery. If local administrator passwords are reused across multiple locations, attackers can escalate a breach to widespread access. Local administrator accounts typically authenticate directly at the point of use, bypassing MFA checks entirely.