Still Circling: Blind Eagle's Toolkit Keeps Evolving

In June 2025, LevelBlue SpiderLabs published Tracing Blind Eagle to Proton66, in which we assessed with high confidence that Blind Eagle (also tracked as APT-C-36, APT-Q-98, TAG-144, AguilaCiega), a threat actor focused on Latin America, had moved part of its VBScript delivery infrastructure onto the Russian bulletproof hosting provider Proton66. A year later, we're still tracking this cluster closely, and the group hasn't slowed down. If anything, it has kept building.

Between late May and early July 2026, we collected several fresh batches of samples from newly exposed Blind Eagle staging servers. Rather than retread ground we've already covered, this blog post focuses squarely on what's new.

Four developments stood out during this collection window:

1. a third distinct string-obfuscation scheme, including a JavaScript-based stage that replaces AES’s standard Rijndael S-box with a bespoke permutation

2. a RunPE loader built entirely on a bare AutoIt3 interpreter and staged through raw.githubusercontent.com, a domain most security stacks allow-list by default

3. a persistence disguise (“Photo Studio”) that we found reused, byte-for-byte, across three independently obfuscated toolchains, pointing to a shared internal builder; and

4. a materially upgraded AsyncRAT build, internally codenamed JC-46, that introduces Windows Notification Facility (WNF) process injection, a custom Base28 payload encoding, a full Hidden VNC (HVNC) banking-fraud module with browser profile cloning, and a Chrome App-Bound Encryption (ABE) v20 bypass.

A Familiar Pattern, on New Servers

As in the Proton66 cluster, every sample set discussed in this post was recovered from an exposed, unauthenticated Apache open directory — a recurring Blind Eagle pattern that has now been documented by multiple independent research teams over a period of several years. Table 1 summarizes four representative staging servers behind this collection window.

These four IPs are just a slice of a much larger picture. They sit alongside a sprawling set of similarly built domains and IPs that heavily overlap, and that mostly rely on the same dynamic DNS services. Nearly all of them also host the same or near-identical payloads, built on identical or closely related logic. We won't catalog the entire footprint here, but we'll walk through some of the most interesting cases below.

Table 1. Open-directory staging servers observed across the May to July 2026 collection window.

One data point is worth calling out on its own: the C2 host recovered from the 46[.]246.84.5 dropper is not new infrastructure in any meaningful sense. That same IP address appears in historical AsyncRAT C2 resolution data for Blind Eagle dating back to March 2023, resolving through the same commercial VPN exit pool the group has leaned on for years. Whether this reflects literal infrastructure reuse or simply the actor drawing repeatedly from the same small, cheap VPN provider, it reinforces an assessment we have made previously: Blind Eagle’s operational tempo is high, but its infrastructure choices are narrow, repetitive, and rarely refreshed.

One Actor, Three Obfuscation Dialects

Blind Eagle’s VBScript droppers have always leaned on encrypted string tables and AES-wrapped payloads, but the three loader families recovered this cycle show a threat actor (or, more precisely, a crypter-as-a-service provider working for the actor) actively iterating on the obfuscation layer while leaving the underlying delivery logic essentially untouched: build a random %TEMP% folder, assemble an AES decryption stub in memory, execute it, and delete the evidence.

Fixed-key XOR and a Self-rewriting Dropper

The simplest of the three (46[.]246.84.5) XOR-encrypts 35 string constants with a single hardcoded byte, 0xE0, before assembling and executing an in-memory AES-256-ECB PowerShell decryptor.

Figure 1. The envifa.vbs / sostener2.vbs string decryptor— XOR against a single hardcoded byte, 0xE0.

More interesting is a self-mutation routine that reads the script’s own source from disk, re-encrypts every string with a freshly randomized XOR key, renames every zv-prefixed identifier, and overwrites itself — changing the file hash on every single execution.

Figure 2. Because the key and every identifier change on each run, hash-based IOCs from this family go stale the moment a sample executes once.

The practical takeaway for defenders is unambiguous: file hashes for this loader family are worthless beyond a single infected host. Detection has to anchor on the constant 0xE0 XOR key, the zv-prefixed identifier pattern, and the AES-256-ECB PowerShell decryption skeleton described later in this post — all of which recur, with only cosmetic changes, across every loader family we discuss below.

A Hand-rolled Stream Cipher, Disguised with Fake Arithmetic

The 181[.]235.8.24 loader family (31agosto.vbs, 31diciembre.vbs, andre.vbs, sostener.vbs) is considerably more elaborate. Roughly 95% of each 3.5 to 4.0 MB file is a single giant Base64-like string built from thousands of chained VBScript string-concatenation statements – not junk, but the AES ciphertext for the next stage, split into small fragments purely to defeat naive Base64-blob signatures and to inflate the file well past the size threshold some scanners use to skip deep inspection.

Layered on top of that is a second obfuscation trick: a 13-element array of pipe-delimited byte values is deliberately populated out of index order, and the “correct” reassembly order is computed via arithmetic expressions that look like a keyed shuffle but evaluate, every time, to the identity mapping 0, 1, 2 … 12.

Figure 3. A “keyed shuffle” that is, on inspection, a no-op — cheap but effective against static de-obfuscators that reorder arrays without actually evaluating the arithmetic.

The reassembled stream is then fed into a genuinely custom decoder: a stateful cipher combining a running XOR accumulator, a small per-build rotation table, and an 8-bit rotate-right-by-3 operation — functionally similar to a simplified RC4/TEA keystream generator, but entirely bespoke.

Figure 4. The custom stream-cipher decoder. Every constant here — the seed, the rotation table length and values, and the variable names — is randomized per build; the algorithm itself stays fixed.

The decoded output runs via ExecuteGlobal and reveals a clean, legible stage-2 script whose real purpose is disguised behind a fake photo-viewer identity – the same “Photo Studio” cover story we return to below. From there, an AES-256-ECB-encrypted PowerShell payload compiles inline C# via Add-Type and performs process hollowing into RegSvcs.exe, the signed .NET Services Installation Tool. A commented-out line in that final stage:

#XLOADER $processToHollow = [System.Diagnostics.Process]::GetCurrentProcess().MainModule.FileName

is a builder artifact, suggesting that this RunPE template was copied or licensed from the XLoader/FormBook loader ecosystem, a pattern of template reuse that is common among commercial crypter and loader-as-a-service operators.

A JavaScript Stage with its own AES S-box

The most technically distinctive sample in this collection came from 178.16.52.80: a three-file chain (hold.bat, hold.vbs, hold.js) in which the final JavaScript stage implements a fully custom AES-256 cipher — not a wrapper around .NET’s AesCryptoServiceProvider, but a hand-rolled implementation with a non-standard substitution box and non-standard round constants.

Figure 5. hold.js— a custom AES-256 implementation with a substituted S-box and RCON table, then an additional 0xA5 XOR mask layered on top of the decrypted output.

Substituting both the S-box and the round constants is a meaningfully more sophisticated evasion choice than anything else in this collection: any tool, decryptor, or YARA rule that fingerprints standard Rijndael constants will silently fail against this sample, even though the overall cipher structure is still recognizably AES. Combined with the outer XOR-hex VBScript layer (13,409 concatenated fragments, alternating key bytes 0x88/0x1E) and the DOS-batch-disguised-as-.exe first stage, this is a four-layer obfuscation stack for what is, functionally, the same “Photo Studio” persistence and fileless PowerShell execution pattern seen in the other two families.

A Bare AutoIt3 Interpreter, Staged from GitHub

The fourth staging server, 64[.]89.160.17, introduced a delivery mechanism we had not previously documented for this actor: instead of a single obfuscated dropper, two small VBScript downloaders (System3.vbs, System5.vbs, roughly 790 bytes each) simply shell out to PowerShell to fetch two files from raw.githubusercontent.com and chain them together.

Figure 6. The complete, functional body of System3.vbs. No .ps1 file ever touches disk; the PowerShell command is built inline and passed via -Command.

The file downloaded as installer.exe / .pif has a legitimate “AutoIt Consulting Ltd” version resource and is, on inspection, the generic AutoIt3.exe runtime with no compiled script attached — the AU3!EA06 marker that Aut2Exe embeds into self-contained builds is entirely absent. In other words, the actor ships the interpreter and the malicious logic as two independent files precisely so the interpreter’s hash always matches a known-clean AutoIt release, while the actual script (fetched separately and mislabeled with a .html extension) can be swapped at will without repacking anything.

That script implements roughly 12,000 lines of heavily obfuscated AutoIt, with essentially every literal string and API name run through a custom decoder the author named Wales(). Each call site supplies a ]-delimited list of shifted character codes and a key expressed as a division rather than a bare integer.

Figure 7. Worked decode of a single Wales() call site. Scripted decoding across all 2,101 call sites recovers the loader’s complete DllCall() surface.

Decoding the full call graph confirms that this is another process-hollowing loader — fingerprinting installed AV/EDR by process name, spawning AppLaunch.exe or jsc.exe suspended, unmapping the legitimate image, decompressing an embedded payload (RtlDecompressFragment / LZNT1), writing it in, and resuming the thread. One detail is worth flagging on its own: before spawning the hollowing target, the script builds an extended STARTUPINFOEX attribute list with PROC_THREAD_ATTRIBUTE_PARENT_PROCESS (0x00020000), populated with a handle obtained via OpenProcess(..., ProcessExists("explorer.exe")) — classic parent-process-ID spoofing, so process-tree telemetry shows the hollowed process as a child of Explorer rather than of the AutoIt interpreter that actually created it.

Defenders relying on domain-reputation controls for stage-2 downloads should not treat GitHub raw-content URLs as inherently safe and should instead alert on the command-line pattern itself: an AutoIt3.exe-identified process invoked from a user-writable directory with a non-.au3 file argument is anomalous regardless of where that file was retrieved from.

“Photo Studio”: One Persistence Disguise, Three Toolchains

Perhaps the most useful correlation to come out of this collection window did not come from any single sample, but from comparing all of them side by side. Three independently obfuscated loader families — the 181[.]235.8.24 stream-cipher loader, the 178[.]16.52.80 triple-language dropper, and the JC-46 AsyncRAT chain discussed below — all decode to the identical persistence cover identity, down to the exact string values:

Table 2. “Photo Studio” configuration constants recovered, unchanged, from three separately obfuscated toolchains.

These three families use entirely different outer obfuscation — hex-XOR string tables in one, a custom stream cipher in another, rolling XOR with a distinct seed in the third — yet the decoded stage-2 logic that installs persistence is functionally and, in places, literally identical, right down to a Task Scheduler XML template built from ~40 assembled string fragments and a helper function that writes files via a double ADODB.Stream trick specifically to force UTF-8-without-BOM encoding. This is strong evidence of a shared internal builder: the obfuscation layer is generated fresh per campaign (probably to defeat hash- and signature-based detection), while the payload-delivery and persistence logic is templated and reused wholesale. Notably, none of the samples we examined were observed actually invoking the scheduled-task creation routine at runtime in the code path reached during static analysis — the full Task Scheduler XML machinery is present and callable in every family but appears to be a builder feature that individual campaigns can enable or leave dormant.

For threat hunters, this makes “Photo Studio” / “PhotoStudioVBS” a high-confidence pivot: regardless of which lure filename, encryption scheme, or final RAT family is in play, a scheduled task or %LOCALAPPDATA% folder under that name is a durable signal that a host is running this builder’s output.

JC-46: A Materially Upgraded AsyncRAT Build

The most significant find in this collection window is a four-layer chain (31agosto.vbs, andre.vbs, sostener.vbs — reusing the same filenames as the stream-cipher loader family above but carrying a different final payload) that terminates in a heavily customized AsyncRAT build the developer’s own debug artifacts refer to as project JC-46.

Layer-by-Layer: From Hex-XOR to Base28

The chain’s first two stages follow the pattern already described above — fixed hex-XOR (key 0x8F) in stage one, a 99-entry rolling-XOR string table (seed 0x8C, computed at runtime as 0x4C XOR 0xC0) in stage two — before AES-256-ECB decryption yields a 634 KB PowerShell orchestrator. That script introduces a genuinely new encoding scheme we had not seen documented elsewhere for this actor: a custom Base28 alphabet (the 26 uppercase Latin letters plus lowercase ‘a’ and ‘b’) used to encode two further payload blobs.

Figure 8. stage3.ps1’s custom Base28 decoder. Output strings look like random capitalized text rather than the recognizable padding and alphabet of standard Base64, which is enough to dodge most Base64-pattern detections.

The Base28-decoded bytes are then AES-256-CBC decrypted (a different, hardcoded 32-byte key and 16-byte IV per blob) into two artifacts: Paralell.dll (a 69 KB, CryptoObfuscator-protected .NET injector) and Client1.exe (the 298 KB AsyncRAT payload itself). Paralell.dll’s own debug symbols were left in the build:

PDB path (verbatim): C:\Users\UserPC\source\repos\JC-46\JC-46\Paralell\Paralell\bin\Debug\CryptoObfuscator_Output\Paralell.pdb

This single string leaks the developer’s machine username (UserPC), confirms CryptoObfuscator as the commercial .NET protector used post-build, and gives us the campaign’s internal project name — the same JC-46 that also appears, commented out, as a builder tag (“#XLOADER”) inside the PowerShell orchestrator itself.

WNF Injection: A Step Up from CreateRemoteThread

Paralell.dll’s class and method names follow a consistent fashion/clothing theme (CoutureFlow, StyleInjection, RunwayWalk) that reads as innocuous on casual review but maps cleanly onto a process-injection engine. Rather than the classic VirtualAllocEx / WriteProcessMemory / CreateRemoteThread sequence that most EDR products key on, the injector’s primary path abuses the Windows Notification Facility (WNF) via the undocumented NtUpdateWnfStateData syscall to trigger the payload as a kernel-delivered callback, with process hollowing retained only as a fallback for older Windows targets.

Figure 9. Reconstructed WNF injection flow (Paralell.dll). The injection target, MSBuild.exe, is a Microsoft build tool that most EDR baselines whitelist by default.

This is a meaningful capability upgrade from the plain process-hollowing that has characterized Blind Eagle’s tooling in every other sample we examined this cycle (and in prior public reporting), and it is purpose-built to defeat the specific behavioral heuristic (WriteProcessMemory followed by a remote thread creation) that most EDR products use to catch classic injection.

HVNC and Browser Profile Cloning: The Banking-fraud Engine

Client1.exe’s most operationally significant feature is a Hidden VNC (HVNC) module built specifically around Blind Eagle’s banking-fraud mission. The RAT creates an entirely separate Windows desktop that is never connected to any monitor or user session, spawns an Explorer shell onto it for a normal-looking taskbar and start menu, and streams it to the operator while forwarding their mouse and keyboard input back.

Figure 10. Hidden desktop creation, reconstructed from Client1.exe imports and strings.

The operator does not have to phish banking credentials separately: once on the hidden desktop, the RAT pauses the victim’s real browser process just long enough to copy its Chromium profile (cookies, Login Data, Local State, Web Data) into a clone directory, resumes the victim’s browser, and launches a second, fully authenticated browser instance on the hidden desktop using that cloned profile.

Figure 11. Browser profile cloning sequence. The victim’s real session is interrupted for only as long as the file copy takes; the operator then controls an independently authenticated banking session on the hidden desktop.

While the operator works in the hidden session, the visible desktop is covered by a full-screen, topmost overlay in Spanish, purporting to be an in-progress browser update.

Figure 12. Victim-facing distraction overlay strings extracted verbatim from Client1.exe.

Google introduced App-Bound Encryption (ABE) in Chrome 127 (August 2024) specifically to stop non-Chrome processes from decrypting saved credentials and cookies. Client1.exe implements a working bypass for ABE v20 – escalating to SYSTEM via Winlogon token impersonation, then using the Windows CNG APIs to decrypt the ABE master key before falling back to direct SQLite write-ahead-log parsing to read the cookie database while Chrome still has it locked.

Figure 13. Reconstructed Chrome App-Bound Encryption v20 bypass, based on NCrypt/BCrypt import and string analysis of Client1.exe.

The fact that the group is actively tracking and defeating a Chrome security feature introduced in mid-2024 tells us something about their current investment level: this is not a static, “set it and forget it” commodity build, but tooling under continued development against the specific defenses their banking-fraud targets rely on.

The Rest of the Capability Set

Beyond WNF injection and HVNC, JC-46’s capability set is broad even by commodity-RAT standards. The table below summarizes it by category.

Table 3. JC-46 (Client1.exe) capability inventory, grouped by objective.

The Hidden RDP module is worth a brief note of its own: it enumerates and tries both English and Spanish-locale local group names when adding its hidden account to Administrators and Remote Desktop Users – a small detail, but one more piece of evidence for a development team fluent in, and building specifically for, Spanish-language Windows environments.

Detection Takeaways for Defenders

Rather than chasing rapidly changing hashes and obfuscation, defenders should prioritize stable behavioral patterns that persist across Blind Eagle campaigns. High-value detections include wscript.exe or cscript.exe spawning PowerShell, followed by execution of rarely used Microsoft binaries such as RegSvcs.exe, MSBuild.exe, jsc.exe, or AppLaunch.exe, particularly when they perform process injection or hollowing.

Organizations should avoid blindly allow-listing trusted services such as raw.githubusercontent.com; instead, correlate downloads with subsequent execution from user-writable directories. Likewise, monitor for legitimate interpreters such as AutoIt3 executing scripts from %TEMP% or %LOCALAPPDATA%, regardless of the interpreter's reputation.

From a hunting perspective, the most durable host indicators are the shared persistence artifacts reused across multiple loader families, including the "Photo Studio" scheduled task and %LOCALAPPDATA%\PhotoStudioVBS. Defenders should also monitor for browser profile cloning, anomalous access to Chromium profile data by non-browser processes, and process creation patterns indicative of parent-process spoofing or WNF-based injection, as these behaviors are considerably more resilient detection opportunities than the actor's frequently changing obfuscation layers.

Conclusion

A year on from Tracing Blind Eagle to Proton66, the group's fundamentals remain exactly as we described them then: Spanish-language phishing against Colombian and broader Latin American targets, commodity RATs wrapped in custom loader chains, DuckDNS infrastructure, and a level of operational security that continues to hand defenders open directories, leftover PDB paths, and hardcoded keys on a routine basis. What has changed is the sophistication of specific components — a hand-rolled AES implementation with its own S-box, WNF-based injection built to specifically defeat CreateRemoteThread heuristics, and an HVNC/browser-cloning module under active development against Chrome's newest anti-theft protections.

It's also worth pausing on why a toolkit this recognizable keeps working. Blind Eagle isn't succeeding because its tradecraft is stealthy in any absolute sense — it's succeeding because the core delivery mechanics (VBScript droppers, %TEMP%-staged AES decryption stubs, wscript/cscript spawning PowerShell) and the payloads riding on top of them (NjRAT, AsyncRAT, LimeRAT) have barely changed in years, and that stability is the point, not an oversight. A VBScript-to-PowerShell dropper chain is cheap to build, trivial to re-obfuscate on demand, and lands in environments where legacy scripting hosts are still enabled by default and where signature- and hash-based detection is still the primary line of defense. Commodity RATs persist for the same reason commodity malware always persists: they're maintained by someone else, they're cheap or free to license, and their capability set (keylogging, credential theft, remote access, HVNC) already covers everything a banking-fraud operation needs. There is no incentive to replace a delivery mechanism or a RAT family that continues to get past defenses; the incentive is only to keep re-skinning the obfuscation layer just enough to stay ahead of hash- and signature-based detection, which is precisely the pattern this collection window shows across all four sample sets.

That is also why the group's investment is so selective. Rather than rebuilding its toolkit end to end, Blind Eagle channels effort into the small number of components that most directly serve its objectives (a new S-box here, a WNF injection path there, an HVNC module aimed squarely at defeating a specific Chrome protection) while leaving the VBScript delivery skeleton, the commodity RAT core, and the infrastructure patterns untouched.

The group is not reinventing itself; it is investing selectively in the pieces of its toolkit that most directly serve its banking-fraud objectives, while continuing to outsource everything else to commodity malware and a shared external builder. For defenders, this is the key takeaway: the same VBScript-and-commodity-RAT playbook that worked against this actor a year ago, and years before that, still works today.

Appendix: Indicators of Compromise

Network

Table 4. Network indicators.

Files and Persistence

Table 5. File and host-based indicators.