Tag Archive: DefenderXDR

Some time ago, Microsoft announced and released Automatic Attack Disruption which is a feature within the Microsoft Defender XDR suite. Since then it has growth and from working for a service provider of Managed Detection and Response and running 100% Microsoft XDR, this is an amazing feature.

This blogpost will explain different aspects of disruption and how certain things works and the requirements in form of configurations to make it work.

Please note: All screenshots from Defender is from a Demo and Lab tenants and not customer tenants

The feature has to many parts possible to write a blog post about on its own, but let’s start somewhere:

Automatic Attack Disruption is not a new Auto IR (MDE) that acts on a single detection and tries to remediate according to defined playbook. Attack Disruption is chain of events, lower signals, such as RDP login to next event to next etc. until a certain level of confidence is reached. When the confidence reaches 99%+ SNR (Signal to Noise Ratio) then it kicks in. But it doesn’t simply stops processes or uses other classical Antimalware techniques, it goes back to the initial event and blocks everything used on the way.

Example scenario:

Internet to exposed RDP > Ask for service tickets for all SPNs (Kerberoast) > [Offline crack] > Login interactively to a server from the compromised RDP using one of the credentials from the Kerberoast attack > Enumerate ADCS templates > enroll certificate with new SAN > Domain admin

What Attack disruption will do is take a note of the initial RDP (similar to a human like: “Ok, someone used RDP, it’s not malicious but I will keep an eye on it”).

Next step is the Kerberoast

Still not malicious activities depending on how the threat actor executes that it could be an SPN enumeration alert. However, asking DC for a ticket is how Active Directory works and let’s play this as no incidents are generated in this case.

Threat Actor’s next step, after the tickets where cracked and the SPN account password is now in clear text (using hashcat, john to crack the password). Now it’s time for Threat Actor to login using these credentials and they user RDP to login interactively on the remote server.

The server they end up on has access as system to enroll a vulnerable certificate template (ESC1) and becomes domain admin using a sensitive account as the SAN name.

When Attack Disruption is over 99% certain that this is malicious activities, it kicks in. Remember that just RDP is very common still by both users and admins and Attack Disruption does not kick in until it is certain.

What is awesome with the feature is that when it kicks in, it takes care of entities involved in the chain, to completely block the Threat Actor. Such as containing device (If not onboarded to MDE, it will tell all onboarded endpoints that they are not allowed to communicate with the mentioned device). The involved users will be contained as well, blocking them from logons and disabling accounts.

Another example I would like to explain is the Business Email Compromise, BEC

A user clicks on a phishing link (even if we, as a community pushes security awareness, it still happens frequently)

The user who clicked ends up on the link lands on a phishing website, which act as a proxy and therefor can handle MFA requests as well since the proxy will try authenticate to, in this case, Office 365

MFA

From the Threat Actor side and the Evilginx, the authentication is captured

The cookies from the authentication can then be injected to the browser and the threat actors are logged in.

The Threat Actor then takes further steps, such as configure rules to exfiltrate all incoming emails using a forward rule to an external email address, or send a email to finance department to pay an invoice, and configure a rule to move all replies to such email to another folder to avoid the compromised user to notice this.

Back to Attack Disruption…

So what happens in the last scenario is that the service detects the events which by themselves might not be that bad, but when chained it’s certain that it’s something bad going on and disruption kicks in to stop the attack.

Another example

Attack Disruption is definitely a game-changer. When it detects something bad it will take actions on all assets used by the Threat actor automatically which will happen faster than a human can react and click. The humans are still needed, but this is a great feature the back the human SecOps.

Building Disruption Scenarios

When Microsoft develop new scenarios, they start, as in proactive Threat Hunting, with a hypothesis.

• Research creates hypothesis
• Research validates hypothesis in telemetry
• Detector(s) development for events worth noticing
• Detectors trigger as non-customer facing detections
  (establish 99% confidence)
• Non customer facing alerts are manually investigated
  (establishing 99%  confidence)
• Release alerts to customers
  (not taking action)
• Alerts are released but throttled – Disrupt engages
  (Triggered alerts are manually investigated)
• Alerts are released through release rings
  (Customer grading is monitored)
• Customers with Disrupt incidents are being contacted and interviewed
  (Validating response efficacy)
• Scenario gets released to all customers
• Detector are being reviewed and updated
  (based on new TTPs and customer feedback/ researcher grading)

From correlated signals to disruption

Scenarios and requirements