Campagna “Error 524” usa finte pagine Cloudflare per colpire gli utenti mobili

Campagna “Error 524” usa finte pagine Cloudflare per colpire gli utenti mobili

Se hai ricevuto un SMS con un link urgente, non aprirlo subito: verifica il mittente, controlla l’indirizzo del sito e, se hai dubbi, accedi solo dall’app ufficiale del servizio. Questa è la misura più rapida per ridurre il rischio di cadere in una campagna di phishing mobile che sfrutta marchi noti, pagine di errore credibili e flussi di raccolta dati molto ben costruiti.

La campagna prende di mira utenti mobili in più aree del mondo e si presenta come un servizio legittimo, ma in realtà serve a sottrarre informazioni personali e dati di pagamento. Gli attaccanti imitano brand diffusi in settori come telecomunicazioni, finanza e programmi fedeltà, perché questi nomi ispirano fiducia e rendono più facile convincere le vittime a compilare moduli fraudolenti.

L’operazione è attiva almeno dalla seconda metà del 2025 e, pur avendo un forte focus iniziale sull’America Latina, si è estesa anche in Europa, nell’area APAC e in Nord America. Questa espansione mostra quanto il modello del phishing-as-a-service sia diventato industrializzato: gli operatori possono lanciare campagne coordinate, adattarle per Paese e cambiare rapidamente infrastruttura per evitare il blocco dei domini.

Una delle caratteristiche più efficaci di questa campagna è l’uso di pagine finte con messaggi di errore Cloudflare, incluso il noto “Error 524”. In pratica, quando il sito viene visitato in condizioni considerate non interessanti dagli attaccanti, ad esempio da desktop o da una geolocalizzazione non prevista, al posto del contenuto malevolo compare una pagina che sembra un normale problema tecnico. Questo inganno riduce la probabilità che scanner automatici, ricercatori o provider di hosting vedano subito la vera pagina di phishing.

La selezione delle vittime avviene in modo condizionale. Se il dispositivo è mobile e la posizione geografica rientra nei Paesi bersaglio, il visitatore viene reindirizzato verso l’interfaccia fraudolenta; in caso contrario, vede una schermata innocua o un errore credibile. Questo approccio rende la campagna più difficile da analizzare e più resistente ai tentativi di smascheramento.

In America Latina, i Paesi più colpiti includono Messico, Cile e Colombia. In questa regione sono stati identificati almeno 4.389 domini di phishing, un numero che indica un livello di scala molto elevato. La concentrazione su LATAM è coerente con diversi fattori pratici: un uso molto intenso del mobile, controlli meno rigidi contro lo spoofing via SMS e una forte diffusione di servizi basati su premi, punti o promozioni, che forniscono pretesti convincenti per il raggiro.

Anche fuori dall’America Latina la campagna mostra varianti ben organizzate. In Europa sono state osservate centinaia di domini, con particolare presenza nei Paesi Bassi e in Germania, dove gli obiettivi principali erano servizi finanziari e operatori logistici. Nell’area APAC, invece, i domini rilevati hanno puntato soprattutto su telecomunicazioni e impersonificazione di enti governativi, con l’Australia tra i Paesi più rappresentati.

Il flusso d’attacco inizia di solito con un SMS che crea urgenza. I messaggi parlano di premi in scadenza, consegne in sospeso o altri eventi che spingono l’utente ad agire subito. Gli SMS arrivano spesso da numeri locali falsificati, così da sembrare più credibili e aumentare la probabilità di cliccare sul link inserito nel messaggio.

Dopo il clic, la vittima viene portata su un sito progettato per sembrare minimale all’inizio. Il caricamento iniziale mostra solo una struttura HTML ridotta, mentre la parte malevola viene attivata solo dopo le verifiche del dispositivo e della posizione. Quando il sistema conferma che il visitatore è un bersaglio valido, il sito mostra un’interfaccia specifica per il brand imitato e per il Paese di destinazione, con elementi grafici e testi localizzati per aumentare l’affidabilità percepita.

La raccolta dei dati avviene in più fasi. Prima vengono richieste informazioni di base come nome, indirizzo, email e numero di telefono. Solo dopo, il modulo passa alla fase più sensibile, in cui viene chiesto l’inserimento completo dei dati della carta di pagamento. Il processo è costruito per sembrare normale e progressivo, così la vittima si sente dentro una procedura autentica anziché in un furto di dati.

Un aspetto importante è che le verifiche sulle carte sono volutamente minime. Invece di controllare in tempo reale se la carta sia valida presso un circuito bancario, il sistema si limita a verifiche basilari come il checksum. Questo consente agli attaccanti di raccogliere molte più informazioni in meno tempo, evitando ritardi e riducendo il rischio che una verifica bancaria blocchi la sessione.

La campagna usa anche canali WebSocket cifrati per esfiltrare i dati in tempo reale. Quando la pagina di phishing viene caricata, si apre una connessione persistente tra il browser della vittima e i server controllati dagli attaccanti. In questo modo, i dati possono essere trasmessi immediatamente mentre l’utente inserisce le informazioni, e segnali periodici di mantenimento della connessione aiutano a conservare la sessione attiva e a raccogliere informazioni sul comportamento della vittima.

Anche l’infrastruttura è costruita per resistere alle difese. Cloudflare viene usato come reverse proxy per nascondere i server di origine, che risultano spesso ospitati su ambienti cloud come Tencent Cloud e Alibaba. Questo rende più complicato risalire all’origine reale dell’operazione e limita l’efficacia delle azioni di rimozione basate solo sul livello CDN, perché il backend può continuare a funzionare anche se una singola superficie viene mitigata.

Per aumentare la resilienza, gli operatori cambiano spesso dominio e usano estensioni economiche come .top, .ink e .click. I nomi dei domini sono scelti per somigliare a portali di premi o pagine di servizi legittimi, così da imitare schemi familiari agli utenti e migliorare il tasso di conversione delle frodi.

Nel complesso, questa campagna dimostra come il phishing mobile stia diventando sempre più sofisticato. L’unione tra delivery via SMS, geofencing, fingerprinting del dispositivo, esfiltrazione in tempo reale e infrastrutture cloud distribuite crea un ecosistema di attacco veloce, scalabile e difficile da individuare con i controlli tradizionali.

Per gli utenti, la difesa più efficace resta semplice: non fidarti dei link ricevuti via SMS, soprattutto se richiedono dati personali, credenziali o pagamenti. Se un messaggio sembra provenire da una banca, da un corriere, da un operatore telefonico o da un programma premi, apri l’app ufficiale o digita manualmente l’indirizzo del servizio invece di usare il collegamento incluso nel testo.

Per le aziende, il caso evidenzia anche un problema più ampio: la combinazione di spoofing SMS, brand impersonation e pagine dinamiche costruite per mostrare contenuti diversi in base al contesto rende insufficiente il solo blocco dei domini. Servono monitoraggio continuo, protezione del marchio, telemetria sui comportamenti anomali e procedure di risposta rapide per ridurre la finestra di esposizione.

Technical Deep Dive

La parte più interessante della campagna è il suo modello di conditional rendering. Il contenuto fraudolento non viene mostrato indiscriminatamente, ma solo dopo aver superato controlli lato client su geolocalizzazione e fingerprint del dispositivo. Questo significa che il semplice crawling da desktop, molto usato da difensori e scanner automatici, può restituire solo una facciata inattiva o una pagina d’errore.

L’uso di pagine Cloudflare false, incluso l’“Error 524”, è particolarmente efficace perché sfrutta un comportamento visivo familiare. Un visitatore casuale tende a interpretare quel messaggio come un problema temporaneo del sito, non come una tecnica di occultamento. Dal punto di vista operativo, invece, questa scelta riduce l’esposizione della payload page e abbassa il rischio di segnalazioni premature.

L’architettura basata su una SPA codificata in Base64 aggiunge un ulteriore livello di frizione all’analisi statica. In questi casi, gran parte della logica viene decodificata ed eseguita solo a runtime, quindi l’ispezione del codice sorgente iniziale non rivela subito il flusso completo. Per gli analisti, questo implica la necessità di emulazione dinamica, cattura delle chiamate di rete e osservazione del comportamento in un ambiente mobile simulato.

Il ricorso a WebSocket cifrati per l’esfiltrazione è rilevante anche dal punto di vista difensivo. Una connessione persistente WSS permette comunicazione bidirezionale continua, utile sia per inviare dati in tempo reale sia per ricevere eventuali istruzioni o aggiornamenti dalla piattaforma di attacco. In più, la presenza di heartbeat periodici offre agli operatori un segnale sullo stato della sessione e può essere usata per misurare tempo di permanenza, progressione del form e probabilità di completamento.

Dal lato dell’infrastruttura, la separazione tra CDN e server di origine complica il takedown. Se il front-end usa un reverse proxy e il backend è distribuito su provider differenti, il blocco di un singolo componente non interrompe necessariamente l’intera catena. Questo spiega perché le campagne PhaaS moderne tendano a usare più livelli di astrazione e a ruotare frequentemente domini, IP e template.

Infine, il fatto che il controllo delle carte sia limitato a verifiche di formato indica un obiettivo chiaramente orientato al volume. Gli operatori preferiscono massimizzare il numero di record raccolti piuttosto che rallentare il flusso con controlli bancari in tempo reale. In termini di threat modeling, questo comportamento suggerisce una pipeline ottimizzata per l’acquisizione rapida dei dati e la monetizzazione successiva, piuttosto che per la sola validazione immediata delle credenziali.

Fonte: https://gbhackers.com/error-524-decoy-campaign/

Torna in alto