The CEO’s personal Gmail is in a stealer log

The call is rarely “we were breached.” It is “someone forwarded me a screenshot of my CEO’s Gmail, and a password, and it looks like it came off the dark web.”

That is usually an infostealer log. RedLine, Lumma, Vidar, whatever is fashionable this quarter. A laptop or a home PC ran a loader. The malware lifted the browser: cookies, saved passwords, autofill, session tokens, sometimes Discord, sometimes a crypto wallet extension. The log was packed, sold, and is now searchable.

Corporate SSO can be perfect. Conditional access can be boring and correct. None of that follows the CEO onto a personal MacBook at 23:00.

What a stealer log is not

It is not proof that the company tenant was popped. It is not ransomware. It is not “the dark web has our database.”

It is a copy of what one browser knew. Often the personal Gmail. Often the LinkedIn session. Often a reused password that still opens a vendor portal someone forgot existed. Sometimes an old @company.com that was never deprovisioned from a phone.

The useful question is not “is the dark web real.” The useful question is: which identities in this log are still live, and which of them can walk into something that matters.

Why executives show up first

Executives have messy personal surfaces. A Gmail from 2009. A Hotmail they use for domain-registrar recovery. A boarding-pass airline login. A Google session that still has the company calendar synced “just for travel.”

Attackers do not need to phish the SOC. They buy a log, grep for the last name, and try the sessions. A stolen cookie skips the password. MFA was for the password.

If the same password appears next to the corporate mailbox in the same file, you now have a credential-stuffing problem on the tenant and a personal-account problem. Those are different owners, different resets, same week.

What to do before you “monitor the dark web”

Identify the mailbox, not the vibe. Personal Gmail, iCloud, the registrar, the old domain. Write down every address in the log that is theirs. Guessing first.last@ the company is how you invent a second incident.

Assume the browser is hostile until it is wiped. Password change on a still-infected machine is theater. Session cookies will be re-stolen. The endpoint — home laptop, spouse PC, the iPad that “isn’t work” — is in scope even if IT does not own it.

Rotate sessions, not just passwords. Google, Microsoft personal, Apple ID, LinkedIn, GitHub, domain registrar, password manager. Sign out everywhere. App passwords. Recovery mailbox. If a token was in the log, the password reset is incomplete.

Check reuse against the company. If the personal password equals any corporate password, ever, treat the tenant as exposed to stuffing until you know otherwise. That is the one moment internal identity has to be told, even if the original log was “personal.”

Do not pay a takedown guy on Telegram. The log is already copied. You are buying a listing to be renamed, not a file to be uninvented.

What I look at

I have read a lot of these files. The work is matching: is this their Gmail or a lookalike. Is the password current. Is there a *.okta.com or login.microsoftonline.com cookie. Is the log from a date that still matters. Did the same bot hit three other executives at the same company, which means a shared machine or a shared bad habit.

Dark-web “monitoring” that emails you “your domain was mentioned” is not this. Mentions are cheap. A stealer line with a live session is a thing you can revoke today.

If a board member forwards a screenshot of a CEO’s personal inbox sitting in a marketplace: do not argue about whether infostealers are overhyped. Pull the log. See whether the session still answers. Then rotate the human, not the brand.