Daily Defender News
Aboutmerill.net
Microsoft Defender Vulnerability Management
Vulnerabilities and exposure

Mitigate the Log4Shell vulnerability with Microsoft Defender Vulnerability Management

4 September 2026Doc update+13 / −11 lines

In brief

The article title and date were updated, Log4j file-detection details were clarified, JNDI mitigation terminology was expanded, and descriptions for advanced hunting queries were added or refined.

What Defender admins need to know

Administrators get clearer guidance for enabling Log4j detection, reviewing mitigation status, and identifying affected software and files. No required action is stated.

Summaries are generated from the documentation change itself.

Documentation change

View full page diffView on Microsoft Learn

The comparison below shows only the changed extract. Use the full-page view for complete context.

Defender Vulnerability Management provides you with the following capabilities to help you identify, monitor, and mitigate your organizational exposure to the Log4Shell vulnerability:

  • Discovery: Detection of exposed devices, both Microsoft Defender for Endpoint onboarded devices and devices that have been discovered but aren't yet onboarded, is based on vulnerable software and vulnerable files detected on disk.
  • Threat awareness: A consolidated view to assess your organizational exposure. This view shows your exposure at the device level and software level. It also provides access to details on vulnerable files. For example, you can see when a file was last seen, last executed, and last executed with open ports. Use this information to prioritize your remediation actions. ItExposed device data can take up to 24 hours for exposed device data to appear on the dashboard.
  • Mitigation options: Apply mitigation options to help lower your exposure risk.
  • Advanced hunting: Use advanced hunting to return details for vulnerable log4j files identified on disk.

Onboarded devices are assessed using built-in capabilities that discover vulnerable software and files.

For devices that are discovered but not yet onboarded, you must enable Log4j detection. This featureLog4j detection sends probes the same way device discovery probes your network. The probes run from onboarded endpoints (Windows 10+ and Windows Server 2019+ devices). They only probe within subnets to find devices that are vulnerable and remotely exposed to CVE-2021-44228.

To enable Log4 detection:

:::image type="content" source="media/enable-log4j.png" alt-text="Screenshot of setting to enable log4j2 detection." lightbox="media/enable-log4j.png":::

Running these probes triggers the standard Log4j flow without causing any harmful impact on either the device being probed or the probing device. The probing itself is done by sending multiple HTTP requests to discovered devices, targeting common web application ports (for example - 80,8000,8080,443,8443) and URLs. The request contains HTTP headers with a JNDI payload. This payload that triggers a DNS request from the probed machine.

For example, User-Agent: ${jndi:dns://192.168.1.3:5353/MDEDiscoveryUser-Agent} where 192.168.1.3 is the IP of the probing machine.

  • Vulnerable files: Both files in memory and files in the file system are assessed. These files can be Log4j-core jar files with a known vulnerable version. They can also be an Uber-JAR that contains a vulnerable JNDI lookup class or a vulnerable log4j-core file. The file detection process performs these checks:

    • Examines JAR files and searches for the file: \META-INF\maven\org.apache.logging.log4j\log4j-core\pom.properties. If this filepom.properties exists, the Log4j version is read and extracted.
    • Looks for the JndiLookup.class file inside the JAR file. It searches for paths that contain the string "/log4j/core/lookup/JndiLookup.class". If this JndiLookup.class file exists, the tool checks whether the JAR contains a Log4j version defined in pom.properties.
    • Searches for vulnerable Log4j-core JAR files inside a nested JAR. It looks for paths that contain any of these strings:
      • lib/log4j-core-
      • WEB-INF/lib/log4j-core-

Log4Shell vulnerability mitigation

Java Naming and Directory Interface (JNDI) lookups are a Log4j feature that attackers can abuse to execute remote code. The log4ShellLog4Shell vulnerability can be mitigated by preventing JNDI lookups on Log4j versions 2.10 - 2.14.1 with default configurations. To create a mitigation action that disables JNDI lookups, from the Threat awareness dashboard:

  1. Select View vulnerability details.

Mitigation status

The mitigation status indicates whether the workaround mitigation to disable JDNIJNDI lookups (described in the previous section) was applied to the device. You can view the mitigation status for each affected device in the Exposed devices tabs. ThisReviewing the mitigation status can help prioritize mitigation and/orand patching of devices based on their mitigation status.devices.

:::image type="content" source="media/mitigation-status.png" alt-text="Screenshot of Possible mitigation statuses." lightbox="media/mitigation-status.png":::

Use advanced hunting

Advanced hunting queries for Log4Shell

Advanced hunting lets you query for Log4j issues across your devices. Use the examples below to get started.

ThisThe following query findsidentifies devices with vulnerable software:software affected by the Log4j CVEs (CVE-2021-44228 and CVE-2021-45046):

   DeviceTvmSoftwareVulnerabilities
   | where CveId in ("CVE-2021-44228", "CVE-2021-45046")

ThisThe following query shows file-level results from disk:searches software evidence and disk paths to find Log4j-related files on each device:

   DeviceTvmSoftwareEvidenceBeta