Skip to main content

Advisory: Phished Sign-Ins Used to Hijack Workday Payroll Sessions

Support
Support
Fluency Support

Fluency investigated a compromise at one customer. An attacker captured an employee's password and a one-time MFA code, signed in to Workday through Microsoft single sign-on, and held the Workday session open for about nine hours with an automated script. The session kept working for 83 minutes after the employee's password was reset and their Microsoft sessions were revoked.

The way in resembles the published "payroll pirate" campaigns, in which attackers change an employee's direct-deposit details so the next paycheck goes to an account they control. Here no bank or payment change was made before the session ended, but the attacker did view the employee's tax documents, date of birth, salary and contact details. Any Microsoft Entra ID tenant that signs users in to Workday or another HR or payroll app through SSO is exposed in the same way. Fluency swept every customer tenant and found no other customer affected.

On November 10, 2026, Fluency released a detection to every instance for the step that let this attack through: a user who signs in with a passkey completing a sign-in with a password and a weaker MFA method from a new network. No action is needed to turn it on.

What you should do now

Require phishing-resistant MFA for Workday and every payroll or banking-detail app. When an account is compromised, end the user's sessions inside every SSO application, not only in Entra ID: revoking Microsoft sessions does not sign the user out of Workday.

AdvisoryFSA-2026-11-01
SeverityHigh
PublishedNovember 9, 2026
UpdatedNovember 10, 2026: detection released
AffectsMicrosoft Entra ID tenants that use SSO to Workday or other HR and payroll apps
SharingTLP:CLEAR, may be shared freely. Details of the affected customer are withheld.

How the attack worked​

  1. Phishing captured the password and the code. The employee normally signed in with a passkey. The phishing page relayed their password and an authenticator one-time code to Microsoft in real time (adversary-in-the-middle). A passkey cannot be relayed this way, so the page led the employee to "use another method".
  2. The sign-in came from a hosting provider. It came from a data-center IP address in Virginia, on a device Microsoft had never seen. Entra ID rated it high risk, but the one-time code satisfied the MFA requirement, so the sign-in was allowed.
  3. Straight to Workday. Within 5 seconds of signing in, the attacker opened the employee's tax documents, date of birth, compensation and contact information, and started the Change My Personal Information task. No email, files or other apps were touched.
  4. A scripted keep-alive. The session then repeated a search and a personal-information edit about every 3 minutes, all night, so that Workday would not time it out.
  5. It outlived the Microsoft containment. Resetting the password and revoking the user's Entra ID sessions did not end the Workday session, which already existed. It kept running for 83 more minutes.

The Workday user activity log was the only record of what the attacker did in Workday, and of the session still running after containment.

Why common defenses did not stop it​

  • The passkey was available but not required. If a user can also sign in with a one-time code, a push or SMS, a phishing page can steer them to that method instead.
  • "Any MFA" was accepted for a high-risk sign-in. A relayed code counts as completing MFA, and Entra ID then marks the risk as remediated.
  • Revoking Microsoft sessions does not sign the user out of SaaS apps. Workday, Salesforce and other SSO apps keep their own sessions until those sessions expire or are ended inside the app.

What we recommend​

  1. Require phishing-resistant sign-in for HR and payroll apps. In Entra ID Conditional Access, apply the Phishing-resistant MFA authentication strength to Workday and to any payroll or banking-detail app. Users who already have a passkey or Windows Hello see no change.
  2. Block high-risk sign-ins instead of accepting any MFA. Set high sign-in risk to block, or to require phishing-resistant strength, at least for HR, finance and administrator accounts.
  3. Remove weaker methods where a passkey exists. Restrict one-time codes, SMS and voice for users who have registered a passkey, starting with HR, payroll, finance and administrators.
  4. Add checks inside Workday.
    • Require re-authentication for Manage Payment Elections.
    • Notify the employee's personal email when bank details change.
    • Hold or verify payment-election changes made shortly before a payroll run.
    • Review the session timeout and the maximum session length.
  5. Update your incident steps. When an account is compromised, end the user's sessions inside every SSO application, not only in Entra ID, and check each application's own audit log for activity after you contain the account.
  6. Send your Workday audit log to Fluency. Fluency collects the Workday user activity log: which account ran which task, against which object, from which address and session. See Workday for the setup. Workday keeps the log for a limited time, so collect it before you need it.

How to check your environment​

  • Successful sign-ins to Workday or payroll apps from hosting or data-center networks, especially from devices that are not registered.
  • Users who normally sign in with a passkey or Windows Hello who suddenly completed MFA with a one-time code, a push or SMS. For passkey, security-key and certificate users, Fluency alerts on this from November 10, 2026 (What Fluency is doing).
  • In Workday: views of tax documents, date of birth or compensation within seconds of sign-in; repeated Change My Personal Information events at a steady interval; any Manage Payment Elections change from an unfamiliar IP address.
  • Workday sessions that continue after the user's password was reset.

The sign-in checks read the Entra ID sign-in logs, collected by Entra ID Audit via Event Hubs or Microsoft Graph; the Workday checks read the Workday user activity log. Fluency customers can ask their analyst to run these checks.

Also seen across customers: password spraying​

During the follow-up hunt, Fluency saw a password-spray campaign against many Microsoft 365 tenants. It sends password-only sign-ins through the Azure Active Directory PowerShell app with an axios/1.x user agent, mostly from addresses in Morocco, Turkey and a few hosting providers. Every attempt we checked failed. In one tenant, though, the attacker guessed the correct password of an administrator account that had no MFA method registered, and only the MFA registration prompt stopped the sign-in.

  • Find accounts with no MFA method registered, especially administrator and break-glass accounts, and fix them.
  • Block legacy and password-only (ROPC) sign-ins where you can.
  • Treat error 50072 (MFA registration required), 50074 or 50076 (MFA required) on an account that is being sprayed as "the password is known", and rotate the password.

For the low-and-slow spray Fluency reported on November 1, and the detections released for it, see the Microsoft 365 password spray advisory.

Indicators​

TypeValueNotes
IP address104.145.236.30The sign-in and the Workday session in this incident.
NetworkAS64245, DigitalFyre Internet Solutions, Ashburn, VAHosting provider.
BehaviorWorkday-only sign-in; a one-time code from a passkey user; a personal-information edit every 3 minutesMore reliable than the IP address, which attackers rotate.

We found no other Fluency customer with activity from this infrastructure.

What Fluency is doing​

  • Swept every customer tenant for the indicators in this advisory and in the public reporting below. No other customer was affected.
  • Released a detection on November 10, 2026. EntraID_MFA_Downgrade alerts, at high severity, when a user who normally signs in with a passkey, a security key or a certificate completes a sign-in with a password and a weaker method (a one-time code, a push, a text message or a phone call) from a network they have never used the passkey from, on a device that is not their compliant one. This is the step that let this attack through. It also alerts on a password and weaker MFA from a browser that claims to be Safari on Windows, a disguise phishing kits use to hide the passkey option. The rule reached every instance that collects Entra ID sign-in logs, with nothing to turn on; the passkey comparison learns each user's networks for seven days before it alerts, and the Safari-on-Windows check alerts now. Treat an alert as a stolen session: revoke the user's sessions, reset the password, and check for MFA methods added since. The match conditions and triage steps are in the release notes, and the coverage is described in Attack Coverage.
  • Still developing detections for Workday sign-ins from hosting networks and for automated Workday session activity.
  • Reported our findings and recovery steps to the affected customer.

Questions, or a check of your tenant: contact your Fluency SOC team, or raise a support ticket.

References​

Splash Summary

An attacker phished an employee's password and one-time MFA code, signed in to Workday through Microsoft single sign-on from a hosting provider, viewed the employee's tax, salary and personal details, and kept the session alive with a script for about nine hours. The Workday session ran on for 83 minutes after the password was reset and the user's Microsoft sessions were revoked.

Require phishing-resistant MFA for Workday and every payroll app, and when an account is compromised, end its sessions inside every SSO application, not only in Entra ID. Fluency swept every customer tenant and found no other customer affected.

Updated November 10, 2026: a new detection, on every instance, alerts when a passkey user signs in with a password and a weaker MFA method from a new network.