Skip to main content
Lantern Home
 
 
Splunk Lantern

Monitoring for wire transfer fraud with the Splunk App for Fraud Analytics

  1. Last updated
  2. Save as PDF

 

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. If you are not a Splunk Enterprise Security customer or are unable to install the Splunk App for Fraud Analytics, we recommend using the Splunk platform version of this article instead.

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.

If you work in financial services, you potentially conduct thousands of wire transfers on a daily basis. These transfers are constantly at risk for many common scams, such as fake rental deposit requests, lottery winnings that supposedly require a "prepayment", and overpayments on bad checks. Monitoring for wire transfer fraud allows you to protect your customers from scammers, and as a result, protect the reputation of your business. The Splunk App for Fraud Analytics ships with out-of-the-box use cases that address various use cases within the financial services sector.

While the wire transfer fraud use case is not included out-of-the-box, the application does provide the necessary frameworks to implement and enable this use case. This process will address how to detect wire transfer fraud using the frameworks provided within Splunk Enterprise Security and the Splunk App for Fraud Analytics.

Review and prepare data for use within wire transfer fraud use case

The Splunk App for Fraud Analytics includes five data models that support numerous use cases. However, it does not include a data model for wire transfer activity. For scaling and code reuse purposes, we recommend leveraging data models, report acceleration, or summary indexing when searching across hundreds of GBs of events in a single search. Take this into consideration when deciding how to support this data source.

The required data sources for this use case include application data of wire transfer activity (could be web data, database, etc), and a custom lookup (csv or kvstore) of data on suspicious countries. The following procedure walks you through creating a data model (recommended) and preparing your data for use in the wire transfer fraud activity use case:

Create a data model

If you opt to use raw data (and not a data model) or summary indexing, skip this step.

  1. In the Splunk platform, navigate to Settings > Datamodels.
  2. Click New Datamodel.
  3. Create a data model following the instructions in the Splunk platform documentation.

Design your data model

If you opt to use raw data (and not a data model) or summary indexing, skip this step.

To meet the requirements of the recommended detections to support the wire transfer use case, you should include the following fields within your data model:

  • _time
  • c_time
  • OpenDate
  • action
  • clientIP
  • customer
  • amount
  • FromAccount
  • ToAccount
  • Country
  • City
  • destIP

In most cases, you should be able to build this data model with a single root object based on a single data source.

Build custom lookup of suspicious countries

  1. Create and upload your CSV lookup to the Splunk platform.
    1. The file should have the following two fields: country and is_suspicious.
    2. The Country field should contain the name of the country (only need to list countries the customer deems as suspicious).
    3. The is_suspicious field should contain a value of "Yes"
  2. Create a lookup definition and update permissions as necessary, so it is accessible by Splunk Enterprise Security.
  3. Create a managed lookup in Splunk Enterprise Security, and point it to the lookup definition you just created. For detailed steps on how to do this, see Create and manage lookups in Splunk Enterprise Security.

Prepare and configure risk rules and risk notables applicable to wire transfer fraud

The following content is recommended for detecting wire transfer fraud activity. Implement the following detections, and modify the search language to leverage your custom data model or summary index, if you are not searching directly against the raw data.

Search Name Rule Type Description Search
RR-Fraud-WT-Detect large wire transfer immediately after account activation Risk Rule Notable Customers open up accounts all the time. It would be unusual for a customer to open up a new account and shortly thereafter transfer a large amount of money. This could be an indicator of a fraudulent account. sourcetype=<wire transfer data source>
| eval _time=strptime(_time, "%Y/%m/%d %H:%M:%S")
| sort - _time
| where _time<relative_time(OpenDate, "+1d") and amount>10000
| eval AccountOpenDate=strftime(OpenDate, "%Y-%m-%d %H:%M:%S")
| iplocation destIP
| rename Country AS DestCountry City as DestCity
| table _time, AccountOpenDate, customer, amount, FromAccount, ToAccount, DestCountry, DestCity
| eval amount=tostring(round(amount, 2), "commas")
RR-Fraud-WT-Detect wire transfers into suspicious or banned countries Risk Rule Notable Large amounts of money being transferred into certain countries can indicate fraud. This will require correlating user activity with a list of banned and suspicious countries. sourcetype=<wire transfer data source>
| eval _time=strptime(_time, "%Y/%m/%d %H:%M:%S")
| sort - _time
| eval is_suspicious="no"
| lookup <name of lookup file of suspicious countries> ip AS destIP OUTPUT is_suspicious
| where is_suspicious="yes" AND amount>10000
| iplocation destIP
| rename Country AS destCountry
| table _time, customer, FromAccount, ToAccount, action, amount, destCountry, destIP
| eval amount=tostring(round(amount, 2),"commas")
RR-Fraud-WT-Detect wire transfers from multiple client IP addresses Risk Rule Notable In order to look for signs of compromise and help protect users, this will report on customers who transfer funds in a short amount of time using more than one client IP. This is unusual behavior and similar to the "superman" use case. sourcetype=<wire transfer data source>
| convert timeformat="%Y/%m/%d %H:%M:%S"
| sort - _time
| eval amount=tostring(round(amount, 2), "commas")
| streamstats time_window=1m count(eval(action="authorized")) AS authorized_count list(FromAccount) AS FromAccount list(ToAccount) AS ToAccount list(amount) AS amount list(action) AS action list(c_time) AS time values(clientIP) AS clientIP dc(clientIP) AS clientIP_count BY customer
| where clientIP_count>=2
| fields - OpenDate epoch destIP _time, clientIP_count c_time authorized_count
RR-Fraud-WT-Detect when a number of wire transfers exceeds threshold Risk Rule Notable This detection looks for clients that have completed a number of large wire transfers over a one hour time span. This might be an indicator of fraud. sourcetype=<wire transfer data source>
| sort - _time
| eval amount=tostring(round(amount, 2), "commas")
| streamstats time_window=1h count(eval(action="authorized")) AS authorized_count list(FromAccount) AS FromAccount list(ToAccount) AS ToAccount list(amount) AS amount list(action) AS action list(_time) AS time BY customer
| where authorized_count>=7
| fields - OpenDate epoch clientIP destIP _time
RR-Fraud-WT-Detect multiple account login denials followed by authorization Risk Rule Notable This is a successful brute force detection, and might indicate compromised customer credentials. sourcetype=<wire transfer data source>
| convert timeformat="%Y/%m/%d %H:%M:%S" ctime(epoch) AS c_time
| sort - _time
| streamstats time_window=1h count(eval(action="denied")) AS denied_count count(eval(action="authorized")) AS "authorized_count" latest(action) AS latest_action BY customer FromAccount ToAccount
| where denied_count>=5 and authorized_count>=1 and latest_action="authorized"
| table _time customer FromAccount ToAccount amount denied_count authorized_count
| eval amount=tostring(round(amount, 2), "commas")
Notable-Fraud -- Possible Wire Transfer Fraud Notable This is a custom risk notable focused on detecting multiple anomalies across the wire transfer fraud use case. It is modeled on the Account Takeover and New Account fraud notables.

| from datamodel:"Risk.All_Risk"
| search source="*RR-Fraud-WT*"
| dedup risk_object risk_object_type source
| eval source_short=replace(source, "(?i).*? -- (.*?)( - Rule)", "\1")
| eventstats sum(calculated_risk_score) AS risk_score_total, dc(source) AS source_count, values(sourc*) AS sourc* BY risk_object risk_object_type
| where risk_score_total >= 10
| eval severity=case(risk_score_total<20,"low",
risk_score_total<30,"medium",
risk_score_total<40,"high",
risk_score_total>=40,"critical")

| fillnull AF__app AF__dash
| stats values(DM) AS DMs, first(severity) AS severity, first(urgency) AS urgency, values(threat*) AS threat*, first(risk_score_total) AS risk_score_total, values(sourc*) AS sourc*, values(AF__qs) AS AF__qs by risk_object risk_object_type AF__app AF__dash
| sort 0 - source_count risk_object risk_object_type
| streamstats c(eval(if(len(AF__app)>1,1,null()))) as c by risk_object risk_object_type
| where c<10
| eval AF__DD0{c}_app=if(AF__app=0, null(), AF__app)
| eval AF__DD0{c}_app=`AF__app`
| eval AF__DD0{c}_app="SplunkEnterpriseSecuritySuite"
| eval AF__DD0{c}_dash=if(AF__dash=0, null(), AF__dash)
| eval AF__DD0{c}_qs="( " . mvjoin(AF__qs, " OR ") . " )"
| eval AF__DD0{c}=if(AF__dash=0, null(), "Investigate Notable: Possible ATO (" . risk_object_type . "=" . risk_object . ") via [" . AF__dash . "] dashboard")
| stats values(DMs) AS DMs, first(severity) AS severity, first(urgency) AS urgency, values(threat*) AS threat*, first(risk_score_total) AS risk_score_total, values(sourc*) AS sourc*, values(AF__DD*) AS AF__DD* by risk_object risk_object_type
| sort 0 - source_count risk_score_total risk_object risk_object_type
| dedup source
| table sev* urg* risk* thr* calc* tot* sou* DM* AF__D*

Next steps

After you have implemented this wire transfer fraud 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.

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.