destroylist is a continuously updated phishing and scam domain blocklist that ships curated and community feeds in hosts, AdBlock, dnsmasq, Unbound, and RPZ formats for defenders and authorized security teams.
| Tool | phishdestroy/destroylist — real-time phishing and scam domain blocklist with curated and community feeds plus a threat intelligence API |
| Category | DNS blocklists / threat intelligence feeds |
| Primary Use | Feeding network-level blocking in Pi-hole, AdGuard Home, dnsmasq, Unbound, and RPZ-capable resolvers with phishing, crypto-scam, and drainer domains |
| Safe Use | Deploying on networks and resolvers you are authorized to administer, and for defensive research, SOC triage, and phishing analysis in lab environments |
| Telemetry Note | Purely defensive: defenders observe reduced resolution of listed domains; the DNS-verified feeds reveal which entries remain live, useful for monitoring feed freshness and liveness |
destroylist is a maintained, MIT-licensed blocklist project that positions itself as a free, continuously refreshed source of phishing and scam domains for network defenders. The repository carries roughly 1,777 stars and is organized around two tiers of data: a curated primary feed the maintainers verify themselves, and a broader community feed aggregated from more than 13 external sources. What makes it interesting from an operator's perspective is not just the raw data but the operational hygiene layered on top — automated GitHub Actions pipelines for list updates, statistics generation, and GitHub Pages deployment, all visible through workflow badges in the README.
The feed architecture is where the design decisions show. The primary feed (list.json, list.txt) is described as curated phishing domains updated in real time, which the README recommends for production use. On top of that sit DNS-verified variants (active_domains.json, active_domains.txt) that are refreshed on a 24-hour cycle, filtering the list down to entries that actually resolve. This distinction matters a lot in practice: a blocklist full of expired and parked domains wastes resolver memory and dilutes signal, so the liveness verification is arguably the project's most valuable engineering contribution.
The community tier widens coverage considerably. Aggregated from 13+ upstream sources on a 2-hour cadence, the community feed (community/blocklist.json, community/blocklist.txt) is explicitly recommended for maximum coverage rather than maximum precision. There is a community-live variant with DNS verification, and the README is refreshingly honest about the trade-off — you take on more false-positive risk in exchange for breadth. An allowlist.json exists specifically for false-positive protection and is maintained manually, which tells you the maintainers have fielded enough appeals to build process around them.
Beyond DNS liveness, the project adds content-verified feeds. The primary content feed (dns/content_active.json) is described as curated plus HTTP content verified on a 12-hour cycle, meaning entries are not just resolving but serving something at the HTTP layer. This is a meaningful escalation in verification depth: it catches domains that resolve but serve nothing, and it implies a pipeline that fetches and evaluates content. For defenders triaging phishing reports, a content-verified list reduces the noise of stale registrations that still have DNS glue but no live attack infrastructure behind them.
Format support is unusually comprehensive. The root lists directory ships TXT, hosts, AdBlock, dnsmasq.conf, unbound.conf, and RPZ variants for each of the four main tiers, meaning the same data drops directly into Pi-hole and AdGuard Home for home-lab use, into dnsmasq or Unbound for self-hosted resolvers, and into RPZ for enterprise-grade BIND-style response policy zones. The README's quick start is a single URL paste into blocklist settings, and it explicitly recommends the jsDelivr CDN links over raw raw.githubusercontent.com URLs because the latter can return 429 rate-limit errors under heavy traffic — a small operational detail that signals real-world deployment experience.
Availability engineering extends to the delivery layer. The CDN mirror is billed as globally distributed with no rate limits, which matters for anyone running scheduled fetches from a fleet of resolvers or a SIEM ingestion pipeline. The README also documents the discrepancy between badge counts and API counts: badges reflect exact feed-entry counts, while the threat intelligence API applies normalization — stripping www prefixes, deduplicating URLs and domains — so API-reported totals can be lower. Acknowledging that gap in documentation rather than letting users discover it confusingly is the kind of transparency you want from a feed you might hinge blocking policy on.
Machine-readable metrics are exposed via dns/metrics.json plus a family of count files (today_added.json, week_added.json, month_added.json and community equivalents) that track additions across daily, weekly, and monthly windows. For a SOC consuming this feed, those delta counters are a lightweight freshness signal: a feed whose additions flatline may have lost its upstream pipeline, while sudden spikes often correlate with an active phishing campaign or a mass drainer deployment in the web3 scam space the topics list hints at (crypto-scam, drainer, seed-phishing, web3-security).
The topic tags sketch the threat model clearly. Alongside generic phishing and malware tags sit crypto-scam, seed-phishing, and drainer, pointing at crypto wallet drainer kits and seed-phrase phishing as a core focus. That focus is a genuine differentiator against older general-purpose blocklists, because crypto scam infrastructure rotates domains aggressively and demands the near-real-time update cadence the primary feed advertises. Defenders protecting exchange customers, wallet users, or corporate crypto holdings get coverage tuned to that rotation rate.
The appeals process and the fraud-victims section in the README deserve mention as governance signals. A published appeals path means domain owners who land on the list in error have recourse, which is essential for any blocklist that firewall and DNS administrators adopt at scale. The fraud-victims information section suggests the project also aims at end users, not just operators, framing itself as protective infrastructure rather than a pure research artifact.
For authorized use, this is a defensive tool through and through: ingest the feeds into a resolver or SIEM you administer, correlate hits against egress logs, and use the verified tiers to prioritize. The practical guidance in the README is sound — list.json or active_domains.json for production precision, blocklist.json for maximum coverage, and the root-list formats for firewall and DNS enforcement. Operators integrating the threat intelligence API should account for the normalization behavior and pin their ingestion to the CDN endpoints to avoid rate-limit flakiness.
Caveats worth flagging: the README is heavy on presentation but the verification internals — how curation happens, what the content verification actually checks — are not fully specified in the visible text, so treat feed quality claims as partly unaudited. Community-aggregated tiers inherit the quality of 13+ unnamed upstream sources. None of this is disqualifying; it simply means a prudent deployment validates the feed against your own allowlist and monitors false-positive rates, exactly as you would with any third-party threat intelligence.
phishdestroy/destroylist.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.