Fraud Management: Identifying and Alerting for an IP Threat

Published: June 1, 2023

Scenario

Data breaches affecting consumer data are notoriously common for businesses. In 2017, for instance, credit reporting agency Equifax exposed 145.5 million user accounts, with many clients exposing their social security numbers and other details.

There are many ways customer identity data can be compromised, resulting in account takeover (ATO) attacks. Fraudsters will appear to connect from similar sources. An SOC or Security Investigations Unit will need to monitor the IP addresses that attempt to access an application or service. The objective is to identify Fraudulent IPs, alert the monitoring team, and label the IP and network address for future reference.

Solution

We need a reference/source persistent repository to investigate the IPs that are likely to be fraudulent and provide a historical reference for past fraudulent IPs used in identity theft.

Step 1: Create a KV Store to hold fraudulent IPs

Create a KV Store “ip_reference” with the following fields: reference_ip, network_address, ip_status, network_status, country, city, location, frequency, and black_listed.

Step 2: Populate the ip_reference KV Store

Create a service to populate the ip_reference store if a threat is identified by the fraud investigation team. This repository can act as an input coupled with other applications and data stores to identify threats. Splunk supports this effort through dashboards, searches, or data pushes and helps remediate an identity attack.

Step 3: Analyse the ip_reference store and assign status

The data in the ip_reference store should be categorized based on the types of threats—categories could be Confirmed Fraud, Suspected, Malicious, or Unidentified. Frequency values could be Rare, Sparse, Frequent, and Quite Often.

Automated processes pull IP, location, and network information for the threat IPs and add classification and frequency values. Based on these metrics, we can blacklist the fraud actor’s IPs and networks.

Step 4: Monitor application and server logs

Index logs from servers and applications and monitor for new activity from IPs stored in the KV Store table. Create a dashboard to display transaction statuses. Include deep drill-downs into raw data for analysts to see new application calls from the same IP.

Step 5: Generate a transaction alert based on the ip_reference lookup

From the transaction alert table, extract the IP address and lookup with the ip_reference lookup table and see whether any results match. If one does, trigger an alert. The alert severity should be based on the status of the IP in the lookup table. As the volume in the lookup table increases, the results produced will be more meaningful.

For general KV Store reference documentation from Splunk, go here