CLDAP Reflection Attack - High Resource Usage on lsass.exe on Windows ServerPosted on
Ran into issues where lsass.exe uses up obscene amounts of resources on your Windows Server machine? It’s a common issue, especially on dedicated servers rented from providers that don’t automatically lock the machines down with external firewalls.
If you have a publicly accessible Windows Server configured to be a “domain controller” for a Windows domain, then it automatically listens for certain commands from other PCs asking for information about the Windows domain. If it’s listening to these requests from the internet at-large, then anyone can send a request pretending to be someone else and your machine will send the response to that other person.
In practice, this means that someone malicious on the internet can send a tiny request to your machine and make it send a large response to a victim’s PC instead of the requester. If they send a million requests to a thousand such machines, then the victim gets billions of large responses. In a real life scenario, the victim might receive 50+ times the amount of data than the attacker sends.
This is bad, both because you’re being used to attack other machines and because your machine’s performance is degraded because it’s busy sending traffic to PCs that haven’t requested it.
If your Windows Server has the following:
- A Windows domain configured instead of the regular Workgroup.
- A Windows Domain Controller role installed.
- High CPU usage on lsass.exe: Check Task Manager > Details to see this.
- High network usage on lsass.exe: Check Performance Monitor > Network > Select lsass.exe to see this.
If so, then you’re likely being used for targeted CLDAP Reflection attacks, and you should follow the below steps to secure your machines.
In order to resolve this and keep your Windows domain working, you must understand your Windows domain setup, or work with your systems administrator to get this resolved. If you aren’t confident of your grasp on working with Windows servers, I recommend getting a consultant to advise you.
This explanation will assume that you are only using Windows Firewall to secure your machine. If you are using another firewall as well, then replicate the changes on that.
There are two aspects to cover when trying to fix this:
- block LDAP to internet,
- allow LDAP on local network.
This should be done on all your domain controllers, including backup ones.
Allow LDAP on local network
This step will change depending on your provider. You must have/set up a second network connecting all of the computers in your domain. This network should offer no connection to the internet, only from one computer to the next. This is the internal network connection.
On the domain controller machines, the firewall should be configured to not cover this internal network connection. This will ensure that LDAP will continue functioning across this internal network connection.
Block LDAP to internet
On the domain controller machine, open the firewall and add two rules in both inbound and outbound:
- “LDAP Block” set to block port 389 on TCP.
- “LDAP Block UDP” set to block port 389 on UDP.
At the same time, disable the default LDAP TCP/UDP-in rules in both inbound and outbound.
Ensure the firewall is enabled and active on the external network connection.
Upon doing the above steps your machine will be secure, however the incoming packets will continue arriving, and resource usage will continue to be high for some time. This is because attackers tend to use a list of vulnerable machines that isn’t updated very often. Eventually the machine will be removed from the list.
Be aware that I have observed attackers then launching an attack upon secured machines, where none had happened before. Most major providers will cover you under their Anti-DDoS mitigation during this.