I have intentionally and reluctantly avoided this topic for a while, but enough customer experience has occurred, and I feel the benefits are balanced with or outweigh the negatives. So, over the last week I wrote and have made available My-MdeMigration a PowerShell Module to help with MDE Migrations.

MDE Offline update provides the ability for organizations to locally source MDE Security Intelligence Updates rather than using the provided Microsoft SIU service. Considering the repeat scripting and static file web server requirements it seemed that this could conventiently be addressed by containerization.

Customers frequently ask about moving Defender policies between various environment. This generally requires manual efforts of replicating settings from one portal to another. However, this manual process is painful and error prone which makes the migration less that optimal.

Instead, a better way is to export the policy and push it to the other environment, but without portal capabilities how can this be accomplished. Enter the Device Configuration v2 API.

“By failing to prepare, you are preparing to fail” -Benjamin Franklin

Recently I’ve been working with several customers on migrations from a third party EPP-EDR to Microsoft Defender for Servers (MDfS), and have found there is an important pattern that should be followed to predict, control, and minimize performance and business impacts during the migration. While Arc may perform the onboarding for your organization, other factors like change management and maintenance windows may require additional steps or procedures to limit & control what and when Arc performs actions.

Recently the MDE Attach capability was updated to include managing the MDE service on Linux, and MacOS, to provide a similar experience for configuring and managing the MDE service on these non-windows platforms. There are several questions that this new capability raises which I will attempt to address in this post.

Previsouly, I wrote about QR Phishing and the many challenges it poses to current cyber awareness training, and defensive tools. As this is a growing trend it is important for companies to incorporate this type of phishing method into existing cyber training and awareness. Specifically, this post will detail how to use Microsoft Defender for Office to generate a QR Phishing campaign.

Earlier this year some news outlets began to report about increased Phishing that utilized QR codes. This had been discussed as a new threat vector when the COVID pandemic moved restaurants, cafes, and other locations to replace physical menus with digital menus that could be easily accessed from a QR code sticker on your table. Recently, around August/September, more new stories, reports, and industry data have indicated that QR Phishing is becoming more prevalent.

For the last 2-3 years I’ve been working with customers on migrating to Defender for Endpoint from other AV/FW/EDR solutions. One of the big issues I’ve seen is there are a lot of checks to see what could prevent Defender from successfully onboarding. In order to make these checks more consistent and faster I decided to create a script to help identify and flag potential migration issues.

Recently I had a customer ask about an Advanced Hunting Query that could detect the Microsoft Screen Clipping vulnerability CVE-2023-28303. Some initial testing of the Threat and Vulnerability Management in Advanced Hunting tables this software is not being captured on my test machines. However, there are still some ways we can detect the potential of this vulnerability.

Recently an issue was raised that a customer had configured their Defender AV policies and then applied Tamper Protection. When they checked the local machine’s settings they realized that some values in Defender AV were not consistent with their AV Policy which was unexpected. What was found is an undocumented/vaguely documented action by Tamper Protection.

I’ve seen a lot of asks from customer about how they can use Azure AD Groups with MDE Device Groups. Unfortunately, there isn’t a direct way to use Azure AD groups with the MDE Device groups, but there is an approach that provides a similar capability.

I’ve decided to really document and push my Azure Labs so anyone can easily deploy environments for use with testing and learning the various Microsoft Defender products. This labs have been available for a while, but I’ve now committed some time to documenting and incorporating that information as part of this site.

MDE for Linux has serveral articles about using common deployment tools, but recently I was asked about using SaltStack which was a tool I’m not familiar with and that lacks/lacked official documentation.

In the previous post about ASR adoption, I recommended you enable ALL ASR rules in AUDIT mode. Now we will use the Security Baseline to build an ASR policy that should be minimally impactful to your systems and end users.

This post is intended as a starting point for organizations looking to adopt Attack Surface Reduction (ASR) rules. ASR rules can help improve an organization’s security, but they can potentially disrupt normal user and application behaviors in certain environments. My recommendation to anyone looking to implement ASR rules is to always start with Auditing.

This is the second post on switching to Defender Anti-Virus and using the Security Baselines published in Endpoint Manager to create a good starting point for your Defender AV settings. This post will focus on the settings in the Security Baseline for Windows 10 and later and how to create an AV only policy based on these settings.

When switching from one AV to another organizations want to know if they can keep their current AV settings, or if their AV Vendor has recommendations for better adoption, detection, and performance. For these types of conversations with Microsoft Defender AV I often recommend customers look at the Security Baseline rules as a good starting point.

The secuity portal comes with several nice vulnerability reports for customers to review that show a summary of the risks in their environment. However, some customers find that these reports are too general, so while they show summary data they cannot distribute these to system owners who could then go an patch their systems.

Working with a customer on the MDE Unified Installer for Windows Server 2016/2012R2 we ran into the issue that SCEP was installed and thus blocking the Unified Installer. Therefore, instead of the Install approach we really needed to perform an Upgrade, but would that mean we needed an approach for servers where SCEP had been installed vs. servers where SCEP was not installed? Answer: No!

Recently Microsoft announced the public preview of a unified EPP and EDR package that allows a similar onboarding approach for these servers as Server 2019, Windows 10, and Windows 11. Recently, a customer I support wanted to test this new method and perform deployment using the GPO methodology.

Many organizations want to delegate enabling and disabling MFA for a user to their helpdesk, but the only RBAC role that allows MFA management is the Global Administrator and no one wants to grant helpdesk technicians Global Admin access to their tenant. However, there is a way around this RBAC limitation if your organization has Azure AD Premium.

As a Technical Solutions Professional at Microsoft who covers Identity and Security I get a lot of questions about Office 365 MFA vs. Azure Active Directory MFA around the differences, benefits, and what I suggest. Customers always assume because I concentrate on the EMS stack Microsoft offers (Intune, Azure AD, Azure Information Protection) I recommend Azure AD MFA over Office 365 MFA, but the reality is when customers really compare the experiences they will almost always go with Azure AD MFA.

Duo Labs announced on Feb 27th that it had discovered a security vulnerability in some SAML SSO providers. The outline of their public post showed how an attacker could authenticate so a SAML SSO provider, and then manipulate the SAML response to allow them to impersonate a user based thanks to different canonicalization algorithms.