Peakhour.IO - Threat Intelligence

A Proxy Takedown Is Not a Security Control

2026-08-03T09:00:00+10:00

A residential proxy network is disrupted on Tuesday. On Wednesday, a password-spraying campaign is still reaching your login route through consumer IP addresses. The takedown changed upstream supply. It did not stop the campaign at your edge.

Legal action, platform enforcement, domain seizures, malware removal, and industry coordination matter. They can protect device owners, remove capacity, raise operating costs, and expose relationships that were previously difficult to see. They do not inspect the request currently approaching your application or decide whether it should be allowed to change an account.

That is the boundary security and fraud teams need to keep clear. A takedown is an ecosystem intervention. A provider label is time-bound intelligence. A request decision is a control in the path of the work being attempted.

The first article in this series compares what the IPIDEA and NetNut actions changed. The second examines why a network can disappear while its former IP inventory remains visible elsewhere. This final article starts after enforcement: when the network has changed, the headlines have moved on, and the application still needs to handle live traffic.

Disruption Changes the Network, Not the Destination's Job

Google's January 2026 IPIDEA disruption combined legal action against control and marketing domains, intelligence sharing, and Google Play Protect enforcement. Google said the action significantly degraded the network and reduced its available device pool by millions. It also warned that reseller agreements created overlap between exit pools and made definitive attribution difficult.

In July, Google took coordinated action against NetNut. Google said it disabled accounts and services used for command and control, shared intelligence, and used Play Protect against applications incorporating known NetNut SDKs. It estimated the network at a minimum of two million devices and reported 316 distinct threat clusters using suspected NetNut exits during one week in June.

Those are Google's findings and estimates, not a claim that every address associated with either provider was malicious. They still show why enforcement deserves support. Reducing compromised supply helps the people whose connections were being used and makes abuse infrastructure more expensive.

The destination's exposure is different. Google also said that operators affected by the earlier IPIDEA disruption began buying capacity from competitors and acting as resellers. A storefront can lose part of its own pool while continuing to sell access sourced elsewhere. Buyers can move as well. Demand, tooling, accounts, target lists, and attack behaviour do not disappear with a control domain.

If your production rule is provider = IPIDEA, the disruption may make that rule less accurate precisely when the incident looks most successful.

Expect Migration Before You Expect Silence

Post-disruption network-layer observations reinforce that warning, but they need careful attribution. Lumen's Black Lotus Labs reported from its own backbone telemetry that IPIDEA lost traffic and victim population after the January action, then rebuilt infrastructure and recovered. The same Black Lotus Labs proxy-ecosystem report describes backend connections and resale relationships across several networks.

That report reflects Lumen's visibility, detection methods, and assessments. It is not a complete census of the internet, and an infrastructure relationship does not prove that every request, exit, or customer belongs to one named operator. Its operational lesson is narrower and useful: supplier and reseller relationships can change faster than a static provider label.

After a disruption, assume four kinds of movement until evidence shows otherwise:

existing exits reconnect through replacement infrastructure;
a provider buys or resells another pool;
customers shift to a different storefront or whitelabel service;
the same operator rotates through new IPs while keeping its browser, credentials, request sequence, and target set.

The defender's task is not to guess the next brand name. It is to keep the intelligence current and preserve enough behavioural continuity to recognise the work after the address changes.

Rebaseline the Intelligence

A disruption date should trigger a data review, not an automatic claim of coverage.

Take a pre-action baseline by route: request volume, proxy prevalence, provider attribution, challenge completion, authentication outcomes, blocks, 429 responses, transaction completion, origin work, analyst review, and support contacts. Then compare the same measures immediately after the action and as the market adapts.

Refresh feeds and internal observations on their own collection cadence. Do not merge a historical provider association into a permanent property of the IP. For each proxy or network result, retain:

observed_at
indicator or network value
provider attribution, if any
attribution source and dataset version
confidence and reason
first_seen and last_seen where available

observed_at matters because a residential address can leave a pool, return to a different subscriber, or appear under another reseller. Confidence matters because “seen as an exit” and “attributed to this provider” are different claims. Provider attribution should be allowed to decay, be superseded, or remain unknown.

This is the provenance contract described in What a Residential Proxy Decision Log Should Contain. Keep the current request, the time-bound observation, the policy revision, the selected action, and the outcome connected. A retrospective feed correction should not silently rewrite what the control knew at decision time.

Correlate the Actor's Work Across IP Rotation

IP rotation is meant to break IP-only memory. Build continuity from the parts of the operation that are harder or more expensive to change together.

Useful correlation keys include:

account, tenant, API credential, session, or target object;
credential reuse and failure outcomes across many accounts;
versioned TLS, HTTP, browser, or device fingerprint cohorts;
route order, timing, retry behaviour, and automation cadence;
checkout, promotion, recovery, or payment-instrument patterns;
request cost and repeated origin or database work.

None of those fields proves identity by itself. A common browser fingerprint can group many legitimate users, and an account can be shared. The value comes from agreement across independent observations and from the route being protected.

Residential Proxy Detection for APIs Without JavaScript applies the same principle to machine traffic: use network and protocol evidence in the request path, then combine it with the API identities and outcomes already available. Do not make browser JavaScript a prerequisite for detecting rotation against an API.

Keep the Action Route-Specific

The takedown does not tell you what to do with a request. Neither does the proxy flag. As A Proxy Flag Is Not a Security Policy explains, the signal should change how much corroboration or friction a request needs, not select one global response.

Use the action that fits the route and the cost of error:

Allow low-risk activity when the session and behaviour are consistent.
Log new or uncertain intelligence while measuring the local population.
Challenge an interactive client when it can provide more evidence and has a safe recovery path.
Rate limit repeated or expensive behaviour across the account, client cohort, route, token, and outcome keys that survive IP rotation.
Step up authentication or transaction verification when the request can transfer account control or value.
Block when evidence is strong, harm is current, and a narrower action cannot protect the route.

Account creation, login, password reset, checkout, and public APIs have different identities and failure modes. Five Routes, Five Residential Proxy Decisions provides a concrete policy split. The important post-disruption change is to tune each contract with current observations rather than adding a site-wide deny rule for yesterday's provider.

Measure Protection and Customer Cost Together

An enforcement event can make a threat-intelligence chart fall without improving an application's outcome. A provider-labelled cohort may shrink because attribution changed. Attackers may reduce request rate, move to a new pool, or switch routes. Legitimate customers may still be caught behind shared networks.

Measure the control where the business feels it:

successful login, recovery, checkout, signup, and API completion;
confirmed abuse, account loss, fraud, scraping, and costly operations;
challenge presentation, completion, failure, and abandonment;
blocks and limits overturned by analysts;
origin work and application cost avoided;
support contacts, time to resolution, and exception volume;
policy changes, rollbacks, and rules past their review date.

Support cost is part of control cost. If a policy creates a queue of customers who cannot recover accounts, the team needs to see that beside the reduction in suspicious requests. Peakhour Residential Proxy Detection keeps the proxy signal in the live web and API decision. Bot Management and Advanced Rate Limiting add behavioural and route-aware controls, while API Security protects machine-facing operations without assuming an interactive browser.

The objective is a measurable change in harmful outcomes without an unacceptable change in legitimate completion.

Questions to Ask a Security or Fraud Vendor

Post-disruption due diligence should test operational evidence, not invite another pool-size claim.

Ask:

Do you retain observed_at, source, dataset or detector version, confidence, and provider-attribution reason separately?
How quickly can a provider label decay or change after infrastructure, reseller, or ownership movement?
Can you show what changed in your coverage after the IPIDEA and NetNut actions, including misses and attribution uncertainty?
Can your controls correlate behaviour across rotating IPs without treating a fingerprint as a person?
Can we set different allow, log, challenge, rate-limit, step-up, and block policies by route and API operation?
Does API detection work in the request path without a JavaScript lookup or a second application call?
Will the decision record show the inputs, policy revision, reason codes, action, and later outcome?
Can we compare security outcomes with customer completion, support cases, analyst overturns, and origin cost?
Who owns an emergency rule, when does it expire, and how quickly can we roll it back?

A credible answer should expose limits. If the vendor cannot distinguish an enforcement event, a provider association, and a request decision, it will be difficult for your team to do so during an incident.

Keep the Boundary Honest

Takedowns are necessary work. They protect consumers and disrupt infrastructure at a scale an individual destination cannot reach. They should continue.

Your application still has to judge the request in front of it.

Refresh the intelligence. Keep its time, source, attribution, and confidence. Follow behaviour across address changes. Apply a route-specific action. Record what happened next, including the customer's cost.

Enforcement can reduce the supply of abusive infrastructure. Only a control on the destination's current request path can protect the account, transaction, or API operation being attempted now.

When a Proxy Network Dies but Its IPs Survive

2026-08-03T08:30:00+10:00

A residential proxy network goes dark. Its domains are seized, its control systems are disrupted and its branded pool almost disappears. Two weeks later, many of the same public IP addresses appear through other proxy services.

Did the takedown fail? Did the same devices move? Were several providers selling the same supply all along?

The honest answer is narrower: the address inventory overlapped across time. That is valuable evidence, but it is not device identity, ownership or motive.

This distinction matters to security and fraud teams deciding what to do with traffic. It also matters to buyers, auditors and researchers trying to establish whether a proxy provider controls the supply chain it describes.

One Address Sits Above Several Relationships

The destination website sees the last layer in a longer chain:

device -> public IP -> SDK or supplier -> proxy pool -> reseller -> buyer -> destination

Each arrow represents a separate relationship.

The device may be a phone, laptop, streaming box, household gateway or server. Software on it, or elsewhere on the same network, sends a buyer's traffic out through a public IP assigned by an ISP or mobile carrier.

An SDK or supplier enrols that capacity. A proxy pool makes it selectable. A reseller may buy the service upstream and sell it under another name. A buyer chooses a location or session through an API. The destination sees a request from the exit address, not this commercial history.

Those layers do not map one-to-one. Several devices can share one public address through a household router or carrier-grade NAT. One device can receive different addresses over time. One supplier can feed several pools. A pool can combine direct supply with upstream inventory. A reseller may not know which device, supplier or SDK produced a particular session.

Our article on how bandwidth sharing feeds residential proxy networks covers the ways capacity enters this chain. The question here is different: what can we infer when a named network disappears but addresses associated with it remain visible elsewhere?

What the NetNut Measurement Found

On 2 July 2026, Google, the FBI, Lumen and other partners took action against the NetNut residential proxy network, also known as Popa. Our comparison of the IPIDEA and NetNut actions separates the controls and public claims involved. Google said it disabled accounts and services used for command and control, shared technical intelligence, and updated Play Protect to disable applications known to contain NetNut SDKs. Google estimated that the network included at least two million devices and said it had high confidence that multiple proxy brands white-labelled NetNut capacity.

Layer3 Intel then published a useful post-event measurement. Its NetNut takedown analysis says the number of unique NetNut exit IPs it observed per hour fell by 99.92% by 5 July. At the brand or gateway layer, that is a decisive decline.

The cross-network result was less absolute. Layer3 Intel took IPv4 addresses it had observed through NetNut in the 30 days before the shutdown and checked whether they appeared through other networks during the following 14 days. Among addresses seen through NetNut in the final one to two days, 78.81% reappeared elsewhere.

The researchers also tried to account for ordinary churn. They applied reappearance rates from a 4 June placebo cutoff to the July cohort. On that basis, they expected about 17.96 million recent addresses to reappear and observed 16.90 million. The difference produced a baseline-adjusted estimate of about 1.06 million IP addresses removed from the wider proxy ecosystem beyond normal churn.

These measurements support three bounded findings:

NetNut's branded, observable exit service collapsed.
Much of the recent public-address inventory associated with NetNut was observable through other proxy networks after the disruption.
Reappearance was lower than the selected June baseline, consistent with a real takedown effect beyond ordinary address churn.

That is already operationally important. A provider name can disappear while some of the address inventory remains commercially reachable.

An IP Match Is Not a Device Match

The same measurement does not prove that the same physical device survived, moved between suppliers or carried two SDKs.

Public addresses are assigned to connections, not permanently engraved on devices. DHCP leases expire. Mobile subscribers move between network gateways. Consumer routers reconnect. Carrier-grade NAT lets many subscribers share public addresses from a provider-controlled pool. RFC 6598 documents shared address space used by service providers for CGNAT, but the ambiguity exists outside that range too: the destination only sees the translated public address.

If 203.0.113.x appears through Network A before a cutoff and Network B afterwards, several explanations fit:

the same device was available through both networks;
different devices behind the same household or carrier address were enrolled;
an ISP reassigned the address to a different subscriber;
a shared upstream supplied both pools;
one provider resold another provider's capacity;
the enumeration system attributed one of the observations incorrectly.

IP overlap increases confidence that address inventory is shared or recycled across the market. It does not identify which explanation is correct for any one address.

It also does not prove supplier ownership. A provider may own infrastructure, contract directly with a supplier, buy capacity through an intermediary, or combine all three. Nor does overlap prove that a device owner did not consent. Consent belongs to a specific person, device, software version, disclosure and time. An IP address contains none of those records.

Most importantly, overlap does not prove motive. It can show that a buyer's request travelled through an observed exit. It cannot establish what the supplier, reseller or provider knew, why a buyer selected the route, or whether the destination request was benign or abusive.

Google's earlier IPIDEA investigation reached beyond address overlap. It analysed applications, Windows binaries, SDK code, command infrastructure and shared server pools, and paired that technical work with platform and legal action. Even then, Google noted that overlaps between exit nodes made definitive quantification and attribution difficult. That is the right standard: use IP observations as one part of a multi-layer attribution, not as a shortcut through the layers.

Read the 1.06 Million Estimate as an Estimate

Layer3 Intel's analysis is stronger than a simple before-and-after count because it recognises ordinary churn and uses an age-matched comparison. Its scale and high-frequency observation also give it a useful view of the market.

The public methodology still leaves material uncertainty:

Enumeration is proprietary. The post describes the volume and timing of observations, but does not publish the complete sampling system, provider coverage, request selection, deduplication rules or validation set. Readers cannot independently reproduce the population from the article alone.
An IP is a noisy unit. Dynamic addressing and CGNAT break a stable link between address, subscriber and device. Counting distinct IPv4 addresses can overstate devices and obscure shared use.
The windows choose what can reappear. The source cohort covers 30 days; the follow-up covers 14. Shorter or longer windows would change both the raw overlap and the churn model.
There is one published placebo cutoff. A single June comparison is useful, but it does not show the normal week-to-week distribution, seasonal effects or whether that period was representative.
No confidence intervals are published. The 1.06 million figure is presented as a point estimate. The post does not provide uncertainty bounds, sensitivity analysis or an error rate for network attribution.
The counterfactual is observational. The difference from baseline is consistent with the takedown removing capacity. Other simultaneous supplier, demand, enforcement or measurement changes could contribute.

None of these limits makes the result useless. They set its resolution. “About 1.06 million fewer addresses reappeared than this baseline predicted” is supported by the published method. “Exactly 1.06 million devices were removed” is not.

What a Sourcing Claim Can Responsibly Prove

A vendor can responsibly prove facts about processes and records it controls.

It can show which entity contracted each direct supplier, which software package enrolled a device, what disclosure was presented, how affirmative consent was recorded, how withdrawal works, which versions were active, and whether a buyer's session can be traced to that evidence. It can document reseller dependencies, prohibit undisclosed sub-supply, test compliance and publish exceptions.

A policy page can prove that a policy exists. A contract can prove that parties accepted terms. Neither proves that every active exit followed the policy.

“Ethically sourced” is therefore too broad unless the provider defines the claim and its coverage. Does it apply only to a proprietary pool? To upstream suppliers? To every session sold by resellers? Does consent come from the device user, the account holder, the network owner or all relevant parties? How quickly is an exit removed after withdrawal?

The strongest claim is session-level and time-bound: for this delivered connection, the provider can trace the supply path to a named enrolment mechanism and current evidence, subject to stated audit limitations. Anything less should be described at its actual scope.

What Auditors and Buyers Should Request

Do not ask only whether sourcing is ethical. Ask for evidence that follows the chain:

a current inventory of direct suppliers, upstream pools and white-label dependencies;
the percentage of delivered traffic covered by direct, auditable sourcing rather than policy language alone;
SDK names, package hashes, versions, distribution channels and signed build provenance;
the exact user disclosure and consent event, including timestamp, software version and withdrawal path;
proof that the person giving consent had authority over the device and network connection;
controls for CGNAT, reassigned addresses, duplicate exits and concurrent appearance across providers;
session-level lineage from buyer request to pool, supplier and enrolment record, sampled by an independent auditor;
contractual limits on sub-suppliers, plus evidence that those limits are tested;
complaint, removal and incident records, including time to disable an exit across every downstream reseller;
methodology for advertised pool size, unique-IP counts and active-device counts, with uncertainty and deduplication rules;
independent test results, exceptions and remediation, not only a clean summary statement.

Buyers should also keep their own record: product and upstream named at purchase time, contract revision, stated sourcing basis, session identifiers where available, destination and purpose, and the control used to prevent abuse. A provider's assurance does not transfer accountability for how the buyer uses the route.

Defenders Still Have a Request to Judge

Post-takedown research can improve proxy intelligence. It cannot turn an IP address into a verdict.

An address that reappears across pools may deserve closer observation, especially on login, account recovery, checkout or expensive APIs. The action should still depend on route, account state, client consistency, behaviour and recent outcomes. That is why a proxy flag is not a security policy.

Keep the provenance of the observation as well. Record which network label was seen, when it was observed, which dataset and version supplied it, what other evidence changed the action, and what happened next. Our guide to residential proxy decision logging sets out that operating record.

A takedown can kill a service without retiring every address that passed through it. The surviving IPs tell us that the market has shared, changing inventory. To say who supplied it, whether a device owner consented, or why a request was sent, we have to follow the rest of the chain.

For the destination, the work continues with the request. The final article in this series explains why a proxy takedown is not a security control and what security and fraud teams should rebaseline after a disruption.

Public Fingerprint Databases Are Not Ground Truth

2026-07-13T09:28:00+10:00

Network fingerprint formats are public. Reliable labels are not.

We reviewed the main public JA3, JA4, TLS, TCP, HTTP, SSH, JARM, DHCP, operating-system and service-fingerprint resources. The result was not one large ecosystem of interchangeable databases. It was a set of much narrower things: small mapping samples, old signature lists, active-probe rules, malware feeds, account services and a large observatory whose TLS records are almost entirely unlabelled.

That is not a criticism of the maintainers. It is a warning about what happens after a fingerprint field reaches a dashboard. A precise-looking value invites a precise-looking name. The evidence behind that name may be a controlled capture, a best guess from 2018, a community submission or a malware sandbox observation that was never compared with benign traffic.

Those labels should not produce the same decision.

The largest public TLS database has almost no TLS labels

The relaunched TLS Fingerprint Observatory is an unusually valuable public resource. It exposes more than a million distinct TLS fingerprints and billions of passive observations from the University of Colorado Boulder and Merit Network. Records can include first and last seen, counts by source, cipher suites, extensions, groups, signature algorithms, ALPN and other parsed fields.

At the time of our review, essentially none of the TLS fingerprints had implementation labels.

That fact makes the observatory more credible, not less. The collection can answer prevalence and protocol-evolution questions without pretending it knows which application created every handshake. Its smaller QUIC corpus has several hundred controlled labels, often tied to generated capture files.

The limitation is equally clear. A prevalence database cannot become a browser or malware classifier merely because its records are detailed. The labels require another source of truth.

The public JA4 database is a sample, not JA4DB

FoxIO maintains JA4DB, a hosted service covering several JA4-family methods, applications and detection guidance. It is the closest current service to a multi-surface mapping database.

The public file most people can inspect is different. FoxIO's ja4plus-mapping.csv contains 66 data rows. Only 35 carry a core JA4 value; the other JA4+ columns are sparser.

That file is useful documentation. It shows how an application, library, device, operating system and several network observations can sit in one row. It is not broad enough to serve as a general browser, bot or malware catalogue.

The hosted service is now account-oriented. Its bulk-data licence and per-record provenance are not publicly clear enough to call it an open database. Core JA4's BSD licence does not automatically cover the hosted labels, and it does not cover all other JA4+ methods under the same terms.

The open JA3 mappings are mostly historical

Salesforce's archived JA3 lists contain roughly 159 application mappings for macOS and Linux. The repository describes them as example or best-guess material. They have no per-row capture date, client version, source PCAP or confidence.

Trisul's ja3prints is larger: 626 JSONL mappings assembled from Salesforce examples, malware-traffic-analysis captures, FingerprinTLS and browser additions. Its last update was in 2018, and the combined dataset does not have a clear repository-wide licence.

The historical FingerprinTLS database preserves richer ClientHello fields than JA3, which makes it valuable for research. It is now archived, and many records lack consistent capture dates, operating-system evidence and confidence.

These sources still matter. They document the lineage and can help with an older incident. They should not silently become current application ground truth.

Rules are not observations

Some of the strongest public databases are actually matcher corpora.

Nmap's OS database contains actively maintained probe-response signatures. Nmap service probes combine test payloads with regular expressions that extract products and versions. Rapid7 Recog maintains XML signatures for SSH, HTTP, SNMP, favicons, JARM and other surfaces. p0f's p0f.fp contains passive TCP and HTTP traits, although its upstream corpus is now dated.

These resources can be excellent at their stated job. A rule match means that a response satisfied the signature. It does not establish population prevalence, exclusivity or a particular process behind the connection.

Flattening a matcher result into the same table as an observed application mapping discards that distinction.

Malware observation is not malware identity

SSLBL publishes a JA3 blacklist under CC0. It records fingerprints observed while analysing more than 25 million malware PCAPs and offers both CSV and Suricata rules.

SSLBL also says the values were not tested against known-good traffic and may cause substantial false positives.

That warning is part of the data. A row supports this statement:

malware samples assigned this family label produced this JA3

It does not support this statement:

every connection with this JA3 is that malware

Shared libraries make the second statement unsafe. Cisco's destination-context research examined public malware JA3 indicators and found that many were more strongly associated with benign processes in its enterprise observations.

VirusTotal's behavioural pivots have the same boundary. Files sharing a JA4 may be related malware, come from one developer or merely use the same TLS library. The pivot begins an investigation; it does not finish one.

Mercury publishes the schema, not the labels

Cisco Mercury offers one of the clearest public designs for a fingerprint knowledge base. Its resource documentation describes mappings from fingerprints to candidate processes, process counts, operating-system observations and destinations. The classifier can use destination address, port and server name to rank those candidates.

The current Cisco-labelled resource database is not in the public repository.

This is an honest architectural boundary. The NPF format, collector and database contract are inspectable. The production labels depend on continuously collected endpoint, network and malware-analysis data that Cisco does not publish as an open corpus.

What is actually missing

The public ecosystem does not mainly need another hash list. It needs evidence attached to each mapping:

the raw or reversible fingerprint;
the method and implementation version;
an independent label source;
capture position and environment;
first and last seen;
observation count;
competing labels;
confidence and review state;
a usable dataset licence.

Almost none of the public resources supplies all of these. Some optimise for scale, some for current labels, some for inspectability and some for rules that can run in an existing scanner.

The practical response is to preserve those categories. Use an observatory for prevalence, a matcher corpus for response signatures, a threat feed for malware observations, and a mapping database for candidate labels. Then validate the result against local evidence before it reaches enforcement.

The full directory is in Public Network Fingerprint Databases and What They Cover. The evaluation checklist is in How to Evaluate a Network Fingerprint Database.