Brand Impersonation & Phishing Takedown SOP

Standard operating procedure for detecting, investigating, and taking down websites that impersonate Wealthy or misuse its SEBI registration to defraud users.

Brand Impersonation & Phishing Takedown SOP

Purpose

This SOP defines how Wealthy’s security team responds when an external website impersonates Wealthy — cloning the brand, or displaying Wealthy’s SEBI / CIN / DP / RA registration numbers — to defraud the public.

These events are external security incidents, not breaches: Wealthy’s own systems and data are not compromised. The response is investigation + takedown + browser blocklisting, escalating to regulators and law enforcement only as needed. Record each case under Security Incidents, not the engineering RCA section.

Scope

Applies to look-alike domains, fake trading/broking platforms, fraudulent “Wealthy” apps, and any site misusing Wealthy’s regulatory identifiers.

Step 1 — Triage (confirm it is impersonation)

  1. Confirm the site visibly impersonates Wealthy: brand/logo reuse, or — most damning — it displays Wealthy’s own SEBI registration, CIN, DP, or RA number.
  2. Cross-check any displayed SEBI registration against Wealthy’s real numbers. A match proves impersonation (not a coincidental name clash).
  3. Note classic fraud signals: guaranteed/“assured” returns, “success rate” claims, deposit/KYC collection forms — all prohibited for a SEBI broker.
  4. Confirm the site is currently live (this drives how far you escalate — see Step 4).

Step 2 — Investigate (OSINT runbook)

Work entirely from public sources — never probe, log in to, or attack the target. Capture output as evidence (timestamped).

 1# DNS → hosting IP + provider (nameservers reveal the host)
 2dig +short <domain> A
 3dig +short <domain> NS
 4
 5# WHOIS on the domain → registrar, abuse contact, registration age, registrant
 6whois <domain>
 7
 8# WHOIS on the IP → hosting provider + abuse contact
 9whois <ip>
10
11# HTTP headers → web-server / application stack fingerprint
12curl -sI https://<domain>/
13
14# TLS certificate transparency → THE KEY PIVOT.
15# SAN entries often leak the operator's control domain and sibling clone sites.
16curl -s "https://crt.sh/?q=<domain>&output=json"

Pivot: if crt.sh reveals a control/parent domain, repeat whois + dig on it. Matching IP + nameservers + registrant ties sites to one operator and frequently exposes an entire network of clones impersonating other firms — document these for a consolidated case.

Attribution caution: WHOIS registrant names are self-declared and unverified. Record them as a string of evidence only. Never publicly attribute a registrant name to a real individual (e.g. matching a LinkedIn profile) — it is defamation risk and weakens the real case. Verified identity comes only from the registrar/host under a legal request, or from law enforcement.

Step 3 — Preserve evidence

  • Screenshot the live site (homepage + any deposit/login portal).
  • Save the dig / whois / headers / crt.sh output to a dated evidence file.
  • Open a tracking issue in the security repo and attach findings before requesting takedown (the site may disappear quickly).

Step 4 — Report & take down (escalate by outcome)

Act in this order. Reassess after each step — once the site is down, you may not need to escalate further.

Priority Channel Why When
1 Hosting provider abuse Fastest lever — it is their server Always, first
2 Google Safe Browsing (report form) Browser/DNS-level warning protects users immediately (Chrome/Android) Always
3 Domain registrar abuse Domain suspension + registrant disclosure If site stays up, or for the control domain
4 SEBI (email + SCORES) Misuse of Wealthy’s licence; CSCRF regulated-entity notification If material / ongoing, or regulator notification required
5 CERT-In (incident@cert-in.org.in / portal) Phishing is a mandatorily reportable category (2022 Directions) If site persists / national coordination needed
6 National Cyber Crime portal (cybercrime.gov.in / 1930) Financial-fraud case; strongest law-enforcement lever If victims reported losses

Match the response to the outcome. If the host report + Safe Browsing submission already take the site offline, regulator/law-enforcement escalation can be prepared and held in reserve rather than filed reflexively — and sent immediately if the site resurfaces. Reserve the heaviest channels (SEBI, CERT-In, cyber-crime) for sites that stay up, recur, or caused confirmed investor loss.

Step 5 — Close out & monitor

  1. Record the case under Security Incidents (YYYY-MM-DD-<brief>.md), sanitised — no unverified names, no live operational detail.
  2. Monitor for resurfacing — DNS still resolving after the server goes down means the domain is not de-registered; the operator may return on a new IP/domain.
  3. If it returns, escalate using the retained drafts (registrar → SEBI → CERT-In → cyber-crime).

Reference — reporting contacts

Body Channel
Google Safe Browsing safebrowsing.google.com/safebrowsing/report_phish
CERT-In incident@cert-in.org.in · cert-in.org.in portal · 1800-11-4949
SEBI sebi@sebi.gov.in · SCORES portal
National Cyber Crime cybercrime.gov.in · helpline 1930
(Host / registrar abuse) Resolve per-case from whois output