Detecting Malicious Bulk Registrations

A practical guide to identifying potentially malicious bulk domain registration campaigns using DataPulse tools. Start with datapulse_dns_regclusters to surface suspicious clusters, then pivot through similarity search, scraping, and history for confirmation.

Red Flag Indicators

Registrar Red Flags

Not all registrars respond equally to abuse reports. Watch for:

Domain Name Red Flags

Examine sample_domains in the summary response for these patterns:

TLD Red Flags

Certain TLDs consistently appear in abuse data. High volumes from these TLDs deserve extra scrutiny:

A cluster of 500+ registrations at a lesser-known registrar, all on .top or .icu, is a strong heuristic for abuse, not a finding: corroborate with the scraped content (datapulse_domain_overview), DNS history (datapulse_dns_dphistory) and abuse contacts before reporting it as malicious. Registrar, TLD and hosting patterns are all triage hints that need a second signal.

Registration Timing Red Flags

When using detail mode (registrar_id), examine the registration_date timestamps:

Investigation Workflow

Step 1: Surface Suspicious Clusters

Start with a broad summary scan:

datapulse_dns_regclusters({
  "date": "2025-02-09",
  "min_cluster_size": 50
})

Review the results:

• Skip well-known registrars with historically normal volumes (GoDaddy, Namecheap, Tucows)
• Flag registrars you don’t recognize
• Flag known abuse-friendly registrars
• Check sample_domains for DGA patterns, brand abuse, or suspicious TLDs

Step 2: Drill Into a Suspicious Registrar

Get the domain list for a flagged registrar (first page of 200):

datapulse_dns_regclusters({
  "date": "2025-02-09",
  "registrar_id": 3222
})

If total_count in the response exceeds 200, the first page is usually enough to identify patterns. Page through with offset if needed:

datapulse_dns_regclusters({
  "date": "2025-02-09",
  "registrar_id": 3222,
  "offset": 200
})

Examine the list for:

• Naming pattern consistency (all DGA? all brand + random? mixed?)
• TLD distribution
• Registration timestamp clustering

Step 3: Check Infrastructure Overlap

Pick 2–3 suspicious domains and run similarity searches:

datapulse_dns_dptechsim({
  "domain": "suspicious-domain.top",
  "similarity": 0.90
})

If multiple domains from the cluster share infrastructure (same NS ASN, same MX ASN, same hosting), this strengthens the case for a coordinated campaign. Look specifically for:

• Rare ASN overlap (not Cloudflare/AWS/Google)
• Shared nameservers across unrelated-looking domains
• Same registrar_iana_id across similarity results

Step 4: Scrape for Content

Submit suspicious domains to see what they’re hosting:

datapulse_scrape_submit({
  "url": "http://suspicious-domain.top",
  "wait": true
})

Common findings for malicious bulk registrations:

• Blank/parked pages (domains staged for future use)
• Redirect chains to phishing or scam pages
• Login page clones (brand phishing)
• SEO spam / doorway pages
• Cryptocurrency scam landing pages

If the scrape fails, check whether the domain has live DNS records:

datapulse_live_dns({
  "domain": "suspicious-domain.top"
})

No A/AAAA records means no web address was published for the name — the usual reason a scrape fails, though a scrape can also fail with A/AAAA present (blocked, timed out, no HTTP service). The name may still resolve for other types (MX, TXT, NS), so check the full record set before calling it dormant. Web addresses missing at registration is common with bulk registrations: domains are registered but not yet pointed at infrastructure (staging for a future campaign). The absence of DNS records is itself a signal — legitimate bulk registrations (e.g., brand protection) usually resolve immediately.

Step 5: Check History and Timeline

For domains that appear active:

datapulse_dns_dphistory({
  "domain": "suspicious-domain.top"
})

Look for:

• Very recent first-seen dates (freshly weaponized)
• Rapid IP changes (fast-flux behavior)
• Infrastructure that appeared and disappeared quickly (burned domains)

Example Investigation

Scenario: Unknown Registrar with 800+ Domains

1. regclusters(date="2025-02-09", min_cluster_size=50)
   → registrar_id: 3222 (registrar_id_scheme: "iana", registrar_name: "Domainipr Limited") — 964 domains
   → sample_domains: ["byts-cy.com", "fm664.com", "fjhdad.com", ...]
   → Red flags: unfamiliar registrar, DGA-like names

2. regclusters(date="2025-02-09", registrar_id=3222)
   → 964 domains returned
   → Most are 4-8 random characters on .com/.net
   → All registered between 05:00 and 07:00 UTC (2-hour burst)

3. dptechsim("byts-cy.com", similarity=0.92)
   → 47 matches, all share NS on ASN 40034
   → Same registrar, same date cluster
   → Infrastructure is coordinated

4. scrape_submit("byts-cy.com")
   → Blank page, single tracking pixel
   → Conclusion: domains staged for future campaign

5. dphistory("byts-cy.com")
   → First seen today, pointing to 45.x.x.x (known bullet-proof hoster)
   → Conclusion: HIGH CONFIDENCE malicious bulk registration

Scenario: Brand Impersonation Campaign

1. regclusters(date="2025-02-09", min_cluster_size=20)
   → Registrar X — 340 domains
   → sample_domains: ["paypal-verify2.top", "amzn-secure.icu", ...]
   → Red flags: brand names + high-abuse TLDs

2. regclusters(date="2025-02-09", registrar_id=XXXX)
   → 340 domains, all contain brand keywords
   → Brands targeted: PayPal, Amazon, Microsoft, Apple
   → All on .top, .icu, .sbs TLDs

3. dptechsim("paypal-verify2.top", similarity=0.90)
   → Cluster of 200+ domains on same infrastructure
   → Shared NS, same hosting ASN

4. scrape_submit("paypal-verify2.top")
   → PayPal login clone with credential harvesting form
   → Conclusion: CONFIRMED phishing campaign

Distinguishing Legitimate from Malicious

Quick Triage Checklist

When reviewing a cluster from regclusters, quickly assess:

• Registrar recognized? — If not, investigate further
• Sample domains look human-generated? — Random chars = suspicious
• TLDs reputable? — .top/.icu/.sbs = high risk
• Volume normal for this registrar? — Compare with adjacent dates
• Infrastructure shared? — Run dptechsim on 2–3 samples
• Content live? — Scrape 1–2 domains to see what’s hosted

If 3+ of these checks raise flags, the cluster warrants a full investigation and potential reporting to the registrar’s abuse contact.

Related Topics

• regclusters — Tool documentation and parameter reference
• techsim — Infrastructure similarity search details
• reconnaissance — Full domain investigation workflow
• scraping — Web scraping tool usage