Peakhour.IO - Account Protection

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.

For a protocol-level example, see A network fingerprint is a cohort, not a client. It compares the information retained by JA3, JA4 and Cisco Mercury and explains why a matching TLS value can still cover many applications and users.

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.

Anatomy of a Credential Stuffing Attack

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

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

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

What is Credential Stuffing?

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

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

The Attacker's Toolkit

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

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

The Business Impact

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

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

Building a Multi-Layered Defense

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

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

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

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

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

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.

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.

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.

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.

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.

Your Anti-Fraud Residential Proxy Detection Sucks

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

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

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

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

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

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

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

Not anymore.

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

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

The Shocking Truth: Our Results

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

Here's a summary of our findings:

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

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

Why Your Residential Proxy Detection Service is Failing You

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

The Good Old Days of Proxy Detection

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

TOR networks
VPN services
Data center proxies

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

The Rise of Residential Proxies: A New Breed of Threat

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

What Are Residential Proxies?

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

Home computers
Mobile phones
Tablets
IoT devices

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

How Are Residential Proxy Networks Formed?

This is where the problem starts:

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

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

Why Are They So Dynamic?

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

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

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

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

Shared IPs: The Needle in the Haystack Problem

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

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

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

Why Traditional Methods Are Failing (Revisited)

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

1. Port Scanning

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

import socket

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

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

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

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

2. Honeypots

Honeypots try to lure and identify proxy traffic.

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

3. Client-Side Detection

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

3.1 WebRTC Leak

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

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

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

3.2 Geolocation Inconsistencies

Comparing IP-based geolocation with browser-reported location.

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

3.3 DNS Leaks

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

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

3.4 Browser Fingerprinting

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

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

Why these techniques fail

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

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

4. Threat Intelligence

Threat intelligence involves maintaining databases of known proxy IP addresses:

import requests

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

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

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

Why IP-Based Blocking Is No Longer Enough

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

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

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

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

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

The Need for Connection-Level Detection

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

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

Final Thoughts

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

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

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

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

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

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.

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.

The Iconic is the latest Account Takeover victim in the news

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

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

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

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

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

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

Why are Account Takeover attacks carried out?

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

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

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

How are Account Takeover attacks carried out?

Common techniques used to compromise user accounts on websites include:

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

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

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

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

What can users do about it?

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

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

What can websites do about it?

Quite a bit. Websites can minimise the risk by:

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

Preventing automated log in attempts

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

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

Conclusion

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

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

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

HTTP Security Headers

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

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

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

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

Key HTTP Security Headers

Content-Security-Policy (CSP)

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

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

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

X-Frame-Options

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

X-Frame-Options: DENY

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

X-Content-Type-Options

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

X-Content-Type-Options: nosniff

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

X-XSS-Protection

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

X-XSS-Protection: 1; mode=block

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

Strict-Transport-Security (HSTS)

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

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

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

Conclusion

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

A Tale Of Two Scoring Systems

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

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

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

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

The Timeline So Far

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

Looking to EPSS for advice

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

EPSS Score Changes I Observed

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

As seen in the descending date table:

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

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

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

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

Making Sense of the EPSS Score Changes

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

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

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

EPSS vs. CVSS in My Vulnerability Management Approach

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

Are Peakhour Clients Protected?

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

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

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

This is a larger list probing for already compromised instances

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

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

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

What other protections could be applied

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

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

Addressing the Backlog of Security Vulnerabilities and Patch Timelines

The Challenge of a Growing Vulnerability Backlog

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

Patching Pace vs. Vulnerability Escalation

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

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

The Gap Between Detection and Remediation

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

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

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

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

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

What next from here?

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

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.

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.

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.

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.

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.

Enterprise DDoS Protection

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

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

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

Microsoft's Layer 7 DDoS Attacks

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

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

The Attack Methods

Storm-1359 used several attack types, including:

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

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

Azure Web Application Firewall, ModSecurity, and DDoS Attacks

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

ModSecurity's Limitations in DDoS Defence

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

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

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

The Role of Residential Proxy Networks in Layer 7 DDoS Attacks

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

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

A Potential Solution

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

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

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

The Need for Specialised Rate Limiting Services

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

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

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

Advanced Rate Limiting and Custom Keys

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

Criteria Used in Rate Limiting

Rate limits can be defined using different criteria:

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

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

The Role of Anomaly Detection

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

Caching as a Mitigation Strategy

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

Recommendations for Defence Against Layer 7 Attacks

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

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

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

The Rise of the Dragon

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

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

Understanding the New Malware

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

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

The People and Intentions Behind The Malware

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

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

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

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

The Implications of Residential Proxies

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

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

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

GeoIP Security Measures and Their Limitations

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

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

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

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

Detecting Residential Proxies: The Role of Network Fingerprinting

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

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

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

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

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

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

Residential Proxies and MITRE Framework

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

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

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

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

From Credential Stuffing to Account Takeover and Data Exfiltration

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

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

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

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

The Role of Residential Proxies in Web Scraping

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

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

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

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

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

Defending Against Proxy-Related Cyber Attacks Informed by MITRE

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

Network Monitoring and Analysis

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

Implementing Access Controls and Rate Limiting

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

Application of Web Application Firewalls (WAFs)

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

Proxy Detection and Blocking

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

User Behavior Analytics (UBA)

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

Educating Users on Security Hygiene

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

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

Detecting Malicious Use of Residential Proxies

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

Traffic Pattern Analysis

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

Behavioral Anomaly Detection

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

IP Reputation and Proxy Lists

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

Endpoint Detection and Response (EDR) Systems

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

Advanced Machine Learning Models

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

Collaboration and Information Sharing

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

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

Residential Proxy Detection

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

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

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

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

Demystifying Residential Proxies

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

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

Applications of Residential Proxies

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

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

Navigating the Risks and Concerns

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

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

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

Exploring the Creation of Residential Proxies and their Implications

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

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

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

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

The Birth of 'Ethical' Proxies

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

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

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

From Hola VPN to the Camaro Dragon

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

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

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

Legal Consequences of Residential Proxies in Data Scraping Operations

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

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

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

The Wider Implications for the Security Industry

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

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

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

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

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

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

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

Malicious Bot Threats

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

Bots are software applications that automate repetitive tasks without human interaction. They have become part of the normal infrastructure of the internet. Some bots are useful; others are bad bots. The latter are the concern for application and security teams.

Bad bots keep changing and are increasingly difficult to detect. They can cause significant financial damage to organisations by disrupting online operations, overwhelming websites with traffic, and stealing information such as web content and ecommerce pricing data.

Bad Bot Types

Bad bots span a wide range of attack capabilities and scenarios. The following are the main categories these attacks fall into:

Spam Bots

Spam bots typically target blog comment sections, community portals and lead generation forms with 'garbage' or fake content. They can also insert unwanted ads, malicious phishing links and banners into real-time conversations to disrupt the service and attack users.

Scraping Bots

Price, content and inventory scraping bots steal prices and product listings. This can damage an ecommerce site's revenue stream and harm SEO rankings when duplicate content appears on competitor and bogus sites. These bots also scrape product reviews, news, product catalogues and user-generated content. Scraper bots can harvest email addresses, images and text from victim websites, then repurpose that material to pose as legitimate web pages.

Credential Stuffing Bots

Credential Stuffing Bots attempt to use login details from other sites, or run brute force guessing attacks against customer and admin accounts. If successful, they can make purchases, harvest personal information and purchase histories, make unauthorised cryptocurrency transactions, and transfer reward points and money to gift cards and air miles.

Ad Click Fraud Bots

Ad Click Fraud Bots can sabotage competitors by clicking on their ads to drive costs up and exhaust budget caps. They can also be used to scam advertisers with fake websites and ad clicks that pay the fraudster directly. In both scenarios, bots automatically generate interactions or 'clicks' with ads, promotions and media.

Credit Card Stuffing Bots

Carding bots make repeated attempts to authorise stolen credit card credentials. This can leave merchant payment processors with chargebacks and penalties, and may ultimately result in the victim merchant being prevented from accepting credit cards altogether.

Inventory Denial Bots

Cart Abandonment and Inventory Exhaustion bots automatically add hundreds of products to ecommerce shopping carts, then abandon them. This can block consumers from buying products, reduce sales, manipulate conversion rates and damage a brand’s reputation.

DDoS Bots and Botnets

Distributed Denial of Service (DDoS) attack bots and botnets are made up of thousands of compromised computers or Internet of Things (IoT) devices called "zombies". They can slow down a website or take it offline completely by flooding sites with massive amounts of artificially generated traffic. Researchers have found cybercriminals advertising DDoS services on the dark web with basic fees to attack unprotected sites ranging from $50 to $100, while an attack on a protected site can reach $400 or more.

Ticket Scalping Bots

Ticket scalping bots automatically buy tickets, enabling malicious users to resell them at a higher price. Examples include using a bot to purchase concert tickets for major events the minute they go on sale.

Fake Account Creation Bots

Fake Account Creation bots create fake accounts for criminal activities such as content spam, cryptocurrency laundering and malware distribution. Fake accounts can compromise brands and attack users with malware such as ransomware.

Hacker Bots

Hacker bots can distribute malware, attack websites and compromise entire networks by exploiting security vulnerabilities and injecting code into victim sites. Hacker bots can also perform DDoS attacks across web proxies with browser-like signatures to disrupt business operations.

Impersonator Bots

Impersonator bots copy human computer interactions and behaviours to fool users and bot mitigation defences while they conduct malicious activity. Impersonator bots also include propaganda bots that influence political opinions on platforms such as Facebook and Twitter. According to researchers at the University of Southern California who studied bot use during the 2016 U.S. Presidential election, “the presence of social media bots can indeed negatively affect democratic political discussion rather than improving it, which in turn can potentially alter public opinion.”

The Growing Threat

A report from Imperva found that roughly one-quarter of all website traffic in 2019 originated from bad bots, an increase of 18% over 2018. 75% of that bad bot traffic is made up by Advanced persistent bots (APBs) that attempt to evade detection by cycling through random IP addresses, using anonymous proxies, and changing their identities. The industries hardest hit by bad bots in 2019 included financial services, education, ecommerce and government, as well as media and airlines.

Companies offering "Bad Bots as-a-Service"* are also gaining ground. These data scraping services sell bots as easy-to-use packaged products that provide pricing and competitive intelligence, alternative data for finance, or competitive insights managed by Web Data Extraction Specialists and Data Scraping Specialists.

Malicious bot-for-hire services also offer personal and financial data harvesting, brute-force login services, ad click fraud, spamming services, transaction fraud services, and Distributed Denial of Service (DDoS) attacks.

Final Thoughts

Bad bot activity continues to increase, so websites need security controls that can identify and stop them. Our next article on bots will go over the common countermeasures used to combat bad bots.