The Flooder Next Door: DEDIK and the Harvest at Flood Velocity

TI-2026-082E · The Tripwire Ledger, Part E Confidence: HIGH — behaviour and infrastructure documented across web telemetry, RIPE registration, and reputation feeds; the cluster tie to the EMBNEX neighbourhood is stated at MEDIUM Classification: TLP:WHITE

The tool that found its own subject

The first four parts of this series read the router's ledger — the auto-ban lists nobody thinks of as intelligence — and pulled two costumed scanners and their broker out of the noise. Between Part D and this one, that reading was made permanent: the router's ban-lists were wired into the enrichment graph, each list stamped with a signal type describing what it detects — router-recon, dos-l4, spam, and, for the application-layer flood rule, dos-l7.

The morning that enrichment went live, the signal type dos-l7 did not exist in our data. By afternoon it did — and the first question anyone asks a new lens is what does it show me that I could not see before? One query against signal:dos-l7, sorted by threat, returned a top row that was not in the corpus at all: a host we had never profiled, globally reported by hundreds of organisations, sitting one street over from the very broker neighbourhood Parts A–D mapped. The lens found its own subject on the first look.

This dossier is that subject — AS209413, DEDIK SERVICES LIMITED — and it is two things at once. It is a forensic profile of a novel actor. And it is the proof-of-work for the whole series' thesis: the router's ban-lists, once enriched, are a discovery surface, not a dead pile of blocked addresses.

What tripped the flood alarm was a harvest

Start with the behaviour, because it reframes the category the tripwire assigned.

DEDIK reached this estate not through the router's management ports (the door that caught Parts A and B) but through the web edge. Two of its addresses — 151.243.150.222 and 151.243.150.23 — each did the identical thing on a single day (.23 on 2026-06-04, .222 on 2026-07-08): 300 requests across roughly 150 distinct paths, all aimed at one host, in a burst. Not 150 tries at one door. One try each at 150 different doors, hammered fast.

And the doors are unmistakable. They are a credential-file wordlist:

/.env      /.env.1     /.env.2      /.env.bak    /.env.bak~   /.env.backup
/.aws/config    /.aws/credentials    /.docker/.env    /.dockerenv
/.circleci/config.yml    ... (≈150 secret-file variants)

The classifier read it exactly right: credential_harvest, user-agent class bot, cadence burst, effective-bad-rate 1.0 — every single request hostile, not one legitimate. This is the doctrine documented in The Harvest (079) and The .env Harvesters (046A): sweep a host for exposed secrets — cloud keys, Docker envs, CI config — grab whatever leaked, move on.

So here is the twist that names this dossier. DEDIK did not appear on signal:dos-l7 because it launched a volumetric denial-of-service. It appeared there because it harvested credentials so fast that the request rate tripped the router's application-layer http-flood rule. The flood alarm did not catch a flood. It caught a harvester moving at flood velocity — and that is a more useful catch, because it means the L7-flood tripwire is quietly a second net under the credential-harvest economy. A greedy harvester betrays itself twice: once to the intent classifier, once to the rate limiter.

AS209413, or: the host that is three countries

Now the identity, and it wears the exact costume Parts A and B taught us to distrust.

DEDIK SERVICES LIMITED operates AS209413 and fronts the domain dedik.io. It is tiny — the whole autonomous system announces just two /24 prefixes. And across those two prefixes it cannot keep its story straight about where it is:

• 151.243.150.0/24 — RIPE inetnum country DE (Germany), org ORG-DSL57-RIPE, maintainer netutils-mnt.
• 176.65.144.0/24 — netname DEDIKIO, inetnum country CH (Switzerland), but the org-name record gives country GB (United Kingdom), maintainer MNT-ZEXOTEK.

DE, CH, and GB — three jurisdictions across two /24s from one holder. This is precisely the triple-mismatch that unmasked VASH KREDIT (DE/AE/UA, Part A) and VPSVAULT (GB/SC/US, Part B). No single mismatch proves anything; geography is imperfect and companies incorporate abroad. But a two-prefix host that claims three countries is not a company with an unusual footprint — it is a brand laid over brokered address space, and the registration is the tell.

The rest of the costume matches, piece for piece:

• dedik.io was registered 2025-05-23 — roughly two months before the harvest we observed — through the registrar Spaceship, with the registrant shielded behind "Withheld for Privacy ehf" (the Icelandic privacy front). A fresh, anonymous brand.
• The 176.65.144.0/24 maintainer is MNT-ZEXOTEK — Zexotek, a maintainer associated with abuse-tolerant allocations. The registry-level custodian of the space is itself a known quantity.
• Its two BGP upstreams are AS197071 (ACTIVE-SERVERS / active 1 GmbH, Germany) and AS43440 (Digitale Suisse AG, Switzerland) — a German and a Swiss budget host. That pairing explains the DE/CH split: the geography isn't a real dual-home, it's an artifact of which cheap transit DEDIK bought.

Clean brand, offshore privacy front, abuse-tolerant maintainer, laundered geography, tiny brokered footprint. If you have read Parts A through D, you have seen this outfit before.

Next door to the wardrobe

You have not just seen the outfit — you have seen the street. DEDIK's two prefixes sit in the two broker neighbourhoods the earlier parts mapped, and that is the finding that makes this Part E rather than a standalone.

The 176.65.144.0/20 neighbourhood. DEDIK's 176.65.144.0/24 is one slice of a /20 that is carved among a crowd of small ASNs — and the immediate neighbours include Pfcloud (AS51396) holding 176.65.148, .149, .150, .151. Pfcloud is not a stranger: it is a tenant in the Part D costume catalog, and VPSVAULT's own router-tripwire hits (Part B) landed on 176.65.149.x. DEDIK rents a room on the same corridor as the EMBNEX catalog's tenants.

The 151.243.0.0/16 range. DEDIK's other prefix, 151.243.150.0/24, shares that /16 with VASH KREDIT's 151.243.11.0/24 (Part A) and with Meteor Cloud (AS210554) at 151.243.24.0/24 — Meteor Cloud being one of the nine EMBNEX tenants in Part C's foundry. Two of DEDIK's closest neighbours in this /16 are catalog members.

The allocation block. DEDIK's AS209413 and VASH KREDIT's AS209630 are both minted from the RIPE 209308 autonomous-system block — adjacent AS numbers from one issuance window.

Now the honest limit, stated plainly. None of this proves DEDIK is operated by the same hands as VASH KREDIT or the EMBNEX tenants. A shared /16, a shared /20, an adjacent AS number, and an identical costume template are provenance and neighbourhood, not a single operator. What they establish, at MEDIUM confidence, is that DEDIK was provisioned from the same broker-adjacent pool and follows the same doctrine — a new costume from the same wardrobe, not necessarily the same body wearing it. That distinction is the whole discipline of this series: name the association, size it correctly, and stop there.

Why the L7 tripwire is the story

Part A's actors were caught by the management-port tripwire — they touched the router and nothing else. DEDIK is different: it reached Traefik (600 requests), left zero SSH-honeypot sessions, and appears on the http-flood and crowdsec-blacklist lists, not mikrotik-attack. A different door, a different alarm.

That difference is the point of Part E. The series' method — read the router's ban-list as a sensor — was proven in Parts A–D on the management-port list. DEDIK proves it generalises to the other auto-ban lists. Once every list carries a signal type and its members are enriched into the graph, the application-layer flood list becomes a discovery surface too — and the first thing it surfaced was a globally-reported, corpus-absent harvester sitting next door to the wardrobe we already knew. The router keeps several ledgers. This series started reading one of them. Part E is the moment a second ledger paid out.

And it paid out with something the management-port lists structurally cannot show: an actor that engages the application. The recon actors of Parts A/B never touched a real service; DEDIK went straight for the secrets. The L7 tripwire, read as intelligence, catches the class of attacker the recon tripwire never sees — the one that skips the reconnaissance and just grabs.

The honest ledger

Three limits, stated up front, as every part of this series has:

• DEDIK is provably a novel, globally-reported credential harvester on brokered, laundered space — that is HIGH confidence, resting on the web telemetry, the RIPE registration, and 869 AbuseIPDB reports from 490 organisations.
• Its tie to the EMBNEX cluster is neighbourhood and provenance, not a proven shared operator — MEDIUM confidence. The /16, the /20, the RIPE block, and the costume template converge well past coincidence, but routing adjacency is not a single hand, and we do not claim one.
• No individual is named. The privacy front, the abuse-tolerant maintainer, and the offshore registration exist precisely to prevent that, and inventing a name would betray the method. What we characterise is a trade and a provenance, not a person.

What survives all three is the load-bearing claim: a novel harvester, moving fast enough to trip the flood alarm, was found by the enriched router ledger, in the same neighbourhood as the costume catalog.

The translation, for everybody

Across this series, you put a silent alarm on your back service-panel and caught two burglars casing it — both with vans rented from the same yard. This one is different, and it shows why it was worth wiring all your alarms into one board, not just the back-panel one.

This time the alarm that went off wasn't the back panel. It was the one on your front door that trips if someone rattles the handle too many times too fast. And when you looked, it wasn't someone trying to break the lock by force — it was a man who ran down your whole street trying 150 different mailboxes in under a minute, checking each for a spare key someone left inside. He moved so fast the "someone's pounding the door" alarm fired. But what he was actually doing was robbing mailboxes at a sprint.

You look him up: hundreds of your neighbours have reported this exact man. His van says DEDIK and claims to be from three different countries at once, and it's parked — of course — on the same block as the rental-yard vans from the earlier chapters. You'd never profiled him, because he never touched your back panel; he came at the front, fast, and only your newest, freshly-wired alarm caught him.

You didn't need his name; the alarm already locked him out. What you learned is worth more than a name: the fast-rattle alarm on your front door is quietly also a mailbox-theft alarm — and the man it caught lives on the street you were already watching.

The Tripwire Ledger — Part E

A novel host, three claimed countries, two prefixes, one two-month-old privacy domain — sprinting through 150 secret-file paths fast enough to trip the flood rule, caught by an enrichment shipped that same day, standing next door to the EMBNEX wardrobe of Parts A–D. The harvest, run at flood velocity. The ledger, read from a second page.

The Tripwire Ledger continues. Every alarm the router keeps is a sensor — you only have to wire it in and read it.

The series

Cross-references

• TI-2026-082A / 082C / 082D — VASH KREDIT (shared /16 + RIPE block), EMBNEX, and the costume catalog (Pfcloud, Meteor Cloud) DEDIK neighbours.
• TI-2026-079 / 046A — The Harvest / The .env Harvesters — the credential-file-sweep doctrine DEDIK executes at flood velocity.
• TI-2026-066E — The Bulletproof Midtier — reading laundered hosting by its routing neighbourhood and maintainer rather than its registration.

This dossier documents a novel credential-harvesting host for defensive purposes. Behaviour and registration are stated at HIGH confidence; the tie to the EMBNEX neighbourhood is provenance/adjacency at MEDIUM confidence and is expressly not a claim of shared operation. No individual is named. DEDIK SERVICES LIMITED, its upstreams, and MNT-ZEXOTEK are treated as network identities; the upstreams are named for routing accuracy with no implication of wrongdoing. TLP:WHITE.