“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.
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.
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.
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.
MDI alerts have a number of different learning periods, and each is well documented. However, there is not a single list of all the alerts that have learning periods for easy reference, so I have created and will update this list.
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.