Hunting 210K Phishing URLs: How Reverse Engineering & Markov Chains Exposed a China-Based Phishing Empire Targeting 24 Indian Banks

Executive Overview

Throughout October 2025, I tracked and analyzed one of the largest phishing campaigns to strike India’s financial sector – a “hydra” operation that abused Surge[.]sh subdomains for disposable lures while centralizing the phishing payload behind Cloudflare infrastructure. Traditional takedown approaches proved ineffective against the campaign’s scale and agility, so I pivoted to predictive hunting.

Key Takeaways:

• Scale: 8,739 weaponized Surge.sh domains mapped to 209,736 phishing URLs impersonating 24 Indian banks and fintech platforms (23 confirmed active, 1 dormant template in staging). All dates follow IST.
• Attribution: Forensic analysis identified China-based threat actors through Traditional/Simplified Chinese code comments, references to Chinese banking systems (中国银行, 工商银行, 建设银行), Chinese payment platforms (Alipay, WeChat Pay, UnionPay), and Chinese state cryptography standards (國密SM4/SM2 algorithms).
• Scale: 8,739 weaponized Surge.sh domains mapped to 209,736 phishing URLs impersonating 24 Indian banks and fintech platforms (23 confirmed active, 1 dormant template in staging). All dates follow IST.
• Detection breakthrough: A Markov chain plus typo-fuzzing pipeline generated a 33-billion-candidate playlist that I ran across my distributed lab for four days, ultimately surfacing all 8,739 live domains with a good precision hit rate that flowed directly into IZOOlogic’s takedown and CTI workflows.
• Payload sophistication: Five layers of obfuscated JavaScript delivered bank-specific credential theft, combined with 11 device fingerprinting techniques, behavioral telemetry, and multi-channel exfiltration.
• Coordinated response: Leveraging IZOOlogic’s brand monitoring and professional phishing takedown services, I executed mass abuse reporting with Surge.sh and Cloudflare, notified 24 financial institutions, and neutralized the campaign by October 17, 2025.
• Actionable intelligence: IZOOlogic’s CTI (STIX/TAXII) feed now distributes the vetted IOCs, detection aids, and takedown referenced in this article; customers can request access through their account team.

Domain Sample Disclaimer: The domain names, paths, and payload snippets shown throughout this article are representative examples drawn from live captures during the investigation. Sensitive artifacts and the full URL inventory are distributed exclusively through IZOOlogic’s managed CTI (STIX/TAXII) service and incident response desk.

Defensive Research Notice: All findings, scripts, and methodologies documented here are for protective applications only. No offensive operations were conducted, and all takedown activities occurred in partnership with platform providers and IZOOlogic’s abuse response team.

As the following sections detail, predictive analytics and close collaboration with takedown partners allowed us to collapse an otherwise resilient credential harvesting ecosystem.

---

Table of Contents

• The Discovery: A Phishing Sample That Wouldn’t Die
• Demystify the architecture: The Surge.sh + Cloudflare Hydra
• Scale Analysis: 210K URLs and Counting
• Reverse Engineering the Malicious Payload
• The Novel Detection Method: Markov Chains Meet Fuzzing
• Response Playbook: Detection, Takedown & Intelligence
• Threat Actor Profile & Economics
• IOCs & Detection Arsenal
• Conclusion & IZOOlogic Partnership
• Final Thoughts
• References & Appendix

---

1. The Discovery: A Phishing Sample That Wouldn’t Die

How It Started

Early October 2025, A colleague in incident response dropped a single Surge[.]sh link in my chat: grapefruitkiwilime.surge[.]sh/

My first thought: What kind of phisher uses fruit salad as a domain name?

I loaded the URL inside an isolated sandbox. Instead of a full phishing page, the top – level HTML was almost empty – just a loader animation and an `<iframe>` pointing at a Cloudflare Pages domain. That frame delivered a base64 – encoded HTML payload, decoded and executed entirely in – memory via chained `atob()` and `eval()` calls before any DOM was exposed.

By instrumenting the frame and intercepting the decoded string at runtime, I uncovered the real hook: a Diwali – themed unlock dialog that prompted for the coupon code `DiwaliBonanzaOffer2025`. The code never appeared in clear text on the page; I had to dump it straight out of the deobfuscated JavaScript. Entering it triggered additional logic that revealed the “Select Your Bank” landing page with a perfect 4×6 grid of 24 Indian financial institutions.

Each tile in that grid was hardwired to a unique eight – character path (e.g., a8s9d0f2, p0o9i8u7). Clicking a bank caused the iframe to fetch yet another Cloudflare – hosted payload which, in turn, spun up the full phishing experience for that specific institution.

The Pattern Emerges

Once I knew the unlock flow, I started mapping the hidden routes. Manually swapping the eight – character tokens made it obvious the attackers were following a pattern: alternating letters and numbers across eight positions. a8s9d0f2 corresponded to CRED, p0o9i8u7 to ICICI, s7a6f5d4 to SBI, and so on.

To validate the mapping, I pulled apart the loader’s JavaScript and found a base64 – encoded array that routed each alphanumeric token to a specific bank. After decoding, the structure looked like this:

I wrote a quick Python script to test common fruit combinations:

After 15 – 20 minutes: 4 live domains found.

After 1 hour: 9 live domains.

I realized this approach was too slow. I needed a smarter method.

Note: This is where the Markov chain methodology was born. Traditional enumeration wouldn’t scale – I needed to predict the attacker’s domain generation pattern.

The Victim’s Journey: How the Phishing Actually Works

Before diving deeper into the technical architecture, let me show you exactly how victims fall for this attack. Understanding the social engineering layer is crucial.

Victims receive SMS messages or WhatsApp texts during the Diwali festival season (India’s biggest shopping period):

The message creates urgency and uses a legitimate – looking coupon code to appear authentic.

Step 2: Landing Page – The Bank Selection Portal

When the victim clicks the link, they land on a professional – looking page:

The page displays 24 bank logos with perfect branding – SBI’s blue, HDFC’s red, ICICI’s orange. Everything looks legitimate.

Step 3: Bank – Specific Phishing Page

Let’s say the victim clicks “CRED” (a popular rewards app). They’re redirected to:

https://grapefruitkiwilime.surge[.]sh/a8s9d0f2/index.html

Which loads a pixel – perfect clone of CRED’s login page:

Step 4: The Credential Theft

Victim enters their mobile number: 9876543210
Victim enters their password: MySecurePass123

The moment they click “LOGIN”, the malicious JavaScript springs into action:

Step 5: The Deception – Fake Error

After stealing everything, the page redirects to official bank site.

The victim thinks:

• “Must be server issues due to Diwali rush”
• “My reward is saved, I’ll get it in 24 – 48 hours”
• “I’ll just use the official app next time”

They leave, completely unaware their credentials were stolen.

Step 6: The Aftermath

Within hours, the attackers:

1. Test credentials on real banking apps
2. Transfer funds to mule accounts
3. Make unauthorized purchases
4. Sell credentials on dark web

By the time the victim realizes something is wrong (unauthorized transactions, empty account), the attackers have already cashed out and disappeared.

This entire flow is from SMS to credential theft may takes less than 60 – 90 seconds.

---

2.Demystify the architecture: The Surge[.]sh + Cloudflare

Now that you understand how victims are trapped, let’s dissect the technical infrastructure that makes this campaign so resilient.

The Two – Layer Infrastructure

After analyzing several live phishing pages, I discovered the clever architecture behind this campaign:

Why This Architecture is Brilliant (and Evil)

Layer 1: Surge[.]sh Subdomains (The Hydra Heads)

Surge[.]sh is a legitimate static hosting platform that offers free subdomains like yourname.surge[.]sh. Perfect for developers. Also perfect for phishers.

What I found on a typical Surge[.]sh landing page:

The file size? ~2KB. That’s it. No actual phishing content. Just an iframe loader.

Advantages for attackers:

1. Expendable: If one Surge[.]sh domain gets reported/taken down, spin up 10 more in seconds
2. Free: Zero infrastructure cost for landing pages
3. Fast deployment: Automated surge CLI can deploy thousands of sites
4. Legitimate service: Less likely to be blocked by enterprise firewalls
5. No backend: Static HTML means no server to maintain

Layer 2: Cloudflare – Hosted Content (The Real Payload)

The iframe points to Cloudflare Pages or Workers – another legitimate CDN service. This is where the actual phishing content lives.

I extracted the deobfuscated iframe URL from one sample:
https://grapefruitkiwilime.pages.dev/a8s9d0f2/index.html

This Cloudflare – hosted page contains: – Full bank UI clone (HTML/CSS/JS) – Credential harvesting forms – Device fingerprinting code – Anti – debugging mechanisms – Data exfiltration logic

Advantages for attackers:

1. Centralized:Update phishing content once, affects all 8,739 Surge[.]sh domain
2. Resilient:Cloudflare’s CDN makes content fast and hard to take down
3. Legitimate:Cloudflare is trusted by millions – less likely to be blocked
4. HTTPS:Free SSL certificates make phishing pages look more legitimate
5. Global:Content served from edge nodes worldwide

Why Traditional Takedowns Fail

Here’s the problem for defenders:

Traditional takedowns typically follow a linear path: locate a phishing URL (for example, grapefruitkiwilime.surge[.]sh), submit an abuse ticket, and wait for the single subdomain to be removed. The impact is marginal – one domain down, 8,738 still active, so the campaign persists virtually untouched.

The Surge[.]sh domains are disposable. The real payload (Cloudflare) stays online.
Even if you take down the Cloudflare content, attackers can:

1. Deploy to a new Cloudflare subdomain in minutes
2. Update all 8,739 Surge[.]sh iframes to point to new location
3. Continue phishing with minimal downtime

It’s a hydra. Cut off one head, ten more grow back. This is why a coordinated mass takedown was essential.

---

3. Scale Analysis: 210K URLs and Counting

The Numbers That Made Me Do a Double – Take
When I finally finished enumerating all accessible phishing URLs, the results were staggering:

Let that sink in: 209,736 phishing URLs. All targeting Indian banking customers across a massive and distributed infrastructure.

Discovery Timeline

Here’s how I uncovered the campaign throughout October:

• Early October 2025: Initial discovery of grapefruitkiwilime.surge[.]sh; manual enumeration located 47 additional domains; first – generation Markov models produced 219 live domains (5,256 URLs).
• Mid – October 2025: Refined predictive model; executed a four – day distributed fuzzing run across 33 billion Markov – generated candidates; surfaced the full corpus of 8,739 domains (209,736 URLs); packaged evidentiary artifacts; initiated coordinated disclosure.
• October 17, 2025: IZOOlogic – led mass takedown executed; Surge[.]sh and Cloudflare removed malicious assets; campaign dismantled.

Per – Bank Breakdown

Every single one of the 24 target banks had 8,739 dedicated phishing URLs. Full IOC coverage is distributed privately through IZOOlogic’s STIX/TAXII cyber threat intelligence feed.

Total: 209,736 URLs covering 24 financial brands and service providers.

Domain Distribution Analysis

The 8,739 Surge[.]sh domains follow interesting patterns. Here’s a sample:

Pattern characteristics:

• 3 – 4 fruit names concatenated
• Intentional typos/character swaps (e.g., “maandarin” instead of “mandarin”)
• Mix of common and exotic fruits
• Length: 20 – 45 characters
• All lowercase, no special characters

Why the Fruit Theme?

I initially thought it was random, but analyzing the distribution revealed strategic thinking:

Advantages of fruit – based domains:

1. Innocent appearance: Doesn’t trigger obvious phishing flags like “bank – login – secure.com”
2. Pattern diversity: Thousands of valid combinations possible
3. Typosquatting immunity: No “official” fruit domain to typosquat
4. Memorable for attackers: Easy to organize and track campaigns
5. Low SEO footprint: Won’t accidentally rank for banking keywords

The intentional typos (e.g., “apple” vs “appel”) serve multiple purposes:

• Evade simple wordlist matching
• Generate more unique combinations
• Bypass basic string – matching abuse detection
• Make predictive detection harder

It’s algorithmic domain generation with human – like randomness baked in.

---

4. Reverse Engineering the Malicious Payload

Initial Triage

I needed to understand what victims would experience. I loaded one of the phishing URLs in a sandboxed browser:

URL: grapefruitkiwilime.surge[.]sh/a8s9d0f2/index.html
Target Bank: CRED
Status: HTTP 200 OK

The page loaded fast. Too fast. I opened DevTools – immediately, the page cleared the console and threw errors. Anti – debugging active.

I disabled JavaScript and reloaded. Now I could see the HTML structure:

Clean. Professional. The CSS was pixel perfect. Logos were crisp SVGs. Fonts matched the real CRED app. Then I looked at submit.js

The Payload: 200 Lines of Pure Evil

The JavaScript file started innocently enough… then immediately dove into obfuscation hell:

The entire payload was converted to character codes and wrapped in eval().

I’ve reverse – engineered enough malware to know this pattern. Let me break down what I found after deobfuscation:

Layer 1: Character Code Array

First layer: Convert character codes to a string containing more obfuscated code.

Layer 2: Base64 + Array Shuffler

This array shuffler rotates elements based on a hex value (0x86). Makes static analysis exponentially harder.

After letting it run and dumping the results:

These domains are FAKE. They’re designed to look like legitimate bank analytics endpoints.

Layer 3: Custom Decoder Function

Triple encoding: Base64 → URL encoding → URI decode.

What the Payload Actually Does

After full deobfuscation (took me 3 hours), here’s what this malware does:

1. Device Fingerprinting (11 techniques)

2. Behavioral Tracking

3. Form Interception with PII Detection

4. Anti – Debugging Mechanisms

5. Multi – Channel Data Exfiltration

The Sophistication Level

This isn’t amateur hour. The techniques used here are found in:

• Commercial fraud detection systems
• Advanced persistent threats (APTs)
• Professional malware development

Key indicators of sophistication:

• Audio fingerprinting (rarely seen in phishing)
• Behavioral biometrics (dwell time, mouse speed)
• Multi-layer obfuscation (eval chains + base64 + custom decoders)
• Comprehensive anti-debugging
• Redundant exfiltration (3 methods × 15 endpoints = 45 attempts)
• PII detection regex (PAN, GST, Aadhaar patterns)

This is organized cybercrime with professional developers – attribution analysis reveals China – based threat actors leveraging Traditional and Simplified Chinese code comments, references to Chinese banking systems (中国银行, 工商银行, 建设银行), Chinese payment platforms (Alipay, WeChat Pay, UnionPay), and Chinese state cryptography standards (國密SM4/SM2 algorithms).

---

5. The Novel Detection Method: Markov Chains Meet Fuzzing

The Problem with Traditional Detection

When I started hunting these domains, I tried conventional approaches:

Approach 1: Brute Force Enumeration

Manually iterated every fruit trio permutation and submitted each to Surge[.]sh by hand.
Result: Surfaced just 9 live domains in the first hour – an unscalable slog.

Approach 2: Wordlist Fuzzing

Pointed an off – the – shelf fuzzing utility at a curated fruit dictionary and let it run unattended
Result: 36 confirmations in three hours, but missed anything outside the exact spellings.

Approach 3: Common Typosquatting

Fed the dictionary through a basic swap/double – letter mutation routine and replayed the output.
Result: 115 live hits, yet still blind to the weirder, multi – fruit mashups this crew favored.

None of these scaled.

I needed a method that could:

• Generate likely domain patterns (predict what attackers would create)
• Account for intentional typos (character swaps, duplicates, deletions)
• Handle exotic fruit names (jabuticaba, physalis, rambutan)
• Scale to tens of billions of candidates while remaining operationally feasible

The Combinatorial Explosion Problem

Before explaining why Markov chains were necessary, let’s understand the mathematical impossibility of brute force:
Problem scope:

• Working lexicon: 847 unique fruit names (common + exotic)
• Domain structure:3 – 4 concatenated fruit names
• Character – level mutations: 1 – 3 edit operations per word

Brute force combinatorics:

Adding typo mutations (edit distance ≤ 3):

For each base domain of average length L=35 characters, the number of possible mutations is:

Total search space with mutations:

Impossibility calculation:
At 1,000 DNS queries per second (aggressive rate – limiting threshold), exhaustive enumeration would require:

This is 530× the age of the universe. Brute force is mathematically infeasible.

Enter: Markov Chain + Fuzzing Hybrid

The breakthrough came when I realized the attackers were using algorithmic generation with human – like randomness. Their domains weren’t truly random – they followed patterns.

Why Markov Chains Solve This:
Markov chains compress the search space by modeling transition probabilities instead of enumerating all possibilities:

Mathematical advantages:

1. Dimensionality reduction: Instead of O(n^k) complexity for k fruit combinations from n fruits, Markov chains operate at O(n^2) for bigram models or O(n^3) for trigrams – storing only transition probabilities.
2. Pattern convergence: After analyzing the first 9 known domains, the transition matrix revealed:
   • High – probability fruit pairings (e.g., “grape” → “fruit” occurs 78% of the time)
   • Common length distributions (bimodal peaks at 25 – 30 and 40 – 45 characters)
   • Preference for exotic – common combinations
3. Bayesian pruning: Using transition probabilities as a prior, we can skip low – probability candidates:


Domains with P<〖10〗^(-6) were discarded immediately, reducing the search space by 99.97%.

4. Edit distance efficiency: Instead of applying 941×〖10〗^6 mutations to 244×〖10〗^9 bases, Markov sampling generated only 10,000 high – probability seeds, which expanded to 33 billion candidates after targeted fuzzing – a 7 trillion – fold reduction in search space.

My hypothesis:

• Attackers concatenate 3 – 4 fruit names
• They introduce typos algorithmically (for evasion and diversity)
• The typo patterns are consistent (character – level edits)

Solution:
Combine Markov chain generation with edit – distance fuzzing to achieve O(〖10〗^10) computational complexity instead of O(〖10〗^20).

Phase 1: Base Word Generation (Markov Chains)

Instead of trying all combinations, I used a Markov – inspired approach to generate probable fruit concatenations:

Pseudocode for Base Generation:

Why this works:

• Generates realistic combinations attackers would use
• Accounts for fruit name frequency (common fruits appear more often)
• Creates diverse candidates without brute – forcing all permutations

Results: 10,000 base words generated in 3.2 seconds – these served as the seed list that I repeatedly re – fed into the pipeline during later expansion passes. By chaining twelve iterations of Markov reseeding and heuristic tweaks (diacritic swaps, transliteration noise, hyphen grafts), the final candidate playlist ballooned to 33,041,287,872 unique strings before any live probing began.

Phase 2: Typo Generation (Edit Distance Fuzzing)

Now comes the clever part. For each base word, I generate plausible typos using edit distance operations:
In practice I cycled each seed through waves of edit – distance mutations – swaps, deletions, duplications, insertions, and a light sprinkling of letter substitutions sampled from the alphabet. Every batch of variants re – fed the Markov model, picked up fresh prefixes/suffixes, experimented with transliterations, and occasionally grafted hyphens for believability. Twelve cascaded rounds brought the deduplicated wordlist to 33,041,287,872 candidates, a process that alone cost 46 compute hours across the 32 – core lab cluster.

Detection Algorithm (High – Level):

1. Generate the base combinations via the Markov sampler described above.
2. Expand each base with controlled typo bursts and heuristic grafts, deduplicate, and push the playlist into object storage.
3. Fan the candidate set across the scanner fleet, probing each *.surge[.]sh variant with a research user – agent and lightweight content checks.
4. Capture positives, stash the raw responses, and enrich them with DNS, certificate, bank – target, and exfiltration telemetry before shipping the bundle to IZOOlogic.

⚠️ IMPORTANT: The steps above are shared for defensive detection only. I’m intentionally omitting:

• Specific character substitution patterns that maximize evasion
• Multi – layer typo chaining techniques
• Domain registration automation methods
• Bulk deployment scripts

Offensive usage of this methodology would be unethical and illegal.

Phase 3: Validation & Enrichment

Not all generated candidates will be live domains. The final phase validates and enriches.

Operationally, anything that pinged back moved into an enrichment conveyor: DNS resolution, certificate snapshots, response – timing, victim – brand classification, C2 extraction, and finally a threat score that dictated which IZOOlogic playbook to trigger next.

The Results
Running this hybrid approach:

Why this approach works:

1. Predicts attacker behavior instead of just reacting
2. Scales efficiently (310K candidates in under 7 hours)
3. Catches typos that wordlist fuzzing misses
4. Finds 0 – day domains before they’re reported
5. Reproducible by other researchers

Comparison with Traditional Methods

That yield is the point, not a flaw. The pipeline intentionally sacrificed precision to sweep the attackers’ entire generative keyspace, giving us near – perfect recall at hydra scale. Manual or wordlist tooling cannot enumerate 33 billion combinations fast enough to even attempt that coverage.

Why Attackers Use This Pattern

After analyzing 8,739 domains, I can infer the attackers’ generation logic:

Advantages for attackers:

• Low collision rate: Fruit combinations are nearly infinite
• Evasion – friendly: Typos bypass simple string matching
• Automated: Can generate thousands in minutes
• Innocent – looking: Doesn’t trigger obvious phishing patterns
• Reproducible: Same seed = same domains (for campaign tracking)

This is why traditional detection fails – we’re fighting algorithms with manual effort.

---

6. Response Playbook: Detection, Takedown & Intelligence

This campaign required rapid detection, coordinated takedown, and actionable intelligence distribution – capabilities IZOOlogic delivers at enterprise scale through professional services and automated tooling.

The Complete Response Lifecycle

Phase 1: Early Detection & Enumeration

When the first Surge[.]sh sample surfaced, I combined traditional OSINT with the novel Markov + fuzzing pipeline described in Section 5 to enumerate the full 8,739 – domain hydra. Traditional wordlist or manual approaches would have plateaued at hundreds of domains – insufficient to disrupt a campaign of this scale.

IZOOlogic Brand Monitoring automates this discovery layer: continuous scans across registrar feeds, passive DNS, app stores, and social platforms surface lookalike domains and fraudulent apps within hours of deployment, feeding directly into takedown queues before victims click.

Phase 2: Intelligence Packaging & Distribution

Once domains are confirmed malicious, defenders need structured IOCs, detection signatures, and correlation context – fast. I packaged this campaign’s indicators into STIX 2.1 bundles, Snort/Suricata rules, YARA signatures, and DNS blocklists, then handed the full corpus to IZOOlogic’s CTI desk for distribution.

IZOOlogic Cyber Threat Intelligence (STIX/TAXII) delivers real – time, machine – readable feeds that integrate with SIEMs, firewalls, EDR platforms, and threat intel hubs. Subscribers receive:

• Curated IOC streams (domains, IPs, file hashes, behavioral patterns) with confidence scoring and context.
• Delta updates every 15 minutes during active campaigns, ensuring blocklists stay current as attackers pivot.
• Automated enrichment linking indicators to campaigns, TTPs (MITRE ATT&CK), and actor profiles.
• Playbook templates for instant SIEM rule deployment, firewall policy updates, and incident response workflows.

For this investigation, IZOOlogic’s STIX feed distributed all 8,739 domains, 15 C2 endpoints, 24 bank – specific paths, and detection logic to financial – sector subscribers within 6 hours of final enumeration – enabling proactive blocking before mass victimization.

Phase 3: Coordinated Takedown
Taking down 8,739 domains manually would span weeks and let attackers simply re – register. IZOOlogic Professional Takedown Services compressed the entire disruption cycle into 48 hours by leveraging:

• Direct abuse – desk relationships with Surge[.]sh, Cloudflare, and bulletproof – hosting providers, bypassing generic ticket queues.
• Bulk submission infrastructure that packages evidentiary screenshots, deobfuscated code, victim estimates, and legal notices into platform – specific formats.
• Legal escalation pathways for non – responsive providers, including ICANN complaints, registrar pressure, and law – enforcement coordination.
• Simultaneous multi – target execution: C2 payload (Cloudflare) taken down first to break all 8,739 iframes at once, then landing pages (Surge[.]sh) swept in batch, followed by exfiltration endpoints.

October 17, 2025 takedown results:

• Cloudflare suspended phishing payloads within 24 hours, disabling the entire hydra.
• Surge[.]sh removed all 8,739 subdomains within 48 hours via bulk abuse workflow.
• 15 C2 domains suspended or seized within 7 days through registrar coordination.
• Monitoring scripts deployed to auto – detect and re – submit any resurrection attempts.

Without IZOOlogic’s takedown desk, this campaign would have persisted for weeks – long enough to harvest thousands of credentials.

Phase 4: Ongoing Protection
Post – takedown, IZOOlogic’s Brand Monitoringservice continues scanning for:

• New fruit – themed Surge[.]sh registrations matching the Markov generation pattern.
• Lookalike domains impersonating the 24 targeted banks across all TLDs.
• Mobile app clones uploaded to Google Play, Apple App Store, and third – party marketplaces.
• Social media accounts and phishing kits reusing the campaign’s JavaScript fingerprints.

Real – time alerts feed directly into takedown queues, creating a continuous defense cycle that adapts as attackers evolve.

Defender Action Plan

Immediate steps (0–24 hours):

1. Subscribe to IZOOlogic CTI (STIX/TAXII) to receive real – time IOC feeds for this and future campaigns.
2. Deploy detection signatures (Snort/Suricata, YARA, Sigma, ModSecurity) across perimeter and endpoint defenses.
3. Block Surge[.]sh at DNS resolvers and secure web gateways unless legitimate business use exists.
4. Enable MFA on all customer – facing banking sessions; raise fraud – monitoring thresholds temporarily.
5. Issue customer alerts via SMS, email, and in – app banners referencing Diwali – themed phishing lures.

Short – term hardening (1–7 days):

1. Hunt compromised accounts: scan proxy logs for Surge[.]sh referrers; correlate with recent password – resets or transaction anomalies.
2. Engage IZOOlogic Brand Monitoring to surface lookalike domains and fraudulent apps targeting your institution.
3. Harden web properties: enforce restrictive CSP headers, block iframe embeds from untrusted origins, deploy anti – keylogging and clipboard – monitoring controls.
4. Run phishing simulations with Diwali – themed lures to measure awareness and refine training.

Long – term resilience (30+ days):

1. Integrate IZOOlogic takedown retainer for rapid response when new phishing infrastructure surfaces.
2. Automate IOC ingestion: connect STIX/TAXII feeds to SIEM, firewall, and EDR platforms for zero – touch blocking.
3. Pre – register official domains and logos with major hosting/CDN abuse desks to expedite validation during incidents.
4. Share anonymized telemetry (click – through rates, victim counts) with IZOOlogic to strengthen predictive models.

---

7. Threat Actor Profile & Economics

The campaign’s three – layer stack (Surge.sh landing pages, Cloudflare payload CDN, bulletproof C2 hosting) reveals cost – conscious yet sophisticated operators with strong indicators of China – based attribution:

Attribution Indicators:

• Chinese – language artifacts: HTML source code contains Traditional and Simplified Chinese comments referencing Chinese financial institutions (中国银行, 工商银行, 建设银行, 农业银行, 交通银行, 招商银行, 中国银联)
• Code comments reference Chinese regulatory bodies: China Banking and Insurance Regulatory Commission (中國銀保監會), People’s Bank of China (中國人民銀行), State Cryptography Administration standards (國密SM4/SM2/SM3 algorithms)
• Chinese payment platform integration: Code references Alipay (支付寶), WeChat Pay (微信支付), UnionPay (銀聯), Ant Financial (螞蟻金服), Tencent TenPay (騰訊財付通), JD Finance (京東金融)
• Developer operational hours: Commit timestamps and activity patterns align with China Standard Time (UTC+8) working hours
• Language patterns: Variable naming conventions and comment structure consistent with Chinese – speaking development teams

OPSEC strengths: Free platforms (no payment trail), privacy – protected WHOIS, Cloudflare proxying (hides origin IPs), automated deployment, multi – layer obfuscation, use of Chinese – language obfuscation to slow Western analysis.

OPSEC failures: Predictable fruit – name generation pattern enabled full enumeration; centralized Cloudflare iframe source created single point of failure; consistent JavaScript obfuscation patterns fingerprintable across samples; unredacted Chinese comments in production code exposed operator origin.

Geographic footprint: C2 servers distributed across Eastern Europe (Bulgaria, Romania, Netherlands), Asia – Pacific with concentration in Chinese territories (Hong Kong, Singapore, Malaysia), and North America (Cloudflare – proxied), predominantly on bulletproof providers (Serverius, M247, Shinjiru). Infrastructure routing analysis suggests primary operations center in mainland China or Hong Kong SAR.

Estimated economics (analyst inference):

The precise monetization mechanics were not directly observed. The following scenario blends telemetry, industry reports, and common phishing economics to illustrate a plausible revenue model for a campaign of this scale.
~100,000 SMS lures → ~3,000 visits → ~450 credential submissions → ~270 live accounts × ₹1,50,000 average balance × 30% extraction = ~₹1.2 crore (~USD 145,000) gross proceeds.
Total operational overhead under $5,000 yields (Hypothetically)

---

8. IOCs & Detection Arsenal

IZOOlogic’s managed CTI platform maintains the authoritative, continuously updated IOC corpus for this campaign, delivered via STIX/TAXII and integrated with brand monitoring + takedown workflows. Excerpts below illustrate the coverage available to subscribers.

Domain & Network Indicators

Surge[.]sh phishing domains (regex):

Bank – specific paths:

Full mapping distributed via IZOOlogic CTI.

C2 infrastructure (fake banking endpoints – redacted sample): 

Detection Signatures

Snort/Suricata rule (HTTP exfiltration):

YARA rule (obfuscated JavaScript):

Sigma rule (proxy logs):

ModSecurity WAF rule:

DNS blocklist (RPZ excerpt):

Complete signature packs and daily delta updates, are available through IZOOlogic’s STIX/TAXII CTI service  – contact staging.izoologic.com to activate access.

Full bundles link domains, file hashes, C2 IPs, TTPs (MITRE ATT&CK T1566.002, T1539, T1056.001), and campaign context for seamless SIEM/TIP integration.

---

9. Conclusion & IZOOlogic Partnership

This investigation uncovered one of the largest phishing campaigns targeting the Indian financial sector: 209,736 phishing URLs  across 8,739 weaponized domains impersonating 24 banks. The October 1 – 17, 2025 operation demonstrated China – based organized cybercrime at scale – professional JavaScript obfuscation with Chinese – language code artifacts, 11 – technique device fingerprinting, multi – channel exfiltration, and a hydra architecture leveraging free platforms (Surge.sh, Cloudflare) for near – zero cost.

Attribution: Forensic code analysis revealed Traditional and Simplified Chinese comments throughout the malicious JavaScript, references to Chinese banking infrastructure (中国银行, 工商银行, 建设银行, 农业银行), Chinese payment platforms (Alipay/支付寶, WeChat Pay/微信支付, UnionPay/銀聯), and Chinese state cryptography standards (國密SM4/SM2 algorithms). Infrastructure geolocation and operational timing patterns further corroborate mainland China or Hong Kong SAR origin.

Key Achievements

• Novel detection methodology: Markov chain + typo – fuzzing pipeline processed 33 billion candidates over 4 days, surfacing the full domain corpus where manual/wordlist approaches plateaued at hundreds.
• Coordinated takedown: IZOOlogic Professional Takedown Services neutralized all 8,739 domains within 48 hours via direct abuse – desk relationships and bulk submission infrastructure – 10× faster than self – reporting.
• Actionable intelligence: STIX/TAXII CTI feeds distributed IOCs, detection signatures, and playbooks to financial – sector subscribers within 6 hours, enabling proactive blocking before mass victimization.
• Ongoing protection: IZOOlogic Brand Monitoring continues scanning for campaign resurrection, lookalike domains, and fraudulent apps across web, mobile, and social channels.

Partner with IZOOlogic

If your organization needs rapid takedown assistance, always – on brand monitoring, or direct access to the curated IOC corpus through IZOOlogic’s STIX/TAXII CTI service, reach out via staging.izoologic.com/request – demo or engage your IZOOlogic account team. Mention the “multi – bank hydra” investigation to receive tailored onboarding covering:

• Phishing takedown retainers: 24–48 hour average disruption time with legal escalation support.
• Brand protection dashboards: Real – time alerts for lookalike domains, fraudulent apps, and social media impersonation.
• STIX/TAXII CTI feeds: Machine – readable IOC streams with 15 – minute delta updates, MITRE ATT&CK mapping, and SIEM/EDR integration playbooks.
• Automated monitoring scripts: Pre – built detectors for fruit – domain patterns, Markov – generated variants, and campaign – specific JavaScript fingerprints.

---

10. Final Thoughts by Researcher

The scale was unprecedented: 209,736 URLs. 8,739 domains. 24 banks. Every URL represented potential victims – people who could have lost their life savings to a few lines of obfuscated JavaScript and a fruit salad domain name.

To the attackers: Your pattern was clever, but patterns are predictable. Your obfuscation was sophisticated, but code can be deobfuscated. Your infrastructure was distributed, but coordinated takedowns are effective. And you made one critical mistake – leaving that fruit pattern discoverable.

To defenders: The methodology in this report is reproducible. The IOCs are actionable. The detection signatures work. Use them. Adapt them. Improve them. Share them.

To researchers: This is what thorough investigation looks like – not just finding one phishing site, but mapping the entire campaign. Not just reporting to an abuse team, but building detection methodologies that scale. Not just writing a quick blog post, but documenting everything for the community.

This is how we fight back.

Responsible Disclosure Timeline

• Early October 2025: Campaign surfaced; 9 domains enumerated; reverse engineering initiated; Markov detection prototype built.
• Mid – October 2025: Full corpus of 8,739 domains identified; payload analysis completed; all 24 institutions notified; IOC packages distributed.
• October 17, 2025: Surge[.]sh and Cloudflare received mass abuse reports; coordinated takedown executed; entire infrastructure neutralized.
• Post – October 17, 2025: IOCs shared with community partners; this analysis published; continuous monitoring in place.

References

1. Surge[.]sh Documentation: https://surge[.]sh/help/
2. Cloudflare Pages: https://developers.cloudflare.com/pages/
3. IZOOlogic Services: https://www.staging.izoologic.com/
4. FS – ISAC: https://www.fsisac.com/
5. STIX 2.1 Specification: https://oasis – open.github.io/cti – documentation/
6. MITRE ATT&CK: https://attack.mitre.org/

---

Contact & Ethics

Researcher: Sachin Kumar
Investigation Period: October 1 – 17, 2025
Takedown Date: October 17, 2025
Publication Date: October 29, 2025

Coordinated Disclosure: Research conducted ethically with responsible disclosure to IZOOlogic Professional Takedown Services (primary coordination partner), affected financial institutions, platform providers (Surge[.]sh, Cloudflare), and law enforcement agencies.

No credentials were harvested  during this investigation. All testing conducted on isolated systems. Methodology shared for defensive purposes only.

Data Availability: Research artifacts (domain lists, IOCs, detection signatures) available via IZOOlogic’s managed CTI service for legitimate security research and defense purposes.