The Fileless Paradox: How My 33-Day-Old Research Became Today's Ransomware Reality
33 Days Before BARADAI Emerged 🔴 Before You Read: What Is This Article About? This is the first article I have published on Microsoft Tech Community, and this is not a standard threat report. This is the story of being right before anyone believed it — and of a ransomware family called BARADAI that proved it. On April 5, 2026, I published a technical research article documenting, in detail, a fileless malware architecture that operated entirely in RAM using steganography and Windows Registry persistence. When I shared it on social media, the reactions were immediate and brutal: “A fileless payload cannot be persistent. If it leaves no trace on disk, it cannot survive a reboot.” “This technique is entirely theoretical. No real threat actor would ever use this in production.” “You cannot have persistence without leaving traces. Pick one.” And the most absurd ones: “Stop writing articles with AI.” “This level of technical detail is unrealistic — did AI generate this?” “Forensic artifacts cannot be erased. What kind of technique is this?” At that moment, I could not prove myself. I had a working proof-of-concept. I had built the architecture myself. The technical logic was sound. But I did not yet have a real-world threat actor using it in production. 33 days later, BARADAI appeared. And it used the exact same playbook I had written. This article is the first volume of the “We Saw It Coming” series. In this series, I correlate my independent research with emerging real-world threats, document technical overlaps, and provide actionable detection and defense guidance for Microsoft environments. Right now, I am actively trying to reverse and decrypt BARADAI. I do not yet have a definitive solution. But I am publishing this journey because my goal is to finalize a solution by collecting additional logs and intelligence. 📌 Table of Contents The Moment Nobody Believed 33 Days Later: Meet BARADAI The B-Family: Shared Infrastructure Ecosystem Side-by-Side: Technical Overlap Analysis Deep Dive: The Fileless Paradox — How Both Architectures Work The PAIDMEMES Anomaly: Forensic Residue Inside BARADAI My Technique vs BARADAI: Shared Technical Patterns Microsoft Sentinel Detection Rules (KQL) MITRE ATT&CK Mapping Decryption Research and My Current Approaches Defensive Recommendations Sources and References ------------------------------------------------------------------------------ 1. The Moment Nobody Believed April 5, 2026 — A Research Paper, a Community, and Silence On April 5, 2026, I published a detailed technical research article on Medium titled: “STEGOMALWARE — PNG Persistence Through Steganography and Windows Registry” The article documented a complete attack architecture that I designed and tested from scratch in a controlled laboratory environment. My core thesis was this: A fileless malware strain can achieve persistent, reboot-resilient execution without ever writing a malicious executable to disk — by hiding its payload inside the pixels of a PNG image using LSB steganography and leveraging the Windows Registry for persistence. I demonstrated this by building a keylogger. The architecture had four defining characteristics: Feature 1 — Fileless Execution (RAM-Only) The malicious payload never touches disk as an executable file. Instead, a small, “clean-looking” loader script extracts hidden code from the pixel data of a PNG image and executes it directly in RAM. No .exe, no .py, no .dll on disk. Traditional antivirus file-scanning mechanisms are effectively blind to this. Feature 2 — Registry-Based Persistence Contrary to critics claiming that fileless malware cannot survive reboots, the loader writes itself into the Windows Registry Run key: HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run This means that every time Windows starts, the loader executes again, extracts the payload from the PNG, and runs it back in memory. The malware lives in the Registry — not on disk. Feature 3 — Process Masquerading I compiled the loader under the name svchost.exe and assigned it a Windows service icon. When viewed in Task Manager, it appeared indistinguishable from a legitimate Windows system process. Feature 4 — Self-Repair (Self-Integrity Check) The loader continuously validated both its Registry entry and its file copy. If an antivirus product deleted the file or removed the Registry entry, the loader detected the modification and restored itself during the next execution cycle. Feature 5 — Intelligent Data Collection The keylogger I built automatically embedded collected data into the pixels of a PNG image every 10 characters or every 30 seconds — whichever occurred first. After each cycle, it reset itself, cleared temporary memory artifacts, and initiated a fresh collection loop. This architectural design enabled the malware to remain undetected on a system for months. Because there was no ever-growing log file on disk — the data was continuously transferred into images. ------------------------------------------------------------------------------------------ The Reactions The reactions I received when sharing this research did not surprise me, but they disappointed me. Technical objections: “Fileless malware, by definition, cannot survive reboots. No disk means no persistence.” “Forensic evidence cannot be erased. This makes no technical sense.” “If you are writing to the Registry, then it is not truly fileless.” Personal attacks: “Stop writing with AI.” “If you can perform technical analysis this detailed, why has nobody heard of you before?” “Copied from AI — even the formatting looks AI-generated.” This feedback revealed two things: First, people fundamentally misunderstood the concept of fileless malware — they were confusing “fileless execution” with “leaving absolutely no traces anywhere.” The Registry is not a traditional file in the conventional sense, yet it remains a persistent storage mechanism resilient across reboots. Second, it demonstrated how easily independent researchers are dismissed. Research not published by a major corporation or university was automatically labeled “AI-generated” or “theoretical.” At that moment, I could not prove myself. 33 days later, BARADAI proved me right. ------------------------------------------------------------------------------ 2. 33 Days Later: Meet BARADAI May 5–8, 2026 — A New Threat Surfaces On May 5, 2026, researchers at PCrisk documented a new ransomware sample submitted to VirusTtl. On the same day, CYFIRMA’s underground forum monitoring team flagged it in their threat intelligence feeds. By May 8, CYFIRMA’s Weekly Intelligence Report had published the first structured analysis. The threat was named BARADAI — derived from the extension it appends to encrypted files: .BARADAI -------------------------------------------- What Is BARADAI? BARADAI is a Windows ransomware variant belonging to the MedusaLocker family. MedusaLocker has been active since late 2019 and remains one of the most prolific and long-lived ransomware-as-a-service (RaaS) operations in the threat landscape. BARADAI is a specific variant of the MedusaLocker v3 architecture — sometimes tracked in threat intelligence repositories as “BabyLockerKZ.” Detection names across major security vendors: Microsoft Defender: Ransom:Win64/MedusaLocker.MZT!MTB ESET: Win64/Filecoder.MedusaLocker.A Avast: Win64:MalwareX-gen [Ransom] Kaspersky: HEUR:Trojan-Ransom.Win32.Generic ------------------------------------------------------------ How Does It Operate? BARADAI follows a double-extortion model. Silent Phase (Reconnaissance) After initial access, BARADAI does not immediately begin encryption. Instead, it performs systematic reconnaissance: -Enumerates running processes -Maps network topology -Collects browser-stored credentials -Harvests session cookies and SSL certificates -Captures desktop screenshots -Exfiltrates collected data to attacker-controlled C2 infrastructure Encryption Phase After exfiltration is complete, BARADAI activates its cryptographic payload: -AES-256-CBC for file content encryption -RSA-4096 for key protection Extortion Phase A ransom note (read_to_decrypt_files.html or WHATS_HAPPEND.txt) is dropped into every encrypted directory. Victims are given a 72-hour deadline. If payment is not made before expiration, stolen data is published on the group’s Data Leak Site (DLS). ------------------------------------------------------------------- Confirmed Targeting as of May 2026 Geographies -United States -Brazil -France -Australia -Italy -Israel -Malaysia Sectors -Education -Manufacturing -Engineering -Retail -Logistics -NGOs Ransom Demand Range -USD $10,000 — $80,000 per incident (CYFIRMA, May 2026) ------------------------------------------------------------------ 3. The B-Family: Shared Infrastructure Ecosystem One of the most important findings that emerged during my analysis was this: BARADAI is not operating alone. Threat intelligence monitoring identified a cluster of MedusaLocker variants sharing: -The same naming conventions -Similar code architecture -And most critically — the same Tor-based infrastructure I named this cluster: “The B-Family” --------------------------------------------- Evidence of Shared Infrastructure The strongest evidence of coordination inside the B-Family is not behavioral similarity — it is shared infrastructure. BARADAI’s ransom note lists the following Tor hidden service for victim negotiations: t33zoj4qwv455fog7qnb2azi5xcdxkixughmmduzbw2rtdgryqfbh6id.onion This is identical to the Tor address listed as the Data Leak Site and file leak server for BAVACAI — independently verified by ransomware.live, which identified the server running NGINX 1.24.0. PCrisk’s BARADAI documentation also includes screenshots of the leak site using the filename prefix: bavacai- This is structural evidence confirming that the same backend infrastructure serves both variants. What This Means The B-Family is not a collection of copycat operations. It is a single operation — or a tightly coordinated RaaS affiliate ecosystem — using different “brand names” per campaign in order to complicate attribution, tracking, and law enforcement disruption. ----------------------------------------------------------- Known Victims (BAVACAI DLS — Shared Backend) As of May 8, 2026, the BAVACAI DLS listed 16 victims — all published simultaneously on May 5. ------------------------------------------------------------ 4. Side-by-Side: Technical Overlap Analysis This section is the core of the article. The table below correlates the exact techniques documented in my April 5, 2026 research with the verified BARADAI behaviors documented by CYFIRMA, PCrisk, and the broader MedusaLocker analysis corpus. The conclusion is direct and unavoidable: The architecture I built, tested, documented, and published in a controlled laboratory environment on April 5, 2026 — the same architecture the community dismissed as “theoretical,” “AI-generated,” and “impossible” — was operationalized by a real threat actor 33 days later. -------------------------------------------------------- 5. Deep Dive: The Fileless Paradox Let us settle the debate permanently. The Misconception: “Fileless Malware Cannot Be Persistent” The argument I repeatedly encountered was this: “If malware does not leave files on disk, it cannot survive a reboot because RAM is volatile.” Technically correct. Strategically incomplete. It is true that RAM-resident code disappears when the system powers off. However, persistence does not require the malicious payload itself to reside on disk. It requires a mechanism that re-executes the payload after reboot. Those are two different things. -------------------------------------------------------------- The Architecture: How It Actually Works ┌──────────────────────────────────────────────────────────┐ │ ATTACK ARCHITECTURE │ │ │ │ DISK (minimal footprint): │ │ ┌──────────────────────────────────────────────────┐ │ │ │ loader.exe (masquerading as svchost.exe) │ │ │ │ cover_image.png (contains hidden payload) │ │ │ └──────────────────────────────────────────────────┘ │ │ │ │ │ REGISTRY (persistence): │ │ │ ┌──────────────────────────────────────────────────┐ │ │ │ HKCU\...\Run\WindowsUpdateService │ │ │ │ → points to loader.exe │ │ │ └──────────────────────────────────────────────────┘ │ │ │ │ │ ON EVERY BOOT: │ │ │ Registry triggers → loader.exe executes → │ │ Reads PNG pixels → extracts payload → │ │ Loads into RAM → executes │ │ (No malicious .exe is ever written to disk) │ │ │ │ RAM (execution): │ │ ┌──────────────────────────────────────────────────┐ │ │ │ Keylogger / RAT / Ransomware module │ │ │ │ Executes entirely in memory │ │ │ │ Invisible to disk-based AV scanning │ │ │ └──────────────────────────────────────────────────┘ │ └──────────────────────────────────────────────────────────┘ Only the loader exists on disk — and the loader itself is a small, legitimate-looking executable without a malicious signature. The malicious payload lives in: -The pixel data of the PNG image (steganographically encoded) -RAM (during active execution) The Registry provides the trigger mechanism — not the payload itself. That was the exact distinction critics failed to understand. ------------------------------------------------------------------ Why It Evades Traditional Detection BARADAI’s Implementation BARADAI uses the same logical architecture at larger scale. The MedusaLocker v3 binary: - Achieves persistence via Registry Run Key: HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\BabyLockerKZ -Executes core ransomware logic in memory without writing recoverable payload components to disk -Uses Parent PID Spoofing (T1134.004) to appear as a child process of explorer.exe or svchost.exe -Restores itself through persistence mechanisms if binaries are deleted ------------------------------------------------------------------------------ 6. The PAIDMEMES Anomaly: Forensic Residue Inside BARADAI One of BARADAI’s most distinctive — and frankly bizarre — technical characteristics is its configuration and key storage mechanism. Unlike most ransomware variants that attempt to keep all cryptographic material exclusively in volatile memory, BARADAI writes directly into the Windows Registry under an extremely unusual hive: HKCU\SOFTWARE\PAIDMEMES\PUBLIC HKCU\SOFTWARE\PAIDMEMES\PRIVATE - HKCU\SOFTWARE\PAIDMEMES\PUBLIC stores the Base64-encoded RSA public key extracted from the malware configuration. - HKCU\SOFTWARE\PAIDMEMES\PRIVATE stores encrypted runtime state and configuration parameters required for persistence across multiple execution instances. ------------------------------------------- Why This Matters The PAIDMEMES Registry hive is not random — it serves a specific operational purpose. When BARADAI is launched with the -network flag (instructing it to encrypt network shares), it spawns a secondary instance of itself as a non-elevated process. By storing cryptographic keys and configuration inside the Registry, that secondary instance — even without administrative privileges — can access everything necessary to continue the attack. These two Registry artifacts represent your highest-confidence BARADAI detection signals: HKCU\SOFTWARE\PAIDMEMES (Key creation = active infection) HKCU\...\Run\BabyLockerKZ (Persistence = infection survived reboot) ------------------------------------------------------------ 7. My Technique vs BARADAI: Detailed Technical Similarities Now let us go deeper technically and explain why I believe I am one of the people closest to understanding BARADAI. 7.1 Payload Concealment: LSB Steganography My Technique I replaced the least significant bits (LSB) of RGB channels in PNG pixels with Base64-encoded keylogger payload bits. A 1/255 modification inside an 8-bit value is visually imperceptible to the human eye. In BARADAI The stegomalware technique forms the core of payload transportation. The same LSB logic applies: -No visible image corruption -No signature-based scanner triggers -Payload blended into image “noise” Shared Point Mathematically, it is the same approach. The only difference is scale: I concealed a keylogger. BARADAI conceals a ransomware module. -------------------------------------------------------- 7.2 Fileless + Registry: The “Impossible” Combination My Technique I registered my loader under: HKCU\...\Run\WindowsUpdateService Every time Windows booted, the loader executed, read the PNG, extracted the payload into RAM, and launched it. A .py file never existed on disk. In BARADAI HKCU\...\Run\BabyLockerKZ Exactly the same mechanism. Same Registry path. Same logic. Same “fileless yet persistent” paradox. ------------------------------------------------- Shared Point When critics claimed these two concepts could not coexist, they were wrong. Both BARADAI and I proved it. 7.3 Process Concealment: svchost.exe Masquerading My Technique I compiled the loader with PyInstaller under the name svchost.exe and assigned it a Windows service icon. Inside Task Manager, it appeared identical to a legitimate system process. In BARADAI BARADAI uses Parent PID Spoofing. Through Windows API manipulation, it makes execution appear as if initiated by svchost.exe or explorer.exe. EDR behavioral engines typically flag unknown processes performing system-level modifications. This technique bypasses those checks. Shared Point Same concealment strategy. Different implementation layer. 7.4 Timers and Silent Collection My Technique The keylogger embedded data into PNG images every 10 characters OR every 30 seconds — whichever occurred first. After each cycle: -Temporary memory artifacts were cleared -The process reset -No ever-growing log file existed on disk This is why antivirus products could not see it. This is why it could remain undetected for months. In BARADAI “Ghost Software.” After initial compromise, BARADAI does not immediately encrypt. It silently waits. Harvests credentials. Maps the network. Exfiltrates data. Encryption is the final signature. Shared Point Both architectures rely on a “silent hunter” model. I used 30-second image-based exfiltration loops. BARADAI remains dormant for days or weeks while collecting intelligence. The logic is identical. Only the timescale differs. ---------------------------------------------------------------- 7.5 Why I Believe I Am One of the People Closest to Solving BARADAI These similarities are not coincidence. They reflect the same technical mindset reaching the same solutions to the same problems. Because I built this architecture from scratch: -I understand its weak points — because I encountered the same weak points myself -I can reverse-engineer LSB steganography workflows — because I wrote the same algorithm -I understand Registry-based configuration logic — the PAIDMEMES hive pattern is familiar to me - I understand interruption points inside timer-based collection loops — because I built the same cycle architecture myself ------------------------------------------------------------------------------ 8. Microsoft Sentinel Detection Rules (KQL) The following Kusto Query Language (KQL) queries are designed for deployment in Microsoft Sentinel. They target specific behavioral artifacts associated with BARADAI and the broader MedusaLocker family. Deploy all three as scheduled analytics rules. Rule 1: PAIDMEMES / BabyLockerKZ Registry Artifact Detection High confidence. Detects exact forensic strings unique to MedusaLocker v3 / BARADAI. If This Rule Triggers The device is actively infected with BARADAI or the malware has successfully established persistence. Treat as a P1 incident. Immediately isolate the endpoint. Rule 2: Shadow Copy & Backup Deletion Chain Detection High confidence. Detects BARADAI’s recovery-destruction sequence. If This Rule Triggers A ransomware payload is actively preparing for encryption. This is your final detection window before data loss begins. Immediately isolate the affected endpoint and every reachable network share. Rule 3: EnableLinkedConnections — Network Share Privilege Escalation Detection Medium-High confidence. Detects BARADAI’s technique for accessing administrator-mapped network drives from non-elevated processes. If This Rule Triggers An attacker is preparing to encrypt network shares normally visible only to administrator-level processes. This is a pre-encryption lateral movement signal. ---------------------------------------------------------------- 9. MITRE ATT&CK Mapping ------------------------------------------------------------------------------ 10. Decryption Research and My Current Approaches Let me be completely transparent. Current status: There is no verified public decryptor available for BARADAI. -The No More Ransom project lists no decryptor for any MedusaLocker v3 / BabyLockerKZ variant -The AES-256-CBC + RSA-4096 implementation is mathematically sound -Historical decryptors existed only for significantly older MedusaLocker v1 and early v2 variants by exploiting key sanitization weaknesses in memory management -Those vulnerabilities were patched in v3 What We Know About the Encryption BARADAI uses intermittent encryption for large files: -Files larger than ~7.7MB are not fully encrypted -The malware encrypts 750KB, skips 250KB, encrypts another 750KB, and repeats This dramatically reduces encryption time while still rendering the file structurally unusable. --------------------------------------------------------------- What I Am Currently Researching I am currently analyzing the BARADAI binary from multiple angles: PRNG Weaknesses I am investigating the entropy source used during AES key generation. If the PRNG is insufficiently random, the effective key space may be reducible. Key Sanitization Behavior I am investigating whether AES keys remain in memory after usage. This weakness existed in MedusaLocker v1 and v2 and enabled historical decryptors. Although patched in v3, implementation mistakes remain possible. PAIDMEMES Registry Storage Analysis The PAIDMEMES hive stores runtime state. I am investigating whether this storage area contains recoverable cryptographic material. Registry-stored cryptographic data could provide a viable decryption foothold. Weaknesses in Intermittent Encryption The 750KB-encrypt / 250KB-skip pattern enables structural comparisons between encrypted and unencrypted regions. Known file formats (.docx, .xlsx, etc.) contain predictable header structures. This creates potential for partial known-plaintext attacks. ------------------------------------------------------------------------------ I will publish my findings in Vol.4 of this series regardless of the outcome. ------------------------------------------------- If You Are a BARADAI Victim -Do not pay the ransom until all alternatives are exhausted -Contact professional incident response services -Preserve all encrypted files and ransom notes — a future decryptor may eventually become available -Regularly monitor nomoreransom.org ---------------------------------------------------- 11. Defensive Recommendations Priority 1: Phishing-Resistant MFA (Against AiTM) Traditional MFA — push notifications, SMS codes, authenticator apps — can be defeated by AiTM reverse-proxy attacks. Deploy: -FIDO2 hardware security keys (YubiKey, etc.) -Windows Hello for Business These technologies cryptographically bind authentication tokens to the legitimate TLS session of the login portal. Stolen cookies become useless in separate sessions. ------------------------------------------------------- Priority 2: Eliminate RDP Exposure BARADAI’s primary initial access vector is exposed RDP on TCP 3389. -Disable Internet-facing RDP at the perimeter firewall -Enforce MFA + VPN for all remote administrative access -Implement account lockout policies and Network Level Authentication (NLA) Priority 3: Immutable Backups BARADAI deletes Volume Shadow Copies via vssadmin. Implement: -A 3–2–1 backup strategy with at least one offline/immutable copy -Azure Immutable Blob Storage (WORM) -Multi-user authorization for backup vaults -Monthly restoration testing --------------------------------------------- Priority 4: FSRM Canary Files Configure Windows File Server Resource Manager (FSRM): Immediately alert when files with extensions: .BARADAI .BAVACAI .BASANAI .BAGAJAI are created. Trigger automated scripts that: -Terminate the originating user session -Revoke network share access -------------------------------------------------- Priority 5: Deploy the Sentinel KQL Rules Above The three rules in Section 8 provide layered behavioral detection that signature-based tooling cannot replicate. Deploy them before an incident occurs. -------------------------------------------------------------------------- Priority 6: Zero Trust Architecture BARADAI’s EnableLinkedConnections Registry modification allows standard user processes to encrypt administrator-mapped drives. -Segment backup servers, Domain Controllers, and critical infrastructure -Require hardware-backed MFA for sensitive segments -Implement least privilege and Just-In-Time (JIT) administrative access with Azure PIM ------------------------------------------------------------------------ 📢 Call to Action: Collective Intelligence I started this research alone. But disrupting the impact of the B-Family requires collective effort. If your organization or threat-hunting operations have observed additional logs, unusual network traffic, or alternative steganographic payload samples associated with the B-Family (BARADAI, BAVACAI, BASANAI, etc.), do not remain silent. Data Sharing You may share anonymized IoCs or log artifacts with us. and Direct Contact If you have technically significant observations or findings related to BARADAI analysis, you can contact me directly through my Webex profile. Webex Contact - email address removed for privacy reasons Our collective security depends on the aggregation of these small signals. --------------------------------------------- Sources and References For technical verification and further investigation, refer to the following resources: Threat Intelligence & Ransomware Reports CYFIRMA: Weekly Threat Intelligence Report (2026–05–08) Ransomware.live: BAVACAI Group & DLS Infrastructure PCrisk: BAVACAI | BAGAJAI | BASANAI Analysis Technical Foundations & MITRE TTPs CISA: MedusaLocker Advisory (AA22–181A) Picus Security: MedusaLocker TTPs and Simulation Barracuda: GhostFrame Phishing Kit Spotlight (2025–12–04) Detection & Response Tools Microsoft Sentinel: Official Shadow Copy Deletion Analytics Rule GitHub (Bert-JanP): Hunting Queries and Detection Rules No More Ransom: Global Decryption Tools Repository Cassandra MARE Independent Research Deniz Tektek: Stegomalware & Fileless Persistence (2026–04–05) https://medium.com/@deniizz/stegomalware-steganografi-ve-windows-registry-ile-kalıcılık-sağlayan-png-01e50849a218 Cassandra Community: Initial BARADAI Analysis (2026–05–14) https://medium.com/@cassandracommunity/baradai-ransomware-hayalet-yazılım-ı-parçalarına-ayırıyoruz-0c04bb008f73 This article has been published strictly for defensive purposes. All described techniques have been analyzed within the context of threat detection and defense. This is my debut article on the Microsoft Tech Community. I am Deniz Tektek, a Red Team Operator, Cybersecurity Analyst, and Founder of the Cassandra community. My work focuses on the intersection of human psychology, IoT security, and the development of zero-trust local AI agents. This article, “The Fileless Paradox,” is the inaugural entry in my "We Saw It Coming" threat intelligence series, where I document technical overlaps between independent research and active real-world threats. What’s Next? Vol. 2: "Invisible Exfiltration" — Analyzing how BARADAI’s C2 hides in plain sight. Vol. 3: "The Human Gateway" — Why your MFA and AI-driven defenses are currently being bypassed. Vol. 4: "Cracking BARADAI" — My ongoing decryption research. Connect With Me If you want to discuss these findings, exchange logs, or collaborate on security research, please check my profile bio for contact information or connect with me via LinkedIn. I welcome all technical perspectives and peer reviews. My LinkedIn: https://www.linkedin.com/in/deniz-t-91166438a Deniz Tektek — May 2026 © Deniz Tektek & Cassandra — All Rights Reserved. Originally published on Microsoft Tech Community. Cross-posted on Medium.Security Copilot Agents in Defender XDR: where things actually stand
With RSAC 2026 behind us and the E5 inclusion now rolling out between April 20 and June 30, anyone planning SOC workflows or sitting on a capacity budget needs to get a clear picture of what is GA, what is preview, and what was just announced. The marketing pages tend to blur those lines. This is my sober look at the current state, with the operational details that matter for adoption decisions. What is actually shipping right now The Phishing Triage Agent is GA. It only handles user-reported phish through Defender for Office 365 P2, but for most SOCs that is a meaningful chunk of the L1 queue. Verdicts come with a natural-language rationale rather than just a label, which is the part that determines whether analysts will trust it. The agent learns from analyst confirmations and overrides, so the feedback loop matters more than the initial setup. There is a setup detail that is easy to miss: the agent will not classify alerts that have already been suppressed by alert tuning. The built-in rule "Auto-Resolve - Email reported by user as malware or phish" needs to be off, and any custom tuning rules that touch this alert type need review. If you skip this, the agent runs on an empty queue and you wonder why nothing is happening. The Threat Intelligence Briefing Agent is also GA. It produces tenant-tailored intel briefings on a regular cadence. Useful, but lower operational impact than the triage agents. Copilot Chat in Defender went GA with the April 2026 update. Conversational Q&A inside the portal, grounded in your incident and entity data. This is the lowest-risk way to get value out of Security Copilot and probably where most teams should start. Public preview, worth watching The Dynamic Threat Detection Agent is the most technically interesting one. It runs continuously in the Defender backend, correlates across Defender and Sentinel telemetry, generates its own hypotheses, and emits a dynamic alert when the evidence converges. Detection source on the alert is Security Copilot. Each alert includes the structured fields (severity, MITRE techniques, remediation) plus a narrative explaining the reasoning. For EU tenants the residency point is worth confirming with whoever owns data protection in your org: the service runs region-local, so customer data and required telemetry stay inside the designated geographic boundary. During public preview it is enabled by default for eligible customers and is free. At GA, currently targeted for late 2026, it transitions to the SCU consumption model and can be disabled. The Threat Hunting Agent is also in public preview. Natural language to KQL with guided hunting. Lower stakes, but useful for teams without deep KQL expertise on hand. Announced at RSAC, still preview Two agents got the headlines in March: The Security Alert Triage Agent extends the agentic triage approach beyond phishing into identity and cloud alerts. The longer-term direction is consolidating phishing, identity, and cloud triage under a single agent. Rollout is from April 2026, in preview. The Security Analyst Agent is the multi-step investigation agent. Deeper context across Defender and Sentinel, prioritised findings, transparent reasoning trace. Preview since March 26. Both look promising on paper, but Microsoft's history of preview features that take a long time to mature is well-documented. I would not plan production workflows around either of them yet. What you actually get with the E5 inclusion This is the licensing change most people are dealing with right now. Security Copilot has been part of the E5 product terms since January 1, 2026. Tenant rollout is phased between April 20 and June 30, 2026, with a 7-day notification before activation. The numbers: 400 SCUs per month for every 1,000 paid user licenses Capped at 10,000 SCUs per month, which you hit at around 25,000 seats Linear scaling below that, so a 3,000-seat tenant gets 1,200 SCUs per month No rollover, the pool resets monthly What is included: chat, promptbooks, agentic scenarios across Defender, Entra, Intune, Purview, and the standalone portal. Agent Builder and the Graph APIs are in. If you also run Sentinel, the included SCUs apply to Security Copilot scenarios there. What is not included: Sentinel data lake compute and storage. Those still run through Azure on the regular meters. Beyond the included pool you pay 6 USD per SCU pay-as-you-go, with 30 days notice before that mode kicks in. Practical things worth knowing before activation A few details that are easy to miss in the docs: Under System > Settings > Copilot in Defender > Preferences, switch from Auto-generate to Generate on demand. Auto-generate will burn SCUs on incidents nobody is going to look at. Generate on demand gives you direct control. In the Security Copilot portal workspace settings, check the data storage location and the data sharing toggle. Data sharing is on by default, which means Microsoft uses interaction data for product improvement. If your compliance position does not allow that, change it before agents start running. Changing it requires the Capacity Contributor role. Agent runs are not equivalent to the same number of analyst chat prompts. A triage agent processing fifty alerts in one run consumes meaningfully more SCUs than fifty manual prompts on the same data. If you have a high-volume phishing pipeline, model that out before you flip the switch broadly. The usage dashboard in the Security Copilot portal breaks down consumption by day, user, and scenario. Output quality depends on telemetry quality. Flaky connectors, gaps in log sources, or a high baseline of misconfigured alerts will produce verdicts that match. Connector health monitoring (the SentinelHealth table in Advanced Hunting is a sensible starting point) is a precondition. The agents only improve if analysts feed the override loop. If your team treats the verdicts as background noise rather than confirming or correcting them, the feedback signal is lost and calibration stays where it shipped. That is a process problem, not a product problem, but it determines whether any of this is worth the SCUs. A reasonable adoption order A rough sequence that minimises capacity surprises: Copilot Chat in Defender first. Lowest risk, immediate value through natural language Q&A in the investigation context. Phishing Triage Agent on a controlled subset, with a review cadence in place. Check the built-in tuning rules first. Watch the SCU dashboard for the first month before adding anything else. Let the Dynamic Threat Detection Agent run while it is in public preview, since it is default-on and free anyway. Compare its alerts against existing Sentinel detections. Security Alert Triage Agent for identity and cloud once the phishing baseline is stable. Establish a monthly review covering agent decisions, false-positive rate, SCU cost, and MTTD/MTTR trends. Technically, agentic triage is moving past phishing into identity and cloud, and the Dynamic Threat Detection Agent represents a genuine attempt at the false-negative problem rather than just another rule engine. Lizenziell, the E5 inclusion removes the biggest barrier to adoption that previously existed. The risk is enabling everything at once. Agents that nobody reviews are agents that consume capacity without delivering value, and the SCU dashboard is the only thing that will tell you that is happening. One agent, one use case, a 30-day baseline, then the next one. The order matters more than the speed.Sentinel to Defender Portal Migration - my 5 Gotchas to help you
The migration to the unified Defender portal is one of those transitions where the documentation covers "what's new" but glosses over what breaks on cutover day. Here are the gotchas that consistently catch teams off-guard, along with practical fixes. Gotcha 1: Automatic Connector Enablement When a Sentinel workspace connects to the Defender portal, Microsoft auto-enables certain connectors - often without clear notification. The most common surprises: Connector Auto-Enables? Impact Defender for Endpoint Yes EDR telemetry starts flowing, new alerts created Defender for Cloud Yes Additional incidents, potential ingestion cost increase Defender for Cloud Apps Conditional Depends on existing tenant config Azure AD Identity Protection No Stays in Sentinel workspace only Immediate action: Within 2 hours of connecting, navigate to Security.microsoft.com > Connectors & integrations > Data connectors and audit what auto-enabled. Compare against your pre-migration connector list and disable anything unplanned. Why this matters: Auto-enabled connectors can duplicate data sources - ingesting the same telemetry through both Sentinel and Defender connectors inflates Log Analytics costs by 20-40%. Gotcha 2: Incident Duplication The most disruptive surprise. The same incident appears twice: once from a Sentinel analytics rule, once from the Defender portal's auto-created incident creation rule. SOC teams get paged twice, deduplication breaks, and MTTR metrics go sideways. Diagnosis: SecurityIncident | where TimeGenerated > ago(7d) | summarize IncidentCount = count() by Title | where IncidentCount > 1 | order by IncidentCount desc If you see unexpected duplicates, the cause is almost certainly the auto-enabled Microsoft incident creation rule conflicting with your existing analytics rules. Fix: Disable the auto-created incident creation rule in Sentinel Automation rules, and rely on your existing analytics rule > incident mapping instead. This ensures incidents are created only through Sentinel's pipeline. Gotcha 3: Analytics Rule Title Dependencies The Defender portal matches incidents to analytics rules by title, not by rule ID. This creates subtle problems: Renaming a rule breaks the incident linkage Copying a rule with a similar title causes cross-linkage Two workspaces with identically named rules generate separate incidents for the same alert Prevention checklist: Audit all analytics rule titles for uniqueness before migration Document the title-to-GUID mapping as a reference Avoid renaming rules en masse during migration Use a naming convention like <Severity>_<Tactic>_<Technique> to prevent collisions Gotcha 4: RBAC Gaps Sentinel workspace RBAC roles don't directly translate to Defender portal permissions: Sentinel Role Defender Portal Equivalent Gap Microsoft Sentinel Responder Security Operator Minor - name change Microsoft Sentinel Contributor Security Operator + Security settings (manage) Significant - split across roles Sentinel Automation Contributor Automation Contributor (new) New role required Migration approach: Create new unified RBAC roles in the Defender portal that mirror your existing Sentinel permissions. Test with a pilot group before org-wide rollout. Keep workspace RBAC roles for 30 days as a fallback. Gotcha 5: Automation Rules Don't Auto-Migrate Sentinel automation rules and playbooks don't carry over to the Defender portal automatically. The syntax has changed, and not all Sentinel automation actions are available in Defender. Recommended approach: Export existing Sentinel automation rules (screenshot condition logic and actions) Recreate them in the Defender portal Run both in parallel for one week to validate behavior Retire Sentinel automation rules only after confirming Defender equivalents work correctly Practical Migration Timeline Phase 1 - Pre-migration (1-2 weeks before): Audit connectors, analytics rules, RBAC roles, and automation rules Document everything - titles, GUIDs, permissions, automation logic Test in a pilot environment first Phase 2 - Cutover day: Connect workspace to Defender portal Within 2 hours: audit auto-enabled connectors Within 4 hours: check for duplicate incidents Within 24 hours: validate RBAC and automation rules Phase 3 - Post-migration (1-2 weeks after): Monitor incident volume for duplication spikes Validate automation rules fire correctly Collect SOC team feedback on workflow impact After 1 week of stability: retire legacy automation rules Phase 4 - Cleanup (2-4 weeks after): Remove duplicate automation rules Archive workspace-specific RBAC roles once unified RBAC is stable Update SOC runbooks and documentation The bottom line: treat this as a parallel-run migration, not a lift-and-shift. Budget 2 weeks for parallel operations. Teams that rushed this transition consistently reported longer MTTR during the first month post-migration.Ingesting Windows Security Events into Custom Datalake Tables Without Using Microsoft‑Prefixed Table
Hi everyone, I’m looking to see whether there is a supported method to ingest Windows Security Events into custom Microsoft Sentinel Data Lake–tiered tables (for example, SecurityEvents_CL) without writing to or modifying the Microsoft‑prefixed analytical tables. Essentially, I want to route these events directly into custom tables only, bypassing the default Microsoft‑managed tables entirely. Has anyone implemented this, or is there a recommended approach? Thanks in advance for any guidance. Best Regards, Prabhu Kiran
Migrate MS Sentinel from one tenant to another tenant
I need to migrate Microsoft Sentinel with all its resources (playbooks, workbook, connectors, analytics rules), I would need a step by step, since I see that among the documentation that Microsoft has, it does not have it. I would like to know if there is any tool or functionality that allows me to do this, without having to rebuild everything
Unified detection rule management
Hi, I attended the webinar yesterday regarding the new unified custom detection rules in Defender XDR. I was wondering about the management of a library of rules. As with any SOC, our solution has a library of custom rules which we manage in a release cycle for a number of clients in different Tenants. To avoid having to manage rules individually we use the JSON approach, importing the library so it will update rules that we need to tune. Currently I'm not seeing an option to import unified detection rules in Defender XDR via JSON. Is that a feature that will be added? Thanks Ziv
From “No” to “Now”: A 7-Layer Strategy for Enterprise AI Safety
The “block” posture on Generative AI has failed. In a global enterprise, banning these tools doesn't stop usage; it simply pushes intellectual property into unmanaged channels and creates a massive visibility gap in corporate telemetry. The priority has now shifted from stopping AI to hardening the environment so that innovation can run at velocity without compromising data sovereignty. Traditional security perimeters are ineffective against the “slow bleed” of AI leakage - where data moves through prompts, clipboards, and autonomous agents rather than bulk file transfers. To secure this environment, a 7-layer defense-in-depth model is required to treat the conversation itself as the new perimeter. 1. Identity: The Only Verifiable Perimeter Identity is the primary control plane. Access to AI services must be treated with the same rigor as administrative access to core infrastructure. The strategy centers on enforcing device-bound Conditional Access, where access is strictly contingent on device health. To solve the "Account Leak" problem, the deployment of Tenant Restrictions v2 (TRv2) is essential to prevent users from signing into personal tenants using corporate-managed devices. For enhanced coverage, Universal Tenant Restrictions (UTR) via Global Secure Access (GSA) allows for consistent enforcement at the cloud edge. While TRv2 authentication-plane is GA, data-plane protection is GA for the Microsoft 365 admin center and remains in preview for other workloads such as SharePoint and Teams. 2. Eliminating the Visibility Gap (Shadow AI) You can’t secure what you can't see. Microsoft Defender for Cloud Apps (MDCA) serves to discover and govern the enterprise AI footprint, while Purview DSPM for AI (formerly AI Hub) monitors Copilot and third-party interactions. By categorizing tools using MDCA risk scores and compliance attributes, organizations can apply automated sanctioning decisions and enforce session controls for high-risk endpoints. 3. Data Hygiene: Hardening the “Work IQ” AI acts as a mirror of internal permissions. In a "flat" environment, AI acts like a search engine for your over-shared data. Hardening the foundation requires automated sensitivity labeling in Purview Information Protection. Identifying PII and proprietary code before assigning AI licenses ensures that labels travel with the data, preventing labeled content from being exfiltrated via prompts or unauthorized sharing. 4. Session Governance: Solving the “Clipboard Leak” The most common leak in 2025 is not a file upload; it’s a simple copy-paste action or a USB transfer. Deploying Conditional Access App Control (CAAC) via MDCA session policies allows sanctioned apps to function while specifically blocking cut/copy/paste. This is complemented by Endpoint DLP, which extends governance to the physical device level, preventing sensitive data from being moved to unmanaged USB storage or printers during an AI-assisted workflow. Purview Information Protection with IRM rounds this out by enforcing encryption and usage rights on the files themselves. When a user tries to print a "Do Not Print" document, Purview triggers an alert that flows into Microsoft Sentinel. This gives the SOC visibility into actual policy violations instead of them having to hunt through generic activity logs. 5. The “Agentic” Era: Agent 365 & Sharing Controls Now that we're moving from "Chat" to "Agents", Agent 365 and Entra Agent ID provide the necessary identity and control plane for autonomous entities. A quick tip: in large-scale tenants, default settings often present a governance risk. A critical first step is navigating to the Microsoft 365 admin center (Copilot > Agents) to disable the default “Anyone in organization” sharing option. Restricting agent creation and sharing to a validated security group is essential to prevent unvetted agent sprawl and ensure that only compliant agents are discoverable. 6. The Human Layer: “Safe Harbors” over Bans Security fails when it creates more friction than the risk it seeks to mitigate. Instead of an outright ban, investment in AI skilling-teaching users context minimization (redacting specifics before interacting with a model) - is the better path. Providing a sanctioned, enterprise-grade "Safe Harbor" like M365 Copilot offers a superior tool that naturally cuts down the use of Shadow AI. 7. Continuous Ops: Monitoring & Regulatory Audit Security is not a “set and forget” project, particularly with the EU AI Act on the horizon. Correlating AI interactions and DLP alerts in Microsoft Sentinel using Purview Audit (specifically the CopilotInteraction logs) data allows for real-time responses. Automated SOAR playbooks can then trigger protective actions - such as revoking an Agent ID - if an entity attempts to access sensitive HR or financial data. Final Thoughts Securing AI at scale is an architectural shift. By layering Identity, Session Governance, and Agentic Identity, AI moves from being a fragmented risk to a governed tool that actually works for the modern workplace.
Enterprise Strategy for Secure Agentic AI: From Compliance to Implementation
Imagine an AI system that doesn’t just answer questions but takes action querying your databases, updating records, triggering workflows, even processing refunds without human intervention. That’s Agentic AI and it’s here. But with great power comes great responsibility. This autonomy introduces new attack surfaces and regulatory obligations. The Model Context Protocol (MCP) Server the gateway between your AI agent and critical systems becomes your Tier-0 control point. If it fails, the blast radius is enormous. This is the story of how enterprises can secure Agentic AI, stay compliant and implement Zero Trust architectures using Azure AI Foundry. Think of it as a roadmap a journey with three milestones - Milestone 1: Securing the Foundation Our journey starts with understanding the paradigm shift. Traditional AI with RAG (Retrieval-Augmented Generation) is like a librarian: It retrieves pre-indexed data. It summarizes information. It never changes the books or places orders. Security here is simple: protect the index, validate queries, prevent data leaks. But Agentic AI? It’s a staffer with system access. It can: Execute tools and business logic autonomously. Chain operations: read → analyze → write → notify. Modify data and trigger workflows. Bottom line: RAG is a “smart librarian.” Agentic AI is a “staffer with system access.” Treat the security model accordingly. And that means new risks: unauthorized access, privilege escalation, financial impact, data corruption. So what’s the defense? Ten critical security controls your first line of protection: Here’s what a production‑grade, Zero Trust MCP gateway needs. Its intentionally simplified in the demo (e.g., no auth) to highlight where you must harden in production. (https://github.com/davisanc/ai-foundry-mcp-gateway) Authentication Demo: None Prod: Microsoft Entra ID, JWT validation, Managed Identity, automatic credential rotation Authorization & RBAC Demo: None Prod: Tool‑level RBAC via Entra; least privilege; explicit allow‑lists per agent/capability Input Validation Demo: Basic (ext whitelist, 10MB, filename sanitize) Prod: JSON Schema validation, injection guards (SQL/command), business‑rule checks Rate Limiting Demo: None Prod: Multi‑tier (per‑agent, per‑tool, global), adaptive throttling, backoff Audit Logging Demo: Console → App Service logs Prod: Structured logs w/ correlation IDs, compliance metadata, PII redaction Session Management Demo: In‑memory UUID sessions Prod: Encrypted distributed storage (Redis/Cosmos DB), tenant isolation, expirations File Upload Security Demo: Ext whitelist, size limits, memory‑only Prod: 7‑layer defense (validate, MIME, malware scanning via Defender for Storage), encryption at rest, signed URLs Network Security Demo: Public App Service + HTTPS Prod: Private Endpoints, VNet integration, NSGs, Azure Firewall no public exposure Secrets Management Demo: App Service env vars (not in code) Prod: Azure Key Vault + Managed Identity, rotation, access audit Observability & Threat Detection (5‑Layer Stack) Layer 1: Application Insights (requests, dependencies, custom security events) Layer 2: Azure AI Content Safety (harmful content, jailbreaks) Layer 3: Microsoft Defender for AI (prompt injection incl. ASCII smuggling, credential theft, anomalous tool usage) Layer 4: Microsoft Purview for AI (PII/PHI classification, DLP on outputs, lineage, policy) Layer 5: Microsoft Sentinel (SIEM correlation, custom rules, automated response) Note: Azure AI Content Safety is built into Azure AI Foundry for real‑time filtering on both prompts and completions. Picture this as an airport security model: multiple checkpoints, each catching what the previous missed. That’s defense-in-depth. Zero Trust in Practice ~ A Day in the Life of a Prompt Every agent request passes through 8 sequential checkpoints, mapped to MITRE ATLAS tactics/mitigations (e.g., AML.M0011 Input Validation, AML.M0004 Output Filtering, AML.M0015 Adversarial Input Detection). The design goal is defense‑in‑depth: multiple independent controls, different detection signals, and layered failure modes. Checkpoints 1‑7: Enforcement (deny/contain before business systems) Checkpoint 8: Monitoring (detect/respond, hunt, learn, harden) AML.M0009 – Control Access to ML Models AML.M0011 – Validate ML Model Inputs AML.M0000 – Limit ML Model Availability AML.M0014 – ML Artifact Logging AML.M0004 – Output Filtering AML.M0015 – Adversarial Input Detection If one control slips, the others still stand. Resilience is the product of layers. Milestone 2: Navigating Compliance Next stop: regulatory readiness. The EU AI Act is the world’s first comprehensive AI law. If your AI system operates in or impacts the EU market, compliance isn’t optional, it’s mandatory. Agentic AI often falls under high-risk classification. That means: Risk management systems. Technical documentation. Logging and traceability. Transparency and human oversight. Fail to comply? Fines up to €30M or 6% of global turnover. Azure helps you meet these obligations: Entra ID for identity and RBAC. Purview for data classification and DLP. Defender for AI for prompt injection detection. Content Safety for harmful content filtering. Sentinel for SIEM correlation and incident response. And this isn’t just about today. Future regulations are coming US AI Executive Orders, UK AI Roadmap, ISO/IEC 42001 standards. The trend is clear: transparency, explainability, and continuous monitoring will be universal. Milestone 3: Implementation Deep-Dive Now, the hands-on part. How do you build this strategy into reality? Step 1: Entra ID Authentication Register your MCP app in Entra ID. Configure OAuth2 and JWT validation. Enable Managed Identity for downstream resources. Step 2: Apply the 10 Controls RBAC: Tool-level access checks. Validation: JSON schema + injection prevention. Rate Limiting: Express middleware or Azure API Management. Audit Logging: Structured logs with correlation IDs. Session Mgmt: Redis with encryption. File Security: MIME checks + Defender for Storage. Network: Private Endpoints + VNet. Secrets: Azure Key Vault. Observability: App Insights + Defender for AI + Purview + Sentinel. Step 3: Secure CI/CD Pipelines Embed compliance checks in Azure DevOps: Pre-build: Secret scanning. Build: RBAC & validation tests. Deploy: Managed Identity for service connections. Post-deploy: Compliance scans via Azure Policy. Step 4: Build the 5-Layer Observability Stack App Insights → Telemetry. Content Safety → Harmful content detection. Defender for AI → Prompt injection monitoring. Purview → PII/PHI classification and lineage. Sentinel → SIEM correlation and automated response. The Destination: A Secure, Compliant Future By now, you’ve seen the full roadmap: Secure the foundation with Zero Trust and layered controls. Navigate compliance with EU AI Act and prepare for global regulations. Implement the strategy using Azure-native tools and CI/CD best practices. Because in the world of Agentic AI, security isn’t optional, compliance isn’t negotiable, and observability is your lifeline. Resources https://learn.microsoft.com/en-us/azure/ai-foundry/what-is-azure-ai-foundry https://learn.microsoft.com/en-us/azure/defender-for-cloud/ai-threat-protection https://learn.microsoft.com/en-us/purview/ai-microsoft-purview https://atlas.mitre.org/ https://digital-strategy.ec.europa.eu/en/policies/european-approach-artificial-intelligence https://techcommunity.microsoft.com/blog/microsoft-security-blog/microsoft-sentinel-mcp-server---generally-available-with-exciting-new-capabiliti/4470125Microsoft Sentinel Graph with Microsoft Security Solutions
Why I Chose Sentinel Graph Modern security operations demand speed and clarity. Attackers exploit complex relationships across identities, devices, and workloads. I needed a solution that could: Correlate signals across identity, endpoint and cloud workloads. Predict lateral movement and highlight blast radius for compromised accounts. Integrate seamlessly with Microsoft Defender, Entra ID and Purview. Sentinel Graph delivered exactly that, acting as the reasoning layer for AI-driven defense. What's new: Sentinel Graph Public Preview Sentinel Graph introduces: Graph-based threat hunting: Traverse relationships across millions of entities. Blast radius analysis: Visualize the impact of compromised accounts or assets. AI-powered reasoning: Built for integration with Security Copilot. Native integration with Microsoft Defender and Purview for unified security posture. Uncover Hidden Security Risks Sentinel Graph helps security teams: Expose lateral movement paths that attackers could exploit. Identify choke points where defenses can be strengthened. Reveal risky relationships between identities, devices, and resources that traditional tools miss. Prioritize remediation by visualizing the most critical nodes in an attack path. This capability transforms threat hunting from reactive alert triage to proactive risk discovery, enabling defenders to harden their environment before an attack occurs. How to Enable Defense at All Stages Sentinel Graph strengthens defense across: Prevention: Identify choke points and harden critical paths before attackers exploit them. Detection: Use graph traversal to uncover hidden attack paths and suspicious relationships. Investigation: Quickly pivot from alerts to full graph-based context for deeper analysis. Response: Contain threats faster by visualizing blast radius and isolating impacted entities. This end-to-end approach ensures security teams can anticipate, detect, and respond with precision. How I Implemented It Step 1: Enabling Sentinel Graph If you already have the Sentinel Data Lake, the graph is auto provisioned when you sign in to the Microsoft Defender portal. Hunting graph and blast radius experiences appear directly in Defender. New to Data Lake? Use the Sentinel Data Lake onboarding flow to enable both the data lake and graph. Step 2: Integration with Microsoft Defender Practical examples from my project: Query: Show me all entities connected to this suspicious IP address. → Revealed lateral movement attempts across multiple endpoints. Query: Map the blast radius of a compromised account. → Identified linked service principals and privileged accounts for isolation. Step 3: Integration with Microsoft Purview In Purview Insider Risk Management, follow Data Risk Graph setup instructions. In Purview Data Security Investigations, enable Data Risk Graph for sensitive data flow analysis. Example: Query: Highlight all paths where sensitive data intersects with external connectors. → Helped detect risky data exfiltration paths. Step 4: AI-Powered Insights Using Microsoft Security Copilot, I asked: Predict the next hop for this attacker based on current graph state. Identify choke points in this attack path. This reduced investigation time and improved proactive defense. If you want to experience the power of Microsoft Sentinel Graph, here’s how you can get started Enable Sentinel Graph In your Sentinel workspace, turn on the Sentinel Data Lake. The graph will be auto provisioned when you sign in to the Microsoft Defender portal. Connect Microsoft Security Solutions Use built-in connectors to integrate Microsoft Defender, Microsoft Entra ID, and Microsoft Purview. This ensures unified visibility across identities, endpoints, and data. Explore Graph Queries Start hunting with Sentinel Notebooks or take it a step further by integrating with Microsoft Security Copilot for natural language investigations. Example: “Show me the blast radius of a compromised account.” or “Find everything connected to this suspicious IP address.” You can sign up here for a free preview of Sentinel graph MCP tools, which will also roll out starting December 1, 2025.Know MCP risks before you deploy!
The Model Context Protocol (MCP) is emerging as a powerful standard for enabling AI agents to interact with tools and data. However, like any evolving technology, MCP introduces new security challenges that organizations must address before deploying it in production environments. Major MCP Vulnerabilities MCP’s flexibility comes with risks. Here are the most critical vulnerabilities: Prompt Injection Attackers embed hidden instructions in user input, manipulating the model to trigger unauthorized MCP actions and bypass safety rules. Tool Poisoning Malicious MCP servers provide misleading tool descriptions or parameters, tricking agents into leaking sensitive data or executing harmful commands. Remote Code Execution Untrusted servers can inject OS-level commands through compromised endpoints, enabling full control over the host environment. Unauthenticated Access Rogue MCP servers bypass authentication and directly call sensitive tools, extracting internal data without user consent. Confused Deputy (OAuth Proxy) A malicious server misuses OAuth tokens issued for a trusted agent, performing unauthorized actions under a legitimate identity. MCP Configuration Poisoning Attackers silently modify approved configuration files so agents execute malicious commands as if they were part of the original setup. Token or Credential Theft Plaintext MCP config files expose API keys, cloud credentials, and access tokens, making them easy targets for malware or filesystem attacks. Path Traversal Older MCP filesystem implementations allow navigation outside the intended directory, exposing sensitive project or system files. Token Passthrough Some servers blindly accept forwarded tokens, allowing compromised agents to impersonate other services without validation. Session Hijacking Session IDs appearing in URLs can be captured from logs or redirects and reused to access active sessions. Current Known Limitations While MCP is promising, it has structural limitations that organizations must plan for: Lack of Native Tool Authenticity Verification There is no built-in mechanism to verify if a tool or server is genuine. Trust relies on external validation, increasing exposure to tool poisoning attacks. Weak Context Isolation Multi-session environments risk cross-contamination, where sensitive data from one session leaks into another. Limited Built-In Encryption Enforcement MCP depends on HTTPS/TLS for secure communication but does not enforce encryption across all channels by default. Monitoring & Auditing Gaps MCP lacks native logging and auditing capabilities. Organizations must integrate with external SIEM tools like Microsoft Sentinel for visibility. Dynamic Registration Risks Current implementations allow dynamic client registration without granular controls, enabling rogue client onboarding. Scalability Constraints Large-scale deployments require manual tuning for performance and security. There is no standardized approach for load balancing or high availability. Configuration Management Challenges Credentials often stored in plaintext within MCP config files. Lack of automated secret rotation or secure vault integration makes them vulnerable. Limited Standardization Across Vendors MCP is still evolving, and interoperability between different implementations is inconsistent, creating integration complexity. Mitigation Best Practices To reduce risk and strengthen MCP deployments: Enforce OAuth 2.1 with PKCE and strong RBAC. Use HTTPS/TLS for all MCP communications. Deploy MCP servers in isolated networks with private endpoints. Validate tools before integration; avoid untrusted sources. Integrate with Microsoft Defender for Cloud and Sentinel for monitoring. Encrypt and rotate credentials; never store in plaintext. Implement policy-as-code for configuration governance. MCP opens new possibilities for AI-driven automation, but without robust security, it can become an attack vector. Organizations must start with a secure baseline, continuously monitor, and adopt best practices to operationalize MCP safely.
