Fraud rings operate on an economy of scale. Unlike individual bad actors, organized groups rely on shared infrastructure to generate synthetic identities, manipulate payment gateways, or scrape competitive data. While they attempt to mask their origin using residential proxies and VPNs, the underlying infrastructure often leaves a detectable footprint.

This guide outlines the technical methodology for identifying these rings by analyzing shared IP characteristics, ASN velocity, and connection types.

The Anatomy of a Ring Attack

A fraud ring typically rotates IPs to bypass basic rate limiting. However, cost constraints force them to reuse resources. A ring attack manifests in three patterns:

Subnet Closeness: Multiple accounts originating from different IPs within the same /24 CIDR block.
ASN Hosting Concentration: High volume traffic from ASNs belonging to hosting providers (e.g., DigitalOcean, AWS, Hetzner) rather than residential ISPs.
Proxy Rotation: Rapid cycling of IPs that flag as VPN, Tor, or Proxy in intelligence databases.

Analyzing ASN and Subnet Velocity

Rate limiting by single IP is insufficient. Advanced detection requires tracking velocity by Autonomous System Number (ASN) and Company.

If you detect 50 signups in 10 minutes from AS14061 (DigitalOcean), and your service targets general consumers, this is a statistical anomaly indicative of a botnet or script.

Python Implementation: ASN Velocity Check

The following Python snippet utilizes a Redis cache to track registration attempts by ASN over a sliding window.

import redis
import requests
import time

# Redis connection
r = redis.Redis(host='localhost', port=6379, db=0)

def check_asn_velocity(ip_address, limit=10, window=300):
    # 1. Enrich IP Data using IPASIS
    response = requests.get(f"https://api.ipasis.com/json/{ip_address}?key=YOUR_API_KEY")
    data = response.json()
    
    asn = data.get('asn')
    org = data.get('org')
    
    # If no ASN found, fallback or block
    if not asn: 
        return False

    # 2. Create a sliding window key for the ASN
    current_time = int(time.time())
    key = f"velocity:asn:{asn}"
    
    # 3. Add timestamp to sorted set and expire old entries
    pipe = r.pipeline()
    pipe.zadd(key, {current_time: current_time})
    pipe.zremrangebyscore(key, 0, current_time - window)
    pipe.zcard(key)
    pipe.expire(key, window)
    _, _, count, _ = pipe.execute()

    print(f"Activity from {org} ({asn}): {count} requests in {window}s")

    if count > limit:
        raise Exception(f"Velocity exceeded for ASN {asn} ({org})")

    return data

Graphing User-IP Relationships

Sophisticated fraud rings use "residential proxies" to appear legitimate. However, these IPs are expensive and often recycled among the ring's bots. By mapping User IDs to IP addresses in a graph database (or a simple adjacency list), you can detect connected components.

Normal Behavior: 1 User ↔ 1-5 IPs (Home, Mobile, Work).
Fraud Ring Behavior: 50 Users ↔ 10 IPs (Many-to-Many mesh).

If User A shares an IP with User B, and User B shares a different IP with User C, they form a cluster. If any node in that cluster is confirmed fraud, the entire graph should be flagged for manual review.

Automating Detection with IP Intelligence

Analyzing raw logs is reactive. Proactive defense requires inspecting the connection type at the ingress point (e.g., registration or checkout middleware).

Specifically, you must reject or challenge traffic where is_proxy, is_vpn, or is_tor is true, particularly if the request originates from a datacenter ASN.

Node.js Middleware Example

const axios = require('axios');

const ipasisMiddleware = async (req, res, next) => {
  const clientIp = req.headers['x-forwarded-for'] || req.socket.remoteAddress;

  try {
    const { data } = await axios.get(`https://api.ipasis.com/json/${clientIp}?key=${process.env.IPASIS_KEY}`);

    // 1. Block known threats immediately
    if (data.is_bogon || data.is_tor) {
      return res.status(403).json({ error: 'Connection type not allowed.' });
    }

    // 2. High-risk logic: Datacenter IPs acting as proxies
    if (data.is_datacenter && data.is_proxy) {
       // Trigger 2FA or CAPTCHA instead of hard block
       req.risk_score = 'HIGH';
    }

    next();
  } catch (error) {
    // Fail open or closed depending on security posture
    console.error('IP Intelligence lookup failed', error);
    next();
  }
};

Handling False Positives: The CGNAT Issue

When blocking shared infrastructure, you must distinguish between fraud rings and Carrier-Grade NAT (CGNAT).

Mobile networks (T-Mobile, Verizon) and some ISPs put thousands of legitimate users behind a single public IP. If you block an IP based solely on user-density (graphing), you risk blocking a city block of legitimate mobile users.

Solution:

Check the isp field in the IPASIS response. If it indicates a mobile carrier, relax velocity limits.
Combine IP signals with Device Fingerprinting. If the IP is shared but device hashes are unique, it is likely CGNAT. If device hashes rotate or match known bot signatures, it is a ring.

FAQ

Q: Should I block all Datacenter IPs?

A: For B2C applications (e-commerce, social), yes. Legitimate users rarely browse from AWS or Azure IPs. For B2B dev tools, this may generate false positives.

Q: How do residential proxies bypass detection?

A: They route traffic through infected devices of real users. IPASIS detects this by analyzing the history and behavior of the IP, flagging it as a compromised residential node (is_proxy: true).

Q: Can I cache IP intelligence data?

A: Yes, but keep TTL short (e.g., 10-60 minutes). Fraud rings rotate IPs rapidly; data stale by 24 hours is often useless.

Stop Fraud Rings at the Gate

Pattern matching is essential, but high-quality data is the fuel for your security engine. IPASIS provides real-time detection of VPNs, proxies, and tor nodes with industry-leading accuracy.

Get your free API key at IPASIS.com and start sanitizing your traffic today.

Identifying Fraud Rings via Shared IP Infrastructure Analysis