You rolled out MFA. Users tap “Approve” on their phones. Your CISO is happy. Compliance boxes are checked.
And somewhere in your environment right now, an attacker is authenticating directly to your file server with a stolen password hash — no login form, no push notification, no trace in your MFA logs.
This isn't a hypothetical. It's the most common technique red teams use to move laterally inside enterprise networks. And it works because every MFA solution on the market protects applications — not Active Directory itself.
What Your MFA Stack Doesn't See
Think about what Duo, Okta, or Azure MFA actually protects. Your VPN portal. Your email login. Your cloud apps. Anything that has a login page and supports SAML or OIDC.
Now think about what doesn't have a login page:
- An attacker running net use \\fileserver\share with a stolen credential
- Lateral movement over SMB using a compromised service account
- PsExec pivoting through your network at 2am
- A Golden Ticket authenticating directly to any service in your domain
- An RDP brute force campaign against an unprotected workstation
All of these speak directly to Active Directory using Kerberos or NTLM. Neither protocol knows what MFA is. Your DC happily issues tickets to anyone who presents valid credentials — stolen, guessed, or extracted from memory. Your MFA stack never saw any of it.
The Credential Is Already Compromised. Now What?
Here's the uncomfortable reality: credentials get stolen. Phishing, password reuse, memory scraping, insider threats — there are a hundred ways a valid Active Directory credential ends up in an attacker's hands.
The question isn't whether it will happen. It's what happens next.
With application-layer MFA, the attacker hits your VPN portal, gets a push notification challenge they can't pass, and stops there. But if they skip the portal entirely and authenticate directly to a domain resource? They're in — and you won't know until the next morning's SIEM alert, if you're lucky.
Authnull AD Shield changes what happens next. The moment a stolen credential is used against your domain — regardless of protocol, regardless of tool, regardless of whether there's an app in the way — the real user's phone lights up with a push notification. They deny it. The authentication fails. You get an alert. The attacker gets nothing.
MFA at the Identity Layer
Authnull AD Shield is a sensor that runs on the Domain Controller itself. Not a proxy. Not an agent on every endpoint. On the DC — the single chokepoint through which every domain authentication flows.
It intercepts Kerberos and NTLM authentication requests in real time, fires a push notification to the legitimate user, and physically holds the authentication in memory while they respond. No approval means no ticket. No ticket means no access.
The whole flow takes under a second. From authentication attempt to push notification on the user's phone, the sensor adds less latency than a slow DNS lookup. Users who are actually logging in tap Approve and move on. Attackers using stolen credentials get nothing but a failed authentication.
What “Agentless” Actually Means
Every competing solution that claims to protect AD has the same dependency hidden in the fine print: agents, proxies, or infrastructure changes.
Endpoint agents require installation on every workstation — leaving every unmanaged device, BYOD laptop, and machine where an attacker has removed the agent completely exposed.
Network proxies require routing all auth traffic through a chokepoint you control — complex, latency-sensitive, and a single point of failure for your entire domain.
Cloud-brokered identity requires migrating away from on-prem AD — a multi-year project that solves tomorrow's problem while leaving today's exposure untouched.
AD Shield installs as a Windows service on the DC. No endpoints touched. No network topology changed. No migration required. If your DC can run a Windows service, you're protected in minutes.
The Protocols That Actually Matter
| If an attacker uses… | AD Shield stops it via… |
|---|---|
| Pass-the-hash over SMB | NTLM interception at LSASS level |
| Pass-the-ticket | Kerberos packet hold before TGT issued |
| Golden Ticket | Kerberos AS-REQ interception |
| RDP brute force | NTLM NLA enforcement + session termination |
| LDAP credential stuffing | Event log interception + network block |
| Lateral movement via PsExec | NTLM + SMB enforcement |
What Happens When Someone Denies
When a user denies an MFA request — or doesn't respond — AD Shield doesn't just log it and move on.
The source IP is blocked at the network layer via Windows Filtering Platform. Any active sessions for that user on the DC are terminated. The security team gets a full event with username, source IP, protocol, timestamp, and workstation name. And the deny window uses a sliding expiry — every retry from the same attacker refreshes the block.
The attacker's session is dead. The legitimate user's other sessions are completely unaffected. Nobody else on that network sees any disruption.
The Bottom Line
MFA on apps is no longer enough. Attackers know your apps are protected. They go around them.
The only way to enforce MFA on every domain authentication — regardless of protocol, regardless of tool, regardless of whether there's an app in the way — is to enforce it at the identity layer. At the DC. At the point where Kerberos and NTLM actually run.
That's what Authnull AD Shield does. And nothing else on the market does it without agents, proxies, or a migration project.
Ready to close the gap? Talk to us at Authnull and see AD Shield running against your environment in a live demo.