Disrupting a Phishing Operation: Technical Breakdown

Overview

We identified an active phishing site impersonating Illinois government services at:

https://illinois.dot-rn.cc/us#/

The site targeted victims via SMS and harvested sensitive data including credit card information.

This post breaks down how the scam worked, where it failed, and how we disrupted the backend by reverse engineering the frontend, identifying the C2 endpoint, and flooding it with invalid data.

1. Initial Behavior: Cloaked Payloads

The phishing site responded differently depending on how it was accessed:

• Clicking the SMS link displayed the full scam form

• Visiting directly showed a fake “site can’t be reached” page

We suspected filtering based on the referrer or user-agent. Using Burp Suite, we confirmed this. Spoofing header with a fake imessage referrer triggered the real scam content.

Example User-Agent:

Mozilla/5.0 (iPhone; CPU iPhone OS 17_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.0 Mobile/15E148 Safari/604.1

2. Reverse Engineering the Frontend

The main HTML loaded scripts from:

/assets/us_illinois/

The JavaScript was only lightly obfuscated, common wrappers, junk variables, but not encrypted or minified.

Inside the scripts, we found:

• Credit card validation (Luhn check, CVC rules)

• Address/email/phone field checks

• Submission logic POSTing to: /app/(with a dynamic url)

3. Understanding the Backend Requirements

From the validation logic, we recovered the exact POST parameters:

• full_name

• address1

• city

• state

• zip

• email

• phone

• card_holder

• card_number

• validity_time (MM/YY)

• cvv

The endpoint had no protections:

• No authentication

• No rate-limiting

• No CAPTCHA

• No server-side validation

4. Countermeasure: Disrupting the C2

We wrote a Python script to spam the endpoint with valid-looking fake data.

The script:

• Generates Luhn-valid card numbers

• Rotates user-agents and IPs (via proxy lists)

• Randomizes names, addresses, and expiry dates

• Sends continuous submissions with slight timing variation

This flooded their database with junk, making it harder to filter real victims.

5. Technical Weaknesses

They made a few major mistakes:

• Exposed C2 endpoint with no checks

• Client-side validation only

• Readable scripts with minor obfuscation

• WebSocket logging with no input filtering

• No evasion against automation tools

6. Outcome

We:

• Identified their infrastructure

• Extracted the endpoint

• Validated the payload structure

• Flooded it with false positives

• Reported the domain to Cloudflare & Google, and started takedown efforts

Their operation is now far less useful.

This case shows how poorly built phishing kits can be disrupted with no special access. Careful analysis and targeted response can wreck their value.

Tips for investigating phishing kits:

• Trace data flow end-to-end

• Reverse the frontend logic

• Check for exposed endpoints

• Always test from isolated networks

• Report and document everything

Disclaimer: This activity was conducted strictly for educational and research purposes. No real user data was accessed, stored, or interacted with. No unauthorized access or exploitation occurred. All testing was performed in isolated environments using researcher-owned hardware and networks. No university systems, sponsors, or third-party infrastructure were involved or impacted.