Weekly dark web breach check for staff and customer emails

Every Monday at 7am on a cron trigger, sweep our staff and customer email list against known dark web breach dumps so we find out about compromised credentials before an attacker uses them.

Start by reading the email addresses from our Google Sheet with Get Values. The addresses live in a single column on a dedicated tab, so read that range and treat each non-empty cell as one address to check. Trim whitespace, skip blank cells, and de-duplicate the list so a repeated address does not burn an extra lookup.

For each address, call IPQualityScore Dark Web Leak Lookup to check whether it appears in public data breaches or private leaked-credential dumps. Two details matter here. First, the Dark Web Leak endpoint puts the API key in an unusual path position, after the type segment, as /leaked/{type}/{apiKey}/{data}, unlike other IPQualityScore endpoints which use /<product>/{apiKey}/<value>. Second, IPQualityScore returns HTTP 200 even when a call fails, so branch on the success field in the response body rather than the status code, and record a lookup error for that address instead of silently treating it as clean.

Write the results back into the sheet with Append Values so each run leaves a dated audit row per address: the run date, the email address, whether a leak was found, and which breach source it came from. This append-only history is what makes each sweep auditable, and it is also the input for next week's comparison.

Before posting anything, diff this run against the previous run's rows in the same tab to work out which exposures are new. An address counts as newly exposed when this run found a leak for it and the most recent earlier audit row for that address did not, or when the address has no earlier row at all. Exposures that were already reported in a previous week stay out of the callout.

Finish with a single Slack Send a Message to our security channel covering the count of addresses checked, the count newly exposed, and the specific addresses that are newly compromised since last week, each with the breach source it came from. Only newly appearing leaks should be called out by name so the alert stays actionable instead of repeating the same known exposures every week. If nothing new appeared, still post the summary with a count of zero so we know the sweep actually ran.

Keep the address list bounded. Each lookup consumes IPQualityScore account credits, so the size of the range read from the sheet drives the cost of every weekly run.