---
name: dark-web-exposure-check
description: >
  Check whether a company domain, executive's email, or brand name has exposure in breach
  datasets or dark-web/BRI sources, as a periodic hygiene check rather than an incident response.
  Use this skill whenever a user asks for a "dark web check", "exposure scan", "breach check for
  our domain/execs", "have we been mentioned anywhere we shouldn't be", or wants a recurring/
  periodic review of company or executive exposure. Also trigger when a user asks specifically
  about Flashpoint, BRI, or dark web mentions of a company asset. Do not use this for a
  single-account "is this account compromised right now" investigation tied to active suspicious
  activity — use the identity compromise check skill for that; this one is for proactive,
  periodic exposure review.
---

# Dark Web Exposure Check Skill

A periodic hygiene scan — not an incident response — for whether a company domain, executive
email, or brand shows up somewhere it shouldn't: breach dumps, dark-web forums, or BRI sources.

---

## Workflow Overview

```
1. Confirm scope  →  2. Check breach datasets  →  3. Check dark-web/BRI sources
   →  4. Check brand/domain abuse  →  5. Render exposure report
```

---

## Step 1 — Confirm Scope

Ask (if not already given) which of the following are in scope, since scope changes both the
sources queried and how the report should be framed:
- Specific executive email(s) or a distribution list
- The company's primary domain(s)
- Brand/product names (for impersonation and typosquatting checks)

This is a periodic check, not an urgent one — take the time to confirm scope rather than guessing.

---

## Step 2 — Check Breach Datasets

| Source | ID | What it adds |
|---|---|---|
| Have I Been Pwned | `haveibeenpwnd_3_2_0_node_18_e72f988cf7_1721826241` | Which breaches each email appeared in, and when |
| EmailRep | `emailrep` | Reputation and known-exposure flags |

---

## Step 3 — Check Dark-Web / BRI Sources

| Source | ID | What it adds |
|---|---|---|
| Flashpoint | `flashpoint_3_4_0_node_18_f7fea5e788_1744211229` | Business Risk Intelligence — dark web/forum mentions, credential dumps, chatter |
| PhishStats | `phishstats_3_1_4_node_18_440ea84824_1740732419` | Recent phishing submissions referencing the domain/brand |

---

## Step 4 — Check Brand/Domain Abuse

| Source | ID | What it adds |
|---|---|---|
| DomainTools IRIS | `domaintools_iris_3_1_9_node_18_ba17ff4ea1_1697658218` | Lookalike/typosquat domain registrations |
| ECrimeX-style / APIVoid | `apivoid_3_1_3_node_18_5ed4fc6eac_1765902753366` | Blocklist presence for lookalike domains found |
| Cisco Umbrella | `cisco_umbrella_3_2_0_node_18_b764bf26c7_1697657935` | Categorization of any suspicious lookalike domains |
| LinkedIn | `linkedin` | Public impersonation profiles using the brand/exec name, if relevant to scope |

---

## Step 5 — Render Exposure Report

Render via `visualize:show_widget`:

1. **Header** — scope covered, check date (this is a point-in-time snapshot, say so), overall
   exposure level (Low/Moderate/Elevated based on volume and recency of hits)
2. **Breach exposure table** — email | breach name | date | data types exposed
3. **Dark web / BRI mentions** — source | date | summary (paraphrased, not reproduced verbatim —
   Flashpoint/forum content should be summarized, not quoted at length) | relevance
4. **Lookalike domains** — domain | registration date | categorization/blocklist status | risk read
5. **Recommended actions** — password rotation for exposed accounts, domain takedown requests for
   confirmed malicious lookalikes, monitoring for others — time-horizon badged
6. **Footer** — sources queried, and a note that this is a point-in-time check, recommend
   re-running periodically (e.g., quarterly) rather than treating this as continuous monitoring

### Visual Design Rules (all reports)

Follow the claude.ai design system exactly:

- **No hardcoded hex colors.** Use only CSS variables: `--color-background-primary/secondary/tertiary`,
  `--color-text-primary/secondary/tertiary`, `--color-border-tertiary/secondary`,
  `--color-background-danger/warning/info/success`, `--color-text-danger/warning/info/success`.
- **Dark mode mandatory** — every element must be readable on a near-black background.
- Font sizes: section labels 11–12px uppercase tracking, body 13–14px, metric numbers 20–24px.
  Font weights: 400 body, 500 headings/labels only. Never 600 or 700.
- Cards: `background: var(--color-background-primary); border: 0.5px solid var(--color-border-tertiary);
  border-radius: 12px; padding: 1rem 1.25rem`.
- Badges: `display: inline-block; padding: 4px 12px; border-radius: 6px; font-size: 12px; font-weight: 500`
  using semantic CSS vars for bg + text.
- Section separators: `border-top: 0.5px solid var(--color-border-tertiary)`.
- Tabler outline icons only (`<i class="ti ti-NAME" aria-hidden="true">`). Never filled variants.
- Sentence case everywhere. No ALL CAPS section titles.
- No gradients, drop shadows, blur, or glow effects.
- Score/meter bars: plain `<div>` with width `${value}%`, no canvas or chart libraries.
- Always render via `visualize:show_widget` (HTML mode). Call `visualize:read_me` with
  `modules: ["mockup"]` first if not already done this session. One line of prose before the
  widget call, nothing after except an offer to drill into any section.

---

## Handling Edge Cases

**No Flashpoint/BRI connector available**: Say so explicitly and scope the report to breach data
and domain abuse only — don't imply dark-web coverage that wasn't actually performed.

**Large executive list (>10 people)**: Summarize in table form with counts, not full detail cards
per person; offer to expand any individual on request.

**Old breach hits only (>3 years, likely already rotated)**: Note them for completeness but don't
inflate the overall exposure level on stale data alone — weight recency in the Low/Moderate/
Elevated read.

**Lookalike domain found but not yet weaponized (parked, no MX/content)**: Flag as "monitor" not
"urgent" — registration alone isn't an active attack, though it's worth tracking.

**User wants this run on a schedule**: This skill itself doesn't have scheduling; suggest the
user set up a recurring reminder or ask their Claude environment's scheduling feature (if
available) to re-invoke it periodically.