In this writeup, I am going to be taking a look at ZeroLogon. At a high level, ZeroLogon comes from an implementation error with Microsoft’s MS-NRPC.
I used the exploit that was located here. The only issue that I had with the exploit, is that I was running Impacket v0.9.21. Although this version is stated in the requirements.txt
of the GitHub repo, I was having an issue that stated that a function inside of the exploit’s function script was not found in the installed Impacket version. This is what the error looked like when it did occur:
![](ZeroLogon writeup – Perf3ct Se.png)
Removing my install via rm
and pip
, and then reinstalling the latest release of Impacket (v0.9.22) from GitHub and following the instructions, I was able to get the exploit to run without any issues.
How does it work?
From the blog post here: “Researchers from Dutch security firm Secura, who found this vulnerability, released a whitepaper last week that explains in detail why the flaw exists and how it works. MS-NRPC’s handshake and authentication involves the use of AES-CFB8 (8-bit cipher feedback) mode. This is a more obscure variant of the AES block cipher that is designed to work with blocks of 8 bytes of input instead of the regular 16 bytes (128-bit).
“In order to be able to encrypt the initial bytes of a message, an Initialisation Vector (IV) must be specified to bootstrap the encryption process,” Secura researcher Tom Tervoort said in the whitepaper. “This IV value must be unique and randomly generated for each separate plaintext that is encrypted with the same key. The ComputeNetlogonCredential function [of the MS-NRPC protocol], however, defines that this IV is fixed and should always consist of 16 zero bytes. This violates the requirements for using AES-CFB8 securely: Its security properties only hold when IVs are random.”
Tervoort figured out that because of this implementation error for 1 in 256 keys, applying AES-CFB8 encryption to an all-zero plaintext will result in all-zero ciphertext. In the context of MS-NRPC, the attacker impersonating a client can send a challenge during the handshake made up of 8-bytes of zeros and keep retrying for 256 times until the server will accept it, bypassing authentication. This is a simplification of the whole process, which is detailed in the whitepaper, because the goal of a handshake in a key exchange protocol is to establish a shared secret between two parties that is used to secure the connection without actually exposing passwords or secret keys before the communication channel is secure.”
The whitepaper for ZeroLogon discovered by the team at Secura can be found here, and the blog post previously mentioned can be found here.
Can the machines see each other?
All that is really required for this exploit to work, aside from the code dependencies, is the ability to reach the domain controller. For this attack, I am running a Windows Server 2019 datacenter, under the hostname VESEMIR-DC
, that does not have the latest patches, and is therefore vulnerable to the exploit dubbed ZeroLogon by Secura.
Attacker –> Victim connection
Victim –> Attacker connection
Running ZeroLogon:
Running secretsdump.py
after changing the machine password
Supplying empty password hashes to authenticate to the machine: