Why MFA Fails Inside the Network: AD Authentication Gaps Attackers Exploit

Organizations invest heavily in multi-factor authentication for their external perimeter. VPN access requires MFA. Cloud applications require MFA. Remote desktop has MFA. Executives feel confident because their security dashboards show 100% MFA coverage. Then I start an internal penetration test and compromise the entire domain without triggering a single MFA prompt.

The uncomfortable truth is that MFA, as most organizations deploy it, protects only the perimeter. Once an attacker is inside the network -- through phishing, a compromised VPN, a rogue device, or a supply chain attack -- Active Directory authentication relies entirely on passwords and Kerberos tickets. No second factor. No additional verification. Just a password hash or a ticket, and I am in.

Where MFA Does Not Apply

To understand the gap, you need to understand which authentication protocols are actually used inside a typical corporate network. NTLM authentication uses password hashes. There is no mechanism to inject MFA into the NTLM challenge-response flow. When I perform pass-the-hash or NTLM relay attacks, MFA is completely irrelevant because the protocol does not support it.

Kerberos authentication uses tickets issued by the Key Distribution Center on the domain controller. The initial ticket request (AS-REQ) validates the user's password, but there is no built-in mechanism for a second factor. Once I have a valid TGT -- whether through Kerberoasting, pass-the-ticket, or Golden Ticket forgery -- I can request service tickets to any resource without additional authentication challenges.

SMB, WMI, PowerShell remoting, RDP to servers, LDAP queries, and all other internal Windows authentication methods operate through NTLM or Kerberos. None of them enforce MFA by default. This means that the vast majority of authentication inside your network happens without any multi-factor challenge.

The Attack Scenarios MFA Cannot Prevent

Let me describe the specific attack scenarios I exploit where MFA provides zero protection:

Kerberoasting: I request service tickets using any valid domain account. The tickets are encrypted with the service account's password hash. I crack them offline. MFA has no role in the Kerberos TGS request process, so it cannot prevent or detect this attack.

NTLM relay: I intercept NTLM authentication and forward it to another server. The relay happens at the protocol level, below any MFA integration. Even if the original user has MFA enabled for interactive logon, the relayed authentication bypasses it completely.

Pass-the-hash and pass-the-ticket: I extract credential material from memory or disk and use it to authenticate as the user. These techniques bypass password entry entirely, and since MFA is typically tied to the password entry process, it is never triggered.

Lateral movement: Once I have valid credentials, I move between machines using standard remote access tools. WMI, PsExec, and PowerShell remoting all use NTLM or Kerberos authentication without MFA. I can traverse the entire network with a single set of compromised credentials.

Closing the Gap: What Actually Works

Accepting that traditional MFA cannot protect internal AD authentication, here is what I recommend instead:

Implement Windows Hello for Business: This replaces password-based authentication with certificate or key-based authentication tied to a TPM chip. It is the closest thing to real MFA for Windows authentication because the credential is bound to a specific device and backed by hardware. An attacker who steals a password hash cannot use it from a different machine.

Deploy Credential Guard: Windows Credential Guard uses virtualization-based security to isolate NTLM hashes and Kerberos tickets in a protected memory region that even local administrators cannot access. This prevents pass-the-hash and pass-the-ticket attacks on machines where it is enabled. It should be deployed on all workstations and servers that support it.

Use the Protected Users security group: Accounts in the Protected Users group cannot authenticate using NTLM, cannot have their credentials cached, and cannot use DES or RC4 encryption for Kerberos. Add all privileged accounts to this group. It significantly limits the credential theft techniques available to attackers.

Enable Authentication Policies and Silos: Available in Windows Server 2012 R2 and later, authentication policies can restrict where privileged accounts can authenticate. You can enforce that Domain Admin accounts can only obtain TGTs from specific domain controllers and can only be used from designated Privileged Access Workstations. This is effectively network-layer access control for authentication.

Detection: Compensating for the MFA Gap

Since MFA cannot protect most internal authentication, compensating detection is essential. Focus your monitoring on the specific attack techniques that bypass MFA:

• Monitor for pass-the-hash by watching for NTLM logons (Event ID 4624, logon type 3) where the source IP does not match expected patterns for the authenticated account.
• Detect Kerberoasting through Event ID 4769 with encryption type 0x17 (RC4). AES should be the standard, so RC4 requests are anomalous.
• Alert on Golden Ticket usage by monitoring for TGTs with abnormally long lifetimes or issued for nonexistent accounts.
• Watch for privilege escalation by monitoring changes to privileged groups (Event ID 4728, 4732, 4756) and modifications to sensitive AD objects (Event ID 5136).

Rethinking Internal Security Assumptions

The biggest mistake I see organizations make is treating the network perimeter as the security boundary. They invest millions in perimeter MFA and then assume everything inside the network is trusted. This assumption is what allows me to compromise entire domains on every engagement.

Zero trust architecture, applied to Active Directory, means verifying every authentication regardless of network location. It means assuming that an attacker is already inside your network and designing your controls accordingly. Credential Guard, Protected Users, authentication silos, and aggressive monitoring are not replacements for MFA -- they are the internal security controls that MFA was never designed to provide. Deploy them alongside your perimeter MFA, and you will have an environment that is genuinely difficult to compromise.