Campagna malevola su NGINX e pannello Baota
Una campagna malevola sta sfruttando configurazioni di NGINX e del pannello hosting Baota per intercettare e reindirizzare traffico web verso infrastrutture controllate dagli attaccanti, compromettendo affidabilità e integrità delle sessioni utente, con impatti diretti su brand, utenti finali e catene di fornitura digitali.
Bersagli e domini nel mirino degli attaccanti
Gli aggressori prendono di mira installazioni NGINX esposte su Internet e ambienti gestiti tramite il pannello Baota (BT), molto diffuso nel mercato asiatico.
Il focus riguarda domini con TLD come .in, .id, .bd, .th, oltre a siti con domini .gov e .edu, inclusi portali governativi e istituzioni educative.
Questa scelta massimizza l’impatto del dirottamento, consentendo campagne di sorveglianza, frodi pubblicitarie, furto di credenziali e potenziale manipolazione di contenuti e transazioni, sfruttando la fiducia implicita legata a enti pubblici e accademici.
Perché le manomissioni restano poco visibili
La campagna non sfrutta una vulnerabilità di NGINX, ma modifica direttamente i file di configurazione, operando come un amministratore legittimo.
L’uso della direttiva proxy_pass e di regole di rewrite “normali” rende il traffico apparentemente conforme alle policy di bilanciamento esistenti, riducendo alert di sicurezza automatici.
Poiché le configurazioni vengono revisionate meno spesso rispetto alle patch software, i blocchi malevoli possono restare attivi per lunghi periodi, soprattutto in contesti dove la gestione è delegata a pannelli come Baota e manca un controllo puntuale delle modifiche.
Tecniche di iniezione e abuso di proxy_pass
Il cuore della campagna consiste nell’iniezione di blocchi location malevoli all’interno di configurazioni già operative di NGINX, sfruttando direttive di proxy legittime per deviare quote selezionate di traffico verso domini sotto controllo degli attaccanti.
Blocchi location malevoli e riscrittura URL
Gli script inseriscono blocchi location che intercettano richieste verso percorsi URL scelti, spesso legati a pagine ad alto valore come login, pagamenti, aree riservate o risorse statiche molto richieste.
Le regole riscrivono l’intero URL e lo inoltrano a backend esterni tramite proxy_pass, mantenendo in apparenza il funzionamento del sito originale.
Questo approccio consente di dirottare solo una porzione mirata del traffico, riducendo errori evidenti e rendendo complessa la diagnosi, specialmente in ambienti con molte virtual host e configurazioni stratificate nel tempo.
Preservazione header per eludere controlli
Per non generare anomalie visibili lato applicazione, gli aggressori preservano header chiave come Host, X-Real-IP, User-Agent e Referer nelle richieste inoltrate.
Questo fa apparire ai log applicativi un traffico coerente con quello legittimo, oscurando la presenza di un hop intermedio gestito dagli attaccanti.
La conservazione degli header contribuisce anche ad aggirare controlli di sicurezza basati su IP sorgente, user agent o provenienza delle richieste, rendendo indispensabile un’analisi dettagliata a livello di configurazione e flussi di rete.
Toolkit automatizzato e strategie di difesa
La campagna risulta supportata da un toolkit multi‑stadio che automatizza discovery, compromissione e ricognizione dei server, con una catena di script in grado di adattarsi a diverse strutture di configurazione NGINX e alla presenza del pannello Baota.
Funzionamento del toolkit e ricognizione dei domini
Gli script scaricano ed eseguono componenti successivi, puntando inizialmente alle configurazioni gestite da Baota e ampliando poi la scansione a directory come sites-enabled, conf.d e sites-available.
Sono previsti controlli per evitare corruzioni, inclusa la validazione con nginx -t prima del reload, così da mantenere il servizio operativo e non destare sospetti immediati.
In fase finale, il toolkit mappa domini dirottati, template di iniezione e target di proxying, esfiltrando queste informazioni verso un server di comando e controllo per ulteriori abusi o ottimizzazioni della campagna.
Raccomandazioni operative per amministratori
Gli esperti raccomandano audit regolari dei file di configurazione NGINX, cercando direttive proxy_pass inattese, logiche di rewrite sospette e riferimenti a domini non autorizzati.
È essenziale applicare controllo di versione alle configurazioni, abilitare il logging dettagliato delle modifiche tramite sistemi di configuration management e limitare l’accesso amministrativo al pannello Baota con autenticazione forte.
Monitorare deviazioni nei pattern di traffico e nei record DNS, insieme a controlli di integrità automatizzati sui file di configurazione, aiuta a individuare tempestivamente manomissioni e a ridurre la finestra di esposizione.
FAQ
Qual è il rischio principale per i siti che usano NGINX
Il rischio principale è il dirottamento silente del traffico verso server controllati dagli attaccanti, con possibili furti di credenziali, sessioni, dati sensibili e manipolazione di contenuti senza evidenti interruzioni del servizio.
Perché il pannello Baota è particolarmente esposto
Baota centralizza la gestione di siti e configurazioni, diventando un singolo punto di compromissione: chi lo controlla può modificare in massa le configurazioni NGINX senza passare da procedure di revisione standard.
Come riconoscere blocchi location sospetti nelle configurazioni
Bisogna cercare blocchi location che puntano a domini esterni sconosciuti, pattern di URL non documentati o regole di rewrite non allineate alle esigenze applicative note, confrontando sempre con la baseline autorizzata.
Quali log controllare per evidenziare un dirottamento
È utile analizzare access log e error log di NGINX, log applicativi e, se presenti, log del pannello Baota, verificando variazioni nei backend raggiunti, nei codici di risposta e nelle catene di proxying.
Quali misure preventive implementare subito
Implementare backup e versioning delle configurazioni, accessi amministrativi limitati e monitorati, autenticazione forte, scansioni periodiche per direttive proxy_pass estranee e test di integrità automatizzati sui file.
Chi ha scoperto e documentato questa campagna malevola
L’analisi tecnica della campagna e delle sue fasi operative è stata condotta e resa pubblica dai ricercatori di Datadog Security Labs, che hanno fornito dettagli su tecniche, obiettivi e raccomandazioni difensive.
Our Fact Checking Process
We prioritize accuracy and integrity in our content. Here's how we maintain high standards:
- Expert Review: All articles are reviewed by subject matter experts.
- Source Validation: Information is backed by credible, up-to-date sources.
- Transparency: We clearly cite references and disclose potential conflicts.
Our Review Board
Our content is carefully reviewed by experienced professionals to ensure accuracy and relevance.
- Qualified Experts: Each article is assessed by specialists with field-specific knowledge.
- Up-to-date Insights: We incorporate the latest research, trends, and standards.
- Commitment to Quality: Reviewers ensure clarity, correctness, and completeness.
Look for the expert-reviewed label to read content you can trust.