rss.livelink.threads-in-node

WDSI Submission Review Has Been Pending for 10 Days

Orxan — Mon, 24 Aug 2026 08:59:47 GMT

I submitted the application I developed to WDSI for review because the Microsoft Defender SmartScreen warning appears when running it. I would like the application to be added to the virus database so that this warning no longer appears, but the review has still not been completed after 10 days. Could you please help me?

Submission ID: 61955163-f60b-4141-aafa-cd4afe171996

Link: https://www.microsoft.com/en-us/wdsi/submission/61955163-f60b-4141-aafa-cd4afe171996

Device* tables missing from Advanced Hunting schema despite M365 E5 license

rahman973 — Tue, 11 Aug 2026 11:29:49 GMT

We have an M365 E5 trial (with Microsoft Defender for Endpoint service plan enabled) and a standalone Defender for Cloud Apps trial on the same tenant. Two devices are onboarded and show as Active in Device Inventory. one Windows 11 VM hosted on mac m4 and one Windows Server 2019 Azure VM.

The issue: the entire Devices section is missing from the Advanced Hunting schema. No DeviceInfo, DeviceNetworkEvents, DeviceEvents, DeviceProcessEvents, etc. The schema only shows Alerts & behaviors, Apps & identities, Email & collaboration, Defender Vulnerability Management, and Exposure Management.

Additionally:

- The device Timeline tab does not appear on device pages (not in visible tabs or overflow menu)

- "Go hunt" from a device page only generates a query against IdentityLogonEvents, not any Device* tables

- Settings → Microsoft Defender XDR does not show an "Advanced hunting" option for managing data sources

- The MDE Client Analyzer on the Azure VM passes all EDR cloud connectivity checks (CnC, Cyber, AutoIR, SampleUpload, MdeConfigMgr all Succeeded 200)

- Settings → Endpoints → Optional features loads with all toggles including the Defender for Cloud Apps integration

- Cloud Discovery via MDA works (discovered apps visible on the device page)

- The Tenant ID and Org ID shown in XDR settings are different values

The tenant originally had only the Defender for Cloud Apps standalone trial. The E5 trial was added afterward. It appears the MDE data source was never deployed/activated in Defender XDR despite the license and onboarding being in place.

I've opened a support case but wanted to ask here as well, has anyone resolved this issue? I've found several older posts describing the same problem but none with a confirmed fix.

Any guidance would be appreciated.

How to send false positive?

Joerg4 — Thu, 06 Aug 2026 18:15:09 GMT

Hi, I coded a small program which Microsoft treats as malicous. Unfortunately the Microsoft false positive submission site is not working. How can I alternatively send a false positive to Microsoft? Any help is appreciated.

EnableConvertWarnToBlock will not enable - stays False

Warren212 — Tue, 04 Aug 2026 16:27:15 GMT

We have a GPO applied to Windows 11 Pro machine - fully patched and onboarded to MDE. The GPO enables "EnableConvertWarnToBlock" as follows:

The GPO is applied to the machine and the following registry key is populated:

But when I check the status on the client - it will not enable:

I have enabled troubleshooting mode and disabled tamper protection in case this is blocking but nothing seems to work. Its as if MDAV/MDE is not even looking/reading that registry key.

Anyone else have the same issue or ideas on resolution?

Location of Defender for Identity Entry in Defender Tables

MichaelMichalko — Mon, 03 Aug 2026 18:39:16 GMT

Our GRC group wants an automated report on windows servers and workstations over 7 days old not onboarded for Defender for Endpoint. A change in our environment (not sure if it was MS or us) has caused an additional entry in a column named "DiscoverySources" for Defender for Identity. It's my understanding that D4I is only used on domain controllers, but we get entries on non-DCs as well. This identifier does not appear on the device dashboard, nor can I add it in with the custom column tab. Furthermore, if a machine requires onboarding for D4E, it will show them both in the same column, it separates them with a comma in the same field.

Right now, I have to do this process manually and with the overhead involved, it takes me about 30 minutes to run the reports, filter out the false positives and forward them to the appropriate staff. They want this every day, and I can't do this operationally. I'd welcome the opportunity to create a Logic App based on a query to perform this function and route it.

Can someone point me in the direction of the table which contains the DiscoverSources column? I haven't been able to find it. That would help me to perform the necessary KQL and Logic App to automate this process.

Long time listener. First time publisher. Thanks

Defender Device Groups

alexcolombari — Thu, 30 Jul 2026 20:59:40 GMT

Hello everyone,

I need some help creating a device group in Defender. I can't find anything related to Groups inside Microsoft Security. I'd read that it's possible to create one inside the Permissions tab, but I can't figure out how.

Someone can explain what's the process?

Inconsistent Microsoft Defender Behaviour

OllieHay1 — Mon, 20 Jul 2026 07:54:38 GMT

Hi everyone,

We have an issue whereby across several intune managed devices with identical defender AV policy, signature version, and platform version, we've found inconsistent detection/remediation behaviour.

Some devices block malicious files instantly on download (expected and correct). Others only detect on open rather than on write, or log a successful detection/remediation action without the file actually being removed from disk, it remains fully accessible indefinitely.

Since this occurs despite identical config, we're concerned this is a genuine gap in automatic remediation reliability that could affect real threats, not just our test files.

Troubleshooting completed, issue persists:

- Ruled out exclusions (path/extension/process)

- Confirmed PUA protection, real-time protection, tamper protection, and all granular protection flags enabled/healthy

- Removed orphaned third-party AV registrations from WSC (previously caused Defender to show as "snoozed")

- Confirmed filter driver (WdFilter) loaded correctly, no conflicts

- Cleared stuck "detected but not remediated" threat entries

- Ruled out file locks preventing remediation

- Cleared cached signature state, forced fresh signature pull

- Attempted full platform reset

- Confirmed cloud protection/MAPS enabled and reachable

- Increased CloudBlockLevel to test enforcement aggressiveness

Does anyone have any idea what could be happening here?

Thanks

MDVM - Patch Publication Date

cipherdell — Thu, 16 Jul 2026 14:54:25 GMT

Dear Microsoft MDVM Development Team,

Please could you as quickly as possible implement the "Patch Publication Date" for the vulnerabilities you report on. Any major Vulnerability management platform has this simple field/record please advise you are implementing this and the timeframe for it?

Kind Regards,

Graeme

New Privileged Token Context Telemetry Boosts Advanced Hunting in Microsoft Defender

TalTzhori — Wed, 15 Jul 2026 16:00:00 GMT

In brief: Defenders can now easily identify logons involving high-privilege identities or special logon flags to better hunt threats and fine-tune detections.

When a user logs on, Windows’ Local Security Authority (LSA) constructs an access token that represents the user’s security context for that session. This token includes the user’s SID, group memberships, user rights, and logon flags, the information that determines what the session is allowed to access. The challenge was that, although Microsoft Defender has been collecting a token creation event at logon to supplement standard logon telemetry, the most important privilege context inside that token was not directly exposed for hunting. It was possible to see that a logon occurred, but much harder to quickly answer questions like: Did this session include Domain Admin membership? Was the logon tied to a local account?

We’re excited to share that Microsoft Defender is closing this visibility gap by surfacing key privilege context from token creation events that occur during login. It surfaces these new token context fields in Advanced Hunting, making it possible to query the privileged groups and logon attributes that were present in the user’s token at logon time. With this context available directly in hunting data, it is now much easier to isolate privileged sessions, investigate suspicious logons, and build higher-fidelity detections around privilege misuse.

New fields include:

TokenHasDomainAdminSid - The token contained the Domain Admins group SID.
TokenHasSchemaAdminSid - The token contained the Schema Admins group SID.
TokenHasEnterpriseAdminSid - The token contained the Enterprise Admins group SID.
TokenHasGroupPolicyCreatorSid - The token contained the Group Policy Creator Owners group SID.
TokenHasDomainControllerSid - The token contained the Domain Controllers group SID (indicates a DC’s computer account logon).
TokenHasCertificatePublisherSid - The token contained the Certificate Publishers group SID (relevant in AD Certificate Services scenarios).
TokenHasLocalAccountSid - The token contained a local account SID (not a domain account).
TokenHasNtlmAuthSid - The token contained the NTLM authentication SID (rather than Kerberos).
TokenHasThisOrgCertificateSid - The token contained a SID associated with certificate-based authentication issued by the organization (e.g., PKINIT logon).
NumberOfSidsInDomainAdminToken - If the token contained the Domain Admins group SID, this represents the total number of SIDs in that token (a measure of how many group memberships/privileges/logon flags were in an admin’s token).

These fields are available under AdditionalFields in the DeviceLogonEvents table.

How it works

Defender is deriving these fields from the token’s SID list at the moment of logon. Essentially, when the access token is created, Defender inspects it for any well-known high-privilege SIDs or special logon flags (see [MS-DTYP]: Well-Known SID Structures | Microsoft Learn for reference). By capturing privileges at token creation, the data offers an accurate snapshot of the user’s rights at logon. This is valuable because it can catch ephemeral privilege elevations. For example, whether an account is temporarily added to an admin group and quickly removed, or an attacker manipulates the PAC directly using a Silver or Golden Ticket, any logon during that window will still contain the admin SID in the token, even if the directory no longer reflects that membership later.

Note: This token context telemetry is additive to existing Windows logon events. Standard Security Log events like 4624 (logon success) provide information on network context (source IP, etc.) but don’t tell you about group memberships or special authentication methods. The new token fields fill that gap by focusing on privilege context. To correlate a token event with a traditional logon event and obtain a more complete view of the logon, you can match common attributes such as timestamp, account SID, device, logon type and logon ID (see the example query under “1. Spot suspicious privileged logons” below). Together, the two sources let you understand both how the logon happened and what privileges it carried.

Why this is powerful for defenders

The new token context fields unlock powerful ways to detect misuse of privileged accounts and unusual authentication patterns. For example:

1. Spot suspicious privileged logons

Identify cases where privileged tokens appear in unexpected contexts (e.g., admin accounts logging into low-tier devices, unusual logon types, or rare hosts).

// Token creation events let TokenCreateEvents = DeviceLogonEvents | where InitiatingProcessFileName == "lsass.exe" // Token creation events | where AdditionalFields has "TokenHasDomainAdminSid" | project DeviceId, AccountSid, AccountDomain, AccountName, LogonType, LogonId, AdditionalFields, TokenTime = Timestamp; // Standard logon events DeviceLogonEvents | where ActionType == "LogonSuccess" | where InitiatingProcessFileName != "lsass.exe" // filter out Token creation events | project DeviceId, AccountSid, AccountDomain, AccountName, LogonType, LogonId, RemoteDeviceName, RemoteIP, Timestamp // Correlate both events (same logon, small time window) | join kind=inner TokenCreateEvents on DeviceId, AccountSid, AccountDomain, AccountName, LogonType, LogonId | where Timestamp between (TokenTime - 1s .. TokenTime + 1s) // Example filter (specific source device) | where RemoteDeviceName == "kali"

2. Detect privilege escalation attempts

As previously detailed, whether an adversary utilizes ephemeral group modifications or direct PAC manipulation, the outcome is the same. These temporary group memberships used during an attack will still be reflected in the token captured at logon, making this activity easier to identify retrospectively. For instance, a standard user who suddenly logs on with TokenHasDomainAdminSid is a red flag for potential token manipulation or group membership abuse.

let lookback = 14d; let recent = 1d; let token_priv = "TokenHasDomainAdminSid"; // Baseline: users who historically were DAs let baseline_users = DeviceLogonEvents | where Timestamp between (ago(lookback) .. ago(recent)) | where InitiatingProcessFileName == "lsass.exe" // Token creation events | summarize DA_sids = make_set_if(AccountSid, AdditionalFields has token_priv), non_DA_sids = make_set_if(AccountSid, AdditionalFields !has token_priv); // Recent: new users with DA token DeviceLogonEvents | where Timestamp > ago(recent) | where AdditionalFields has token_priv | where AccountSid in (baseline_users | project non_DA_sids) and AccountSid !in (baseline_users | project DA_sids)

3. Monitor certificate-based logons

If your environment does not normally use smart cards or certificate-based authentication, or if a user who does not typically authenticate using smart cards suddenly generates events with TokenHasThisOrgCertificateSid, this may warrant investigation, as it could indicate authentication using a fraudulently issued certificate.

let lookback = 14d; let recent = 1d; // Baseline: users who historically used certificate-based auth let baseline_users = DeviceLogonEvents | where Timestamp between (ago(lookback) .. ago(recent)) | where AdditionalFields has "TokenHasThisOrgCertificateSid" | summarize by AccountSid; // Recent: new certificate-based logons DeviceLogonEvents | where Timestamp > ago(recent) | where AdditionalFields has "TokenHasThisOrgCertificateSid" | where AccountSid !in (baseline_users)

4. Identify local account lateral movement

Pivot on TokenHasLocalAccountSid to identify logons where a local account was used, especially in remote or network logon scenarios. Such activity is uncommon in well-managed environments and may indicate lateral movement using shared credentials or local administrator reuse.

DeviceLogonEvents | where Timestamp > ago(7d) | where AdditionalFields has "TokenHasLocalAccountSid" | where LogonType == "Network" or LogonType == "RemoteInteractive"

These examples illustrate how token privilege context can improve both threat hunting and detection engineering. Analysts can quickly isolate high-interest logons from large volumes of authentication telemetry, while custom detection rules can leverage these fields to focus on sessions with elevated privileges and improve fidelity.

DVM Certificate Inventory Shows No Data Despite Healthy Endpoints in Defender for Endpoint

vijaysethiya — Tue, 07 Jul 2026 12:54:31 GMT

Hi Team,

I'm testing Microsoft Defender Vulnerability Management.

Current status:

- Defender Vulnerability Management Add-on enabled

- Certificates inventory tab is visible

- Software Inventory populated

- Security Recommendations populated

- Windows and Linux devices onboarded

- Linux mdatp health = healthy:true, licensed:true, cloud_enabled:true

- Devices have local certificates installed

- Certificate Inventory page shows "No data"

The DVM Add-on was enabled more than 36 hours ago.

Has anyone experienced a delay in Certificate Inventory population or are there additional prerequisites beyond DVM licensing and device onboarding?

Thanks.

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, 15 Jul 2026 14:05:55 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. With this release, we are bringing built-in, flexible scheduling capabilities directly into Defender - making it easier to manage and standardize scan behavior 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 🥳 🎉