Peakhour.IO

An Operating Model for API and Account Protection

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

API and account protection is often discussed as a stack of controls: authentication, MFA, bot detection, rate limiting, WAF rules, logging, fraud checks, and incident response. Those controls matter, but the missing piece is usually the operating model.

Who owns the route? Which signals are trusted? What action should happen before origin? What evidence is preserved? When does a rule move from monitor to enforce? How does the team know whether it helped or hurt?

Without those answers, account protection becomes a set of disconnected gates. The login page has one policy. The mobile API has another. Password reset is reviewed only after support tickets appear. Rate limits are tuned during incidents, then left in place because nobody wants to touch them.

A better model is route first, signal second, action third, evidence always.

1. Map the Routes That Matter

Start with the account and API routes that change trust, money, access, or user state. Do not begin with every endpoint in the estate. Begin with the flows where abuse has a clear consequence.

Typical routes include:

Login and token issue.
Token refresh.
Password reset start and completion.
MFA enrolment and recovery.
New account registration.
Email, phone, address, and password changes.
Stored payment, wallet, loyalty, or checkout actions.
High-volume read APIs.
Partner or machine-to-machine API access.

For each route, record the owner, normal traffic shape, expected clients, authentication method, downstream cost, and likely abuse case. A login endpoint and a product search endpoint can both be APIs, but they should not have the same policy.

This is where traffic control becomes part of account security. The route tells the edge what kind of decision is being made: allow, challenge, throttle, block, route, cache, or log.

2. Classify the Signals Before Choosing the Action

A useful account decision combines several signal families:

Identity and token state.
Credential exposure or failed-login history.
Residential proxy, VPN, hosting, mobile, or office network context.
IP reputation and ASN behaviour.
Client, browser, TLS, or HTTP fingerprint.
Request rate and response codes.
Route sequence and session behaviour.
Account event context, such as reset, recovery, or profile change.

The mistake is treating any one signal as the whole answer. A residential proxy signal on a low-risk route may only need monitoring. The same signal on a password reset route, with repeated failures and a first-seen client, should be handled differently.

This is the job of contextual security: apply friction where the request context justifies it, while keeping trusted users on the shortest path.

3. Choose Actions That Match Route Risk

Not every suspicious request should be blocked. Blocking is one action, and it should be available, but account protection needs a wider set of responses.

Common actions include:

Allow and record.
Log only.
Add to a rate-limit zone.
Throttle or return a 429.
Require a challenge.
Require step-up authentication.
Deny the request.
Route to a safer path.
Alert security or support.

Advanced rate limiting is useful here because the counter does not have to be the source IP. For API traffic, a policy may key on an Authorization header, token, fingerprint, route, cookie, response code, or a combination of fields. For account flows, response-aware limits can count failed logins or suspicious reset attempts, then apply a stricter rule on the next request.

This matters for distributed abuse. If attackers rotate through residential proxies, a simple IP counter sees fragments. A route-aware, signal-aware policy can still recognise the behaviour that matters.

4. Preserve Evidence While the Control Runs

A security decision that cannot be explained will be difficult to tune and harder to defend internally. Teams need to know why a request was allowed, challenged, throttled, or blocked.

The evidence should keep the request, route, signal, policy, action, and outcome together. That includes useful fields such as the matched route, rate-limit zone, proxy or IP classification, fingerprint, response code, decision reason, and timestamp.

Log forwarding is part of the operating model, not an afterthought. If the evidence only exists in a dashboard screenshot or a short-lived edge event, support, fraud, platform, and security teams will end up reconstructing incidents by hand. Forwarded logs should carry enough context into the SIEM, object store, or observability pipeline for investigation and tuning.

This also protects the rollout. When a control is in monitor mode, evidence shows who would have been affected. When it is enforced, evidence shows who was affected and why.

5. Tune From Monitor to Enforce

The safest way to deploy account and API controls is usually staged:

Monitor the route and collect baseline evidence.
Add low-friction actions, such as logging or soft thresholds.
Review false positives, support impact, and route ownership.
Enforce on the clearest abuse patterns.
Expand enforcement only where evidence supports it.
Keep rollback and emergency tightening paths documented.

This avoids two common failures. The first is leaving controls in monitor mode forever because nobody owns the decision to enforce. The second is enforcing too broadly and creating customer friction that causes the business to bypass the control.

A staged model gives security, platform, product, and support teams a shared language. The rule is not "on" or "off". It has a route, a risk case, an action, evidence, and a review cycle.

6. Fit the Model to the Edge You Already Run

Some teams want Peakhour as the active application edge. Others need to keep Cloudflare, Fastly, CloudFront, another CDN, or an existing hosting edge in place. That deployment choice should not change the operating principle.

The goal is still to classify request context before origin, apply the right action, and preserve evidence. Bring Your Own Edge matters because many organisations cannot redesign delivery just to improve account protection. They need a control path that fits the architecture they already operate.

The practical test is straightforward: can the team explain what happened to a sensitive account or API request without guessing?

If the answer is no, the next step is not another generic control. It is an operating model: map the route, classify the signals, choose the action, preserve the evidence, and tune the policy from observed behaviour.

That is how API and account protection becomes something the organisation can run, not just something it bought.

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.

The Real Cost of Breached Credentials

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

The cost of breached credentials is usually counted in the wrong place.

When an organisation suffers a data breach, the obvious costs are incident response, legal work, notification, customer support, remediation, and regulatory attention. Those costs matter. IBM's 2025 Cost of a Data Breach Report puts the global average breach cost at about USD 4.4 million. IBM's data breach explainer also says stolen or compromised credentials were one of the top five initial attack vectors in the 2025 report, accounting for 10% of breaches and taking up to 186 days to identify.

But that is only the first bill.

Once usernames and passwords leave the original system, they do not stay attached to the original incident. They are copied, sorted, bundled, tested, resold, and mixed with other personal data. Another company's breach becomes your login problem. A password reused somewhere else becomes your fraud queue, your support call, your chargeback, your locked account, your angry customer, and your next security review.

That is the real cost of breached credentials: not just the breach, but the long tail of account abuse that follows.

The Roundup: Breaches Are Feeding Account Abuse

The numbers are not subtle.

The Identity Theft Resource Center's 2025 Annual Data Breach Report tracked 3,322 data compromises in 2025, a record high and a 79% increase over five years. The same report found that 70% of breach notices did not include attack information, making it harder for consumers and downstream businesses to understand what risk they now carry.

The ITRC also introduced a category it calls Previously Compromised Data: old stolen data that is repackaged and recirculated. In the full report, the ITRC says there were four major PCD releases in 2025, including two incidents involving roughly 16 billion records with no known notices. Its warning is the important part: while this may not be "new" stolen data, aggregation makes it highly effective for credential stuffing and account takeover attacks.

That matches the operational pattern security teams see on login endpoints. OWASP describes credential stuffing as automated testing of stolen username and password pairs against login forms. The reason it works is boring and persistent: people reuse passwords. Attackers do not need to breach your site if a customer has already reused a working credential somewhere else.

For Australian organisations, the local signals are just as relevant. The OAIC received 532 Notifiable Data Breach notifications between January and June 2025, with malicious or criminal attacks remaining the largest source of notifications. ASD's Annual Cyber Threat Report 2024-25 notes that its credential exposure notification process proactively sent 9,587 credential exposure events to about 220 organisations between 19 November 2024 and 30 June 2025.

None of that means every fraud loss starts with a reused password. It does mean credential exposure is part of the operating environment. Attackers have supply, tooling, proxy infrastructure, and plenty of places to turn account access into money.

The FBI's 2025 IC3 report gives useful context for that monetisation path. Cyber-enabled fraud accounted for 452,868 complaints and USD 17.697 billion in reported losses. Those losses include many crime types, not just credential stuffing, but the transaction paths are familiar to anyone dealing with account abuse: wire and ACH transfers, cards, peer-to-peer transfers, prepaid and gift cards, and cryptocurrency.

Where the Cost Actually Lands

A breached credential is cheap for the attacker and expensive for everyone else.

The first cost is detection. A login using the right username and password does not automatically look malicious. If the attacker spreads attempts across residential proxy infrastructure, uses one attempt per account, or targets mobile API endpoints directly, simple IP-based rate limits may not see the pattern. Peakhour has written about this in The Australian epidemic of Account Takeover attacks and in Credential Stuffing Does Not Stop at the Login Form.

The second cost is fraud. Once a credential works, the attacker looks for value: stored cards, gift cards, loyalty points, refunds, store credit, subscription changes, delivery addresses, and saved payment flows. This is why account takeover is not just an authentication problem. The expensive moment may be checkout, not login.

The third cost is support. Customers do not usually know whether the original password leak happened somewhere else. They know their account was used, their card was charged, their loyalty balance disappeared, or their email address changed. The business still has to handle the support ticket, freeze the account, unwind the transaction, review the evidence, and explain what happened.

The fourth cost is trust. We have covered this before in The Cost of Credential Stuffing: the reputational damage is practical. Customers see refunds, account locks, suspicious messages, and public complaints. Even if the business was not the source of the original breach, it becomes the place where the harm is felt.

The fifth cost is friction. If the only response is to challenge everyone, the business pays through abandonment and customer frustration. If the response is too soft, the business pays through fraud. The work is to apply friction where the evidence justifies it.

You Do Not Need Surveillance to Secure Accounts

There is a bad version of account protection that tries to identify people everywhere they go. That is not necessary, and it is not the right model for this problem.

Credential abuse defence should be scoped to the account security decision in front of you. Is this login using a known exposed credential pair? Is the session coming from suspicious infrastructure? Is it a first-seen device for the account? Is it trying to change email, reset the password, add a payout method, redeem stored value, or check out with saved payment details? Did the same client pattern just test many accounts?

Those questions can be answered with security-specific signals, not advertising-style tracking. Hash the credential check. Treat fingerprints as evidence, not identity. Keep the evidence tied to the protected account and request path. Use network, device, route, behaviour, and credential-risk context to decide whether to allow, step up, throttle, block, or review. Do not build a cross-site identity graph when the job is to stop account abuse on your own service.

That distinction matters. Users should not have to trade privacy for basic account security. Businesses also do not need to choose between doing nothing and adding blanket friction. Contextual security is useful because it lets the response match the risk.

What Teams Should Measure

If breached credentials are a business cost, measure them like one.

Useful measures include:

How many login attempts match known breached credential pairs.
How many breached-credential attempts result in a successful login.
Which routes see the risk: login, password reset, email change, stored-card checkout, gift card redemption, account recovery, mobile API, partner API, or admin access.
How often high-risk sessions move from login into sensitive account actions.
Which signals appear together: breached credential, residential proxy, first-seen device, unusual geography, repeated failure, rapid checkout, or recovery-flow pressure.
How many support tickets, refunds, chargebacks, account locks, and fraud reviews are linked to account takeover.
How many controls create customer friction, and whether that friction is landing on risky sessions or ordinary customers.

This does not need to be perfect on day one. The important step is to stop treating credential stuffing as a vague security category and start treating it as an observable account-risk workflow.

The Control Pattern

The control pattern is layered.

Start with breached credential scanning so reused or exposed credentials are visible at login. Feed that signal into account takeover prevention rather than treating it as a standalone report. Add bot management and advanced rate limiting so automation and distributed testing are harder to run at scale. Use residential proxy detection as a risk signal, especially where attackers are trying to make automated traffic look like normal customer traffic.

Then carry the risk forward after login.

A low-risk page view and a saved-card checkout should not inherit the same level of trust just because the password worked. A session that begins with a breached credential match, comes through suspicious infrastructure, and immediately changes the email address or redeems stored value deserves a different response from a known customer browsing order history.

The response can be graduated:

Log low-risk activity for visibility.
Tighten rate limits on suspicious automation.
Require step-up verification before sensitive account changes.
Hold or review risky transactions.
Notify the customer when high-risk account changes are attempted.
Block sessions when the evidence is strong enough.

That is how breached credential data becomes useful. It is not a panic button. It is a signal that helps decide when trust should be earned again.

The Practical Takeaway

Breached credentials are not only a breach-response issue. They are an account protection issue, a fraud issue, a support issue, and a customer trust issue.

The original breach may have happened somewhere else. The cost can still land on your login form, your checkout, your API, and your support team.

The goal is not to make every login difficult. The goal is to make stolen credentials harder to turn into account control, money movement, stored-value abuse, or customer harm.

That starts by making credential risk visible, connecting it to session and route context, and applying proportionate controls where the cost would otherwise show up.

Credential Stuffing Does Not Stop at the Login Form

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

Credential stuffing is usually described as a login problem. An attacker takes breached username and password pairs, tests them against a site, and tries to find accounts where people reused passwords.

That description is accurate, but incomplete. The login is only the first gate. The real damage often happens in the flows that follow a successful login: password reset, email change, saved cards, loyalty balances, gift cards, account recovery, address changes, and checkout.

If account protection only watches the login form, it can miss the part of the attack that matters most to the business.

A successful credential stuffing attempt does not always look dramatic. The attacker may have valid credentials. They may come through residential proxy infrastructure. They may spread attempts across many IP addresses. They may slow the attack down to stay below simple thresholds. If the site treats a valid username and password as the end of the risk decision, the attacker inherits whatever the account can do.

That is why account takeover prevention needs to cover account actions, not just authentication.

The Attack Continues After the Password Works

Once an attacker is inside an account, they usually want persistence, value, or both.

A password reset or password change can lock the real customer out. An email change can move alerts, receipts, and recovery messages away from the owner. A phone number change can weaken later verification. A new shipping address can redirect physical goods. Stored payment methods can turn account access into immediate fraud. Gift cards, store credits, loyalty points, and refunds can be easier to monetise than a card transaction.

Checkout is often where the compromise becomes visible, but the risk builds earlier. A login from unfamiliar infrastructure followed by a profile change, then a saved-card purchase, is different from a returning customer browsing previous orders. A dormant account that suddenly redeems gift cards, changes email, and ships to a new address deserves more scrutiny than an ordinary login.

These flows are also common in APIs. Mobile apps, single-page applications, partner integrations, and checkout backends expose account actions through endpoints that may not share the same controls as the web login page. Attackers do not care whether the valuable step is behind /login, /api/account/email, or /checkout/payment. They follow the path that works.

Breached Credentials Are a Risk Signal

Breached credential checks are useful because they add context before the account is fully trusted. If a credential pair is known to have appeared in a breach, the site can treat the session differently from the start.

That does not mean every breached credential attempt should be handled the same way. A user may be genuinely logging in with a reused password. An attacker may be testing a combo list. A customer may be returning after a long period away. The point is to make the risk visible and carry it through the session.

Peakhour has written before about managing breached credential usage. The practical lesson is that credential risk should feed the wider account protection decision. A breached credential signal should be considered alongside client evidence, network context, request rate, route sensitivity, behaviour, and the action being attempted.

A low-risk page view and a stored-card checkout should not inherit the same confidence just because both follow a successful login.

MFA Helps, But It Does Not Close Every Path

Multi-factor authentication remains useful. It can stop many direct account takeover attempts and raise the cost of abuse. But MFA is not a complete defence when attackers use social engineering, session theft, weak recovery flows, trusted devices, or post-login actions that do not require step-up verification.

The better pattern is adaptive control. Let the login succeed when the evidence is low risk. Step up when the action matters. Ask for stronger verification before changing the email address, adding a new payout method, redeeming a stored balance, or checking out with saved payment details from an unfamiliar context.

This is not about adding friction everywhere. It is about reserving friction for the points where compromise turns into loss.

What to Monitor After Login

The useful signals are operational and specific:

Credential risk at login, including known breached username and password pairs.
New client, browser, or network evidence on an existing account.
Password reset, password change, email change, and phone change attempts.
New shipping addresses, payment method changes, stored-card use, gift card redemption, and loyalty balance activity.
Sudden changes in behaviour, such as rapid checkout after login or repeated account recovery attempts.
API routes that perform sensitive account actions without the same scrutiny as browser flows.

The response should match the confidence and consequence. Some events only need logging. Some need tighter rate limits. Some need a browser challenge, MFA step-up, temporary hold, customer notification, or review.

Credential stuffing defence is not finished when a password works or fails. The more useful question is: what does this session try to do next, and does the evidence justify trusting it?

For account protection, that is the line that matters.

Fingerprints Are Evidence, Not Identity

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

The word "fingerprint" can create the wrong expectation.

In security, a browser or network fingerprint is not the same as a human fingerprint. It does not prove who a person is. It does not remove uncertainty. It should not be treated as a permanent identity for a customer.

A fingerprint is evidence. Sometimes it is strong evidence. Sometimes it is weak, common, stale, or deliberately manipulated. Its value comes from how it is combined with route, behaviour, account state, network context, credential risk, and the action being requested.

That distinction is more than wording. It affects how security teams design controls, explain decisions, and avoid overblocking legitimate users.

What Network Fingerprints Can Tell You

Network fingerprinting compares connection and protocol evidence. TCP behaviour, TLS handshakes, JA3 or JA4-style representations, HTTP/2 settings, header shape, MTU, proxy indicators, ASN, and path characteristics can all help classify the client or infrastructure behind a request.

That can be useful during credential stuffing, scraping, scanning, API abuse, or Layer 7 attack pressure. Attackers may rotate IP addresses, but parts of the client stack or automation framework can remain consistent. Grouping requests by network evidence can make rate limiting, bot detection, and investigation more precise than IP-only rules.

But the fingerprint is still not identity.

Common browsers can share similar network shapes. Mobile networks and carrier-grade NAT can make unrelated users appear close together. VPNs and residential proxies can distort source context. Browser and library updates can change fingerprints overnight. Hashing can make signals portable while hiding useful detail. Attack tools can also try to imitate normal clients.

The right conclusion from a suspicious network fingerprint is not "we know who this is". It is "this request deserves a different level of confidence".

What Browser Fingerprints Can Add

Browser fingerprinting adds evidence from the application layer and, where appropriate, browser-side checks. Headers, client hints, JavaScript-visible properties, rendering behaviour, storage behaviour, timezone, language, permissions, and API availability can help decide whether a request looks like the browser it claims to be.

This matters because many attacks try to borrow the appearance of ordinary browser traffic. Automation frameworks, emulators, headless browsers, anti-detect browsers, and scripted API clients can all present a user-agent string that looks plausible. Browser evidence helps compare the claim with the rest of the request.

Again, the useful output is confidence, not identity. A browser fingerprint might support a challenge. It might support a lower rate limit. It might explain why a session changing an email address needs step-up verification. It might help bot management separate obvious automation from normal traffic.

It should not become a claim that one technical pattern equals one person.

The Comparison Matters

Peakhour's page on browser fingerprinting vs network fingerprinting makes the operational split clear. Network fingerprints usually come from passive connection and protocol evidence. Browser fingerprints often involve request and browser-side evidence. They answer related but different questions.

A strong decision often needs both.

A request claiming to be a normal browser should look broadly consistent across TLS, HTTP/2, headers, JavaScript-visible browser properties, proxy context, route behaviour, and account history. If the browser looks normal but the network path resembles a known automation cluster, that is useful. If the network path looks ordinary but the browser evidence is inconsistent or missing on a sensitive route, that is useful too.

The mismatch is the signal. The response still depends on consequence.

A suspicious request to a public asset route might only need logging. The same evidence on login, password reset, stored-card checkout, account email change, admin access, or an expensive API route may justify a challenge, tighter limit, temporary hold, or review.

How to Use Fingerprints Responsibly

Fingerprints work best when they are attached to an explainable decision. A security event should show the route, account or token context where relevant, source network evidence, browser evidence, policy action, response code, and review outcome. That gives operators a way to understand and correct decisions.

Peakhour's guide to network fingerprint signals and security decisions frames the choices properly: allow, log, challenge, rate limit, block, or review. A fingerprint should help choose among those actions. It should not replace judgement.

Responsible use also means accepting uncertainty. Fingerprints collide. They drift. They can be spoofed. Some privacy tools intentionally reduce or alter browser signals. Some legitimate users have unusual configurations. Some high-risk requests have only partial evidence.

That uncertainty does not make fingerprints useless. It means they should be one layer in a wider control set.

For account and API security, the practical question is not "can this fingerprint identify a person?" It is "does this evidence change the confidence we should place in this request?"

If the answer is yes, use it carefully. Increase scrutiny on sensitive actions. Reduce friction where evidence is clean. Preserve enough context for review. Avoid pretending that a technical fingerprint is a human identity.

That is the more accurate model, and it leads to better security decisions.

Account Security Without Tracking People

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

Account security needs evidence. A login request is not just a username and password; it has a route, client context, browser behaviour, network path, timing, session history, credential risk, and follow-on actions. Without some of that context, defenders are left with blunt controls: block too much, challenge everyone, or trust too easily.

The privacy problem starts when security teams confuse evidence with identity.

A risk signal should help answer a narrow operational question: should this login, password reset, email change, API call, or checkout step be allowed, challenged, rate limited, blocked, logged, or reviewed? It should not become a general-purpose profile of a person.

That distinction matters. Good contextual security is not surveillance dressed up as account protection. It is purpose-bound telemetry used to make proportionate security decisions.

Minimise the Signal Set

Security teams should start with the action they are protecting.

A login attempt may need credential risk, source network context, browser consistency, known client status, failed-attempt history, and session age. A password reset may need different evidence. A checkout using stored payment details may need another set again. There is rarely a good reason to collect every possible signal for every route.

This is especially important with browser and device evidence. Browser fingerprinting can include headers, client hints, JavaScript-visible properties, rendering behaviour, storage behaviour, timezone, language, and other consistency checks. Those signals can be useful for detecting automation, anti-detect browsers, session abuse, and high-risk account changes. They can also be privacy-sensitive if collected broadly or retained without a clear purpose.

The practical standard should be simple: collect what is needed for the account defence decision, attach it to that decision, and avoid turning uniqueness into the goal.

Use Evidence Over Identity

A security system does not need to know who a person "really" is to make a better login decision. It often only needs to know whether the request looks consistent with the account, route, browser, network path, and recent behaviour.

That is where verified browser trust fits. The point is not to label a human being. The point is to decide whether a browser-like request has returned enough trustworthy evidence to proceed on a sensitive path. If the evidence is weak, the system can choose a proportionate response: log, challenge, rate limit, step up authentication, or send the event for review.

Network evidence should be handled the same way. Network fingerprint signals can help distinguish ordinary browser traffic from automation, proxy paths, unusual client stacks, or inconsistent request shapes. But a network signal is not a person. It is one piece of evidence attached to a request.

That framing reduces overreach. It also improves operations because decisions remain reviewable. If a customer is challenged, support and security teams should be able to see the route, risk signals, and policy reason without needing a vague black-box identity claim.

Be Careful With Behavioural Analytics

Behavioural analytics can help detect account compromise, especially when a session changes sharply from normal account usage. A customer who normally logs in from one region and browses slowly may deserve extra scrutiny if the same account suddenly logs in from unfamiliar infrastructure, changes email, redeems stored value, and checks out quickly.

But behavioural systems have limits.

Some users are sporadic. Some travel. Some use privacy tools. Some share devices. Some change browsers or phones. Some only visit when there is a problem. If there is not enough history, the system should admit that uncertainty rather than pretending the baseline is stronger than it is.

That is where adaptive security is useful. Low-confidence evidence does not always justify a hard block. It might justify logging, a lower rate limit, a step-up challenge on a sensitive action, or a temporary hold on a risky change.

The aim is not perfect recognition. It is better decision-making under uncertainty.

Make Retention and Purpose Part of the Design

Privacy-respecting account security is not only about which signals are collected. It is also about how long they are kept, where they are used, and who can inspect them.

Useful practices include:

Tie telemetry to account defence purposes such as login risk, bot detection, account recovery, checkout abuse, and API misuse.
Prefer route-specific evidence over broad user profiling.
Keep raw signals only where they are needed for detection, audit, or investigation.
Store decision evidence in a way operators can review.
Avoid using security telemetry for unrelated marketing or behavioural targeting.
Tune controls so low-risk users are not repeatedly challenged without cause.

Peakhour should not pretend that account security can happen with no fingerprints, no telemetry, and no judgement. Modern attacks abuse valid credentials, residential proxy paths, automation frameworks, API routes, and post-login workflows. Defenders need evidence.

The privacy-respecting position is narrower and stronger: collect the right evidence for the security decision, minimise it, keep it purpose-bound, and treat fingerprints as confidence signals rather than personal identity.

That is how account security can become safer without turning every login into tracking for its own sake.

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.

Price Transparency Is Now a Data Access Problem

2026-05-18T00:00:00+10:00

Australia's supermarket pricing debate can look like a consumer pricing story.

For digital teams, it is also a bot and API protection story.

The ACCC's final supermarket inquiry recommended that ALDI, Coles, and Woolworths publish prices on their websites. It also recommended that Coles and Woolworths make dynamic price APIs available for third-party comparison tools.

Then, on 18 May 2026, Guardian Australia reported on CW Scanner data about Coles and Woolworths promotion patterns. For digital teams, the operational detail is this: the report said CW Scanner's operator stated the service was not scraping, and instead used the supermarkets' website application programming interfaces.

That does not settle questions about permission, terms of use, supermarket approval, or the status of any specific API. It does make the practical problem sharper.

Price transparency increasingly depends on automated access to current data.

Every automated request still needs a decision.

APIs do not remove the bot problem

It is tempting to treat an API as the clean alternative to scraping. Sometimes it is cleaner. A documented API can make access more predictable, auditable, and easier to govern than repeated extraction from product pages.

But an API is still an automation surface.

The same retailer or marketplace may need to support:

public product pages;
price, promotion, search, listing, catalogue, and inventory routes;
browser-backed application calls;
documented APIs and partner feeds;
comparison tools and public-interest services;
search engines, monitoring systems, and accessibility tooling;
unknown collectors rebuilding price, inventory, availability, or ticketing datasets outside the intended access model.

Some of that traffic is useful. Some is commercially necessary. Some is abusive. Much of it will not identify itself honestly.

So the question is not "should bots be blocked?"

The question is: can you tell intended automated access from uncontrolled extraction?

The decision needs evidence

A blanket "block all automation" position can break comparison services, partner integrations, search visibility, monitoring, accessibility tooling, and APIs that were built to be automated.

A blanket "allow everything" position can expose pricing, product, inventory, account, checkout, ticketing, and API paths to extraction and abuse.

The practical middle ground is governed automation:

publish the access you want to support;
recognise the clients and behaviours you expect;
validate API route, schema, method, authentication, and client context;
detect traffic that has drifted from the intended use;
keep decision logs so security, legal, product, and commercial teams can review what happened;
respond proportionately with allow, log, rate-limit, challenge, block, or review decisions.

That is where bot protection becomes more than a yes-or-no control.

It supplies the evidence behind each access decision.

Where Peakhour fits

Scraping protection should identify repeated extraction across product, price, search, listing, catalogue, article, inventory, and availability routes. The goal is not to stop every non-human request. It is to separate expected access from collectors rebuilding data outside the site's control.

API bot protection applies the same discipline to automated API clients. APIs exist to be automated. The risk comes from unknown clients, unexpected route combinations, credential abuse, endpoint enumeration, excessive request volume, and business-logic abuse that generic perimeter controls cannot explain.

Bot management turns request evidence into a decision: allow trusted traffic, log expected automated access, rate-limit noisy collectors, challenge uncertain sessions, block confirmed abuse, or send edge cases to review.

Verified browser trust adds a useful signal when browser-backed journeys are being automated or replayed. Headers and cookies can be copied, proxy networks can rotate, and automation can mimic ordinary navigation. Peakhour can challenge the browser path, verify that the expected evidence came back, and attach that witness to the wider decision record.

That browser signal does not, by itself, prove the user, device, or account is trustworthy. It helps the risk engine decide what to do alongside route, proxy, device, behaviour, credential, and API context.

Why this matters beyond supermarkets

The ACCC's 2024 proceedings against Coles and Woolworths were about alleged false or misleading price statements, not supermarket price regulation, collusion, or anti-competitive conduct. The ACCC announced on 14 May 2026 that the Federal Court found Coles made false or misleading representations in 13 of 14 agreed sample "Down Down" tickets, with penalties and other orders still to be determined. For Woolworths, the separate "Prices Dropped" proceeding was awaiting judgment at publication.

Those legal details matter, but they are not the Peakhour point.

The Peakhour point is operational: when transparency, comparison, availability, or fairness depends on current digital data, organisations need a control plane that can support the access they intend and limit the extraction they do not.

That pattern shows up in retail, marketplaces, ticketing, travel, financial services, media, and any platform where public pages, browser-backed calls, and APIs expose commercially valuable data. It also shows up in adjacent problems like account abuse, checkout abuse, ticket scalping, product scraping, distorted analytics, and inventory harvesting.

The organisations that handle this well will not treat every automated request as the same.

They will be the ones that know what access they intend to allow, what behaviour they intend to stop, and why.

Cloudflare outage proves Plan B depends on controlling DNS

2025-11-18T21:00:00+11:00

On Tuesday, 18 November 2025, Cloudflare’s own status page marked every major service—CDN, Firewall, WARP, Workers, and the dashboard—as degraded for most of the day while engineers worked through an internal control-plane failure. The timeline moved from “Investigating” at 11:48 UTC to “Monitoring” after 14:42 UTC, and the incident wasn’t officially resolved until 19:28 UTC. During the worst of it, Cloudflare disabled WARP in London, bot scores seesawed, and customers were told to wait while remediation continued.

Waiting was the only option for many teams because their Plan B lived behind the same dashboard that was timing out. The top comment on the Hacker News thread was a set of curl commands for moving domains off Cloudflare’s proxy edge. Admins were stuck in 2FA flows trying to fetch an API token, or searching for Terraform credentials so they could toggle a proxied flag. That is not a resilience strategy.

We learned this lesson the hard way—and wrote about it after the 2021 Fastly outage in How to have a Plan B. The rule still stands: the platform you are trying to leave cannot be the only place that can change where your DNS points.

Detect: understand what’s actually broken

Incidents like Tuesday’s change shape quickly. Cloudflare’s own feed showed different failure domains every 30 minutes: bot management, dashboard auth, Access, WARP. The first mile is impartial telemetry that tells you what your users feel, not what the provider thinks. At Peakhour we stream real user monitoring, synthetic checks, and control-plane health from multiple CDNs and DNS partners. That lets us distinguish “cache errors in Hong Kong” from “global auth outage” and choose the right lever.

Decide: keep DNS authority in neutral territory

When your domain delegation lives with agnostic providers—Route 53, NS1, Azure DNS, or the enterprise registrar your legal team already approved—you can make failover decisions without pleading with a failing control plane. Peakhour doesn’t replace those vendors; we orchestrate them. We set short-but-safe TTLs, keep secondary answers staged, and continuously audit API access so we can flip traffic with one signed request. The minute you outsource DNS authority to a proxy CDN, you have given up the control that makes Plan B possible.

Divert: run the playbook in minutes, not hours

A workable Plan B has three moves:

Pre-stage alternate edges. Your secondary CDN, origin, or transit provider must be in sync with the active one—certificates, cache rules, WAF policies, everything. We keep them hot by replaying production configs across vendors.
Wire DNS automation. We integrate with multiple third-party DNS APIs at once so we can update apex A/AAAA, flattened CNAMEs, and geo/latency rules in a single workflow. Because the automation lives off the impacted platform, we can execute even while Cloudflare’s dashboard is returning 500s.
Drill humans on the handoff. Our SOC sits in Sydney and Melbourne, but we cover global hours. During an incident we line up Slack/Teams bridges with your SREs, confirm business impact, and keep execs in the loop while traffic drains to the healthy provider.

With that in place we routinely hit sub-five-minute diversion times, including DNS propagation, because the decision, the tooling, and the people are ready before the outage hits.

What Peakhour brings to your Plan B

Independent authority, familiar vendors. We leverage multiple established DNS providers instead of locking you into ours. You keep your contracts; we bring the automation and guardrails.
Unified multi-CDN config. Cache rules, image optimisation, WAF, and routing policies stay aligned across providers so you don’t lose capabilities when you switch.
Real drills, not just runbooks. Quarterly failover exercises prove that certificates, APIs, and humans are ready. We share the post-mortems so your execs see clear RTO/RPO numbers.
People you can phone. 24×7 Australian-based engineers who know your stack and can execute the play while your own team communicates with customers.

Book a resilience review

If Tuesday exposed that your failover path still depends on your primary provider’s dashboard, book a 30-minute Resilience Review with Peakhour and we’ll:

Map who really controls your DNS today.
Identify the gaps between your primary and standby CDNs.
Outline the automations we can layer on top of your existing DNS and hosting vendors.

The output is a concrete Plan B, a drill schedule, and a team that can execute it the next time a global provider blinks.

The BOTS Act and the War on Ticket Scalping

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

For popular concerts and events, tickets can disappear in seconds. Often the competition is not just other fans, but ticket scalping bots built to buy faster than a human can, then push those tickets into secondary markets at heavily inflated prices. The United States introduced the Better Online Ticket Sales (BOTS) Act to address that conduct. Whether it is working is less clear. Recent investigations into Ticketmaster suggest enforcement is still catching up.

Understanding the BOTS Act

Enacted in 2016, the Better Online Ticket Sales (BOTS) Act is a U.S. federal law aimed at giving consumers a fairer chance when buying tickets online. The law makes it illegal to use software, or "bots," to bypass security measures on ticket-selling websites.

Specifically, the BOTS Act prohibits:

Circumventing a security measure, access control system, or other technological control used by a ticket issuer to enforce purchasing limits.
Using a bot to purchase tickets in excess of posted limits.
Selling tickets that were acquired in violation of these rules, if the seller knew or should have known they were obtained illegally.

The aim was to stop scalpers using automated tools to buy tickets in bulk, so fans had a fairer chance of purchasing tickets at face value.

Australia's Approach

Ticket scalping bots are not only a U.S. problem. Other countries have also used legislation to protect consumers. In Australia, the state of New South Wales (NSW) became the first to outlaw ticket bots in 2017.

The legislation introduced heavy penalties, with fines up to $110,000 for corporations using bots to snap up tickets. The law also went further than the US BOTS Act by capping ticket resale prices at no more than 10% above the original price. At the time, a representative from TEG, the owner of Australia's largest ticket seller Ticketek, stated that bots accounted for up to 70% of activity on their website, showing how widespread the problem had become.

Ticketmaster Under the Microscope

Despite the BOTS Act being in place for years, ticket scalping persists. U.S. regulators have now turned their attention to the platforms themselves. In September 2025, reports emerged that the U.S. Federal Trade Commission (FTC) was investigating whether Ticketmaster, a subsidiary of Live Nation, was doing enough to comply with the BOTS Act.

The probe is reportedly examining whether the ticket seller has a financial incentive to allow resellers to circumvent its own rules. Ticketmaster denies wrongdoing and claims to block hundreds of millions of bots daily, but the investigation raises a direct question: are ticket platforms motivated to eliminate a secondary market from which they can also profit?

If the FTC pursues a case and finds Ticketmaster in violation, the penalties could be substantial. The law allows for fines of up to $53,000 per violation, which could translate to billions of dollars in penalties and put the rest of the industry on notice.

Renewed Political Pressure

Ticket scalping has also drawn direct political attention. In March 2025, President Donald Trump signed an executive order aimed at cracking down on ticket scalpers and price-gouging practices. The order specifically calls on the FTC to increase its enforcement of the BOTS Act, a piece of legislation that, despite being law since 2016, has been used to prosecute offenders only once.

The executive order also pushes for greater price transparency throughout the ticket-buying process and calls for investigations into unfair and anti-competitive practices in the secondary market. This follows similar efforts from the Biden administration, which had focused on eliminating "junk fees" and promoting all-in pricing. The bipartisan pressure points to a growing consensus that the current state of the ticketing industry is failing consumers.

The order received broad support from across the industry, with Live Nation, StubHub, and the National Independent Venue Association (NIVA) all voicing their approval. That support reflects a clear industry position: stronger enforcement of existing laws like the BOTS Act is a necessary step in protecting fans from scalpers.

Fighting on Two Fronts

While regulators are questioning Ticketmaster's efforts, the company has also used legal channels to fight bot operators. A notable case involved Prestige Entertainment, a ticket broker that Ticketmaster accused of using sophisticated bots to buy large quantities of tickets for resale.

In that lawsuit, Ticketmaster alleged that Prestige used bots and dummy accounts to bypass security measures like CAPTCHAs and purchase limits. The case produced some interesting legal arguments, including a novel copyright claim. Ticketmaster argued that in order to develop the bots, the software creators must have illegally copied code from Ticketmaster's website and app.

The legal battle ended in a settlement in 2019, with Prestige Entertainment permanently banned from using bots on Ticketmaster's platforms. The case shows that while Ticketmaster is under scrutiny itself, it has also pursued those who exploit its system. That leaves Ticketmaster fighting on two fronts: against bot operators, and now against regulators questioning whether its own enforcement is strong enough.

An Endless Cat and Mouse Game

The ticketing industry is locked in a constant technical arms race. As platforms like Ticketmaster develop more sophisticated security measures, bot creators find new ways to circumvent them. They use tools like residential proxies to mimic human users and distribute their attacks across thousands of IP addresses, making them difficult to detect.

Ticketmaster states it blocks 200 million bots a day, a fivefold increase from 2019. That figure shows the scale of the problem. The financial incentive for scalpers is large, and they are willing to invest heavily in technology to stay ahead.

For consumers, this means sold-out events and high resale prices are likely to continue. The BOTS Act provides a legal framework to punish offenders, but its effectiveness depends on enforcement and cooperation from major players like Ticketmaster. The current FTC investigation may show how much practical force the law has.

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 solutions use techniques like network and browser fingerprinting 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.

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.

Beyond the IP Address

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

For years, rate limiting has been a standard control for protecting websites and APIs from abuse. The basic model is simple: limit the number of requests a single "user" can make in a given period. If a user exceeds the limit (e.g., 10 login attempts in a minute), they are temporarily blocked.

The hard part has always been identifying that "user". Traditionally, the answer was the IP address. The assumption was that one IP address equaled one user. In the early days of the internet, this was a reasonable approximation. Today, that assumption no longer holds, and it leaves systems exposed to modern attacks.

The IP address is no longer a reliable identifier for a single user or device. There are three common reasons:

Proxy Networks: Attackers don't use a single IP address. They use large residential proxy networks to rotate requests through thousands or even millions of different IP addresses, making each request look like it comes from a new user.
Shared IPs (CGNAT): At the same time, a single IP address can represent thousands of legitimate users. Mobile carriers use Carrier-Grade NAT (CGNAT) to make many mobile devices share the same public IP. Similarly, an entire office building or university campus might appear to the internet as a single IP.
Distributed Attacks: Modern automated attacks, like Layer 7 DDoS or credential stuffing, are inherently distributed. Attackers use botnets or proxy networks to spread their attack across a large number of IPs, so no single IP ever exceeds a traditional rate limit.

Blocking a shared IP because of one bad actor can cause collateral damage, denying access to thousands of legitimate users. On the other side, failing to see that thousands of IPs are part of a single coordinated attack means the attack succeeds. Traditional IP-based rate limiting is no longer enough.

The New Way: Advanced Rate Limiting

Advanced Rate Limiting addresses this by moving beyond the IP address. Instead of grouping requests by a single, unreliable identifier, it lets you count requests using more stable and meaningful characteristics of the connection or the software making it.

This approach groups requests using identifiers like:

TLS/HTTP2 Fingerprints: Every client application (like a browser or a script) has a unique "fingerprint" based on how it initiates a secure connection (TLS) or communicates over HTTP/2. This fingerprint remains consistent even as an attacker rotates through thousands of IP addresses. By rate limiting based on the TLS fingerprint, you can track and block the underlying automation tool itself, not just the IPs it uses.
Device Characteristics: A fingerprint can be constructed from a range of attributes, including the device's operating system, browser version, and more. This allows for the detection of repeated requests coming from the same class of device.
A Combination of Headers: For authenticated APIs, you can group requests by an Authorization header or API key, enforcing fair usage and preventing abuse by a single authenticated client.

Practical Use Cases

The value of advanced rate limiting is clearest when it is applied to real-world threats:

Mitigating Distributed Credential Stuffing: An attacker using a tool like OpenBullet launches a credential stuffing attack against your login page, rotating through thousands of residential proxy IPs. Traditional rate limiting is ineffective here. However, the OpenBullet software has a consistent TLS fingerprint. By setting a rule to limit failed login attempts per TLS fingerprint, you can detect and block the entire distributed attack, regardless of how many IPs are involved.
Protecting APIs from Abuse: A partner is abusing their API key, sending far too many requests and degrading service for other users. By rate limiting based on the Authorization header, you can enforce usage limits on a per-client basis, keeping access fair without affecting other users.
Stopping Content Scrapers: A scraper is hammering your e-commerce site to steal pricing data. They are using a botnet to distribute the requests across hundreds of IPs. However, the scraping script has a unique combination of a user-agent and a TLS fingerprint. Advanced rate limiting can count requests based on this combined signature and block the scraper, protecting your intellectual property.

When attackers are distributed, your defences need to see the single actor behind the many IPs. Advanced rate limiting provides that visibility and should be part of a modern application security strategy.

The Invisibility Cloak

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

Every time you connect to a website, you leave behind a "digital fingerprint." This is not a physical fingerprint, but a set of signals from your device and browser. Security tools analyse this fingerprint—which includes your IP address, browser type, operating system, supported fonts, and even subtle characteristics of your network connection (TLS fingerprinting)—to distinguish legitimate users from malicious bots.

For years, this was a reliable way to spot automated threats. Bots often had clumsy, inconsistent fingerprints that made them easier to identify. Today, attackers can combine tools that mimic real users closely enough to weaken many traditional defences. The two most important components of this modern "invisibility cloak" are residential proxies and anti-detect browsers.

What Are Residential Proxies?

A residential proxy is an intermediary server that uses an IP address assigned by an Internet Service Provider (ISP) to a real home internet connection. When a bot routes its traffic through a residential proxy, its requests appear to originate from a genuine home user, not a data centre.

These proxy networks are large, often containing millions of IP addresses sourced from around the globe. How are these IPs obtained? Often through questionable means:

Malware and Botnets: Unsuspecting users' devices are infected with malware that turns them into proxy endpoints.
SDKs in Free Apps: Some free applications (often VPNs or mobile apps) include code that enrols the user's device into a proxy network in exchange for using the app, often without the user's full knowledge or consent.

By rotating through this large pool of legitimate-looking IPs, attackers can launch large-scale attacks that are difficult to separate from normal traffic. To a website's security system, a distributed attack from a residential proxy network looks like thousands of individual customers from different locations.

What Are Anti-Detect Browsers?

While residential proxies mask the attacker's network location, anti-detect browsers are designed to spoof the rest of the digital fingerprint. These specialised browsers allow an attacker to create and manage thousands of unique browser profiles, each with a customised and consistent fingerprint.

An anti-detect browser can control and randomise every detail a website uses for identification, including:

Browser type and version (e.g., Chrome, Firefox, Safari)
Operating system (Windows, macOS, iOS, Android)
Screen resolution, fonts, and plugins
Time zone and language settings
Subtle browser characteristics like Canvas and WebGL rendering

With a few clicks, an attacker can make a single machine in one country appear as thousands of unique users on different devices and operating systems from all over the world.

The Combined Threat: A Perfect Storm for Attacks

When attackers combine residential proxies with anti-detect browsers, they cover both the network and browser layers that many controls rely on. The residential proxy provides a legitimate IP address, and the anti-detect browser provides a consistent, human-looking browser fingerprint.

This combination makes attacks like large-scale credential stuffing, content scraping, and inventory scalping much harder to distinguish from legitimate user traffic. Each malicious request appears to be from a unique person on a standard device, using a normal home internet connection.

Why Traditional Defenses Fail and What to Do About It

This level of sophistication weakens traditional security measures:

IP Blocklists and Reputation Services: These struggle when attackers are using a constantly rotating pool of millions of legitimate residential IP addresses. Our own research shows that even the best IP intelligence services fail to detect the vast majority of residential proxy traffic.
Basic Browser Fingerprinting: Anti-detect browsers are specifically designed to defeat these checks by providing a consistent and realistic fingerprint.

To combat this combined threat, organisations need a modern approach to bot detection that looks beyond the surface:

Advanced Network Fingerprinting: Instead of just looking at the IP address, modern solutions analyse the underlying characteristics of the network connection itself (like the TLS/JA3 fingerprint). These signatures can often identify the underlying automation tool or proxy network, even when the IP address appears legitimate.
Behavioural Analysis: Advanced systems model normal user behaviour—such as mouse movements, typing speed, and page navigation—to identify the subtle, non-human patterns of automation that even sophisticated bots can't perfectly mimic.
Hardware and Rendering Fingerprinting: While anti-detect browsers can spoof software-level details, faking the underlying hardware is far more difficult. Advanced techniques, such as those used in Google's Picasso, analyse how a device renders graphics (e.g., Canvas and WebGL), processes audio, and performs CPU-intensive tasks. This creates a hardware fingerprint based on the unique characteristics of the GPU, audio stack, and CPU clock speed. This fingerprint can reveal inconsistencies between the claimed browser profile and the actual hardware being used. When combined with network fingerprinting and residential proxy detection, this becomes a strong signal for identifying a single machine attempting to impersonate many different users.
Dedicated Residential Proxy Detection: Specialised techniques are required to identify traffic coming from residential proxy networks. This is a critical signal, as very few legitimate users have a reason to route their traffic this way.

Attackers using residential proxies and anti-detect browsers are harder to identify, but they still leave signals. Network characteristics, hardware fingerprints, and the behavioural tells of automation give security teams a better chance of separating the bot from the user it is trying to resemble.

The CAPTCHA Conundrum

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

Remember the distorted, wavy letters you had to decipher to prove you were not a robot? That was CAPTCHA, which stands for "Completely Automated Public Turing test to tell Computers and Humans Apart." First developed in the early 2000s, its purpose was simple: create a challenge that humans could solve, but automated scripts, or bots, would struggle with.

For years, CAPTCHA was used across common web actions, from creating an account to posting a comment. But bots have improved faster than the test, while users have become less tolerant of friction. CAPTCHA now often fails in both directions: it interrupts legitimate users and can still be solved by automated campaigns.

The User Experience Problem: Killing Conversions

The biggest issue with visible CAPTCHAs is the friction they add to the user journey. Customers expect checkout, login, and form flows to be quick. Asking them to stop and solve a puzzle creates a clear point for abandonment.

The data is hard to ignore:

A landmark Stanford University study found that adding a CAPTCHA can reduce form conversions by up to 40%.
Research from bot management firm HUMAN Security revealed that 40% of real shoppers have abandoned a purchase because of CAPTCHA frustration.
Other analyses have shown that simply adding a CAPTCHA can lead to a 3.2% higher bounce rate and an overall 3-5% drop in conversions.

For an e-commerce business, losing up to 40% of potential sales at the final checkout step is not a marginal UX issue. These numbers map directly to revenue from legitimate customers who were annoyed, delayed, or unable to solve the puzzle. The impact is even worse for users with disabilities, for whom many visual CAPTCHAs are nearly impossible to complete.

The Security Problem: A Speed Bump for Bots

While CAPTCHAs frustrate legitimate users, they are often only a small obstacle for modern bots. A market exists for bypassing them at scale.

Attackers now use automated CAPTCHA-solving services, often called "CAPTCHA farms." These services use a combination of machine learning algorithms and low-wage human workers to solve CAPTCHAs in real time for a fraction of a cent per puzzle.

An attacker using an automation tool like OpenBullet can integrate with these services via a simple API call. When the bot encounters a CAPTCHA, it sends the puzzle to the solving service and receives the solution seconds later. In many cases, these services have a higher success rate at solving CAPTCHAs than actual humans.

That breaks the original CAPTCHA model. The test designed to block bots can now create a false sense of security while actively harming the experience for real users.

The Modern Alternative: Invisible Challenges

If visible CAPTCHAs are broken, what's the alternative? Modern bot management uses invisible challenges to verify users without causing friction. Instead of actively testing the user, these systems analyse background data to distinguish humans from bots.

This is achieved through a multi-layered approach:

Behavioural Analysis: These systems track subtle indicators of human behaviour, like mouse movements, typing cadence, and touchscreen interactions. Bots, even sophisticated ones, struggle to mimic these patterns consistently.
Network and Browser Fingerprinting: By analysing hundreds of data points from the browser and network connection, these systems can identify the tell-tale signs of automation, such as the use of data centre IPs, proxy networks, or inconsistencies in the browser fingerprint.
Machine Learning: Machine learning models are trained on vast datasets of human and bot traffic. They can identify complex patterns and adapt in real time to new and evolving bot techniques.

With this approach, most legitimate users never see a challenge at all. Their journey remains uninterrupted. Only when the system detects highly suspicious activity is a challenge presented, so security controls are applied where the risk justifies the friction. For sites that depend on checkout completion, account protection, or lead capture, that is a better trade-off than showing every user another puzzle.

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.

The Negative Impact of Visible CAPTCHAs on Bounce Rates and Conversions

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

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

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

Conversion Rate Impacts of Visible CAPTCHAs

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

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

Bounce Rates and User Abandonment

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

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

User Experience Friction and Qualitative Insights

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

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

Industry-Specific Observations

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

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

Death of the CAPTCHA

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

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

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

Protecting Against a Share Point Zero Day Vulnerability with Network Fingerprinting

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

Why Network Fingerprinting is Your Strongest First Defense

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

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

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

Understanding the Threat: CVE-2025-53770

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

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

The Race Against Scanners

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

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

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

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

Why IP Reputation Isn't Enough

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

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

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

Unmasking the Attacker's Tools with Network Fingerprinting

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

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

Peakhour uses several passive fingerprinting techniques to do this:

TCP Fingerprinting

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

TLS Fingerprinting

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

HTTP/2 Fingerprinting

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

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

Defense in Depth

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

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

Staying Ahead in a Zero-Day World

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

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

Why Don't We Have an AI UI Yet?

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

In my last post, I made the case that Artificial Intelligence is the next great computer interface: a way to translate our intentions directly into actions. It is a powerful idea, but it immediately raises the practical question. If this is the future, where is it? Why am I still clicking icons and navigating menus on my computer instead of just talking to it?

The concept is much cleaner than the implementation. We are still a fair way from having a true AI-native interface, and there are some hard problems to solve before it becomes the main way we use a computer.

The Understanding Problem

The first challenge is that current AIs don't truly understand things in the way humans do. When you ask an AI to "write a summary of last quarter's sales," it doesn't know what a "sale" is or what a "quarter" means to the business. It is an extremely capable pattern-matching machine that knows which words and concepts are statistically likely to follow your request.

That is useful for generating text or code, but it can also lead to "hallucinations"—where the AI confidently makes things up. For a chatbot, that might be annoying. For a computer's operating system, it is a critical failure. You can't have an interface that might invent a file that doesn't exist or misinterpret a crucial command.

The Action and Safety Problem

An AI interface needs to do more than just talk; it needs to act. It must be able to open programs, manage files, change settings, and send emails. That requires giving the AI deep access to the core functions of the operating system, which is where the idea stops feeling neat and starts feeling risky.

How do you give an AI the power to delete files based on a verbal command without creating a massive security hole? How do you ensure it can't be tricked by a cleverly worded prompt (or an external attacker) into causing chaos on your system? Creating a safe and reliable bridge between the AI's language processing and the computer's functions is a hard engineering problem.

The Trust and Reliability Problem

For an AI interface to be useful, we have to trust it completely. If you tell it to "delete my old holiday photos from 2018," you need to be certain it won't misunderstand and delete your wedding photos or important work documents.

This need for absolute reliability runs counter to the probabilistic nature of today's AI models. We can't have an interface that is "mostly right." It needs to be right every single time. The hard part is adding the necessary safeguards and confirmation steps without turning the whole thing into a slower version of the menus we were trying to escape.

The Speed and Cost Problem

Finally, there is a practical issue. Running the massive language models that would power such an interface is slow and computationally expensive. A good user interface needs to feel instant and responsive. If it takes ten seconds for an AI to process your request to open a web browser, it is not a better experience than just clicking the icon yourself. The hardware and software infrastructure isn't quite ready to deliver the seamless, real-time experience we would expect from a primary computer interface.

These challenges aren't insurmountable, but they are significant. That is why I think AI will keep showing up first as powerful features within our existing apps and operating systems. Those narrower uses give it clearer jobs, tighter permissions, and more places for humans to confirm what is about to happen. The full AI interface may arrive eventually, but I don't think it appears all at once. It will earn trust in smaller pieces first.

AI as the Translator Between Human and Machine

2025-07-19T00:00:00+10:00

Think about how we've talked to computers over the years. At first, it was rigid and unforgiving. The command line expected the exact words, in the exact order. One typo, and you were met with an error. It was powerful, but only once you learned to speak the computer's language.

Then came the graphical user interface, or GUI—the familiar world of windows, icons, and mouse pointers. That changed the relationship. You no longer had to memorise commands before you could do something useful. You could see your options, click on them, and drag things around. It made computers accessible to hundreds of millions of people because it was more intuitive. It was a visual conversation.

But both of these interfaces, the command line and the GUI, share the same basic bargain: we adapt ourselves to the computer. We still have to navigate menus, find the right button, or remember a specific command. We take a goal in our head and break it into steps the computer understands.

What if that translation was no longer mainly our job? What if the computer could understand our goal well enough to work out the steps?

This is the next shift I find interesting, and it is powered by Artificial Intelligence. AI is starting to look less like another application and more like the next major interface. It's not a visual one with buttons and menus, but an intelligent one built on understanding.

The idea is simple, even if the implementation is not: we state our intent, and the AI figures out the steps. Instead of clicking through five different menus to create a sales report, you could just say, "Show me last quarter's sales figures for the eastern region, and visualise it as a bar chart." The AI's job is to understand that request and then do the work: query the database, aggregate the data, select the right chart type, and present it to you. It acts as a translator between human language and the computer's machine language.

We're already seeing the early stages of this. When you ask a smart assistant to play a song, or when an AI co-pilot writes code for you, you're using an intent-driven interface. You're not telling it how to do the task; you're just telling it what you want done.

That shift matters because it moves some of the cognitive load from us to the machine. We no longer need to be experts in using a particular piece of software; we just need to be clear about what we want to achieve. This has the potential to democratise technology on a scale we've never seen before, making complex digital tools feel closer to a conversation than a training course.

The future of computing isn't about learning more complex systems. It's about building systems that can learn from us. The interface of tomorrow won't be something we click on, but something we talk to, correct, and steer. That is the real change: technology that doesn't just follow instructions, but understands our goals.

From Research Paper to Running Code

2025-07-18T00:00:00+10:00

In my last post, I talked about my journey from typing format c: on an old DOS machine to collaborating with AI. The part I keep coming back to still feels slightly unreal: turning academic research papers directly into working code.

For years, the hard part was the distance between academia and industry. A good idea could be locked inside a dense, equation-heavy paper, and turning it into a practical tool could take a team of specialists weeks or months. You had to understand the mathematics, translate it into logic, write the code, and then debug all the places where the theory met the real world.

Now my process looks completely different. I'll find an interesting paper, give it to an AI like Gemini, and say, "code this for me". It is a conversation, not just a command. We go back and forth, clarifying ambiguities in the paper and refining the implementation. What used to take weeks of painstaking effort can now be prototyped in an afternoon.

Here are a few examples from my own experiments.

Anomaly Detection

I recently came across a paper detailing a new statistical method for detecting anomalies in time-series data. In the past, I would have spent days just trying to get comfortable with the mathematical models before writing a single line of code. This time, I fed the PDF to the AI. Within minutes, it had parsed the document and produced a Python implementation of the core algorithm. It was not perfect on the first go, but it was a solid, working foundation that we could test and refine together. The AI handled the heavy lifting of translation, leaving me to focus on validating and applying the model.

Customer Journey Mapping

Another area I have been looking at is using data to understand customer behaviour. There are academic papers that model how users interact with a website or product, mapping out their journey from discovery to purchase. Implementing these models used to be a serious undertaking. Now, I can give the AI a paper on a new journey mapping technique, and it can generate the code to analyse server logs or user event data and produce the kind of insights the paper describes. That makes it much easier to experiment with new ways of understanding our customers.

Building Small Language Models

This is where it gets really interesting. We can use large language models (LLMs) to help build smaller, more specialised ones. I've been experimenting with research papers that propose new, efficient LLM architectures. I can give one of these papers to a large AI and have it help me write the code for the smaller architecture. There is a beautiful irony in using a massive AI to help create its smaller, more nimble cousins. It speeds up the cycle of innovation inside the AI field itself.

For me, the important change is the shorter loop between reading an idea, testing it, and getting it into use. The friction between a theoretical concept and a working prototype has been reduced almost to zero. That means I can explore more ideas, take more risks, and bring those research ideas into real use much faster than before.

My Programming Journey

2025-07-17T00:00:00+10:00

My path into technology started with a beige box and no plan beyond seeing what it would do.

When I was a kid, I got an old 8086 computer. The only thing it came with was a thick manual for 'DOS', its operating system. For a child trying to make sense of it, the blinking C:\> prompt was not exactly welcoming. What was I meant to do with it?

I tried typing whatever came to mind, but most of it ended in errors. Then I stumbled on a command that actually did something interesting: format c:. After I typed 'Y' to confirm, the screen would fill with text, showing me its progress. I didn't realise I was wiping the computer's entire memory. I only knew the machine was finally responding.

Things properly opened up when I found a book filled with GW-BASIC programs. I wasn't just using a computer anymore; I was telling it what to do. I spent ages carefully typing out code, one line at a time. 10 PRINT "HELLO THERE", 20 GOTO 10. It was slow work, but there was something hard to beat about bringing a program to life with my own hands.

My skills moved along when QuickBasic started coming with MS-DOS. The tools were better, the language was more powerful, and I started building my own little games and applications, learning how to organise my ideas into code.

Every programmer eventually hits a wall. For me, it was a 64-kilobyte limit on a single variable. It sounds tiny now, but it blocked a project I cared about. The only way forward was to learn C, a much more complex language. It was a hard jump, but it was the way to build bigger and more powerful software.

That arc is why today's tools feel so strange to me.

For most of my career, my job was to translate human ideas into instructions a computer could follow. I had to think like a machine, breaking everything down into small, logical steps.

Now the process feels very different. I still solve problems, but I spend less time spelling out every instruction. I have a conversation with my computer. I can describe a goal, or show it a research paper, and an AI partner helps me write the code. My role has shifted from writing each line by hand to setting direction, checking the work, and deciding what is actually worth building.

Looking back, the path from blindly typing format c: to working alongside an AI still feels odd in the best way. We've moved from telling the machine exactly how to do something to describing what we want to achieve and then judging the result. That is a big change. I am still getting used to it.

A Complete Guide to SMS Pumping Fraud

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

The Growth of SMS Fraud

SMS pumping fraud is a costly online abuse pattern, with global losses reaching an estimated $6.7 billion in 2021 alone. It targets companies that rely on SMS for verification or customer communications, leaving them to pay for traffic they did not request.

The scheme relies on malicious actors and dishonest telecom operators working together to generate and monetise large volumes of fraudulent text messages. For businesses caught in these schemes, the financial impact can be severe. Twitter (now X) reportedly lost $60 million to this type of fraud.

This guide explains how SMS pumping works, which businesses face the highest risk, and the controls your organisation can use to reduce exposure.

Understanding SMS Pumping Fraud

SMS pumping (also called SMS toll fraud, SMS spamming, or Artificially Inflated Traffic) involves manipulating mobile networks to inflate charges for text messages. The term "pumping" describes fraudsters forcing high SMS volume through a target's systems.

This fraud exploits how SMS messages travel and get billed across phone networks. Attackers target companies that use SMS codes to verify users. Each time a business sends a verification code, it pays a fee. Fraudsters trigger these systems to send thousands of messages to numbers they control.

These attacks create direct costs for businesses and revenue for the attackers. The fraud works through coordination between criminals and corrupt telecom operators, who charge premium rates for message delivery and share the proceeds.

The fraud has changed as more businesses have adopted SMS verification. Attackers keep developing new methods, and the phone industry has not removed the risk. Many companies still carry the financial exposure.

How SMS Pumping Works

SMS pumping attacks usually exploit message systems through these steps:

Finding Targets: Attackers look for websites or apps that send SMS codes for account verification or password resets.
Creating Fake Requests: Fraudsters use automation to send thousands of code requests to phone numbers they own or control.
Hiding Their Tracks: Attackers change their IP addresses and device information so requests appear to come from real users.
Sharing Profits: Fraudsters work with dishonest phone companies that charge high fees when messages pass through their networks. These companies then share the money with the attackers.
Using Complex Routes: Messages travel through many networks before reaching their destination, making the source of the fraud harder to trace.
Targeting Expensive Routes: Attackers focus on international numbers where sending messages costs more or where rules are weaker.

These attacks look legitimate because each message contains a real code sent to what appears to be a normal phone number. Companies like Twilio or Bird must pay fees to deliver these messages. Most businesses only find out about the fraud when a large bill arrives from their SMS service.

SMS pumping differs from basic spam because the profit-sharing between attackers and phone companies creates a direct cost for the target business.

Businesses at Risk

SMS pumping is most likely to affect these types of businesses:

Financial Institutions

Banks, investment platforms, and cryptocurrency exchanges use SMS codes to protect accounts. These firms send thousands of codes each day, which makes it hard to spot fake requests mixed with real ones.

E-commerce Platforms

Online shops use SMS messages when users create accounts, reset passwords, or make purchases. These businesses often run on small profit margins, so extra SMS costs can hurt their earnings. High volumes of new users make it easier for attackers to hide their activity.

Social Media Companies

Social networks use text messages to check user identity and stop fake accounts. These companies send millions of codes each day to users around the world. Twitter lost $60 million from this type of fraud, showing the scale these bills can reach.

Software-as-a-Service (SaaS) Providers

These companies often offer free trials that require SMS verification. They plan for a set cost to acquire each new user, but fraud can push these costs much higher than expected.

Telecommunications Companies

Phone companies face two problems: their own systems can be attacked, and parts of their network might help fraudsters. They need strong monitoring tools to find unusual patterns in message traffic.

Small Businesses and Startups

While smaller firms send fewer messages, they often lack security teams and fraud detection tools. This makes them easier targets. The cost of an attack can put these businesses at risk of closing down because they have less money in reserve.

Advanced Attack Methods

Attackers now combine SMS pumping with other techniques to avoid detection.

Credential Stuffing

Fraudsters use passwords stolen in data breaches to break into accounts. Once inside, they change phone numbers to ones they control and trigger verification messages. This makes fraud appear to come from real users.

Peakhour's breach database detection identifies when stolen credentials are used to access accounts. The system flags these attempts before phone numbers can be changed, stopping the attack chain.

Residential Proxy Networks

Unlike data centre proxies that security systems can often spot, residential proxies hide attack traffic behind home internet connections. This makes fraud look like it comes from regular users in different locations.

Peakhour specialises in residential proxy detection. Its technology identifies these masked connections and blocks them before verification requests can pass through. The system maps known proxy networks and detects signs of traffic passing through residential IPs.

When combined with device fingerprinting, these protections create a stronger defence. Fingerprinting tracks device characteristics that remain consistent even when attackers change IP addresses or accounts. Peakhour's fingerprinting technology works without cookies, making it effective against attackers who clear browser data.

These methods focus on the techniques fraudsters use to hide their identity. With Peakhour's protection, businesses can detect and block these attacks before they trigger costly SMS verification messages.

Historical Incidents

Reported SMS pumping incidents show how quickly costs can build:

Twitter's $60 Million Loss

In January 2023, Twitter owner Elon Musk said the platform lost more than $60 million to SMS pumping fraud. He named over 390 phone companies that took part in the scheme. While Twitter later questioned some claims, the case brought public attention to this type of fraud.

Industry-Wide Financial Impact

The Communications Fraud Control Association reports that SMS pumping caused global losses of $6.7 billion in 2021. Many companies do not share their fraud losses with the public.

Costs to Individual Businesses

Companies hit by these attacks pay between tens of thousands and millions of dollars each month in fake charges. These costs grow fast because each fake message costs much more than normal text rates.

Verification Policy Changes

Because of these threats, many large platforms have moved away from SMS codes. Twitter removed SMS verification for most users in March 2023, stating fraud as the reason.

Operational Disruptions

Beyond the cost of messages, businesses can face service problems during attacks. Real users may not get their codes on time. This can cause users to abandon transactions, contact support more often, and lose confidence in the company.

Rules and Enforcement

Rules to stop these attacks differ around the world. Some telecoms authorities have strict rules and fines for networks that allow fraud, but enforcement remains hard. Fraudsters use complex message routes that cross many countries to avoid getting caught.

Understanding the Stakeholders

SMS pumping involves these key groups:

Businesses

Companies use SMS to check user identity and send updates. They hire SMS gateway providers to handle their messages. When fraud happens, these businesses pay for the fake messages. Most find out about the attack only when they receive an unexpected bill.

SMS Gateway Providers

Companies like Twilio and MessageBird connect businesses to phone carriers. They give businesses tools to send text messages without working with phone networks directly. When fraud passes through their systems, these providers may try to stop it, but still charge businesses for the messages sent.

Mobile Network Operators (MNOs)

These companies run the networks that deliver messages to phones. Most work honestly, but SMS pumping schemes often include corrupt operators who charge extra fees for messages to numbers they control. These operators then split the money with the attackers who started the fraud.

Content Aggregators

These middlemen combine message traffic and work with many carriers to find the best routes. Most run honest operations, but their position in the message chain creates routing and oversight gaps that attackers can use.

Regulatory Bodies

Groups like the GSM Association create rules and standards for the industry. These rules are hard to enforce because phone networks cross many countries with different laws.

Financial Flow

The payment flow starts when businesses pay gateway providers to send messages. The gateway providers then pay fees to network operators based on where messages go. In fraud schemes, inflated fees go to corrupt operators who share the money with attackers. This creates a system where sending more fake messages makes more money for criminals while costing honest businesses more.

Effective Protection Strategies

Protecting your organisation usually requires several controls:

Basic Protections

Rate Limits: Restrict how many verification attempts a user can make in a set time period.
Traffic Pattern Checks: Track normal SMS message patterns and watch for changes that might indicate attacks.
Provider Protection: Services like Prelude's SMS Pumping Protection find and block messages to fake numbers.
Other Ways to Verify Users: Use app-based verification or push alerts instead of SMS codes.
Control by Country: Limit SMS verification to countries where you do business and add more checks for countries with higher fraud risk.
Work with Trusted Partners: Choose SMS service providers that focus on security and can help stop fraud quickly.

Advanced Protection Methods

Residential Proxy Detection: Find and block users who hide their true location behind home networks used as proxies.
Device Fingerprinting: Collect device signals to track users across sessions and spot when many verification requests come from the same device.
User Behaviour Tracking: Learn how real users act on your site and flag unusual actions that might be bots.
Machine Learning Systems: Use systems that learn from data to find hidden fraud patterns and adapt to new attack types.
Phone Number Checks: Use lists of known bad numbers to decide which phone numbers need more verification steps.
Verify in Multiple Ways: Ask users to prove who they are in different ways, such as email plus SMS, to make attacks harder.
Work with Other Companies: Share information about new attack methods and bad phone numbers with other businesses.
Watch Transactions as They Happen: Use systems that can pause message sending when they spot unusual patterns and learn from both legitimate and abusive traffic.

Fighting SMS Pumping Fraud

SMS pumping fraud costs businesses $6.7 billion worldwide each year. Companies like Twitter lost $60 million to these attacks, showing that scale alone does not remove the risk.

SMS pumping works through a network of fraudsters, network operators, and service providers who exploit the payment system for text messages. Fraudsters target authentication systems to generate large volumes of SMS, then collect revenue shares from the process.

Peakhour and Prelude offer combined protection against these threats. Peakhour provides device fingerprinting to identify suspicious devices attempting verification. Its residential proxy detection stops fraudsters who hide behind legitimate IP addresses. These tools block attackers before they access verification systems.

Prelude complements this protection with their multi-routing SMS verification platform. Its system uses real-time fraud detection across five messaging channels in 230 countries. When Prelude detects a potential attack, it automatically redirects traffic through secure routes.

Businesses need to understand the SMS delivery chain to protect themselves. Gateway providers, network operators, and content aggregators each introduce possible points of exploitation.

Prevention requires multiple security layers:

Rate limiting to restrict message volume
Device fingerprinting to track suspicious patterns
Residential proxy detection to unmask hidden attackers
Behavioural analytics to spot unusual activity
Machine learning to adapt to new attack methods
Continuous learning based on real user interactions

The continuous learning systems from both Peakhour and Prelude build protection that improves with each user interaction. Their platforms analyse legitimate traffic patterns to differentiate them from attacks, helping protection adapt over time.

While SMS verification remains common, Peakhour and Prelude help businesses implement more secure authentication methods. Together, they provide protection that adapts to evolving threats and reduces the cost of fraudulent verification traffic.

See how Peakhour's Application Security Platform helps protect against SMS pumping and other automated threats. Contact our team to secure your applications.

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.

A/B Testing, Bots, and the New Normal

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

Marketing traffic is no longer just human traffic. We spent months analysing how AI agents interact with websites, and the findings put pressure on a core assumption behind digital marketing: that campaign data mostly reflects human behaviour.

Consider a simple A/B test on a landing page. The data shows a clear winner, with conversion rates 30% higher than the control. You ship the change, then the live result misses the forecast. One possible cause is that AI agents were counted in the test population.

This is not speculation. We have observed AI agents, from shopping bots to research tools, interacting with marketing campaigns in ways that weaken traditional metrics. These agents do not behave like people. They optimise for efficiency, not experience. They follow patterns, not preferences.

The consequence is straightforward. A/B test results may reflect what works best for AI agents rather than human users. Conversion metrics may combine human decisions with automated actions. A marketing funnel can end up optimising for the wrong audience.

The scale became clear when we analysed traffic patterns across various sectors. In ecommerce, AI agents now account for up to 40% of product page views. For content sites, the figure rises to 60% for certain categories. These are not simple scraper bots. They interact with content, follow links, and even complete transactions.

Blocking all of this traffic is not a practical answer. Many agents serve legitimate purposes, from price comparison to content aggregation. Marketing teams now need to recognise and measure a dual audience: human and AI.

Through our research, we have identified three shifts in marketing strategy:

First, marketing funnels need to bifurcate. One path should be optimised for human users, with emphasis on engagement and experience. Another should serve AI agents, with structured data and efficient access to information.

Second, A/B testing needs new frameworks. Analysis should separate AI and human interactions. That requires stronger detection methods and separate datasets for each audience type.

Third, attribution models need to evolve. When an AI agent researches products before recommending them to a human user, who gets credit for the conversion? The traditional last-click model does not capture that sequence well.

The problem is not limited to metrics. AI agents use residential proxies to mask their nature, making detection difficult. They learn and adapt, which means identification methods need regular updates. They also operate at scale, potentially overwhelming analytics systems.

There are useful opportunities here, but they need to be treated with discipline. Organisations that adapt their marketing strategies can optimise content delivery for both audiences. They can use AI agents as a marketing channel where that makes sense. They can also build campaigns that are less exposed to polluted measurement.

The path forward starts with a clearer operating model. Marketing teams need to treat AI agents as a distinct audience segment, with different behaviours and requirements. They also need tools and metrics that measure performance across both audiences without mixing them together.

Our research suggests several practical steps:

Implement robust bot detection systems to identify AI agent traffic. This gives teams the basis for separate analysis of human and AI interactions.

Develop structured data formats that serve AI agents efficiently while maintaining rich experiences for human users.
Create attribution models that account for the role of AI agents in the customer journey.
Monitor residential proxy usage to understand the true nature of website traffic.
Build marketing strategies that balance the needs of both audience segments.

Marketing data will keep changing as AI agents become more sophisticated. The line between human and automated interactions may blur further. Teams that recognise the split can make better decisions about testing, attribution, and campaign design.

Organisations that continue to treat all traffic as human risk optimising for the wrong audience. Organisations that separate the signal can make better use of both human and AI traffic.

Our next challenge is understanding how AI agents influence human decision-making. That is a separate question.

The views expressed in this article reflect our research and analysis of AI agent behaviour in marketing environments. We encourage organisations to conduct their own analysis and develop strategies suited to their specific circumstances.

When Bots Are Your Primary Users

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

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

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

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

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

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

Structure and Format

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

Rate Limiting and Quotas

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

Authentication and Security

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

Documentation and Discovery

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

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

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

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

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

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

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

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

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

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

Our APIs have to evolve with their users.

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.

Why Reasoning Models Like DeepSeek Change Everything

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

Visa's Security Roadmap 2025-2028

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

Visa's Security Roadmap 2025-2028 for Australia is not just a payments strategy document. It is a signal about where fraud, application security, authentication, and compliance work are converging for merchants, acquirers, issuers, gateways, and service providers.

The timing matters. Visa's roadmap cites Australian card fraud rising 32% to A$762 million in 2023, with unauthorised card-not-present fraud increasing 33% to A$688 million. Scam losses reached A$2.7 billion in 2023, and reported data breaches increased 19% in the second half of 2023 compared with the first half. The pressure is not coming from one direction. Payment teams are dealing with automation abuse, social engineering, compromised credentials, weak merchant onboarding, third-party exposure, and new payment experiences at the same time.

Visa groups its roadmap into six focus areas: preventing enumeration attacks, continued investment in secure technologies, data-driven risk, resilience against fraud and scams in the era of AI, stronger cyber security posture, and secure digital payment experiences. For Australian businesses, the more useful way to read it is as a set of operational themes.

Automation Abuse Has Become a Payment Control Issue

Enumeration attacks sit first in the roadmap for a reason. Visa defines enumeration and account testing as automation used to test and guess payment credentials that can later be used in fraudulent transactions. The attacks often appear as high-speed card testing against online merchants, with low-value attempts used to validate PAN, expiry, or CVV2 combinations.

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 enumeration attacks over the year to 30 September 2023. The updated Visa Acquirer Monitoring Program (VAMP), effective 1 April 2025, adds enumeration criteria alongside broader fraud and dispute monitoring.

The implication is practical: merchants and acquirers need route-level evidence, anomaly monitoring, velocity controls, and a way to identify distributed automation before it becomes payment fraud. IP-only controls are weak when attacks use residential proxies, first-seen devices, and slow distributed attempts. Peakhour's bot management, residential proxy detection, advanced rate limiting, and edge logging can help support that evidence path, but the business still needs payment-flow ownership and acquirer alignment.

Authentication and Tokenisation Are Moving Together

Visa's secure technology theme is not simply "add more authentication." The roadmap ties tokenisation, EMV 3DS, biometric or in-app authentication, passkeys, and Click to Pay into the same customer and fraud problem: protect credentials while reducing unnecessary friction.

Tokenisation reduces the value of exposed card data by replacing a card number with a token. Visa notes that the Visa Token Service has passed one billion tokens in Asia Pacific and that merchants adopting VTS for digital payments saw payment fraud rates reduced by more than half in the cited Asia Pacific analysis. But the roadmap also flags token provisioning fraud, where bad actors illegitimately provision tokens and then monetise them quickly.

That is why authentication quality matters. Visa says issuers are being mandated to move away from SMS OTP as the sole authentication factor by 2026, toward methods such as biometric, in-app, app-to-app, or passkey-based authentication. For merchants, updated Visa Secure minimum data requirements push more complete authentication data into the decision process.

For application teams, the lesson is that checkout security is not a single login prompt. It includes account creation, saved-card use, card add, token provisioning, checkout, refund, and support paths. A risk-based challenge should appear where the action justifies it, not everywhere by default.

Risk Decisions Need Better Data, Not Just More Data

The roadmap's data-driven risk theme is about using available payment and authentication data to reduce fraud and false positives. Visa points to EMV 3DS data elements, Visa Secure requirements, risk-based authentication, and issuer decisioning as examples of how better data quality can change outcomes.

More data is not automatically better. It has to be accurate, relevant, protected, and available at the moment of decision. A fraud team may need account history, device consistency, proxy likelihood, card-attempt cadence, transaction context, and previous response outcomes. A compliance team may need to know why that data is collected, where it is retained, and who can query it.

This is where contextual security becomes useful. Peakhour's Contextual Security approach combines request, route, account, network, device, and behaviour signals so teams can allow, challenge, rate limit, block, or log based on risk. The control is strongest when the decision record stays attached to the event: signal set, policy version, action, and outcome.

AI Raises Scam and Fraud Pressure, But It Is Also Part of Detection

Visa frames AI in both directions. Generative AI lowers the barrier for phishing, social engineering, deepfakes, and personalised scam content. At the same time, Visa points to its long history using AI and machine learning in payment fraud detection, including around 150 AI and machine learning models in production.

For businesses outside the payment network, the message is not "buy AI." It is to prepare for more scalable deception and faster abuse cycles. Fraud controls need to watch for account creation abuse, credential stuffing, payment testing, suspicious onboarding, transaction anomalies, and customer manipulation signals. Human review still matters because authorised scams can look different from unauthorised account compromise.

Peakhour's role is strongest around the request and account edge: identifying automation, proxy-backed traffic, route abuse, credential risk, and abnormal behaviour before fraud reaches sensitive application paths. Those signals can feed fraud review and incident response, but they should be used with privacy, false-positive, and customer-impact controls.

Cyber Posture Is Now Part of Payment Ecosystem Resilience

Visa's fifth theme connects payment fraud to cyber security posture. PCI DSS remains mandatory for entities storing, processing, or transmitting Visa cardholder data. Visa also highlights third-party agent (TPA) registration, its Account Information Security program, third-party service provider risk, breach trends, and preparation for broader AES support by 2030.

For Australian businesses, this is a reminder that payment risk is not limited to the payment processor. A breach of a CMS account, a third-party script, a weak checkout plugin, a vulnerable API, a compromised support tool, or an unmanaged service provider can affect the payment environment. PCI scope and third-party oversight need to include the systems that can change or observe checkout, not only systems that store card numbers.

Peakhour can help with application-layer controls around WAF, API protection, bot management, rate limiting, DDoS mitigation, and log forwarding. Those controls can support evidence for payment security and cyber posture. They do not replace PCI DSS validation, TPA obligations, acquirer requirements, or legal review.

New Payment Experiences Need Security Built Into the Flow

Visa's final theme covers digital payment experiences such as Click to Pay, passkeys, Flex Credential, and Tap to Everything. These changes are about reducing manual card entry, password dependence, and fragmented checkout experiences while preserving cardholder verification and transaction security.

The security work for merchants is to keep pace with those flows. New payment methods bring new integration paths, data elements, redirects, APIs, support workflows, and customer education needs. The right question is not only "does the new payment method work?" It is "which systems can affect it, what data is passed, how is the customer verified, what fraud signals are available, and what evidence remains after a dispute or incident?"

What Businesses Should Do Next

Read the roadmap as an operating agenda. Map payment and account routes. Identify where automation can test credentials or cards. Review SMS OTP dependence. Check whether tokenisation and 3DS data are being used well. Validate which vendors affect checkout and payment security. Confirm that logs can support fraud review without capturing sensitive card data. Tune rate limits and bot controls by route, not only by IP.

The next few years of payment security will reward teams that can make proportionate, evidence-backed decisions. That is the thread running through Visa's roadmap and through Peakhour's edge security work: see the request in context, choose the right action, and keep enough evidence for fraud, security, and compliance teams to explain what happened.

How Bots Are Corrupting Your A/B Testing Data

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

Bot traffic contaminates A/B testing results and can undermine marketing strategy. Your testing programme is exposed when residential proxy networks generate fake interactions (e.g. click fraud) that appear to come from your target market.

These residential proxies hide behind real household internet connections in the targeted geographic areas. When a bot network routes traffic through Sydney IP addresses to masquerade as real Australians, your analytics counts that traffic as legitimate local engagement. Because the traffic matches your demographic and geographic targeting profile, traditional detection methods become less effective.

This contamination affects the accuracy of the marketing strategy. Your A/B tests should show clear winners, but the results are masked by bot behaviour rather than real user preferences. Marketing teams then optimise campaigns from false signals, wasting budget and time on the wrong opportunities. The data starts driving decisions that harm conversion rates and revenue.

The scale of the problem continues to grow. Residential proxy services now offer millions of local IPs in every market. They rotate these IPs automatically and match real browser characteristics. Without specialised detection such as Peakhour A/B Testing Protection, this traffic can appear identical to genuine users in your analytics.

Each day without detection compounds the damage. Tests generate misleading data that guides strategic decisions. Marketing teams spend hours analysing invalid results and implementing changes that reduce performance. Budget allocated to testing delivers diluted ROI as optimisations based on bot data decrease conversion rates.

Traditional bot protection fails against this distributed threat. IP-based detection cannot identify residential proxy traffic that matches your target geography. Rate limiting proves ineffective against attacks spread across thousands of residential IPs. These bots evade basic JavaScript challenges through sophisticated browser emulation.

Peakhour's A/B Testing Protection uses network fingerprinting to detect residential proxy traffic. Our system analyses subtle patterns in how these proxies connect and behave, identifying bot networks that other solutions miss. We maintain a real-time database of residential proxy services to block new threats as they emerge.

Our customers have discovered that 40% of their test traffic came from bots. After implementing protection, they achieved:

Valid test results reflecting real user preferences
Increased conversion rates from accurate optimisation
Reduced waste of marketing team time and resources
Protection of testing budget from invalid traffic
Confidence in strategic decisions based on clean data

The rise of residential proxies has amplified bot threats to A/B testing. Traffic that appears to come from local users may mask sophisticated bot networks. Protecting your testing programme requires detection that goes beyond IP addresses and basic challenges. Contact us to learn how Peakhour can help secure your A/B testing data and keep optimisation decisions grounded in real users.

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.

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

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

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

The Scale of Bot Traffic

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

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

The Impact on Marketing Strategy

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

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

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

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

The Residential Proxy Challenge

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

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

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

Protecting Your Tests

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

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

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

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

Making Informed Decisions

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

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

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

Taking Action

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

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

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

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

Conclusion

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

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.

The Hidden Cost of Click Fraud

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

Marketing organisations are losing money to automated clicks and fake impressions. These attacks drain advertising budgets and corrupt the data CMOs rely on for strategic decisions. The lost money cannot be recovered, but understanding the scale and mechanics of click fraud helps marketing teams protect future investment and optimise campaigns.

The Scale of Click Fraud

Click fraud now consumes 40% of digital advertising budgets through fake clicks and impressions that never reach real customers. It affects every digital marketing channel, from pay-per-click and display advertising to social media campaigns, retargeting, and video advertising. The damage goes beyond direct financial loss, because it also corrupts the metrics teams use for decision-making.

Our research on bot traffic shows the percentage of fraudulent clicks continues to rise each quarter. Marketing teams that ignore this threat base their strategies on flawed data, which leads to misallocated resources and weaker campaign performance.

How Bots Generate Fake Clicks

Automated bots generate clicks and impressions at scale across digital advertising platforms. These programs target competitor advertisements to drain marketing budgets through fake clicks. They create artificial impressions that inflate metrics and send false engagement signals. Bots also manipulate bidding algorithms and skew attribution data, leading to misallocated advertising resources.

Modern bots use more advanced techniques to evade standard security controls. They mimic human behaviour patterns and rotate through different IP addresses to avoid detection and blocking.

The Residential Proxy Challenge

Residential proxies create a significant obstacle for click fraud detection systems. These proxy services route bot traffic through IP addresses assigned to real consumers' homes and devices, making fraudulent traffic look legitimate to traditional anti-bot tools.

Residential proxy networks build their IP pools through multiple channels. They partner with consumer VPN services, distribute browser extensions, embed code in mobile applications, and in some cases exploit compromised devices. This mix gives proxy operators access to millions of residential IP addresses.

Traditional IP reputation services fail to identify this proxy traffic. Our research demonstrates these services miss up to 96% of residential proxy traffic, leaving advertising campaigns exposed to fraud through these channels.

Impact on Marketing Strategy

Click fraud undermines three core areas of marketing decision-making. First, it distorts campaign performance metrics through false click-through rates and inflated impression counts. The fraud creates skewed conversion data and engagement metrics that mask true campaign performance.

In budget allocation, click fraud wastes marketing spend on non-existent users while reducing campaign ROI. Artificially inflated acquisition costs lead marketing teams to misallocate resources across channels and campaigns.

Strategic planning suffers when data is contaminated across multiple dimensions. A/B testing results become invalid when bots generate fake interactions. Geographic and demographic data lose accuracy due to proxy traffic. Competitive intelligence becomes unreliable as bot activity masks true market dynamics.

Marketing teams that base decisions on corrupted data take on significant risk. Their optimisation efforts target bot behaviour instead of real users. Campaign budgets flow to channels dominated by fraud. Strategic initiatives fail because decisions are based on artificial metrics rather than genuine customer behaviour.

Protecting Your Marketing Investment

Lost money from click fraud cannot be recovered, so marketing teams need protection measures for future investment. Detection forms the first line of defence through continuous monitoring of traffic patterns and IP reputation analysis. Teams track user behaviour to identify suspicious patterns that indicate fraud.

Prevention requires a multi-layered security approach. Marketing teams need systems that block known bot networks and detect residential proxies attempting to generate fake clicks. These controls validate real user traffic and filter out fraudulent clicks before they affect campaigns.

Campaign optimisation becomes more useful once fraud protection is in place. Teams can adjust targeting parameters based on genuine user data and reallocate budgets to channels with verified traffic. This supports updates to bidding strategies and refinement of audience segments based on real engagement.

Our Ad Fraud Protection solution protects marketing investment by blocking bot traffic, detecting residential proxies, and validating real users. This helps ensure ad spend reaches genuine customers rather than fraudulent clicks.

Making Informed Decisions

Understanding click fraud changes how marketing teams analyse data and plan campaigns. Data analysis starts with identifying corrupted metrics in campaign reports. Teams must filter bot traffic from their analytics to measure real user engagement. This enables tracking of true campaign performance based on human interactions.

Budget planning improves once teams understand the scale of click fraud. Marketing teams can allocate resources to channels with verified human traffic. This focus on real users optimises campaign spend and improves return on investment across marketing initiatives.

Strategy development depends on clean, accurate data. Teams make decisions based on genuine user behaviour rather than bot interactions. Campaign planning targets real audience segments with messages that resonate. Performance measurement reflects actual results rather than artificial engagement.

Taking Action

Marketing teams need protection measures across three key areas to secure their investments. First, bot protection forms the foundation through deployment of bot management systems. These systems block automated traffic while validating real users and monitoring for suspicious patterns.

The second protection layer focuses on residential proxy detection. Teams implement proxy detection to identify and block proxy networks. This helps ensure traffic comes from real IP addresses and prevents fraud through residential proxies.

The third component centres on protecting ad spend through traffic monitoring. Teams implement systems to block fraudulent clicks and validate impressions. This enables tracking of real engagement from genuine users.

Our Traffic Control solution combines these protection measures to help marketing teams secure their investments and base decisions on real user data.

Conclusion

Click fraud threatens marketing budgets and corrupts campaign data. Lost money cannot be recovered, but understanding and preventing fraud helps marketing teams protect future investment and make better decisions.

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 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. Residential proxy detection needs real-time analysis of each connection.

Peakhour's residential proxy detection service uses algorithms and machine learning to analyse connections on the fly. We don't just look at where a connection is coming from, but how it behaves, allowing us to spot proxy usage even when it's hiding behind seemingly innocent IP addresses.

Lists of suspect IPs still have a place, but they cannot be the whole answer. Modern proxy detection has to understand the behaviour of network connections.

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 connections.

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

Managing Bots For Application Security

2024-09-15T00:00:00+10:00

This guide separates bot management into three maturity levels: basic, intermediate, and advanced. The point is not to rank feature lists. It is to understand what kind of bot decision each level can safely make on the request path.

Bots now target revenue, data, accounts, inventory, APIs, and origin capacity. Some are obvious crawlers. Others run credential stuffing, account creation, scraping, inventory hoarding, click fraud, or Layer 7 pressure through traffic that looks close to normal. A useful bot control has to decide whether to allow, challenge, rate limit, block, log, or review a request without punishing legitimate users who happen to share a network or device pattern.

For more on account impact, read our article on the Business Impact of Credential Stuffing.

Basic Protection

Basic bot management is built around visible signals: user-agent checks, simple IP reputation, known bot signatures, and broad rate limits. These controls still have a job. They can manage well-behaved crawlers, block obvious automation, and stop a single noisy source from hammering a site.

The limitation is that basic controls assume the source or header tells most of the story. That breaks down when automation behaves like a browser, rotates infrastructure, or spreads requests across residential and shared networks. A flat IP limit may slow one scraper and still miss a credential attack distributed across many exits. It may also catch real users behind a busy office, mobile carrier, or public Wi-Fi network.

Basic protection is suitable when the risk is low, the main concern is crawler hygiene, and the business can tolerate coarse controls. It is not enough for account protection, high-value scraping targets, or API workflows where abuse can arrive through valid requests.

Intermediate Protection

Intermediate bot management adds more request and client evidence. JavaScript signals, header consistency, cookie behaviour, basic network fingerprints such as TLS fingerprinting, and route-level observations make the decision less dependent on the IP address alone. This level can catch automation that fails to behave like a normal browser or that exposes inconsistencies across requests.

It is a meaningful step up, but it still has limits. Anti-detect browsers and modern automation can keep browser signals plausible for long enough to run a campaign. Residential proxy networks can make source reputation noisy. API requests may not run browser-side checks at all. If the bot system treats browser, route, credential, and API context as separate problems, operators end up tuning several partial controls rather than one decision.

Intermediate protection works for general scraping, noisy automation, and non-persistent abuse. It starts to struggle when attackers adapt, slow down, distribute requests, or target sensitive routes where a small number of requests can cause business harm.

Advanced Protection

Advanced bot management is combined signal decisioning. The difference is not "more techniques" in a checklist. The difference is that IP intelligence, residential proxy status, network and browser fingerprints, route-specific rates, behaviour, credential risk, API context, WAF/WAAP findings, DDoS pressure, and logs feed the same action model.

That context changes the decision. A high request rate on a public image route is not the same as repeated failed logins. A suspicious proxy signal on a cached page is not the same as the same signal on account recovery. A browser fingerprint mismatch may be logged on a low-risk page but challenged when paired with exposed credentials and rapid account switching.

Advanced protection is designed for persistent abuse: credential stuffing, account takeover attempts, scraping at scale, inventory hoarding, fake account creation, API bot traffic, and bot-driven Layer 7 floods. It should support web, mobile, and API traffic, and it should preserve evidence so security, platform, and support teams can see which signal drove an action.

Choosing the Right Level

The right level depends on what the bot can damage. A brochure site may only need crawler management and basic rate limits. An ecommerce site needs protection for search, product, checkout, promotion, and account routes. A marketplace, bank, gaming platform, ticketing site, or API-heavy business usually needs route-aware decisions that combine proxy, fingerprint, credential, account, and behaviour context.

The false-positive risk matters just as much as the attack risk. Shared networks, carrier-grade NAT, privacy tools, corporate egress, and normal browser drift can all make a simple signal look suspicious. A mature bot programme does not block every unusual request. It uses uncertainty to pick safer actions: log, challenge, rate limit, or review before escalating to a block.

Peakhour's View

Peakhour's Bot Management connects bot decisions to the rest of the application security path. Residential Proxy Detection, IP Intelligence, Advanced Rate Limiting, API Security, WAAP/WAF controls, and Log Forwarding all support the same request outcome: allow, challenge, rate limit, block, log, or review with evidence.

That is the practical maturity model. Basic controls handle obvious bots. Intermediate controls add client and request evidence. Advanced controls combine signals into decisions that match the route, risk, and business impact.

Application Security for Financial Services Under CPS 234

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

Recent credential stuffing attacks on prominent Australian retailers like The Iconic and Dan Murphy's have brought this threat into sharper focus. For APRA-regulated entities, these incidents are a reminder that credential stuffing is not only an account takeover issue. It can also trigger assessment and disclosure obligations under Prudential Standard CPS 234 Information Security.

The Rising Tide of Credential Stuffing

Credential stuffing is now common in Australia and globally. These attacks exploit password reuse across multiple sites. Cybercriminals use automated tools to test large volumes of stolen username and password combinations against websites, looking for accounts they can access without authorisation.

The scale is large. According to recent studies, there are over 15 billion stolen credentials circulating on the internet. In 2020 alone, one large content delivery network reported more than 193 billion credential stuffing attacks globally. For Australian businesses, the risk is significant and growing.

The Compounding Threat of Residential Proxies

The use of residential proxies has increased the sophistication and effectiveness of credential stuffing attacks. Residential proxies allow attackers to route their traffic through legitimate residential IP addresses, making automated activity look more like normal user behaviour.

This technique poses several challenges:

Bypassing Traditional Defences: Standard IP-based rate limiting and geo-blocking become ineffective when attacks come from diverse, legitimate-looking IP addresses.
Evading Detection: Traffic from residential proxies is harder to distinguish from genuine user activity, complicating detection efforts.
Scalability: Attackers can distribute their attempts across a large network of proxies, allowing for larger-scale attacks without triggering typical alarm thresholds.
Improved Success Rates: By appearing to come from the same geographic area as legitimate users, these attacks are more likely to bypass location-based security measures.

The Crabby Phenomenon

The emergence of sites like Crabby Cash shows how credential stuffing fits into a broader cybercrime market. These platforms serve as marketplaces for compromised accounts, making it easier for criminals to monetise successful credential stuffing attacks.

Key points about Crabby Cash and similar sites:

Ease of Access: These sites lower the barrier to entry for cybercriminals, providing ready access to compromised accounts.
Rapid Exploitation: Once credentials are verified and listed on these sites, the window for detection and mitigation narrows significantly.
Diverse Targets: The range of compromised accounts often spans multiple industries, including retail, financial services, and entertainment.
Ongoing Threat: The existence of these marketplaces incentivises continuous credential stuffing attempts, creating a persistent threat landscape.

The CPS 234 Disclosure Imperative

The prevalence of credential stuffing attacks, compounded by residential proxies and platforms like Crabby Cash, makes the disclosure requirements in CPS 234 directly relevant.

Paragraph 35 of CPS 234 states:

An APRA-regulated entity must notify APRA as soon as possible and, in any case, no later than 72 hours, after becoming aware of an information security incident that:

(a) materially affected, or had the potential to materially affect, financially or non-financially, the entity or the interests of depositors, policyholders, beneficiaries or other customers; or

(b) has been notified to other regulators, either in Australia or other jurisdictions.

The existence of sites like Crabby Cash can increase the potential impact of credential stuffing attacks, making them more likely to meet the materiality threshold for disclosure.

A Risk-Based Approach to Disclosure

To manage credential stuffing risk and meet CPS 234 obligations, organisations should take a risk-based approach to detection, mitigation, and disclosure. This involves:

Working with Specialised Providers: Engage with cybersecurity providers who can offer insights into your organisation's exposure and risk levels based on:
- Network fingerprinting
- Levels of breached credential login attempts
- Prevalence of residential proxy traffic as a high-correlating signal of attack
Continuous Risk Assessment: Regularly evaluate the risk posed by credential stuffing attacks, considering factors such as:
- The volume and sophistication of attempts
- The success rate of attacks
- The potential impact on customers and the organisation
Inadequate Defences as a Risk Signal: Recognise that the absence of robust defences against credential stuffing is itself a risk signal. Organisations without advanced bot detection, multi-factor authentication, and behavioural analysis capabilities may face higher risk and should consider this in their disclosure decisions.
Adaptive Disclosure Thresholds: Develop flexible, risk-based thresholds for APRA notification that take into account:
- The current threat landscape
- The organisation's defensive capabilities
- The potential impact of a successful attack

Assessing Materiality in Light of These Threats

When assessing whether a credential stuffing incident meets the materiality threshold for APRA notification, entities should consider:

Scale of the Attack: The number of accounts targeted or compromised.
Success Rate: Whether any accounts were actually breached.
Exposure on Dark Web Markets: If compromised credentials appear on sites like Crabby Cash.
Potential Financial Impact: Both immediate losses and potential future exploitation.
Non-Financial Impacts: Including reputational damage and loss of customer trust.
Broader Systemic Risk: Whether the attack could impact the wider financial system.
Defensive Posture: The adequacy of existing controls and the organisation's ability to detect and mitigate attacks.

Proactive Measures and Controls

To mitigate the risks of credential stuffing attacks, particularly those leveraging residential proxies, APRA-regulated entities should implement robust controls as outlined in CPS 234 and CPG 234:

Contextual Security Approach: Implement a contextual security strategy that considers multiple factors to assess the risk of each login attempt, including device characteristics, user behaviour patterns, and network attributes.
Advanced Bot Detection: Deploy bot management systems capable of identifying automated attempts, even when they come from diverse IP addresses.
Residential Proxy Detection: Utilise specialised residential proxy detection tools to identify and mitigate threats from this increasingly common attack vector.
Multi-Factor Authentication: As suggested in CPG 234, implement MFA for high-risk activities to provide an additional layer of security beyond passwords.
Behavioural Analysis: Use analytics to detect anomalous login patterns that may indicate credential stuffing attempts.
Continuous Monitoring: Implement real-time monitoring systems to quickly identify and respond to potential attacks.
Password Policies: Encourage or enforce the use of unique, strong passwords to mitigate the impact of credential stuffing.
Customer Education: Proactively inform customers about the risks of password reuse and the importance of strong, unique passwords.
Collaboration and Information Sharing: Engage with industry peers and law enforcement to share threat intelligence and effective practices.
Adaptive Authentication: Implement risk-based authentication that adjusts security requirements based on the perceived threat level of each login attempt.

By adopting these measures, particularly a contextual security approach incorporating residential proxy detection, organisations can improve their resilience against credential stuffing attacks and better protect their customers' accounts.

Conclusion

Credential stuffing, residential proxies, and platforms like Crabby Cash make account takeover risk harder to assess and harder to contain. APRA-regulated entities need a proactive, risk-based approach to information security and regulatory compliance.

APRA-regulated entities should treat credential stuffing attacks as more than a technical control problem. They are business risks that may require Board-level attention and, depending on materiality, regulatory disclosure under CPS 234. By implementing preventative measures, maintaining effective incident response capabilities, and keeping clear processes for assessing and reporting incidents, organisations can better protect themselves and their customers from this growing threat.

In this environment, CPS 234 compliance is not only a reporting exercise. It depends on information security controls that protect the organisation, its customers, and the broader financial system before credential stuffing becomes a material incident.

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.

Account Protection and User Experience in Web Applications

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

Web applications face a wide range of security threats, but customer accounts are often the target. Our recent survey of Australian businesses showed a need for stronger account protection measures. Those controls can add friction for users if they are applied too broadly. This article looks at ways to balance security with user experience in web applications.

The Challenge: Compromised Credentials

Our survey found that 21% of organisations cited reputation loss as their main cybersecurity challenge. That result points back to a practical security problem: compromised credentials.

Causes of compromised logins include:

Phishing attacks
Password reuse across multiple sites
Data breaches exposing user credentials
Credential stuffing attacks
Keylogging malware

These risks make password-only authentication a weak control for customer account protection.

Moving Beyond Traditional Multi-Factor Authentication

Multi-Factor Authentication (MFA) adds a useful security layer, but it can also add friction. Our survey found that only 40% of organisations implement bot protection, which leaves a clear gap around automated attacks.

While 77% of surveyed businesses use MFA, that figure can hide other weaknesses. MFA alone doesn't protect accounts from every attack path.

Learn more about the limitations of traditional MFA

Contextual Security: A User-Focused Approach

Contextual security helps reduce that tradeoff between protection and user experience. It assesses the risk of each login attempt using factors including:

Location of the login attempt
Time of day
Device used
User behaviour patterns
IP address reputation
Network characteristics

By analysing these contextual factors, web applications can apply adaptive authentication without asking every user to complete an extra step every time.

Figure 1: Key factors considered in contextual security

Implementing Contextual Security in Web Applications

To improve account protection without adding unnecessary friction, consider these controls:

Real-time monitoring: Track user activity and detect anomalies.
Adaptive authentication: Adjust security requirements based on the risk level of each login attempt.
Behavioural analysis: Use machine learning to understand user behaviour and flag suspicious activity.
Transparent security measures: Apply checks that don't require additional user actions for low-risk scenarios.
Risk-based access controls: Apply stricter security measures for high-risk actions or sensitive data access.
Bot protection: Detect and mitigate automated attacks.
API security: Protect APIs from abuse and unauthorised access.
Residential proxy detection: Identify and mitigate threats from residential proxy networks.

For web applications, the goal is targeted control rather than blanket friction.

The Role of User Education

User education still has a place in a security strategy. Training and awareness programs can help users understand:

The importance of strong, unique passwords
How to identify phishing attempts
The risks of password reuse across multiple sites
The importance of keeping software and devices updated
How to recognise and report suspicious activities

User education works best when it supports technical controls rather than carrying the whole burden.

Addressing Mobile Application Security

Our survey indicates a potential gap in mobile security strategies. As mobile apps take on operations like banking and e-commerce, they become part of the application attack surface.

Only 30% of respondents implement Web Application and API Protection (WAAP), indicating many businesses may not be ready to protect their mobile assets. That gap leaves mobile applications exposed to attacks, including API abuse and data exfiltration.

The Threat of Residential Proxies

Our survey found that only 15% of organisations use residential proxy detection. That low adoption rate leaves a weakness in many businesses' security postures.

Residential proxies can threaten account security by:

Bypassing traditional IP-based rate limiting
Evading geolocation-based restrictions
Facilitating large-scale credential stuffing attacks
Enabling undetected data scraping

Businesses should consider security providers that can detect and mitigate residential proxy threats.

Learn more about residential proxy detection

Finding the Balance

Balancing account protection and user experience in web applications requires more than a single control. By implementing contextual security measures, organisations can:

Improve security without unnecessary impact on user experience
Adapt to threats in real-time
Reduce the risk of compromised credentials and account takeovers
Protect against threats like residential proxies and mobile application vulnerabilities

As threats change, account protection needs to change with them. Contextual security gives organisations a practical way to protect users and their reputation.

The Cost of Credential Stuffing

2024-07-17T00:00:00+10:00

In recent months, Australian businesses have faced a wave of credential stuffing attacks. These attacks do not require the affected website itself to be breached. They target customer accounts, leading to fraudulent transactions. The damage is practical as well as reputational: disputed purchases, refunds, locked accounts, and customers asking how someone else was able to use their account.

What is Credential Stuffing?

Credential stuffing occurs when attackers use login details obtained from a data breach to access accounts on other sites. Criminals test millions of credentials against a target website to identify working combinations. This attack affects users who reuse passwords across multiple services [1].

The Scale of the Problem

Tens of thousands of Australian online accounts are reported to have been accessed since late November 2023 [2]. The attacks affected major retailers and service providers, including:

The Iconic
Guzman y Gomez
Dan Murphy's
Event Cinemas
Stan

The Impact

While reusing passwords between sites has long been considered poor security practice, users still do it. Blaming the customer, as 23andMe did in its response to an attack, is not a serious account protection strategy. Over 70% of Americans believe that websites have a responsibility to prevent account takeovers via stuffing attacks. Not doing so can negatively impact a business in several ways.

Financial Impact

The cost can fall on either the affected business or the affected customer. Fraudsters made significant purchases using compromised accounts. One scammer claimed to have spent over $800 on high-end alcohol at Dan Murphy's [2]. Others bought iPhones and clothing. Either the customer will be out of pocket, or the business when the customer issues a chargeback on the purchase.

Reputation Damage

The attacks leave businesses dealing with customer complaints, refunds, and visible questions about account security. The Iconic pledged to refund affected customers [1]. Dan Murphy's confirmed that a "small number of user accounts were subject to fraudulent transactions" [3].

Customer Trust

These incidents erode customer trust. Users expect businesses to make account abuse difficult, even when the original password leak happened somewhere else. When accounts are taken over, customers question the security practices of the affected companies.

Business Response

Companies responded by:

Locking compromised accounts
Issuing refunds
Encouraging customers to change passwords
Implementing stronger security measures

Dan Murphy's advised customers to "practise good password hygiene, using a strong password and changing it periodically" [3].

Prevention Strategies

To protect against credential stuffing, businesses should:

Implement multi-factor authentication
Educate customers about password security
Monitor login behaviour on their website
Implement, and regularly update, security measures, including bot management and advanced rate limiting.

Credential stuffing is not just a password reuse problem. It is an account protection problem, and businesses that sell online need controls that make stolen credentials harder to turn into purchases.

Sources:

[^1^] ABC News: "The Iconic was hit by criminals taking money by 'credential stuffing'. How can you stay safe?" [^2^] Cyber Daily: "Guzman y Gomez, Dan Murphy's customers affected in credential stuffing campaign" [^3^] The Sydney Morning Herald: "Thousands of Australians hacked in 'credential stuffing' credit card scam"

2024 Survey Insights

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

Our recent survey of Australian CISOs and CTOs looked at account protection controls, planned security measures, and how teams are responding to credential stuffing and residential proxies. Key findings:

Multi-Factor Authentication (MFA) Adoption: 76.23% of Australian businesses use MFA, showing broad adoption of a baseline account security control.
Bot Protection: Currently implemented by 39.34% of organisations, with an additional 34.65% planning to adopt it.
Bot Management Solutions: Cloudflare is the most common bot management provider in the survey, used by 48.24% of respondents.
Residential Proxy (Resip) Detection: Only 13.11% of organisations currently use this technology, although many plan to implement it to address residential proxy traffic.
Credential Stuffing Concerns: Businesses are planning measures to reduce credential stuffing risk, including bot protection, MFA, and checking credentials against known breaches.
Mobile Security Gap: Low adoption of Web Application and API Protection (WAAP) suggests gaps in mobile application security.
Executive vs. Engineer Priorities: The survey showed different cybersecurity priorities between executives and engineers.

These findings point to the need for account protection strategies that go beyond MFA and address automated traffic, breached credentials, and residential proxies.

2024 Survey Insights

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

Recent customer account takeovers have put account protection back on the agenda for Australian businesses. Our 2024 survey of Australian CISOs and CTOs shows how respondents are using MFA, bot protection, WAAP and residential proxy detection to manage credential stuffing and account takeover risk.

Account Protection: Current State and Future Plans

Our survey found 76.23% of Australian businesses use Multi-Factor Authentication (MFA). MFA is widely adopted, but it is not a complete account protection strategy on its own.

39.34% of organisations currently use bot protection. That matters because credential stuffing is automated by design. Another 34.65% of businesses plan to implement bot protection in the future.

The pattern is clear: many organisations are treating MFA as a baseline and looking at additional controls around it.

Current Bot Management Solutions

The survey also asked which bot management solutions Australian businesses currently use. Cloudflare was the clear leader, with nearly half of respondents using its services.

The breakdown of bot management solutions is as follows:

Cloudflare: 48.24%
AWS WAF Bot Ruleset: 10.59%
Other solutions make up the remaining percentage

This distribution is concentrated around Cloudflare. Outside that, the remaining respondents are spread across other solutions rather than one clear alternative.

Tooling matters here. Residential proxy traffic weakens IP reputation and simple rate limits, so detection capability, request grouping and response controls matter as much as vendor name. If residential proxies continue to feature in credential stuffing tooling, this mix may shift as teams look for more advanced protection measures.

The Rising Threat of Residential Proxies

A key finding from our survey is the low adoption rate of residential proxy (resip) detection, with only 13.11% of organisations currently using this technology. Planned adoption suggests teams are starting to account for the risk, but current coverage is still low.

Resips are difficult for account security teams because malicious traffic can look like normal ISP traffic. They enable attackers to:

Bypass traditional IP-based rate limiting
Evade geolocation-based restrictions
Conduct large-scale credential stuffing attacks
Scrape sensitive data undetected

The planned adoption of resip detection points to a shift in security strategies, away from simple IP-based controls and towards more specific network signals.

Learn more about the threat of residential proxies and how to detect them

Credential Stuffing: A Persistent and Growing Concern

Credential stuffing attacks continue to be a major concern for businesses. These attacks exploit password reuse across multiple sites, allowing attackers to gain unauthorised access to user accounts.

Respondents said they plan to implement several measures to reduce credential stuffing risk:

34.65% plan to implement bot protection
32.67% intend to add multi-factor authentication
31.68% aim to check credentials against known breaches

These plans point to layered account protection rather than reliance on one control.

Mobile Applications: An Emerging Attack Surface

While mobile applications were not directly addressed in our survey, the data suggests a possible gap in mobile security strategies. The low adoption rate of Web Application and API Protection (WAAP) - implemented by only 27.87% of respondents - indicates many businesses may be underprepared to protect their mobile assets.

As mobile apps become primary interfaces for critical operations, this gap leaves businesses exposed to attacks that use the same automation and resip infrastructure seen on web login flows.

Balancing Security and User Experience

The operational problem is familiar: increase assurance without making login unusable. Key considerations for enhancing account protection while preserving usability include:

Expanding beyond MFA
Implementing bot protection
Adopting WAAP solutions
Monitoring credential leaks
Focusing on API security
Implementing residential proxy detection

Explore strategies for balancing security and user experience

Executive vs Engineer Perspectives

Our survey found differences in cybersecurity priorities between executives and engineers:

Figure 3: Comparison of cybersecurity priorities between executives and engineers

The gap matters because budget, architecture, and incident response are often owned by different teams. Account protection plans need to cover both executive risk concerns and engineering realities, including the threat from RESIPs.

Final Thoughts

Our 2024 survey results point to a simple position: MFA is widely used, but it is not the whole account protection strategy. Bot protection, breached credential checks, WAAP and residential proxy detection are still unevenly adopted. That matters because credential stuffing does not depend on one weakness; it combines reused credentials, automation, proxy networks and weak response controls.

Australian businesses do not need every control at once, but they need a layered plan that reflects how account takeover attacks are run now. For teams reviewing their controls, resip detection and mobile/API coverage are worth checking explicitly because both are easy to miss if the programme is still centred on MFA and IP reputation.

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.

How To Exclude Query String Parameters from Search Engine crawling

2024-05-21T13:00:00+10:00

Last year we wrote about the problem of excessive crawling from search engine spiders. Search engines such as Google and Bing aim to index as much content as possible. For ecommerce sites, this often means indexing pages with query string parameters used for sorting, filtering, or pagination. Those parameters help users navigate the site, but they can cause a few predictable crawler problems:

Over-Crawling: Search engines may spend too much time crawling similar pages with different parameters, wasting crawl budget.
Duplicate Content: Pages with different parameters can be treated as duplicate content, weakening SEO performance.
Server Load: Excessive crawling can increase server load, slow down your site, and affect user experience. Search engines typically account for 30-50% of page requests to an ecommerce store. Managing their crawling effectively can have a material effect on site speed and server spend.

Another common cause of over crawling is internal searches being indexed.

In our previous article we mentioned using the webmaster tools provided by Google and Microsoft to manage crawler behaviour by adding ignored parameters. Since then, both tools have been updated and no longer allow you to add parameters to ignore during a crawl.

Differences in Crawling and Indexing

Search engines maintain an 'index' of web pages. Pages in this index are what appear in search results. To maintain the index, the search engine crawls a website to 'discover' new content and keep existing entries up to date. Webmasters can control what gets indexed with tags or headers in their web pages. These include:

Canonical Tags can be used to indicate the preferred version of a page. This helps consolidate link 'juice' and tell the search engine which URL to index.
Noindex tags can be used to prevent specific pages from being indexed. This is useful for thank you pages, admin pages or any content you don't want to appear in search results.
Nofollow links can be used to indicate to a search engine not to pass on SEO value to the linked page.

However, controlling what does or does not get indexed does not prevent content from being crawled. The only way to do that is via the robots.txt file. You may be familiar with the Disallow directive in the robots.txt file, but you can also use wildcards to prevent crawling of url parameters.

An example...

Consider an ecommerce store that has a category page which can then be customised with the following parameters:

    orderBy
    colors
    brands
    page
    results

These may appear in any order, and the combinations can result in 100s or even 1000s of variations of essentially the same page. Google is fairly smart when presented with this scenario, but Bing.... Bing can crawl very aggressively and it likes to try everything. In our example above, we may want to stop crawling everything except the page number, in which case an effective way to control crawler behaviour would be:

    User-agent: *
    Disallow: /*?*orderBy=*
    Disallow: /*?*colors=*
    Disallow: /*?*brands=*
    Disallow: /*?*results=*

We can't really do this in a single Disallow because the parameters might be in any order. By including the ? in the url we're ensuring that the parameter names are only in the query string, not in the main url path. This prevents crawlers from wasting crawl budget and putting unnecessary load on server resources.

Final Thoughts

Search engines can often make up 30-50% of the overall page requests to a website. Managing their behaviour helps maximise useful crawling and minimise server utilisation. Keep an eye on your access logs for unwanted behaviour, and use robots.txt where it gives you the right level of control.

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.

The Iconic is the latest Account Takeover victim in the news

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

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

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

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

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

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

Why are Account Takeover attacks carried out?

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

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

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

How are Account Takeover attacks carried out?

Common techniques used to compromise user accounts on websites include:

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

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

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

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

What can users do about it?

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

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

What can websites do about it?

Quite a bit. Websites can minimise the risk by:

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

Preventing automated log in attempts

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

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

Conclusion

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

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

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

HTTP Security Headers

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

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

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

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

Key HTTP Security Headers

Content-Security-Policy (CSP)

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

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

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

X-Frame-Options

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

X-Frame-Options: DENY

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

X-Content-Type-Options

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

X-Content-Type-Options: nosniff

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

X-XSS-Protection

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

X-XSS-Protection: 1; mode=block

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

Strict-Transport-Security (HSTS)

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

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

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

Conclusion

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

RFC 9460

2023-11-16T00:00:00+11:00

RFC 9460 introduces two DNS record types: "SVCB" (Service Binding) and "HTTPS". They let browsers learn more connection details during DNS lookup, before redirects and TLS negotiation add extra steps. The result is cleaner connection setup, with practical improvements in speed, security, and efficiency.

Understanding the Current Process

Traditionally, when a browser connects to a website, it follows a sequence:

Browser requests site via HTTP.
Server redirects request to HTTPS.
Browser receives ALPN (Application-Layer Protocol Negotiation) during the HTTPS handshake.

The model is secure, but it is not optimal. It involves multiple round trips, which affects Time to First Byte (TTFB) and the overall user experience. Load balancing and failover are also less direct than they could be. RFC 9460 changes this by allowing DNS to provide the necessary connection details earlier. That reduces the steps involved in establishing a secure connection, lowering TTFB.

The Impact of SVCB and HTTPS Records

SVCB and HTTPS records move useful connection hints into DNS. They speed up the time-to-first-packet by incorporating the Alt-Svc HTTP header and ALPN TLS extension into DNS, which shortens connection setup. These records also enable redirection at the zone apex, a task not possible with CNAMEs. They simplify DNS load distribution and failover, making web services more resilient. They also remove the need for HSTS preloading and support Encrypted Client Hello (ECH), formerly ESNI, for better privacy.

Adoption and Industry Response

Adoption started before the RFC was finalised. Firefox has been conducting HTTPS lookups since May 2020, limited to DNS over HTTPS (DoH). Apple's iOS, Safari, and macOS have followed suit since September 2020. Chrome introduced partial support in December 2020 and has recently enabled ECH by default. Various DNS service providers have also started supporting HTTPS and SVCB records.

As reported on Netmeister, adoption is still early but not insignificant. As of October 2023, about 10 million domains have implemented an HTTPS record for their 'www' service names, roughly 4.4% of domains. Around 9.1 million domains, or about 4.0%, use the record on their bare second-level domain name. Among the top 1 million domains, approximately 22.5K (25.5%) use HTTPS records for 'www' service names, and nearly 24K (25.6%) use them on bare domains.

What the Records Look Like

A typical SVCB record might look like this:

_example.com. 7200 IN SVCB 1 svc4.example.net. (alpn="h2,h3" port="8004")

This record indicates that the service at _example.com can be accessed at svc4.example.net using either HTTP/2 or HTTP/3 on port 8004.

An HTTPS record could be:

example.com. 3600 IN HTTPS 0 svc.example.net.

This record suggests that example.com should be accessed securely through svc.example.net.

Apex Domains and the Importance of SVCB/HTTPS Records

One long-running DNS limitation is the inability to use CNAME records at the apex (root level) of a domain due to conflicts with other necessary records like NS and SOA. RFC 9460's SVCB/HTTPS records address this by enabling apex domain aliasing without those conflicts. This matters for efficient content delivery networks (CDNs) and load balancing strategies.

These records enhance capability

1. Load Balancing:

Consider a website that needs to distribute traffic across multiple servers. SVCB records can indicate different server endpoints with varying priorities.

example.com. IN SVCB 10 server1.example.com. (alpn="h2,h3")
example.com. IN SVCB 20 server2.example.com. (alpn="h2")

In this example, server1.example.com is the preferred endpoint (lower priority number), offering both HTTP/2 and HTTP/3 protocols. If it's unavailable, traffic automatically shifts to server2.example.com.

2. Failover Mechanism:

For a service that requires high availability, SVCB records can express failover directly:

critical-service.example.com. IN SVCB 1 primary-service.example.com. (alpn="h2,h3")
critical-service.example.com. IN SVCB 2 backup-service.example.com. (alpn="h2")

Here, primary-service.example.com is the primary endpoint. If it fails, the system automatically falls back to backup-service.example.com.

3. Apex Domain Usage:

A practical advantage of SVCB/HTTPS records is their ability to handle apex domains, where CNAME records are not feasible. This is important for root domain aliasing to different service providers.

example.com. IN HTTPS 0 cdn-provider.example.net.

This record indicates that the apex domain example.com is to be served through cdn-provider.example.net, overcoming traditional DNS limitations.

4. Encrypted ClientHello Support:

Future enhancements of SVCB could include keys for Encrypted ClientHello, which improves privacy and security during the initial TLS handshake.

secure.example.com. IN SVCB 1 tls-service.example.net. (ech="base64-encoded-key")

This record can be used to initiate a TLS connection with tls-service.example.net using the provided Encrypted ClientHello key.

5. Directing Traffic to Specific Protocols:

For services that need to direct clients to newer or more efficient protocols, SVCB records can specify the exact protocols to use.

api.example.com. IN SVCB 1 api-server.example.com. (alpn="h3")

Clients that understand HTTP/3 can connect directly using this protocol, bypassing the usual HTTP/1.1 or HTTP/2 protocols.

The Long Wait

HTTPS has been around for a while, so RFC 9460 raises an obvious question: why did this take so long? Apex records have had their share of problems, including not being able to use CNAMEs and having to resort to custom records like ALIAS or Cloudflare's 'cname flattening'.

It is a fair question. We've had some bizarre records hanging around for ages along with a wide range of solutions to the "CNAME at the zone apex" problem.

Credit to the creators of RFC 9460 for getting this through and obtaining browser support: - B. Schwartz from Meta Platforms, Inc. - M. Bishop from Akamai Technologies - E. Nygren from Akamai Technologies

Final Thoughts

RFC 9460 gives DNS a more useful role in HTTPS connection setup. SVCB and HTTPS records let operators publish endpoint, protocol, failover, and privacy information before the browser starts negotiating the connection. That gives service providers more precise control over how clients reach web services, with practical benefits for performance, reliability, and security.

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.

Enterprise-Level Caching for All

2023-11-02T13:00:00+11:00

We've released our Magento 2 plugin for e-commerce stores using Magento. It brings Peakhour's caching features into Magento, including capabilities that other providers often reserve for enterprise plans. With Peakhour, 'Enterprise for Everyone' means making those features available to all customers, regardless of plan.

Why Cache Tags Matter

Cache tags solve a practical website management problem: keeping your cache current when content changes. In Magento 2, a single change, such as updating a product's price, can affect multiple pages. Cache tags ensure that only the relevant cached content is updated, maintaining cache efficiency and reducing server load. That matters for website speed and user experience, which directly affect sales and SEO rankings.

Enterprise for Everyone

While other providers offer cache tags only in expensive enterprise plans, Peakhour makes this feature available to everyone. Our infrastructure and caching algorithms make that possible. We also offer other enterprise-level features, including DDoS protection, real-time analytics, and custom caching rules, so 'Enterprise for Everyone' is reflected in the product rather than just the plan names.

Peakhour vs. Magento and Varnish Caching

Our plugin goes beyond Magento's built-in caching and Varnish cache in several ways:

Custom Cache Tags: Unlike Magento's built-in cache, we offer custom cache tags for more granular cache control.
Advanced Algorithms: Our caching algorithms go beyond Varnish, helping improve cache hit rates and lower server load.
Additional Features: With Peakhour, caching sits alongside real-time analytics, DDoS protection, and custom caching rules, features often missing in standard Magento or Varnish setups.

Expected Performance Improvements

By using Peakhour's Magento 2 plugin, you can expect performance improvements:

Faster Page Loads: Our caching can reduce page load times by up to 50%, giving users a smoother experience.
Reduced Server Load: Efficient caching means fewer requests to your origin server, reducing server load by as much as 70%.
Improved SEO: Faster websites are favoured by search engines, which can improve SEO rankings.
Higher Conversion Rates: A faster website gives users a better experience, which can lead to higher conversion rates and increased sales.

Installation Options

You can install the Magento 2 plugin through Magento Connect, Composer, or a ZIP file. For more detail, see our plugin page.

Useful tips to accelerate your Magento store

2023-11-01T13:00:00+11:00

Out of the box, Magento is not the fastest ecommerce platform. Magento 2 is built with Full Page Cache in mind, so repeat page requests do not always have to hit the application. A slow Magento store can frustrate customers, increase bounce rates, and cost sales. There are several practical ways to accelerate your Magento store and improve the user experience. These are good places to start.

Caching is King

Caching is usually the biggest performance lever for a Magento store. By storing pre-generated versions of pages, you reduce server response times and avoid asking Magento to rebuild the same page for every request.

Full Page Caching (FPC): Magento includes built-in FPC, but it can be extended. Varnish is a common choice for this role. Magento 2 has native support for Varnish, which acts as a web application accelerator.
Redis: Use Redis for session and cache storage. It is an in-memory data structure store that can speed up backend operations by reducing database load.
Edge Caching: Use Peakhour Edge to cache your dynamic pages close to users. This serves content from a nearby delivery path and reduces latency. Peakhour's Magento 1 and Magento 2 plugins make this straightforward to set up.

Optimise Your Images

Images often make up the bulk of a page's weight. Optimising them is one of the simplest ways to improve load times.

Compression: Use image compression tools to reduce file sizes without a noticeable loss in quality.
Next-Gen Formats: Serve images in modern formats like WebP or AVIF, which offer better compression. A CDN can often handle this conversion automatically.
Lazy Loading: Implement lazy loading for images that are "below the fold" (not immediately visible). This means they only load when they are about to enter the user's viewport.

Minify and Merge CSS/JavaScript

Magento has built-in features for merging and minifying CSS and JavaScript files.

Minification: Removes unnecessary characters (like whitespace and comments) from code to reduce file size.
Merging: Combines multiple CSS or JavaScript files into a single file to reduce the number of HTTP requests.

Note: Always test thoroughly after enabling merging, as it can sometimes cause issues with certain themes or extensions.

Keep Your Environment Updated

The environment your Magento store runs in has a direct effect on performance.

Latest PHP Version: Use the latest stable version of PHP supported by your Magento version. Each new release brings performance and security improvements.
Server Resources: Ensure your server has adequate RAM and CPU power to handle your traffic, especially during peak times.
Web Server: Use a high-performance web server like Nginx, which is known for its speed and efficiency.

Use Edge Caching and Delivery

An edge delivery layer is a practical requirement for many ecommerce stores. It caches your static assets (images, CSS, JavaScript) close to users.

Reduced Latency: Users receive content from the server geographically closest to them, which speeds up load times.
Reduced Origin Load: By serving cached content, an edge cache reduces the number of requests that hit your origin server, improving its performance and stability.
Enhanced Security: Peakhour also offers security features like a Web Application Firewall (WAF) and DDoS protection.

Database Optimisation

A slow database can slow the whole store.

Clean Logs: Regularly clean out Magento's log tables (e.g., log_customer, log_visitor). These can grow very large and slow down database queries.
Enable Flat Catalog: For Magento 1 and older versions of Magento 2, enabling the Flat Catalog for products and categories can improve performance by reducing the complexity of database queries.
Re-index Regularly: Keep your Magento indexes up to date. A cron job should be set up to handle this automatically.

Audit Third-Party Extensions

Poorly coded or unnecessary third-party extensions are a common cause of Magento performance issues.

Review Extensions: Audit your installed extensions regularly. If you're not using one, disable or uninstall it.
Use a Profiler: Use Magento's built-in profiler or a tool like New Relic to identify slow-running code, which can often be traced back to a specific extension.

These changes will not fix every Magento performance problem, but they cover the areas that usually matter first: cache behaviour, asset weight, the hosting environment, database maintenance, and extension overhead.

Navigating CDN Consolidation

2023-11-01T00:00:00+11:00

The CDN industry is moving quickly, with major providers such as Akamai and Cloudflare consolidating their positions. For businesses caught in that movement, changing CDN providers is rarely a simple swap. Your CDN sits in front of your website or application, so migration decisions touch performance, security, routing, caching, and operational risk.

Market Shifts in the CDN Industry

The CDN market is being reshaped by large providers and newer entrants. Akamai's acquisition of Linode is one example, expanding its cloud services and strengthening its position beyond CDN. Cloudflare is moving in a similar direction, adding cloud-based services around its CDN platform.

Akamai's Strategic Moves

Akamai has recently bought customer contracts from both Lumen and StackPath. This is likely to lift its 2024 revenue by tens of millions of dollars. The transferred customers will also benefit from Akamai’s wider cloud and security services.

Azure CDN Standard from Akamai, StackPath CDN, and Lumen CDN are all going offline soon. Clients have received only 2-3 months' notice to migrate, which is a tight window for a service that usually has routing, security, caching, and origin dependencies. Vendors should avoid putting customers in this position. A multi-CDN strategy can reduce that exposure.

What Happened to Section.io?

Section.io, once a CDN, shifted to edge computing before being sold to Webscale. That leaves approximately 300 Australian websites looking for new service providers. If you are one of them, now is the time to act.

These moves make the decision to switch or stay with a CDN provider more complex, especially for smaller businesses that need flexible and reliable local alternatives such as Peakhour. Switching your CDN is not as straightforward as changing a DNS record. Your CDN acts as the gateway to your website or application, so a move can involve reconfiguring a large part of the delivery stack.

Why Peakhour Is the Right Choice

Peakhour is a local, reliable alternative in an industry changing quickly. We offer the flexibility needed for customisation and a full suite of services.

If you are considering a CDN switch, treat it as a technical migration rather than a procurement task. Peakhour can help make that transition smoother.

Peakhour's Top 10 Things to Consider When Changing Providers

Switching CDNs? Work through these ten factors before you move:

Caching Rules: Use the migration to review and optimise your caching settings.
POP Distribution: Understand how the new CDN's points of presence may affect your traffic.
Security Gaps: Evaluate how the new CDN's security measures compare to your current provider.
Access Lists: Make sure IP whitelists and blacklists are carried over cleanly.
Origin Security: Update IP addresses to ensure your origin server recognises the new CDN.
SSL/TLS Certificates: Confirm the new CDN supports your existing SSL/TLS settings and can carry over the certificates you need.
API Compatibility: Ensure the new CDN offers APIs that match or exceed your current usage.
Analytics and Monitoring: Assess if the new CDN's analytics tools meet your needs.
Rate Limiting: Review the new CDN's rate limiting options, especially if your site experiences traffic bursts.
Costs: Account for migration work, potential downtime, and any hidden fees.

Additional Considerations for a Seamless Transition

Beyond the top ten, also consider:

Bot Protection: Evaluate how the new CDN manages automated traffic.
User Agent Validation: Make sure the new CDN effectively screens search engine bots.
IP Reputation Lists: Know how your new CDN updates and uses IP reputation lists.
API Protection: Confirm that the new CDN provides strong API security controls.
Dynamic Page Caching: Check how the new CDN handles caching for dynamic content.
Query String Handling: Understand how your new CDN treats query strings, as this can affect cache performance after migration.

Special Concerns for E-commerce Sites

For e-commerce, also think about:

Site Integrations: Does the new CDN support plugins for your platform, such as Magento?
Custom WAF Rules and Exceptions: Ensure these can be moved to the new CDN.
Image Optimisation: Update Image APIs if your CDN handles image transformations.

Advanced Configurations

Advanced setups need closer review:

Origin Mounting: Confirm your multiple origins will work as needed with the new CDN.
Request Routing: Make sure you can replicate your existing routing configurations with the new provider.
Edge Redirects: Ensure the new CDN can handle any redirects you’ve configured at the edge.

Google Chrome's "IP Protection" vs Apple Private Relay

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

Google Chrome's "IP Protection" vs. Apple's iCloud Private Relay

Google and Apple are both pushing browser-level privacy features that reduce how much a website can infer from a user's IP address. Google's recent announcement of its "IP Protection" feature for Chrome follows Apple's iCloud Private Relay, but the two approaches are not the same.

Apple's iCloud Private Relay: A Closer Look

In 2021, Apple introduced iCloud Private Relay for paid iCloud+ subscribers. The feature encrypts traffic from the user's device and routes internet requests through two separate relays. The intention is to stop any single party, including Apple, from building a comprehensive user profile from IP address, location, and browsing activity.

However, this feature is specific to Apple's Safari browser. It is not a full VPN; it is a browser-centric service that protects Safari traffic on iOS, iPadOS, and macOS. The user's internet requests are routed first through an Apple server, then through a partner network like Akamai, Cloudflare, or Fastly, before reaching the intended destination. This dual-hop design means neither party has a complete view of both the user's IP address and the browsing destination.

Google's "IP Protection": Playing Catch-up?

Google's "IP Protection" for Chrome appears to be an answer to Apple's initiative. By masking users' IP addresses using proxy servers, Google aims to preserve user privacy while keeping essential web functions working. Unlike Apple's solution, which is limited to Safari, Google's feature potentially has wider application within the Chrome ecosystem.

However, Google's solution is still early, with phased implementation and limited domain application. Apple has already integrated and offered iCloud Private Relay to its users; Google is still testing its feature.

Can Apple Allow Google's Feature on Chrome?

Given the competitive nature of the technology industry, it remains uncertain whether Apple will allow Google's IP Protection feature on Chrome for Apple devices. With iCloud Private Relay already in place, Apple may see Google's feature as redundant or conflicting with its privacy objectives.

The Bigger Picture: Ad Tracking and Platform Control

Both companies present these changes as privacy improvements, but the platform context matters. Hiding IP addresses does not remove ad tracking, and privacy features can also reinforce platform control. By making privacy protections part of their own browsers and ecosystems, Google and Apple can reduce some third-party visibility while keeping users inside platforms they operate and measure.

Apple's iCloud Private Relay and Google's "IP Protection" both improve some aspects of user privacy, with different approaches and coverage. As Google plays catch-up to Apple in this area, users should understand what these features do and what they leave in place. The goal should be genuine online privacy, and as we've discussed in our article on TLS fingerprinting, network-based fingerprinting is becoming increasingly important for protecting services in this changing environment.

An Overview of JA4+ Network Fingerprinting and Its Implications

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

JA4+ is a suite of modular network fingerprints. It succeeds the 2017 JA3 standard for TLS fingerprinting, refining and extending the model from a single method into a broader toolset for network fingerprinting.

The Essence of JA4+

JA4+ provides a set of fingerprints for multiple protocols. Each component of a signature—expressed in an a_b_c format—stands alone for more granular inspection. That structure lets you focus on targeted parts of the fingerprint while keeping the design simple enough to extend.

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.

The Quest for Fidelity: A Peakhour Experiment

JA4+ brings a useful change in the sorting of TLS cipher extensions, especially because cipher suites often appear in random order. Peakhour's experiments, however, highlight the need for caution with TLS cipher ordering in the signature, which was implemented to reduce the impact of cipher stunting. Our tests showed a loss of fidelity. This is why logging raw signatures remains important. It preserves the flexibility needed for detailed post-analysis, including fidelity loss and implementation variations.

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

Google Chrome's recent initiative to randomise a portion of the TLS fingerprint highlights the need for sorting. While this move aimed to stop server implementers fixating on Chrome's fingerprint, the outcome was not fully anticipated. Peakhour's data suggests that the number of unique fingerprints soared after the Chrome update, making it almost impossible to identify the Chrome network stack through TLS fingerprint alone. Sort normalisation of the TLS Extensions solves this problem whilst maintaining almost 99% signature fidelity.

The H2 Signature Choice

Peakhour opts for the H2 signature over the HTTP signature to enhance fidelity. JA4+ does not include an H2 signature, which is a detail worth noting.

Nod to the Pioneers

Before digging further into JA4+'s features and limitations, it's worth acknowledging its predecessors. The Cisco Mercury format has significantly shaped network fingerprinting. Its preference for raw signatures aligns with JA4+ and offers a proven method for handling diverse signature production. The original JA3 also laid important groundwork (by the same author as JA3).

Trade-offs and Future Avenues

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. JA4 tries to address this with open-source app support.

A New Chapter in Network Fingerprinting?

JA4+ is a notable development in network fingerprinting. Its applicability, modularity, and extensibility make it useful for threat-hunting and advanced security analysis. As the method continues to evolve, future enhancements and applications are worth watching.

For contribution and discussion, the official JA4+ repository is available. It is an open platform for the community to discuss, develop, and refine the toolset.

We welcome the overall initiative and the renewed interest in fingerprinting that JA4+ has sparked. It is a practical next step in network security.

Google Chrome's "IP Protection" and Online Privacy

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

Google plans to introduce an "IP Protection" feature in Chrome. The feature is intended to improve privacy by masking IP addresses through proxy servers. It may also affect ad tracking and who controls access to online platforms.

Understanding IP Addresses and Google's Strategy

IP addresses can let websites follow user activity across platforms. Over time, that can build detailed profiles and create real privacy concerns. Google's "IP Protection" is designed to reduce that signal by sending third-party traffic through proxies, hiding user IPs. The feature will start as optional, then focus on domains thought to track users.

At first, Google will use a dedicated proxy for its own domains. As testing continues, the system may change. Google is also considering a 2-hop proxy system for better privacy, with an outside CDN handling the second proxy.

Google wants to use proxy connection IPs to give users broad locations, not exact ones. It will test this on platforms like Gmail and AdServices, in Chrome versions 119 to 225.

VPN Growth and Other Browsers

The growth of VPN use points to demand for online privacy. VPNs, like Google's IP Protection, hide user IP addresses. Firefox and Opera have added VPN features to their browsers. Apple, known for user privacy, has worked with CDN companies on similar privacy improvements.

This change has trade-offs. Sending traffic through Google's, or others', servers can make it harder for security teams to handle threats. Google has suggested fixes like checking users with the proxy and rate-limiting to tackle these problems.

What It Means

Traditional safety tools like IP reputation and GeoIP methods are becoming less reliable. This change highlights the role of network-based fingerprinting now. For more on this, read our article on TLS fingerprinting.

While firms talk about hiding IP addresses, ad tracking is still common. These changes might also push users to certain platforms. Even if users think they're safe, big tech's tracking tools can still watch them. That can give users a false sense of safety. Real privacy still needs practical tools and clear public understanding.

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.

HTTP/2 Rapid Reset Attack Deepdive

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

Distributed Denial of Service (DDoS) attack vectors keep changing. The recent spike in HTTP/2-based DDoS attacks has been notable for its volume, with some attacks surpassing 398 million requests per second. Peakhour observed these attacks and worked through how to understand and mitigate them. This article explains how they work and what operators can do to reduce exposure.

The Rise of HTTP/2 in DDoS Attacks

HTTP/2 was designed to make web traffic more efficient. The same features that improve performance for legitimate users can also be abused in DDoS traffic.

Much of HTTP/2's efficiency lies in "stream multiplexing." It allows multiple messages to be sent over a single TCP connection. While HTTP/1.1 processes each request serially, HTTP/2 can manage multiple concurrent streams on a single connection. This means a client can send multiple requests in a single round trip, increasing how much work each connection can drive.

The 'Rapid Reset' Attack Explained

The "Rapid Reset" attack is a specific DDoS technique built around HTTP/2. The attacker starts by opening multiple streams, much like in a standard HTTP/2 attack. However, instead of waiting for responses, they cancel each request immediately.

The client does this by sending a RST_STREAM frame, indicating that a previous stream should be cancelled. The rapid request-and-reset sequence means the server spends resources processing the request, only for it to be cancelled before a response is generated. This tactic amplifies the server's workload without the attacker needing to wait for responses, which increases the pressure each connection can place on the server.

Variants of the Rapid Reset Attack

Attackers also used variations of the Rapid Reset attack:

One variant involves delaying the reset action. The attacker opens multiple streams, waits, then cancels the streams and instantly opens new ones. This method can evade some rate-based defences.
Another variant avoids stream cancellations. Instead, the attacker tries to open more streams than the server allows. This aims to keep the server continually busy, processing a near-constant flow of requests.

Effective Mitigation Techniques

Mitigation is not as simple as blocking individual malicious requests. A more effective approach is to close the entire TCP connection when malicious activity is detected. The HTTP/2 protocol supports connection termination through the GOAWAY frame. This feature needs to be used aggressively to prevent Rapid Reset attacks, rather than relying on the more passive, standard implementation.

Deciding which connections to treat as malicious is a challenge. One potential strategy is to monitor connection statistics. If a connection exceeds a set threshold of cancelled requests, it might be deemed malicious. Responses to suspect activity could range from sending a GOAWAY frame to terminating the TCP connection.

For the non-cancelling variant, the best approach is to shut down connections that breach the concurrent stream limit, either immediately or after a few violations.

Broader Protocol Implications

These attack techniques are specific to HTTP/2, but the wider protocol lesson still matters. The HTTP/3 (QUIC) protocol isn't directly vulnerable in the same way. As a precaution, server implementations should consider limiting the work done by a single connection.

The Importance of Industry Collaboration

When the threat of the Rapid Reset attack became apparent, the industry collaborated to address the issue. The vulnerability was disclosed to key HTTP/2 implementers, helping to devise and distribute effective countermeasures. The vulnerability is logged against CVE-2023-44487.

HTTP/2 'Rapid Reset' DDoS attacks pose a serious risk to services using the protocol. To reduce exposure, service providers should promptly apply available software patches and updates.

Learn how Peakhour's Application Security Platform helps protect against Layer 7 DDoS attacks, including the HTTP/2 Rapid Reset vulnerability. Contact our team to secure your infrastructure.

Web scraping another Business' website

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

As businesses continue to build their presence online, screen scraping is becoming more prevalent. Screen scraping is the use of software or code to take data from another website. For example, popular platforms like Skyscanner or booking.com usually take price data on flights and accommodation and display it on their websites. However, Australian copyright laws or the website owner’s terms and conditions may forbid you from screen scraping. This article explains the legal aspects of scraping data from another business’ website and the precautions you should take.

Am I Violating the Law by Screen Scraping?

Australian copyright law safeguards ‘original creative works’, including:

written works;
visual images;
music; and
moving images.

Copyright can also protect documents such as government reports and legal forms. When determining whether copyright protects a creative work, the work does not need to be intricate or of high quality. It only needs to demonstrate originality and not be copied from another source.

Is Data an ‘Original Work’?

Data is usually fact-based and primarily consists of statistics or numbers. As a result, copyright usually does not protect data.

Examples of such data include:

the consumer price index for a particular quarter;
monthly house price increases in a city;
the number of students in a class; or
the count of films released in a year.

Generally, the law does not consider this an original work because it merely represents real-world information.

What Data is an ‘Original Work’?

However, data can be an original work in some circumstances. For example, if you organise data in a unique manner that reflects someone's creativity, the law might consider that data an ‘original work’.

Examples of organised data that copyright protects include;

accounting forms;
sequences of numbers or letters for a bingo game; or
a car parts catalogue.

Consequently, screen scraping data from a website is unlikely to infringe copyright unless it involves protected, creatively organised data. Infringing someone’s copyright means using their copyright-protected material without their permission.

Are There Exceptions to Copyright Law?

In the rare event that your screen scraping infringes copyright, your use could fall under an exception to copyright infringement. Australian copyright law refers to these exceptions as 'fair dealing.'

The four ‘fair dealing’ exceptions include using copyright-protected materials for:

research or study;
review or critique;
parody or satire; and
reporting the news.

For instance, a journalist scraping original data sets to report potential price-gouging among airlines could potentially rely on the exception for reporting the news. However, if you are scraping data for business purposes, the fair dealing exceptions may not apply.

What if a Website Explicitly Bans Screen Scraping?

Even if screen scraping is not always illegal under Australian copyright law, website owners can use their terms of use to prohibit data scraping. These terms of use often appear as website pop-ups. The pop-ups typically state that by continuing to use the website, you accept the terms of use.

These terms can explicitly forbid:

data scraping;
copying;
hacking; or
any form of data extraction.

Violating these terms would result in you breaching the website’s terms of use. As a result, the website owner may take legal action against you. If the data on the website qualifies as original work, copyright infringement claims may also arise.

Therefore, it is advisable not to screen scrape from websites with explicit terms of use against that activity. If you do engage in screen scraping, ensure you only extract factual information.

Key Takeaways

Screen scraping is generally lawful if you extract strictly factual information from other websites. However, if a website's terms of use prohibit screen scraping, even for factual data, it is advisable to avoid data scraping. Otherwise, you could face potential breach of contract and copyright infringement claims.

For assistance with your legal obligations, LegalVision’s experienced IT lawyers can assist as part of their membership. For a low monthly fee, you will have unlimited access to lawyers who can answer your questions and draft and review your documents. Call LegalVision today on 1800 296 912 or visit their membership page.

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.

Interaction to Next Paint (INP)

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

Google has announced that Interaction to Next Paint (INP) will replace First Input Delay (FID) as a Core Web Vital as of March 2024. Introduced as a metric in 2022, INP covers gaps in FID by measuring more of what happens after a user interacts with a page.

To help site owners prepare for its introduction as a Core Web Vital, INP is already included in the Chrome User Experience Report (CrUX). By analysing the CrUX data, website owners can see their current INP performance and make targeted optimisations ahead of the March 2024 change.

A better metric than First Input Delay

First Input Delay, as its name suggests, only measures the delay between an input, such as a keypress or mouse click, and the point where the browser begins to handle that event. It does not include the time spent processing the input. It only measures how long the browser was blocked before it could start handling it.

That leaves two issues: it only considers the FIRST event, and it does not measure how long it takes for the user to see the result of their input.

INP is designed to cover both issues. It measures the latency of ALL 'interactions' through to the visual response for that interaction. As explained by Google, an interaction like a tap on a touch screen device can consist of several input events.

"An interaction's latency consists of the single longest duration of a group of event handlers that drives the interaction, from the time the user begins the interaction to the moment the next frame is presented with visual feedback."

After measuring all interactions, the final INP score is the longest interaction observed, ignoring any outliers.

What Constitutes a Good Score

INP is measured in milliseconds (ms), with lower scores indicating better performance:

Good: < 200 ms
Needs Improvement: 200-500 ms
Poor: > 500 ms

How to ensure you have a good INP score

Minimise Main-Thread Work

Long-running JavaScript can block the main thread and increase INP times. Break these tasks into smaller parts and run them asynchronously to reduce delays.

Efficiently Use Browser APIs

APIs that trigger layout recalculations can be expensive. Use them sparingly and look for alternatives that put less pressure on the browser.

Defer Non-Essential CSS and Scripts

Postpone the loading of non-critical CSS and JavaScript. Use techniques like asynchronous loading to improve INP scores.

Monitor Third-Party Scripts

Heavy third-party scripts can degrade INP performance. Use asynchronous or deferred loading for these scripts to limit their impact.

Conclusion

Google estimates that 90% of a user's time on a page is after it has finished loading. FID focused on first impressions, with the assumption that a fast start meant the page would stay responsive. Interaction to Next Paint addresses that gap and gives a more accurate view of user experience. If you want to know your current INP score, you can use our free website speed comparison tool to view it alongside your other Web Vitals, and see how your website compares to your competitors.

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.

A Secure Internet

2023-08-16T00:00:00+10:00

Here at Peakhour, we track browser security changes because they affect how sites are delivered and how users experience warnings. Google Chrome has made another move towards encrypted and authenticated traffic by expanding HTTPS-First Mode. Here is what Chrome unveiled on August 16, 2023, and what it means for HTTPS by default.

Automatic Upgrades to HTTPS

Chrome aims to make HTTPS the standard protocol by automatically upgrading all HTTP navigations to HTTPS. Even if you click a link explicitly declaring HTTP, Chrome will try HTTPS first. If the upgrade fails because of an invalid certificate or another issue, Chrome will fall back to HTTP.

The change is part of an experiment in Chrome version 115. It does not protect against active network attackers, but it does shift more everyday traffic away from passive eavesdropping and towards HTTPS as the default.

Warning on Insecurely Downloaded Files

Chrome is also adding warnings before users download high-risk files over insecure connections. Downloaded files can contain malicious code that compromises a computer. The warning gives users a clearer signal before they proceed, while still allowing the download if they accept the risk. The rollout of these warnings is expected to start in mid-September.

Expanding HTTPS-First Mode Protections

Chrome's longer-term goal is to enable HTTPS-First Mode for all users. It is expanding those protections in several areas:

Enabling HTTPS-First Mode for users in Google's Advanced Protection Program who are also signed into Chrome.
Planning to enable HTTPS-First Mode by default in Incognito Mode for a more secure browsing experience.
Experimenting with automatically enabling HTTPS-First Mode on sites frequently accessed over HTTPS.
Exploring automatically enabling HTTPS-First Mode for users who rarely use HTTP.

Try it Out

For users who want to try HTTPS upgrading or insecure download warnings before the full rollout, Chrome has provided options in the browser's settings to enable these features.

Peakhour's HTTPS Redirection Feature at the Edge

At Peakhour, HTTPS redirection is a practical edge control. It helps enforce encrypted and authenticated connections before a request reaches the origin.

When a user attempts to access a site over HTTP, our edge identifies the unsecured connection. Instead of allowing that connection through, we redirect the request to the HTTPS version of the site.

Enhanced Security: By enforcing HTTPS, data transmitted between your website and your users is encrypted and protected from potential attackers.
Compliance with Best Practices: This feature aligns with industry standards and recent browser policies, including Chrome's push towards HTTPS-first mode.
User Trust: A secure connection gives users a clearer reason to trust the site, improving the user experience and potentially supporting higher conversion rates.

We also offer options for customisation, allowing you to set specific rules and behaviours for how HTTP requests are handled and redirected to HTTPS. Peakhour's HTTPS redirection feature at the edge is a small control with a clear job: move HTTP traffic onto HTTPS automatically, protect users, and keep sites aligned with current browser expectations.

Final Thoughts

Chrome's push towards a secure-by-default web is another step towards a fully encrypted and authenticated internet. It also matches the way Peakhour thinks about everyday security controls: enforce the basics at the edge, and make the safe path the default.

Chrome's changes may require developers, enterprises, and users to adapt. The direction is still clear: less plain HTTP, more HTTPS by default, and fewer silent insecure paths. If your organisation is reviewing its HTTP handling, Peakhour can help you apply the right redirects and edge rules.

Vary Cache on Cookie Value

2023-08-03T13:00:00+10:00

On most websites, a user requests a page and receives the same response as everyone else. Some websites, however, change the content depending on who is visiting. For example, someone visiting from Australia might get the page in English, while someone visiting from Spain gets it in Spanish.

The Vary Header

The HTTP Vary header is the standard way to tell a cache that the content of a page can change depending on a request header. For example, if a website returns this header:

Vary: Accept-Language

It tells any cache that the content can change depending on the language preference of the user's browser. The cache then stores a separate copy of the page for each language.

That works for standard request headers, but content often changes based on something else. For example, a user might be able to select their currency on an ecommerce store. This preference is usually stored in a cookie.

A common, but problematic, way of handling this is to return:

Vary: Cookie

This tells the cache to store a separate version of the page for every unique Cookie header it sees. The problem is that the Cookie header can contain many different cookies (e.g., for analytics, session tracking, etc.), creating many cached versions and a very low cache hit rate. This effectively makes caching useless.

Varying on a Specific Cookie Value

A better solution is to vary the cache based on the value of a specific cookie. For example, an ecommerce store might use a cookie named currency to store the user's preference. By instructing the CDN to look only at the value of the currency cookie, it can store separate cached versions for AUD, USD, EUR, etc., while ignoring all other cookies.

This means you can serve personalised, dynamic content while still benefiting from a high cache hit rate.

Use Cases

Varying the cache on a cookie value is useful for dynamic websites:

Multi-Currency/Multi-Lingual Stores: Serve cached pages with the correct currency and language for each user.
User Groups: Show different content or pricing to different user groups, like wholesale vs. retail customers, without them needing to log in.
A/B Testing: Serve different versions of a page to different users as part of an A/B test and cache both versions.
Personalisation: Cache pages with personalised content, like recently viewed items or location-based offers.

Enterprise or Essential?

Many major CDN providers restrict this feature to their expensive enterprise plans, putting it out of reach for many businesses. At Peakhour, we see it as an essential feature for modern dynamic websites. That's why we make it available on all our plans. It's a core part of our 'Enterprise for Everyone' philosophy.

The ability to vary the cache on a specific cookie value addresses the limitations of the Vary: Cookie header and allows for efficient caching of personalised content. It is not a luxury feature; it is an essential tool for improving performance and user experience on modern websites.

Content and Origin Mounting

2023-06-29T13:00:00+10:00

Some features look niche until you map them to the problems they remove. Content mounting is one of those features. It has been available in Peakhour for some time and has helped solve some unique challenges for our biggest clients. We've applied it to SEO, usability, performance, and security problems. Peakhour's implementation is also unique in the CDN world.

What is Content Mounting?

Peakhour's 'Content Mounting' lets you 'mount' content hosted on another website or server onto a subfolder of your main website. For example, say you have the primary hostname of:

example.com

This feature effectively means that you can serve content from:

shop.example.com

under your primary hostname, eg

example.com/shop/.

Fetching content from a different origin is configured using Edgerules, giving you a high degree of control over how content is fetched and for whom. EdgeRules allow you to:

Match criteria beyond the URL, for example a cookie value, a header, the device type, and more.
Override the hostname header, eg the incoming request for example.com will have the host header to the origin replaced with shop.example.com. This is crucial for the secondary origin server to respond to the request. It also overrides the Server Name Indication (SNI) for the request to the origin.
Rewrite the path, eg the request for /shop/ can be rewritten to be just / so it matches the URL scheme on the secondary origin.
Rewrite links in the returned HTML document. Content on shop.example.com will have resources/links referencing shop.example.com. Those links need to be rewritten as example.com/shop/ so navigation stays on example.com and CSS/JS/images load properly. The restriction is that only links in HTML will be rewritten. Links in JavaScript or CSS won't be rewritten, so content might not look right.

Use Cases for Content Mounting

Boost domain authority: By 'mounting' all your content onto your main domain, you can significantly increase the amount of quality content under your primary URL. This aggregation can improve your website's domain authority, a key factor search engines consider when ranking your site.
Improved User Experience: This strategy also improves the user experience by keeping everything under one main domain. It reduces confusion, provides consistency, and keeps navigation seamless. Search engines prioritise websites that offer a strong user experience, so this could indirectly improve your rankings.
Improve Performance: Each hostname that the browser has to connect to incurs a performance cost. It has to start a new thread and negotiate a DNS lookup and TLS handshake. You can speed things along with browser hints like dns-prefetch and pre-connect but it can still be in the region of 100-500ms per hostname. Mounting them onto your main domain and allowing Peakhour to maintain warm connections to the different hosts can deliver measurable benefits.
API Security: With the rise of Headless eCommerce and microservices, it is common for information to be fetched from several different hostnames. By mounting them on your main domain, say under /api/, you can achieve versioning and consistency.
Eliminate CORS configuration issues and preflight requests: When JavaScript in your browser has to call another hostname, it needs specific headers that grant permission, and there is also a preflight request penalty. Trendspek eliminated CORS and preflight requests from their application using our content mounting and dramatically improved 3D model loading.

Conclusion

Content mounting is a practical tool for organising and orchestrating your website content. With the rise of microservices and headless ecommerce, it can be vital for ensuring a consistent and secure website experience.

Cache Tags/Surrogate Keys

2023-06-28T13:00:00+10:00

Caches are a way of storing information so future requests for the same data can be served more quickly. CDNs, including Peakhour, run caches on each of their POPs (Points of Presence). At that level these caches are key/value stores, where the key can be a combination of several request details, as outlined in our previous blog post on cache keys.

An established way to improve website performance is full page caching, where a copy of a full page generated by a CMS is stored in a CDN. For a cache hit compared with a cache miss, this can typically cut 1-4s off a page load.

Main document load before caching: 2.07s

Main document load after caching: 82ms!!

A Simple Cache Example

When a website changes a resource, such as a page or image, it can instruct the CDN to flush the cache entry for that resource's key. For example, say we have a page:

/about-us/

If we're doing full page caching, it will be stored in the CDN with the key "/about-us/". If it changes, we can issue a flush using the key "/about-us/" and the CDN will fetch a fresh version.

A blog example

But consider a blog article with the URL "/caching/caching-explained/". A typical blog has categories, tags, and authors. A link and summary for the article can exist on many pages: the home page if it's recent, the category pages that the article belongs to, the author page, and so on.

When we update the article, flushing only the key "/caching/caching-explained/" is not enough. We also have to find the other pages it appears on and flush them too, because they may have changed. That means issuing database queries to find all the pages that our article appears on, gathering them into a list, and issuing a flush for each of them.

An eCommerce example

Another example is an ecommerce store with lots of products and product categories. A particular product might appear on 100s of pages with its price displayed. When that price changes, the cached site needs to reflect it. You have two choices: do a lot of work on the server to discover the pages the product is on and flush them, or flush everything. Neither option is good. The first can slow your website to a crawl with database queries; the second forces the cache to repopulate.

Enter Cache Tags

Cache tags, also known as surrogate keys, are a mechanism for adding another way to find content in a cache. Unlike the primary cache key, these tags are not unique.

A website utilises cache tags by returning them in an HTTP header with the response. For example, Magento 2 uses the header X-Magento-Tags:

x-magento-tags: cms_b_site_home_main_banner,store,cms_b,cms_b_site_homepage_bar,cms_p_47,cms_b_header_custom_notice,cms_b_porto_custom_block_for_header_home5,cms_b_site_header_social_links,cms_b_site_home_shopby_category,cms_b_site_home_shopby_brand,cat_c_p_2,cat_p_2508,cat_p,cat_p_2483,cat_p_2387,cat_p_2372,cat_p_1412,cat_p_1388,cat_p_2575,cat_p_2560,cat_p_2557,cat_p_2543,cat_p_2520,cat_p_1262,cat_p_2434,cat_p_2423,cat_p_1660,cat_p_1579,cat_p_1276,cat_p_1217,cms_b_site_footer_social_links,cms_b_site_footer_contact_us,cms_b_site_footer_popular_items,cms_b_site_footer_quick_links,cms_b_site_footer_information

Magento returns tags for page elements like the navigation, sidebar, and notice, as well as for product categories and products. Products have tags in the format cat_p_1234, where 1234 is the product id in the database.

When someone updates product 1234, a flush is issued for the tag cat_p_1234 and all pages that have that tag are flushed. Magento doesn't have to do any work trying to determine which page the product might be on. The cache can efficiently find those cached pages and invalidate them.

Cache tags in CMSs

As mentioned, Magento 2 uses a sophisticated cache tag strategy to maximise the performance of its full page cache. Other CMSs, including Drupal 8/9/10 and Typo3, also utilise cache tags. Peakhour adds cache tags to WordPress, Prestashop, Magento 1, and Opencart via our plugins to enable full page caching.

Cache Tag support amongst CDNs

If you're looking for maximum full page cache effectiveness for your website, especially if you're using a CMS with built-in cache tag support, cache tag support matters. The table below outlines support amongst major CDN providers.

CDN/Cache	Cache Tag Support	Custom Header
Peakhour
Cloudflare	Enterprise Plan Only
Fastly
Self Hosted Varnish
Cloudfront

Enterprise or essential?

In our view, cache tags are an essential feature for any CDN trying to maximise cache performance. They make cache invalidation targeted and efficient, which protects hit rates and reduces work on the origin server. They shouldn't be walled off in an Enterprise-level package.

Headless Commerce Security

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

At Peakhour, we spend a lot of time looking at e-commerce architecture trends. Single Page Applications (SPAs) and headless commerce keep coming up, with tools such as Nuxt.js, Strapi, Hydrogen, and Gatsby leading many builds. These tools can make frontend work faster and more flexible, but they also put more e-commerce data behind APIs that scrapers can target.

Single Page Applications (SPAs) and headless e-commerce have changed how many retailers build their storefronts. Frontend development tools like Nuxt.js and headless CMSs like Strapi are now common parts of that stack.

The trade-off is exposure. Product information is often available as JSON data, which makes it easier for scrapers to collect at scale. That raises a practical question: how do you secure data while still making it available through APIs?

Strategies for Data Protection

Data protection matters, but it is not a single control. These are the usual layers:

Rate Limiting: Controls the number of client requests to your API within a set time frame.
Bot Detection: Distinguishes between humans and bots based on behavioural patterns.
Page Load Authentication: Secures the page load through bot detection and authenticates subsequent API calls.
IP Threat Intelligence: Blocks suspicious IP addresses from accessing your API.
GeoIP Filtering: Regulates requests based on geographical origin.

As bots change, those controls need to change as well.

Facing the Challenge of Headless Scraping

Headless scraping uses browsers without a user interface to imitate normal browsing. It is difficult to detect, but network fingerprinting can help.

Network fingerprinting examines network features like Transport Layer Security (TLS) settings and HTTP/2 (H2) parameters. By analysing these, companies can detect and block bots, adding another security layer.

Client-side Security in SPAs

In SPAs, where much of the processing happens in the user's browser, the security concerns shift:

Data Exposure: Protecting sensitive data from leakage or manipulation is critical.
Injection Attacks: SPAs must guard against attacks like Cross-Site Scripting (XSS).
Authentication and Session Management: Properly handled, these prevent unauthorised access.
Insecure Direct Object References (IDORs): Proper authorisation stops attackers from accessing others' data.

Risks in JavaScript Packages

SPAs usually depend on JavaScript libraries and packages. They are useful, but they also add supply chain risk. Using only essential packages, keeping them updated, and sourcing them from trusted providers reduces that risk. Supply chain audit tools can help automate the work:

Security audits need to be frequent because vulnerabilities can appear quickly. Tools like npm's npm audit or GitHub's Dependabot, along with regular penetration testing, can help uncover potential weaknesses.

Final Thoughts

The move toward SPAs and headless commerce is a trade-off between development flexibility and security exposure. These architectures can improve user experience and speed up delivery, but they also introduce new security issues.

Client-side security in SPAs needs deliberate attention. Data exposure, injection attacks, and insecure direct object references all need to be managed, and the convenience of JavaScript libraries brings its own vulnerabilities.

Peakhour addresses these problems with rate limiting that manages request traffic and helps prevent attacks without harming customer experience. Our Web Application Firewall (WAF) examines all payload data, adding another layer of protection.

Frequent security audits still matter. They help e-commerce managers keep SPAs and headless commerce operations secure without giving up the efficiency these architectures can provide.

ZDNS - scan the entire internet

2023-06-20T13:00:00+10:00

The lack of a free Reverse DNS (rDNS) lookup database has made large-scale DNS research harder. To address this, we used ZDNS, an open-source, high-performance DNS toolkit developed by Stanford University, to create our own rDNS database. To reduce UDP timeout issues during rDNS operations, we devised a scan-ordering approach that randomised the IP space and improved the efficiency of the scanning process.

Leveraging ZDNS for rDNS Lookups Across the Internet

Understanding rDNS is useful for internet operations and research. Active DNS measurement helps us inspect how providers advertise the use of their IP address space. One of the components of this ecosystem is Reverse DNS (rDNS), which serves an important role in IP database categorisation and ASN (Autonomous System Number) classification. However, running rDNS across the entire internet is not a trivial task.

Previously, Rapid7 provided a free database for rDNS lookups, but it has discontinued the offering. This situation has prompted the need to create our own database, calling for a robust, efficient, and scalable tool to accomplish the task. ZDNS was the right fit.

Introducing ZDNS

ZDNS, a part of the ZMap.io project, is a capable tool developed by Stanford University to support scalable and reproducible DNS research. ZDNS is an open-source DNS measurement framework specifically optimised for large-scale DNS research on the public internet. It can resolve 50 million domains in 10 minutes and query the PTR records of the complete public IPv4 address space in approximately 12 hours.

This high-performance toolkit offers a modular interface, enabling researchers to safely implement new functionalities. Its architecture is designed to expose DNS lookup chains by performing recursive resolution. ZDNS supports a command-line interface and outputs results in JSON, a machine-parsable format.

Enhancements by ZDNS

ZDNS's architecture and feature set are tailored to the challenges of extensive DNS research. Its guiding principles are that the DNS lookup chain is exposed, and that the tool is safe, easy to use, and extensible.

ZDNS's performance optimisations make it a suitable tool for DNS experiments that require querying a large number of names. Parallelism, UDP socket reuse, and selective caching are some of the critical performance optimisations that enable ZDNS to efficiently handle large volumes of DNS queries.

ZDNS's scalability, execution time, and success rate have been evaluated against several existing tools, showcasing its performance. For instance, when it comes to exposing the DNS lookup chain, ZDNS is 85 times faster than Dig. ZDNS also outperforms other higher-performance tools, achieving 2.6 to 3.6 times more successful queries per second and experiencing about 30% less packet drop than MassDNS.

Our rDNS Journey

When we started scanning the whole internet with rDNS, we hit a practical roadblock: UDP timeouts made the scans slow. The system spent too much time waiting for responses from parts of the internet that were either empty or broken.

We used two changes. Firstly, instead of scanning the internet's addresses in order, we mixed them up and scanned randomly. This spread out our requests and stopped the system from getting stuck on troublesome ranges. Secondly, we checked smaller sections of the internet first, so we did not waste time waiting for big chunks of the internet that weren't responding.

With these changes, we scanned the whole internet in 13 days, finding over a billion addresses. The main lesson was straightforward: scan order matters when timeout behaviour dominates runtime.

Wrapping Up

ZDNS has proven to be a valuable tool for DNS research, especially for substantial tasks like performing a reverse DNS scan of the entire internet. Our experience underscores the value of practical adjustments when dealing with large-scale challenges, like randomising the IP space to avoid delays caused by UDP timeouts.

As an open-source tool, ZDNS is available on Github. For more detail, read the award-winning paper presented at IMC 2022.

Our work with ZDNS shows its value in DNS research and the operational detail involved in large-scale DNS work. By randomising the scan order, we mitigated timeout issues and improved the efficiency of our scanning process.

Izhikevich, L., Akiwate, G., Berger, B., Drakontaidis, S., Ascheman, A., Pearce, P., Adrian, D., & Durumeric, Z. (2022). ZDNS: a fast DNS toolkit for internet measurement. In Proceedings of the 22nd ACM Internet Measurement Conference (pp. 33-43). https://doi.org/10.1145/3517745.3561434 ↩
ZMap Project. (n.d.). ZDNS. GitHub. Retrieved 2023-05-15 13:00, from https://github.com/zmap/zdns. ↩

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.

Maximising Website Speed

2023-06-07T12:31:00+10:00

As businesses prepare for a global economic downturn, every source of friction matters. One of the most controllable is website speed.

For many customers, the website is where they first test whether a business is worth their time. They learn about the company, compare products, read content, and, if the experience holds up, buy. Loading time shapes that first impression, affects engagement, and can change whether a visitor becomes a customer.

This article looks at why speed deserves attention when trading conditions tighten. It covers search rankings, conversion impact, and published case studies where faster sites produced measurable gains.

The Need for Speed

Website speed is not an abstract technical score. It is how quickly users can see and interact with content. A delay measured in milliseconds can affect engagement, conversion rates, and customer retention.

Speed matters because user expectations are set by fast services and fast networks. When a page feels slow, people leave and are less likely to return.

Speed also affects how search engines, including Google, rank your website. For businesses trying to remain visible in a crowded market, especially during an economic downturn, performance is a practical lever.

Correlation with Search Rankings

The relationship between website speed and search rankings is supported by research and by statements from Google. A few years ago, Google announced that page speed would be a ranking factor. The change reflected Google's focus on relevant, usable pages.

Websites that meet all of Google's requirements receive a slight advantage, ranking one percentage point higher than the average. These requirements cover several areas, from content relevance and quality to mobile-friendliness and page speed.

By contrast, websites that fail to meet at least one of Google's requirements can sit at a measurable disadvantage, ranking 3.7 percentage points lower. That matters when search visibility is already under pressure.

Google's Core Web Vitals have also become a measurable factor in search rankings. These vitals measure aspects of page speed and user experience, showing how speed and SEO (Search Engine Optimisation) now overlap.

A study by Crystallize also found a correlation between speed and SEO. In their page speed score experiment, a page with a high score ranked #1 in Google with a featured snippet for the optimised item. Unoptimised pages with lower speed scores did not appear in search results.

The practical point is straightforward: website speed can improve search visibility. In an economic downturn, that extra visibility can matter.

Conversion Impact of Speed

Speed also affects conversion rates. Deloitte's 'Milliseconds Make Millions' report shows how small improvements in loading time can change commercial outcomes.

The study examined a 0.1 second decrease in loading time across different market sectors. In retail, a quicker page loading time led to an 8.4% rise in conversion rates and a 9.2% improvement in average shopping basket size. The travel sector saw a 10.1% increase in conversion rates and a 1.9% rise in average basket size. For luxury brands, faster loading times resulted in an 8.6% increase in page views per session and an 8.3% decrease in form bounce rates.

Peakhour clients have seen the same pattern. Pharmacy Direct reported a 30% increase in conversions and order value after reducing page load time by 90%. Kitchen Warehouse saw a 150% increase in revenue after decreasing page load times by 70%.

These numbers show that page speed is tied to business metrics, not just technical scores. The scale varies by site and sector, but the direction is consistent across the cited examples.

Real-Life Success Stories

The effects of website speed optimisation are visible in published case studies:

French linen brand Carré Blanc saw a 25% increase in conversion rates after improving web page loading speed.
Renault optimised the Largest Contentful Paint (LCP), leading to a 14 percentage point decrease in bounce rate and a 13% rise in conversions.
E-commerce platform eBay found that every 100ms improvement in search page loading time resulted in a 0.5% increase in additions to the shopping cart.
SnipesUSA.com doubled their average conversion rate from about 1% to about 2% by decreasing load times by 30%.
French toy retailer King Jouet enjoyed a 5% increase in conversion rates within a month through page speed optimisation.
AliExpress, a global online retail marketplace, experienced a 10.5% increase in orders and a 27% increase in conversions for new customers by reducing loading time by 36%.
Boutique designer brand Revelry saw 43% faster page loading, an 8% decrease in bounce rates, and a 30% increase in conversions after optimising images on their eCommerce site.
Zalando, an online fashion platform, reported a revenue increase of 0.7% per session by reducing web page loading time by 100ms.
Pinterest observed a 15% increase in platform registrations following an improvement in loading speed.
Telecommunications company Vodafone saw an 8% sales increase with a 31% improvement in Largest Contentful Paint ( LCP).
Mobile marketplace Swappie achieved a 42% increase in mobile revenue by focusing on Core Web Vitals.

These examples show how improving loading speed can lift conversion rates and revenue.

Optimising for Search Performance

Speed also affects search performance beyond organic ranking. Several examples point to paid search impact:

Lever Interactive Agency reported that one of their clients improved their Quality Score, resulting in a 17% decrease in Cost Per Click (CPC), a 31% decrease in Cost Per Acquisition (CPA), and a 20% increase in conversion rate on faster landing pages.
Crystallize Headless Commerce noted that scoring high in the Quality Score can lead to significant benefits, including up to a 50% discount on CPC prices. Conversely, a low Quality Score can result in paying up to 400% extra, severely impacting your marketing budget.

Core Web Vitals have also become a priority for eCommerce platform Shopify. The company continues to optimise speed performance to improve search rankings.

These cases show why performance work needs to be ongoing, especially where search traffic and paid acquisition costs are material to the business.

Enhancing Engagement

Engagement is not separate from speed. A fast, well-optimised site gives users less reason to leave and more opportunity to browse, compare, and interact. The data supports this in several ways.

Take eCommerce for instance. Customers are 10% more likely to recommend an eCommerce website when pages load in 10 seconds instead of 13 seconds. The likelihood of recommendation rises to 26% if loading time is reduced to 3 seconds. That shows how quickly performance changes user perception.

Other companies have also seen measurable effects from speed optimisation. Netflix implemented Gzip compression for resource optimisation, resulting in a 43% reduction in outbound traffic. Yahoo Japan News saw increases in both page views per session and session times (15% and 13% respectively), as well as a 1.72% decrease in bounce rate, by improving their Cumulative Layout Shift (CLS) by 0.2 points.

Google has also published data linking Core Web Vitals to engagement. Their data showed that favourable Core Web Vitals scores can reduce the likelihood of users abandoning a page before it loads by up to 24%. Meeting Core Web Vitals thresholds also led to an overall 43% improvement in bounce rate for The Economic Times.

The agriculture e-commerce platform, Agrofy, improved their Core Web Vitals scores by 70% for LCP and 72% for CLS, resulting in a 76% reduction in abandonment rate. Again, the useful lesson is not just that the site became faster. It is that users behaved differently once it did.

Key Speed Metrics

Website speed is about more than full-page load time. Several metrics help assess how fast and stable a page feels to a user. Google's Pagespeed Insights lists the following important metrics:

Largest Contentful Paint (LCP) measures the time taken to load the largest visible content on the page. The ideal target for this is less than 2.5 seconds. This metric matters because it provides a clear indicator of perceived load speed for the user.
Cumulative Layout Shift (CLS) evaluates the visual stability of a page during loading. The target here is less than 0.1. This helps limit content jumping or shifting while the page loads, providing a smoother user experience.
First Input Delay determines how quickly a page responds to user input, with the target being less than 0.1 seconds. This metric measures the interactivity and responsiveness of a website.

Together, these metrics show whether a website delivers a fast, smooth user experience.

User Expectations and Impact on Business

Users expect pages to respond quickly. When they do not, speed becomes a business issue rather than only an engineering issue.

According to Think with Google, slow-loading pages can affect user experience, resulting in higher bounce rates, negative brand perception, and an impact on conversions and revenue. When users have to wait too long for a webpage to load, they are likely to leave and look for a faster experience elsewhere.

Digital marketing expert Neil Patel highlights that a 1-second delay in page response can lead to a 7% reduction in conversions. To put that into perspective, if an e-commerce site is making $100,000 per day, a 1-second page delay could cost $2.5 million in lost sales every year.

Akamai also found that 53% of mobile site visitors will leave a page that takes longer than three seconds to load. This shows the standards modern users have for website performance and the revenue risk for businesses that fail to meet them.

Common Culprits

If your website is running slowly, a few common issues could be to blame. The usual causes are technical and operational:

Time to First Byte (TTFB) is the time it takes for the first byte of data to be received from the server. High TTFB can affect loading times and should be minimised.
Large Page Size and Resources can also contribute to slow loading times. This includes heavy content, such as images, videos, or large files. Optimising these resources can materially improve loading speed.
Third-Party Resources like ads, plugins, or widgets can require additional loading time. While these are often necessary, they need to be managed carefully to avoid excessive loading delays.
JavaScript can be a double-edged sword. While it enables advanced functionality, complex or poorly optimised JavaScript code can also hinder performance.
Single-Page Applications (SPAs) may experience slower initial loading due to their extensive scripting requirements, but they often offer faster navigation once loaded.
Busy Servers Handling Bot Traffic can also cause slowdowns. Bot traffic, in some instances, can account for over 40% of server load. Managing this effectively can help improve website speed.

Understanding which of these factors applies to your site helps you focus performance work where it will matter.

Continuous Monitoring and Performance Optimisation

Getting a site fast once is not enough. Speed can regress as content, third-party tags, releases, and traffic patterns change, so monitoring and performance optimisation need to be continuous.

Tools such as Google's Pagespeed Insights can help track website performance. Regular checks of key metrics can show which issues are slowing the site down and which changes need attention.

It is also important to test improvements on a staging website before deploying them to production. That reduces the risk of disrupting live performance or user experience. Regular diagnostic testing and iterative improvements help keep the site aligned with current performance expectations.

As SEO consulting company Moz highlights, focusing on continuous performance optimisation can have significant benefits. It can help maintain a fast, usable site and support higher search rankings, better engagement, and increased conversions and revenue.

Preparing for the Coming Recession

With an economic downturn on the horizon, a fast, well-optimised website becomes more important. Consumers are likely to be more selective with their spending, and businesses will need to compete harder for each sale.

A fast website can be a useful differentiator in this environment. It can boost your search rankings, making the site more visible to potential customers. It can improve engagement by giving visitors fewer reasons to leave. It can also increase conversion rates, which has a direct effect on sales.

In this context, website speed is not cosmetic. It is an operating requirement. The work is to measure the current experience, fix the main bottlenecks, and keep monitoring performance as the site changes.

The data and case studies point in the same direction: speed optimisation is a practical investment. It helps align the website with user expectations and makes the site a more effective part of the business.

Website speed is measurable, improvable, and commercially relevant. For businesses preparing for tighter conditions, it deserves active management rather than occasional clean-up.

Down But Not Out - JXL Will Return on Safari

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

Just as we were coming to terms with the controversial decision by Google to drop support for JPEG-XL (JXL) in Chrome, Apple announced support for JXL during the WWDC June 5th livestream. That is a meaningful shift. JXL was down, but not out.

Google's decision to stop JXL support in Chrome surprised us at Peakhour, along with plenty of others who care about web performance and image delivery. Google Chrome, as the most used browser globally, often sets the course for web standards. In deciding to drop JXL, Google appeared to be exercising its dominance over those standards, and the decision drew real debate in the web community.

Apple's announcement changes the picture. Apple has long pushed high dynamic colour and high-resolution features, and Safari support is a useful signal for image delivery. By bringing JXL support to Safari, Apple is giving this promising image format a fair go.

This move also hints at wider JXL support across the entire Apple ecosystem, which includes iPad, iPhone, Mac, and Apple TV. While there are still some limitations - embedded colour profiles and animations are not yet supported in the current MacOS Sonoma beta - we hope these gaps are fixed soon.

At Peakhour, this is good news. We look forward to welcoming Apple users to our websites, where they will be able to see the quality benefits of JXL images as soon as their operating systems support it.

This turn of events gives JXL a much-needed boost. It does not undo Google's Chrome decision, but it keeps the format in play and makes the future of web image formats less settled than it looked a short while ago.

Understanding HTTP Link Headers

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

HTTP headers are part of browser requests and server responses. They carry information about the connecting client, the requested resource, the server, and other request context. An HTTP header has a case-insensitive name followed by a colon (:), then its value. Headers are used for authentication information, content negotiation, and related protocol behaviour. Here are some sample request headers sent by my browser when requesting a page on the Peakhour website:

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: en-AU,en;q=0.9
Connection: keep-alive
Cookie: _ga_NRWSVE0PSC=GS1.1.1685943893.13.0.1685943893.0.0.0
Host: www.peakhour.io
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.4.1 Safari/605.1.15

The HTTP Link header

An HTTP Link header lets a server send context about a document back to a client. It can identify related resources or the direct location of a specific asset. For page-load optimisation, Link headers can be an alternative to putting preload/preconnect/prefetch hints in the HTML.

History

HTTP Link headers were proposed as a standard in the late 1990s, around the same time the HTTP/1.1 protocol was defined. However, it wasn't until 2010 that HTTP Link headers were officially recognised by the Internet Engineering Task Force (IETF) in RFC 5988, which described their purpose and functionality.

Uses

HTTP Link headers have several uses in web development. Some common examples are:

Pagination: Say we have a blog site with hundreds of posts, and we display 10 posts per page. When a user requests a page, we can use Link headers to provide URLs for the next and previous pages. This helps navigation through the large list of posts. Here's an example of how it might look:
```
Link: </posts?page=2>; rel="next", </posts?page=4>; rel="prev"
```
Preloading: Suppose we have a heavy image or a large CSS file that we know will be required for a webpage. We can use a Link header to tell the browser to start downloading it early, improving the perceived page load speed. For instance:
```
Link: </images/big-picture.jpg>; rel=preload; as=image
```
Resource Hints: Link headers can give the browser hints about resources that might be needed in the future, so the browser can decide whether to fetch them ahead of time. For instance:
```
Link: </scripts/myscript.js>; rel=prefetch
```

Comparison to Link Tags and Why Headers Can Be Better

Now you might be wondering, "Why use Link headers when we can use HTML Link tags?" There are several reasons HTTP Link headers might be a better choice:

Faster Processing: Since HTTP Link headers are part of the HTTP response, they arrive before the HTML document. This allows browsers to start preloading or prefetching resources sooner, which can improve page load times.
Greater Flexibility: HTTP Link headers can be used in situations where HTML Link tags cannot. For instance, they can be used with file types that don't support HTML, like JSON or XML. They can also be added by a third party, e.g., an edge delivery layer such as Peakhour, without the need to parse and rewrite the HTML document.
Less Clutter: Link headers can make your HTML less cluttered, as you can avoid filling the HTML document with numerous Link tags.

Conclusion

HTTP Link headers are a small part of HTTP, but they are useful for performance and flexibility. An edge delivery layer can add Link headers without the overhead of parsing or manipulating the main document, which makes them useful for optimising website performance.

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/ ↩

When Bots Break Bad

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

Bots account for a large share of web traffic. Recent studies put automated traffic at nearly 50% of all internet requests. Some bots are useful, such as search engine crawlers that index your site. Some are clearly harmful, such as scrapers and sneaker bots. Others sit in a grey area, including backlink and marketing bots from services such as Ahrefs and SEMrush. Even useful bots can create problems when they crawl too hard. This article looks at the main bot types and how to manage them with robots.txt and bot management tools.

Understanding the Different Types of Bots

'Good Bots'

Good bots perform legitimate work. Search engine crawlers like Googlebot and Bingbot index webpages so search results can stay current and relevant. Other examples include uptime and performance monitoring bots.

'Bad Bots'

Bad bots harm websites, users, or both. Common examples include:

Scraping content, copying and repurposing data from websites.
Sneaker bots, automatically purchasing limited-edition products (like sneakers) before human users can.
Spam bots, posting unsolicited messages and advertisements in comment sections or forums.
Vulnerability Scanners, trying thousands of website URLs to find security vulnerabilities.
Account Takeover, attempting to gain access to existing user/admin accounts using either credential stuffing or brute-force attacks.

'Grey Bots'

Grey bots sit between good and bad. They often serve a useful purpose and may follow crawling directives in robots.txt, but they can still cause problems when they crawl too aggressively. Common examples include:

AhrefsBot: A backlink analysis bot used by Ahrefs, an SEO tool.
SEMrushBot: A bot used by SEMrush, another popular SEO and digital marketing tool.
MJ12bot: A bot used by Majestic, a service that provides backlink data and analysis.
ScreamingFrog: An SEO analyser run from a local desktop.

When Grey bots (and even Good Bots) go bad.

Left unattended, grey bots can create practical problems:

Slow page loading times, which affect user experience.
Strain on server resources, potentially causing crashes, downtime, and higher costs.
Distorted website analytics, when bot traffic is mistaken for human traffic.

Managing Grey Bots with Robots.txt

The robots.txt file is a simple text file that tells web crawlers which parts of your site they can or cannot access. You can use it to manage bot behaviour and protect your website from aggressive crawling. Useful controls include:

Disallowing specific bots: You can block specific bots from accessing your site by adding a "User-agent" and "Disallow" directive to your robots.txt file. For example:

User-agent: AhrefsBot
Disallow: /

Limiting crawl rate: You can ask bots to slow down their crawling by adding a "Crawl-delay" directive:

User-agent: SEMrushBot
Crawl-delay: 10

Not all bots will follow robots.txt. ScreamingFrog, for example, can be instructed to ignore robots.txt and crawl a site as quickly as possible. You would not want a competitor doing this to your site.

Bot Management Tools

In addition to robots.txt, bot management tools (like those provided by Peakhour) can protect your website from abusive bots. Good bot management tools automatically block most unwanted traffic using a combination of Threat Intelligence, Fingerprinting techniques, Reverse DNS verification, and Header Inspection.

Advanced techniques like rate limiting and machine learning can help identify more sophisticated bad bots.

Search Bots and Double Crawling

Search bots like Bingbot can sometimes blindly follow links and crawl the same page multiple times due to different URL parameters. This double, triple, or worse crawling can increase server load and make indexing less efficient. eCommerce sites are especially exposed because product catalogues often have several filtering paths. We've seen Bing go haywire on a number of sites. Most recently, it was issuing around 50,000 requests per day to the search function of a Magento 2 store while cycling through parameters. This dropped to 2-3k requests per day when fixed. On another store, Bing was responsible for nearly half of all page requests (40k page requests) on a busy OpenCart store. Configuring it to ignore parameters dropped this to around 4k per day.

Configuring Search Bots to Ignore Query Parameters

Note: Since publishing both Google and Bing have removed the ability to ignore parameters when crawling via their webmaster/search console tools. See using robots.txt to instruct search engines to ignore query string parameters

To help search bots crawl your site efficiently, you can configure them to ignore specific query parameters. Use these methods:

Configuring Bing Webmaster Tools

Bing Webmaster Tools provides an option to specify URL parameters that should be ignored during the crawling process. To configure this setting, follow these steps:

Sign in to your Bing Webmaster Tools account and select the website you want to manage.
Navigate to the "Configure My Site" section and click on "URL Parameters."
Click on "Add Parameter" and enter the parameter name you want Bingbot to ignore.
Select "Ignore this parameter" from the dropdown menu and click on "Save."
Configuring Bing Webmaster Tools this way helps stop Bingbot double crawling pages with specific URL parameters, reducing server load and improving indexing efficiency.

Managing Other Search Bots

For other search engines like Google, use the relevant webmaster tools to manage URL parameters. In Google Search Console, follow these steps:

Sign in to your Google Search Console account and select the property you want to manage.
Navigate to the "Crawl" section and click on "URL Parameters."
Click on "Add Parameter" and enter the parameter name you want Googlebot to ignore.
Choose "No URLs" from the "Does this parameter change page content seen by the user?" dropdown menu.
Click on "Save."
Specifying the parameters you want search bots to ignore can prevent double crawling and make indexing more efficient.

Final Thoughts

When good or grey bots crawl too aggressively, they can cause the same operational problems as malicious bots: overloaded servers, slower pages, and worse user experience. Monitor website traffic and server load, set clear robots.txt rules, and use the major search engines' webmaster tools to control inefficient crawling. Done properly, this improves website performance and can lower infrastructure costs.

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.

Consistent Hash with Bounded Loads

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

A consistent hash with load bounds extends the basic consistent hashing technique. Standard consistent hashing distributes keys across servers in a way that minimises rehashing when servers are added or removed, but it does not guarantee a perfectly even load distribution. Random hash collisions can leave some servers responsible for significantly more keys than others, creating an imbalance in the load distribution.

Consistent hashing with bounded loads, or bounded-load hashing, addresses this issue. It keeps the load (i.e., the number of keys assigned) on any given server within a factor of the average load across all servers.

The approach still uses a hash ring, but with an additional constraint that no server can exceed a certain load limit. When a key is hashed and the corresponding server in the hash ring is already at its load limit, the key is assigned to the next server in the hash ring that isn't at its load limit. This process is repeated until all keys have been assigned.

Here's a rough pseudocode example:

# Function to add a key with bounded loads
def add_key_bounded(key):
    position = hash_function(key)

    # Find the server for this key
    for i in range(position, position+1000):
        i = i % 1000  # To loop back to the beginning of the ring
        if hash_ring[i] is not None and server_loads[hash_ring[i]] < LOAD_LIMIT:
            server_loads[hash_ring[i]] += 1  # Increment the server's load
            return hash_ring[i]  # Return the server that should handle this key

In this example, server_loads is a dictionary that tracks how many keys each server is responsible for, and LOAD_LIMIT is the maximum number of keys any server is allowed to handle.

By bounding the load on each server, this approach can produce a more balanced distribution of keys across servers. However, it's worth noting that this algorithm can result in keys being assigned to servers that are not their nearest neighbours in the hash ring, which can increase latency in some cases. As with any algorithm, there's a trade-off between load balancing and other factors such as latency and computational overhead.

The Google Cloud team, in collaboration with visiting researcher Mikkel Thorup from the University of Copenhagen, devised an efficient allocation algorithm to improve load balancing in large-scale web services such as content hosting. The results of their research were detailed in a paper titled “Consistent Hashing with Bounded Loads” that was published in August 2016.

Load balancing in large-scale web services means distributing client requests evenly across multiple servers to prevent any individual server from becoming overloaded. An ideal load-balancing system distributes the load uniformly and minimises the changes to the system when servers or clients are added or removed. This consistency matters in dynamic environments where servers and clients can change over time.

Traditional consistent hashing techniques, although effective for load balancing in dynamic environments, can still lead to sub-optimal load distribution across servers in certain scenarios. As both servers and clients can be added or removed frequently, the load balancing algorithm needs to stay dynamic and adaptive, maintaining an evenly distributed load while minimising the number of client reassignments whenever a change occurs.

Google's algorithm addresses these challenges. To explain their method, they use an analogy of servers as bins and clients as balls. The goal is for all bins (servers) to have a load (clients) roughly equal to the average density, with a small tolerance factor, ε. The algorithm is designed to ensure that every bin has a capacity within the range of the average load times (1+ε), which helps achieve both uniformity and consistency in client-server allocations.

The algorithm employs two separate hash functions to assign positions to balls (clients) and bins (servers) on a circular continuum. The balls are then allocated in a specific order (say, based on their ID), with each ball being assigned to the first bin it encounters with spare capacity as it moves clockwise on the circle.

The algorithm recomputes the allocation whenever an update occurs (i.e., the addition or removal of a client or server) to maintain the uniform distribution of load. The paper proves that every ball removal or insertion in the system results in O(1/ε²) movements of other balls. Importantly, this upper bound is independent of the total number of balls or bins in the system, which means the algorithm scales well with increasing size.

The algorithm creates a trade-off between uniformity and consistency. A smaller ε value provides better uniformity but compromises consistency, while a larger ε value improves consistency but reduces uniformity. The algorithm performs well even in worst-case scenarios, making it ideal for dynamic, large-scale environments like content hosting services.

Google's algorithm has been used in production. Andrew Rodland from Vimeo implemented it in HAProxy, a popular open-source software package, for their load balancing project, resulting in a substantial decrease in cache bandwidth by almost a factor of 8. This eliminated a significant scaling bottleneck, showing the algorithm's practical effectiveness.

Overall, the work of the Google Cloud team and Mikkel Thorup is a useful contribution to load balancing. By addressing the challenges of uniformity and consistency in dynamic environments, their algorithm provides a robust solution for managing large-scale web services efficiently. The team's research and its open-source availability give the broader community a practical implementation path.

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.

Double MAD vs the Rest

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

Limitations of Double MAD and Comparison with Z-Score

Double MAD is useful for anomaly detection, but it has clear limits. One is that it does not account for the shape of seasonal data. Time series data often show cyclical patterns by time of day, week, or year. For instance, web traffic to an e-commerce site might spike during holidays and dip on off-peak days.

Double MAD can capture shifts in the median of these data, but it does not consider the shape or pattern within these cycles. It might therefore miss anomalies that occur within a specific season, or flag normal seasonal variations as anomalies.

Another limitation is that Double MAD does not account for trends over time. If your time series data shows a consistent increase or decrease, Double MAD might misinterpret this trend as a series of anomalies.

Double MAD vs. Z-Score

In anomaly detection, Double MAD is often compared with the more traditional Z-score method. A Z-score measures how many standard deviations a data point is from the mean. It assumes that the data follows a Gaussian (or normal) distribution, which often does not hold true for real-world data.

Double MAD, on the other hand, is a non-parametric method that does not make assumptions about the distribution of data. This makes it more robust to outliers and skewed distributions.

However, Z-score has an advantage when data follows a Gaussian distribution, or when the data size is large enough for the Central Limit Theorem to take effect. It also accounts for the mean and standard deviation, giving it an edge in datasets where these measures are informative.

In contrast, Double MAD is more robust for datasets with outliers or skewed distributions, as it uses the median and absolute deviations from the median, which are less sensitive to extreme values.

Both Double MAD and Z-score have strengths, and the choice between them should be guided by the nature of your data. Understanding these nuances helps you choose the method that fits your specific use case.

Efficiently Generating and Printing All IPv4 Addresses in a Random Order

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

In this article, we explored an efficient way to generate and print all possible IPv4 addresses in a random order using
a Linear Congruential Generator (LCG). The LCG, a pseudorandom number generator, helps generate the full range of IP
addresses without consuming vast amounts of memory, making this approach suitable for systems with memory constraints.
We also provided a Python script demonstrating the concept, along with a test case to verify its correctness.

We then delved into the importance of randomising IP addresses, highlighting its critical role in areas like security
testing, load balancing, enhancing privacy, and web scraping. However, while using this technique, it's essential to
respect privacy and legality, as misuse can lead to legal repercussions.

In summary, the ability to generate and print all IPv4 addresses in a random order is a powerful tool, especially in the
realm of networking and cybersecurity, and can be achieved efficiently using the LCG approach.

In networking, some tasks require generating and printing every possible IPv4 address. Doing that in random order without a large memory footprint is less straightforward. The IPv4 address space contains 2^32, or 4,294,967,296, values. Storing all of them in memory at once is not feasible for most systems.

This article uses a Linear Congruential Generator (LCG) to generate the full range without holding it in memory.

Linear Congruential Generator

A Linear Congruential Generator is a type of pseudorandom number generator that can run without storing the whole sequence. It generates each next value from a linear equation based on the previous value. The basic form of the LCG is:

X_(n+1) = (a*X_n + c) mod m

Here, a, c, and m are constants, and X_n is the nth number in the sequence. The initial seed or starting point of the sequence is X_0.

If we choose parameters such that the period of the LCG is maximum (equal to the modulus), and the modulus equals the range of numbers we're generating (the number of possible IPv4 addresses in this case), then the LCG should generate each number in the range exactly once before repeating.

Here is that idea in Python:

import ipaddress

def lcg(modulus, a, c, seed):
    """Linear congruential generator."""
    while True:
        seed = (a * seed + c) % modulus
        yield seed

start_ip_str = '0.0.0.0'
end_ip_str = '255.255.255.255'

start_ip = int(ipaddress.IPv4Address(start_ip_str))
end_ip = int(ipaddress.IPv4Address(end_ip_str))

modulus = end_ip - start_ip + 1
a = 1664525
c = 1013904223
seed = 1  # Arbitrary seed

generator = lcg(modulus, a, c, seed)

for _ in range(modulus):
    ip_int = start_ip + next(generator)
    ip = ipaddress.IPv4Address(ip_int)
    print(ip)

The script first defines the parameters of the LCG. a, c, and seed are set to values used in Numerical Recipes' LCG, a well-known and widely used LCG. The modulus is set to the total number of possible IPv4 addresses.

The function lcg() is implemented as a Python generator, yielding the next number in the sequence each time it is called.

The loop then generates and prints each IP address. It adds the output of the LCG to the start IP address, converts it back to an IP address string, and prints it.

This script generates and prints each IP address in random (more precisely, pseudorandom) order using very little memory. Each IP address is printed exactly once, assuming the period of the LCG is maximum.

The point is that a small pseudorandom number generator can walk a large range without materialising the whole list. The code can still be tweaked and optimised for specific requirements and constraints.

The Importance of Randomising IP Addresses

Randomising IP addresses has practical uses in several networking workflows:

1. Security Testing and Penetration Testing

In cybersecurity, randomising IP addresses can help simulate attacks on a network from various sources. By using a range of IP addresses in no particular order, penetration testers can mimic the unpredictable nature of real-world cyber threats and build more robust test scenarios.

2. Load Balancing and Network Traffic Simulation

Randomising IP addresses is also useful in network traffic simulations. Network engineers and administrators can use this approach to test network resilience and capacity. By sending requests to servers from randomised IP addresses, they can evaluate how well their load balancing strategies are functioning and whether the network can handle high traffic loads from various sources.

3. Anonymity and Privacy

In some cases, randomising IP addresses can help with privacy and anonymity. While it is not a foolproof method, using a different IP address for each request can make it more challenging for online trackers to monitor user activity. It is a common practice among privacy-focused internet users and is also used in some VPN (Virtual Private Network) services.

4. Web Scraping

Web scraping is another area where randomising IP addresses is useful. To prevent being blocked by anti-bot measures, web scrapers often need to rotate their IP addresses. By using a different IP address for each request, they can avoid being detected and blocked by the sites they are scraping.

Randomising IP addresses can be useful in these cases, but privacy and legality still matter. Unauthorised network scanning, privacy breaches, and cyberattacks are illegal and punishable under law.

Generating and printing every possible IPv4 address in a random order is a valuable technique with various applications, from network testing to privacy enhancement. With the Linear Congruential Generator approach, we can do it efficiently.

Locality Sensitive Hashing

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

Locality Sensitive Hashing (LSH) is a computer science technique for designing hash functions for high-dimensional data. LSH aims to maximise the probability that similar items map to the same hash bucket. The principle is to amplify the difference between similar and dissimilar items, keeping similar items closer together while pushing dissimilar items farther apart. This gives a probabilistic approach to nearest neighbour search, a problem that appears in machine learning, data mining, and information retrieval.

Background and Usage of LSH

LSH was introduced by Piotr Indyk and Rajeev Motwani in 1998 to address the "curse of dimensionality," where traditional computational algorithms become significantly less efficient as the dimensionality of a problem increases. This makes LSH useful in contexts dealing with large and complex data sets, including text analysis, recommendation systems, image recognition, and genome sequencing.

The general idea is to use hashing to map high-dimensional data into a lower-dimensional hash space. The hashing scheme is designed so that collisions are much more likely for objects close to each other in the original space than for objects far apart. This supports sub-linear time complexity for nearest neighbour searches, which matters when working with large data sets.

LSH Variant for Load Balancing

LSH is also used in load balancing for distributed systems. A variant of LSH, known as Consistent Hashing, is often used for this purpose. In consistent hashing, the output range of a hash function is treated as a fixed circular space or "ring" (think of this as a circular hash table). Each node or server in the system is assigned a random value within this space, and each data item or request is assigned to the node closest to it in the hash space.

The practical advantage of consistent hashing is that when a node is added or removed, only an average of 1/n keys need to be remapped, where n is the number of servers. Conventional hash functions would require almost all keys to be remapped. This property makes consistent hashing useful in dynamic environments where the server set changes often, such as in a CDN (Content Delivery Network).

LSH in CDNs for Load Splitting and Caching

In a CDN, data is distributed across multiple servers in different geographical regions. The objective is to let users access the data they need as quickly as possible. This is achieved by routing each user's request to the server closest to them that has the data they want.

Consistent hashing, a variant of LSH, fits this scenario. By hashing both data and user requests, we can assign each request to the server closest in the hash space. This approach gives an even distribution of load across all servers, improving overall system performance.

LSH can also make CDN caching more efficient. When a request for a specific piece of content comes in, the CDN can use the hash function to find the server holding that content. The content can then be served quickly, improving the user experience.

LSH and Server Pool Rebalancing

LSH also helps with rebalancing server pools. In dynamic environments, workload changes constantly, and servers may be added or removed frequently. This can create an imbalance in load distribution across servers.

Consistent hashing mitigates this issue. As mentioned earlier, when a server is added or removed, consistent hashing only requires a minimal reassignment of keys. This keeps load redistribution to a minimum, so the system can quickly adapt while maintaining a balanced load across all servers.

Maglev and LSH

Maglev is a network load balancer developed by Google that uses a distinctive approach to connection distribution. It employs a variant of consistent hashing to balance load across a pool of servers. Using a large lookup table and a consistent hashing-like algorithm, Maglev can evenly distribute traffic across servers, even when servers are added or removed.

Maglev's algorithm starts by assigning a pseudorandom permutation of backend servers for each entry in the lookup table. These entries are then filled by iterating over the permutation and assigning each entry to a server. If a server becomes unavailable, its entries are reassigned to other servers using the same permutation. If a server becomes available, it is gradually reintroduced into the permutation, minimising disruption. This is a practical demonstration of LSH's principles applied to server load, high availability, and performance.

Conclusion

Locality Sensitive Hashing has applications from high-dimensional data analysis to load balancing in distributed systems. Its property of bringing similar items closer in the hash space and pushing dissimilar items farther apart makes it useful for handling large and complex datasets. In CDNs and server pool management, LSH, and its variant Consistent Hashing, support balanced load distribution and efficient caching, improving system performance and user experience. Its application in Google's Maglev shows how these principles can be used in production-scale load balancing.

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.

Multi-Origin Load Balancing

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

Websites and applications with global audiences often run into a problem that a standard CDN cannot always hide: not every request can be served from cache. Traditional Content Delivery Networks (CDNs) reduce latency by distributing content across multiple points of presence (POPs) around the world. But when content has to be fetched from a distant origin server, for example dynamic content that cannot be cached, users still wait on that round trip. This post explains the problem multi-origin load balancing solves and how Peakhour handles it.

Understanding the Problem

Web content usually starts from a single server, called the origin server. As a website's audience grows, that server takes more traffic, which can slow response times. CDNs reduce the pressure by caching and delivering content from servers distributed across multiple geographic locations. When the content is already cached, this reduces origin load and lowers latency for users accessing the content.

However, traditional CDNs still have limits when serving global audiences. If a user requests content that is not cached in the CDN, the request has to go back to the origin server. If that origin is far away from the user, latency increases and pages take longer to load.

Multi-origin load balancing addresses that remaining gap in CDN performance and further reduces latency.

Introducing Multi-Origin Load Balancing

Traditional load balancing distributes traffic evenly across two or more servers that are physically hosted in the same location.

Multi-origin load balancing extends that approach across origin servers in different geographical locations. The Peakhour EDGE can select the closest origin server to a user, or choose a different origin based on criteria such as device type, user preferences, or URL. For requests not stored in the CDN, this reduces the time spent crossing long network paths.

Real-Time Performance Monitoring: Peakhour continuously monitors its global network of servers in real time. This allows the system to detect potential issues or bottlenecks and adjust routing. If one origin server experiences high traffic or goes offline, Peakhour can reroute user requests to the next best server to keep the site responsive.

Adaptive Content Caching: Peakhour Edge uses adaptive content caching strategies, which dynamically cache both static and dynamic content based on user behaviour and request patterns. Frequently requested dynamic elements, such as personalised user data or search results, are cached on edge servers, reducing the need to fetch content from the origin servers and further minimising latency.

Load Balancing and Failover: Peakhour's multi-origin load balancing is complemented by load balancing and failover mechanisms. These features keep the system resilient and responsive during periods of high traffic or server outages. By distributing user requests evenly across origin servers and automatically redirecting traffic when a server fails, Peakhour maintains a stable and reliable content delivery experience for users worldwide.

Conclusion

Multi-origin load balancing addresses the limitations of traditional CDNs by optimising content delivery for a global audience. Peakhour Edge reduces latency and improves the experience for users who would otherwise wait on a distant origin server.

As web content and applications grow in complexity and reach, origin placement and routing become part of performance planning. Peakhour implements multi-origin load balancing with clients' origin servers so requests can be sent to the most suitable origin instead of treating a single distant server as the only fallback.