Phaltblyx e il BSOD fake: come una finta schermata blu trasforma un phishing “Booking” in controllo remoto completo

0

Phaltblyx malware sfrutta un BSOD fake per indurre le vittime a incollare comandi in Win+R, poi abusa MSBuild.exe come binario fidato per eseguire un progetto malevolo e rilasciare un payload basato su DCRat RAT. La campagna, attribuita da Securonix a un cluster identificato come PHALT#BLYX, colpisce il settore hospitality con email che imitano Booking.com, usa una tecnica di social engineering in stile ClickFix e punta a ottenere controllo remoto completo, con keylogging, process injection e persistenza tramite elementi di avvio Windows. Il punto non è l’exploit: è la costruzione di una catena in cui l’utente diventa l’esecutore dell’attacco, mentre i binari legittimi diventano lo scudo.

La catena di infezione: dal phishing “Booking” al progetto MSBuild

L’attacco parte da una classica email di phishing che riproduce la semantica operativa dell’hospitality: cancellazioni, reclami, pagamenti, urgenze. Il dettaglio che rende credibile la narrazione è l’uso di addebiti in euro e testi con tono “europeo” in periodi festivi, quando turni ridotti e stress operativo rendono più probabile il click impulsivo.

Il link non porta subito a un download. Prima introduce un passaggio di “frizione” controllata: reindirizzamenti su domini intermedi, una pagina che simula un errore del browser e un CAPTCHA ingannevole. È qui che entra in gioco la parte più subdola: un pulsante “Refresh” scatena un BSOD fake a schermo intero, costruito per sembrare un crash reale del sistema.

Il BSOD non serve a “bloccare”, serve a spingere l’utente a obbedire. La schermata istruisce a premere Win+R e incollare con Ctrl+V un comando, normalizzando un comportamento che in azienda dovrebbe essere sempre proibito. Questo è ClickFix nella sua forma più efficace: non forza un eseguibile, arruola la vittima.

ClickFix con BSOD fake: perché funziona così bene

Il BSOD è una metafora di autorità: comunica urgenza, paura e assenza di alternative. In un contesto hospitality, dove un gestionale fermo significa camere bloccate e reclami, il personale tende a seguire procedure “di emergenza” senza verifiche.

La scelta del BSOD è strategica anche perché aggira un limite tipico dei phishing moderni: i browser e gli endpoint bloccano download sospetti, ma non possono impedire all’utente di eseguire Run e PowerShell se l’organizzazione non ha policy solide. L’attacco passa quindi da “malware delivery” a “self-execution guidata”, sfruttando la fiducia cieca nel fatto che “se lo dice Windows, sarà vero”.

PowerShell come primo stadio: decoy, ricerca di msbuild e drop in ProgramData

Il comando incollato in Run avvia uno script PowerShell che esegue più azioni coordinate. Prima apre un decoy che reindirizza a un dominio apparentemente legittimo collegato a Booking (un modo per ridurre sospetti immediati e dare alla vittima l’illusione di essere tornata “sul sito giusto”). Subito dopo lo script cerca msbuild.exe sul sistema, individuandolo nel percorso locale.

Questo passaggio è centrale: MSBuild è un binario Microsoft “fidato”, spesso presente su macchine con componenti .NET o tool di sviluppo e, soprattutto, raramente considerato “pericoloso” dagli utenti. Lo script scarica quindi un file progetto, tipicamente v.proj, in %ProgramData%, e lo esegue con msbuild.exe.

L’uso di %ProgramData% è un altro elemento di mimetizzazione: è una directory comune e condivisa, dove la presenza di file non è immediatamente anomala per chi non fa triage. Qui, però, diventa un deposito operativo per l’esecuzione del payload.

Living off the land: MSBuild come motore di esecuzione “legittimo”

Il file .proj non è un “eseguibile” in senso classico. È un progetto XML che MSBuild interpreta e compila, includendo task che possono richiamare comandi. Phaltblyx sfrutta questo meccanismo inserendo un task Exec che contiene PowerShell embedded, ottenendo esecuzione di codice con un processo firmato Microsoft.

Questa scelta ha un vantaggio duplice. Sul piano difensivo, molti controlli permettono msbuild perché necessario a build e compilazioni. Sul piano di detection, il rumore generato da msbuild in alcune organizzazioni rende più difficile distinguere l’uso legittimo da quello malevolo senza regole contestuali, come la directory di origine, i parametri e la presenza di download esterni. In altre parole, l’attacco non “rompe” Windows: si finge Windows.

Escalation e sabotaggio delle difese: Windows Defender nel mirino

La catena prevede un ramo decisionale legato ai privilegi. Se lo script ottiene permessi amministrativi, passa alla fase di sabotaggio: disattiva il real-time monitoring di Windows Defender e aggiunge esclusioni per estensioni e directory, creando una corsia preferenziale per i payload successivi. Se non ha privilegi elevati, lo script tenta di forzare l’utente a concederli tramite ripetute richieste UAC, creando stress e pressione psicologica. In un contesto di servizio clienti, il personale potrebbe cliccare “Sì” per “far tornare tutto normale”, completando l’innalzamento dei privilegi. Questa parte è un punto chiave perché dimostra che la campagna non punta solo all’infezione, ma alla durabilità operativa: se disabiliti Defender e crei esclusioni, l’endpoint diventa terreno stabile per successive azioni di esfiltrazione e controllo remoto.

Lo stager .NET e la persistenza: LNK e shortcut URL in Startup

Il payload scaricato include uno stager .NET, descritto come offuscato e impacchettato, che copia se stesso in una posizione temporanea e avvia meccanismi di persistenza basati su componenti Windows nativi. Il dettaglio interessante è l’uso di file come update.lnk e soprattutto un .url in Startup, ad esempio DeleteApp.url, che punta a un percorso file:// per rilanciare l’eseguibile al login.

Questa tecnica non è la più comune nel malware “di massa”, ma è efficace perché il file InternetShortcut viene spesso sottovalutato nelle policy e nei controlli. È persistenza “povera” ma resiliente: niente servizi, niente driver, niente scheduled task complessi. Solo la logica di avvio dell’utente. Il file pins.dat viene usato come marcatore di stato, per indicare che l’installazione è completata o per evitare re-infezioni sullo stesso host. Anche questo è un segnale di maturità: l’attore gestisce la campagna come un processo.

Il payload finale: DCRat come piattaforma di controllo remoto

Il payload finale è descritto come basato su DCRat, una RAT molto diffusa in ambienti underground, con capacità che vanno ben oltre la semplice backdoor. Le funzionalità citate includono controllo remoto, keylogging, shell interattiva, screen streaming, raccolta di informazioni di dominio e capacità di iniettare o holloware processi per eseguire codice senza creare nuovi eseguibili evidenti.

Il valore di una RAT in hospitality è enorme: accesso a dati di prenotazione, documenti di identità, credenziali di portali, flussi di pagamento e, soprattutto, possibilità di muoversi verso fornitori e partner, alimentando rischi di supply chain e possibili estorsioni.

C2 cifrato e comportamento di rete: porta 3535 e heartbeat ravvicinati

Securonix descrive un canale C2 basato su MessagePack per serializzazione, con cifratura AES-256 e controlli di integrità come HMAC-SHA256. Il malware invia pacchetti di “ClientInfo” contenenti HWID, utente e informazioni di sistema e mantiene un heartbeat a intervalli di 10–15 secondi, un ritmo compatibile con esigenze di controllo interattivo. La presenza di una porta dedicata come 3535 e domini dinamici associati alla famiglia è un pattern utile per detection, ma la vera criticità è che, in molte reti hospitality, le egress policy sono permissive e consentono traffico outbound generico. In quel contesto, la RAT può vivere a lungo.

Indicatori tecnici e tracce utili per hunting

Gli indicatori descritti includono file come v.proj, staxs.exe, tybd7.exe, update.lnk, DeleteApp.url, pins.dat, insieme a domini come 2fa-bns.com e infrastrutture C2 correlate. Anche quando gli hash cambiano, la catena lascia segnali ricorrenti: download in %ProgramData%, uso anomalo di msbuild.exe, avvio di PowerShell da Run, creazione di .url in Startup e tentativi di modifica delle impostazioni Defender. Sul lato endpoint, un elemento ad alto valore è l’abuso di processi “insospettabili” per injection, ad esempio aspnet_compiler.exe, perché in ambienti non developer la sua presenza e attività possono risultare anomale.

Perché hospitality è un bersaglio perfetto

Hotel e catene hospitality hanno tre caratteristiche che rendono queste campagne devastanti. La prima è l’alta rotazione di personale e la pressione operativa: la social engineering “vince” più spesso. La seconda è la presenza di sistemi eterogenei, spesso con postazioni condivise e policy permissive. La terza è l’esposizione di dati monetizzabili: carte, documenti, prenotazioni, email e credenziali di portali.

Leggi il report completo di Securonix

Inoltre, l’hospitality vive di fornitori: channel manager, sistemi di booking, servizi di pagamento, manutenzione IT. Una singola RAT può diventare un punto di partenza per colpire un’intera filiera.

Mitigazione: cosa blocca davvero Phaltblyx

La prima barriera è culturale e procedurale: rendere esplicito che nessun dipendente deve mai incollare comandi in Win+R a seguito di istruzioni ricevute da pagine web. Questo punto, da solo, spezza ClickFix. La seconda barriera è tecnica: abilitare PowerShell logging, soprattutto la visibilità su script block, e monitorare eventi associati all’esecuzione anomala. La terza è il controllo sui binari living off the land: msbuild.exe deve essere monitorato quando viene eseguito da directory non standard e quando scarica o compila file in percorsi come ProgramData. La quarta barriera è difensiva: proteggere e monitorare modifiche a Windows Defender, in particolare tentativi di disattivazione e aggiunta di esclusioni. Infine, rafforzare egress filtering e bloccare domini e pattern noti riduce la capacità del malware di mantenere un canale C2 stabile.

Domande Frequenti su Phaltblyx malware