Dark Web Credentials We Could Actually Reset

Three work emails showed up in a dump. The founders wanted to know if anyone was in the tenant, and what to do before the next alert. They did not want a movie.

That is the usual starting point for dark web monitoring that actually produces work. A San Fernando Valley technology firm called Secure Techies after a monitoring product named their domain. They ship software. They did not want to become the after-hours help desk.

This case study records the reset, the mailbox hunt, the leftover guest, and the one-page watch. Company identifiers stay out. The method does not. We will not invent a count of accounts we “saved.”

Why they called

Product teams reuse passwords when a personal GitHub leak and a work mailbox share a habit. Have I Been Pwned is the public version of that news. A monitoring feed is the version you pay for. Neither one resets the tenant for you.

CISA’s note on phishing and social engineering is about the next login, not the last dump. The FTC small-business cybersecurity pages say the same thing in owner language: you still own the accounts.

Two facts set the afternoon:

1. Three addresses were work domain, not personal Gmail.
2. MFA was missing on a contractor mailbox that still received customer mail.

The dump named a founder, an ops mailbox, and a contractor who had rolled off in 2024 but whose guest still sat in Entra. The monitoring vendor’s email said “credentials found.” It did not say whether the hash was current, whether anyone had tried it, or whether the password had been reused on GitHub last year. That is normal. Combo lists do not come with a diagnosis.

We had no leftover sign-in report from a prior MSP. We treated the dump as live until the tenant said otherwise.

The founders’ first instinct was to ask whether they should email customers. That is a legal question if customer data moved. It is not the first IT question. The first IT question is whether a mailbox is owned, whether a session is still open, and whether a leftover guest can still open mail.

What this engagement was, and was not

Secure Techies sells cybersecurity and Microsoft 365 operations. A dark web credential alert is incident-lite plus a short harden. It is not a courtroom forensic package, and it is not a promise that monitoring will stop the next dump.

We wrote the non-goals down before we touched Global Admin.

Out of scope on purpose:

• Filing an IC3 complaint in the firm’s name
• Inventing a loss number
• A full penetration test
• Pretending monitoring replaces MFA
• A customer-notification letter we are not counsel to write

In scope:

• Reset and session revoke
• Mailbox and sign-in review
• MFA on leftover boxes
• Stale guests
• A written watch for the next feed hit

Microsoft documents Entra ID Protection as risk-based identity. We used the tenant we had. We did not sell a new SKU to look busy. If Protection had a risky-user flag on those three accounts, we would have treated it. It did not. The dump still justified a reset.

How we worked the alert

Hour one: reset

First: force password change on the three named accounts. Revoke sessions. Confirm MFA. Microsoft’s how MFA works is the reason a dump without a second factor is still a problem. Microsoft also documents how to revoke user access in an emergency: disable if needed, revoke sessions, understand that access tokens can live until they expire. We revoked. We did not disable the founder accounts, because they still had to ship. We did disable the leftover guest.

We did not argue about whether the hash was current. Reuse is cheaper to assume than to prove. A password that appeared in a third-party dump is a password you should not keep, even if last-change in Entra is more recent than the dump date.

The founder who got the monitoring email had already changed their own password in a panic, from a phone, without revoking sessions. That is a common first move and it is incomplete. A refresh token on a laptop they left at the office would still have been good. Revoke is the part people skip.

The rest of the day: the mailboxes

A leak and a takeover require different work. We assumed both until the logs said otherwise.

What we opened:

• Inbox rules and forwarding, including rules that delete after they forward
• Delegates and send-as
• Recent interactive and non-interactive sign-ins
• Whether Global Admin was a personal Microsoft account
• App passwords leftover from legacy IMAP
• Whether Security Defaults were on, or someone had turned them off because a script broke

The mailboxes did not show a takeover. No hidden forward. Sign-ins matched the people in the room, from expected cities, on expected devices. That was good news. It was not a reason to skip the rest.

We read interactive and non-interactive sign-ins for 30 days, not just today’s successes. A dump that is a week old can already have been tried. We looked for client apps nobody in the room recognized, overnight successes, and a fail-then-success pair from a new country. We did not find those.

Inbox rules: we opened Outlook on the web for each named box and looked for rules that forward and then delete, including rules a user cannot see in the desktop client if they never open the rules wizard. That is the quiet payday in a mailbox takeover. None were there. We wrote “none found” so the next person does not have to guess.

CIS Access Control Management still applies: leftover guests and password-only shared mail are access you forgot. The 2024 contractor guest had last signed in months ago. Access was still live. Offboarding had been a Slack goodbye.

We also looked at the shared ops mailbox. Two people knew the password. It had no MFA. Customer mail still landed there when a form on the marketing site used that address. That is not a process. That is a shared secret with a public inbox. We converted it to a real shared mailbox: Full Access for the two people, sign-in blocked on the mailbox itself, MFA on the people who open it. The marketing form kept the same address. The password on a sticky note did not.

The week: harden and write

We enrolled the contractor mailbox on Authenticator, then converted ops to a shared mailbox so nobody signed into it as a person. We cut the 2024 guest. We checked legacy auth and turned Basic Authentication off where it was leftover. We wrote the watch. We sat with the people who actually ship, for fifteen minutes, and walked the 11 p.m. path: who gets the next alert, what “reset” means, which number to call.

The watch is one page on purpose. A 40-page incident plan would have sat in a Drive folder nobody opens. The page names the monitoring product, the mailbox that receives alerts, the Global Admin backup, and the managed help desk number. It says reset first, then call. It does not say “investigate the dump vendor.”

What the tenant actually showed

The dump was a third-party combo list. Not proof of a Microsoft breach. Not proof the password still worked. Enough to reset. The monitoring vendor named a source we will not reprint. It was a public leak of an unrelated consumer site, plus work emails that had been used as usernames. That is the usual path: your domain in someone else’s breach.

The founder mailboxes were not owned. We still rotated, because “probably fine” is how leftover sessions survive an afternoon. Sign-in logs for the prior 30 days did not show a stranger. They showed the founder, from the office and from home, and one travel login they could name.

A contractor mailbox could still receive customer mail. It had no MFA. Two people knew the password. The contractor was gone. The mailbox was not. Form submissions still arrived. That is how a dump row becomes a customer conversation you did not plan.

A guest outlived the contract. Last sign-in was months old. Access was still live. The guest had been invited to a product-spec library “for two weeks.” The library was still shared. That is the same leftover pattern we keep finding in employee offboarding.

Global Admin was two people, both founders, both with Authenticator. That was better than a personal Microsoft account as admin, which we have seen elsewhere. We still wrote down who the break-glass account was. There was not one. We put that on the watch as a next item, not a same-day panic.

None of this required a new monitoring product. It required an afternoon that treated an alert as a gift.

What we would not do

We would not claim we stopped a hack in progress. The logs did not show one.

We would not invent “47 credentials remediated” when three work addresses were named.

We would not tell them to email every customer. No customer data had a demonstrated path out of the tenant. If counsel later wanted a notice, they would have facts: dump source, accounts reset, no mailbox takeover found. We are not their lawyer.

We would not skip the watch because everyone was tired.

We would not buy a second monitoring product because the first one had done its job.

Our dark web monitoring guide is the product background. This page is one alert. Password management is the reuse chapter. MFA is the second lock.

What the packet contained

1. Named accounts. Reset, MFA, last sign-in, session revoke time.
2. Mailbox notes. Rules, forwards, none found, still rotated.
3. Guest list. Cut vs live, with the 2024 contractor called out.
4. Tenant hygiene. Legacy auth, Security Defaults, who held Global Admin.
5. Watch page. Who gets the next alert, what reset means at 11 p.m., help desk number.

The packet is short enough to re-read when the next alert arrives. It is specific enough that a new engineer could pick it up without a tour. Screenshots of settings sat in an appendix. Adjectives stayed out of the watch. Offboarding now includes the guest, so the next contractor does not become the next dump row.

What we verified before we called it closed

An alert with no reset is a blog post.

We sat on the tenant for 30 days after the reset. The monitoring feed did not name new work addresses in that window. Sign-ins on the three accounts stayed boring. That is not a guarantee. It is a close-out note.

What they had that they did not have that morning:

• A clear answer: dump, not proven takeover, with the evidence
• MFA on the leftover mailboxes
• A guest that could not still open mail
• A watch for the next feed hit
• A help desk number that was not a founder’s cell

What they still did not have, and should not claim:

• A guarantee the next dump never names them
• A customer-notification package
• A substitute for unique passwords
• A break-glass account (that stayed on the next-item list)

Lessons we would repeat

Reset first. Debating hash age is how reuse wins.

Revoke sessions, not just the password. A panic change from a phone leaves tokens on the laptop at the office.

Assume takeover until the log says no. Rules and forwards are the quiet payday. Look for the rule that deletes after it forwards.

MFA on contractor mail. “They are not staff” is not a control. If the mailbox receives customer mail, it is staff for the purpose of MFA.

Cut guests when the contract ends. Slack goodbye is not offboarding.

Write the 11 p.m. path. The next alert will not wait for a board meeting. One page beats a binder.

Do not turn a dump into a customer letter by default. If data did not leave, do not perform a breach you cannot show.

Planning for a dump with your name on it

If monitoring just named a work address, reset, revoke, check MFA, then call us. If nothing has happened yet and you want the watch written first, bring Global Admin and whoever actually reads the alerts.

Do not paste the dump into Slack. Do not email the hashes around. Do not disable every account in a panic and lock the company out of its own tenant.

Secure Techies works from Canoga Park with technology firms and other Southern California offices. Schedule a consultation if you want the same kind of reset-and-watch this client used.

For a different project record, see SharePoint oversharing cleanup for a media agency.