Your vendor says the site is down. Here are five reasons it might not be, and how to check for yourself.
Phishing takedown reporting has a verification problem. Vendors report sites as removed. Security teams discover, sometimes weeks later, that the sites are still serving credential-harvesting pages to their customers. Surprisingly, it is not uncommon to hear stories of teams taking down sites a vendor had marked as resolved, or of dashboards reporting a site as offline while the page still loads normally when checked from a different network or device. When one “confirmed” takedown turns out to be still live, every other entry in the dashboard becomes suspect.
The gap between what a takedown report says and what is actually happening has specific, identifiable causes. Understanding them is the first step toward knowing whether your takedowns are holding.
Five ways a confirmed takedown is still live
The gap between a vendor reporting a takedown as complete and the site actually being gone has specific, identifiable causes.
Suspension is not removal. When a hosting provider suspends a domain, the site stops resolving for most visitors. But the domain registration, hosting account, and phishing kit files often remain intact. Suspended sites can be reactivated by transferring the domain or waiting for the suspension to lapse. Some registrars allow deleted domains to be re-registered rather than permanently retired, feeding the same infrastructure back into circulation.
Cloaking hides the phish from the scanner. This is not a niche technique. Research analyzing 2,933 phishing kits found that 96.52% contained cloaking mechanisms, with 82% implementing user-agent verification and 69% implementing IP-based filtering. The APWG’s Q1 2026 report documented an increase in phishing sites using geo-blocking, referrer-based filtering, and device fingerprinting to show different content to different visitors. A site that displays a clean page when checked from a scanning environment may still serve a fully functional credential-harvesting page to a consumer on a mobile device in a different state. Commercial cloaking-as-a-service platforms now use machine learning to filter across 900+ visitor parameters, making evasion a commodity rather than a custom capability.
The page is gone but the kit is not. A hosting provider may remove the visible phishing page while leaving the underlying kit, redirect scripts, or data-collection endpoints in place. The URL returns a 404, which registers as a successful takedown. But the infrastructure remains functional. Academic research has documented that 5-15% of phishing pages display fake “404 Not Found” or “Page Not Exist” messages in their HTML while the actual HTTP status code is 200, meaning the page is active but camouflaged. Partial removal is particularly common when phishing kits are hosted in subdirectories of compromised legitimate sites, where the provider removes the reported page but does not audit the rest of the directory.
The site re-emerges on new infrastructure. Phishing operations built on phishing-as-a-service platforms are designed for rapid redeployment. When one instance is taken down, the kit redeploys on a different domain or host. The CrowdStrike analysis of the Tycoon2FA takedown in March 2026 documented exactly this: law enforcement disrupted the infrastructure, daily volumes dropped to 25% of pre-disruption levels, and then activity rebounded to previous levels as operators redeployed. A takedown without recurrence monitoring counts the initial removal and misses the redeployment.
“Ticket submitted” is counted as “done.” Some providers count a takedown as complete when the abuse report is submitted to the hosting provider, not when the site is confirmed offline. The gap between submission and actual removal can be days or weeks. During that period, the dashboard shows the threat as resolved while the site continues to operate. As we examined in our analysis of how takedown speed claims are built, the definition behind the number determines whether it means anything.
How to verify a takedown yourself
Five checks will tell you whether a reported takedown reflects reality.
Check from the victim’s perspective. Verify the site from a consumer device on a residential or cellular network, not from your corporate IP or a known scanning range. If the site appears down from your office but loads from a phone on a different network, cloaking is in play. Given that nearly all phishing kits now include some form of visitor filtering, this step is not optional.
Confirm DNS resolution independently. A site can appear down in a browser while still resolving at the DNS level. Use a DNS lookup tool to check whether the domain still points to an active IP. If it resolves, the infrastructure is live regardless of what the browser displays.
Verify content removal, not just what the page shows. A 200 HTTP response displaying a “Page Not Found” message is not the same as a confirmed removal. Check whether redirect scripts, data-collection endpoints, or kit artifacts are still accessible at the same path. A removal that clears the landing page but leaves the backend intact has not eliminated the threat.
Demand closure evidence, not ticket confirmation. Ask your vendor what “confirmed” means in their reporting. If it means a ticket was submitted, ask for the timestamp when the site was independently verified as offline. If that timestamp does not exist, the confirmation is a process marker, not an outcome.
Monitor for recurrence. A site that reappears on new infrastructure within days was not meaningfully taken down. Ask your vendor whether they monitor for redeployment, how long they monitor, and what triggers a new case. If each redeployed instance is treated as a separate event, the recurrence rate is invisible in their reporting.
The Bottom Line
A takedown report that says “confirmed” does not always mean the site is gone. Nearly all phishing kits now include cloaking that can make a live site appear down to a scanner. Partial removal leaves infrastructure intact. Redeployment can restore the threat within days. And “ticket submitted” is not “site offline.” The vendor willing to teach you how to verify its own work is the one whose numbers you can trust. The one that discourages you from checking is the one whose numbers you should question most.
Key Takeaways
Five failure modes: suspension without full removal, cloaking that hides the phish from scanners (present in 96.5% of phishing kits), partial removal that leaves kit artifacts active, redeployment on new infrastructure, and “ticket submitted” counted as “done.”
Check from a consumer device on a different network. Confirm DNS resolution independently. Verify content removal beyond what the page displays. Demand closure evidence, not ticket confirmation. Monitor for recurrence.
The term covers at least three outcomes: blocking (visitors redirected or warned), suspension (page offline but infrastructure intact), and full removal (domain deregistered, hosting terminated, kit deleted). Most vendor reports do not specify which one occurred.
Research found that 96.52% of analyzed phishing kits contained cloaking mechanisms. Commercial cloaking-as-a-service platforms now use machine learning to evade detection. Cloaking is the default, not the exception.
What does “confirmed” mean in your reporting? Do you verify from the victim’s perspective or from scanning infrastructure? Do you monitor for redeployment after removal? What is your recurrence rate?
