Ahmed Saleh
2026/08/19
One seat, 41 people: how account sharing hid a scraping and resale ring
Every week I take one real fraud or abuse case, walk through what the actor actually did, and list the rules you can add to your own trust engine because of it. This is edition #004.
This week: one seat was shared with 41 people, who then scraped the platform, and the data ended up resold.
How it happened
1. One legitimate seat
A real company, a real person, an Enterprise subscription with a card on file. Nothing about this account looked like a problem, which is exactly why it's worth writing up. Nobody goes digging inside a healthy enterprise seat.
2. The team rides along
Five colleagues start working off his login instead of buying their own. Normal enough. Every SaaS company has some of this.
3. It goes overseas
Then the data work gets handed to freelancers abroad. Same login. Usage, devices and IPs start piling up, and the same login starts appearing from Pakistan.
4. Out of control
Thirty-six more people pile on. That's 41 active devices on one seat, across 227 IP addresses and 43 different internet providers.
5. Scrape and resell
A headless browser signs in and walks the data pages for 52 straight minutes. Same page, over and over, holding each one for the same number of seconds every time. Then that data shows up in reseller rings.
The harm done
Lost revenue. Only 1 in 5 of the people using this account were paying for it. Roughly 20% of the revenue this client should have been worth.
Lost new customers. The data got scraped and resold cheaper in reseller rings. Prospects can now buy it there instead of buying it from you.
Wasted team effort. Hours, meetings and distraction spent on measures that don't hold: rate limiting, seat caps, manual review.
What did work
| Signal | This seat | Normal |
|---|---|---|
| active devices on one seat | 41 | under 3 |
| remote internet providers | 43 | 1 |
| velocity | 50 standard deviations | under 3 |
The counting rule is the important part. Not how many devices have ever touched the account, but how many are active and belong to somebody other than the owner. A seat with 41 devices on it and a seat with 41 lifetime logins from the same laptop are completely different problems.
On top of that: impossible travel, concurrency and velocity, run on every page rather than only at authentication. That's what turns Miami and Islamabad inside a single session into one alert instead of two unrelated logins.
Then bot behaviour, not only hard automation signals, and known residential proxy networks scored into the risk assessment.
Rules worth adding to your engine
- Track total active devices on a seat.
- Flag sharing signals: impossible travel, concurrency, velocity.
- Do it on every page, not just at auth.
- Look for bot behaviour, not just hard signals.
- Score known residential proxies into your risk assessment.
The part that surprised me
This platform had exactly one automatic control switched on: account sharing. So every challenge it has ever issued was for sharing, and nothing else.
Of the accounts that net caught, 40% were also running scraping bots. You can rent one of those now. There's a whole commercial market for it.
The takeaway
Account sharing usually gets treated as a billing annoyance. Put a device limit on it, move on, chase the upsell later.
But pay attention to signals of abuse, because they often uncover something bigger. The people willing to share a seat are frequently the same people willing to automate it and sell what comes out. Account sharing at this scale usually means a reseller ring behind it, and stopping it properly can be double-digit revenue growth.
See this on your own traffic
Every signal in this write-up ships with Rupt. Book a demo and we will show you what is already happening inside your product.
Book a demo →Get the next case in your inbox
Trust Booster is one real fraud or abuse case a week, with the rules to catch it. Free, and it works whether or not you use Rupt.
Subscribe to Trust Booster →