I Walked Away from Cybersecurity. A Phishing Attempt on My Own Code Dragged Me Back In.

Last year, I stopped concentrating on cybersecurity. A different technical domain piqued my interest and got me distracted. That being said, recently an automated phishing campaign hit my production content. I write technical articles on dev.to and recently got a notification for a comment left on one of my posts. The account was supportdev. The comment was extremely urgent social engineering to create a sense of panic:

Dear User,
Due tо an inсrеase in bot activitу оn the рlatform, wе rеquire vеrify оf yоur account.
Pleаsе lоg іn vіa thе link belоw:
• anti-bot.icu/5K0N5G7M9C4
Verificated deadlinе - 12 hours.
Sincerely, Dev Suрport

When I clicked through, it was exactly what you'd expect from a credential-harvesting trap: a cloned dev.to logo paired with a custom Vue-rendered payment form aggressively demanding credit card details to "verify" my identity.

My dormant cybersecurity brain suddenly woke up. This huge, completely irrational adrenaline rush I got.

Logic tells me I had one data point and one only. A single spam comment on a blog post. A normal user would just hit "Delete" and move on. But my brain didn't see it logically. It went straight into full Hollywood movie logic.

You know those cyber-thriller movies where the lone hacker finds a random, tiny glitch, starts pulling at the thread, and suddenly it escalates into a high-stakes battle between a random guy in his room and a massive, shadowy global syndicate?

That's just the sort of kick I wanted. I did not want this to be a lonely spam bot. I wanted this to be a big automated network. I wanted the excitement of the chase. I wanted to be the random guy that exposes the infrastructure.”

So, with just movie delusion and a long-standing love for forensics, I opened my Linux terminal and tried to map it out.

---

Phase 1: Technical Breakdown of the Initial Lure

Before diving into the network architecture, I would like to decompose the exact comment code. The attackers were using a clever way around automated guardrails.

1. Unicode Homoglyph Obfuscation

When I ran the raw string of the comment through a character inspector, the mechanism for evading dev.to's automated spam filters became clear. The attacker wasn't using standard Latin text. They relied on Unicode homoglyphs—characters from different scripts (like Cyrillic) that look identical to Western characters to the human eye but have entirely different hex values:

• Expected Latin o (U+006F) was replaced with Cyrillic о (U+043E).

• Expected Latin a (U+0061) was replaced with Cyrillic а (U+0430).

• Expected Latin e (U+0065) was replaced with Cyrillic е (U+0435).

By salting the copy with these characters, the text reads flawlessly to a panicked user while looking like completely benign, non-blacklisted strings to simple regex or automated keyword filters.

2. Initial Infrastructure Reconnaissance

I dropped the URL path into a basic WHOIS evaluation to finger the domain anti-bot.icu.

bash

$ whois anti-bot.icu
Domain Name: ANTI-BOT.ICU
Registrar: PDR Ltd. / PublicDomainRegistry
Creation Date: 2026-09-25T08:30:32Z
Registry Expiry Date: 2027-09-25T23:59:59Z

Use code with caution.

The domain had been provisioned exactly two days before the account was spun up and deployed. The operation was fresh, active, and running on a tightly controlled timeline. I immediately packaged this data and submitted a formal abuse ticket to PublicDomainRegistry (Case #53471908) requesting an immediate infrastructure suspension.

---

Phase 2: Bypassing the Anti-Analysis Defenses

This is where the cinematic hunt became highly technical. When security researchers look at a phishing site, threat actors look back. The kit was heavily armored to prevent anyone from investigating its source code.

1. Client-Side Fingerprinting and Cloaking

When I attempted to extract the site’s raw HTML payload using a standard command-line utility, the origin server rejected the handshake:

$ curl -A "Mozilla/5.0" https://anti-bot.icu
HTTP/1.1 403 Forbidden
Content-Type: text/html

The application was employing defensive user-agent and client-side cloaking. It checked for valid browser headers, canvas rendering parameters, and Cloudflare verification loops before exposing the actual malicious payload. If you weren't browsing from a real, active desktop profile, it served a generic, custom HTML page stating "Oops! Something is wrong." to hide its intent.

I successfully bypassed this cloaking ring by routing an isolated scanner (urlscan.io) to capture an authentic browser engine fingerprint and hold a persistent cf_clearance cookie session.

2. The Rickroll Debugger Trap

Once inside the DOM, things got genuinely hilarious. The kit developers embedded an anti-forensics library called console-ban v3.2.0.

The scripts were configured to detect whenever the browser's Developer Tools panel (F12 or Ctrl+Shift+I) was opened. The absolute millisecond a security engineer opened DevTools to inspect the active network sockets, the library triggered an infinite loop of execution blocks via a debugger; statement, locked up the browser tab, and forcibly redirected the window to a Rickroll music video.

// Conceptual representation of the console-ban defensive routing
import ConsoleBan from 'console-ban';
ConsoleBan.init({
  redirect: 'https://youtube.com', // The Trap
  write: 'Debugger active. Access denied.'
});

To complement this, the page disabled standard context menus (oncontextmenu="return false"), blocked text selection, intercepted Ctrl+U / Ctrl+S commands, and applied a subtle hue-rotate(4deg) CSS filter layout to frustrate simple visual analysis and automated screenshot matches.

---

Phase 3: Deconstructing the Data Harvesting Engine

Once the cloaking and defense walls were cleared, the core system opened up. The actual phishing landing zone was a slick, multi-tiered credential-harvesting machine.

                   [ Client Browser ] 
                           │
                           ▼ (Bypasses 403 Cloak)
                [ "ACCOUNT VERIFICATION" ]
           (Hotlinked dev.to wordmarks & logos)
                           │
                           ▼ (User clicks "Verify")
                  [ /merchant/order/id ]
            (Vue.js Client App / Fake Card UI)
                           │
                           ▼ (Real-time tracking)
                [ Socket.IO WebSocket ]
         (Real-time push / Scripted Operator Chat)

1. The Cloned Interface

The root landing page was configured with full multi-language translation architecture natively handling 10 separate languages (EN, DE, FR, IT, ES, PL, PT, NL, TR, RU) dynamically parsed through navigator.language to scale the attack vector globally.

function detectLang() {  
  var lang = (navigator.language || navigator.userLanguage || 'en').toLowerCase().substring(0,2);  
  var supported = ['en','de','fr','it','es','pl','pt','nl','tr','ru'];  
  return supported.indexOf(lang) >= 0 ? lang : 'en';  
} // Kit multi-language evaluation logic

2. The Vue-Driven Card Capture UI

The checkout path located at /merchant/order/<campaign_id> was not standard, static HTML. It was configured as a client-side rendered Single Page Application (SPA) built on Vue.js v2.6.10 and vue-swal v1.0.0. This architectural choice explains why primitive HTTP scraper bots could never capture the input elements—they required an active Javascript runtime environment to paint the capture form onto the screen.

To maximize social-engineering trust, the developers baked in an animated payment card wrapper element with a highly unique hook: a dummy field masking dropdown that read "Unlock your account to view autofill suggestions".

This gave the illusion of an actual, integrated OS or security browser function, building synthetic legitimacy so users would input their full card names, CVVs, and expiry parameters.

At the bottom of the form layout, fine print explicitly asserted:

"By clicking 'Next', you confirm your intention to connect your account to Square API."

This is a false/borrowed brand reference. The page had no physical integration with Square’s engineering APIs—it was purely using the trusted financial identity of a massive global payment processor to lower user defenses.

3. Real-Time WebSockets & Scripted Social Engineering

The kit featured a highly responsive chat component at /supportChatFrame/<id> driven by a custom supportSocketClient.js payload. The engine opened a direct WebSocket communication channel to a Node.js/Express backend, assigning each target session a unique client identification string:

// Extracted payload elements
socket.emit('register', {
  adId: '5K0N5G7M9C4',
  supportToken: localStorage.getItem('supportToken')
});

The system tracked user activity in real time. If a target paused or hesitated on the input page, the WebSocket automatically pushed scripted responses down the line to combat user skepticism:

"If you are afraid to enter your card data, do not worry, because the data is double encrypted with the PCI24 protocol..."

Security Check: There is no such thing as "PCI24". The recognized financial framework is PCI DSS. The kit simply fabricated a technical-sounding acronym to manufacture credibility and pressure victims.

---

The Smoking Gun: Mapping the Broader Network

This wasn’t a minor, isolated script running out of a single garage. It was part of an extensive, highly automated software kit.

Two days after submitting my initial report, the plot escalated. By running behavioral profiling across dev.to, I uncovered 5 distinct accounts (including handles like devsupportss and devsupporte) all leveraging the exact same automated comments.

Simultaneously, a parallel infrastructure nodes emerged through independent URL shorteners (tr.ee/dev-verified) pointing to a second active domain: antibot.casa.

When I extracted the raw source files for both anti-bot.icu and antibot.casa, I hit the ultimate architectural link. Deep within the components of both independent deployment instances sat an identical, explicit developer comment left inside the source tree:

<!--Добавляем div для вставки дополнительного HTML-кода-->

Translated directly from Russian, it states: "Adding a div for inserting additional HTML code."

Forensic Interpretation

While a shared language artifact in code doesn't provide concrete geopolitical attribution (as phishing kits are routinely bought, leaked, and shared across global dark web forums), it serves as a definitive architectural fingerprint. It proves with near-absolute certainty that both domains were generated by the exact same centralized, reusable multi-brand phishing kit deployment process.

Threat Remediation and Current Status

Thanks to the rapid processing of the compiled evidence log, the infrastructure take-down was a complete success:

• anti-bot.icu: Officially suspended by PublicDomainRegistry under Case #53471908.

• supportdev: Account completely neutralized and now returns a clean 404 Not Found.

• antibot.casa: Taken down independently shortly after discovery.

• Secondary Accounts: Instantly caught by dev.to’s automated heuristics engines and forcibly locked down into inactive spam_* handles.

Indicator of Compromise (IOC)	Type	Entity Status	Forensic Link Confidence
anti-bot.icu	Domain	SUSPENDED	Confirmed (Primary landing zone)
antibot.casa	Domain	OFFLINE	High (Identical templates & code comments)
supportdev	DEV Account	MUTED (404)	Confirmed (Source of spam vector)
<!--Добавляем div...-->	Code Artifact	ACTIVE FINGERPRINT	Confirmed (Shared kit software footprint)

This entire case served as a massive personal wake-up call. Sometimes walking away from a technical field like cybersecurity is the only way to remind yourself why you fell in love with it in the first place. It took an automated threat actor targeting my own platform content to give me that real-world Hollywood movie rush again.

The hunt is ongoing. I am continuing to trace passive OSINT indicators, monitor certificate transparency chains, and log shortener vectors to track exactly where this kit attempts to re-surface its infrastructure next.

Stay safe, double-check your platform administration alerts, and never trust a support message that requires credit card data to verify your terminal workspace.