No other department combines those two powers. That is the whole reason payroll diversion, W-2 pretexts, benefits-portal clones and fake job offers all converge on the same small team. This page is about how those attacks actually run, what a verification procedure has to look like, and where a lookup against 390,000+ DNS-verified live phishing domains genuinely helps — and where it does not.
Five fields an attacker would like to steal, and one they would rather quietly change. HR is the only function that can do both from a single screen.
Most functions can be told to distrust unexpected mail. HR cannot, because unexpected mail from people it has never met is the work itself.
Security guidance tends to assume a reader who can safely ignore an unfamiliar sender, and that assumption does not survive contact with a recruitment inbox. A recruiter's day consists of receiving documents and links from strangers, opening them, and forming a judgement — not a risky deviation from the role but the role itself. The same is true one desk over: a benefits coordinator corresponds with carriers and brokers she did not choose, a payroll specialist exchanges files with a bureau and a tax authority, an HR business partner receives employment-verification requests from lenders and landlords with no prior relationship. Telling any of them to stop clicking is telling them to stop working.
One HRIS login reaches the legal name, date of birth, national identity number, home address, dependants, salary history and bank details of everyone on the payroll. There is no other seat in a company where one credential opens that much personal data about that many people, and it is a category of data with no expiry — a leaked password is rotated in an afternoon, a leaked date of birth and identity number are permanent. That is why an HR compromise reads differently in an incident report from almost any other kind.
Payroll is a recurring, high-volume, automated payment run in which nobody approves each beneficiary individually. Change the field and the money follows, on schedule, with no exception raised and no counterparty to query it. Finance functions have spent years building controls around outbound payments precisely because they are the obvious target; the bank-detail field in an employee record often has less scrutiny around it than a two-hundred-pound supplier invoice, and it pays out every month.
Real HR mail asks people to upload identity documents to portals they have never seen, to log into a benefits site they use once a year, to confirm personal details in a window that closes on a date, and to do all of it at the request of a department most employees interact with only occasionally. The templates for imitating that are sitting in every employee's archive from last year, which is why HR communication is the easiest internal voice in the organisation to fake convincingly.
The threats are the same. What differs is who is standing between the request and the record, and how many of them there are.
One or two generalists run recruitment, onboarding, payroll input and benefits between them. There is no separation of duties because there are not enough people to separate, and the person who receives a bank-change request is the person who applies it.
Change requests arrive as tickets in a queue, handled by whoever picks them up, often across several legal entities and time zones. Volume is the vulnerability: an agent processing forty personal-detail updates a day has no realistic way to treat the forty-first as suspicious on instinct alone.
You are two things at once: an impersonated brand, because your login page is cloned to harvest your customers' administrator credentials, and a pipe, because candidate-supplied links flow through your applicant-tracking system into recruiters' browsers at every client you serve.
The most profitable attack on HR is also the quietest, because the victim does not find out until payday and the paperwork looks entirely normal.
The campaign usually opens somewhere other than HR. An employee receives a message about a payroll portal, a payslip that failed to deliver, or a benefits statement waiting for review, and lands on a hosted clone of the real self-service page. They authenticate. Nothing appears to happen, or they are redirected to the genuine site with an error, and they move on. The attacker now has a working credential for a system that lets the employee change their own bank details — or, if the employee has any administrative rights, other people's. Where self-service exists, no HR person is ever involved in the fraud at all, which is why the first indication is a payday support call rather than a security alert.
The message comes from an address resembling the employee's, or a free-mail account explaining that it is a personal address because access has been lost, and asks for the deposit account to be updated before the next run. It is polite. It contains no urgency that would trigger suspicion, no threats, no unusual attachment. Frequently it opens with an entirely innocuous question and only raises the bank change in the second or third reply, after a normal-looking thread has been established — a rhythm designed to make the request feel like continuing business rather than starting it.
The reason it works is not carelessness. A bank-detail change is a genuinely routine request, made by real employees for real reasons, dozens of times a year in any mid-sized organisation, and refusing to process it quickly is itself a failure of the job. The attacker is not asking HR to do something strange; they are asking HR to do something ordinary, on behalf of somebody who superficially appears to be entitled to ask, at a moment when the queue is full. The request does not look wrong, because it is not shaped wrongly.
A message that appears to come from a senior executive, an external auditor or a tax adviser asks for a payroll export, a list of employees with identity numbers, or copies of year-end tax statements, framed as urgent and confidential and often citing a real deadline. The pretext is well researched — it arrives during the window when such a request would be plausible, names a real internal process, and sometimes references a genuine meeting. A single successful one hands over the permanent identity data of an entire workforce in one file, which is then used for fraudulent filings, credit applications and further targeted phishing against the same people.
The most dangerous request is the polite one. Teams are trained to spot urgency, threats and bad grammar. Modern payroll-diversion mail has none of those. It is calm, correctly spelled, patient across several exchanges, and asks for something HR does every week. Build the control around the type of request, not around how the message feels.
Where a domain check fits. Both variants above usually involve a hostname somewhere: the cloned portal the employee logged into, a look-alike domain in the reply-to address, a link in the thread to a "secure document". Screening those hostnames against a list of currently-live phishing domains catches the ones already known and does nothing about the ones that are not. It is a filter in front of the procedure, not a replacement for it.
Not a reputation score, not a content judgement, not an opinion about the sender.
Domains that stop resolving are dropped rather than kept, so what comes back is a statement about live infrastructure rather than a historical archive. For an HR team that matters practically: a warning on a candidate's personal website that has been dead for two years teaches recruiters to ignore warnings, and once they do, the control has been spent.
HR is unusual in facing an inbound stream of untrusted URLs and an outbound stream that other people are taught to trust.
Every applicant-tracking system in use today accepts candidate-supplied links — a portfolio, a personal site, a code repository, a video introduction, a URL in a covering letter — and recruiters are expected to open them, so "do not click links in applications" is advice nobody can follow. Screening solves the tractable part: when an application is submitted, extract the hostnames from every URL in it and check them as a batch before the record ever reaches a human queue. Anything already confirmed as live phishing infrastructure is flagged on the record itself, so the recruiter sees a warning attached to the link rather than a security lecture attached to their job.
Attackers build convincing career sites in the name of real employers, post real-looking vacancies, conduct interviews over chat, and issue offer letters — then send the "new hire" to an onboarding portal to upload a passport, a national identity number, a right-to-work document and bank details for payroll. Nobody in the victim's life has any reason to intervene, because everything they are being asked for is exactly what a genuine new employer would ask for. Monitoring for hostnames that combine your organisation's name with recruitment vocabulary, and checking each against the daily database, is how many employers find these sites before their applicants do. HR-tech vendors feel this one hardest, because the cloned brand is theirs as often as it is their customers'.
HR sends more links to more people than almost any other function, and every one of these message types teaches staff that a mail from HR pointing at an unfamiliar third-party hostname is normal:
That habit is precisely the one an attacker needs. Screening your own outbound links achieves two things: it catches the rare case where a vendor's domain has been compromised or a marketing subdomain has lapsed and been re-registered, and it leaves you with an accurate, current inventory of every external hostname the workforce has been told to trust. That inventory is itself a security artefact worth having.
# candidate-submitted links, screened as a batch on application receipt
$ curl -s -X POST https://phishingdetectionapi.com/api/v1/batch \
-H "Content-Type: application/json" \
-d '{"apikey":"YOUR_KEY",
"domains":["portfolio.candidate.example",
"careers-yourcompany.example",
"docs-onboarding.example"]}'
# a single hostname pulled out of a reply-to address
$ curl -s "https://phishingdetectionapi.com/api/v1/check\
?domain=careers-yourcompany.example&apikey=YOUR_KEY"
{"domain":"careers-yourcompany.example","is_phishing":true,
"category":"credential-harvesting","dns_status":"resolving",
"last_checked":"2026-07-26T04:08:51Z","confidence":"high",
"database_size":391204}Up to 100 hostnames per batch request, one lookup each, with typical responses under 50 ms. The key is used server-side from the ATS backend or the mail gateway — never from a page a candidate can load. Larger estates that would rather match locally can take the whole database as a daily CSV feed instead. Teams already running this at the mail layer will find the overlap described in phishing detection for email security.
Nobody is easier to phish than a person who has just joined, wants to make a good impression, and has no idea yet what normal looks like.
Every pre-start message travels to a private address with no corporate mail filtering, no security tooling and no colleague to ask. The new hire cannot tell your onboarding vendor's domain from a convincing imitation, because they have never seen either one before.
Passport scan, right-to-work evidence, national identity number, home address, emergency contact, bank details. It is the single richest bundle a person ever hands over, uploaded on trust, to a hostname they were told about in an email they cannot verify.
A welcome post names the person, the role and the employer. That is enough for an attacker to write a plausible message from a plausible manager about a plausible task, and to know that the recipient has been in the building for less than forty-eight hours.
A message from someone senior, apologetic and brief, asking for a small favour before a meeting. The new hire has no baseline for how that person writes, no sense of which requests are unusual, and a strong incentive to be responsive rather than sceptical.
New joiners genuinely do get their account details wrong, and genuinely do write in to fix them before the first payment. A fraudulent request in this window is indistinguishable from the real thing on its face — which is exactly why it must be verified by procedure rather than by judgement.
Whatever the first week taught them to click is what they will click in month six. An onboarding sequence that sends people to five unfamiliar external hostnames has trained a reflex that no later awareness session will fully undo.
The cheapest fix on this page: in the offer letter itself, list every hostname the new hire will legitimately be asked to visit during onboarding, and state plainly that HR will never send them anywhere else. A named list given before the first message arrives converts an unverifiable link into a verifiable one, and it costs a paragraph.
If you take one thing from this page, take the procedure — the technology exists to make the procedure cheaper, not to stand in for it.
Write it down and make it unconditional: no change to a bank account, tax code or payroll-affecting personal detail is applied on the strength of an email, a chat message or a ticket alone. Five clauses carry the whole procedure, and none of them cost anything:
Two of those clauses do most of the work. The first is the callback direction: an attacker can put any number in a message, so a call must go outward to a number you already had. The second is the confirmation to the old details, because it is the only step that still fires when everything else has been successfully impersonated. If you implement only those two, you have removed most of the value from payroll diversion, and you have done it without buying anything.
Worth being blunt about: a domain blocklist has never once stopped a payroll diversion that arrived as plain text with no link in it — and a great many of them do. What the blocklist removes is the front half of the attack, the credential harvest that made the request look internal in the first place. Treat it as narrowing the funnel, not closing it.
When a request touching payment details arrives, extract the sender's domain and any hostnames in the body and check them. The result is read asymmetrically, and the runbook should say so in exactly these words:
Staff defer to it. The screening result becomes the answer rather than an input, callbacks get skipped on anything that came back clean, and the procedure erodes quietly over a few months without anyone deciding to abandon it. Then something arrives as plain text from a compromised genuine mailbox, the tool has nothing to say about it, and the control that would have caught it has not been run in weeks.
Staff use both, because the two are doing visibly different jobs: the lookup removes a handful of cases before they reach a human, and the callback decides every case that does. That framing matters more than any configuration choice on this page, and it pairs naturally with the way security awareness programmes and service-desk verification are run in organisations that handle this well.
Every predictable HR event is a window in which an unusual request stops looking unusual.
The HR year is unusually legible from outside. An attacker does not need inside knowledge to time a campaign; they need a calendar, and yours is largely published:
The timing does the persuasion, because a request that would prompt a raised eyebrow in a quiet month is entirely expected in the week everybody is chasing the same paperwork. The practical response is not more vigilance, which does not survive a busy fortnight. It is to decide in advance which controls tighten during which window, and to say so before the window opens: what gets verified, what gets refused outright by policy rather than judgement, and which hostnames staff should expect to see. Publishing the legitimate hostnames ahead of an enrolment period is worth more than any number of reminders to be careful, because it gives people something concrete to compare against.
Year-end tax statements. Bulk requests for employee tax forms and identity numbers cluster around statutory deadlines, usually impersonating an executive, an auditor or a tax adviser. Make the answer structural rather than situational: payroll data leaves the department only through an established channel, never as an attachment in response to a request, no matter who appears to be asking.
Open enrolment. A defined window, external carrier portals, unfamiliar branding and a deadline — the ideal conditions for a benefits-portal clone aimed at employees rather than at HR. Send the carrier hostnames on the first day of the window, in the same message as the deadline, and tell people that any other address is wrong.
Volume hiring and campus season. Application volume rises, review time per candidate falls, and the ratio of unknown senders to known ones spikes. This is when automated screening of candidate-submitted links earns its keep, precisely because the human attention that would normally catch something has been spread thinner.
Offboarding and final payments. A leaver has already lost corporate mail access, which makes a message from a personal address about a final payslip or outstanding expenses perfectly plausible. Set the rule now: final-payment details are confirmed before the last working day, through the verification procedure, and never renegotiated by mail afterwards.
Worth reading before anyone writes "phishing protection" into an HR data-protection document.
A known-bad domain list is a floor under the link-based half of the problem and makes no claim about the rest. The honest way to present it internally is a two-column view: what the lookup sees, and what has to cover the gap when it does not.
| The attack as it actually arrives | Does the domain lookup see it? | What has to cover it instead |
|---|---|---|
| Payroll diversion in plain text, from a compromised but entirely genuine employee mailbox | No. There is no URL, no attachment and no look-alike domain — nothing for a domain lookup to examine. This is not a corner case; it is one of the most common shapes the fraud takes. | The verification procedure, entirely. The outbound callback and the confirmation to on-file details are the only things standing between this message and a redirected salary. |
| A hostname registered this morning and used this afternoon | Not yet. Every entry has been observed and confirmed to be resolving, which is what makes a hit trustworthy — and also what delays a brand-new domain's arrival in the build. | Published hostname lists sent before the window opens, plus the procedure. Targeted campaigns using a handful of fresh domains are exactly where a known-bad list is weakest, and exactly what HR faces during enrolment and hiring waves. |
| A compromised page on an otherwise legitimate corporate site | No. The lookup answers about hostnames, and this hostname is not phishing infrastructure. | Mail-layer content inspection and the habit of reaching vendor portals from a bookmark rather than from a link in a message. |
| A display name reading like your chief executive over a free-mail address | No. There is no malicious domain involved at all. | Mail authentication, external-sender marking, and a standing rule that payroll data never leaves the department in reply to a request. |
| Whether a document is genuine, a candidate is real, or a request is authorised | No. These were never questions about a hostname. | Human judgement supported by procedure — right-to-work checks, identity verification and the separation between who verifies and who applies a change. |
| A hostname already confirmed as live phishing infrastructure | Yes, in well under 50 ms, with a date attached that can be recorded on the case. | Nothing else has to. This is the one column where the lookup is the cheapest control available to you. |
And it is not a compliance control by itself. It is a technical measure that can reasonably be described as part of how you protect employee personal data — alongside access control, least privilege on the HRIS, multi-factor authentication for administrators, retention limits on identity-document scans, and the verification procedure. Describing a domain lookup as adequate protection for employee data on its own would be a claim you could not defend, and it is not one we would make for you.
Including the ones a sceptical HR director asks in the second meeting.
Coverage of everything that never travels through mail, and a different kind of answer. Three routes bypass the gateway entirely:
Design the workflow so a flag never rejects anyone — it annotates the link, not the application. Three properties keep it that way:
The request contains a hostname and an API key. It does not contain the message, the sender, the employee, the candidate or any personal data, so the lookup itself is not a transfer of employee information — and if you would rather not send hostnames off your network at all, take the whole database as a daily CSV and match locally, so nothing leaves at query time. On your side, keep the record deliberately thin:
Two places, and both are backend work rather than product surface:
Much less than teams expect, because HR link volume is small. A department screening every candidate-submitted URL, every outbound campaign link and every hostname appearing in a payroll-change request rarely exceeds a few thousand lookups a month:
Partly, and it is worth being precise about the limit. You can take candidate hostname patterns — your brand combined with words like careers, jobs, hiring, recruitment or onboarding — and check them against the database, which will tell you which of those are already confirmed live phishing infrastructure. Two boundaries come with that:
Yes, because the parts that matter most cost nothing to implement. A three-person team can do all four of these in an afternoon, and together they remove most of the value from the attacks on this page:
The database is rebuilt every 24 hours, with a changelog recording what was added and removed in each build. Every entry is verified as resolving in DNS at build time, and entries that stop resolving are removed rather than retained, so the size figure reflects live infrastructure rather than accumulated history. Two things to wire into your monitoring:
Screen candidate links in the ATS, hostnames in payroll-change requests and the addresses your own campaigns point at — against a database rebuilt every 24 hours from domains verified as currently resolving. Credit packages start at Growth at $99/month for 25,000 lookups and stay billed monthly.
