Monitoring for account takeover with the Splunk App for Fraud Analytics

Last updated
Save as PDF
Share
1. Share
2. Tweet
3. Share

If you have not already installed the Splunk App for Fraud Analytics, complete the steps in the deployment guide and then come back to this article.

The information in this article applies to Splunk Enterprise Security (ES) versions 7.x. If you have upgraded to Splunk Enterprise Security version 8.x, some terminology and steps might not apply. For additional assistance on this use case with ES 8.x, Splunk Professional Services can help.

Analysts need to be able to identify when a legitimate customer account is taken over by a malicious actor with the intent to commit fraud. The Splunk App for Fraud Analytics ships with out-of-the-box use cases that address both new account and account takeover fraud, along with limited support for some additional fraud use cases. This process will address how to detect the account takeover fraud use case within the out-of-the-box constraints of the application.

Identify the risk rules applicable to account takeover fraud

After performing the initial configuration of the Splunk App for Fraud Analytics, as described in the deployment guide, navigate to Enterprise Security > Configure > Content Management.
Filter on the following:
- Type: Correlation Search
- App: Fraud Analytics for Splunk
- Filter: 'RR-Fraud --'
The following results should appear:
Examine the SPL for each of the applicable searches to determine data source requirements. Currently, all detections applicable to account takeover fraud require data from the fraud_web data model. If you add new detections that require another data type, this should be noted for future steps.

Review and prepare data for compliance with the `fraud_web` data model

The fraud_web data model focuses on account activity such as login/logout, payment and trading activity, or profile changes, and allows analysts to search for and detect potentially fraudulent account behavior. The data could be in the form of web or other application-like data, but focuses on data fields rather than specific data types. So, theoretically, both the fraud_account and fraud_web data models could leverage the same source type. The difference is how they focus different lenses on this data through specific fields within the data models.

Review the applicable data fields for the fraud_web data model by navigating to Settings > Data Models > fraud_account. The fraud_account data model applicable fields can be seen in the table in Splunk Docs.

While the above fields are all of the fields available to you through the fraud_web data model, similar to how most Splunk Enterprise Security detections work, you won't need to normalize to every single field. You only need to normalize to the fields applicable to the account takeover risk rules described in the previous step. Following are the fields required for successful implementation of the account takeover risk rules described in the previous step.

Fields required for risk rule implementation

Risk Rule	Required Fields	Combined Required Fields
RR-Fraud -- Brute force attack on user	`logged_in` `username_tried` `src_ip`	`action` `Country` `ip_subnet_16s` `languages` `logged_in` `Region` `session_id` `src_ip` `username` `usernames` `username_tried`
RR-Fraud -- Country of login doesn't match browser language	`Country` `languages` `usernames` `session_id`
RR-Fraud -- Excessive Logins - group behavior	`username` `usernames`
RR-Fraud -- IP hitting multiple user accounts	`username_tried` `src_ip`
RR-Fraud -- Significant edit user profile followed by quick money movement	`action` `session_id` `usernames`
RR-Fraud -- Successful logins from different regions	`Country` `Region` `ip_subnet_16s` `username`
RR-Fraud -- Successful logins from multiple ip addresses	`logged_in` `ip_subnet_16` `src_ip` `username` `username_tried`
RR-Fraud -- Suspicious attempts to login to high value accounts	`username_tried` `username` `src_ip`

Fields required for dashboard implementation

Dashboard	Panel	Required Fields	Combined Required Fields
Financial Fraud > Web Traffic Analysis
	Combined timechart of all events	`_time`	`_time` `action` `src_ip` `Country` `Region` `City` `username_ex` `username_tried` `logged_in` `accept_language` `http_user_agent` `http_method` `risk_exposure` `risk_exposure_r` `screen` `screens` `session_id` `status` `uri` `uri_path`
	Selected events	`_time`
	Multi-field investigative panel (all views)	`bytes_in` `Country` `Region` `src_ip` `username_tried` `logged_in` `accept_language` `http_method` `status` `http_user_agent` `uri_path`
	Detailed web traffic activity	`_time` `src_ip` `Country` `Region` `City` `username_tried` `logged_in` `accept_language` `http_user_agent` `http_method` `status` `uri_path`
Financial Fraud > Fraud Risk Exposure Analysis
	Money Movement Events	`action`
	Interactive investigation: User accounts and risk analysis (Countries)	`src_ip` `username_ex` `Country`
	Interactive investigation: User accounts and risk analysis (Usernames)	`risk_exposure` `src_ip` `username_ex`
	Interactive investigation: User accounts and risk analysis (IP Addresses)	`username_ex` `http_user_agent` `risk_exposure` `Country`
	Interactive investigation: User accounts and risk analysis (Screen Info)	`username_ex` `risk_exposure` `screens`
	Interactive investigation: User accounts and risk analysis (Session ID)	`risk_exposure` `session_id`
	Interactive investigation: User accounts and risk analysis (User Agent)	`risk_exposure` `http_user_agent`
	Interactive investigation: User accounts and risk analysis (Risk Level)	`username_ex` `risk_exposure_r`
	Interactive investigation: User accounts and risk analysis (Actions)	`action`
	Detailed portal activity	`_time` `src_ip` `Country` `Region` `City` `session_id` `username_ex` `screen` `http_method` `status` `action` `uri` `risk_exposure` `http_user_agent`

Identify the fields within the applicable dataset, and normalize those to the fraud_web data model.
If you need to adjust out-of-the-box risk rules based on your unique requirements, keep note of any additional fields that need to be normalized to the fraud_web data model and incorporated into the detection.

Enable the risk rules and risk notable applicable to account takeover fraud

Enable the Risk Rules identified in the first step in this process by navigating to Enterprise Security > Configure > Content Management, and first filtering for the new account fraud risk rules.
- Type: Correlation Search
- App: Fraud Analytics for Splunk
- Filter: 'RR-Fraud --'
Enable all of these rules through the Content Management user interface.
Enable the following Risk Notables:
- Notable-Fraud -- Possible Account Takeover Attack
- Risk Threshold Exceeded for User - all channels

Next steps

If you want more step-by-step guidance about how to implement this use case by walking through a sample scenario, see the Multichannel fraud detection article.

After you have implemented this account takeover use case, you might be interested in other ways to protect your financial services organization and its customers. Return to the fraud detection and prevention deployment guide for instructions on implementing additional use cases.

Finally, if you would like more hands-on assistance with this or any other fraud detection and protection use case, Splunk Professional Services can help. Find more information here or reach out directly to sales.