Peakhour.IO - Threat Detection

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.

API Bot Abuse Does Not Stay in One Endpoint

2026-06-19T00:00:00+10:00

API bot abuse rarely stays politely inside one endpoint.

A campaign may start at login, move through token refresh, test account recovery, check saved addresses, probe checkout, abuse coupons, scrape product availability, and then return to account actions once a working session is found. Looking at each route alone makes the activity seem smaller than it is.

The pattern matters more than the individual request.

That is why API bot protection has to follow journeys, not just endpoints.

Login Is the First Measurement Point

Login endpoints are the obvious place to look for bot abuse. Credential stuffing, password spraying, brute force attempts, and token abuse all show up there.

But the login endpoint is only the first measurement point. Attackers are not trying to create a failed-login graph. They are trying to find usable accounts and move to the next action.

A bot campaign may keep failed attempts low per IP address. It may rotate through residential proxies. It may slow down to avoid simple thresholds. It may mimic the browser request shape closely enough to get past a basic check. It may use an API route that exists for the mobile app rather than the public login form.

So the useful question is not just "how many login attempts did we see?" It is "which client, route, network, fingerprint, account, and response pattern suggests automation?"

That is where bot management belongs in the account journey. It should not be an isolated "human or bot" label. It should become part of the request evidence used for login, recovery, checkout, and account-change decisions.

Checkout Abuse Is Often API Abuse

Checkout abuse is not always a stolen-card problem. It can be a request-path problem.

Bots can test coupon codes, reserve inventory, create carts, check delivery combinations, retry payment flows, and exploit business logic at machine speed. Some of this happens through visible browser journeys. Much of it happens through APIs used by the front end or mobile app.

The damage is not always dramatic in a single request. A few extra cart creations may look normal. A small number of coupon checks may be expected. A payment retry can be legitimate. The problem is the campaign shape across routes.

If the same automation profile moves through login, cart, promo, shipping, and payment APIs with abnormal timing or sequencing, the response should not depend on one endpoint crossing a crude global limit.

It should be route-aware.

A checkout API can tolerate different behaviour from a catalogue API. A payment route deserves different thresholds from a product search route. A coupon route may need controls around account age, session state, rate, and client evidence. A cart route may be harmless in one context and abusive in another.

Account Journeys Need Sensitive-Action Controls

Account abuse becomes most damaging when a session moves into sensitive actions.

Changing an email address, resetting a password, adding a new delivery address, viewing stored payment details, redeeming loyalty value, or placing an order are different from normal browsing. They deserve stronger context.

The request may be technically valid. The token may pass validation. The password may be correct. The API schema may be satisfied. That does not mean the action is safe.

A strong control model looks at the full path into that action. Did the session begin with credential stuffing signals? Is the client first seen? Did the network change? Is there proxy or fingerprint drift? Has the account recently failed login attempts? Is the request cadence consistent with a human journey? Is the action unusually soon after authentication?

These are not abstract "zero trust" slogans. They are practical checks on the account request path.

Rate Limits Need Better Keys

API abuse prevention often starts with rate limiting, but IP-only limits struggle with distributed automation and shared networks. The hard part is deciding what to count.

For API bot abuse, useful rate keys can include route, method, account, token, API key, response code, ASN, country, TLS or HTTP fingerprint, verified bot state, and combinations of headers. The right key depends on the journey.

A login endpoint might count failed attempts by account and fingerprint. A token endpoint might count refresh patterns by client and session. A checkout route might count attempts by account, payment state, and client fingerprint. A partner API might count by API key and route.

Advanced rate limiting is valuable because it can model the abusive actor more precisely than a single IP address. It also gives teams response options short of blanket blocking: log, challenge, throttle, or deny depending on the route and risk.

That matters because real API traffic includes customers, mobile apps, partners, service clients, good bots, bad bots, and increasingly AI-driven agents.

Agents Will Make the Journey Problem Harder

The next wave of automated API use will not all look like simple scripts. As discussed in Agentic AI vs. Your API, reasoning agents can explore, adapt, and change their behaviour based on responses.

That does not mean every AI agent is malicious. It does mean endpoint-by-endpoint rules will age quickly.

A reasoning agent can try one path, observe the result, and adjust. It can move from documentation to browser-backed APIs to mobile-shaped requests. It can test which routes are protected, which errors reveal state, and which actions trigger stronger checks.

Defence needs the same journey view. The campaign should be visible as it moves, even when the exact request pattern changes.

Keep Evidence Attached to the Campaign

API bot abuse is easier to manage when the evidence stays attached.

The useful record is not just "blocked by rule 42". It is the route, account state, token or key context, fingerprint, proxy signal, rate key, response pattern, action taken, and protected business step. That evidence lets teams tune controls without guessing and investigate incidents without reconstructing the whole path from raw logs.

For broader background, API abuse prevention covers the categories. The operational point is narrower: login, checkout, and account APIs should not be defended as separate islands.

Attackers use the journey.

The defence should too.

API Protection and Account Protection Are One Request-Path Problem

2026-06-19T00:00:00+10:00

Account protection is often discussed as if it belongs to the login page. That made sense when most account abuse looked like someone submitting a username and password into a web form.

That is not how modern account journeys work.

A customer signs in through a browser, a mobile app, a partner integration, a password reset flow, a token refresh endpoint, a profile update request, a checkout API, and sometimes a service-to-service call that exists nowhere in the visible front end. The account is not protected by one screen. It is protected, or exposed, by the whole request path.

That is why API security and account protection should not be treated as separate operating problems. The API route, the identity context, the client evidence, the rate pattern, the token behaviour, the bot signal, and the account action all arrive together. Splitting those signals across disconnected tools makes the final decision weaker.

The Login Is Only the Start

Credential stuffing is the obvious example. Attackers test leaked credentials against login endpoints, but the useful outcome is rarely the login itself. The value comes after the session opens.

They try to change the email address. They add a shipping address. They reset a password. They check stored cards. They redeem loyalty value. They place an order. They call account APIs that were built for the real customer journey and then abuse them in a different sequence.

If the login defence is separate from the API defence, the organisation may see only fragments:

A spike in failed logins in one dashboard.
A suspicious token refresh pattern somewhere else.
A burst of profile-change requests in application logs.
A fraud case after checkout.

Each of those is useful. None is the full story.

The better model is to keep the decision close to the request. A request to /login is different from a request to /account/email, /checkout/payment, or /api/token/refresh. The route matters. So does the method, the session state, the previous failures, the network, the client evidence, and the account action being attempted.

APIs Carry Account Risk

APIs are not just developer plumbing. They are where many account journeys now happen.

Mobile apps use APIs for login, registration, password reset, saved addresses, payment methods, and checkout. Single-page applications call APIs behind browser journeys. Partner systems may call account or order APIs directly. Internal services may use API keys or service credentials that function like non-human accounts.

That creates a practical issue: account protection must cover both human and non-human identity paths.

OAuth, JWTs, API keys, refresh tokens, and service credentials all need lifecycle control, least-privilege access, rotation, validation, and monitoring. But those controls are still not enough if the protected API cannot see whether the request is behaving like abuse.

A valid token can be stolen. A valid API key can be overused. A real session can be driven by automation. A known customer can suddenly perform a high-risk action from a first-seen client through proxy infrastructure.

The request has to be judged in context.

Rate Limiting Has to Follow Business Logic

Basic rate limiting often starts with an IP address. That is an understandable first step, but it is not enough for account protection. Attackers rotate through proxy networks. Legitimate users may share a carrier or office IP. Some attacks are low and slow enough that no single IP looks exceptional.

For account journeys, rate limiting needs to be tied to the thing being protected.

Login attempts can be counted differently from password resets. Token refreshes can be counted differently from product searches. A failed authentication response can be treated differently from a normal read request. A route hit by a first-seen client can be treated differently from one used by a known browser session.

That is the point of API protection as an operating layer, not just an API inventory exercise. The route, schema, authentication state, bot signal, and rate key should be available to the same decision. Otherwise teams end up writing compensating rules in several systems and hoping the gaps line up.

The Edge Decision Needs Options

Not every suspicious request should be blocked. Some should be logged. Some should be rate limited. Some should be challenged. Some should be allowed because the business impact of a false positive is worse than the risk presented by that specific request.

Account protection is strongest when the action matches the journey.

A login request with weak risk signals might be allowed but watched. A password reset request with stronger signals might require step-up. A checkout attempt from a newly compromised session might be blocked or reviewed. A partner API key exceeding expected usage might be throttled without affecting normal customers.

Peakhour's position here is simple: API, bot, WAF, rate, and account controls work better when they share request evidence. That can run on Peakhour Edge, or it can sit beside the CDN and cloud edge already in place through bring your own edge. The important part is not the label on the component. It is whether the request path has enough context to make the right decision.

Account Protection Is a Journey Control

A useful account protection programme should be able to answer operational questions.

Which routes are involved in account takeover attempts?
Which sessions moved from suspicious login behaviour into account changes?
Which tokens or API keys are behaving outside their expected pattern?
Which controls created friction, and where?
Which blocked requests actually protected account, checkout, or recovery actions?

Those questions cannot be answered from a login form alone. They require API visibility, account-event context, rate data, bot signals, and reviewable evidence.

That is the thesis of this series: API protection and account protection are one request-path problem. The account is compromised through a sequence of requests. The defence needs to see that sequence early enough to act.

For teams already working on account takeover prevention, the next step is not simply adding another login prompt. It is connecting the account journey to the API routes that now carry it.

How Residential Proxies Changed API and Account Abuse

2026-06-19T00:00:00+10:00

Residential proxies have changed the shape of API and account abuse. The old picture was easier to reason about: too many failed logins from one IP, a known hosting provider range, an obvious bot user agent, or a burst that crossed a threshold quickly enough to trip a rule.

That still happens, but it is not the harder problem.

The harder problem is the attempt that arrives through ordinary consumer networks, spreads itself across many addresses, and behaves just slowly enough to avoid looking like an incident. One login attempt here. A password reset probe there. A token refresh pattern that is unusual only when it is seen beside the route, the client, the ASN, the credential history, and the account event.

That is why residential proxy detection should be treated as part of the account and API decision path, not as a standalone allow/block list.

The Account Workflow Is Now a Distributed Target

Attackers do not need to break the whole application at once. They can work through the account surface in pieces:

Login attempts against known usernames.
Password reset initiation and verification.
New account registration.
Token issue and refresh routes.
Payment, address, profile, and email changes.
Loyalty, wallet, checkout, or stored-value workflows.
API calls that reveal whether an account or credential is valid.

Each route may look acceptable in isolation. The risk appears when the pattern is joined together.

A residential proxy network helps the attacker keep that pattern quiet. Requests rotate through many residential-looking exits. IP-based rate limits see different sources. A reputation feed may not have labelled a fresh or private proxy network yet. Geo checks can look plausible enough. The traffic does not necessarily arrive as a clean burst.

This is where static thinking breaks down. If the only question is "is this IP bad?", the answer will often arrive too late or be too blunt to use safely.

Fresh and Private Proxy Networks Create a Timing Problem

Many teams think about proxy detection as a database problem: look up the IP, see whether it is a proxy, then block it. That works for some traffic, especially known data centre proxies and commodity infrastructure.

Residential proxy abuse is less tidy. Fresh networks can appear before public datasets have a confident label. Private networks may not show up in broad feeds at all. Some exit points are shared with legitimate users. Some sit behind carrier-grade NAT or normal household connections. Blocking the address outright can create customer pain, while allowing it without context leaves the account flow exposed.

This is the practical reason Peakhour talks about residential proxy use as a signal. The signal matters, but it has to sit beside IP intelligence, connection characteristics, client history, request behaviour, account state, and route sensitivity.

A residential proxy on a marketing page may only need logging. The same proxy signal on a login route with recent failures may justify a challenge. On a password reset or high-value account change, it may justify step-up authentication, throttling, or blocking depending on the rest of the evidence.

The control should match the risk of the action.

Low-and-Slow Behaviour Is Still Automation

Low-and-slow abuse is uncomfortable because it avoids the easy operational story. There is no dramatic spike. There may be no single IP worth banning. The application may not be overloaded. Support may only see a few confused users, a few locked accounts, or a gradual rise in reset attempts.

For API and account workflows, this is still automation. It just looks less like a flood and more like a background process.

Useful signals include:

Repeated failed authentication across a shared fingerprint or client pattern.
Many accounts touched by similar request timing.
Token or reset routes used out of sequence.
Browser characteristics that do not match the claimed client.
Residential proxy use on sensitive account routes.
Fresh IP or ASN patterns appearing around account events.
Similar request shapes distributed across unrelated accounts.

None of these signals has to prove abuse by itself. The point is to combine them early enough that the application does not have to make the decision alone.

Peakhour's view is that proxy detection belongs in the same operating model as bot management, rate limiting, account risk scoring, and event evidence. The useful question is not "can we block every residential proxy?" It is "what should this route do when proxy use appears with this account, this client, this credential pattern, and this recent behaviour?"

API Routes Need the Same Treatment as Browser Flows

A common gap is protecting the visible login page while leaving API routes with weaker controls. Browser-side checks can help on web flows, but many account actions now happen through mobile apps, single-page applications, partner integrations, and backend APIs.

Those routes still need context. They need request-level validation, route-aware thresholds, proxy and IP signals, token checks, and evidence that can be reviewed later. A login API, a reset API, and a profile-change API should not all receive the same action just because the source address has the same reputation.

This is also why rate limiting has to move beyond source IP. A rule can key on a token, header, fingerprint, account identifier, route, response code, or a combination of signals. That makes it possible to slow failed login behaviour without punishing every legitimate user behind the same network.

The background reading on proxy detection challenges and quantifying residential proxy risk covers the broader detection problem. For API and account teams, the immediate step is more operational: find the routes where a residential proxy signal should change the action.

The Right Outcome Is Controlled Friction

Residential proxy detection is not a magic verdict. It is a way to make the account decision more honest.

Some traffic should pass. Some should be logged. Some should be rate limited. Some should be challenged. Some should be blocked. The difference should come from route sensitivity, request context, and observed behaviour, not from a single IP label.

A practical policy might look like this:

Monitor proxy use across all account and API routes.
Apply tighter thresholds on login, reset, token, and account-change routes.
Combine proxy use with credential, client, rate, and behaviour signals.
Preserve decision records so security and support can explain what happened.
Move from monitor to enforce only after reviewing false positives and customer impact.

That model gives teams a way to respond to residential proxy abuse without turning every shared residential network into a casualty.

For a grounding definition, see What is Residential Proxy Detection?. For the product control, see Residential Proxy Detection.

The important shift is simple: residential proxies are not just a network category. In account and API protection, they are context for deciding how much trust a request deserves.

Shadow APIs Are Account-Abuse Paths

2026-06-19T00:00:00+10:00

A shadow API is not dangerous because it has a mysterious name. It is dangerous because it still accepts requests.

If an endpoint can reset a password, refresh a token, check an account, change a delivery address, apply a discount, validate a stored payment method, or expose customer data, it is part of the account-abuse surface. Whether it appears in the current OpenAPI file is secondary.

Attackers do not need your API catalogue to be tidy. They need one working route that your normal controls do not understand.

The Forgotten Paths Are Often Real Paths

Most organisations have more API surface than they think.

Mobile apps leave behind old versions. Partner integrations get built for a campaign and then stay online. Browser-backed APIs are treated as internal because they are called by the front end, even though anyone can inspect and replay the requests. Legacy account endpoints remain active because turning them off might break an unknown client.

None of this is unusual. It is how real systems evolve.

The risk appears when those routes keep accepting production traffic without the same security treatment as the visible application. A current login page may have bot detection, adaptive prompts, and tuned rate limits. An older mobile endpoint may only check whether the credentials are valid. A partner route may trust an API key that has not been rotated. A browser API may return more account state than the front end displays.

That gap is where account abuse gets practical.

Unknown Does Not Mean Unused

Security teams sometimes talk about discovery as if the main outcome is a cleaner inventory. Inventory matters, but the more useful question is: what can this route do?

A shadow API that serves public catalogue data has one risk profile. A shadow API that changes account details has another. A forgotten token endpoint is different again. A mobile route that accepts username and password combinations is a credential stuffing target, even if the public login page has already been hardened.

This is why API security has to stay connected to account context. Route discovery is only the start. The protection model needs to know method, schema, authentication state, response pattern, user journey, and business sensitivity.

A POST request to an account recovery endpoint deserves different treatment from a GET request to a static content API. A password reset route used by a first-seen client through rotating proxy infrastructure is not the same as the same route used by a known customer session.

The route matters because the account outcome matters.

Browser-Backed APIs Are Still APIs

A common blind spot is the API behind the web application.

The front end might make a neat request to /api/account/profile, /api/cart/apply-coupon, or /api/session/refresh. Because the route was designed for the browser, teams may assume the browser is the control. It is not.

Requests can be replayed outside the page. Headers can be copied. Tokens can be stolen. User agents can be faked. Automation can follow the same sequence as the application, only faster and at scale.

The right response is not to treat every browser-backed API as hostile. The right response is to attach evidence. Is this a known browser session? Is the TLS and HTTP behaviour consistent? Is the request sequence normal for the journey? Is the session suddenly moving from login to sensitive account changes? Does the schema match what the route expects?

Those questions sit between basic definitions of what API security is and the operational work of stopping abuse.

Mobile and Partner APIs Need Ownership

Mobile and partner APIs create a slightly different problem. They often have legitimate non-browser clients, so crude controls can break real use.

A mobile app may have older versions in the field. A partner may send traffic from fixed infrastructure, or from changing cloud infrastructure. A service client may authenticate with an API key rather than an interactive user session. Some requests will look less browser-like because they are not meant to be browsers.

That makes ownership important.

Each route should have an owner, expected clients, authentication model, rate expectation, schema expectation, and deprecation plan. API keys should be treated as credentials, not configuration strings. OAuth and JWT use should include short-lived access, appropriate scopes, and validation at the endpoint. Legacy flows should not survive indefinitely just because nobody is sure what they support.

For REST services, that discipline includes the basics covered in REST API security: method control, status-code handling, input validation, token handling, rate limiting, and useful logging. The account-abuse angle is narrower and more operational: which of these controls tells us whether this request can harm a customer account?

Discovery Has to Feed Enforcement

A report listing unknown endpoints is useful for a week. A discovery process that feeds policy is useful every day.

When a new route appears, the security question should be concrete:

Who owns it?
Is it authenticated?
Does it match a known schema?
Does it touch account state?
Can it reset trust, change value, or expose customer data?
What rate and behaviour patterns are normal?
Which action should apply when it is abused?

That is where API protection use cases become more than documentation. The goal is not to produce a perfect catalogue for its own sake. The goal is to reduce the number of unknown request paths that can be used for account abuse.

Shadow APIs are not a separate class of attack. They are normal APIs without enough operational visibility.

And when they sit on account journeys, they become a direct path from unknown surface to customer harm.

Agentic AI vs. Your API

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

For years, "bots" mostly meant simple, scripted programs. They followed rigid, predefined rules: if you see X, do Y. They were predictable. They could still do damage in attacks like credential stuffing, but their lack of intelligence made them relatively easy to detect. Their patterns were repetitive and clearly different from the complex, often messy, behaviour of human users.

That model is no longer reliable. The emergence of open and powerful reasoning models like DeepSeek has given rise to a new class of automation: agentic AI. These are not just scripts. They are autonomous agents that can reason, plan, and adapt their behaviour in real time. They don't need a human to write a script for every possibility. Give them a goal and they can work out the steps themselves. That changes the nature of automated threats, and security controls need to change with it.

The New API Consumer

Historically, APIs were consumed by two main groups: human users via a front-end application, and scripted bots following predictable patterns. Agentic AI introduces a third consumer, and one likely to become dominant. These AI agents are becoming primary users of web APIs, and they interact with them in materially different ways.

An AI agent can analyse an entire API surface in seconds, understand the relationships between different endpoints, and generate complex interaction patterns that a human developer would rarely attempt. They don't just follow a linear path; they can explore, learn, and optimise their interactions to achieve their goals, whether that's finding the best price on a product, gathering data, or probing for security weaknesses.

New Security Challenges: The Self-Hacking AI

The reasoning capabilities of these agents introduce security challenges that static, rule-based systems are poorly equipped to handle. An agentic AI doesn't just throw known exploits at a system; it can probe its defences and invent new attacks as it goes.

Consider a traditional Web Application Firewall (WAF) that relies on pattern-matching rules to block threats like SQL injection. An AI agent can send a series of carefully crafted requests, observe the WAF's responses, and systematically learn the structure of its rules. Once it understands the patterns the WAF is looking for, it can generate a custom exploit designed to bypass those rules while still achieving its malicious objective.

This isn't theoretical. Security teams are already reporting sophisticated attacks that adapt in real time, adjusting their tactics based on the system's defensive responses. These aren't simply pre-programmed behaviours; they are reasoning models at work.

A New Security Paradigm: From "Block Bots" to "Manage Agents"

The rise of agentic AI changes the security question. The old goal of "blocking all bots" is no longer viable or even desirable. AI agents will be used for both benign and malicious purposes. A customer's personal AI assistant booking a flight is useful automation; an attacker's AI agent trying to find vulnerabilities is not.

Bot management cannot stop at trying to keep automation out. It needs the intelligence to safely identify and manage AI agents. This requires moving away from static, signature-based detection and toward a more contextual, behavioural approach.

The key questions will no longer be "Is this a human or a bot?" but rather:

"What is the intent of this automated agent?"
"Is its behaviour consistent with a legitimate use case?"
"Can we trust this agent?"

This requires a new generation of security tools that can understand and adapt to agent behaviour, distinguishing between the legitimate AI assistants that will soon be a core part of our digital lives and the malicious ones that seek to exploit our systems. Organisations that fail to prepare for this shift risk having their defences systematically tested, mapped, and bypassed by the next wave of intelligent, automated threats.

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.

Key Considerations for Effective Bot Management

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

Introduction

Bots account for a large share of web traffic. Recent studies estimate that nearly 50% of all internet traffic is generated by automated programs. Some bots are necessary for the web to function, such as search engine crawlers, but a significant portion are malicious. These "bad bots" are used for content scraping, credential stuffing, spam, and DDoS attacks.

As bot operators become more sophisticated, bot management needs to cover detection, classification, and response. This article outlines the main considerations for security teams protecting intellectual property, online revenue, and user accounts.

The Goal: Accurate Bot Detection and Classification

The first step in effective bot management is separating legitimate users from automated threats. Identification is not enough on its own. Security teams also need accurate classification across good, bad, and "grey" bots.

Good Bots: Support normal internet operations, such as search engine crawlers (Googlebot, Bingbot) and performance monitoring bots.
Bad Bots: Carry out malicious activity such as content scraping, account takeover, and spamming.
Grey Bots: Serve a legitimate purpose but can cause problems when they crawl too aggressively, such as SEO and marketing bots (Ahrefs, SEMrush).

Effective detection usually needs more than basic signatures. A layered approach commonly includes:

Basic Protection: Targets simple bots using user agent checks and IP reputation databases.
Intermediate Protection: Uses JavaScript-based challenges and basic network fingerprinting, such as JA3/JA4, to detect less sophisticated bots.
Advanced Protection: Combines comprehensive network fingerprinting, behavioural analysis, and machine learning to identify sophisticated bots that mimic human behaviour, use residential proxies, or rely on anti-detect browsers.

Machine learning models help in this context because they can learn from changing bot strategies and inspect incoming traffic for subtle signs of automation.

The Method: Continuously Adaptive Detection and Response

Bot behaviour changes quickly. Threat actors modify tooling, traffic patterns, and infrastructure to avoid detection, so static defence rules degrade over time. Organisations need detection and response that can adapt as the attack changes.

That means correlating metadata with behavioural factors in real time, then applying the right response for the risk. When a bot attempts account takeover or data scraping, an adaptive response can act immediately to reduce the impact.

Effective adaptive responses include:

Advanced Rate Limiting: Goes beyond simple IP-based limits by grouping requests with more stable identifiers, such as TLS/HTTP2 fingerprints or device characteristics. This helps stop distributed attacks from tools like OpenBullet that rotate through thousands of IP addresses.
Web Application Firewalls (WAF): Provide an important first line of defence by filtering harmful Layer 7 traffic based on predefined rules.
Tarpitting: Slows malicious connections to increase cost and resource consumption for attackers.
Challenges: Traditional visible CAPTCHAs can harm user experience and are often solvable by modern bots. Invisible challenges can verify a legitimate browser environment with less friction.
Alternate Content Serving: Misleads scraping bots by serving alternate or cached content with incorrect information (e.g., higher prices), making their scraped data useless.

The same response process should also feed learning loops, building a repository of bot attack patterns that can train machine learning models and improve accuracy over time.

The Expected Outcomes: A Resilient Security Posture

An adaptive bot management strategy should support several practical outcomes:

Risk Mitigation: Reduce potential financial losses, service disruption, and data breaches associated with malicious bot activity such as credential stuffing, ad fraud, and inventory hoarding.
Improved User Experience: Keep disruption low for genuine users by using invisible challenges and behavioural analysis instead of frustrating CAPTCHAs, which can reduce conversions by up to 40%.
Intellectual Property Protection: Protect valuable content, pricing data, and other intellectual property from unauthorised scraping.
Online Revenue Security: Protect online revenue streams by preventing fraud, inventory scalping, and other malicious activity that targets e-commerce platforms.
Regulatory Compliance: Help organisations meet data protection and privacy regulations with a proactive bot management approach.

Conclusion: Fortifying Against Sophisticated Bots

Modern bot defence depends on accurate detection, precise classification, and adaptive response. Machine learning, comprehensive network fingerprinting, and behavioural analysis all contribute, but they work best as part of a layered control set.

With that approach, security teams can better protect intellectual property, online revenue, and user accounts from sophisticated bot activity.

The Bot Spectrum

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

The word "bot" is often used as shorthand for unwanted automation: scripts trying to break into accounts, scrape content, or overwhelm websites. A large share of internet traffic does come from bad bots, but automated traffic is not automatically harmful. Some bots are part of how the web is discovered, monitored, and kept usable.

Effective bot management is not about blocking every automated request. It depends on accurate classification: separating good bots from bad bots, and recognising the "grey" bots that sit between them. That classification lets you apply controls that reduce risk without cutting off traffic that helps your site operate.

Good Bots: The Essential Workers of the Web

Good bots are automated programs that perform useful or necessary tasks. They are usually clear about who they are and respect the rules you set in your robots.txt file. Blocking them can damage search visibility, monitoring, or other business workflows.

Examples of Good Bots:

Search Engine Crawlers: Bots like Googlebot and Bingbot are the best-known good bots. They crawl and index your website's content, which is how your pages appear in search engine results. Blocking them would make your site invisible on Google.
Performance Monitoring Bots: These bots are used by services to check your website's uptime and performance from different locations around the world, and to alert you if your site goes down.
Copyright Bots: These bots scan the web for plagiarised content, helping to protect your intellectual property.

Management Strategy: Good bots should be identified and allowed to access your site freely. Verification techniques, such as reverse DNS lookups, can be used to confirm that a bot claiming to be Googlebot is actually coming from Google.

Bad Bots: The Malicious Actors

Bad bots are designed for malicious activity. They are a major reason bot management exists as a security function. These bots are deceptive, often hiding their identity and purpose, and they can be responsible for a wide range of costly and damaging activity.

Examples of Bad Bots:

Credential Stuffers: These bots use stolen usernames and passwords to carry out account takeover attacks.
Content and Price Scrapers: These bots steal your valuable content, product listings, and pricing data, often for use by competitors.
Spam Bots: These bots flood comment sections, forums, and contact forms with unwanted ads or malicious links.
Denial of Service (DDoS) Bots: These bots are part of a botnet used to overwhelm a website with traffic, causing it to slow down or crash.
Inventory Hoarding Bots: Common in e-commerce, these bots automatically add limited-edition products to shopping carts to prevent legitimate customers from buying them, often for resale at a higher price (scalping).

Management Strategy: Bad bots need to be accurately identified and blocked as quickly as possible, ideally at the network edge before they consume your server resources.

Grey Bots: The Nuanced Category

Grey bots are not inherently malicious, but their behaviour can still cause problems. They often serve a legitimate purpose, but become an issue when they crawl too aggressively, consume excessive bandwidth or server resources, and slow the site down for real users.

Examples of Grey Bots:

Aggressive SEO Tools: Bots from marketing tools like Ahrefs, SEMrush, and Majestic crawl websites to gather data for backlink analysis and competitive research. They can be useful, but their crawling can also be heavy.
Partner and Aggregator Bots: These could be bots from partner companies or price comparison websites that need to access your data. The activity may be legitimate, but it still needs to be managed.
Feed Fetchers: Bots that collect data for news aggregators or other applications fall into this category.

Management Strategy: Grey bots require more than a simple allow or block rule. The best strategy is often to rate-limit or tarpit them.

Rate-Limiting: This allows the bot to continue accessing your site, but slows it to a manageable level so it does not overwhelm your servers.
Tarpitting: This intentionally slows the connection for a specific bot, increasing the cost and time required to crawl your site and discouraging overly aggressive behaviour.

By classifying incoming bot traffic and applying the right control for each category, organisations can block threats, manage resource consumption, and allow the useful automation the modern web depends on.

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.

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.

Why We Can't Trust IP Addresses

2025-03-11T14:00:00+11:00

Blocking bad traffic by checking an IP address used to be a reasonable starting point. It is not enough anymore. The rise of residential proxies, especially mobile proxies like those from Proxidize, has weakened one of the simpler assumptions in web security: that an IP address tells you much about who is behind a request.

Why is this a problem now?

Residential proxies route traffic through real household IP addresses, so requests look as if they come from normal homes rather than data centres. Companies like Proxidize have made mobile proxy setups accessible using Android phones or USB modems.

In my presentations at AISA and other security conferences, I've described these proxies as systems that "masquerade internet usage as originating from residential and office networks," because they sit outside the assumptions used by many security controls.

What has changed recently is access. Proxidize offers kits that let anyone set up a proxy farm - from 5-modem kits at $499 to 80-modem setups for around $6,000. They have turned proxy farming into a plug-and-play system where you can be up and running "in less than 60 seconds."

The scale is large. Proxidize users process an estimated 80 billion records combined every single day: 80B+ Records Scraped Daily.

The model is also being sold as a "passive income opportunity," where people can earn money by setting up proxy farms and selling access to others. In their recent webinar, they announced plans for a "Proxidize Grid" marketplace where users can sell their proxies with "a single click through an automated Marketplace."

The BYOD mobile proxy revolution

Companies like iProxy.online have taken this further with a Bring Your Own Device (BYOD) approach. Rather than requiring specialised hardware, they let customers turn any Android device into a mobile proxy.

As Sabir, the cofounder of iProxy.online, explained in a recent interview, "You can install iProxy app here and in the dashboard you have proxy access like Socks5, HTTP accesses, and traffic goes through your device."

This means anyone with an old Android phone and a SIM card can create their own mobile proxy, lowering the barrier to entry. For around $59 per month (based on Proxidize's pricing), users get access to what Sabir calls "precious" mobile IP addresses.

Why are mobile IPs so valuable? As Sabir explains: "If you have Barcelona, we are here in Barcelona and you have like 2 million people living there and you have like several thousands of IP addresses from your mobile providers. And one IP address is shared by many. By thousands of people... And if you have mobile IP address, this cannot be blocked by Facebook or Instagram or any other services because in this case, like innocent people, like thousands of them will be blocked."

This carrier-grade NAT (CGNAT) technology means mobile IP addresses are shared across thousands of users, making broad IP blocks difficult without affecting legitimate users.

What this enables attackers to do

With residential proxies, attackers can:

Hide behind legitimate IP addresses that security systems trust
Bypass geo-restrictions to attack from what appears to be a local source
Distribute attacks across thousands of residential IPs to avoid detection
Make malicious traffic look like it comes from normal users

In my work at Peakhour.IO, we've seen a rise in attacks originating from these residential proxies. The Chinese state-sponsored group Camaro Dragon showed the potential of the model when they developed custom firmware for TP-Link routers, turning them into residential proxies for their operations. This method let them bypass traditional defences like GeoIP blocking because the traffic appeared to come from normal homes.

The broader trend is commoditisation. You no longer need to be a nation-state actor to use them. Anyone with a few hundred dollars can set up a residential proxy farm or use services like iProxy.online to route their traffic through mobile networks.

How it enables data exfiltration

Data exfiltration is harder to detect when residential proxies are involved. State-sponsored actors like Volt Typhoon have used compromised network devices to "proxy all network traffic to targets through compromised SOHO network edge devices."

This means stolen data travels through home routers or office equipment before reaching the attacker, making it harder to trace. Since the traffic appears to come from thousands of different legitimate sources, traditional data loss prevention tools struggle to identify and block the exfiltration.

I've worked with organisations that have suffered breaches where data was exfiltrated through residential proxies. In these cases, the traffic blended in with normal home user traffic, making it difficult to detect. These weren't sophisticated nation-state attacks - they were conducted by ordinary cybercriminals using commercially available residential proxy services.

How it enables credential stuffing and other attacks

Credential stuffing attacks have hit Australian businesses hard, with companies like The Iconic, Guzman y Gomez, Dan Murphy's, and others falling victim. Residential proxies help these attacks work because attackers can distribute their login attempts across thousands of residential IP addresses.

When an attack comes through residential proxies, each login attempt appears to come from a different legitimate user. IP-based rate limiting fails because no single IP shows suspicious volume. Even when security teams try to block suspicious regions, proxies let attackers appear to be local customers.

According to our research at Peakhour.IO, traditional IP intelligence services are failing to detect these proxies. Tests we conducted showed that top providers like Maxmind detected 0% of residential proxies, while even the best performer, IP Quality Score, only identified 24%.

The traffic share can be significant. We've seen cases where up to 40% of traffic to Australian e-commerce sites consists of bots using residential proxies for credential stuffing, price scraping, and inventory checking. This puts customer accounts at risk, distorts analytics, and wastes marketing budgets on fake traffic.

The TCP/IP fingerprinting challenge

One aspect of mobile proxies that makes them even more effective is the ability to match TCP/IP fingerprints with the purported device. As Sabir from iProxy.online explains:

"In some cases, your fingerprint, TCP fingerprint should match to your user agent. For example, if you like pretending to be a Mac user or iOS user or Windows user, your TCP fingerprint should be matched with your browser fingerprint."

This means detection mechanisms that look for mismatches between TCP/IP fingerprints and browser types can also be bypassed.

Anybody can now set them up

The barrier to entry for setting up residential proxies has fallen sharply. Companies like Proxidize market their products as simple to use, with statements like "Start using Proxidize in less than 60 seconds."

There are YouTube videos showing how to earn "passive income" by setting up proxy farms. One video explains how hosts can earn "$200 a month minimum" by hosting Proxidize hardware in their homes.

With iProxy.online, it's even simpler—just install an app on an Android phone, and you have a mobile proxy. As Sabir explains, "Actually your expenses are like you pay like for the SIM card, you pay a small subscription fee to the service and you just... That's it. It requires like one minute of work just to download an app."

This accessibility means residential proxy use is no longer limited to nation-states and sophisticated cybercriminal organisations. It is now within reach of anyone with basic technical skills.

The solution: per-connection detection

The rise of residential proxies means IP reputation databases are not enough on their own. As I've been explaining in my talks, "Residential proxies pose a significant challenge to traditional defense mechanisms... making malicious traffic appear legitimate."

The practical answer is per-connection detection that looks at network behaviour patterns rather than just IP addresses. At Peakhour.IO, we stack detections across layers to identify and mitigate proxy traffic.

A useful technique is analysing protocol behaviour. When traffic passes through a residential proxy, there are often detectable differences between network signatures (which come from the proxy) and the application behaviour (which comes from the third-party application).

These techniques can identify proxy connections even when they come from legitimate residential IP addresses, giving defenders a way to respond without blocking whole residential or mobile networks.

A call to action for businesses

If you're a business, especially in e-commerce, financial services, or any industry that relies on user accounts, residential proxy traffic needs to be part of your security model.

Traditional security approaches based on IP reputation, geolocation, and rate limiting are no longer sufficient. You need to implement per-connection detection that can identify residential proxy usage regardless of the source IP address.

At Peakhour.IO, we've seen organisations fall victim to attacks that could have been prevented with the right detection mechanisms. Waiting until credential stuffing or data exfiltration becomes visible is the expensive way to learn this lesson.

IP addresses alone can no longer tell us who to trust. We need to look deeper at each connection to protect systems and data now that proxy networks are easy to rent or build.

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.

Data-Driven Risk Management

2025-02-07T00:00:00+11:00

After our examination of Visa's Security Roadmap, this article looks at how Peakhour's contextual security approach supports Visa's third key focus area: shifting to a data-driven, risk-based approach.

The Evolution of Risk Management

Traditional security controls often rely on static rules and fixed thresholds. Visa's Security Roadmap 2025-2028 emphasises the need for dynamic, data-driven risk management that adapts to emerging threats while keeping operations efficient. That shift is important for attacks like credential stuffing and enumeration attacks, which exploit weak points in static defences.

Understanding Contextual Security

Contextual security moves beyond fixed rules by using real-time data analysis to assess risk and choose a proportionate response. It starts by collecting a broad set of signals for each interaction, including user behaviour patterns, device characteristics, network indicators like TLS fingerprints, geographic patterns, and historical trends.

Those signals feed a dynamic risk assessment engine with continuous monitoring and adaptive thresholds. Using techniques such as behavioural analysis and anomaly detection, the system can identify subtle deviations from normal activity that may signal a threat. The result is a response matched to the risk: triggering risk-based authentication, applying adaptive security measures, or initiating an automated threat response with customised rules.

How Peakhour Aligns with Visa's Vision

Our Contextual Security platform supports Visa's data-driven approach by combining multiple layers of defence. At the core is edge intelligence, which uses a global network to process data in real time, close to the user. This supports rapid identification of emerging threats, sharing threat intelligence across the network, and responding to attacks as they happen.

This is backed by advanced analytics that use machine learning models, behavioural analysis, pattern recognition, and anomaly detection. These tools are essential for identifying sophisticated threats, such as bots using residential proxies or anti-detect browsers. By analysing connection-level data, we can distinguish malicious automation from legitimate user traffic, a task traditional IP-based methods often fail.

This analysis supports risk-based decision-making. Instead of applying one-size-fits-all rules, our platform implements dynamic security measures. This includes adaptive authentication, contextual access controls, risk-based policies, and automated responses like advanced rate limiting, which can help stop distributed attacks.

Key Benefits of a Data-Driven Approach

Adopting a data-driven, contextual security model gives organisations practical advantages. It improves security through earlier threat detection and a reduction in false positives. The broader coverage protects against a wider range of attacks, from automated bots to manual fraud attempts.

At the same time, it can improve the user experience. By assessing risk more accurately, the system can reduce friction for legitimate users, support faster transactions, and make authentication less intrusive. This personalised security approach strengthens trust without sacrificing usability, a necessary balance for modern businesses.

Finally, this strategy improves operational efficiency. Automated responses reduce the need for manual review and intervention, optimising resource allocation. The scalable nature of the platform ensures that security can keep pace with business growth, providing a more sustainable way to manage risk.

Implementing Contextual Security

Organisations can implement contextual security by assessing their current state: reviewing existing controls, identifying data sources, and evaluating current capabilities. A planning phase then defines objectives, selects appropriate solutions, and establishes key performance metrics. Deployment follows, with systems installed, rules configured, staff trained, and performance monitored continuously.

To maximise effectiveness, teams need high-quality, real-time data collection while maintaining user privacy. They also need a robust analysis framework: well-defined risk models, adaptive thresholds, and clear policies for automation. Finally, response mechanisms should be practical to operate, with automated workflows and controls that can be monitored and refined over time.

Real-World Applications and Future Considerations

In practice, contextual security applies across several security workflows. For authentication, it enables risk-based multi-factor authentication and adaptive policies. In transaction monitoring, it allows for real-time analysis and fraud prevention. For access control, it supports dynamic permissions based on context-aware rules.

Looking ahead, organisations should prepare for the increasing role of advanced analytics, including AI and predictive analytics. Integration with other systems through APIs will be important, as will adapting to evolving regulatory requirements and new threat vectors.

Final Thoughts

The shift to data-driven risk management is an important change in security strategy. Peakhour's contextual security solutions help organisations align with Visa's vision while improving security, efficiency, and user experience. Moving beyond static rules to an adaptive defence gives businesses a better way to protect themselves and their customers in a more complex digital environment.

Learn how Peakhour's contextual security solutions can help your organisation implement data-driven risk management aligned with Visa's Security Roadmap 2025-2028. Contact our team to improve your security posture.

Did Residential Proxies enable a $600 Billion loss?

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

The DeepSeek story puts residential proxy networks under scrutiny as a possible factor in AI's latest market disruption. In January 2025, the Chinese startup's emergence erased $600 billion from Nvidia's market value by demonstrating AI capabilities that match industry leaders at a fraction of the cost.

The path to this capability raises a practical security question for AI platforms. Leading platforms protect their APIs with multiple security layers - rate limiting to prevent mass data extraction, bot detection to block automated requests, and geoblocking to restrict access from certain regions. These measures are meant to prevent the systematic collection of training data.

Residential proxy networks create a route around those protections. These networks route traffic through household IP addresses, so requests appear to originate from homes in permitted regions. A request from a restricted location could look like legitimate traffic from Sydney, Melbourne, or Perth.

The circumstances suggest this approach is plausible. By distributing requests across millions of residential IPs worldwide, each IP could maintain human-like patterns while staying below rate limits. The aggregate data could form a substantial training set without triggering security alerts.

Meta's lawsuit against Bright Data strengthens this possibility. The case exposed how proxy providers monetise residential IPs, often without homeowners' knowledge. That model creates a global network capable of bypassing traditional security measures - exactly the type of infrastructure needed for large-scale data collection.

The residential proxy industry threatens $600 billion in business value through data theft and security bypasses. DeepSeek's impact on Nvidia's market capitalisation highlights the real-world impact of residential proxies.

For AI platforms, the question is operational. How can platforms distinguish between legitimate users and well-crafted requests through residential proxies? When geographical restrictions lose meaning, what security measures remain effective? Traditional IP Intelligence based proxy detection based on historical usage is no longer effective; per-connection proxy detection is essential.

DeepSeek's emergence suggests AI security teams need to revisit their assumptions. The potential use of residential proxy networks to dissolve digital borders challenges current approaches to platform protection.

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 MTU Fingerprinting Identifies VPNs and Mobile Users

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

For traffic analysis, it helps to know how a user reached the service. Are they on a home network, a mobile connection, or a VPN? Deep packet inspection is invasive, but TCP handshake metadata can still carry useful context about the Maximum Transmission Unit (MTU) a connection appears to be using. By analysing those inferred MTU values, we can build "fingerprints" that point to the underlying network technology carrying the connection.

This article looks at how common technologies affect MTU values and shows how a SQL query can turn that data into useful network labels.

What is MTU and Why Does it Change?

The Maximum Transmission Unit (MTU) is the largest data packet, or frame, that a network-connected device can transmit. On standard Ethernet networks, this value is typically 1500 bytes. Larger payloads have to be split into chunks that fit that limit.

Encapsulation and Tunneling

The value starts to shift when tunnelling protocols are involved, including those used by VPNs and mobile networks. These protocols wrap the original data packet inside another packet, a process called encapsulation. The outer packet has its own headers for routing and management.

This encapsulation "steals" space from the original 1500 bytes available on the physical network. If a tunnelling protocol adds 60 bytes of headers, for example, the maximum size for the original data packet is now 1440 bytes (1500 - 60).

The Problem with Fragmentation

What happens if a device tries to send a 1500-byte packet through this 1440-byte tunnel? The packet has to be broken into smaller pieces, a process called fragmentation. It works, but it is inefficient. Fragmentation consumes CPU resources on the router performing it, adds header overhead to each fragment, and requires the receiving device to reassemble the pieces. The result is lower speed and higher latency.

To avoid that penalty, operating systems and network devices reduce the MTU of the connection to account for the tunnel's overhead. The amount of the reduction follows from the tunnelling protocol in use. That predictable drop is the basis for MTU fingerprinting.

A Guide to Common MTU Values

Different technologies add different overheads, which produces distinct MTU values.

WireGuard

WireGuard is a modern VPN known for its efficiency, but it still adds overhead.

IPv4 Overhead: 60 bytes (20-byte IPv4 header + 8-byte UDP header + 32-byte WireGuard header).
IPv6 Overhead: 80 bytes (40-byte IPv6 header + 8-byte UDP header + 32-byte WireGuard header).

On a standard 1500-byte network, that produces predictable MTU values:

1500 - 60 = 1440 bytes (WireGuard over IPv4)
1500 - 80 = 1420 bytes (WireGuard over IPv6)

There is a special case with ISPs that use DS-Lite (Dual-Stack Lite) to carry IPv4 traffic over an IPv6 network. This adds another 40-byte IPv6 header, reducing the MTU further.

1420 - 40 = 1380 bytes (WireGuard over DS-Lite)

OpenVPN

OpenVPN is another common VPN solution, but its fingerprint is less tidy. Instead of setting a static interface MTU, OpenVPN often uses a feature called mssfix. This dynamically adjusts the Maximum Segment Size (MSS) value within the TCP headers of encapsulated packets to prevent fragmentation.

The MSS is the MTU minus the IP and TCP header sizes (typically 40 bytes for IPv4). The exact MSS value, and therefore the effective MTU, depends on OpenVPN's configuration, including the transport protocol (UDP or TCP), cipher, MAC algorithm, and compression. As noted by security researcher ValdikSS, these unique MSS values can be used to fingerprint a connection with high precision. For example, a common configuration might result in an MSS of 1369, which corresponds to an effective MTU of 1409 (1369 + 40).

For general analysis, connections with an MTU around 1400 or 1380 bytes often indicate OpenVPN or other VPN usage, especially when seen with other factors.

Mobile Networks (LTE & 5G)

Mobile networks also modify MTU values. When your phone connects to the internet, its data is tunnelled through the carrier's network using the GPRS Tunnelling Protocol (GTP). This encapsulation adds its own layer of headers.

As detailed by Nick vs Networking, the typical overhead for GTP traffic over an Ethernet transport network is 50 bytes:

14 bytes for the Ethernet header
20 bytes for the outer IPv4 header
8 bytes for the UDP header
8 bytes for the GTP header

For a mobile carrier using a standard 1500-byte MTU on its transport network, the maximum MTU available to the user's device is 1450 bytes (1500 - 50).

Mobile devices don't guess this value; they are explicitly told what MTU to use by the network during the connection setup process (via Protocol Configuration Options). Mobile operators have two choices to avoid fragmentation:

Increase Transport MTU: Enable jumbo frames (for example, 1600 bytes or more) on their internal network to accommodate the 50-byte overhead and still provide a full 1500-byte MTU to the user.
Lower Advertised MTU: Advertise a lower MTU to the user's device. This is why values such as 1450 are common. Some operators may configure a more conservative MTU, such as 1300 bytes, to maintain stability across all parts of their network.

Other Common Values

Standard Ethernet: The baseline is 1500 bytes.
PPPoE: Common for DSL connections, adds 8 bytes of overhead, resulting in an MTU of 1492 bytes.
IPv6 Minimum: The IPv6 specification mandates a minimum MTU of 1280 bytes, so this value is also a significant marker.

Analysis with SQL

With this context, we can analyse network logs to classify user connections. The following SQL query buckets and attributes MTU values from a large dataset, turning raw numbers into meaningful labels.

The query works in several stages:

Extract Data: It parses the MTU from a fingerprint string in the logs.
Bucket MTUs: It uses a CASE statement to group MTUs. Specific known values, such as 1500, 1440, 1420, and 1380, go into their own buckets. Jumbo frames (>1500) are grouped into 100-byte buckets, and everything else is grouped into 20-byte buckets.
Attribute Buckets: In the final SELECT, another CASE statement translates those numeric buckets into human-readable descriptions based on the fingerprints we've identified.

The Query

-- Bucketing logic and attribution informed by research from:
-- https://ripx80.de/posts/06-wg-mtu/ (WireGuard)
-- https://medium.com/@ValdikSS/detecting-vpn-and-its-configuration-and-proxy-users-on-the-server-side-1bcc59742413 (OpenVPN)
-- https://nickvsnetworking.com/mtu-in-lte-5g-transmission-networks-part-1/ (Mobile Networks)
WITH base_data AS (
    SELECT
        toInt32OrNull(splitByChar(':', splitByChar(',', synner_fingerprint)[1])[4]) AS mtu,
        toInt32OrNull(splitByChar(':', splitByChar(',', synner_fingerprint)[1])[5]) AS wsize,
        toInt32OrNull(splitByChar(':', splitByChar(',', synner_fingerprint)[2])[1]) AS scale,
        (tls.handshake_rtt_us - tcp.min_rtt_us) >= 65000 AS is_high_latency
    FROM logs.client_logs
    WHERE time >= '2025-07-01' AND shielded = 0
),
main_aggs AS (
    SELECT
        CASE
            WHEN mtu = 1500 THEN 1500
            WHEN mtu = 1440 THEN 1440
            WHEN mtu = 1420 THEN 1420
            WHEN mtu = 1380 THEN 1380
            WHEN mtu > 1500 THEN 1501 + intDiv(mtu - 1501, 100) * 100
            ELSE intDiv(mtu, 20) * 20
        END AS mtu_bucket,
        countIf(is_high_latency) AS high_latency_count,
        countIf(not is_high_latency) AS normal_latency_count,
        round(avg(wsize * pow(2, scale))) AS avg_real_wsize
    FROM base_data
    WHERE mtu IS NOT NULL AND wsize IS NOT NULL AND scale IS NOT NULL
    GROUP BY mtu_bucket
),
top_wsizes AS (
    SELECT
        mtu_bucket,
        groupArray((wsize, cnt)) AS top_wsizes
    FROM
    (
        SELECT
            CASE
                WHEN mtu = 1500 THEN 1500
                WHEN mtu = 1440 THEN 1440
                WHEN mtu = 1420 THEN 1420
                WHEN mtu = 1380 THEN 1380
                WHEN mtu > 1500 THEN 1501 + intDiv(mtu - 1501, 100) * 100
                ELSE intDiv(mtu, 20) * 20
            END AS mtu_bucket,
            wsize,
            count() AS cnt,
            row_number() OVER (PARTITION BY mtu_bucket ORDER BY cnt DESC) AS rn
        FROM base_data
        WHERE mtu IS NOT NULL AND wsize IS NOT NULL AND scale IS NOT NULL
        GROUP BY mtu_bucket, wsize
    )
    WHERE rn <= 5
    GROUP BY mtu_bucket
),
top_scales AS (
    SELECT
        mtu_bucket,
        groupArray((scale, cnt)) AS top_scales
    FROM
    (
        SELECT
            CASE
                WHEN mtu = 1500 THEN 1500
                WHEN mtu = 1440 THEN 1440
                WHEN mtu = 1420 THEN 1420
                WHEN mtu = 1380 THEN 1380
                WHEN mtu > 1500 THEN 1501 + intDiv(mtu - 1501, 100) * 100
                ELSE intDiv(mtu, 20) * 20
            END AS mtu_bucket,
            scale,
            count() AS cnt,
            row_number() OVER (PARTITION BY mtu_bucket ORDER BY cnt DESC) AS rn
        FROM base_data
        WHERE mtu IS NOT NULL AND wsize IS NOT NULL AND scale IS NOT NULL
        GROUP BY mtu_bucket, scale
    )
    WHERE rn <= 5
    GROUP BY mtu_bucket
)
SELECT
    CASE
        WHEN mtu_bucket IN (1500, 1440, 1420, 1380) THEN toString(mtu_bucket)
        WHEN mtu_bucket > 1500 THEN concat(toString(mtu_bucket), '-', toString(mtu_bucket + 99))
        ELSE concat(toString(mtu_bucket), '-', toString(mtu_bucket + 19))
    END AS mtu_range,
    CASE
        WHEN mtu_bucket = 1500 THEN 'Standard Ethernet'
        WHEN mtu_bucket = 1480 THEN 'Likely PPPoE (e.g., 1492)'
        WHEN mtu_bucket = 1460 THEN 'Likely DS-Lite/GRE Tunnel'
        WHEN mtu_bucket = 1440 THEN 'Likely Mobile LTE/5G (e.g., 1450) / WireGuard over IPv4'
        WHEN mtu_bucket = 1420 THEN 'WireGuard over IPv6'
        WHEN mtu_bucket = 1400 THEN 'Likely OpenVPN / Mobile'
        WHEN mtu_bucket = 1380 THEN 'Likely OpenVPN / WireGuard over DS-Lite / Mobile'
        WHEN mtu_bucket = 1300 THEN 'Likely Mobile LTE/5G configured'
        WHEN mtu_bucket = 1280 THEN 'IPv6 Minimum'
        WHEN mtu_bucket > 1500 THEN 'Jumbo Frame'
        ELSE 'Other'
    END AS mtu_attribution,
    high_latency_count,
    normal_latency_count,
    round(high_latency_count / (high_latency_count + normal_latency_count), 2) AS high_latency_ratio,
    top_wsizes,
    top_scales,
    avg_real_wsize
FROM main_aggs
LEFT JOIN top_wsizes USING (mtu_bucket)
LEFT JOIN top_scales USING (mtu_bucket)
WHERE (high_latency_count + normal_latency_count) > 10000
ORDER BY mtu_bucket
LIMIT 50 FORMAT Vertical

Why Jumbo Frames Matter

Jumbo frames (MTU values greater than 1500 bytes) are a useful edge case in MTU fingerprinting. These frames, typically ranging from 9000-9216 bytes, are primarily used in high-performance computing environments, data centres, and enterprise networks where throughput optimisation is important.

When we detect jumbo frame MTUs in our analysis, they often indicate:

Enterprise Users: Corporate networks frequently enable jumbo frames for internal communications
Data Centre Traffic: Cloud services and CDNs often use jumbo frames between their infrastructure
High-Performance Applications: Video streaming, large file transfers, and backup operations can benefit from larger frame sizes
Network Misconfiguration: Jumbo frames sometimes appear because of network equipment misconfiguration

The presence of jumbo frames can help distinguish consumer and enterprise traffic, adding useful context for traffic classification and security analysis.

Practical Use Cases and Applications

MTU fingerprinting is useful across several security and operational domains:

Security Applications

VPN Detection for Compliance: Organisations can identify employees bypassing corporate network policies with personal VPNs, supporting compliance with data governance requirements.

Bot Traffic Classification: Automated traffic from residential proxy networks often shows consistent MTU patterns that differ from genuine residential users, improving bot detection.

Threat Intelligence Enhancement: Correlating MTU patterns with other indicators helps build broader threat profiles and improves attack attribution.

Network Operations

Performance Optimisation: Understanding the MTU distribution of your user base helps optimise content delivery and reduce fragmentation-related performance issues.

Infrastructure Planning: MTU analysis reveals the underlying network technologies your users employ, informing CDN placement and capacity planning decisions.

Quality of Service: Different MTU patterns correlate with connection quality, enabling proactive support for users on constrained networks.

Business Intelligence

Market Analysis: Geographic and demographic patterns in MTU distribution reveal technology adoption trends and market characteristics.

User Experience Optimisation: Identifying users on mobile or constrained networks enables adaptive content delivery and interface optimisation.

Dynamic Analysis vs Static IP Databases

MTU fingerprinting is a dynamic signal, which makes it useful alongside static IP reputation databases. It has several practical advantages:

Real-Time Adaptation

Static IP databases go stale. A residential IP address might be flagged as malicious based on historical activity, but MTU fingerprinting analyses the current network configuration. This dynamic approach captures the infrastructure being used at the moment of connection, providing more accurate and timely intelligence.

Circumvention Resistance

Attackers can rotate IP addresses or use clean residential proxies to bypass static blacklists. It is harder to manipulate the network characteristics that influence MTU values, because MTU is determined by the underlying network infrastructure.

Granular Classification

Where IP databases provide binary classifications (malicious/benign), MTU fingerprinting offers more detail on the specific technologies and configurations in use. This granularity enables more sophisticated risk assessment and response strategies.

Reduced False Positives

Static databases often flag legitimate users sharing IP addresses with malicious actors, which is common with residential ISPs and mobile carriers. MTU fingerprinting focuses on network behaviour rather than IP reputation, reducing false positive rates while maintaining security effectiveness.

Infrastructure Transparency

MTU analysis reveals the network path and technologies involved in a connection, providing transparency that static IP databases cannot match. This visibility enables more informed security decisions and a better understanding of threat actor capabilities.

Conclusion

MTU fingerprinting turns network metadata into useful context about the infrastructure behind a connection. Unlike static databases that rely on historical reputation, this dynamic analysis technique provides real-time insight into network technologies, user behaviours, and potential security threats.

By understanding MTU patterns, security teams can identify VPN usage, classify mobile traffic, detect residential proxy abuse, and optimise network performance. Its resistance to circumvention and low false-positive rates make it a useful addition to modern security architectures.

As network technologies continue to evolve, MTU fingerprinting provides a stable way to understand and classify traffic based on fundamental network characteristics rather than short-lived indicators. That makes it a practical signal for network security and operations.

Anti-Detect Browsers

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

Anti-detect browsers matter to defenders because they attack the assumptions behind browser trust. Many bot and fraud controls look for consistency between the browser, network, session, and behaviour. Anti-detect tooling is designed to make automated or repeated activity look more like separate ordinary browser sessions.

This article is not a guide to using those tools. The defensive question is simpler: when a browser tries to look ordinary, what can still be observed safely, and how should that evidence affect a request decision?

Why They Create Risk

Anti-detect browsers are often discussed as a browser-fingerprinting problem, but the risk is wider than that. The same traffic may also involve residential proxies, credential lists, automation, and API requests that never run browser-side checks. A login attempt, account creation flow, product scrape, checkout request, or mobile API call may look valid at the protocol level while still being part of an automated campaign.

The hard part is that some signals are genuinely ambiguous. A changed browser, a new device, a shared network, or a privacy tool does not prove abuse. A defensive system has to treat those observations as risk inputs, not as standalone verdicts.

Browser Consistency Is Evidence, Not Identity

Anti-detect tooling tries to make browser-reported attributes look internally consistent. That weakens simple checks that only ask whether the browser appears plausible. Defenders need a broader view: does the claimed browser line up with the network stack, TLS and HTTP behaviour, session history, cookie continuity, route sequence, response-code pattern, and recent account behaviour?

That does not mean a fingerprint identifies a person. Fingerprints classify software, client behaviour, and connection characteristics. They can help separate likely automation from ordinary traffic, but they need to be combined with route, account, proxy, and behavioural context. The result should be a risk classification with evidence attached, not an unexplained block.

Residential Proxies Change the Decision

Residential proxies are a common companion signal because they make requests appear to come from consumer networks. That creates a false-positive problem. Real customers also use shared residential, mobile, office, carrier-grade NAT, and public Wi-Fi networks. Blocking every suspicious or shared source would damage legitimate traffic.

The safer approach is to use residential proxy detection as one input in the decision. A proxy signal on a public content page may be logged. The same signal on repeated login failures, account creation, checkout abuse, or sensitive APIs may justify a challenge, rate limit, or block. Context changes the action.

The API Gap

Browser-side checks are weakest where the browser is not present. Mobile apps, partner integrations, token routes, and direct API clients may not expose the same JavaScript or browser evidence that a web page does. Attackers do not need a convincing browser if the target workflow accepts valid-looking API requests.

That is why anti-detect risk belongs in the wider application security model. API routes need method, schema, authentication, token, request cadence, response-code, account, and bot context. If the only signal available is an IP address, the decision will be too blunt.

Observable Signals Defenders Can Use

The useful evidence is usually the mismatch between what the request claims to be and how it behaves over time. A browser may look plausible on one request, but the wider pattern can still show automation: repeated attempts across accounts, route sequences that normal users do not follow, cache-miss pressure on expensive pages, unusual response-code loops, or browser and network characteristics that drift in ways ordinary clients rarely do.

Bot Management works best when it combines these signals rather than chasing a single magic detector. IP intelligence, proxy classification, network and browser fingerprints, route-aware rates, API state, WAF findings, and behaviour should all feed the same action vocabulary: allow, challenge, rate limit, block, log, or review.

Safer Defensive Response

The defensive response should be proportionate. High-confidence exploit traffic can be blocked quickly. Uncertain browser or proxy evidence may be better challenged, rate limited, or logged until the pattern is clearer. Sensitive routes should have tighter policy than public content. Account-impacting actions should preserve enough evidence for review.

This is especially important for support teams. If a real customer is challenged or blocked, operators need to see which signal drove the action and which route was involved. Without that record, anti-bot policy becomes a black box.

Final Thoughts

Anti-detect browsers are a practical problem because they reduce the value of simple browser checks. They do not make traffic invisible. They leave request-path evidence in network behaviour, route sequences, account activity, API usage, proxy signals, and response patterns.

The right goal is not to identify a person from a fingerprint or to block every unusual browser. The goal is to classify risk with enough context to choose a safe action at the edge, then keep the evidence available for tuning and review.

Residential Proxies - The Growing Threat to Ad Campaigns

2024-12-30T00:00:00+11:00

Digital advertising fraud costs organisations $42 billion annually through fake clicks and fake impressions. The growth of residential proxy networks has changed how this fraud reaches campaigns: bot traffic can now hide behind legitimate residential IP addresses, putting it outside the reach of many traditional checks.

Hiding in the crowd

Residential proxies make bad traffic harder to separate from real visitors. Unlike data centre IPs that traditional tools can often detect, residential proxies hide behind real households' internet connections. This means the traffic appears to come from genuine users in your target market. When a residential proxy network operates from Sydney suburbs to attack an Australian campaign, existing protection systems can be fooled into treating it as authentic local traffic.

The impact extends beyond direct financial losses. Your analytics may show engagement from what appears to be your target demographic, while the activity is bot traffic masquerading as potential customers. This contaminated data can push marketing strategy in the wrong direction and waste retargeting spend. Competitors can also use fake clicks to drain your budget while gathering intelligence on your campaigns.

Bad data then compounds the spend problem. Once bots are counted as engaged prospects, reporting and optimisation start from the wrong signal. The result is not only wasted media spend, but poorer decisions built on traffic that should never have been treated as customer intent.

A growing threat

The residential proxy industry continues to expand. Services now offer millions of residential IPs with precise geographic targeting capabilities. They rotate IPs automatically and match real browser fingerprints. Without specialised detection methods, the traffic can become indistinguishable from genuine users.

This is a budget problem, not just a technical one. Each day without protection means 30-40% of your ad budget feeds bot networks instead of reaching customers. The corrupted analytics drive decisions that compound these losses. As residential proxy services grow more sophisticated, basic controls fall further behind.

Traditional IP reputation and rate limiting fail against this distributed threat because the IP addresses are not obviously suspicious. Protection requires advanced network fingerprinting that looks beyond IP addresses. Peakhour's Ad Fraud Protection analyses subtle patterns in how residential proxies connect and behave, and detects the signs of proxy traffic that other solutions miss.

Knowledge is power

Peakhour integrates this protection with your existing ad platforms to stop fraud before it affects your campaigns. Our customers have reduced wasted ad spend by 35% while improving campaign performance through cleaner analytics. The system adapts as threat techniques change, so detection keeps pace with new residential proxy methods.

Residential proxies have changed ad fraud because traffic that appears local and legitimate may mask sophisticated bot networks. Protecting your campaigns requires detection that goes beyond IP addresses and treats residential proxy behaviour as its own signal. Contact us to learn how we can help secure your ad spend against residential proxy networks.

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.

Your Anti-Fraud Residential Proxy Detection Sucks

2024-10-04T13:00:00+10:00

Online fraud is big business: account takeovers, chargebacks, scams, even romance scams. It costs businesses billions of dollars every year.

A common way websites fight it is to use an anti-fraud service to calculate the risk of a transaction. Most teams get this intelligence from a third-party service, either through an API or a plugin.

For online stores, ecommerce fraud prevention has to protect checkout and account flows without punishing real customers.

One of the major signals these services use is IP reputation. IP reputation tries to answer questions like:

Is the order coming from a datacentre?
Is it coming from a country other than your target audience?
Is the IP address a known VPN?
Is it a known TOR exit node?
Have lots of fraudulent orders come from this IP address in the past?

Until recently, these services gave teams a useful way to calculate fraud risk from an IP address.

Not anymore.

Fraud traffic has shifted in recent years, away from VPNs and TOR and toward residential proxies. These same anti-fraud services claim they can detect residential proxies, but what if the services many businesses rely on are falling well short?

The results are bad enough that they deserve a blunt look.

The Shocking Truth: Our Results

We took 25 IP addresses that had just been used as residential proxies in an attack on one of our clients, and within 5 minutes of detection ran them through some of the most popular IP intelligence services. The results are not going into anyone's marketing deck.

Here's a summary of our findings:

Service	Detected Proxies	Accuracy
Maxmind	0/25	0%
IP Quality Score	6/25	24%
Seon	1/25	4%
ProxyCheck.io	0/25	0%
ip2proxy	1/25	4%

The best performer in our test, IP Quality Score, detected only 24% of the proxies. The others ranged from 0% to 4%.

Why Your Residential Proxy Detection Service is Failing You

So why are these services performing so poorly? To understand it, we need to look at how proxy usage and detection have changed.

The Good Old Days of Proxy Detection

In the recent past, detecting proxies was much easier. Fraudsters primarily used:

TOR networks
VPN services
Data center proxies

These were relatively static targets. They were tied to a single, stationary IP, or IP ranges. Listing them in IP block lists was straightforward.

The Rise of Residential Proxies: A New Breed of Threat

Now we need to talk about residential proxies, the new go-to tool of fraudsters and scammers. These are not just a new label for old proxies. They behave differently.

What Are Residential Proxies?

Residential proxies come from IP addresses assigned to real residential services by Internet Service Providers (ISPs). These can be:

Home computers
Mobile phones
Tablets
IoT devices

Unlike data center proxies, which use IP addresses from hosting companies, residential proxies use IPs that look just like any other home or mobile user. They have become the tool for avoiding security controls on websites in the last 2-3 years, and they are causing all sorts of headaches for website owners.

How Are Residential Proxy Networks Formed?

This is where the problem starts:

Compromised Devices: Malware can turn innocent devices into proxy endpoints without the owner's knowledge.
Incentivised Programs: Some companies offer users benefits (like free VPN services) in exchange for using their device as a proxy endpoint. Hola VPN and Brightdata are prominent examples.
APP SDKs Quite often, proxy providers will incentivise app developers to include their proxy toolkit in their apps. The user is totally unaware that their device's internet connection is now being resold.

So your personal device, be it a computer or phone, could have its internet connection used to carry out a crime without you knowing. The police could come knocking on YOUR door one day.

Why Are They So Dynamic?

Since the proxy is formed by reusing the internet connection of a device, it is inherently much more dynamic than a proxy formed on a server.

Device Mobility: A mobile phone can connect from home Wi-Fi, then a coffee shop, then a cellular network – all in one day.
ISP IP Rotation: Many ISPs dynamically assign IP addresses, changing them periodically.

Depending on the type of fraud being carried out, the attacker might also rotate the device being used, popping out of a different location. Also, due to the way these proxies are formed, i.e. via an app on a computer or phone, that particular exit point on the proxy network might depend on that app being open.

This dynamic nature is what makes residential proxies so hard to detect using traditional methods.

Shared IPs: The Needle in the Haystack Problem

Residential proxy IPs are not just dynamic. They are typically shared. This means that a single IP address could be used by both legitimate users and proxy traffic:

ISP IP Pools: Internet Service Providers often use large pools of IPs that are dynamically assigned to users. This means that an IP used by a proxy one minute could be assigned to your grandmother's iPad the next.
Carrier-Grade NAT (CGN): Mobile carriers frequently use CGN, which can make hundreds or thousands of users appear to come from the same IP address.
Compromised Routers: A single compromised home router could serve both the legitimate traffic of the homeowner and proxy traffic from the attacker.

If you simply blocked any IP that shows proxy behavior, you would end up blocking legitimate users too.

Why Traditional Methods Are Failing (Revisited)

Now that we understand residential proxies better, let's revisit why old-school detection methods are not enough.

1. Port Scanning

Traditional proxy detection often relies on scanning for open proxy ports. Here's a simple port scanner:

import socket

def port_scan(ip, port):
    sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    result = sock.connect_ex((ip, port))
    sock.close()
    return result == 0

# Example usage
ip = "123.45.67.89"
proxy_ports = [80, 8080, 3128]  # Common proxy ports

for port in proxy_ports:
    if port_scan(ip, port):
        print(f"Port {port} is open - potential proxy detected")

Why it fails: Residential proxies don't typically have these ports open. They route traffic through standard web ports, making them indistinguishable from normal traffic.

2. Honeypots

Honeypots try to lure and identify proxy traffic.

Why it fails: Sophisticated residential proxy networks can identify and avoid known honeypots. Plus, since they're using real residential IPs, even if they do hit a honeypot, the IP itself isn't a reliable indicator of proxy usage.

3. Client-Side Detection

Detection services may also try to detect proxies by executing Javascript in the browser and checking the result for inconsistencies. These are the common techniques.

3.1 WebRTC Leak

WebRTC can sometimes reveal a user's true IP address:

function detectRealIP(callback) {
    var RTCPeerConnection = window.RTCPeerConnection || window.mozRTCPeerConnection || window.webkitRTCPeerConnection;
    var pc = new RTCPeerConnection({iceServers:[]}), noop = function(){};
    pc.createDataChannel("");
    pc.createOffer(pc.setLocalDescription.bind(pc), noop);
    pc.onicecandidate = function(ice) {
        if(!ice || !ice.candidate || !ice.candidate.candidate) return;
        var myIP = /([0-9]{1,3}(\.[0-9]{1,3}){3}|[a-f0-9]{1,4}(:[a-f0-9]{1,4}){7})/.exec(ice.candidate.candidate)[1];
        pc.onicecandidate = noop;
        callback(myIP);
    };
}

detectRealIP(function(ip) {
    console.log("Your real IP address is: " + ip);
});

3.2 Geolocation Inconsistencies

Comparing IP-based geolocation with browser-reported location.

navigator.geolocation.getCurrentPosition((position) => {
  const browserLat = position.coords.latitude;
  const browserLong = position.coords.longitude;
  // Compare with IP-based geolocation from server
});

3.3 DNS Leaks

Check whether DNS requests are routed through the proxy or are leaking:

const image = new Image();
const uniqueDomain = `test-${Date.now()}.example.com`;
image.src = `http://${uniqueDomain}/pixel.gif`;
// Monitor DNS requests server-side to detect leaks

3.4 Browser Fingerprinting

Check whether there are inconsistencies with the browser, e.g. timezone, and the geolocation of the IP address

const fingerprint = {
userAgent: navigator.userAgent,
screenResolution: `${screen.width}x${screen.height}`,
colorDepth: screen.colorDepth,
timezone: Intl.DateTimeFormat().resolvedOptions().timeZone,
plugins: Array.from(navigator.plugins).map(p => p.name),
// ... other characteristics
};
// Analyze fingerprint for proxy indicators

Why these techniques fail

Proxy services can work around all of these methods. Many browsers now allow users to disable WebRTC or use extensions that prevent this leak. Some residential proxy services are sophisticated enough to handle WebRTC requests without leaking the real IP.

Finally, relying on client-side detection means: * Your detection can be reverse engineered and bypassed. * You've already served the content the attacker wants. * It requires Javascript execution, something that won't always be available, for instance on an API.

4. Threat Intelligence

Threat intelligence involves maintaining databases of known proxy IP addresses:

import requests

def check_ip_threat_intel(ip):
    api_key = "your_api_key_here"
    url = f"https://api.threatintelligence.com/v1/ip/{ip}?key={api_key}"
    response = requests.get(url)
    if response.status_code == 200:
        data = response.json()
        return data.get('is_proxy', False)
    return False

# Example usage
ip = "123.45.67.89"
if check_ip_threat_intel(ip):
    print(f"{ip} is a known proxy according to threat intelligence")

Why it fails: As our results show, threat intelligence databases are struggling to keep up with the dynamic nature of residential proxies. By the time an IP is identified and added to a database, it may no longer be in use as a proxy.

Why IP-Based Blocking Is No Longer Enough

Given the shared nature of IPs in the age of residential proxies, simply identifying and blocking "bad" IPs is too blunt. Here's why:

False Positives: Blocking an IP used by a proxy might also block legitimate users sharing that IP.
Ineffectiveness: Proxies can quickly switch to new IPs, so IP-based blocking turns into a chase.
Collateral Damage: You might end up blocking entire ISPs or mobile carriers, cutting off large swaths of legitimate users.

The practical failure is customer friction. A checkout, login, or account recovery flow cannot treat every residential or mobile network as hostile. Teams need enough request context to choose a proportionate response: log the signal on a low-risk page, challenge a suspicious account change, rate limit repeated failures, or block only when proxy evidence lines up with stronger abuse indicators.

The same problem shows up on APIs and partner integrations. A partner batch job, mobile carrier, or shared office network can look noisy without being hostile. A compromised key can look legitimate until it starts hitting expensive routes. Good review paths keep the route, account or API key, request rate, fingerprint, and recent outcomes together so the answer is not just "block the IP" or "allow everything."

This is where proxy detection stops being a lookup problem and becomes an operating problem. The team needs to know which route was hit, what account or session was involved, whether the request matched normal behaviour, and what the enforcement cost would be if the signal was wrong. That is the difference between reducing abuse and quietly pushing good customers into support. For a deeper treatment of that tradeoff, see the guide to customer friction and false-positive measurement.

The Need for Connection-Level Detection

Instead of focusing only on IPs, we need to look at the connections themselves. Here's what this means:

Deep packet inspection: Analyses traffic patterns and characteristics beyond surface-level indicators.
Protocol behaviour analysis: Identifies subtle anomalies in how network protocols are implemented across the proxy chain.
TLS/TCP fingerprinting: Examines characteristics of TLS handshakes to detect proxy usage.
Timing analysis: Measures minute differences in network latency that can indicate the presence of a proxy.

Final Thoughts

Proxy usage has evolved, and detection methods need to keep up. Simple IP-based blocking and static lists of "bad" addresses are no longer enough. They still have a place, but they cannot be the whole answer.

Modern residential proxy detection has to evaluate the live request: IP context, connection behaviour, fingerprints, route, account state, request rate, and recent outcomes. On a low-risk page that may only justify logging. On login, signup, checkout, password reset, API key creation, or account recovery, the same signal may justify a challenge, hold, rate limit, or block.

Peakhour's residential proxy detection is built for that request-path decision. The point is not to label every residential IP as bad. The point is to give operators enough evidence to act when proxy use lines up with account abuse, fraud, scraping, or automated traffic.

If you're still treating IP reputation as the main answer, you're already behind. It's time to stop blocking IPs and start understanding the request.

Want a demo of our residential proxy detection? Contact us for a live demo of our service.

The Australian epidemic of Account Takeover attacks

2024-07-29T10:00:00+10:00

In recent months, credential stuffing attacks have hit a number of Australian businesses, leading to compromised accounts, fraudulent purchases, and customer complaints. The pattern is a reminder that account protection cannot stop at password policy or MFA alone.

A Case Study in Credential Stuffing

Security researcher Jacob Larsen has documented a credential stuffing operation targeting Australian businesses. Larsen's research, detailed in his blog post, describes the activity of a threat actor known as "Crabby," who has sold compromised Australian accounts since July 2023.

Larsen's findings show:

The operation began with a threat actor called "Based" selling compromised accounts via Discord and dedicated websites.
In November 2023, the operation was acquired by "Juicy," a notorious account vendor, and rebranded as "Crabby."
As of May 2024, over 19,000 compromised accounts from various Australian brands were offered for sale.
Low-level fraudsters purchasing these accounts have used them to make unauthorised purchases, often targeting high-value items for resale.

The Crabby operation shows how credential stuffing has moved beyond isolated login attempts. It now includes account marketplaces, low-level fraud buyers, and the challenges businesses face once compromised accounts are monetised.

The Difficulty of Defense

Credential stuffing defence is harder when attacks are spread across residential proxies and kept to single attempts per account.

Residential Proxies: The Invisible Threat

Residential proxies weaken traditional IP-based controls. These proxies use IP addresses assigned to real residential internet connections, so malicious traffic can look like normal customer traffic. That helps attackers bypass simple rate limiting and geolocation checks.

That distribution makes login traffic harder to classify. Signals such as a high volume of attempts from one IP address become less useful when attackers can spread requests across a pool of residential IPs.

Single-Hit Attacks: Precision Strikes

Single-hit attacks are another way attackers avoid noisy patterns. In this approach, each stolen credential is used only once per target site, reducing the chance of detection by traditional rate-limiting or anomaly detection systems.

By limiting each credential to one attempt, attackers avoid controls tuned to repeated login failures. A business can have rate limiting in place and still miss credential stuffing that never crosses those thresholds.

The Mobile API Conundrum

As mobile applications become a primary user interface, credential stuffing also moves into mobile API traffic. Traditional bot protection often relies on JavaScript challenges or browser fingerprinting, which does not apply cleanly to attacks against mobile APIs.

Mobile applications typically communicate with backend services via APIs, bypassing the browser environment where many bot detection techniques run. This creates several challenges:

Lack of JavaScript Execution: Mobile APIs don't execute JavaScript, making it impossible to use browser-based bot detection techniques.
Limited Fingerprinting Capabilities: Standardised mobile API requests make it difficult to distinguish between legitimate user activity and automated attacks based on request characteristics.
Increased Attack Surface: More mobile apps means more potential entry points for attackers, making comprehensive protection more complex.
Authentication Simplification: To improve user experience, mobile apps often use simplified authentication flows, which can create weaker controls against automation.

This gap needs API-centred controls that can assess mobile login behaviour without relying on browser-only signals.

Framing Credential Stuffing as a Business Risk

Credential stuffing should be treated as a business risk, not just an authentication issue. The impact can include refunds, chargebacks, customer support load, reputational damage, and regulatory disclosure work.

Risk Quantification and Disclosure

Risk quantification gives security teams a way to explain credential stuffing in business terms. By applying frameworks like FAIR (Factor Analysis of Information Risk), businesses can:

Quantify the potential financial impact of credential stuffing attacks.
Prioritise security investments based on risk reduction potential.
Communicate the importance of cybersecurity measures to non-technical stakeholders.

CPS 234 in Australia adds a disclosure dimension for regulated entities. Businesses need to protect against credential stuffing and be able to explain their exposure, controls, and mitigation strategy.

The State of Credential Stuffing Defense in Australia

Our recent survey of Australian businesses shows uneven adoption of credential stuffing defences:

While 77% of respondents use Multi-Factor Authentication (MFA), only 40% have implemented bot protection measures.
15% of companies chose not to respond to questions about their security measures, suggesting potential gaps in protection.
Just 29% of businesses check credentials against known breaches, leaving a large window of opportunity for attackers using stolen credentials.
Only 15% of organisations use residential proxy detection, a critical component in identifying and mitigating modern credential stuffing attacks.

These results suggest a gap between how credential stuffing is run now and the controls many Australian businesses have in place.

Recommendations for Enhanced Protection

Based on our analysis and survey results, businesses should review the following controls:

Implement Advanced Bot Protection: Deploy controls that detect and mitigate bot attacks, including attacks using residential proxies.
Enhance Mobile API Security: Use mobile API controls that focus on anomaly detection and behavioural analysis rather than browser-based techniques.
Adopt Risk-Based Authentication: Implement dynamic authentication mechanisms that adjust based on the assessed risk of each session or transaction.
Utilise Breached Credential Databases: Check user credentials against known breach databases and enforce password changes for compromised accounts.
Implement Residential Proxy Detection: Use technology that identifies and mitigates traffic from residential proxy networks. This is a key control for modern credential stuffing attacks.
Apply Advanced Rate Limiting: Utilise device fingerprinting and other identifiers beyond IP addresses to implement more effective rate limiting, particularly for single-hit attacks.
Employ Contextual Security: Use signals such as user behaviour patterns, device characteristics, and historical usage to identify anomalies that may indicate credential stuffing attempts.
Quantify and Communicate Risk: Use frameworks like FAIR to quantify the potential impact of credential stuffing attacks and communicate this risk to stakeholders.
Implement Continuous Monitoring: Deploy real-time monitoring that detects patterns indicative of credential stuffing attacks, and update defences as attack methods change.

These controls address the specific problems created by residential proxies, single-hit attempts, mobile API traffic, and weak credential hygiene. They also reflect the limits of IP-only rate limiting and browser-only bot detection.

Credential stuffing defence works best as a layered programme: bot detection, residential proxy detection, breached credential checks, mobile API coverage, and risk reporting. The practical goal is to stop account takeover attempts earlier, reduce fraud exposure, and give security teams evidence they can act on.

The Challenge of Proxy Detection

2024-07-19T10:00:00+10:00

Our recent survey found that only 15% of Australian organisations use residential proxy detection. That leaves many teams relying on controls that were not built for current proxy traffic, especially where CGNAT and NAT make IP-level decisions unreliable.

The Shortcomings of Traditional Methods

Legacy bot protection providers often combine IP reputation, network characteristics, header analysis, and JavaScript-based checks to identify proxy usage. These methods struggle against well-run residential proxies:

IP and ASN categorisation: Ages quickly as new proxy networks emerge.
Network-level checks: Well-configured proxies can work around them.
Header analysis: Proxies can alter HTTP headers to mimic legitimate traffic.
JavaScript-based detection: Struggles against headless browsers and leaves API endpoints vulnerable.

The CGNAT and NAT Challenge

A practical limit of traditional methods is their inability to distinguish legitimate traffic from proxy traffic when both originate from the same IP address. Carrier-Grade NAT (CGNAT) and Network Address Translation (NAT) make this common:

CGNAT: Used by ISPs to conserve IPv4 addresses, resulting in multiple users sharing a single public IP.
NAT: Commonly used in home and business networks, allowing multiple devices to use one public IP address.

As a result, legitimate users and residential proxy traffic can appear to come from the same IP address. IP reputation and geolocation alone cannot separate these traffic types.

This creates a difficult tradeoff:

Blocking suspicious IPs risks denying service to legitimate users.
Allowing all traffic from these IPs opens the door to potential abuse via residential proxies.

Traditional methods cannot reliably pull apart these different types of traffic, so teams either block too much legitimate traffic or allow too much proxy traffic through.

The Need for Sophisticated Network Fingerprinting

To detect and mitigate residential proxy threats while allowing legitimate traffic from shared IPs, detection needs to move beyond IP identity. Network fingerprinting addresses the limits of traditional methods:

Deep packet inspection: Analyses traffic patterns and characteristics beyond basic IP or header indicators.
Protocol behaviour analysis: Identifies subtle anomalies in how network protocols are implemented across the proxy chain.
TLS fingerprinting: Examines unique characteristics of TLS handshakes to detect proxy usage.
Timing analysis: Measures small differences in network latency that can indicate the presence of a proxy.

Used together, these techniques can detect proxy usage on a per-connection basis for both web traffic and API calls, even when traffic originates from shared IP addresses. This approach provides several advantages:

Improved accuracy: Significantly reduces false positives and negatives compared to traditional methods, including in CGNAT and NAT scenarios.
API protection: Secures API endpoints, which are often overlooked by JavaScript-based solutions.
Real-time detection: Allows for immediate action against detected proxy usage without impacting legitimate users.
Adaptability: Can be updated to detect new proxy technologies as they emerge, regardless of IP sharing.

Implementing Effective Proxy Detection

To implement proxy detection that accounts for modern network complexity, organisations should consider the following:

Deploy solutions that use network fingerprinting techniques capable of distinguishing between different types of traffic from the same IP.
Ensure protection covers both web applications and API endpoints, as both are vulnerable to proxy-based attacks.
Implement real-time mitigation capabilities to respond swiftly to detected threats without impacting legitimate users.
Regularly update and tune detection algorithms to keep pace with evolving proxy technologies and network architectures.

Together, these practices improve an organisation's ability to detect and mitigate residential proxy threats across credential stuffing, account takeover, and related activity, while keeping access available for legitimate users.

Learn more about our proxy detection solution, which uses network fingerprinting to address the challenges posed by CGNAT and NAT.

For more detail, explore our learning resources:

As proxy technologies and network architectures change, detection and mitigation need to change with them. Network fingerprinting gives organisations a more reliable way to identify residential proxy abuse without treating every shared IP as suspicious.

Quantifying The Residential Proxy Threat

2024-07-18T10:00:00+10:00

Our 2024 survey found that only 15% of Australian businesses use residential proxy detection. That leaves a measurable blind spot in many security programmes: traffic routed through real consumer connections is harder to separate from legitimate users. This article looks at why residential proxy detection is difficult and how to quantify the risk before choosing controls.

Understanding the Residential Proxy Threat Landscape

Residential proxies use IP addresses assigned to residential internet connections, so malicious traffic can look legitimate. This weakens controls built around IP reputation, GeoIP, and simple request thresholds, and creates a specific detection problem for security teams.

The effectiveness of residential proxies stems from their ability to:

Use legitimate IP addresses, often from unsuspecting users
Bypass IP-based rate limiting and traditional bot detection methods
Evade geolocation restrictions, making GeoIP filtering less reliable
Support large-scale attacks without triggering typical alarm thresholds
Mimic legitimate user behaviour, which makes detection more difficult

These capabilities make residential proxies useful infrastructure for credential stuffing, data scraping, and attempts to bypass fraud detection systems. Because the traffic is distributed across many residential connections, attacks can stay below the thresholds that conventional controls rely on.

Limitations of Conventional Security Approaches

Conventional controls have clear gaps when they are applied to residential proxy traffic:

IP-based detection misses constantly changing, legitimate-appearing IP addresses.
GeoIP filtering becomes less useful against globally distributed residential IPs.
User agent analysis struggles because proxies can mimic legitimate browsers.
Standard rate limiting falters when attacks appear to originate from many unique IPs.
Behavioural analysis based on known bot patterns may miss more careful proxy-based attacks.

These limitations point to a practical requirement: security teams need controls that assess context, not just static request attributes. Residential proxies make simple rule-based decisions less reliable, especially when attacks are distributed and deliberately low-noise.

Quantifying the Risk

To make a sensible decision about residential proxy controls, organisations need to quantify the risk. This involves:

Assessing the potential financial impact of successful attacks via residential proxies
Evaluating the likelihood of such attacks based on industry trends and organisational attractiveness to attackers
Determining the effectiveness of current security measures against this specific threat
Calculating the return on investment for implementing advanced detection and mitigation strategies

Risk quantification gives businesses a clearer basis for investing in residential proxy detection. It aligns security spending with actual threat levels and potential impacts, rather than broad concern or industry pressure alone.

Reframing Security

The challenge of residential proxy detection is less about one new control and more about how signals are combined. A useful approach includes:

Contextual Analysis: Analyse the full context of each request, not just its origin. This includes examining patterns of behaviour across multiple sessions and users.
Continuous Monitoring and Adaptation: Use real-time monitoring systems that can detect subtle patterns indicative of proxy use. These systems should continuously adapt to new attack vectors.
Risk-Based Authentication: Use dynamic authentication mechanisms that adjust based on the assessed risk of each session or transaction.
Holistic Data Analysis: Correlate data from multiple sources - including login attempts, transaction patterns, and user behaviour - to identify anomalies that may indicate proxy use.
Proactive Threat Hunting: Actively search for indicators of residential proxy use within your network and user base, rather than waiting for attacks to trigger alerts.

This approach moves beyond simple allow/block decisions and gives teams a better view of user and network behaviour.

Implementing Advanced Detection Strategies

Residential proxy threats need detection that looks beyond the source IP:

Machine Learning-Based Behavioural Analysis: Use AI and machine learning to identify patterns consistent with proxy use, even when individual actions appear legitimate.
Device Fingerprinting Beyond IP: Use advanced fingerprinting techniques that identify individual devices based on a combination of factors, making it harder for proxies to mimic legitimate users.
Network Traffic Analysis: Analyse network behaviour at a granular level to identify patterns consistent with proxy network traffic.
Adaptive Challenge Mechanisms: Deploy targeted challenges based on risk assessment, without disrupting legitimate user experiences.
Cross-Organisational Data Sharing: Participate in threat intelligence sharing networks to gain broader insights into residential proxy activities and emerging attack patterns.

When used as part of the broader security stack, these strategies improve defence against residential proxy threats.

Elevating Security Through Risk Quantification

Residential proxies are not only a technical detection problem. They change the risk model for web applications because attacker traffic can borrow the appearance of ordinary residential users. By adopting a risk quantification approach and implementing advanced detection strategies, organisations can:

Align security investments with actual threat levels
Improve detection of sophisticated, proxy-based attacks
Strengthen overall security posture against evolving threats
Make data-driven decisions about security priorities and resource allocation

Organisations that handle this well will be able to quantify their risk, adapt their security strategies, and implement intelligent detection mechanisms. The goal is practical: identify, analyse, and mitigate sophisticated threats before they cause material damage.

Effective protection starts with understanding the risk well enough to measure it.

Application Security Beyond MFA

2024-07-15T10:00:00+10:00

Multi-factor authentication (MFA) remains a useful defence against account takeovers, but it is not a complete control. Attackers increasingly work around MFA with social engineering, automation, and infrastructure that makes malicious traffic look ordinary.

MFA answers one narrow question: can the user present a second factor at this point in the flow? That is valuable. It does not prove the password was safe, the session will remain safe, the device is trusted, or the person entering the code has not been manipulated. Account protection needs to cover the request path before MFA, around MFA, and after MFA.

OTP Bots Target the Human, Not the Cryptography

A Kaspersky article describes the rise of OTP bots: tools that call or message users and convince them to hand over one-time passwords. The attacker does not need to break the MFA system. They need the victim to read out a fresh code at the same moment the attacker is logging in.

The usual flow is simple. The attacker obtains a working username and password from a breach, phishing kit, or credential stuffing result. They attempt a login, which triggers an OTP. The victim receives a call or message claiming to be from the bank, retailer, courier, or support team. The story is urgent enough to make the code feel like part of protecting the account, not compromising it.

AI phone assistants such as Lucy are built for legitimate business use, but similar conversational technology lowers the effort required to run more convincing criminal call flows. The security issue is not that AI magically defeats MFA. It is that a fluent, responsive call can make social engineering less scripted and harder for a user to dismiss.

This is why "we have MFA" should not end the account protection conversation. MFA can stop many stolen-password logins, but it cannot reliably stop a user from being tricked in real time.

Residential Proxies Weaken the Surrounding Checks

Attackers also work to make the login itself look unremarkable. Residential proxies route traffic through IP addresses assigned to ordinary home or mobile internet connections. That lets malicious traffic borrow the appearance of normal customer traffic.

Traditional controls often lean too heavily on IP address, geolocation, and request volume. Residential proxy networks weaken all three. An attacker can rotate through many IPs, keep each source below a simple rate limit, and choose an exit location that roughly matches the victim's country or city. If the login looks local enough, the MFA challenge may be the only control left.

That is a poor place to put all the risk. A login with a correct password, a plausible IP address, and a successful OTP can still be an account takeover. The system needs to keep evaluating the request: device and browser signals, network fingerprint, known breached credentials, velocity across accounts, and behaviour after login.

Automation Happens Before and After MFA

MFA is usually visible at the point of login, but account takeover campaigns are broader than one prompt. Bots test credential pairs across login forms and APIs. Tools such as OpenBullet and similar automation frameworks can replay login flows at scale. Breached credential lists give attackers a cheap starting point because password reuse remains common.

Once an attacker gets through, the next actions matter. They may change the email address, add a device, disable notifications, alter delivery details, use stored payment methods, transfer value, or test what the account can access. If monitoring treats a successful MFA as the end of risk, those actions can happen inside a trusted session.

The defence needs to be layered around the actual attack path:

Check credential risk before and during login, especially known breached username and password pairs.
Use bot and browser signals to detect automation even when traffic is distributed.
Rate limit on better keys than IP alone, such as TLS or HTTP/2 fingerprints, headers, routes, ASNs, countries, and account behaviour.
Treat residential proxy evidence as a risk input, not just an allow-or-block label.
Monitor session and account changes after MFA, then challenge, hold, revoke, or review when behaviour changes.

This does not mean every login needs more friction. It means the system should have more choices than "ask for MFA" or "allow". A low-risk login from a known device can keep moving. A login using breached credentials through proxy infrastructure can be slowed, challenged, or blocked before the user receives a confusing call. A successful login followed by high-risk account changes can trigger fresh verification or session invalidation.

Controls Around MFA

Peakhour's Advanced Rate Limiting helps reduce reliance on IP address by grouping and limiting requests using signals such as HTTP/2 and TLS fingerprints, ASNs, countries, request headers, and route context. That matters when credential stuffing is spread across residential proxies.

Peakhour's Bot Management adds another layer by looking for automation, browser inconsistency, suspicious device patterns, and residential proxy use. The aim is to identify the machinery behind the attack before it becomes a clean-looking login attempt.

Peakhour's Account Protection brings those signals closer to the account decision. Breached credential checks, bot evidence, rate limits, proxy context, custom rules, and monitoring should all feed the decision to allow, challenge, rate limit, block, log, or review.

User education still has a place, especially around OTP sharing and unexpected calls. It should not be the main control. Users are asked to make security decisions at bad moments, often under pressure, with limited context. Technical controls should reduce the number of times an attacker can create that moment.

MFA Still Belongs in the Stack

The point is not to remove MFA. Strong MFA, especially phishing-resistant methods, raises the cost of account takeover and should remain part of the stack. The mistake is treating MFA as proof that the account is safe.

Account protection works better when MFA is one decision point inside a wider system. The login attempt, credential history, network path, device, session, account changes, and transaction behaviour all carry evidence. MFA is useful evidence. It is not the whole case.

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.

Managing Breached Credential Usage

2024-03-15T00:00:00+11:00

Credential stuffing attacks remain a common way to take over accounts on applications and APIs. For DevOps, SRE, and DevSecOps teams, the problem is not just whether a password is correct. It is whether the login attempt carries signs of automation, credential reuse, or known compromise. Effective account protection needs breached credential checks alongside contextual risk analysis.

Breached Credential Databases and Risk Profiling

Modern Application Security Platforms can use breached credential intelligence containing billions of leaked username and password combinations from historical data breaches. Used at login time, this gives security teams an immediate signal that an account may be at higher risk, even before there is confirmed account takeover activity.

Enterprise Credential Intelligence

Peakhour's Application Security Platform includes Breached Credentials protection designed to work with existing authentication systems. The platform provides:

Real-Time Credential Checking: Validation against breached credential data during login attempts
API-Native Integration: Integration with authentication services and identity providers
Privacy-Preserving Verification: Hashing mechanisms that protect user privacy whilst enabling threat detection
DevSecOps Compatibility: RESTful APIs for security automation and CI/CD workflows

Building Statistical Models

To detect credential stuffing, organisations need a baseline for normal breached credential use. This typically involves:

Collecting data from API and login endpoint attempts
Aggregating data using device fingerprints
Analysing login patterns and credential use frequency
Establishing baselines for typical user behaviour

These models show how often breached credentials appear in normal login traffic, and when the pattern starts to look like automated testing rather than ordinary user behaviour.

Application Security Platform Integration

Breached credential checks are most useful when they feed into the rest of the application security stack:

Multi-Layer Defence Strategy

Edge Processing: Credential validation at the CDN edge
API Protection: Coverage for both web applications and mobile APIs
Bot Management Integration: Correlation with bot detection systems to identify automated credential testing
Rate Limiting Coordination: Rate limits adjusted by credential risk

DevSecOps Operational Excellence

Security Automation: Response workflows for high-risk credential attempts
Compliance Reporting: Audit logging and monitoring for security reviews
Threat Intelligence Feeds: Updates from breach monitoring
Custom Rule Engine: Policy configuration for organisation-specific requirements

Conclusion

Breached credential protection is one part of account takeover defence. On its own, it can show that a password has appeared in a breach. It should sit alongside broader controls such as bot management, rate limiting, API protection, and DDoS mitigation, while still giving teams a clear basis for deciding whether to block, challenge, or monitor a login attempt.

The practical goal is to make credential risk visible at the point of authentication without treating every user as suspicious. That requires breached credential checking to be part of the login flow, not a separate report reviewed after the attack has already run.

Rate Limiting for API Security

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

Rate limiting prevents servers from being overwhelmed by too many requests in a short period of time. Typically, rate limiting is configured using rules made up of a filter, for example a path like /login, and a limit on the number of requests a user can make in a given time, such as 10 requests in a minute. If a user exceeds this limit, they are usually blocked for a timeout period.

But how do you identify a user? Traditionally rate limiting has used the IP address for grouping requests, assuming that requests from the same IP address will be the same user. That assumption is now weak. IP addresses are rarely static and are often shared. For example, an office network might have hundreds of individual computers in it but present a single IP address for all those computers to the internet. Mobile operators commonly use carrier-grade network address translation (CGNAT) to share the same IP across thousands of devices or users. Bot networks, seeking to avoid security controls like rate limiting, will rotate their requests through thousands of different IP addresses. This makes rate limiting based on IP addresses a poor choice from both a functional and a security perspective.

Introducing Advanced Rate Limiting

Peakhour's Advanced Rate Limiting service lets you create filters using any HTTP request characteristic, for example URI, request method, headers, cookies, country, network fingerprints and more. You can also use response headers and response codes, so a rule can count failed login attempts, repeated 404s from a scraper, or traffic that crosses an API threshold.

For counting requests you can use the following fields for grouping:

IP Address
ASN
Country Code
HTTP/2 Fingerprint
TLS Fingerprint
Any combination of Request Headers

You can use one of those fields, or a combination of them, to identify users with more control than IP address alone.

You can also separate the filter and mitigation expression. For example excessive attempts to /login can be blocked on the entire site.

This matters because rate limiting is not just a request counter. In Peakhour it sits beside bot management, WAF, DDoS protection, traffic controls, and origin shielding on the same managed edge path. That gives operators a practical way to set different thresholds for verified crawlers, suspicious automation, authenticated API clients, and normal visitors without pushing every policy change into the application. It also gives them allowed, blocked, and threshold-hit evidence to tune the rule after it is deployed, whether Peakhour is the active edge or adding controls beside an existing CDN or cloud edge.

Putting it into action

Advanced Rate Limiting can help protect applications from attacks like Layer 7 DDoS, Account Takeovers, Credential Stuffing, and more. Here are some real world examples you can configure using our dashboard and API.

Protect against general site abuse

Our example website is a medium-sized ecommerce store that has page URLs ending in /. It serves Australian clients and typically sees around 100 page requests a minute from non-search-engine traffic during peak traffic times. With that baseline, we can set up rate limiting to prevent general site abuse and protect against layer 7 DDoS attacks.

Peakhour rate limiting starts with zones. You specify your request limits in these zones.

Here we've specified a maximum of 45 requests in 1 minute. We're going to apply this limit to page loads only. Since our typical maximum for all users on this website is 100 in a minute, it seems reasonable that a real user is not going to view 40 pages in 1 minute. We could also specify a value for error responses in a minute. An error could be a 404, which a scraper might typically get when looking for removed URLs.

Now let's define our filter and our counter. For our filter we mentioned that pages end in /, so we'll use that, but exclude verified bots to make sure they're not restricted when crawling the site. A verified bot is a crawler like Google or Bing, that Peakhour has verified as legitimate by using reverse DNS to confirm they are who they say they are.

Attackers, scrapers, and others looking to abuse a site will launch an attack using a particular piece of software. That piece of software will have a TLS fingerprint (like JA3) that remains the same, even as the attacker rotates their user-agent, IP address, and other characteristics, so we'll use the TLS fingerprint as our request counter.

Rate Limit authenticated API Users

It is common for APIs to require an Authorization header as part of the request to authenticate access. By grouping requests on the value of this header, we can rate limit a specific API client even if it uses multiple applications, or if its credentials are stolen.

Protecting from Account Takeovers

Account Takeover attacks have been in the news recently, with several high-profile websites being victims. Credential Stuffing and Brute Force attacks rely on attempting lots of logins to identify valid credentials. Along with lots of attempts come lots of failures. Attackers will rely on software like openbullet to carry out their attacks, using proxy networks to constantly rotate IP addresses and defeat traditional rate limiting.

The program the attacker is using will present a consistent TLS fingerprint. We can make a special rule for our login form that tracks failed login attempts by TLS Fingerprint, effectively tracking the attacker as they rotate IP address.

If the attack is low and slow, we can track failed attempts over a longer timeframe by using the response from the server when adding to our counting zone.

Final Thoughts

Advanced rate limiting is a practical response to the limits of IP-based controls. IP address rotation is the standard amongst attackers and scrapers, rendering the traditional approach obsolete. Useful protection now needs to identify the actor behind the requests, protect the origin before expensive application work is triggered, and give teams enough evidence to adjust the policy without guesswork. Counting requests against a combination of network fingerprints, request fields, response signals, and bot context is how you stop abuse from scrapers, SEO spiders, and layer 7 attackers without treating every visitor the same.

Dive into CVSS Scores

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

Understanding CVSS through Atlassian Confluence Vulnerabilities

The Common Vulnerability Scoring System (CVSS) gives security teams a shared way to rate the severity of software vulnerabilities. It does not predict risk on its own; it describes the characteristics of a specific security flaw. CVSS uses three metric groups: Base, Temporal, and Environmental. The result is a score from 0 to 10, represented by a vector string that records the details behind the score.

Base Metrics describe the inherent aspects of a vulnerability, including how it can be exploited and its potential system impact.
Temporal Metrics change over time, reflecting current exploitability and available mitigations.
Environmental Metrics account for the specific environment where the vulnerability exists, tailoring the score to the affected organisation.

The National Vulnerability Database (NVD) utilises CVSS to assign base scores and provides tools for calculating Temporal and Environmental scores.

Atlassian Confluence Vulnerability Analysis

Two Atlassian Confluence vulnerabilities show why the vector matters as much as the headline score:

CVE-2023-22515 is a critical flaw with a base score of 10.0. It is exploitable remotely, with low complexity, no privilege requirements, and no need for user interaction. The attack vector is network-based, so exposure is not limited to local access. Its broad scope and impact across confidentiality, integrity, and availability make it a vulnerability that needs immediate attention.

CVE-2023-22518 shares many similarities with CVE-2023-22515, including a critical base score of 10.0. It can also be exploited remotely without privileges or user interaction, and with low complexity. Its impact on the system's confidentiality, integrity, and availability is high, allowing attackers to gain complete control and shut down the affected resources.

Both CVE-2023-22515 and CVE-2023-22518 are critical vulnerabilities that demand urgent remediation. Understanding their CVSS vectors helps prioritise the security response and the mitigations needed.

CVE-2023-22515 carries a CVSS score of 10 because it is remotely exploitable, easy to execute, and does not require privileges or user interaction.

CVSS Vector for CVE-2023-22515

Base Score: 10.0 (Critical)
Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

This vector indicates:

Attack Vector (AV): Network (N) - The vulnerability is remotely exploitable.
Attack Complexity (AC): Low (L) - It is easy to exploit without major obstacles.
Privileges Required (PR): None (N) - No special access is needed.
User Interaction (UI): None (N) - It can be exploited without user involvement.
Scope (S): Changed (C) - The impact extends beyond the initial target.
Confidentiality, Integrity, Availability (C/I/A): High (H) - There is a complete loss of confidentiality, integrity, and availability.

Atlassian's high CVSS score for CVE-2023-22515 reflects its critical nature and the need for immediate action.

CVE-2023-22518 has the same CVSS score of 10, with similar impact across confidentiality, integrity, and availability.

CVSS Vector for CVE-2023-22518

Base Score: 10.0 (Critical)
Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

This vector means:

Attack Vector (AV): Network (N) - Exploitable remotely.
Attack Complexity (AC): Low (L) - Easy to exploit with minimal barriers.
Privileges Required (PR): None (N) - No user privileges required.
User Interaction (UI): None (N) - No need for user action.
Scope (S): Changed (C) - Broad impact beyond the initial system.
Confidentiality, Integrity, Availability (C/I/A): High (H) - Complete compromise of the system's security.

Understanding the CVSS scores for these vulnerabilities helps teams prioritise their security response. For a full breakdown and history of CVSS, see Wikipedia. More detailed information on CVSS can also be found in FIRST's official CVSS documentation.

A Risk Based Approach To Vulnerability Scoring

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

The Exploit Prediction Scoring System (EPSS) estimates the likelihood that a published CVE will be exploited in the wild. Its value is that it brings several signals into one risk score, instead of treating every vulnerability with the same CVSS severity as equally urgent. The main inputs are:

Data Sources of EPSS

MITRE’s CVE List: EPSS scores only vulnerabilities that are "published" on this list.
Text-based “Tags”: Extracted from CVE descriptions and related discussions.
Publication Duration: The time period since the CVE was published.
Reference Count: The number of references in the CVE entry.
Published Exploit Code: Code from platforms such as Metasploit, ExploitDB, or GitHub.
Security Scanners: Data from security tools such as Jaeles and Nuclei.
CVSS v3 Vectors: Based on the base score in the National Vulnerability Database (NVD).
CPE (vendor) Information: Details about the vendors of the products involved, also from NVD.
Ground Truth Data: Real-world exploitation data from sources such as AlienVault.

EPSS Model and Tools

The current EPSS model, version 2022.01.01, uses 1,164 variables and is based on Gradient Boosting, a machine learning technique. For a visual and interactive view of EPSS scores, the EPSScall tool is useful. It provides historical data and graphs that make score movement easier to inspect.

The Drivers of EPSS Scores

To understand EPSS, it helps to look at which inputs carry the most weight. The variable importance graph shows the strongest contributors to the EPSS score.

Vendor data plays an outsized role in the scoring process. The graph shows how much weight each component has when estimating whether a vulnerability is likely to be exploited.

Why Does This Matter?

EPSS uses these data sources to predict exploit likelihood more directly than severity-only methods. By considering factors from the age of the CVE to real-world exploit instances, EPSS gives defenders a clearer view of which vulnerabilities are more likely to matter operationally. That makes patching and mitigation decisions easier to prioritise when resources are limited.

Understanding the components of EPSS also makes the score easier to interpret. It is not a single severity metric; it is a blend of several data points, each with different weight. Tools like EPSScall make those inputs easier to inspect when tuning a vulnerability management process.

Final Thoughts

EPSS is useful because it shifts vulnerability triage away from severity alone and towards exploit likelihood. Its use of multiple data sources and machine learning makes it a practical tool for defenders who need to decide what to fix first. Prioritising vulnerabilities this way does not replace judgement, but it gives teams a stronger starting point than CVSS alone.

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.

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.

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.

APRA Cybersecurity Guidelines

2023-10-12T12:31:00+11:00

Website cybersecurity is a practical requirement, and Australian organisations have a substantial body of guidance to work from. While the Australian Government's "Essential 8" focuses broadly on workplace security, the Australian Prudential Regulation Authority (APRA) offers a more specific Information Security Manual (ISM) with recommendations that apply to business websites.

Why Website Security Matters

When your business operates a website or web application, you are not just managing content; you are responsible for protecting data. Inadequate security controls expose you to risks such as data breaches, malware, DDoS attacks, and reputational damage. Company executives and operational staff need to implement relevant recommendations to minimise risk and liability if a security breach occurs.

APRA’s ISM: Tailored for Websites

APRA's ISM guidelines are practical for website owners. These are the key recommendations for websites and why they matter:

Network Traffic and Anonymity (ISM-1627, ISM-1628)

Blocking anonymity network traffic reduces the ability of malicious actors to hide their identity. This improves accountability when investigating suspicious requests and reduces security threats.

Cloud Service Providers (ISM-1437)

APRA advises the use of cloud service providers for hosting online services. A well-managed cloud platform can provide security controls and operational maturity that are difficult to match on premises.

Content Delivery Network (ISM-1438)

A CDN is not only a performance tool. It can filter malicious traffic before it reaches the origin and provide an additional layer of security.

Origin Exposure and DDoS Mitigation (ISM-1439)

Hiding the origin IP and using cloud providers for DDoS mitigation helps protect your primary server by dispersing traffic across a distributed network.

Data Encryption (ISM-1781, ISM-1139)

Encrypt all data over the network and use only the latest version of TLS to protect data in transit.

Logging and Auditing (ISM-261, ISM-580, ISM-0585, ISM-1661)

Comprehensive audit logging is vital for tracking activity and identifying irregular patterns. Logs should be detailed and reviewed periodically.

Web Application Firewall (WAF) (ISM-1240, ISM-1490, ISM-1509, ISM-1657)

A WAF provides a control point for monitoring and filtering incoming traffic, enabling you to block harmful requests.

Backup and Configuration (ISM-1511)

Back up your data, website, and configurations, and store them securely, preferably in a version-controlled environment such as Git.

HTTPS and SSL (ISM-1277, ISM-1552)

SSL certificates and HTTPS should be standard for all web content. This helps safeguard data integrity and user confidentiality.

Scaling and Monitoring (ISM-1579, ISM-1581)

Ensure your website can scale during demand spikes and that you have real-time monitoring for capacity and availability.

Virtual Patching and Antivirus Scanning (ISM-1690, ISM-1288, ISM-1694)

Virtual patching and antivirus scanning help protect your website against new vulnerabilities and malware.

Content Types (ISM-0649)

Only allow the specific content types your website needs to run. Restricting this reduces the risk of malicious content affecting your website.

Final Thoughts

Incorporating APRA’s ISM recommendations into your cybersecurity strategy makes your website more resilient against cyberattacks. Treat them as essential operating practices for website security, not as guidance to skim once and set aside.

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 how defenders can detect and block it.

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.

We can, however, counter OpenBullet by detecting and blocking the frameworks on which it relies.

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. Encouraging users to create unique passwords for each account and change them regularly can help reduce the risks posed by credential stuffing.

Implementing Advanced Bot Protection Measures

To secure online services against tools like OpenBullet, advanced bot protection matters. These measures can provide a multi-layered security strategy that runs in the background, collects detection signals, and challenges users only when necessary. They can help stop bot attacks from the first request, including those carried out through OpenBullet's automation framework.

As web platforms evolve, the tools used to exploit them evolve as well. Understanding threats like OpenBullet is the first step towards stronger online protection.

Peakhour's advanced Bot Management and rate limiting capabilities can help protect your site from automated tools like OpenBullet. Contact our team for a free security analysis.

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 Behavioral Analysis

Alongside advanced rate limiting, technologies like fingerprinting and behavioural analysis add another layer of protection. By creating a unique identifier for each user based on a combination of factors, such as IP address, device information, and browser settings, and tracking that user's behaviour over time, these technologies can help distinguish genuine users from automated scripts.

These mechanisms can detect anomalies, such as repetitive non-human patterns, sudden changes in behaviour, or usage patterns that do not match the typical profile of a human user. This level of analysis can identify and block even sophisticated bots that are designed to mimic human behaviour, providing an effective defence against OpenBullet and similar tools.

OpenBullet's accessibility and versatility have made it a popular choice for web attacks. Its simple UI, support for CAPTCHA farm services, and ability to run human-like automation allow even users with limited programming skills to execute complex attacks. Despite these challenges, detecting and blocking OpenBullet is achievable by understanding the origin of requests and the nature of its operation. A combination of advanced rate limiting, fingerprinting, and behavioural analysis can provide an effective defence.

Enterprise DDoS Protection

2023-06-19T00:00:00+10:00

Cyber threats continue to grow in complexity and volume, and Layer 7 attacks remain especially difficult to defend against¹. Each layer presents its own set of vulnerabilities for threat actors to exploit. The 7th layer, or application layer, handles application-specific communications. That makes it a useful target because modern applications are complex and varied.

Defending against Layer 7 attacks requires continuous tuning and adaptation¹. Microsoft highlighted the issue in June 2023, when it reported a traffic surge that temporarily affected the availability of some of its services¹.

Microsoft's Layer 7 DDoS Attacks

Microsoft's security team detected and tracked DDoS activity from a threat actor it called Storm-1359. The actor used a mix of resources, including multiple virtual private servers (VPS), rented cloud infrastructure, open proxies, and DDoS tools¹.

The activity did not target layers 3 or 4. It targeted layer 7, where requests can look like regular traffic and arrive from source IPs distributed around the world.

The Attack Methods

Storm-1359 used several attack types, including:

HTTP(S) Flood Attack: The attacker aimed to exhaust system resources with a high load of SSL/TLS handshakes and HTTP(S) request processing. This attack led the application backend to run out of compute resources such as CPU and memory¹.
Cache Bypass: The attacker attempted to overload the origin servers by bypassing the CDN layer¹.
Slowloris: In this case, the client opens a connection to a web server, requests a resource, such as an image, but fails to acknowledge the download or accepts it slowly. This causes the web server to keep the connection open and hold the requested resource in memory¹. Strengthening Layer 7 Protections

Microsoft mitigated the majority of disruptions by hardening its Layer 7 protections. It fine-tuned Azure Web Application Firewall (WAF) to better defend customers from the impact of similar DDoS attacks¹.

Azure Web Application Firewall, ModSecurity, and DDoS Attacks

Azure Web Application Firewall (WAF), part of Microsoft's security architecture, is built upon ModSecurity⁴, a well-established open-source Web Application Firewall (WAF) module¹. The DDoS attack Microsoft faced highlighted potential limitations in using ModSecurity, or any conventional WAF, as the primary defence mechanism against such threats.

ModSecurity's Limitations in DDoS Defence

ModSecurity is effective against a variety of web application threats, but it has limitations when dealing with DDoS attacks:

Lack of Scalability: ModSecurity is not inherently scalable. It can struggle to handle the enormous traffic volume associated with DDoS attacks.
Delayed Response: ModSecurity's rule-based approach can result in slower response times to evolving DDoS threats. While it can block threats based on established rules, it can take time to identify and create rules for new or uncommon attack patterns.
Operational Complexity: ModSecurity requires substantial expertise and constant fine-tuning to remain effective, potentially slowing down response times during a fast-paced DDoS attack.

These limitations were visible during the DDoS attack Microsoft experienced. Even though Microsoft utilised ModSecurity via Azure WAF, the time it took for Azure to respond underlines the challenge of using traditional WAFs for this class of attack¹.

The Role of Residential Proxy Networks in Layer 7 DDoS Attacks

Residential proxy networks create a specific problem in the defence against Layer 7 DDoS attacks³. These networks use IP addresses tied to physical locations, often originating from typical home or office internet connections. That makes it harder to separate legitimate traffic from malicious traffic.

Unlike traditional proxy or VPN networks, where traffic can be blocked or rate-limited based on their recognisable IP ranges, residential proxy networks blend in with legitimate users. That complicates identifying and blocking malicious requests, as any blocking or limiting measures could affect legitimate traffic from residential IPs.

A Potential Solution

In this context, fingerprinting can help distinguish between legitimate clients and malicious actors. Fingerprinting involves gathering data points from each client request, including user agent, IP address, headers, cookies, and more. The combination of these data points creates a unique 'fingerprint' for each client.

By analysing these fingerprints, it is possible to detect anomalous request patterns and potentially identify malicious clients hidden behind residential IPs. Fingerprinting can improve the accuracy of identifying malicious traffic, but it is not foolproof and should sit inside a broader, layered defence strategy.

Implementing effective fingerprinting also requires substantial technical expertise and resources. The measures need to avoid degrading user experience or breaching privacy regulations.

The Need for Specialised Rate Limiting Services

A specialised rate limiting service could have offered a faster and more effective response to the DDoS attack. Rate limiting restricts the number of requests that an IP address can make within a specific time period².

Such a service offers several advantages when defending against DDoS attacks:

Rapid Response: Rate limiting can provide a quick initial defence against a DDoS attack by immediately limiting traffic from suspicious IP addresses.
Flexibility: Rate limiting rules can be applied to factors such as IP addresses, URL, headers, response codes, and more, creating more granular defence mechanisms.
Reduced Load: By limiting the rate of requests, these services can reduce the load on the server, preserving resources for legitimate traffic.

Advanced Rate Limiting and Custom Keys

One way to defend against these attacks is through advanced rate limiting². Rate limiting restricts the number of requests an IP address, URL, or another custom key can make in a set time period. This can stop a single actor from flooding a network with traffic.

Criteria Used in Rate Limiting

Rate limits can be defined using different criteria:

IP Address
URL
Query String
Headers
Response Codes
GeoIP Information: ASN or Country Code
Parsed User Agent Information: Different rules for search engines vs. generic 'bots'
Fingerprints: TCP, TLS or H2 fingerprints can uniquely identify the connecting software
Meta Information: From bot protection service²

This allows rate limiting to 'bucket' requests using different criteria, effectively rate limiting a larger group of connections.

The Role of Anomaly Detection

Anomaly detection is another useful tool against these attacks. It identifies patterns or events that deviate from the norm and may indicate suspicious activity. Detecting those anomalies quickly can help teams respond faster, identify a suitable rate limit key and stop the potential attack.

Caching as a Mitigation Strategy

Caching is an effective mitigation strategy for Layer 7 attacks. It stores static responses to requests, reducing load on the server by serving those responses instead of processing each request individually. In a DDoS scenario, where a flood of requests is sent to the server, caching can help maintain availability. Ignoring client-provided 'Cache Control' headers such as 'max-age=0' or 'no-cache' can be effective because these headers are typically used to bypass a CDN.

Recommendations for Defence Against Layer 7 Attacks

Use anomaly detection to identify an active attack.
Use Layer 7 protection services, including rate limiting, with past 99th percentile hit rates as a starting point.
Apply bot mitigation techniques, as most Layer 7 attacks originate from bots.
Use IP reputation as an early warning sign, as many IPs have been involved in attacks before.
Block, limit, or redirect traffic from outside a defined geographic region.
Rate limit or block requests from data centre and hosting ASNs.
Create custom WAF rules to automatically block and rate limit HTTP or HTTPS attacks with known signatures.
Use effective CDN caching and ignore client-presented Cache-Control headers.

Defending against Layer 7 attacks requires several controls working together. Rate limiting, anomaly detection, and effective caching all have a role.

Peakhour's advanced rate limiting and DDoS mitigation strategies help protect applications from sophisticated Layer 7 attacks. Contact our team to strengthen your defences.

The Rise of the Dragon

2023-05-17T13:00:00+10:00

Camaro Dragon, a Chinese state-sponsored group, has developed a custom firmware implant for TP-Link routers. Once installed, it can turn compromised routers into residential proxies. That weakens traditional cyber-defences, including GeoIP blocking, because traffic can appear to come from ordinary local connections. This article looks at how the malware works, why residential proxies matter for enterprise security, and where GeoIP security measures fall short.

Understanding the New Malware

Check Point's research describes Camaro Dragon's sophisticated attacks on European foreign affairs entities. The group uses a custom firmware implant, known as 'Horse Shell', designed specifically for TP-Link routers. The malware includes a backdoor that grants the attackers continuous access to compromised networks and allows them to build anonymous infrastructure.

'Horse Shell' can execute arbitrary commands on the infected router, transfer files, and relay communications using SOCKS tunnelling. Its design can be adapted to different vendors' firmware, suggesting the possibility of a wider spread.

The People and Intentions Behind The Malware

Investigations into the origin of the 'Horse Shell' malware by Check Point Research, Avast, and ESET point to a well-known cyber threat actor: Mustang Panda. This advanced persistent threat (APT) group, linked to the Chinese government, is known for complex attacks that often exploit Internet-facing network devices.

The primary function of 'Horse Shell' is to relay traffic between an infected device and the attackers' command and control servers. This method obscures the true source and destination of the communication, making it difficult to trace back to the attackers.

Importantly, Mustang Panda appears to choose router implant targets indiscriminately. The infection of a home router doesn't imply that the homeowner is a direct target. Instead, each infected router becomes a node in a broader chain that connects main infections with command and control operations.

Researchers identified this approach when they found the 'Horse Shell' implant during an investigation of targeted attacks against European foreign affairs entities. The implant allows the attackers to maintain ongoing access, establish anonymous infrastructure, and move laterally within compromised networks.

The Implications of Residential Proxies

Residential proxies serve as intermediaries, using real IP addresses issued by Internet Service Providers (ISPs). They are used across a range of applications, including business web scraping and anonymising user online activity.

Residential proxies become more serious when malware such as 'Horse Shell' is involved. This malware infects routers, turning them into a network of residential proxies that can then be used for malicious activity, including data breaches and distributed denial-of-service (DDoS) attacks.

Most importantly, this use of residential IP space can make an attack look as if it originates from a domestic source within the target's location. That undermines traditional cyber-defences.

GeoIP Security Measures and Their Limitations

GeoIP blocking, a traditional cyber security tool, works by limiting access from specific geographical regions or networks frequently associated with cyber threats. However, this method is becoming less effective against the rising use of residential proxies.

Residential proxies can disguise the actual origin of a cyber attack, giving the illusion that it's originating from a trusted, usually local, location. This capability allows them to effectively bypass GeoIP blocking measures. Consequently, malicious actors using residential proxies can carry out their activities with less obvious attribution and often go undetected.

The key operational issue is the exploitation of home routers by malware like 'Horse Shell,' which turns these devices into unwitting participants in cyber attacks. This manipulation means an attack could appear to originate from a seemingly trusted domestic source, which can render GeoIP blocking ineffective.

This threat shows why cyber security needs a more layered approach. Sole reliance on GeoIP blocking is no longer enough. As malware evolves to exploit residential proxies, detection and defence strategies need to adapt. Specifically, it's important to recognise that relying solely on GeoIP blocking, or trusting apparently local connections and deny-listing countries like Russia and China, can create a false sense of security.

Detecting Residential Proxies: The Role of Network Fingerprinting

The rise of residential proxy malware makes network fingerprinting important for identifying these threats. Five techniques can help detect residential proxies:

TCP Fingerprinting: Proxied requests may generate TCP fingerprints that don't match the expected device type. For example, a request from a residential IP address that bears the fingerprint of a server OS could be a strong signal of a proxy.
TLS and HTTP/2 Signatures: As with TCP fingerprints, unusual TLS and HTTP/2 signatures could reveal proxies. An incoming request using a version of TLS or HTTP/2 not commonly used in residential networks might indicate a proxy.
JavaScript-based Fingerprinting: This method identifies the specific browser in use. Discrepancies in JavaScript fingerprints, or the absence of a fingerprint, could suggest the presence of a residential proxy.
Timing Analysis: The timing of requests can also be a signal. Proxied requests might exhibit longer or inconsistent intervals between requests, indicating a residential proxy.
Port Scanning: This technique can detect open ports that could indicate the presence of SOCKS or other proxies, revealing possible exposure to threats.

While residential proxies have legitimate uses, such as web scraping, those applications sit beside a more serious risk: compromised trusted or local networks can be turned into proxy infrastructure at scale. Cyber threats like 'Horse Shell' use residential proxies to undermine traditional GeoIP security measures, which means defence strategies need to keep evolving.

In Part 1 of our series on residential proxies, we provide an overview of this topic and why it matters to security teams. From basic uses to their role in complicated cyber attacks, we cover the key points.

Learn how Peakhour's Application Security Platform protects against account takeovers and credential stuffing. Contact our team to secure your user accounts.

Cohen, I., Madej, R., & Threat Intelligence Team (2023). The Dragon Who Sold His Camaro: Analyzing Custom Router Implant. Check Point Research. Retrieved from https://research.checkpoint.com/2023/the-dragon-who-sold-his-camaro-analyzing-custom-router-implant/ ↩
Goodin, D. (2023, May 17). Malware turns home routers into proxies for Chinese state-sponsored hackers. Ars Technica. Retrieved from https://arstechnica.com/information-technology/2023/05/malware-turns-home-routers-into-proxies-for-chinese-state-sponsored-hackers/ ↩

Residential Proxies and MITRE Framework

2023-05-17T13:00:00+10:00

Residential proxies act as intermediaries, routing traffic through real-world IP addresses. That can mask user identity, bypass geographical restrictions, and improve privacy. The MITRE ATT&CK framework, a matrix of cyber adversary tactics and techniques, categorises proxy use under technique T1090. The classification helps explain how attackers use proxies to maintain command and control across target environments, including Linux, Windows, and macOS.

Residential proxies are useful and risky in equal measure. They support anonymity and data collection, but misuse creates ethical and security concerns, including credential stuffing and account takeovers. MITRE ATT&CK's treatment of proxy use gives security teams a clearer way to reason about those risks and plan mitigations.

Looking at residential proxies through the MITRE framework keeps the discussion grounded. It shows where proxy use fits into attacker tradecraft, and where defenders need practical controls rather than broad assumptions about intent.

From Credential Stuffing to Account Takeover and Data Exfiltration

Credential stuffing and account takeover incidents, including the Ubiquiti breach, show how exposed digital defences can be. Attackers use residential proxies to mask activity, which aligns with MITRE ATT&CK technique T1090. This technique describes proxy use for discreet command and control. In the Ubiquiti case, adversaries utilised proxies to test and apply stolen credentials across systems without revealing their true locations, a direct application of T1090's principles.

The Camaro Dragon malware demonstrates residential proxy exploitation for account takeovers. By infecting devices and incorporating them into a botnet, the malware facilitated remote control over victims' accounts, aligning with MITRE's T1090 for proxy-managed network communications. Camaro Dragon's operation reflects the tactic of maintaining anonymity while executing unauthorised access and control, a strategy documented within the MITRE framework.

Volt Typhoon's activities present a sophisticated use of residential proxies in data exfiltration. This group, known for targeting infrastructure, manipulated proxies to move data discreetly from compromised networks, a tactic that falls under MITRE's T1090. The operation shows how adversaries use residential proxies to obscure the digital footprint of data theft, complicating traceability and detection.

Viewed through MITRE ATT&CK, these examples show how residential proxies support credential stuffing, account takeovers, and data exfiltration. They also point to the need for integrated defence strategies that account for different forms of proxy misuse, rather than treating proxy traffic as a single problem.

The Role of Residential Proxies in Web Scraping

Residential proxies are common in web scraping because they let operators simulate requests from different geographic locations. That capability is especially useful when gathering data from websites with GeoIP restrictions or anti-scraping measures. In the MITRE ATT&CK framework, residential proxy use in web scraping aligns with several techniques that describe how adversaries gather information and evade detection.

Technique T1090, which details proxy use, illustrates how adversaries utilise residential proxies to disguise web scraping activity. By routing requests through proxies, they can avoid IP bans and rate limits, enabling the collection of large amounts of data without detection. This technique shows the practical advantage of residential proxies in bypassing network defences and aggregating targeted information discreetly.

Web scraping through residential proxies also intersects with the MITRE framework's emphasis on reconnaissance techniques. Adversaries use reconnaissance to gather valuable data about targets, and residential proxies help them do it discreetly. By presenting requests as coming from different residential IPs, attackers can compile detailed profiles on organisations, their operations, and vulnerabilities without revealing their intent or location.

For defenders, residential proxy use in web scraping creates a dual challenge. It can support legitimate data collection and market research, and it can also help adversaries gather intelligence before further attacks. That makes proxy handling a judgement problem as well as a blocking problem: organisations need to balance access to information with protection against unauthorised data extraction.

Understanding residential proxy use in web scraping through MITRE ATT&CK helps define the detection problem more precisely. Defenders need mechanisms that can distinguish legitimate proxy-backed activity from malicious use, and policies that can respond without over-blocking normal traffic.

Defending Against Proxy-Related Cyber Attacks Informed by MITRE

Defending against cyber attacks that use residential proxies requires layered controls informed by MITRE ATT&CK. Technique T1090, which focuses on proxy use for command and control activity, provides a useful base for designing those defences.

Network Monitoring and Analysis

A core defence is stronger network monitoring and analysis. By scrutinising network traffic, organisations can identify unusual patterns that may indicate malicious proxy use. This includes monitoring for excessive requests from varied geographic locations that do not align with normal user behaviour. The MITRE framework suggests network intrusion detection systems (NIDS) to detect suspicious activity, including anomalous residential proxy use.

Implementing Access Controls and Rate Limiting

To mitigate credential stuffing and account takeover through proxies, organisations need strict access controls and rate limiting. These measures can reduce automated attacks by limiting how many requests a user can make within a set timeframe, weakening distributed attempts to breach systems via residential proxies.

Application of Web Application Firewalls (WAFs)

Web Application Firewalls (WAFs) help defend against proxy-related attacks. When configured to recognise and block requests with patterns typical of proxy misuse, such as rapid request rates or known malicious IP addresses, WAFs provide a barrier against unauthorised data scraping and other proxy-facilitated intrusions.

Proxy Detection and Blocking

Advanced proxy detection tools help organisations identify and block traffic coming through known residential proxies. Techniques include analysing originating IP addresses for known proxies and using behaviour analysis to detect patterns indicative of proxy use. Once identified, these IP addresses can be blocked or subjected to additional scrutiny.

User Behavior Analytics (UBA)

User Behavior Analytics (UBA) helps detect anomalies that may signal a proxy-based attack. By establishing baselines of normal user activity, UBA systems can flag deviations that suggest malicious activity, such as multiple failed login attempts or unusual data access patterns, which are indicative of credential stuffing or data exfiltration attempts.

Educating Users on Security Hygiene

Educating users on security hygiene can help prevent inadvertent participation in malicious proxy networks. Users should understand the risks of downloading unverified software or browser extensions, which could turn their devices into nodes within a residential proxy network.

Informed by MITRE ATT&CK, these defence strategies give organisations a practical way to reduce exposure. Understanding the tactics and techniques used by adversaries helps teams strengthen controls against sophisticated residential proxy use in cyber attacks.

Detecting Malicious Use of Residential Proxies

Detecting malicious residential proxy use requires both technical controls and threat intelligence. The MITRE ATT&CK framework, particularly technique T1090, gives defenders a reference point for how adversaries use proxies and where detection mechanisms should focus.

Traffic Pattern Analysis

One primary method for detecting malicious residential proxy use is traffic pattern analysis. This includes monitoring for spikes in traffic from geographical locations that do not match the service's typical user profile. Anomalies in request rates or patterns that suggest automation, such as regular intervals between requests, can also indicate proxy abuse.

Behavioral Anomaly Detection

Behavioural anomaly detection systems identify actions that deviate from normal activity. These systems can flag unusual behaviour that might indicate malicious residential proxy use, such as repeated login attempts from different IP addresses in a short period, which could signify a credential stuffing attack.

IP Reputation and Proxy Lists

Utilising IP reputation databases and known proxy lists can help identify and block requests from suspicious sources quickly. These lists include IP addresses known to be part of residential proxy networks or previously implicated in malicious activity. Integrating this intelligence into security systems allows for real-time blocking or flagging of potentially harmful traffic.

Endpoint Detection and Response (EDR) Systems

Endpoint Detection and Response (EDR) systems help spot compromised devices within an organisation that could unknowingly be part of a residential proxy network. By monitoring endpoints for signs of malware or unexpected network traffic, organisations can detect and isolate infected devices before they are used in cyber attacks.

Advanced Machine Learning Models

Advanced machine learning models can be trained to recognise subtle signs of proxy misuse. By analysing large datasets of network traffic, these models can identify patterns that human analysts might miss. This includes detecting sophisticated attempts to mimic legitimate user behaviour through proxies, which could indicate reconnaissance or data exfiltration efforts.

Collaboration and Information Sharing

Collaboration and information sharing among organisations and cybersecurity entities can improve detection of malicious proxy use. Sharing indicators of compromise (IoCs) and tactics, techniques, and procedures (TTPs) associated with proxy misuse can help develop stronger detection strategies across the board.

Incorporating these detection methods, informed by MITRE ATT&CK, helps organisations identify and mitigate risks associated with malicious residential proxy use. The goal is not to label every proxy request as hostile, but to detect the patterns that matter when residential proxies are exploited for cyber attacks.

Residential Proxy Detection

2023-05-17T13:00:00+10:00

Residential proxies are under increasing scrutiny, both for how their IP addresses are obtained and for how those networks are used. They also expose how heavily many online services rely on GeoIP data, from content customisation to security controls.

That scrutiny reveals a complicated reality. Residential proxies can help businesses, researchers, and individuals preserve anonymity or work around GeoIP-dependent restrictions. The same properties also create ethical problems, particularly when the networks are misused.

This article explains what residential proxies are, how they work, where they are useful, and where the risk sits. The same properties that make them attractive for legitimate monitoring and research also make them useful for abuse.

Demystifying Residential Proxies

These proxies connect automated software to the internet through IP addresses tied to real-world residential locations. That lets the software look closer to ordinary internet usage, which can help it bypass geographical and network restrictions while adding a layer of anonymity.

Residential proxies need a clear legal and ethical distinction. Their use can be lawful, including for web scraping and data gathering, while still enabling activity that may breach the intended usage policies of some online services. This could include mass consumption of data intended for general use, such as scraping websites for machine learning datasets. These actions may not be strictly illegal, but they raise substantial ethical questions and are often unwelcome to the data providers.

Applications of Residential Proxies

The defining characteristic of residential proxies is that requests can appear to originate from local residential networks. That supports a wide range of use cases, including:

Concealing True IP Addresses: Residential proxies allow third parties to hide genuine IP addresses and location, making identity and origin harder to determine. By routing internet traffic through residential IP addresses, they can evade detection, bypass security rules, and access geo-restricted content.
Research and Monitoring: Residential proxies are often used by researchers, analysts, and market intelligence professionals to gather data and monitor online activity. By utilising residential IP addresses, they can emulate real user IP addresses and bypass restrictions.
Web Scraping and Data Gathering: Residential proxies are central to many web scraping and large-scale data collection workflows. With the capacity to rotate IP addresses and access a wide range of residential locations, third parties can scrape valuable data from websites without triggering anti-scraping measures. Residential proxies can make data scraping more discreet, with fewer access interruptions and cleaner collection results.
Ad Verification: Residential proxies are widely used for ad verification. Ad verification companies utilise residential IP addresses to confirm the accuracy and legitimacy of online advertisements. By mimicking genuine residential connections, they can check that ads are correctly displayed and monitor the performance and integrity of advertising campaigns.
Ad Fraud: Residential proxies can also be misused for ad fraud. Competitors or their agents may utilise residential IP addresses to falsely inflate the views of a rival's online advertisements. By using genuine residential connections, these entities can manipulate advertising metrics, compromising the accuracy and integrity of the ad's performance data. This abuse of residential proxies for ad fraud poses a significant concern for the online advertising industry.
Last Mile Monitoring: Last mile monitoring is another application for residential proxies, allowing companies to assess the user experience from a residential viewpoint. By using residential IP addresses, they can monitor website loading speeds, test service availability, and evaluate the performance of online platforms more accurately. This helps organisations pinpoint and rectify issues that may negatively affect user satisfaction.

Navigating the Risks and Concerns

Residential proxies create material risks, particularly when users are unaware that they are hosting one. Their use can introduce practical limits and security vulnerabilities that are easy to miss.

Despite their valid uses, residential proxies can be used for cybercriminal activity. Malicious actors may exploit them for account takeovers, fraud, or other targeted attacks.

Using residential proxies without the knowledge or consent of residential users creates serious security issues. These users, unaware of how their connections are being utilised, could face legal exposure, compromised privacy, and cyber threats. Their devices could unwittingly participate in malicious activity, leaving them exposed to legal consequences and reputational damage.

Exploring the Creation of Residential Proxies and their Implications

Residential proxy providers build their networks in several ways, some of which can have significant security implications.

Providers can obtain residential proxies through partnerships with Internet Service Providers (ISPs) or by leasing IP addresses from legitimate residential users. At the same time, some providers or private groups may use questionable practices to obtain residential proxies.

SDKs: Certain applications may include Software Development Kits (SDKs) that gather and sell user data, including their IP addresses. In some instances, these SDKs can be exploited by residential proxy providers to acquire residential IPs without the explicit consent or knowledge of the users.
Malware Exploitation: Malware, including botnets, can infiltrate the devices of unsuspecting residential users. Attackers may then exploit these infected devices as part of a broader residential proxy network, without user awareness. This unauthorised use of residential IPs poses significant security threats to both the affected users and the wider internet ecosystem.
Free VPN Services: Some free Virtual Private Network (VPN) services, which promise anonymity and privacy, may use users' connections as part of their residential proxy networks. Users unknowingly become exit nodes for other users' internet traffic, potentially exposing their connections to malicious activities.

Using residential proxies without the knowledge or consent of residential users raises serious security concerns. These users may not understand how their connections are being used, which can lead to legal consequences, compromised privacy, and exposure to cyber threats. Their devices might unknowingly participate in malicious activities, exposing them to potential legal consequences and reputational damage.

The Birth of 'Ethical' Proxies

An important part of the residential proxy discussion is the rise of providers claiming that their IP address pools are ethically sourced. These companies argue that they have obtained the consent of the original IP owners and provide transparency in how these connections are utilised. By positioning themselves as 'ethical' residential proxy providers, they aim to mitigate the associated risks and concerns.

Even where consent is obtained, the potential for misuse remains a significant issue. This is largely due to the inherent anonymity of residential proxies and the difficulty of tracing activity back to the original user. Despite claims of ethical sourcing, the complexity and opacity of the residential proxy environment mean that it remains a grey area, inviting scepticism and demanding further scrutiny.

The result is a nuanced market that consumers, providers, and regulators need to understand as the digital landscape continues to evolve.

From Hola VPN to the Camaro Dragon

Several publicised incidents show how residential proxies are formed and the impact they have had on the industry and users. These examples show the different ways residential proxies can be created and used, legitimately and otherwise.

Hola VPN is a well-known free VPN service that promises privacy, security, and access to blocked content. However, it fell under scrutiny when it was revealed that it was selling its users' bandwidth to its sister company, Luminati, which operates a residential proxy network. Users of Hola VPN unknowingly became part of a residential proxy network, with their connections being utilised by third parties. This raised significant ethical and security concerns, as users' devices could be implicated in illegal activities carried out using their IP addresses.
The residential proxy service known as 911 has been selling access to hundreds of thousands of Microsoft Windows computers for the past seven years. This service enables customers to route their internet traffic through these computers, allowing them to appear as if they are browsing from any country or city around the world. While 911 claims that its network comprises users who voluntarily install its "free VPN" software, recent research indicates that the proxy service has a history of obtaining installations through questionable "pay-per-install" affiliate marketing schemes, some of which were operated by 911 itself. The service primarily targets users in the United States but has a global user base. Residential proxy networks like 911 can serve legitimate business purposes, but they are often abused for cybercriminal activities due to the difficulty in tracing malicious traffic back to its source.
Cybercriminals are increasingly leveraging residential broadband and wireless data connections to anonymise their malicious traffic. One notable type of network, referred to as "bulletproof residential VPN services", has gained attention. These networks are constructed by acquiring discrete blocks of internet addresses from major internet service providers (ISPs) and mobile data providers. An investigation into one such company, Residential Networking Solutions LLC (also known as Resnet), unveiled that it had obtained a significant number of IP addresses, some of which were previously controlled by AT&T Mobility. Resnet leased these IP addresses, enabling it to resell data services for major providers such as AT&T, Verizon, and Comcast Cable. However, the precise nature of the relationship between Resnet and AT&T remains unclear, and the matter has been referred to law enforcement. Cases like this emphasise the potential abuse of IP addresses within residential proxy networks.
Infatica.io, a Singapore-based company, has developed a network of over 10 million web browsers that clients can rent to conceal their true internet addresses. The company achieved this by compensating browser extension developers to incorporate its code into their extensions. Many extension developers struggle to earn fair compensation for their work, making offers like these enticing. Infatica seeks extensions with at least 50,000 users and offers to pay developers between $15 and $45 per month for every 1,000 active users with the code included in their extensions. Infatica's code routes web traffic through the browsers of extension users, providing anonymity to the company's customers. The service's pricing depends on the volume of web traffic a customer wishes to anonymise. However, this approach raises concerns about privacy and the potential misuse of users' browsers for malicious activities. Developers, particularly those who author free software, can find the monetisation opportunity offered by residential proxies extremely tempting. The potential to earn revenue from their existing user base by incorporating such code into their extensions can present a persuasive proposition.
Camaro Dragon, a form of malware, provides a recent example of residential proxies being acquired through malicious means. This malware infects the devices of unsuspecting users, forming a botnet that can then be utilised as a residential proxy network. Infected devices can then be exploited for various cybercriminal activities without the knowledge or consent of the device owners. This example highlights the significant cybersecurity risks associated with residential proxies and emphasises the importance of robust protection measures.
Volt Typhoon is a state-sponsored actor based in China that typically focuses on espionage and information gathering. Volt Typhoon proxies all its network traffic to its targets through compromised SOHO network edge devices (including routers). Microsoft has confirmed that many of the devices, which include those manufactured by ASUS, Cisco, D-Link, NETGEAR, and Zyxel, allow the owner to expose HTTP or SSH management interfaces to the internet. Volt Typhoon has been active since mid-2021 and has targeted critical infrastructure organisations in Guam and elsewhere in the United States.

These examples illustrate the ethical, security, and legal issues surrounding residential proxies. They put transparency and consent at the centre of how proxy networks are acquired and used. The implications for users, the security industry, and the broader digital landscape are substantial, which is why regulation, user education, and responsible practices matter for protecting privacy, security, and the integrity of the internet.

Legal Consequences of Residential Proxies in Data Scraping Operations

Residential proxies are a concern because of their potential for misuse and their legal implications. Two notable cases, the Ticketmaster Case and the Meta vs Bright Data Case, have drawn attention to the challenges posed by the unauthorised use of residential proxies in commercial settings and data scraping operations. These cases show why the legal ramifications of residential proxy use need to be understood in real-world scenarios.

The Ticketmaster Case: In 2018, a major international case came to light when Ticketmaster sued Prestige Entertainment for using residential proxies to circumvent ticket-purchasing limits and scoop up large numbers of tickets for resale. This case underscores the potential misuse of residential proxies in commercial settings, and how they can be used to breach the terms of service of websites.
The Meta vs Bright Data Case: The legal case between Meta Platforms, Inc. (formerly Facebook) and Bright Data Ltd. demonstrates a contentious and potentially unlawful use of residential proxies in the real world. In this case, Meta accused Bright Data of operating a business designed to use automated software to scrape and sell data from various online platforms, including Facebook and Instagram. This scraping was allegedly facilitated using unauthorised tools and services that bypassed detection by Meta's security measures. Despite Meta's efforts to halt these activities, Bright Data purportedly continued its operations. The data involved included user profiles, follower counts, and shared posts. Bright Data was alleged to not only scrape this information but also advertised the sale of the scraped data. The scope of this operation was extensive, with the Instagram data set alone priced at $860,000.

These cases show how residential proxies are used in practice, the challenges they present, and why their use remains legally and commercially contested.

The Wider Implications for the Security Industry

The growth of residential proxies, and the way some networks are acquired, has broader implications for the security industry. It raises questions about transparency, ethical practices, and the responsibility of proxy providers.

Ethical and Regulatory Implications: The questionable practices some providers use to acquire residential proxies highlight the need for stronger regulation and industry standards. This would help ensure that residential proxies are obtained and used in a lawful and ethical manner, protecting users' privacy and the wider internet ecosystem. There is a clear demand for more transparency in how these services operate and procure their proxies.
Cybersecurity Implications: Residential proxies can enable malicious cyber activity, ranging from fraud to targeted attacks. This can increase the need for cybersecurity measures and protections, potentially reshaping strategies and priorities within the cybersecurity industry.
Legal and Reputational Implications: If individuals unknowingly become part of a proxy network, there could be legal repercussions for them if their connections are utilised for malicious activities. This could lead to greater scrutiny and liability for companies operating within this space.
State Actors and Residential Proxy Networks: State-sponsored actors have been known to establish their own residential proxy networks within foreign countries for various campaigns, including information warfare, disinformation campaigns, and surveillance, adds another layer of complexity to the issue. These activities pose significant geopolitical and security risks, requiring increased international cooperation and robust defence mechanisms.

The rise of residential proxies exposes a weakness in common security models: the assumption that residential and mobile IPs are inherently more trustworthy, and that GeoIP is a reliable reputation or security control. Widespread proxy use has shown how brittle that assumption can be.

Uncertain or unethical sourcing makes that trust problem harder. It can make online interactions less reliable and introduce security risks.

Residential proxies are not just tools; they highlight a deeper issue in how we approach digital access and security. Understanding what is already known, questioning current practices, and building better controls are practical steps towards using residential proxies responsibly and ethically. Recognising the false sense of security GeoIP restrictions can provide is part of that work.

Part 1 ends here. In Part 2: the Camaro Dragon malware, we look more closely at a specific case. This sophisticated malware uses residential proxies in a way that shows their potential for misuse. The next article covers how Camaro Dragon works, its impact on cybersecurity, and practical protection measures.

Mi, X., Tang, S., Li, Z., Liao, X., Qian, F., & Wang, X. (2021). Our Phone is My Proxy: Detecting and Understanding Mobile Proxy Networks. Retrieved from https://xianghang.me/files/ndss21_mobile_proxy.pdf ↩
Mi, X., Feng, X., Liao, X., Liu, B., Wang, X., Qian, F., Li, Z., Alrwais, S., Sun, L., & Liu, Y. (2019). Resident Evil: Understanding Residential IP Proxy as a Dark Service. Retrieved from https://www-users.cse.umn.edu/~fengqian/paper/rpaas_sp19.pdf ↩
Krebs, B. (2019, August 19). The Rise of "Bulletproof" Residential Networks. Retrieved from https://krebsonsecurity.com/2019/08/the-rise-of-bulletproof-residential-networks/ ↩
Krebs, B. (2022, July 18). A Deep Dive Into the Residential Proxy Service '911'. Retrieved from https://krebsonsecurity.com/2022/07/a-deep-dive-into-the-residential-proxy-service-911/ ↩
Krebs, B. (2021, March 1). Is Your Browser Extension a Botnet Backdoor? Retrieved from https://krebsonsecurity.com/2021/03/is-your-browser-extension-a-botnet-backdoor/ ↩
Meta Platforms, Inc. v. Bright Data Ltd. Retrieved from https://unicourt.com/case/pc-db5-meta-platforms-inc-v-bright-data-ltd-1374026 ↩
Volt Typhoon targets US critical infrastructure with living-off-the-land techniques. Retrieved from https://www.microsoft.com/en-us/security/blog/2023/05/24/volt-typhoon-targets-us-critical-infrastructure-with-living-off-the-land-techniques/ ↩

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.

Double MAD?

2023-05-15T13:00:00+10:00

This article explores the use of Double Median Absolute Deviation (Double MAD) for [anomaly detection](/learning/threat-detection/what-is-anomaly-detection/) in time series
data, particularly in skewed or non-symmetric distributions. Double MAD, which calculates two median absolute
deviations — one for data below the median and one for data above — provides a more nuanced approach than traditional
MAD, allowing for accurate detection of anomalies even in skewed data distributions. We also delve into its application
in identifying slow abuse, like bots, by catching lower range anomalies. However, it's important to note Double MAD's
limitations such as not capturing seasonal data shape and trends over time. A comparison is also drawn with the Z-score
method, highlighting that the choice between the two depends on the nature of your data. The article provides insights
into the practical implementation of Double MAD and its potential to improve your data analysis toolkit.

Operational systems increasingly rely on time-series data for decisions. Anomaly detection is one practical use: by identifying patterns that deviate from the norm, businesses can investigate potential issues early or understand unexpected opportunities.

One useful technique for anomaly detection is the Median Absolute Deviation (MAD) and, more specifically, its extension, the Double MAD. This article explains where Double MAD fits in time-series anomaly detection and how it can help identify anomalous clients.

Understanding MAD and Double MAD

MAD, a robust measure of variability, is less susceptible to outliers than standard deviation. It calculates the median of absolute deviations from the data's median, often providing a better representation of 'normal' behaviour in datasets with skewed distributions or outliers.

Double MAD is an extension of MAD, where two MADs are calculated — one for the data below the median and another for the data above. This split gives the detection process a better fit for asymmetric data, which is common in real-world time series data.

Why Double MAD?

While MAD provides a robust way to understand the 'normal' range of a dataset, it assumes a symmetric distribution of data around the median, which may not always hold true. Double MAD is useful where that assumption breaks down, offering an improved anomaly detection process for skewed or asymmetric datasets.

In time-series analysis, especially with 24-hour cycles like web traffic or server usage, patterns can exhibit seasonality and trend components. These patterns can often be asymmetric, making Double MAD a valuable tool for capturing the variability in different parts of the data.

Using Double MAD in Anomaly Detection

The Double MAD implementation provided uses Rust, a system programming language known for speed and memory safety. The code calculates the lower and upper MAD values, along with their respective thresholds. Anomalies can then be detected by comparing each data point to these thresholds.

An anomaly is defined as a data point that deviates significantly from the expected range. If a data point falls below the lower MAD threshold or above the upper one, it can be flagged as an anomaly. This approach is especially effective when handling datasets with high variability or extreme values.

Double MAD for Anomalous Client Detection

Beyond time-series data, Double MAD can also be instrumental in identifying anomalous behaviour among clients. By comparing each client's behaviour against the Double MAD of the time-series data, teams can pinpoint clients that deviate from the norm.

For instance, in the context of web service usage, an anomalous client might be one that is sending an unusually high or low number of requests. By using Double MAD, you can flag such outliers and take appropriate action, such as investigating potential misuse or reaching out to understand and address any issues they may be facing.

Detecting Lower-Range Anomalies: A Case of Slow Abuse

An interesting application of Double MAD is in detecting lower-range anomalies, a pattern often associated with slow abuse such as bots or Distributed Denial of Service (DDoS) attacks. These abuses are characterised by an unusually low frequency of activity that is consistent over a prolonged period. This consistent, low-level activity can fly under the radar of typical anomaly detection systems.

By setting a lower MAD threshold, Double MAD can effectively detect these lower-range anomalies, providing early warning of slow abuse. Its ability to detect both high and low anomalies makes Double MAD a flexible tool for anomaly detection.

The Math Behind Double MAD

To illustrate the power of Double MAD, let's consider a dataset from a right-skewed distribution. Applying the conventional MAD approach might lead to false positives where normal data points are marked as outliers. This is because MAD uses a symmetric interval around the median, which doesn't account for the skewed nature of our data.

With Double MAD, we instead calculate two MADs — one for the data below the median (MAD-lower) and another for the data above (MAD-upper). Outlier thresholds are then defined using these two MADs. The lower threshold is calculated as the median minus a multiplier (k) times MAD-lower. The upper threshold is the median plus k times MAD-upper.

This approach takes into account the asymmetric nature of our data, providing more accurate anomaly detection. For example, in a right-skewed distribution, Double MAD would correctly identify only the extreme right tail values as outliers without incorrectly flagging data points on the left tail.

Wrapping Up

Accurate anomaly detection matters when teams rely on time-series data to operate and investigate systems. The Double MAD approach provides a robust method for this, allowing businesses to better understand their data, spot potential issues early, and make more informed decisions.

Whether you're monitoring web traffic, server usage, or client behaviour, leveraging Double MAD can offer valuable insights and help ensure your operations continue to run smoothly. The ability to detect both high and low anomalies makes it especially powerful, providing protection against potential threats like slow abuse.

Understanding and implementing Double MAD gives your data analysis toolkit a more complete view of asymmetric data and helps you detect potential anomalies earlier.

Scaling anomaly detection with RRCF

2023-05-15T13:00:00+10:00

As data volumes grow, the anomaly detection process has to scale with them. RRCF is efficient, but large, high-dimensional datasets can still create performance challenges. The following strategies focus on reducing dimensionality, smoothing bursts of input, and distributing independent work.

Compute Summary Statistics Instead of Shingling

Shingling transforms a single time series into a multivariate one by stacking lagged versions of the data. This can help capture temporal dependencies, but it also increases the dimensionality of the points inserted into each tree, which can slow the algorithm down.

An alternative is to compute summary statistics that capture the types of anomalies you are looking for. For instance, if you are detecting spikes, the data points could consist of second central differences. If you are looking for long-term trends, the data points could consist of rolling means at different window sizes. This reduces the dimension of the points inserted into each tree, improving performance.

Buffer Input and Compute Rolling Summary Statistics

When data arrives too quickly to be inserted into the trees directly, buffer the input and compute rolling summary statistics (mean, median, max, etc.). This reduces the number of points that need to be inserted into the trees and helps the algorithm keep up with the streaming data.

Parallelisation

RRCF can be parallelised, which is particularly useful when dealing with multiple independent time series. Different RRCF instances can be run for each time series, using separate processes or server instances. This distributes the computational load and can improve performance.

For instance, if you have 10 independent time series, you can run 10 instances of RRCF in parallel, each focusing on one time series. This scales the anomaly detection process to handle larger volumes of data.

Conclusion

Scaling RRCF for large datasets usually means reducing the work each tree has to do, controlling input volume, and parallelising where the data allows it. Summary statistics, input buffering, and independent RRCF instances can help manage high-dimensional data and high data velocities without changing the underlying anomaly detection goal.

Applied RRCF - thresholding techniques.

2023-05-15T13:00:00+10:00

Once we've applied the RRCF algorithm to our streaming data, the resulting scores measure how anomalous each data point is. To classify data points as "normal" or "anomalous", we still need to set a threshold. This defines the level of deviation considered anomalous and controls how often anomalies are over-identified or missed.

Why is Thresholding Needed?

Thresholding matters in anomaly detection because it separates normal and anomalous behaviour. Without a threshold, the scores still indicate relative degrees of anomalousness, but they do not provide a clear dividing line between normal points and anomalies.

Set the threshold too low and normal data points may be misclassified as anomalies, increasing false positives. Set it too high and actual anomalies may be missed, increasing false negatives.

How to Set the Threshold?

There are several ways to set a threshold for RRCF scores, including the Median Absolute Deviation (MAD), Min/Max, and others. The right method depends on the characteristics of the data and the specific use case.

Median Absolute Deviation (MAD)

The Median Absolute Deviation is a robust measure of variability in a data set. For RRCF scores, MAD can be used to set a threshold. A typical approach is to set the threshold as some multiple of the MAD above the median. This approach is robust to outliers and can be useful when the data has heavy-tailed distributions.

Min/Max

Another approach is to use the minimum and maximum RRCF scores to set the threshold. This could mean setting the threshold as a percentage of the range between the minimum and maximum scores. The method is straightforward, but it can be sensitive to extreme score values.

Z-Score

Several other methods can be used to set the threshold, depending on the data. These include statistical techniques such as setting the threshold based on standard deviations from the mean, using quartiles of the data, or using machine learning techniques to dynamically adjust the threshold based on observed data.

Conclusion

Thresholding gives anomaly detection a clear boundary between normal and anomalous scores, which helps identify potential issues such as cyber threats or system errors. The choice of thresholding method depends on the use case and the characteristics of the data. Whatever method is used, the threshold needs to balance anomaly detection against the risk of false positives and false negatives.

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.

Intelligent Rate Limiting

2022-05-16T13:00:00+10:00

Rate limits protect web applications from clients making excessive requests. Peakhour.IO supports rate limits with flexible controls for selecting which clients are limited and which type of limit applies.

What kinds of attacks are stopped by rate limiting

When an application is protected with rate limiting, the main attack patterns are:

Brute force and enumeration attacks
Denial of Service (DoS) and Distributed Denial of Service (DDoS)
Site scraping
Vulnerability scanners

What else can rate limiting protect

Public APIs and authenticated APIs can be abused or misused. Sensible rate limit policies on these endpoints can reduce attack traffic and help maintain service availability. Rate limiting can protect:

APIs
Overzealous 'good bots'

How does it work?

Rate limiting focuses on a connecting client and their IP address. The following measures can be used to track client requests for rate limiting:

Concurrent connections
Connections per interval
Hits per interval
HTTP 4xx responses per interval
HTTP 5xx responses per interval
Custom criteria

How granular can rate limiting be?

Using wirefilter rules, rate limiting can identify clients from both the HTTP request and response, allowing rate limits to be separated by endpoint or behaviour. For example, the URL /api can be rate limited separately from the /login endpoint. Rate limits can also be set on response codes; for example, the endpoint /search can be protected from scraping by rate limiting clients with excessive 4xx response codes.

What types of criteria can be used to define rate limits?

Rate limits can include any information defined in an HTTP request and response, including:

IP address
URL
Query string
Headers
Response codes
GeoIP information such as ASN or country code
Parsed user agent information allowing different rules for search engines vs generic 'bots'
Metadata we make available from our BOT protection service

Defining your rate limits

Picking sensible rate limits is difficult without adequate analytics on how the web application is typically used. The Peakhour dashboard includes rate-based analytics to help with setup.

Peakhour's Application Security Platform combines high-performance delivery and cache capabilities with security controls for applications and APIs. It maintains caching performance while applying advanced threat protection. Contact our team to discuss how rate limiting can improve application performance and security posture.

Why Manage Bots?

2020-11-30T13:00:00+11:00

Modern sophisticated bad bots often work around traditional security controls. They disrupt websites, mobile applications, and APIs. Malicious bot tactics include scraping user and pricing data, creating fake accounts, running advertising click fraud, exhausting online inventories, and taking websites offline with automated DDoS attacks.

About one-quarter of all website traffic in 2019 originated from bad bots, an increase of 18 percent over 2018. Advanced persistent bots (APBs) made up seventy-five percent of that bad bot traffic as they attempted to evade detection by cycling through random IP addresses, using anonymous/residential proxies, and changing their identities (user agent). The industries hit hardest by bad bots in 2019 included financial services, education, ecommerce, and government as well as media and airlines.

“Bot attack campaigns have become big business for threat actors, and major organizations are now fighting to support legitimate users and prospects while keeping attackers out of online applications and services,” says Paula Musich, Research Director, Enterprise Management Associates.

Bots have moved from simple scripts to distributed networks of automated agents that can mimic human interactions with machine learning techniques. They can avoid detection by network security technologies that have not kept pace with the way automated agents now operate.

Reducing the damage from bad bots means using security countermeasures that detect automated traffic and make attacks uneconomic, not just visible.

Bot Countermeasure Best Practices:

The following bad bot countermeasure practices cover network security, machine learning, and behavioural analysis. The aim is to reduce the economic harm that malicious bots inflict on businesses and end-users.

Web Application Firewalls

Web Application Firewalls (WAF) are a common first line of defence that filter out harmful Layer 7 web application (HTTP) traffic using rules or policies that protect organisations against Distributed Denial of Service (DDoS) bot attacks. WAFs also protect against cross-site forgery, cross-site-scripting (XSS), file inclusion, and SQL injection attacks. A WAF is considered a reverse proxy that protects servers and can be deployed as an appliance, server plug‑in, or filter, and customised by application type or use case. WAF rules can be updated or changed based on the type of bot attack.

IP Tracking and Reputation

Sophisticated bots can be detected with network forensics by inspecting web traffic and assessing whether requests come from actual users or bad bots. Requests can be analysed using data sources including Tor/proxy IPs, IP addresses, IP geo-location information, ISP information, and IP owners. Additional sources for real-time and near-time malicious IP threat data can come from network data, CERTs, MITRE and cooperating competitors.

Client/Device Fingerprinting

Fingerprinting attempts to identify devices, including PCs, Internet of Things (IoT) devices, mobile devices and servers, using data attributes that create real-time risk profiles to stop bot attacks. Using web page access data, a bot detection fingerprinting engine generates unique fingerprints for each end-user device and checks them against bad bots that use evasion techniques, including dynamic IP addresses and anonymous web proxies.

Machine Learning

Artificial Intelligence (AI) and machine learning algorithms are increasingly used to analyse malicious bot activity and make mitigation recommendations using data from sources such as user activity history, behavioural patterns and meta-data. Machine learning can use custom-tailored algorithms to target bots and iteratively process user data and identities to discern emerging bot attack patterns from very large amounts of real-time information.

Tarpitting

Tarpitting is a bot countermeasure that delays and slows down incoming malicious traffic from suspect connections. The technique is used to increase the financial and resource costs of bot attacks in an attempt to discourage malicious actors. Bad bot tar pits can delay bot request responses or take the bad bot IP address attack source offline completely. Innovative tarpitting techniques include requiring bad bots to solve computationally complex maths challenges to access resources or websites, thereby slowing down or stopping bot activity.

User Behavior Analysis

User interaction behaviour and identifying characteristics on a web page or mobile app differ from the behaviour of an automated malicious bot. Factors such as number of pages visited per session, time spent on each web page or within a mobile app and repeat visit frequency all help differentiate authentic users from bad bots. Defeating bad bots using Behavior Analysis involves creating a user model for individual sites with historical visitor data, then checking for anomalies that may indicate bad bot activity.

Intent-based Deep Behavior Analysis (IDBA)

Compared with Behavior Analysis, Intent-based Deep Behavior Analysis (IDBA) conducts behavioural analysis at the user intent level rather than the commonly used interaction-based behaviour analysis. IDBA consists of intent encoding, intent analysis, and adaptive learning. It also employs machine learning techniques to detect bad bots emulating on-site human behaviour interactions. Bad bot mitigation techniques include limiting attempts on login pages, web authentication pages and API call authentication pages.

Rate Limiting

Rate Limiting mitigates bad bots and DDoS attacks by restricting the amount of incoming traffic accepted by specific applications and API endpoints using pre-defined bandwidth limitation policies. Web applications, GET versus POST requests, APIs that receive queries, and login credentials can all be blocked if clients, IP addresses or IP and user-agent pairs violate Rate Limiting rules. Intellectual property scraping can also be protected by Rate Limiting policies that restrict repeated image or digital downloads.

Javascript Injection

JavaScript Injection techniques can help mitigate bad bot attacks in several ways. Scripts can be placed into web applications that “fingerprint” a user’s browser to distinguish humans versus bad bots emulating “human-like” mouse movements, keystrokes or clicks. Fingerprinting detection may also involve user agent identification, HTML5 canvas and audio fingerprinting, and protocol-level fingerprinting with TLS and HTTP2. JavaScript combined with browser cookies can also be used to identify anomalous behaviour from unwanted traffic or bad bots trending over time.

ANYCast DDoS Mitigation

Anycast is an IP addressing method that routes incoming traffic requests to the nearest location or “node.” Using ANYCast for selective routing enables network load resilience against DDoS attacks by routing high traffic across multiple servers and data centres. This prevents network resources from becoming overwhelmed with malicious or irrelevant traffic.

Alternative Content Serving

Serving Alternate and Cached Content when a bad bot is detected gives organisations a way to mislead bots without blocking them altogether. For instance, e-commerce sites may fool price scraping bots by serving alternative web pages that look like legitimate pages but with higher prices. Serving Cached Content when a bot is detected also minimises load on servers without affecting site performance.

Challenges

Requests from suspected bots can be redirected to Challenges or puzzles such as a CAPTCHA, also known as a Completely Automated Public Turing test, to help identify a bad bot versus a human. Online puzzles, such as letter matching, are easy for humans to solve but difficult for automated bots. reCAPTCHA, offered free from Google, is an advanced version of CAPTCHA puzzles that require users to identify text from real-world images such as street address signs, printed books or text from paper newspapers.

Final Thoughts

Bad bots hijack user accounts, create fake accounts, scrape websites for data and personal information, flood websites with traffic through automated distributed denial of service attacks and attack public-facing APIs using constantly changing techniques. They hide behind dynamic IP addresses, change their attack signatures, mimic human behaviours, and take over vast networks of hosts and IoT devices, creating zombie machines that distribute malware across the internet. Countermeasures ranging from Web Application Firewalls to sophisticated Machine Learning algorithms form an organisation's primary line of defence against bad bots.

Application Performance Optimisation

2020-09-12T13:00:00+10:00

Website performance testing is most useful when it explains where a request lost time. A single score can tell you that a page is slow, but it rarely tells the site team what to change next. The better starting point is the request path: where the visitor is, where the origin is, whether the response was cached, how much the browser had to download, and what work blocked rendering or interaction.

This article is a primer for that diagnosis. Start with a representative page, test it from a location that matches your users, then read the evidence in order.

Start With the First Request

The browser cannot render a page until it receives the main HTML document. That first request includes DNS lookup, TCP connection setup, TLS negotiation, any redirect, cache handling, origin processing, and the first byte coming back. When the origin is far away, latency compounds. Peakhour's performance material uses simple Australian examples: Sydney to Melbourne is about 5 ms one way, Sydney to Perth about 25 ms, and Sydney to San Francisco about 75 ms. Those numbers become larger when a page load needs several round trips.

This is why the main document matters in WebPageTest. In one Peakhour example, the main HTML document took 149 ms, which is fast. Many sites take 2 to 5 seconds before the browser receives that document. If the main response is already slow, the page has little chance of a good Largest Contentful Paint because the browser has not yet discovered the resources needed to paint the largest content.

Cache state is part of the same first request. A cache hit at the edge should look different from a miss that forwards to origin. Headers such as Cache-Status can show hit, miss, TTL, stored state, cache key, and collapsed request behaviour. Without that evidence, teams often guess whether a slow page is caused by the CDN, the origin, the application, or a cache-bypass rule.

Use WebPageTest for the Waterfall

WebPageTest is useful because it loads the page in a real browser and lets you choose test locations and connection profiles. That matters for Australian sites because a test from the wrong continent can make a local problem look worse or hide a regional problem from view.

The waterfall is the main working view. Read the first rows before looking at the rest of the page. A redirect on the first request adds delay before the useful page is even requested. Long DNS, connect, or TLS blocks point to connection setup or third-party domains. A long wait on the main document points to cache miss, origin processing, or backend work. Large downloads point to page weight. Red rows show broken requests, and the domain view shows how many external services the browser had to contact.

The filmstrip is just as important. It shows what the user saw while the waterfall was happening. If the HTML arrived quickly but the filmstrip stayed blank, the issue may be render-blocking CSS, JavaScript, fonts, or a hero image. If the page starts to render quickly but then jumps, you are looking at layout stability, not just network speed.

Use Lighthouse for Browser Work

Lighthouse is good at surfacing work inside the browser. It runs a controlled test, reports Core Web Vitals-related metrics, and lists opportunities such as eliminating render-blocking resources, reducing unused CSS, deferring JavaScript, compressing assets, and reducing main-thread work.

Treat the score as a prompt, not a verdict. Lighthouse scores can vary between runs because the local CPU, network conditions, and server response can vary. The useful part is the diagnostics. If Lighthouse points to a font, a theme stylesheet, or a third-party script that delays rendering, compare that with the WebPageTest waterfall and filmstrip. If both tools point to the same resource, you have a stronger case for change.

Connect Metrics to Causes

Core Web Vitals are easier to act on when each metric is tied to the part of the path it describes.

Symptom	Where to look	Likely next question
High TTFB	WebPageTest first row, cache headers, origin logs	Did the request hit cache, miss to origin, or wait on application work?
Slow FCP	Waterfall, filmstrip, render-blocking resources	Did HTML, CSS, or synchronous JavaScript stop the first paint?
Slow LCP	Main document timing, hero media, image weight	Was the largest element discovered and delivered early enough?
High CLS	Filmstrip, image dimensions, injected banners, fonts	Did content move after the visitor started reading?
Poor INP	Lighthouse main-thread diagnostics, third-party scripts	Is JavaScript delaying the next paint after interaction?
High page weight	WebPageTest content breakdown	Are images, JavaScript, fonts, or unused assets carrying the load?
Too many domains	WebPageTest domains view	Which third-party services are adding connection setup and blocking work?
Unclear cache behaviour	`Cache-Status`, CDN analytics, debug headers	Which paths are hits, misses, bypasses, stale responses, or collapsed misses?

This table is not a checklist to run forever. It is a triage map. Pick the symptom that matches the page, then follow the evidence to the next request-path decision.

Diagnose the Common Failures

Latency is the first failure to rule in or out. If the origin is in the United States and most customers are in Australia, the page can lose time before WordPress, Magento, Drupal, or a custom application has done any work. Edge caching helps when the response is safe to reuse, because the first byte can come from a location closer to the visitor.

Page weight is the next obvious drag. WebPageTest's content breakdown shows whether images, JavaScript, CSS, fonts, or other assets dominate the transfer. Unoptimised images are common, especially on CMS and ecommerce sites. Image variants in AVIF or WebP, responsive sizes, compression, and stable dimensions can improve both download time and LCP.

Render-blocking resources explain why a page can download quickly and still look blank. CSS and synchronous JavaScript in the head can stop the browser from painting. Large theme bundles and plugin scripts often include code that is not needed on the current page. The fix might be removing unused files, deferring non-critical scripts, splitting code by route, self-hosting critical third-party resources, or using preconnect only where the first view depends on a third-party domain.

Third-party domains need a sober review. Analytics, marketing tags, chat widgets, social embeds, payment scripts, and fonts can all be legitimate. They can also add DNS, TCP, TLS, download, parsing, and main-thread cost. If a third-party script is not needed for the first view, it should not block the first view.

Where Peakhour Evidence Fits

Peakhour performance work should show both user experience and origin relief. For caching, that means hit ratio, miss causes, Cache-Status, purge state, cache keys, shielded misses, collapsed requests, and origin fetch volume. For images, it means original size, transformed size, selected format, responsive variant, and cache hit state. For Core Web Vitals, it means LCP, CLS, INP, TTFB, page weight, and the same page tested before and after changes.

Security belongs in the performance review when it changes the request path. Bot filtering, WAF rules, rate limits, and login protection can reduce origin load by stopping abusive or noisy traffic before PHP, database, search, or API work begins. They can also create friction if rules are too broad. Measure the edge decision, the latency, the origin effect, and the false-positive risk. Do not treat "security enabled" as a generic performance story.

Good performance testing ends with a specific change to validate: cache this public route, purge it by tag, move this script later, replace this image variant, reduce these third-party domains, protect this login path, or investigate this slow origin query. Then run the same test again from the same location and compare the evidence.

Instant Alerts

2019-05-31T13:00:00+10:00

We've introduced Instant Alerts, an optional service that notifies you when there is a problem with your site. You can specify the email addresses and/or mobile numbers that should receive the alerts.

At the moment you can receive alerts when your origin server:

Times out
Cannot be reached at all
Returns an error

To avoid repeated messages, each alert has a cooldown limit you can set from 30 minutes to 24 hours.

If you're using a service like Pingdom to check that your site is up, you probably will want to enable Instant Alerts. Services like Pingdom might be served pages from our cache while your origin server is actually down.