Cross-Platform Rust Loader Delivers Modified Sliver Implant via Cloud Storage Abuse

We identified a two-stage malware operation: a Rust-compiled downloader that fetches and AES-128-CFB decrypts a second payload confirmed to be a modified build of Sliver, the open-source C2 framework. Both stages are staged inside a misconfigured cloud storage bucket belonging to an unrelated third party, and command-and-control runs behind Cloudflare Tunnel, concealing the operator's true origin server. RADICL tracks this activity as UNC-RAID-M8280.

Key Findings

• A Rust-compiled loader downloads and AES-128-CFB decrypts a second-stage payload confirmed to be a modified build of Sliver, the open-source C2 framework.
• One build pipeline covers five platforms — i386, ARM32, ARM64, and x86-64 Linux, plus Windows — with per-build AES keys patched into an otherwise-identical compiled template.
• The Sliver payload carries a custom protobuf extension (FlyFireReq, FlyFireUpgradeReq, FlyFireToolsUploadReq) absent from the public Sliver source tree.
• Both stages are staged inside a misconfigured cloud storage bucket belonging to an unrelated third party.
• Command-and-control sits behind Cloudflare Tunnel, concealing the operator's true origin server. All observed C2 endpoints returned a tunnel-not-connected error at analysis time.
• 31 unique objects recovered across four upload waves, June 2024 through June 2026.

1. Loader

All loader samples are Rust binaries statically linking `reqwest`/`hyper`/`tokio` for HTTP, `aes`/`cfb-mode` for AES-128-CFB, and `rand_chacha`. Every build shares one binary template: a 32-byte block holding a 16-byte key followed by a 16-byte IV, immediately followed by a drop-path string. A patcher tool stamps new key/IV/path values into this block per build; same-wave builds across every architecture are byte-identical outside that one patched region.

Summary

i386 — Two Build Generations

L-I386-1 (1,381,524 bytes, entry 0x804be61) predates the rest of the set by roughly two years. L-I386-2 and L-I386-3 (1,444,352 bytes, entry 0x804bad5) are from the 2026 waves and are byte-identical to each other outside the key/IV/path block. Different size and different entry point across the gap — a rebuild, not a re-key.

All three are stripped. Key/IV recovered from the 32 bytes preceding each binary's embedded /tmp/ path:

ARM32 — Unstripped, Confirms the Code Path Directly

All three ARM32 samples share one build (entry 0x13f54, 1,832,272 bytes) and, unlike every other architecture in this set, ship with symbols intact:

The key, IV, and drop-path string sit contiguous in memory, in that order:

The source crate is named linux; control flow is can_access_internet → download → decrypt_shellcode_stub. Only an encrypt primitive exists in the binary — CFB decryption reuses the block cipher's encrypt operation on the keystream, so no separate decrypt routine is ever compiled in. The aes crate's soft::fixslice implementation is a bitsliced, table-free AES — it doesn't use the classic S-box lookup table, which is why that byte sequence doesn't appear anywhere in these binaries.

ARM64

Four samples, one build (entry 0x4031bc, 2,016,000 bytes). Symbols aren't retained here despite file reporting "not stripped" — key/IV extraction used the same drop-path-marker method as the stripped architectures.

x86-64

Four samples, one build (entry 0x14c0a, 1,569,392 bytes). file calls these "dynamically linked" — misleading. No NEEDED entries, no PT_INTERP segment: this is static-PIE, fully self-contained.

Windows — MinGW-w64

Three samples, 1,380,352 bytes, byte-identical outside a 270-byte patched window (offset 0xd2131–0xd223e) holding the same key/IV/path template, adapted to c:/users/public/downloads/<hex>.

Toolchain is GNU/MinGW-w64, not MSVC: MajorLinkerVersion=2.34 is a ld version number, no Rich/DanS marker is present anywhere in the file, and the import table pulls msvcrt.dll with legacy CRT startup symbols (__getmainargs, __initenv, _acmdln) characteristic of MinGW's crt1.o rather than MSVC's UCRT startup. Build timestamp 1751339644 (2025-07-01T03:14:04Z) is identical across all three.

192 imported functions across 14 DLLs. No CryptoAPI imports — AES-CFB is entirely the statically-linked Rust crates, same as the Linux builds. OpenProcess, VirtualAllocEx, WriteProcessMemory, ResumeThread, and CreateProcessA/W are all present, but NtUnmapViewOfSection and SetThreadContext/GetThreadContext are absent, as is CreateRemoteThread — the import table alone supports a drop-to-disk-and-execute loader, not confirmed process hollowing.

Cross-Architecture Notes

• Key reuse spans architectures within a wave, not just within one architecture — the same AES key patches into the i386 build and the Windows build in the same batch.

• No persistence, no mutex, no anti-debug or anti-VM strings anywhere in the loader, any architecture. Any persistence on a compromised host comes from the operator via the second stage, not the loader itself.

2. Payload

Decryption

All 13 second-stage payloads are AES-128-CFB ciphertext — no header, no magic bytes, uniform ~8.0 bits/byte entropy end to end. All 13 keys trace directly back to loaders in this set. Only nine distinct keys cover the 17 loaders, and the reuse isn't confined to one architecture — the same key can span multiple loader architectures and decrypt multiple payloads in different formats:

Key 2 decrypts three payloads across three different formats — native i386, native x86-64, and x86-64 shellcode. Keys 6, 7, and 8 each decrypt two. The operator is minting one key per delivery batch, not per artifact — architecture and payload format don't factor into key assignment. Key 9's loader, L-ARM64-3, has no matching payload among the 13 recovered, meaning whatever it was paired with was never uploaded or already removed.

Identification

10 of 13 payloads decrypt to native ELF binaries matched to their loader's architecture. The remaining 3 decrypt to raw x86-64 shellcode with no file header — built for reflective/in-memory loading rather than execution from disk. Every payload, ELF or shellcode, carries the identical 198-message sliverpb.* capability surface — the shellcode packaging isn't a reduced build.

Build fingerprint across all 13: Go 1.19.3, CGO_ENABLED=0, -trimpath=true (no leaked developer paths), module path github.com/bishopfox/sliver, version (devel).

A Modified Fork

All 13 payloads carry protobuf message types compiled into the standard github.com/bishopfox/sliver/protobuf/sliverpb package that do not exist in the public Sliver source: FlyFireReq/FlyFireResp, FlyFireUpgradeReq (versioned self-upgrade, carries a file name and payload), and FlyFireToolsUploadReq/FlyFireToolsUploadResp (per-architecture tool upload with an MD5 checksum). Full getter methods are compiled in for every field — a genuine schema extension, not a stray string.

Capability Surface

• File system: Ls, Mkdir, Mv, Rm, Cd, Pwd, Download, Upload, FileInfo
• Execution: Execute, ExecuteAssembly, InvokeExecuteAssemblyReq, InvokeInProcExecuteAssemblyReq, SpawnDll, Sideload, Task, Ps, ProcessDump, LinuxMemFdExecuteReq (fileless exec via memfd_create), WindowsMemExecuteReq
• Privilege escalation: GetSystem, GetPrivs, Impersonate, MakeToken, RevToSelf, RunAs, CurrentTokenOwner, WindowsPrivilegeEntry
• Persistence: Backdoor, ServiceInfo, StartServiceReq, StopServiceReq, Migrate
• Windows registry: RegistryCreateKey, RegistryDeleteKey, RegistryRead, RegistryWrite, RegistrySubKeyList, RegistryValuesList
• Networking and pivoting: Portfwd, RPortfwd, Socks, StartImplantLocalSocks5Req, WGSocks/WGSocksServer (WireGuard SOCKS), WGPortForward, WGTCPForwarder, NetConnPivot, Netstat, Ifconfig, Tunnel/TunnelData
• Multi-hop pivoting: PivotHello, PivotListener, PivotPeer, PivotServerKeyExchange, PivotStartListenerReq
• C2 session: BeaconRegister, BeaconTasks, DNSBlockHeader, DNSSessionInit, HTTPSessionInit, Envelope, OpenSession, Reconfigure, PollInterval, KillReq, WebhookTunnelData
• Reconnaissance: Screenshot, EnvInfo, camera and interface enumeration via the vendored library set below
• Extension framework: CallExtension, ListExtensions, RegisterExtension
• Interactive access: Shell, SSHCommand
• Fork additions: FlyFireReq/Resp, FlyFireUpgradeReq, FlyFireToolsUploadReq/Resp

Vendored Libraries

User-Agent Strings

13 unique UAs, one per binary, drawn from Sliver's default randomized pool — 11 Windows-shaped, 2 Linux-shaped, with synthetic Chrome version numbers that don't match real releases. Not tied to the binary's actual target platform.

C2 Domains

3. Infrastructure

Both stages are staged inside a misconfigured cloud storage bucket — an unrelated company's storage, not attacker-owned infrastructure, with anonymous list and read access enabled. The malware objects sit alongside years of that company's own operational data, giving the operation free, high-reputation hosting with no infrastructure footprint of its own. An unrelated Chinese-language scareware page (a Ministry of Public Security impersonation, hash LURE-1) was also present in the same bucket, with no functional connection to the loader/implant chain.

Command-and-control runs on a domain registered through NameCheap in December 2025, Cloudflare-fronted with certificates from Google Trust Services, plus one earlier domain (traceroute[.]vip) tied to the 2024 wave that had since lapsed into domain parking and finally NXDOMAIN. Both sit behind Cloudflare Tunnel — the operator's real origin server is never exposed via DNS or direct connection.

At the time of this analysis, every C2 subdomain returns Cloudflare error 1033 (tunnel not connected), reproduced through different methods.

Two additional subdomains on the same apex domain — api[.]lotteofficial[.]org and music[.]lotteofficial[.]org — were not observed in any recovered payload but return the identical Cloudflare Tunnel error, indicating shared operator infrastructure with no confirmed sample tying them to this campaign.

One subdomain has a public historical scan (December 2025, status 200) serving a verbatim copy of the real systemd sysupdate.d manual page — cover content for anyone browsing the domain directly without the request signature an implant would send. Live reproduction returns the same tunnel error as everything else; the capture reflects a period when the tunnel was still connected.

Remediation

RADICL reported the abused storage bucket to the hosting cloud provider. The provider confirmed the reported content had been mitigated, removing the operator's staging and delivery point for both loader and payload stages.

4. Detection

Loader: a process writing a file to /tmp/<64–100 hex chars> (Linux) or c:\users\public\downloads\<64–100 hex chars> (Windows) and executing it shortly after is the strongest host indicator. Rust build-artifact strings (aes-0.7.5, cfb-mode-0.7.1, decrypt_shellcode_stub) survive stripping and are stable across build generations.

Payload: the FlyFire* protobuf strings are a low-collision signature for this specific fork if the payload is ever recovered unencrypted. memfd_create-based fileless execution (Linux) and unbacked executable memory regions (Windows) match the implant's compiled capabilities. Domain-based blocking of the C2 domains is more effective than IP-based blocking, given Cloudflare Tunnel's shared, rotating edge addresses.

Infrastructure: this delivery chain depends entirely on a cloud storage bucket with open list/read permissions.

Indicators of Compromise

Files

Network

File System

YARA

rule Rust_Stager_AES_CFB_Sliver_Loader {
    meta:
        description = "Rust-compiled multi-platform stager that downloads and AES-CFB decrypts a Sliver-family implant"
        date = "2026-07-09"
    strings:
        $sym1 = "linux::download" ascii
        $sym2 = "decrypt_shellcode_stub" ascii
        $sym3 = "can_access_internet" ascii
        $crate_aes = "aes-0.7.5" ascii
        $crate_cfb = "cfb-mode-0.7.1" ascii
        $droppath_lin = /\/tmp\/[0-9a-f]{60,100}/ ascii
        $droppath_win = "c:/users/public/downloads/" ascii nocase
    condition:
        (2 of ($sym*)) or (all of ($crate_aes, $crate_cfb)) or $droppath_lin or $droppath_win
}

rule Sliver_Implant_Custom_FlyFire_Extension {
    meta:
        description = "Sliver C2 implant carrying non-stock FlyFire* protobuf extension"
        date = "2026-07-09"
    strings:
        $stock1 = "github.com/bishopfox/sliver" ascii
        $stock2 = "sliverpb." ascii
        $custom1 = "FlyFireReq" ascii
        $custom2 = "FlyFireUpgradeReq" ascii
        $custom3 = "FlyFireToolsUploadReq" ascii
    condition:
        (1 of ($stock*)) and (1 of ($custom*))
}