Microsoft Security Community Forum topics

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:

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.

Passkey Sign in Method (Entra Account) missing in Security

chandraO — Mon, 25 May 2026 13:16:47 GMT

Hi Microsoft Support

we enable FIDO2 passkey in entraId. However, when we try to register the FIDO2 passkey on myaccount.microsoft.com -> Security -> Add a Sign-in Method -> Passkey is missing. Attached screenshot.

For a personal account, the Passkey method is available at the same location, even though interface is slightly different than an Entra Id account. Attached screenshot for the personal account as well.

Kindly guide us on where to register the passkey or if we need to enable certain settings in EntraId for the passkey to show up in sign-in methods.

 We have Auth Strengths enabled in EntraId for the particular user in question and this reflects in the Device Lockscreen during login on Entra Registred Device.

Thanks

Chandra

Has anyone else been experiencing frequent Chrome freezes lately?

Nyathi — Sun, 24 May 2026 23:35:31 GMT

I've noticed that Google Chrome occasionally becomes completely unresponsive on several Windows 11 devices that are Microsoft Entra ID joined. In some cases, the browser freezes to the point where users are unable to recover without performing a hard reboot of the device. Unfortunately, the issue tends to reoccur after some time, even after restarting the machine.

Has anyone else encountered similar behaviour in a Windows 11 and Entra ID-joined environment? If so, were you able to identify the root cause or find a reliable fix?

BlackHat Community Interest Survey

Trevor_Rusher — Wed, 20 May 2026 19:58:36 GMT

Hey all! We’re planning Microsoft Security community circles, meetups, and AMA sessions during Black Hat week and would love your input on the topics and conversations most valuable to you.

Please help us by filling out this form with your opinions (NO PERSONAL DATA COLLECTED):

https://forms.cloud.microsoft/Pages/ResponsePage.aspx?id=v4j5cvGGr0GRqy180BHbR11eh_DyBlNCr6Pu5FQsI9ZUN1VQWTRDOTRZUVpQNEFLR05HMkg2RkFRTi4u

Thank you!

Critical identities in the Agent 365 era

umamasurkar28 — Fri, 15 May 2026 09:56:58 GMT

From identity governance to execution control in the age of AI agents

As organizations accelerate AI adoption, a fundamental shift is taking place in enterprise security:

Identity is no longer just about access it is becoming the control plane.

What started with user identities evolved into application and workload identities.
Now, with AI agents entering the enterprise, we are entering a new phase:

Every actor human, application or AI agent must be governed through identity.

Why identity needs to evolve

AI agents are no longer passive tools. They:

Access enterprise data
Trigger workflows
Interact across systems
Act autonomously

This introduces a new reality:

Security is no longer about who can log in
It is about what is being executed, by which identity, in which context

Introducing critical identities

To address this, identity must evolve into a unified model:

Critical identities = Human + Non-human + Agent identities

Human identities — Employees, partners
Non-human identities (NHIs) — Workloads, APIs, service principals
Agent identities — AI agents powered by Entra Agent ID

The next shift: a new identity plane

Beyond users and applications, we now have:

A third identity plane : Agent identities

This identity type:

Operates in its own execution context
Acts autonomously
Requires continuous governance

Identity is no longer static
It becomes contextual, behavioral and execution-driven

The first principle: Converged identity is non-negotiable

You cannot secure AI without converged identity

This is not a priority.
This is a prerequisite.

Organizations must move from fragmented identity silos to:

One unified identity fabric across all actors

Where:

Every identity is governed
Every permission is controlled
Every action is attributable

Converged identity becomes the foundation of the agentic enterprise

The next principle: AI SOC is no longer optional

Your SOC must operate at machine speed not human speed

This is not modernization.
This is survival in an AI-led environment.

In an AI-driven world:

Events are continuous
Signals increase exponentially
Actions are autonomous

SOC must evolve to:

AI-powered, identity-aware and automation-driven operations

Without it:

Threats outpace detection
Agents execute unnoticed
Security becomes reactive

AI SOC is not an enhancement it is the new operating model

The next principle: Data security becomes the first line of defense

Data not infrastructure is the primary risk surface

AI agents:

Aggregate enterprise data
Generate new outputs
Share insights dynamically

Organizations must shift to:

Protecting data in interaction not just at rest

Without it:

Sensitive data is exposed
Agents amplify over-permissioned access
Compliance breaks silently

AI without data security is exposure not innovation

The next principle: Agent 365 is the control plane for agents

Agents must be governed as identities, not treated as background components

Without governance:

❌ No visibility
❌ No ownership
❌ No lifecycle control

Agent 365 delivers:

Agent Registry → complete visibility
Entra Agent ID → identity foundation
Policy enforcement → Conditional Access + least privilege
Lifecycle governance → full control
Observability → execution tracking

Without this:

Agents act without accountability

& Introducing Agent Inventory

One view across identity, execution and control

As AI scales, the challenge is no longer deployment:

It is visibility into how identities behave

Why Agent Inventory matters

Traditional IAM answers:

Who has access

But now the real question is:

Which identity is executing what, in which context, under which policy?

What Agent Inventory surfaces

Blueprints → Identity design layer
Agent identities → Execution entities
Agent users → Context (on-behalf-of)
Orphan risk → Governance gaps
Credential expiry → Identity hygiene
Privilege gap analysis → Behavior vs access
Registry gaps → Missing control plane coverage
Action queue → Prioritized remediation
Relationship graph → Identity + execution mapping

What’s fundamentally new

Traditional IAM	Agentic IAM
Identity = access	Identity = execution control
Static roles	Context-aware permissions
Identity lists	Identity graphs
Periodic review	Continuous monitoring

Bringing it all together

When you step back and connect these capabilities, a clear pattern emerges. Identity becomes the foundation that governs every actor human, workload and agent while AI-powered SOC ensures detection and response can operate at the speed of execution. Data security establishes the guardrails, protecting what truly matters as agents interact with enterprise information. On top of this, Agent 365 provides the control plane bringing visibility, governance, and lifecycle management to every AI agent in the environment. And finally, Agent Inventory completes the picture by making identity and execution observable, helping organizations understand not just what exists, but how it behaves. Together, these layers form a cohesive model one that enables organizations to move from fragmented security to a unified, identity-driven approach that is ready for the realities of the agentic enterprise.

We are entering a new paradigm:

Humans define intent
Applications execute logic
Agents drive autonomous actions

And all of it is governed by identity.

So, You can’t govern agents without understanding their identity. You can’t secure identity without understanding execution.

Critical identities + Agent 365 + Agent Inventory establish the control plane for the agentic enterprise.

Microsoft Sovereignty 2026: From Data Residency to Digital Control

umamasurkar28 — Fri, 15 May 2026 07:45:38 GMT

Over the past few years, data sovereignty has evolved from a compliance checkbox to a board-level priority. What began as a discussion around where data is stored has now expanded to who controls it, who operates it and under which jurisdiction it is governed.

As we move into 2026, Microsoft Sovereignty is no longer just a roadmap, it is actively shaping how enterprises design cloud and AI architectures, especially across regulated industries.

Why Sovereignty Matters More Than Ever

Organizations today are navigating a complex landscape:

Increasing regulatory mandates (GDPR, NIS2, DORA)
Rising geopolitical concerns around cross-border data access
Accelerated adoption of AI, copilots, and agentic systems

But what’s changing in 2026 is the scale of AI adoption:

1.3B AI agents expected by 2028
82% of organizations plan to integrate AI agents within 1–3 years
90% of developers will use AI-assisted coding tools

This fundamentally shifts the sovereignty discussion:

It’s no longer about protecting data, it’s about governing AI-driven decisions and automation.

Sovereignty in the Age of AI Agents

A critical insight emerging from the field:

Not all AI workloads can run in public cloud environments.

Some AI scenarios require sovereignty by design, especially when:

Data must remain within national jurisdiction
Operational access must be restricted
Systems must continue functioning during disconnection or crisis

Examples include:

Government AI copilots for citizen services
Defense systems requiring air-gapped AI
Financial services with strict regulatory oversight
Healthcare workloads with sensitive patient data

AI strategies must now survive regulation, disruption and disconnection not just scale.

Microsoft Sovereignty: A Multi-Layered Approach

Microsoft’s approach to sovereignty is not a single feature it’s a comprehensive framework spanning infrastructure, operations, security and AI.

At its core, Microsoft Sovereign Cloud introduces three key deployment models:

1. Sovereign Public Cloud

Regional data boundaries and in-country processing
Built-in sovereign controls at hyperscale
AI model choice with localized processing

2. Sovereign Private Cloud (AI-Driven Evolution)

This is where sovereignty is evolving the fastest in 2026.

Runs on Azure Local + Microsoft 365 Local + Foundry Local
Enables continuous operations in hybrid or disconnected environments
Supports AI workloads with local inferencing and GPU acceleration

This is no longer traditional on-prem it is cloud-grade AI deployed locally.

3. National Partner Clouds

Operated by local entities
Meets country-specific certifications
Bridges global cloud and national regulations

Sovereign AI: From Data Control to Full Lifecycle Control

The biggest shift in 2026:

Sovereignty is no longer just about data it’s about the entire AI lifecycle.

Sovereign AI ensures:

Data stays local and under customer authority
AI systems operate even without connectivity
Customers control model selection (proprietary, OSS or custom)

This introduces a new dimension:

Model Sovereignty + Operational Sovereignty + Infrastructure Sovereignty

The Rise of Foundry Local: AI From Cloud to Edge

One of the most important innovations enabling this shift is Microsoft Foundry Local.

Foundry Local extends AI capabilities across:

Cloud
Edge devices
On-premises environments
Fully disconnected deployments

This allows organizations to:

Run models locally using containers
Use Arc-enabled Kubernetes for deployment
Maintain consistent governance across environments

AI Models Under Sovereign Control

Microsoft enables multiple AI model strategies:

Models-as-a-Platform (MaaP) → Customer-managed
Models-as-a-Service (MaaS) → Microsoft-managed
BYO Models → Full flexibility (Open-source or proprietary)

This means enterprises can shift from:

❌ Vendor-dependent AI
✅ Sovereign, customer-controlled AI ecosystems

Sovereign AI Deployment Patterns

Two dominant patterns are emerging:

1. Hybrid Sovereign AI

Develop in cloud
Deploy to edge or sovereign environments
Maintain flexibility

2. Fully Disconnected AI

Air-gapped environments
No dependency on cloud connectivity
Full local processing and inference

This is critical for defense, public sector and critical infrastructure.

The Reality Check: What Enterprises Must Still Own

While Microsoft provides the platform, sovereignty is not “set and forget.”

Organizations must still:

Design region-first and sovereignty-aware architectures
Implement governance across hybrid and disconnected environments
Manage model lifecycle and inferencing policies locally
Ensure compliance with evolving regulatory frameworks

Sovereignty is now an architecture decision not just a cloud feature.

My Perspective (Field Insight)

From working with regulated customers (BFSI, telecom, public sector), I see three clear patterns:

1. Sovereignty is now directly tied to AI adoption

→ Customers will not scale GenAI without sovereign guarantees

2. Hybrid + Sovereign AI is becoming the default architecture

→ Cloud-only strategies are no longer sufficient

3. Control of models and inferencing is the new trust boundary

→ Trust is shifting from infrastructure to AI execution layers

Final Thoughts: Sovereignty as an AI Enabler

The narrative around sovereignty is shifting:

❌ Earlier: “Sovereignty restricts innovation”
✅ Now: “Sovereignty enables trusted AI at scale”

Microsoft’s Sovereign Cloud strategy reflects this evolution bringing together:

Cloud-scale capabilities
Local control and resilience
AI lifecycle governance

The opportunity ahead is clear:

Design sovereign-by-default AI architectures that are secure, compliant and built for resilience whether connected, hybrid or fully disconnected.

BIT LOCKER RECOVERY

Dave1950 — Mon, 27 Apr 2026 13:31:12 GMT

Greetings everyone,

Recently Microsoft Windows forced into entering an update upon closing my laptop. After that I could not boot up without being asked to enter a Bit Locker Recovery key.I eventually found the correct key and entered it this morning successfully.Laptop was up and running ok or so I thought.Switched the laptop on just now and low and behold I have to put the Recovery key in again.!!I gather the problem arrived during the last update.I s there a fix for this or am I now having to put the key in every single time I switch the laptop on!! Is it possible to remove the faulty update?

Many thanks for any help received

Dave1950

Defender Threat & Vulnerability Management Reporting

GirthDefenceForce — Thu, 07 May 2026 18:06:02 GMT

Hello, we're looking at implementing DTVM for our endpoints, but are curious about reporting.

Is there a way we can get these reports in a PDF format, and scoped to specific devices only? I'd like to use the evidence paths gathered from KQL to help build the reports. Are there any guides or steps out there that shows how we can do this with tools like PowerBI?

Thanks in advance.

Short survey: Feedback on Sensitivity Label Suggestions in Microsoft 365 Apps

krisingh — Sat, 25 Apr 2026 13:42:21 GMT

Hi everyone,

I’m looking to gather feedback on user experiences with Sensitivity Label suggestions in Microsoft 365 apps.

This short survey aims to understand how label recommendations are working in practice and where improvements may be needed. Your responses will help identify common challenges and opportunities to make the label recommendation process more accurate, useful, and seamless for users.

Survey link: Experience with Recommended Sensitivity Labels in Microsoft 365 – Fill out form

The survey takes around 3 minutes to complete.
Your feedback will directly help us better understand real-world experiences with label suggestions.

Thank you very much for taking the time to contribute.

Security Copilot Agents in Defender XDR: where things actually stand

Marcel_Graewer — Sat, 25 Apr 2026 08:44:48 GMT

With RSAC 2026 behind us and the E5 inclusion now rolling out between April 20 and June 30, anyone planning SOC workflows or sitting on a capacity budget needs to get a clear picture of what is GA, what is preview, and what was just announced. The marketing pages tend to blur those lines.

This is my sober look at the current state, with the operational details that matter for adoption decisions.

What is actually shipping right now

The Phishing Triage Agent is GA. It only handles user-reported phish through Defender for Office 365 P2, but for most SOCs that is a meaningful chunk of the L1 queue. Verdicts come with a natural-language rationale rather than just a label, which is the part that determines whether analysts will trust it. The agent learns from analyst confirmations and overrides, so the feedback loop matters more than the initial setup.

There is a setup detail that is easy to miss: the agent will not classify alerts that have already been suppressed by alert tuning. The built-in rule "Auto-Resolve - Email reported by user as malware or phish" needs to be off, and any custom tuning rules that touch this alert type need review. If you skip this, the agent runs on an empty queue and you wonder why nothing is happening.

The Threat Intelligence Briefing Agent is also GA. It produces tenant-tailored intel briefings on a regular cadence. Useful, but lower operational impact than the triage agents.

Copilot Chat in Defender went GA with the April 2026 update. Conversational Q&A inside the portal, grounded in your incident and entity data. This is the lowest-risk way to get value out of Security Copilot and probably where most teams should start.

Public preview, worth watching

The Dynamic Threat Detection Agent is the most technically interesting one. It runs continuously in the Defender backend, correlates across Defender and Sentinel telemetry, generates its own hypotheses, and emits a dynamic alert when the evidence converges. Detection source on the alert is Security Copilot. Each alert includes the structured fields (severity, MITRE techniques, remediation) plus a narrative explaining the reasoning.

For EU tenants the residency point is worth confirming with whoever owns data protection in your org: the service runs region-local, so customer data and required telemetry stay inside the designated geographic boundary.

During public preview it is enabled by default for eligible customers and is free. At GA, currently targeted for late 2026, it transitions to the SCU consumption model and can be disabled.

The Threat Hunting Agent is also in public preview. Natural language to KQL with guided hunting. Lower stakes, but useful for teams without deep KQL expertise on hand.

Announced at RSAC, still preview

Two agents got the headlines in March:

The Security Alert Triage Agent extends the agentic triage approach beyond phishing into identity and cloud alerts. The longer-term direction is consolidating phishing, identity, and cloud triage under a single agent. Rollout is from April 2026, in preview.

The Security Analyst Agent is the multi-step investigation agent. Deeper context across Defender and Sentinel, prioritised findings, transparent reasoning trace. Preview since March 26.

Both look promising on paper, but Microsoft's history of preview features that take a long time to mature is well-documented. I would not plan production workflows around either of them yet.

What you actually get with the E5 inclusion

This is the licensing change most people are dealing with right now. Security Copilot has been part of the E5 product terms since January 1, 2026. Tenant rollout is phased between April 20 and June 30, 2026, with a 7-day notification before activation.

The numbers:

400 SCUs per month for every 1,000 paid user licenses
Capped at 10,000 SCUs per month, which you hit at around 25,000 seats
Linear scaling below that, so a 3,000-seat tenant gets 1,200 SCUs per month
No rollover, the pool resets monthly

What is included: chat, promptbooks, agentic scenarios across Defender, Entra, Intune, Purview, and the standalone portal. Agent Builder and the Graph APIs are in. If you also run Sentinel, the included SCUs apply to Security Copilot scenarios there.

What is not included: Sentinel data lake compute and storage. Those still run through Azure on the regular meters. Beyond the included pool you pay 6 USD per SCU pay-as-you-go, with 30 days notice before that mode kicks in.

Practical things worth knowing before activation

A few details that are easy to miss in the docs:

Under System > Settings > Copilot in Defender > Preferences, switch from Auto-generate to Generate on demand. Auto-generate will burn SCUs on incidents nobody is going to look at. Generate on demand gives you direct control.

In the Security Copilot portal workspace settings, check the data storage location and the data sharing toggle. Data sharing is on by default, which means Microsoft uses interaction data for product improvement. If your compliance position does not allow that, change it before agents start running. Changing it requires the Capacity Contributor role.

Agent runs are not equivalent to the same number of analyst chat prompts. A triage agent processing fifty alerts in one run consumes meaningfully more SCUs than fifty manual prompts on the same data. If you have a high-volume phishing pipeline, model that out before you flip the switch broadly. The usage dashboard in the Security Copilot portal breaks down consumption by day, user, and scenario.

Output quality depends on telemetry quality. Flaky connectors, gaps in log sources, or a high baseline of misconfigured alerts will produce verdicts that match. Connector health monitoring (the SentinelHealth table in Advanced Hunting is a sensible starting point) is a precondition.

The agents only improve if analysts feed the override loop. If your team treats the verdicts as background noise rather than confirming or correcting them, the feedback signal is lost and calibration stays where it shipped. That is a process problem, not a product problem, but it determines whether any of this is worth the SCUs.

A reasonable adoption order

A rough sequence that minimises capacity surprises:

Copilot Chat in Defender first. Lowest risk, immediate value through natural language Q&A in the investigation context.
Phishing Triage Agent on a controlled subset, with a review cadence in place. Check the built-in tuning rules first.
Watch the SCU dashboard for the first month before adding anything else.
Let the Dynamic Threat Detection Agent run while it is in public preview, since it is default-on and free anyway. Compare its alerts against existing Sentinel detections.
Security Alert Triage Agent for identity and cloud once the phishing baseline is stable.
Establish a monthly review covering agent decisions, false-positive rate, SCU cost, and MTTD/MTTR trends.

Technically, agentic triage is moving past phishing into identity and cloud, and the Dynamic Threat Detection Agent represents a genuine attempt at the false-negative problem rather than just another rule engine. Lizenziell, the E5 inclusion removes the biggest barrier to adoption that previously existed.

The risk is enabling everything at once. Agents that nobody reviews are agents that consume capacity without delivering value, and the SCU dashboard is the only thing that will tell you that is happening. One agent, one use case, a 30-day baseline, then the next one. The order matters more than the speed.

Microsoft Entra Conditional Access Optimization Agent - Move from Static to Continuous Protection

Prashbv — Tue, 07 Apr 2026 12:59:36 GMT

Conditional Access has long been Microsoft Entra’s Zero Trust policy engine—powerful, flexible, and can easily go wrong with misconfiguration over time due to large volume of policies. As the no of tenants increase the no of new users and applications the new modern authentication methods are introduced continuously, and Conditional Access policies that once provided full coverage often drift into partial or inconsistent protection.

This is an operational gap which introduces complexity and manageability challenges. The solution to this is utilizing Conditional Access Optimization Agent, an AI‑powered agent integrated with Microsoft Security Copilot that continuously evaluates Conditional Access coverage and recommends targeted improvements aligned to Microsoft Zero Trust best practices.

In this article, Let us understand what problem the agent can solve, how it works, how it can be best utilized with the real‑world Entra Conditional Access strategy.

The Problem is Conditional Access does not break loudly

Most Conditional Access issues are not caused by incorrect syntax or outright failure. Instead, they emerge gradually due to the continuous changes into the enviornment.

New users are created but not included in existing policies
New SaaS or enterprise apps bypass baseline controls
MFA policies exist, but exclusions expand silently
Legacy authentication or device code flow remains enabled for edge cases
Multiple overlapping policies grow difficult to reason about

Although there are tools like What‑If, Insights & Reporting, and Gap Analyzer workbooks help, they all require manual review and interpretation. At enterprise scale with large no of users and applications, this becomes increasingly reactive rather than preventative.

What is the Conditional Access Optimization Agent?

The Conditional Access Optimization Agent is one of the Microsoft Entra agents built to operate autonomously using Security Copilot. Its purpose is to continuously answer a critical question. Are all users, applications, and agent identities protected by the right Conditional Access policies - right now?

The agent analyzes your tenant and recommends the following.

Creating new policies
Updating existing policies
Consolidating similar policies
Reviewing unexpected policy behavior patterns

All recommendations are reviewable and optional, with actions typically staged in Report‑Only mode before enforcement.

How the agents actually works ?

The agent operates in two distinct phases - First the Analysis and then Recommendation & remediation

During the analysis phase it evaluates the following.

Enabled Conditional Access policies
User, application, and agent identity coverage
Authentication methods and device‑based controls
Recent sign‑in activity (24‑hour evaluation window)
Redundant or near‑duplicate policies

This phase identifies gaps, overlaps, and deviations from Microsoft’s learned best practices.

The next and final phase of recommendation and remediation depends on the results from the finding. Based on this the agent can suggest the following.

Enforcing MFA where coverage is missing
Adding device compliance or app protection requirements
Blocking legacy authentication and device code flow
Consolidating policies that differ only by minor conditions
Creating new policies in report‑only mode

Some of offer one click remediation making it easy for the administrators to control and enforce the decisions more appropriately.

What are its key capabilities ?

Continuous coverage validation
The agent continuously checks for new users and applications that fall outside existing Conditional Access policy scope - one of the most common real‑world gaps in Zero Trust deployments.
Policy consolidation support
Large environments often accumulate near‑duplicate policies over time. The agent analyzes similar policy pairs and proposes consolidation, reducing policy sprawl while preserving intent.
Plain‑language explanations
Each recommendation includes a clear rationale explaining why the suggestion exists and what risk it addresses, helping administrators validate changes rather than blindly accepting automation.
Policy review reports (This feature is still in preview)
The agent can generate policy review reports that highlight spikes or dips in enforcement behavior—often early indicators of misconfiguration or unintended impact

Beyond classic MFA and device controls, One of the most important use case is the agent also supports passkey adoption campaigns (This feature is still in preview) . It can include the following.

Assess user readiness
Generate phased deployment plans
Guide enforcement once prerequisites are met

This makes the agent not only a corrective tool, but it is helpful as a migration and modernization assistant for building phishing‑resistant authentication strategies.

Zero Trust strategies utilizing agents

For a mature Zero Trust strategies, the agent provides continuous assurance that Conditional Access intent does not drift as identities and applications evolve. The use of Conditional Access Optimization Agent does not replace the architectural design or automatic policy enforcement instead it can be utilized to ensure continuous evaluation, early‑alarm system for any policy drift and can act as a force‑multiplier for identity teams managing change at scale. The object of agent usage is to help close the gap upfront between policy intent depending on the actual use, instead of waiting for the analysis to complete upon resolving incidents and post auditing.

In this modernized era, the identity environments are dynamic by default. The Microsoft Entra Conditional Access Optimization Agent reflects a shift toward continuous validation and assisted governance, where policies are no longer assumed to be correct simply because they exist. For organizations already mature in Conditional Access, the agent offers operational resilience. For those still building, it provides guardrails that scale with complexity but without removing human accountability.

Sentinel to Defender Portal Migration - my 5 Gotchas to help you

Marcel_Graewer — Sat, 04 Apr 2026 07:20:46 GMT

The migration to the unified Defender portal is one of those transitions where the documentation covers "what's new" but glosses over what breaks on cutover day. Here are the gotchas that consistently catch teams off-guard, along with practical fixes.

Gotcha 1: Automatic Connector Enablement

When a Sentinel workspace connects to the Defender portal, Microsoft auto-enables certain connectors - often without clear notification. The most common surprises:

Connector	Auto-Enables?	Impact
Defender for Endpoint	Yes	EDR telemetry starts flowing, new alerts created
Defender for Cloud	Yes	Additional incidents, potential ingestion cost increase
Defender for Cloud Apps	Conditional	Depends on existing tenant config
Azure AD Identity Protection	No	Stays in Sentinel workspace only

Immediate action: Within 2 hours of connecting, navigate to Security.microsoft.com > Connectors & integrations > Data connectors and audit what auto-enabled. Compare against your pre-migration connector list and disable anything unplanned.

Why this matters: Auto-enabled connectors can duplicate data sources - ingesting the same telemetry through both Sentinel and Defender connectors inflates Log Analytics costs by 20-40%.

Gotcha 2: Incident Duplication

The most disruptive surprise. The same incident appears twice: once from a Sentinel analytics rule, once from the Defender portal's auto-created incident creation rule. SOC teams get paged twice, deduplication breaks, and MTTR metrics go sideways.

Diagnosis:

SecurityIncident | where TimeGenerated > ago(7d) | summarize IncidentCount = count() by Title | where IncidentCount > 1 | order by IncidentCount desc

If you see unexpected duplicates, the cause is almost certainly the auto-enabled Microsoft incident creation rule conflicting with your existing analytics rules.

Fix: Disable the auto-created incident creation rule in Sentinel Automation rules, and rely on your existing analytics rule > incident mapping instead. This ensures incidents are created only through Sentinel's pipeline.

Gotcha 3: Analytics Rule Title Dependencies

The Defender portal matches incidents to analytics rules by title, not by rule ID. This creates subtle problems:

Renaming a rule breaks the incident linkage
Copying a rule with a similar title causes cross-linkage
Two workspaces with identically named rules generate separate incidents for the same alert

Prevention checklist:

Audit all analytics rule titles for uniqueness before migration
Document the title-to-GUID mapping as a reference
Avoid renaming rules en masse during migration
Use a naming convention like <Severity>_<Tactic>_<Technique> to prevent collisions

Gotcha 4: RBAC Gaps

Sentinel workspace RBAC roles don't directly translate to Defender portal permissions:

Sentinel Role	Defender Portal Equivalent	Gap
Microsoft Sentinel Responder	Security Operator	Minor - name change
Microsoft Sentinel Contributor	Security Operator + Security settings (manage)	Significant - split across roles
Sentinel Automation Contributor	Automation Contributor (new)	New role required

Migration approach: Create new unified RBAC roles in the Defender portal that mirror your existing Sentinel permissions. Test with a pilot group before org-wide rollout. Keep workspace RBAC roles for 30 days as a fallback.

Gotcha 5: Automation Rules Don't Auto-Migrate

Sentinel automation rules and playbooks don't carry over to the Defender portal automatically. The syntax has changed, and not all Sentinel automation actions are available in Defender.

Recommended approach:

Export existing Sentinel automation rules (screenshot condition logic and actions)
Recreate them in the Defender portal
Run both in parallel for one week to validate behavior
Retire Sentinel automation rules only after confirming Defender equivalents work correctly

Practical Migration Timeline

Phase 1 - Pre-migration (1-2 weeks before):

Audit connectors, analytics rules, RBAC roles, and automation rules
Document everything - titles, GUIDs, permissions, automation logic
Test in a pilot environment first

Phase 2 - Cutover day:

Connect workspace to Defender portal
Within 2 hours: audit auto-enabled connectors
Within 4 hours: check for duplicate incidents
Within 24 hours: validate RBAC and automation rules

Phase 3 - Post-migration (1-2 weeks after):

Monitor incident volume for duplication spikes
Validate automation rules fire correctly
Collect SOC team feedback on workflow impact
After 1 week of stability: retire legacy automation rules

Phase 4 - Cleanup (2-4 weeks after):

Remove duplicate automation rules
Archive workspace-specific RBAC roles once unified RBAC is stable
Update SOC runbooks and documentation

The bottom line: treat this as a parallel-run migration, not a lift-and-shift. Budget 2 weeks for parallel operations. Teams that rushed this transition consistently reported longer MTTR during the first month post-migration.

Feature Request: Extend Security Copilot inclusion (M365 E5) to M365 A5 Education tenants

lehmannj — Thu, 02 Apr 2026 05:38:58 GMT

Background At Ignite 2025, Microsoft announced that Security Copilot is included for all Microsoft 365 E5 customers, with a phased rollout starting November 18, 2025. This is a significant step forward for security operations.

The gap Microsoft 365 A5 for Education is the academic equivalent of E5 — it includes the same core security stack: Microsoft Defender, Entra, Intune, and Purview. However, the Security Copilot inclusion explicitly covers only commercial E5 customers. There is no public roadmap or timeline for extending this benefit to A5 education tenants.

Why this matters Education institutions face the same cybersecurity threats as commercial organizations — often with fewer dedicated security resources. The A5 license was positioned as the premium security offering for education. Excluding it from Security Copilot inclusion creates an inequity between commercial and education customers holding functionally equivalent license tiers.

Request We would like Microsoft to:

Confirm whether Security Copilot inclusion will be extended to M365 A5 Education tenants
If yes, provide an indicative timeline
If no, clarify the rationale and what alternative paths exist for education customers

Are other EDU admins in the same situation? Would appreciate any upvotes or comments to help raise visibility with the product team.

Authentication Context (Entra ID) Use case

Prashbv — Fri, 27 Mar 2026 10:42:46 GMT

Microsoft Entra ID has evolved rapidly over the last few years, with Microsoft continuously introducing new identity, access, and security capabilities as part of the broader Zero Trust strategy. While many organizations hold the necessary Entra ID and Microsoft 365 licenses (often through E3 or E5 bundles), a number of these advanced features remain under‑utilised or entirely unused. This is frequently due to limited awareness, overlapping capabilities or uncertainty about where and how these features provide real architectural value.

One such capability which is not frequently used is Authentication Context. Although this feature is available for quite some time, it is often misunderstood or overlooked because it does not behave like traditional Conditional Access controls. Consider Authentication Context as a mobile “assurance tag” that connects a resource (or a particular access route to that resource) to one or several Conditional Access (CA) policies, allowing security measures to be enforced with resource-specific accuracy instead of broad, application-wide controls. Put simply, it permits step-up authentication only when users access sensitive information or perform critical actions, while maintaining a smooth experience for the “regular path.”

When used intentionally, it enables resource‑level and scenario‑driven access control, allowing organizations to apply stronger authentication only where it is actually needed without increasing friction across the entire user experience.

Not expensive

Most importantly to use Authentication Context the minimum licensing requirement is Microsoft Entra ID Premium P1 which most customers already have this license. so you not need to convenience for higher license to utilize this feature. But do note Entra Premium 2 is needed if your Conditional Access policy uses advanced signals, such as:

User or sign‑in risk (Identity Protection)
Privileged Identity Management (PIM) protected roles
Risk‑based Conditional Access policies

The Workflow

Architecturally, Authentication Context works when a claims request is made as part of token issuance commonly expressed via the acrs claim. When the request includes a specific context (for example c1), Entra evaluates CA policies that target that context and forces the required controls (MFA, device compliance, trusted location, etc.). The important constraint: the context must be requested/triggered by a supported workload (e.g., SharePoint) or by an application designed to request the claim; it is not an automatic “detect any action inside any app” feature.

Lets look at few high level architecture reference

1. Define “assurance tiers” as contexts

Create a small set of contexts (e.g., c1: Confidential Access, c2: Privileged Operations) and publish them for use by supported apps/services.

2. Bind contexts to resources

Assign the context to the resource boundary you want to protect—most commonly SharePoint sites (directly or via sensitivity labels), so only those sites trigger the context. (e.g - Specific SharePoint sites like financials, agreements etc )

3. Attach Conditional Access policies to the context

Create CA policies that target the context and define enforcement requirements (Additional MFA strength, mandating device compliance, or location constraint through named locations etc.). The context is the “switch” that activates those policies at the right moment.

4. Validate runtime behavior and app compatibility

Because authentication context can impact some client apps and flows, validate supported clients and known limitations (especially for SharePoint/OneDrive/Teams integrations).

Some Practical Business Scenarios

Scenario A — Confidential SharePoint Sites (M&A / Legal / HR)

Problem: You want stronger controls for a subset of SharePoint sites without forcing those controls for all SharePoint access.

Architect pattern: Tag the confidential site(s) with Authentication Context and apply a CA policy requiring stronger auth (e.g., compliant device + MFA) for that context.

Pre-reqs: SharePoint Online support for authentication context; appropriate licensing and admin permissions; CA policies targeted to the context

Scenario B — “Step-up” Inside a Custom Line-of-Business App

Problem: Users can access the app normally, but certain operations (approval, export, privileged view) need elevated assurance.

Architect pattern: Build the app on OpenID Connect/OAuth2 and explicitly request the authentication context (via acrs) when the user reaches the sensitive path; CA then enforces step-up.

Pre-reqs: App integrated with Microsoft identity platform using OIDC/OAuth2; the app can trigger claims requests/handle claim challenges where applicable; CA policies defined for the context

Scenario C — Granular “Resource-based” Zero Trust Without Blanket MFA

Problem: Security wants strong controls on crown jewels, but business wants minimal prompts for routine work.

Architect pattern: Use authentication context to enforce higher assurance only for protected resources (e.g., sensitive SharePoint sites). This provides least privilege at the resource boundary while reducing global friction.

Pre-reqs: Clearly defined resource classification; authentication context configured and published; CA policies and monitoring.

In a nutshell, Authentication Context allows organizations to move beyond broad, one‑size‑fits‑all Conditional Access policies and adopt a more precise, resource‑driven security model. By using it to link sensitive resources or protected access paths to stronger authentication requirements, organizations can improve security outcomes while minimizing unnecessary user friction. When applied deliberately and aligned to business‑critical assets, Authentication Context helps close the gap between licensing capability and real‑world value—turning underused Entra ID features into practical, scalable Zero Trust controls.

If you find this useful, please do not forget to like and add your thoughts 🙂

Rescheduled Webinar: Copilot Skilling Series

emilyfalla — Wed, 25 Mar 2026 22:30:27 GMT

Rescheduled Webinar

Copilot Skilling Series | Security Copilot Agents, DSPM AI Observability, and IRM for Agents

Hello everyone! The Copilot Skilling Series webinar on Security Copilot Agents, DSPM AI Observability, and IRM for Agents originally scheduled for April 16th, has been rescheduled for April 28th at 8:00 AM Pacific Time.

We are sorry for the inconvenience and hope to see you there on the 28th. Please register for the updated time at http://aka.ms/securitycommunity

All the best!

The Security Community Team

Kerberos and the End of RC4: Protocol Hardening and Preparing for CVE‑2026‑20833

JoaoFranca — Tue, 17 Mar 2026 12:41:48 GMT

CVE-2026-20833 addresses the continued use of the RC4‑HMAC algorithm within the Kerberos protocol in Active Directory environments. Although RC4 has been retained for many years for compatibility with legacy systems, it is now considered cryptographically weak and unsuitable for modern authentication scenarios.

As part of the security evolution of Kerberos, Microsoft has initiated a process of progressive protocol hardening, whose objective is to eliminate RC4 as an implicit fallback, establishing AES128 and AES256 as the default and recommended algorithms.

This change should not be treated as optional or merely preventive. It represents a structural change in Kerberos behavior that will be progressively enforced through Windows security updates, culminating in a model where RC4 will no longer be implicitly accepted by the KDC.

If Active Directory environments maintain service accounts, applications, or systems dependent on RC4, authentication failures may occur after the application of the updates planned for 2026, especially during the enforcement phases introduced starting in April and finalized in July 2026.

For this reason, it is essential that organizations proactively identify and eliminate RC4 dependencies, ensuring that accounts, services, and applications are properly configured to use AES128 or AES256 before the definitive changes to Kerberos protocol behavior take effect.

Official Microsoft References

CVE-2026-25177 - Security Update Guide - Microsoft - Active Directory Domain Services Elevation of Privilege Vulnerability
Microsoft Support – How to manage Kerberos KDC usage of RC4 for service account ticket issuance changes related to CVE-2026-20833 (KB 5073381)
Microsoft Learn – Detect and Remediate RC4 Usage in Kerberos
AskDS – What is going on with RC4 in Kerberos?
Beyond RC4 for Windows authentication | Microsoft Windows Server Blog
So, you think you’re ready for enforcing AES for Kerberos? | Microsoft Community Hub

Risk Associated with the Vulnerability

When RC4 is used in Kerberos tickets, an authenticated attacker can request Service Tickets (TGS) for valid SPNs, capture these tickets, and perform offline brute-force attacks, particularly Kerberoasting scenarios, with the goal of recovering service account passwords. Compared to AES, RC4 allows significantly faster cracking, especially for older accounts or accounts with weak passwords.

Technical Overview of the Exploitation

In simplified terms, the exploitation flow occurs as follows:

The attacker requests a TGS for a valid SPN.
The KDC issues the ticket using RC4, when that algorithm is still accepted.
The ticket is captured and analyzed offline.
The service account password is recovered.
The compromised account is used for lateral movement or privilege escalation.

Official Timeline Defined by Microsoft

Important clarification on enforcement behavior
Explicit account encryption type configurations continue to be honored even during enforcement mode. The Kerberos hardening associated with CVE‑2026‑20833 focuses on changing the default behavior of the KDC, enforcing AES-only encryption for TGS ticket issuance when no explicit configuration exists.
This approach follows the same enforcement model previously applied to Kerberos session keys in earlier security updates (for example, KB5021131 related to CVE‑2022‑37966), representing another step in the progressive removal of RC4 as an implicit fallback.

January 2026 – Audit Phase

Starting in January 2026, Microsoft initiated the Audit Phase related to changes in RC4 usage within Kerberos, as described in the official guidance associated with CVE-2026-20833. The primary objective of this phase is to allow organizations to identify existing RC4 dependencies before enforcement changes are applied in later phases.

During this phase, no functional breakage is expected, as RC4 is still permitted by the KDC. However, additional auditing mechanisms were introduced, providing greater visibility into how Kerberos tickets are issued in the environment.

Analysis is primarily based on the following events recorded in the Security Log of Domain Controllers:

Event ID 4768 – Kerberos Authentication Service (AS request / Ticket Granting Ticket)
Event ID 4769 – Kerberos Service Ticket Operations (Ticket Granting Service – TGS)
Additional events related to the KDCSVC service

These events allow identification of:

the account that requested authentication
the requested service or SPN
the source host of the request
the encryption algorithm used for the ticket and session key

This information is critical for detecting scenarios where RC4 is still being implicitly used, enabling operations teams to plan remediation ahead of the enforcement phase.

If these events are not being logged on Domain Controllers, it is necessary to verify whether Kerberos auditing is properly enabled. For Kerberos authentication events to be recorded in the Security Log, the corresponding audit policies must be configured.

The minimum recommended configuration is to enable Success auditing for the following subcategories:

Kerberos Authentication Service
Kerberos Service Ticket Operations

Verification can be performed directly on a Domain Controller using the following commands:

auditpol /get /subcategory:"Kerberos Service Ticket Operations"
auditpol /get /subcategory:"Kerberos Authentication Service"

In enterprise environments, the recommended approach is to apply this configuration via Group Policy, ensuring consistency across all Domain Controllers.

The corresponding policy can be found at:

Computer Configuration

- Policies

- Windows Settings

- Security Settings

- Advanced Audit Policy Configuration

- Audit Policies

- Account Logon

Once enabled, these audits record events 4768 and 4769 in the Domain Controllers’ Security Log, allowing analysis tools—such as inventory scripts or SIEM/Log Analytics queries—to accurately identify where RC4 is still present in the Kerberos authentication flow.

April 2026 – Enforcement with Manual Rollback

With the April 2026 update, the KDC begins operating in AES-only mode (0x18) when the msDS-SupportedEncryptionTypes attribute is not defined. This means RC4 is no longer accepted as an implicit fallback. During this phase, applications, accounts, or computers that still implicitly depend on RC4 may start failing. Manual rollback remains possible via explicit configuration of the attribute in Active Directory.

July 2026 – Final Enforcement

Starting in July 2026, audit mode and rollback options are removed. RC4 will only function if explicitly configured—a practice that is strongly discouraged. This represents the point of no return in the hardening process.

Official Monitoring Approach

Microsoft provides official scripts in the repository:

https://github.com/microsoft/Kerberos-Crypto/tree/main/scripts

The two primary scripts used in this analysis are:

Get-KerbEncryptionUsage.ps1

The Get-KerbEncryptionUsage.ps1 script, provided by Microsoft in the Kerberos‑Crypto repository, is designed to identify how Kerberos tickets are issued in the environment by analyzing authentication events recorded on Domain Controllers.

Data collection is primarily based on:

Event ID 4768 – Kerberos Authentication Service (AS‑REQ / TGT issuance)
Event ID 4769 – Kerberos Service Ticket Operations (TGS issuance)

From these events, the script extracts and consolidates several relevant fields for authentication flow analysis:

Time – when the authentication occurred
Requestor – IP address or host that initiated the request
Source – account that requested the ticket
Target – requested service or SPN
Type – operation type (AS or TGS)
Ticket – algorithm used to encrypt the ticket
SessionKey – algorithm used to protect the session key

Based on these fields, it becomes possible to objectively identify which algorithms are being used in the environment, both for ticket issuance and session establishment.

This visibility is essential for detecting RC4 dependencies in the Kerberos authentication flow, enabling precise identification of which clients, services, or accounts still rely on this legacy algorithm.

Example usage:

.\Get-KerbEncryptionUsage.ps1 -Encryption RC4 -Searchscope AllKdcs | Export-Csv -Path .\KerbUsage_RC4_All_ThisDC.csv -NoTypeInformation -Encoding UTF8

Data Consolidation and Analysis

In enterprise environments, where event volumes may be high, it is recommended to consolidate script results into analytical tools such as Power BI to facilitate visualization and investigation.

The presented image illustrates an example dashboard built from collected results, enabling visibility into:

Total events analyzed
Number of Domain Controllers involved
Number of requesting clients (Requestors)
Most frequently involved services or SPNs (Targets)
Temporal distribution of events
RC4 usage scenarios (Ticket, SessionKey, or both)

This type of visualization enables rapid identification of RC4 usage patterns, remediation prioritization, and progress tracking as dependencies are eliminated.

Additionally, dashboards help answer key operational questions, such as:

Which services still depend on RC4
Which clients are negotiating RC4 for sessions
Which Domain Controllers are issuing these tickets
Whether RC4 usage is decreasing over time

This combined automated collection + analytical visualization approach is the recommended strategy to prepare environments for the Microsoft changes related to CVE‑2026‑20833 and the progressive removal of RC4 in Kerberos.

Visualizing Results with Power BI

To facilitate analysis and monitoring of RC4 usage in Kerberos, it is recommended to consolidate script results into a Power BI analytical dashboard.

1. Install Power BI Desktop

Download and install Power BI Desktop from the official Microsoft website

2. Execute data collection

After running the Get-KerbEncryptionUsage.ps1 script, save the generated CSV file to the following directory:

C:\Temp\Kerberos_KDC_usage_of_RC4_Logs\KerbEncryptionUsage_RC4.csv

3. Open the dashboard in Power BI

Open the file RC4-KerbEncryptionUsage-Dashboards.pbix using Power BI Desktop.

If you are interested, please leave a comment on this post with your email address, and I will be happy to share with you.

4. Update the data source

If the CSV file is located in a different directory, it will be necessary to adjust the data source path in Power BI.

As illustrated, the dashboard uses a parameter named CsvFilePath, which defines the path to the collected CSV file.

To adjust it:

Open Transform Data in Power BI.
Locate the CsvFilePath parameter in the list of Queries.
Update the value to the directory where the CSV file was saved.
Click Refresh Preview or Refresh to update the data.
Click Home → Close & Apply.

This approach allows rapid identification of RC4 dependencies, prioritization of remediation actions, and tracking of progress throughout the elimination process.

List-AccountKeys.ps1

This script is used to identify which long-term keys are present on user, computer, and service accounts, enabling verification of whether RC4 is still required or whether AES128/AES256 keys are already available.

Interpreting Observed Scenarios

Microsoft recommends analyzing RC4 usage by jointly considering two key fields present in Kerberos events:

Ticket Encryption Type
Session Encryption Type

Each combination represents a distinct Kerberos behavior, indicating the source of the issue, risk level, and remediation point in the environment.

In addition to events 4768 and 4769, updates released starting January 13, 2026, introduce new Kdcsvc events in the System Event Log that assist in identifying RC4 dependencies ahead of enforcement.

These events include:

Event ID 201 – RC4 usage detected because the client advertises only RC4 and the service does not have msDS-SupportedEncryptionTypes defined.
Event ID 202 – RC4 usage detected because the service account does not have AES keys and the msDS-SupportedEncryptionTypes attribute is not defined.
Event ID 203 – RC4 usage blocked (enforcement phase) because the client advertises only RC4 and the service does not have msDS-SupportedEncryptionTypes defined.
Event ID 204 – RC4 usage blocked (enforcement phase) because the service account does not have AES keys and msDS-SupportedEncryptionTypes is not defined.
Event ID 205 – Detection of explicit enablement of insecure algorithms (such as RC4) in the domain policy DefaultDomainSupportedEncTypes.
Event ID 206 – RC4 usage detected because the service accepts only AES, but the client does not advertise AES support.
Event ID 207 – RC4 usage detected because the service is configured for AES, but the service account does not have AES keys.
Event ID 208 – RC4 usage blocked (enforcement phase) because the service accepts only AES and the client does not advertise AES support.
Event ID 209 – RC4 usage blocked (enforcement phase) because the service accepts only AES, but the service account does not have AES keys.

https://support.microsoft.com/en-gb/topic/how-to-manage-kerberos-kdc-usage-of-rc4-for-service-account-ticket-issuance-changes-related-to-cve-2026-20833-1ebcda33-720a-4da8-93c1-b0496e1910dc

They indicate situations where RC4 usage will be blocked in future phases, allowing early detection of configuration issues in clients, services, or accounts.

These events are logged under:

Log: System
Source: Kdcsvc

Below are the primary scenarios observed during the analysis of Kerberos authentication behavior, highlighting how RC4 usage manifests across different ticket and session encryption combinations. Each scenario represents a distinct risk profile and indicates specific remediation actions required to ensure compliance with the upcoming enforcement phases.

Scenario A – RC4 / RC4
In this scenario, both the Kerberos ticket and the session key are issued using RC4. This is the worst possible scenario from a security and compatibility perspective, as it indicates full and explicit dependence on RC4 in the authentication flow.
This condition significantly increases exposure to Kerberoasting attacks, since RC4‑encrypted tickets can be subjected to offline brute-force attacks to recover service account passwords. In addition, environments remaining in this state have a high probability of authentication failure after the April 2026 updates, when RC4 will no longer be accepted as an implicit fallback by the KDC.
Events Associated with This Scenario
During the Audit Phase, this scenario is typically associated with:
Event ID 201 – Kdcsvc
Indicates that:
the client advertises only RC4
the service does not have msDS-SupportedEncryptionTypes defined
the Domain Controller does not have DefaultDomainSupportedEncTypes defined
This means RC4 is being used implicitly.
This event indicates that the authentication will fail during the enforcement phase.
Event ID 202 – Kdcsvc
Indicates that:
the service account does not have AES keys
the service does not have msDS-SupportedEncryptionTypes defined
This typically occurs when:
legacy accounts have never had their passwords reset
only RC4 keys exist in Active Directory
Possible Causes
Common causes include:
the originating client (Requestor) advertises only RC4
the target service (Target) is not explicitly configured to support AES
the account has only legacy RC4 keys
the msDS-SupportedEncryptionTypes attribute is not defined
Recommended Actions
To remediate this scenario:
Correctly identify the object involved in the authentication flow, typically:
a service account (SPN)
a computer account
or a Domain Controller computer object
Verify whether the object has AES keys available using analysis tools or scripts such as List-AccountKeys.ps1.
If AES keys are not present, reset the account password, forcing generation of modern cryptographic keys (AES128 and AES256).
Explicitly define the msDS-SupportedEncryptionTypes attribute to enable AES support.
Recommended value for modern environments:
0x18 (AES128 + AES256) = 24
As illustrated below, this configuration can be applied directly to the msDS-SupportedEncryptionTypes attribute in Active Directory.
AES can also be enabled via Active Directory Users and Computers by explicitly selecting:
This account supports Kerberos AES 128 bit encryption
This account supports Kerberos AES 256 bit encryption
These options ensure that new Kerberos tickets are issued using AES algorithms instead of RC4.
Temporary RC4 Usage (Controlled Rollback)
In transitional scenarios—during migration or troubleshooting—it may be acceptable to temporarily use:
0x1C (RC4 + AES) = 28
This configuration allows the object to accept both RC4 and AES simultaneously, functioning as a controlled rollback while legacy dependencies are identified and corrected.
However, the final objective must be to fully eliminate RC4 before the final enforcement phase in July 2026, ensuring the environment operates exclusively with AES128 and AES256.

Scenario B – AES / RC4
In this case, the ticket is protected with AES, but the session is still negotiated using RC4. This typically indicates a client limitation, legacy configuration, or restricted advertisement of supported algorithms.
Events Associated with This Scenario
During the Audit Phase, this scenario may generate:
Event ID 206
Indicates that:
the service accepts only AES
the client does not advertise AES in the Advertised Etypes
In this case, the client is the issue.
Recommended Action
Investigate the Requestor
Validate operating system, client type, and advertised algorithms
Review legacy GPOs, hardening configurations, or settings that still force RC4
For Linux clients or third‑party applications, review krb5.conf, keytabs, and Kerberos libraries

Scenario C – RC4 / AES
Here, the session already uses AES, but the ticket is still issued using RC4. This indicates an implicit RC4 dependency on the Target or KDC side, and the environment may fail once enforcement begins.
Events Associated with This Scenario
This scenario may generate:
Event ID 205
Indicates that the domain has explicit insecure algorithm configuration in:
DefaultDomainSupportedEncTypes
This means RC4 is explicitly allowed at the domain level.
Recommended Action
Correct the Target object
Explicitly define msDS-SupportedEncryptionTypes with 0x18 = 24
Revalidate new ticket issuance to confirm full migration to AES / AES

Conclusion

CVE‑2026‑20833 represents a structural change in Kerberos behavior within Active Directory environments. Proper monitoring is essential before April 2026, and the msDS-SupportedEncryptionTypes attribute becomes the primary control point for service accounts, computer accounts, and Domain Controllers. July 2026 represents the final enforcement point, after which there will be no implicit rollback to RC4.

Device Inventory and discovery - private vs corporate network

HathMH — Thu, 12 Mar 2026 20:26:06 GMT

Trying to sanity‑check something in Defender, and hoping this is the right place given how many Defender products exist now.

Goal: get an accurate device inventory of everything connected to the network. I’ve gone through the configuration so it should only be showing devices on our corporate network. We’re a mixed environment with on‑prem users, remote/VPN users, and external endpoints.

What I’m unsure about: Devices showing 10.x.x.x make sense — that’s our internal corporate network. But I’m also seeing devices with 192.168.x.x addresses.

In a Defender device inventory, what would typically cause 192.168.x.x devices to appear? Are these likely remote/VPN clients, home routers, or something misconfigured?

Posting screen snip of some findings.

Unsanctioned cloud apps generates constant alerts

lfk73 — Wed, 11 Mar 2026 00:44:42 GMT

When I mark a cloud app as unsanctioned it created a URL based indicator to block the site. However, it also by default enables the Generate Alert option on the indictor. This causes my SOC to bet inundated with garbage alerts. Now normally if I'm just unsanctioning one Cloud App a could go and turn of the alert.

However, I use cloud app policy that will identify any new Cloud Apps in an entire category and then unsanction it. But it enables Generate Alert on the URL indicator.

Then if someone accesses that new one the generate alert kicks off.

I don't want to have to go into every new app and untick generate alert manually that's just too time consuming.

Is there a way to change the default behaviour when adding an indicator to not enable the generate alert? Of is there some other way to do this?

I could consider using power automate or something but I'd rather the default behaviour be the fix as automation can break. I don't have time to babysit it.