← Blog
Asif
AsifJune 4, 2026
Engineering

Building Agentless MFA Enforcement for Active Directory

How Authnull Intercepts Kerberos and NTLM at the Domain Controller — Before a Ticket Is Ever Issued


Most enterprises think they have MFA covered. They've rolled out Duo, wired up Okta, enforced Azure AD Conditional Access. Their users tap “Approve” a dozen times a day.

And then a red team operator runs Mimikatz, grabs a hash from memory, and authenticates directly to a file server over SMB. No app proxy. No login form. No MFA prompt. Just a clean authentication straight through Active Directory — and nobody notices.

That's the gap Authnull AD Shield is built to close.

The Problem Nobody Talks About

Every MFA solution on the market works the same way: sit in front of an application and intercept the login. It's effective for protecting specific apps. It's completely blind to anything that speaks directly to Active Directory.

Kerberos and NTLM don't have login forms. They don't have SSO portals. They're binary protocols baked into Windows since before MFA was a concept — and your DC processes them thousands of times a day, completely invisible to your MFA stack.

Pass-the-hash. Pass-the-ticket. Golden Ticket attacks. Lateral movement over SMB. RDP brute force. Every one of these goes straight through Active Directory without triggering a single push notification. Until now.

What AD Shield Actually Does

Authnull AD Shield is a sensor that runs directly on the Domain Controller. Not a proxy in front of it. Not an agent on every endpoint. On the DC itself — where every single domain authentication flows through, no exceptions.

When a user (or an attacker using stolen credentials) authenticates against your domain, the sensor intercepts the request, fires a push notification to the real user's phone, and holds the authentication in memory while they respond.

Approve — ticket issued, session established.

Deny — authentication fails before a ticket ever exists.

The attacker never gets in. The real user finds out someone is using their credentials. Your security team gets a full audit trail.

Four Layers of Interception

AD Shield doesn't rely on a single mechanism. It stacks four complementary interception layers so nothing slips through.

Layer 1 — Windows Security Event Log

The DC's Security log records every authentication event in real time. AD Shield subscribes to these events via a live watcher and parses them into a normalized format within milliseconds: 4624 (logon), 4768 (Kerberos TGT), 4776 (NTLM validation). This covers everything — including protocols that never generate a visible login form.

Layer 2 — SSP DLL (Inside LSASS)

A custom Security Support Provider DLL is loaded directly into lsass.exe — the Windows process responsible for every authentication on the machine. The SpAcceptCredentials callback fires synchronously during NTLM authentication, before the logon session is created. This is true inline enforcement — the authentication physically cannot complete until MFA resolves.

Layer 3 — WinDivert Packet Interception

For Kerberos, we go even deeper. WinDivert captures AS-REQ packets on port 88 before lsass ever sees them. The packet sits in memory while MFA runs. On approval it is reinjected unchanged. On denial a Kerberos error is returned to the client. This is the only way to enforce before a TGT is issued — no ticket, no session, no lateral movement path.

Layer 4 — Windows Filtering Platform

After a denial verdict, WFP rules block the source IP on ports 88/445/135/139 for a configurable window. This is the backstop — catches edge cases where inline interception wasn't possible and prevents the client from retrying through a different code path.

The Decision Pipeline

Every authentication event — regardless of which interception layer caught it — runs through the same four-step pipeline. The auth request is held at every step. There is no path through the pipeline that bypasses MFA.

Auth Event
    │
    ▼
[Step 1] Local policy check         < 1ms   Whitelist/blacklist, service accounts
    │
    ▼
[Step 2] Backend policy check               Risk score, geo, device posture, time
    │
    ▼
[Step 3] MFA push notification              User approves or denies on mobile
    │
    ▼
[Step 4] JIT privilege escalation           Admin approval gate for sensitive access
    │
    ▼
Verdict: Allow / Deny

The Engineering Challenges Worth Knowing About

Eliminating Noise Without Losing Coverage

A single RDP login generates 6–8 auth events simultaneously — an NTLM validation, a TGT request, a service ticket, a logon event. Without deduplication, one login means eight push notifications. AD Shield uses a per-user semaphore with a pipeline-pending cache state: the first event claims the pipeline, subsequent events wait and reuse the verdict.

Background Windows processes are an even bigger noise source — Kerberos ticket renewals, Group Policy refresh, Netlogon heartbeats. AD Shield filters these out by default, so MFA only triggers on real interactive logons and direct NTLM challenges.

NTLM Over CredSSP (RDP NLA)

NTLM for RDP Network Level Authentication travels inside TLS on port 3389. WinDivert can't intercept it inline because it's encrypted. AD Shield handles this through the SSP DLL path, which fires inside LSASS regardless of the transport layer, plus session termination after a denial verdict.

Circuit Breaker

If the Authnull backend is unreachable, the sensor doesn't fail-closed and lock everyone out. A circuit breaker opens after 5 consecutive failures, applies a configurable fallback (allow or deny), and probes again every 30 seconds. When the backend recovers, the circuit closes automatically and enforcement resumes.

Protocol Coverage at a Glance

ProtocolCommon Attack VectorHow AD Shield Enforces
Kerberos AS-REQPass-the-ticket, Golden TicketWinDivert inline hold before TGT issued
NTLMPass-the-hash, relay attacksSSP DLL (LSASS-level) + event log
RDP (NLA)Credential stuffing, brute forceNTLM path + WFP block + session termination
SMBLateral movement, ransomware prepWFP block post-denial
LDAPEnumeration, bind attacksEvent log + WFP

Zero Infrastructure Changes

AD Shield installs as a Windows service in minutes. No Group Policy changes. No client-side software. No network reconfiguration. No proxies between your DCs and your workstations.

The Domain Controller is already the chokepoint for every domain authentication — AD Shield simply adds an enforcement layer at that chokepoint, invisible to everything around it.

Authnull AD Shield is available now. Get in touch to see it running against your environment.


← Back to Blog