For Part I of this article see: How to Detect Zerologon Attacks
First, an Update
Samba versions 4.7 and below are also vulnerable to Zerologon
Non-Microsoft software which interacts with or is compatible with low-level Microsoft Network services may also be vulnerable. This includes the Open Source Samba project which provides components to seamlessly integrate Linux/Unix Servers with Microsoft Network Services. However, since version 4.8 (released in March 2018), the default behaviour of Samba has been to insist on a secure netlogon chamnnel, which is a sufficient fix against the known exploits. This default is equivalent to having 'server schannel = yes' in the smb.conf.
The netlogon protocol contains a flaw that allows an authentication bypass. This was reported and patched by Microsoft as CVE-2020-1472. Since the bug is a protocol level flaw, and Samba implements the protocol, Samba is also vulnerable.
However, since version 4.8 (released in March 2018), the default behaviour of Samba has been to insist on a secure netlogon channel, which is a sufficient fix against the known exploits. This default is equivalent to having 'server schannel = yes' in the smb.conf.Samba patches are linked here: https://www.samba.org/samba/history/security.html
The New Exploit Method (doesn't require a password reset)
Dirk-jan Mollema described a new exploit chain in his tweet below (and his blog). This method does not require the reset of the Domain Controller machine account password (and the resulting Active Directory mayhem) , which means that all detection methods relying on the password reset detection will not detect this method.
This attack method relies on a "printer bug" (discovered in 2018 by Lee Christensen). An attacker can use this bug to trigger an authentication (via NTLM) from any machine that has the print spooler service enabled. In short (and with apologies to Dirk-jan and everyone who worked on this attack method), this attack chain goes a little like this:
It all starts by using the printer bug to trigger a Domain Controller ("Domain Controller 1") to authenticate to an Attacker controlled machine.
The Attacker's machine is running a specialized relay tool called NTLMRelay. This tool receives the triggered auth attempt from Domain Controller 1.
The Attacker machine uses the Zerologon vulnerability to establish a netlogon session with another Domain Controller ("Domain Controller 2") and then relays the NTLM authentication message from Domain Controller 1 (yes, we need at least two DCs).
Domain Controller 2 accepts the Attacker relayed authentication attempt (originally from Domain Controller 1) and sends the Attacker a session key with the privileges of the Domain Controller 1 machine account. This account has special privileges which allow it to carry out common Domain Controller tasks like synchronizing Active Directory LDAP objects between two domain controllers in the same Active Directory domain (usually called Directory Replication).
The attacker now uses this session key to initiate a connection to the DRSUAPI (Directory Replication Service) and trigger replication for administrative accounts, which will result in the domain controller sending the Attacker the password hash for the krbtgt account, which enables the attacker to execute a Golden Ticket / Pass-the-Hash attack, thereby giving them unfettered access to Active Directory and member computers.
This is likely not the only attack permutation either. Any protocol accepting NTLM authentication and allowing for privileged access could be a potential target.
Note that the method described in our previous How to Detect Zerologon Attacks article does not only rely on the machine account password reset, but also relies on the noise created during the on average 256 NetrServerAuthenticate calls required to successfully brute force the netlogon authentication.
How To Detect
Detect the Printer Bug
It's hard to detect this one, but we are on the lookout. This section will be updated if we find something that can detect this to some level of certainty without too many false positives.
Detect ZeroLogon
Event ID 4742: Windows Event ID 4742 “A computer account was changed”, often combined with Windows Event ID 4672 “Special privileges assigned to new logon”.
The problem with the ID 4742 artifact is that even though it is uncommon, it does happen periodically, and can therefore lead to false positive detections
Network traffic: The second is an abnormal spike in traffic between lsass.exe and the attacker as part of the key guessing step. You'd need to be monitoring network traffic in order to detect this. Pretty hard to instrument that in a reliable way in a typical network architecture.
Good ole' NetLogon Debug log: The best way we have found was the method described in the last post and it works wonderfully. It gives you a play-by-play of the netlogon bruteforce attempt.
Note that Microsoft also added five new event IDs to notify vulnerable Netlogon connections in the August, 2020 patch. For example, the event ID 5829 is generated when a vulnerable Netlogon secure channel connection is allowed.
Detect DCSync
Enable Relevant Audit Policy Subcategories
To detect this, you will have to enable Windows audit policies for the following event categories:
Directory Service Replication: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn319121(v=ws.11)
Detailed Directory Service Replication: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn311482(v=ws.11)
This can be done by opening the Local Group Policy Editor and going to Computer configurations > Windows Settings > Security Settings > Local Policies > Audit Policy. Right clicking on the two audit categories described above and then clicking on Properties. Check the box for Success and click Apply.
The DCSync attack has two components. It passes a stolen hash to the DC and then requests a directory replication. These can be detected separately, but when detected together can build more confidence in the detection.
Detect Pass-The-Hash
Event ID 4776: Event ID 4776 (The domain controller attempted to validate the credentials for an account) is logged when a domain controller successfully authenticates a user via NTLM (instead of Kerberos). This specifies the user account who logged on (Account Name) as well as the client computer's name from which the user initiated the logon in the Workstation field. Check for domain controller machine account names (e.g. DomainController1$) logging in from computer names which are not the same domain controller.
Event ID 4624: Event ID 4624 (An account was successfully logged on) is important because it contains the source IP address (instead of the derived computer name) of the machine where the authentication event originated. The idea here is the same as the event 4776 above. Check for domain controller machine accounts (e.g. DC1$) logging in from an IP address which does not belong to Domain Controller 1.
Detect Directory Replication
Event ID 4662: Now that we have enabled the generation of logs for the appropriate events, it is possible to hunt for DCsync attacks by looking for this event 4662 on Domain Controllers. The account performing the sync should almost always be the computer account of another domain controller. If this is not the case, the event should be investigated. It may be an attacker attempting to obtain credentials for an administrative account. No environment is the same, so there are some exceptions to this rule. Some hybrid cloud setups may have directory replication configured with Azure. This would manifest itself in Event ID 4662 with the Azure replication service account attempting the sync.
In our current scenario, the attacker has hijacked a Domain Controller machine account. The replication requests will actually appear to be coming from the correct Domain Controller 1 machine account. So, although this method works in some cases, it doesn't help us right now.
Event ID 4932: Event ID 4932 (Synchronization of a replica of an Active Directory naming context has begun) actually shows the computer account LDAP DN (distinguished name) in the Source DRA parameter recorded in the event information.
How To Prevent
Some ideas for prevention.
Bad Idea: Disable Print Spoolers on all servers except the ones that need it
This sounds like a great idea –from a defense-in-depth perspective– until you realize that Active Directory environments are immensely complicated and you could mess something up that you'll only find out months later. See tweet below:
https://twitter.com/rootsecdev/status/1307686585811570691?s=19
Harden your Active Directory environment
Block outbound network connections from the Domain Controllers to internal Computers
Once again, sound like a great defense-in-depth security architecture. There may be some caveats where –typically smaller shops– are using the Domain Controller servers for things other than Active Directory related services, which need to reach out to member computers. However, for the most part Active Directory domain joined computers are the ones reaching out to the Domain Controllers, not the other way around.
In our scenario, the Printer Bug would not have been able to generate a successful auth request from Domain Controller 1 out to the attacker machine if the DC-to-Computer network access was blocked.
Block outbound network connections from the Domain Controller to the Internet
It may also be helpful to block outbound Internet access for Domain Controllers (with the exception of DNS, if the DC is your primary DNS). This may also be a great idea for other sensitive servers. Also take into account processes like fetching updates and certificate revocation lists. This would prevent things like direct payload downloads from the Internet.
Client Isolation
Client isolation means that individual computers are not able to connect to each other. Although Windows computers can expose file shares and other services directly (without the need of a server) to other computers on the same network, it is not a great practice from a security perspective. Preventing domain joined computers from talking to each other over the network would prevent malicious actor lateral movement using Pass-The-Hash and Golden Ticket attacks.
Hopefully this help informs not just detection on new flavors of Zerologon attacks, but also pass-the-hash attacks in general and also hardening the environment which could prevent these attacks. If you see something here that we missed feel free to ping us at hello@ovrsr.com.
About us: Overseer Security provides part-time cybersecurity leaders (dedicated hours per week or month) to build your security and privacy programs and policies and then help implement processes, infrastructure, and tooling. Talk security to us at hello@ovrsr.com.