Error 524 Decoy: Unmasking a Global Smishing Operation Hiding Behind Error Pages

Introduction

Latin America, characterized by high mobile penetration and uneven SMS anti-spoofing controls, is often exploited by fraud operators. Group-IB researchers have identified a sophisticated, large-scale smishing and phishing operation, active since the second half of 2025, that uses the region as its primary theater and has expanded to 72 countries across the globe. This campaign has impersonated over 267 unique brands across sectors like telecommunications and financial services, successfully generating thousands of phishing domain instances aimed at harvesting full credit card credentials and personal identifiers.

The operation has a layered anti-analysis evasion architecture, which uses convincing fake Cloudflare error pages, like the “Error 524” timeout screen, as a decoy. The malicious content is only revealed to victims matching specific geofencing and mobile device criteria. This is combined with a technically mature infrastructure utilizing Base64 obfuscated Single Page Applications and real-time data exfiltration over encrypted WebSocket channels.

Key discoveries

• The campaign has been active since H2 2025, impersonating more than 260 unique brands across 72 countries spanning LATAM, Europe, APAC, North America, and META regions.
• Group-IB identified 4,389 phishing domain instances; Mexico alone accounts for 1,851, with Chile (529) and Colombia (258) among the top targets in LATAM.
• Telecommunications is the most targeted sector with 1,754 domain instances, followed by Financial Services (696) and Consumer Rewards programs (488).
• The phishing kit uses fake Cloudflare error pages as decoy screens, revealing malicious content only to victims matching geofencing and device fingerprint rules.
• Data exfiltration occurs via encrypted WebSocket channels using binary encoded payloads, with heartbeat pings to maintain real-time connections.
• Approximately 30% of phishing infrastructure is hosted on Tencent Cloud and Alibaba (US) origin servers, fronted by Cloudflare (AS13335) to mask true hosting IPs.

Who may find this blog interesting:

• Cybersecurity analysts and corporate security teams
• Malware analysts
• Threat intelligence specialists
• Cyber investigators
• Computer Emergency Response Teams (CERT)
• Law enforcement investigators
• Cyber police forces

Group-IB Threat Intelligence Portal: Smishing Error524

Group-IB customers can access our Threat Intelligence portal for more information about this threat actor.

• Smishing Error524

Threat Actor Profile

Campaign Discovery and Geographic Scope

Group-IB’s Digital Risk Protection (DRP) teams identified this campaign during routine monitoring of brand impersonation infrastructure in the second half of 2025. Automated domain clustering and visual fingerprinting of phishing kits revealed a high-consistency pattern across domains targeting telecom operators, financial institutions, and consumer loyalty programs predominantly in Latin America, and reaching in a small scale Europe, APAC, and North America.

The campaign’s LATAM concentration is not coincidental. Mexico, Chile, and Colombia together account for 2,638 of the 4,389 regionally attributed domain instances, roughly 60% of the identifiable campaign footprint.

Figure 1. Breakdown of the smishing campaign’s LATAM footprint.

Figure 2. Breakdown of the smishing campaign’s most targeted industries in LATAM.

Group-IB’s analysis attributes this geographic weighting to three structural factors: 

• Weak SMS anti-spoofing enforcement across multiple LATAM carriers. 
• High mobile internet penetration combined with relatively low security awareness among mobile-first consumer populations. 
• Prevalence of high-traffic loyalty and reward programs operated by major telecoms and retailers, which generate the “urgency pretexts”, points expiring, rewards unclaimed, that drive victim click through rates.

Beyond LATAM, the campaign’s European instances (673 confirmed domains, primarily Netherlands and Germany) targeted financial services and logistics operators, while APAC instances (238 domains, led by Australia) focused on telecommunications and government impersonation. The North American footprint (405 domains) disproportionately targeted financial services and consumer rewards programs, consistent with the campaign’s reliance on loyalty program lures.

Figure 3. Breakdown of the campaign’s regional distribution.

The Error 524 Evasion Architecture

The most operationally significant feature of this campaign is its layered anti-analysis architecture, centered on exploiting legitimate Cloudflare error page aesthetics as a deception mechanism. When a phishing domain is accessed by a request that does not meet the campaign’s access control criteria: IP geolocation from a non-targeted country, a non-mobile user-agent string, or the absence of expected session parameters, the server returns a page visually identical to a Cloudflare gateway error, displaying various error codes such as 524 (a gateway timeout), 300, or 313.

This tactic serves dual purposes. For security researchers and automated scanners attempting to enumerate the phishing infrastructure, the decoy page offers no indicators of malicious content, no credential harvesting forms, no brand impersonation assets, and no suspicious JavaScript. For hosting providers and takedown request recipients reviewing flagged domains, the decoy page reinforces plausible deniability, as the site appears to be a misconfigured or broken legitimate deployment rather than an active fraud operation.

The filtering criteria are enforced at page-load time through client-side IP geolocation queries to external APIs. The response, including country code, currency, and language, determines whether the victim proceeds to the malicious SPA or receives the decoy. Mobile user-agent validation adds a second filtering layer, consistent with the campaign’s exclusive targeting of mobile device users. This dual-layer conditional rendering is among the more operationally disciplined implementations Group-IB has observed in a PhaaS-attributed campaign.

Figure 4. The websites utilizes a Cloudflare error page, displaying various error codes, as a deceptive landing page.

Attack Chain: From SMS Lure to Credit Card Exfiltration

For victims who do meet the campaign’s geofencing and device criteria, the attack unfolds across a precisely engineered five-stage interaction flow, optimized for mobile usability and designed to progressively build victim trust before soliciting the highest-value data: full credit card credentials.

Stage 1: Lure Delivery

Victims receive an SMS from a number spoofed to appear local to their country. The message is constructed with an urgency pretext–most commonly a reward balance about to expire, a benefit pending claim, or a delivery requiring confirmation–and embeds a shortened URL. URL shorteners obscure the destination domain within the SMS, reducing the  likelihood that carriers or security aware recipients will identify the link as suspicious before clicking.

Stage 2: Landing Page Load

On click (from a qualifying device and IP), the phishing domain loads a minimal HTML skeleton, a single <div id=”app”> mount point consistent with a Single Page Application architecture. The full application content is encoded as Base64 data within custom HTML elements and decoded at runtime by bundled JavaScript. This approach eliminates inline scripts visible to static analysis tools and moves the malicious rendering logic into an obfuscated runtime execution layer.

Stage 3: Identity Harvesting

The initial form solicits a national registry or identification number, a low-friction entry point that exploits familiarity. On submission, the interface surfaces a personalized “reward offer” or benefit relevant to the impersonated brand, reinforcing the legitimacy of the interaction. Subsequent screens collect full name, physical address, email address, and phone number.

Stage 4: Credit Card Collection

The final data collection stage solicits complete payment card information: card number, expiration date, and CVV. Validation is intentionally minimal, relying solely on the Luhn algorithm checksum for card number format verification. Test cards passing the checksum are accepted and immediately trigger the post submission redirect. This approach maximizes throughput by avoiding real-time authorization checks that would require bank connectivity and introduce latency.

Stage 5: Exfiltration and Redirect

Submitted data is exfiltrated in real time via an encrypted WebSocket (WSS) channel established at page load. Binary-encoded payloads of varying sizes (64–1,008 bytes) carry the harvested credentials, while heartbeat pings maintain channel integrity and log session dwell time as behavioral analytics. Following submission, the victim is seamlessly redirected to the legitimate brand website. This post-harvest redirect serves two functions: it sustains the illusion that the interaction was legitimate, reducing immediate victim reporting; and it reinforces the session close, ensuring no post-harvest persistence on the victim’s device.

HTTP Traffic Analysis

First Request

The HTTP response from this initial request serves a minimal HTML document for a single page application (SPA). It’s proxied through Cloudflare, with the origin server being Caddy, a lightweight web server often used for Go language apps or static serving.

The response body is a bare bone HTML skeleton: No server rendered content, just a mount point <div id=”app”> for client-side rendering.

Code block 1. First HTTP request from the phishing page.

Code block 2. First HTTP response from the phishing page.

Second Request

This HTTP response is an immediate API call from the client-side JavaScript, after mounting the SPA at /apps/CL_PT_04. It’s dynamic, proxied via Cloudflare with Caddy again as the origin server.

After the SPA load, the JS sends a session bound request to fetch personalized or secure data. The Backend (PHP/Caddy) encrypts it server-side, returns blobs for client decryption.

Code block 3. http request to the endpoint /getApp.

Code block 4. HTTP response delivering a JSON payload.

The data object contains three large encoded Base64 binary blobs (k, d, s), that are not human readable text:

• k: Likely a symmetric encryption key (e.g., AES-256 derived key) or nonce.
• d: Encrypted payload (ciphertext), possibly application data like user state, config, or content fetched via the session (PHPSID cookie).
• s: Signature or MAC (e.g., HMAC-SHA512) for integrity or authenticity, computed over d using k.

Third Request

An HTTP request to a managed Cloudflare endpoint for Real User Monitoring (RUM).

RUM is a performance monitoring tool that collects anonymized telemetry data about how real users experience a website’s load times, interactions, and resource usage. The endpoint /cdn-cgi/rum is part of Cloudflare Web Analytics, which sites can enable to track metrics without third-party cookies.

It’s reporting data for a single page navigation event, including detailed browser timings. The payload is a JSON object with performance metrics, indicating a relatively quick page load. This enables efficient, persistent communication without polling, ideal for mobile devices.

Code block 5. HTTP request to the endpoint /cdn-cgi/rum.

Code block 6. HTTP response 204 No content.

Fourth Request

This request attempts to upgrade to a WebSocket connection on the same domain. The path /wss with a query parameter uuid indicates a custom WebSocket endpoint, likely for real-time features in the SPA for live updates, notifications, or bidirectional communication in the /apps/CL_PT_04 app. This follows the sequence: HTML load → JSON API fetch → WebSocket init.

Code block 7. HTTP request to the endpoint /wss.

Code block 8. HTTP response to the prior WebSocket upgrade request, confirming a successful handshake.

The HTTP 1.1 101 Switching Protocols status indicates the connection has been upgraded from HTTP to WebSocket, over the existing TCP socket. All communication shifts to WS frames. This completes the SPA’s real-time setup. The client now has a bidirectional, low latency channel for features like live updates or chat in /apps/CL_PT_04.

Websocket Communication

The malicious domains utilize the WebSocket protocol to transmit encrypted information, including the time a user spends on the website, via “heartbeat” requests.

The WebSocket traffic is binary, consisting of encoded Base64 raw bytes that decode to 1008 bytes of opaque binary data. This binary format indicates the data is not standard UTF-8 text.

The heartbeat mechanism is essential for maintaining the real-time channel, which supports the core /apps/CL_PT_04 endpoint functionality of the application, for example live synchronization.

Infrastructure Analysis

The campaign’s infrastructure architecture reflects deliberate operational security choices, balancing global reach, low detection footprint, and rapid domain cycling against the need for reliable delivery to qualifying mobile victims.

Hosting and CDN Architecture

Cloudflare (AS13335) serves as the primary CDN and reverse proxy across the majority of scanned domains, providing IP masking, TLS termination, and the Real User Monitoring (RUM) endpoint repurposed as a behavioral telemetry channel. Origin servers are predominantly hosted on Tencent Cloud (AS132203) and Alibaba US (AS45102), which together account for approximately 30% of identified phishing infrastructure by instance volume. Group-IB assesses that the selection of Chinese cloud providers is deliberate: both services offer rapid provisioning, competitive pricing, and a degree of IP blocking resistance due to the providers’ association with legitimate global cloud infrastructure.

The use of Cloudflare to proxy Tencent and Alibaba origin servers creates a compound attribution challenge for takedown requests: the registering abuse team typically contacts Cloudflare, which may apply restrictions at the CDN layer while the origin server remains active, enabling rapid re-fronting under a new domain.

Domain Patterns and TLD Selection

Domains exhibit consistent structural patterns: short registrations on low-cost top-level domains with generic prefixes mimicking brand names (e.g., rewards-[brand]-cl[.]ink, puntos-[brand]-mx[.]bond). Bulk registration with sequential naming patterns allows rapid domain cycling following takedowns. TLDs identified in campaign infrastructure include .ink, .top, .bond, .click, .icu, .vip, and .cyou, all of which are consistent with the TLD preferences of Southeast Asian eCrime infrastructure clusters documented in prior Group-IB investigations.

Primary Infrastructure IPs

Analyzing the Technical Composition of the Phishing Pages

The operational consistency across all functional phishing sites provides undeniable evidence of a unified kit and campaign. Analysis of DOM structures, JavaScript execution, HTTP headers, and XHR patterns reveals an identical technical fingerprint:

• Developing a realistic user experience, the attackers utilize the Vue.js frontend framework (evidenced by data-vue- attributes and specific window objects like __VUE_INSTANCE_SETTERS__) combined with FormKit for complex form handling.
• A standardized core endpoint pattern is used, where each site triggers an XHR to /getApp?app_id=XX_XX_XX (e.g., CL_PT_04). This acts as the central loader, with the “PT” prefix likely denoting “Payment Target.”
• The asset structure remains uniform, loading large bundled JS files (1–2 MB) alongside legitimate resources like Open Sans fonts and Font Awesome icons to enhance credibility.
• For geolocation and monitoring, the kit uses ipapi.co to bypass geo-restrictions and Cloudflare’s beacon.min.js for behavioral analytics.
• The backend configuration consistently utilizes PHPSID and uuid cookies, with servers alternating between Caddy and Workerman.

This structural design accounts for the two-sided appearance of the identified domains: an operational Vue-powered landing site when conditions are met, and a fraudulent 524 timeout error screen designed to hide the phishing kit from requests that do not match target device profiles.

Conclusion

The Smishing Error524 operation represents an evolving and highly sophisticated threat that has industrialized brand impersonation on a global scale. By leveraging deceptive error page aesthetics to bypass traditional security filters, the campaign demonstrates a significant technical maturity in modern eCrime syndicates.

The impact is particularly notable in the LATAM region, where the absence of robust SMS anti-spoofing controls allows fraudulent messages to be delivered with ease. This lack of enforcement across regional carriers creates a fertile environment for attackers to target critical sectors of the digital trust economy, including telecommunications and financial services.

The success of this campaign relies on psychological manipulation. End users must remain vigilant and skeptical of unsolicited messages that create a false sense of urgency. Staying ahead of such disciplined PhaaS operations requires a combination of behavioral detection, dark-web intelligence, and proactive brand monitoring.

Group-IB’s Unified Risk Platform provides continuous monitoring across the phishing domain lifecycle, from registration through active deployment to takedown, giving organizations the intelligence lead time needed to act before victims are exposed. As PhaaS operators continue to refine their anti-analysis architectures and expand their affiliate networks into new regions, the combination of threat intelligence, behavioral analytics, and coordinated takedown capability will define which organizations stay ahead of these campaigns and which do not.

Recommendations

For Security Teams and Fraud Prevention

• Integrate Threat Intelligence feeds to receive timely IOCs on newly registered phishing domains matching campaign TLD and infrastructure patterns (.ink, .bond, .top, .cyou on Tencent/Alibaba origin IPs).
• Monitor for bulk domain registrations using brand-adjacent naming patterns on suspicious TLDs, particularly those registering clusters of sequential domains within 24–72 hours.
• Leverage an advanced Digital Risk Protection platform for automated brand impersonation detection and coordinated takedown, targeting domains before they reach active victim contact.

For End Users and Consumer-Facing Teams

• Train users to be skeptical of unsolicited SMS messages claiming reward balances, delivery confirmations, or benefit claims, regardless of whether the sender number appears local.
• Instruct users to navigate directly to brand websites by typing the URL rather than clicking SMS links, particularly for financial or reward program interactions.
• Remind customers that legitimate brands will never request full credit card details, including CVV, via SMS-linked landing pages.

For Executives and CISOs

• Assess your organization’s exposure in the sectors most targeted by this campaign: telecommunications, financial services, and consumer rewards programs, particularly if operating in Mexico, Chile, Colombia, or other LATAM markets.
• Include PhaaS-driven brand impersonation in your organization’s threat model and ensure Digital Risk Protection coverage spans domain registration monitoring, not just takedown response.
• Engage with Group-IB’s LATAM Digital Crime Resistance Center (DCRC) in Chile for regional threat intelligence and coordinated response capabilities aligned to your operating markets.

Group-IB Fraud Matrix

MITRE ATT&CK

Indicators of Compromise (IOCs)

Network IOCs

• 47.82.154[.]2
• 43.165.6[.]36
• 43.159.168[.]186
• 154.81.166[.]17
• 43.162.84[.]202
• 8.222.134[.]149
• 45.135.162[.]90

DISCLAIMER: All technical information, including malware analysis, indicators of compromise and infrastructure details provided in this publication, is shared solely for defensive cybersecurity and research purposes. Group-IB does not endorse or permit any unauthorized or offensive use of the information contained herein. The data and conclusions represent Group-IB’s analytical assessment based on available evidence and are intended to help organizations detect, prevent, and respond to cyber threats.

Group-IB expressly disclaims liability for any misuse of the information provided. Organizations and readers are encouraged to apply this intelligence responsibly and in compliance with all applicable laws and regulations.

This blog may reference legitimate third-party services such as Telegram and others, solely to illustrate cases where threat actors have abused or misused these platforms.

This material is provided for informational purposes, prepared by Group-IB as part of its own analytical investigation, and reflects recently identified threat activity. 

All trademarks referenced herein are the property of their respective owners and are used solely for informational purposes, without any implication of affiliation or sponsorship.