What actually happens during a phishing site takedown

bs-single-container

Ask how a phishing site gets removed and you'll usually be handed a list of destinations: the registrar's abuse form, the hosting provider's abuse mailbox, a browser blocklist submission page. The list is accurate. It's also the least interesting part of the work.

What decides whether a fake login page stops harvesting credentials this afternoon or keeps going for three more days is everything around those forms: who controls the asset, whether the evidence survives review by someone with no context, and who's still watching after the first confirmation arrives.

A takedown isn't an action you perform on a phishing site. It's a series of requests to intermediaries who owe you nothing in particular, each holding one narrow lever. Understanding which lever sits with which party is the difference between a queue that closes threats and a queue that accumulates ticket numbers.

The clock starts before anyone files a report

By the time a phishing page is reported, it has usually been working for a while. A 2020 USENIX Security study led by Arizona State University researchers, covering 4.8 million victim visits over one year, found that detection by anti-phishing entities came nearly 9 hours after the first victim visit on average, and that 62.73% of victims had already visited the page before it was detected. The average attack ran about 21 hours between its first and last victim visit.

That's the window a takedown is competing with. Volume makes it worse: the Anti-Phishing Working Group recorded 3.8 million phishing attacks across 2025, up slightly from 3.76 million the year before, and 971,181 in the first quarter of 2026. Every one of those stays live until somebody routes a request.

One more number shapes what the registrar can do for you. Interisle's Phishing Landscape 2025 study found that 77% of phishing domains were registered specifically to commit the crime, against 23% that were legitimate domains someone had compromised. A disposable domain can be suspended outright. A compromised one belongs to an innocent business, and the remedy has to be narrower.

Verification and evidence come first

The signal arrives before anyone has decided what to do with it: a customer complaint, a monitoring alert, a forwarded email that just felt wrong. Those inputs carry very different levels of confidence, which is why the first real task is verification rather than enforcement. A report filed against a legitimate site spends credibility the same team will need on a real case next week.

Verification and evidence collection happen in the same pass. The page gets captured as it renders, with the impersonated brand, the credential form, and the address bar in one frame, because the reviewer who sees the case later can't recreate what you saw. The domain is resolved, and a registration lookup such as ICANN Lookup establishes which registrar sponsors it and where its abuse contact lives.

Then comes the scoping call most guides skip: does the fraudulent content have a domain of its own, or does it sit on somebody else's platform? Interisle found that 13% of phishing attacks used resources at subdomain providers, with 89% of those concentrated on just 10 providers. A page on free hosting or a site builder has no separate registration to report, so the report goes straight to the platform. Get that wrong at intake and you spend a full cycle waiting on a party that was never able to help.

Who controls which lever

Once the asset is scoped, the report has to reach parties with real authority over it, and those are usually two different organizations with two different remedies. A registrar controls the domain name and can act on the registration, while the hosting provider controls the server and can remove or suspend the content. Both tracks run in parallel, not in sequence.

Registrars have a contractual obligation here, and it got sharper in 2024. Since April 5, 2024, ICANN's compliance advisory on the amended Registrar Accreditation Agreement defines DNS abuse as malware, botnets, phishing, pharming, and spam used to deliver any of those. When a registrar has actionable evidence that a domain is being used for DNS abuse, it must promptly take mitigation action reasonably necessary to stop or disrupt that use. Registrars must also confirm receipt of an abuse report with enough detail that the reporter can prove it was submitted.

Two words in that obligation do most of the work: "actionable evidence." ICANN's standard is that the information readily available to the registrar must be enough to make a reasonable determination on its own. That's the bar your report has to clear, and it's why the evidence package matters more than the urgency of the language around it.

Finding the right intake point is unglamorous and often the slowest manual step in the chain. RFC 2142 reserves the abuse@ mailbox for exactly this purpose, registration data usually carries an abuse contact, and most providers run their own web form. A misrouted report doesn't fail loudly. It sits in a queue somewhere, unanswered, while the phishing kit, the packaged fake site the attacker deployed, keeps collecting your customers' logins.

What happens inside the abuse desk

From the outside, submission feels like the end of the work. From the inside, it's the start of a triage problem. Your report lands in a queue next to spam complaints, copyright disputes, and automated noise, handled by staff who have no relationship with your brand and no obligation to accept your characterization of the page.

Their job is to match your evidence against their policy and their confidence threshold, so the report is read less as an accusation and more as a case file that either stands up on its own or doesn't. A reviewer needs the exact URL, a rendered capture showing impersonation and credential collection, a resolution trail connecting that URL to infrastructure the provider controls, and enough context to act without opening a conversation. Anything missing becomes a clarification request, and every round trip resets the case while the page stays live.

The remedy also depends on which lever the recipient holds. A host can pull the content while the domain keeps resolving. A registrar can act on the registration while the files sit untouched on a server, ready to serve again the moment DNS points somewhere new. Platform operators hosting subdomain scams hold both levers in one decision, which is often why those cases close faster than a domain-plus-host pairing.

Blocklists protect victims but remove nothing

Running alongside the provider track is a mitigation layer that removes nothing at all, and treating it as a substitute for enforcement is a common category error. Reporting a URL to Google Safe Browsing aims at the victim's browser rather than the attacker's server. A listing produces a warning screen in Chrome and other browsers that use the service, which Google says helps protect more than 5 billion devices every day.

That warning suppresses a meaningful share of traffic during the hours when the site is live and nobody has answered your report, which is real protection. What it doesn't do is end the campaign. The content is still hosted, the domain still resolves, and links delivered through channels that never consult a browser blocklist keep working.

The page is one piece of the campaign

Almost no phishing page generates its own traffic. It sits inside an operation that also includes whatever is driving victims toward it: fake accounts on social platforms, promoted posts, paid search and display ads, and the messages carrying the link. All of that lives outside the registrar and hosting relationship, and all of it survives the removal of the page it points to.

In practice, enforcement runs across several counterparties at once. Each social platform and each ad network has its own intake process, its own evidentiary expectations, and its own review timeline. A team that closes the hosting case and leaves the ad account running has removed a destination while leaving the acquisition engine intact. The operator repoints the same creative at a new URL and resumes against the same audience.

Why a confirmed takedown can still leave people exposed

The most persistent failure in this work is an accepted report that never produced the outcome recorded against it. Some programs count a case as closed when the abuse report is submitted, others when the host confirms removal, and under the first definition a dashboard can show a clean closed case while the credential form is still accepting input from the people you were trying to protect.

Cloaking makes independent checking harder than it sounds. APWG's Q1 2026 report notes that phishers still use geo/IP blocking and user-agent blocking, and that a growing number of sites only show fraudulent content when the referrer is a certain site or kind of site. A check from a data center address with no referrer and a desktop profile can get a harmless page or a plain error while the phishing flow renders normally for mobile traffic arriving from the campaign's own links. One probe from one vantage point isn't evidence of anything.

So put three questions to whoever closes your cases, Bolster AI included: from how many places the URL was checked before it was called offline, whether it was checked from a phone with the referrer the campaign expects, and when it gets checked again after closure. A confirmation without verification isn't a resolution. It's a hypothesis nobody has tested.

Rebuilds are cheap, and correlation is the answer

Successful enforcement against one URL is rarely the end of the engagement. The operator keeps the kit, the target list, the distribution accounts, and a working relationship with whichever providers tolerate the activity. A fresh domain or subdomain takes minutes, while the defending team starts intake, verification, and routing again from zero, so case by case the attacker's cost per rebuild stays far below the defender's cost per takedown.

What changes that arithmetic is correlation rather than speed on individual cases. Pivoting from the reported URL to shared hosting, registration patterns, kit artifacts, certificate data, and the accounts feeding traffic reveals the cluster behind it, and enforcing across the cluster at once makes the rebuild expensive enough that the operator has a reason to move on. Handled one alert at a time, the same campaign presents as a run of unrelated cases that each close successfully while the operation continues. That's the whole argument for treating lookalike domain registrations, ads, and accounts as parts of one campaign rather than separate tickets.

Where automation changes the math

Manual enforcement works right up to the point where volume exceeds the hours an analyst can spend locating abuse contacts and filling in forms. Every step above recurs per URL, and a single campaign spraying subdomains across a permissive host can absorb a full day of analyst time and still leave live pages behind.

Automation changes two things that matter operationally. The first is consistency, because an automated submission carries the same complete evidence package every time, which removes the clarification round trips that quietly consume the hours when a phishing page is most productive. The second is reach, because hosts, registrars, and blocklists can all be handled by the same workflow instead of by a person working down a list. Bolster AI's automated takedown flow is built on that pattern: API relationships with registrars and hosting providers, an evidence package attached to every request, and automatic submission to global blocklists, with automation carrying the volume and Bolster AI analysts handling the cases that need judgment.

When a case leaves the abuse desk

Some cases stop responding to the provider track entirely, and the pattern is recognizable before anyone escalates. The registrar declines to act, the host doesn't answer, the operator sits in a jurisdiction where abuse policy is nominal, and the same infrastructure absorbs repeated, correctly routed reports without visible effect. At that point, additional submissions through the same channels are documentation, not enforcement.

Legal and law enforcement channels reach things abuse desks can't: the identity behind a registration, the payment and cash-out infrastructure, and the operator's activity across other victim brands. What they don't offer is speed. Criminal referral and civil process run in weeks and months while the mitigation clock runs in hours, so the two tracks belong in parallel, with blocklist and provider requests suppressing live exposure while the slower track builds toward attribution.

What a takedown program should measure

The number of reports filed rises whenever attacker volume rises and says nothing about whether your customers were protected. Three questions do, whoever is running the program:

  1. How long from detection to confirmed offline, and who confirmed it?
  2. How many closures were checked from more than one vantage point before they were called closed?
  3. How often does infrastructure you took down reappear under a new address, and how quickly is it caught when it does?

A program measured on verified resolution and rebuild cost eventually makes your brand a less attractive target. A program measured on submissions gets better at counting. For the step-by-step version of the process above, our phishing site takedown guide walks through it in order.

Bolster AI detects external threats including phishing sites, lookalike domains, fraudulent social accounts, fake mobile apps, fraudulent ads, and marketplace abuse, connects related infrastructure into a single campaign, and removes them. Detection and takedown run as one workflow rather than as two separate promises, with automation carrying the volume and Bolster AI analysts handling the cases that need judgment.

If you'd rather see the whole chain run on a live platform than read about it, book a demo and bring the last case your team couldn't get confirmed offline.

TL;DR: Here's how phishing takedowns actually work: a sequence of requests to intermediaries who each control one lever. The registrar controls the domain, the hosting provider controls the content, and browser blocklists control what victims see. Speed comes from scoping the target correctly, sending evidence a stranger can act on without asking questions, and verifying removal from more than one vantage point. Detection typically lags the first victim by hours, so the clock is already running before anyone files a report.