MFA is Great, But It's Not a Silver Bullet: The Windows Auth Coverage Gap
Hey everyone,
I just read the latest article on The Hacker News about where MFA stops and credential abuse starts. It really hits home on a misconception I see constantly: the belief that rolling out MFA via an IdP like Entra ID or Okta automatically invalidates stolen passwords.
In Windows environments, that assumption is dangerous. The article highlights that the issue isn't MFA itself, but coverage. Once an attacker is inside the perimeter or has phished a user's session token, they often find that legacy authentication protocols or on-prem Active Directory don't enforce the same strict MFA policies as the cloud login page.
We see this constantly during Red Team engagements. If an attacker can dump LSASS memory or perform a Pass-the-Hash (PtH) attack, your Entra MFA policy doesn't stop lateral movement.
Detection Logic: We need to start hunting for anomalies that MFA won't catch. For example, monitoring for explicit credential usage (Event ID 4648) where a user is accessing a machine they don't usually interact with:
SecurityEvent
| where EventID == 4648
| where SubjectUserName != TargetUserName
| extend TargetHost = tostring(TargetInfo)
| project TimeGenerated, Computer, SubjectUserName, TargetUserName, TargetHost, IpAddress
| summarize count() by TargetUserName, TargetHost, bin(TimeGenerated, 1h)
| where count_ > 5
Additionally, audit your local admin accounts to ensure they aren't falling outside the IdP scope entirely:
Get-LocalUser | Where-Object {$_.PrincipalSource -eq 'Local'} | Select-Object Name, Enabled, PasswordRequired
How are you guys handling the gap between cloud IdP enforcement and on-prem Windows auth? Are you strictly blocking NTLM, or do you have other compensating controls in place?
Great post. This is exactly why we've been aggressively pushing to disable NTLM and legacy LDAP auth on our domain controllers. It's a painful migration process, but relying on MFA at the edge while leaving the back door wide open via NTLM hashing is a recipe for disaster. We also implemented PTA (Pass-Through Authentication) strictly for monitoring, but the real fix was enforcing 'Smart Card is required for interactive logon' on our privileged accounts via GPO.
From a SOC perspective, we've stopped looking just at successful logons and started focusing heavily on 4624 Logon Type 3 (Network) events originating from internal IPs that shouldn't be talking to each other. MFA stops the initial phish, but it rarely stops the credential dumping that follows. We use Splunk to correlate LSASS process access events with subsequent network logons. If you aren't monitoring for mimikatz behavior, you're missing the point of the article.
I've seen this exploited so many times in pentests. I get a foothold via a phishing email, pull the LSA cache, and then use pth-winexe or crackmapexec to move laterally. The user had MFA on O365, but I never touched O365 again. I stayed entirely in the on-prem Windows environment where the MFA policy didn't reach. The coverage gap is real, especially for orgs using 'hybrid' setups without enforcing Protected Users security groups.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access