A firm holding completion monies is a target with a known deadline, a known amount and a known counterparty — and the fraud that takes it is not technical. It is a plausible message with new bank details, sent into a live matter at the right hour. This page is about checking hostnames as a matter of routine, keeping those checks inside the firm for privilege reasons, and doing both in a practice with no security team and no appetite for another system to administer.
Every element the fraud needs is published, predictable or discoverable, and the window in which the theft has to succeed is measured in hours.
Consider what an attacker knows about a residential completion before doing anything at all. There is a definite sum. There is a date, fixed weeks in advance and communicated to five or six parties. There is a chain of correspondence in which the buyer, the seller, two firms, an agent and a lender all exchange documents that name the amounts and the timing. And there is an established, entirely legitimate step near the end at which somebody sends bank details and somebody else acts on them. The fraud does not have to invent any of that. It has to insert one message into a sequence that everyone involved is expecting.
An account somewhere in the chain has already been compromised — often not at the law firm but at the estate agent, the mortgage broker or the client's own personal mailbox — and the fraudulent instruction arrives inside a genuine thread, from a genuine address, with the correct history quoted beneath it. Nothing about the message is anomalous, because nothing about it is fabricated except the account number.
A message from a real account, containing no link at all, simply stating new account details, is defeated only by procedure: verified call-back to a number obtained independently of the email, a standing rule that bank details are never changed by correspondence, and client care letters saying so in advance so the client is not surprised when the firm refuses. Those controls are well understood in the profession and are not what this page is about.
Nobody is compromised and the attacker works from a domain differing by a character, a hyphen or a top-level domain, relying on nobody reading the address bar of a reply. It costs a few pounds, requires no intrusion, and is therefore more common than firms assume — appearing in a reply-to, a document-sharing invitation, a "secure portal" link, or the signature block of a fabricated firm.
The message is credible precisely because it contains a link rather than raw account numbers. Clicking feels safer than typing, and the page it opens can carry the branding and the reassuring language a plain email cannot. That link resolves to a hostname, and a hostname is a thing that can be checked before anybody opens it.
What makes the timing so unforgiving is not sophistication but finality. Once the transfer executes, the funds are broken up and moved through several accounts within hours. The recall process depends on the receiving bank acting before that happens, and it usually does not. From the firm's perspective the loss is immediate, it belongs to the client, and the question of who bears it is answered afterwards by a regulator and an insurer — which is why the profession's exposure to this offence is not really a technology question at all.
An attempt to change where money goes, rather than to break into anything: the attacker's entire objective is that a legitimate payment already scheduled by a legitimate party arrives in a different account. Nothing is stolen from the firm's systems; the firm is used as the instrument. That is why it defeats controls designed around intrusion — there is no malware, frequently no attachment, and sometimes no link at all.
Firms investigating one of these incidents often start by auditing their own mail platform and find nothing, because the compromised mailbox belongs to the agent, the broker or the client. Plan your response on that assumption: the first question is which party in the chain was read, not which of your fee earners clicked something.
Written to be lifted into a practice manual and amended. Square brackets are the parts that differ from firm to firm.
last_checked where a check was performed. The record is made whether or not funds were at risk.Most firms already have some version of clauses 2 to 4. The gap is nearly always clause 5: nobody checks the hostname, because until recently there was no quick, definite way to do it that did not involve pasting a live matter's details into a public web form. That last part is the problem this page spends most of its length on.
Litigation and transactional practice run on links from services the recipient has no relationship with, which is precisely the condition an impersonation needs.
Beyond the payment instruction itself, three surfaces recur. Two of them are inbound, and both exploit the fact that a solicitor's ordinary working day involves acting on messages from services and senders the firm has no prior relationship with. The third faces outward, at clients.
Opposing solicitors nominate a review platform. A client's investment bank runs the data room. An expert delivers a report through a service the firm has never used. Each notification is a branded email with a link arriving without warning, because nobody tells the other side in advance which system they intend to use — so the recipient has no baseline for what a genuine notification from that service looks like, and no reason to be suspicious of an unfamiliar one.
There is nothing to compare it against. It needs to name a matter, look institutional, and arrive during a period when documents are genuinely moving — which, in a disclosure exercise, is every week. The credential it collects is usually the mail account, and the value of that account is not the mail itself but the position it gives the attacker inside all future correspondence on the matter.
Solicitors receive substantive, action-requiring correspondence from complete strangers as a normal part of practice: opposing counsel instructed last week, an agent in another jurisdiction, a court office, a regulator, an expert, a prospective client with an urgent matter. The instinct that protects people elsewhere — I do not know this sender, therefore be suspicious — cannot be applied, because not knowing the sender is the ordinary case.
Extracting domains from inbound correspondence and running them against a verified list is a mechanical step requiring no judgement from the fee earner. It works at the gateway, in a small script over the message store, or as a manual lookup by whoever handles a referred message. The question "is this domain confirmed live phishing infrastructure" has an answer, and that answer does not depend on anybody's instinct about whether a message feels right.
A firm's domain is imitated in order to reach the people who have far less context than the staff do. Typo variants, hyphenated forms, an added word such as "secure" or "portal", and swaps of the top-level domain are all cheap, and all effective against somebody who has exchanged three emails with you in their life and has no idea what your address is supposed to look like.
Assemble the obvious variants of your own domain, anything a client has forwarded as looking odd, and the domains of any portal or payment service you direct clients to, then submit them in batches of up to 100 at one lookup each. It will not discover a variant nobody has thought of and should not be sold internally as if it would — but a verified, dated answer on addresses you already suspect is the right basis for a client warning and a registrar complaint. Firms running a wider watch pair it with the brand protection approach.
last_checked value returned. If the matter is ever reviewed by an insurer or a regulator, that record is the evidence the protocol was followed.A firm should be able to describe the source it relies on in one sentence. Here is that sentence, and the limits that go with it.
The database holds more than 390,000 phishing domains. Inclusion requires a confirmed active A record, verified through rotating proxy infrastructure, on a host assessed as phishing or malware distribution. That test is also the retention rule: when a domain stops resolving it falls out of the list rather than accumulating in it, so what you match against describes hosts that are answering now rather than everything ever reported. For a firm, the practical consequence is that a match means something current, which is exactly what you need when the question is whether to release funds this afternoon.
The build lands at 04:30 UTC, and a daily changelog of additions and removals ships alongside it — so an update can be a diff rather than a full reload, and you can see what changed without reading the whole file.
A single lookup returns is_phishing, a category of phishing/malware, dns_status of resolves and a last_checked date, within a limit of 10 requests per second per key.
A graduated score would put a fee earner in the position of interpreting a probability, and that is not a judgement anybody in a conveyancing department should be asked to make at four o'clock on a Friday.
It means the hostname is not on the list. A domain registered and used for the first time within the same hour will not be present, and that gap is real rather than theoretical.
A fraudulent message containing nothing but new account numbers gives it nothing to check — and that is a substantial share of the highest-value cases. Clauses 2 to 4 of the outline above remain the controls that carry the most weight.
Domains already caught, verified as resolving and confirmed as hostile are answered as such whether the person checking is a partner, a paralegal, or a temp covering reception on a Friday afternoon. It does not depend on anybody's attention.
last_checked, and the feed's daily changelog records when a domain entered and left. Both matter if a file is reviewed later.A firm that would not name a client in a search box should think carefully before sending that client's counterparty domains to a third party, one at a time, in real time.
Most checking services work by asking. Your gateway or your analyst sends a hostname to a provider and receives a verdict. In many industries that is an unremarkable arrangement. In a law firm it deserves a moment's thought, because the stream of hostnames a firm asks about is not neutral metadata. It is a record of who the firm is corresponding with, when, and in what volume. A sequence of queries about a particular counterparty's domains, clustered around a particular week, describes a matter to anyone holding the logs — not its contents, but its existence, its timing and its participants.
None of that is privileged in the strict sense, and it would overstate the position to say a per-query lookup breaches confidentiality. But the duty is framed around reasonable efforts to prevent disclosure of information relating to the retainer, and that is broader than the contents of advice. A firm that has considered the point and can explain why its arrangement is appropriate is in a far better position than one that never thought about it.
Instead of asking about each domain, the firm downloads the whole database — a single authenticated retrieval, CSV as domain,category,dns_status or JSON — and matches against a file it holds. From that point, checking a hostname involves no outbound traffic at all: no per-query record outside the firm, nothing for a provider to disclose, and no dependency on an external service being reachable when a fee earner needs an answer.
It is architecturally true rather than contractually true, which is what a tender response or a client security questionnaire is really testing. The comparison happens on the firm's own equipment, nobody outside learns which domains were checked, downloads are unlimited so there is no incentive to economise, and local matching is fast enough to sit inside a gateway rule or a matter-opening script without anybody noticing.
The distinction worth holding on to: a firm that sends every suspicious hostname to an external service has outsourced a security question and created a confidentiality one. A firm that downloads the list and matches it locally has answered the security question and never created the second — and that is the version that survives a client's security questionnaire without a caveat.
The two audiences ask different questions about the same incident, and both are answered by documentation the firm either has or does not.
Regulatory frameworks for the profession differ by jurisdiction, but the shape of the obligation is remarkably consistent: a solicitor must keep client money safe, must take reasonable steps to protect confidential information, and must be able to demonstrate that the systems and controls in place were appropriate to the size and nature of the practice. None of those rules prescribes a technology. All of them are assessed after the fact, against what the firm actually did, in the light of what was known to be happening in the profession at the time.
A control that was uncommon five years ago becomes the reasonable baseline once the risk is well documented and the mitigation is cheap and widely available. Payment-instruction fraud against firms holding client money is now thoroughly documented by every body that supervises the profession, and warnings are issued routinely — so a firm with no written protocol, no verification requirement and no way of checking a hostname is not comfortably placed when asked what it did about a risk it was repeatedly told about.
Professional indemnity proposal forms increasingly ask specific questions about payment verification procedures, staff training and technical controls, and the answers are warranties. An incident revealing that the procedure described on the form was not in force is an incident with a coverage argument attached — precisely the moment a firm least wants one. A documented protocol, a record of checks and a review minute make that conversation short.
Not the intention. A check that was performed but not written down is, six months later, indistinguishable from a check that was not performed. That is why clause 9 requires the hostname, the date and the result on the matter file — including the last_checked value where a check was made. It costs one line, and it is the difference between a documented process and an assertion.
Nobody is assessed against perfection. The question is whether the firm's arrangements were proportionate to its practice, informed by risks it knew about, and actually operating rather than merely written. A small conveyancing practice with a two-page protocol that everyone follows is in a stronger position than a larger firm with an elaborate policy nobody applies.
The protocol itself, dated and approved. The review minutes. The record of checks on individual matter files. The evidence that staff were told — an email to all fee earners is sufficient. And, if you deploy the feed, a note of when the scheduled retrieval was configured and how staleness is monitored.
A four-partner practice with an outsourced IT provider and a practice manager who also does everything else. That is the deployment this has to fit.
It is worth being blunt about the constraint, because most security guidance written for the profession is not. A typical firm in this category has no internal IT function. It has a support contract with a local provider who visits when something breaks, a hosted mail platform administered by that provider, a practice management system from a legal software vendor, and a practice manager whose job description does not contain the word security and whose week is already full. Any proposal that requires a new console to check daily, a dashboard for somebody to monitor, or an ongoing analytical judgement will not survive contact with that reality — not because the firm is careless, but because there is nobody to do it.
If the firm takes the feed, the whole implementation is a retrieval after 04:30 UTC, a sanity check that the downloaded file is plausible before it replaces the previous one, and a reload of whatever consumes it — the mail gateway's blocklist, the firewall, or a local resolver. A single afternoon for the IT provider, described in a paragraph on a change request, with no recurring administrative task except one staleness alert.
If the firm prefers to hold nothing, the practice manager checks a hostname by hand when a fee earner refers a suspicious message, using the documented check endpoint, on a small monthly plan that lasts years at that volume. Less protective, because it depends on somebody noticing and referring — but realistic, and far better than the current position in most firms, which is that the hostname is never examined at all.
Your API key is simply the username you chose when registering, and it functions as a server-side secret. It must not appear in client-side JavaScript, in a document management template, in a shared script left on a network drive, or in anything a fee earner could forward. If a browser-side check is wanted, put a small endpoint of the firm's own in front of it.
A silently stale list is the only realistic way this deployment fails, and it fails invisibly — enforcement carries on against last week's copy while everything appears to work. One alert if the file is more than forty-eight hours old matters more than anything else in the setup.
/stats endpoint reports database size and last update and requires no API key, no credits and no authentication, so the size of the list can be verified in seconds.Including the objection that this does not address the fraud that actually costs firms the most money.
No, and that is the honest limit of it. Where an account in the chain has been compromised and the fraudulent instruction arrives inside a genuine thread from a genuine address, containing nothing but new account details in plain text, there is no hostname to check and this contributes nothing. Those cases are defeated by clauses 3 and 4 of the outline above — no change by correspondence, independent verified call-back — and by nothing else. What this addresses is the cheaper and more numerous variant that uses a look-alike domain or a fake portal link, plus the general run of credential theft that produces those compromised accounts in the first place, so treat it as a layer that removes a category of attempt rather than as the answer to payment fraud. Any firm that adopts it instead of the procedural controls has made itself worse off.
Only if you choose the per-query route. Calls to /check and /batch transmit the hostnames you ask about, and over time that is a record of who the firm corresponds with and when. It is not privileged content, but it is information relating to retainers and it deserves a decision rather than a default. The feed removes the issue entirely: you download the whole database once a day and match locally against a file the firm holds, so no hostname from any matter is ever transmitted — which is the recommended deployment for anything touching live correspondence, and what lets a firm answer a client security questionnaire without a caveat.
Your existing IT support provider, as a single change request. What you are asking for is a scheduled download after 04:30 UTC, a file, a reload of whatever already holds a blocklist, and one alert if the file is more than forty-eight hours old. There is no console to administer and no dashboard for anyone in the firm to watch. If even that is more than you want, the manual route works: the practice manager checks a hostname by hand when a fee earner refers something, using the documented endpoint, on a small monthly plan that will last a firm of your size for years — less protective, entirely realistic, and considerably better than nobody looking at the hostname at all.
It tells you that the hostname has a confirmed active DNS record and has been assessed as phishing or malware infrastructure, as of the last_checked date in the response. That is a factual observation about a host. It is not a finding about who sent the message, and it should not be recorded on a file as one. Operationally a match means: do not open the link, do not reply to the message, do not forward it to anybody other than the person named in your protocol, and escalate the same day; if the matter involves funds, the transfer stops until clause 4 verification is complete — and write it on the file, with the hostname, the date and the result.
Almost nothing, and this is the misreading that would do real harm. A clean result means the hostname has not been observed and verified — which covers a domain registered an hour ago, a domain used against a target set too small to have been seen, a domain that stopped resolving before it could be verified, and a domain that is entirely legitimate. The four are indistinguishable in the result, so it must never be the reason a suspicion is dropped or a transfer released — record it as a check performed with no match returned, and carry on with the verification protocol exactly as if you had not checked at all.
The database is rebuilt every 24 hours with the build landing at 04:30 UTC, and every entry has a confirmed active A record verified through rotating proxy infrastructure. Domains that stop resolving fall out rather than accumulating, which is why the active count sits above 390,000 rather than growing without limit. A description you can put straight into a questionnaire: the firm subscribes to a commercially maintained list of domains verified as actively resolving credential-harvesting infrastructure, rebuilt daily, matched locally against the firm's own copy so that no hostname from client correspondence is transmitted externally. That sentence is accurate, and it is the one that answers the question actually being asked.
Two shapes. Credits are monthly subscriptions via PayPal, billed monthly, with unused credits expiring at the end of that period: Growth at $99/month for 25,000 lookups, Growth at $99/month for 25,000 lookups , Professional at $249/month for 100,000 lookups with priority support. A firm checking referred hostnames by hand and running a quarterly sweep of its own domains will not exhaust the smallest package quickly. There is a 14-day refund window if under ten percent has been used. Alternatively the Daily Threat Feed runs at $499/month, with priority support — and that is the route giving you local matching and unlimited downloads, with bank transfer available above $4,000 in place of card payment. The full table is on the pricing page and delivery options are set out on the daily feed page.
Sometimes, and it depends entirely on the mechanism, which the published accounts usually do not specify. If the reported case involved a look-alike domain, a fake portal or a credential-harvesting page, then a verified hostname check at the right moment would have produced a definite answer. If it involved a compromised mailbox at the estate agent and a plain-text change of bank details, it would not have helped at all. The useful response to those reports is not to buy one control but to write down what your firm actually does between receiving a payment instruction and releasing funds, then ask which of the two mechanisms above your written process would stop — most firms find they have partial coverage of the first and none of the second, or the reverse. The outline in the section above is a starting point for that exercise, and related workflows are covered on the real estate and email security pages.
Confirm the database size from the open statistics endpoint, check the hostnames from every suspicious message the firm has kept, and decide whether the answers are worth having on file. If client confidentiality is the deciding factor, the daily feed is the deployment that keeps every lookup inside the practice.
