Ok, so I took a look at detecting the LDAP bruteforcer ldapnomnom (github.com/lkarlslund/lda… by @lkarlslund) with vanilla Zeek (@Zeekurity) and vanilla @Suricata_IDS (w. ET Open). (Thanks to @boller for PCAPs)
Short conclusion: Zeek can detect it, Suricata can't.
#itsecurity
1/12
Short conclusion: Zeek can detect it, Suricata can't.
#itsecurity
1/12
Zeek unfortunately doesn't have a LDAP protocol decoder in the vanilla install. One is available as a package though, but that's for another thread.
2/12
2/12
Zeek's conn.log gives enough data to detect this attack. Normal, unencrypted LDAP traffic consists of both UDP and TCP. Common for this traffic is that it's relatively few bytes being transferred - significantly fewer than when ldapnomnom starts bruteforcing.
3/12
3/12
Here I've taken normal traffic from an organization with about 1k users and compared it to the ldapnomnom traffic.
4/12
4/12
Writing a detection for this is pretty straight forward:
(id_resp_p = 389 AND orig_bytes > 30000)
This should give a minimum of false positives. For the standard traffic I've seen in a normal Windows network over the last month it produces no false positives.
5/12
(id_resp_p = 389 AND orig_bytes > 30000)
This should give a minimum of false positives. For the standard traffic I've seen in a normal Windows network over the last month it produces no false positives.
5/12
When it comes to the TLS variant of LDAP (called LDAPS) on port 636 the picture resembles the unencrypted traffic on port 389.
6/12
6/12
The only difference in the environment I'm looking at is that there are regular connections with high amounts of traffic, probably some kind of sync - it always happens to the same servers.
7/12
7/12
So the TLS detection becomes:
(id_resp_p = 636 AND orig_bytes > 30000 AND id_orig_h != "10.0.0.1")
.. for the environment I'm looking at. Examine your environment for servers doing syncs over LDAPS and exclude them (like I've shown for 10.0.0.1).
8/12
(id_resp_p = 636 AND orig_bytes > 30000 AND id_orig_h != "10.0.0.1")
.. for the environment I'm looking at. Examine your environment for servers doing syncs over LDAPS and exclude them (like I've shown for 10.0.0.1).
8/12
Vanilla Suricata with the Emerging Threats (ET) Open signature set enabled gives no usable alerts. A detection signature would probably be a good idea.
9/12
9/12
When it comes to detection mitigations from the attacker side: Shorter lived connections with fewer attempts per connection would enable ldapnomnom to go under the radar with these stats based detections.
10/12
10/12
If ldapnomnom gets these improvements then a protocol based detection in Zeek is probably needed, but it'll be hard to detect on the network side in the TLS enabled connections, apart from aggregated statistics.
11/12
11/12
All in all: Baseline your network with @Zeekurity and you'll be able to detect the ldapnomnom attack - for now.
12/12
12/12
• • •
Missing some Tweet in this thread? You can try to
force a refresh
