rss.livelink.threads-in-node

Microsoft Defender false positive and WDSI submission details page bug

MykolaHaponiuk — Thu, 25 Jun 2026 02:56:05 GMT

Hello,

I am the developer and publisher of Pulse Launcher, a legitimate signed Windows application / Minecraft mod launcher.

I already submitted this through Microsoft Security Intelligence and also opened a Microsoft Q&A thread, but I am posting here because the WDSI submission portal itself appears to be broken for these submissions.

Related Microsoft Q&A thread:

https://learn.microsoft.com/en-us/answers/questions/5929545/microsoft-defender-false-positive-and-wdsi-submiss

There are two related issues:

1. Microsoft Defender cloud ML false positives keep appearing on public multi-engine scan results for the same signed application/product family. The Microsoft detection name changes across rescans and equivalent builds, including:

- PUA:Win32/Puwaders.C!ml

- Program:Win32/Wacapew.C!ml

- Trojan:Win32/Wacatac.B!ml

- Trojan:Win32/Wacatac.C!ml

- Trojan:Win32/Sabsik.EN.A!ml

2. Microsoft Security Intelligence submissions are visible in Submission history and show status "In progress", but opening the submission details page returns:

"The details for the submission were not found or the submission has expired."

Affected submission IDs:

- dd476efa-fc04-4f13-82cf-631bbfd145a6

- efc6514c-d700-4d6a-a7e2-67a9a83334a2

- ff8d04b7-c5fc-4a05-bd53-ee7ac5981284

File details:

- File name: pulse_launcher.exe

- SHA-256: def6059c07c3e1f4a8c5649a1bbf190d4f355ee8e8b88c55c5b404edee99ecc8

- Signer: FOP Haponiuk Mykola Viktorovych

- Certificate: GlobalSign EV Code Signing certificate

The executable is not VMProtect-packed or obfuscated. It is EV-signed. A previous Microsoft analyst response stated that the file did not meet Microsoft criteria for malware or PUA, but Microsoft cloud detections continue to appear.

Could someone route this to Microsoft Defender Security Intelligence / malware analysis, or advise how to escalate WDSI submissions that exist in history but whose details endpoint returns "not found or expired"?

Thank you.

Microsoft Defender for Endpoint and WDAC audit logs not include kernel audit/blocks

Warren212 — Fri, 12 Jun 2026 13:35:02 GMT

While testing WDAC on a fully patched Win11 pro machine - I noticed that kernel audit/block events do not get collected by MDE in the advanced hunting portal, only user mode audit/blocks are collected. Can anyone confirm they see this too and is this by design?

My test case is to use a Strict Kernel Mode WDAC policy (as per:

https://github.com/HotCakeX/Harden-Windows-Security/wiki/WDAC-policy-for-BYOVD-Kernel-mode-only-protection) which is active, using the global secure access client as my test, when the machine boots, the below event is generated locally on the machine:

This event is never shown on the MDE advanced hunting portal, though user events do show. Examples of events that are coming through:

Not receiving these events centrally for auditing would make deploying a kernel mode wdac control impossible. Would be amazing if Microsoft product team could look into this and resolve as these alerts should be captured as well please to facilitate deployment of more secure controls.

Reduce unnecessary internet exposure with Microsoft Defender

hadarshindler — Thu, 11 Jun 2026 16:00:00 GMT

In today’s threat landscape, internet exposure, i.e. devices that allow inbound connectivity from the public internet, continues to be a major vector for initial access and compromise. Devices that are exposed to the public internet can significantly increase an organization’s attack surface, making them prime targets for initial access, exploitation, and lateral movement.

However, not all internet-facing devices represent a security issue. Many are intentionally exposed to support business-critical scenarios such as hosting web applications, enabling remote access, or supporting communication services. The challenge for security teams is not just detecting internet-facing devices, but understanding why a device is exposed, whether that exposure is expected, and what action should be taken. That’s why we’re introducing a new security recommendation in Microsoft Defender that helps organizations identify, review, and reduce unnecessary internet exposure across their environment.

Understand your internet-facing exposure

This recommendation focuses specifically on devices that are accessible from the public internet, meaning they can receive inbound connections initiated from external sources, not devices that only use the internet for outbound communication.

Externally reachable assets are often the first point of entry for attackers, making this a critical signal for security prioritization.

Microsoft Defender identifies internet-facing devices based on signals that indicate external inbound reachability, including:

External scan telemetry identifying devices reachable from the public internet
Network telemetry showing inbound connections from external sources

By correlating these signals, Defender surfaces devices that are externally reachable.

Introducing internet-facing exposure assessment

A new recommendation in Microsoft Defender provides a centralized view of devices that are externally reachable from the public internet, helping you understand and manage exposure across your environment.

This assessment categorizes devices based on their exposure state:

Exposed devices: Devices that are reachable from the public internet and require review
Compliant devices: Devices that are not externally reachable, or where the internet exposure has been explicitly validated and accepted by the organization’s security team as intended
Not applicable devices: Devices that do not exhibit inbound internet exposure

From the recommendation view, you can:

Drill down into exposed devices and understand why they are reachable
Review context such as exposed services and connectivity
Explore device-level details to support investigation
Track exposure posture across your environment over time

Take action on your internet exposure

To access this recommendation in the Defender portal, navigate to Exposure management → Recommendations → Devices → Misconfigurations. Once Defender identifies internet-facing devices, it provides the context needed to review and take action.

Your action plan

1. Assess your exposure
Review the recommendation to understand which devices in your environment are externally reachable from the public internet and why they were classified as internet-facing.

2. Validate whether exposure is required
Determine if the inbound connectivity is expected for each device. Confirm business need and ownership before taking action.

3. Prioritize high-risk assets
Focus on critical servers or sensitive environments that are exposed to the internet, as they present the highest risk for initial access.

4. Reduce unnecessary exposure
Restrict or remove inbound connectivity where it is not required by closing exposed ports, removing public access, or moving services behind controlled access layers.

5. Track and maintain posture over time
Continuously monitor internet-facing devices to ensure unnecessary exposure is reduced and new exposure is validated as environments evolve.

FAQ

1. Which devices are currently supported?

This recommendation applies to supported Windows client and Windows Server devices. Supported versions include Windows 10, version 1607 and earlier; Windows 10, version 1809 and later; and Windows 11.

2. Why might there be differences between this recommendation and the Internet-facing filter in device inventory?

This recommendation reflects devices observed as internet-facing during the recommendation assessment window. Device exposure can change over time, and different Microsoft Defender experiences may refresh at different times.

As a result, temporary differences may occur between this recommendation and the Internet-facing filter in device inventory.

For the most current device-level view, use the Internet-facing filter in device inventory. If a device was recently remediated or its exposure recently changed, allow time for the recommendation status to refresh.

3. Could regular employee laptops or personal devices appear as internet-facing?

This recommendation evaluates supported devices onboarded to Microsoft Defender for Endpoint and focuses specifically on inbound internet reachability.

Typical internet usage, such as web browsing, generates outbound traffic and does not by itself classify a device as internet-facing.

Devices are identified as internet-facing only when they are externally reachable from the public internet.

As a result:

- Personal devices that are not onboarded to Microsoft Defender for Endpoint are not included in this assessment.
- Corporate laptops may appear as internet-facing if they are directly reachable from the internet, which may indicate an unintended network exposure or configuration issue.

Learn more

For additional guidance on investigating and managing internet-facing devices, see:

Learn how Defender identifies and maps externally reachable devices across your environment Discovering internet-facing devices using Microsoft Defender
Learn how to review and investigate internet-facing device exposure Investigate devices in Microsoft Defender
Learn more about Microsoft Secure Score for Devices in Microsoft Defender
To learn more about endpoint protection with Microsoft Defender, check out our website.
To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

Introducing scheduled antivirus scans on Microsoft Defender Linux

Rutuja_dange — Wed, 10 Jun 2026 16:00:00 GMT

Security teams rely on scheduled scans to ensure consistent coverage across devices, detect dormant or missed threats, and meet compliance requirements. However, managing scans on Linux has traditionally required custom scripts and cron-based setups, which can be hard to scale and maintain. That’s why we’re excited to introduce centrally managed scheduled antivirus scans for Linux in Microsoft Defender, now available in public preview. With this release, we are bringing built-in, flexible scheduling capabilities directly into Defender - making it easier to manage and standardize scan behaviour across Linux environments.

What’s new

With this capability, customers can now configure scheduled antivirus scans on Linux using security settings management policies in the Microsoft Defender portal for centralized policy enforcement or local Managed JSON configuration that can be deployed via configuration management tools like ansible, puppet and chef.

The feature supports a flexible set of scheduling options, including hourly quick scans (interval-based scheduling), daily quick scans at a defined time, and weekly scans with configurable scan type (quick or full). In addition, customers can control how scans run with advanced options such as:

Running scans only when the device is idle
Reducing CPU impact using low CPU priority
Checking for definition updates before scanning
Randomizing scans start times
Ignoring exclusions during scheduled scans

These capabilities allow security teams to balance coverage, performance, and operational needs across large Linux environments.

Why this matters

From a security perspective, scheduled scans play a critical role in detecting dormant threats, missed detections, and malicious artifacts that may not be caught through real-time protection alone. Without consistent and centrally enforced scheduling, these gaps can increase risk across the environment.

With this release, scheduled scans are now:

Centrally managed through Defender policies
Consistently enforced across devices
Aligned with security best practices for regular scanning
Integrated into the broader Defender security posture

This helps organizations strengthen their overall security posture while reducing operational complexity.

Get started

To get started, ensure devices are running agent version 101.26032.0000 or later (production ring), and configure scheduled scans using managed JSON or Defender portal policies.

Learn more

Learn more about how to schedule antivirus scans on Linux

To learn more about endpoint protection with Microsoft Defender, check out our website.
To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

Elevate your telemetry using custom data collection in Microsoft Defender

Theo_Cohen — Tue, 09 Jun 2026 16:00:00 GMT

At Ignite in November, we announced that Microsoft Defender is now the only endpoint protection solution that allows data-hungry security teams to meet specific telemetry needs by optimizing their data collection right within the Defender portal, without the need to rely on fragmented and siloed solutions. Since then, we've heard from customers that this tool has been a game changer, enabling them to hunt through new data types as well as richer data on events already reported. The release of custom data collection was a key milestone in our ongoing journey to make Defender easy to manage and customize.

Security teams have been asking for guidance and examples of how to get the most out of the tool, so today we're sharing how some organizations can use custom data collection and dynamic tagging to detect command and control (C2) communications, giving defenders elevated visibility and deeper telemetry into attacker activity across the environment.

See the data you want to see

Defender's default telemetry is tuned to balance performance and signal-to-noise across millions of devices, so it focuses on the events most useful for high-fidelity detection at fleet scale, but many organizations want richer, more granular signals for deeper hunting, compliance, or auditing purposes. Custom data collection lets you go beyond what Defender already captures without ever leaving the Defender portal. Easily build custom collection rules based on your organization’s specific needs using natural language; no PhD required! It includes several highly requested data types, including AMSI for hunting over script content, and Kerberos for hunting auth-based and network attacks.

This truly integrated custom data offering is possible thanks to Microsoft’s platform approach, as the additional telemetry can be collected and analyzed via Defender and stored via Microsoft Sentinel. It puts you in complete control of any customized, add-on data, including exactly which data types are collected and how long they are stored. No other security solution has fully integrated and customizable telemetry collection and analysis.

Example custom telemetry scenario: detecting C2 communications

Many organizations have a set of assets that require special attention, like internet-facing servers, domain controllers, and other high-value endpoints where deeper telemetry can make the difference between catching an intrusion early and discovering it after the damage is done.

Imagine your organization has received threat intelligence on attacks using stealthy C2 frameworks: HTTPS beacons with jittered intervals, DNS-based data exchange, and persistence via scheduled tasks and registry modifications. You want richer visibility into those internet-facing servers and high-value endpoints so you can hunt for these patterns proactively, instead of reconstructing them after the fact.

Dynamic tags scope these high-value devices into a targeted group, and custom data collection captures the extra process, network, and registry events from them, giving analysts the telemetry they need to hunt for beaconing, suspicious DNS patterns, and persistence before attackers establish a foothold.

To detect C2 communications using dynamic tagging, follow these steps:

Step 1: Tag your devices

Custom Data Collection rules are scoped to dynamic tags; once set, those tags are automatically applied and removed based on conditions you define. Configure them in Settings > Microsoft Defender XDR > Asset Rule Management.

Tag	Rule name	Conditions	Tag to apply
Internet-facing servers	InternetFacing-Servers	Internet facing = true AND OS platform equals Windows Server 2022	C2-Watchlist
Devices under active investigation	HighSev-Investigation	Manual tag equals UnderInvestigation	HighSev-Verbose

Bringing manual tags into the dynamic model

Custom data collection is built around dynamic tags by design: one leading, unified tagging experience that's more flexible and customizable. Dynamic tags can be driven by device properties, group membership, OS, or by existing manual tags, so anything your team already tags manually flows naturally into custom data collection through a simple Asset Rule Management rule, exactly as Tag 2 above does.

In this example, analysts manually tag a device UnderInvestigation during incident response. The dynamic rule picks up that manual tag and applies HighSev-Verbose, which custom data collection rules can target. The analyst doesn't need to know about dynamic tags they tag the device the way they always have, and custom data collection activates automatically.

Step 2: Build your collection rules

Navigate to Settings > Endpoints > Rules > Custom Data Collection. Select your Microsoft Sentinel workspace in the top-right corner.

Before creating rules, confirm you meet every prerequisite in the custom data collection documentation , in particular, your tenant must be onboarded to the Unified Security Operations Platform (USOP).

Rule 1: Outbound network connections from high-risk processes

Capture connections from processes commonly abused by C2 frameworks living-off-the-land binaries and scripting engines.

Setting	Value
Rule name	C2-OutboundConnections
Table	DeviceCustomNetworkEvents
Action	Connection Success
Condition	InitiatingProcessFileName Equals: powershell.exe, rundll32.exe, regsvr32.exe, mshta.exe, certutil.exe, msiexec.exe
Scope	Devices tagged C2-Watchlist

Rule 2: DNS query activity

Many C2 frameworks use DNS for beaconing or data exchange. Default telemetry captures limited DNS data. This rule collects all DNS queries from monitored devices.

Setting	Value
Rule name	C2-DNSActivity
Table	DeviceCustomNetworkEvents
Action	Connection Success
Condition	RemotePort equals 53
Scope	Devices tagged C2-Watchlist

Rule 3: Persistence mechanisms

C2 implants establish persistence via scheduled tasks, registry run keys, or services. Capture process creation events for common persistence tools.

Setting	Value
Rule name	C2-Persistence
Table	DeviceCustomProcessEvents
Action	Process Created
Condition	FileName in (schtasks.exe, reg.exe, sc.exe, at.exe)
Scope	Devices tagged C2-Watchlist

Rule 4: Full process and script telemetry during investigations

When a device gets the HighSev-Verbose tag, collect everything.

Setting	Value
Rule name	HighSev-AllProcesses
Table	DeviceCustomProcessEvents
Action	Process Created
Condition	Broad (all process creation events)
Scope	Devices tagged HighSev-Verbose

Setting	Value
Rule name	HighSev-ScriptCapture
Table	DeviceCustomScriptEvents
Action	Script execution
Condition	Broad (all script events) – add a condition which is always true such as FileName not equals “”
Scope	Devices tagged HighSev-Verbose

Collection profiles summary

Tag	Rules active	What gets collected	Use case
C2-Watch list	OutboundConnections, DNSActivity, Persistence	Network connections from, DNS queries, persistence tool usage, DLL sideloading	Persistent C2 monitoring
HighSev-Verbose	AllProcesses, ScriptCapture	Every process creation, all script execution	Full-depth incident response

Important: when you remove the HighSev-Verbose tag after closing an incident, collection automatically drops back to baseline, no manual rule cleanup needed. This is what makes verbose collection safe to leave configured: it's only active while the tag is.

Step 3: Hunt

Rules deploy within 20 minutes to an hour. Query the data in AH directly.

Detect beaconing patterns processes making regular-interval outbound connections:

Find DNS queries to high-entropy domains (potential DGA):

Spot persistence being established:

Leverage the telemetry from your new collection rule into a Custom Detection so high-value findings raise alerts automatically, instead of waiting for the next manual hunt.

Custom data collection effectively extends your endpoint protection into a targeted, general-purpose log collector, one that's now ready to serve advanced hunting, custom detections, and auditing or regulatory use cases, while default fleet-wide telemetry stays tuned for performance and signal-to-noise. By combining dynamic tagging with purpose-built collection rules, your highest-risk devices are always streaming the signals that matter most, ready for detection and investigation before and during an incident.

Learn more

To learn more about endpoint protection with Microsoft Defender, check out our website.
To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.
To learn more about custom data collection and how to get started, see our documentation.

Ways to fetch quarantine files

Dhwani_Shah — Tue, 09 Jun 2026 05:36:57 GMT

We are working with quarantine files and have a few questions:

1. Is there a public API available to retrieve quarantined files from Microsoft Defender for Endpoint?

2. Is there a documented method to map an alert or a file SHA-1/SHA-256 hash to the corresponding object in the Defender quarantine store?

3. Is there a way to retrieve quarantined files other than using a PowerShell script through the Live Response API?

Microsoft Defender now monitors RPC activity

EdanZwick — Tue, 09 Jun 2026 16:55:28 GMT

Remote procedure call (RPC) is a protocol commonly abused by attackers that allows functions implemented in a separate process, and potentially on a remote machine, to be called as if they were local. Many core Windows and Active Directory capabilities are built on or make use of RPC, which makes it an attractive target. To help protect against remote RPC-based attacks, Microsoft Defender now monitors remote RPC calls, disrupts malicious activity that leverages them, and surfaces relevant telemetry in advanced hunting.

RPC basics

While RPC is a rich and complicated protocol, the main components that are relevant for security monitoring purposes are:

Interface: A logical grouping of functionality exposed by an RPC server. Interfaces are identified by UUID. Example interfaces include Task Scheduler, Remote Registry, and the Service Control Manager, each exposing functionality related to a different Windows OS component.
OpNum: Stands for Operation Number, an ordinal that denotes a specific function exposed by an RPC interface. Examples include RCreateServiceW (OpNum 12, Service Control Manager interface) and BaseRegQueryValue (OpNum 17, Remote Registry interface).

Many remote attack techniques and tactics are based on RPC, for example:

Lateral movement: often abuses RPC functionality for remotely creating tasks, services or invoking WMI.
Credential theft: DCsync attacks, which abuse privileged compromised accounts to remotely extract credential material from Active Directory, are based on RPC functionality for directory replication. SecretsDump and similar attacks, which remotely extract SAM or LSA secrets, are based on querying a device’s registry remotely, using RPC.
Privilege escalation: Multiple authentication coercion attacks abuse benign RPC interfaces to coerce servers to authenticate an attacker.
Discovery: Tools such as SharpHound leverage RPC calls to enumerate users, sessions and shares.

For a more comprehensive mapping of RPC interfaces to attack techniques, see work by Jonathan Johnson.

RPC auditing in Defender

Since RPC is so heavily used on Windows systems and in Active Directory domains, monitoring remote RPC traffic using network monitors is often expensive and infeasible. Additionally, if the underlying transport protocol is encrypted (such as SMB3), it might be impossible to observe RPC traffic.

To enable efficient auditing of remote RPC activity regardless of transport-layer protection, Defender research and engineering expanded the existing RPC integration with the Windows Filtering Platform (WFP) to support OpNum-level granularity. This makes it possible to identify and audit the specific RPC function being invoked, rather than only the RPC interface.

This capability is designed to help detect remote RPC-based attack techniques, where an attacker interacts with RPC interfaces exposed by a target device. For that reason, Defender focuses this monitoring on inbound remote RPC calls observed on the RPC server host. The telemetry is collected using audit-only WFP filters, which do not interfere with normal traffic, while still providing visibility into suspicious remote activity targeting the device. This approach does not require visibility into the source device.

Local RPC calls, such as inter-process communication on the same device over local transport, and outbound RPC client calls are outside the scope of this monitoring mechanism.

Using this capability, Defender monitors selected RPC calls, leverages the resulting telemetry to detect malicious activity, and exposes monitored calls in advanced hunting. Defender dynamically monitors selected remote operations from interfaces including, but not limited to: Remote Registry, Service Control Manager, Task Scheduler, and Windows Management Instrumentation (WMI). RPC monitoring for workstations is generally available, while server monitoring is currently in gradual rollout.

RPC-based detections and disruption triggers are already available in Defender and include detections such as:

Ongoing hands-on-keyboard attack via Impacket toolkit
Suspicious service creation initiated remotely
Indication of local security authority secrets theft
Unusual RPC user and session discovery
Authentication coercion attack

Example Advanced Hunting queries

1. Remote registry key save events, abused for remote credential dumping.

let remoteRegistryInterface = '338cd001-2244-31f1-aaaa-900038001003'; let registrySaveOpnums = dynamic([20, 31]); // BaseRegSaveKey, BaseRegSaveKeyEx DeviceEvents | where ActionType == 'InboundRemoteRpcCall' | extend AdditionalFields = parse_json(AdditionalFields) | extend RpcInterface = tostring(AdditionalFields.RpcInterfaceUuid), OpNum = toint(AdditionalFields.RpcOpNum) | where RpcInterface == remoteRegistryInterface and OpNum in(registrySaveOpnums)

2. Remote Service Creation events, could indicate lateral movement:

let remoteServicesInterface = '367abb81-9844-35f1-ad32-98f038001003'; let serviceCreationOpnums = dynamic([12, 24, 44, 45, 60]); // RCreateServiceW, RCreateServiceA, RCreateServiceWOW64A, RCreateServiceWOW64W, RCreateWowService DeviceEvents | where ActionType == 'InboundRemoteRpcCall' | extend AdditionalFields = parse_json(AdditionalFields) | extend RpcInterface = tostring(AdditionalFields.RpcInterfaceUuid), OpNum = toint(AdditionalFields.RpcOpNum) | where RpcInterface == remoteServicesInterface and OpNum in(serviceCreationOpnums)

3. Session discovery events, could indicate account discovery:

let srvsvcInterface = '4b324fc8-1670-01d3-1278-5a47bf6ee188'; let netrSessionEnumOpnum = 12; DeviceEvents | where ActionType == 'InboundRemoteRpcCall' | extend AdditionalFields = parse_json(AdditionalFields) | extend RpcInterface = tostring(AdditionalFields.RpcInterfaceUuid), OpNum = toint(AdditionalFields.RpcOpNum) | where RpcInterface == srvsvcInterface and OpNum == netrSessionEnumOpnum | summarize dcount(DeviceId) by AccountName, AccountDomain, AccountSid

Check out the advanced hunting tab to see monitored RPC activity in your environment and stay tuned for more updates from Defender.

Learn more

To learn more about endpoint protection with Microsoft Defender, check out our website.
To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

Understanding AI workloads on Linux

tejaskashyap — Tue, 02 Jun 2026 15:01:12 GMT

Hi everyone,

I’m a PM working on security for Linux environments and trying to better understand how AI workloads are actually showing up in production today.

Would appreciate hearing from folks here:

Are you running any AI workloads on Linux today? Or actively exploring?
What does your deployment/setup look like — e.g., model training/inference, agents, MCP servers, data pipelines, etc.?
How are you thinking about securing this stack, if at all?

If you’re open to a quick 30-min chat, I’d love to learn more from your experience as well.

Thanks in advance — this will directly help shape where we invest next.

How Microsoft Defender used predictive shielding to proactively disrupt a ransomware attack

AvivSharon — Mon, 01 Jun 2026 17:16:47 GMT

Modern ransomware attacks are increasingly designed to blend in with normal IT operations, using trusted administrative tools to quietly weaken defenses and distribute malicious payloads at scale.

In a recent real‑world incident, a human‑operated ransomware actor attempted to do exactly that by abusing Group Policy Objects (GPOs) to target hundreds of devices, but Microsoft Defender detected the attack and proactively hardened those devices before GPOs were deployed.

The attacker’s plan

The target organization, a large educational institution with more than a couple of thousand devices onboarded to Microsoft Defender, had already experienced a compromise of a domain admin account from an unmanaged device before the ransomware deployment attempt began.

Because GPOs are a trusted mechanism for pushing configuration changes across devices, they present an attractive path for attackers looking to disable security tools or deploy ransomware broadly without needing to access each machine individually. This attacker’s plan involved weaponizing GPOs to:

Push tampering configurations that could disable Defender protections across the environment
Distribute and execute ransomware via scheduled tasks
Leverage built‑in enterprise infrastructure to scale the attack

This approach allowed the attacker to attempt ransomware deployment through standard administrative channels, minimizing the need for direct interaction with individual devices and increasing the potential for widespread impact.

How Defender thwarted the attack

First, Defender quickly detected the attack and contained the domain admin account that the attacker had compromised. Then, since the attacker had created a malicious GPO that disabled key Defender protections, a Defender tampering alert was triggered. In response, predictive shielding activated GPO hardening, temporarily pausing the propagation of new GPO policies across all MDE onboarded devices reachable from the attacker’s standpoint and achieved protection of ~85% of devices against the tampering policy before ransomware was deployed.

Ten minutes later, the attacker attempted to distribute ransomware, but because GPO hardening had already been applied, GPO propagation was already disabled on the targeted devices and the attacker was unsuccessful. Defender recognized that GPO tampering is a precursor to ransomware distribution and acted preemptively. It didn’t wait for ransomware to appear; it acted on what the attacker was about to do, preventing downstream impact such as recovery costs and operational downtime.

The results

Zero machines were encrypted via the GPO path.
Roughly 97% of devices the attacker attempted to encrypt were fully protected by Defender. A limited number of devices experienced encryption during concurrent ransomware activity over SMB; however, attack disruption successfully contained the incident and stopped further impact.
700 devices applied the predictive shielding GPO hardening policy, reflecting the attacker’s broad targeting scope, and blocking the propagation of the malicious policy set by the attacker within approximately 3 hours.

Attackers are getting more sophisticated, finding ways to evade detection by abusing legitimate IT tools that organizations rely on and can’t simply turn off. Security teams can’t restrict these mechanisms without impacting daily operations. By detecting ransomware staging and predicting the attacker’s next move, Defender can apply targeted restrictions just in time, shifting from reactive response to proactive prevention, stopping only what matters when it matters while maintaining full business productivity. With average ransom demands now ranging from $2–5M, the downstream recovery and remediation savings from preventing these attacks can be massive.

Learn more

To learn more about this specific attack, check out the full case study: Case study: How predictive shielding in Defender stopped GPO-based ransomware before it started [microsoft.com]
To learn more about endpoint protection with Microsoft Defender, check out our website.
To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

Larac2shell: Turning MDE Live Response into a near real-time shell We are the EDR!

alkefallonitis — Fri, 08 May 2026 08:25:12 GMT

https://github.com/akefallonitis/larac2shell

Turning MDE live response into a near real time interactive shell beta version out

Features:

- Internal (Thanks to Fabian Bader - Nathan McNulty and xdrinternals research ) vs External api authentication
- Arbitrary command execution via pre-uploaded base64 wrapper script
- Cross-OS support

PS Two MSRC bugs reported for direct command execution bypass waiting for Microsoft Response in order to publish them

Coming SOON TM

Full LaraC2 Post Exploitation OST framework over MDE as C2/C3 Channel - We are the EDR / No external Infra / Onboarding to your controlled tenant silencing MDE

Happy testing 🥳 🎉

Introducing selective response actions for high-value assets in Microsoft Defender

amibarayev — Mon, 18 May 2026 15:50:40 GMT

Deploying Microsoft Defender on high-value assets (HVAs) such as domain controllers, ADFS servers, and other Tier-0 systems, requires a thoughtful approach to balance strong protection with operational stability. Given the powerful response capabilities available, organizations often seek greater control over how these actions are applied in sensitive environments. Many organizations, especially those with strict privileged access management policies, also prefer to limit cloud-initiated administrative actions on Tier-0 systems to align with their security and compliance requirements.

We introduced simplified onboarding in late 2025 with the release of the Defender deployment tool, and now we’re excited to announce that selective response actions for high-value assets are now available in public preview to afford security teams greater flexibility within the onboarding process. This new capability provides a more controlled and flexible approach, enabling organizations to define exactly which response actions are allowed on critical assets. Security teams can maintain operational continuity while still benefiting from the full visibility and protection of Defender.

How it works

Deploying Defender on high-value assets requires additional safeguards. This capability introduces a controlled onboarding experience that enforces strict boundaries from the start.

Security teams can:

Generate a custom onboarding package tailored specifically for Tier-0 and High-Value Assets
Use the Defender deployment tool, a lightweight, dynamic tool that simplifies onboarding and removes the need for complex scripts
Leverage secure key validation and package expiry, ensuring controlled and secure deployment
Explicitly define which remote response actions are permitted on sensitive systems
Onboard both Windows workstations and Windows Server environments

This approach ensures that security controls are applied consistently and cannot be altered post-deployment, reducing the risk of misconfiguration or misuse.

Image 1: selective response actions in the Defender deployment tool package settings

Key benefits

Selective response actions for high-value assets provide a safer and more controlled way to protect critical systems:

Reduce operational risk by limiting powerful security actions on Tier-0 assets
Prevent accidental or malicious disruptions caused by overprivileged or compromised accounts
Align with privileged access management (PAM) policies by restricting cloud-initiated administrative actions
Support compliance and regulatory requirements with stricter enforcement of security controls
Maintain full Defender visibility and protection without overexposing sensitive systems
Provide explicit and granular control over remote response capabilities

Image 2: view of the available response actions for a particular device in the Defender portal

Secure your most critical assets with confidence

You can now extend Defender for Endpoint protection to your most critical Windows systems, while maintaining strict control over how those systems are accessed and managed. This capability empowers security teams to protect what matters most with confidence and precision.

Learn more

Learn more about how to set up selective response actions for high value assets
To learn more about endpoint protection with Microsoft Defender, check out our website.
To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

runHuntingQuery API and 'evaluate pivot'

Tim4 — Fri, 01 May 2026 09:26:00 GMT

Seem to have a problem where any request to the runHuntingQuery API with 'evaluate pivot' fails with

error": {

"code": "UnknownError",

"message": "",

Is this just a 'feature' ? The query happily runs trough the website/XDR portal. :-(

Is there a way to simulate a pivot (easily) in powerapps ?

Assess Secure Boot status with Microsoft Defender

amitcohen — Mon, 27 Apr 2026 16:38:22 GMT

Understanding the Secure Boot certificate challenge

Secure Boot is a foundational security feature that validates the integrity of your device's boot process, ensuring only trusted software can run during system startup. This protection has been quietly defending enterprise devices since 2012, but the original 2011 certificates that enable this trust are approaching their expiration date.

When certificates expire in June 2026, devices that haven't transitioned to the new Windows UEFI CA 2023 certificates will no longer be able to receive new security protections for the early boot process. While these devices will continue to boot, they may no longer be able to receive or enforce new protections at the earliest stages of system startup. Over time, this can weaken the device’s root of trust and expose it to classes of attacks that operate before the operating system and security controls are fully loaded:

Malicious or tampered boot components may no longer be reliably blocked if they are not signed with trusted certificates
Devices may be unable to adopt future Secure Boot policy updates designed to mitigate newly discovered boot-level threats
Attackers may attempt to leverage boot-level persistence techniques that operate below the visibility of traditional security controls

As new vulnerabilities and protections are introduced, devices that are not updated will gradually fall behind in their ability to enforce trust at boot, but the challenge isn’t just knowing that this transition needs to happen, it’s understanding which devices in your fleet have successfully completed the update and which still require attention.

Introducing Secure Boot 2023 certificate assessment

A new recommendation in Defender allows you to ensure that devices are updated to Secure Boot 2023 certificates and boot manager, providing a centralized, at-scale view of Secure Boot certificate readiness across your environment.

This assessment automatically categorizes your devices into:

Exposed devices: Still trusting older Secure Boot certificates without trust for newer Secure Boot certificates
Compliant devices: Successfully relying on the 2023 certificates and signed boot manager
Not applicable devices: Systems where Secure Boot is disabled or not supported

From the recommendation view, you can:

Drill down into exposed devices and identify exactly which systems require attention
Filter by OS platform and device context to prioritize remediation efforts
Export device data to share with infrastructure and platform teams
Track rollout progress across your organization
Integrate findings into existing security posture workflows

[Secure Boot 2023 recommendation in MDE portal showing deployment status across the fleet]

Take action on your Secure Boot readiness

To access this tool in the Defender portal, navigate to Exposure Management → Recommendations → Devices → Misconfigurations. Once Defender identifies exposed devices, it provides remediation guidance.

For detailed deployment guidance, including enterprise rollout strategies and validation practices, see: https://aka.ms/GetSecureBoot

Your action plan

Assess your exposure
Navigate to the tool to understand how many devices in your environment require updates.
Engage the right teams
Secure Boot certificate deployment is typically owned by infrastructure and platform teams, so coordinate across your organization.
Prioritize high-value assets
Focus remediation efforts on critical devices and sensitive environments first.
Track progress over time
Monitor rollout progress and ensure coverage improves ahead of the June 2026 deadline.

Learn more

Visit the comprehensive Secure Boot guidance at https://aka.ms/GetSecureBoot
Learn more about Microsoft Secure Score for Devices in Microsoft Defender for Endpoint
To learn more about endpoint protection with Microsoft Defender, check out our website.
To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

Introducing effective settings: See security configurations enforced on your device

ArielMichaeli1 — Mon, 09 Mar 2026 16:00:00 GMT

See exactly which security configurations are enforced on your device

Security teams spend significant time defining policies for Microsoft Defender security settings. But when it comes to investigations or troubleshooting, the real question is often simple: what is currently being enforced on this device? Today, we’re excited to share that the settings experience is now generally available in Defender to provide this critical visibility.

Figure #1: Effective settings tab on the device page

From intended policy to real-world enforcement

Understanding device security posture sometimes means correlating policy intent across multiple management sources, including Intune, Group Policy Object (GPO), and local admin configurations. With effective settings, administrators can see the effective value of each security setting on a specific device—along with the configuration source—and quickly identify configuration attempts that didn’t take effect. This helps eliminate silent gaps where intended protections are not actually enforced, reducing the risk of unnoticed exposure during incidents or active attacks. And this shift from intent to reality helps teams move faster when validating posture, investigating incidents, or resolving conflicts between management tools.

A new view on the device page

The effective settings tab is available as a new tab under the configuration management tab on the device page. From this single location, you can:

View the actual value enforced for each security setting
Identify the configuring source responsible for that value
See additional configuration attempts from other sources that were evaluated but not applied

For complex or layered scenarios such as Microsoft Defender Antivirus exclusions and Attack Surface Reduction (ASR) rules, all configured rules are shown together with their effective value, configuring source, and additional configuration attempts.

This makes it far simpler to understand why a device behaves the way it does, without jumping between consoles or guessing which policy “won.”

Figure #2: Simple settings side panelFigure #3: Complex settings side panel

Practical use cases

Security admins and analysts can use effective settings for use cases like:

Validating enforcement – Confirm that intended security configurations are truly applied on devices
Troubleshooting conflicts – Quickly spot competing policies or management sources that prevented a configuration from being enforced
Improving operational confidence – Reduce uncertainty by relying on an authoritative, device-level view of security settings

Platform support and what’s next

The current release focuses on Windows platform antivirus security settings, including ASR rules and exclusions. This is just the beginning. Our roadmap includes expanding coverage across additional platforms, and a broader set of security settings configured through the Microsoft 365 Defender and Intune portals.

Getting started

If you’re using Microsoft Defender for Endpoint, head to a device page and open the configuration management → effective settings tab to explore the experience firsthand.

Supported versions:

Microsoft Defender for Endpoint Sense client: 10.8735.26018.1000 or later
Microsoft Defender Antivirus platform: 4.18.25010.11 (January 2025 release) or later

Learn more

Learn more about investigating devices in Defender. To get started, navigate to a device page and open the configuration management → effective settings tab.
To learn more about Microsoft Defender endpoint protection, check out our website.
To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

Transparent and customizable onboarding for modern and legacy Windows devices

Sinclaire_Hamilton — Tue, 03 Mar 2026 03:25:40 GMT

Onboarding all devices in your estate is paramount for strong security posture. In fact, Microsoft Threat Intelligence research shows that in the majority of ransomware attacks, the spreader machine was a device that was not yet onboarded. But customers often struggle to follow complex steps that differ by OS, accidentally duplicate devices because they can’t tell whether onboarding is in progress or failed, or have incorrect initial configuration settings causing system incompatibility. That’s why we’re introducing an updated onboarding experience via the Defender deployment tool for Windows that improves progress visibility and adds controls—like package naming and configurable expiry—to help administrators manage onboarding securely at scale.

What’s new

The Defender deployment tool streamlines the onboarding process by dynamically adapting to the operating system, delivering healthy endpoint security to a diverse estate of Windows devices. It is the preferred automated solution that works on modern and legacy devices and removes the need for a separate onboarding file by embedding the onboarding package and all related information within a downloadable .exe that can be run to onboard devices. This updated experience makes onboarding more predictable and transparent, while adding administrative controls that help reduce exposure if onboarding packages are accidentally shared beyond your organization:

A single, runnable .exe for onboarding with the onboarding information embedded (no separate onboarding file required)

Silent and non-interactive onboarding options to support large-scale deployments with tools like Group Policy or Configuration Manager

Custom package identifiers to help track and manage onboarding packages across your organization

Configurable onboarding package expiry (up to one year)

Customizable name identifiers and keys for increased control and visibility

New portal entry points and guidance to make it easier to find the right onboarding and offboarding method for Windows, including directly from the device inventory page

The new, streamlined onboarding tab in the Defender portal

Customize your deployment package

This experience moves away from using scripts and loose blobs, making it more difficult for onboarding to take place at the hands of unauthorized users and significantly decreasing security issues related to blobs in the wild that don't expire. And for the first time, you can set custom expiry dates on onboarding packages for 1 day, 7 days, or a custom amount up to a year. Expiry for onboarding packages protects customers from unwanted onboarding and compliance issues, limiting packages from getting misused if they’re found in a public place. Expiry reduces the likelihood of unauthorized package usage, together with the new portal-provided key that you must input to complete the onboarding process.

Customize your deployment package with a name and expiry date

See your onboarding telemetry in detail

Deployment tool events are available in the device timeline and advanced hunting tabs for increased transparency into onboarding progress and errors, so you can quickly address any issues.

On the new deployment packages page, you can see your organization's onboarding packages at a glance and click to see more package properties, increasing visibility and traceability within the onboarding process. This is a great foundation for adding even more onboarding-related telemetry to view per device in the future. You can even filter by active or expired packages and hide packages you no longer wish to see.

The new deployment packages page in the Defender portal

To experience this next iteration of the Defender deployment tool for Windows, navigate to Settings > Endpoints > Onboarding > Windows, or jump there directly from the device inventory page. There you'll see the newly designed onboarding page in the Defender portal, complete with on/offboarding guides. Select the Defender deployment tool from the options shown.

New onboarding and offboarding buttons on the device inventory page

The Defender deployment tool is also available for Linux. We look forward continuing to share ways we're making it easier to onboard devices to Defender.

Learn more

Deploy Microsoft Defender endpoint security to Windows devices using the Defender deployment tool (preview) - Microsoft Defender for Endpoint | Microsoft Learn

Deploy Microsoft Defender endpoint security to Linux devices using the Defender deployment tool (preview) - Microsoft Defender for Endpoint | Microsoft Learn

To learn more about Microsoft Defender's endpoint protection, check out our website.

To learn more about Microsoft Security solutions, visit our website. Bookmark the https://www.microsoft.com/security/blog/ to keep up with our expert coverage on security matters. Follow us on LinkedIn (https://www.linkedin.com/showcase/microsoft-security/) and X (https://twitter.com/@MSFTSecurity) for the latest news and updates on cybersecurity.

Introducing library management in Microsoft Defender

amibarayev — Tue, 17 Feb 2026 17:52:18 GMT

In dynamic investigation environments, preparation and agility are key. Security analysts working with live response in Microsoft Defender often rely on scripts and tools to triage, investigate, and remediate threats. Until now, these assets had to be uploaded during active sessions, limiting manageability and increasing time to action.

Recognizing the need for better readiness and control, Defender now introduces a more proactive and efficient way to manage these assets: library management.

The new library management experience in Defender brings powerful enhancements to how security teams manage scripts and files used in live response. With this centralized and streamlined interface, analysts no longer need to wait for an active session to organize their investigation tools everything can now be managed proactively, directly from the portal. This enhancement in Defender’s live response tooling improves operational readiness, enhances visibility and control, and helps streamline response workflows across SOC teams.

What’s new in library management?

Centralized script and file management – Security teams can now upload, manage, and clean up their entire collection of Live Response scripts and files outside of an active investigation. This proactive approach allows better preparation and alignment across analysts.

Upload in advance – Easily upload PowerShell scripts, batch files, or other response tools ahead of time, so they're immediately accessible when needed during an investigation.

View script contents in the portal – No need to switch tools, analysts can review script contents directly within the Defender UI to validate logic and confirm functionality before execution.

Clean and organize – Outdated or redundant scripts can be deleted with a click, keeping your library lean, relevant, and audit-friendly.

Boost analyst understanding with Copilot – Understanding unfamiliar scripts can slow down investigations. That’s where Microsoft Security Copilot comes in.

Copilot automatically analyzes scripts in the library and provides:

Summarized behavior descriptions
Security-relevant insights
Execution risk context

This makes it easier for analysts—especially those new to a team or handling inherited tools—to assess what a script does before running it, reducing errors and increasing confidence.

Get started today

You can access the Library Management experience from the live response page in the Microsoft Defender portal. Start uploading your investigation tools, explore script previews, and let Copilot assist in surfacing the intent and behavior of your scripts.

Defender for Business - No alert after process lock out ?

karnalta — Tue, 27 Jan 2026 11:43:15 GMT

Hello all,

A few days ago, I have setup Defender for business server on a Windows Server 2019.

I can see that server in the Microsoft security portail devices list.

I have also tested the "suspicious" powershell command provided by Microsoft and it went all good. Powershell blocked, alert escaladed as incident in the security portal, email received, ...

But the next day, I tried to install a service on that server that got blocked by Virus & Thread Protection because it was attempting to modify a lot of files. That was a good point for Defender (it was not a real thread and was later added as exception).

My worry is that it was never escaladed to the security portal, I didn't received a alert email, .. The system blocked that "thread" multiple times during my attempt to deploy it and no incident were throw.

What could be wrong ?

Thank you.

Save the date - January 26, 2026 - AMA: Secure your endpoints with policy and Microsoft Defender

Pearl-Angeles — Tue, 20 Jan 2026 22:13:25 GMT

Save the date for January 26 at 8:00 AM PT! Have questions about using Microsoft Intune to enforce device compliance? Curious how to configure devices to help prevent security breaches and limit the impact of threats? Ask Microsoft Anything (AMA) about integrating Microsoft Defender for Endpoint with Microsoft Intune at Tech Community Live!

Product teams will be answering your questions live and in chat. Get tips using policy to onboard devices, define risk level, block non-compliant devices from accessing corporate resources, and more.

Go to aka.ms/AMA/SecureEndpoints to save the date and add this event to your calendar!

Defender for Identity health issues

zlate81 — Mon, 19 Jan 2026 11:31:19 GMT

When will the issues/alerts from defender for identity sensors be available to view via advanced hunting instead of the Graph API and "/security/identities/healthIssues"

Using MDE (Passive Mode) with Palo Alto Cortex XDR to enable Defender for IoT (Enterprise IoT)

gabpereira — Wed, 14 Jan 2026 13:56:04 GMT

Hi everyone!
I’m working with a customer that uses Palo Alto Cortex XDR as their primary EDR. We want to leverage Microsoft Defender for IoT specifically for Enterprise IoT (not OT/ICS). I have a few questions:

MDE in Passive Mode as a sensor:
Can Microsoft Defender for Endpoint (MDE) running in Passive mode act as a sensor to enable Enterprise IoT discovery/monitoring for Defender for IoT? Are there any feature limitations when MDE is not the primary EDR?
Appliance sensor in Enterprise IT:
If we cannot use the MDE agent, is it supported to deploy the Defender for IoT appliance sensor in an enterprise IT network (e.g., offices/campuses) to cover Enterprise IoT use cases?
Coexistence / Complementary sensors:
Is it possible (and recommended) to run the appliance sensor alongside MDE (sensor) to complement coverage/features? Any guidance on architecture, data overlap/deduplication, or licensing implications?