The Hidden Problem that XDR has to Solve and Why You Should be Careful about XDR

Let’s Connect! | LinkedIn| Twitter

Photo by Markus Spiske on Unsplash

What is your experience with an XDR product? Have you started using one, or are you considering buying one? As a person who has experience with both EDR, SIEM, and a little bit of XDR, I’ll explain what will be the success or failure factor for the XDR products from my perspective.

Forrester has recently defined the XDR as follows:

XDR is emerging due to the value that endpoint detection and response (EDR) brings to incident response and the appetite to pair EDR data with additional telemetry that can’t be captured from endpoints alone. Forrester defines XDR as:

The evolution of EDR, which optimizes threat detection, investigation, response, and hunting in real time. XDR unifies security-relevant endpoint detections with telemetry from security and business tools such as network analysis and visibility (NAV), email security, identity and access management, cloud security, and more. It is a cloud-native platform built on big data infrastructure to provide security teams with flexibility, scalability, and opportunities for automation.

Let’s try to see the potential value of XDR by looking at the below attack chain example:

Information about the victim:

User: Bob White
Account Name: contoso\bwhite
Email Address:
Bob’s workstation: WS-BOBWHITE.contoso.local

Bob has a separate account for performing operations that require high privileges.

Bob’s privileged account: contoso\adm-bob.white

1. Bob receives a phishing e-mail

  • The email security gateway generates an informational/low severity alert.
  • Since the confidence level is low, the email is delivered to Bob.
  • Since there are too many alerts, the alert is not investigated properly or never investigated(alert fatigue).
  • The email alert summary
    Alert Name: An email with a low Spam score was delivered
    Destination User:

2. Bob opens the attachment in the email, enables the macro

  • Macro runs, and a backdoor gets installed on WS-BOBWHITE
  • AV/EDR generates an informational/low severity alert(or maybe doesn't generate an alert at all)
  • Since there are lots of alerts with the same name/type, the alert is not picked up by the SOC or closed as FP (maybe Bob’s PC is known to generate FPs)
  • The alert summary
    Alert Name: Suspicious process execution
    Account name: contoso\bwhite
    Source: ws-bobwhite.contoso.local

3. Bob uses his privileged account on his workstation to perform an administrative task

  • The attacker steals the Kerberos TGT of contoso\adm-bob.white
  • The attacker uses TGT and tries to logon to several remote devices. This activity generates a few logon failures and causes a low severity alert. The alert is low severity because Bob is known to logon to several devices for daily operations.
  • The alert (…guess what…) is skipped!
  • The alert summary
    Alert Name: Suspicious Logon Failures
    Account: adm-bob.white
    Source: WS-BOBWHITE

If we were able to correlate all these alerts together, it would be quite easy to generate a high severity alert with all the low/informational severity alert details. The problem is, although all the alerts are related to the same attack, the information provided in the alerts makes it difficult to correlate information.

Let’s have a look at another attack, Web Shell (phishing and the web shell is the most common initial vector):

  1. Your IDS/IPS generates an alert with the Public IP of your Web Application.
  2. Your Next-Gen Firewall generates an alert with the Load Balancer Virtual IP of your Web Application.
  3. Your WAF generates an alert with the URL of your Web Application.
  4. Your HIDS/AV generates an alert with the server hostname of your Web Application.

How are you going to correlate these all alerts?

Correlation has been the main issue with SIEM products for years. Everyone has been talking about correlation but has never thought about its true meaning behind the scenes or has never tried to analyze what the issue was with the correlation. Yes, SIEM implementations have failed because they were not able to correlate logs properly out-of-box, and it was NOT the SIEM’s fault. It was(and still is) security vendors’ fault because they are responsible for the logs they generate.

EDRs have been successful because they didn’t face such a correlation issue. All the logs/activities are in a unified format across all the systems. Process events, network events, registry events, etc., all have the user name, hostname, etc., in the same format.

If an XDR can’t solve the correlation issue, it will be just another SIEM+SOAR type centralized product(or let’s say Next-Gen Failed SIEM).

Native XDRs have the potential to solve this issue. However, even these products require customization according to the environment(been there, done that).

In my opinion, one of the most important questions you should ask a vendor must be the correlation capabilities of the XDR product, and it should be an important evaluation criterion when making a decision.

Will XDR solve the issue? Time will tell. Till then, I’ll use my tailor-made solutions.

Disclaimer: All the characters and events depicted are fictitious in the scenarios explained in this post.


Cyber Defense Professional. @Cyb3rMonk ( Threat Hunting | Active Defense | Cyber Deception | SOC | SIEM )

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store