A defence environment cannot call out to a commercial verdict service on every lookup, and no amount of contractual assurance changes that. What it can accept is an inspectable daily file of DNS-verified phishing hostnames, transferred one way into the networks that need it and enforced locally from then on. This page is about that shape, and about being honest regarding what it covers.
Defence buyers are rightly suspicious of products that describe a nation-state adversary and then sell a signature list.
A capable adversary studies a programme before touching it — the contract announcements, the conference agendas, the professional networking profiles that list a clearance level and a programme name. They register infrastructure for one target, use it once, and abandon it, with a pretext built from a real deliverable, a real review board date, a real subcontract number. Against that, no list of previously observed hostnames helps very much, because the hostname has never been observed by anyone, and a supplier who implies otherwise is describing marketing rather than capability.
Beneath the targeted campaigns sits an enormous, undifferentiated volume of commodity phishing that reaches defence organisations for the same reason it reaches everybody: reused kits, rotating hostnames, credential pages aimed at payroll systems, benefits portals, travel booking and password resets. It is not aimed at your programme and it works anyway, because it only needs one person on a bad afternoon. That layer is entirely addressable with a verified list of what is live right now, and clearing it means the small number of genuinely targeted attempts stop competing for analyst attention with a thousand pieces of noise.
This is a known-bad lookup over DNS-verified, currently-resolving hostnames, rebuilt every 24 hours. It reduces exposure to high-volume commodity credential phishing across every network it is loaded onto, and it does so with no outbound dependency at enforcement time. It does not discover novel infrastructure and it does not analyse page content; a negative result states only that the hostname is absent from the list. Write that sentence into the requirement and the product either meets it or it does not — a far more useful procurement conversation than one about advanced persistent threats.
Prime contractors have security operations centres. The machine shop holding one component's drawings has an office manager and a support contract.
Any serious programme flows down through tiers, and the tiers get thinner fast. Below the primes are mid-tier suppliers with a compliance officer and an outsourced help desk; below them, thousands of specialist firms — forging, machining, composites, connectors, test equipment, niche software — for whom the security requirements in a flow-down clause are the most demanding technical obligation in the entire contract. These are the organisations holding Controlled Unclassified Information in an Outlook mailbox and a shared drive, and they are targeted precisely because of that asymmetry.
Compromise a small supplier's mailbox with a commodity credential page. Read the correspondence until the programme vocabulary, the approval chain and the delivery schedule are familiar. Then write to the tier above from a real address, inside a real thread, referencing a real drawing number. Nothing is forged, so nothing is anomalous, and the trust relationship carries the intrusion upward on its own.
DFARS clause 252.204-7012 and the Cybersecurity Maturity Model Certification exist substantially because the supply chain, rather than the prime, is where the practical exposure sits. But a requirement written into a contract is not a control operating on a network, and the gap between the two is exactly where small suppliers live and where assessors keep finding problems.
Something that works without a security team, needs no agent on machines also running the CAM software, and adds no monthly cost a sub-contract cannot absorb. A supplier with a single firewall or resolver can load a file and be measurably better off the same afternoon — see the supply chain and email security pages for the assurance and gateway angles.
The most productive lures aimed at defence populations have nothing to do with classified material.
There is a persistent assumption that phishing against defence organisations must be about the programme. In volume terms it is overwhelmingly not. The credential pages that actually harvest are imitations of pay and personnel systems, benefits and healthcare enrolment portals, travel and expense platforms, training and certification records, retirement and pension administration, and the identity provider used to reach all of them. Those systems hold complete personal records, they are used by everyone regardless of role, and they are administered by organisations that are frequently outsourced and always impersonated.
A stolen personnel-system login produces name, service history, dependants, addresses and banking detail in one place, supporting both financially motivated fraud and, in the hands of a foreign service, targeting and coercion. Password reuse then does the rest: the same credential is tried against the mailbox, the collaboration suite and the remote-access portal, and often works, because the person who reused it did so on a personal device outside anything your policy reaches.
Enrolment windows, pay changes, tax deadlines, deployment and rotation cycles, transition and separation periods — each produces a predictable wave of impersonation aimed at people expecting exactly that kind of message and often navigating an unfamiliar process on a deadline. Personnel in transition are hit hardest, because they are handling employment, education, healthcare and pension paperwork with several new organisations at once and have no baseline for what any of them should look like.
Messages impersonating support services, housing and relocation administration, deployment notification and benefits programmes reach people who are anxious, unfamiliar with the systems, and using personal devices. Nothing an employer deploys protects a spouse's phone. What can be done is narrower and still worth doing: block the hostnames on every network the organisation does control, and verify a reported hostname before issuing a warning so the notice is factual rather than precautionary.
Impersonated recruiting and transition-assistance sites reach people who are not yet inside the organisation, collecting biographical data and, in some campaigns, clearance status. There is no internal network involved at all, so the only useful controls are verification of reported hostnames and rapid escalation. The identity protection and government pages cover the citizen-facing version of the same problem.
Four properties that determine whether this is usable inside an accredited environment, stated without embellishment.
The verification standard is what makes this deployable rather than merely available. Nothing enters the file without an active A record confirmed through rotating proxy infrastructure, and anything that ceases to resolve is dropped at the following rebuild rather than left to pile up. What you hold is therefore an inventory of the currently live, not a museum of everything ever reported — which matters a great deal when a person has to review, transfer and load it on a schedule and will certainly notice if it doubles in size every quarter.
A response carries a boolean on is_phishing, the fixed string phishing/malware on category, resolves on dns_status, and a calendar date on last_checked. Two confidence values exist and only two: 0.98 on a confirmed match, 0.0 on no match. There is no model to explain in an accreditation package and no probabilistic language a reviewer can read as a hedge.
Rather than replacing an entire file nightly and filing a record that says nothing, you apply a delta and record exactly what entered and what left on a given date. Over a year that produces an audit trail answering the question assessors actually ask — not "was the tool installed" but "can you show what changed, and when".
Because /stats is unauthenticated and consumes no credits, a reviewer or a build pipeline can confirm the database size and last update date without any commercial relationship existing at all. Formats are CSV with three columns of domain, category and DNS status, or the same fields as JSON.
The reason a downloaded list works in this sector and a cloud lookup service does not is architectural, not commercial.
Separation of networks is the foundational control in defence environments and everything else is arranged around it. A closed network has no route to the public internet by design; where data must move inward it goes through a controlled transfer path — a guard, a diode, a review station, a documented manual process — and every object that crosses is inspected, recorded and accountable to somebody. That architecture is not negotiable and it is not going to be redesigned to accommodate a security vendor.
The model requires an outbound call and an inbound response at the moment of enforcement, for every lookup. No version of that survives a one-way boundary, and the usual approximations — a proxy in the DMZ, a cached tier, a scheduled synchronisation of recent verdicts — are simply worse implementations of a file, with more moving parts and more surface to accredit. The honest conclusion is that the lookup model belongs on the connected side and nowhere else.
A plain text object of known format is exactly the class of thing controlled transfer paths were built to handle, and it can be inspected before promotion by someone who does not need to trust the supplier. If the transfer happens weekly rather than nightly the deployment still functions — coverage is a few days behind, which is a known and acceptable degradation rather than a failure state.
A scheduled job on an internet-facing host authenticates and downloads the current build shortly after 04:30 UTC. The API key is the username chosen at registration; it lives in that host's secret store and appears nowhere else.
Check the record count against the previous build and against the open /stats endpoint, confirm the format parses, reject anything with an implausible delta, and generate the hash that will travel with the file.
The file crosses using whatever controlled path is already accredited. Nothing new is being introduced — this is a plain text object of a known format and a known size, which is the easiest possible case for that process.
Hash verified on arrival, previous file retained for rollback, local allow-list applied after import so exceptions survive, resolver or firewall list reloaded, verification query run, change closed with the changelog attached as evidence of what altered.
The realistic failure mode is not a bad entry — it is a transfer that silently stopped in March. One alert if the loaded file is older than a defined threshold is worth more than any amount of match reporting.
Two things every programme security officer needs before this reaches a requirement document: what it costs, and what it will not do.
Credit packages cover API-shaped work on the connected side and are monthly subscriptions via PayPal: Growth at $99/month for 25,000 lookups, $99/month for 25,000 lookups, $249/month for 100,000 lookups, $499/month for 250,000 lookups, $999/month for 750,000 lookups, with larger tiers above that. Unused credits expire at twelve months, a package under ten percent consumed can be refunded within fourteen days, and payment by bank transfer becomes available above $4,000 — the last of which is the more relevant route for most organisations here, where paying by card against a requisition is frequently not permitted at all.
For closed networks the relevant product is the Daily Threat Feed — $499/month — with unlimited downloads, so cost does not scale with the number of sites, networks or enclaves the file is distributed to. Take it annually and you also get archive access to historical data, priority support, format customisation, a named account manager and 100,000 API credits, enough to cover the connected-side checking without raising a second procurement action. On-premise deployment, SFTP or S3 delivery, STIX/TAXII and custom update frequencies are quoted rather than listed.
This is a known-bad lookup. Absence from the list is not evidence that a destination is harmless; it is only evidence that the hostname has not been observed and verified. A domain registered this morning and used once this afternoon against one named individual will not be present, and no verification-based database can contain it, because verification requires having watched the domain resolve at least once.
It does not analyse content, inspect attachments, evaluate sender reputation, detect anomalous authentication or do anything at all about an intrusion already inside. Against a well-resourced actor who builds infrastructure specifically for your programme and burns it after a single use, it contributes very little — and any capability document implying otherwise will not survive first contact with a competent assessor.
Analysts in this sector are scarce, expensive and cleared, and every hour spent triaging commodity credential phishing is an hour not spent on the events genuinely aimed at the programme. Removing that noise at the resolver is the cheapest way to recover the hours. Pair it with the layers on our incident response, threat intelligence and SIEM integration pages and the whole becomes considerably more than this one part.
checked, phishing_found and credits_used, which is all a scheduled sweep needs to write one log line.Eight questions, including the two a supplier would normally prefer not to be asked directly.
Yes, and it is the primary reason the feed exists as a file rather than only as an API: the download happens on a connected host, and what crosses the boundary is a CSV or JSON file of a known format, with a size and a hash you generated yourself, containing nothing but hostnames and two metadata columns. That is exactly the class of object a controlled transfer path is designed to carry, and a reviewer can open it in a text editor before it is promoted, which is not true of any agent or appliance. A per-query lookup service cannot do this in any configuration, because the model requires a request to leave the network at the moment of enforcement.
Nothing phones home once the file is loaded: matching happens entirely inside your infrastructure, against your own resolver, firewall or matching service, with no callback, licence check or telemetry at enforcement time. The only outbound traffic in the whole design is the scheduled authenticated download on the connected side, and even that is a plain HTTPS fetch of a file rather than an agent maintaining a session with somebody else's cloud. Where the requirement is a fully on-premise arrangement — including the delivery mechanism and the update process — that is available as a quoted option rather than a published package.
Probably not, and it is better to say so at this stage than to be found out at the assessment: if the entry point was infrastructure registered for that specific target and used once, it was on no list anywhere at the time, including this one, because verification-based inclusion is inherently retrospective and the domain has to have been observed resolving before it can appear. What this removes is the commodity layer beneath the headline cases — the reused kits and rotating hostnames that hit hundreds of organisations in the same week — and that layer is the overwhelming majority of what actually arrives in a defence mailbox. Judge it on that and it earns its place; judge it as an answer to a targeted actor and it fails.
It contributes evidence, not a certification. Practices concerned with monitoring systems, identifying and reporting security events, and protecting the network boundary are supported by a control that blocks known malicious destinations and produces logs of attempted resolutions, and the artefacts you can show an assessor are ordinary and durable: a scheduled job with a run history, a dated file with a hash, a record count corroborated against the open /stats endpoint, a change record per promotion, and the daily changelog demonstrating exactly what altered. Whether that satisfies any specific practice is a determination for your assessor against your system security plan, and no supplier can make it on your behalf.
No. The enforcement point is infrastructure the traffic already passes through — a recursive resolver, a firewall external dynamic list, a proxy, or a mail gateway extracting hostnames from inbound messages — so no agent is installed, no image is modified, and nothing on a workstation changes, which matters where machines run qualified software configurations that cannot be altered without re-testing. It also means coverage extends to devices that could never take an agent at all: appliances, test equipment, shared terminals and anything sitting on a build or laboratory network.
Design for it before it happens: keep a local allow-list that your import script applies after each update so an exception survives the next promotion, and run in log-only mode for at least one full cycle before enforcing, so any collision surfaces during observation rather than during an operational period. Two conditions have to be met before a hostname is included — it must resolve, and it must be confirmed as phishing infrastructure — so false positives are rare, but they are not impossible, and in this sector a documented correction path counts for more than a low error rate. Make sure the duty officer can add an exception without waiting for a change board to convene.
This is one of the more useful things a prime can do for a programme: feed downloads are unlimited on a subscription, so a single holder can pull the daily build and redistribute the file through whatever supplier portal or secure transfer arrangement already exists, and the suppliers then load it into their own resolver or firewall with no commercial relationship of their own. That removes both the cost objection and the procurement delay that otherwise stop small firms from acting at all. Confirm the redistribution arrangement in your agreement rather than assuming it, and pair it with the supplier-domain sweep described on the supply chain page.
A complete rebuild happens on a 24-hour cycle, the finished build appears at 04:30 UTC, and every entry has been confirmed to hold an active A record via rotating proxy infrastructure. When a domain stops resolving — suspended, seized or simply abandoned — it drops out of the next build rather than remaining in the file indefinitely, which keeps the loaded list a working set rather than a growing archive and is what makes a nightly transfer and reload sustainable over a period of years. Each check response carries last_checked as a date, and the daily changelog records precisely which hostnames entered and left on any given day.
Confirm the database size and last update through the open statistics endpoint, take one build through your transfer and review process, and run it in log-only mode for a cycle before enforcing. For closed networks and for distribution across a supplier ecosystem, the daily feed is the only shape that fits the architecture.
