Somewhere in a fleet of a few hundred thousand virtual hosts, a handful of document roots are answering requests with a bank login clone. You already hold half the answer — the inventory of every hostname you serve. This page is about the other half: a daily, DNS-verified list of hostnames confirmed to be live phishing infrastructure, and what an abuse desk does with the overlap.
The phishing content on a mature hosting platform is overwhelmingly parasitic on customers who did nothing wrong except fall behind on updates.
The mental model most people bring to abuse work is the disposable account: an attacker signs up with a stolen card, deploys a kit, gets terminated, signs up again. That does happen, and signup fraud controls are worth having. But on a platform that has been running for a decade it is not where the volume sits. The volume sits on legitimate, paying, long-standing customer sites compromised through an unpatched content-management plugin, a reused FTP password, an administrative account belonging to a developer who left two years ago, or a theme downloaded from somewhere it should not have been. The account has years of billing history and a real human behind it, which is precisely what makes the hostname valuable to an attacker and awkward for you. What follows is the life of one such kit, from the first written file to the case your desk finally closes.
The mechanics are dull and consistent. Something in the stack — a plugin three versions behind, an abandoned theme, an upload handler that never checked what it was handed — is used to place a file on disk. No credential was needed and the customer sees nothing.
Control-panel credential phishing is a permanent fixture of this industry: a message that appears to come from your brand, warning that a plan is lapsing or a payment failed, linking to a form that reproduces your cPanel, Plesk or client-area login down to the favicon. When that works the attacker needs no exploit at all — they sign in, add an addon domain or a subdomain, and upload through your own file manager. Resellers make this worse, because their customers often have no idea whose infrastructure they are on and therefore no baseline for what a genuine platform notice looks like.
Rarely the kit itself. Usually a few kilobytes of uploader in a nested directory under an uploads folder, a path mimicking a well-known metadata directory, or a cache folder that gets recreated on every deploy — chosen precisely because it survives a tidy-up and attracts no attention in a file listing.
A handful of PHP files, an HTML clone of a bank or webmail login, a stylesheet and image bundle pulled straight from the imitated brand, and a handler that mails or posts each captured credential set to a drop address. The gap between the uploader and the kit is why filesystem timestamps alone rarely tell the whole story.
A .htaccess frequently ships with the kit, configured to return a 404 to anything that looks like a security crawler or an address range belonging to a scanning service. The page renders for a victim arriving from an email link and vanishes for anyone checking afterwards, which is how a report can be entirely genuine and entirely unreproducible.
Free subdomains, staging URLs, preview hostnames and site-builder addresses all hand out a label under a parent domain that has accumulated years of reputation. A phishing page on an unfamiliar new domain has to overcome a reader's suspicion of a strange string; one on a subdomain of a hosting brand that mail filters and browsers have been seeing benign traffic from for years starts several steps ahead of that.
The page has to answer DNS to be worth anything to its operator, and that is the moment it becomes findable by anyone holding a list. It enters the next daily build as a confirmed, currently-resolving phishing hostname — the first point in this whole sequence where you can learn about it from data rather than from a complaint.
Without that step, this is the stage where a brand-protection vendor, a bank's takedown team or a customer forwarding a screenshot tells you instead — and free-subdomain namespaces are exactly where hosts most often learn about the problem from outside rather than from anything running inside their own estate.
Hosted phishing is rarely contained to the account hosting it, which is why the discovery lag is the expensive part rather than the takedown.
A compromised account that starts pushing lure mail through your shared relay puts that relay's reputation at risk for every tenant on it. The first symptom is usually a support queue full of unrelated customers reporting that their invoices are landing in spam.
Blocklist operators frequently act on the address rather than the hostname. One kit on a shared IP can put hundreds of unrelated vhosts behind a warning interstitial or a mail rejection, and delisting is a queue you join rather than a switch you flip.
Reports arrive from brand-protection vendors, bank takedown teams, automated pipelines and members of the public. A large share are duplicates or already dead. Sorting the live ones by hand is what turns a two-hour response target into a two-day one.
Suspending a whole account on a bad report takes a working business offline and produces a chargeback, a public complaint and a retention problem. Not suspending a real one leaves you hosting active credential theft. Both errors are expensive, in different currencies.
Notice-and-takedown regimes turn on whether you acted promptly once aware. An abuse process whose only evidence is a mailbox thread is a weak record. A dated, machine-generated case carrying the source of the finding is a strong one.
Ask most abuse teams where their hours go and they describe triage, not remediation. Once a case is confirmed, quarantining a document root or nulling a vhost takes minutes. The cost sits upstream of that: establishing whether a reported hostname is genuinely serving phishing right now, whether the report is a week stale, which account owns the vhost, and whether the customer is a victim or the operator. A list of hostnames already verified as resolving does not remove those judgement calls, but it collapses the first of them from an investigation into a lookup — and it lets you ask the question about the whole fleet at once, rather than only about the hostnames somebody happened to report.
You are the only party who knows every hostname your fleet answers for. That inventory is the asset; the feed is simply the second column.
Every hosting platform can produce, with some effort, a flat list of every hostname it serves: primary domains, addon domains, parked aliases, every label under a free-subdomain namespace, every CDN property, every staging and preview host. That export is the thing nobody outside your organisation has. The database behind this API is the complement: hostnames confirmed, within the last twenty-four hours, to be resolving in DNS and serving phishing. Neither list is interesting alone. The intersection is an operations queue — the specific set of your customers who are, at this moment, hosting credential theft.
It is arithmetic. If your fleet is four hundred thousand vhosts and you want to check all of it daily, that is four hundred thousand lookups a day through the batch endpoint at a hundred hostnames per request. The feed inverts the direction of travel: you pull the complete database once, load it into whatever you already use for set membership — a Redis set, a sorted file, an indexed table, a Bloom filter if you are matching in a hot path — and the comparison runs on your own hardware at whatever rate you like. The daily changelog of added and removed domains keeps the update cheap, because after the first load you are applying a delta rather than rebuilding.
At the narrow points where you need an answer about one hostname at a decision moment, and there are three of them on a typical platform:
Those are single calls, they return in well under fifty milliseconds, and the plan arithmetic is comfortable: an abuse desk processing three thousand reports a day consumes roughly ninety thousand lookups a month, which the Professional plan covers at $249/month for 100,000 lookups with room to spare.
Ordering matters more than teams expect, and three sort keys applied in this order produce a worklist ordered by consequence rather than by the order in which reports happened to arrive:
$ curl -s -X POST https://phishingdetectionapi.com/api/v1/batch \
-H "Content-Type: application/json" \
-d '{"apikey":"YOUR_KEY",
"domains":["shop.tenant-4471.example",
"portal.tenant-9820.example",
"edge.tenant-1033.example"]}'
# single-hostname verification at the abuse desk
$ curl -s "https://phishingdetectionapi.com/api/v1/check\
?domain=portal.tenant-9820.example&apikey=YOUR_KEY"
{"domain":"portal.tenant-9820.example","is_phishing":true,
"category":"credential-harvesting","dns_status":"resolving",
"last_checked":"2026-07-26T04:12:09Z","confidence":"high",
"database_size":391204}The batch endpoint accepts up to 100 hostnames per request and charges one credit per hostname. A database-stats endpoint returns the current size and last-update timestamp, which is what your staleness alarm should watch. The key is held server-side and never appears in a customer-facing control-panel page. Full parameter reference on the API documentation page.
Four properties that decide whether this is usable inside an automated abuse pipeline.
Dead domains are dropped rather than retained, and that is the property which matters most to an abuse desk. A blocklist that keeps every hostname it has ever seen produces findings you cannot act on and customer relationships you cannot repair. A list containing only hostnames observed resolving today produces a queue where every row is a live problem.
The hard part of abuse handling was never the takedown. It is deciding quickly and defensibly which reports deserve one.
An abuse mailbox is a firehose of unequal inputs. Some reports come from organisations with disciplined pipelines and precise evidence. Some come from a member of the public forwarding an email with no URL in it. Some are automated resubmissions of a case you closed last month. The rational response is a triage gate costing almost nothing per item — extract every hostname in the report, check each one, route on the answer:
Once a case is actionable, the suspension decision should be a policy your legal and support teams settled in advance, not one an analyst improvises at two in the morning. The narrowest useful action is usually to quarantine the offending path — move the kit out of the document root, leave the rest of the site serving — and open a customer notification carrying the evidence, which preserves a compromised victim's business while removing the harm. Full account suspension makes sense in four situations:
Publishing that ladder — quarantine, notify, escalate, suspend — turns an argument into a checklist.
Most of the people you are writing to are victims, and a message that opens by accusing a small business of hosting fraud produces a defensive reply and a support escalation. A message stating that a specific file at a specific path is serving a login page imitating a named brand, that the hostname was independently confirmed as live phishing infrastructure on a given date, that the likely cause is a compromise rather than anything the customer did deliberately, and that here are the three things to check first, produces cooperation. Attach four things every time:
Teams that pair that trail with a broader incident-response workflow and a threat-intelligence pipeline end up with one evidence trail serving three purposes at once.
Nothing here needs an agent on a customer node, and nothing changes how tenants are provisioned.
Every hostname the fleet answers for — primary, addon, parked, subdomain-namespace label, CDN property — with the owning account ID and node beside it.
An authenticated fetch of the current CSV plus the added and removed changelog, scheduled after the rebuild lands, with an alarm if the file is more than two days old.
Join on the hostname inside your own infrastructure. Keep the rows where the domain is currently resolving; park the rest as lower-priority cleanup work.
Open an abuse case against the owning account automatically, carrying the feed row, the date first observed, the vhost path and the templated customer notification.
After remediation, re-check the hostname through the check endpoint and write the result onto the case. No verification, no closure — that rule is the whole discipline.
The customers who pay for a kit you did not find quickly are almost never the customer who was hosting it.
Shared infrastructure means shared consequences. When a phishing page is served from an address that also serves four hundred unrelated sites, the parties who act on it — mail receivers, browser safe-browsing systems, corporate DNS filters, security appliances — frequently act at the granularity of the address or the enclosing range rather than the hostname. That is not carelessness on their part; from outside, an IP that has served two kits this month is a defensible unit of risk. But the effect inside your platform is that a compromise on one small customer's blog degrades mail deliverability and browser trust for every neighbour on the node, none of whom did anything and all of whom will open a ticket.
Delisting is not a switch. It is a sequence you only partly control:
During that window your support team is explaining to unaffected customers why their transactional mail is bouncing. Some operators eventually migrate the affected tenants onto fresh address space, which works, costs money, and does nothing about the next occurrence. The only genuinely cheap intervention is compressing the interval between a kit going live and you knowing about it, because the listing is triggered by external observation — and if you observe first, you can remove the content before anyone else's observation is worth acting on.
External detection of a new phishing hostname and its arrival in a shared feed happen on similar timescales, so a platform intersecting its inventory against the current build each morning is usually looking at the same finding a blocklist operator is about to act on — but with the ability to remove the content rather than merely record it. That is not a guarantee and should not be sold internally as one. It is a meaningful shift in the odds, and across a year it is the difference between a couple of listing incidents and a steady trickle of them. Operators who also run resolvers for customer-facing services often load the same feed there; the mechanics are covered on DNS filtering and ISP and telco networks.
They fail in different directions, which is the argument for running more than one — and for being precise about which does what.
| Question | Wait for abuse reports | Document-root signature scanning | Feed × inventory intersection |
|---|---|---|---|
| Finds it before an outside party complains | Never, by definition | On the next scan pass | On the next daily build |
| Works on unmanaged VPS and container tenants | Reports arrive regardless | No filesystem access | Hostname-level, no agent |
| Sees past cloaking that hides the page from crawlers | Only if a victim reported it | Reads files, not responses | Depends on prior verification |
| Tells you the exact file to remove | Usually a full URL | Path and file hash | Hostname only |
| Confirms the target is live right now | Stale reports are common | Files may be orphaned | DNS-verified within 24 h |
| Cost of adding another 100,000 vhosts | Grows with ticket volume | CPU and I/O on every node | One more join, same daily file |
| Catches a kit uploaded in the last hour | Not until somebody sees it | If the scan interval is short | Not yet observed or verified |
| Produces a dated record for a takedown file | A mailbox thread | Scanner output | Feed row with observation date |
Read the losing rows carefully. The intersection is beaten on freshness and it will never point at a file. It wins on the tenants whose disks you cannot read, on cost at fleet scale, and on the certainty that what it returns is live rather than historical.
Worth reading before this goes into a policy document or a customer-facing security page.
A kit that went live forty minutes ago on a hostname nobody has yet observed is not in the database, and no amount of query volume will conjure it there. What you get is phishing infrastructure already caught and confirmed — on a large fleet a meaningful and continuously refreshed set, but never the first thing to notice a brand-new campaign. If your platform is a frequent target of novel kits, this belongs alongside filesystem integrity monitoring and outbound mail anomaly detection rather than instead of them.
A listing on a customer's domain tells you the domain is serving phishing somewhere, not where. Locating the file is still your job, and on a busy shared node that means a targeted scan of the document root with modification timestamps as the starting point. The granularity cuts in your favour on subdomain namespaces though: a listing on one label under your free-subdomain domain is a statement about that label, not the parent. Never build automation that suspends a namespace because one of its children appeared.
Every entry is confirmed to be resolving, which is exactly what makes the list actionable — but it also means an attacker who pulls the DNS record while leaving the files in place drops out of the list. The content is still on your disk, still reachable by address or by some future hostname, and still evidence of a compromised account. Treat a hostname that disappears from the intersection as a case to close deliberately, with a verification call and a look at the filesystem, rather than as a case that resolved itself.
It tells you a hostname is serving phishing. It does not tell you whether the account holder is a criminal or a bakery whose plugin was three versions behind. That distinction drives your entire response — quarantine and notify, or suspend and refer — and it is yours to make from account history, payment signals and how the customer answers the notification. Any vendor implying otherwise is selling a judgement they are not positioned to have.
The practical ones, answered without hedging.
Coverage of everything the scanner cannot read. A signature scanner is excellent on managed shared hosting where you own the filesystem, and it gives you the exact file, which the feed never will. It gives you nothing at all on the tenants you cannot reach into:
Almost never as a first action. The overwhelmingly common case is a compromised legitimate site, where the proportionate response is to quarantine the offending path, leave the rest of the site serving, and notify the customer with the evidence and a remediation checklist. Full suspension is reserved for the accounts where proportionality runs out:
It means every hostname in the database has been confirmed to resolve in DNS as part of the daily rebuild, and hostnames that stop resolving are dropped rather than retained — the database is a snapshot of what is live, not an archive of everything ever seen. For an abuse desk that is the difference between a usable queue and an unusable one:
Yes, and it is the cheapest control described here. A single call to the check endpoint when a domain is added as a primary, addon or parked domain returns in well under fifty milliseconds and costs one credit — and attackers do reuse domains that are already burned, so catching one at provisioning saves the entire downstream cycle of kit, report, triage, suspension and appeal. Two implementation rules matter:
Faster than a customer domain, and with a narrower blast radius in mind. That hostname is spending your brand's reputation rather than a customer's, and the filters and browsers acting on it may generalise to the parent, so these belong at the top of the priority queue with the takedown as a single automated action rather than a ticket somebody picks up in the morning. Two guardrails go with that:
label.yourbrand.example is a statement about that label alone.It depends entirely on which access mode you lean on. Fleet-wide sweeps belong on the daily CSV feed, which is a separate subscription and does not consume per-lookup credits at all — you pull the whole database and match locally, so a million-vhost estate costs the same as a ten-thousand-vhost one. Credits are for decision-point lookups, and a worked example sizes them quickly:
It helps you get out and stay out; it does not shorten the delisting queue itself. What it changes is the quality of your answer at two moments:
Many hosts do, and it reads well on a managed tier: continuous monitoring of your hostnames against a daily-updated database of live phishing infrastructure, with a notification if your site is ever found serving it. Described accurately — monitoring and notification, not prevention — it is a claim you can stand behind, and it pairs naturally with the brand-protection monitoring larger customers already buy. Two claims to keep out of the marketing copy:
Most platforms are surprised by the first intersection, and usually not by the number — by which accounts are on it. Monthly plans start at $99/month for 25,000 lookups, and the whole-database CSV feed is available as a separate subscription for fleet-wide sweeps.
