Hi All,

I have been trying to block teams senders within XDR > TABL. The issue is that sometimes the option for 'Teams Senders' is there, and other times it is not. I confirmed with Microsoft that my tenant is configured correctly. Is anyone else experiencing the same issue?

The issue seems to arise if I don't fully sign out of XDR fully, then sign back in (that sometimes fixes it, not always). If I reuse a session from yesterday, then, Defender removes 'Teams Sender' and other settings until i fully log out.

Note: The setting (Teams Senders) seems to disappear shortly after logging in from a fresh session, and wont persist for my full session.

I have had a ticket in for 6 months about this now, and there has been ZERO movement on fixing it. Yet again, signing out and in only sometimes fixes it. We keep getting slammed by Fake Teams senders and cannot block them since the option is missing.

What it should look like:

https://preview.redd.it/vhjsq44h8h2h1.png?width=859&format=png&auto=webp&s=af60592b9a944296d16757eb31d6694786fe3ec6

What it looks like 99% of the time (Note the missing last option)

https://preview.redd.it/myssb8fj8h2h1.png?width=829&format=png&auto=webp&s=1efa56c00986e78dfc671614b8b52dd0e7123d91

My question - has anyone else experienced this? If not, can anyone tell me if you freshly sign in to Defender every day, or if you reuse your session from yesterday? Would also appreciate it if maybe you could reuse an old session and check for me if the setting is missing.

https://preview.redd.it/lbx1l5ft2b2h1.png?width=712&format=png&auto=webp&s=3f2ec49bef40ff73fa020c4e6a56e79e95580728

We are starting to have this issue for many customers...

anybody has the same issue?

Hi all,

We have a client that has a trust between their on prem AD and another on prem AD. We have deployed defender for identity on the client AD.

We get recommendations for the trusted AD from the other company which we do not manage. It affects the secure score and makes the overview of actions to take less clear. Ideally the other AD environment will be secured on all the recommendations, but that is not up to us :)

Is there a way to exclude the other on prem AD from security recommendations completely? I already tried the global exclusions under settings -> identity -> global excluded entities -> domain.

Hi there,

running into a weird issue with Microsoft Defender for Identity and wondering if anyone else has seen this.

Our v3 sensors stopped working out of nowhere. No obvious errors beforehand, just suddenly no data / no activity coming through from that sensor.

What’s odd:

• We still have two v2 sensors running fine in the same environment
• No configuration changes were made recently (no updates, no policy tweaks, nothing)
• Connectivity and domain controller health look normal from what I can tell

Things I’ve checked so far:

• Basic connectivity (seems OK)
• Defender portal – sensor just shows as inactive

Feels like the v3 sensor just dropped off completely while v2 keeps chugging along without any issues

Has anyone experienced something similar with v3 sensors specifically?
Any known issues, logs I should dig into, or things that tend to break silently?

Thank you 😄

I have enabled Tamper protection at Tenant level in Defender portal. But I see on some devices, it is still showing disabled. What am I missing here?

I have a technical question about how Microsoft Defender for Endpoint (MDE) and Windows Sandbox interact at the network level.

The scenario: Host PC with MDE and Network Protection enabled. Host alerts are regularly forwarded to a SIEM/SOAR. I open Windows Sandbox on the host PC and, from inside the isolated environment, I try to browse a known malicious site (e.g., phishing or C2).

The question: Considering I'm using the Sandbox, does the host's Network Protection still manage to intercept the request, block it, and trigger the alert to the SIEM? Or does the Sandbox isolation "hide" the traffic from the host's Defender, preventing the alert from triggering?

We are looking to onboard crowdstrike as our primary av and EDR solutions. I can’t find anything on how this will affect telemetry to e5 solutions we have like purview, defender for cloud apps, and other solutions. From what I can tell the only thing it will affect is quarantining of files. Will we still get edr telemetry into Microsoft incidents? Will purview still see sensitive data we’ve classified? Anyone done something similar?

Im trying to understand in depth the many rules of Defender.

Under Endpoints -> Device Groups you have to group devices and apply the level of remediation. I did Full Remediation for all.

But already when you implement the AV, you have settings to "Block processes" "Block malware" and various ASR rules.

Is there a conflict here? If a device is onboarded on defender, with all restrictive AV policies, does it need to be in a Full Remediation group? What happens if it isnt?

Hey everyone,

I have been doing some hands-on testing with Microsoft Defender for Cloud Apps session policies and CA App Control and stumbled across some behaviour that is confusing me.

My understanding of how it works: The Conditional Access policy with "Use Conditional Access App Control -- Use custom policy" session control acts as the on-ramp that routes the user's browser session through the MDCA proxy. Once routed, MDCA enforces the session policy rules like block downloads, block uploads etc.

What I found through testing: I disabled the CA policy entirely and left only the MDCA session policy active with a user filter scoped to my own account. When I tried to download a file from SharePoint, the download was still blocked even though:

• There was no monitoring banner
• The URL did not change to .mcas.ms
• The CA policy was completely disabled

This suggests the session policy is enforcing independently without the CA policy routing the session through the proxy.

My environment:

• Microsoft 365 E5
• Microsoft Defender for Endpoint P2 integrated with MDCA
• Managed Windows device enrolled in Intune
• Session policy type: Control file download with inspection
• Filter: specific user account

My theories:

1. The MDE integration is allowing MDCA to enforce session policies at the endpoint level rather than through proxy routing
2. MDCA has a separate enforcement mechanism for directly targeted users that does not rely on proxy routing
3. The CA policy is only needed for the monitoring banner and proxy routing but not for actual policy enforcement

Has anyone else encountered this? Is this expected behaviour or something worth investigating further?

Trying to unblock one of our C++ devs. They are on VS 2022 building a native projectS and Defender (MsMpEng) was sitting at ~70% CPU during links..

What we've done so far:

Ran MDAV Performance Analyzer, confirmed link.exe scanning .lib files in Windows Kits\10\Lib was the hot path.

Added Intune AV exclusions for link.exe (wildcarded across VS year/edition/MSVC version) plus the Windows Kits Lib/Include folders and the MSVC toolset's own lib folder.

Enabled Dev Drive on L:, they moved the work there, Defender now async-scans it.

But they complained agian. We ran Performance Analyzer again and the new top offender is the VS Installer package cache (C:\ProgramData\Microsoft\VisualStudio\Packages) eating ~900s of scan time on .vsix payloads whenever VS updates.

What do you think the right approach here? Should we keep chasing whatever clogs resources and mde and add to exclusion.

I am trying to be minimal in exclusions as possible.

Are my exclusions approach correct? Or will it come to bite my butt in the future?

Current excl:

Excluded Paths

C:\Program Files (x86)\Windows Kits\10\Lib,

C:\Program Files (x86)\Windows Kits\10\Include, C:\Program Files\Microsoft Visual Studio\*\*\VC\Tools\MSVC\*\lib,

C\ProgramData\Microsoft\VisualStudio\Packages

Excluded Processes

C:\Program Files\Microsoft Visual Studio\*\*\VC\Tools\MSVC\*\bin\Hostx64\x64\link.exe,

C:\Program Files\Microsoft Visual Studio\*\*\VC\Tools\MSVC\*\bin\Hostx64\arm64\link.exe

Hi, we are blocking most AI already in our environnement (some are allowed) but the question is how to automatically block new discovered AI

I tried to make an app discovery policy saying to unsaction Generative AI but it seems to take in note those we want to allow is there a way to make sure it only blocks NEW discovered AI and not touch those we do not allow?

Thanks

This was kind of an interesting/fun case, so I thought I'd share the story here:

We've been using secure score as a gross metric to make our overall security efforts more translatable to management. We had a couple of items that had just one machine holding us up from capturing full points. When we looked at the workstation in question, it didn't follow our standard naming convention despite having a bunch of markers that clearly identified it as one of ours. When we checked it's serial number in Intune, it was definitely ours and still under warranty.

I opened a live response session and was browsing the user folders. When I went to one set of user folders, they contained several identifying documents, including a FL driver's license. I used Live Response's "get" function to DL those files. My org is in a middle Atlantic state. I went to the guy's FB profile, and it contained Cyrillic characters that Google identified as Ukrainian.

I then remembered that we had a contractor (who was also Ukrainian) whom we had identified as potentially engaging in activities that my infosec team had identified as shady previously. I checked that contractor's FB profile, and he and this FL guy are FB friends; gotcha, fucker.

I turned all this over to our legal dept and our infrastructure director. Good times are going to ensue next week.

This whole thing was super fun in a "figuring out a puzzle" kind of way. Our findings are going to have an impact on this guy, and on the agency that sponsored this contractor into our org, but that's not my problem; my team and I are just the ones who figured out that this guy was stealing from us.

Edit/update: turned all info over to our police. They are now going to do police-y stuff

Hi everyone,

Curious how other teams are handling the “knowledge management” side of Defender XDR / MDE.

At the moment we have some many notes in OneNote, but it’s starting to get messy and not very useful during actual triage. We’re trying to find a better way to document things like:

• Playbooks for custom detections / recurring KQL-based alerts
• Notes for alerts that keep coming back on the same assets or same type of activity (that we for some reason cannot filter)
• Known benign / expected behaviour for specific devices, users, apps, etc.
• Working incidents with multiple analysts without stepping on each other. I really don't like the comment experience in the security portal. And e.g. teams doesn't archive the comments in context of the incident.
• Lessons learned after bigger incidents, so we don’t repeat the same investigation every time
• Finding related incidents, with notes on those incidents, so you're not figuring it out all over again when a similar incident has already been handled.

Defender incident comments exist, but in practice I don’t find the user experience good enough for proper investigation notes, handover, or building any kind of useful knowledge base. OneNote works okay for storing information, but searching, ownership, versioning and linking it back to alerts/incidents is not great.

For those of you running Defender XDR day to day:

1. Where do you keep your internal playbooks and investigation notes?
2. Do you use SharePoint, Confluence, ServiceNow, something else?
3. Do you document recurring alerts per alert title, per detection rule, per asset, or in some other way?
4. How do you handle handover when multiple people work the same incident?
5. How do you communicate with each other? And do you save that communication in the context of the incident?

Not looking for a “perfect SOC platform” answer, more interested in what actually works in practice without becoming another admin burden.

Thanks!

I am proud to announce the release of Crow-Eye v0.10.0. This milestone marks the official launch of The Eye a robust intelligence layer designed to integrate your own AI agents directly into Crow-Eye, This isn't just a regular update; it’s a massive milestone for us . My goal from day one has been to build an ecosystem that doesn't just chase known signatures, but actually gives investigators the power to hunt zero-days

But as we celebrate this release and introduce our new AI layer, we need to talk about the elephant in the room.

The Problem with AI in Forensics

There’s a huge rush right now to slap AI onto cybersecurity tools, and honestly, a lot of it is dangerous. We are seeing "black box" solutions where investigators feed raw data into an LLM and just trust the answers it spits out.

In DFIR, an AI hallucination can ruin a case. An answer without mathematical, binary proof is worthless. If an AI agent cannot anchor its reasoning to exact offsets, hashes, and unmanipulated timestamps, we cannot trust it. To fix this, I realized we had to architect a system where the AI is bound by the exact same strict evidentiary rules as a human analyst.

The Starting Line: Automated Triage

Before the AI even wakes up, Crow-Eye does the heavy lifting. When you launch The Eye, the platform immediately runs a high-speed Automated Triage phase.

It queries the underlying SQLite databases to map out the ground truth: active users, execution histories, accessed files, USB devices, and Auto Run configs. This builds a comprehensive Initial Report. This report isn't the final investigation it’s the baseline. It’s the verified starting line before we let the AI touch the data.

The Brain of "The Eye"

I believe you should have total control over your data and your analytical "brain." That’s why The Eye is completely modular. You can plug in whatever intelligence fits your environment:

• Cloud AI Models: Hook up your public API keys for high-performance reasoning.
• Offline Servers & Local Inference: For air-gapped labs where privacy is non-negotiable.
  • Dev Note: A lot of my testing and development for The Eye was actually done using LM Studio and Google’s open-weights models (like the Gemma family). If you're a solo investigator, running Gemma locally on your own machine is incredibly powerful. Just a tip: push your context window as high as possible to handle the dense forensic payloads!
• CLI Agents: If you are a developer or researcher, you can hook up your own custom-built local agents, or seamlessly pipe in tools like Claude Code and the Gemini CLI.

https://preview.redd.it/zdg32192ic0h1.png?width=2023&format=png&auto=webp&s=a1458500b3765ccb1a7fb4018a9dcd2203bd7a1a

Keeping the AI Honest: The Ghassan Elsman Protocol (GEP)

Triage gives us the data, but the Ghassan Elsman Protocol (GEP) ensures the AI doesn't mess it up. The GEP is a strict set of rules hardcoded into the workflow to maintain a perfect chain of custody:

1. Case Awareness: The Initial Report is injected directly into the prompt to ground the AI in reality.
2. Pre-Flight Ping: Validates backend connectivity to stop silent failures.
3. Evidence Anchoring: Automatically tags and preserves raw hashes, IPs, and timestamps in the chat history.
4. Chain of Custody: Every truncation or data preservation event is meticulously logged.
5. Non-Repudiation: Messages are assigned deterministic, hash-linked IDs so records can't be altered.
6. Context Pinning: Critical evidence is locked and excluded from automated AI summarization.
7. Tool Traceability: Every tool the AI uses (like querying LOLBAS) is logged with exact execution counts.
8. Machine-Readable Synthesis: You get a clean JSON audit trail at the end to prove compliance.

What's Next: Bridging Analysis and Anatomy

While The Eye handles the high-speed analysis, our educational hub, Eye Describe, In upcoming updates, we are going to start building a bridge between these two tools. The goal is to gradually integrate visual references alongside the AI's findings. We want to reach a point where the AI doesn't just give you an answer, but helps point you toward the structural anatomy of the artifact it analyzed. It’s an iterative, ongoing project, but we believe it is an important step toward total forensic transparency.

This is the very first release of The Eye. You might hit a few bumps connecting to certain local backends or managing specific CLI tools, but we are actively squashing bugs and refining the experience over the next few weeks. Please submit any issues you find!

The latest source code and release are available right now on our GitHub. For those waiting for the compiled .exe version, it will be dropping very soon on our official website.

GitHub : https://github.com/Ghassan-elsman/Crow-Eye

good hunting

Microsoft Defender XDR now provides visibility into devices that still need this update, making it easier to track readiness and reduce exposure across the environment.

Exposure Management → Recommendations → Devices → Misconfigurations (good adjustment if you have also Windows Servers onboarded to Defender for Endpoint P2)

https://preview.redd.it/0zmvahs01g0h1.png?width=1903&format=png&auto=webp&s=a04983627c933f6ad2ddeca62445ccc40a85e1cd

https://preview.redd.it/liu81hs01g0h1.png?width=1901&format=png&auto=webp&s=45ac528a844e4c5bac2af9344705953e14be4122

Hello all,

Recently defender portal update hasn't got any arrows to hide the sidebar/left blade. This seems like a downgrade to previous portal

https://preview.redd.it/z2r6vgj7hf0h1.png?width=1705&format=png&auto=webp&s=f7b8f024700d04569dbc8e2a623956be28b751c7

We often see Defender being installed on non-corporate devices. In some cases, users access corporate services from their personal computers (Teams, desktop Outlook), or simply connect their work profile to Windows, which then triggers automatic antivirus enrollment on that device.

What I currently don’t understand is how these devices should be properly removed afterwards. What is considered the best practice for offboarding Defender from non-corporate devices? So far, I haven’t found a reliable way to remove it remotely.

Also, how can we prevent Defender from being automatically installed on personal/non-corporate devices in the first place?

Has anyone experienced problems with the Standard (baseline) preset setting for email filtering?

There are standard and strict modes. Everyone starts with what MS calls "built-in" protection. I have been trying to enable the standard preset for a handful of users to test this. However, it remains toggled off after I created it and when I forcefully enable the selected policy within Email/Collaboration > Policies/Rules > Threat Policies > Anti-phishing, anti-spam, anti-malware

nothing happens. I get no message confirming. The status stays off.

https://security.microsoft.com/presetSecurityPolicies

Is this not something useful within MS365 as a feature they offer? We were hoping to try this as a test, then enable widely if there are no problems with messages being received.