FortiBleed from the Target Side: The Ecosystem [Part 2/3]

Part 2 of 3 · The Ecosystem. One dump, many operators, and a heartbeat that proves central control. Read Part 1: The Corpus first; continues in Part 3: What Stops Them .

Part 1 established the what: the spray is a stolen, cracked, organization-sorted credential dump being recycled — not brute force. This part follows that dump across the people spraying it.

The single most important upgrade over earlier snapshots of this activity: this is not one sprayer. The same FortiBleed-sourced corpus is being validated against our one honeypot, in parallel, by a competitive field of operator groups — several of which, as the sections below show, collapse into a single orchestrated fleet — on dedicated infrastructure. In the three-day cleartext window we counted 327 source IPs across roughly 25 networks and ~13 operator autonomous systems (the ~34,600-IP fan-out substrate is a 14th AS, but a delivery fabric rather than an operator) — the overwhelming majority small “bullet-proof”-style hosting allocations.

(ASNs only here; the per-CIDR network ranges are in the restricted edition.)

The Geo column is the BGP-announced / registrant country. As Part 3 shows, several of these operators are physically hosted in an entirely different jurisdiction — the announced geography is itself part of the concealment, so treat this column as where the address space is registered, not where the operator sits.

Three arrival waves

The operators did not all arrive together. They came in three distinct waves, separated by days of silence — each consistent with a separate consumer or distribution event deploying its own validation infrastructure at a different time.

• Wave 1 (June 3) — the heaviest and most organized: four clusters opened fire within twelve minutes of each other. Three of them — the bare-Mozilla/5.0 Linux sprayers carrying the rare 42,340 / window-scale-12 stack — are one operator wearing three different ASN masks (the evidence is two subsections down); the fourth is a ~34,000-IP botnet substrate that appears to hold the master list and feed the others. A Go HTTP client, a synchronized heartbeat, alphabetically-segmented credential assignments.
• Wave 2 (June 12) — a completely different operation: a mixed-stack cohort (not the Fleet’s uniform Linux image), rotating browser user-agents, and — unique in the dataset — discovering our addresses through its own internet scanning rather than a handed-down list. Credential-list overlap with Wave 1: ~0%.
• Wave 3 (June 15) — smaller, slower, targeted: a static fake-Chrome cohort on standard Linux, each member working a non-overlapping alphabetical segment of the list. One late arrival doubles as a vulnerability scanner, hunting /.env files alongside its credential spray.

The waves line up with campaign-refresh or target-list-distribution events [INF]: each looks like a moment when a fresh batch of FortiGate targets was pushed to a downstream buyer. The same dump, sold and re-sold, worked in parallel by competing validators — which is exactly why the credential lists overlap.

The proof they share one source

How do we know these operators are spraying the same stolen dump rather than independently scanning FortiGates? Because their credential lists overlap — heavily, and specifically. Of the 210,683 unique credential pairs we logged over the month, 88,825 (42.2%) were tested by two or more separate operators. Some of that is unremarkable — admin/admin showed up from nine different networks, admin/P@ssw0rd from seven. But the overlap is not limited to obvious guesses. Specific corporate credentials — a particular company’s own admin account paired with its real, idiosyncratic leaked password — appear independently from six different networks. A company-specific password string is not something two unrelated attackers arrive at by chance; its appearance across six independent operators means they are all reading from copies of the same extracted-config dump.

The operators are also not running the same software. By browser-string behavior they fall into at least three distinct cohorts: one sends a bare, truncated Mozilla/5.0 user agent (the bulk of the volume), a second sends a fixed, never-rotating fake Chrome string, and a third rotates through Windows/macOS/Linux browser strings to look less robotic. Different tools, different infrastructure, overlapping credential lists.

The operators, one by one

The ASN table is a roster; the behavior behind each entry is where the professionalism shows. The captured credential streams and passive fingerprinting let us profile the persistent validators individually. None is a person — we identify infrastructure (autonomous systems, rented VPS ranges), never a name — but each runs a recognizably distinct operation. (Where an operator “validated” or “landed” a credential below, our honeypot returned one of its controlled success responses — see Part 7; not one of them did anything with it.)

• The volume miners (AS211486 “the Fleet” and AS213474 — two ASN masks of the same orchestrated operator, per the rare-signature section). The two heaviest sprayers by raw count work enormous lists — tens of thousands of usernames each — at a steady cadence, POST /logincheck and nothing else: no VPN probe, no API call, no reconnaissance. Neither ever landed admin with a working password in our window; their lists are broad and stale. These are the enumerators — walk the whole dump, sell the hit-list downstream.

• The five-VM segmented validator (AS200730, Poland). One operator ran five IPs in lockstep, each spraying a non-overlapping slice of a single breach list — zero credential overlap between the five, the signature of one list deliberately partitioned across five workers. Passive fingerprinting shows five genuinely separate Linux VMs (five distinct TCP-timestamp clocks, not one NAT). The same /24 simultaneously runs SSH port-scanning from other addresses — a multi-protocol platform, web on one set of IPs and SSH on another. Some captured credentials carry Hashcat’s $HEX[…] hex-encoding, the literal output format of a cracking pipeline. The cluster paused over a weekend, then resumed with a fresh list segment — and that fresh segment produced its validations: all five successes fell inside a single fourteen-minute window on the first day back, one per IP, each against admin, each a rare non-dictionary password. That is the signature of spray, check results, load the winning batch.

• The two-tier cluster (AS205997, Kazakhstan). On one /24, two roles on two machines — a targeted validator (current-version Chrome UA, high-quality stolen credentials, several validations, then silence) flanked by volume sprayers (bare Mozilla/5.0, weeks of continuous low-value spraying, zero validations). The two roles even carry different TCP stacks. One operator, two job descriptions, split across hosts.

• The industrial two-ASN operator (AS209896 / AS201813, Moldova-linked). The most professionalized operation we saw: five IPs across two autonomous systems registered to the same entity, running in parallel — in one sampled hour both ASNs were active in 51 of 60 minutes, with requests landing in the same sub-second. The credential list is partitioned alphabetically by username across the workers: one IP grinds the “gf…” names, another “geo…”, another “hi…” — a single dictionary sharded across machines. The tool sends a hardcoded recent-Chrome UA that its Linux TCP fingerprint flatly contradicts. And it sleeps: a clean nightly silence from roughly 01:00 to 07:00 UTC every day, matching ordinary working hours in the operator’s likely time zone. Credential overlap across the two ASNs confirms the two “independent” networks are one hand.

• The list-refreshing operator (AS201002, Singapore). Two IPs in tight lockstep carrying a strikingly multinational corpus — usernames and passwords from real deployments across South Asia, Turkey, Spain, Vietnam and Italy, organization by organization. It went dark for five full days, then returned with a different batch that validated almost immediately — an operator topping up its list from a supplier between runs.

• The deterministic validating pair (AS202412). Two Linux VMs in rigid lockstep — one fires, the other follows 3–4 seconds later, on all 18 of 18 attempts without exception — a stagger too constant for a human: one controller driving two source IPs to spread per-IP rate. They concentrated on one password and its case-variants against the web login, and probed the SSL-VPN portal and the REST API (POST /api/v2/authentication, with a correctly-formed JSON body) once each — enough to show the tool is built to the FortiGate authentication contract, not a generic web scanner.

The sector-specialist (AS214403) and the re-validator (AS267784 / AS48721) are profiled separately — the first below, the second in Part 7. The throughline: these are not opportunists. They partition lists, segment infrastructure, schedule around business hours, refresh from suppliers, and tool specifically for FortiGate. That is what an industry looks like.

The supply chain, caught in motion

The 42.2% pair-overlap proves operators share lists; the timing of that overlap supports a distribution-chain model, not coincidence. Because we capture every submitted password in cleartext, we can watch a single rare credential travel from one operator to another over days. Track the credentials too idiosyncratic to be guessed independently — a phone number used as a password, a person’s name fused with digits and symbols, a company name stamped with a year — and a consistent pattern appears: the rare string shows up first at one operator, then days later at a different operator on an unrelated autonomous system.

A phone number or a personal password does not arrive at two unrelated operators by chance; the most parsimonious explanation is that both are reading copies of the same extracted-config dump [INF], handed to them — days apart — by a common upstream source. The trivial-word case shows the breadth of that distribution: one ordinary password (a common Spanish word for “temporary”) tested by eight separate autonomous systems across an eighteen-day span, the dump’s reach made visible through a single shared entry. This is a credentials supply chain with a measurable propagation delay — breach source → aggregator → parallel validators — observed at the validation edge, with the upstream handoff inferred from timing and overlap [INF].

Three tool families under the hood

Passive TCP fingerprinting sorts the validators into three distinct tool families — a second, independent axis of diversity on top of the three user-agent cohorts, and far harder to fake because it comes from the operating-system kernel, not a configurable string.

• The generic-Linux build. Most operators ride the ordinary modern-Linux defaults (receive window 64,240, window-scale 7, the standard Linux TCP-option order). On its own that is unremarkable, so we cluster these operators by their full fingerprint plus per-host timestamp clocks, not the window alone.
• The exotic-Linux build. A small set advertises a window of 42,340 with window-scale 12 — a tuned, non-default stack you essentially never see in the wild. That signature is effectively a serial number, and it is the subject of the next section.
• The Windows build. Two operators run a visibly different stack: the Windows TCP-option order (MSS first, then NOP-padded window-scale and SACK, with no TCP timestamps), window-scale 8, ECN negotiated — distinct from every Linux operator in the set. It belongs to exactly two of them: the re-validator (Part 7) and the sector-specialist below. A different operating system means a different toolchain.

Three kernels means at least three separate validation tools are being pointed at the same dump — independent corroboration, from the wire instead of the browser string, that this is a crowd of operators rather than one program.

One tool image, eight “independent” hosting providers

Passive TCP fingerprinting of the connecting hosts produces the strongest single piece of attribution in this dataset. Every TCP SYN advertises a receive window and a window-scale factor; the normal value for a modern Linux server is a window of 64,240 with a scale of 7 — we observed exactly that, boringly, from 1,057 unrelated IPs across 226 networks. But a small set of our sprayers advertised something you essentially never see in the wild: a window of 42,340 with a window-scale of 12. Window-scale 12 is not the default of any mainstream operating system; it is a tuned, idiosyncratic build. A signature that exotic is effectively a serial number.

That exact signature — window 42,340 with window-scale 12 — appears on fifteen IP addresses across eight autonomous systems. Three of those eight are the named heavy-volume networks; the other five are hosting providers that ASN and geography alone would never have linked to the campaign. (A note on rigor: the window 42,340 on its own is not rare — a different window-scale value on the same window carries hundreds of unrelated hosts — so the discriminating fingerprint is the full 42,340 / window-scale 12 combination, not the window size.) Multiple “independent” networks emitting that exact exotic stack is not coincidence. It is one operator’s tool image, redeployed across a rotating fleet of rented VPSs — stitching together providers that, by ASN and geography, look completely unrelated.

Two details close the loop. First, the IPs carrying that signature are the same IPs spraying credentials — the host that quietly maps targets and the host that validates passwords are the same machine, doing both jobs. Second, the fleet’s other fingerprints (randomised IP-ID, a distinct TCP-timestamp clock per address) show these are separate modern Linux VMs, not one box and not a botnet of compromised victims — exactly what a rented-VPS operation looks like. (A further slice of the broader spray arrives through tunnels — TCP MSS values as low as 1300, the fingerprint of WireGuard/IPsec/PPPoE encapsulation — so some operators add a VPN hop on top.) The marketplace is real, but passive fingerprinting shows several of its “independent” sellers are the same hand, and that hand both scans and sprays from a fleet of disposable VMs.

A byte-order mark from Notepad

The botnet substrate — the single autonomous system behind almost the entire IP count — left the most human fingerprint in the dataset. Its admin-password list, sprayed one password per disposable node, carries a UTF-8 byte-order mark (the bytes EF BB BF) glued to the front of its first password. The proxy nodes forward it verbatim, submitting the invisible marker as part of the credential. A byte-order mark on a text file is the residue of saving it from Windows Notepad in UTF-8. The delivery infrastructure is entirely Linux; the curation was done by a human on a Windows desktop who saved a wordlist and never stripped the marker. One node in that botnet had probed us four separate times across sixteen days — a different username each visit — before the list was updated to the working default, evidence that the wordlist is edited and re-pushed between runs. The operator’s workstation leaked through the encoding of their own password file.

One last detail underlines how targeted this is. The same honeypot also exposes an SSH service, hammered around the clock by a completely separate crowd — generic Linux brute-forcing, root-heavy, off-the-shelf Go tooling and the usual IoT-botnet defaults. The FortiBleed clusters want nothing to do with it: they touch only the FortiGate management port, never SSH. These are not opportunistic scanners spraying everything that moves; they are a single-purpose operation pointed at FortiGate management interfaces, working a FortiGate-specific credential list. The surgical focus is itself a signature.

The heartbeat that signals central control

One of the clearest signals hides in the least interesting-looking credential. A synthetic pair — a username and password that belong to no real organization and would never appear in a stolen configuration — is sent as the very first request by all twelve machines in the three-ASN Linux cluster, every time they start. Then it recurs periodically during the spray: a heartbeat, fired by all twelve nodes within the same minute (on one beat, twelve out of twelve fired in the same sixty-second window). The tool is checking that its connection works — an applicative liveness probe, not a credential being validated.

But the timing is the finding. Twelve IP addresses on three different autonomous systems, sending an identical synthetic credential within the same minute, several times over three weeks, is not coordination — it is one controller operating a fleet. These machines are not independent actors who happened to buy the same dump; they are the same operator’s VPS pool, orchestrated from a central point that pushes a target list, starts the spray, and fires a health-check beat at intervals. The three “different ASNs” are three invoices from three hosting providers, paid by the same hand.

And the heartbeat is not the only orchestration signature. The botnet substrate — the ~34,600-IP fan-out behind almost the entire IP count — runs its own. After three weeks spraying varied credential pairs, it switched (around June 21) to a single-target metronome: 270 fresh IP addresses, one admin password each, fired on a rigid ~17-minute beat, with two fresh IPs submitting the same password in lockstep before rotating out forever. Two of those nodes landed the working password thirteen seconds apart, from different countries — machines taking dictation from one clock. A twelve-node synchronized heartbeat in one operator and a 270-node metronome in another are two independent proofs of the same fact: behind the apparent crowd of scanners stand a few controllers driving disposable fleets.

External corroboration of our highest-volume cluster. The network we labelled the “Fleet” — AS211486, our top sprayer by volume — is independently identified as FortiBleed harvesting infrastructure. Recorded Future’s Insikt Group attributed an address inside AS211486 to the campaign (a different allocation within the same autonomous system), and a June 18 PwnDefend post corroborated the same address. Our heaviest validator sits, on third-party telemetry, inside confirmed FortiBleed plumbing — which anchors the cluster attribution.

Put together: the ecosystem around the FortiBleed credential dump has at least two layers. At the outer edge, genuinely independent operators — different tools, different credential slices, different infrastructure — consume the dump in parallel (the marketplace). At the core, what looks like multiple clusters is one operator running a centrally orchestrated fleet, disguised as independent scanners through multi-ASN hosting. The marketplace is real, but part of it is one large player wearing several masks.

A sector-specialist: a health-themed credential list

One operator stood out for a different reason — not volume, but specificity. A single IP on a German VPS ran a metronomic 3-request cycle every 20 minutes, 24/7, for 13 consecutive days: first a GET to the SSL-VPN portal (/remote/login), then the web admin login page (/login), then a credential POST to /logincheck. The cadence never varied — no bursts, no pauses, no weekday/weekend pattern. A steady, patient probe below any rate-limiting threshold.

What made it distinctive was the credential list. The usernames were alphabetical first names — the window we captured was the “C” segment (cassius, catherine, cecelia, cedric, celeste…). The passwords rotated through exactly four values, two of which read as health-themed; the other two were generic defaults (123, P@ssw0rd). Two themed passwords are not proof of anything — but the pairing reads less like a generic combolist and more like a list assembled with healthcare targets in mind. The dual-surface probing is deliberate: the operator wants either admin access (firewall control) or VPN access (network entry) — both valuable for ransomware against a healthcare target, where downtime is life-threatening and ransom payments are statistically more likely.

Zero successes, zero intrusion. We cannot prove a healthcare focus from two themed passwords. But if that reading is right, the implication matters: the FortiBleed dump would not be consumed as a monolithic list — it would be sliced by vertical and handed to operators carrying sector-specific lists. The possibility that the most ransomware-targeted sector has a dedicated, low-and-slow validation pipeline running against its Fortinet perimeter is worth flagging precisely because it would be invisible to any SOC that hunts by volume spike.

The assembly line

Pull back from the individual operators and the whole thing resolves into a four-stage division of labor — an assembly line for turning a stolen configuration dump into sellable, verified access.

1. Source. A breach-data aggregator compiles username/password pairs from compromised FortiGate configurations and cracks the hashes offline. We never see this stage directly, but it is stamped all over the corpus: Hashcat $HEX[…] artifacts, date stamps spanning 2013–2025, a multinational organizational spread, and — most humanly — a wordlist saved in Windows Notepad. This is the supplier.

2. Spray. The list is handed to volume operators who execute it industrially — partitioned alphabetically across workers, pre-segmented with zero overlap between VMs, fired at a fixed cadence below lockout thresholds, one credential per connection. This is the stage we see most of: tens of thousands of usernames ground against a single firewall by a fleet of disposable hosts.

3. Analyze (inferred). We do not observe this stage directly, but the gap between spray and validation demands it. The targeted validators do not run the full combo-list; they run a shorter, admin-focused one — and the specific credentials they confirm had already surfaced at other, unrelated operators five to six days earlier. Something is reading the fleet’s output, selecting the credentials worth a careful second look, and handing a curated short-list to a validator. Reinforcing it: one operator switched its entire strategy — from a slow one-password-a-day cycle to a full breach-dump corpus — immediately after its first success, as if a result had come back and changed the plan.

4. Validate, then vanish. The validator confirms the curated credentials with a patient, browser-like client, records each hit on its own infrastructure, and — the moment it has what it came for — goes silent, while the volume sprayers beside it grind on for weeks. The output is a catalogue of confirmed access, ready for sale.

Stages 2 and 4 we watched directly. Stage 1 we reconstructed from the corpus. Stage 3 we infer — but the inference is strongly supported by the evidence on either side of it. The takeaway for a defender is uncomfortable: the spray hitting your firewall is not the threat actor, it is the factory floor of one, and the product rolling off the line is your own credentials, verified.

Part VI — The victims, identified from their own stolen passwords

Because we capture the corpus in cleartext, the spray list itself is an intelligence product: every credential that carries an organization’s identity likely indicates exposure of a FortiGate-related credential set for that organization — confidence is highest for config-only artifacts (service accounts, FortiCloud tokens) and lower for ordinary email-style usernames. In the cleartext window we recovered 59 unique corporate-email usernames plus a large number of company-named accounts (the full 30-day restricted corpus is larger still — 779 email-identifiable accounts across roughly 246 domains). We have anonymized the organizations below; the specific names, addresses and (defanged) passwords are withheld from this report and can be made available to national CERTs on request if needed.

A few representative patterns, anonymized:

• A major South Asian telecom. More than a dozen branch-site codes, all sharing the same single-word password — the company’s own name. Systemic password reuse across branch-office firewalls: compromise of one device’s config exposed credentials for many others.
• Security companies and managed security providers. Several MSSPs and a couple of named cybersecurity firms appear in the corpus — organizations that manage other companies’ security. Their compromised FortiGate credentials are a potential pivot into client networks.
• Hospitality, agriculture, healthcare, manufacturing, ISPs and government. Hotel-admin accounts, an agricultural producer’s admin and contractor accounts, healthcare-provider mailboxes used as logins, plus a .gov mailbox — the spread mirrors FortiGate’s broad enterprise footprint.
• A network-config-management service account (the kind used by tooling like RANCID) — another account type that only exists inside a real device’s configuration.

The geographic concentration tracks FortiGate market share: heavy in Latin America, South Asia and Southeast Asia, with a long tail across Europe, the Middle East, East Asia, Africa and the Americas.

The presence of security vendors and MSSPs among the victims is the part defenders should sit up for. When the firewall credentials of a company that manages other companies’ firewalls are circulating in a validation spray, the blast radius is not one organization — it is everyone they protect.

Part VII — Validate and leave: the IAB fingerprint

This is the behavioral core of the report.

Our honeypot returned an authentic-looking successful-login response to 19 distinct attacker IP addresses — 25 times over the month, every one against the admin account. Not one of those 19 IPs followed up with an exploitation action. Eighteen of the nineteen never sent a single request to anything other than the login endpoint, despite hammering it thousands of times each (one logged 6,154 login attempts and not one other request); the lone exception, a residential IP, merely fetched the login page itself. There was no configuration download, no user enumeration, no firewall-rule query, no VPN-tunnel establishment, no session reuse — no post-access exploitation of any kind.

And not one of them is a browser. On all 19 we logged zero loaded assets — no JavaScript, no CSS, no image, no favicon — zero fetches of the Angular admin interface (/ng/), and zero follows of the success redirect; the method split is 64,640 POST against 6 GET. They are not browser-less by accident: they carry fake browser User-Agents (Chrome-on-Windows, Safari-on-Mac, Firefox-on-Linux) to slip naïve filters — but the disguise slips, leaking the real Go-http-client on a handful of requests. These are headless credential-stuffers in a browser costume. The tell is sharpest by contrast: the only session in 30 days that behaved like a human at a browser — loading the admin app, reading the device config and status — was our own quality-assurance traffic. The real operator with a browser comes later, after buying the validated access; the machines we watched were never that operator.

That pattern — authenticate, ignore, continue — is strong evidence for the IAB credential-checker model [INF]:

• The tool records successes on the attacker’s side, not by interacting with the device. The validated credential is logged on their own infrastructure for later sale or use by a separate team.
• Validation and exploitation are decoupled. The checker’s only job is to find out which passwords still work. Someone else — a ransomware affiliate, an espionage operator, a data broker — returns later, armed with validated access.
• For the business model, proof is sufficient. The buyer will do their own verification; the checker has no reason to touch the box.

We see the same thing on our other honeypots: credential sprayers that succeed authenticate, do nothing, and disconnect. Validate-and-leave is a reliable IAB signature wherever it appears.

The exception that proves the rule: re-validation

Across the whole dataset exactly one behavior broke the “authenticate and ignore” mold, and it points in the same direction. One operator (two IPs, Panama and Monaco, one entity) received a success, and then — roughly two to three days later — came back and re-tested a one-character variant of the very credential that had worked, before pivoting its whole list to a fresh batch. That is not exploitation either; it is an operator consulting its own records. Someone had logged “this credential validated” on their side and returned to confirm the entry still held — exactly the bookkeeping an access broker keeps on inventory it intends to sell.

A second cluster gives the mirror image. Its targeted-validator IP went quiet about a day after its last success and then stopped entirely, while the bulk-spray IPs beside it kept grinding for weeks more. A validator that winds down once it has logged its hits is an operator that got what it came for — the success was the goal, and the goal was a catalog entry, not a foothold.

Neither behavior contradicts validate-and-leave; both sharpen it. The operators do not wander off at random after a success. They leave because the success itself — recorded on their own infrastructure, occasionally re-checked — is the product.

Part VIII — How they find the target, and how little they check

The validators’ behavior around the spray is as revealing as the spray itself.

They do no reconnaissance. The high-volume clusters do not port-scan us first (they never touch any port but 443), they do not fetch the login page, they do not request the favicon, they do not probe the FortiOS API to confirm the product. Their very first packet is already a POST to the login endpoint. They connect straight to the open management port and start validating credentials. They already know it is a FortiGate. (Smaller cohorts are the exception — the health-themed sector-specialist and a few others run a light dual-surface check, fetching the SSL-VPN portal before spraying.)

How do they know? Because the device’s discovery is done for them, upstream, by someone else. Search engines like Shodan and Censys continuously scan the internet and index every FortiGate they find — by its HTTP title, its TLS certificate, and the hash of its login-page favicon. A one-line search for the FortiGate favicon hash returns a ready-made list of every internet-facing FortiGate management interface on earth. The validators harvest that list and spray it. They never re-verify, because the search engine already vouched for the target. (Our honeypot is in those results — indexed as a FortiGate like any other, which is the entire point of the deception.)

This is the division of labor made visible. The reconnaissance — the favicon fetches, the / crawls, the /.env and /.git/config secret-hunting — is performed by a completely separate population of thousands of crawler IPs that almost never brute-force anything. The credential validators are different machines that consume the reconnaissance output. Mapping, validating and (eventually) exploiting are three different hands.

They run essentially no honeypot detection. A spray operator worried about deception would probe response consistency, check timing, request odd paths, or confirm the FortiOS API behaves correctly before trusting a “success.” The validators do none of this — they trust the search-engine label and their credential list, and move on. The behavioral consequence is the part that matters for a defender: the credential-mill bulk does not verify the target, so a granted “success” they never act on is a strong signal of validate-and-leave rather than of a fooled attacker.

Their operational security is imperfect. The validation tools mask themselves as ordinary browsers, but the mask slips: one busy node sent fourteen thousand requests as a fake browser and then, exactly once, leaked the real Go-http-client user agent — revealing the tool is written in Go. The noisier scanning and exploitation population does not even bother to mask: we logged credential and exploit traffic openly identifying itself as curl, python-requests, aiohttp, and axios. And the targeting is purely by raw IP address rather than hostname — the fingerprint of a list harvested from an internet scan, not of a human who looked anything up.

One more honest note. The credential validators do not exploit — but a separate population does, and the two never overlap. Across 30 days, about 15 IPs threw genuine Fortinet-product exploits at the honeypot: two FortiGate flaws — an auth-bypass (CVE-2022-40684) and the classic SSL-VPN path-traversal file-read (CVE-2018-13379) — plus an (unattributed) command-injection RCE against FortiSandbox, a separate Fortinet appliance — all failed. And the split is clean: not one of those exploiters ever sprayed a credential, and not one of the 19 credential-validators ever threw an exploit (19 versus 15 IPs, zero overlap). Validation and exploitation are different trades, run by different hands. The exploitation that produced the dump happened months ago; what continues now is the patient, industrial business of checking which of the stolen keys still turn.

Continue to Part 3: What Stops Them — the only control that works, the detections that do not, and the IOCs that are already stale.

OHIIHO Research tracks targeted threat campaigns and APT-grade attackers through high-intensity, intelligence-grade honeypot infrastructure worldwide. We identify infrastructure at the ASN level, never individuals; organizational identifications derive solely from credentials captured in transit, and no victim system was accessed. Contact: research@ohiiho.com .