Disrupting a Phishing Operation: Technical Breakdown
How we found and dissected an active phishing site targeting Illinois residents — breaking down their scam, mapping their backend from the frontend out, and driving the takedown.
Jul 21, 2025
Overview
We identified an active phishing site impersonating Illinois government services:
https://illinois.dot-rn.cc/us#/The site was distributed over SMS and built to harvest personal and payment data.
This post covers how the kit worked, where it was weak, and how we mapped its backend by reverse engineering the frontend — then handed the whole thing to the parties who can pull it offline.
1. Initial Behavior: Cloaked Payloads
The site behaved differently depending on how you reached it.
Arriving from the SMS link showed the full scam form.
Visiting the URL directly showed a fake "this site can't be reached" page.
That's cloaking. The kit hides the payload from anyone who looks like a scanner or a curious analyst, and shows it only to the targeted victim flow.
We confirmed the filter with Burp Suite. Supplying a mobile user-agent and a fake iMessage referrer flipped the page from the dead-end error screen to the live 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
The false “this site can’t be reached” to disguise the page
2. Reverse Engineering the Frontend
Everything here came from scripts the site served to our own browser. No access to their server was needed or attempted.
The main HTML pulled scripts from:
/assets/us_illinois/The JavaScript was only lightly obfuscated — common wrappers, junk variables — not encrypted, not minified. Readable with a little patience.
Inside, we found:
Credit card validation (Luhn check, CVC rules)
Address, email, and phone field checks
Submission logic POSTing to a dynamic
/app/endpoint
3. Understanding the Backend Requirements
The client-side validation told us exactly what the backend expected. The kit validates everything in the browser, which means the field schema is sitting right there in the code:
full_nameaddress1citystatezipemailphonecard_holdercard_numbervalidity_time(MM/YY)cvv
Scammers code
The client-side validation told us exactly what the backend expected. The kit validates everything in the browser, which means the field schema is sitting right there in the code:
full_nameaddress1citystatezipemailphonecard_holdercard_numbervalidity_time(MM/YY)cvv
The validation logic also showed how little stood behind it. Everything was enforced client-side. When a kit validates in the browser and trusts whatever gets POSTed back, you're looking at a low-effort build.
4. Technical Weaknesses
The kit made a few clear mistakes:
Validation lived entirely client-side, so the field schema was readable.
Scripts were obfuscated only lightly — no real barrier to analysis.
Cloaking relied on referrer and user-agent, both trivially spoofable.
WebSocket logging ran with no input filtering.
Nothing was hardened against analysis tooling.
This is a kit, deployed fast, meant to run for a few days before it burns.
5. Disruption: Driving the Takedown
We did not touch their infrastructure. The leverage on a kit like this comes from the chain of providers who can pull it offline, and they move fast when you hand them a clean report.
What we did:
Reported the domain to Cloudflare (fronting provider) with the cloaking behavior and harvested-field evidence.
Reported to Google Safe Browsing, so the URL gets flagged in Chrome, Android, and Gmail link checks.
Filed with the Anti-Phishing Working Group (
[email protected]) and the FBI's IC3 (ic3.gov).Notified the registrar of the abuse, with the same evidence package.
A flagged domain stops converting. Once Safe Browsing lists it, the SMS links throw warnings and the kit's already-short shelf life gets shorter. Reporting through the proper channels makes the operation uneconomical, which is the whole goal.
6. Outcome
We:
Identified the infrastructure and cloaking logic
Reverse engineered the frontend
Recovered the exact payload schema
Documented the weaknesses
Reported the domain through every channel that can act on it
A poorly built kit gives up almost everything from the frontend alone. Document it, report it, and let the providers do the rest.
Tips for Investigating Phishing Kits
Trace the data flow end to end.
Reverse the frontend logic, the schema is usually right there.
Note exposed behavior, but never interact with attacker infrastructure.
Test from an isolated environment on your own hardware.
Report to Cloudflare, Google Safe Browsing, APWG, IC3, and the registrar.
Document everything.
Disclaimer: This research involved only content the phishing site served to our own browser, analyzed in an isolated environment on researcher-owned hardware. We did not access, probe, submit data to, or otherwise interact with the operator's backend. Disruption was carried out solely by reporting the domain to the relevant providers and authorities. No university systems, sponsors, or third-party infrastructure were involved or impacted.