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.

While working on another blog post I looked at different lateral movement paths an attacker can use, when she has compromised the Entra ID (Azure AD) Connect server. Since this is the gateway to the cloud environment there already is quite some research available. When reading the existent posts about this topic, the main lateral movement path mentioned is a password reset to take over a privileged account synced to the cloud.

If you have worked with Microsoft Sentinel you will, at one point, stumbled over two different file formats for Analytics Rules: YAML and ARM. The YAML format is mostly used to distribute Analytics Rules between people. All Analytics Rules you will find in the official Sentinel GitHub repo and others out there are offered in this format. The ARM format is what you need to deploy the Analytics Rules when using a pipeline or even if you want to import them using the UI in Microsoft Sentinel.

Business email compromise and phishing are just two of the threats sent to hundreds and thousands of email inboxes around the world every day. As defenders, we use various tools and methods to limit the delivery of these emails to the intended target. In most cases, the attackers start by registering a domain that closely resembles the target company’s own domain name, or simply include the company name in the domain (e.