The challenge
The client runs a loyalty programme across a group of mid-market hotels in Europe. Members accumulate points on stays and redeem them for free nights and room upgrades, or transfer them to airline frequent flyer programmes. Several million registered accounts, active enough that points have real monetary value to members and, it turned out, to attackers.
The fraud team spotted it first. An unusual volume of points-to-miles conversion requests, all routing to the same small set of airline frequent flyer numbers. The accounts initiating the transfers looked normal: real members, real historical activity, real email addresses. Just not the real owners converting them.
Credential stuffing: attackers had been running leaked username and password pairs against the loyalty login endpoint for weeks. Successful logins got harvested and queued for conversion — hotel points transferred to airline miles through the programme’s partner integrations. By the time the fraud team flagged it, roughly €85,000 in points had been transferred out. Points-to-miles transfers are not reversible through normal programme channels. No points came back.
The security team looked at the logs and saw nothing alarming. No rate limit breaches, no unusual error rates. The attack ran at around one request every few minutes per IP address, spread across thousands of residential proxies. It stayed comfortably under every threshold the team had configured.
That’s the nature of credential stuffing done well. It doesn’t look like an attack. It looks like a lot of people slowly logging in.
The approach
We were brought in with two priorities: stop the ongoing losses and establish how far back the compromise went.
Forensic review
We pulled 90 days of login event data and ran behavioural analysis — timing regularity, device fingerprint cycling, success rate anomalies by IP subnet, session behaviour after login. The attack had started 34 days before the fraud team’s flag. Roughly 1,400 accounts had been accessed by someone other than their owner. About 600 had been drained.
The client’s security team notified affected members in parallel while we moved to protection.
Bot Manager Premier
We deployed Akamai Bot Manager Premier on the login endpoint in observation mode. Within hours, it had classified a significant portion of active traffic as known automated credential testing tools. The detection works because credential stuffing frameworks leave consistent fingerprints in TLS handshakes, JavaScript execution behaviour, and HTTP request patterns — signals that don’t change when the IP rotates. The attack was using at least two distinct frameworks, both with known fingerprints in Bot Manager Premier’s detection model.
The behavioural gap between real users and stuffing traffic was clear too. Real members arrive with a browser session, take time on the form, and show natural timing variance. The attack traffic had machine-precision timing and no meaningful prior session.
We moved to active blocking within 24 hours. Known tool signatures were blocked outright. Unclassified suspicious sessions received a transparent challenge — invisible to real users, ineffective for scripted clients.
Hardening the endpoint
The login endpoint accepted credentials directly over a JSON API with no session prerequisite — the same interface the mobile app used. We added a lightweight token exchange requiring a valid session from a browser or the official app before credentials could be submitted. Legitimate users and the mobile app were unaffected. The cost of running credential testing tools against the endpoint went up significantly.
The results
From the day Bot Manager Premier went active, account takeovers stopped. No new fraudulent transfers occurred post-deployment.
The 1,400 affected members were notified and had their accounts reset. The client reimbursed the 600 members whose points had been converted. The €85,000 in transferred miles was gone — the reimbursement came entirely from the hotel group’s fraud budget.
Legitimate login traffic was unaffected. No increase in authentication failures, no member complaints, no degradation in the booking funnel.
What made it work
Rate limiting is built for volume attacks. Credential stuffing at scale doesn’t need volume — it needs patience and IP diversity, both of which are cheap to buy. An attacker running 10 requests per minute across 5,000 proxies generates 50,000 attempts per hour without triggering a single rate limit. If your only defence is thresholds, you don’t have a defence.
Bot Manager Premier identifies the tooling, not just the traffic pattern. The fingerprints — TLS cipher suites, JavaScript sensor behaviour, HTTP/2 patterns — persist regardless of how slowly the attack runs or how many IPs it rotates across. That’s what made moving from observation to full protection in 24 hours possible. The attack wasn’t subtle once we were looking at the right signals.
The session prerequisite was worth adding regardless. It’s not a substitute for Bot Manager Premier, but it narrows the attack surface and raises the cost of automating against the endpoint. Good defence in depth: cheap to add, meaningful reduction in exposure.