Skip to content

NTLMv1 Downgrade

Also calledNTLMv1, LM downgrade, LmCompatibilityLevel

Gets a weak NTLMv1 response from a client still allowed to send one, then the NT hash.

Needs
Incoming Sign-In
Gives
NT HashandDC Account

How the Attack Works

NTLMv1 makes its response by encrypting the server's challenge with DES, keyed by three slices of the NT hash, and binds it to no time or target. A client whose LAN Manager authentication level is 2 or lower still sends it, to a real server or to any machine posing as one, though Windows 11 24H2 and Windows Server 2025 removed it. A v1 response can be turned back into the NT hash itself, however long and random the password, so a coerced DC gives up its own computer account's hash.

Read first LM, NTLMv1 and NTLMv2, NTLM Authenticate and Validation

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.

ws-017 is still set to send NTLMv1, and signs in to an unknown device that accepts it.Step through it

ws-017 Client

  • dana's key

192.0.2.66 Unknown device

  1. Step 1 of 3, Challenge, 192.0.2.66 to ws-017
  2. Step 2 of 3, NTLMv1 Response, ws-017 to 192.0.2.66
  3. Step 3 of 3, Hash Recovered, on 192.0.2.66
  1. Step 1 of 3: Challenge

    192.0.2.66 Unknown device to ws-017 Client

    Challenge that accepts NTLMv1 CHALLENGE_MESSAGE SMB, port 445

    The device posing as a server sends its challenge and will accept NTLMv1.

    What Defenders See

    No log on ws-017 or any other machine records the challenge, which travels in the clear. The exposure shows beforehand, in the NTLM V1 logons that real servers write to their Security logs.

    Hooks into NTLM challenge

  2. Step 2 of 3: NTLMv1 Response

    ws-017 Client to 192.0.2.66 Unknown device

    Answer in the weak NTLMv1 form AUTHENTICATE_MESSAGE SMB, port 445

    ws-017, allowed by its LAN Manager authentication level, answers in NTLMv1, which is DES over the challenge, keyed by dana's NT hash.

    What Defenders See

    No domain host logs the NTLMv1 response, because ws-017 sends it to the unknown device. A workstation old enough to send v1 also predates enhanced NTLM logging, which writes to the Microsoft-Windows-NTLM/Operational log.

    Hooks into NTLM authenticate

  3. Step 3 of 3: Hash Recovered

    On 192.0.2.66 Unknown device

    The v1 response is turned back into dana's NT hash offline, however strong her password.

    Keys

    • 192.0.2.66 now holds dana's key (new at this step)

    What Defenders See

    No log on any machine in the domain records this step, because it happens offline.

Needs First

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

  • An Incoming Sign-InA sign-in from a client still allowed to send NTLMv1, arriving at a machine the attacker controls.

Gives the Attacker

What running it hands the attacker to use next.

  • An NT HashThe NT hash of the account that signed in, recovered from the v1 response.
  • A DC's Computer AccountWhere the client is a coerced DC, its computer account's hash, which carries replication rights.

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
4624 An account was successfully logged on (opens in a new tab) Security logThe computer that was logged on toPackage Name (NTLM only) NTLM V1 on a real server, which means the client still sends v1, and would send it to any machine.Reading Logon Events explains how to read it.Audit Logon
4020 and 4021 This machine attempted to authenticate to a remote resource via NTLM (opens in a new tab) Microsoft-Windows-NTLM/Operational logThe client that sends the NTLM sign-in (4021 flags a weaker one, such as NTLMv1)A 4021 warning on a Windows Server 2019 or 2022 machine, such as a coerced DC, that sent NTLMv1 as a client, which newer Windows cannot do.On by default on Windows 11 24H2, Windows Server 2025 and, with October 2026 updates, Windows Server 2019 and 2022. The NTLM Enhanced Logging policy (System > NTLM) controls it
4022 and 4023 A remote client is using NTLM to authenticate to this workstation (opens in a new tab) Microsoft-Windows-NTLM/Operational logThe server the NTLM sign-in reaches (4023 flags a weaker one, such as NTLMv1)A 4023 warning on a server that received NTLMv1, naming the client that sent it.On by default on Windows 11 24H2, Windows Server 2025 and, with October 2026 updates, Windows Server 2019 and 2022. The NTLM Enhanced Logging policy (System > NTLM) controls it
4030 to 4033 The DC <DC Name> processed a forwarded NTLM authentication request originating from this domain (opens in a new tab) Microsoft-Windows-NTLM/Operational logDomain controllers, which log 4032 and 4033 when the server is in its domain and 4030 and 4031 when only the client account isA 4033 warning on a DC, or 4031 across domains, for an NTLMv1 sign-in it checked for a server.On by default on Windows 11 24H2, Windows Server 2025 and, with October 2026 updates, Windows Server 2019 and 2022. The Log Enhanced Domain-wide NTLM Logs policy (System > Netlogon) controls it

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.

4624 An account was successfully logged on

In the Security log on srv-fin-01,

The exposure, seen beforehand, because ws-017 still signs in to srv-fin-01 with NTLMv1.

  • Whose response was built in v1. Any machine posing as a server would get the same weak form.

    As Windows writes it: Account Name dana

  • The client still set to send NTLMv1, because its LAN Manager authentication level is 2 or lower.

    As Windows writes it: Workstation Name WS-017

  • ws-017's own address, so this logon is genuine. The risk is the setting, not this sign-in.

    As Windows writes it: Source Network Address 192.0.2.17

  • The sign-in used NTLM, and Package Name says which version.

    As Windows writes it: Authentication Package NTLM

  • The weak version 1 response. Move this client to NTLMv2 only before anyone downgrades it.

    As Windows writes it: Package Name (NTLM only) NTLM V1

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.

  • The v1 answer goes to a machine outside your estate, so no logon event records the theft. Find the exposure first, in NTLM V1 logons and the enhanced NTLM warnings.
  • A client set to send v1 that never signs in to your servers leaves no NTLM V1 logon, so read its LAN Manager authentication level instead.

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 Endpoint, and it sees only changes to the value inside its retention, not one set long ago. A hit shows a machine set to send v1, not that any response was captured, which goes to a machine outside your estate.

KQLDefender XDR, Advanced hunting
// Machines set to send NTLMv1 or LM responses (LmCompatibilityLevel 0, 1 or 2)DeviceRegistryEvents| where Timestamp > ago(30d)| where RegistryKey endswith @"\Control\Lsa" and RegistryValueName =~ "LmCompatibilityLevel"| where RegistryValueData in ("0", "1", "2")| project Timestamp, DeviceName, ActionType, RegistryValueData, PreviousRegistryValueData, InitiatingProcessAccountName, InitiatingProcessCommandLine| order by Timestamp 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