XposedOrNot

A Free Breach-Monitoring Toolkit for Sysadmins

July 31, 2026

A Free Breach-Monitoring Toolkit for Sysadmins (SysAdmin Day Edition)

Happy SysAdmin Day.

If that greeting applies to you, this post is my thank-you. Not a discount code, not a webinar invite. A working setup.

I come from IT myself. Same work, same interruptions, a couple of decades earlier. And if those years left me with one strong opinion about tooling, it is this: the tools that actually got used were the ones you could try between two tickets, with no budget approval and no vendor call. You tried it, it worked, it stayed.

So that is the bar for everything below. Five pieces, all free, all scriptable, and honest about their limits. Together they answer one question that is surprisingly hard to answer otherwise: when credentials from my org show up in a data breach, will I find out, or will I be the last to know?

Fair warning before we start: yes, XposedOrNot is my project. It is open source and the pieces below are free, so I feel okay recommending my own tool on the one day of the year that is officially yours. Audit everything I say. That is piece five.

Piece 1: The keyless API, for your scripts

Let us start with the piece you can try in the next ten seconds, from the terminal you already have open:

curl https://api.xposedornot.com/v1/check-email/you@example.com

No API key. No signup. No onboarding email sequence. You get JSON back: a list of every known breach that email address appears in, straight from the breach index. Try it with your own address first. Everyone does, and it is usually an educational moment. (No terminal handy? The same check runs at xposedornot.com )

Why does this matter for you specifically, and not just for your users? Because your admin and service accounts are the ones that can reset everyone else’s passwords. An old admin email sitting in a stealer log or a breach dump, combined with a reused password somewhere, is exactly how “how did they get in” stories start. Those few special accounts deserve standing surveillance, not an annual check when someone remembers.

Here is the nightly version. One text file with your admin and service addresses, one script, one cron entry:

				
					#!/bin/bash
  # breach-watch.sh: nightly delta check of admin/service accounts
  # accounts.txt: one email per line, lives next to this script
  cd "$(dirname "$0")"
  while read -r addr; do
    body=$(curl -s "https://api.xposedornot.com/v1/check-email/${addr}")
    hits=$(printf '%s' "$body" | jq -r '.breaches[0] | length' 2>/dev/null ||
  echo 0)
    known=$(cat ".known-${addr}" 2>/dev/null || echo 0)
    if [ "${hits:-0}" -gt "${known}" ]; then
      echo "${addr}: breach count now ${hits} (was ${known})" \
        | mail -s "Breach alert: ${addr}" you@example.com
      echo "${hits}" > ".known-${addr}"
    fi
    sleep 3   # stay inside the per-IP rate limit
  done < accounts.txt

What it does: checks each address, compares the breach count against the last count it saw, and emails you only when the number goes up. Silence means nothing new, which is the correct amount of email. (It assumes a working mail command; swap in curl to your webhook of choice if your boxes do not send email.)

Three things worth knowing, because I tested all of this today before publishing:

The first run will alert on every address that has existing exposure. That is your baseline, not an emergency. Read the results once, and from then on you only hear about changes.
Unknown addresses return a polite “not found” body, and the script treats that as zero. No crashes on your cleanest accounts.
The rate limits are per-IP and documented on the API docs. They are generous enough for a nightly loop over a handful of accounts and tight enough that you cannot audit the whole company through this endpoint. That is deliberate. The org-wide view is piece three, and it requires proving you own the domain first. While testing this post I ran the loop twice back to back and rate-limited myself, hence the sleep. Consider that my quality assurance contribution.

One more endpoint worth knowing about. Say the alert fires someday. Your real question at that moment is not “did it happen”. It is “how bad”.

curl https://api.xposedornot.com/v1/breach-analytics?email=you@example.com

This one answers that: what types of data got exposed, a rough risk score, how the exposure spreads across years. Enough to decide between “rotate one password” and “clear my afternoon”.

Piece 2: The RSS feed, for your morning coffee

Every new breach we index, as it lands, at a plain old RSS URL:

https://api.xposedornot.com/v1/rss

Point your feed reader at it and you get breach awareness the way sysadmins have always preferred information: skimmable, on your schedule, with no dashboard login and no marketing newsletter wrapped around it.

The quiet benefit is vendor awareness. The feed is how you notice “wait, we use them” three coffees before the first user forwards you a news article and asks if the company is affected. When a name in the feed rings a bell, you go check your domain dashboard (piece three) instead of wondering. (Prefer your breach data visual? The whole catalog is also browsable as charts and timelines.)

Piece 3: Domain verification, for the org-wide view

This is the highest-leverage ten minutes in this post.

Everything above works one address at a time. But you do not actually care about addresses one at a time. You care about a different question: across everything@yourcompany.com, what is exposed, and is anything new? To answer that, you first prove you control the domain, and then the whole picture unlocks.

The proof works like a TLS certificate challenge, and you get to pick whichever method annoys you least:

a DNS TXT record,
a confirmation to a standard admin email on the domain, or
an HTML file drop on the website.

You have all three of these powers. Ten minutes, once, and it keeps working for you long after you have forgotten about it. Want every click spelled out? There are walkthroughs for both the DNS method and the HTML file method.

What you get after verification:

every known breach touching any address on your domain, in one dashboard,
per-address detail, so you can see whether it is one exposed mailbox or two hundred,
trends over time, which is what makes the picture make sense, and
alerts when new exposure lands, so the dashboard works for you instead of you working the dashboard.

The detail I am proudest of, because it comes straight from operations experience: alerts have an acknowledgment step. When something fires, someone can mark it seen. Which means “did anyone actually look at this” has an answer you can point to, at 9am and in the post-incident review. If you have ever watched an alert die unread in a shared mailbox, you know exactly which failure this exists to prevent.

Piece 4: The Microsoft Sentinel connector, if you run a SIEM

Nobody wants pane of glass number seven. So if your org already runs Microsoft Sentinel, skip our dashboard entirely and use the official connector instead (this one does want an API key; the free community key covers it). Breach exposure lands in the SIEM you already watch, and the plumbing you spent years building just picks it up. Alert rules, escalations, runbooks. Nothing new to learn, nothing new to forget to check.

Bonus: the next time an auditor asks how you monitor for credential exposure, “it is in the SIEM with an alert rule” ends that conversation fast.

No license fee on our side. If you run a different stack, the keyless API from piece one is the universal adapter.

Piece 5: The source code, because you should not have to trust me

Everything above is open source and MIT licensed at github.com/XposedOrNot: the API, the website, the Sentinel connector, even official SDKs in eight languages (Python, JavaScript, Go, Ruby, PHP, Rust, .NET, Java) for the day curl stops being enough.

Read the code. Audit the endpoints your data touches. Fork it. I mean this as more than a slogan: a monitoring tool you cannot inspect is just another vendor promise, and sysadmins have collected enough of those to know better. The trust model here is “verify”, not “trust us”.

The honest limits

A toolkit post from a founder should tell you what the toolkit cannot do, so here it is.

This monitors known, indexed breaches. It cannot see a breach that has not surfaced yet, and breaches surface late. In our catalog the median gap between a breach happening and becoming public is measured in years. That lag is exactly why standing monitoring beats the one-off check: you want to hear about the 2022 breach the day it surfaces in 2026, not never.
The free tier is permanent for monitoring yourself and your own domains. Alerts reach you by email and on the dashboard. Paid tiers exist for a different job, monitoring domains that are not yours, for clients. Everything in this post stays free.

Fifteen minutes, one coffee

The whole setup, in the order I would do it:

Run the one-line curl on your own email. (10 seconds, educational)
Set up breach-watch.sh over your admin and service accounts. (5 minutes)
Point your feed reader at the RSS feed. (1 minute)
Verify your domain and turn on alerts with acknowledgment. (10 minutes, once)

That is standing breach visibility for your whole org, assembled inside one coffee break, on the one day of the year you are officially allowed to spend it on yourself.

Happy SysAdmin Day. Genuinely: thank you for keeping everything running.

And if a free, open-source, scriptable breach monitor earns it, drop us a star on GitHub (https://github.com/XposedOrNot). It helps other infrastructure people find the project, and honestly, it makes our day.