Peakhour.IO - Account Protection

Five Routes, Five Residential Proxy Decisions

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

Account creation and password reset may sit under the same /account/ prefix. They are not the same security decision. One creates a new identity; the other can transfer control of an existing one.

The same problem appears when a team applies one residential-proxy action across login, checkout, and public APIs. Low-risk traffic is rejected, shared networks create support cases, and the attacker moves to an unlabelled exit or another route.

Policy has to begin with what each request can do. These five routes have different identities, costs, recovery paths, and abuse patterns, so the proxy result changes each one differently.

1. Account Creation

Signup abuse creates fake accounts for promotion fraud, spam, inventory reservation, scraping, or later account farming. A residential proxy helps the operator distribute registrations and make geography look ordinary.

Useful evidence includes:

registrations across a shared device or fingerprint cohort;
repeated email, phone, payment, referral, or promotion patterns;
verification completion and time to complete;
route sequence before and after signup;
residential proxy and network context;
account creation velocity across IPs and client cohorts.

A first-seen proxy result may only justify logging. Proxy use combined with repeated device evidence and failed verification can justify a shared limit or stronger verification. Preserve legitimate households and mobile networks by avoiding one-account-per-IP assumptions.

2. Login

Login protection has to handle password mistakes, credential stuffing, password spraying, and targeted account takeover without turning the attack into an account lockout service.

The OWASP Credential Stuffing Prevention Cheat Sheet recommends layered controls including MFA, breached-password checks, connection and device fingerprinting, and defence in depth.

For a residential proxy login, look at:

exposed credential state;
failures against this account across all IPs;
accounts attempted by this client cohort;
familiar device and session history;
normal or abnormal route sequence;
success, failure, MFA, and challenge outcomes.

One failure from a new address is weak evidence. Distributed failures across many accounts with a shared cohort are stronger. Rate limit the behaviour, not merely the exit.

3. Password Reset

Password reset is both a recovery mechanism and a route to account control. It also leaks information if response behaviour reveals whether an account exists.

OWASP's Forgot Password Cheat Sheet recommends consistent messages and response timing, side-channel delivery, rate limiting, and protection against excessive reset requests.

Residential proxy use should raise attention when it appears with account enumeration, repeated reset initiation, token guessing, or a new client followed by recovery-factor changes.

The action may be a tighter account-and-cohort limit, delayed processing, step-up verification, or a user notification. A broad IP block can stop legitimate recovery for every person sharing the exit.

4. Checkout and Stored Value

Checkout risk is not limited to card testing. Automated clients can reserve scarce inventory, abuse promotions, drain loyalty balances, test stored payment instruments, or change shipping details after account takeover.

Connect the network signal to the transaction:

established account and device history;
payment, address, basket, and promotion changes;
velocity across accounts and instruments;
prior login or recovery risk in the same session;
repeated declines and response patterns;
inventory or application cost created by the request.

A proxy signal on a normal repeat purchase may add little. The same signal after a breached-credential login and recovery-email change should carry more weight. Step-up verification or a bounded transaction hold can be safer than a network-wide deny.

5. Public and Partner APIs

APIs often lack browser JavaScript and interactive challenge support. They may also expose expensive search, export, GraphQL, or object-access operations.

Use the identities the API already has: tenant, token, API key, client certificate, object, operation, and schema outcome. Add network and fingerprint cohorts where they help group rotation.

The OWASP API Security Top 10 calls out unrestricted resource consumption and unrestricted access to sensitive business flows. Residential proxy rotation can distribute both. Route-aware limits should account for operation cost rather than applying one requests-per-minute value to the whole API.

Machine clients cannot complete a browser challenge. A predictable 429, reduced operation budget, token step-up, or deny response may be the correct protocol action.

One Signal, Five Policies

Peakhour Residential Proxy Detection feeds proxy evidence into the request decision with IP, credentials, device, behaviour, and route context. Advanced Rate Limiting can count using route, ASN, country, IP, TLS fingerprint, response code, and other request attributes.

That allows each route to have its own contract:

Route	Primary concern	Useful action
Account creation	Scaled fake accounts	Verify and limit across client cohorts
Login	Credential reuse and spraying	Count failures across account and cohort
Password reset	Enumeration and account recovery abuse	Consistent responses, account limits, step-up
Checkout	Fraud and stored-value loss	Transaction-aware verification or hold
API	Resource and business-flow abuse	Identity- and cost-aware limits

Run new policies in monitor mode first. Record proxy prevalence, actions, successful completion, false positives, challenge outcomes, and origin cost. Move to enforcement by route, with an owner and rollback condition.

The implementation work is to give each route an explicit contract, then verify that its action protects the journey it was written for. A shared proxy result can feed all five contracts without forcing all five routes into the same response.

Credential Stuffing Through “Clean” Residential IPs

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

The login came from an Australian consumer ISP. The address had no bad reputation and submitted one password. Viewed alone, the request barely deserved a second look.

Across the account population, the same client pattern was trying credentials against one user after another while the source addresses changed. Residential proxy networks make that distribution cheap: each exit stays below a simple threshold, the geography looks plausible, and the campaign moves before an address develops a history.

That is what the operator is buying when an exit is sold as “clean”: borrowed trust from the network and the people who normally use it. The application has to find continuity somewhere other than the address.

The Credential Is Only the Start

The OWASP Credential Stuffing Prevention Cheat Sheet recommends layered defences because no single control reliably separates every legitimate login from automated reuse. MFA, breached-password checks, device and connection signals, rate limits, and user notifications address different parts of the problem.

At the edge, the request already carries several useful facts:

the login route and response outcome;
the account or username being attempted;
whether the credential is known to be exposed;
residential proxy and broader IP context;
network and browser fingerprint cohorts;
device and session history where available;
recent attempts against this account and from this client pattern;
what the client does before and after the login request.

Peakhour Breached Credential Scanning scores credential exposure beside proxy use, IP reputation, device history, behaviour, and login context. A breached match is not an automatic conviction. People reuse exposed passwords without knowing it. The match becomes urgent when it appears inside an active attack pattern.

Count Across More Than the Address

An IP-only login limit still protects against crude repetition. It sees one slice of the campaign.

Credential stuffing needs counters that see both sides of the distribution:

per account:     failed logins across all network sources
per cohort:      failed logins across rotating IPs
per credential:  exposed match plus repeated failure or success
per campaign:    shared route, timing and client shape across accounts

These counters answer different questions. A per-account limit protects one user even when every attempt comes from a new address. A fingerprint-cohort limit exposes a tool working through many accounts. A breached-credential match raises the cost of accepting an otherwise ordinary-looking login.

Avoid permanent lockouts based only on attack traffic. They can be turned into a denial-of-service mechanism against known users. Throttling, temporary holds, step-up verification, and user alerts usually offer safer recovery paths.

Watch the Whole Account Journey

Stopping at the login form creates a blind spot. A successful credential-stuffing attempt may move immediately to:

token issue and refresh;
email or phone change;
password reset and MFA recovery;
stored payment, wallet, loyalty, or gift-card access;
address changes and checkout;
creation of new API credentials or trusted devices.

Our article Credential Stuffing Does Not Stop at the Login Form covers those post-authentication routes. The important operational point is continuity: the same risk evidence should remain available when the session reaches a high-consequence action.

A login accepted after a breached-credential match and residential proxy signal may still be allowed, but the session should not become fully trusted merely because the password worked. A recovery-email change or stored-value transfer can require stronger evidence.

“Clean” Is a Property of the Dataset

Security teams often say an IP is clean when it is absent from known abuse and proxy lists. That is a statement about current knowledge, not the connection's owner or purpose.

Google's 2026 IPIDEA disruption report described millions of devices being removed from an available proxy pool and many tracked threat groups using the exits. Google also found multiple SDK brands and reseller relationships connected to shared infrastructure.

The lesson is not that every unlabelled residential address is hostile. It is that a negative lookup cannot carry the decision. Freshness, private supply, reseller overlap, and device churn create a period in which the request arrives before the label.

Peakhour's Residential Proxy Detection evaluates the live request and places the result inside the wider account decision. Browser evidence can add context, while login APIs still receive network, credential, route, rate, and outcome controls without depending on JavaScript.

Apply Friction Where the Consequence Changes

For login and account routes, policy might respond like this:

Allow a familiar session with no adverse credential or behaviour evidence.
Log a residential proxy result on a low-risk or first-seen login.
Rate limit distributed failures across the account and client cohort.
Challenge when proxy use, an exposed credential, and unusual device or route behaviour agree.
Require step-up verification for recovery, payment, or account-control changes.
Block a confirmed automated campaign with bounded route and policy scope.

Measure successful login and recovery completion beside attack reduction. A control that suppresses failures by preventing real customers from signing in is not a successful account-protection policy.

Treat “clean” as a statement about the dataset at that moment. Make the account decision from the credential, client, route, and recent outcomes that arrived with the address.

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.

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.

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.

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.

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.