VOOZH about

URL: https://dev.to/devaonbreaches/stealer-logs-in-xposedornot-4an3

⇱ Stealer logs in XposedOrNot - DEV Community


I've been running XposedOrNot for years now. The pitch has always been simple: type in an email, find out if it's turned up in a data breach. Free, no signup, open source. Millions of lookups later, it still does exactly that.

But I've had a nagging feeling for a while that we were only answering half the question.

When someone asks "has my email been exposed?", a breach is the obvious answer. Some company got hacked, their user table leaked, your record was in it. Fair enough. But there's a second way your data ends up for sale, one that has nothing to do with a company being careless, and it's been growing fast: stealer logs.

I finally built coverage for them. We're starting with one source, AlienStealer, and more are on the way. Here's what it is, why it nagged at me, and how to actually use it.

Breach vs. stealer log, in plain terms

A breach is server-side. One service gets popped, the records for that service spill out. You reset that one password and you're mostly fine.

A stealer log is the other end of the spectrum. It's client-side. Some bit of infostealer malware lands on a device (a cracked installer, a sketchy "free" tool, a phishing attachment) and quietly scrapes whatever the browser and local apps will hand over. Saved passwords, autofill, crypto wallets, and the part that actually bothers me, session cookies and tokens. All of it, across every site that device touches, packaged into a "log" and sold.

Data breach Stealer log
Comes from A service's database An infected device
Scope One account, one service Every saved login on the device
Payload Mostly credentials Credentials, plus live cookies and tokens
What fixes it Reset that password Treat the whole device as compromised

Here's the bit I want every developer to sit with for a second. Stealer logs include live session cookies. An attacker can sometimes replay a session straight into a logged-in state without ever touching the password, and without tripping MFA. If you build auth for a living, "but they had 2FA on" stops being the comfort it usually is.

Those stealer logs are exactly what account-takeover and ransomware crews buy to skip straight past the front door. So yeah, I wanted XposedOrNot to actually see this.

What I shipped

Stealer-log hits now show up in the same lookups you already use. Same email search, same API. The one difference is the type: an entry that came from a stealer log is tagged as one, so you can tell it apart from a regular breach and handle it differently. Because you should.

AlienStealer is the first source in. It won't be the last.

Using it

If you've touched the API before, there's nothing new to learn. Free endpoint, no key:

curl https://api.xposedornot.com/v1/check-email/you@example.com
{"breaches":[["LinkedIn","Tesco","AlienStealerLogs"]],"email":"you@example.com"}

That just gives you names. To tell a stealer log apart from a regular breach, pull the breach record from /v1/breaches. The field you want is breachType:

curl "https://api.xposedornot.com/v1/breaches?breach_id=AlienStealerLogs"
{"status":"success","exposedBreaches":[{"breachID":"AlienStealerLogs","breachType":"Stealer Logs","exposedData":["Email addresses","Passwords","Browser Cookies","Autofill Data"],"exposedRecords":1542300,"passwordRisk":"plaintext","searchable":true,"verified":false}]}

breachType is your branch point. Everything else (exposedData, exposedRecords, passwordRisk, verified, and so on) is there too. The values above are illustrative, but the field names are straight from the API source.

Need the per-email picture instead of the per-breach record? breach-analytics returns the same source under ExposedBreaches.breaches_details, in snake_case:

curl "https://api.xposedornot.com/v1/breach-analytics?email=you@example.com"
{"breach":"AlienStealerLogs","xposed_data":"Email addresses;Passwords;Browser Cookies;Autofill Data","xposed_records":1542300,"xposed_date":"2024","password_risk":"plaintext","searchable":"Yes","verified":"No"}

One gotcha worth knowing: breach-analytics doesn't carry the type flag, so if you're classifying sources, branch on breachType from /v1/breaches. No SDK needed for any of this, plain requests does it:

import requests

r = requests.get("https://api.xposedornot.com/v1/breaches",
 params={"breach_id": "AlienStealerLogs"})
for b in r.json().get("exposedBreaches", []):
 if b["breachType"] == "Stealer Logs":
 print(f"{b['breachID']} is a stealer log: {b['exposedData']}")

Where I'd actually wire this in

  • At signup or login. If an account's credentials show up in a stealer log, step up verification. The password may already be replayable, so don't lean on it alone.
  • Across your org. One infected laptop can quietly expose a company. The domain exposure check scans a whole validated domain, and the CXO / VIP dashboard keeps watch on the people attackers go after first.
  • In your SOC playbooks. A stealer-log hit is a strong signal to kill active sessions, not just force a reset.

The part I care about most

XposedOrNot has been open source since day one, and that doesn't change because we added a new data type. The API is MIT licensed, and the whole thing is on GitHub. Password checks use k-anonymity, so only a partial hash ever leaves your machine, and email lookups aren't stored. You don't have to take my word for any of it. Read the code.

If you give it a spin and it earns a spot in your stack, a star on GitHub honestly makes my day. And if something's broken, or you've got an idea for the next stealer source we should add, tell me.
That's half the reason it's open.

Go check an email or a domain. Worst case, you learn something.

Devanand Premkumar,
Founder XposedOrNot