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.
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.