Enhancing Vulnerability Management with Microsoft Defender for Endpoint (finding the installation path of each software)

In the fast-paced digital world, strong vulnerability management is key to solid cybersecurity. Our goal is to equip organizations with top-notch tools and practices to protect their digital assets. Recently, customers have asked about locating the installation path of their vulnerable software in their setups. Using Microsoft Defender for Endpoint (MDE) and Microsoft Defender for Cloud, we can provide this information.

Installation Path Insights

A crucial part of our vulnerability management is offering detailed insights into software installation paths. Microsoft Defender Vulnerability collects this data, which administrators can access via KQL (Kusto Query Language). For example, KQL queries can efficiently find paths for essential software like Chrome.exe. These queries help create thorough summaries for assessing and managing vulnerabilities.

Unified Data Capture

The insights are derived from data collected across all devices utilizing the existing MDE components implemented by our clients. This integrated method guarantees a consistent and thorough understanding of the software environment, allowing us to detect possible vulnerabilities more efficiently. The collected data is easily accessible for querying, giving our clients the ability to customize their vulnerability management strategies according to their unique requirements.

Defender for Cloud Integration

Besides MDE, all servers using Microsoft Defender for Cloud provide detailed insights in the console. This setup uses the same data and sensors as Defender for Endpoint but presents it in a more user-friendly way, improving clients’ capability to track and manage vulnerabilities across their IT systems.

Conclusion

By leveraging the power of Microsoft Defender for Endpoint and Microsoft Defender for Cloud, we empower our clients to proactively manage vulnerabilities and protect their digital assets.

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

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.

Fastest way to capture and upload the hardware hashes into Intune AutoPilot (Microsoft Device Management #MEM)

We expect the vendors to provide the Windows Autopilot hardware hashes or onboard the devices directly into our tenant. However, that is not usually the case. While the process has improved over the years, there are situation where vendors may not be able to generate the hardware hashes on a timely manner, or not at all. That is why Windows Autopilot device registration can be done within your organization by manually collecting the hardware hashes and uploading this information in a comma-separated-value (CSV) file.

STOP THERE… that process has been updated and improved, making our life much easier. Thank to a newly available option as part of the Windows10 devices, you can manually generate the hashes and automatically upload the hashes to your tenant without the need exporting it into a .CSV file.

During the OOBE (Out of the Box Experience) you also can initiate the hardware hash upload by launching a command prompt (Shift+F10 at the sign in prompt), and using the following commands.

Prerequisite: Your device needs to be connected either a wired or wireless network with internet access.

Powershell.exe 
Install-Script -name Get-WindowsAutopilotInfo -Force
Set-ExecutionPolicy Unrestricted
Get-WindowsAutoPilotInfo -Online

At this point you will be prompted to sign in, an account with the Intune Administrator role is sufficient, and the device hash will then be uploaded automatically. If MFA is enabled, you will be required to use it. (Always make sure to have MFA enabled in all your accounts)

Upon confirmation of the uploaded device hash details, run a sync in the Microsoft Endpoint Manager Admin Center and wait for your new device to appear.

Once the device is shown in your device list, and an autopilot profile is assigned, restarting the device will result in OOBE running through Windows Autopilot provisioning process.