I sure am glad I'm not a software developer at a Russian bank.

Today, I was browsing my threat-hunting stack. And I saw this.

A reasonable person may ask, what is this?

That is wel1.ru, it's a domain – that much we know for sure. But more importantly, it's a domain that has recently appeared in 101 packages, 16 of which has been removed from npmjs.

This is a bad sign, or the way I see it, a great sign that something is afoot.

I click into the potential IOC. And immediately, a huge dependency confusion campaign reveals itself. But I didn't know that yet, so pretend you still don't either.

All the versions are 35.X.X all the instances of the domain are in the same few files, across the same line range. That tells me something too. So I grab a sample, and pop it into Mercury.

Mercury allows me to do basic analysis of NPM and PyPi packages without having to extract malware onto my laptop, this is desirable because I do not want to get pwned, you may find use in it too.

Quick glance. Immediately we can see several Cloudflare worker URLs all broken up, some logic for handling different binaries per OS, and something about analytics.

Quick sidebar on the analytics.

This campaign is doing the same nonsense we saw a while back with the moika.tech campaign, which coincidentally also targetted Russian financial institutions. It really tries to sell this idea that this is a humble telemetry tool.

Back on track. We have a loader, it does many things. One of those is to fetch a stage 2.

Wait wait wait, before it fetches the stage 2, it checks for the existence of a cache file. This CACHE_TTL value is different across each version of each malicious package. Not by any significant amount, but rather this achieves the effect of breaking hash-based file caching and detection.

If it's happy that there is no cache, then it picks the payload.

const PLAT_TABLE = {  
"darwin/arm64": "darwin",   
"freebsd/x64": "linux_x64",  
"linux/arm64": "linux_arm64", 
"win32/x64": "win32",  
"linux/x64": "linux_x64",   
"win32/ia32": "win32",  
"darwin/x64": "darwin",     
"linux/arm": "linux_x64"
}

Eight entries, four outcomes. Somebody thought about FreeBSD. Somebody thought about 32-bit Windows. I approve of this attention to detail.

The domains are next, and this is the first thing that actually looks like hiding.

const _ORIGINS = [
  ["oob-worker.","cf102-b","af.workers.de","v"].join(""),
  ["oob-worker.cf101-adf.workers",".de","v"].join(""),
  ["oob-worker.cf99-9b3",".workers.","de","v"].join("")
];

Three Cloudflare Workers, each chopped into pieces and glued back together at runtime. The split points are different for each one, and different in every package in the campaign.

const _FALLBACK_RESOLVERS = {
  linux_x64:   ['sdk.dl.wel1.r','u'].join(""),
  linux_arm64: ['ext','.dl.wel1','.ru'].join(""),
  darwin:      ['pk','g.dl.wel1.ru'].join(""),
  win32:       ['net.','dl.wel1.r','u'].join("")
};

That is the whole reason I am writing this. wel1 survives every split. It is the one string the obfuscation never breaks, and it's how I found the campaign in the first place. Thank you, wel1.ru.

The DNS payload fetching logic is also pretty cool. In case the victim environment can't just grab the binary it queries 0.<domain>, 1.<domain>, 2.<domain> in batches of ten, concatenates every TXT record it gets back, and base64-decodes the result into a binary.

Now we are in stage 2 territory. I decided to look at the Windows build, because I've done Windows malware analysis before, I know it will run in a sandbox, and my sandbox can't run exes, so over-enthusiastic analysis won't get me popped.

The binary is packed, so anyway - I started running strings.

Anti EDR, Anti-Anti-Malware, Anti-Analysis, Anti-Debug, and a list of usernames that if logged in – shouldn't execute the malware.

We see similar techniques in the Linux and MacOS payloads too, infact we also see persistence methods implemented to cover all OS cases across the payloads.

On Windows it is a scheduled task named \Microsoft\Windows\Multimedia\SystemSoundsService, triggered on logon, running with highest privileges, with the binary dropped to %APPDATA%\Microsoft\Windows\Themes\SystemSoundsService.exe.

Plus an HKCU Run key. Plus a mutex.

Now, i want to start looking for the C2, or a further stage. But strings isn't giving me anything.

I've seen enough malware to know, that it has to phone home to something, somehow. Otherwise, what's the point?

The stage 1 JavaScript hid its domains by chopping them into array fragments. That was a source-level trick and it does not port to a compiled binary.

The usual equivalent is an XOR, and the usual XOR in something this size is a single byte. There are only 255 of them.

for k in range(1, 256):
    if bytes(c ^ k for c in b"workers.dev") in data:
        print(hex(k))

ox9c. Hello friend.

This revealed to me 5 new Cloudflare worker URLs

package-proxy.cf5oobworker[.]workers.dev
package-proxy.cf6oobworker[.]workers.dev
package-proxy.cf7oobworker[.]workers.dev
package-proxy.cf8oobworker[.]workers.dev
package-proxy.cf11oobworker[.]workers.dev

The other three builds hide the same table with different keys — 0x31 on Linux x86-64, 0x0e on Linux arm64, 0x9c on both macOS and Windows.

We also get 3 non-Cloudflare c2 URLs

nexus.tcsbank.ru
repo-linux.tcsbank.ru
alertmanager.cloudpayments.ru

An internal Nexus artifact repository. An internal Linux package repository. An Alertmanager instance. tcsbank.ru is Tinkoff Credit Systems, now T-Bank. cloudpayments.ru is a Russian payment processor.

The stage 2 binaries reference 3 more paths on those same worker URLs.

/pkg/beacon_linux.bin    5,131,004 bytes
/pkg/beacon_mac.bin     13,292,768 bytes
/pkg/update_win.exe     10,315,776 bytes

These are much larger binaries than anything we've seen so far, so I know I'm on the right track.

I went with Linux, for boring reasons.

The Windows one turns out not to be encrypted at all , so there is no puzzle there to solve.

That leaves the macOS and Linux payloads, both of which come down as opaque data. Linux is the smaller of the two by a factor of three, and I am sitting in front of a Linux box with some tooling ready to go.

I didn't actually have to work very hard for the key, because I had already found it earlier, when I XORed the table. I had initially thought those random bytes between the domains were garbage noise.

53865775268105af2a6edf31c261ab40007515d107a812687b326fd7636f2726

Testing it costs one comparison. We know the binary has to start with an ELF header, 7f 45 4c 46. So decrypt four bytes and look.

Happy days. The binary itself is mangled and we don't have any build symbols and other info. But with Go, we do have the protobuf message types names. Which is to say that we know the methods this implant has available to it.

That is Sliver C2. The thinking threat-actor's Cobalt Strike, and in this economy the financially responsible threat-actors' too.

https://package-proxy.cf19-427.workers.dev
dns://pkg.wel1.ru

Another Cloudflare Worker URL, again, independent from the other batches we have seen in the earlier stages.

Since it is stock Sliver, the capability list is not a guess.

File upload and download. Arbitrary command execution. In-memory .NET assembly execution. DLL sideloading. Screenshots. Process dumping, which means LSASS.

Windows token theft and impersonation. Registry read and write. Port forwarding and SOCKS. SSH command execution.

Somebody out there really really wants to be inside Russian financial institutions.

We've seen the malware, we've seen the packages, but does the infrastructure tell a story too?

Start with the domain. Whois says it was registered on the 1st Jan this year.

The web hosting seems to be a fairly standard Russia-based ISP.

The Cloudflare worker URLs are revealing too.

A workers.dev hostname is <worker-name>.<account-subdomain>.workers.dev. Split the eleven hostnames we've collected that way:

stage 1,oob-worker:cf99-9b3, cf100-416, cf101-adf, cf102-baf, cf103-070
stage 2,package-proxy:cf5oobworker, cf6oobworker, cf7oobworker, cf8oobworker, cf11oobworker
stage 3,package-proxy:cf19-427

Eleven separate Cloudflare accounts, and they're numbered 2 different way. The second I can't guess. The first I absolutely can.

Cloudflare hands you a free oracle. An account subdomain that exists answers NOERROR, one that doesn't answers NXDOMAIN.

cf103-070.workers.dev                 status: NOERROR
definitelynotreal-zzz9q8.workers.dev  status: NXDOMAIN

So I enumerated cf1oobworker through cf200oobworker.

cf5   cf6   cf7   cf8   cf9   cf11  cf12  cf13  cf15  cf16
cf64  cf65  cf66  cf67  cf68

Fifteen accounts. Five are in the malware. Ten are in not of the 1,046 samples I have. As far as I can tell, the ones that aren't in the packages we found and aren't serving malware are currently serving interaction loggers, a bit like Burp Collaborator or interactsh.

cf5 cf6 cf7 cf8 cf9 cf11 cf12 cf13      5 July 2026   all inside 14 hours
cf15 cf16 cf19-427                      6 July 2026
cf64 cf65 cf66 cf67 cf68               15 July 2026
cf99 cf100 cf101 cf102                 17 July 2026
cf103                                  22 July 2026

Cloudflare also issues Let's Encrypt certificates for all worker URLs, while these only last 90 days by looking at the Not Before dates we know that these workers have been live since at-least July of this year.

My investigation ends here, if you've made it this far thank you for reading. Be sure to leave a comment with your thoughts wherever you found this, and check out some more from veryserious.systems. Below is (as far as I'm aware) a complete list of IOCs.

IOCs and items of interest

Tria.ge link for all payloads: TRIA.GE

Stage 1 — Cloudflare Workers

Stage 1 — DNS-over-TXT

Stage 2 — domains

package-proxy[.]cf5oobworker[.]workers[.]dev
package-proxy[.]cf6oobworker[.]workers[.]dev
package-proxy[.]cf7oobworker[.]workers[.]dev
package-proxy[.]cf8oobworker[.]workers[.]dev
package-proxy[.]cf11oobworker[.]workers[.]dev
dl[.]wel1[.]ru

Stage 3 — domains

package-proxy[.]cf19-427[.]workers[.]dev    HTTPS
pkg[.]wel1[.]ru                             DNS

Victim hostnames compiled into stage 2

nexus[.]tcsbank[.]ru
repo-linux[.]tcsbank[.]ru
alertmanager[.]cloudpayments[.]ru

Nameservers

wel1[.]ru           ns1[.]jino[.]ru  ns2[.]jino[.]ru  ns3[.]jino[.]ru  ns4[.]jino[.]ru

URL paths

/pkg/package              stage2 linux_x64
/pkg/package-arm64        stage2 linux_arm64
/pkg/loader_mac           stage2 darwin
/pkg/package.exe          stage2 win32
/pkg/beacon_linux.bin     stage3 linux, RC4
/pkg/beacon_mac.bin       stage3 darwin, RC4
/pkg/update_win.exe       stage3 win32, plaintext UPX PE

DNS-over-TXT protocol

c.<domain>        TXT -> chunk count
0.<domain>        TXT -> base64 chunk 0
1.<domain>        TXT -> base64 chunk 1
...               queried in batches of 10, concatenated, base64-decoded

Binary hashes

Crypto — stage 2 config XOR

Crypto — stage 3 RC4

key      53865775268105af2a6edf31c261ab40007515d107a812687b326fd7636f2726
mode     RC4, no drop-N, no nonce, no IV, no header, ciphertext from byte 0
location stage2 config table, offset 0x5860 in macOS build after XOR 0x9c
decrypts beacon_linux.bin -> UPX-packed ELF
fails on beacon_mac.bin (separate key, not located)

Crypto — non-indicators

expand 32-byte k   ChaCha20 sigma, present in linux builds only, belongs to the
                   statically linked TLS stack, not the payload cipher

Host artefacts — stage 1

/tmp/.analytics_state                       run-once stamp, POSIX
%TEMP%\analytics_state                      run-once stamp, windows, no leading dot
/var/tmp/.cache_<8 hex>                     dropped stage2, POSIX
%TEMP%\dotnet_diag_<8 hex>.exe              dropped stage2, windows

Host artefacts — stage 2 linux

/usr/lib/.cache/ksoftirqd                   implant binary
/usr/lib/.cache/
~/.config/systemd/user/dbus-broker.service  Description=D-Bus Broker
~/.local/share/dbus-1/.dbus-daemon
/etc/init.d/ + rc-update                    Kernel softirq processing helper
/etc/local.d/
crontab @reboot
[kworker/0:1-events]                        argv[0] masquerade

Host artefacts — stage 2 macOS

~/Library/LaunchAgents/com.apple.windowserver.helper.plist
~/.local/share/runtime/com.apple.runtime    payload
~/.local/share/runtime/.lock
launchctl load -w                           RunAtLoad, KeepAlive, ThrottleInterval 60

Host artefacts — stage 2 windows

%APPDATA%\Microsoft\Windows\Themes\SystemSoundsService.exe
\Microsoft\Windows\Multimedia\SystemSoundsService   scheduled task, ONLOGON, /RL HIGHEST
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
Global\{7A3B9E1F-C2D4-4F8A-B5E6-D7A1F0C3E2B9}        mutex

User agents

node-fetch/2.6                                                stage1
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)               stage2 darwin
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36  stage2 win32
Mozilla/5.0                                                   stage2 linux, HTTP/1.0

Windows — username blacklist

malware      virus        sample       test         admin
user         john         CurrentUser  TESTBOX      hapubws
timmy        milozs       Hong Lee     IT Admin     Johnson
Miller       Peter Wilson

GetUserNameA + _stricmp, contiguous null-terminated table

Windows — EDR/AV process names

CSFalconContainer   csfalconservice    SentinelAgent.exe   SentinelHelper
MsSense.exe         SenseIR.exe        SenseCncProxy.exe   SophosAgent.exe
ds_agent.exe        coreServiceShell   cylancesvc.exe      kavfs.exe
bdagent.exe         xagt.exe           hmpalert.exe        taniumclient.exe
wazuh-agent.exe     elastic-agent.exe  elastic-endpoint    filebeat.exe
winlogbeat.exe

CreateToolhelp32Snapshot + Process32NextW

Windows — API evasion

amsi.dll / AmsiScanBuffer                     AMSI patch, dynamically resolved
ntdll.dll / EtwEventWrite                     ETW blinding, dynamically resolved
NtQueryInformationProcess                     ProcessDebugPort / ProcessDebugFlags
IsDebuggerPresent
CheckRemoteDebuggerPresent
GetThreadContext                              hardware breakpoints
SYSTEM\CurrentControlSet\Services\Disk\Enum   VM disk strings
GlobalMemoryStatusEx / GetDiskFreeSpaceExW    resource checks

Linux — container detection

/.dockerenv          /run/.containerenv   /proc/1/cgroup
kubepods             containerd           docker
KUBERNETES_SERVICE_HOST

macOS — anti-analysis

ptrace PT_DENY_ATTACH                  sysctl / sysctlbyname
debugserver          dtrace            frida
/Applications/VMware Fusion.app
/Library/Application Support/VMware Tools
/usr/local/bin/wireshark
hw.memsize                             low-RAM check
http://127.0.0.1:4444/health           interception-proxy probe

Generator — dropper filenames

_adapter.js         _bootstrap.js       _bridge.js          _compat.js          _ext.js
_helpers.js         _init.js            _loader.js          _platform.js        _polyfill.js
_runtime.js         _shim.js            _support.js         _vendor.js          setup.js

Generator — TTL constant names

CACHE_TTL  COOLDOWN  EXPIRE_SEC  MAX_AGE  STAMP_TTL  TTL

Generator — TTL values

range     19,805 - 23,399 seconds (5.50 - 6.50 hours)
mean      21,643
distinct  910 across 1,046 packages
expected  908 if uniform over the range

Detection — structural markers

try { require("./_<name>"); } catch (_) {}     tail of index.js, result unused
["a","b","c"].join("")                        1-9 fragments, yields a hostname
statSync(<tmp>/.analytics_state) vs 19800-23400s   run-once gate
DISABLE_TELEMETRY / ANALYTICS_OPT_OUT / DO_NOT_TRACK
spawn(..., {detached:true, stdio:'ignore'}).unref()

Detection — garbled Sliver protobuf names

SideloadReq    SpawnDllReq     ScreenshotReq   InvokeMigrate   ProcessDump
RegistryRead   MakeToken       ImpersonateReq  PivotPeer       PivotPingWaitDelay
ExecuteAssembly                SSHCommand      BeaconTasks     BeaconRegister

Publishers

cl648b5qjmh1      0 packages as of 2026-08-05
z34itea6zf7x      0 packages as of 2026-08-05

Version distribution

Two-step publishes

a.poltoradnev-package-b                     0.0.2 -> 33.9.1
a.poltoradnev-package-c                     0.0.2 -> 33.9.5
aasp-tent-aasp-tent-core                    0.0.2 -> 33.4.6
accounts-appointment                        0.0.2 -> 33.2.6
accounts-card-design-picker                 0.0.2 -> 33.5.1
accounts-constants                          0.0.2 -> 33.1.7
accounts-ddos-shield                        0.0.2 -> 33.3.8
accounts-forms                              0.0.2 -> 33.2.6
accounts-limits                             0.0.2 -> 33.6.6
beaver-ui-breadcrumbs                       0.0.2 -> 33.1.6

dropper payload byte-identical across both versions in every pair

Acquisition timeline

Scopes

Reproduction

python3 tools/harvest.py <archive-data-dir> campaign --workers 12 --max-mb 8
python3 tools/workers.py campaign
python3 tools/deobf.py stage2_win32.bin 0x9c 0x90c0 0x9220
python3 tools/deobf.py stage2_mac.bin   0x9c 0x5850 0x5890
python3 tools/build_iocs.py . IOCS.md

Packages — 1,046 versions

W = stage1 Workers embedded (99, 100, 101, 102, 103)
ttl = run-once window, seconds
machine-readable: iocs-packages.csv