SANS ISC posted a quick diary on June 1 flagging a fresh sample where an unidentified first-stage RAT drops NetSupport RAT. That’s the whole story, and that’s also the problem. Stage one has no vendor name, no family tag, no YARA rule shipped with your EDR. Stage two is a legitimate, signed, decades-old remote support product that half your help desk could justify on a Wednesday afternoon. This is the kind of two-step that quietly defeats most cybersecurity stacks while looking, on the wire and at the endpoint, like nothing in particular.

The interesting part lives upstream of NetSupport. We’ve been watching NetSupport get weaponized for years; what changes campaign to campaign is the loader in front of it, and how rarely defenders are equipped to deal with samples that don’t yet have a name.

What The ISC Sensors Actually Caught

The reported chain is unglamorous and exactly what most current intrusions look like. A first-stage binary executes from a user-writable path, beacons out, and pulls down NetSupport’s client.exe along with the standard client32.ini configuration file. The remote-control panel is operator-controlled. Persistence is whatever the loader bolts on, usually a Run key or a scheduled task. Once NetSupport is live, an operator has full GUI control, file transfer, command execution, and a session that looks indistinguishable from a normal remote support call.

What makes the diary worth reading is the framing: unidentified. ISC’s handlers know what NetSupport is. They don’t yet know what’s in front of it. That gap, between “we see something dropping a known tool” and “we have a family attribution for the something,” can last weeks. Sometimes the loader never gets named at all because the next campaign uses a recompiled variant before anyone bothers. The fingerprint your threat intel platform is waiting on may simply never arrive.

Why Unnamed Loaders Beat Most Cybersecurity Programs

Most defensive programs are built on names. EDR vendors ship detections for known families. Threat intelligence feeds are organized by actor and toolset. SOC playbooks reference MITRE techniques tied to specific campaigns. When the first stage doesn’t have a name yet, the entire downstream apparatus skids.

Your AV may flag the binary on a generic heuristic if you’re lucky. Your EDR’s behavioral engine might catch the LOLBin chain if the operator was sloppy. Your threat intel platform will return zero hits on the hash. Your IR team will spend the first two hours of the engagement trying to figure out what they’re looking at, instead of containing the box. Programs that treat vendor naming as a prerequisite for action are paying the dwell cost on every fresh loader, and operators have noticed.

The loaders themselves are usually trivial. A few hundred lines of C++ or Go, sometimes Nim or Rust if the operator is feeling fashionable. AES-encrypted blobs, a hardcoded C2, a download routine, and a process injection primitive. Anyone with intermediate skills can write one in an afternoon, and the cost of rebuilding from scratch every campaign is a few hours of compilation time. The cost to you, of waiting for someone to attach the right name, is the entire dwell window.

Why NetSupport Keeps Showing Up As Stage Two

NetSupport Manager is a perfectly legitimate commercial remote-administration product. It’s been around since the early 1990s. It has a signed installer, a stable file layout, and configuration via a plain-text INI file. None of that is malicious on its own. All of it is gold for an operator who wants persistent hands-on-keyboard access without writing custom C2.

You get the GUI a help-desk technician would expect. You get a transport that looks like remote support traffic. You get binaries that won’t be flagged as malware on most endpoints, because they aren’t malware on most endpoints. And you can throw away your loader between campaigns while keeping the same stage two, which is exactly why ISC keeps seeing it dropped by whatever the latest unnamed first stage happens to be.

This is the same defense-in-depth bypass story you’ve seen with ScreenConnect, AnyDesk, TeamViewer, Atera, and Action1. Trusted remote tools are the new dual-use category. The right question to ask is whether anyone at this company had a reason to run NetSupport on this host today, and whether your tooling can answer that question without paging a human.

Practical Detection And Response Steps

If you can’t wait for a vendor to give the loader a name, you need to build detections that don’t depend on one. Most of this is unglamorous behavioral work that pays off against any unnamed first stage that drops a commodity remote tool, which means it pays off against the next three campaigns too.

Treat the presence of any remote-support binary you didn’t deploy as a high-severity finding. That holds for NetSupport client.exe, and the same logic applies across the rest of the dual-use category. Build the inventory of what your help desk actually uses, then alert on everything else.

• Inventory every remote-control product authorized in your environment, by exact filename, hash, and install path. Anything outside that list is an incident, not a ticket.
• Alert on client32.ini creation or modification anywhere on disk. The presence of that file outside a sanctioned install is one of the cleanest NetSupport-abuse indicators available.
• Baseline outbound traffic to known NetSupport gateway IPs and the geolocations your business actually uses. First-seen destinations get a hold-and-investigate response.
• Block or alert on execution from user-writable paths for any binary that wasn’t deployed by your management tool. AppData, Temp, Downloads, and Public are not application directories.
• Tighten brute-force and credential-stuffing controls on every external auth surface. The unnamed loader has to land somewhere, and phishing-led credential abuse is still how most of these chains start.
• Reduce session and token lifetimes on identity providers so a stage-two foothold doesn’t translate into weeks of silent access.

On the response side, rehearse the case where stage one has no name. Your IR runbook should not require family attribution to authorize containment. Decide in advance what level of behavioral evidence triggers host isolation, credential rotation, and a network-level egress hold. Practice the tabletop where your threat intel team returns “no known family” and the SOC has to act anyway. Security hardening, threat detection, and incident response all bend around the same point: behavior is the trustworthy signal when the name isn’t there yet.

Sources

• Unidentified RAT pushes NetSupport RAT (SANS ISC)
• ISC Stormcast For Monday, June 1st, 2026