# Catch employee laptops infected with password-stealing malware

> Every weekday morning we check your company domain for logins captured by malware, confirm who still works here, and open a fix-it ticket for each person.

- Workflow type: agent
- Services: Have I Been Pwned, Okta, Jira, Slack Bot
- Categories: Engineering, Operations
- Published: 2026-08-14

## What it does

- Checks your company email domain every weekday for staff logins captured by password-stealing malware, which signals a live infection rather than an old leak.
- Confirms each person is still an active employee and pulls their department and manager, so you are not chasing former staff or shared mailboxes.
- Ranks every hit by what was stolen: work systems like your own sign-in page, GitHub, your cloud account or a VPN are urgent, while personal accounts like streaming are lower priority.
- Opens one ticket per affected person with the sites involved and a remediation checklist, skips anyone already reported, and posts a single summary to your security channel.

## What you'll need

- A Have I Been Pwned account on the Pro plan or higher, which is the level that includes malware-stolen credential data.
- Your company email domain added and verified on that Have I Been Pwned account.
- An Okta login, so we can check who is still an active employee and find their department and manager.
- A Jira project where the remediation tickets should be created.
- A Slack workspace and the channel your security team watches.

## Prompt

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.

## How to customize

- Change the timing: run it daily including weekends, twice a day, or only on Monday mornings.
- Adjust what counts as urgent by naming the work tools you care most about, such as your cloud provider, code host or password manager.
- Change where the work lands: a different Jira project, a different Slack channel, or an extra direct message to the affected person's manager.

## FAQ

### How is this different from a normal data breach alert?

A normal breach alert tells you some third-party website was hacked, often years ago, and your employee's email was in the stolen list. This looks at something more urgent: credentials captured by malware running on someone's computer at the moment they typed them in. It usually means that laptop is infected right now, which is why every hit becomes a tracked ticket instead of a line in a weekly report.

### Do I need a paid Have I Been Pwned plan for this?

Yes. Malware-stolen credential data is only available on the Pro plan or higher, and your company domain has to be verified on the account first. If your plan does not cover it, the workflow says so plainly rather than quietly reporting that everything is fine.

### Will it open the same ticket for the same person every morning?

No. Before alerting, it searches your Jira project for tickets already raised for that person, so a known case does not create a duplicate every day. A new ticket is only opened when someone new is affected, or when new sites appear for an existing case, which suggests a fresh capture.

### What happens on a day when nothing is found?

You get a short all-clear message in your security channel. No tickets are created, and a clean result is never treated as an error.

### Will it raise alerts about people who have already left?

No. Every address is checked against Okta first, so former employees, shared mailboxes and aliases that no longer map to a real person are filtered out before any ticket or alert is raised. That check is the reason the alerts stay trustworthy.

Use this prompt in General Input: https://www.generalinput.com/prompts/catch-employee-laptops-infected-with-password-stealing-malware