Pay Day Piracy: How Attackers Talk Their Way Into Your Payroll System

The help desk is the soft underbelly of many organizations, a theme we explored in our post on how attackers compromise the IT help desk and one that security teams keep confirming, because help desk identity verification can still depend heavily on human judgment, particularly when agents face high request volumes and convincing impersonators. Social engineering such as help desk impersonation led to average breach costs of $5.23 million, and the FBI has long tracked payroll diversion as a variant of business email compromise, a category that reached $3.05 billion in reported losses in 2025. 

Microsoft documented related payroll diversion campaigns involving Storm-2657 and Storm-2755, demonstrating how attackers can exploit compromised accounts to manipulate payroll workflows. Both campaigns involved inbox rules that concealed payroll-related communications and the redirection of salary payments, although their initial access methods differed. In the Storm-2657 campaign specifically, attackers also enrolled their own phone numbers as MFA methods and used 11 compromised accounts at three universities to send phishing emails to nearly 6,000 accounts across 25 universities.

How the ATT&CK Unfolds

Microsoft's campaigns began with adversary-in-the-middle phishing, and the same playbook is reachable through a phone call, which maps to ATT&CK as follows:

1. Initial access through voice social engineering (T1566.004, Spearphishing Voice). The attacker impersonates the account owner to the help desk and leaves with a temporary password and deactivated phone factors, which removes the second factor without a single phishing email.

2. Valid account abuse (T1078.004, Cloud Accounts). The attacker signs in to the identity provider from a residential IP using only the password, and because the credentials are genuine, the login appears authorized.

3. Persistence and stealth (T1098.005, Device Registration; T1564.008, Email Hiding Rules). An attacker-controlled phone is enrolled as an MFA factor and a mailbox rule deletes payroll messages, so the employee never sees what changed.

4. Impact (T1657, Financial Theft). The attacker changes the employee's direct deposit details in the HR system to redirect future salary payments to an attacker-controlled account.

Each step surfaces in a different system, with the reset in Entra, the sign-in and enrollment in Okta, the mail rule in Exchange Online, and the payment change in the HR platform, so no single security tool is able to visualize the entire attack chain.

How Abnormal ITP detects each stage

Identity Threat Protection scores every event against the behavioral baseline of the specific user and organization, using signals from email, the identity provider, and SaaS applications, while the Threat Library shows each organization where it is exposed, including the users in the most targeted roles and posture gaps such as accounts bypassing MFA. In the case of help desk social engineering leading to a payroll redirect, ITP could detect a multi-platform attack as follows:

1. Help desk reset: a service-desk MFA reset with no out-of-band callback verification, which Abnormal reads from Microsoft audit activity and evaluates against what is normal for that identity.

2. Sign-in: a password-only Okta sign-in from a first-ever location, with a new device fingerprint and a residential or mobile ISP the account has never used.

3. Persistence: an Okta audit log event showing a new SMS factor enrolled eight minutes after the novel-IP sign-in, a sequence highly unusual for a legitimate user.

4. Evasion and impact: a mailbox filter that deletes messages mentioning direct deposit or payment method, followed by a payment method change in the HR platform during the same session.

No single signal is conclusive, but once the payment change correlates with the novel-IP session and the freshly enrolled MFA factor, the case moves from medium to high confidence, and the summary presents the collection of signals as a contextual determination of an attack.

Remediation and clean-up

Containment has to match the footprint of the attack, so the remediation workflow covers both identity providers and the changes the attacker left behind, with a review step before any action runs:

• Account containment: revoke active sessions, disable the account, and force a password reset in Microsoft 365, alongside session revocation and account disablement in Okta, since ending Entra ID tokens leaves Okta sessions intact.

• Malicious mailbox rules: removal of rules created during the incident window, which stops further suppression of payroll notification emails.

• Attacker MFA devices: removal of MFA methods registered during the incident window, which closes the persistence path that would otherwise survive a password reset.

These steps mirror the cleanup Microsoft recommends for payroll pirate incidents, and running them in one workflow means the attacker loses the session and the foothold together. To see how Identity Threat Protection correlates email, identity, and SaaS signals in your environment, request a demo.

Request a Demo