rss.livelink.threads-in-node

Introducing a unified alert experience for Microsoft Purview Insider Risk Management

MSlotwinski — Tue, 30 Jun 2026 19:00:00 GMT

Modern insider risk investigations succeed or fail based on how quickly analysts can move from signal to decision with more context. Too often, investigations within Microsoft Purview require high switching costs while analysts struggle with disconnected alert views and scattered case notes across workflows. Every switch slows triage pulling focus away from the risk itself, decreasing the speed and confidence of investigations.

That’s why we’re unifying the Microsoft Purview Insider Risk Management investigation experience with three connected improvements — a unified alert queue, expanded user profile details, and notes across alerts and cases. Analysts can now triage, understand context, and capture their work in a streamlined investigation flow to help enable faster investigations and increase confidence. Here’s what’s coming to public preview in July 2026:

1. One unified alert queue integrating classic and agent workflows together

The most disruptive part of triage happens before analysts dig into any single alert: understanding what alerts require the most attention. Today, that means toggling between the classic alert queue and the Data Security Triage Agent’s insights. We’re now bringing them together into a single, unified alerts list.

Instead of switching between two experiences, analysts get one page where they can:

Preview agent summaries, alert details, and user details directly from the alerts list, reducing the need to open each alert individually.

Filter all classic and agent attributes on one page, including a new agent categorization column and the ability to surface agent-triaged alerts that need attention.

View and manage the agent directly from the alerts list.

Open or act on an alert with the ability to stay within the queue.

As part of this unification, alert spotlighting is being retired, and the toggle between agent and classic alerts is going away in favor of the single view. To give teams time to adjust, both the classic and new experiences will remain available for at least 60 days, with support for both currently planned through August 31, 2026. Explore the unified alert queue here → New IRM Alert Experience.

Launch details: Public preview: July 2026 | Roadmap ID: 564621

Figure 1: The unified IRM alerts list, showing inline agent summaries, the new Categorization column, and combined classic and agent filtering on a single page.

2. Expanded user profile details to better understand user risk

Once an alert has been raised, the next question is about the person behind it: Who are they, and how much risk does this really represent? Answering that used to mean piecing context together from multiple places.

The expanded user profile brings context into one unified view by:

Adding new signals from the user’s Entra profile including office location, employee type, department, and last working date.

Aggregating key insider risk signals in one place including Entra profile details, past alert and case history, priority user group status, and policy inclusion.

The result is a fuller, more detailed picture of users' risk, to provide investigators with more context for decisions without leaving the alert. See expanded user profile details here → New IRM Alert Experience

Where to find it: On the new Alerts (preview) tab — click Alerts (preview) in the left navigation, open an alert, scroll to User details, and select View user details. Note: when pseudo-anonymization is enabled, user profile details will not appear, preserving privacy by design.

Launch details: Public preview: July 2026 | Roadmap ID: 564619

Figure 2: The unified user details view, combining Entra profile signals with aggregated Insider Risk history and status.

3. Notes across alerts and cases keep context with the work

Investigation context shouldn’t live in someone’s memory or a side document. Analysts and investigators can now add and view notes directly in alerts and cases within the Purview portal, ensuring the story of an investigation stays with the investigation.

Notes come in two forms:

System-generated notes are applied automatically on key changes including alert or case status, assigned user, alert or case closure, and case escalations.

Analyst notes let investigators capture their own observations as they work

This gives teams continuity and a clearer record of investigation activity history without breaking stride.

Where to find it: In the Notes tab within the alert details panel, and within the Cases tab within a case. Start capturing notes across alerts and cases here→ New IRM Alert Experience

Launch details: Public preview: July 2026 | Roadmap ID: 564620

Figure 3: The Notes tab in the alert detail panel, showing both system-generated and analyst-added notes.

Ready to get started? Try the unified Insider Risk Management experience today: Click here to get started

Privacy Statement: 
Microsoft Purview Insider Risk Management correlates various signals to identify potential malicious or inadvertent insider risks, such as IP theft, data leakage, and security violations. Insider Risk Management enables customers to create policies to manage security and compliance. Built with privacy by design, users are pseudonymized by default, and role-based access controls and audit logs are in place to help ensure user-level privacy.

Understand your Sentinel tables at a glance: Monitor with table insights

NikitaChhabra — Mon, 29 Jun 2026 17:48:32 GMT

What it is

Table insights is a new panel on the Sentinel Tables page that gives you 30-day ingestion volume per tier, day-over-week fluctuations, the top 5 tables by volume, last-data-received per table, an estimated daily cost, and a volume anomaly indicator.

Who benefits: SOC engineers chasing silent data connectors, platform owners chasing cost spikes, FinOps teams chasing chargeback clarity — all from the same screen.

Why these matter

Every Sentinel customer I talk to has the same two recurring incidents.

"A third-party data connector stopped sending data three days ago and nobody noticed until a hunt came up empty."

Both incidents share a root cause: until now, table-level health lived in a workbook you had to remember to open, a Usage KQL you had to remember to write, or a SentinelHealth alert someone had to remember to configure. In a workspace with 500+ tables and a mix of Microsoft 1st-party data connectors, third-party data connectors, custom logs, and data-lake tables, that's a lot of remembering.

Table insights flips the model. It puts the answer on the same page where you already manage tiers and retention, so the next time you open the Tables page to right-size a Lake-tier table, the data connector that went silent at 3 a.m. is already staring at you.

Try it today

Open the Defender portal → Microsoft Sentinel → Configuration → Tables and expand the Table insights panel.

Figure 1: Table insights panel

What's new on the Tables page

Ingestion volume per tier - Analytics vs. Lake split for the last 30 days. The first time you see Lake tier exceeding Analytics, you'll know the data-lake migration is working.

Table ingestion fluctuations - tables whose last-24h volume differs from the same day last week beyond a threshold (default 10% and 1 MB).

Top 5 tables by daily ingestion volume - 30-day trend. The line that looks like a heart-rate monitor is the one your FinOps lead wants to talk about.

Last data received column – time of recency per table.

Volume anomaly column - signed percentage change versus baseline, right next to the table name.

Data sources – Click on table details to open side panels for data sources.

Who wins, and how

Persona	Pain today	Win with Table insights
SOC engineer	Detections silently degrade when a third-party data connector stops sending- you only notice when an incident is missed.	Spot the drop in "Last data received" or a -100% fluctuation before the next shift report.
Data Connector onboarding lead	"Did the new data connector light up?" takes a KQL query and a workbook hunt.	One glance at the Tables page confirms the destination table, tier, and last-received timestamp.

How I'd actually use it

Baseline- Open the Tables page, filter by Tier = Analytics, sort by Avg. daily ingestion descending.

Triage silent data connectors- Sort by Last data received ascending.

Tier review- For every table above a few GB/day with low SOC query usage, evaluate moving it to Auxiliary or Lake tier. The Est. daily ingestion cost column makes the business case for you.

Wire up alerts- Convert the fluctuations card into a scheduled analytics rule on SentinelHealth, so the next "-100%" row pages someone instead of waiting for the morning standup.

Share the screenshot- Drop the ingestion volume per tier card into your monthly business review.

Honest caveats

Fluctuations only compare the last 24h to the same day last week.

Cost numbers are estimates They're great for relative comparisons, not invoice forecasting.

Volume anomaly is most accurate on Analytics-tier tables today. Lake/Auxiliary anomalies will be catchup in features soon.

The grid shows the table; for third-party data connectors you'll still cross-reference the Tables-to-connectors mapping page to find the upstream data connector.

Table insights is a visualization. If you want to be paged, build the SentinelHealth analytics rule.

Resources

Manage data tiers and retention in Microsoft Sentinel

Monitor the health of your Microsoft Sentinel data connectors

Microsoft Sentinel health tables reference (SentinelHealth)

Microsoft Sentinel tables and associated connectors

Transform or customize data at ingestion time

Ask Microsoft Anything: Microsoft Defender Attack Disruption

Trevor_Rusher — Fri, 26 Jun 2026 17:06:45 GMT

Learn more about attack disruption—Microsoft Defender’s built‑in, AI-powered capability that stops in‑progress attacks at machine speed by analyzing attacker intent, identifying compromised assets, and containing threats before they spread. Bring your questions and hear directly from product experts on real‑world scenarios and best practices.

What is an AMA?

An 'Ask Microsoft Anything' (AMA) session is an opportunity for you to engage directly with Microsoft employees! This AMA will consist of a short presentation followed by taking questions on-camera from the comment section down below! Ask your questions/give your feedback and we will have our awesome Microsoft Subject Matter Experts engaging and responding directly in the video feed. We know this timeslot might not work for everyone, so feel free to ask your questions at any time leading up to the event and the experts will do their best to answer during the live hour. This page will stay up so come back and use it as a resource anytime. We hope you enjoy!

The state of MCP security in 2026

JiteshThakur — Tue, 30 Jun 2026 16:43:45 GMT

Co-Author: ShalabhPradhan

A year ago we published Understanding and mitigating security risks in MCP implementations.

The core idea still holds: the moment a model can choose and call tools, it stops being a question-and-answer box and becomes software that acts. Anything that acts has a trust boundary, and tool descriptions, schemas, outputs, and credentials all sit inside it.

What has changed is scale. The Model Context Protocol has gone from a promising idea to the way agents connect to tools, data, and systems. Enterprises have stopped experimenting and started shipping into production. This post is a checkpoint: the main risks as they stand now, which of them have moved, and what good security looks like for each.

A specification that keeps moving

MCP is still evolving quickly, and the spec is revised on a regular cadence. The latest release candidate raises the security baseline in ways worth knowing.

Requests now carry what they need, so a gateway can inspect and enforce on every call rather than trust a hidden session. Identity checks between clients and servers are tighter. And a new MCP Apps capability lets a server ship interactive UI that the host renders inside a sandbox.

The protocol deliberately does not enforce security for you. It defines how clients and servers talk, and the rest is your responsibility. Treat "we reviewed MCP last year" as out of date, and revisit your assumptions with each release.

The main risks in 2026

Some of these are the risks we flagged last year. Some have shifted, and authorization in particular has been reworked. Each entry below covers the same three things: what the risk is, what happens if it is exploited, and the controls that help most.

Figure 1: MCP Security Overview

1. Prompt injection and tool poisoning

What it is: An agent treats everything in its context as trustworthy: tool descriptions, parameter schemas, and the data tools return. Anyone who can plant instructions in any of those can steer the agent. Tool poisoning is the sharp edge, malicious instructions hidden in a tool's description or schema that the model reads and the user usually does not.

What could happen: The agent follows the attacker's instructions instead of the user's. It might exfiltrate data through a tool call that looks legitimate, call the wrong tool, or take an action nobody approved.

Controls: Treat tool descriptions and outputs as untrusted input, and inspect the full schema before you approve a server. Put the tool list through a human approval step, and show the full tool call rather than a friendly summary. Keep sensitive servers isolated from general-purpose ones so a poisoned tool cannot reach across without further safeguards.

2. Authorization and the confused deputy

What it is: This is where the protocol moved most. MCP servers are now treated as OAuth 2.0 resource servers, and the guidance has settled on OAuth 2.1, PKCE, and tokens bound to a specific audience. The risk it targets is the confused deputy: a server acting with its own broad privileges on behalf of a user who does not have them, or a proxy that can be tricked into handing an attacker a valid authorization code.

What could happen: An attacker uses the server's privileges to reach data or actions the user was never entitled to, sometimes without the user approving anything.

Controls: Adopt the current authorization model: OAuth 2.1 with PKCE, per-client consent, strict redirect-URI matching, and audience-bound tokens, so a token issued for one server cannot be replayed against another. Put an identity-aware gateway in front of every server and reject any call that does not carry a valid, audience-bound token. Azure API Management can validate Microsoft Entra tokens and check issuer, audience, and expiry before the request reaches a tool.

Figure 2: Confused Deputy Problem

3. Over-broad access and credential aggregation

What it is: A single MCP server often holds credentials for several systems at once, and asks for wider scopes than it needs, such as full mailbox access where read-only would do.

What could happen: One compromised server, or one leaked token, becomes a breach path of every system it touches. Wide scope means a wide blast radius.

Controls: Apply least privilege, per resource: scoped, narrow OAuth scopes over wildcards; short-lived tokens over long-lived secrets. Give every agent an identity you can govern, like Microsoft Entra Agent ID, so you can apply policy to a whole class of agents or shut them down in one operation.

4. Supply chain and rug pulls

What it is: An MCP server is never just the server. It is the server, its dependencies, and the infrastructure it runs on, and each of those is a way in. A typo squatted package, a compromised dependency, or a change of ownership behind the same URL can all turn a trusted server hostile. Also, known as a 'rug pull' attack where a server behaves while it is being reviewed, earns approval, then changes once agents and workflows already depend on it.

What could happen: The server you approved is no longer the server you run. An ordinary tool call starts leaking its arguments, rewriting a response, or exfiltrating a token, and nothing about the request looks different from the thousands before it.

Controls: Approval cannot be a one-time event. Build a Secure By Design Registry and register every server in a design-time catalog so you have a known-good baseline, pin tool definitions and alert on drift so you have a tripwire for rug pulls, and route everything through a gateway that re-checks identity and policy on every call. Azure API Center inventories your APIs and MCP servers, and the OWASP MCP Top 10 mapped to Azure controls lines the risks up against what you already run.

Figure 3: Supply Chain- Rug Pull. The approved dependency remains trusted even after ownership, version, or behavior changes.

5. Shadow MCP

What it is: This is shadow IT for the AI era. A developer stands up a server to unblock a demo or get some work done quickly, a team wires an agent to whatever endpoint is handy, and nobody registers or verifies it.

What could happen: You cannot govern, patch, or revoke what you cannot see, and ungoverned servers are where supply chain problems tend to hide.

Controls: Start with visibility, of what exists, and a runtime gateway that everything routes through. The GSA AI Gateway helps you surface the unregistered, shadow servers you didn't know were running.

6. Command injection and sandbox escape

What it is: Many MCP servers run locally and talk over standard input/output, spawning subprocesses and touching the file system. If a server passes unsanitized input into a shell or a file path, you have command injection or path traversal, and that has been one of the largest classes of MCP vulnerabilities reported this year.

What could happen: Arbitrary code runs on the host, or a server reaches files and credentials well outside what it should, in the worst cases with no user approval at all.

Controls: Sandbox local servers in containers with only the file-system and network access they need, and block outbound traffic by default. Validate and sanitize every input and output, and never pass raw shell commands or unsanitized paths. Keep servers and SDKs patched, because this class of bug is being fixed in the field constantly.

Wrapping up

MCP has not changed what good security looks like, only where you need to apply it. The risks that matter most now sit at the supply chain, in identity, and in servers nobody verified, and the controls that address them are ones you already know: strong identity, least privilege, a gateway in front of every server, sandboxing for local servers, and an alert when an approved tool changes. The spec continues to keep improving, but it still leaves the security decisions to you.

If you would like to help improve the protocol, you can contribute to the specification here.

In the next part, we'll get practical: a hands-on guide to implementing these controls in depth, with the patterns and configurations you can put to work.

With thanks to Sarah_Young for their inputs and collaboration on this post.

Security Community Spotlight: Sathish Veerapandian

RenWoods — Thu, 25 Jun 2026 15:00:00 GMT

Meet Sathish Veerapandian: security architect, community collaborator, published author, and cycling enthusiast with a knack for turning real-world customer challenges into product-shaping feedback. From influencing phishing-resistant authentication and malware scanning improvements to helping organizations navigate Microsoft Purview, AI governance, and hybrid work, Sathish brings the best kind of energy to the Microsoft Security Community: curious, practical, generous, and always ready to help others move forward.

What do you find most rewarding about being a member of the Microsoft Security Community?

I find it most rewarding to be part of a community where knowledge sharing directly contributes to stronger, real world security outcomes. The Microsoft Security Community brings together practitioners, MVPs, engineers, and product teams, creating a space where collaboration leads to practical solutions, continuous learning, and meaningful impact. Being able to share experiences, learn from others, and help shape the direction of Microsoft Security technologies is what makes this community truly valuable to me.

I have tested and provided feedback on a wide range of products via the Security Advisors program. Some examples include extending FIDO support for on-premises environments; improving Microsoft Defender for Storage malware scanning with Sentinel integration, cost estimation, delta scanning, and scheduled scans; streamlining Microsoft Purview DSPM for AI onboarding and Insider Risk visibility; and strengthening Predictive Shielding by turning risk insights into preventive Conditional Access controls.

Overall, these examples reflect how I collaborate: identifying real-world gaps during implementation and operations, translating them into clear product feedback, and contributing in ways that help Microsoft engineering and the broader community.

Could you share something you’re proud of or a project you’ve completed?

One project I’m particularly proud of is co-authoring the book Reimagine Remote Working with Microsoft Teams with my community colleagues during the COVID pandemic. At that time, we saw a significant increase in questions from organizations on how to effectively utilize Microsoft Teams to enable efficient and productive remote work. Recognizing this need, we took the initiative to bring together our collective experience and authored the book as a team. Our main goal was to help organizations improve their collaboration. We came together as a team and shared our real-world experience.

Authoring this book also motivated my colleagues to become more interested in the Microsoft MVP Program and contributing to the Tech Community forums, which helped a lot of people.

Reimagine Remote Working with Microsoft Teams is available for public purchase and has been used by IT professionals, team leaders, and organizations looking to strengthen their hybrid work strategy. A copy of the book was also archived in the Microsoft Corporate Library in Redmond, which is a personal milestone and an honor as an MVP.

What does your ideal community experience look like?

My ideal community experience continues to be one where practitioners, MVPs, and product teams collaborate closely to share real- world insights, solve challenges together, and help shape the future of Microsoft Security. I value environments where knowledge flows openly, where hands- on learning is encouraged, and where community members can contribute through content, discussions, and events that have a meaningful impact on others.

How long have you been working with Microsoft Security Products?

My Microsoft Security journey began over a decade ago in the on- premises era, working with technologies such as Forefront, TMG, Exchange security, and Antispam solutions. Those early years gave me a deep foundation in securing Microsoft workloads at the infrastructure and perimeter level, long before cloud adoption became mainstream. As the industry shifted, I transitioned into the cloud security space, embracing Microsoft 365 and Azure security capabilities. This evolution led me to focus on data protection, identity, and modern collaboration security, eventually specializing in Microsoft Purview, Copilot DLP, Insider Risk, and Information Protection.

What features or products have provided the most impact?

The Microsoft Security products that have had the most impact for me are the ones that directly improve security outcomes while staying deployable at scale. The most impactful areas have been:

1) Microsoft Entra ID – FIDO / Passwordless (including on-prem considerations)

Impact: Enabling phishing-resistant authentication in a way that works for real enterprise environments (including hybrid setups).

Essential capability: FIDO/passwordless support that can extend into on-prem realities, so customers are not blocked by architecture constraints.

2) Microsoft Defender for Storage – On-demand Malware Scanning

Impact: Improving security assurance for storage data, especially during high-risk operational events like large-scale migrations.

Essential capabilities: More effective delta scanning and the ability to run scheduled or on-demand scans aligned to migration windows and operational needs.

3) Microsoft Purview – DSPM for AI

Impact: Supporting governance and security posture for AI-related data usage, with an experience that enables customers to adopt quickly.

Essential capability: A smoother enablement/onboarding experience so the subscription/capability can be activated reliably and used without friction.

4) Predictive Shielding + Conditional Access (preventive controls)

Impact: Turning risk insight into preventive action by applying controls through Conditional Access.

Essential capability: Preventive enforcement that helps stop risky access/behavior earlier rather than only detecting after the fact.

What advice do you have for others who would like to get involved in the Microsoft Community?

My advice is to simply start by sharing what you know. You don’t need to be an expert to contribute just be willing to help others, document your learnings, and stay curious. The Microsoft Community grows through collaboration, and even small contributions like answering questions, writing a short post, or sharing a demo can make a real impact. Engage consistently, connect with others who share your interests, and focus on adding value. Over time, those small steps build into meaningful involvement, strong relationships, and opportunities you never expected.

Tell us more about you, including where to find you!

Outside of technology, I’m very passionate about cycling. I run a local cycling community in Almere called the Almere Cycling Club, where we focus on improving the health and fitness of people through regular group rides and community activities. It’s something I truly enjoy because it brings people together, encourages a healthier lifestyle, and creates a positive impact in the place where I live.

Here’s where you can connect with me online:

YouTube: DevOpsInfo 391

LinkedIn: Sashtish Veerapandian

Website: https://ezcloudinfo.com

Purview Community Lightning Talk: From Zero to First Signal: Insider Risk Management Prerequisites That Actually Matter

Sathish’s story is a reminder that strong communities are built by people who show up with curiosity, generosity, and a willingness to turn real-world experience into shared progress. Whether he’s helping shape Microsoft Security products, guiding organizations through modern security challenges, or bringing people together through cycling, Sathish leads with purpose and impact- and the Microsoft Security Community is stronger because of it.

Learn and Engage with the Microsoft Security Community

Visit the Microsoft Security Community home.
Log in and follow this Microsoft Security Community Blog.

Follow = Click the heart in the upper right when you're logged in 🤍.

Subscribe to the Security Community Email List and be notified of upcoming events, product feedback surveys, and more.
Get early access to Microsoft Security products and provide feedback to engineers by joining the Microsoft Security Advisors.
Join the Microsoft Security Community LinkedIn Group and follow the Microsoft Entra Community on LinkedIn

How Karambit.AI and Microsoft Bring Software Authenticity to 14 Billion Files Per Month

AlecCheung — Wed, 24 Jun 2026 20:30:26 GMT

The Problem: Static Analysis Without Context

Traditional static analysis treats every file as an island. Scan a binary, match against known signatures, flag what you recognize. The approach is well-understood and increasingly insufficient against modern threats.

The fundamental limitation is the absence of context. Without it, a packer is just a packer. A network call is just a network call. An obfuscation routine is just an obfuscation routine. Whether that behavior is normal or anomalous, whether it belongs in this software, in this ecosystem, performing this function, is invisible to tools that evaluate files in isolation.

Attackers exploit this gap. They hide malicious behavior inside legitimate software patterns, evolve their techniques between versions, and distribute intent across multiple components so that no single artifact triggers a detection in a context-free scan.

Context-Aware Behavior Analysis

Context-aware analysis inverts the model. Instead of asking "is this file bad?" it asks: "is this file behaving the way it should, given everything we know about this ecosystem?"

This requires building and maintaining behavioral context across multiple dimensions:

Ecosystem-level behavioral baselines: Understanding what behaviors are normal across the entire corpus and which should never appear. In a trusted software ecosystem, obfuscated or packed content is itself an anomaly worth enforcing policy against, regardless of whether the underlying payload is known-malicious.
Behavioral chains with low false-positive rates: Individual API calls and instructions are ambiguous in isolation. Context-aware analysis identifies chains of behaviors, sequences where data staging feeds into exfiltration, or where privilege escalation is followed by persistence mechanisms, that reveal intent with high confidence.
Cross-file and cross-instance correlation: Behaviors observed in one file are evaluated against patterns seen across millions of other files and scan instances. Shared behavioral fingerprints reveal family relationships, evolutionary lineage, and coordinated campaigns that single-file analysis cannot surface.
Historical behavioral deltas: What changed between version N and version N+1? New behaviors in an update, especially behaviors that don't correspond to documented changes, are flagged not because they match a signature, but because they deviate from the established behavioral profile.

The result: dramatically higher detection confidence, lower false-positive rates, and the ability to enforce behavioral policy at the ecosystem level.

Case Study: Packer_Dictator, Behavioral Detection Under Adversary Adaptation

Adversaries must change their Tactics, Techniques, and Procedures (TTPs) over time. When a detection capability catches them, they adapt to evade it. This is expected behavior and it is precisely why general detections at the behavior level are more durable than signature-based approaches. Behavioral patterns are fundamentally harder for adversaries to change without breaking their own tooling.

The packer family tracked as packer_dictator illustrates this dynamic clearly.

Initial Detection: Obvious Indicators

Early variants of packer_dictator used conspicuous binary section names: authoritarian and politically-themed strings that made identification straightforward for anyone examining the PE headers. These were low-hanging indicators, but Karambit.AI's detection wasn't built on them. The system flagged these samples based on their behavioral profile: the entropy characteristics of their packed sections, the structure of their unpacker initialization routines, and the other patterns used to unpack and execute hidden payloads.

Adversary Adaptation: Surface Changes, Persistent Behavior

As detections rolled out, the users of this packer had to adapted. The obvious section names disappeared, replaced by more benign alternatives: .upx0, standard "unpacked" section names, and other strings designed to blend in with legitimate software.

But the underlying behavior didn't change because it couldn't, not without fundamentally rearchitecting the packer itself.

Entropy Analysis: Seeing Through Surface Changes

Sliding-window entropy analysis reveals why surface-level changes are insufficient to evade behavioral detection. The entropy profiles of packer_dictator samples, even after the section name changes, maintain a characteristic signature:

Figure 1: fancontroller.sys sample entropy sliding windowFigure 2: packer_dictator sample entropy sliding window

Both profiles exhibit the same structural pattern: a low-entropy region corresponding to the unpacker stub, followed by a sharp transition to a high-entropy plateau spanning the packed payload. This entropy profile is indicative of hidden behaviors, content that has been deliberately obscured, though not necessarily malicious content on its own. The profile shape, transition points, and entropy floor/ceiling ratios form a behavioral fingerprint that persists across variants regardless of metadata changes.

Unpacker Initialization: Common Structure Enables Generalized Detection

At the disassembly level, packer_dictator variants share a common unpacker initialization sequence that enables generalized analysis across the family. Examining the entry-point code of two samples reveals the structural similarity:

Figure 3: Sample 1 disassemblyFigure 4: Sample 2 disassembly

Both samples exhibit a characteristic pattern:

Register preservation: PUSH R9/PUSH R11 followed by PUSHFQ to save register state and flags before the unpack routine modifies them.
Immediate constant loading: Large immediate values loaded into registers (MOV R9, 0x689f8c87eebd998c / MOV R11, 0x6592b8afc22b0736) that serve as decryption keys or XOR masks for the unpacking routine.
Arithmetic flag manipulation: Sequences of TEST, NEG, OR, CMP, NOT, and SETNS instructions that compute control flow decisions based on the loaded constants — a form of opaque predicate that obscures the true branch target.
Stack-based payload resolution: MOV instructions referencing [RSP + local_120] / [RSP + 0x8] with additional immediate constants written to the stack, setting up parameters for the decompression/decryption loop.

The structural template is consistent even as the specific constants, register assignments, and opaque predicate formulations change between variants. This is what makes behavioral detection durable: the adversary can rotate constants and rename sections, but the computational structure required to unpack the payload is constrained by the packer's architecture.

By generalizing detection to this structural level, Karambit.AI's engine identifies new packer_dictator variants, and structurally related packer families, without requiring signature updates for each iteration. And this is only one example of the resilience of Karambit.AI’s resilience in the face of constantly advancing adversaries.

From Karambyte to Karambiner: Engineering for Billions

Karambyte: Building the Context

Karambyte was Karambit.AI's original analysis engine, purpose-built for deep behavioral extraction from compiled binaries. Its core function was to extract behavioral context, disassemble control flow, API call chains, entropy profiles, packer identification, behavioral intent classification, and store it for comparison and reference.

Karambyte proved the model. It demonstrated that context-aware behavioral analysis could identify threats that traditional static analysis missed, by building rich behavioral profiles and comparing them across software versions and file populations. The system extracted context and maintained it internally, enabling the cross-file and cross-version correlation that drove detections like packer_dictator.

But Karambyte's architecture, extracting and storing context within the same system, created a scaling constraint. As adoption grew and the target moved from hundreds of thousands to billions of files per month, the tight coupling between analysis and context storage became the bottleneck.

Karambiner: Externalizing Context for Scale

Karambiner re-architected the relationship between analysis and context. Rather than each analysis instance maintaining its own behavioral context store, Karambiner externalized the context layer into a dedicated reference that can then be customized for the specific organizational context.

This separation enabled three critical capabilities at scale:

Horizontal analysis throughput: Analysis scales independently of the context store. Adding processing capacity doesn't require replicating the full behavioral knowledge base.
Context enrichment: Behavioral context extracted from collective scans can be used in the massively scalable analysis engine.
Ecosystem-wide policy enforcement: With externalized behavioral context, the system can enforce policies across a large-scale ecosystem, such as blocking all obfuscated or packed content.

The move from Karambyte to Karambiner was the architectural shift that made scanning of 14 billion files per month possible: a configurable depth of behavioral analysis, with context that scales to the size of the ecosystem rather than the capacity of individual analysis nodes.

The Result: Software Behavior Analysis in Microsoft's Pipeline

Today, Karambiner is integrated into Microsoft's operational pipeline for build/release and plays a critical role in performing context-aware behavioral analysis across billions of files monthly.

The operational impact:

Ecosystem-level behavioral policy enforcement: Obfuscated and packed content that has no legitimate reason to exist in the ecosystem is blocked by policy, informed by the scaled behavioral analysis.
Durable detection under adversary adaptation: The packer_dictator lineage demonstrates that behavioral detection survives TTP changes that defeat signature-based approaches. Adversaries can change section names, rotate constants, and vary metadata, but the structural behaviors required to execute their payloads remain detectable.
Low false-positive rates at scale: Because detection decisions are driven by behavioral understanding and optimizing for scale, the system maintains precision even at 14 billion files per month.
Understanding AI capabilities: Behavior analysis can include understanding of where and how AI is used in an ecosystem.
Deep understanding of the software going to production: Developers don't always know what components and behaviors make it to the production software, behavior analysis has allowed us to catch unexpected components developers didn’t realize were going to deployment.

What's Next

The partnership between Karambit.AI and Microsoft demonstrates that context-aware behavior analysis operates on a massive scale in production. As software supply chain attacks grow more sophisticated and adversaries continue evolving their TTPs and the use of AI agents to develop code, the ability to understand what software actually does, in context, across billions of files, is foundational infrastructure.

Software authenticity isn't about checking a signature or trusting a certificate. It's about confirming that every binary does what it should, and nothing more.

Karambit.AI is the software authenticity platform, ensuring software does only what the developer intended — nothing more. Learn more at karambit.ai.

Securing data and access in the era of AI with Microsoft Entra and Microsoft Purview

Heather_Poulsen — Fri, 19 Jun 2026 13:32:18 GMT

As organizations move from experimenting with AI to deploying it at scale, securing sensitive data, access, and AI usage has become mission critical.

In this series, Microsoft experts will show how Microsoft Entra and Microsoft Purview help you:

Protect sensitive data across networks, apps, and AI interactions
Govern access for users, applications, and AI agents
Reduce risk while enabling innovation at scale

Whether you're shaping your security strategy or implementing controls, you’ll walk away with the guidance you need to secure data and access to AI as one unified strategy.

DATE	TIME (PDT)	TOPIC
July 21	9:00 AM	Secure the age of AI: Redefining trust, data and access
July 22	9:00 AM	Data and identity controls for the browser and network
July 23	9:00 AM	Unlock AI agents without sacrificing security

How do I participate?

Select the sessions you are interested in, then select Add to Calendar to save the date and/or the Attend button to save your spot, receive event reminders, and participate in the Q&A.

Not able to attend live? This session will be recorded and available on demand shortly after airing.

Don't see Attend or Add to Calendar? Sign in to the Tech Community to join the conversation.

Unlock AI agents without sacrificing security

Heather_Poulsen — Fri, 19 Jun 2026 13:06:45 GMT

AI agents are reaching into mailboxes, files, line-of-business apps, and the open web on behalf of your users—and the business wants more of them, faster. To scale agents safely, your security teams need to be able to verify each agent, govern what it can access, and enforce clear boundaries across every interaction.

Learn how Microsoft Entra helps you discover shadow AI agents, govern agent permissions, keep BYOD and endpoint-based agents in scope, and apply Conditional Access to AI prompts and responses. Then see how Microsoft Purview provides visibility into agent activity, strengthens runtime data protection, helps detect agentic risk, and supports auditability across local agents developed on GitHub Copilot CLI, Claude Code, OpenAI Codex, and OpenClaw. Walk away with practical ways to unlock AI agents while keeping access and data protection aligned with your enterprise security needs.

How do I participate?

Select Add to Calendar to save the date, then click the Attend button to save your spot, receive event reminders, and participate in the Q&A. Not able to attend live? This session will be recorded and available on demand shortly after airing.

Don't see Attend or Add to Calendar? Sign in to the Tech Community to join the conversation.

This session is part of Securing data and access in the era of AI with Microsoft Entra and Microsoft Purview. View the full agenda for more insights to help you move from experimenting with AI to deploying it at scale, securing sensitive data, access, and AI usage.

Data and identity controls for the browser and network

Heather_Poulsen — Fri, 19 Jun 2026 13:07:40 GMT

Sensitive data doesn't stay still. It moves through browsers, SaaS apps, generative AI tools, and prompts; often beyond the visibility of traditional controls. In this session, see how Microsoft Entra and Purview bring real-time visibility and control to sensitive data in motion across the network. You’ll learn how integrated data security and secure access controls can help reduce leakage risk, support responsible AI adoption, and enable modern work without slowing the business down.

How do I participate?

Secure the age of AI: Redefining trust, data and access

Heather_Poulsen — Fri, 19 Jun 2026 13:08:32 GMT

There is no question that AI is transforming the enterprise: changing how data moves, how decisions are made, and how risk takes shape. As agents access, interpret, and act on sensitive data, unmanaged AI use expands and traditional boundaries blur.

Kicking off our series on Securing Data and Access in the Era of AI, Microsoft Entra VP of Product Sinead O’Donovan and Microsoft Purview GM of Product Maithili Dandige explain why legacy security models fall short in the age of AI—and why you need a strategy that brings together identity, access, and data protection. Want to adopt and enable AI innovation with greater control and confidence? Join us to learn how leading organizations are securing access, protecting data, and establishing trust for the next generation of AI-powered work.

How do I participate?

Microsoft Leads a New Era of Software Supply Chain Transparency

ShubhraS — Mon, 22 Jun 2026 18:01:03 GMT

Today, Microsoft announces the general availability of Microsoft’s Signing Transparency (MST) – a first-of-its-kind capability that brings unprecedented visibility and trust to our software supply chain. With this release, Microsoft is leading the industry by recording the build of critical cloud services into a publicly readable and verifiable SCITT standard (Supply Chain Integrity, Transparency, and Trust) compliant blockchain ledger. This means every production software build for in scope services like Azure Attestation and Azure Managed HSM (Hardware Security Module), Azure confidential ledger, Microsoft Signing Transparency itself (and others over time) – is now logged in an immutable, tamper-evident record. Only builds that are in the MST ledger are deployed to production; this gives customers confidence that the supply chain for these critical services can be audited at anytime.

Notably, the MST ledger is fully open source and built to align with the emerging IETF SCITT standard. By embracing SCITT’s principles and open protocols, Microsoft ensures that MST not only secures our own ecosystem but also contributes to a broader industry movement toward standardized supply chain transparency. The open-source MST ledger serves as a verifiable trust anchor that any organization or researcher can inspect, audit, or even integrate with their own tooling. MST itself meets the highest levels of transparency, backed by a tamper-proof confidential ledger, open-source, and independently verified. Specifically, we are making the foundation of our trust model transparent and accessible to everyone – reinforcing that trust must be earned through proof, not just promises.

This launch marks a major milestone in our commitment to Zero Trust principles, extending “never trust, always verify” all the way into the build itself. Building on a public preview introduced late last year, MST’s general availability delivers verifiable transparency at the software level. It transforms traditional code signing with an additive trust layer that is accessible via an open verification model. Every new software update is accompanied by a publicly auditable proof of integrity, enabling security teams to proactively confirm that each update is authentic and unaltered.

To help organizations get the most out of this capability, we are also introducing a free tool to explore the contents – Ledger Explorer – an offline tool that allows security teams to examine MST ledger entries, verify cryptographic proofs, and even validate the ledger’s integrity independently. This tool, combined with MST’s open design, ensures that every Microsoft customer – and the broader community – can hold us accountable in real time for the software we run on their behalf.

Key Benefits of Microsoft’s Signing Transparency (MST)

Verified Code Integrity – Every software release is cryptographically logged in MST’s ledgers. This makes each build tamper-evident and traceable. If an attacker attempts to inject malicious code or sign an unauthorized update, it will be evident through the well-defined validation step built into the SCITT standard. Organizations gain the assurance that code integrity can be independently confirmed at any time.

Independent Verification & Zero Trust – MST enables customers and auditors to verify software authenticity on their own, without having to solely rely on vendor attestations. For each update, Microsoft provides a transparency “receipt” (proof of logging) that you can use to prove the update was officially published and unaltered. This fosters a “don’t just trust, verify” approach, empowering security teams to double-check everything running in their environment aligns with what Microsoft intended.

Audit-Trail & Compliance – The transparency ledger creates a permanent, auditable timeline of code deployments. Every entry is a record of what was released and when, backed by cryptographic proofs. This simplifies compliance reporting and accelerates forensic analysis. In the event of an incident, you can quickly audit the ledger to see if any unexpected code was introduced. For highly regulated industries, MST offers concrete evidence of software integrity and policy compliance over time.

Leadership & Open Standards – We are delivering real transparency now, encouraging a future where all critical software is released with verifiable integrity. MST’s open source implementation and SCITT-compliant design exemplify our commitment to openness and collaboration. We believe widespread adoption of these standards will strengthen supply chain security for everyone, making trust verification a universal practice.

Next Steps

Microsoft’s Signing Transparency is more than a new security feature and shapes the advances in trust technology. As threats grow more sophisticated, we must evolve the way we assure our customers about the software they depend on. With MST now generally available, we are leading by example: proving that it is possible to open up the traditionally opaque process of software deployment and turn it into a source of strength and trust, i.e., empowering each person with verifiable transparency.

We invite the industry to join us on this journey and get started by reading the documentation and exploring Ledger Explorer today! Together, by embracing transparency and open standards, we can turn “trust but verify” from a slogan into an everyday reality for digital infrastructure.

New Exchange Online Mailbox Auditing Signal: Visibility into IPM to Non-IPM Copy Activity

NehaArora1 — Wed, 10 Jun 2026 15:00:00 GMT

Background: IPM vs. Non-IPM Subtree

Every Exchange Online mailbox is organized into two parts:

IPM subtree (Interpersonal Message subtree) — the visible, user-facing part of a mailbox, designed for messages exchanged between human recipients. This includes Inbox, Sent Items, Deleted Items, Calendar, Contacts, Tasks, Notes, and any custom folders a user creates. Exchange mailbox auditing has always focused on activity within this area.
Non-IPM subtree — a hidden folder structure used by Exchange and Microsoft services for system-level storage, such as the Recoverable Items folder. Users cannot see or directly interact with this area from most mail clients (like Outlook).

For more details, see IPM Subtree | Microsoft Learn.

The Audit Gap This Addresses

A known audit evasion technique involves copying mail items from a user's visible IPM folders into a hidden folder in the non-IPM subtree and then accessing the data from there for exfiltration. This technique has been observed in security investigations against Exchange Online.

This worked as an evasion method because:

Copy operations are not enabled for auditing by default
Activity in the non-IPM subtree was not audited

By staging data in the non-IPM subtree before exfiltration, this activity previously left no trace in the mailbox audit log.

What's New

Exchange Online now logs a MailItemsAccessed event whenever a mail item is copied from the IPM subtree to the non-IPM subtree.

A new AccessType value — CopyFromIPM — has been introduced to distinguish these records from existing MailItemsAccessed events, making them straightforward to query for:

AccessType	Description
Bind	Existing — individual item access
Sync	Existing — bulk sync access
CopyFromIPM	New - an item in the IPM subtree was accessed to copy its content to the non-IPM subtree

How to Query for These Records

Use the following PowerShell command to search for CopyFromIPM activity in your tenant:

Search-UnifiedAuditLog -StartDate 4/1/2026 -EndDate 4/15/2026 -FreeText "CopyFromIPM"

Understanding the CopyFromIPM Audit Record

When a CopyFromIPM event is logged, it is recorded as a MailItemsAccessed operation in the Unified Audit Log. Each record captures an individual mail item that was copied from the IPM subtree to the non-IPM subtree during the operation. When an entire folder is copied, the ItemId that is captured is the Id of the folder; individual records are not captured for each item in the folder.

Feedback

If you have any feedback about this change, you can reach out to ExchangeMailboxAudit-Support group. We are always happy to hear from you and assist in any way we can.

Level up your Azure Network Security Skills with our Upcoming Webinar Series

andrewmathu — Thu, 11 Jun 2026 18:09:16 GMT

As network and application-layer threats continue to evolve, security and infrastructure teams need more than product knowledge. They need practical, scenario-driven guidance they can apply to real workloads. To support that, the Azure Network Security team is hosting a series of upcoming technical webinars covering the capabilities our customers rely on every day: Azure Web Application Firewall (WAF), Azure Firewall, Azure DDoS Protection and Azure Bastion.

Each session is focused on demos, the latest enhancements, and the design and operational decisions you face when securing modern Azure environments. Whether you are protecting customer-facing web applications, hardening east-west and egress traffic, or securing remote administrative access at scale, there is a session in this lineup for you.

These webinars are ideal for Security Architects and Engineers, Network and Infrastructure teams, SOC Analysts, Cloud Platform Owners, Partner Technical Consultants, and any practitioner responsible for the security posture of workloads running on Azure.

Below is the schedule of the upcoming live deliveries.

Upcoming Events

Azure WAF Layer 7 DDoS defense in practice

Date and time: Thursday, June 18, 2026, at 8am PST

View event details and join

As web applications become primary targets for sophisticated application-layer attacks, Azure Web Application Firewall continues to evolve to meet the needs of modern application security teams facing volumetric and targeted application-layer threats. In this webinar, we will explore how Azure WAF enables a layered, adaptive approach to application-layer DDoS mitigation, helping organizations detect and block malicious request patterns through intelligent inspection, control traffic flow to prevent resource exhaustion from abusive sources, progressively challenge suspicious clients to verify legitimacy without disrupting real users, and combine multiple defense mechanisms into a cohesive mitigation strategy that adapts to evolving attack techniques. Whether you're securing customer-facing web apps or business-critical services, this session will equip you with practical approaches to building resilient application-layer defenses on Azure.

Azure Firewall IDPS Detections and Sentinel Integration

Date and time: Thursday, July 9, 2026, at 8am PST

View event details and join

As network threats grow in complexity, organizations need visibility that extends beyond simple traffic filtering into intelligent detection and unified investigation workflows. Azure Firewall's Intrusion Detection and Prevention capabilities continue to evolve to meet the needs of modern security operations teams facing advanced lateral movement, exploitation attempts, and command-and-control activity. In this webinar, we will explore how Azure Firewall identifies malicious network patterns in real time, how detection signals flow seamlessly into Microsoft Sentinel to enrich the broader security narrative, and how security teams can correlate firewall intelligence with other data sources to accelerate threat hunting, streamline incident response, and build a more connected and actionable view of their network security posture.

What's New in Azure Bastion

Date and time: Thursday, July 23, 2026, at 8am PST

View event details and join

Secure remote access to cloud workloads remains a critical requirement as organizations scale their Azure environments and adapt to evolving operational demands. Azure Bastion continues to evolve to meet the needs of modern infrastructure teams seeking seamless, browser-based connectivity without exposing virtual machines to the public internet. In this webinar, we'll explore the latest enhancements to Azure Bastion covering new capabilities that improve connectivity options, streamline the administrative experience, expand protocol and session support, and strengthen the overall security posture of remote access workflows. Whether you're managing a handful of VMs or operating at enterprise scale, this session will bring you up to speed on what's new and how these improvements can simplify and secure your day-to-day operations.

What's New in Azure Firewall

Date and time: Thursday, August 6, 2026, at 8am PST

View event details and join

As network architectures grow more distributed and threat landscapes more dynamic, organizations need a cloud-native firewall that keeps pace with both modern workload patterns and adversary techniques. Azure Firewall continues to evolve to meet the needs of network and security teams managing hybrid environments, multi-region deployments, and increasingly complex east-west and north-south traffic flows. In this webinar, we will explore the latest enhancements to Azure Firewall covering new policy and rule management capabilities, improvements that expand protocol and traffic inspection coverage, and deeper integrations across the Azure security ecosystem to streamline operations. Whether you are standardizing perimeter protection across a global Azure footprint or modernizing segmentation for business-critical workloads, this session will bring you up to speed on what is new and how these improvements can simplify and strengthen your day-to-day network security operations.

What's New in Azure Web Application Firewall

Date and time: Thursday, August 27, 2026, at 8am PST

View event details and join

Web applications remain primary entry points for attackers, and organizations need a Web Application Firewall that adapts as quickly as the threats targeting their workloads. Azure Web Application Firewall continues to evolve to meet the needs of modern application security teams defending against an expanding mix of OWASP-class attacks, automated abuse, and business logic threats across diverse hosting models. In this webinar, we will explore the latest enhancements to Azure WAF. We will cover new detection and rule capabilities that improve protection accuracy, tuning and exclusion improvements that reduce false positives without weakening coverage, and expanded visibility and analytics that accelerate investigation. Whether you are securing customer-facing web apps or managing WAF policies at scale, this session will bring you up to speed on what's new and how these improvements can simplify and strengthen your application protection strategy

Past Recordings:

View additional past webinars from Azure Network Security on Microsoft Security Community YouTube.

Stay connected with the Azure Network Security community

Influence product feedback and join the Threat Protection Advisors Program

Stay up-to-date and follow the Azure Network Security Blog | Microsoft Community Hub

Engage with peers, ask and answer questions in the Azure Network Security discussion board

---

Learn and Engage with the Microsoft Security Community 

Log in and follow this Microsoft Security Community Blog and post/ interact in the Microsoft Security Community discussion spaces.
- Follow = Click the heart in the upper right when you're logged in 🤍

Join the Microsoft Security Community and be notified of upcoming events, product feedback surveys, and more.

Get early access to Microsoft Security products and provide feedback to engineers by joining the Microsoft Security Advisors..

Learn about the Microsoft MVP Program.

Join the Microsoft Security Community LinkedIn and the Microsoft Entra Community LinkedIn

June 4 - Secure Boot AMA

Heather_Poulsen — Wed, 03 Jun 2026 17:23:06 GMT

Microsoft is updating the Secure Boot certificates originally issued in 2011 to ensure Windows devices continue to verify trusted boot software. These older certificates begin expiring in June 2026. Devices that haven’t received the newer 2023 certificates will continue to start and operate normally, and standard Windows updates will continue to install. However, these devices will no longer be able to receive new security protections for the early boot process, including updates to Windows Boot Manager, Secure Boot databases, revocation lists, or mitigations for newly discovered boot level vulnerabilities.

Whether you are already working through Secure Boot certificate updates across your estate, or aren't sure where to start, you can get answers to your questions and helpful insights at the next Secure Boot AMA on 8:00 a.m. PDT June 4, 2026. Can't attend live? No problem. Post your questions in advance.

Visit https://aka.ms/AMA/SecureBoot to save the date and post your questions.

For detailed, step-by-step guidance, see the following resources:

Securing the new risk surface: local agents, claws, and open runtimes

Herain_Oberoi — Tue, 02 Jun 2026 17:15:00 GMT

The next wave of AI is more than just powerful models. We’re now seeing intelligent agents that run locally on our devices, interacting directly with sensitive data, apps, and systems. Some operate persistently: monitoring, planning, and executing tasks over time instead of just responding to one-off prompts. We call these more sustained, autonomous processes “claws.” Together, local agents and claws are changing how work gets done. They also introduce a new risk surface for organizations: these agents often run with deep access and minimal oversight on endpoints, meaning a single misstep or malicious input could lead to misuse of data, unintended system changes, or other real-world impacts.

A new class of risk: when agents run locally

Enterprise security teams already understand the risks introduced by AI agents in cloud services and managed platforms. Local agents introduce a different, and in many ways more acute, risk profile.

When agents run locally on endpoints, they operate inside the user’s trust boundary. They inherit the device context, user credentials, local files, cached tokens, browser sessions, and developer tools already present on that machine. Unlike centrally managed cloud agents, local agents can be created, modified, and executed with little to no centralized oversight, often outside established onboarding and governance workflows.

This creates a distinct risk scenario:

High privilege by proximity – Local agents often run under a user’s full identity and permissions, with direct access to sensitive data and systems the user can reach.
Reduced visibility – Security teams may not know which agents are running locally, how they are configured, or what external services they communicate with.
Immediate impact – A single malicious input, compromised dependency, or unsafe configuration can translate directly into data exposure, destructive system changes, or unauthorized external communication, at endpoint speed.

The risk is not theoretical. As recent incidents have shown, a locally running agent with overly broad permissions can issue destructive commands, leak sensitive data, or propagate errors faster than traditional software controls can react[1]. Existing endpoint and application security models were not designed for autonomous systems making decisions continuously on user devices.

To reduce this risk, security must extend beyond application boundaries and into the agent operating environment. Organizations need visibility into local agents, control over where and how they run, and enforcement of policy as agents act, before unsafe behavior can cause harm.

A secure agent operating environment

Microsoft’s approach to agent security is already well established: secure agents as systems, not individual tools, with consistent visibility, control, and enforcement across identity, data, network, and runtime. Today’s announcements build on that foundation by extending the same agent security model to local agents running on endpoints.

Local agents introduce a different operating reality. They run on user devices, inherit local context, and act with direct proximity to sensitive data, credentials, and tools. Securing them requires bringing endpoint‑level agents into the same control framework CISOs already rely on, without fragmenting governance or creating new blind spots.

To do this, Microsoft extends the Agent 365 control plane to local agents, delivering outcomes security leaders expect:

Observe: Gain a unified view of known local agents across the enterprise to identify what is running, where, and with what access, reducing blind spots before risk materializes.
Secure: Contain agent activity and help enforce controls in real time to block unsafe behavior, prevent unauthorized access, and stop sensitive data loss before impact.
Govern: Apply consistent policy and audit across the agent lifecycle to help ensure accountability, enforce standards, and maintain control as agent behavior evolves over time.

By extending Microsoft Agent 365 to the endpoint, local agents and claws can now operate under the same standards of oversight as cloud‑based agents. This reduces risk while enabling organizations to confidently adopt local, autonomous agents as part of their enterprise AI strategy.

Observe: discover and understand local agents

The first step in reducing risk is always visibility. Local agents often emerge and operate outside traditional IT oversight, what we call “shadow AI”. If security teams can’t see these agents, they can’t manage or protect them. Therefore, true observability into local agent presence and behavior is critical: organizations need an updated inventory of known local agents, where they’re running, and what they can access. With that knowledge, CISOs and their teams can assess exposure and take informed action.

Today, Microsoft is introducing agent observability for 20+ local AI agents running on managed Windows and MacOS devices as first-class security assets. Together, these signals roll up into a unified agent inventory that is surfaced through the security and admin experiences teams already use, so IT, security, and identity teams can see and assess potential local agent risk in the context of their existing workflows.

Agent 365 Agent Registry (including Shadow AI) provides a system of record for local agents that have been brought under governance, while also surfacing unmanaged or unsanctioned local agents detected on managed endpoints. Together, these capabilities give security teams visibility into both known local agents and previously unknown agent activity, using existing endpoint security signals. Teams can assess risk, decide whether to block execution, or bring local agents under governance as part of an end-to-end control workflow. Public preview coming later in June. Learn more.

Shadow AI detection in the Microsoft 365 admin center, showing unmanaged agents and their publishers across the tenant.

Microsoft Defender now discovers and profiles supported local AI agents on eligible Microsoft Defender onboarded devices. It surfaces each agent’s configuration, such as any associated Model Context Protocol (MCP) servers, and maps it to the device and user identity under which it runs. This approach gives security teams a clear picture of potential exposure for supported agents: what it can reach and what it is entitled to access, making it easier to identify potentially risky combinations, such as auto-approval of agents running with elevated permissions on devices that contain sensitive data, and investigate using the same endpoint telemetry security teams already use in Defender. Now in public preview. Learn more.
Microsoft Purview extends observability into the data layer by showing how agents interact with sensitive information across the environment. It helps identify potential exposure paths where data could be overshared, leaked, or used in ways that increase risk. This insight gives organizations the context they need to help reduce data security and compliance risk as part of broader agent governance. Now in public preview. Learn more.
Microsoft Entra extends its Secure Access Service Edge (SASE) architecture to local agents, bringing identity‑aware, network‑level visibility to agents running on Windows and MacOS devices. By correlating network signals with Defender endpoint telemetry, security teams can see which local agents communicate externally, how they are configured, and which resources they are permitted to reach versus what they actually access. This elevates local agent network behavior into first‑class security insight, helping teams identify previously unknown or unmanaged agents and assess risk quickly. These insights surface through the Agent 365 experience, enabling faster, more confident decisions about local agent exposure. Now in public preview. Learn more

Together, these capabilities help organizations with a unified, updated view of known local agent activity and potential risks, helping to minimize blind spots at the endpoint. But visibility alone does not reduce risk. To do that, organizations must also control how local agents behave—both where they run and what they do in real time.

Secure: contain and enforce local agent actions

As the earlier example illustrates, the risk is not just that local agents exist, but that they act autonomously. A single decision can translate directly into real‑world impact, accessing data, executing code, or modifying systems at machine speed.

Reducing this risk requires two layers of protection. First, organizations must control where agents run and what they can access by design. Second, they must enforce controls as agents act, helping to stop unsafe behavior in real time. Microsoft delivers both through OS‑level containment and runtime enforcement.

Execution environment: control agent behavior by design

Containment helps organizations bound what agents can access and do, preventing dynamic behavior from turning into unintended impact. Today, we’re announcing execution‑environment controls that define where local agents run and what they can access, limiting exposure by design.

Windows 365 for Agents provides Cloud PCs that enable AI agents to execute multi-step workflows across software, including opening apps, navigating interfaces, entering inputs, and processing data. Today, we are making Windows 365 for Agents generally available within Agent 365, enabling Agent builders to build computer-using agents for a variety of enterprise use cases. Now generally available within Agent 365. Learn more.
Microsoft Execution Containers (MXC) helps to contain agent impact without limiting productivity gains. MXC is a cross-platform, policy-driven execution layer for agents across Windows and WSL. Developers declare what an agent can access — like files and networking related policies — and MXC enforces those boundaries at runtime. Windows delivers a composable sandbox through MXC—a single SDK and policy model that maps to the right isolation construct for any agent workload, from fast process isolation (adopted by GitHub Copilot CLI) to micro-VMs, Linux containers, and cloud instances via Windows 365. Session isolation separates the agent's execution from the user's desktop, clipboard, UI, and input devices, and critically, binds the agent to a strong user identity — mitigating UI spoofing, input injection, and cross-session data leakage. Agent 365 layers Entra and Intune policy on top so IT can govern containment centrally while developers choose the guardrail weight their workload demands. Now available in early preview. Learn more.
OS-enforced Agent Identity and enterprise manageability on Windows: beyond containment, every agent activity must be attributable and governed. Windows assigns agents a local ID or a cloud provisioned identity backed by Entra and attributes all activity from the container to that identity, so you can clearly differentiate human from agent. Native Windows integration with Agent 365 provides a common foundation for observability, security and governance, including native Intune integration to set policies that gate the agent runtime execution and control how agents run. Defender, Entra, Intune and Purview will provide runtime protections for evolving threats across access, sensitive data, malicious prompts, and risky behavior so security and IT teams can prevent enterprise risk. Learn more.

Runtime: enforce controls as agents act

If the execution environment defines where agents are allowed to operate, runtime enforcement governs what they are allowed to do. This is the moment an agent accesses sensitive data, invokes tools, or takes action under a user’s identity, and where real‑time controls matter most.

Today, we are announcing runtime controls across identity, data, and threat protection for Claude Code and GitHub Copilot CLI, with OpenClaw and OpenAI Codex support coming in late June.

Microsoft Defender adds runtime protection for supported local AI agents on Windows, helping to detect unsafe or malicious behavior inline across prompts, tool calls, and responses. Based on policy, Defender can help block or audit agent actions and raise alerts with agent context, enabling investigation using the same telemetry and hunting workflows security teams already use. Now in public preview. Learn more.

Microsoft Defender enforcement of policies during a local agent interaction with a potential threat

Microsoft Purview extends enforcement of Data Loss Prevention policies to local agent interactions, preventing sensitive data leakage and exfiltration as agents execute tasks, call tools, or generate outputs. These controls help reduce AI-driven data risks while maintaining productivity and providing visibility into recurring risky behaviors across agent sessions. Now in public preview. Learn more.

Microsoft Purview enforcement of Data Loss Prevention policies during a local agent interaction with sensitive data

Microsoft Entra extends the Secure Access Service Edge (SASE) model to local agents by enforcing network-based security controls at runtime, as agents act. Security teams can apply agent-specific network policies directly to agent traffic—separate from user traffic—to restrict web access to authorized destinations, control file transfers, and limit connections to trusted services. Enforced inline during execution, these controls help reduce the risk of data exfiltration, unauthorized access, and communication with untrusted systems, while maintaining consistent, policy‑driven control over local agent behavior. Now in public preview. Learn more.

Together with environment-level containment, these controls help to secure not just where agents run, but how they act.

Govern: sustain control with policy and audit

As agents become persistent systems operating over time, risk extends beyond individual actions to sustained and evolving behavior. Without governance, organizations lose visibility into how agents evolve, what they access, and whether their actions remain aligned with policy. Sustaining trust in local agents requires continuous oversight, accountability, and lifecycle control.

Today, we’re announcing governance controls that keep local agent activity accountable over time through policy and audit.

Microsoft Intune helps control how agents run on managed devices by applying endpoint policies that reduce device-level risk. It enables teams to help block OpenClaw on Windows and apply security policies for runtime protection, now in public preview. With MXC as well as Windows 365 for Agents, administrators can use Intune to configure the environments for managed agents running locally and on Cloud PCs. This helps organizations apply controls across deployment models, prevent unauthorized agent activity, and maintain real-time governance over execution.

In the Microsoft Intune admin center, an IT professional can apply policies to configure agents like OpenClaw to run in MXC and manage what they can access.

Microsoft Purview provides a comprehensive audit record of agent activity over time, capturing how local agents access, use, and interact with sensitive data. These audit logs support investigation, compliance reporting, and accountability, helping to ensure agent actions are traceable and defensible long after execution. Now in public preview for supported agents. Learn more.

Together, these governance capabilities help to ensure that local agent activity is not only controlled in the moment, but managed consistently over time, with visibility and accountability for every action. This enables organizations to move beyond limited AI pilots to trusted, auditable, enterprise‑scale adoption of agentic AI.

From unmanaged claws to secure and governed agents

The result of extending visibility, runtime enforcement, and governance across the agent operating environment is a shift from unmanaged local agents and claws to a secure, enterprise‑ready system. Each layer of Microsoft’s security stack plays a clear role:

Agent 365 provides the unified control plane now for local agents that includes:

Microsoft Defender to detect and block unsafe actions
Microsoft Purview to provide data protection and compliance
Microsoft Entra to enforce network access controls
Microsoft Intune governs execution through device policy

And Microsoft Windows enforces execution boundaries at the platform layer

Together, these layers form a defense‑in‑depth model that helps to close gaps across the local agent lifecycle.

Enabling agentic AI with confidence

Local agents and claws introduce a new class of enterprise risk, as autonomous systems operate continuously across identities, data, and systems. They break assumptions that traditional security models rely on.

Microsoft addresses this shift by securing the agent operating environment itself—helping organizations identify known agents through unified observability, help secure agent actions via real-time enforcement of policies, and govern agent interactions over time through consistent policy and audit.

AI adoption is accelerating faster than the governance structures organizations have in place to manage it. Extending proven security principles to local agents and claws is how that gap gets closed.

Learn more: aka.ms/securityforAI

[1] Claude AI agent wipes firm’s database in 9 seconds | Cybernews

Microsoft Purview enables developers with strong data security across AI apps and agents

Nathalia_Borges — Tue, 02 Jun 2026 17:14:32 GMT

Today, developers are at the center of a new wave of innovation—building AI applications and agents that are deeply connected to enterprise data. But with this opportunity comes a new and complex set of security challenges. AI systems operate across cloud platforms, third-party services, and even local and on-premises development environments, interacting dynamically with sensitive data such as customer records, financial information, and intellectual property. Traditional security approaches weren’t designed for this level of scale, autonomy, or fluid data movement—leaving developers to navigate fragmented tools, unclear policies, and the risk of unintentionally exposing sensitive information.

At the same time, expectations are rising. Organizations need to ensure that AI applications and agents are compliant, auditable, and secure by default on an enterprise-level—not retrofitted after deployment. But for developers, adding security often means additional complexity, custom integrations, and slower time to market. This tension between speed and control has become one of the biggest barriers to moving AI from experimentation into production.

Microsoft Purview is designed to help with this challenge by embedding data security and compliance controls across the development cycle. Purview provides a consistent way to govern how data is accessed, used, and shared—without requiring developers to become security experts. The result is a simpler path to building AI systems that are secure, compliant, and enterprise-ready by design.

Extending data security and compliance to local agents and claws

Local and endpoint agents, built in platforms such as GitHub Copilot CLI and OpenClaw, introduce a new class of data security challenges as they operate outside traditional control planes and directly on user machines. Unlike cloud systems, these agents can access local files, credentials, terminals, and enterprise apps simultaneously—often moving data across tools and environments. This expands data risks, from sensitive data being unintentionally stored, copied, or shared, to API keys and tokens being exposed, and autonomous workflows triggering data movement without explicit user intent. At the same time, many existing security controls were designed for browser or cloud-based activity, leaving a growing blind spot at the endpoint where agents are increasingly running. The result is a widening gap between how developers build agents to operate locally in the users machines, and how organizations can detect, govern, and protect the data those agents interact with.

Microsoft Security and Windows are integrating management and security capabilities directly into the local agents’ development workflow, enabling security as an architectural guarantee rather than an implementation choice.

At Build, we are thrilled to be extending Purview visibility and protection capabilities to local agents developed on GitHub Copilot CLI, Claude Code, OpenAI Codex, and OpenClaw - in Public Preview. Unlike traditional cloud applications, these agents operate closer to the data and often create new risks for data exposure. Purview addresses this challenge across all types of agent interactions with a clear, simplified set of scenarios:

▪ Observability: Visibility on Purview Data Security Posture Management (DSPM) across agent inventory, as well as into how local agents interact with sensitive data—across prompts, responses, and actions.

▪ Runtime data protection: Purview Data Loss Prevention (DLP) controls enforced directly into the agent execution flow, inspecting prompts and tool calls in real time to prevent sensitive data exfiltration.

▪ Agentic risk detection: Risky or anomalous agent behaviors detected through Insider Risk Management (IRM) signals, helping teams detect unsafe interactions early.

▪ Audit: Comprehensive, end-to-end logging of all local agent interactions—capturing prompts, responses, data access, and actions for data context.

For example, a developer is using a local coding agent to generate code and accidentally includes sensitive credentials in a prompt. AI observability in DSPM surfaces the interaction and shows what data the agent accessed. DLP detects the sensitive data in real time and blocks it from being sent or processed (or sensitive files from being accessed and exfiltrated). At the same time, agentic risk detection flags the session as high risk based on the behavior pattern. All of this activity is captured in audit logs, enabling the security team to investigate and take action quickly.

Data protection policy blocks agent interaction with sensitive data

Developers and security teams gain visibility into agent activity and data interactions, while policies prevent sensitive data leakage. This ensures consistent security outcomes across both cloud and endpoint environments, without disrupting developer workflows.

Strengthening visibility and controls for Foundry agents

Foundry gives developers a central place to build and manage AI agents, but it also creates a need for data security context directly in that workflow—especially as prompts, model interactions, and downstream actions increasingly involve sensitive enterprise data.

At Build, we are excited to announce the expansion of the Foundry integration with Purview. This includes Purview DLP runtime controls for prompt processing in Foundry, in Public Preview. As agents and applications built on Foundry increasingly interact with sensitive data, Purview ensures those interactions are governed by trusted controls, identifying Sensitive Information Types (SITs) in real time to detect and protect confidential data embedded in prompts. For example, if a user includes customer PII or financial data in a prompt, Purview can automatically identify the sensitive content and block that prompt from being processed by the model. This ensures that all Foundry apps and agents, regardless of how they’re built or deployed, inherit consistent data protection – allowing organizations to reduce risk of inadvertent data exposure, centralize compliance enforcement across AI workloads, and confidently scale AI adoption knowing sensitive data is protected by design.

We’re also building up on the Purview coverage for Foundry shared at the last Microsoft Ignite by announcing Purview insights embedded directly into the Foundry Control Plane, in General Availability, bringing rich data security context to the plane where developers already work. Purview surfaces crucial signals—such as SITs detected in the agentic interactions, % of agentic interactions involving sensitive data, and spread of high-risk users — so Foundry admins can know how AI apps and agents are built in their environment. This shift enables developers to make faster, better decisions in the moment, reducing rework and closing security gaps early on.

Purview Audit embedded in the Foundry Control Plane

For customers, the value is clear: stronger security by design and at enterprise scale, accelerated development cycles, and reduced risk of data leaks or compliance issues—without slowing down innovation.

Innovating for developers everywhere, at the pace of AI growth

Microsoft is also expanding Purview’s reach across the broader developer ecosystem. New integrations help organizations apply consistent oversight to AI tools and platforms developers already use, without adding separate compliance workflows.

GitHub Copilot is a critical productivity layer for developers, accelerating how code is written and shipped—making it equally important that developer interactions with GitHub Copilot are governed and secured with the same rigor as enterprise data. Microsoft Purview now extends data governance and compliance capabilities to GitHub Copilot interactions, in Public Preview, enabling GitHub Enterprise customers with Entra SSO to stream audit logs directly into Purview. This brings centralized visibility for AI activity, allowing security and compliance teams to analyze GitHub Copilot agent session activity alongside other AI workloads. With this native integration into GitHub workflows, Purview audits Copilot activity across repositories, pull requests, and developer sessions—ensuring AI-generated code aligns with enterprise data policies, compliance requirements, and secure development standards.

By integrating Purview into existing workflows, organizations can govern GitHub AI usage without building parallel pipelines—reducing complexity while ensuring consistent compliance coverage across their entire data estate.

Purview capabilities configured directly into the GitHub Copilot experience

Today’s AI agents aren’t built in just one ecosystem—they span custom apps, third-party platforms, and open-source frameworks. Without consistent controls, this creates blind spots where sensitive data can be exposed outside enterprise guardrails. That’s why extending Purview protection beyond Microsoft environments is critical: it ensures developers can apply the same data security, DLP policies, and compliance controls to any agent, anywhere—so innovation can scale without increasing risk.

Developers already use Microsoft Purview APIs to embed data protection into enterprise workflows. Today, we’re introducing the Microsoft Purview SDK for .NET — a simple, drop-in toolkit that brings Purview capabilities directly into any application, in Public Preview. Instead of weeks spent wiring APIs, authentication, and error handling, developers can add content scanning, DLP checks, and sensitivity labeling in just a few lines of code. The SDK handles the heavy lifting — including auth, retries, caching, and telemetry — so teams can focus on building experiences.

For AI apps and agents built outside of the Microsoft AI platforms, SDK adds built-in support and can evaluate prompts and responses in real time against DLP and content policies — helping prevent data exposure at runtime without custom logic.

Designed for both real-time and asynchronous patterns, and for authenticated or anonymous flows, the SDK also feeds activity back into Purview to give security teams centralized visibility and control. The bottom line is- the Microsoft Purview SDK enables developers to build AI apps and agents that are secure and compliant by default — cutting integration time from weeks to days while ensuring data protection scales with AI. The SDK will be available in public preview within the next month.

Together, these announcements represent a significant step forward in how developers build secure AI systems. Microsoft Purview is no longer just a data security and compliance solution—it is a first-class layer of the development process by protecting data across AI applications and agents, and enables a bridge between developers and security teams. As AI becomes more agentic, distributed, and deeply connected to enterprise data, the need for built-in security will only grow. With Purview, developers no longer must choose between speed and security—they can build both into every application from the start

Getting connected with Microsoft Purview and learn more

Learn more about Microsoft Purview on our website and Microsoft Learn.

Explore Agent 365.

Try Microsoft Purview data security.

Learn more about Microsoft Purview SDK.

New Windows Features to Secure Today’s Data in a Post-Quantum World

AabhaThipsay — Tue, 02 Jun 2026 16:30:00 GMT

Quantum safety is a staged transition across customer environments. Windows is enabling this progression by extending quantum-safe support beyond algorithms and APIs, into the protocols and platform components that organizations use the most. This foundation empowers customers to build, validate, pilot, and ultimately deploy quantum-safe applications, systems, and infrastructure at scale.

Microsoft’s earlier announcements introduced PQC support in the core cryptographic building blocks and outlined the broader Quantum Safe Program, including the need for crypto-agility, standards alignment, and a practical migration path. Microsoft delivered a key milestone last November by making PQC algorithms generally available on Windows 11 and Windows Server 2025.

Now, we’re bringing quantum-safe capabilities to where they are used: adding PQ TLS hybrid key exchange to the Windows Transport Layer Security (TLS) stack, enabling composite PQC algorithms in Windows cryptography APIs and certificate functions, and bringing the ability to generate PQ certificates via Active Directory Certificate Services (ADCS). Together, these advances help organizations address long-lived data risks now and begin preparing for the broader transition across authentication, certificates, device protection, and management workflows.

These updates are part of a broader transition: bringing quantum-safe security into the systems and workflows on which organizations already rely.

PQ TLS hybrid key exchange comes to Windows

The Windows TLS stack is a core component for secure communication across the platform. Adding PQ TLS hybrid key exchange brings quantum-safe protection to real data-in-transit scenarios that already run on Windows.

Hybrid key exchange combines classical and post-quantum algorithms, allowing organizations to begin mitigating HNDL risks. This is especially important for data that must remain confidential for years, as adversaries can capture encrypted traffic today and attempt to decrypt it in the future when quantum computing becomes practical.

This reflects Microsoft’s ongoing work in standards development and broader platform investments, including the core cryptographic library SymCrypt, Windows cryptography APIs, and certificate handling. TLS PQ hybrid key exchange is available now in preview through the Windows Insider Program and will become generally available on Windows 11 and Windows Server 2025 in the coming months.

These new quantum safe key exchange options can be configured the same way as existing TLS curves (the classical encryption groups already in use today). IT administrators can enable them using familiar Windows management tools: Group Policy for domain-joined enterprise environments, Mobile Device Management (MDM) for modern device management platforms such as Intune, or TLS PowerShell cmdlets (scripted configuration commands) for manual or automated setup. The following hybrid combinations — each pairing a classical algorithm with the post-quantum NIST ML-KEM algorithm to protect against both current and future threats — are available:

X25519_MLKEM768 — combines the widely-used X25519 classical algorithm with ML-KEM

SecP256r1_MLKEM768 — combines the NIST P-256 elliptic curve with ML-KEM

SecP384r1_MLKEM1024 — combines the NIST P-384 elliptic curve with ML-KEM at a higher security level

In practical terms, bringing this capability to Windows enables security teams and application owners to evaluate real, Windows-native deployments and begin planning the policy and configuration updates needed for quantum-safe readiness. It provides a direct path to start testing in familiar Windows environments, without relying only on specialized preview stacks. Our TLS supported groups page describes the PQ TLS hybrid key exchange groups available and how to enable them in your environment.

Composite PQC algorithms in Windows cryptography APIs

Windows cryptography APIs are adding support for composite ML-KEM and composite ML-DSA, where ML‑KEM (Module-Lattice Key Encapsulation Mechanism) and ML‑DSA (Module-Lattice Digital Signature Algorithm) are NIST approved PQ algorithms for key exchange and digital signatures respectively. Composite approaches are important for transition because they allow cryptographic operations to incorporate both classical and post-quantum components.

Composite algorithms provide defense in depth by requiring an adversary to break all components to compromise protected data. When implemented natively, they abstract away the complexity of securely combining multiple algorithms, reducing the risk of incorrect integrations and strengthening resilience against weaknesses in individual schemes. This work follows the IETF drafts for composite ML-DSA and composite ML-KEM, to combine the traditional digital signature algorithm ECDSA with ML-DSA and traditional key exchange algorithm ECDHE with ML-KEM.

For developers, platform engineers, and security architects, this means Windows-native APIs are moving beyond foundational primitives toward the real-world certificate and signing patterns required in production environments. Composite support enables organizations to prototype new certificate profiles, evaluate trust chain impacts, and prepare for scenarios as relying parties, issuing systems, and policy controls adopt post-quantum capabilities at different speeds.

These capabilities are in Windows Insider Preview for Cryptography API Next Generation and certificate functions and will become generally available on Windows 11 and Windows Server 2025 in the coming months. Visit our crypto developers page to learn more and get started.

PQ Certificates come to ADCS

Active Directory Certificate Services (ADCS) support for issuance of ML‑DSA certificates in Windows Server 2025 is now generally available as of May 2026, bringing PQC support into enterprise public key infrastructure (PKI). ML‑DSA enables quantum‑resistant signing operations across Certification Authorities (CAs) and Online Certificate Status Protocol (OCSP) Responders, providing a practical way to evaluate post‑quantum certificate issuance and trust validation workflows.

ADCS supports three ML‑DSA parameter sets (ML‑DSA‑44, ML‑DSA‑65, ML‑DSA‑87), allowing organizations to balance security strength with key and signature size for scenarios like code signing and TLS certificates. PQC support requires newly deployed CAs (as existing CAs cannot be upgraded in place), so organizations can introduce a parallel CA hierarchy alongside existing infrastructure to test and validate deployments without disrupting production workloads.

Additional post‑quantum capabilities, including ML‑KEM and composite algorithm support, are planned later this year to expand beyond signing scenarios and enable broader certificate interoperability.

What this means for security teams and developers

For many organizations, these announcements provide a clear starting point to adopt quantum-safe cryptography. The Windows platform now enables early validation and integration of PQC capabilities across applications and infrastructure.

The most effective migrations will be phased. Organizations should start by inventorying where public-key cryptography is used, prioritizing systems that protect sensitive data with long confidentiality lifetimes, and testing hybrid and composite approaches in non-production environments.

Security teams can start by identifying where long-lived data is at risk, such as document repositories (e.g., SharePoint), email archives, database systems, and backup or archival storage (including device and cloud backups), and prioritizing the systems that depend on TLS and certificate-based trust. They can then map which applications rely on Windows cryptographic interfaces. Developers can test new algorithm support in controlled environments. IT administrators can prepare for the operational changes required for quantum-safe migration, including across certificates, device policy, performance validation, interoperability testing, and cryptographic inventory management.

The goal is not only to adopt new algorithms, but to build crypto-agility into processes so future transitions are easier to manage. These latest Windows capabilities make it easier for that work to begin in a more practical, standards-aligned way.

Looking ahead: the next wave of quantum-safe capabilities in Windows

These announcements mark early but important steps in bringing quantum-safe capabilities into the Windows scenarios organizations depend on most. Beyond foundational cryptography and PQ hybrid key exchange, that roadmap extends across certificate lifecycle workflows, networking protections such as IPsec and Wi-Fi, authentication scenarios including TLS and Kerberos, passwordless experiences like Windows Hello and passkeys, and platform protections that rely on trusted keys, certificates, and recovery flows.

This future direction includes additional capabilities like composite PQ support in ADCS, which will be central to enterprise certificate enrollment and issuance, as well as BitLocker, software signing, and firmware signing. Customers will see progress in some of these areas this year, with additional advancements planned for 2027.

Across these investments, the goal remains consistent: to help customers move from algorithm availability to deployable, manageable, enterprise-ready, and quantum-safe solutions.

Preparing now for the transition ahead

The transition to quantum safety will take time, testing, and close coordination across standards bodies, platform providers, software developers, and enterprise security teams. But momentum matters.

By expanding Windows support from foundational post-quantum primitives to real protocol and certificate scenarios, Microsoft is helping make that transition more practical. TLS PQ hybrid key exchange in the Windows TLS stack, composite PQC algorithms in Windows cryptography APIs, and PQC capabilities in ADCS represent important next steps in turning quantum-safe readiness into deployable capability.

As the roadmap continues to unfold across certificates, authentication, and platform protection, the best time for organizations to begin preparing is now.

Securing today. Preparing for what’s next.

Security in Windows is built into the platform - continuously maintained and designed to evolve as threats change.

Learn more in the Windows Security book and Windows Server Security book or explore Windows 11, Windows Server, and Copilot+ PCs. 

For broader solutions, visit the  Microsoft Security site, follow the Security blog, or connect with Microsoft Security on LinkedIn and @MSFTSecurity.   

Share Your Use Case in a Lighting Talk

RenWoods — Mon, 01 Jun 2026 19:38:07 GMT

Microsoft Security Store Lightning Talks are high‑energy, community-led mini sessions spotlighting real users like you who are putting Microsoft Security Store agents and solutions to work, driving measurable impact through faster workflows, smarter automation, and stronger security outcomes.

Selected sessions will be recorded and curated into a single can’t‑miss public virtual event, with speakers live in chat to answer questions and help attendees translate ideas into action. After the event, each speaker receives a dedicated Microsoft Security Community YouTube link for their segment, ready to share and keep up the community momentum.

Any user of agents of solutions from the Microsoft Security Store are welcome to submit a session; multiple submissions are welcome: aka.ms/MSScfp | Due June 4^th

See examples of Microsoft Security Community Lightning Talks here
Sessions must be no longer than 10 minutes long and session submissions/descriptions can be 1-3 sentences.
More information on the requirements and timeline can be found within the submission form.
Event date: July 30th.
- Interested in registering for the event? Watch this event space and follow this blog post - yes, the one you're reading! Sign in (upper right corner) then click the heart to follow and be alerted on updates.
Have questions? Feel free to post in the comments below. Need help? Let us know by sending RenWoods a direct message.
Professional speaking experience is not required in this community-focused event. Microsoft employees are not eligible to present.

Submit your Microsoft Security Store Lightning Talk today!

Learn and Engage with the Microsoft Security Community

Log in and follow this Microsoft Security Community Blog and post/ interact in the Microsoft Security Community discussion spaces.
- Follow = Click the heart in the upper right when you're logged in 🤍
Join the Microsoft Security Community and be notified of upcoming events, product feedback surveys, and more.
Get early access to Microsoft Security products and provide feedback to engineers by joining the Microsoft Security Advisors..
Learn about the Microsoft MVP Program.
Join the Microsoft Security Community LinkedIn and the Microsoft Entra Community LinkedIn

Why “Data in Switzerland” Is Not Enough

AladinH — Tue, 02 Jun 2026 17:52:25 GMT

Moving from Residency to Control in Microsoft 365

Every conversation about data sovereignty in regulated industries tends to start the same way:

“We use Multi-Geo. The data stays in Switzerland.”

It’s the right starting point. Microsoft 365 Multi-Geo allows organizations to place selected workloads - SharePoint sites, OneDrive accounts, Teams data, or Exchange mailboxes - into specific regions, including Switzerland, while maintaining a single global tenant. This makes it possible to align sensitive data with regulatory or customer requirements without fragmenting the overall environment.

But it only answers one question:

Where is the data stored?

It does not answer who accessed the data, from where, under which conditions, or what happened after access. That is where the real problem begins.

A scenario that happens every day

A Swiss engineering firm stores sensitive project documentation in Switzerland using Multi-Geo. An external contractor - working from an unmanaged device outside Switzerland - is granted access to review a file. The document opens. The data is now on a screen in an unknown location, on a device with no compliance posture, in a session with no restrictions.

From the platform’s perspective, residency was enforced. From a sovereignty perspective, control was lost the moment access was granted without conditions.

The file never left Switzerland. But sovereignty did.

Residency is static. Control is not.

The moment a document is opened, storage location stops being the relevant boundary. The file is no longer just “in Switzerland.” It moves instantly across endpoints and browsers, collaboration tools like Teams, external users and partners, and increasingly AI-driven contexts.

The infrastructure remains unchanged. The data does not. From the platform’s perspective, everything is working as designed - access was granted, residency was enforced - and control was lost.

Most “data in Switzerland” strategies fail at exactly this moment: when the data is used.

The shift: from location to conditions

If data sovereignty is the goal, the question must change. Not “Where is the data stored?” but:

Under which conditions can data be accessed and used?

This shift fundamentally changes the architecture. Control must be applied across three distinct layers - and all three must be connected.

Layer 1: Access is conditional, not static

Conditional Access extends control beyond authentication and turns it into continuous evaluation. Access decisions can depend on:

Device compliance
Location (geo-restriction)
Identity and risk signals

Multi-Geo ensures data is placed correctly. Conditional Access ensures it is reachable only under defined conditions. The two must work together - residency without access governance is an incomplete control.

Layer 2: The session is the real risk surface

Even with strict access controls, risk remains. A session is an exposure surface by design. During an active session, data is viewed, copied, shared, processed by applications, and connected to AI prompts.

The gap does not appear at storage or authentication. It appears during active usage - inside the session. This is the layer most architectures do not explicitly address.

Controls must extend into the session itself: limiting data transfer and replication, restricting interaction patterns, and enforcing policies in real time. Access is no longer a one-time event. It becomes continuously governed.

This becomes even more critical as AI assistants consume content across SharePoint, Teams, Exchange, and other Microsoft 365 services. The question is no longer only where the source document resides - but whether the AI interaction itself is governed by the same access and protection controls as direct access.

Layer 3: The document becomes the control point

The most durable control does not sit in the network or in the session. It sits in the data itself.

In regulated industries, organizations often arrive at this architecture having first evaluated sovereign or national encryption solutions. The decision to rely on native Microsoft 365 Purview encryption rather than a separate layer comes down to integration: AES-256 protection operating natively at file, user, and SharePoint level - including geo-based access restrictions - without an additional system to maintain.

When protection is applied directly to the document through Microsoft Purview:

Sensitivity labels define classification - automatically assigned based on content
Encryption enforces access - AES-256, bound to the file itself
IRM controls usage - view, copy, print, share, and presentation rights
DLP governs movement across services - preventing data from leaving defined boundaries
Dynamic watermarking tracks exposure - applied on open, view, or print

At that point, access is enforced by the file, usage restrictions travel with it, and control persists regardless of location.

The document becomes the perimeter.

Platform control: limiting provider access

One dimension often overlooked in sovereignty discussions is platform access itself. Even a perfectly configured tenant is only as sovereign as the controls placed on the operator.

Customer Lockbox ensures that even Microsoft support cannot access customer data without explicit, logged, time-bound approval. Every access request is visible, auditable, and subject to customer veto.

Data control applies not only to users - but also to the platform operating the service.

Enforcement requires an integrated architecture

Most organizations already have the required capabilities: Multi-Geo, Conditional Access, session control, Purview (labels, encryption, DLP, IRM), and monitoring. The issue is not capability. It is fragmentation.

In practice, fragmentation looks like this: residency is configured in one project, Conditional Access policies are managed by a different team, and Purview labels were applied during a compliance initiative that never connected to the access layer. The tools exist. The signals do not flow between them.

When designed as a single architecture:

Data is placed intentionally - residency aligned to regulatory requirements
Access is governed by context - device, location, and identity evaluated continuously
Usage is controlled dynamically - session-level restrictions enforced in real time
Protection is embedded in the document - encryption and IRM travel with the file
Signals are connected across the platform - monitoring feeds access policy, not just audit logs

“Data in Switzerland” becomes not just a statement - but an enforceable system property.

Closing thought

Placing data in Switzerland is the right first step. Multi-Geo makes it possible, even in global environments. But residency alone is not control.

Data residency answers where information is stored. Data sovereignty requires proving who can access it, under which conditions, and what controls remain in place after access is granted.

In Microsoft 365, sovereignty is no longer defined by geography alone. It is defined by the ability to enforce control wherever the data travels.

The Fileless Paradox: How My 33-Day-Old Research Became Today's Ransomware Reality

DenizTektek — Fri, 29 May 2026 21:03:13 GMT

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

Originally published on Microsoft Tech Community. Cross-posted on Medium.

rss.livelink.threads-in-node

Introducing a unified alert experience for Microsoft Purview Insider Risk Management

2. Expanded user profile details to better understand user risk

3. Notes across alerts and cases keep context with the work

Ready to get started? Try the unified Insider Risk Management experience today: Click here to get started

Understand your Sentinel tables at a glance: Monitor with table insights

What it is

Why these matter

Try it today

What's new on the Tables page

Who wins, and how

How I'd actually use it

Honest caveats

Resources

Ask Microsoft Anything: Microsoft Defender Attack Disruption

The state of MCP security in 2026

A specification that keeps moving

The main risks in 2026

1. Prompt injection and tool poisoning

2. Authorization and the confused deputy

3. Over-broad access and credential aggregation

4. Supply chain and rug pulls

5. Shadow MCP

6. Command injection and sandbox escape

Wrapping up

Security Community Spotlight: Sathish Veerapandian

What do you find most rewarding about being a member of the Microsoft Security Community?

Could you share something you’re proud of or a project you’ve completed?

What does your ideal community experience look like?

How long have you been working with Microsoft Security Products?

What features or products have provided the most impact?

What advice do you have for others who would like to get involved in the Microsoft Community?

Tell us more about you, including where to find you!

Learn and Engage with the Microsoft Security Community

How Karambit.AI and Microsoft Bring Software Authenticity to 14 Billion Files Per Month

The Problem: Static Analysis Without Context

Context-Aware Behavior Analysis

Case Study: Packer_Dictator, Behavioral Detection Under Adversary Adaptation

Initial Detection: Obvious Indicators

Adversary Adaptation: Surface Changes, Persistent Behavior

Entropy Analysis: Seeing Through Surface Changes

Unpacker Initialization: Common Structure Enables Generalized Detection

From Karambyte to Karambiner: Engineering for Billions

Karambyte: Building the Context

Karambiner: Externalizing Context for Scale

The Result: Software Behavior Analysis in Microsoft's Pipeline

What's Next

Securing data and access in the era of AI with Microsoft Entra and Microsoft Purview

How do I participate?

Unlock AI agents without sacrificing security

How do I participate?

Data and identity controls for the browser and network

How do I participate?

Secure the age of AI: Redefining trust, data and access

How do I participate?

Microsoft Leads a New Era of Software Supply Chain Transparency

Key Benefits of Microsoft’s Signing Transparency (MST)

Next Steps

New Exchange Online Mailbox Auditing Signal: Visibility into IPM to Non-IPM Copy Activity

Background: IPM vs. Non-IPM Subtree

The Audit Gap This Addresses

What's New

How to Query for These Records

Understanding the CopyFromIPM Audit Record

Feedback

Level up your Azure Network Security Skills with our Upcoming Webinar Series

Upcoming Events

Azure WAF Layer 7 DDoS defense in practice

Azure Firewall IDPS Detections and Sentinel Integration

What's New in Azure Bastion

What's New in Azure Firewall

What's New in Azure Web Application Firewall

June 4 - Secure Boot AMA

Securing the new risk surface: local agents, claws, and open runtimes

A new class of risk: when agents run locally

A secure agent operating environment

Observe: discover and understand local agents

Secure: contain and enforce local agent actions

Execution environment: control agent behavior by design

Runtime: enforce controls as agents act

What features or products have provided the most impact?