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.

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.

In part one I focused mostly on detecting offensive security tools like AzureHound, GraphRunner, and PurpleKnight. In part two I will go into more depth how you can use the now available information for hunting and how to correlate it with other datasets to gain deeper insights. Correlate Graph activities with other log sources While the MicrosoftGraphActivityLogs alone is a trove of information, correlating it with other logs makes it an even more interesting data source.

When working with Microsoft Entra there are many log sources you can use to detect usage and changes to the environment and the assets within it. Most of them can be forwarded using the diagnostic settings to different targets for better analysis capabilities or long term storage. In many cases a Microsoft Sentinel or Log Analytics workspace is the target of choice, but also other SIEM solutions can benefit from this stream of log data.

The challenge Most of us analyzing Azure AD SignIn logs have been there. You come across a failed sign-in, but the ResultDescription is not really helpful, but only shows “Other”. Other? But what other? When using the Entra ID portal UI most of those error codes will perfectly translate to a more helpful error message. What the sign-in logs cannot do, the portal UI is able to So how can you have the same experience when using KQL?

When working with Defender for Cloud and Microsoft Sentinel the two product greatly integrate into each other. If integration is enabled each Defender for Cloud alert will generate an Sentinel incidents which contains the entities, description, the title and more information of the DfC alert. Also there is a direct link to the alert and if bi-directional alert synchronization is enabled it keeps the alerts, you guessed it, in sync.

…or SCRIL in a hybrid environment. What could possibly go wrong? Way before the term “passwordless” was used by Microsoft to promote the use of alternative authentication methods besides a password there already was a way to go passwordless. In Active Directory there is a feature called SCRIL to achieve exactly this. SCRIL which is short for “Smart card is required for interactive logon” is an effective way to prevent any interactive sign-in to a domain joined machine using a password for the user that holds this attribute.

When you work with one or multiple Microsoft Sentinel workspaces you may find it necessary to not only deploy Analytics rules and other configuration artifacts using a version controlled source control (CI/CD) to limit human error and enforce consistency. But you might also want to independently verify your deployment on a regular basis. I certainly did and set out to write a test driven solution. Since I love to use PowerShell and there is already a superb test framework, the tool to use for the task at hand was an easy choice: Pester.