The delivery server that should have been locked down instead exposed 1,048 files, giving analysts a full view of an AI-assisted phishing toolkit in the wild. Rapid7 swooped in, downloaded the entire repository, and laid out a development trail that most defenders never see. That trail includes lure templates, failed experiments, and a live campaign aimed at Windows users in Mexico.
Key Takeaways
- Rapid7 recovered a 1,048‑file repository that documents an AI‑driven phishing operation.
- The core technique abuses CVE‑2025‑33053 to hijack WebDAV shares via.url shortcuts.
- Over 77,000 requests were logged in a six‑day window, with Mexico accounting for 82.5% of traffic.
- LLM‑generated README files, emoji‑heavy scripts, and a mapping CSV point to a generative‑AI workflow.
- The campaign delivered a.scr file masquerading as a PDF, stealing wallets, credentials, and Telegram sessions.
AI-Assisted Phishing Toolkit Exposes Development Process
What’s striking isn’t just the payload size; it’s that the attacker left the whole operation in plain sight. The server hosted the complete toolkit, from initial lure generation to final delivery logs. That openness let Rapid7 see hard‑coded paths that point to an open‑source AI coding agent, suggesting the operator leaned on generative AI to churn out phishing components at speed.
Why the Server Was Open
The admin panel, a tool called Simba Service, sat on the server with its default port and credentials untouched. That oversight turned a private lab into a public case study. It’s a reminder that even threat actors can slip up.
Historical Context
WebDAV‑related hijacks have been part of the Windows attack surface for years. Early proofs of concept showed that manipulating a working directory could redirect helper binaries, a technique that resurfaced with each new client update. When CVE‑2025‑33053 was disclosed, the community noted its similarity to prior directory‑traversal bugs, but the public documentation was sparse.
At the same time, the security world watched generative AI models evolve from simple autocomplete tools to full‑fledged code generators. By 2022, researchers had demonstrated that large language models could produce functional snippets of malicious code when prompted. Those experiments laid the groundwork for the kind of automated, self‑documenting kits we see today.
Rapid7’s discovery fits into that timeline. The repository’s README files, emoji‑laden comments, and mapping CSV echo the output style of popular code‑generation assistants. That overlap isn’t accidental; it reflects a broader shift where attackers treat AI as a teammate rather than a novelty.
Inside the WebDAV Hijack Chain
The centerpiece of the kit focuses on CVE‑2025‑33053, a WebDAV working‑directory hijack that Check Point documented last summer. The technique uses a.url shortcut to launch a legitimate signed binary—originally iediagcmd.exe—while pointing its working directory at an attacker‑controlled WebDAV share. When the shortcut runs, Windows loads a malicious route.exe from the share instead of the genuine one in System32.
Microsoft patched the flaw in June 2025, yet the operator reproduced the exploit, likely to test its viability on older systems. The README claims the attack runs “WITHOUT any security warnings. Zero alerts!” despite the patch.
Scaling the Test Set
One “comprehensive test kit” expands the single technique into 59.url files, each targeting a different signed binary—.NET tools like InstallUtil and RegAsm, LOLBAS entries, and even UAC‑bypass candidates. The notes label these as hypotheses, not confirmed hijacks, showing a systematic probing approach.
The operator also bundled smaller test sets for two other file‑handling flaws: the MSHTML bypass CVE‑2026‑21513 and the NTLM‑leak CVE‑2025‑24054. Still, the WebDAV hijack remained the primary focus.
Technical Architecture of the Exploit
At the heart of the chain lies the.url shortcut file. The file contains a URL that points to a signed executable, but it also embeds a working‑directory directive. Windows evaluates that directive before launching the binary, trusting the path as if it were part of the executable’s own environment. By pointing the directive at a remote WebDAV share, the attacker gains control over any auxiliary binaries the main executable attempts to load.
In this case, the signed binary expects to find route.exe in its System32 folder. The manipulated working directory causes the loader to pull route.exe from the attacker’s share instead. Because route.exe is also signed, the operating system does not raise a warning, and the malicious payload executes silently.
The exploit chain also uses the.scr file format. A right‑to‑left Unicode override tricks the file manager into displaying “PDF” while the system treats the file as a script. When the victim clicks the link, the script runs, drops an Inno Setup installer, and hands off a.NET infostealer to a signed Qihoo 360 process. The entire flow hinges on trusted components being redirected, a classic “trusted‑source” abuse.
LLM Footprints in the Code
Rapid7 identified a distinct LLM signature across READMEs, lure‑generation guides, and a _MAPPING.csv that ties each test file to its target binary. The formatting is verbose, emoji‑laden, and mirrors output from large language models. Even the phishing site’s JavaScript carries that emoji‑heavy style.
The Russian‑language comments and folder names—one called testik—place the operator in a Russian‑speaking context, but no identity is revealed. Rapid7 attributes the workflow to an LLM‑assisted tool likely built with help from a code‑generation model dubbed Coderrr, rendered as “CodeRRR.”
The original report confirms the repository is public as of July 20, 2026. The AI agent behind it draws inspiration from Claude Code, GitHub Copilot CLI, and Cursor—general‑purpose tools, not attacker‑specific frameworks. Rapid7 summed it up bluntly: “the attacker used LLMs to operate more like a modern software product team.”
Campaign Metrics and Impact
Threat‑intel traced the active campaign to gobf.mx, a typosquat of Mexico’s CURP national‑ID lookup site. Victims saw a fake record‑retrieval page; clicking the download button fired a search‑ms:query that opened the attacker’s WebDAV share filtered to.scr files.
The most‑delivered lure masqueraded as a CURP PDF report but was actually a.scr executable. A right‑to‑left Unicode override made the filename read as “PDF” while the OS treated it as a script. The payload was an Inno Setup installer that unpacked a loader and ran a.NET infostealer entirely in memory, hollowed into a signed Qihoo 360 process.
The stealer harvested cryptocurrency wallets, browser credentials, session cookies, and Telegram sessions. A secondary campaign directory—DlrtyGames—took a different route, sideloading a trojanized DLL through a signed Ubisoft binary to drop a modular.NET RAT.
During a 5.5‑day window (June 20‑26, 2026 UTC), the delivery panel logged 77,098 requests from 3,892 unique IPs across 101 countries. Mexico alone drove 82.5% of traffic and accounted for 96.9% of launch activity. A single CURP lure was responsible for 2,384 of the 2,441 launch events—about 97.7% of all launches.
Those figures measure delivery reach, not infections. Rapid7 counts a “launch event” when the panel sees a client request or opens an executable from the SHA.
Implications for Defenders
- LLM‑generated tooling can produce fully documented attack kits that expose internal testing.
- WebDAV hijacks remain viable on legacy Windows versions despite patches.
- Emoji‑heavy, verbose README styles may become a new indicator of AI‑assisted threat actors.
- Typosquatting of government services continues to be an effective lure vector.
What This Means For You
If you develop Windows utilities, you need to audit any.url shortcuts that launch signed binaries. Even if a binary is signed, a malicious working directory can redirect helpers like route.exe to attacker‑controlled code. Patch‑level checks alone aren’t enough; runtime validation of the working directory should be added to your hardening playbook.
For security teams, the presence of LLM‑style documentation—emoji, verbose language, and mapping CSVs—should be added to your detection heuristics. The fact that an entire development workflow was left exposed means you can now train models on real‑world AI‑assisted malware creation, improving future alerts.
Looking ahead, we’ll have to ask whether the ease of LLM‑driven tooling will make such detailed, self‑documenting kits more common, and how defenders can stay a step ahead without exposing their own processes.
Concrete Scenarios
- You’re packaging a signed installer that includes a.url shortcut for automatic updates. An unchecked working‑directory field could let an attacker replace a helper binary, turning a benign update into a delivery vector.
- Your organization relies on internal WebDAV shares for distributing configuration files. If an adversary gains read‑only access, they could host malicious binaries and wait for a misconfigured shortcut to pull them in.
- A SOC analyst receives an alert about a new.url file on a compromised host. Matching the file’s name against known LLM‑generated patterns—emoji usage, overly verbose comments—could prioritize the investigation before the payload executes.
Key Questions Remaining
- Will future patches to WebDAV handling close the remaining bypass paths, or will attackers shift to other trusted‑binary redirection techniques?
- How quickly can defensive tooling adapt to the stylistic fingerprints left by LLM‑generated malware, given the rapid iteration cycles of AI models?
- What governance frameworks can organizations adopt to prevent their own development pipelines from becoming inadvertently public, mirroring the mistake seen with the Simba Service panel?
- Can threat‑intel platforms incorporate the observed mapping CSV structure to automate correlation of new.url files with known malicious binaries?
Sources: The Hacker News, Rapid7
