technology

Microsoft Defender for Endpoint (MDE) Platform-Specific Antivirus Engines and Unified Security Intelligence Versioning

Carlos A Lopez (Twitter: @CLopezDC) Office365 , , , ,

Microsoft Defender, the enterprise-grade antivirus and endpoint protection solution, is designed to operate seamlessly across multiple platforms including Windows, Linux, macOS, Android, and iOS. To ensure optimal performance and threat detection, Microsoft employs platform-specific engines and a unified versioning system for Security Intelligence Updates. This blog explores these two critical aspects in detail.

Platform-Specific Antivirus Engines

Each operating system has unique characteristics, system calls, file structures, and threat vectors. To address these differences, Microsoft Defender uses platform-specific antivirus engines tailored to the environment in which they operate:

Windows

  • Engine: Uses the full-featured Microsoft Defender Antivirus engine.
  • Integration: Deeply integrated with the Windows OS, leveraging features like AMSI (Antimalware Scan Interface), Windows Security Center, and Kernel-mode scanning.
  • Update Mechanism: Utilizes Windows Update and Microsoft Update services for seamless delivery of engine and definition updates.

Linux

  • Engine: A lightweight, command-line based engine optimized for server environments.
  • Integration: Designed to work with Linux file systems and daemon processes.
  • Update Mechanism: Uses Microsoft’s Linux software repositories and package managers like apt or yum for updates.

macOS

  • Engine: Tailored to macOS architecture with support for real-time protection and on-demand scanning.
  • Integration: Works with Apple’s system extensions and endpoint security framework.
  • Update Mechanism: Updates are delivered via Microsoft AutoUpdate (MAU).

Android

  • Engine: Focuses on app scanning, web protection, and device compliance.
  • Integration: Integrates with Microsoft Intune and Google Play Protect.
  • Update Mechanism: Updates are pushed through the Google Play Store and Microsoft Endpoint Manager.

iOS

  • Engine: Designed to provide app protection, phishing protection, and compliance checks.
  • Integration: Works with Microsoft Intune and leverages Apple’s Mobile Device Management (MDM) framework.
  • Update Mechanism: Updates are managed via the App Store and Microsoft Endpoint Manager.

Unified Security Intelligence Versioning Across Platforms

Despite the differences in engines and update mechanisms, Microsoft Defender employs a unified versioning system for its Security Intelligence Updates. This system ensures consistency and simplifies management across diverse environments.

Key Features of Unified Versioning

  • Consistent Version Numbers: All platforms share the same version number format (e.g., 1.405.1234.0).
  • Tailored Content: While the version number is consistent, the actual update content is customized per platform. For example, a definition update on Windows may include AMSI-specific signatures, while the Linux version may focus on file-based threats.
  • Simplified Management: IT administrators can track and verify update deployment across all endpoints using a single versioning scheme.

Benefits

  • Cross-Platform Visibility: Unified versioning enables centralized monitoring and reporting.
  • Operational Efficiency: Reduces complexity in update validation and compliance.
  • Improved Security Posture: Ensures all devices are protected with the latest threat intelligence.

Additional Resources

For more detailed information on Microsoft Defender Security Intelligence Updates and platform-specific release notes, refer to the official documentation:

By leveraging platform-specific engines and a unified versioning system, Microsoft Defender ensures robust, consistent, and efficient protection across all major operating systems.

Protecting Windows Endpoints from Kernel-Level Threats: The Power of ASR’s Vulnerable Driver Block Rule

Carlos A Lopez (Twitter: @CLopezDC) Office365 , , , ,

When it comes to cybersecurity, the kernel is sacred ground. Once compromised, it offers attackers the keys to the kingdom. That’s why Microsoft Defender for Endpoint’s Attack Surface Reduction (ASR) rules are critical in hardening enterprise environments.

Today, I am spotlighting one very important but sometimes overlooked ASR rules:

Block abuse of exploited vulnerable signed drivers

Intune Name: Block abuse of exploited vulnerable signed drivers

GUID: 56a863a9-875e-4185-98a7-b882c64b5ce5)

Advanced hunting action type:

  • AsrVulnerableSignedDriverAudited
  • AsrVulnerableSignedDriverBlocked

Why This Rule Matters

In recent years, attackers have shifted to exploiting legitimately signed but vulnerable drivers to gain kernel-level access. These drivers are often trusted by the OS due to their signature status, yet harbor security flaws that can be used to:

  • Disable security tools like EDR or antivirus,
  • Inject malicious code into kernel memory,
  • Persist undetected across reboots.

Once attackers load a vulnerable driver, they can effectively operate at ring 0, where traditional defenses struggle to respond.

The ASR rule prevents applications from writing such vulnerable drivers to disk. Blocking one of the most effective paths to escalation.

How Microsoft Identifies Vulnerable Drivers

Microsoft maintains a curated list of vulnerable drivers, largely informed by:

  • CVE disclosures (Primarily)
  • Partner and customer telemetry
  • Internal security research

When a driver is confirmed to be vulnerable, its signature or hash is added to the blocklist. This ensures that any attempt to introduce it into the environment is proactively stopped.

New vs. Existing Drivers: What You Need to Know

An important nuance:

  • This ASR rule only blocks NEW vulnerable drivers from being written to disk.
  • Existing vulnerable drivers already loaded in teh devices will not be impacted by the rule unless they are modified or reinstalled.

This approach is by design and it avoids disrupting legacy systems while still raising the bar on future risk. Vulnerable drivers already in the system will be detected by Microsoft Defender Threat and Vulnerability Management MDTVM

What Happens During a BIOS or Driver Update with a vulnerable driver?

Here’s a common scenario:

  • You push a BIOS update across your fleet.
  • The update includes a vulnerable driver.
  • The ASR rule kicks in and blocks the driver from executing.

At this point, your team has two options:

  1. Evaluate and accept the risk by adding an exclusion for the driver (not recommended unless absolutely necessary),
  2. Reach out to the vendor for a new, patched version of the driver.

The ASR rule is working exactly as intended here—protecting your environment from known kernel-level exploits.

Visibility Through Advanced Hunting

To monitor ASR rule activity related to this feature, use these action types in Microsoft 365 Defender’s Advanced Hunting:

  • AsrVulnerableSignedDriverAudited
  • AsrVulnerableSignedDriverBlocked

These events provide insight into attempted driver installs, blocked actions, and any exclusions in place.

Best Practices for Deployment

  • Start in audit mode to evaluate potential impact in your environment.
  • Monitor activity via Defender advanced hunting.
  • Gradually shift to block mode once you’ve validated that critical business apps are not affected.
  • Educate device management teams about potential driver update issues and escalation paths.

Final Thoughts

ASR’s “Block abuse of exploited vulnerable signed drivers” rule is a proactive, targeted defense against a stealthy and growing threat vector. It’s a perfect example of security-by-default, letting organizations reap the benefits of Microsoft’s threat intelligence without needing to build and maintain their own vulnerable driver databases.

Implement it. Monitor it. And rest easier knowing that one more kernel exploit vector just got locked down.

Managing Duplicate Device Objects in Microsoft Defender for Endpoint (MDE)

Carlos A Lopez (Twitter: @CLopezDC) Office365 , , , ,

When working with Microsoft Defender for Endpoint (MDE), it’s important to understand how certain actions can create duplicate device objects, which can clutter device inventory and hinder management efforts. This issue arises because MDE retains old device entries for 180 days, even when new entries for the same device are created due to changes in its configuration.

Here are the key scenarios where duplicate device entries can occur:

Scenarios That Lead to New Device Entries:

  1. Renaming a Device: Changing the name of a machine will result in a new entry being created in MDE while retaining the old entry.
  2. Workgroup Rename/Change/Join: If a machine moves from one workgroup to another, or is joined to a different workgroup, a new entry will appear.
  3. Domain Join: Joining a domain will trigger the creation of a new device entry.
  4. Changing Primary DNS Suffix: Modifying the DNS suffix also results in a new entry.

Recommendations for Autopilot Machines:

To avoid duplicate entries, it’s critical to reconsider the AutoPilot process for hybrid machines. Specifically, machines should be onboarded to MDE only after they have been renamed and assigned to the end-user. This ensures that the correct name and configuration are reflected in MDE from the start, preventing unnecessary duplicate device objects.

Recommendations for VDI Infrastructure:

In the case of VDI environments, handling duplicates requires different strategies depending on whether your VDI setup is non-persistent or persistent.

  • Non-Persistent VDI: For non-persistent VDIs, it’s essential that the organization follows the appropriate process to include the necessary scripts to prevent new device entries from being created each time a session spins up. Automation can be key here in minimizing duplicates as explain the Microsoft Docs
  • Persistent VDI: Persistent VDIs should be treated like regular machines. Onboarding to MDE should follow the same process as autopilot machines or any other workstation—ensuring they are renamed and assigned before being onboarded. This approach will prevent unnecessary duplicate entries.

Actions That Won’t Create Duplicate Device Entries:

Not all changes result in the creation of a new device object. The following actions are not expected to trigger new entries:

  • Updating the OS version (e.g., upgrading from Windows 10 version 20H1 to 21H2)
  • In-place upgrades (From Win10 to Win11)
  • Updating to the unified agent on older systems like Windows Server 2012r2 or 2016
  • Rolling back updates
  • Offboarding and re-onboarding a device within the 180-day retention period
  • Work or school account logins
  • MAC address changes
  • Restoring devices from snapshots

Conclusion:

By understanding the scenarios that cause duplicate device objects in Microsoft Defender for Endpoint, IT teams can optimize onboarding processes for autopilot and VDI environments. Taking the right steps to ensure machines are properly renamed, assigned, and onboarded after configuration changes will significantly reduce the clutter of duplicate device entries and improve overall device management within MDE.