Peakhour.IO - Security

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 Home Devices Become Attack Infrastructure

2026-08-01T12:30:00+10:00

A compromised streaming box under a customer's television is not an endpoint your application team can patch.

It can still send traffic to your login page.

Residential proxy and botnet supply increasingly includes ordinary connected devices: streaming boxes, routers, phones, PCs, projectors, and other hardware that stays online behind a consumer connection. Some owners knowingly share bandwidth. Some accept a vague disclosure inside an app. Others never consent because the device or software was compromised.

The sourcing problem matters to platforms, app stores, vendors, ISPs, and law enforcement. The destination service has a more immediate job. It must decide what the request is allowed to do.

The Exit Looks Like a Customer Network

When third-party traffic leaves through a household device, the destination sees the household's public IP. The address may belong to a well-known Australian ISP. It may have no negative reputation. It may also be shared with legitimate activity from the same home or carrier network.

This is why an IP allow-list, deny-list, or country rule cannot establish who controls the request. The source is real. The relationship between that source and the operator is hidden.

Our earlier article, How Bandwidth Sharing Feeds Residential Proxy Networks, explains the supply chain. The defensive consequence is that trust has to move up from the address to the request, session, route, and behaviour.

Quiet Monetisation Changes the Compromise

In 2025, Palo Alto Networks Unit 42 documented attackers exploiting vulnerable GeoServer instances and deploying a legitimate passive-income application and SDK. The code matched the vendor's official version; the installation and use were unauthorised. Unit 42's proxyware campaign report explains why legitimate binaries can still be part of a compromise.

That payload can be quieter than ransomware or cryptomining. It produces recurring value without making the device's failure obvious. For a destination application, quieter supply means a proxy exit can remain useful for longer.

The FBI's 2025 BADBOX 2.0 alert described Android-based streaming devices, projectors, tablets, digital picture frames, and aftermarket vehicle systems affected before purchase or during setup. The FBI said compromised devices could become part of residential proxy services and botnets used for criminal activity.

These reports do not mean every inexpensive smart device is compromised. They show why household provenance is not a security verdict.

What the Application Can Observe

The destination cannot inspect the television or router. It can observe the work attempted through it:

route and operation;
authentication and account state;
residential proxy and broader IP context;
TLS, HTTP, and browser fingerprint cohorts;
device and session history where available;
request timing and sequence;
credential exposure;
failures, retries, and response-code loops;
application and origin cost.

Several devices may also share the public address. A permanent household ban can punish the subscriber whose device was compromised. Correlate the behaviour using keys that fit the route.

Control the Sensitive Journey

The action should follow what the request can change or consume.

For public cached content, proxy use may need no intervention. For login, count failures across account and client cohorts rather than relying on the exit. For password reset, keep responses consistent and limit repeated recovery attempts. For checkout or account changes, carry the earlier session risk forward and request stronger verification when the consequence rises. For expensive APIs, use identity- and cost-aware budgets.

Peakhour Residential Proxy Detection contributes a live network signal for browser and API traffic. Bot Management combines it with the route, client and behaviour already visible in the request path. The objective is not to identify the appliance. It is to stop relayed traffic from inheriting unconditional trust from the household address.

Platform Enforcement Reduces Supply, Not Every Request

Since August 2019, Google Play has required an app facilitating proxy services to third parties to make proxying its primary, user-facing core purpose. The current Device and Network Abuse policy retains that rule. It gives Google a basis for removing unrelated apps that hide proxy functionality, regardless of whether an SDK vendor describes enrolment as consensual.

That policy can reduce deceptive supply. Device takedowns and legal action can disrupt infrastructure. Google's IPIDEA operation combined legal action, platform enforcement, and industry coordination.

Application controls are still required. Existing exits do not disappear at once, private pools remain, and new supply can emerge before datasets identify it.

The 2026 actions against IPIDEA and NetNut show both sides of that boundary. Our takedown comparison covers the upstream disruption; the follow-up on surviving proxy IP inventory explains why an address seen after a takedown does not, by itself, identify the device or supplier behind it.

Preserve Evidence Without Blaming the Customer

When an event is challenged or blocked, record the route, proxy and network evidence, client cohort, account or token context, policy revision, selected action, and outcome. Avoid language that says the household owner attacked the service. The evidence usually supports a narrower statement: traffic reached the application through this connection and matched this behaviour.

That distinction matters for support, fraud review, and incident response. The subscriber may be a victim too.

Application teams cannot repair every compromised box on the internet. They can refuse to let a residential address stand in for identity, intent, or permission.

Residential Proxies Turn Layer 7 DDoS Into a Route Problem

2026-08-01T12:20:00+10:00

Not every Layer 7 DDoS attack looks large at the edge.

A residential proxy pool can spread requests across thousands of consumer addresses. Each exit sends a modest amount of traffic. Per-IP limits stay quiet. Aggregate bandwidth may look manageable. The application still falls over because the requests concentrate on work that is expensive to perform.

Search, login, checkout, GraphQL, report generation, uncached rendering, and API aggregation can fail long before the network link is full. Residential distribution turns the incident into a route and resource problem.

Count the Work, Not Just the Requests

Two HTTP requests can have radically different cost.

A cached image may be served at the edge with no origin work. A search request may query several indexes. A login can invoke password hashing, credential checks, session state, and downstream identity services. A GraphQL operation can expand into many resolvers. An export can hold database and worker capacity for seconds or minutes.

Cloudflare's explanation of application-layer DDoS attacks describes the core distinction: Layer 7 attacks target the application work involved in processing apparently legitimate requests.

Map the routes before an incident:

which requests are cacheable;
which invoke database, search, identity, payment, or third-party dependencies;
which hold workers, connections, queues, or memory;
which can be assigned a cost class;
which business journeys must remain available under pressure.

Requests per second is still useful. It is not the complete capacity model.

IP Limits See the Distribution, Not the Campaign

A per-IP limit catches simple floods and protects against one noisy client. Keep it as one layer.

Residential proxies are designed to distribute source addresses. A campaign can remain below an IP threshold while one fingerprint cohort, route sequence, query shape, account pattern, or operation class grows rapidly across the fleet.

Useful aggregate keys include:

route + fingerprint cohort
operation + query cost class
login route + account + failed outcome
tenant + API credential + expensive operation
route + proxy state + response outcome

No key is universally safe. A common browser or mobile SDK can create a large legitimate cohort. Observe bucket sizes and successful outcomes before using a grouping key for enforcement.

Proxy Detection Changes Confidence

A residential proxy result does not prove DDoS. It changes how the request is interpreted when other evidence agrees.

For example:

a new residential exit fetching one cached page adds little risk;
many exits sharing a narrow client cohort and repeatedly missing cache on an expensive route add more;
the same pattern causing queue growth, timeouts, and origin errors supports immediate mitigation.

Google's IPIDEA investigation showed how large and commercially interconnected a residential exit pool can become. Application defenders should assume source diversity is purchasable.

Peakhour DDoS Protection combines anomaly detection, route-aware rate limits, bot and WAAP context, cache policy, and origin protection in one request path. RESIP contributes a signal; the action comes from the route, behaviour, and current service pressure.

Preserve a Clean Path

Emergency mitigation often fails by protecting the server from everyone.

Decide in advance which journeys need to survive:

existing authenticated sessions;
account recovery;
checkout or payment confirmation;
status and support information;
partner or operational APIs;
cacheable public content.

Controls can then narrow around the attacked resource. Serve cacheable responses at the edge. Reduce budgets for costly anonymous operations. Apply stricter limits to repeated failures. Challenge interactive browsers where there is a recovery path. Preserve authenticated or known-good traffic when the evidence supports it.

Challenges do not solve every flood. Browser automation can complete them, and challenge generation can itself consume capacity. Machine-to-machine APIs need protocol-appropriate responses. RFC 6585 defines HTTP 429 Too Many Requests and the optional Retry-After header, but clients and operators still need to prevent retries from amplifying pressure.

Watch the Origin Outcome

Mitigation evidence should connect the request to what happened behind it:

cache hit or miss;
origin request avoided;
application latency and response status;
queue, worker, connection, and dependency pressure;
rate-limit, challenge, or block action;
successful user journey completion;
policy revision and activation time.

A rising block count only describes the control. Protection is visible when essential routes remain available, origin pressure falls, and legitimate completion stays within an acceptable range.

Rehearse the Policy Before the Flood

During an incident, teams reach for the keys they already have. If every counter is bound to source IP, residential distribution will force a broad emergency rule.

Choose one expensive route now. Measure normal cost and cohort sizes. Add observation counters for route, identity, fingerprint, proxy state, and outcome. Define the threshold that indicates resource pressure, the first reversible action, the owner, and the rollback condition.

For the first rehearsal, one expensive route is enough. If the team can describe its normal cost, see distributed pressure, apply a bounded action, and preserve legitimate completion, it has a mitigation pattern worth extending. An address ban on its own does not provide that pattern.

Privacy Relay, Corporate VPN, or Residential Proxy?

2026-08-01T12:00:00+10:00

An application sees a login from an address that does not match the user's apparent location. The connection belongs to a relay, VPN, or proxy network.

That is a reason to look closer. It is not a reason to call the user malicious.

Privacy relays, corporate VPNs, consumer VPNs, carrier-grade NAT, and residential proxies all weaken the old assumption that an IP address describes one person in one place. They do it for different reasons and with different operating models. A security policy that reduces them to anonymous=true will either miss abuse or punish legitimate users.

Privacy Services Deliberately Separate Identity from Destination

Apple says iCloud Private Relay uses separate internet relays so no single party can see both who a user is and which sites they visit. It also lets the user preserve a general location or use a broader country-and-time-zone location. Apple's Private Relay overview explains the scope and the role of the relay addresses.

That design changes what a website can infer from the source IP. It does not remove the session, account, route, browser, or request behaviour available to the application.

A corporate VPN creates a different pattern. Many employees may exit through a small set of company gateways. The source can be stable and organisation-owned, but the address still represents a population rather than one device. A consumer VPN may rotate gateways and mix unrelated subscribers. Carrier-grade NAT can make a normal mobile or broadband address shared even when no privacy product is involved; RFC 6598 documents shared address space reserved for carrier deployments.

Residential proxy services are different again. A remote operator deliberately routes through consumer or ISP connectivity so the destination sees the household exit. Mobile proxy services use the same broad model through carrier connectivity, but should remain separately labelled because their sharing and attribution conditions differ. Either form of supply may come from an informed participant, an embedded SDK, compromised software or another path.

The network categories matter. They still do not establish intent.

Define the Expected Population

Policy should reflect the application and route.

A workforce portal may know its corporate VPN ranges and require device or certificate evidence. A consumer service should expect mobile networks, privacy relays, travel, and shared households. A country-restricted service may need stronger location verification than an online catalogue. An API used by fixed partners can enforce network expectations that would be unreasonable on a public login page.

Ask:

Is this network type expected for this user population?
Is the route public, authenticated, sensitive, or expensive?
Does the account have established device and session history?
Is the apparent location material to the transaction?
Can the client provide another form of evidence?
What does a false rejection cost?

The answer determines whether the network signal should be ignored, logged, challenged, or combined with stronger controls.

Use Context to Separate Risk from Privacy

Peakhour IP Intelligence and Residential Proxy Detection place network context beside credentials, device history, fingerprints, behaviour, route, and recent events.

Consider two logins through privacy infrastructure.

The first uses an established session, familiar device history, a normal route sequence, and one successful authentication. The second attempts many accounts, carries an exposed credential, has no normal session history, and repeats the same failure pattern across rotating addresses.

Both hide or replace the direct source address. Only one presents a strong account-abuse pattern.

The policy should be able to express that difference. Blocking every relay or VPN is not contextual security. It is a network-category ban.

Geography Needs the Same Restraint

IP geolocation is an estimate of network presence, not proof of a person's physical location. VPN gateways, relays, mobile routing, satellite networks, corporate egress, and proxy exits can all separate the address from the user.

Use geography as evidence proportionate to the decision. A content preference may tolerate a coarse estimate. A regulated transaction may require account evidence, verified identity, payment context, or an explicit location control beyond an IP lookup.

Avoid impossible-travel rules that treat every IP change as physical movement. A session can switch between mobile, Wi-Fi, VPN, and relay paths without the person travelling at all. Look for continuity in the account, device, session, and behaviour before escalating.

Choose an Action That Can Be Recovered From

The action can then scale with the evidence:

Allow expected privacy or corporate access with consistent session evidence.
Log an unfamiliar network category on low-consequence routes.
Apply tighter rate limits when repeated behaviour spans accounts or rotating exits.
Challenge an interactive client when network change appears beside account risk.
Require step-up verification for recovery, payment, or access-control changes.
Block confirmed automated abuse with bounded route and policy scope.

Challenges are not perfect humanity tests. Automation can complete them, while privacy tools, accessibility software, or broken browser environments can cause legitimate failures. Measure completion and provide a recovery path.

Retain the Reason

When a policy acts, retain the network category, source, route, contributing evidence, action, and outcome. “Anonymous IP” is too vague for support or incident review.

The record should show whether the deciding factor was proxy use, an exposed credential, failure velocity, a new device, a route sequence, or several observations agreeing. That evidence lets the team tune the control without adding broad exceptions that erase protection.

Privacy and security are not opposing verdicts attached to an address. They are requirements the application has to handle at the same time.

What a Residential Proxy Decision Log Should Contain

2026-08-01T11:50:00+10:00

A log line that says proxy=true is intelligence. It is not a decision record.

When a customer asks why a login was challenged, a fraud analyst reviews an account event, or an engineer tunes a rate limit, the team needs to reconstruct what the control knew and what it did. A timestamp, IP address, and final risk score cannot answer that on their own.

Peakhour Residential Proxy Detection keeps the proxy result inside the request decision with IP, credential, device, behaviour, and route context. The record should preserve that connection without becoming an indiscriminate collection of personal data.

Record the Request Being Judged

The event comes first. The detector explains one part of it.

Useful request fields include:

observed_at
request_id and trace_id
service, host and route class
HTTP method
response status
account, tenant, session or API-key reference where permitted
edge location and origin target
cache outcome and whether origin was reached

Avoid logging secrets, complete session tokens, passwords, payment data, or unrestricted request bodies. The OWASP Logging Cheat Sheet recommends excluding or masking access tokens, authentication passwords, sensitive personal data, and other values whose collection creates more risk than operational value.

Use stable references where the investigation needs continuity, and keep their purpose and retention bounded.

Keep Signal Provenance

The value of a signal depends on how it was produced.

For proxy and network evidence, retain:

proxy_result and category
detector or feed name
detector version or dataset time
network type, ASN and country
client IP source and trusted forwarding hop
fingerprint method, version and capture point
browser or device evidence source

A fingerprint without a method and capture point cannot be compared safely. A country value without a source and observation time is difficult to audit after data changes. A forwarded IP taken from an untrusted header should never have reached policy in the first place.

Flattening every input into one number leaves the analyst with a threshold and no explanation. Retain the factors that moved the score.

Record the Policy and the Action

The event should identify the control that made the decision:

policy_id and revision
policy owner
mode: monitor or enforce
matched conditions
threshold and current counter state
selected action
action reason code
expiry or review date

Reason codes should be stable enough to aggregate. Free-text analyst notes can add context, but they should not be the only explanation.

The action field needs more detail than blocked=true. Distinguish allow, log, challenge, rate limit, deny, route, and step-up outcomes. For a limit, keep the key class and interval without exposing sensitive raw values. For a challenge, record whether it was presented, completed, failed, expired, or abandoned.

Connect the Decision to Its Outcome

Security controls are judged by what happened next.

Join the decision to:

successful login, signup, reset, checkout, or API completion;
authentication failure and account lockout;
challenge completion and abandonment;
429, deny, or step-up response;
origin request avoided or origin work created;
support case, analyst disposition, or confirmed incident where available;
policy rollback or exception.

This is how a team distinguishes attack reduction from customer suppression. If challenges rise and successful account recovery falls, the proxy policy may be adding friction in the wrong place.

NIST SP 800-92, the Guide to Computer Security Log Management, treats log management as a lifecycle of generating, transmitting, storing, analysing, and disposing of data. That lifecycle matters here. A detailed event that nobody can query, retain safely, or delete on schedule is not operational evidence.

Metrics Should Lead to a Decision

For an enforcement platform, useful measures should connect signals to route outcomes:

proxy prevalence by route and action;
percentage of proxy-labelled traffic allowed, challenged, limited, and blocked;
challenge completion for proxy and non-proxy cohorts;
legitimate transaction completion after action;
confirmed abuse caught with and without a proxy signal;
false-positive and analyst-overturn rates;
origin requests and application cost avoided;
time from observation to policy change;
rules past their review date.

A count of “risky sessions detected” is hard to act on. A rise in residential-proxy password-reset attempts with low challenge completion and repeated account failures can justify a route-specific change.

A Minimal Event

A compact decision record might resemble:

{
  "request_id": "req_...",
  "route_class": "account_recovery",
  "proxy": {"result": true, "category": "residential", "source": "resip"},
  "fingerprint": {"method": "ja4", "version": "pinned", "capture": "client_edge"},
  "credential_state": "exposed_match",
  "recent_outcome": "repeated_failure",
  "policy": {"id": "recovery-risk", "revision": 7, "mode": "enforce"},
  "action": "step_up",
  "reason_codes": ["residential_proxy", "exposed_credential", "failure_velocity"],
  "outcome": "pending"
}

The exact schema will differ by application. The contract should not: current request, signal provenance, policy revision, selected action, and measurable outcome.

The schema is ready when a support engineer can explain a challenge, an analyst can reconstruct an account event, and the policy owner can measure the result without opening a second system. Anything collected beyond that needs a stated security purpose and retention period.

Keep Your CDN. Add Proxy and Bot Decisions at the Edge.

2026-08-01T11:40:00+10:00

Security projects often begin with a false choice: replace the current CDN or accept the controls it already provides.

Real environments are messier. A business may have a long-term CDN contract, cloud-specific routing, established cache rules, a migration freeze, or applications that cannot all move together. The security problem still exists. Residential proxy traffic, credential stuffing, scraping, API abuse, and Layer 7 floods do not wait for a platform consolidation programme.

Peakhour Bring Your Own Edge supports two first-class paths: Peakhour Edge can be the delivery layer, or Peakhour intelligence can operate alongside the edge provider already in place. The product value is not the diagram. It is retaining one decision model for request context, policy, action, and evidence in either deployment.

Decide Where the Authoritative Observation Happens

An application behind a CDN sees a connection from the CDN, not necessarily the original client-facing connection. That affects IP provenance, TLS fingerprints, geography, and rate counters.

Before adding another control, map the path:

client → existing edge → Peakhour decision point → origin

or:

client → Peakhour Edge → origin

For every field used by policy, record where it was observed and who is allowed to set it. Client-supplied copies of forwarding or fingerprint headers must be removed at the trusted boundary. The authoritative edge can then set the value passed downstream.

This is not bookkeeping. A rate limit built on a spoofable forwarded address is a client-controlled rate limit. A TLS fingerprint calculated at origin may describe the intermediary rather than the browser. Provenance determines whether the signal can safely change an action.

Keep Policy Close to the Consequence

A decision point earns its place only if it can still protect the route. It needs to prevent avoidable origin work, slow repeated behaviour, challenge an interactive browser, block a confirmed attack, or preserve a clean path during a flood.

Peakhour combines IP intelligence, residential proxy detection, fingerprints, credentials, route behaviour, bot state, rate thresholds, and WAAP findings in that request path. The action can be allow, log, challenge, rate limit, or block. The existing CDN can remain responsible for the delivery work it already does well.

This matters because enrichment without enforcement creates a timing and ownership gap. A lookup result delivered after the application has rendered a page, queried a database, or changed account state may still help an investigation. It did not protect that request.

Network intelligence is useful on account creation, login, and password-reset routes when the signal remains connected to the request. Peakhour carries that context through to route-specific action and retains the outcome.

Migrate a Decision, Not the Whole Estate

A staged deployment can begin with one abused route:

Observe the request at the trusted boundary.
Forward or derive the fields required by the policy.
Run the new decision in monitor mode.
Compare it with current CDN and origin outcomes.
Apply one reversible action.
Expand only after false positives and operational ownership are understood.

Login, account creation, search, scraping targets, and expensive API operations are good candidates because their behaviour is measurable and their business consequence is clear.

Duplicating every rule in two systems is not a migration strategy. Decide which layer owns each action, how conflicts are resolved, and which record is authoritative. A request should not be challenged twice because two providers reached the same conclusion independently.

Preserve Cache and Origin Context

Bot and proxy decisions affect more than authentication. Scrapers and Layer 7 floods consume cache, transformation, application, and origin capacity.

A useful decision record can include:

cache status and whether the request reached origin;
route and request cost class;
proxy, IP, fingerprint, credential, and bot evidence;
rate-limit state and selected action;
response status and origin health;
policy revision and enforcement point.

That joined record shows whether a control actually protected capacity. Blocking more requests is not inherently better. Serving clean cache hits while throttling expensive automated misses may produce a stronger outcome than a broad deny rule.

Make the Trust Boundary Explainable

NIST's Zero Trust Architecture frames access around explicit resource decisions rather than implicit trust in network location. The same discipline helps at an application edge: evaluate the request from current evidence, enforce a resource-specific policy, and retain enough information to explain the decision.

An existing CDN is not an obstacle to that model. An undefined trust boundary is.

Use the delivery reality you have. Identify the client-facing observation point, choose the routes where better context can change an outcome, and assign policy ownership. Move delivery layers when the operational case supports it—not because a security feature forced an all-or-nothing migration.

A Proxy Flag Is Not a Security Policy

2026-08-01T11:00:00+10:00

At Peakhour, a residential proxy match changes how much trust we place in a request. It never selects the action on its own.

The match tells us that the network presenting the traffic may not be where the operator is sitting. Whether that matters depends on what the request is trying to do, what else is known about the client, and the cost of getting the action wrong. Treating a proxy label as policy collapses those questions into one bit. The rule becomes easy to configure and hard to operate.

Residential proxy detection therefore sits inside the live request decision beside IP reputation, credentials, device history, network fingerprints, behaviour, route sensitivity, and recent outcomes. It changes the level of evidence we require.

The Same Signal Means Different Things on Different Routes

Consider three requests from the same residential proxy exit:

A visitor opens a cached product page.
A client tries one password against 200 accounts.
An authenticated user changes the recovery email on a high-value account.

The network fact is identical. The consequences are not.

The first request may need no action beyond logging. The second has a pattern consistent with credential stuffing and needs a shared limit or block. The third may justify step-up verification because the action can transfer control of an account. A site-wide proxy deny rule misses those distinctions.

This is also why a global risk score can be frustrating in production. A score can help rank events, but the operator still needs to know what raised it and which action is proportionate. Peakhour's concern is where that context meets enforcement: on the request path, before origin work and account state changes occur.

Residential Does Not Mean One Person

Public IP addresses are weak identity keys even when no proxy is involved. Carrier-grade NAT allows many subscribers to share address space; RFC 6598 reserves a shared range specifically for that purpose. Households, offices, mobile networks, privacy services, and public Wi-Fi also put unrelated users behind common addresses.

A residential proxy complicates the picture further. The address belongs to a real consumer network, but the request may have originated elsewhere. A clean reputation may mean the exit is new. A poor reputation may reflect one abusive user while ordinary subscribers share the same public address.

This cuts both ways:

Absence from a proxy list is not proof that the request is direct.
Presence on a proxy list is not proof that the request is malicious.

Google's 2026 disruption of the IPIDEA network showed the scale of the timing problem. Google identified hundreds of Android applications and thousands of Windows binaries connected with the proxy infrastructure, and observed many tracked threat groups using its exits. The investigation also found multiple SDK brands and reseller relationships feeding shared infrastructure. The details are in Google's IPIDEA disruption report.

A provider label or yesterday's reputation cannot carry the whole decision.

Build the Decision from the Request Outward

A workable policy starts with the route.

For each protected route, record:

what the request can read, change, or spend;
whether it creates expensive application or database work;
which identity is available, such as account, session, API key, or none;
whether an interactive challenge is possible;
what a false block would cost the user and the business;
which recent outcomes make repetition suspicious.

Then add the network and client evidence. A residential proxy result becomes more useful when it agrees with other observations: a breached credential, an unseen device, a fingerprint shared across rotating IPs, failed outcomes across many accounts, an invalid route sequence, or an abnormal request rate.

The policy can then choose among real actions:

Allow when the route is low risk and the session is otherwise consistent.
Log when the signal is new or the cost of intervention is higher than the current evidence supports.
Challenge when the client can provide more evidence and there is a safe recovery path.
Rate limit when repeated behaviour is the problem, especially across accounts, fingerprints, API credentials, or costly operations.
Block when the evidence is strong, harm is current, and narrower controls cannot protect the route.

Peakhour evaluates that context in the request path. Browser signals can add evidence when a browser is present, while API traffic can still be assessed without requiring JavaScript. The selected action and its inputs remain part of the decision record rather than disappearing into a standalone lookup.

Scores Need Reasons and Actions Need Owners

A security team should be able to answer three questions after a request is challenged or blocked:

Which observations changed the decision?
Which policy revision selected the action?
Did the action protect the route without breaking legitimate completion?

If the only retained field is risk_score: 87, review becomes guesswork. Keep the useful components: route, proxy result, IP category, fingerprint provenance, account or token state, recent failures, threshold state, action, policy revision, and origin outcome.

Every enforcement rule also needs an owner and an expiry condition. Proxy networks change. Client populations change. A rule created during an incident should not become permanent merely because nobody knows why it exists.

Start in observation mode on one sensitive route. Measure ordinary variation, proxy prevalence, successful completion, challenge outcomes, and false positives. Move to enforcement when the evidence supports a specific action. Roll back when the customer cost exceeds the risk reduction.

On a sensitive route, the proxy match may justify corroborating evidence or a reversible action. On a low-risk route, logging may be enough. In both cases, the team should be able to show which facts changed the decision and what happened afterwards. That is how proxy intelligence becomes an operable control rather than another label in a feed.

Two Lineages of TLS Fingerprinting: JA3, JA4 and Cisco Mercury

2026-07-26T09:00:00+10:00

It is tempting to draw the history of TLS fingerprinting as a single line: JA3, then JA4, with Cisco Mercury somewhere nearby. That version is tidy. It is also wrong.

Two strands of work developed around the same observation: a TLS ClientHello exposes enough information to say something useful about the software that created it. One strand concentrated on portable identifiers that could be logged and exchanged. The other concentrated on retaining protocol structure and combining it with evidence that could improve classification.

JA3 and JA4 belong mainly to the first strand. Cisco Mercury belongs mainly to the second. For the technical work that preceded JA3, see how TLS handshakes became fingerprints.

Before JA3

Passive fingerprinting predates TLS. Tools such as p0f identified operating-system characteristics from TCP/IP behaviour without sending probes to the target. Researchers later applied the same instinct to fields exposed during SSL and TLS negotiation.

In 2009, Ivan Ristić published an SSL handshake fingerprinting experiment that compared ClientHello messages from web clients. Marek Majkowski followed with a TLS fingerprinting patch for p0f in 2012. Lee Brotherston's FingerprinTLS later provided tools and a database for creating and matching TLS fingerprints.

Salesforce's JA3 project drew directly on that work. JA3 serialised five ordered ClientHello feature groups, removed GREASE values and calculated an MD5 digest. The result was compact enough to put in a log, share in threat intelligence or match in a rule. The archived JA3 repository documents both the format and its debt to FingerprinTLS.

JA3's compactness came with a cost. A digest does not explain why two clients differ. Ordered inputs also meant that harmless permutation could produce a different value. Most importantly, a matching digest did not prove that the traffic came from one application. Programs built on a shared TLS library could produce the same ClientHello.

The JA4 branch

FoxIO introduced JA4 in 2023 after Chrome began permuting TLS extension order. Peakhour saw the practical effect of that change in our Chrome extension-randomisation analysis: a representation that preserved extension order split one common browser family into a large number of values.

JA4 canonicalises selected ClientHello features before hashing them. Its a_b_c structure keeps a readable summary in the first section, a digest of sorted cipher identifiers in the second, and a digest derived from extensions and signature algorithms in the third. This makes the components useful independently. An analyst can group on part of a JA4 value without pretending every field is identical.

That is deliberate lossy compression. JA4 is useful because it throws away distinctions its designers judged unstable or unhelpful for this job. It is not a reversible rendering of the ClientHello, and its truncated SHA-256 sections do not provide a measure of semantic distance. The exact format is set out in the FoxIO JA4 technical specification.

JA4 is one method. JA4+ is the name used for a wider family that includes server, HTTP, TCP, SSH, certificate and other fingerprints. Those methods do not all share JA4's licence, which matters if the fingerprints will be built into a commercial service.

The Cisco research branch

Cisco's work took a different route. In 2016, Blake Anderson, Subharthi Paul and David McGrew studied how observable TLS features could help distinguish malware from enterprise traffic without decrypting it. Their paper, Deciphering Malware's Use of TLS, also dealt with an awkward issue that still matters: malware-sandbox data can bias a classifier.

Anderson and McGrew's 2017 operating-system fingerprinting research combined evidence from TCP/IP, TLS and HTTP across multiple sessions. The point was not to mint a universally portable hash. It was to ask whether several kinds of passive evidence, accumulated over time, reduced uncertainty about the endpoint.

The same multi-protocol approach appears in Cisco's Joy and Mercury projects. Mercury's Network Protocol Fingerprinting format represents selected protocol features as a tree of hexadecimal byte strings. The full form retains structure. Its naming can state the protocol and fingerprint rule version. An optional compact hash can be used where a fixed-length value is more practical. Cisco's current draft NPF specification defines fingerprints for TLS, QUIC, TCP, HTTP, SSH and other protocols.

Mercury also keeps fingerprint generation separate from process classification. That distinction is easy to miss.

A fingerprint and a label are different things

In Cisco's 2020 paper, Accurate TLS Fingerprinting Using Destination Context and Knowledge Bases, the authors found that common TLS fingerprints mapped to many processes. For the 100 most prevalent fingerprints in their May 2020 data, the median was 24.5 process names per fingerprint.

Their response was not a longer hash. They combined the fingerprint with destination address, port and server name, then used a weighted naïve Bayes classifier backed by a continually updated knowledge base.

That produces an inference, not a property embedded in the fingerprint string. The result depends on labelled observations, their age, the monitored environment and the destination evidence available for the connection. The open Mercury repository can generate fingerprints without possessing Cisco's production knowledge base.

This is the clearest difference between the two lineages:

JA3 and JA4 define portable representations for selected TLS observations.
Mercury NPF retains a richer, versioned representation that can be fed into a separate analysis system.
Mercury's destination-context classifier is another layer again.

None of these layers proves who made a request.

Where the lineages meet

The projects respond to many of the same protocol changes. Both JA4 and recent Mercury formats sort selected TLS fields to reduce instability caused by permutation. Both deal explicitly with GREASE. Both recognise that operators need compact values for logs as well as enough detail to investigate differences.

They make different trade-offs. JA4 is convenient for grouping and interchange. Mercury's full NPF form is better suited to inspection and to analysis that benefits from retained structure. JA4's wider family adds fingerprints for other observations, while Mercury is also a packet metadata collector and protocol-analysis library. Comparing only the length of their hashes misses most of the design.

The lab article makes that concrete. In one ClientHello, three fingerprints, we run JA3, JA4 and Mercury against the same packet capture, record the exact tool versions and compare what each output preserves.

Before JA3: How TLS Handshakes Became Fingerprints

2026-07-19T09:00:00+10:00

JA3 is often treated as the beginning of TLS fingerprinting. It was not. Its real contribution was narrower and, operationally, just as important: JA3 took a set of ideas that had been explored for years and turned them into a small identifier that ordinary security tools could carry.

The path to that format runs through an SSL Labs experiment in 2009, an experimental p0f extension in 2012 and Lee Brotherston's FingerprinTLS work in 2015. Each step answered a different question. What can the cleartext handshake reveal? Which details survive often enough to identify a client? How do you turn those details into something an analyst can match? And, finally, how do you make the result portable?

This is a documented lineage where the authors themselves cite the earlier work. The claim that JA3's decisive move was simplification is our interpretation of those sources, not a claim that every project shared one design plan.

2009: the cipher list as a client signature

In June 2009, Ivan Ristić described an experiment in HTTP client fingerprinting using SSL handshake analysis. He was working on SSL Labs and noticed a useful property of the initial handshake: clients sent different lists of supported cipher suites, and those lists were visible before encryption began.

The important observation was not that any one cipher identified a browser. It was the combination of ciphers a client offered. Ristić recorded the entire list as a signature and compared it with the HTTP User-Agent seen after the connection was established. He then published examples collected from real SSL handshakes, showing that the approach could separate a range of browsers, command-line clients and crawlers.

This early method was deliberately modest. It concentrated on the cipher-suite list. It did not define a general-purpose fingerprint containing every useful ClientHello feature, and it did not claim that a signature proved the identity of a process.

Even so, the core technical idea was in place:

unencrypted ClientHello
  -> implementation-dependent choices
  -> repeatable signature
  -> comparison with previously observed clients

The handshake was no longer just cryptographic setup. It was passive metadata about the software constructing it.

2012: p0f adds order, extensions and matching rules

Marek Majkowski pushed the idea further in his 2012 SSL fingerprinting patch for p0f. p0f was already known for passive operating-system fingerprinting at lower layers. Majkowski applied a similar signature-and-database model to SSL and TLS ClientHello messages.

His post explicitly credits Ristić's 2009 work, then points to two details he believed deserved more attention: ordering and TLS extensions. The patch represented a fingerprint as four fields:

requested version : ordered ciphers : ordered extensions : flags

That is a meaningful technical step. Cipher suites are normally sent in preference order, and extension order can differ between implementations. Retaining those sequences gives the signature more discriminatory power than an unordered inventory. The flags recorded other behaviours, such as compression support or an unusual relationship between record and handshake versions.

The implementation did more than print a string. It matched the result against a database of signatures that could contain wildcards and return a browser family, possible versions and sometimes a platform. The original p0f patch and notes are still useful because they expose the boundary between observation and label: one part generates the raw signature; another compares it with knowledge gathered elsewhere.

Majkowski also wrote with appropriate caution. His notes say that a ClientHello can sometimes identify the underlying SSL library and, for software with a custom build or distinctive feature set, may narrow the application version. "Sometimes" matters. Two applications using the same TLS stack can look alike, while one application can change its handshake when its library, configuration or build changes.

The p0f work did not become the universal exchange format for TLS fingerprints. It did, however, demonstrate most of the ingredients that later systems would reuse: selected fields, preserved order, a serialised signature and a separate matching database.

2015: FingerprinTLS turns a method into a toolset

Lee Brotherston's 2015 work expanded the practical surface again. His DerbyCon and SecTor presentation, Stealthier Attacks and Smarter Defending with TLS Fingerprinting, examined TLS fingerprinting from both sides: defenders could recognise unexpected software, while an operator could alter a client's handshake to blend in or evade a simplistic rule.

The associated FingerprinTLS repository packaged the approach into several working parts:

FingerprinTLS detected TLS sessions on a live interface or in a PCAP, created fingerprints and matched them;
fingerprints.json stored the known fingerprint database;
Fingerprintout exported observations into other forms, including Snort and Suricata rules.

This was broader than calculating a digest. It was a workflow for capturing a handshake, retaining many of its characteristics, associating that observation with known software and moving the result into operational tools.

The project also made an awkward truth visible: rich fingerprints are not especially convenient interchange formats. FingerprinTLS could inspect more detail, but exporting that detail into a rule language could lose accuracy. Its README warned that Snort and Suricata exports might require tuning because their rule syntax could not express the full matching logic.

That trade-off set the stage for JA3. A detailed signature helps an analyst explain why two handshakes differ. A compact value is easier to add to a connection log, compare across sensors and share with another team. It is difficult to optimise one representation for both jobs.

2017: JA3 chooses portability

Salesforce open-sourced JA3 in 2017. John Althouse's original JA3 announcement directly cites Ristić's 2009 post and Brotherston's 2015 research. It also states the team's design requirement plainly: the result had to work with existing monitoring systems and load balancers, be independent of the destination, and be easy for other tools to consume.

JA3 selected five ordered ClientHello feature groups:

TLS version,
cipher suites,
extension types,
supported groups,
elliptic-curve point formats

It rendered their numeric values into a comma-separated string, removed GREASE values, then calculated an MD5 digest. A long handshake description became a 32-character identifier.

MD5 was not being used here to protect a password or prove integrity. It was a compact naming function. The security weakness of MD5 still means a JA3 value should not be treated as proof, but changing to a stronger digest would not solve the more common identification problem: unrelated software can naturally produce the same selected features, and software can deliberately copy another client's ClientHello.

The simplification was substantial. Compared with FingerprinTLS, JA3 retained fewer fields and discarded the explanatory structure once the string was hashed. Compared with the p0f patch, it did not carry matching wildcards or classification rules in the fingerprint. What it gained was a common unit that could fit almost anywhere an operator could put a string.

That was why JA3 travelled. A sensor could calculate the value, a SIEM could index it, an intelligence report could publish it and a rule could match it without every participant adopting the same fingerprint database or packet parser.

What JA3 inherited, and what it left behind

The documented history supports a few specific claims:

Ristić showed in 2009 that an unencrypted SSL handshake, particularly its cipher list, could distinguish HTTP clients.
Majkowski's 2012 p0f work explicitly built on that experiment and added ordered extensions, behavioural flags and database matching.
Brotherston's 2015 research and FingerprinTLS made detailed capture, matching, creation and export available as a standalone toolset.
Salesforce cited the earlier work when it released JA3 and designed a smaller representation for existing operational systems.

It does not support treating a fingerprint as an application identity. Every stage depended on a set of observed features and, when a software name was returned, knowledge collected outside the handshake itself. The label could be useful without being certain.

That distinction is easier to see when the formats are run side by side. Our reproducible lab feeds one ClientHello to JA3, JA4 and Cisco Mercury and records both the compact outputs and the detail each format preserves.

JA3 was not the final step either. JA4 later changed the normalisation and output structure to cope with modern sources of instability, while Cisco's research followed a more structured, context-aware path. Those are separate branches, not one straight succession. We trace them in Two Lineages of TLS Fingerprinting.

The useful lesson from the early history is not who coined the first fingerprint. It is that the representation determines the work you can do with it. Rich detail helps investigation. Compact identifiers help distribution. Neither turns a handshake into an identity document.

A Network Fingerprint Is a Cohort, Not a Client

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

A TLS fingerprint usually tells you that two connections look alike under a particular set of rules. That is useful. It is not the same as showing that they came from the same client.

The distinction becomes obvious when a common TLS library sits underneath many programs. Those programs can offer the same protocol version, cipher suites, extensions and signature algorithms. A fingerprint built from those fields groups them together even though their purpose, owner and risk are different.

The reverse also happens. One application can generate several fingerprints after a browser update, operating-system change, feature rollout or configuration difference. A fixed application name does not imply a fixed ClientHello.

The safest mental model is a cohort: traffic that looks the same after a fingerprint method has selected and normalised its inputs.

The method defines the cohort

JA3 preserves the order of its selected ClientHello feature lists. Change the order and the MD5 value changes. JA4 sorts selected identifiers before calculating two of its components, so permutations that split a JA3 cohort may remain grouped under JA4.

Cisco Mercury can preserve more packet-derived structure in its full Network Protocol Fingerprint. Different Mercury rule versions also make different normalisation choices. A tls/2 value is therefore not just a longer spelling of JA4. It is the result of another feature-selection contract.

This means there is no format-independent "real fingerprint" hiding underneath the tools. Each method answers its own equivalence question: which differences count, and which should be ignored?

Our same-PCAP lab demonstrates that point without relying on a hypothetical browser. The three tools inspect the same ClientHello and produce representations with different retained detail.

Common does not mean safe

A popular browser fingerprint will naturally appear in a great deal of legitimate traffic. An attacker can also use a browser, drive one through automation, or imitate its TLS stack. Matching a common browser value therefore says little about intent by itself.

The opposite shortcut is just as risky. An uncommon fingerprint is not proof of malware. Internal tools, older mobile applications, embedded devices, accessibility software and regional client variants can all be rare in one dataset.

Rarity is relative to the observation point. A fingerprint that is common across a public content site may be unusual on an administrative API. A value common in one country, network or month may be rare in another.

Capture point changes what you see

TLS fingerprinting only works where the relevant handshake is visible. At an origin behind a CDN or reverse proxy, the TLS connection may have been terminated and replaced upstream. The origin can then observe the proxy's connection rather than the end user's ClientHello unless the edge explicitly forwards a derived fingerprint.

That forwarded value also needs provenance. Operators should know which implementation and format version produced it, whether it came from the client-facing connection, and whether middleware transformed or sampled the traffic.

Without that information, two values that look compatible may have been generated under different rules. Fastly has documented how implementation differences can undermine the portability promised by a shared hash in The State of TLS Fingerprinting.

Context can improve an inference

Cisco's Mercury research is helpful because it does not hide the ambiguity. The 2020 destination-context paper reports that one TLS fingerprint often maps to tens or hundreds of process names. Its classifier adds destination IP address, port and server name, backed by a labelled knowledge base, to rank the possible processes.

That is stronger than treating a bare fingerprint as an application name. It is still conditional. Change the environment, the age of the knowledge base, the available destination fields or the software population and the probabilities can change. The paper's reported accuracy belongs to its datasets and experimental design, not to every network that runs Mercury.

JA4 deployments often add context too. A security platform might combine the JA4 value with request rate, geography, path, account state or observations from other customers. Those extra fields are not secretly part of JA4. They are features in the surrounding detection system.

Use fingerprints where grouping helps

Fingerprints earn their place when grouping similar connections improves an investigation or control. Examples include:

counting login failures across rotating IP addresses;
finding a TLS stack that appeared at the start of an incident;
comparing a claimed browser with HTTP and browser-side evidence;
monitoring drift after a client or library release;
selecting traffic for review before writing a narrower rule.

For the decision and enforcement consequences, see Fingerprints are evidence, not identity. The protocol-specific conclusion here is narrower: a matching TLS fingerprint places connections in a cohort defined by one method. It cannot tell you, on its own, who is on the other end.

The practitioner follow-up, Using network fingerprints in bot and rate-limit decisions, turns that boundary into a route-scoped policy and rollback model.

From Joy to Mercury and EVE: Following Cisco's Network Fingerprinting Work

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

Cisco's network fingerprinting work is often compressed into a neat product story: Joy became Mercury, and Mercury became the Encrypted Visibility Engine. There is a real lineage here, but that sentence hides more than it explains.

Joy and Mercury are public software projects. Network Protocol Fingerprinting is a representation. The 2020 destination-context paper describes a classification system and the data needed to support it. EVE is a Cisco Secure Firewall capability backed by Cisco's operational data and machine-learning systems.

Those pieces share ideas, authors and engineering history. They are not four names for the same thing.

Joy started with flow records, then looked inside them

Cisco released Joy as a BSD-licensed tool for collecting network flow and intraflow data from live traffic or PCAP files. Its basic unit was recognisable to anyone who had worked with NetFlow or IPFIX: a flow with addresses, ports and counters. Joy then added observations from within that flow.

Those observations included packet lengths and arrival times, byte distributions, TLS record sequences, visible TLS handshake fields, DNS data and selected HTTP fields. It wrote the results as JSON so researchers could feed them into analysis tools without building a packet parser first.

That breadth matters. Joy was not originally just a ClientHello hash generator. It was a network-research instrument for asking what could still be learned from traffic when the application payload was encrypted.

The research around Joy shows how Cisco used it. The 2016 paper Deciphering Malware's Use of TLS (without Decryption) combined conventional flow measurements, packet-length and timing sequences, byte distributions and visible TLS handshake features. Its authors were interested in malware detection and family attribution, but they were also explicit about dataset bias. A sandbox operating system or its default TLS library could become an accidental shortcut for the classifier.

In 2017, OS Fingerprinting: New Techniques and a Study of Information Gain and Obfuscation used an extended Joy collector to record features from TCP SYN packets, TLS ClientHello messages and HTTP requests. The study combined evidence across protocols and sessions rather than expecting one handshake to provide a definitive operating-system label.

The enduring idea was broader than any one model: retain useful network observations, join them to trustworthy labels where possible, and test what the combined evidence can support.

Mercury narrowed and hardened the collection path

The Joy repository now directs readers to Mercury for Cisco's more recent fingerprinting tools and data. Mercury carries forward the packet-metadata and JSON-output model, but it is a separate implementation with a stronger focus on fast capture, protocol fingerprints and online analysis.

The public repository contains a C++ application and library, along with the portable Python implementation pmercury. Mercury can read PCAPs or live traffic, identify supported protocols and emit selected metadata. On Linux, its native collector uses the kernel's AF_PACKET TPACKETv3 path and multiple workers. The repository describes use in some production applications, while still asking users to treat the open software as beta.

Mercury also makes a useful boundary visible in its JSON:

packet
  -> protocol metadata
  -> fingerprint object
  -> optional destination-context analysis
  -> analysis object

The fingerprint is an observation. The analysis is an inference made from that observation and other data. They should not be collapsed into one label.

NPF is the representation, not the classifier

Mercury's fingerprints use Cisco's Network Protocol Fingerprinting format. NPF selects characteristic fields from an initial protocol message, normalises values that should not distinguish implementations, and writes the retained structure as a tree of hexadecimal byte strings.

A full TLS fingerprint can therefore be inspected. Its tls/2 prefix identifies the protocol and rule version; parentheses and brackets preserve the selected tree structure and sorting decisions. Mercury can also use a compact hash nickname when fixed-length storage is more useful than inspection.

The draft NPF specification covers more than TLS. It documents rules for protocols including QUIC, TCP, HTTP, SSH, STUN and OpenVPN. This is one point at which the Joy heritage remains visible: the project treats protocol evidence as a network-wide problem, not solely as a way to name TLS clients.

Our guide to Cisco Mercury fingerprinting separates the collector, NPF representation, knowledge base and classifier in more detail. Inside a Mercury NPF fingerprint works through the full notation.

The 2020 paper made the attribution problem explicit

A fingerprint is useful for grouping similar protocol implementations. It is often a poor application name.

Blake Anderson and David McGrew quantified that problem in Accurate TLS Fingerprinting Using Destination Context and Knowledge Bases. TLS libraries are shared. Common fingerprints can map to tens or hundreds of processes. A dictionary that assigns one process name to one fingerprint will therefore produce convincing-looking false positives.

The paper added three destination features to the TLS fingerprint: destination address, destination port and the TLS server name, when present. A weighted naive Bayes classifier used those features and prevalence counts from a labelled knowledge base to rank candidate processes.

The knowledge base was the difficult part. The researchers joined network observations to endpoint process data, generated fresh knowledge bases daily and merged them into an operational view. They also used malware-sandbox observations. The paper describes billions of connections, a changing population of fingerprints and destinations, and the need to discard stale data.

Its reported results were strong, including a process-family F1 score above 0.99 and high precision and recall for the malware task. Those figures belong to the paper's datasets and evaluation. They are not an accuracy guarantee for a Mercury installation downloaded from GitHub.

The authors also documented important limits: their endpoint data was dominated by desktop Windows and macOS systems, mobile and IoT coverage was absent, and most data came from one enterprise. They wrote that a site could build a custom knowledge base if it had suitable endpoint ground truth and network monitoring, but acknowledged the significant initial investment.

That is the operational lesson. A classifier is not made current by having a good fingerprint format. It stays current through labelled collection, joining, curation, expiry and evaluation.

For a closer reading, see how destination context changes TLS attribution.

EVE puts the research into a firewall product

Cisco describes its Encrypted Visibility Engine as work based on that earlier destination-context research. EVE first appeared in Secure Firewall 7.1 as a disabled-by-default experimental beta for visibility only; it did not enforce actions and Cisco warned that it could produce false positives. The 7.2 release notes say EVE began working with QUIC and allowed high-confidence process assignments to feed application policy. Version 7.3 specifically added HTTP/3 and SMB-over-QUIC detection, along with indication-of-compromise events for unsafe applications.

In Cisco's account of how EVE detects malicious use of trustworthy cloud services, the runtime inputs have the same recognisable shape:

an NPF representing client-side protocol characteristics; and
server context such as address, port and domain name.

EVE uses machine learning over Cisco's labelled data to estimate the client process and detect suspicious encrypted traffic without decrypting its payload. Cisco says its training data is refreshed daily with network samples joined to endpoint ground truth, with additional malicious observations from Cisco Secure Malware Analytics.

This is the clearest public link from NPF and the 2020 paper to the commercial system. It is also where careful wording matters most.

The public Mercury repository is not a source release of the complete EVE service. Building Mercury does not provide Cisco's continuously collected production dataset, its current models, Secure Firewall integration, Talos context or product policy behaviour. Conversely, the fact that EVE uses NPF does not mean every detail of its current implementation is present in the open repository or frozen at the method described in the 2020 paper.

Open code, published research and a maintained security product have different release cycles and different evidence behind them.

What the lineage actually establishes

There is a coherent progression:

Joy
  broad flow and intraflow metadata for research

Mercury + NPF
  faster collection and versioned, multi-protocol fingerprints

2020 destination-context system
  fingerprints joined to destinations and endpoint labels

EVE
  Cisco-maintained classification in Secure Firewall

This is a lineage of ideas and systems, not a promise that each box is a drop-in edition of the next one.

Joy established a practical way to collect visible evidence around encrypted flows. Mercury made protocol fingerprinting a more explicit and efficient part of that collection. NPF gave those fingerprints a structured, versioned form. The destination-context work showed why labelled, continuously refreshed context was necessary for process attribution. EVE operationalised those ideas inside a commercial firewall environment with data and integrations that do not ship with the public collector.

That history also explains why Cisco's branch of fingerprinting developed differently from JA3 and JA4. A portable hash is useful for logging and exchange. Cisco's work kept returning to a harder question: what additional evidence, labels and maintenance are required before a network observation can support a process assessment?

Neither approach turns a handshake into identity. Our two lineages of TLS fingerprinting article places Cisco's work alongside JA3 and JA4. The reproducible one ClientHello, three fingerprints lab shows the format differences without relying on any vendor classification database.

What an Open Network Fingerprint Database Should Publish

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

An open fingerprint database should let another researcher disagree with it.

That requires more than a hash and an application name. The row needs to show which bytes produced the fingerprint, how the label was established, where the traffic was observed, which software generated the value and what competing explanations remain plausible.

Most public databases were built for a narrower purpose. Historical JA3 lists made values easy to share. Threat feeds made malware observations easy to match. Nmap and p0f made signature rules executable. TLS observatories count what appears at their vantage points. Those are sensible designs for their jobs.

They do not yet add up to a reusable open ground-truth corpus.

Start with observations, not verdicts

The fundamental database object should be an observation:

{
  "observation_id": "...",
  "observed_at": "2026-07-12T00:00:00Z",
  "capture": {
    "position": "client-facing edge",
    "collector": "mercury",
    "collector_revision": "3172786...",
    "source": "controlled-client-run"
  },
  "fingerprints": [],
  "labels": [],
  "evidence": [],
  "licence": "..."
}

The observation can then carry several fingerprint methods and several candidate labels. This is safer than making the hash the primary truth and forcing one application name into the same row.

Store the reversible material

Each fingerprint entry should contain the published identifier and the material used to derive it:

{
  "method": "ja4",
  "implementation": "FoxIO Python",
  "implementation_revision": "...",
  "value": "t12d2709h2_..._...",
  "raw_value": "t12d2709h2_002f,...",
  "source_message_digest": "sha256:...",
  "truncated": false
}

For JA3, retain the five-part source string beside the MD5. For JA4, retain JA4_r where collection policy permits it. For Mercury, retain the complete versioned NPF string rather than only its hash nickname. For HASSH, retain the algorithm lists. For a matcher rule, retain the response bytes or sanitised fixture that satisfied it.

This permits field-level comparison, implementation testing and migration when a definition changes. It also exposes incompatible values hidden behind a common field name.

Make labels many-to-many

Labels should be separate evidence-backed assertions:

{
  "type": "process",
  "value": "example-client",
  "version": "1.2.3",
  "source": "endpoint-telemetry-join",
  "review_state": "reviewed",
  "confidence": 0.94,
  "first_seen": "...",
  "last_seen": "..."
}

One fingerprint can have several process labels because applications share libraries. One process can have several fingerprints because versions, platforms and configurations differ. The schema should preserve counts and conflict instead of selecting one winner during ingestion.

Cisco Mercury's public resource schema points in this direction: fingerprint entries contain candidate processes, observation counts, operating systems and destinations. The production database is private, but the many-to-many model is the right starting point.

Describe how ground truth was produced

Use a controlled vocabulary for evidence sources:

controlled_capture
endpoint_process_join
malware_sandbox
reviewed_pcap
active_probe_match
passive_observation
community_submission
derived_from_external_database

Each type needs its own metadata. An endpoint join should record the join window and ambiguity rules. A controlled capture should name the client build, operating system and generation script. A malware sandbox label should identify the sample and distinguish the sandbox process from the malware process. A community submission should identify what a reviewer actually checked.

Derived labels should never masquerade as independent evidence. If a mapping was imported from an older JA3 list, cite that row and keep its original uncertainty.

Separate prevalence from classification

Prevalence belongs in observation aggregates:

{
  "source": "university-vantage-a",
  "first_seen": "...",
  "last_seen": "...",
  "count": 184233
}

It should not silently increase application-label confidence. A common fingerprint is not necessarily well-labelled; a rare fingerprint is not necessarily suspicious.

The TLS Fingerprint Observatory demonstrates the value of publishing counts even when labels are missing. Its large unlabelled TLS corpus is more useful for prevalence research than a catalogue filled with guesses.

Represent threat observations explicitly

A malware feed should attach an observation, not overwrite the fingerprint's identity:

{
  "type": "malware-sandbox-observation",
  "family": "example-family",
  "sample_sha256": "...",
  "observed_at": "...",
  "known_good_evaluation": "not-performed"
}

This retains the warning published by sources such as SSLBL. It allows a consumer to ask whether a fingerprint was seen in malware without treating every matching benign process as infected.

Publish validation sets and negative evidence

A useful database should include:

controlled positive captures;
known-good observations that share supposedly malicious fingerprints;
deliberately conflicting labels;
client upgrades that changed fingerprints;
malformed and truncated handshakes;
captures before and after a TLS-terminating proxy;
implementation conformance cases.

Negative and conflicting evidence is not database dirt. It tells consumers where a label stops working.

Version the data and the interpretation

Every release should state:

schema version;
database snapshot identifier;
fingerprint implementation revisions;
collection time range;
label additions, removals and merges;
retired mappings;
licence changes;
reproducible validation results.

Consumers should be able to pin a snapshot and explain which database caused a decision. A live service may remain convenient, but an incident review needs the state that existed when the event was classified.

Make licensing part of the schema

Fingerprint method, implementation and dataset rights are separate.

Core JA4 is BSD-licensed. Other JA4+ methods use different FoxIO terms. Nmap's data files use the Nmap Public Source License. A combined historical repository may contain rows imported under different licences. An API may permit lookup but prohibit bulk redistribution.

Store a licence or source-rights reference for each imported dataset and, where necessary, each record. If the rights are unclear, publish a pointer and transformation recipe rather than republishing the row.

Provide a confidence model that can be audited

A score without calibration is decoration. For each label type, document:

what the score estimates;
the labelled validation set;
true-positive and false-positive definitions;
treatment of unseen applications;
time and environment holdouts;
how conflicts and stale observations affect the score.

Where calibration is unavailable, use review states such as submitted, reproduced, reviewed and contested instead of inventing numeric precision.

The minimum viable open record

If full packet evidence cannot be published, a useful minimum is:

method and rule version
implementation revision
compact and raw fingerprint
candidate label, including version/platform
ground-truth method
capture position
first and last seen
observation count
confidence or review state
evidence reference
licence

That is more expensive than a CSV containing hash,name. It is also what makes the mapping useful outside the environment and assumptions of its original collector.

The public ecosystem already contains most of the parts: JA4DB's cross-method model, the TLS observatory's prevalence data, Mercury's candidate-process and destination schema, FingerprinTLS's retained ClientHello fields, and executable fixtures in matcher projects such as Rapid7 Recog. The missing step is to combine those strengths without erasing provenance.

For the current resource landscape, see Public Network Fingerprint Databases and What They Cover. For the import checklist, see How to Evaluate a Network Fingerprint Database.

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.

Does TLS Fingerprint Canonicalisation Hide Attacker Variation? How to Test It

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

Canonicalisation solves a real problem in TLS fingerprinting. If two ClientHello messages differ only because a client shuffled its extensions, treating them as unrelated fingerprints creates noise. Sorting those extensions puts the messages back into one cohort.

It also destroys the original order.

That is not automatically a mistake. A fingerprint is useful partly because it ignores variation that does not help with the job at hand. The unanswered question is whether some of the discarded variation separates ordinary client behaviour from automation, scanners or deliberate evasion.

Our one-ClientHello lab cannot answer that. It proves that three pinned implementations produce recorded representations from the same bytes. It says nothing about a population of clients or attackers. Answering the canonicalisation question needs a corpus and a labelled experiment.

What gets collapsed?

JA3 removes GREASE values but otherwise preserves the order of the selected cipher, extension, supported-group and point-format lists. Change one of those ordered inputs and the MD5 digest changes.

JA4 deliberately defines a broader equivalence class. Its canonical b section hashes sorted cipher identifiers. Its c section hashes sorted extension identifiers followed by signature algorithms in their advertised order. SNI and ALPN extension codes are omitted from that list because related information is represented in the readable a section. FoxIO's JA4 specification documents those choices.

Cisco Mercury makes the rule version visible. In the current draft NPF specification, the older unversioned TLS format retains extension order, tls/1 sorts all represented extensions, and tls/2 sorts selected extensions while applying more specific inclusion and normalisation rules.

These methods do not merely encode the same fingerprint differently. They define different ideas of “the same”.

Why Chrome forced the issue

Chrome's extension permutation rollout showed why order-sensitive identifiers can become operationally brittle. Peakhour's 2023 analysis recorded a sharp rise in unique order-sensitive signatures after the change. The browser family had not suddenly split into thousands of independent TLS implementations. Much of the new variation came from ordering.

Sorting is an effective response if the goal is to recover the implementation cohort. It is also consistent with Chrome's stated reason for making the change: servers and middleboxes should not depend on one fixed extension order.

But an analyst may have another question. Does a tool permute extensions using the same mechanism and constraints as the browser it imitates? Does a scanner generate an ordering distribution that differs from Chrome's? Does malware preserve the static order supplied by its TLS library while claiming a Chrome user agent?

A canonical JA4 can group those handshakes even when their ordering behaviour differs. That is expected. JA4 answered the cohort question, not every possible behavioural question.

The wrong experiment

Counting how many unique raw fingerprints map to one canonical fingerprint is a useful descriptive statistic. It is not, by itself, evidence that canonicalisation weakened detection.

A common browser with extension permutation should produce many raw orders. A large raw-to-canonical ratio may therefore be evidence of normal deployment scale. Calling every collapsed value a loss of “fidelity” assumes that all variation was useful before the test has measured its relationship with any outcome.

The reverse shortcut is also wrong. Stable canonical values do not prove that sorting is harmless for every detector. A field can be poor for application identification but useful for distinguishing one implementation path, library version or evasion technique.

The experiment needs labels and a defined decision.

A testable study design

We would structure the study around observations, transformations and outcomes.

1. Preserve the original ClientHello

Store the permitted raw handshake metadata or a reversible representation alongside derived identifiers. Record:

capture point and TLS termination path;
sensor implementation and revision;
timestamp and software-release period;
JA3 source string and digest;
JA4, JA4_r, JA4_o and JA4_ro where the implementation provides them;
a full, versioned Mercury NPF string;
HTTP and browser claims kept separate from the TLS representation.

Without the raw or reversible material, a later study cannot recover the ordering that canonicalisation removed.

2. Define labels that do not come from the fingerprint

Labels need an independent source. Depending on the environment, that could include controlled browser runs, endpoint process telemetry, sandbox execution, signed test clients or reviewed incident cases.

Do not label traffic as Chrome because its JA4 resembles Chrome and then report that JA4 identifies Chrome. That is circular evaluation.

Cisco's destination-context research used joined endpoint and network observations to build process labels. The paper also discusses how sandbox and environment choices affect the resulting knowledge base. Accurate TLS Fingerprinting Using Destination Context and Knowledge Bases is useful here because it treats ground truth as a system component rather than a list of famous hashes.

3. Compare representations at the same grouping level

Measure at least:

raw ordered representation;
canonical JA4;
useful JA4 component combinations such as JA4_ac;
Mercury rule versions that preserve or sort different structures;
raw ordering features added beside the canonical value.

The comparison should use the same captures, time split and labels. Otherwise a newer fingerprint method can appear better simply because it was evaluated on newer or cleaner data.

4. Use time and environment holdouts

Randomly splitting individual connections leaks near-duplicates between training and test data. Prefer a forward time split and, where possible, a separate network or capture environment.

That exposes two operational questions: does the result survive a browser or library update, and does it survive outside the environment where the labels were collected?

5. Measure decisions, not just uniqueness

Useful measurements include:

collision and fragmentation rates by independently labelled client;
precision and recall for a stated classification or detection task;
false-positive rates on high-volume legitimate cohorts;
stability across software releases;
the incremental value of raw order after canonical identifiers and context are already present;
review volume at an actual alert or policy threshold.

If adding original order improves a classifier by a tiny amount but creates millions of unstable keys, the operational cost may outweigh the gain. If it separates a specific impersonation technique with few false positives, keeping it as a secondary feature may be worthwhile.

Keep both when the questions differ

The design choice does not have to be raw or canonical.

A compact canonical identifier is useful for grouping, counters, joins and rules. A raw or reversible representation is useful for investigation, feature research and migration when the canonical rules change. Storage policy can keep the compact value broadly and retain detailed material for a bounded sample, selected security events or an approved research window.

That split also makes detector claims easier to audit. The rule can say it grouped on JA4 while the event retains enough source material to explain which handshake produced the value.

What we can say now

Sorting removes ordering information. It reduces fragmentation caused by clients that permute their lists. Both statements follow from the format definitions and can be demonstrated with controlled captures.

Whether the removed order contains useful attacker variation is an empirical question tied to a dataset, capture point, label source and decision. Until that study is run, the honest position is to preserve the evidence needed to test it and avoid turning either uniqueness or stability into a claim of detection accuracy.

For the wider format comparison, see Mercury vs JA4 vs JA3. For the identity boundary that applies to every result, read A network fingerprint is a cohort, not a client.

Using Network Fingerprints in Bot and Rate-Limit Decisions

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

A network fingerprint is a useful rate-limit key. It is a poor verdict.

That sounds like a small distinction, but it changes how a control behaves. A limit keyed only by source IP can miss a distributed scraper moving through thousands of addresses. Add a TLS or HTTP fingerprint and the requests may fall into a recognisable cohort. The operator can count and compare them even while the IPs rotate.

The same key can also group thousands of ordinary users running the same browser release. If the control reads “this fingerprint is a bot” and blocks it everywhere, the grouping feature has become a false-positive multiplier.

The practical job is to use the fingerprint where grouping helps, then make the decision from the route, behaviour and consequence. This article sets out one way to do that.

Start with the route, not the fingerprint

A request for a cached image and a request to submit a password do not deserve the same policy. Neither do a search request and an export that starts an expensive database job.

Before adding fingerprint data, classify the routes that matter:

what the request can change or disclose;
whether it consumes scarce application or origin capacity;
whether a legitimate user can retry safely;
whether the client can complete a challenge;
which identity is available, such as an account, session, API key or no identity at all;
what an incorrect block would cost.

This route map sets the response. An unfamiliar cohort fetching public content might only be worth observing. The same cohort attempting passwords across many accounts may justify a tight shared limit. A fingerprint mismatch on an authenticated payment action may call for step-up verification rather than a network block.

Route sensitivity also prevents a common emergency mistake: applying a site-wide rule because an attack was visible on one endpoint. Narrow rules are easier to explain, test and remove.

Use the fingerprint as a cohort key

JA3, JA4 and Cisco Mercury do not identify a person or device. Each method selects and normalises protocol fields, then groups connections that look equivalent under those rules. Our same-ClientHello lab shows how three methods produce three different representations from one handshake.

That makes the fingerprint useful for questions such as:

Are login failures arriving from many IP addresses but one narrow set of client stacks?
Did an expensive API route suddenly attract a new protocol cohort?
Does traffic claiming to be a browser have a consistent TLS, HTTP and header shape?
Did a cohort disappear after an abusive tool changed version, or did the fingerprinting rules change underneath us?

The key should be composite. A workable rate counter might resemble:

route_class + fingerprint_method + fingerprint_version + fingerprint_value

Depending on the abuse case, add an account, tenant, API credential, ASN or country. Do not throw every field into every key. An over-specific key divides a distributed campaign into buckets too small to see; an over-broad key combines unrelated users.

Run a few candidate keys in observation mode and measure their bucket sizes. Look at both tails. A key that places half the site's users in one bucket is too blunt for direct enforcement, however suspicious that bucket looked during one incident.

Record where the value came from

Fingerprint provenance is operational data, not documentation trivia.

At an origin behind a CDN or reverse proxy, the visible TLS connection may belong to that intermediary. A fingerprint forwarded in a header might describe the original client-facing connection, or it might describe a later hop. The receiving service cannot tell from the hash alone.

For each event, keep at least:

method:       ja4
version:      pinned implementation or rule version
value:        t13d..._..._...
capture:      client-facing edge
source:       named collector or trusted forwarding hop
observed_at:  timestamp
policy:       policy identifier and revision
action:       observe, challenge, rate-limit or block

Where the format permits it, retaining the selected raw fields or unhashed representation makes later comparison much easier. Cisco Mercury's full Network Protocol Fingerprint is structured and versioned; its optional hash is a compact nickname that discards that structure. JA4 publishes both a canonical hashed form and a raw JA4_r form. The details are in the Mercury NPF specification and JA4 technical specification.

Trust the forwarding path as deliberately as any other security metadata. Strip client-supplied copies at the boundary, set the authoritative value there, and record the hop that produced it. Otherwise an attacker may be able to choose the value used by the policy.

Use an action ladder

Bot controls work better with space between “allow” and “block”. A simple ladder is observe, challenge, rate limit, then block. It is not a mandatory sequence for every request; it is a way to match disruption to confidence.

Observe

Observation is the right first action for a new cohort, a changed implementation or a weak hypothesis. Record volume, routes, account outcomes, response codes, request cost and how the cohort overlaps with known legitimate clients.

Set an end date before starting. “Log this for seven days and review on Monday” produces a decision. “Log this” often produces another permanent stream nobody owns.

Challenge

A challenge asks the client for more evidence. It can separate some interactive browsers from simple automation, but it is not a universal test of humanity. Browser automation can complete challenges; privacy software, accessibility tools and broken JavaScript can make legitimate users fail them.

Use challenges where the client can reasonably complete one and where failure has a safe recovery path. They are a poor fit for machine-to-machine APIs unless the protocol already defines an authentication or proof step.

Rate limit

Rate limiting fits repeated or costly behaviour. Count a cohort against the route it is affecting, then layer in the identities that make sense for that route. For example:

login:  fingerprint + account + failed outcome
search: fingerprint + route + request cost
API:    fingerprint + tenant or credential + operation

A limit should say what it protects. Requests per minute is sometimes enough. Expensive operations may need a cost-weighted budget. Login protection may count failed attempts while allowing successful account recovery to proceed. Distributed abuse may need a cohort-wide ceiling plus per-account and per-IP limits so that no single key carries the whole policy.

Return an explicit response and keep the retry behaviour predictable. The HTTP 429 Too Many Requests status was defined for rate limiting in RFC 6585, including the option to send Retry-After. Clients still need sensible backoff, and operators need to watch whether retries are making origin pressure worse.

Block

Block when the evidence is strong, the harm is current, and a less disruptive action cannot protect the route. Good candidates include a confirmed exploit tool hitting the vulnerable route, a cohort causing active availability loss, or repeated abuse that has failed narrower controls.

Keep the scope bounded: fingerprint method and version, affected route, relevant behaviour, start time, owner and expiry. A bare fingerprint deny-list with no incident context is hard to audit and tends to outlive its evidence.

For a broader mapping of actions to evidence, see Network Fingerprint Signals and Security Decisions and Network Fingerprinting for Rate Limiting.

Combine evidence before increasing friction

The most useful policy does not ask whether a fingerprint is good or bad. It asks whether several observations agree.

Consider a login campaign. The source addresses rotate through residential networks. The TLS cohort is common because the tool drives a real browser. The fingerprint alone is weak. But the same traffic may attempt many accounts, reuse a route sequence, fail at a high rate, omit normal session history and arrive at a cadence unlike ordinary users. Together those observations justify a shared limit or challenge.

Now reverse the example. A rare TLS cohort signs in successfully to one account from its usual region, follows a normal route sequence and maintains an established session. Rarity does not add much. Blocking it would mostly punish an unusual client.

This is also the line between a format and a detection system. JA4 defines a fingerprint. Mercury defines fingerprint representations and includes separate analysis components. Any claim such as “this is Chrome”, “this is a scraper” or “this is malicious” comes from surrounding data and inference, not from the fingerprint characters themselves. A Network Fingerprint Is a Cohort, Not a Client explains that boundary in more detail. Fingerprints Are Evidence, Not Identity covers the same problem across browser, network and behavioural fingerprints.

Expect versions and populations to drift

Browsers ship, TLS libraries change defaults, mobile applications update unevenly and attack tools copy popular handshakes. Fingerprint implementations also change their parsing rules. Store the method and implementation version so client drift can be separated from detector drift.

Before changing an implementation, calculate old and new values side by side on a sample. Compare cohort sizes and known-good traffic by route. A partner API, mobile application and public website have different expected populations; a global label may be irrelevant to the local control.

Put expiry and rollback in the policy

Every enforcement rule needs an owner, reason, expiry and removal condition. Before enabling it, record request volume, successful transactions, challenges, 429 responses and origin health. Compare the same measures afterwards. A falling attack rate is not success if legitimate completion falls with it.

When a false positive appears, retain the fingerprint version, capture point, contributing evidence, route, identity, policy revision and rollback result. That record shows whether to change a threshold, split a route class, add an exception, demote the action or remove the fingerprint from the key.

A deployable first policy

For a first production use, choose one abused route. Generate a versioned fingerprint at a trusted capture point, log it beside the route and outcome, and observe cohort sizes long enough to include normal variation. Then choose one reversible action with success measures, rollback and an expiry.

The fingerprint has done its job when it helps a team see and control a group of requests that an IP-only rule would miss. It has exceeded its job when the group is treated as proof of a client, person or intent.

One ClientHello, Three Fingerprints: JA3, JA4 and Mercury

2026-07-12T09:00:00+10:00

The easiest way to misunderstand network fingerprints is to compare example strings taken from different clients. We wanted a cleaner test: one packet capture, one TLS ClientHello and three fingerprint formats.

The complete lab is checked into this site's source under labs/network-fingerprinting/, and the publication bundle is available here. It pins the tool revisions, reconstructs the fixture, verifies its checksum, runs the tools and checks that their outputs refer to the same connection. Nothing in the comparison depends on a vendor database or an application label.

The input

The fixture is a 329-byte Peakhour-generated capture containing a local OpenSSL 3.5.6 ClientHello wrapped in one synthetic Ethernet/IPv4/TCP packet:

10.1.1.1:40000 -> 10.2.2.2:443
SNI: lab.peakhour.test

The lab stores the small fixture as base64 under an adjacent BSD 3-Clause licence and verifies the decoded PCAP with SHA-256 before using it. The reserved SNI and private addresses did not cross a network. We select packet 1 and TCP stream 0. That selection matters: saying that several tools read the same PCAP is weaker than proving that their output describes the same flow and ClientHello.

The pinned revisions for this run are:

Cisco Mercury  3172786645f70e1a8347d8cf020b736e185651e5
FoxIO JA4      0e54bc8371de34df94a35f2442c05bda2e8b2034
Salesforce JA3 502cc6395811c54743b0561419d61900a6df3ff7

These pins are part of the result. Fingerprint implementations and specifications change. A value without its method and version is harder to reproduce than it first appears.

Running the lab

From the repository root:

./labs/network-fingerprinting/run.sh
python labs/network-fingerprinting/verify.py

The runner fetches the pinned source archives, builds or invokes the implementations in a temporary work directory, and writes evidence to labs/network-fingerprinting/results/. The verifier checks the fixture and output checksums, connection tuple, SNI and output shape. The pinned source URLs are enforced by the runner rather than inferred by the verifier.

This is a fingerprint-format lab, not a speed test. Build time, runtime and memory use depend heavily on language, wrapper and capture path, so we do not compare them here.

JA3: a portable exact-match digest

For this ClientHello, the canonical JA3 feature string is:

771,49196-49200-159-52393-52392-52394-49195-49199-158-49188-49192-107-49187-49191-103-49162-49172-57-49161-49171-51-157-156-61-60-53-47,65281-0-11-10-35-16-22-23-13,29-23-30-24-25,0-1-2

Its MD5 digest is:

e1934f32e97b0bd52227953ca7d30118

The digest is convenient for logs and exact lookup. On its own it does not show which cipher, extension or group changed. The pre-hash string retains enough information to investigate that difference, which is why throwing it away too early can make later analysis harder.

JA3 removes GREASE values but otherwise retains the order of its selected lists. A client that permutes extension order can therefore generate a new JA3 digest without changing its effective TLS capabilities. The archived Salesforce JA3 repository defines the input fields and GREASE handling.

JA4: canonicalised components

The same ClientHello produces this JA4:

t12d2709h2_a2460661a67a_36cef8aed422

Its first section is readable:

t means TLS over TCP;
12 is the highest supported TLS version after ignoring GREASE;
d says a domain was present in SNI;
27 and 09 are the cipher and extension counts after the format's exclusions;
h2 summarises the first ALPN value.

The second section is the first 12 hexadecimal characters of SHA-256 over sorted cipher identifiers. The third is a truncated SHA-256 value derived from sorted extension identifiers and the signature algorithms in their original order. The canonical JA4 technical specification defines the exact exclusions and encodings.

The lab also records JA4_r, the raw form used by the FoxIO tooling:

t12d2709h2_002f,0033,0035,0039,003c,003d,0067,006b,009c,009d,009e,009f,c009,c00a,c013,c014,c023,c024,c027,c028,c02b,c02c,c02f,c030,cca8,cca9,ccaa_000a,000b,000d,0016,0017,0023,ff01_0403,0503,0603,0807,0808,0809,080a,080b,0804,0805,0806,0401,0501,0601,0303,0301,0302,0402,0502,0602

That makes the normalisation visible. It also shows why JA4 is not fuzzy hashing: sorting makes selected permutations equivalent, while the hashes still support equality matching rather than semantic distance.

Mercury NPF: a retained protocol tree

Cisco Mercury 2.18 emits this tls/2 fingerprint for the same ClientHello:

tls/2/(0303)(c02cc030009fcca9cca8ccaac02bc02f009ec024c028006bc023c0270067c00ac0140039c009c0130033009d009c003d003c0035002f)[(0000)(000a000c000a001d0017001e00180019)(000b000403000102)(000d002a0028040305030603080708080809080a080b080408050806040105010601030303010302040205020602)(0010000e000c02683208687474702f312e31)(0016)(0017)(ff01)]

The value is longer because it is doing another job. Parentheses and square brackets describe an ordered tree of selected byte strings. In the draft NPF notation, square brackets mark a lexicographically sorted list. The tls/2 prefix names the protocol and fingerprint rule version.

An analyst can inspect the retained values rather than relying only on a digest. Mercury also defines a compact hash nickname when a fixed-length index is needed, but that nickname loses the structure used for inspection, prefix comparison or approximate matching. Cisco's draft NPF specification documents both representations.

The Mercury JSON includes the same source and destination tuple and the same SNI as the JA3 and JA4 records. It does not identify the client application in this lab because we did not run a labelled fingerprint knowledge base or the destination-context classifier. A packet-derived NPF value and a process assessment are separate outputs.

What the comparison establishes

All three methods observe the same ClientHello, but they define similarity differently.

Question	JA3	JA4	Mercury NPF `tls/2`
Compact default	Yes	Yes	No; optional hash available
Inspectable selected inputs	Only if the pre-hash string is retained	Partly in `a`; fully in the recorded raw form	Yes in the full tree
Selected list sorting	No, after GREASE removal	Ciphers and most extensions	Rule-specific selected extensions
Explicit format version in value	No	Encoded field semantics, but no separate rule number	Yes
Semantic or approximate comparison	Not from the digest	Component grouping, not hash distance	Full structure can support richer matching
Application attribution in the format	No	No	No

The table does not produce a universal winner. JA3 remains useful where historical compatibility matters. JA4 is compact and handles selected permutations cleanly. Mercury retains more material for inspection and for analysis systems that need structured features.

It also shows what none of the values can establish. The capture does not prove which person, device or application created the connection. Shared libraries, browser impersonation and software updates all complicate that inference. See A network fingerprint is a cohort, not a client for the operational consequences.

For the history behind these design choices, read Two lineages of TLS fingerprinting. The durable format comparison is in Mercury vs JA4 vs JA3.

Edge Security is now a Privacy Compliance Issue

2026-06-25T08:13:00+10:00

For Australian businesses, website security is no longer just an IT problem. If a website collects, processes or exposes personal information, edge security is now part of privacy compliance.

That shift matters because many organisations still treat cyber compliance as an Essential Eight exercise. They focus on patching, MFA, backups, restricted administrative privileges and endpoint hardening. Those controls are important, but they do not fully protect the public-facing web applications, APIs, customer portals and login flows where personal information is often exposed.

Under Australian Privacy Principle 11 — security of personal information, an APP entity that holds personal information must take reasonable steps to protect it from misuse, interference, loss, unauthorised access, unauthorised modification and unauthorised disclosure. The Act also makes clear that those steps include technical and organisational measures.

That wording is important. It means privacy compliance is not limited to policies, contracts and internal IT controls. If customer data is reachable through a website or API, then the controls protecting that website or API become part of the privacy compliance story.

Essential Eight is the floor, not the whole building

The Essential Eight is a valuable baseline. The ACSC says it makes it much harder for adversaries to compromise systems, while also noting that no set of mitigation strategies can protect against all cyber threats.

That distinction is important for web applications.

A business can be mature against Essential Eight and still leave its public-facing website exposed. It may have MFA for staff, but no effective protection against credential stuffing on customer accounts. It may patch internal systems, but still allow bots to abuse login, checkout, account, booking or password reset endpoints. It may have backups, but no useful web-layer logs to understand whether personal information was accessed.

Essential Eight helps reduce compromise risk across the corporate environment. Edge security helps protect the application layer where customers, bots, attackers and APIs interact in real time.

For any business that handles personal information online, both are needed.

The edge is where privacy risk often appears first

Most attacks against websites do not start with malware on an employee laptop. They start with HTTP requests.

Attackers test login forms with leaked credentials. They scrape customer portals. They abuse APIs. They enumerate accounts. They probe CMS plugins. They bypass exposed origins. They overload search, checkout or booking endpoints. They automate password reset flows. They use residential proxies and headless browsers to make malicious traffic look like normal customer activity.

From a privacy perspective, this matters because these attacks can lead directly to unauthorised access, disclosure, misuse or loss of personal information.

That is exactly the risk APP 11 is concerned with.

If a website exposes customer names, addresses, order history, invoices, loyalty balances, support tickets, identity documents, health information, student records or account data, the edge is part of the control environment. It is the place where malicious traffic can be blocked, challenged, rate limited, logged or allowed through to the origin.

Government guidance points beyond basic IT hygiene

The ACSC’s guidance on securing customer personal data recommends practical controls such as creating a register of personal data, limiting what is collected, deleting unused data, controlling access, encrypting data, backing it up, and logging and monitoring access.

For a website, those recommendations have direct edge and application-layer implications.

A register of personal data should include not only databases, but also web forms, APIs, CDN logs, application logs, analytics tools, third-party scripts, support systems and staging environments. Limiting collection should mean removing unnecessary fields from forms, avoiding personal information in URLs, and not sending sensitive data into analytics or debugging tools without a clear reason. Logging and monitoring should include requests to sensitive endpoints, not just server health metrics.

In other words, practical privacy protection has to reach the web stack.

WAF, rate limiting and bot management are privacy controls

A web application firewall is often seen as a security control. Rate limiting is often seen as an availability control. Bot management is often seen as a cost or performance control.

For websites handling personal information, all three are also privacy controls.

A WAF helps block common exploit attempts before they reach the application. Rate limiting helps reduce brute force attacks, account enumeration, password reset abuse, checkout abuse and application-layer denial of service. Bot management helps identify credential stuffing tools, scrapers, automation frameworks, fake browsers and proxy-based abuse.

These controls do not replace secure application development, access control or data minimisation. But they reduce the chance that personal information can be accessed or harvested through normal-looking web requests.

That matters because many privacy incidents are not sophisticated intrusions. They are automated abuse at scale.

A login form without bot protection can become a credential stuffing endpoint. A search API without rate limits can become a scraping interface. A customer portal without behavioural monitoring can become a data extraction tool. An exposed origin can bypass the very controls the business thought were protecting the site.

Edge logging supports breach assessment

Privacy compliance is not only about preventing incidents. It is also about understanding them.

When something goes wrong, a business needs to answer practical questions. Which accounts, IPs, sessions or API keys accessed the affected records? Which endpoints were used? Was the traffic automated? Did it come through the CDN or bypass it? Was the data viewed, modified or exported? What personal information may have been exposed?

Without edge and application-layer logs, those questions are hard to answer.

That creates a second-order privacy problem. If a business cannot determine what happened, it may struggle to assess the seriousness of an incident, notify accurately, or explain what remedial action was taken.

Good logging does not mean storing personal information in logs forever. It means capturing enough security metadata to reconstruct access patterns while avoiding unnecessary personal information in the logs themselves.

Data minimisation also applies at the edge

Privacy risk increases when personal information spreads through systems that were never designed to store it.

Websites often leak personal information into places businesses forget to review: query strings, CDN logs, analytics events, error traces, session replay tools, marketing pixels, staging databases, CSV exports and support tickets.

That is why data minimisation should apply to the whole request path, not only the production database.

Do not put personal information in URLs if it will be logged by browsers, proxies, CDNs and analytics tools. Do not send unnecessary personal information to third-party scripts. Do not retain verbose request logs longer than needed. Do not copy production customer data into staging unless there is a controlled and documented reason. Do not collect fields “just in case”.

The less personal information that passes through the edge, the less there is to expose, protect, delete and explain.

What this means in practice

For Australian websites handling personal information, edge security should now be treated as part of the privacy control set. That usually means:

placing the site behind a CDN or edge security layer
enabling WAF protection for common application attacks
applying rate limits to login, registration, password reset, checkout, search and API endpoints
using bot management to detect scraping, credential stuffing and automated abuse
locking down the origin so attackers cannot bypass edge controls
logging enough request metadata to support investigation and breach assessment
reviewing what personal information appears in URLs, headers, cookies, logs and analytics
applying retention and deletion rules to CDN logs, application logs and third-party tools

The important point is not that every website needs the same controls. A simple contact form does not create the same risk as an ecommerce account portal or health booking system. The point is that the controls should match the risk created by the personal information being handled.

That is the practical meaning of “reasonable steps”.

The takeaway

Edge security has moved from being a performance and availability issue to being a privacy compliance issue.

For Australian businesses, Essential Eight remains a sensible baseline. But it does not prove that a public-facing website, API or customer portal is protected against the most common ways personal information is abused online.

If personal information is collected, accessed or processed through the web application, then WAF, bot management, rate limiting, origin protection, API controls, logging and data minimisation all become part of the privacy compliance conversation.

The question is no longer just whether the business has implemented Essential Eight.

The better question is: if an attacker came through the front door of the website, could the business show it had taken reasonable technical steps to protect the personal information behind it?

Anatomy of a Credential Stuffing Attack

2025-09-01T00:00:00+10:00

In early 2024, major Australian retailer The Iconic was hit by a widespread account takeover attack. Fraudsters used stolen credentials to log into customer accounts, place orders with stored credit cards, and ship goods to different locations. The incident caused significant reputational damage and financial loss, forcing the company to issue refunds and publicly address the security breach.

This attack wasn't the result of a direct hack on The Iconic's systems. It was a classic case of credential stuffing: an automated attack that works because people reuse passwords across services. This article breaks down how credential stuffing works, the attacker's toolkit, the business impact, and the controls that make it harder to run at scale.

What is Credential Stuffing?

Credential stuffing is an automated attack where malicious actors use lists of stolen usernames and passwords—often obtained from third-party data breaches—to gain unauthorised access to user accounts on other websites. The attack works because many users recycle the same password across multiple online services. If a password for a user's social media account is leaked, attackers will "stuff" that same email and password combination into the login forms of e-commerce sites, banking portals, and other high-value targets.

Because attackers submit valid credentials, even though they are stolen, these login attempts can be difficult to distinguish from genuine user activity. That makes credential stuffing harder for traditional security controls to spot.

The Attacker's Toolkit

Modern credential stuffing is not a manual process. Attackers use a mature set of tools and resources to automate and scale their campaigns:

Automation Software: Tools like OpenBullet are central to these attacks. OpenBullet is a powerful, open-source web testing suite that allows even non-programmers to create complex attack scripts. Attackers can find or create "configs" that tell the software exactly how to interact with a target website's login form.
Breached Credential Lists: Dark web markets carry massive databases of usernames and passwords harvested from data breaches. These "combo lists" are the raw material for credential stuffing attacks and can be purchased for very little cost.
Proxy Networks: To avoid being blocked, attackers distribute their login attempts across thousands or even millions of IP addresses. They often use residential proxy networks, which route traffic through the internet connections of real home users. This can make malicious traffic appear to come from legitimate customers, weakening IP-based blocking and rate limiting.

The Business Impact

The consequences of a successful credential stuffing attack extend beyond the login event:

Direct Financial Loss: As seen with The Iconic, attackers can make fraudulent purchases, drain loyalty points, or transfer funds, leading to direct financial losses and the cost of refunding customers.
Damage to Brand Reputation: Publicly reported breaches erode customer trust. Users who have been defrauded may share their negative experiences on social media, leading to lasting reputational harm.
Loss of Customer Trust: When customers believe their accounts are not secure, they may abandon the platform altogether, leading to customer churn and a decline in lifetime value.
Operational Costs: Responding to an attack involves significant operational overhead, including customer support time, fraud investigation, and new security measures.

Building a Multi-Layered Defense

Stopping automated attacks requires a defence strategy that goes beyond simple password policies. A modern, multi-layered approach should include:

Advanced Bot Protection: The first step is to distinguish bots from humans. Modern bot management uses techniques like network and browser fingerprinting, proxy context, route behaviour, and behavioural analysis to detect automated login attempts, even when they mimic human behaviour.
Check Credentials Against Breach Databases: Proactively check usernames and passwords used in login attempts against comprehensive databases of known breached credentials. If a credential pair is known to be compromised, you can flag the login for additional verification or alert the user to change their password.
Advanced Rate Limiting: Traditional IP-based rate limiting struggles against distributed attacks. Advanced rate limiting groups requests by more stable identifiers, such as a TLS fingerprint, which can remain consistent even as an attacker rotates through thousands of IP addresses. This helps track and block a single malicious actor launching a distributed attack.
Enforce Multi-Factor Authentication (MFA): MFA is not a silver bullet, but it provides a critical layer of security by requiring a second form of verification. Websites should strongly encourage or enforce MFA, especially for sensitive actions like changing account details or making purchases.

For production teams, the useful bot-management view ties those controls together on the login path. Credential exposure, residential proxy evidence, fingerprints, request rate, response codes, and session changes should feed one decision about whether to allow, challenge, rate limit, block, or review the attempt.

By combining these controls, organisations can make credential stuffing harder to scale, protect user accounts, and reduce the business risk when attackers test stolen credentials.

The Invisibility Cloak

2025-09-01T00:00:00+10:00

A bot can change its IP address without changing the browser behind the request. It can also change its reported browser profile while continuing the same account attack.

Residential proxies and anti-detect browsers cover those two surfaces. The proxy moves traffic through consumer connectivity. The anti-detect browser manages the client properties exposed to the website. Used together, they make simple IP and browser rules less reliable.

They do not make the operator invisible.

The Proxy Changes the Network Path

A residential proxy sends a third party's traffic through a consumer or ISP connection. The destination sees the exit address rather than the operator's original network.

That supply may come from an informed participant, an embedded monetisation SDK or a compromised device. The destination usually cannot see that enrolment history. It sees a request from an address that may also carry legitimate household traffic.

This is why a clean IP reputation result is not enough to establish trust. A fresh exit may not yet appear in a database, while a stale label can remain after the address has returned to ordinary use.

The Browser Changes the Client Presentation

An anti-detect browser lets an operator manage browser profiles at scale. Profiles can vary user agent, operating system claims, screen properties, language, time zone, storage and rendering inputs. The aim is to make separate sessions look plausible and prevent a site grouping them as one client.

That control is not absolute. Some properties can be spoofed cleanly. Others interact with the network stack, rendering environment, request sequence and account history. A profile can look plausible in isolation while disagreeing with evidence elsewhere in the session.

The stable explainer is Residential Proxies and Anti-Detect Browsers. This article focuses on what their combination changes for a live application.

Look for Agreement, Not a Magic Fingerprint

No fingerprint proves that two requests came from one person or one machine. Common browsers create large cohorts, privacy controls remove information, and legitimate devices change across software updates and networks.

The useful question is whether independent observations agree:

Does the TLS and HTTP behaviour fit the claimed browser family?
Does the browser profile remain internally consistent across the journey?
Does the same request sequence continue as the IP rotates?
Are credentials, accounts, carts or API objects reused across supposedly unrelated clients?
Do timing, retries and outcomes match normal use of the protected route?

Each observation has legitimate explanations. Agreement across several layers raises confidence without pretending a fingerprint is identity.

Protect the Work Being Attempted

Credential stuffing, fake registration, scraping and inventory abuse have different failure modes. Their controls should differ too.

On login, correlate failures across account, credential and client cohorts instead of resetting history with every IP change. On signup, measure creation velocity and the quality of later activity. On checkout, carry session risk into promotion, payment and inventory decisions. On APIs, use credentials, operations, protocol evidence and cost; JavaScript is not required.

Residential proxy detection contributes current network evidence. Browser and network fingerprinting contribute cohort and consistency evidence. Behaviour and route context decide whether the application should allow, log, challenge, rate limit, step up or block.

That is the important limitation of the “invisibility cloak” metaphor. These tools can hide one surface at a time. They still have to complete work against an application that can observe the whole request sequence.

Continue with Proxy Signals and Security Decisions or the route-specific guide Five Routes, Five Residential Proxy Decisions.

How to Use Bot Management for IAM Use Cases

2025-08-20T00:00:00+10:00

Automated attacks against identity and access management (IAM) systems are now a routine account protection problem. Malicious bots drive account takeovers (ATO), credential stuffing, brute-force login attempts, and fake account creation. As these attacks adapt, traditional IAM controls such as password policies and even multi-factor authentication (MFA) are not enough on their own.

Identity and access management leaders should treat bot management as part of the IAM control set, not a separate website security add-on. A dedicated capability helps reduce avoidable financial and reputational losses from account compromise. It also gives organisations a way to manage the risks created as AI agents become regular users of web applications and APIs.

Introduction

Some estimates suggest nearly half of all traffic is automated. That mix matters: useful crawlers and monitoring tools are part of normal internet traffic, but malicious automation is built to test web applications at scale. IAM systems, which control access to sensitive user accounts and data, are a primary target.

The most common bot attacks targeting IAM include:

Credential Stuffing: Attackers use lists of stolen usernames and passwords from third-party data breaches to gain unauthorised access to user accounts. This attack vector is effective because password reuse is still common.
Brute-Force Attacks: Automated scripts guess passwords for known usernames, often targeting login endpoints for platforms like WordPress and Magento.
Fake Account Creation: Bots create fraudulent accounts at scale, which can be used for spam, malware distribution, or to abuse promotional offers.

Recent attacks on major Australian retailers like The Iconic and Dan Murphy's show the practical impact. These incidents, driven by credential stuffing, resulted in reputational damage and financial loss, forcing the companies to issue refunds and publicly address security concerns.

Analysis

Defending IAM systems starts with why common controls fall short and where bot management adds useful signal.

Why Traditional IAM Defences Fail

Attackers have adapted their techniques to bypass legacy security controls. Simple IP-based rate limiting and reputation lists struggle against the combination of residential proxies and anti-detect browsers:

Residential Proxies: Attackers route their traffic through large networks of IP addresses belonging to real residential internet connections. This makes malicious traffic appear legitimate and allows attackers to bypass IP-based blocking and geolocation restrictions. Our own tests show that even leading IP intelligence services fail to detect the vast majority of residential proxy traffic.
Anti-Detect Browsers: These specialised browsers allow attackers to spoof their digital fingerprints, mimicking legitimate user devices and browser configurations. This weakens many JavaScript-based challenges and fingerprinting techniques.

Used with automation suites like OpenBullet, these tools let attackers run "low and slow" distributed attacks that blend into normal traffic. For more information on these tools, see our guide to enterprise bot management.

The Flawed Logic of CAPTCHA

For years, CAPTCHA has been the default way to distinguish humans from bots. It is now a weak control when used on its own. Our research shows that visible CAPTCHAs have a severe negative impact on user experience and conversions. Studies have found that CAPTCHAs can reduce form conversions by up to 40%, as frustrated users abandon purchases or sign-ups.

Modern bots can also solve CAPTCHAs with high accuracy, often more effectively than humans, by using CAPTCHA-solving farm services. Relying on CAPTCHA alone creates friction for legitimate users while providing a false sense of security. Modern bot management uses invisible challenges and behavioural analysis to validate users without disrupting their session.

Modern Bot Management Capabilities for IAM

An effective bot management solution provides a multi-layered defence that goes beyond simple signatures. Key capabilities include:

Advanced Rate Limiting: Instead of relying on IP addresses, modern solutions group requests using more stable identifiers like TLS/HTTP2 fingerprints, device characteristics, or a combination of headers. This helps detect distributed attacks from a single malicious tool, even as it rotates through thousands of IPs.
Network and Device Fingerprinting: By analysing the unique characteristics of a client's TCP and TLS implementation, it is possible to identify the underlying software making the request, regardless of the user-agent header. This helps distinguish between real browsers and automated scripts.
Behavioural Analysis: Systems can model normal user behaviour—such as mouse movements, typing speed, and page navigation—to identify anomalies that indicate automation.
Residential Proxy Detection: Specialised techniques are required to identify traffic coming from residential proxy networks, which is a strong indicator of malicious intent.
Breached Credential Integration: By checking login attempts against databases of known breached credentials, security teams can apply additional scrutiny to high-risk authentication events.

Together, these controls give IAM teams more useful decision points than an IP address, a password check, or a CAPTCHA challenge alone.

The Next Frontier

The next major change in automated traffic is agentic AI. As reasoning models like DeepSeek become more accessible, we are entering an era where AI agents are becoming primary consumers of APIs and web applications.

These are not just the rigid scripts of the past. AI agents can reason, plan, and adapt their behaviour in real-time based on a system's responses. They can analyse an entire API surface in seconds and generate complex interaction patterns that human developers would be unlikely to try manually.

This creates a harder IAM problem. Bot management has usually looked for patterns that differ from normal human behaviour. AI agents can make those patterns less reliable by imitating user behaviour while still operating at machine speed. The line between human and automated traffic blurs.

IAM leaders need bot management solutions that can adapt to this shift. The future of bot management will not only be about blocking bots; it will also be about deciding which automated agents are acceptable, under what conditions, and with which controls. This requires a shift from static, rule-based security to contextual analysis that understands and adapts to agent behaviour, distinguishing between legitimate AI assistants and malicious ones. Organisations that wait until agent traffic is common will have less time to distinguish useful automation from AI-driven attacks.

The Negative Impact of Visible CAPTCHAs on Bounce Rates and Conversions

2025-08-06T13:00:00+10:00

A client of Peakhour's recently migrated their site to us from a bot management vendor that used visible CAPTCHAs. After the migration they noticed double-digit year-on-year growth in revenue and conversions. We'd like to take the credit, but there is a simpler explanation: our bot management works differently. We use targeted invisible challenges to verify browser environments rather than visible CAPTCHAs. Could that account for such a large difference? I decided to check what the research says.

Visible CAPTCHAs (like image-selection or text puzzles) are still a common way to separate humans from automated traffic. They can block some bots, but they also add friction for legitimate users. Recent analyses across providers, including Human (formerly PerimeterX), Google’s reCAPTCHA, Arkose Labs, and others, point to measurable impacts on ecommerce performance and customer behaviour.

Conversion Rate Impacts of Visible CAPTCHAs

Multiple studies and vendor reports show that visible CAPTCHAs can substantially reduce conversion rates. A Stanford University study found that a CAPTCHA challenge can reduce form conversions by up to 40%. In practical terms, many users abandon signup or checkout forms when they hit a CAPTCHA. HUMAN Security researchers similarly found that 40% of real human shoppers have given up on a purchase due to CAPTCHA frustration. For an online retailer, losing up to 40% of potential sales at the final hurdle is a direct revenue problem. Forrester Research reported 19% of consumers have abandoned a website entirely because of encountering a CAPTCHA – showing how these challenges can drive users away before conversion.

Even smaller conversion drops matter. One bot mitigation firm (Datadome) observed that adding a CAPTCHA to a site led to a 3.2% higher bounce rate and an overall 3–5% drop in conversion. Given that average e-commerce conversion rates are often just 2–3%, losing even a few more percent of customers can materially affect revenue. In industries with thin margins and high customer acquisition costs, no business wants to sacrifice those would-be buyers.

Bounce Rates and User Abandonment

Every extra step in the user journey increases the risk of bounce (users leaving after a single page). CAPTCHAs are a common cause. Studies show about 30% of users will leave a site if a CAPTCHA is too complex or cumbersome. Long or indecipherable challenges cause users to give up, raising bounce rates. In one example, shoppers who faced repeated CAPTCHA puzzles during checkout simply exited, contributing to higher cart abandonment and bounce metrics. Even users who intend to buy may get frustrated by being treated like “bots” and decide the purchase is not worth the hassle.

Online patience is thin. Customers expect quick transactions, especially on mobile devices. CAPTCHAs slow things down: one analysis noted completing actions on mobile takes 30–40% more time with a CAPTCHA than without. That delay is enough to hurt conversion, as hurried mobile users are quick to drop off. As a result, visible CAPTCHAs often correlate with higher bounce rates and shorter time-on-site, indicating that challenged users are abandoning sessions. Some reports estimate 20% of users will leave if they encounter difficulties solving a CAPTCHA. This abandonment directly translates to lost sales or sign-ups.

User Experience Friction and Qualitative Insights

Qualitatively, visible CAPTCHAs introduce real user experience (UX) friction. Usability experts note that CAPTCHAs are often hard to read, carry no real meaning for the user, and feel like an unnecessary test, all of which irritate customers and “kill” conversions. They can be especially off-putting to certain user segments, such as older users or those with disabilities. For example, visually impaired users may find image CAPTCHAs nearly impossible to complete, leading to exclusion and site abandonment (W3C Accessibility Guidelines). Legitimate customers often feel inconvenienced or even insulted by being forced to “prove” they are human. As one industry commentator quipped, “Every CAPTCHA is a time tariff imposed on your customers” – it is a tax on their time and patience, which benefits nobody in terms of sales.

False positives (human users being mistaken for bots) make this worse. If a security system is too sensitive and throws frequent CAPTCHAs at real shoppers, it creates friction without benefit. Users confronted with multiple challenges may think twice about continuing. DataDome’s research notes that excessive CAPTCHA usage causes a suboptimal experience, and customers have “little patience” for such delays. The result can be reputational damage as well – annoyed users might complain publicly, hurting the brand. In short, traditional CAPTCHAs tend to “treat customers like criminals”, which pushes people away.

Industry-Specific Observations

The negative effects of visible CAPTCHAs show up across industries, with different tolerance for security friction:

Retail & E-Commerce: Online retail (from fashion to electronics) is highly sensitive to checkout friction. Shoppers have many alternatives, so a challenging CAPTCHA can send them to a competitor’s site in seconds. Even one extra step can hurt sales conversion. E-commerce case studies consistently show that removing CAPTCHAs boosts conversions. Bot solution vendors note that losses from CAPTCHA friction are “especially noticeable in areas such as e-commerce” where even a 3–5% conversion dip means thousands of customers lost.
Travel & Ticketing: Travel sites (flights, hotels) and ticketing platforms often deploy CAPTCHAs to thwart scalpers and bots (e.g. for popular concert tickets or holiday bookings). That can protect inventory, but it can also turn away real customers. Travellers shopping around for deals won’t hesitate to bounce if a booking site throws up hurdles – they’ll try another site. Travel bookings are often time-sensitive (flash sales, limited seats), so any slowdown from a puzzle challenge can cause users to miss out and blame the site. The challenge for this sector is to weed out bot traffic (which can be a huge share of ticketing traffic) without derailing genuine user transactions. Some travel companies use alternatives like virtual waiting rooms or invisible challenges to reduce user-facing friction. A smooth booking path matters: industry observers emphasise that travel and hospitality businesses that “remove booking friction” are rewarded with higher conversion and direct revenue, whereas those using blunt CAPTCHA challenges risk higher bounce rates and lost bookings.
Finance & Banking: Financial services websites (online banking, fintech apps, etc.) deal with sensitive transactions and may introduce verification steps (CAPTCHAs or multi-factor authentication) for security. Users in this sector can be slightly more tolerant of friction if it clearly signals security. However, if a bank’s CAPTCHA fails normal users or frequently interrupts login, customers will get frustrated or call support. Financial institutions must balance fraud prevention with a smooth experience – if there is too much friction, users may abandon opening an account or using the service. In fact, the same 40% conversion drop risk applies here: lost applications or completed transactions if security measures are overbearing. So even in finance, the trend is toward smarter, invisible verification methods to minimise extra steps.
Other Industries: Nearly any consumer-facing online service – from gaming and streaming to government portals – faces the CAPTCHA UX dilemma. Users expect minimal friction. In some niches (e.g. gaming), users are extremely averse to any interruptions in sign-up or sign-in. In others (like online voting or government forms), a CAPTCHA might be more accepted, but if it fails or confuses users, it can prevent task completion. The pattern is consistent: user expectations for convenience are high across the board, and visible CAPTCHAs risk alienating users in any vertical if not handled carefully.

Death of the CAPTCHA

Visible CAPTCHAs are still widely used, and they still add friction at critical moments. The research above shows users often abandon sites or carts rather than struggle with puzzles – a loss of sales that can range from a few percent to double digits. This effect is seen broadly, from fashion retail to travel bookings to financial services.

That is before we consider the actual effectiveness of visible CAPTCHAs. Other studies have shown bots can be MORE effective than humans at solving them.

That is why Peakhour uses invisible challenges: verify the browser environment without making legitimate customers solve a puzzle.

Protecting Against a Share Point Zero Day Vulnerability with Network Fingerprinting

2025-07-23T13:00:00+10:00

Why Network Fingerprinting is Your Strongest First Defense

A critical new remote code execution (RCE) vulnerability in on-premises Microsoft SharePoint Server, identified as CVE-2025-53770, is being actively exploited and presents a serious risk to organisations. This flaw allows an unauthenticated attacker to take complete control of a server over the network, so immediate and effective defence is a priority. Microsoft disclosed the flaw on 19 July.

Vendor patches are essential, but zero-day activity often starts before most organisations can patch. That gap is where proactive controls matter.

This post looks at the technical nature of this threat and how a strategy centred on network fingerprinting can block zero-day exploit activity before a formal patch is deployed.

Understanding the Threat: CVE-2025-53770

The SharePoint vulnerability is particularly dangerous as it allows for the deserialization of untrusted data, leading to remote code execution without any need for attacker authentication. This makes any unpatched, internet-facing on-premises SharePoint server a potential target. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has underlined the severity of this threat by adding it to its Known Exploited Vulnerabilities Catalog.

Exploitation can lead to a complete compromise of the SharePoint server, allowing attackers to steal data, execute arbitrary code, and potentially move laterally across the internal network.

The Race Against Scanners

When a zero-day vulnerability like this is discovered, a global, automated race begins. Malicious actors immediately deploy scanners to canvass the internet for vulnerable systems.

Our own analysis shows that the majority of malicious requests targeting our clients came from the DigitalOcean and Scaleway ASNs, with Amazon Web Services (AWS) EC2 and Microsoft Azure also being a prominent source. These networks are well-known for being used by malicious actors to launch scanning and attack campaigns quickly. Notably, scans were happening on 16 and 17 July, before the vulnerability was disclosed by Microsoft.

This initial scanning phase, however, creates an opportunity for defence. Instead of waiting to analyse the specific attack payload, we can identify and block the very tools the attackers are using.

Exploits attempts in the wild. Note attempts days before disclosure.

Why IP Reputation Isn't Enough

For years, a primary method of defence has been IP reputation—blocking traffic from IP addresses known to be malicious. While simple and somewhat effective against basic attacks, this approach is increasingly unreliable in the face of modern threats.

The rise of sophisticated proxy services has changed the model. Attackers now have easy access to vast networks of residential, mobile, and rotating data centre proxies. These services allow them to distribute their attack traffic across thousands or even millions of seemingly legitimate IP addresses, making it impossible to maintain an effective blocklist. An IP that sends a malicious request one moment could be used by a legitimate customer the next.

Furthermore, attackers leveraging cloud infrastructure use ephemeral IPs that exist for only a short time, rendering IP-based blocking a constant and losing game of cat and mouse. This approach also carries a high risk of "collateral damage", where legitimate users are blocked simply because they share an IP address with a bad actor, a common scenario with Carrier-Grade NAT (CGNAT) or public Wi-Fi. Relying solely on where a request comes from is no longer a viable strategy.

Unmasking the Attacker's Tools with Network Fingerprinting

This is where network fingerprinting becomes useful as a zero-day defence. Fingerprinting in cybersecurity refers to methods used to identify the unique characteristics of devices, software, or users. It allows for the identification and categorisation of operating systems and software based on their distinct signatures in network communications.

When attackers rush to exploit a new vulnerability, they don't use standard web browsers. They quickly code scanners using programming languages and libraries like Python, Go, or Java. These tools and libraries create network connections with distinct, non-browser-like fingerprints. By analysing these, we can block the scanner before it ever delivers its malicious payload.

Peakhour uses several passive fingerprinting techniques to do this:

TCP Fingerprinting

This method identifies a device's operating system by analysing how it implements the TCP protocol. By examining nuances in TCP packets—like window size, Time to Live (TTL), and how the device responds to non-standard packets—we can identify the underlying system that created the request.

TLS Fingerprinting

This technique analyses the "ClientHello" message sent by the client during the initial TLS handshake to establish a secure connection. The combination of TLS version, supported cipher suites, and extensions creates a unique fingerprint. This is a highly effective way of identifying the classes of connecting clients, such as those made by Go, Python, or Java libraries, which are commonly used for attack tooling. JA4 and JA3 are popular TLS fingerprint formats.

HTTP/2 Fingerprinting

This involves analysing how clients use the HTTP/2 protocol, including their patterns in sending HTTP/2 frames and negotiating connections. This makes it easier to differentiate between legitimate browsers, bots, and the custom applications used in an attack campaign.

After identifying these fingerprints, Peakhour's bot management service uses machine learning to classify them as either a legitimate browser or a bot. This provides a strong layer of defence against zero-day exploits. The scanners are identified and blocked based on their fundamental network characteristics, irrespective of the specific vulnerability or payload they carry.

Defense in Depth

No single security measure is a silver bullet. While network fingerprinting provides a powerful first line of defence against automated scanners, a multi-layered, defence-in-depth strategy matters.

Any request that manages to bypass the initial fingerprinting checks must face the next layer: our standard Web Application Firewall (WAF) with post-body scanning. A WAF inspects every request before it reaches the application. By enabling the inspection of the full request body, the WAF can identify and block malicious payloads, such as the specific code used in an exploit attempt, that may be hidden within the data sent to the server. Our WAF was updated with a virtual patch on 22 July at 5am AEST to add protection against this vulnerability.

Staying Ahead in a Zero-Day World

The SharePoint CVE-2025-53770 vulnerability shows why a reactive security posture is not enough. While patching is essential, the reality is that attackers move first.

By using proactive techniques like network fingerprinting, organisations can identify and neutralise the automated tools attackers rely on during the critical opening hours of a zero-day exploit's life. This approach, when combined with payload inspection from a WAF, gives critical assets another layer of practical protection.

How AI Agents Are Writing Custom Exploits

2025-02-17T14:00:00+11:00

The trend is clear enough: AI agents can now craft exploits by analysing security responses in real time. That puts static security rules and traditional Web Application Firewalls (WAFs) under direct pressure. Here is why.

Last week I examined an AI agent probing a test environment. It sent requests, observed the responses, then built bypasses for each security control in sequence. The agent identified pattern-based rules, learned their structure, and generated variations until it found gaps. It did this without human intervention.

This kind of automated exploit development changes the operating conditions for defenders. Traditional defences rely on known patterns: regex rules, signature matching, IP reputation. Those approaches assume threats follow recognisable templates. That assumption is becoming much weaker.

Consider a standard WAF rule blocking SQL injection through pattern matching. An AI agent examines the responses, determines the matching patterns, then generates unique variants designed to bypass those rules while maintaining the exploit's functionality. The variants evolve as the agent learns which approaches succeed.

The same pattern applies beyond SQL injection. AI agents can probe XSS filters, access controls, and input validation in the same systematic way. Each static rule becomes something the agent can test, infer, and work around.

By 2026, I estimate AI agents will drive over 50% of exploit attempts. The speed of this shift stems from three factors:

AI agents operate continuously, testing and learning 24/7
Successful exploits feed back into training data, improving future attempts
Agents share knowledge, building collective intelligence about bypass techniques

This is the practical limit of static security. Traditional WAFs that rely on fixed rules and signatures struggle to keep pace with AI-generated exploits. Each rule loses value as agents discover new bypasses.

The path forward requires a different security architecture. Organisations need context-aware systems that analyse intent, not just patterns. These systems use behavioural AI to distinguish between legitimate requests and exploit attempts, even when the request structure changes.

Key elements of this new approach include:

Intent analysis through deep inspection of request sequences
Behavioural modelling of normal vs malicious patterns
Real-time adaptation as new exploit techniques emerge
Proactive identification of potential vulnerabilities
Integration of threat intelligence across systems

The challenge intensifies when AI agents leverage residential proxies. These proxies route traffic through real consumer IP addresses, bypassing location-based blocks. An AI agent operating through residential proxies can probe defences while appearing to come from legitimate users worldwide.

This combination of AI-driven exploit generation and residential proxy networks makes traditional controls much less reliable. Organisations that continue to rely on static rules face a growing risk of compromise.

Security teams should respond now:

Audit existing WAF rules to identify pattern-based weaknesses
Deploy behavioural analysis capabilities to detect malicious intent
Implement adaptive security controls that evolve with threats
Monitor for AI-driven probing attempts
Build detection for residential proxy traffic

Teams that wait risk watching their defences get mapped and bypassed by automated agents. Static rules alone are not enough for this level of probing.

This also requires a shift in how we approach security. Rather than only blocking specific patterns, we need to understand and control the broader context of system interactions. The goal moves from "preventing known attacks" to "identifying and blocking malicious behaviour, regardless of its specific form."

Adaptive security systems need to reason about traffic in the same context-aware way as the agents probing them. Static rules still have a role, but they cannot be the centre of the defence.

Security strategy needs to account for this now, because AI-driven probing is no longer hypothetical.

The Reasoning Model Revolution

The emergence of open reasoning models like DeepSeek pushes this further. Unlike traditional AI that follows programmed patterns, reasoning models understand context and adapt strategies dynamically. That creates harder security problems.

Consider how a reasoning model approaches security testing. Rather than simply probing for weaknesses, it builds a conceptual model of the system's defences. It understands the purpose of security controls and reasons about potential bypasses. That allows it to generate novel attack strategies that were not present in training data.

DeepSeek demonstrates this shift. Within months of release, it showed capabilities matching established players at a fraction of the cost. This rapid progress comes from reasoning models' ability to understand and adapt, not just pattern match.

For security teams, that is a material challenge. Reasoning models do not just find gaps in rules. They infer why rules exist, deduce the logic behind security controls, and generate attacks that exploit underlying assumptions.

By 2027, I expect reasoning models to handle most security testing and exploit development. Their advantages prove too compelling:

They understand system architecture and security principles
They generate novel attack strategies through reasoning
They adapt in real-time based on system responses
They share and build upon successful approaches

This shift pushes traditional security approaches past their useful boundary faster than many teams expect. Pattern matching and rule-based systems cannot reliably counter an opponent that understands and reasons about their operating logic.

The combination of reasoning models with residential proxies is especially difficult to defend against. Reasoning models devise sophisticated attacks while proxies mask their origin. Each successful breach feeds back into the model's understanding, improving future attempts.

Security teams must embrace a new paradigm focused on:

Understanding attack narratives rather than patterns
Detecting anomalous reasoning rather than known signatures
Building systems that adapt to novel attack strategies
Implementing security that reasons about intent
Developing defences that evolve through adversarial learning

Security systems need to reason about threats as effectively as the AI agents probing them. Traditional approaches will fail against opponents that understand the logic behind security controls and devise creative bypasses.

The age of reasoning security has begun. Static rules and pattern matching are no longer enough on their own.

The question is how quickly security teams can move from fixed patterns to adaptive, intent-aware defence.

When Bots Are Your Primary Users

2025-02-12T14:00:00+11:00

APIs have mostly been designed for human developers first. Reasoning models like DeepSeek make that assumption weaker. If an agent can inspect an API, plan a sequence of calls, and adapt as it goes, it becomes a different kind of consumer.

That is the part worth paying attention to. Many APIs still assume a human-first model while AI agents become regular, and in some cases primary, users. These are not simple scraping bots or automation scripts. Modern AI agents can plan, reason, and change their behaviour. They interact with APIs in ways many teams did not account for when they wrote their OpenAPI specifications and documentation.

A human developer reads documentation, tries a few calls, and works through errors. An AI agent can process the whole API surface in seconds, generate thousands of possible interaction patterns, and test them systematically. That difference changes both API design and API security.

The issue is not limited to technical specifications. API logs already show traffic patterns that challenge older assumptions. AI agents do not follow typical "business hours" usage. They do not slow down because a workflow becomes cognitively heavy. They process responses at machine speed and chain API calls in ways human developers rarely attempt.

This shift forces us to rethink several core aspects of API design:

Structure and Format

Human-readable formats still matter, but they are not the only target. JSON and REST endpoints work well for developers who need to read and understand responses. For AI agents, there may be room for more efficient formats that optimise for machine processing rather than human comprehension.

Rate Limiting and Quotas

Most rate limiting models still assume human consumption patterns. AI agents operate at machine speed and scale. New models need to account for that processing capacity while still preventing abuse. That may mean moving from simple request counts to complexity-based quotas.

Authentication and Security

Traditional API keys and OAuth flows centre on human developers. AI agents need security models that account for how they operate. The hard problem is verifying the identity and intentions of an AI agent without weakening the security controls around the API.

Documentation and Discovery

API documentation still focuses on human understanding. For AI agents, machine-readable specifications need to go beyond OpenAPI. They should describe what endpoints do, not just how to call them.

This also changes how we monitor and maintain APIs. Traditional metrics like response time and error rates remain useful, but they do not explain AI agent behaviour on their own. How do we measure the "success" of an API when its primary users are machines that can adapt to problems and work around them?

Performance optimisation changes as well. A human developer might tolerate occasional latency. An AI agent can make thousands of calls per second, which puts more pressure on caching, edge computing, and response optimisation.

APIs are likely to split into two parallel tracks: human-oriented interfaces that prioritise developer experience, and machine-oriented interfaces optimised for AI consumption. This is not a choice between one audience and the other. It is recognition that they have different needs.

The challenge extends to business models. How do we price APIs when consumers are AI agents that can process information at machine scale? Traditional per-request pricing may not make sense when an AI can make millions of optimised calls that would take a human developer years to replicate.

Residential proxies add another layer of complexity. They allow AI agents to appear as regular users, making it harder to distinguish between human and machine traffic. That pushes API access control beyond IP-based rate limiting.

The ethical questions also matter. As APIs become primarily consumed by AI agents, teams need frameworks for responsible use. That includes asking how an API might be used inside AI systems, and what guardrails should sit around that access.

This is not about replacing human developers. It is about recognising AI agents as a new class of API consumer, with their own needs and capabilities. API design, security, and management all need to account for that.

The APIs we build today will sit under tomorrow's AI-driven systems. They need to be designed for both human and AI consumers, with clear decisions about discovery, access, rate limits, authentication, monitoring, and abuse controls.

The shift to AI-first API design is already under way. The practical question is how quickly API practices can catch up.

Our APIs have to evolve with their users.

Why Reasoning Models Like DeepSeek Change Everything

2025-02-03T08:13:00+11:00

Open reasoning models change how we need to think about automation and security. Looking at models like DeepSeek, the important shift is not another small gain in AI capability. It is the move towards autonomous agents that can plan, reason, and adapt without human guidance.

This became clear while analysing recent credential stuffing attacks. The patterns showed attackers using AI agents to probe systems, identify vulnerabilities, and craft custom exploits. These were not pre-programmed scripts following rigid rules. They were agents making decisions based on the system's responses.

The implications go beyond security. Consider how marketing teams usually approach A/B testing and campaign optimisation. Most tools and frameworks assume automation follows fixed paths: if this happens, do that. Reasoning models do not fit that model. They can work without predefined decision trees or explicit step-by-step instructions. They observe, learn, and create their own strategies.

This forces us to rethink basic assumptions about digital interactions. When an API call could come from an AI agent rather than a script, how do we distinguish friend from foe? Traditional markers such as request patterns, user agents, and IP addresses carry less weight when an agent can analyse and adapt to detection methods.

The same problem applies to customer engagement. Marketing funnels designed for human decision-making now face AI agents that can evaluate options systematically, compare alternatives across multiple sources, and make optimised choices. The customer journey stops being a neat linear path and becomes a space where AI agents operate alongside human users.

Reasoning models also challenge the way we approach bot management. Traditional methods focus on identifying automated behaviour: patterns that deviate from human norms. But what happens when AI agents can mimic human behaviour while operating at machine speed? The line between human and automated traffic becomes harder to draw.

Through conversations with security teams, I have seen this pattern emerge. They report sophisticated attacks that adapt in real-time, probing defences and adjusting tactics based on system responses. These are not pre-programmed behaviours. They are reasoning models understanding and responding to defensive measures.

The business impact extends beyond security. Companies need to adapt digital infrastructure for a world where AI agents become primary users. That means rethinking API design, service architecture, and customer interaction models. The question is not whether to support AI agents, but how to do it safely and effectively.

Authentication is a good example. Traditional systems often rely on proving human presence through CAPTCHAs, behaviour analysis, and device fingerprinting. In a world of reasoning models, we need approaches that focus on intent and trust rather than a simple human versus machine test.

The path forward is a shift in perspective. Rather than only trying to block or restrict AI agents, we need systems that can interact with them safely. That means moving from static rule-based security to contextual analysis that understands and adapts to agent behaviour.

The strategic implications for businesses are significant. Success in this environment requires a clear understanding of how reasoning models operate. Companies must redesign digital interfaces to support both human and AI interactions while maintaining security and control.

From my analysis of current trends, this change is accelerating. Each advance in reasoning models expands their capability and autonomy. Organisations that adapt their strategies now will be better positioned as this digital environment changes.

The rise of reasoning models is more than another technology upgrade. It changes how we approach automation, security, and digital interaction. Organisations need systems capable of engaging safely and effectively with autonomous AI agents.

The question is not whether reasoning models will change business operations. They already are. The practical question is how quickly organisations can adapt their strategies and infrastructure, and whether they can do it without losing control of trust, security, and user experience.

Preventing Enumeration Attacks

2025-01-24T00:00:00+11:00

After our overview of Visa's Security Roadmap 2025-2028, this article looks at the first focus area: preventing enumeration attacks. Visa reports a 40% increase in enumeration attacks in the first six months of 2023 compared with the previous period, and more than US$1.1 billion in global fraud losses from these attacks over the year to 30 September 2023.

Visa defines enumeration and account testing as criminal practices where fraudsters use automation to test and guess payment credentials, which can then be used for fraudulent transactions. In card-testing campaigns, attackers send large numbers of low-value authorisation attempts to validate a primary account number, expiry date, or CVV2. They tend to target online merchants with weaker fraud controls because the merchant site becomes the testing ground while issuers, acquirers, and cardholders absorb the downstream damage.

The volume share can look small. Visa notes that these attacks contribute to less than 1% of global card-not-present volume. That can make the risk easy to underweight until the business sees the operating cost: processor scrutiny, chargeback pressure, support load, infrastructure spikes, blocked genuine customers, and fraud teams trying to reconstruct what happened after the card data has already been validated somewhere else.

The Risk Is Operational Before It Is Regulatory

Enumeration is not only a payment fraud pattern. It is a production traffic problem. The attack arrives as normal-looking checkout or payment API requests, often distributed across many IPs, accounts, devices, cards, and merchants. If the only defence is a fixed IP threshold, the attacker can slow down, rotate infrastructure, or push attempts through residential proxy networks that look closer to consumer traffic.

That is why Visa's roadmap points to authentication controls, anomaly detection, real-time monitoring, velocity thresholds, CVV2 for unsecure transactions, and retries with different values as indicators of account testing behaviour. The common thread is evidence. Teams need to see the pattern across attempts, not just one failed authorisation at a time.

For merchants and acquirers, the first decision is scope. Which routes can submit payment credentials? Which APIs can create checkout sessions, payment intents, or tokenisation requests? Which responses tell an attacker whether the credential is likely valid? Which logs show retries with changed values? Which controls can act before the traffic reaches the processor?

VAMP Raises the Need for Cleaner Evidence

Visa's updated Visa Acquirer Monitoring Program (VAMP) is effective 1 April 2025. In the roadmap, Visa says VAMP brings more aligned fraud thresholds for domestic and cross-border card-not-present transactions and incorporates new enumeration criteria based on the number of enumerated authorisation transactions and the enumeration rate identified by the VAAI Score.

That does not mean every merchant needs the same control design. It does mean acquirers and merchants need better visibility into whether a burst of payment activity is genuine demand, a broken integration, friendly fraud, or enumeration. When traffic is distributed, the evidence needs to include more than source IP. Useful signals include route, account state, card-attempt cadence, response codes, device or browser consistency, proxy likelihood, country and ASN changes, header and TLS patterns, and whether retries are changing only the values an attacker is trying to validate.

Peakhour's role is at the web and API edge. Bot Management, Advanced Rate Limiting, Residential Proxy Detection, WAF, and log forwarding can help teams detect automated payment attempts, slow or block abusive routes, identify proxy-backed traffic, and retain decision evidence. Those controls support a payment security program; they do not determine VAMP standing, replace acquirer guidance, or provide legal advice.

Rate Limits Need to Follow the Attack Shape

Simple rate limits still help, but card testing rarely follows one neat source. A useful rate limit strategy looks at multiple keys: route, payment action, account, session, token, card fingerprint where appropriate, device signal, IP, ASN, country, response result, and time window. The limits should also distinguish between customer actions. A checkout page, card add route, refund path, gift card purchase, and payment authorisation API should not all share one generic threshold.

Teams also need to decide what the control does. Some traffic should be blocked. Some should be slowed. Some should be challenged before payment. Some should be logged and reviewed because false positives would create more harm than the risk being reduced. The right action depends on business context, fraud exposure, customer value, and the confidence of the signals.

Residential proxy abuse is a good example. A residential IP does not prove fraud. Many genuine users sit behind shared or mobile networks. But residential proxy use combined with high-cardinality card attempts, changed CVV2 values, first-seen devices, failed authorisations, and unusual checkout cadence is a stronger signal. The value is correlation, not a single magic indicator.

A Practical Review Path

Teams preparing for enumeration risk should start with the payment routes rather than with a vendor checklist.

Map every route that can create, submit, modify, or retry a payment attempt.
Review response messages and status codes for accidental validation clues.
Check whether logs can show velocity, retries with changed values, and route-level concentration without storing sensitive card data.
Apply route-aware rate limits and bot controls before processor calls where possible.
Add proxy, device, session, and behaviour signals to separate normal checkout friction from testing behaviour.
Keep evidence of policy version, action, route, and signal set so fraud and compliance teams can review outcomes.

The caution is important: do not turn payment logging into a second store of cardholder data. Enumeration defence needs enough evidence to detect and investigate abuse, but PCI DSS and privacy expectations still require careful handling of cardholder data, tokens, logs, and support exports.

What This Means for Peakhour Customers

Enumeration prevention is not a single feature. It is a control path around payment routes: classify the request, evaluate the signals, act proportionately, and keep evidence. Peakhour can help by applying those decisions at the edge before abusive traffic reaches the origin or payment integration.

The business value is not only fewer bad requests. It is cleaner payment telemetry, faster fraud review, fewer avoidable processor calls, and a better basis for conversations with acquirers when suspicious activity appears. Visa's roadmap makes that direction clear: payment security is moving toward data-driven, evidence-backed controls that can recognise automation abuse without blocking genuine customers by default.

How Bots Contaminate Your A/B Testing Results and Marketing Strategy

2025-01-15T13:00:00+11:00

Marketing teams invest heavily in A/B testing to optimise websites, campaigns and user experiences. These tests inform decisions about design, content and functionality. Bot traffic undermines the validity of those decisions.

The Scale of Bot Traffic

Our research shows that bots generate half of all internet traffic. This includes legitimate bots, such as search engines, and malicious bots conducting attacks. For marketing teams, this creates a direct problem: your A/B tests include manipulated responses.

Bot traffic skews test results in multiple ways. Bots do not interact with different test variants the way real users do. They follow programmed patterns rather than genuine user preferences. This contaminates the data marketing teams use to make decisions about website changes, campaign optimisation and user experience improvements.

The Impact on Marketing Strategy

Contaminated A/B test results lead to flawed strategic decisions. Marketing teams might optimise for bot behaviour rather than real user preferences. This affects several areas of strategy:

Website Design - Teams select layouts and features that perform well with bots rather than humans. Navigation flows optimise for automated traffic patterns instead of genuine user journeys. Content decisions target bot consumption rather than human engagement.

Campaign Optimisation - Bot interactions corrupt conversion rate data. Teams allocate budgets based on manipulated performance metrics. Campaigns end up catering to bot behaviour instead of real customers.

User Experience - Interface changes are skewed by bot behaviour patterns. Feature development prioritises elements that score well with automated traffic. Content strategy aligns with bot consumption rather than human needs.

The Residential Proxy Challenge

Residential proxy networks create a specific challenge for A/B testing. These proxies route bot traffic through real consumer IP addresses, making automated traffic look legitimate. Traditional bot detection methods struggle to identify this traffic.

Our research demonstrates that standard IP intelligence services miss up to 96% of residential proxy traffic. This means marketing teams include large amounts of proxy-based bot traffic in their test results without realising it.

Residential proxies mask sophisticated bot behaviour that mimics real users. The bots rotate through different residential IPs to avoid detection. They generate clicks, page views and conversions that appear genuine but represent automated rather than human interactions.

Protecting Your Tests

Marketing teams need protection measures that keep A/B test results valid. This requires a multi-layered approach to identifying and filtering bot traffic:

Detection starts with continuous monitoring of traffic patterns. Teams track user behaviour to identify automated interactions. This includes analysing click patterns, page view sequences and conversion flows that indicate bot activity.

Prevention requires sophisticated bot management capabilities. Our Bot Management solution blocks automated traffic while allowing real users to participate in tests. The system detects and filters residential proxy traffic so test data comes from genuine visitors.

Protection extends to API endpoints that support A/B testing infrastructure. Our API Security capabilities prevent bots from manipulating test data through direct API access. This ensures the integrity of test results across all interaction channels.

Making Informed Decisions

Understanding bot traffic helps marketing teams protect their investment in A/B testing. Data analysis must start by filtering bot interactions from genuine test results. Teams measure genuine user engagement rather than combined human and bot behaviour. This enables accurate assessment of test variants based on real user preferences.

Strategic planning improves once teams understand the impact of bots. Marketing decisions align with genuine user needs rather than artificial interactions. Campaign optimisation targets real customer segments instead of bot characteristics. Feature development prioritises elements that resonate with humans rather than automated traffic.

Budget allocation becomes more effective when based on clean data. Teams invest in changes that improve real user experiences rather than bot interactions. Campaign spending targets channels with verified human traffic. Development resources focus on features that drive genuine engagement.

Taking Action

Marketing teams must implement three key measures to protect A/B testing:

First, deploy comprehensive bot management to identify and block automated traffic. This forms the foundation for valid test results by ensuring participation from real users.

Second, implement residential proxy detection to prevent sophisticated bots from corrupting test data. This ensures traffic comes from genuine users rather than proxy networks.

Third, protect API endpoints that support testing infrastructure. Our Traffic Control solution provides protection across web and API interfaces.

Conclusion

Bot traffic undermines A/B testing and can push marketing teams towards flawed decisions. Past results may already contain bot interactions. The priority is to detect and filter that traffic before it shapes the next test, campaign or product decision.

Next-Generation Application Security Defence Strategies

2024-11-15T14:00:00+11:00

As I look at recent cyber threat activity, the pattern is clear enough: AI is no longer only a defensive tool. Attackers are using it to probe, adapt, and automate application-layer attacks.

One recent incident made that plain. Our threat detection systems identified a series of probes against a client's infrastructure. These were not the typical brute-force attempts we are used to blocking. The attack patterns changed in real time, adapted to our defences, and probed for weaknesses in a way that pointed to AI-driven automation.

The individual attempts were not the main concern. What mattered was how the attack system learned and adjusted its approach. When we blocked one vector, it shifted to another. When we implemented rate limiting, it distributed its attempts through residential proxies. The attack showed a common trait of AI systems: rapid iteration and learning from failure.

This change in attack methodology puts real pressure on the traditional security model. Static defences, including controls that looked strong only months ago, are easier to route around. They might stop obvious threats, but more capable AI-powered attacks can keep testing the edges until they find a path.

The threat landscape has shifted in three practical ways. First, AI enables attacks to adapt and evolve in real time. Second, residential proxies give attackers a distributed network of IP addresses that appear legitimate, making traffic origin verification much harder. Third, AI can analyse and mimic legitimate user behaviour patterns closely enough to bypass traditional bot detection.

These changes require a change in defence strategy. Identifying and blocking known attack patterns still matters, but it is no longer enough on its own. We need systems that can anticipate and adapt to new threats as quickly as they emerge.

In our security operations, we've begun implementing what we call "contextual defence dynamics." The approach moves beyond simple pattern matching to analyse the intent and behaviour behind each request. We examine not just what a request does, but how it fits into broader patterns of behaviour and what it might indicate about the attacker's objectives.

That approach has already proved useful. When we implemented contextual defence dynamics for a major e-commerce client, we identified and blocked an AI-powered credential stuffing attack that had evaded traditional detection methods for weeks. The attack used residential proxies to distribute its attempts and mimicked human behaviour patterns, but our system identified subtle anomalies in its timing and response patterns.

That case highlighted a useful point: while AI-powered attacks grow more sophisticated, they still exhibit patterns. Those patterns may not appear in individual actions, but they do appear in broader behaviour and objectives. By shifting our focus from blocking specific actions to understanding and responding to these broader patterns, we can maintain effective defences even against evolving threats.

This approach requires a different way of thinking about security. We must move from a model of static defences to one of dynamic response. Our security systems must learn and adapt as quickly as the threats they face. This means implementing machine learning systems that can identify new attack patterns, updating defence strategies in real time, and maintaining awareness of emerging threat vectors.

The implications extend beyond technical implementation. Organisations need to treat security budgets and strategies as ongoing commitments, not one-off purchases. The era of "set and forget" security solutions has ended. Continuous adaptation and review now sit at the centre of effective defence.

I expect this arms race to keep accelerating. AI will continue to enhance both attack and defence capabilities. The organisations that maintain strong security will be those that accept this dynamic and build their defences around continuous adaptation.

For security professionals, this means developing new skills and approaches. We must understand not just the technical aspects of security, but the patterns of attack and defence that emerge in AI-driven systems. We must build systems that can learn and adapt, and we must be prepared to change strategy as the threat landscape evolves.

The security arms race has entered a new phase. The advantage will not sit with the strongest static defences alone, but with teams that can adapt and evolve their protection strategies in real time. The focus must shift from building walls to creating intelligent, adaptive defence systems that can match the sophistication of AI-powered threats.

This shift in security thinking is practical, not theoretical. The threats we face are becoming more capable, and defensive tooling is improving as well. The important step is recognising the change and adapting how we build, operate, and review application security controls.

Addressing Key Cloud Security Categories

2024-05-01T10:00:00+10:00

A recent Scale Venture Partners analysis sets out emerging opportunities in cloud security after Wiz. Peakhour is a reverse proxy rather than a cloud control-plane product, but it addresses several of these categories and covers related security needs at the application edge.

Cloud Security Posture Management (CSPM)

The analysis identifies CSPM as a key category in cloud security. Peakhour is not a traditional CSPM, but it contributes to security posture management through:

Traffic Analysis: Peakhour analyses incoming traffic patterns to identify potential security risks.
Configuration Recommendations: Peakhour recommends security configuration improvements based on observed traffic patterns.

Cloud Workload Protection Platform (CWPP)

The article notes that CWPP products provide granular protection for cloud workloads. Peakhour contributes to workload protection through:

Application-Layer Filtering: Peakhour filters traffic at the application layer to protect cloud workloads.
Real-Time Threat Detection: Peakhour detects and blocks threats in real-time.

Cloud Detection & Response (CDR)

CDR focuses on detecting, investigating, and responding to incidents. Peakhour supports CDR work via:

Log Generation: Peakhour generates detailed logs of all traffic for incident investigation.
Anomaly Detection: Peakhour detects anomalous traffic patterns that indicate security incidents.
Automated Response: Peakhour responds to detected threats by blocking malicious traffic.

Cloud-Native Application Protection Platform (CNAPP)

The analysis defines CNAPP as a combination of CSPM, CWPP, and CDR. Peakhour aligns with that model through:

Integrated Security: Peakhour provides a single platform for traffic filtering, threat detection, and response.
Application-Centric Protection: Peakhour's reverse proxy design protects cloud-native applications at the application edge.

Cloud Infrastructure Entitlement Management (CIEM)

Peakhour does not directly manage cloud infrastructure entitlements, but it complements CIEM efforts through:

Access Pattern Analysis: Peakhour analyses access patterns to applications, providing insights that can inform entitlement decisions.

Non-Human Identity (NHI)

The article highlights the growing importance of managing non-human identities. Peakhour contributes to this area by:

Service-to-Service Communication Monitoring: Peakhour monitors and controls service-to-service communication.

Remediation Ops (RemOps)

RemOps focuses on managing the growing volume of security alerts. Peakhour supports RemOps through:

Alert Aggregation: Peakhour aggregates security events from traffic analysis into usable alerts.
Prioritisation: Peakhour prioritises alerts based on threat severity and potential impact.

Additional Peakhour Capabilities

Peakhour also addresses cloud security needs outside the categories covered in the Scale VP analysis:

DDoS Protection

Peakhour provides DDoS protection via:

Layer 7 Rate Limiting: Peakhour protects against application-layer DDoS attacks.
Traffic Anomaly Detection: Peakhour identifies and mitigates DDoS attacks in real-time.

Content Delivery Network (CDN)

Peakhour's delivery and cache functionality reduces cloud load and traffic bills through:

Traffic Optimisation: Peakhour reduces load on origin servers and decreases traffic bills.
Geographic Distribution: Peakhour serves content from geographically distributed nodes.

Bot Management

Peakhour manages bot traffic through:

Bot Detection: Peakhour identifies bot traffic.
Policy Control: Peakhour implements policies for managing different types of bots.
Automated Mitigation: Peakhour applies countermeasures against malicious bot activity.

Cloud Visibility

Peakhour addresses visibility gaps in modern cloud environments:

Traffic Insights: Peakhour provides detailed insights into front-end traffic patterns.
Real-Time Analytics: Peakhour delivers real-time analytics on traffic, threats, and application behaviour.

Final Thoughts

Peakhour addresses several categories identified in the Scale VP analysis of emerging cloud security opportunities. It also covers adjacent needs at the application edge, where traffic, threats, bots, delivery, and visibility meet.

See how Peakhour's Application Security Platform addresses key areas of modern cloud security. Contact our team to strengthen your cloud security posture.

The Iconic is the latest Account Takeover victim in the news

2024-01-15T13:00:00+11:00

Major Australian fashion ecommerce website theiconic.com.au recently announced it would refund victims of an account takeover attack. The attack allowed fraudsters to order items using stored credit cards in the victims' accounts and have them sent to locations in Victoria.

The fraud caused reputational damage to The Iconic, with users taking to social media to complain about both the fraud and the difficulty of contacting support to report it.

The Iconic deserves credit for issuing refunds to affected users. That stands in stark contrast to the response to a similar recent attack at 23andme.com. While 23andme victims didn't suffer any monetary loss, the website's response was to change its terms and conditions and blame the victims for reusing passwords across sites. That same password reuse is what allowed users at The Iconic to be defrauded.

EDIT: Since writing this article major websites, danmurphys.com.au, binge.com.au and guzmanygomez.com have all been affected by similar credential stuffing attacks.

So why and how are these attacks carried out, and what can you do about it?

Why are Account Takeover attacks carried out?

Financial gain remains a primary motivator. Once they gain control of an account, attackers can make unauthorised purchases (as in the case of The Iconic), transfer funds, or access credit card details. eCommerce platforms, financial services, and any site with stored payment information are particularly vulnerable. Bypassing fraud controls is another major motivator. Many eCommerce stores will trust orders from an existing account with a history, allowing fraudsters to order goods with stolen cards.

Access to sensitive information is another goal. Personal data, confidential business information, or intellectual property can be exploited for various illegal purposes, including identity theft, selling data on the dark web (23andMe), or corporate espionage.

ATO attacks can also enable further malicious activity. Compromised accounts can be used to distribute malware, launch further attacks, or perpetrate scams. This can damage the reputation of the affected website, erode user trust, and lead to significant financial and legal repercussions.

How are Account Takeover attacks carried out?

Common techniques used to compromise user accounts on websites include:

Phishing: Phishing involves tricking users into revealing their login credentials. Attackers send emails or messages resembling legitimate communications from trusted entities, directing users to fraudulent websites where their details are captured.

Credential Stuffing: This method involves using previously breached username and password pairs to gain access to accounts on different websites. Because many users reuse passwords across multiple platforms, attackers can successfully breach accounts by trying these known combinations. Credential Stuffing is the type of attack used on both The Iconic and 23andMe.

Brute Force Attacks: Attackers use automated software to generate and try a vast number of username and password combinations until they find the right one to gain access.

Social Engineering: Beyond technical methods, fraudsters often use social engineering tactics to manipulate individuals into revealing their credentials. This can be through phone calls, social media interactions, or other personal contact methods.

What can users do about it?

Users can reduce the risk of their accounts being taken over by:

Using a password manager to use strong, different passwords on different sites.
Checking their commonly used emails on have I been pwned and, if listed, making sure the exposed passwords are updated.
Making sure MFA (Multi Factor Authentication) is enabled if available on a website.
Being alert to phishing attempts. Never follow links/call numbers in emails. Go to a site directly to login/look up phone numbers. If you receive a phone call asking for personal/login information always hang up and call back on an official company number to be sure you're talking to a legitimate company representative.

What can websites do about it?

Quite a bit. Websites can minimise the risk by:

Enforcing strong passwords.
Providing MFA options on log in forms to make account takeover more difficult.
Checking logins against Have I been Pwned to alert users that their account might be compromised.
Locking accounts after 3 or more failed attempts for a set amount of time.
Emailing account holders when changes to an account happen, eg changes to email or delivery address.
Preventing automated abuse of login forms, we'll go into more detail in the next section.
Monitoring login attempts for suspicious activity, ie unusual amounts of attempts/failures and odd locations.

Preventing automated log in attempts

Credential stuffing and brute force account takeover attacks rely on trying many combinations of usernames/passwords to find valid logins. They rely on automated tools like openbullet to carry out these attacks. There are many techniques that can mitigate attacks of increasing sophistication. Some can be implemented on your server if you have the expertise, or at your CDN/WAF provider if you have one.

Block attempts to log in over HTTP 1.1. This rule relies on the fact that most attackers will be using scripting/programming languages for their automation. All modern browsers will use HTTP 2 or higher, while scripts will use 1.1 by default.
Block attempts with no/incorrect referrer header. To log in you have to visit a login page and fill out a form, automated scripts bypass the login page and POST straight to the login handler, more often than not the referring login page is missing in the request.
Use Bot Management to detect automated attempts at logging in. Bot management services can use sophisticated techniques like network and browser fingerprinting and behavioural analysis, ie mouse movement/form access/speed, to determine whether the login attempt is human or a bot.
Use Advanced Rate Limiting to limit log in attempts from a class of device. No bot management solution is foolproof, sophisticated attackers will use full browsers and rotate their IP address using residential proxies to get past protections. Traditional IP address based rate limiting is useless against these sorts of attacks. Advanced rate limiting can count attempts by the connecting program type to defeat attacks and generate alerts when an attack is happening.
Use residential proxy detection to flag logins as a fraud signal.

Conclusion

Unfortunately 23andMe used the tactic of blaming the victims for reusing passwords. While offering MFA, they didn't enforce it, and clearly didn't enforce strong passwords. Further, while they had a major security vendor in place, that vendor was either ineffective, or not utilised properly. All up 14k accounts were compromised, and 7 million other accounts accessed via a sharing feature. That level of activity should have been caught much earlier unless the attacker was extremely sophisticated and patient, carrying out their attack over a long period of time. That amount of effort belies the claim by 23andme that the "the information that was potentially accessed cannot be used for any harm". Haven't they heard of Bond villains making genetic weapons...

The Iconic have the same security vendor as 23andme and don't offer MFA. Their automated prevention is weak (no bot protection and only IP based rate limiting which allowed for 300 attempts), which allowed the attacks to happen. Desperate users were notified of changes to their accounts, but couldn't get in touch with support to prevent the attackers using their stored credit cards. To their credit, The Iconic is refunding clients.

While no countermeasure is perfect at preventing Account Takeovers, the potential loss of reputation and damage to clients makes it imperative that website owners take practical steps to prevent them. While users also bear responsibility for securing their accounts, websites that hold sensitive information need to take every possible step to protect themselves and their users, not just wash their hands and blame the victims.

HTTP Security Headers

2023-11-28T14:00:00+11:00

Traditionally, web security has focused on the server side: protecting the application itself from attack. That work is necessary, but it often leaves the client side under-specified. Client-side attacks move the exposure point into the user's browser, where the business impact can be serious.

Magecart attacks are a clear example. Attackers inject skimming scripts into websites to steal sensitive customer information, such as credit card details, directly from the user's browser. Session hijacking and Cross-Site Scripting (XSS) attacks also exploit browser vulnerabilities, leading to unauthorised access and data breaches. These attacks don't just risk user data; they can erode trust, damage reputations, and result in significant financial and legal repercussions for businesses.

HTTP security headers are practical controls for these types of attacks. Properly implemented, they instruct browsers on how to handle website content and interactions safely.

Key HTTP Security Headers

Content-Security-Policy (CSP)

Purpose: CSP prevents Cross-Site Scripting (XSS) attacks by specifying which sources browsers should allow when loading scripts, images, and other resources. It can also prevent MageCart-style attacks by restricting the host names that an injected script can communicate with.

Content-Security-Policy: script-src 'self' https://apis.google.com;

This example allows scripts to load only from the site's own domain ('self') and https://apis.google.com.

X-Frame-Options

Purpose: This header protects against clickjacking attacks by controlling whether a browser allows a page to be rendered in a <frame>, <iframe>, <embed>, or <object>.

X-Frame-Options: DENY

This setting prevents any domain from framing the content. Another option is SAMEORIGIN, which only allows framing by the same site.

X-Content-Type-Options

Purpose: This header prevents MIME-sniffing, where a browser might incorrectly interpret the content type of a resource, leading to security vulnerabilities.

X-Content-Type-Options: nosniff

This instructs the browser to follow the content type declared in the HTTP headers.

X-XSS-Protection

Purpose: This enables the browser's inbuilt XSS protection features. However, this header is largely deprecated in favour of CSP.

X-XSS-Protection: 1; mode=block

This configuration enables the protection and tells the browser to block the page if an XSS attack is detected.

Strict-Transport-Security (HSTS)

Purpose: HSTS forces the browser to use HTTPS over HTTP, ensuring encrypted communication and protecting against man-in-the-middle attacks. Alternatively, you can automatically redirect all requests to HTTPS on your web server or at your EDGE provider. For example, Peakhour allows you to set up EDGE redirects to force all traffic to HTTPS.

Strict-Transport-Security: max-age=31536000; includeSubDomains

This example tells the browser to use HTTPS for all subdomains for one year.

Conclusion

Implementing the correct HTTP security headers is a straightforward way to improve web application security. These headers form part of the first line of defence against many common security vulnerabilities. As threats evolve, keeping security headers current and properly configured helps safeguard your users and your brand.

A Tale Of Two Scoring Systems

2023-11-08T00:00:00+11:00

When exploits started targeting Atlassian Confluence - CVE-2023-22515 and CVE-2023-22518 - I needed to understand the risk quickly. Confluence is widely deployed, including by Peakhour clients, so the immediate question was what practical advice we could give them.

I started with CVE-2023-22515 and CVE-2023-22518. These were not minor bugs. Attackers could create unauthorised admin accounts, which puts the confidentiality, integrity, and availability of Confluence data directly at risk.

Paul from Secure Stack has already done an excellent analysis of the situation and identified the likely scope of the problem. It is worth reading for background; the timeline below is unashamedly lifted from that article.

The Timeline So Far

CVE-2023-22515 Impact Analysis: This bug initially hit versions 8.0.x to 8.5.3 of Confluence Server and Data Center products. The cloud SaaS versions were spared. Given Confluence's use in large organisations that do not always update quickly, the scope was still large.
Dealing with CVE-2023-22518: A week later, CVE-2023-22518 appeared. It started with a CVSS score of 9.1 and affected every single version of Confluence ever released. That put organisations outside the first CVE's affected range back in scope.
The Severity Upgrade of CVE-2023-22518: On November 7th, 2023, Atlassian raised the severity of CVE-2023-22518 to a CVSS score of 10. Ransomware exploitation had been detected and, like CVE-2023-22515, it allowed the creation of admin accounts.

Looking to EPSS for advice

For these CVEs, I leaned heavily on the Exploit Prediction Scoring System (EPSS). EPSS combines CVE information with real-world exploitation data. It estimates the likelihood of a CVE being exploited in the next 30 days and returns a score between 0 and 1 - the higher the score, the higher the risk. Read more about the applicability of EPSS for scoring vulnerabilities.

EPSS Score Changes I Observed

A major update landed on October 10, 2023, when new threat intelligence came in. The EPSS score for CVE-2023-22515 moved sharply after October 10th, indicating a higher threat level due to active exploitation.

As seen in the descending date table:

Date	EPSS Score	Percentile
2023-10-13	0.93527	0.98809
2023-10-12	0.93527	0.98809
2023-10-11	0.93527	0.98808
2023-10-10	0.00126	0.46728
2023-10-09	0.00126	0.46716

CVE-2023-22518 was still moving, with a score change the day before publication:

Date	EPSS Score	Percentile
2023-11-08	0.01852	0.86954
2023-11-07	0.00061	0.24385
2023-11-06	0.00054	0.20098
2023-11-05	0.00054	0.20099
2023-11-03	0.00054	0.20098
2023-11-02	0.00043	0.07260
2023-11-01	0.00043	0.07283

This table shows a significant increase in the EPSS score from November 1st to November 8th, indicating an escalating likelihood of exploitation.

Making Sense of the EPSS Score Changes

These shifts in EPSS scores tied in with Atlassian's vendor changelog reports:

31 Oct 2023: Atlassian's CISO sent an alert about significant data loss potential. No active exploits were reported yet, but the warning was clear.
02 Nov 2023: Critical information about the vulnerability was posted publicly, increasing the risk of exploitation.
03 Nov 2023: A customer reported an active exploit. That was a clear signal for anyone who had not patched.
06 Nov 2023: Several active exploits and ransomware uses were observed, leading to the CVSS score escalation for CVE-2023-22518.

I also checked the CVSS scores. For CVE-2023-22515, it stood at a perfect 10.0. The EPSS score for CVE-2023-22518 also showed notable fluctuations, reflecting an increasing likelihood of exploitation.

EPSS vs. CVSS in My Vulnerability Management Approach

I use EPSS as a gauge of exploitation probability. It is threat-focused, but it is not the whole picture. Asset accessibility, vulnerability type, and asset value also matter. I use EPSS alongside CVSS to get a clearer view of what we are dealing with. It is also useful to see how the CVSS scores map to EPSS severity.

Are Peakhour Clients Protected?

With the public exploit information in hand, I turned to ClickHouse to see what was happening in practice. We quickly observed active scanning. Our IP Reputation lists were also categorising those IPs, so clients using the lists correctly had another control to keep these requests away from exposed services.

This is an active list of IPs we are seeing probing for CVE-2023-2215

Client IP	IP Reputation Category
178.250.189.169	hosting
185.220.101.57	other, dos, spam, attacks, tor, hosting, datacenter
193.187.172.73	hosting
45.134.26.2	other
45.94.211.81	hosting, datacenter
46.231.179.42	datacenter, hosting
46.38.255.27	other, dos, spam, attacks, tor, hosting, datacenter
95.111.246.11	datacenter, hosting
95.85.78.75	datacenter, hosting

This is a larger list probing for already compromised instances

Client IP	IP Reputation Categories
104.234.140.11	webattacks, hosting, datacenter
104.234.140.21	hosting, datacenter
104.234.140.4	hosting, datacenter
104.234.140.8	webattacks, hosting, datacenter
144.172.76.65	hosting, datacenter, attacks
162.240.159.247	hosting, datacenter
172.233.176.52	hosting, datacenter
178.250.189.169	hosting
185.220.101.57	other, dos, spam, attacks, tor, hosting, datacenter
193.187.172.73	hosting
193.29.56.19	hosting
20.68.177.203	hosting, datacenter
203.145.142.86	attacks, bots
37.221.173.253	hosting, datacenter
45.134.26.2	other
45.248.160.61	bots
45.94.211.81	hoisting, datacenter
46.231.179.42	datacenter, hosting
46.38.255.27	other, dos, spam, attacks, tor, hosting, datacenter
54.161.151.64	hosting, datacenter
92.119.179.90	datacenter
95.111.246.11	datacenter, hosting
95.85.78.75	datacenter, hosting

This is where real-time threat intelligence earns its place in active security controls. It helps keep you under the radar and gives you early intelligence on the actors probing your applications.

We also saw evidence of follow-up attacks after the scan.

What other protections could be applied

Bot mitigation and web application firewalls (WAFs) still matter here. Bot controls help block automated abuse, including credential stuffing, scraping, and DDoS attacks. They also help distinguish legitimate human traffic from automated traffic, reducing the chance that malicious bots can exploit vulnerabilities still waiting to be patched or worked through the backlog.

Web Application Firewalls provide a separate enforcement point for web applications. They monitor, filter, and block potentially harmful requests using predefined or customisable rules, including rules for common web-based attacks such as SQL injection, cross-site scripting (XSS), and other attacks that exploit known vulnerabilities. WAF rules can be adjusted quickly as threats change. Together, bot mitigation and WAFs improve an organisation's ability to reduce exposure across a wide range of web threats.

Addressing the Backlog of Security Vulnerabilities and Patch Timelines

The Challenge of a Growing Vulnerability Backlog

Many security teams are dealing with a growing vulnerability backlog. The data is uncomfortable: 47% of security leaders report having a backlog of applications identified as vulnerable. More concerning, 66% state their backlog includes over 100,000 vulnerabilities. That accumulation matters because vulnerabilities are potential entry points for cyberattacks.

Patching Pace vs. Vulnerability Escalation

Compare that with the escalation timeline from the EPSS and CVSS data. CVE-2023-22515 and CVE-2023-22518 are useful examples:

CVE-2023-22515 and CVE-2023-22518 Escalation: These vulnerabilities escalated quickly in severity and exploitability. For instance, CVE-2023-22518's CVSS score escalated to 10, and its EPSS probability score indicated a high likelihood of exploitation shortly after discovery.
Patch Timelines: The data indicates that 78% of respondents take longer than 3 weeks to patch high-risk vulnerabilities, with 29% needing more than 5 weeks. That delay matters when vulnerabilities like CVE-2023-22515 and CVE-2023-22518 are escalating and being exploited quickly.

The Gap Between Detection and Remediation

The gap between fast vulnerability escalation and slow patching is a real weakness in security defences. A rapid increase in EPSS scores for vulnerabilities like CVE-2023-22518 signals an immediate threat, yet many organisations still have a lengthy patching process. During that window, the risk of exploitation remains high.

If I could take one scoring system to an island, which would I take?

Both the Exploit Prediction Scoring System (EPSS) and the Common Vulnerability Scoring System (CVSS) are useful, but they answer different questions. My preference leans towards EPSS because it states the likelihood of exploitation directly. A probability score is easier to act on when the question is what needs attention now.

That direct approach makes EPSS useful when explaining urgency to both technical and non-technical staff. It avoids some of the translation work that comes with security jargon and helps teams prioritise vulnerabilities quickly.

CVSS is still useful for understanding how critical a vulnerability is. It focuses on severity, including factors such as impact and exploitability. What it does not always show as plainly is the immediate threat level, and that is where EPSS is easier to use.

What next from here?

Viewed through Confluence-Ageddon, EPSS and CVSS are useful together, but they do different jobs. If you need immediate defence, reach out; we can help protect your self-hosted Confluence with a simple DNS change.

Google Chrome IP Protection vs Apple Private Relay

2023-10-25T13:00:00+11:00

Apple Private Relay and Google Chrome IP Protection both reduce how much a destination can learn from a user's original IP address. The similarity ends quickly.

Apple protects eligible Safari browsing for iCloud+ subscribers. Chrome protects selected third-party requests in Incognito. A security policy needs that scope before it decides what the changed address means.

Apple Private Relay

Apple's Private Relay documentation describes two separate relays. Apple operates the first and can see the subscriber's source address without seeing the requested destination. A third-party content provider operates the second, assigns a temporary address and connects to the destination without receiving the subscriber's original address.

Users can preserve their general location or use a broader country-and-time-zone location. Private Relay is part of iCloud+ and protects supported Safari browsing. It is not a full-device VPN.

Chrome IP Protection

Chrome's IP Protection documentation describes a narrower request filter. In Incognito, Chrome proxies third-party requests when the third-party domain is on the Masked Domain List. It uses two chained proxies and supplies a coarse-geolocation address.

The protected resource is embedded in another site. Chrome does not describe IP Protection as proxying every top-level request or all device traffic.

The Operational Difference

Question	Apple Private Relay	Chrome IP Protection
Who receives it?	Eligible iCloud+ users who enable Private Relay	Chrome users browsing in Incognito with the feature available
What traffic is in scope?	Supported Safari browsing	Listed third-party requests
How is the destination reached?	Two separate relays	Two chained proxies
What address reaches the destination?	A temporary address with selected location precision	A proxy address with coarse geolocation
Is it a full VPN?	No	No

Neither service is a residential proxy marketplace. The user activates a browser privacy feature; a remote buyer is not renting the user's connection as an exit.

That does not make every relayed request trustworthy. It means the network label should be accurate. If a login or transaction is risky, the application should explain that decision with account, route, client and behaviour evidence rather than calling privacy use malicious.

The current policy guide is Privacy Relay, Corporate VPN, or Residential Proxy?. For the broader network taxonomy, see Residential Proxy vs VPN vs Tor.

JA4 and JA4+ Network Fingerprinting

2023-10-25T13:00:00+11:00

JA4+ is the name FoxIO uses for a family of network fingerprinting methods. JA4 itself is the TLS ClientHello method. It builds on lessons from JA3, but the wider family also contains separate methods for servers, HTTP, certificates, TCP, SSH and other observations.

JA4 and JA4+

JA4 produces an a_b_c value. Its readable a section records selected connection properties and counts. The b and c sections are truncated SHA-256 values derived from normalised ClientHello fields. Analysts can compare selected components, such as JA4_ac, when the complete fingerprint is too narrow for the question being asked. Other JA4+ methods have their own inputs and specifications; they should not be treated as extra fields inside core JA4.

JA4+ consists of various components:

JA4: TLS Client
JA4S: TLS Server Response
JA4H: HTTP Client
JA4L: Light Distance/Location
JA4X: X509 TLS Certificate
JA4SSH: SSH Traffic

For a more thorough breakdown, the JA4 blog provides the announcement and describes the fingerprints.

JA4+ brings useful improvements, but a few aspects and quirks deserve closer attention.

What sorting changes

JA4 sorts cipher identifiers and most extension identifiers before hashing them. This was especially useful after Chrome began permuting TLS extension order. Sorting puts those permutations back into one cohort. It also discards the order as evidence. That is the trade-off: a more stable identifier retains less information about how the ClientHello was serialised.

Where investigation matters, retain the raw JA4 form as well as the compact value. JA4_r exposes the normalised cipher, extension and signature-algorithm lists, which makes a difference easier to inspect.

The overview of TLS fingerprinting provides a more in-depth explanation of how a TLS signature is formed.

Chrome's change was intended to stop servers and middleboxes from depending on one fixed extension order. In our extension-randomisation analysis, the number of order-sensitive TLS fingerprints rose sharply after the rollout. Sorting reduced that artificial fragmentation. It did not make the resulting value a client identity, and it did not preserve every distinction in the original handshake.

JA3 and Mercury took different paths

Before digging further into JA4+'s features and limitations, it helps to separate two related lineages. The original JA3 established a portable TLS fingerprint that was easy to share and match. Cisco Mercury developed a richer protocol representation and a separate destination-context classification system. Mercury is not a predecessor in the JA3-to-JA4 naming line. Our history of the two lineages explains where their work overlaps and where it does not.

Implementation differences still matter

While sharing signatures through SHA is appealing, it has limits, most notably potential compatibility issues. As Fastly noted, differences in the implementation can be hidden behind the SHA hash, causing issues when searching for and correlating signatures between different services. Record the implementation and version that generated a value; a shared format name does not prove that two sensors handled every field identically.

Check the method, implementation and licence

The official JA4+ repository contains the current specifications and implementations. Check the licence for the individual method before adopting it: core JA4 is BSD-3-Clause, while most other JA4+ methods use the FoxIO Licence and place additional conditions on commercial use.

For a field-level example rather than a format summary, our same-ClientHello lab records JA3, JA4, JA4_r and Mercury NPF output from one packet and pins the implementations that generated them.

Google Chrome's IP Protection and Online Privacy

2023-10-24T13:00:00+11:00

Google Chrome's IP Protection has moved well beyond the broad proposal we first covered in 2023. Its current scope is specific: selected third-party requests in Incognito are proxied when the third-party domain appears on Chrome's Masked Domain List.

That detail changes the security discussion. IP Protection is not a general-purpose VPN and it does not replace the address for every request made by the browser.

What Chrome Proxies

Google's IP Protection overview says the feature applies to requests made in a third-party context to domains on the public Masked Domain List. A top-level site and its ordinary first-party requests are outside that stated scope.

Chrome replaces the user's original address with an address carrying coarse geolocation. The implementation uses two chained proxies so neither proxy should receive both the original client identity and the final origin identity. Blind-signed authentication tokens are intended to prevent the proxy from linking handled traffic back to the signed-in Chrome account.

This is a privacy control aimed at cross-site tracking. It should not be described as a general anonymity service.

What a Website Will Notice

A listed third party can receive requests from the proxy address rather than the user's direct address. That weakens IP-based linking across sites and may alter geolocation, rate and reputation assumptions at the third-party service.

The top-level application still has its own first-party request, session, account and route evidence. Security teams should avoid turning one network category into a verdict. A Chrome privacy relay, corporate VPN, consumer VPN and residential proxy have different operating models even when each obscures the original source address somewhere in the journey.

Keep Abuse Controls Attached to the Route

An application should handle the network change the same way it handles other privacy infrastructure: retain the category, then evaluate what the request is trying to do.

On public content, the changed address may require no action. On login, recovery or payment, combine it with account history, credential evidence, device continuity, request sequence and recent outcomes. Rate limits should use keys that survive shared or changing addresses.

Privacy Relay, Corporate VPN, or Residential Proxy? provides the operational policy. For the browser comparison, read Google Chrome IP Protection vs Apple Private Relay.

ModSecurity’s End-of-Life

2023-10-16T13:00:00+11:00

The end-of-life of ModSecurity on 1 July 2024 marks a practical turning point for application security teams. For DevOps, SRE, and DevSecOps professionals, it reinforces a wider shift towards Application Security Platforms that go beyond traditional Web Application Firewall (WAF) capabilities.

Modern Application Security Platforms use Web Application and API Protection (WAAP) as a core part of edge security. Peakhour's Application Security Platform extends traditional WAF protection with bot management, API security, DDoS mitigation, and account protection, backed by Peakhour Edge delivery infrastructure.

The bedrock of a WAF lies in two main components:

WAF Engine: Inspects and assesses web traffic.
WAF Rules: Guidelines that tell the engine what to inspect and how to respond.

Peakhour's Application Security Platform has used ModSecurity as part of our WAAP solution, integrating it with threat detection, behavioural analysis, and the proven OWASP ModSecurity Core Rule Set (CRS) for application protection.

For two decades, ModSecurity has been a fixture in web security. Its acquisition by Trustwave led to a sunset announcement in 2021, with the EOL set for July 2024.

Deciphering the EOL for ModSecurity

With the EOL, Trustwave will cease commercial support and updates for ModSecurity. That does not make ModSecurity irrelevant. It has been in 'maintenance mode', with Trustwave channelling its efforts towards bug fixes and security patches.

Despite this change, ModSecurity still has active community support. Tutorials and discussions centred around ModSecurity and CRS continue to appear each month. Entities like Atomicorp have pledged to extend their support to ModSecurity beyond its EOL, helping maintain its presence in the market.

Other WAF engines are emerging as potential contenders. The Coraza WAF engine, written in Go, is gaining a place in the market. The public Azure repository hosts Microsoft's ModSecurity fork, while the Edg.IO repository highlights Waflz, showing its role in the WAF ecosystem.

Recent players, such as OpenAppSec by Checkpoint, are also entering the scene. Positioned as an open-source ML-based WAF, OpenAppSec has publicly advised businesses to start their migration strategies and views itself as a viable migration path.

Peakhour's Application Security Platform Evolution

The ModSecurity transition fits with Peakhour's move towards a broader Application Security Platform. Our approach covers:

Immediate Continuity

Operational Continuity: ModSecurity continues to function within our platform, supported by active community development
No Service Interruption: Customers experience no service interruption as we implement next-generation capabilities
Tighter Integration: Existing ModSecurity capabilities are strengthened through integration with our threat detection systems

Advanced Platform Development

Peakhour is implementing security technologies that extend beyond traditional WAF capabilities:

Machine Learning Integration: AI-powered threat detection that adapts to emerging attack patterns
Behavioural Analysis: Algorithms that identify sophisticated threats including residential proxy attacks and anti-detect browser usage
API-Native Security: Protection designed for modern API-first architectures
Real-Time Threat Intelligence: Dynamic rule updates based on global threat landscape analysis

Future-Ready Architecture

Our Application Security Platform roadmap includes:

Multi-Engine Approach: Evaluation of next-generation engines including Coraza, Waflz, and custom ML-based solutions
Request-Path Protection: Security processing at Peakhour Edge locations for performance
DevSecOps Integration: API-first architecture enabling integration with CI/CD pipelines and security automation
Comprehensive WAAP: Integration of WAF, API protection, bot management, and DDoS mitigation in a unified platform

The Future of Application Security

ModSecurity's end-of-life is more than a technical transition. It reflects the move from traditional point solutions to broader Application Security Platforms. For DevOps, SRE, and DevSecOps teams, this shift enables:

Enhanced Security Posture

Unified Threat Protection: Comprehensive WAAP capabilities that protect applications, APIs, and users through a single platform
Advanced Threat Detection: Machine learning and behavioural analysis that identify sophisticated attack vectors
Real-Time Adaptation: Dynamic security policies that evolve with the threat landscape

Operational Excellence

Performance Integration: Security processing at the edge provides protection without compromising application performance
DevSecOps Compatibility: API-first architecture supports security automation and CI/CD integration
Global Scalability: Distributed protection that scales with application growth and user distribution

Strategic Advantages

Long-Term Investment: Platform approach that evolves with emerging threats and technologies
Comprehensive Coverage: Single-pane-of-glass management for application security, performance, and availability
Compliance Alignment: Built-in reporting and monitoring capabilities that support regulatory requirements

The transition from ModSecurity gives organisations a clear point to review and modernise their application security posture. By adopting Application Security Platforms, teams can improve protection whilst maintaining the performance and scalability required for modern applications.

Peakhour's Application Security Platform protects web applications and APIs with WAAP capabilities, delivery performance, bot management, and real-time threat intelligence. Contact our security team to learn how we can support your application security posture whilst maintaining performance.

Understanding the HTTP/2 Rapid Reset Attack

2023-10-11T00:00:00+11:00

The discovery of the HTTP/2 Rapid Reset flaw exposed a serious weakness in a widely used version of the HTTP protocol. When exploited, it can be used to generate large Distributed Denial of Service (DDoS) attacks against HTTP/2 services. This post explains how the attack works and what operators can do to strengthen their defences.

A Deep Dive into the HTTP/2 Rapid Reset Flaw

HTTP/2 is widely deployed, so a flaw in how implementations handle rapid stream resets can have a large operational impact. To take advantage of the issue, a malicious actor sends a request and immediately cancels it, then repeats that pattern over the same HTTP/2 connection. By scaling this "request, cancel" behaviour thousands of times, an attacker can overwhelm vulnerable HTTP/2 implementations. The result is DDoS attacks at the application layer, with potential downtime and disruption.

Major companies including Cloudflare and Google have dealt with this issue. Google, for example, mitigated a DDoS attack reaching a peak of 398 million requests per second that relied on this technique. For scale, this two-minute-long attack generated more requests than the total number of article views reported by Wikipedia in September 2023.

Mitigating the Threat

Large infrastructure providers have led much of the work to understand the attack mechanics and develop mitigations:

Patching Systems: Prompt patching is the primary control for the HTTP/2 Rapid Reset attack. Companies including Peakhour, Microsoft, and others have tested and patched their systems against this threat.
Rate Limiting: Advanced rate limiting has been a recommended action. It provides an extra layer of protection, minimising the risk of massive request inflows.
Collaborative Efforts: Google and Microsoft have both shared intelligence and collaborated with other cloud providers and software maintainers implementing the HTTP/2 protocol stack. This has resulted in patches and mitigation techniques now employed by numerous large infrastructure providers.

What's Next for Users and Enterprises?

If you serve an HTTP-based workload online, understand whether this attack affects your environment. Verify that servers supporting HTTP/2 are either not vulnerable or have applied the necessary patches. Stay informed and consider reaching out to your service providers or account representatives for configuration assistance and guidance.

The HTTP/2 Rapid Reset flaw is a serious application-layer DDoS risk, but it is manageable with the right mitigations in place. Apply the recommended patches and keep HTTP/2-facing services under active review.

Discover how Peakhour's Application Security Platform protects against Layer 7 DDoS attacks, including the HTTP/2 Rapid Reset vulnerability. Contact our team to secure your infrastructure.

The Rise of OpenBullet

2023-09-01T14:00:00+10:00

At Peakhour, we are seeing more automation tools used to simplify interaction with web platforms. These tools have legitimate uses, including automating repetitive tasks and testing applications, but they can also be misused. OpenBullet is one example: a flexible web testing suite that has become a common tool for web attacks such as credential stuffing. This article explains how OpenBullet works, why it creates risk, which libraries it relies on, and where defenders can look for evidence of its use.

Overview of OpenBullet

OpenBullet is an automation suite for scraping, parsing data, and automated penetration testing. It is commonly used by bot developers for automated attacks, including credential stuffing. Released under the MIT open-source licence on GitHub, it is now in its second version, OpenBullet2, which, as of March 2023, had over 1.1K stars and was forked roughly 370 times.

It is particularly favoured by people with limited programming knowledge because it is easy to use and supports third-party plugins. The tool uses configurations that define the actions to perform on a website, and those configurations are easy to find online.

Types of Actions with OpenBullet

The actions OpenBullet can perform are categorised by the framework and library used. There are three broad types:

Browser Actions: Open or close tabs, maximise or minimise the browser window, and more.
Page Actions: Visit a page, fetch page attributes, set or clear cookies, click on page elements, take screenshots, and so forth.
Element Actions: Set or get element attributes, click on elements, check their status, fill in text forms, and more.

OpenBullet's versatility has made it attractive to users who share configurations freely. Advanced configurations for tasks such as scraping and credential stuffing can be found on forums and even sold.

OpenBullet Versus Other Testing Suites

One of OpenBullet's main advantages over other testing suites or automation frameworks is ease of use. It offers a visual mode, with a simple UI instead of lines of code. It also includes a high-level programming language for fine-tuning operations. It does not offer the same level of control as direct interaction with its underlying frameworks, but it can still cause significant issues for websites.

Why OpenBullet is Dangerous

OpenBullet is a threat because its simple UI lets people without programming skills create automated sequences for web attacks. Its integration with CAPTCHA farms also makes it effective against websites that rely on traditional CAPTCHAs for bot protection.

After installing OpenBullet, an attacker needs to create or import a configuration and manage bot behaviour. They can also configure proxies to distribute attacks, hide their real IP addresses, and sidestep traditional rate limiting.

OpenBullet also supports attacks like credential stuffing through a range of integrations. Attackers can add new credentials, store valid credentials, and set the configuration to run for any duration they choose.

Those underlying frameworks can leave useful evidence, but detecting Selenium, Puppeteer, or a Python HTTP client is not the same as proving that a request came from OpenBullet. Legitimate tests use the same tools.

OpenBullet and Its Underlying Libraries

OpenBullet relies on several well-known bot automation libraries and frameworks:

Requests: A Python module for sending HTTP requests with forged attributes. It's highly scalable and can bypass traditional CAPTCHAs using external CAPTCHA farm services. However, it struggles against highly protected sites and mobile applications.
Selenium: This is a browser automation framework initially developed for testing web applications. It can interact with a web service as a human user would, helping attackers mask their bots with human-like behaviours.
Puppeteer: This Node.js library controls Chromium-based browsers. It's faster and lighter than Selenium, making it capable of running more parallel requests.

OpenBullet does not inherently simulate human behaviour; the bot developer has to implement that. Based on an analysis of online configurations, most do not include fake human behaviour features. OpenBullet does, however, support ad hoc JavaScript execution to enable them.

Detecting and Blocking OpenBullet

To detect and block OpenBullet, defenders need to understand where a request is coming from, especially when proxies are used to distribute attacks. OpenBullet can be effective in the wrong hands, but it is not invisible. Several signals can help identify and block its activity.

Identifying Unusual Patterns

Most automated tools, including OpenBullet, generate request patterns that differ from typical human behaviour. The frequency, timing, and sequence of requests can help identify potential OpenBullet attacks. For instance, a high volume of requests from a single IP address, or repeated requests with different login credentials, could indicate automation.

Analysing User Agents

User agents can also provide useful clues. OpenBullet can mimic different user agents to look like a range of browsers, but it may not simulate the broader spread of user agents an actual user base would generate. If an unusual number of requests come from a small set of user agents, it may indicate an automated attack.

Spotting IP Address Anomalies

OpenBullet, like many automated tools, uses proxies to mask its true location and appear to be many different users. Proxies have their own characteristics. Data centre proxies, for instance, do not behave like residential or mobile IP addresses, and they can be flagged as suspicious. Similarly, if many different user identities come from a single IP address, or if the geolocation of an IP address does not match the stated location of the user, it may signal proxy use.

OpenBullet in the Greater Cybersecurity Context

OpenBullet reflects a broader pattern in cybersecurity: tools built for testing can be repurposed for abuse. Its simple UI and automation capabilities show why online security cannot depend on basic controls alone. Although it was created as a web testing tool, its misuse reinforces the need to keep defences current as attack methods change.

The Need for Strong Password Practices

OpenBullet's popularity for credential stuffing attacks underscores the importance of strong password practices. Encourage unique passwords, support password managers, and offer phishing-resistant multi-factor authentication. Do not force periodic password changes without evidence of compromise; predictable rotations often produce weaker passwords without removing the stolen credential from an attacker's list.

Layering Bot Protection Measures

Treat the tool name as context, not as the policy. Protect the login and recovery routes themselves: rate-limit failed attempts, watch how identities and network sources rotate, require stronger verification when several signals agree, and measure the effect on real customers. The useful question is not whether a request can be labelled “OpenBullet”. It is whether the request belongs to an abusive sequence and whether the response is proportionate to the evidence.

Advanced Rate Limiting

One practical defensive measure against stuffing attacks, including those made using OpenBullet, is advanced rate limiting. Unlike basic rate limiting, which restricts the number of requests from a particular source within a specified time frame, advanced rate limiting provides a more nuanced and dynamic approach.

A critical feature of advanced rate limiting is its ability to group, or bucket, requests based on factors beyond the source IP address. These factors could include:

Autonomous System Number (ASN): An ASN is a unique number assigned to each network on the Internet. By grouping requests by ASN, it's possible to detect an unusual number of requests from a specific network, even if those requests are spread across many different IP addresses.
Country: Grouping requests by country allows the detection of a sudden surge of traffic from a specific geographic location, which might indicate a coordinated attack.
Device Fingerprint: A device fingerprint can be constructed from a range of attributes, including the device's operating system, browser version, and more. This allows the detection of repeated requests coming from the same device, even if other factors like the IP address or user agent are being manipulated.
Headers: By examining the headers in HTTP requests, it's possible to detect patterns or anomalies that might signify an automated attack. For instance, a high volume of requests with identical headers could indicate the use of an automation tool.

By grouping requests on these and other factors, advanced rate limiting can provide a nuanced and dynamic defence against stuffing attacks. It allows detection of complex attack patterns that might otherwise go unnoticed, adding a useful layer of security for online systems.

Fingerprinting and Behavioural Analysis

Alongside advanced rate limiting, fingerprints and behaviour add context that an IP address cannot provide. A fingerprint is a cohort signal, not a unique identifier for a person or device. It becomes more useful when it is combined with route, account, request sequence, failure rate, network, and session evidence.

That combination can expose repeated login attempts hidden behind rotating proxies or changing user agents. It still needs a measured response. A weak match may justify logging or a tighter limit; several independent signals may justify a challenge; a well-established attack sequence may justify a block. This is more durable than trying to maintain a single signature for OpenBullet, because configurations and underlying clients can change while the abuse objective remains the same.

Headless Commerce Security

2023-06-28T00:00:00+10:00

At Peakhour, we spend a lot of time looking at e-commerce architecture trends. Single Page Applications (SPAs) and headless commerce keep coming up, with tools such as Nuxt.js, Strapi, Hydrogen, and Gatsby leading many builds. These tools can make frontend work faster and more flexible, but they also put more e-commerce data behind APIs that scrapers can target.

Single Page Applications (SPAs) and headless e-commerce have changed how many retailers build their storefronts. Frontend development tools like Nuxt.js and headless CMSs like Strapi are now common parts of that stack.

The trade-off is exposure. Product information is often available as JSON data, which makes it easier for scrapers to collect at scale. That raises a practical question: how do you secure data while still making it available through APIs?

Strategies for Data Protection

Data protection matters, but it is not a single control. These are the usual layers:

Rate Limiting: Controls the number of client requests to your API within a set time frame.
Bot Detection: Distinguishes between humans and bots based on behavioural patterns.
Page Load Authentication: Secures the page load through bot detection and authenticates subsequent API calls.
IP Threat Intelligence: Blocks suspicious IP addresses from accessing your API.
GeoIP Filtering: Regulates requests based on geographical origin.

As bots change, those controls need to change as well.

Facing the Challenge of Headless Scraping

Headless scraping uses browsers without a user interface to imitate normal browsing. It is difficult to detect, but network fingerprinting can help.

Network fingerprinting examines network features like Transport Layer Security (TLS) settings and HTTP/2 (H2) parameters. By analysing these, companies can detect and block bots, adding another security layer.

Client-side Security in SPAs

In SPAs, where much of the processing happens in the user's browser, the security concerns shift:

Data Exposure: Protecting sensitive data from leakage or manipulation is critical.
Injection Attacks: SPAs must guard against attacks like Cross-Site Scripting (XSS).
Authentication and Session Management: Properly handled, these prevent unauthorised access.
Insecure Direct Object References (IDORs): Proper authorisation stops attackers from accessing others' data.

Risks in JavaScript Packages

SPAs usually depend on JavaScript libraries and packages. They are useful, but they also add supply chain risk. Using only essential packages, keeping them updated, and sourcing them from trusted providers reduces that risk. Supply chain audit tools can help automate the work:

Security audits need to be frequent because vulnerabilities can appear quickly. Tools like npm's npm audit or GitHub's Dependabot, along with regular penetration testing, can help uncover potential weaknesses.

Final Thoughts

The move toward SPAs and headless commerce is a trade-off between development flexibility and security exposure. These architectures can improve user experience and speed up delivery, but they also introduce new security issues.

Client-side security in SPAs needs deliberate attention. Data exposure, injection attacks, and insecure direct object references all need to be managed, and the convenience of JavaScript libraries brings its own vulnerabilities.

Peakhour addresses these problems with rate limiting that manages request traffic and helps prevent attacks without harming customer experience. Our Web Application Firewall (WAF) examines all payload data, adding another layer of protection.

Frequent security audits still matter. They help e-commerce managers keep SPAs and headless commerce operations secure without giving up the efficiency these architectures can provide.

Advanced Anomaly Detection

2023-05-15T13:00:00+10:00

Modern Application Security Platforms need reliable anomaly detection to identify and respond to emerging threats in real-time. For DevOps, SRE, and DevSecOps teams, machine learning algorithms such as Robust Random Cut Forest (RRCF) provide the foundation for automated threat detection and response systems that can operate at the scale and speed contemporary applications require.

Strategic Importance of Anomaly Detection in Application Security

Real-time anomaly detection is a core Application Security Platform capability. It helps identify threats before attacks affect application performance or security posture:

Enterprise Threat Landscape

Modern applications face attack vectors that traditional signature-based detection cannot address:

Adaptive Bot Networks: AI-powered bots that modify behaviour based on defensive responses
Zero-Day Exploits: Previously unknown attack patterns that bypass traditional security rules
Volumetric Attacks: DDoS attacks that scale dynamically to evade rate limiting
Insider Threats: Subtle anomalies in user behaviour that indicate account compromise

Application Security Platform Requirements

Effective anomaly detection needs to integrate cleanly with broader security capabilities:

Real-Time Processing: Threat identification within milliseconds of detection
Scalable Architecture: Analysis of millions of requests without performance degradation
Context Awareness: Integration with application metadata and user behaviour profiles
Automated Response: Immediate threat mitigation through dynamic rule deployment

Advanced Machine Learning for Security

Robust Random Cut Forest provides anomaly detection capabilities designed for streaming data environments common in Application Security Platforms:

Algorithmic Advantages for Security Applications

Streaming Data Processing: Real-time analysis without historical data dependencies
Dimensionality Handling: Effective analysis of high-dimensional security feature vectors
Adaptive Learning: Continuous model updates based on evolving traffic patterns
Computational Efficiency: Linear scaling suitable for high-throughput security processing

Implementation in Application Security Platforms

RRCF enables threat detection across multiple security dimensions:

Traffic Pattern Analysis: Identification of unusual request volumes, frequencies, and distributions
Behavioural Anomalies: Detection of user actions that deviate from established profiles
Network Fingerprinting: Recognition of abnormal connection patterns and protocol usage
Content Analysis: Identification of malicious payloads and injection attempts

RRCF Advantages for Application Security Platforms

Traditional batch-processing anomaly detection systems are a poor fit for Application Security Platforms that must respond to threats in real-time. RRCF's streaming approach provides practical advantages:

Real-Time Threat Detection

Immediate Analysis: Process and analyse security events as they occur, without waiting for batch processing
Adaptive Baselines: Continuously update normal behaviour models based on current traffic patterns
Memory Efficiency: Maintain configurable rolling windows of security data for optimal performance
Scalable Processing: Handle millions of security events per second without degradation

Security-Optimised Implementation

RRCF's forest-based approach is useful for security applications:

Multi-Dimensional Analysis: Analyse request patterns, user behaviour, and network characteristics at the same time
Shape-Sensitive Detection: Identify subtle changes in attack patterns that signature-based systems miss
False Positive Reduction: Leverage ensemble methods to reduce noise in security alerting
Contextual Awareness: Understand normal application behaviour patterns for more accurate threat detection

Application Security Platform Integration

Enterprise Deployment Architecture

Peakhour's Application Security Platform implements RRCF through high-performance Rust-based processing:

Edge Processing Capabilities

Global Deployment: RRCF analysis deployed across CDN edge locations for minimal latency
Distributed Learning: Aggregated threat intelligence from multiple geographic regions
Local Response: Immediate threat mitigation at the edge without central processing delays
Bandwidth Optimisation: Process security events locally to reduce data transmission requirements

Platform Integration Benefits

Unified Threat Detection: RRCF analysis integrated with WAF/WAAP, bot management, and DDoS protection
Automated Response: Dynamic security rule generation based on anomaly detection results
DevSecOps Workflow: API-first architecture enabling integration with security automation tools
Compliance Reporting: Detailed anomaly detection logs for security audits and regulatory requirements

Advanced Security Use Cases

Credential Stuffing Detection

Behavioural Analysis: Identify unusual login patterns that indicate automated credential testing
Geographic Anomalies: Detect impossible travel scenarios and location-based attack patterns
Volume Analysis: Recognise subtle increases in authentication attempts that indicate coordinated attacks
Success Rate Monitoring: Identify campaigns through abnormal authentication success/failure ratios

API Threat Detection

Endpoint Anomalies: Detect unusual API usage patterns that indicate reconnaissance or exploitation
Rate Pattern Analysis: Identify sophisticated rate limiting evasion techniques
Response Time Analysis: Detect performance impacts from malicious API usage
Authentication Anomalies: Recognise token abuse and API key misuse patterns

Zero-Day Threat Identification

Traffic Pattern Deviations: Identify new attack vectors through unusual request characteristics
Response Pattern Analysis: Detect exploitation attempts through server response anomalies
Protocol Anomalies: Recognise malformed requests that indicate exploit attempts
Payload Analysis: Identify suspicious content patterns in request bodies and parameters

Operational Excellence Through Advanced Anomaly Detection

Performance and Security Integration

RRCF implementation delivers measurable improvements across security and performance metrics:

Threat Detection Speed: Sub-millisecond anomaly identification for real-time response
False Positive Reduction: Ensemble methods reduce security alert fatigue
System Performance: Efficient processing maintains CDN performance whilst enhancing security
Adaptive Learning: Continuous improvement in threat detection accuracy over time

DevSecOps Enablement

Modern Application Security Platforms provide APIs and automation capabilities:

Security Automation: Programmatic access to anomaly detection results for automated response
CI/CD Integration: Security testing and validation integrated into development workflows
Monitoring Integration: SIEM and SOC platform integration for security operations
Custom Rule Development: Framework for developing application-specific anomaly detection rules

Final Thoughts

Advanced anomaly detection through RRCF is a fundamental capability for modern Application Security Platforms. By implementing machine learning algorithms at the edge, organisations can achieve real-time threat detection that adapts to evolving attack patterns whilst maintaining application performance.

The integration of RRCF with security capabilities including WAAP, bot management, and DDoS protection creates a unified platform that addresses the security requirements of contemporary applications and APIs. For DevSecOps teams, this approach enables automated threat response whilst providing the visibility and control needed for effective security operations.

Chrome's TLS Extension Randomisation Experiment

2023-02-02T13:00:00+11:00

Transport Layer Security (TLS) fingerprinting is a commonly used technique for identifying client processes. To reduce the risk of server and middlebox fingerprinting of Chrome's current ClientHello and to make the TLS ecosystem more resilient to changes, Google Chrome ran an experiment to randomise a portion of the TLS fingerprint. This experiment was included in Chrome version 108, which was released on December 8, 2022. You can read the status of the current experiment on the chrome status site

The aim of this experiment was to make it more difficult for server implementers to fingerprint Chrome and assume specific implementation behaviour from a fixed extension order. By randomly ordering extensions (subject to the pre_shared_key constraint in the RFC), Chrome hoped to reduce the risk of server and middlebox fixating on details of its current ClientHello.

The above graph correlates to the Chrome experiment and subsequent release of the feature. The number of unique TLS signatures dramatically increased.

From Peakhour data, we can see a large number of unique fingerprints appearing since the date of the experiment, making it very difficult to identify the Chrome network stack by a TLS fingerprint alone. However, an analysis by David McGrew, a Cisco Fellow, cast doubt on the effectiveness of this experiment. In his article, McGrew proposed a lexicographical sorting of TLS extensions and found that 98.8% of signatures were unique after sorting. He argues that the canonical ordering of the TLS extensions in the TLS fingerprint can achieve nearly the same level of entropy as randomising them and still be effective at client identification. Furthermore, he claims that the RFC should be amended to state that extensions SHOULD be sent in an ordered fashion in the ClientHello packet. McGrew also highlights the potential dangers of allowing unordered extension lists, as it could create a \"subliminal channel\" that could be used for tracking or transmitting information. Let's now graph, over the same period, the number of TLS signatures with TLS extension sorting.

The above graph correlates to David's assertion that sorting TLS extensions has minimal impact on TLS fingerprinting.

It appears that David's assertion is correct: sorting TLS extensions has minimal impact on the number of unique TLS fingerprints. Let's now look at in-the-wild Chrome 109 data:

Hashed sorted TLS Fingerprint	Unique unsorted TLS fingerprints	Browser	Version	% of clients	% of hits
3241796329	2	Chrome Mobile WebView	109	6.14	1.01
3313291307	8566	Chrome	109	1.83	1.54
1537819294	26587	Chrome Mobile	109	6.05	4.64
3944870384	1	Chrome Mobile iOS	109	4.31	5.35
3241796329	51594	Chrome Mobile	109	16.9	14.43
1537819294	121346	Chrome	109	15.66	20.7
3241796329	156405	Chrome	109	35.52	37.79

It's interesting that the experiment does not run on WebView.

Final Thoughts

While Chrome's experiment may have reduced the risk of server and middlebox fingerprinting of Chrome's current ClientHello, it seems that randomising TLS extensions alone is not enough to prevent TLS fingerprinting, and may be a useful indicator that it is The Real Chrome.

This experiment became one of the reasons newer formats normalise extension order. Our JA3, JA4 and Mercury lab shows exactly where each format keeps, sorts or discards ClientHello detail. The accompanying history of the two TLS fingerprinting lineages explains why Cisco Mercury and JA4 made related but different design choices.

The remaining research question is whether discarded order ever helps distinguish an imitator or evasive client. Does TLS fingerprint canonicalisation hide useful attacker variation? defines the labelled corpus and holdout study needed to answer it without confusing uniqueness with detection accuracy.

TLS Fingerprinting

2023-02-02T13:00:00+11:00

What is Fingerprinting?

Fingerprinting is a technique that may be used to identify the specific device, web browser, and operating system making a request, regardless of what the client says in its user-agent header. By helping organisations identify and characterise the attributes of a client's connection, fingerprinting can improve network security and help protect against malicious traffic.

Fingerprinting can also refer to techniques for following or uniquely identifying individual users across the web. That is a separate set of techniques and is not discussed in this article.

Transport Layer Security (TLS) Fingerprinting determines the specific characteristics of a client's TLS implementation by examining the initial TLS handshake packet, known as the "Client Hello." This packet contains fields and parameters such as supported cipher suites, extensions, and the client's preferred order of those parameters, which can be used to create a unique "fingerprint" of the client's TLS implementation.

Why is it used?

Fingerprinting has several uses, including bot protection, DDoS protection, and client identification. By identifying and characterising the attributes of a client's connection, fingerprinting can improve network security and help protect against malicious traffic.

How does TLS Fingerprinting work?

TLS Fingerprinting examines the initial TLS handshake packet, known as the "Client Hello". The Client Hello packet is sent by the client during the initial phase of the TLS handshake, which establishes a secure connection between the client and the server. It contains information about the client's preferred encryption methods, extensions, and parameters, including:

Protocol Version: The version of the TLS protocol desired by the client.
Random: A 32-byte random value generated by the client, used in key generation and derivation.
Session ID: An optional session identifier for resuming a previous session.
Cipher Suites: A list of supported encryption algorithms, ordered by preference.
Compression Methods: A list of supported compression algorithms, ordered by preference.
Extensions: Optional extensions that can negotiate additional parameters, such as Server Name Indication (SNI) and Elliptic Curve Supported (ECS).

The Client Hello packet is central to the operation and security of the TLS connection because it provides information the server uses to select encryption algorithms and parameters. The packet also enables the client and server to negotiate an appropriate encryption method for their communication. The Client Hello's variable content, based on the TLS version, library, cipher suites, extensions, and settings supported by the client, makes it a strong candidate for fingerprinting.

Common components used to create a TLS fingerprint include:

Cipher Suites: The order of cipher suites supported by the client.
Extensions: Supported extensions included in the Client Hello packet, such as SNI and ECS.
TLS Point Formats: Encoding of cryptographic parameters in a format that can be transmitted as part of the TLS protocol, used in elliptic curve cryptography (ECC).
TLS Curves: The specific elliptic curves used in ECC, a type of public-key cryptography used in the TLS protocol.

TLS fingerprinting has been a topic of research for several years, with a number of tools and techniques developed from that work. Notable examples include JA3, developed by John Althouse, Jeff Atkinson, and Josh Atkins of Salesforce, which uses a hash of the client's SSL/TLS parameters as a unique identifier for tracking and analysing SSL/TLS traffic. Another tool, Mercury by David McGrew and Blake Anderson, can be used to fingerprint client connections and identify the device, operating system, and application making the connection.

TLS fingerprinting has a variety of uses, including bot protection, DDoS protection, malware identification and client identification. By enabling organisations to identify and characterise the attributes of a client's TLS implementation, TLS fingerprinting can improve network security and help protect against malicious traffic.

In production, TLS fingerprints are most useful when combined with IP intelligence and residential proxy detection, rather than treated as a standalone verdict.

Representation of a TLS Fingerprint

A TLS fingerprint is commonly represented as a string or hash that summarises the important components of the Client Hello packet. The most common components used to create a TLS fingerprint include the supported cipher suites, extensions, and TLS point formats. The cipher suites are represented as a list of hexadecimal values in the order they are presented by the client, while extensions and point formats are represented as a list of hexadecimal values or a unique identifier.

Raw JA3 signatures are represented by the following fields, which are then hashed with MD5:

SSLVersion, Cipher, SSLExtension, EllipticCurve, EllipticCurvePointFormat

An example raw signature is:

 771,4865-4867-4866-49195-49199-52393-52392-49196-49200-49162-49161-49171-49172-156-157-47-53,0-23-65281-10-11-35-16-5-34-51-43-13-45-28-21,29-23-24-25-256-257,0

An MD5 hash is then applied, resulting in the final signature.

579ccef312d18482fc42e2b822ca2430

Mercury signatures are represented by:

"tls/1" (TLS_Version) (TLS_Ciphersuite) [ Extension* ]

An example signature is:

tls/1/
(0303)
(130213031301c02cc030009fcca9cca8ccaac02bc02f009ec024c028006bc023c0270067c00ac0140039c009c0130033009d009c003d003c0035002f00ff)
[
   (0000)
   (000a000c000a001d0017001e00190018)
   (000b000403000102)
   (000d0030002e040305030603080708080809080a080b080408050806040105010601030302030301020103020202040205020602)
   (0016)
   (0017)
   (0023)
   (002b0009080304030303020301)
   (002d00020101)
   (0033)
]

Hash Functions for Representing TLS Fingerprints

Hashing algorithms, such as MD5, are commonly used to create a unique representation of a TLS fingerprint. These hash functions take the client's TLS parameters as input and produce a fixed-length output, which serves as a unique identifier for the client. The hash value can be compared against a database of known TLS fingerprints to help determine the identity of the client.

Other techniques for representing TLS fingerprints include base64 encoding of the client's TLS parameters, such as in the Mercury fingerprint.

Challenges with TLS fingerprinting

TLS fingerprinting is not a foolproof method for identifying clients and their attributes. It has several limitations that need to be considered.

False Positives: TLS fingerprinting relies on the assumption that the client's Client Hello packet uniquely identifies a connecting process by its TLS implementation. However, it is possible for a client to alter the Client Hello packet by customising TLS parameters, which affects the Client Hello packet and can result in a false positive identification. This makes it important to use multiple methods for identifying clients. For example, Mercury takes into account destination ports to add additional context.
False Negatives: While TLS fingerprinting can identify many different clients and their attributes, it is not capable of identifying all clients. Some clients may have a unique or unusual TLS implementation that cannot be accurately fingerprinted. Additionally, some clients may actively attempt to evade fingerprinting by customising TLS parameters or using tools to anonymise their connections.
Forging of TLS Fingerprints: It is possible for attackers to deliberately forge or modify the information contained in their Client Hello packet to appear as a different client. This makes it difficult for fingerprinting tools to accurately identify the true identity of a client and can be used for malicious purposes, such as evading security measures or disguising the origin of an attack.
Incomplete Data: TLS fingerprinting is limited by the information contained in the Client Hello packet, which may not contain all of the necessary data to accurately identify a client. For example, a client may not send a full list of supported cipher suites or extensions, may use a modified version of the TLS protocol that is not recognised by the fingerprinting tool, or the fingerprint may not be present in available databases.

Different fingerprinting implementations can result in different hashes for the same TLS connection, even though the underlying SSL/TLS protocol remains unchanged. This happens due to the various algorithms, parameters, and representations used by different fingerprinting tools.

For instance, implementation differences when generating the TLS fingerprint may cause hashes found in public databases to be inconsistent with a locally generated hash.

Final Thoughts

Be aware of the limitations and differences between fingerprinting implementations, and choose the right tool and representation for your specific use case. Standardising the representation of fingerprints and using common hash algorithms can help avoid confusion and improve interoperability between databases.

IP Threat Intelligence

2022-07-15T13:00:00+10:00

Threat intelligence helps organisations make earlier decisions about cyber attacks. One of the most common forms of threat intelligence in cyber security is IP reputation lists. For example, a given IP address might have a poor reputation for spam, ddos attacks, malware, and several other categories. IP reputation lists often form a front line of defence in Web Application Firewalls and cyber security solutions.

How Peakhour uses IP threat intelligence

Peakhour supports threat intelligence across more than 20 categories, including:

Active DDoS attacks
Brute forcing
Active attackers
Computers infected with malware
Anonymous Proxies
Forum Spammers
TOR anonymous users
IPs with poor reputation
Unroutable and unassigned IPs
Robots and web scrapers
Datacenter
Hosting Providers
Crawlers
And more

Customers have access to all 10 lists, which can be enabled as blocklists or used as part of a custom firewall rule, rate limiting rule, or page rule. For example, you may want to disallow POSTs from forum spammers, rate limit proxies, and outright deny traffic from known brute-forcing IPs.

Creating a spammer can't post rule

How does Peakhour assemble these lists?

The IP reputation lists are sourced from third-party sources, including open source intelligence feeds (OSINT), commercial feeds, community feeds, and our own threat intelligence. IPs are categorised into our pre-defined lists and made available to the WAF and rules engine. Each list is re-evaluated and updated based on the data provider's update schedule; some are updated every minute.

Internally managed feeds include bot sources that are verified using reverse DNS lookups, PTR record lookups, and WHOIS verification (such as Facebook IPs). WAF hits across customers are consolidated and made available as the Active Attacker list, which is updated in near real time. Our Malware and C&C nodes lists are generated from various partnerships.

The Anonymous Proxies list contains known open proxies, services that relay traffic without authentication, whilst our targeted VPN list tracks known third-party VPN services.

IPs are fed back into our system for re-evaluation to help identify emerging behaviour within our customer data.

Data visualisation

Requests from IPs that match a blocklist are tagged with the lists they belong to. Firewall events are enriched with this information, providing visibility into security threats. This context helps you decide how to handle requests, whether they should be blocked, rate limited or observed.

Firewall events generated by reputation matches

Blocks generated by our reputation lists can also be viewed in our analytics section.

Firewall events generated by reputation matches

Future work

We are working on additional data sources to further refine and expand our lists. This includes further segregating our data centre lists and categorising IPs that appear on several lists. We are also introducing our threat research centre to discover possible threats and enrich data blocked only by our WAF.

IP threat intelligence adds another layer of security to a cyber defence system. Peakhour sources and maintains up-to-date threat intelligence, helping our clients better protect themselves against would-be attackers.

See how Peakhour's IP threat intelligence supports the first line of defence for your applications. Contact our team to discuss your security requirements.

CVE-2022-26134

2022-06-02T00:00:00+10:00

On June 2, 2022, Volexity announced active exploitation of Atlassian Confluence. The issue is a Remote Code Execution vulnerability via OGNL injection, tracked as CVE-2022-26134, and impacts all Confluence Server and Data Center versions greater than 1.3.0.

Atlassian has released its security advisory with patches and mitigation instructions.

Peakhour WAF clients are already protected. Since the vulnerability was announced on June 2nd, we have observed a 200% increase in OGNL-based exploit attempts.

Peakhour's Web Application Firewall helps protect applications against zero-day exploitation attempts such as CVE-2022-26134. Contact our team to secure your applications.