The Address Foundry: EMBNEX and the Minting of Disposable Identities

TI-2026-082C · The Tripwire Ledger, Part C Confidence: MEDIUM-HIGH — the broker structure and cone are documented at HIGH; the characterisation of the tenant cohort as a coordinated identity foundry is stated at MEDIUM with the limit made explicit Classification: TLP:WHITE

Follow the address, not the brand

Parts A and B ended on the same sentence, from two different directions. A "Ukrainian bank" and a "British hosting company" — no shared name, no shared jurisdiction, no reason any catalogue would file them together — turned out to draw their IPv6 from one parent block: 2604:be0::/32, held by an entity called EMBNEX, LLC. That was the thread. This dossier pulls it, and finds that EMBNEX is not a footnote to the two scanners. It is the thing they have in common, and it is the more important subject. The scanners are disposable. The foundry that stamps them out is not.

The method that got us here is worth stating plainly, because it is the whole point of the series: stop reading the paint on the van and read the rental slip. Names launder; jurisdictions launder; brands are printed in an afternoon. What does not launder cheaply is the block of addresses an operator has to route from, and the party who leased it to them. Cluster by that — by the /32 parent and the autonomous system that hands out its slices — and nine unrelated-looking identities collapse into one object you can actually watch.

What EMBNEX actually is

Strip the assumption that a company holding address space must be a hosting company, and look at what the registries say.

EMBNEX, LLC operates AS401661 (ARIN org handle EL-1179). Its registration is recent to the point of being remarkable: the autonomous system was registered on 2025-04-14, the org record ten days earlier, on 2025-04-04. At the time of this analysis it was roughly three months old. Its ARIN vCard carries no populated name or postal fields — an empty shell record. And in the entire global routing table it announces exactly one prefix: the IPv6 block 2604:be0::/32. Not a range of server subnets, not a data-centre footprint — one large IPv6 allocation and nothing else.

A three-month-old US LLC with an empty org record, holding a single /32 and no first-party services, is not a host. It is an address holder — and, as the routing shows, an address broker: it exists to subdivide and lease number resources and transit to others. That is not an accusation; it is a description of the only function the data supports.

The minting: one block, many costumes

Here is the foundry in operation. 2604:be0::/32 is not used as one network. It is carved into small more-specifics, each announced by a different downstream autonomous system:

2604:be0:ffe0::/48  ──▶  AS209630   "LLC VASH KREDIT BANK"   (Ukrainian bank)     [082A]
2604:be0:ffe1::/48  ──▶  AS210456   "EastCoastHost Ltd"       (Canada geo)
2604:be0:ffe2::/48  ──▶  AS210554   "Meteor Cloud LTDA"       (Brazil; +2 brands)
2604:be0:ffe5::/48  ──▶  AS267280   "Yellow Connect LTDA"     (Brazil)
2604:be0:fff0::/44  ──▶  AS215925   "VPSVAULT.HOST LTD"       (UK / Seychelles)   [082B]

Five /48-scale costumes, five separate ASNs, five unrelated brands — all cut from one broker's cloth. And the IPv6 delegations are only the visible seam. The broker's BGP neighbour graph widens the picture considerably: on the upstream (left) side EMBNEX takes transit from real carriers — Hurricane Electric (AS6939) and Lumen (AS3356) — and on the downstream (right) side it feeds a cone of at least nine small autonomous systems:

EMBNEX sits exactly where a foundry sits: between the legitimate carriers that provide the raw transit and the fleet of small, freshly-registered, differently-costumed shells that consume it. Hurricane Electric and Lumen are named here only for routing accuracy — they are the public on-ramps any customer may buy, and no culpability attaches to selling transit. The interesting party is the one in the middle that takes that clean transit and a block of addresses and turns them into nine interchangeable identities.

What the foundry actually produced, on us

Now the honest accounting, because forensics is worthless without it.

Of those nine tenants, exactly two have ever touched this estate: AS209630 and AS215925 — the bank and the vault of Parts A and B. Between them they account for the sixteen IPs on the router's mikrotik-attack tripwire (plus one subnet entry and one CrowdSec-blacklist hit) that opened this whole investigation. The other seven downstream ASNs — the Canadian "EastCoast," the run of Brazilian "LTDA" clouds — produced no observed activity here at all, and sampled addresses from their ranges carried no high AbuseIPDB reputation at the time of analysis.

State that plainly and resist the temptation to inflate it. EMBNEX is provably the root of two hostile campaigns against this estate, and the broker of at least seven more identities that we have not caught doing anything to us. The value of documenting the whole cone is not a claim that all nine are actively attacking. It is that the two which did establish a prior for the rest: they prove the foundry ships product that gets used for low-and-slow perimeter reconnaissance, wearing whatever brand is convenient. The other seven are therefore a watchlist keyed on provenance — worth flagging on sight, not worth convicting in absentia. Guilt-by-association is a real failure mode; the discipline here is to name the association and stop exactly there.

Why a foundry beats a scanner

The reason EMBNEX matters more than either scanner is a question of what is durable and what is disposable.

A tenant identity is disposable by design. VASH KREDIT BANK can be retired tomorrow; VPSVAULT.HOST can rebrand; a /48 can be handed to a tenth ASN with a fresh name and a clean reputation. Block the two IPs and the operation continues from the next costume, unblemished, because reputation is scored per-name and the name is new. This is the same structural problem the corpus has documented at the hosting layer (the bulletproof-midtier method of TI-2026-066E) and the platform layer (the accountability gap of TI-2026-078D): the enforceable unit keeps being smaller and more disposable than the operator.

The broker breaks that regress. 2604:be0::/32 does not rebrand. AS401661 does not get a fresh reputation every week. The foundry is the one stable object in a system engineered for churn — the point where all the disposable costumes are provably one supplier's output. That is why the right defensive key is the parent block and the cone, not the tenant string. You will never keep up with the costumes. You can absolutely keep a standing eye on the wardrobe.

This is not the same as "block the /32." A broker allocation can carry genuinely unrelated customers, and collateral matters; the two proven-hostile tenants do not by themselves justify blanket-blocking every future tenant. It is an argument for watching the parent — for treating any new perimeter event whose IPv6 traces to 2604:be0::/32, or whose ASN sits in the AS401661 downstream cone, as pre-suspect regardless of what brand it wears, and for enriching and reviewing it rather than waving it past on the strength of a clean-sounding name.

The honest limits

Three, stated up front:

• We do not name a human operator of EMBNEX. The org record is empty by design; ARIN registration does not expose a person; and inventing one would betray the method. What we characterise is a function — address-and-transit brokerage feeding a costumed cohort — not an individual.
• We do not claim the whole cone is malicious. Two of nine are proven against us; the rest are provenance-flagged. A legitimate small host can absolutely buy space from a broker that also serves bad tenants. The catalogue in Part D is a watchlist, and is labelled as one.
• "Foundry" is a characterisation, at MEDIUM confidence. The routing, the registration dates, the uniform hosting facade and the multi-brand-per-ASN behaviour are individually documented facts; that they add up to a deliberately assembled identity operation rather than an organically-grown reseller is an inference — a strong one, but an inference, and we mark it as such.

What survives all three caveats at HIGH confidence is the load-bearing claim: EMBNEX is the single shared root of the two scanners this estate caught, and the broker of a wider constellation of costumed ASNs. Everything actionable follows from that alone.

The translation, for everybody

In Parts A and B, two burglars with different words painted on their vans — BANK and VPS VAULT — kept trying the one back panel you'd wisely alarmed, and you noticed they'd rented their vans from the same yard.

This is the yard.

It turns out to be a three-month-old company with an empty office and one thing to its name: a big stack of licence plates. It doesn't drive anywhere or deliver anything. What it does is take those plates, split them into small batches, and hand them out to a rotating cast of one-man "moving companies," each with a freshly-painted van and a respectable-sounding name — a bank, a vault, an "East Coast" firm, and a whole row of look-alike outfits registered in Brazil. Two of those drivers have been caught trying your back panel. The other seven you have never seen do anything — they might be honest, they might just be waiting.

You can't memorise every new van; the yard prints a new name whenever it likes. But you can write down the yard. So the next time any van rolls up with plates from that one stack, you don't read the paint and wave it through — you check the plates, and you watch it. You will never keep up with the names. You only ever needed to keep an eye on where they come from.

The series

Cross-references

• TI-2026-082A / 082B — the two proven-hostile tenants that share the EMBNEX 2604:be0::/32 parent.
• TI-2026-082D — The Costume Catalog — the full nine-tenant constellation, mapped as a provenance-keyed watchlist.
• TI-2026-066E — The Bulletproof Midtier — the method of reading laundered hosting by its routing and provenance rather than its registration.
• TI-2026-078D — The Accountability Gap — the same regress (the enforceable unit shrinking below the operator) at the platform layer.

This dossier documents an address-and-transit broker for defensive purposes. Structural facts (registration, routing, allocations) are stated at HIGH confidence; the characterisation of the tenant cohort as a coordinated identity operation is an inference stated at MEDIUM, and no claim is made that every downstream tenant is malicious. No individual is named. Hurricane Electric and Lumen are identified as transit providers for routing accuracy only, with no implication of wrongdoing. TLP:WHITE.