What happens to your users' data after a web app is breached — the marketplaces, the buyers, the resale economy, and what you can do about it.
Knowing how attackers monetize stolen data shapes your defenses. If you understand that a breach leaks into specific marketplaces with specific buyer profiles, your incident response and threat intelligence work get sharper. This tutorial walks through the post-breach economy for web app data specifically — what's stolen, where it goes, who buys it, and how to monitor for your own exposure.
Different data types follow different markets:
Where stolen data gets sold:
Traditional marketplaces with reputation systems. Vendors and buyers anonymous to each other but accountable through escrow and reviews. Examples in the last decade: AlphaBay, Hansa, Hydra, Genesis Market, Russian Market.
Increasingly dominant for credential and access trade. Lower bar to participation than Tor. Channels with thousands of subscribers buying/selling/discussing in real time.
Long-running boards (some 15+ years old) where higher-tier criminals meet. Examples: Exploit.in, XSS.is, Verified.
Some platforms automate the whole flow. Buyer searches for compromised accounts at a specific company, pays in crypto, gets credentials delivered automatically. Genesis Market (taken down 2023) was the most famous example. Successors continue to emerge.
This is worth a dedicated section because it's a common and underestimated attack vector.
Tools that automate this: "Cookie Cloner," various stealer malware (RedLine, Vidar, Raccoon), browser extensions sold for the purpose.
MFA happens at login. Session cookies represent an already-authenticated session. Once issued, they're trusted until expiry. Attackers buy session cookies specifically to bypass MFA.
/admin/*, password change, payment method change all require fresh authentication.# settings.py
SESSION_COOKIE_AGE = 60 * 60 * 8 # 8 hours
SESSION_EXPIRE_AT_BROWSER_CLOSE = True # logout on browser close
SESSION_COOKIE_SECURE = True # HTTPS only
SESSION_COOKIE_HTTPONLY = True # No JS access
SESSION_COOKIE_SAMESITE = 'Strict' # CSRF defense
# Force re-auth for admin actions
from django.contrib.auth.decorators import login_required
from django.contrib.auth.mixins import LoginRequiredMixin
def require_fresh_auth(max_age_seconds=600):
"""Require recent password verification within max_age_seconds."""
def decorator(view_func):
def wrapper(request, *args, **kwargs):
last_auth = request.session.get('last_password_auth')
if not last_auth or (time.time() - last_auth) > max_age_seconds:
return redirect(f'/reauth/?next={request.path}')
return view_func(request, *args, **kwargs)
return wrapper
return decorator
@require_fresh_auth(max_age_seconds=300)
def delete_account(request):
...
If your app gets breached or your users' credentials get harvested elsewhere and tried against you, you want to know early.
*@yourcompany.com appearing in new leaks)# Periodic check (cron job) — alert on new breaches of your domain
import requests
def check_pwned_domain(domain: str, api_key: str):
headers = {"hibp-api-key": api_key}
r = requests.get(
f"https://haveibeenpwned.com/api/v3/breaches?domain={domain}",
headers=headers,
timeout=10,
)
r.raise_for_status()
breaches = r.json()
# Compare against last known list, alert on new ones
return breaches
For HIBP's password check on user login (free, anonymous via k-anonymity), the implementation in tutorial 2 covers it.
A genuine question many companies face. The wrong answer: try to buy it back. (You can't verify the data was deleted; you fund the criminal economy; you may be committing crimes yourself.)
The right responses:
Investigate the source. Where did this come from? Recent breach? Compromise of a partner? Insider exfil? You need to know to prevent recurrence.
Notify affected users. Within 72 hours per GDPR if personal data is involved. Honest, clear communication: what happened, what's at risk, what users should do.
Force password resets and revoke sessions. Even if passwords were hashed, assume worst-case. Invalidate any session/token issued before the breach.
Engage legal counsel. Notification requirements vary by jurisdiction and data type. Get advice early.
Engage law enforcement. Dutch NCSC, Politie Cybercrime Team, or sector regulators. They may have visibility into the seller or related cases.
Engage a DFIR firm if scope is unclear. Specialized firms (KPMG, Deloitte, Northwave NL, Fox-IT, smaller boutiques) handle investigation and stakeholder communication.
Post-incident review. What detection should have caught this earlier? What controls could have prevented it? Update your IR playbook.
Understanding the criminal economy is what makes these threats concrete rather than abstract. Stolen data has market prices that reflect its usefulness: a working set of credentials, a session token that bypasses login, a full identity profile each command different amounts depending on freshness and the access they unlock. This is a real economy with sellers, buyers, intermediaries, and reputation systems, and your application's data is potential inventory in it. Seeing the threat through this economic lens clarifies why attackers want what they want and how they monetize it, which in turn tells you what to protect most fiercely — the data and access that are worth the most to them.
Because people reuse passwords, a credential leaked from one breached site is tried automatically against thousands of others — credential stuffing. Attackers run these at enormous scale with automated tools and lists of billions of leaked pairs, and even a tiny success rate yields many compromised accounts. This is why a breach elsewhere becomes your problem, and why defenses like rate limiting, anomaly detection on login patterns, and offering strong multi-factor or passwordless authentication matter so much. The reused password is the thread that connects every breach into a single ongoing risk, and credential stuffing is the machine that exploits it across the whole web continuously.
The longer a compromise goes unnoticed, the more damage it does, so early detection is a defense in itself. Watch for the signals: logins from unusual locations or devices, sudden bursts of failed attempts, access patterns that do not fit a user's history, data being exported in volume. Logging these events and alerting on anomalies turns a silent, months-long breach into one you catch in hours. The data trade depends on stolen access staying valid and undetected; making your environment one where unusual activity is quickly noticed and acted on directly undercuts the value of whatever an attacker manages to steal from you.
Even when your own systems are sound, your users are exposed by breaches at other services through reused passwords, and a responsible application helps protect them. Checking new passwords against known-breached password lists, prompting for stronger authentication on sensitive actions, and notifying users of suspicious account activity all reduce the chance that someone else's breach becomes a compromise on your platform. This protective posture toward your users — recognizing that their security is partly shaped by events outside your walls — is part of operating responsibly in an ecosystem where stolen credentials circulate constantly and inevitably get tried against you.
Your users' data, once stolen, doesn't disappear. It circulates. It's sold. It's used in attacks against you and against unrelated services for years. The damage extends well beyond the initial breach.
That's why prevention matters so much. Detection-and-response is valuable, but the gap between "data stolen" and "first downstream attack" is often days, sometimes hours. By the time you're responding, the data is already in markets.
Prevention starts with the basics from tutorials 1-2. Detection (tutorial 10) catches what prevention misses. Both layers, both serious, both ongoing.