The First 48 Hours of a Phishing Incident — A 7-Step Response Playbook

The phone call usually starts: "We found a fake site impersonating us." From that moment, the quality of your response is decided in the next 48 hours. Compress the window and the typical brand-impersonation campaign produces a handful of credential theft cases. Stretch it past 72 hours and you end up explaining to your executive team why an active phishing site stayed live across an entire weekend.

What goes wrong, repeatedly, is process. Not technology. Most teams I've worked with already have the tools — they just don't have the order. Engineering writes a registrar abuse report at hour 3, communications drafts a customer email at hour 14, legal evaluates UDRP at hour 22, and meanwhile the phishing site keeps converting. Each function moves competently in isolation; the gap is the coordination layer.

This playbook is the version we run at OpenBait when one of our customers' brands gets hit. Seven steps, each with an owner, an output, and a deadline. The checklist at the bottom is meant to be printed and pinned to the incident channel.

Step 1 — Scope the incident (within hour 1)

Owner: SOC analyst or security lead Output: a one-page incident summary

The first hour is fact-finding only. No abuse reports yet, no customer-facing comms — those will be wrong if your facts are wrong. Lock down:

• Full URL of the phishing page, including any redirect chain (sites that redirect through 2–3 short URLs are common in 2026 — APWG's quarterly trend reports show roughly 60% of credential-collecting URLs sit behind at least one shortener)
• WHOIS / RDAP record — registration date, registrar, nameservers, contact (often redacted post-GDPR but the registrar field alone tells you which abuse desk to target)
• Brand assets being copied — logo, color, copy, layout, login form fields. Take a perceptual hash (pHash) against your real page so you have a numeric distance for evidence later
• Estimated victim count — check inbound CS tickets, social mentions, Google search for the fake URL string, your own referrer logs if the attacker accidentally proxied traffic
• Apparent objective — credential harvesting, fake checkout, fake parcel-delivery confirmation, bogus campaign signup. The objective shapes the customer warning copy

Tools you'll reach for: WHOIS / RDAP lookup, urlscan.io for a sandboxed render, an incognito browser session over a non-corporate network. Don't browse the phishing URL from your office IP — some kits log visitor IPs and an unexpected hit from a corporate netblock alerts the attacker that you've found them.

Teams running continuous monitoring (CT logs + NRD + dnstwist + branded search) skip most of Step 1 — the scoping data is already in the alert. Teams without monitoring need this playbook plus a separate workstream to put baseline detection in place; the typosquat detection guide covers how.

Step 2 — Notify internal stakeholders (within hour 2)

Owner: security lead or CSIRT manager Output: a single message to a single distribution list

The most common failure in 48-hour response is "we kept it inside security too long." Within two hours, sync the following six functions:

Anti-pattern to avoid: "I'm not sure if PR needs to know yet, I'll loop them in later." Wrong. The inclusion question itself is what you're asking PR to decide. Phrase it as "We're tracking an impersonation incident, looping you in for visibility — your input on whether we externalize is wanted." The 30 minutes you save by not pre-deciding for PR is the 30 minutes that determines whether your customer warning ships at hour 12 or hour 36.

Step 3 — Preserve evidence (within hour 4)

Owner: SOC or incident handler Output: a timestamped folder, incident-{date}-{brand}/, with the evidence package

You'll reference this in the registrar abuse report, in any UDRP filing, in customer-facing comms, and in the post-incident review. Capture before the page disappears (kits often go dark mid-incident if the attacker spots the takedown attempt):

1. Screenshots via headless browser, both desktop and mobile viewport
2. Full HTML source (curl -L -A "Mozilla/5.0 ..." {url} > page.html)
3. HTTP response headers (curl -I)
4. TLS certificate chain (openssl s_client -connect {host}:443 -servername {host})
5. WHOIS / RDAP output in JSON
6. Full DNS records (A, AAAA, MX, NS, TXT)
7. Redirect chain (curl -v and save the trace)
8. pHash / SSIM distance vs your legitimate page (numeric similarity score is the single most useful piece of evidence in registrar reports — it makes the case verifiable from a distance)

Store all of these in a versioned location with timestamps. The registrar abuse report attaches directly from this folder.

Step 4 — Warn customers (within hours 6–12)

Owner: PR + customer support + security, jointly Output: a notice on your site, an email to the customer base, and a social post — at least three channels

The deliberation window for "should we tell customers" is short. The legal default in most jurisdictions, and the right thing morally, is to disclose once impersonation is confirmed. Japan's Act on the Protection of Personal Information makes this explicit; GDPR Article 34 requires it for high-risk breaches; FTC guidance for US firms expects equivalent disclosure.

The notice covers:

• The fake domain name, presented as non-clickable text (strip https://, or use an image embed) so readers don't accidentally click and become victims of the very page you're warning them about
• Your real URL, prominently, so readers know what the canonical brand looks like
• What to do if they already entered credentials or payment info — password reset, card cancellation, your CS contact
• What you're doing about it ("We have notified the registrar, hosting provider, and major browser blocklists; takedown is in progress")
• Where to follow updates

Pair this with Step 6 in parallel, not after — the moment your customer-facing notice goes out, you want the browser blocklists to have already started showing warnings on the fake page. Start the blocklist submissions before you publish the notice.

Step 5 — File registrar and hosting abuse reports (hours 12–24)

Owner: security + legal, jointly Output: a sent abuse report to the registrar, plus a parallel one to the hosting provider, with ticket IDs from each

Use the evidence package from Step 3. The full template is in Writing registrar abuse reports that actually move; the abbreviated checklist:

1. Subject line: Phishing Abuse Report — {fake-domain} impersonating {your-brand} — leaving "Phishing" out of the subject is the single most common reason reports get routed to the wrong queue
2. Verifiable evidence attached (screenshot URLs, pHash distance, full evidence package)
3. Explicitly disambiguate from DMCA / UDRP — those are different abuse desks and a misclassified report sits there for days
4. State the brand-owner authorization (skip if you are the brand)
5. Send from a stable reporter address (continuity builds trust with the registrar's abuse team — this matters more than people expect)
6. Diary the 72-hour follow-up

In parallel, file with the hosting provider. If the site is on Cloudflare-fronted infrastructure, AWS S3, GitHub Pages, Netlify, or Vercel, the hosting provider will often respond faster than the registrar. Cloudflare publishes a brand-protection abuse intake; AWS uses the Trust & Safety form; GitHub has a documented takedown process. Don't wait for the registrar before going to hosting — the Interisle 2024 Phishing Landscape data shows registrar response times vary from 6 hours to 6+ days depending on the registrar; hosting providers often dwarf that variance the other direction.

Step 6 — Browser blocklist submission (hours 12–24, parallel with Step 5)

Owner: security Output: submission confirmations from Google Safe Browsing, Microsoft SmartScreen, and Cloudflare's 1.1.1.1 phishing list

This is where you protect customers fastest. Browser warnings hit users within hours of submission and the conversion-to-abandonment rate is above 95%. All three submissions in parallel:

• Google Safe Browsing: covers Chrome, Safari, Firefox, Android. Submission via safebrowsing.google.com/safebrowsing/report_phish/. Common turnaround 24 hours
• Microsoft SmartScreen: covers Edge, Outlook, Teams, Windows Defender. Submission at feedback.smartscreen.microsoft.com. Screenshot is mandatory — submissions without it sit in the queue
• Cloudflare 1.1.1.1 for Families: public abuse intake at cloudflare.com/report-abuse/phishing. Often the fastest of the three to actually update the feed

Per-channel walkthroughs (the gotchas that get reports rejected) live in the browser blocklist submission guide.

After submission, verify the reflection. chrome://safe-browsing-diagnostic?site={url} shows current Safe Browsing status; VirusTotal shows the multi-engine view. Record verification timestamps in your incident ticket — auditors and post-incident reviews will ask.

Step 7 — Stand up continuous monitoring (hours 24–48)

Owner: security + CISO Output: design doc for monitoring infrastructure plus a routing rule for the next alert

Don't close the incident before you've reduced the cost of the next one. Without continuous monitoring, you'll repeat this 48-hour playbook manually every time. The minimum monitoring stack:

1. Certificate Transparency log monitoring — daily query against crt.sh for brand-related cert issuance
2. Newly Registered Domains (NRD) feed — daily diff against the high-risk TLDs (.top, .shop, .xyz, .click, .live)
3. dnstwist-style enumeration — weekly scan of brand-name variants
4. Social-channel monitoring — keyword search across X, Instagram, TikTok, YouTube, LINE for fake-account posts and brand mention spikes

A mid-market team running this stack themselves spends roughly 0.5 FTE on it; outsourcing to a platform tends to come in at a fraction of that cost. We're transparent about where OpenBait fits in the takedown service comparison — there are valid scenarios where in-house, agency, and SaaS each win.

The 48-hour checklist (print this)

Hour 1:
  □ Confirm full fake URL + redirect chain
  □ Pull WHOIS / RDAP
  □ One-page incident summary written

Hour 2:
  □ Notify: engineering, PR, legal, CS, business unit, CISO

Hour 4:
  □ Screenshots (desktop + mobile)
  □ HTML source / HTTP headers / TLS chain
  □ DNS records / WHOIS / redirect chain
  □ pHash / SSIM vs legitimate page

Hours 6–12:
  □ Customer notice on your site
  □ Customer email sent
  □ Social channel post

Hours 12–24 (parallel):
  □ Registrar abuse report
  □ Hosting provider abuse report
  □ Google Safe Browsing submission
  □ Microsoft SmartScreen submission
  □ Cloudflare 1.1.1.1 submission

Hours 24–48:
  □ Verify blocklist reflections
  □ Customer follow-up update
  □ Continuous-monitoring decision
  □ Post-incident review scheduled

What OpenBait automates inside this playbook

We don't pretend the platform replaces incident judgment. It compresses the steps that are deterministic — and steps 2 and 4 stay human:

• Step 1 (scoping): continuous CT + NRD + dnstwist + branded-search monitoring means the alert lands pre-scoped
• Step 3 (evidence): headless-browser screenshot, HTML, pHash, WHOIS auto-captured per detection
• Step 5 (registrar abuse): templates auto-rendered, fixed reporter address, sent-state tracked across the queue
• Step 6 (blocklist): parallel submission to all three browser channels with verification polling
• Step 7 (monitoring): this is the platform's actual product

What it doesn't automate, on purpose: Step 2 (which roles you involve and how is org-specific), Step 4 (tone, language, and legal review of customer notices is your judgment), and the legal escalation in Step 5 (UDRP, court orders) which a lawyer needs to size case by case.

The single biggest lever in 48-hour response is shrinking time-to-detection from hour 1 to hour 0. With monitoring in place, the playbook starts at Step 0 — a notification that lands pre-scoped, with evidence already captured. You can evaluate that on your own domain on the free tier before committing.

Related reading

• Building an anti-phishing defense in 2026
• Picking a takedown service: in-house, agency, or SaaS
• Writing registrar abuse reports that actually move
• Browser blocklist submission, line by line
• Typosquat detection that doesn't drown in false positives
• Why phishing concentrates at specific registrars in 2026

Sources

• APWG Phishing Activity Trends Reports
• Interisle Phishing Landscape 2024
• GDPR Article 34 — Communication of personal data breach
• FTC business guidance on data breach response
• Japan APPI guidance