Since Microsoft Defender for Endpoint is a suite of products, rather than just one single piece of software, there are various places where you can create exclusions for different features. Also, there are integrations in other products, that result in possible side effects when enabling certain settings.

Most of these products have separate documentations, there is no single documentation page that contains all the information about exclusions available in Microsoft Defender for Endpoint. Until now!

Creating and maintaining a secure environment is hard. And with every technology or product added to your environment it gets more complicated. Microsoft Azure as a cloud environment is no exception to this rule and with the many services and features that get added every year it just gets more complicated even if you did not change a thing. Because keeping your IT assets secure is important as you move to the cloud, it is important to know which bad practices to avoid and which attack scenarios are out there.

When Nathan and I released XDRInternals one of the biggest shortcomings for me was the lack of workload identity support. Since we are using the native API of the Defender portal only delegated permissions are supported, which makes it very hard to automate things in a pipeline.

But the fact that it makes it very hard should not prevent you from doing it. Security considerations and common sense are the reasons you should not do it, but let’s throw them overboard for the fun of it.

In Microsoft Entra, Conditional Access is, after the Authentication itself, the most crucial part of defense against attackers. It’s referenced as “zero trust policy engine” and the idea behind is, that in addition to your username and password you can also enforce additional requirements when you access a specific resource.

This could be any combination of

• a second factor (2FA),
• a specific authentication method (e.g. passkey)
• a device that is in a “compliant” state
• a trusted or compliant network

and a lot more, depending on your specific use case.

This blog post is a sleeper. I documented it in 2023 and never came around to publish it. The post was always too short in my opinion, too niche. But today Jonathan Bourke reached out on Twitter and asked why he was getting this strange error message when trying to connect a new Sentinel workspace to his XDR instance.

For a long time now, defenders had the ability to monitor behavior of human- and workload identities in Entra tenants not only through AuditLogs but with high level of insight with the MicrosoftGraphActivityLogs logs. The last two articles of this series gave you detection ideas and hunting queries for this logs source and were meant as a kick starter for detection engineers. But in the end the high cost of this log prevented many companies from putting it into operation. This is about to change with the release of GraphAPIAuditEvents logs in the XDR portal.

Ho, ho, ho… In Germany on the 6th of December we celebrate “Nikolaus”. Kids put out one shoe the night before in the hopes that, in the morning, it is filled with nuts, mandarin oranges, chocolate or even small gifts. Lucky for you, it seems that you also put out your shoe last night, because I have a gift for you as well. But please don’t confuse me with Nikolaus ;)

For red teams and adversary alike it’s important to stay hidden. As many companies nowadays have EDR agents deployed those agents are always in focus and tools like EDRSilencer or EDRSandblast use different techniques to prevent further communications of the EDR agent with the log ingestion endpoint.

A few weeks ago Mehmet Ergene and I were discussing other ways to prevent agent communications and ways to detect such tampering. The idea for a a two part blog post was born. While I cover only one “novel” way to block EDR Mehmet has released part 2 which covers other angels.