I had a Groundhog kind of day investigating detections yesterday for a higher-ed customer.
For any security team, validating an incident, up or down, is hugely valuable. For each incident you're unsure of, you're wasting precious time and resources.
This one started with detection of an LDAP credentials error. No one knew what the device was, and our related detections view showed this device had a "Spike in SSH Sessions" detection three days prior. Secure shell protocol (SSH) is a common application protocol for secure network communications. It's functions include remote access and remote command execution. With these SSH sessions, a user can control and modify remote servers online.
After the SSH detection, details on the ExtraHop Reveal(x) detection card showed that the victim had in turn become an offender, suggesting that the device may have been compromised. Was it possible that something was installed, lying dormant, and now probing for access?
What is the LDAP Protocol?
Lightweight directory access protocol (LDAP) is a technology staple for access control and authorization. It's a vendor-neutral application protocol that facilitates pulling data from servers and communication with on-premises directories. The LDAP protocol manages and arranges data—credentials, devices information, and other values.
Gaining access to the directory information is a straight-forward process:
- A session begins with a client binding to an LDAP server (DSA, Directory System Agent), default port 389. Invalid credentials will result in a failure to bind.
- The client then sends an operation request (a search or compare request) to the server, asking for a particular set of information.
- The server processes this query and supplies a response.
- The client receives the response and unbinds, then processes the data.
LDAP is not without security concerns, and that's why it's crucial to take any alert seriously. Data-fetching operations, modification of data, and spoofing a directory by modifying data in transit can lead to major business disruptions.
The Reveal(x) detection card showed the list of servers being queried, but we did not see details about the user accounts. We drilled down into the device involved and viewed LDAP client activity to see the BindDN list, which includes the credentials used to authenticate against the LDAP protocol.
The first few entries were for root, admin, and such, which didn't raise concerns for the customer. Afterall, many services need root or admin depending on the traffic. However, we saw errors from invalid passwords and wanted to investigate.
Records to the rescue! We jumped from the invalid credential errors to the LDAP response records, and scoped more narrowly to the spike in errors. When we added requests and grouped by BindDN values we began to see some interesting names. This was enough to warrant bringing in another colleague to show our findings. He explained that this device hosts some public-facing services.
We continued the investigation by viewing server activity (HTTP, SSL and SSH). We drilled into URIs, which are unique sequences of characters that represent a data object on the internet, and verified the top five were the service URIs. We also noted the 100% error rate for one of the service URIs.
We navigated to that URI and were presented with a login window: Once a user logs into a web page, a device will make a client request to LDAP to verify credentials. When LDAP servers respond with the invalid password error, the device in this case then responds with an HTTP error. I explained how ExtraHop can correlate server and client activity, and offer insights into HTTP server data.
By using Reveal(x) to view records for the HTTP and LDAP activity for this device, we were able to see the HTTP error status code for the URIs and the invalid password errors for each user account verification attempt.
After a brief discussion everyone agreed this behavior was not a concern (just internal testing being done) and previous SSH spikes were likely unrelated.
This entire investigation involving a two-tier transactional scenario with multiple protocols was investigated in minutes—versus days—which was a huge success for the security team. They can now move forward with confidence, knowing they can take action quickly in the event of another incident.