Catch employee laptops infected with password-stealing malware

Every weekday at 7am, check my company email domain against Have I Been Pwned's stealer log data and turn each hit into a triaged device compromise response. Stealer log data is credentials captured by password-stealing malware on an employee's own machine at the moment they signed in, so a hit means an endpoint is very likely infected right now. Treat it as an active incident, not as historical breach trivia.

Start with Have I Been Pwned's Get Subscription Status operation and confirm the stealer log entitlement is present on the account (the IncludesStealerLogs field). Stealer log searches require the Pro subscription tier or higher, and the domain must already be verified and subscribed on the Have I Been Pwned account. If the entitlement is missing, stop the run and post one Slack message saying the subscription tier does not cover stealer log searches, rather than continuing and reporting a false all clear.

Then call Get Stealer Logs by Email Domain once for our verified domain. Make exactly one domain-level call per run and never loop per employee: the domain-based stealer log endpoints enforce their own independent and lower rate limits, separate from the subscription's requests-per-minute allowance. The response is a two-dimensional array mapping each email alias to the website domains their credentials were captured against, for example {"jane": ["netflix.com", "spotify.com"]}, meaning jane@ourdomain.com had credentials captured while authenticating to those sites. Note the key is the alias only, so recombine alias + "@" + our domain before looking anyone up. An HTTP 404 with an empty body means no results, which is a clean run and not a failure.

For every alias returned, confirm the person is still a real active employee before alerting. Use Okta's List Users with a SCIM filter expression such as status eq "ACTIVE" to pull the active roster, or Retrieve User to fetch an individual by login email, and capture each person's department and manager. This cross-reference is load bearing: the aliases returned routinely include former employees, shared mailboxes and aliases that no longer map to a person. Drop anyone who is not an active employee, and note shared or unmatched mailboxes separately in the summary instead of opening tickets for them.

Rank every remaining hit by what the credentials were captured against, not by how many sites appeared. Anything corporate is critical: our own domain, Okta, GitHub, AWS or a VPN. A critical hit means the attacker holds working corporate credentials and the employee's machine is almost certainly infected with malware, so it needs same-day handling. Captures against personal sites such as streaming, shopping or social accounts are lower priority and can be handled as routine password hygiene.

Before alerting, run a Jira Search Issues (JQL) query scoped to the security project to find tickets already raised for that person, so an alias reported on a previous morning does not open a duplicate ticket every single day. Match on the employee's email address in the summary or description. If an existing ticket already covers the same captured sites, skip that person. If new website domains have appeared since the last ticket, that indicates a fresh capture, so open a new ticket rather than staying silent.

For each newly affected employee, use Jira's Create Issue to open one ticket in the security project. One ticket per person, not per captured site. Make the person and the severity obvious in the summary. In the description include their full email address, their department and manager from Okta, the complete list of website domains their credentials were captured against, the severity you assigned and why, and a remediation checklist covering password rotation on every captured site plus their corporate account, revocation of all active sessions and refresh tokens in Okta so stolen session cookies stop working, and reimaging of the affected device. Set the ticket priority from the ranking.

Finish by sending exactly one Slack Bot message to the security channel. Summarize how many people are affected and name only the critical cases, with their department and the corporate systems involved. Do not name the lower-priority personal-site hits individually; a count is enough. Reference the tickets that were created. If the run comes back clean, post a short all-clear instead of staying silent or raising an error.