Some attacks announce themselves with malformed requests and datacenter IP ranges. The most dangerous ones look exactly like your best customers. Cequence recently encountered an incident of the latter kind alongside a major consumer brand — a large, patient, and genuinely sophisticated automated abuse campaign against a high-value prize sweepstakes — and the telemetry is worth understanding.
6.7M
Automated entry attempts blocked across the event
538K
Distinct residential/mobile IPs behind the attack
409
Device fingerprints those 538K IPs funneled through
0
Impact to legitimate entrants
The prize
A leading national brand runs one of the most popular customer-rewards programs in its industry — a long-running weekly program that thanks customers with free items, partner deals, and a rolling series of high-value prize sweepstakes. When a new offer goes live, tens of millions of people show up at once.
Sweepstakes law in the U.S. requires that a prize giveaway offer a free Alternate Method of Entry (AMOE) — a “no purchase necessary” path open to the public, not just paying customers. That path is, by design, low-friction and open to anyone. The combination — a legally open entry point, no account required, and a valuable prize on the other side — is what makes it a magnet for automation. The week of the attack, the prize was a free one-year subscription to a popular consumer service.
The economics are simple: if one entry gives you a small chance at a valuable prize, ten thousand automated entries give you ten thousand chances. Sweepstakes abuse is a business-logic attack; every individual request is a perfectly valid entry submission. There is nothing “malformed” to catch.
An attack hiding in real traffic
Rather than using a quiet API endpoint where a traffic spike would stand out, they timed their automation to ride the legitimate entry ramp, using the real promotional surge as cover. For much of the day, the malicious entries blended into a crowd of genuine ones.
Cequence Bot Management detection and mitigation engaged continuously, but the attackers retooled three distinct times as they probed for openings.
First sustained wave: Static user-agent and business-logic-abuse policies handled most of the traffic, with fingerprint-based blocking mitigating the afternoon peak.
The sophisticated retool: Volume and evasion both increased. This wave required new policies, and machine-learning models were promoted into blocking mode in real time.
The overnight flood: After a brief lull, a far larger surge began and kept climbing well past midnight.
The attack looked human
This was not cheap bot infrastructure, and that is the whole point. Of the traffic Cequence blocked:
It came from home and mobile networks. 538,081 distinct source IPs spread across 6,507 ISPs — mainstream residential cable, fiber, and mobile carriers. This was well-provisioned residential-proxy infrastructure, not a datacenter.
Reputation lists were useless. Fewer than 0.05% of the blocked IPs appeared in any third-party proxy or VPN threat feed. An IP-reputation-based defense would have missed virtually all of it.
It presented as ordinary browsers. Chrome on Windows, Chrome Mobile on Android and iOS, Edge, Safari — mainstream consumer stacks with no headless markers and no unusual user-id strings in the top cohort.
It scored “maybe.” Median bot-confidence on the blocked traffic that deliberately stayed below the range most tools treat as an obvious giveaway.
If you judged this traffic one request at a time, it would pass. The appearance of the request didn’t give it away — it was the shape of the traffic in aggregate:
538,081 residential and mobile IP addresses across 6,507 ISPs, all funneled through just 409 distinct device fingerprints.
Real human traffic does not cluster like that. Roughly thirteen hundred “different” IP addresses per fingerprint is the fingerprint of a single automation toolkit replayed across a rented proxy pool. That one ratio — enormous IP and ISP diversity paired with a narrow, repeating device footprint — is what let fingerprint-based, identity, and session-velocity policies separate the automation from genuine entrants without the source IPs ever appearing suspicious.
Collaboration in real time
What turned a sophisticated attack into a non-event for the brand’s customers was the combination of an adaptive platform and a live human response working the incident together.
As the attacker retooled through the evening, the Cequence SOC analyst on call iterated through new controls in sequence — promoting tuned rules from monitor to block, standing up threshold-based and session-velocity controls, and running Cequence’s machine-learning capability that models a novel attack pattern directly and generates a targeted blocking model.
Crucially, no single control counted as a silver bullet. When one model’s recall proved insufficient on its own, it became one layer of a stacked response rather than the whole answer. Within an hour, the newly stacked controls had largely neutralized the evening wave.
Then came the overnight escalation the evening response had to scale into. The same fingerprint- and identity-based policies stood up earlier in the day didn’t need to change. They simply absorbed the flood at far greater scale, exactly as intended, while two new models were promoted into action. The newest rules carried nearly 94,000 blocks within twenty minutes of activation — an early burst that kept climbing toward the sustained overnight peak described below.
How it ended
The campaign crested in the midnight–1:00 AM hour, with roughly 1.59 million entry attempts blocked in that single hour — the peak of the incident. From there, the stacked controls drove enforced volume down by an order of magnitude within about two hours, and by the pre-dawn hours the attack had collapsed from well over a million blocks an hour to a few hundred.
Across the full event, Cequence blocked roughly 6.7 million automated entry attempts against the sweepstakes’ public entry flow. Legitimate entrants — the customers the program exists to reward — continued submitting their entries throughout, unaffected.
Phase
What happened
Peak enforced blocks
Afternoon
First sustained automation wave
~66K / hr
Evening
Sophisticated retool; new policies + AFD models live
~59K / hr
Overnight
Massive residential-proxy flood
~1.59M / hr
Pre-dawn
Stacked controls take hold; attack collapses
Hundreds / hr
Cequence has blocked on the order of 7.7 million automated entry attempts against this one endpoint since the campaign began. The adversary is patient and persistent; the defense has held every week — because it was built to run continuously and scale on demand.
The takeaways for any high-value promotion
Open, high-value entry points are automation magnets. Anything that converts a low-friction request into a shot at real value — sweepstakes entries, promo codes, loyalty points, gift-card checks — will attract bots. Legally required “no purchase necessary” paths are especially exposed because they’re meant to be open.
Modern abuse looks just like your customers. Residential proxies plus real browser stacks defeat IP reputation, WAF signatures, and user-agent heuristics. The signal that survives is behavioral and identity-based: how sessions cluster, how many “independent” IPs share one device fingerprint, how many entries trace to one subscriber.
A layered stack beats any single control. Fingerprint, subscriber-identity, session-velocity, and adaptive ML controls reinforced each other throughout the event, tuned live by a SOC team that modeled each new wave as a distinct problem rather than simply absorbing another spike.
Adaptive detection plus human collaboration beats a static product. The attacker changed tactics three times in a single day — and has come back every week since. The response has kept pace each time, because the platform and the people operating it adapt continuously.
Learn how Cequence Bot Management can keep your next promotion fair for real customers and closed to the bots. Request a personalized demo today.
Author
Tushar Arora
Senior Manager, Technical Customer Success
Tushar Arora is Senior Manager of Technical Customer Success at Cequence Security, where he drives AI & MCP implementations and discovery-to-remediation around API security for Tier-1 enterprise accounts. Over a career spanning more than twenty years, he has built and delivered programs at the intersection of payments and platform security — from Amazon Pay at Amazon and BloxOne SaaS at Infoblox to payment infrastructure and PCI compliance work at TD Bank, Verifone, and First Data. He holds an MBA in Information Technology and is a certified PMP, Scrum Product Owner, and Six Sigma Yellow Belt.
Sign up for the latest Cequence Security news
By clicking Subscribe, I agree to the use of my personal data in accordance with Cequence
Security Privacy Policy. Cequence Security will not sell, trade, lease, or rent your
personal data to third parties.
Used to monitor number of Google Analytics server requests when using Google Tag Manager
1 minute
_gid
ID used to identify users for 24 hours after last activity
24 hours
_ga_
ID used to identify users
2 years
_gali
Used by Google Analytics to determine which links on a page are being clicked
30 seconds
_gac_
Contains information related to marketing campaigns of the user. These are shared with Google AdWords / Google Ads when the Google Ads and Google Analytics accounts are linked together.
90 days
__utmx
Used to determine whether a user is included in an A / B or Multivariate test.
18 months
__utmv
Contains custom information set by the web developer via the _setCustomVar method in Google Analytics. This cookie is updated every time new data is sent to the Google Analytics server.
2 years after last activity
__utmz
Contains information about the traffic source or campaign that directed user to the website. The cookie is set when the GA.js javascript is loaded and updated when data is sent to the Google Anaytics server
6 months after last activity
__utmc
Used only with old Urchin versions of Google Analytics and not with GA.js. Was used to distinguish between new sessions and visits at the end of a session.
End of session (browser)
__utmb
Used to distinguish new sessions and visits. This cookie is set when the GA.js javascript library is loaded and there is no existing __utmb cookie. The cookie is updated every time data is sent to the Google Analytics server.
30 minutes after last activity
__utmt
Used to monitor number of Google Analytics server requests
10 minutes
__utma
ID used to identify users and sessions
2 years after last activity
Clarity is a web analytics service that tracks and reports website traffic.