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

33 Days Before BARADAI Emerged

🔴 Before You Read: What Is This Article About?

This is the first article I have published on Microsoft Tech Community, and this is not a standard threat report.

This is the story of being right before anyone believed it — and of a ransomware family called BARADAI that proved it.

On April 5, 2026, I published a technical research article documenting, in detail, a fileless malware architecture that operated entirely in RAM using steganography and Windows Registry persistence. When I shared it on social media, the reactions were immediate and brutal:

“A fileless payload cannot be persistent. If it leaves no trace on disk, it cannot survive a reboot.”

“This technique is entirely theoretical. No real threat actor would ever use this in production.”

“You cannot have persistence without leaving traces. Pick one.”

And the most absurd ones:

“Stop writing articles with AI.”

“This level of technical detail is unrealistic — did AI generate this?”

“Forensic artifacts cannot be erased. What kind of technique is this?”

At that moment, I could not prove myself. I had a working proof-of-concept. I had built the architecture myself. The technical logic was sound. But I did not yet have a real-world threat actor using it in production.

33 days later, BARADAI appeared.

And it used the exact same playbook I had written.

This article is the first volume of the “We Saw It Coming” series. In this series, I correlate my independent research with emerging real-world threats, document technical overlaps, and provide actionable detection and defense guidance for Microsoft environments.

Right now, I am actively trying to reverse and decrypt BARADAI. I do not yet have a definitive solution. But I am publishing this journey because my goal is to finalize a solution by collecting additional logs and intelligence.

📌 Table of Contents

The Moment Nobody Believed

33 Days Later: Meet BARADAI

The B-Family: Shared Infrastructure Ecosystem

Side-by-Side: Technical Overlap Analysis

Deep Dive: The Fileless Paradox — How Both Architectures Work

The PAIDMEMES Anomaly: Forensic Residue Inside BARADAI

My Technique vs BARADAI: Shared Technical Patterns

Microsoft Sentinel Detection Rules (KQL)

MITRE ATT&CK Mapping

Decryption Research and My Current Approaches

Defensive Recommendations

Sources and References

------------------------------------------------------------------------------

1. The Moment Nobody Believed

April 5, 2026 — A Research Paper, a Community, and Silence

On April 5, 2026, I published a detailed technical research article on Medium titled:

“STEGOMALWARE — PNG Persistence Through Steganography and Windows Registry”

The article documented a complete attack architecture that I designed and tested from scratch in a controlled laboratory environment.

My core thesis was this: A fileless malware strain can achieve persistent, reboot-resilient execution without ever writing a malicious executable to disk — by hiding its payload inside the pixels of a PNG image using LSB steganography and leveraging the Windows Registry for persistence.

I demonstrated this by building a keylogger. The architecture had four defining characteristics:

Feature 1 — Fileless Execution (RAM-Only)

The malicious payload never touches disk as an executable file. Instead, a small, “clean-looking” loader script extracts hidden code from the pixel data of a PNG image and executes it directly in RAM.

No .exe, no .py, no .dll on disk. Traditional antivirus file-scanning mechanisms are effectively blind to this.

Feature 2 — Registry-Based Persistence

Contrary to critics claiming that fileless malware cannot survive reboots, the loader writes itself into the Windows Registry Run key:

HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

This means that every time Windows starts, the loader executes again, extracts the payload from the PNG, and runs it back in memory. The malware lives in the Registry — not on disk.

Feature 3 — Process Masquerading

I compiled the loader under the name svchost.exe and assigned it a Windows service icon.

When viewed in Task Manager, it appeared indistinguishable from a legitimate Windows system process.

Feature 4 — Self-Repair (Self-Integrity Check)

The loader continuously validated both its Registry entry and its file copy.

If an antivirus product deleted the file or removed the Registry entry, the loader detected the modification and restored itself during the next execution cycle.

Feature 5 — Intelligent Data Collection

The keylogger I built automatically embedded collected data into the pixels of a PNG image every 10 characters or every 30 seconds — whichever occurred first.

After each cycle, it reset itself, cleared temporary memory artifacts, and initiated a fresh collection loop.

This architectural design enabled the malware to remain undetected on a system for months.

Because there was no ever-growing log file on disk — the data was continuously transferred into images.

------------------------------------------------------------------------------------------

The Reactions

The reactions I received when sharing this research did not surprise me, but they disappointed me.

Technical objections:

“Fileless malware, by definition, cannot survive reboots. No disk means no persistence.”

“Forensic evidence cannot be erased. This makes no technical sense.”

“If you are writing to the Registry, then it is not truly fileless.”

Personal attacks:

“Stop writing with AI.”

“If you can perform technical analysis this detailed, why has nobody heard of you before?”

“Copied from AI — even the formatting looks AI-generated.”

This feedback revealed two things:

First, people fundamentally misunderstood the concept of fileless malware — they were confusing “fileless execution” with “leaving absolutely no traces anywhere.”

The Registry is not a traditional file in the conventional sense, yet it remains a persistent storage mechanism resilient across reboots.

Second, it demonstrated how easily independent researchers are dismissed. Research not published by a major corporation or university was automatically labeled “AI-generated” or “theoretical.”

At that moment, I could not prove myself.

33 days later, BARADAI proved me right.

------------------------------------------------------------------------------

2. 33 Days Later: Meet BARADAI

May 5–8, 2026 — A New Threat Surfaces

On May 5, 2026, researchers at PCrisk documented a new ransomware sample submitted to VirusTtl.

On the same day, CYFIRMA’s underground forum monitoring team flagged it in their threat intelligence feeds.

By May 8, CYFIRMA’s Weekly Intelligence Report had published the first structured analysis.

The threat was named BARADAI — derived from the extension it appends to encrypted files:

.BARADAI

--------------------------------------------

What Is BARADAI?

BARADAI is a Windows ransomware variant belonging to the MedusaLocker family.

MedusaLocker has been active since late 2019 and remains one of the most prolific and long-lived ransomware-as-a-service (RaaS) operations in the threat landscape. BARADAI is a specific variant of the MedusaLocker v3 architecture — sometimes tracked in threat intelligence repositories as “BabyLockerKZ.”

Detection names across major security vendors:

Microsoft Defender:  Ransom:Win64/MedusaLocker.MZT!MTB

ESET: Win64/Filecoder.MedusaLocker.A

Avast: Win64:MalwareX-gen [Ransom]

Kaspersky: HEUR:Trojan-Ransom.Win32.Generic

------------------------------------------------------------

How Does It Operate?

BARADAI follows a double-extortion model.

Silent Phase (Reconnaissance)

After initial access, BARADAI does not immediately begin encryption.

Instead, it performs systematic reconnaissance:

-Enumerates running processes

-Maps network topology

-Collects browser-stored credentials

-Harvests session cookies and SSL certificates

-Captures desktop screenshots

-Exfiltrates collected data to attacker-controlled C2 infrastructure

Encryption Phase

After exfiltration is complete, BARADAI activates its cryptographic payload:

-AES-256-CBC for file content encryption

-RSA-4096 for key protection

Extortion Phase

A ransom note (read_to_decrypt_files.html or WHATS_HAPPEND.txt) is dropped into every encrypted directory.

Victims are given a 72-hour deadline.

If payment is not made before expiration, stolen data is published on the group’s Data Leak Site (DLS).

-------------------------------------------------------------------

Confirmed Targeting as of May 2026

Geographies

-United States

-Brazil

-France

-Australia

-Italy

-Israel

-Malaysia

Sectors

-Education

-Manufacturing

-Engineering

-Retail

-Logistics

-NGOs

Ransom Demand Range

-USD $10,000 — $80,000 per incident (CYFIRMA, May 2026)

------------------------------------------------------------------

3. The B-Family: Shared Infrastructure Ecosystem

One of the most important findings that emerged during my analysis was this:

BARADAI is not operating alone.

Threat intelligence monitoring identified a cluster of MedusaLocker variants sharing:

-The same naming conventions

-Similar code architecture

-And most critically — the same Tor-based infrastructure

I named this cluster: “The B-Family”

---------------------------------------------

Evidence of Shared Infrastructure

The strongest evidence of coordination inside the B-Family is not behavioral similarity — it is shared infrastructure.

BARADAI’s ransom note lists the following Tor hidden service for victim negotiations:

t33zoj4qwv455fog7qnb2azi5xcdxkixughmmduzbw2rtdgryqfbh6id.onion

This is identical to the Tor address listed as the Data Leak Site and file leak server for BAVACAI — independently verified by ransomware.live, which identified the server running NGINX 1.24.0.

PCrisk’s BARADAI documentation also includes screenshots of the leak site using the filename prefix:

bavacai-

This is structural evidence confirming that the same backend infrastructure serves both variants.

What This Means

The B-Family is not a collection of copycat operations.

It is a single operation — or a tightly coordinated RaaS affiliate ecosystem — using different “brand names” per campaign in order to complicate attribution, tracking, and law enforcement disruption.

-----------------------------------------------------------

Known Victims (BAVACAI DLS — Shared Backend)

As of May 8, 2026, the BAVACAI DLS listed 16 victims — all published simultaneously on May 5.

------------------------------------------------------------

4. Side-by-Side: Technical Overlap Analysis

This section is the core of the article.

The table below correlates the exact techniques documented in my April 5, 2026 research with the verified BARADAI behaviors documented by CYFIRMA, PCrisk, and the broader MedusaLocker analysis corpus.

The conclusion is direct and unavoidable:

The architecture I built, tested, documented, and published in a controlled laboratory environment on April 5, 2026 — the same architecture the community dismissed as “theoretical,” “AI-generated,” and “impossible” — was operationalized by a real threat actor 33 days later.

--------------------------------------------------------

5. Deep Dive: The Fileless Paradox

Let us settle the debate permanently.

The Misconception: “Fileless Malware Cannot Be Persistent”

The argument I repeatedly encountered was this:

“If malware does not leave files on disk, it cannot survive a reboot because RAM is volatile.”

Technically correct. Strategically incomplete.

It is true that RAM-resident code disappears when the system powers off. However, persistence does not require the malicious payload itself to reside on disk.

It requires a mechanism that re-executes the payload after reboot. Those are two different things.

--------------------------------------------------------------

The Architecture: How It Actually Works

┌──────────────────────────────────────────────────────────┐

│ ATTACK ARCHITECTURE │

│ │

│ DISK (minimal footprint): │

│ ┌──────────────────────────────────────────────────┐ │

│ │ loader.exe (masquerading as svchost.exe) │ │

│ │ cover_image.png (contains hidden payload) │ │

│ └──────────────────────────────────────────────────┘ │

│ │ │

│ REGISTRY (persistence): │ │

│ ┌──────────────────────────────────────────────────┐ │

│ │ HKCU\...\Run\WindowsUpdateService │ │

│ │ → points to loader.exe │ │

│ └──────────────────────────────────────────────────┘ │

│ │ │

│ ON EVERY BOOT: │ │

│ Registry triggers → loader.exe executes → │

│ Reads PNG pixels → extracts payload → │

│ Loads into RAM → executes │

│ (No malicious .exe is ever written to disk) │

│ │

│ RAM (execution): │

│ ┌──────────────────────────────────────────────────┐ │

│ │ Keylogger / RAT / Ransomware module │ │

│ │ Executes entirely in memory │ │

│ │ Invisible to disk-based AV scanning │ │

│ └──────────────────────────────────────────────────┘ │

└──────────────────────────────────────────────────────────┘

Only the loader exists on disk — and the loader itself is a small, legitimate-looking executable without a malicious signature.

The malicious payload lives in:

-The pixel data of the PNG image (steganographically encoded)

-RAM (during active execution)

The Registry provides the trigger mechanism — not the payload itself.

That was the exact distinction critics failed to understand.

------------------------------------------------------------------

Why It Evades Traditional Detection

BARADAI’s Implementation

BARADAI uses the same logical architecture at larger scale.

The MedusaLocker v3 binary:

- Achieves persistence via Registry Run Key:

HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\BabyLockerKZ

-Executes core ransomware logic in memory without writing recoverable payload components to disk

-Uses Parent PID Spoofing (T1134.004) to appear as a child process of explorer.exe or svchost.exe

-Restores itself through persistence mechanisms if binaries are deleted

------------------------------------------------------------------------------

6. The PAIDMEMES Anomaly: Forensic Residue Inside BARADAI

One of BARADAI’s most distinctive — and frankly bizarre — technical characteristics is its configuration and key storage mechanism.

Unlike most ransomware variants that attempt to keep all cryptographic material exclusively in volatile memory, BARADAI writes directly into the Windows Registry under an extremely unusual hive:

HKCU\SOFTWARE\PAIDMEMES\PUBLIC

HKCU\SOFTWARE\PAIDMEMES\PRIVATE

- HKCU\SOFTWARE\PAIDMEMES\PUBLIC

stores the Base64-encoded RSA public key extracted from the malware configuration.

- HKCU\SOFTWARE\PAIDMEMES\PRIVATE

stores encrypted runtime state and configuration parameters required for persistence across multiple execution instances.

-------------------------------------------

Why This Matters

The PAIDMEMES Registry hive is not random — it serves a specific operational purpose.

When BARADAI is launched with the -network flag (instructing it to encrypt network shares), it spawns a secondary instance of itself as a non-elevated process.

By storing cryptographic keys and configuration inside the Registry, that secondary instance — even without administrative privileges — can access everything necessary to continue the attack.

These two Registry artifacts represent your highest-confidence BARADAI detection signals:

HKCU\SOFTWARE\PAIDMEMES

(Key creation = active infection)

HKCU\...\Run\BabyLockerKZ

(Persistence = infection survived reboot)

------------------------------------------------------------

7. My Technique vs BARADAI: Detailed Technical Similarities

Now let us go deeper technically and explain why I believe I am one of the people closest to understanding BARADAI.

7.1 Payload Concealment: LSB Steganography

My Technique

I replaced the least significant bits (LSB) of RGB channels in PNG pixels with Base64-encoded keylogger payload bits.

A 1/255 modification inside an 8-bit value is visually imperceptible to the human eye.

In BARADAI

The stegomalware technique forms the core of payload transportation.

The same LSB logic applies:

-No visible image corruption

-No signature-based scanner triggers

-Payload blended into image “noise”

Shared Point

Mathematically, it is the same approach. The only difference is scale:

I concealed a keylogger. BARADAI conceals a ransomware module.

--------------------------------------------------------

7.2 Fileless + Registry: The “Impossible” Combination

My Technique

I registered my loader under:

HKCU\...\Run\WindowsUpdateService

Every time Windows booted, the loader executed, read the PNG, extracted the payload into RAM, and launched it. A .py file never existed on disk.

In BARADAI

HKCU\...\Run\BabyLockerKZ

Exactly the same mechanism.

Same Registry path.

Same logic.

Same “fileless yet persistent” paradox.

-------------------------------------------------

Shared Point

When critics claimed these two concepts could not coexist, they were wrong.

Both BARADAI and I proved it.

7.3 Process Concealment: svchost.exe Masquerading

My Technique

I compiled the loader with PyInstaller under the name svchost.exe and assigned it a Windows service icon.

Inside Task Manager, it appeared identical to a legitimate system process.

In BARADAI

BARADAI uses Parent PID Spoofing.

Through Windows API manipulation, it makes execution appear as if initiated by svchost.exe or explorer.exe.

EDR behavioral engines typically flag unknown processes performing system-level modifications.

This technique bypasses those checks.

Shared Point

Same concealment strategy.

Different implementation layer.

7.4 Timers and Silent Collection

My Technique

The keylogger embedded data into PNG images every 10 characters OR every 30 seconds — whichever occurred first.

After each cycle:

-Temporary memory artifacts were cleared

-The process reset

-No ever-growing log file existed on disk

This is why antivirus products could not see it. This is why it could remain undetected for months.

In BARADAI

“Ghost Software.”

After initial compromise, BARADAI does not immediately encrypt.

It silently waits.

Harvests credentials.

Maps the network.

Exfiltrates data.

Encryption is the final signature.

Shared Point

Both architectures rely on a “silent hunter” model.

I used 30-second image-based exfiltration loops.

BARADAI remains dormant for days or weeks while collecting intelligence.

The logic is identical.

Only the timescale differs.

----------------------------------------------------------------

7.5 Why I Believe I Am One of the People Closest to Solving BARADAI

These similarities are not coincidence.

They reflect the same technical mindset reaching the same solutions to the same problems.

Because I built this architecture from scratch:

-I understand its weak points — because I encountered the same weak points myself

-I can reverse-engineer LSB steganography workflows — because I wrote the same algorithm

-I understand Registry-based configuration logic — the PAIDMEMES hive pattern is familiar to me

- I understand interruption points inside timer-based collection loops — because I built the same cycle architecture myself

------------------------------------------------------------------------------

8. Microsoft Sentinel Detection Rules (KQL)

The following Kusto Query Language (KQL) queries are designed for deployment in Microsoft Sentinel.

They target specific behavioral artifacts associated with BARADAI and the broader MedusaLocker family.

Deploy all three as scheduled analytics rules.

Rule 1: PAIDMEMES / BabyLockerKZ Registry Artifact Detection

High confidence.

Detects exact forensic strings unique to MedusaLocker v3 / BARADAI.

If This Rule Triggers

The device is actively infected with BARADAI or the malware has successfully established persistence.

Treat as a P1 incident.

Immediately isolate the endpoint.

Rule 2: Shadow Copy & Backup Deletion Chain Detection

High confidence.

Detects BARADAI’s recovery-destruction sequence.

If This Rule Triggers

A ransomware payload is actively preparing for encryption.

This is your final detection window before data loss begins.

Immediately isolate the affected endpoint and every reachable network share.

Rule 3: EnableLinkedConnections — Network Share Privilege Escalation Detection

Medium-High confidence.

Detects BARADAI’s technique for accessing administrator-mapped network drives from non-elevated processes.

If This Rule Triggers

An attacker is preparing to encrypt network shares normally visible only to administrator-level processes.

This is a pre-encryption lateral movement signal.

----------------------------------------------------------------

9. MITRE ATT&CK Mapping

------------------------------------------------------------------------------

10. Decryption Research and My Current Approaches

Let me be completely transparent.

Current status:

There is no verified public decryptor available for BARADAI.

-The No More Ransom project lists no decryptor for any MedusaLocker v3 / BabyLockerKZ variant

-The AES-256-CBC + RSA-4096 implementation is mathematically sound

-Historical decryptors existed only for significantly older MedusaLocker v1 and early v2 variants by exploiting key sanitization weaknesses in memory management

-Those vulnerabilities were patched in v3

What We Know About the Encryption

BARADAI uses intermittent encryption for large files:

-Files larger than ~7.7MB are not fully encrypted

-The malware encrypts 750KB, skips 250KB, encrypts another 750KB, and repeats

This dramatically reduces encryption time while still rendering the file structurally unusable.

---------------------------------------------------------------

What I Am Currently Researching

I am currently analyzing the BARADAI binary from multiple angles:

PRNG Weaknesses

I am investigating the entropy source used during AES key generation.

If the PRNG is insufficiently random, the effective key space may be reducible.

Key Sanitization Behavior

I am investigating whether AES keys remain in memory after usage.

This weakness existed in MedusaLocker v1 and v2 and enabled historical decryptors.

Although patched in v3, implementation mistakes remain possible.

PAIDMEMES Registry Storage Analysis

The PAIDMEMES hive stores runtime state.

I am investigating whether this storage area contains recoverable cryptographic material.

Registry-stored cryptographic data could provide a viable decryption foothold.

Weaknesses in Intermittent Encryption

The 750KB-encrypt / 250KB-skip pattern enables structural comparisons between encrypted and unencrypted regions.

Known file formats (.docx, .xlsx, etc.) contain predictable header structures.

This creates potential for partial known-plaintext attacks.

------------------------------------------------------------------------------

I will publish my findings in Vol.4 of this series regardless of the outcome.

-------------------------------------------------

If You Are a BARADAI Victim

-Do not pay the ransom until all alternatives are exhausted

-Contact professional incident response services

-Preserve all encrypted files and ransom notes — a future decryptor may eventually become available

-Regularly monitor nomoreransom.org

----------------------------------------------------

11. Defensive Recommendations

Priority 1: Phishing-Resistant MFA (Against AiTM)

Traditional MFA — push notifications, SMS codes, authenticator apps — can be defeated by AiTM reverse-proxy attacks.

Deploy:

-FIDO2 hardware security keys (YubiKey, etc.)

-Windows Hello for Business

These technologies cryptographically bind authentication tokens to the legitimate TLS session of the login portal.

Stolen cookies become useless in separate sessions.

-------------------------------------------------------

Priority 2: Eliminate RDP Exposure

BARADAI’s primary initial access vector is exposed RDP on TCP 3389.

-Disable Internet-facing RDP at the perimeter firewall

-Enforce MFA + VPN for all remote administrative access

-Implement account lockout policies and Network Level Authentication (NLA)

Priority 3: Immutable Backups

BARADAI deletes Volume Shadow Copies via vssadmin.

Implement:

-A 3–2–1 backup strategy with at least one offline/immutable copy

-Azure Immutable Blob Storage (WORM)

-Multi-user authorization for backup vaults

-Monthly restoration testing

---------------------------------------------

Priority 4: FSRM Canary Files

Configure Windows File Server Resource Manager (FSRM):

Immediately alert when files with extensions:

.BARADAI

.BAVACAI

.BASANAI

.BAGAJAI

are created.

Trigger automated scripts that:

-Terminate the originating user session

-Revoke network share access

--------------------------------------------------

Priority 5: Deploy the Sentinel KQL Rules Above

The three rules in Section 8 provide layered behavioral detection that signature-based tooling cannot replicate.

Deploy them before an incident occurs.

--------------------------------------------------------------------------

Priority 6: Zero Trust Architecture

BARADAI’s EnableLinkedConnections Registry modification allows standard user processes to encrypt administrator-mapped drives.

-Segment backup servers, Domain Controllers, and critical infrastructure

-Require hardware-backed MFA for sensitive segments

-Implement least privilege and Just-In-Time (JIT) administrative access with Azure PIM

------------------------------------------------------------------------

📢 Call to Action: Collective Intelligence

I started this research alone. But disrupting the impact of the B-Family requires collective effort.

If your organization or threat-hunting operations have observed additional logs, unusual network traffic, or alternative steganographic payload samples associated with the B-Family (BARADAI, BAVACAI, BASANAI, etc.), do not remain silent.

Data Sharing You may share anonymized IoCs or log artifacts with us. and 

Direct Contact

If you have technically significant observations or findings related to BARADAI analysis, you can contact me directly through my Webex profile.

Webex Contact - email address removed for privacy reasons

Our collective security depends on the aggregation of these small signals.

---------------------------------------------

Sources and References

For technical verification and further investigation, refer to the following resources:

Threat Intelligence & Ransomware Reports

CYFIRMA: Weekly Threat Intelligence Report (2026–05–08)

Ransomware.live: BAVACAI Group & DLS Infrastructure

PCrisk: BAVACAI | BAGAJAI | BASANAI Analysis

Technical Foundations & MITRE TTPs

CISA: MedusaLocker Advisory (AA22–181A)

Picus Security: MedusaLocker TTPs and Simulation

Barracuda: GhostFrame Phishing Kit Spotlight (2025–12–04)

Detection & Response Tools

Microsoft Sentinel: Official Shadow Copy Deletion Analytics Rule

GitHub (Bert-JanP): Hunting Queries and Detection Rules

No More Ransom: Global Decryption Tools Repository

Cassandra MARE Independent Research

Deniz Tektek: Stegomalware & Fileless Persistence (2026–04–05) https://medium.com/@deniizz/stegomalware-steganografi-ve-windows-registry-ile-kalıcılık-sağlayan-png-01e50849a218

Cassandra Community: Initial BARADAI Analysis (2026–05–14) https://medium.com/@cassandracommunity/baradai-ransomware-hayalet-yazılım-ı-parçalarına-ayırıyoruz-0c04bb008f73

This article has been published strictly for defensive purposes. All described techniques have been analyzed within the context of threat detection and defense.

This is my debut article on the Microsoft Tech Community. I am Deniz Tektek, a Red Team Operator, Cybersecurity Analyst, and Founder of the Cassandra community. My work focuses on the intersection of human psychology, IoT security, and the development of zero-trust local AI agents.

This article, “The Fileless Paradox,” is the inaugural entry in my "We Saw It Coming" threat intelligence series, where I document technical overlaps between independent research and active real-world threats.

What’s Next?

Vol. 2: "Invisible Exfiltration" — Analyzing how BARADAI’s C2 hides in plain sight.

Vol. 3: "The Human Gateway" — Why your MFA and AI-driven defenses are currently being bypassed.

Vol. 4: "Cracking BARADAI" — My ongoing decryption research.

Connect With Me If you want to discuss these findings, exchange logs, or collaborate on security research, please check my profile bio for contact information or connect with me via LinkedIn. I welcome all technical perspectives and peer reviews.

My LinkedIn: https://www.linkedin.com/in/deniz-t-91166438a

Deniz Tektek — May 2026

© Deniz Tektek & Cassandra — All Rights Reserved.

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