SOC Prime Bias: Alto

12 Jun 2026 06:33 UTC

Analisi Tecnica di Email Sospette Mirate all’Industria Alberghiera

Author Photo
SOC Prime Team linkedin icon Segui
Analisi Tecnica di Email Sospette Mirate all’Industria Alberghiera
shield icon

Detection stack

  • AIDR
  • Alert
  • ETL
  • Query

Riepilogo

Una sofisticata campagna di malware a più fasi sta prendendo di mira il settore alberghiero attraverso email camuffate da notifiche di Booking.com. La catena di intrusione combina file LNK dannosi, script PowerShell e un trojan di accesso remoto basato su Node.js noto come TonRAT. Uno degli aspetti più notevoli dell’operazione è l’uso dell’API di The Open Network (TON) per ottenere dinamicamente i domini di comando e controllo, il che rende meno affidabile il blocco tradizionale basato sui domini.

Indagine

L’indagine ha scoperto un flusso di esecuzione a strati in cui un archivio ZIP iniziale contiene un file LNK che avvia PowerShell per recuperare uno script secondario. Quello script decritta un payload JavaScript identificato come TonRAT utilizzando AES e lo esegue attraverso un runtime Node.js legittimo scaricato da nodejs.org. Una volta attivo, il malware inizia comunicazioni di comando e controllo basate su WebSocket utilizzando informazioni di dominio prelevate dalle richieste API del blockchain TON.

Mitigazione

Le difese raccomandate includono la restrizione dell’esecuzione di PowerShell, il monitoraggio attento per l’uso non autorizzato del runtime Node.js (node.exe), e il rilevamento del traffico WebSocket anormale. Le organizzazioni dovrebbero anche sorvegliare le connessioni all’API TON, inclusa tonapi.io, e rafforzare il filtraggio delle email per catturare domini falsificati, allegati sospetti e esche di phishing rivolte al personale alberghiero.

Risposta

Se si sospetta una compromissione, i team di sicurezza dovrebbero isolare immediatamente il punto finale interessato per prevenire ulteriore traffico di comando e controllo e possibile esfiltrazione di dati. I log operativi di PowerShell e i record di esecuzione dei processi dovrebbero essere controllati per attività node.exe non autorizzata. Dovrebbe anche essere eseguita una verifica forense per gli hash JavaScript noti di TonRAT, insieme all’indagine su eventuali connessioni all’infrastruttura di comando e controllo identificata.

Flusso di Attacco

Esecuzione della Simulazione

Prerequisito: Il Controllo Preliminare di Telemetria & Baseline deve essere stato superato.

Rationale: Questa sezione dettagliatamente l’esecuzione precisa della tecnica dell’avversario (TTP) progettata per attivare la regola di rilevamento. I comandi e la narrazione DEVONO riflettere direttamente i TTPs identificati e mirare a generare esattamente la telemetria prevista dalla logica di rilevamento. Esempi astratti o non correlati porteranno a una diagnosi errata.

  • Narrazione & Comandi dell’Attacco: L’avversario mira a stabilire un canale di Comando e Controllo (C2) basato su WebSocket. Per confondersi con il traffico legittimo, il malware prima interroga il tonapi.io servizio per risolvere la sua infrastruttura C2. Una volta stabilita l’interazione “legittima” con l’API, il malware avvia una stretta di mano WebSocket (wss://) al dominio malevolo hardcoded zloapobikahy23.bond. Questa sequenza è progettata per sfruttare la reputazione dell’API TON per mascherare la successiva connessione malevola.

  • Script di Test di Regressione:

    # Simulazione di Comunicazione C2 WebSocket TonRAT
    # Passo 1: Simulare l'interazione con l'API TON
    Write-Host "[+] Simulazione dell'interazione con tonapi.io..."
    $api_url = "https://tonapi.io/v2/blockchain/accounts/EQ..."
    Invoke-WebRequest -Uri $api_url -Method Get -UseBasicParsing
    
    # Passo 2: Simulare la connessione WebSocket al dominio C2 malevolo
    # Nota: Utilizziamo un client PowerShell per iniziare una richiesta WSS per attivare la logica 'wss://' e del dominio
    Write-Host "[+] Simulazione della connessione WebSocket al dominio malevolo..."
    $c2_url = "wss://zloapobikahy23.bond/control"
    
    # Utilizzando un client WebSockets .NET per garantire che 'wss://' sia presente nella telemetria
    $ws = New-Object System.Net.WebSockets.ClientWebSocket
    $cts = New-Object System.Threading.CancellationTokenSource
    $uri = New-Object System.Uri($c2_url)
    
    try {
        $task = $ws.ConnectAsync($uri, $cts.Token)
        # Non ci serve una connessione riuscita, solo il tentativo per generare il log
        $task.Wait(5000) 
    } catch {
        Write-Host "[!] Connessione fallita come previsto (il dominio non esiste), ma la telemetria dovrebbe essere generata."
    } finally {
        $ws.Dispose()
    }
  • Comandi di Pulizia:

    # Non vengono creati artefatti persistenti da questo script, ma svuotiamo la console
    Clear-Host
    Write-Host "Completa la pulizia della simulazione."