This is a modified version of dirkjanm's Zerologon exploit that uses some cryptographic tomfoolery to make the exploit check harder to detect.
As specified in the paper, it's not just a challenge of all zero bytes that will result in an all-zero ciphertext. Any byte value repeated will produce the same all-zero ciphertext with the same random chance: 1 in 256.
This means that our challenge can be randomized and does not need to be all zeroes, potentially avoiding IDS detection.
Furthermore, if we are not doing more than checking for exploitability, we can also change the last byte of the challenge to an arbitrary value and, provided the original condition holds where AES(b'\x00'*16, sessionkey)[0] == X where X is the repeated byte in our challenge, we can predict the encrypted version of the next byte Y will be X ^ Y, e.g. the challenge b'AAAAAAAH' (from which the campy "zeroscream" name originates) would produce a ciphertext of b'\x00\x00\x00\x00\x00\x00\x00\x09' 1 in every 256 tries. However, this produces a challenge that makes the next steps of the exploit infeasible given what we know as of this writing, as it is not all zeroes.
It's also still within the realm of feasibility to make the last two bytes different. While we cannot predict the last ciphertext byte, we can guess it with a 1 in 256 chance of being correct. Between the original exploit condition and this new byte guess, we have a 1 in 65535 chance of success.
This exploit script will randomize the challenge to something other than zeroes on every connection. If run with the -just-dc flag, the last byte will be changed to a different byte value to avoid an all-zero ciphertext. Using the -sneaky flag as well will randomize the last two bytes, making the tool take longer to run, but will make detection even less likely. This is probably overkill, and more of a proof of concept than anything.
Greetz to Tom Tervoort from Secura, Dirkjan, and X-Force Red.
Dirkjan's README is reproduced below:
Requires the latest impacket from GitHub with added netlogon structures.
Do note that by default this changes the password of the domain controller account. Yes this allows you to DCSync, but it also breaks communication with other domain controllers, so be careful with this!
More info and original research here
- Read the blog/whitepaper above so you know what you're doing
- Run
cve-2020-1472-exploit.pywith IP and netbios name of DC - DCSync with secretsdump, using
-just-dcand-no-passor empty hashes and theDCHOSTNAME$account
If you install a version of impacket from GitHub that was updated on or after September 15th 2020, secretsdump will automatically dump the plaintext machine password (hex encoded) when dumping the local registry secrets.
Alternatively on slightly older versions you can dump this same password by first extracting the registry hives and then running secretsdump offline (it will then always print the plaintext key because it can't calculate the Kerberos hashes).
With this password you can run restorepassword.py with the -hexpass parameter. This will first authenticate with the empty password to the same DC and then set the password back to the original one. Make sure you supply the netbios name and IP again as target, so for example:
python restorepassword.py testsegment/s2016dc@s2016dc -target-ip 192.168.222.113 -hexpass e6ad4c4f64e71cf8c8020aa44bbd70ee711b8dce2adecd7e0d7fd1d76d70a848c987450c5be97b230bd144f3c3...etc