Payroll diversion: when the session is stolen, the HR portal cannot tell

An employee's entire monthly income can be redirected by editing one field in a self-service portal, and the FBI has warned about this pattern for years. What changed is that the attacker no longer needs to phish the employee — they buy the session.

Part of Payment release authorization

Prerequisites

• Export of direct deposit changes from your HRIS for the last twelve months, with timestamp and initiating session.
• Your payroll calendar — specifically the cutoff date relative to payroll run.
• Whether your HRIS notifies on direct deposit change, to which address, and whether that address is also editable in self-service.

Step 1 — Map the window

The exposure is the interval between a change taking effect and someone noticing. Compute it from your own calendar.

change made        →  day 0
payroll cutoff     →  day 3    (change is picked up)
payroll run        →  day 10
pay date           →  day 15
employee notices   →  day 15-17  (pay did not arrive)

exposure window = 15-17 days, one full pay cycle

An attacker who times the change just before cutoff maximises the window and gets one full cycle. In organisations paying semi-monthly the window is shorter; monthly payrolls are the worst case.

Step 2 — Understand why detection fails here

The relevant advisories describe two variants. In the older one, the employee is phished and the attacker logs in with harvested credentials. In the current one, the attacker replays a session token taken by infostealer malware from the employee's device.

The second defeats the detection stack completely.

There is no signal to detect, which is why detection-based controls have not moved this loss category despite years of advisories.

Step 3 — Check your notification path

Most HRIS platforms notify the employee when direct deposit details change. Verify two things:

1. Where the notification goes. If it goes to the work email and the attacker holds the SSO session, they likely hold the mailbox too.
2. Whether the notification address is itself editable in self-service. If an attacker can change the email and then the bank details in one session, notification is worthless.

Sending to a personal address on file, and prohibiting self-service edits to the notification address, costs nothing and closes the most common bypass.

Step 4 — Gate the field

One field, one gesture. The employee signs a canonical statement rendering the full new account and routing details before the change takes effect.

{
  "type": "manav-stmt/1",
  "action": "direct_deposit_change",
  "render": [
    "Employee: [name, id]",
    "Current: [bank] — [full account] — [full routing]",
    "New:     [bank] — [full account] — [full routing]",
    "Allocation: [percentage or amount]",
    "Effective: [first affected pay date]"
  ],
  "employee": "[credential assertion, user verification required]"
}

The session does not matter. The attacker holding it cannot produce an assertion from a credential on the employee's device.

Step 5 — Handle the exception path

Employees lose phones, change devices, and join without one. The HR service desk must be able to process a change, and that path is where an attacker will go next.

• Require the exception to be performed by a named HR representative signing an exception statement, not by any service desk agent.
• Apply a hold across at least one pay cycle boundary.
• Notify the previous account's associated address and the employee's personal address.
• Report the exception rate monthly. A concentration by representative or by region is the signal.

Failure traps

1. Gating login instead of the field. The session is already past login.
2. Allowing the notification address to be changed in the same session as the bank details.
3. Applying the gate to all HRIS profile edits, which produces resistance disproportionate to the benefit. One field.
4. Forgetting contractors and contingent workers paid through the same system, who frequently sit outside the SSO population entirely.

Why this endpoint specifically

The remedy is not a better anomaly model. It is treating the deposit account as what it is — a payment instruction — and requiring a fresh, bound assertion to change it, plus a notification to a channel the session cannot reach.

Objections and honest limits

“We require MFA on the HR portal.” At login. The stolen session is post-login, which is exactly the gap. Step-up on the change endpoint is the control; MFA at sign-in is not.

“We email a confirmation of the change.” To an inbox the same session can usually reach. Send it out of band, and make the notification say what changed rather than that something changed.

Hardening the deposit change

1. Classify the deposit field as a payment instruction. Not profile data. Everything else follows from that.
2. Require a fresh bound assertion to change it. Rendering the old and new account, with user verification.
3. Notify out of band, stating the change. To a channel the session cannot reach.
4. Hold the first pay run after a change. A short hold costs the employee little and removes the attacker's window.

Terms used here

Infostealer

Commodity malware that harvests credentials and session material from a host. Stolen sessions trade in bulk at low prices.

Session replay

Using a stolen session token to act as the user without authenticating.

Step-up

Requiring a fresh assertion at a specific action rather than relying on the session that opened earlier.

Frequently asked questions

Would MFA on the HRIS fix this? It helps against credential phishing and does nothing against a replayed session, because no authentication event occurs.

Why only the direct deposit field? Because that is where the money moves. Gating every profile edit generates friction and resistance without proportionate benefit.

What about employees without smartphones? The exception path exists for them, with a named HR signer, a hold across a pay cycle and dual notification. It must be staffed rather than improvised.

Does this apply to contractors? If they are paid through the same system, yes — and they are frequently outside the SSO population, which means the gate has to be designed for them explicitly.

Why doesn't MFA stop payroll diversion? MFA runs at login. A stolen session is post-login, so no authentication event occurs and nothing is prompted.

Why is detection so slow? The change looks routine and the consequence only appears at the next pay run — potentially a full cycle later.

What is the single best change? Treat the deposit account as a payment instruction and require a fresh, bound assertion to alter it.

Sources and further reading

• IRS Newsroom — payroll and W-2 phishing warnings
• CISA — protecting against session hijacking and infostealers