ORB Networks Put the Exit Node in Your Metro Area. Your Geofence Was Never Going to Catch It

The uncomfortable thing about an operational relay box network is that the IP hitting your Citrix appliance may be a real residential broadband subscriber. Not a leased VPS in a sketchy ASN you can drop at the edge. A home cable modem, or a compromised Ruckus access point or SOHO router a few towns over, recruited months ago and quietly relaying traffic for whichever China-nexus group rented the path this week. The source is legitimate. The geography is local. The reputation feed has nothing on it. And the node may age out in as few as 31 days — monthly rotation of a large fraction of infrastructure is a selling point ORB contractors compete on.

Mandiant put a name to the trend in May 2024, and the reporting since has only sharpened the picture. SecurityScorecard’s LapDogs writeup in June 2025 documented a network of 1,000-plus SOHO devices — about 55% of them Ruckus Wireless gear, plus a healthy chunk of Buffalo AirStation routers — running a Linux backdoor they called ShortLeash. PolarEdge, a parallel operation, ran north of 2,000 devices. These are not botnets in the DDoS-for-hire sense. They are espionage infrastructure: relay meshes built specifically to launder the traffic between an adversary’s command server and your edge, so that by the time anything lands in your logs it looks like it came from down the street.

If your detection program still treats adversary infrastructure as a list of bad IPs to block, ORB networks are designed to make that program produce zeros. Not because nothing is happening. Because the thing you’re matching on rotated out before you got the feed.

Why the usual controls miss this on purpose

Start with the architecture, because it explains every detection failure that follows. An ORB network has an Adversary Controlled Operations Server sitting in PRC or Hong Kong IP space, a relay layer of leased VPS that authenticates network users, a bulk traversal layer that does the actual obfuscation hops, and exit nodes that egress into your environment. The traversal and exit layers are the part you’ll ever see, and they’re built from two kinds of host: commercially leased VPS (the SPACEHOP/ORB3 model, where the top providers have included Tencent, Alibaba, OVH, and Stark Industries Solutions) and compromised end-of-life routers and IoT (the FLORAHOX/ORB2 model, which stacks a Tor layer on top of hacked routers for good measure).

The leased-VPS half you can sometimes catch with ASN hygiene. The compromised-SOHO half is the problem. Those exit nodes are residential and small-business broadband, and the operators pick them on purpose to be geographically near the target. That single design choice kills two controls at once.

Geofencing dies first. If your VPN appliance only accepts connections from inside the US and the exit node is a Spectrum subscriber in the same state as your headquarters, the geofence waves it through. Impossible-travel dies next, for the same reason — there’s no impossible velocity when the login originates 40 miles from the last legitimate one. Teams that built their identity detection stack around “alert when the account logs in from two countries an hour apart” find that ORB egress sails straight under it. The whole point of a regionally-placed exit node is that it produces a boring, plausible source.

Reputation feeds are the third casualty, and the most expensive one to keep believing in. IPv4 tenure inside these networks runs as short as a month. A threat-intel feed has to observe the node, attribute it, publish it, and get it into your blocklist before rotation — and that pipeline is measured in weeks, against an adversary who recycles in weeks. You will block IPs that stopped mattering before the indicator shipped. SI controls built on static IOC matching (SI-4, anything keyed to a CTI blocklist) degrade quietly here. They keep running. They keep finding nothing. The dashboard stays green.

Where the detection actually lives

You usually don’t detect an ORB from a single source IP in isolation. You either enrich that source against known ORB-network fingerprints, or — more reliably — you detect the session landing in your environment behaving in a way that account and that asset shouldn’t. At the L3/L4 source-IP layer the exit can look indistinguishable from legitimate residential traffic; the signal reappears higher up — in exposed services, account behavior, and asset context. It moved from the network identifier to the access context.

Three places to look, in rough order of payoff.

The edge-appliance management plane. ORB campaigns exist to reach internet-facing edge devices — VPN concentrators, ADCs, mail gateways, the boxes that get zero-days dropped on them. SPACEHOP was used against CVE-2022-27518 on Citrix ADC. So the highest-value detection isn’t on user auth at all; it’s authentication and admin activity hitting the management interface of your edge gear from a residential or SOHO ASN. A Netgear-class consumer router has no business being a client of your NetScaler admin plane. In Zeek terms you’re joining conn.log against an ASN enrichment and filtering destinations to your edge-asset CIDR, then asking which sources sit in broadband consumer ASNs. In Splunk, with an IP-to-ASN lookup table, it’s roughly:

index=netfw dest_asset_group=edge_mgmt
| lookup asn_lookup ip AS src_ip OUTPUT asn_class
| where asn_class="residential" OR asn_class="soho_isp"
| stats count values(dest) by src_ip, user

Note that asn_class isn’t something a stock IP-to-ASN feed hands you — it’s a derived tag you maintain (off MaxMind’s connection-type data or your own residential/SOHO ASN taxonomy); a plain lookup gives you a number and an org name, nothing more. That query will not be clean on day one. Read on.

TLS and service fingerprints — but mind the vantage point. This is the one piece of the ORB you sometimes can see, because the operators have to stand up a service to relay. LapDogs’ ShortLeash spun up a fake Nginx instance and locally generated a self-signed cert impersonating the LAPD — yes, the Los Angeles Police Department, which is how the campaign got its name. Each node minted its own certificate, but they all shared the same subject/issuer metadata and a common JARM (3fd3fd16...), and that shared pattern — not a single reused cert — became the tracking fingerprint across the network. (Its sibling PolarEdge actually did reuse one cert set; LapDogs didn’t, which is the more realistic case to plan for.)

The catch is where you can see it, and this is where two different vantage points get conflated. Run two separate fingerprinting paths and don’t mix them up. Active / CTI enrichment of a suspicious source IP — Censys/Shodan-style lookups, internet-telemetry feeds, your own scanning — is what surfaces the relay node’s exposed service, its LAPD-style x509 metadata, and its JARM; there you’re observing the ORB node as a server. Passive inbound TLS on your edge gives you something different: the client fingerprint (ja3/ja4 in ssl.log, if your sensor populates them) of the session landing on your appliance, plus your own server cert in x509.log. Do not expect the remote node’s LAPD certificate to appear in your inbound x509.log — it isn’t the server in that exchange. And any of this only works when the operator left a reused pattern exposed; mature provisioned networks won’t. Treat fingerprinting as high-value-when-it-hits, not a reliable tripwire.

Session behavior on authenticated access. Low-and-slow is the espionage tradecraft here, not smash-and-grab. Long-lived sessions to sensitive internal assets, originating from a source ASN that account has never used, is the behavioral tell that survives the geofence problem. The key field is per-account ASN novelty, not geography. Baseline each privileged account’s normal source ASNs over 60–90 days, then alert when an authenticated session to a crown-jewel asset comes from an ASN outside that account’s history — weighted up hard if the ASN is consumer broadband and the asset is an edge or OT jump host.

But ASN novelty is a scoring feature, not a security boundary. If the exit node lands in the same residential ISP or metro the account already uses, its ASN history won’t fire — the signal that holds up best is the session that doesn’t fit the account, device, and asset context together, not any single attribute. For privileged access, don’t lean on detection where you can avoid it: pair ASN novelty with device-trust / managed-device requirements, phishing-resistant MFA, PAM-only admin paths, and direct-management-plane deny rules. The strongest control isn’t “detect the residential ASN” — it’s never letting an arbitrary residential source touch edge management in the first place.

What the first week of tuning has to fix

Here’s the part the vendor blogs skip. Deploy the residential-ASN-to-edge query as written and you’ll drown, because a meaningful slice of your own workforce is on residential broadband. Comcast AS7922, Spectrum, AT&T consumer — every remote worker, every admin VPNing from home at 2300, every contractor on a home connection. Residential ASN by itself is not a signal. It’s the baseline condition of remote work.

So the first tuning pass is subtractive, and it’s mostly about what you join the ASN against:

• Scope the destination ruthlessly. Not “all internal assets.” The management plane of internet-facing appliances, OT jump hosts, and tier-0 identity infrastructure. If your CMDB asset tagging is garbage — and it usually is — this is the work that actually has to happen first, and it’s unglamorous enough that it gets deferred until an incident forces it.
• Baseline per account, not globally. The CFO logging in from a residential ASN is normal. A service account or an appliance-admin credential doing it is not. Peer-group the accounts and the false-positive floor drops by an order of magnitude.
• Carve out your sanctioned remote-access paths. If admins are supposed to reach edge gear only through a PAM jump host, then any direct residential hit on the management plane is interesting by definition, and the rule gets much tighter.

Expect the first week to be noisy until those carve-outs land. In a mid-size shop the unfiltered version of this can throw a few hundred hits a day; the scoped, peer-baselined version should settle into single digits a day, and the ones that remain are worth a human. If it’s still firing dozens of times a day after tuning, your asset tagging is wrong, not the logic.

Two more realities that change the answer depending on your environment. First, coverage: this detection assumes you have ASN enrichment in the index and NetFlow or firewall logs that actually capture source IP on the sessions you care about. Plenty of edge appliances log auth events without a usable client IP, or ship them in a format your ingest pipeline silently drops a field from. Verify the field is populated before you build the rule on it — stats count by src_ip and look for the blanks. Second, time skew: correlating an edge-device auth event against a NetFlow session means both sources need clean NTP, and edge appliances are notorious for drifting. A few seconds of skew turns a clean join into a miss.

Where it maps, and what to actually do

The control story here is less about adding new controls than about admitting the old ones were keyed to the wrong artifact.

That last row cuts both ways and it’s the one people forget. Your own end-of-life Ruckus access points and unpatched edge routers are exactly the recruitment pool these networks draw from. The same device class that relays an attack against someone else can be the foothold into you. These aren’t abstract supply-chain controls here; they’re “go find the EOL gear on your perimeter before someone enrolls it.”

Mandiant’s framing is the right one to adopt internally: stop treating ORB infrastructure as IOCs and start tracking each network as an entity with its own TTPs, the way you’d track an APT group. Practically, that means your threat-intel function tracks SPACEHOP and FLORAHOX and LapDogs as named adversary infrastructure with evolving characteristics — port patterns, hosting relationships, recruitment behavior — rather than as a churn of IPs that age out of a spreadsheet.

The blocklist isn’t dead because blocking is wrong. It’s dead because the adversary engineered the half-life of the thing you were blocking to be shorter than your ability to block it. Move the detection to where the behavior can’t rotate: the session, the account, and the asset it touched.

Sources

• IOC extinction? China-nexus cyber espionage actors use ORB networks to raise cost on defenders (Google Cloud / Mandiant)
• Unmasking a new China-linked covert ORB network: inside the LapDogs campaign (SecurityScorecard)
• Typhoon-like gang slinging TLS certificate ‘signed’ by LAPD (The Register)
• China-linked LapDogs campaign drops ShortLeash backdoor with fake certs (Hackread)
• Stealthy backdoor found hiding in SOHO devices running Linux (Help Net Security)
• Chinese ORB networks conceal APTs, render static IoCs irrelevant (Dark Reading)
• State hackers turn to massive ORB proxy networks to evade detection (BleepingComputer)
• Gonzo threat hunting: LapDogs & ShortLeash (Expel)
• It’s ORBin’ time: detecting covert relay networks in your telemetry (Matt Ryan)