Skip to content

Zerologon

Also calledCVE-2020-1472, Netlogon elevation

A Netlogon flaw let a domain controller's own account password be reset without proof.

Needs
Network
Gives
DC Account

How the Attack Works

The August 2020 and February 2021 updates (KB4557222) close this, so on a patched, enforced domain a defender reads it as an exposure and detection story. A 2020 flaw in the Netlogon cryptography, CVE-2020-1472, let a caller on the network reset a domain controller's own computer-account password to empty without proving anything, which then opens the domain. A defender confirms enforcement is on and that no event 5829 remains, then looks for the Netlogon secure-channel events a controller writes when a vulnerable connection reaches it.

Read first Password Hashes and Kerberos Keys

How It Plays Out

The attack step by step. Each step shows which machines take part, what travels, the keys and tickets each side now holds, what is logged and what a defender can see.

On dc-01 a defender finds a burst of Netlogon secure-channel attempts from an address that is not a domain member, and, on an unpatched controller, its own computer-account password reset. The August 2020 updates refuse these once enforcement is on.Step through it

192.0.2.66 Unknown device

dc-01 Domain controller

  1. Step 1 of 3, Netlogon Attempt, 192.0.2.66 to dc-01
  2. Step 2 of 3, DC Account Reset, on dc-01
  3. Step 3 of 3, Reaches the Directory, 192.0.2.66 to dc-01
  1. Step 1 of 3: Netlogon Attempt

    192.0.2.66 Unknown device to dc-01 Domain controller

    A Netlogon attempt Netlogon RPC Netlogon RPC

    A Netlogon secure-channel negotiation reaches dc-01 from an address that is not a domain member it expects.

    Logged

    • 5827 to 5831 The Netlogon service denied a vulnerable Netlogon secure channel connection from a machine account

      On dc-01, in the System log

      A vulnerable Netlogon secure-channel connection, refused or, before enforcement, allowed.

    What Defenders See

    A controller with the August 2020 updates writes System log NETLOGON events 5827 and 5828 for a refused connection, or 5829 for one allowed before enforcement.

  2. Step 2 of 3: DC Account Reset

    On dc-01 Domain controller

    On an unpatched controller, dc-01's own computer-account password in the directory is reset, so other members' secure channels to it break.

    What Defenders See

    Secure-channel failures appear across the domain as members can no longer authenticate dc-01, a sign the controller's own account changed.

  3. Step 3 of 3: Reaches the Directory

    192.0.2.66 Unknown device to dc-01 Domain controller

    Reaching the directory DRS replication DRS RPC

    After the controller's account is reset, replication requests may arrive naming dc-01 from a host that is not a controller.

    What Defenders See

    Defender for Identity raises its Netlogon privilege elevation alert. Watch for replication from an address that is not a domain controller next, which is DCSync.

Needs First

What the attacker must already hold for this attack to be possible.

  • Network AccessNetwork reach to a domain controller, with no account needed at all.

Gives the Attacker

What running it hands the attacker to use next.

  • A DC's Computer AccountA domain controller's own computer account, once reset, which opens replication of the domain.

Leads To

What Defenders See

What this attack leaves for a defender to find, and what to read in each. None of it is proof on its own, so treat each as a lead and confirm it against the rest.

Event and LogWritten OnLook ForSwitch It On
5827 to 5831 The Netlogon service denied a vulnerable Netlogon secure channel connection from a machine account (opens in a new tab) System logDomain controllers, which log 5827 and 5828 for a refused connection and 5829 to 5831 for one allowedIn the System log, events 5827 and 5828 mark a refused vulnerable connection after enforcement, and 5829 one still allowed, which must be cleared first.Domain controllers with the August 2020 or later updates (KB4557222), which log 5829 only until enforcement

What It Looks Like

One event from the worked example, decoded field by field, so you can see what to read in it and what each value means.

5827 to 5831 The Netlogon service denied a vulnerable Netlogon secure channel connection from a machine account

In the System log on dc-01,

A vulnerable Netlogon secure-channel connection to dc-01 from an unexpected address.

  • A vulnerable connection that was allowed, logged only before enforcement. Every 5829 is a connection to clear and a lead to run down.

    As Windows writes it: Event ID 5829

  • The computer account the caller claimed, dc-01's own. A controller's account naming itself over a vulnerable channel is the signal.

    As Windows writes it: Machine SamAccountName DC-01$

  • The unknown device the Registry story tracks, not a domain member. Match it to the rest of that host's activity.

    As Windows writes it: Client IP Address 192.0.2.66

Defender for Identity Alerts

Where Defender for Identity runs, its sensors raise these from what they read on the servers they are installed on, domain controllers above all. Each names what it flags, which is a lead to confirm, not proof on its own.

Blind Spots

Where this attack leaves little or nothing to see, so a quiet log is not read as an all-clear.

  • Event 5829 in the System log records a vulnerable connection that was allowed, so clear every 5829 before enforcement, since after it only 5827 and 5828 should ever appear.
  • The reset shows on the domain controller, not on the machine that reached it, so there is nothing to read on that endpoint.

Hunt It

The query to run in each tool, and how well each one sees this attack. Pick the tool you use, and the others load their query when you open them.

Needs Defender for Identity sensors on every DC. It does not record the Netlogon call itself, it raises the elevation alert, so confirm it in the System log NETLOGON events on the named controller.

KQLDefender XDR, Advanced hunting
// Defender for Identity Netlogon elevation alerts, with the machines and addresses they nameAlertEvidence| where Timestamp > ago(30d)| where Title contains "Netlogon"| summarize FirstSeen = min(Timestamp), Devices = make_set_if(DeviceName, isnotempty(DeviceName)), Addresses = make_set_if(RemoteIP, isnotempty(RemoteIP)) by AlertId, Title| order by FirstSeen desc

How to Prevent It

The controls that break this attack, each with how it helps here and, where the Registry topic has it, where to check it on a machine.

Sources