Payroll Fraud: Analyzing the Attack Lifecycle of a Direct Deposit Scam

Introduction

Business email compromise (BEC) is an email attack where an adversary targets business email in order to defraud a company and its employees, customers, or partners. According to the FBI Internet Crime Complaint Center (IC3), BEC resulted in an exposed dollar loss of $43 billion dollars between June 2016 and December 2021.

Multiple variants of business email compromise exist today. Examples include an adversary impersonating a company executive to social engineer an illicit financial transaction, or using phishing to install malware or steal company login credentials. While there are multiple tactics and techniques employed around BEC attacks, many result in the same outcome: payroll fraud.

This article will highlight different types of payroll fraud, provide deeper analysis into one particular type of payroll fraud attack, and provide guidance that can be used for threat hunting, building detections, and protecting your environment against this style of attack.

Payroll Fraud Overview

Payroll fraud involves the manipulation of payroll systems, or users of payroll systems, to facilitate an unauthorized transfer of company funds. Payroll fraud can be performed by external threat actors or malicious insiders. Types of payroll fraud include:

Timesheet fraud – An employee submitting a fraudulent number of hours worked, therefore causing the company to overpay.

Ghost employees – A nonexistent or former employee that exists in the payroll system and receives funds from the company.

Worker misclassification – An employee is misclassified in the payroll system so that the company avoids paying payroll taxes, health insurance premiums, or other benefits.

Pay rate alteration – An employee’s pay rate is fraudulently changed so they’re paid a higher amount.

W-2 fraud – Employee W-2 tax forms, which include sensitive employee PII, are stolen to be resold on the dark web or used to file fraudulent tax returns.

Direct deposit fraud – An employee’s direct deposit information is modified to redirect future payments to an unauthorized bank account.

This article is going to dive more deeply into direct deposit fraud, also known as a payroll diversion attack, and the tactics and techniques an adversary might utilize to successfully execute this attack.

Payroll Diversion Attack Lifecycle

The phases below outline the entire attack lifecycle of a payroll diversion attack.

In this example use case, we’ll focus on enterprise applications Microsoft 365 for email, Okta for single sign-on (SSO) and multi-factor authentication (MFA), and Workday for human resources and payroll. Demonstrating the use case using real-world business applications helps provide technical context to the attack and highlights audit log examples to guide threat hunting and detection engineering.

Phase 1: Initial Access

A payroll diversion attack typically begins with a user’s account compromise. The user’s credentials could have been compromised via malware, a brute force technique such as credential stuffing, or most frequently, phishing.

Multi-factor authentication (MFA) is a solid security control that minimizes the impact of compromised login credentials. However, MFA bypass methods exist and are leveraged by many adversaries. Such bypass methods can include MFA push notification fatigue, session hijacking, or using legacy authentication protocols that might be enabled.

In summary, a business user’s account has been compromised and the adversary has obtained a foothold into the target environment.

Phase 2: Discovery

During the next stage, the adversary’s objective is to orient themselves in the target environment, discover available resources, and determine the next move toward their final objective: payroll fraud.

For example, an adversary might search the compromised user’s Outlook inbox for emails relevant to Workday, Okta sign-on notifications, or other related business applications or information that might prove useful in understanding the target environment.

An adversary might also enumerate SSO applications through Okta, further probing their new-found access to discover additional resources. Leveraging the stolen account credentials, the adversary will eventually shift their focus to Workday to conduct the next phase of their attack.

Phase 3: Defense Evasion

A cautious adversary might also look to cover their tracks before advancing to their final objective. To hide their activity from the compromised user, an adversary might utilize the following evasion techniques:

• Creating an email inbox filtering rule that redirects messages from Workday, therefore hiding emails that might notify the user of changes to their Workday account or payment elections.
• Creating additional inbox filtering rules to ensure Okta notifications, emails from human resources, or any other emails that might alert of their presence are redirected and hidden from the user’s inbox.
• Disabling Workday mobile notifications to ensure the compromised user’s mobile device doesn’t receive any notifications via the Workday app.
• Changing the compromised user’s email address in Workday to an email address controlled by the adversary.
• Disabling other Workday notifications, such as business process notifications that might occur when payment elections are changed.

Phase 4: Impact / Action on Objectives

Lastly, the adversary is ready to execute the final phase of their attack and modify the user’s direct deposit settings.

Once authenticated into Workday, the adversary can browse the compromised user’s profile and locate their payment election settings. The adversary might elect to modify the list of available bank accounts, or modify the payment election settings directly. This can happen by adding a bank account they control, such as a prepaid credit card, and updating the user’s payment elections to redirect future payments to their account.

In conclusion, the adversary successfully actioned their objective by completing a payroll diversion attack. If the changes remain undetected, the adversary will soon be the recipient of an unauthorized payment of company funds.

Threat Hunting and Detection

Now that a typical payroll diversion attack has been outlined, let’s evaluate each phase and identify the different signals that are available in audit logs to support threat hunting and building detection logic.

It should be noted that each environment is different, and therefore a threat hunting hypothesis may return high quality results in one environment but produce a high volume of benign events in another. Each user’s unique pattern of activity is also different, so their historical baseline of activity should also be analyzed to provide a broader context of their normal activity. Lastly, many of the hunt and detection ideas outlined below require proper tuning to ensure trusted, expected activity is filtered.

Phase 1: Initial Access

The above attack began when a user’s login credentials were compromised. To search for compromised user accounts, let’s begin analyzing basic observables and looking for anomalies.

Basic Observables

In general, defenders can hunt for login attempts with unusual or suspicious characteristics. For example, unusual geo-locations or ISPs, or a high volume of login failures targeting specific users. Similarly, defenders can hunt for successful login activity from unauthorized VPN networks, anonymizing services, or unusual hosting services, such as those offering free or cheap server resources.

Credential stuffing is a common brute force technique where an adversary uses passwords obtained from a data breach to compromise user accounts. An effective method to detect credential stuffing includes searching through authentication logs for the following sequence of events:

• A spike in failed authentication events from the same IP address for multiple distinct user accounts.
• While pivoting on the source IP address, correlate these events with a successful login event from the same IP address.
• Trusted source IP networks should be filtered, and threshold values for authentication attempts and distinct usernames should be tailored to the target environment.

A few basic questions to consider when searching authentication logs and hunting for suspicious activities:

• Are authentication audit logs collected from all critical applications and services?
• Do authentication logs contain context such as success, failure, and failure reason?
• Where do users typically authenticate from?
• Do the logs contain context regarding MFA status?

Okta Use Cases

In environments that use Okta for Identity and Access Management (IAM), the following event types are useful for monitoring authentication activity:

• user.session.start – Generated when Okta initiates a new session for a user who is authenticating.
• user.authentication.auth* – Covers multiple types of Okta authentication events including MFA, Active Directory, Radius, and 3rd party identity providers (IDPs).
• user.authentication.sso – Generated when a user attempts SSO to an application managed in Okta.

When hunting for suspicious activity in Okta authentication events, we recommend focusing on the following use cases:

• Using the Okta event fields outcome.result and outcome.reason to identify failures relating to authentication and MFA activity.
• Pivoting on the Okta event field debugContext.debugData.logOnlySecurityData that surfaces a risk score via the risk.level field, as well as interesting behavioral context such as New Geo-Location, New IP, New Device, etc.
• In isolation these events can often be high volume or benign, but when correlated with other activities or anomalous events, can be quite powerful indicators of compromise.

Another interesting detection opportunity is to hunt for Okta session hijacking attacks. In other words, a user’s legitimate Okta session has been hijacked by an adversary. For example, a pass-the-cookie attack can be used to bypass MFA and obtain SSO access to applications using the same security context as the compromised user.

Defenders can search for the following sequence of events to detect Okta session hijacking attacks:

• Using the Okta event field authenticationContext.externalSessionId, which represents a user’s unique session ID, defenders can correlate events together or create a timeline of events that occurred during a user’s session.
• By pivoting on the session ID, defenders can search for user sessions that contain multiple unique IP addresses, user agents, or autonomous system numbers (ASNs). A user session with multiple anomalous network characteristics might indicate their session has been hijacked and the adversary has an active foothold via the same session ID.
• As mentioned above, tuning is required to ensure the highest fidelity events are returned for your environment. For example, filter by event characteristics that are expected in your environment, such as MFA verification events involving a user’s mobile device.

Recommended further reading specific to Okta authentication events and detecting suspicious activities include Suspicious Activity Report and Queries for Attempted Account Takeover from Okta.

MFA Bypass Use Cases

In addition to hunting for Okta session hijacking attacks, defenders can also search for signals commonly found in other MFA bypass techniques.

In an MFA push notification fatigue attack, an adversary continuously triggers MFA push notifications to a target user, hoping the user eventually approves an authentication request.

In Okta, defenders can hunt for the following events to detect this style of attack:

• Search for a high volume of failed events for event types user.authentication.auth_via_mfa, user.mfa.okta_verify, or user.mfa.okta_verify.deny_push
• While pivoting on the target user, correlate the failure events with a successful Okta authentication event, such as a successful user.session.start, user.authentication.auth_via_mfa, or user.mfa.okta_verify

Threat actors can also leverage legacy authentication protocols to bypass MFA. In Microsoft 365, this often involves utilizing IMAP, POP, or SMTP protocols to gain access to a user’s mailbox. These email protocols don’t support MFA and can provide a non MFA-enforced entry point for adversaries.

Defenders can search for legacy authentication activity in their environment by searching for successful Azure AD AzureActiveDirectoryStsLogon events with a user agent value of BAV2ROPC.

AppOmni’s Approach

AppOmni is uniquely positioned to detect many tactics and techniques commonly found during the initial access phase of an attack. By collecting authentication audit logs from each monitored service, AppOmni normalizes the events, enriches them with geolocation and threat intel context, and processes them through our detection correlation engine to monitor and alert on identified attack techniques. For example, AppOmni Threat Detection is able to:

• Detect brute force attacks such as Password Guessing, Password Spraying, and Credential Stuffing.
• Detect Impossible Travel scenarios, where a user authenticates from two geographically distant locations in a period of time which makes travel between the two locations physically impossible. This is also an effective method to detect session hijacking.
• Detect MFA-related attacks such MFA Push Fatigue, MFA Bypass, and unusual modifications to a user’s MFA enrollment.
• Detect when a user’s mailbox is enabled to support legacy protocols such as IMAP or POP.

Furthermore, via our Policy and Insight engines, AppOmni monitors a service’s security posture for multiple settings that can help prevent techniques commonly utilized during the initial access phase. For example, AppOmni can generate alerts when:

• Users are configured without MFA, or are utilizing a weak MFA factor such as SMS
• Microsoft 365 Azure security defaults aren’t enabled
• Legacy authentication protocols are enabled and not blocked
• Microsoft 365 conditional access policies are disabled
• Okta session timeout values exceed a recommended threshold

Phase 2: Discovery

Detecting reconnaissance activity can often be difficult, but we can hunt for suspicious patterns of users accessing, requesting access, or failing to access a usual number of resources in a short period of time.

The discovery phase also illustrates the importance of collecting user activity audit logs from all critical applications and services. Having visibility into when users create, read, update, or delete (CRUD) different resources can alert teams to anomalous activity. By collecting and centralizing audit logs, security teams can determine baseline user activity, perform long tail analysis, and identify spikes or patterns of unusual activity.

With regard to Okta, defenders can search for unusual spikes or occurrences of the following event types:

• app.generic.unauth_app_access_attempt – Generated when a user attempts to access an unauthorized SSO application.
• app.access_request.approver.deny – Generated when a user requests access to an application but was denied by an administrator-defined approver.
• app.access_request.deny – Generated when a user requests access to an application but was denied by an administrator-defined approver.
• app.access_request.request – Generated when a user requests access to an application.

AppOmni’s Approach

AppOmni collects, normalizes, enriches, and centralizes audit logs from a constantly expanding list of services. This enables AppOmni Threat Detection to continually monitor CRUD actions targeting resource types such as files, records, reports, applications, and system settings.

For example, with regards to Okta, AppOmni Threat Detection monitors when a user generates failed access errors on an unusual number of distinct SSO applications in a short period of time.

In addition to continuous monitoring of CRUD actions, AppOmni also monitors for add, change, and remove (ACR) actions on all IAM resources, such as user accounts, security groups, roles, and permission sets.

The AppOmni Insight and Policy engines help cover the discovery phase as well. For example, by monitoring for dormant, over-privileged accounts, or an excessive number of admin accounts, AppOmni can help reduce the attack surface of a monitored service. This helps reduce the risk should a user account become compromised, by helping to ensure the principle of least privileged is correctly implemented in your service.

Phase 3: Defense Evasion

Defenders can detect or hunt for suspicious inbox filters or forwarding rules by focusing on Exchange “Operations” such as: New-InboxRule, Set-InboxRule, UpdateInboxRules, and Set-Mailbox.

Each event contains informative context regarding the filtering criteria, the destination folder where email messages will redirect to, and whether a forwarding email address was also specified.

For example, the below audit log example illustrates an inbox filtering rule for Workday emails.

The below audit log illustrates an inbox forwarding rule that forwards email to a specified recipient.

In Workday, the “User Activity Log” provides an audit trail of all activities performed by users. Defenders can search for defense evasion techniques by pivoting on WRITE events specific to a user’s account or account preferences.

For example, the below sequence of Workday events illustrate a user who modified their work contact details, changed their primary email address, and then modified their user preferences (which contains granular settings specific to email and mobile notifications).

In threat hunting or building detection logic, defenders can look for the following indicators:

• Microsoft 365 email filters that are suspiciously named, contain certain keywords, or forward email messages to an external, non-corporate domain
• Multiple Workday user profile changes in a short period of time
• A Workday primary email change that involves an external, non-corporate domain

AppOmni’s Approach

AppOmni Threat Detection monitors Microsoft 365 audit logs for suspicious activity involving both email filters and forwarding rules. When a suspicious email rule has been created, a detection alert triggers and will populate the Threat Detection dashboard within your AppOmni tenant.

Additionally, our Insight and Policy engines monitor a service’s security posture for various techniques that might be used to evade detection, including:

• Monitoring when a user’s email address includes a non-corporate or suspicious domain
• Monitoring if important security controls are disabled, such as Workday’s Trusted Device or Security Email Notification features

Phase 4: Impact / Action on Objectives

Defenders can hunt for suspicious Workday direct deposit changes by analyzing the following audit log events:

A user adding a new bank account to their payment elections:

A user changing their payment elections:

A user updating their existing bank account:

Interestingly, these events slightly differ when a user modifies another user’s bank account or payment election settings. This difference is important if the compromised user has privileged access in Workday, and therefore is capable of modifying other user’s payroll settings.

In threat hunting or building detection logic, defenders might look for the following indicators:

• A bank account or payment election modification for an executive or VIP user
• A user who’s made multiple changes to their bank account or payment election settings in a short period of time
• A user modifying bank account or payment election settings for multiple distinct users in a short period of time
• A bank account or payment election modification correlated with another anomalous or suspicious event

AppOmni’s Approach

AppOmni Threat Detection maintains multiple detection rules specific to anomalous transfers or modifications involving bank accounts and payment elections, including:

• Users updating their payment elections or modifying other user’s payment elections
• Ad-hoc, one-time, or wire transfer payments to newly created, or recently modified, customer accounts

Conclusion

We hope this article helped you better understand the different types of payroll fraud that exist, and what the attack lifecycle of a payroll diversion attack might look like. We also hope the threat hunting and detection engineering guidance provides insight and context regarding possible attack techniques, and can be a valuable reference for your organization in detecting and preventing these types of attacks. If you’re interested in more detail about how AppOmni approaches these kinds of threats, as well as our different methods to continuously monitor and detect different risks that may be present in your applications, please get in touch.

---

Related Resources