Malware imgaaa.net: file index alterati e accessi da verificare

Questo articolo descrive un episodio già riportato sul blog con il riferimento “imgaaa.net”: venivano aggiunte stringhe ai file index e comparivano directory con molti file non riconosciuti. Quegli elementi descrivono il caso osservato, non una firma sufficiente per identificare ogni infezione. Il riferimento storico non dimostra che un’eventuale segnalazione attuale abbia la stessa origine.

Se il tuo hosting segnala malware, segui prima la guida su cosa fare subito quando un sito è hackerato. Qui vediamo come leggere gli indizi del caso senza trasformarli in cancellazioni automatiche.

Quali modifiche erano state segnalate nel caso imgaaa.net

Il resoconto originale riportava tre elementi:

• aggiunta di una stringa in coda ai file index;
• creazione di una directory .log con numerosi file;
• comparsa di una directory dal nome numerico con altri file.

Questi nomi non bastano a stabilire se una directory sia dannosa. Cartelle di log, file numerici e script aggiunti possono avere anche usi legittimi. Bisogna confrontarli con il funzionamento previsto del sito, il contenuto dei file e le modifiche autorizzate.

Nel testo originale era ipotizzata la sottrazione delle credenziali FTP, eventualmente attraverso un dispositivo compromesso. Le informazioni riportate non consentono di dimostrare quel punto d’ingresso: va trattato come ipotesi da verificare, non come causa accertata.

Come verificare gli accessi FTP e il perimetro coinvolto

Chiedi al provider quali log conserva, quali file hanno generato l’allarme e se altri siti sullo stesso account presentano anomalie. Confronta orari delle modifiche, trasferimenti e accessi disponibili; registra anche i limiti dei dati raccolti.

Se una credenziale può essere stata esposta, proteggi l’account da un dispositivo affidabile e concorda la revoca degli accessi interessati. Quando l’hosting lo supporta, usa SFTP per proteggere il trasferimento e le credenziali in transito. Il cambio di protocollo non elimina però una backdoor già presente e non protegge da un dispositivo che cattura le credenziali prima della connessione.

Una scansione del computer usato per amministrare il sito può rientrare nei controlli, ma non sostituisce l’analisi dell’ambiente hosting.

Perché non cancellare in blocco cartelle .log e file index

Prima della bonifica, conserva copie protette dei file e dei log disponibili, separate dai backup destinati al ripristino. Se il danno è in corso, coordina questa raccolta con il contenimento richiesto all’hosting.

La bonifica deve rimuovere le modifiche malevole verificate e chiudere gli accessi che le hanno rese possibili. Eliminare tutti i file con un certo nome può distruggere contenuti utili e lasciare intatto il meccanismo che ricrea quelli dannosi.

Quali conseguenze verificare prima della riapertura

Controlla le pagine interessate, i redirect, gli account e le attività pianificate. Se il sito ha distribuito contenuti dannosi, verifica le segnalazioni dei servizi coinvolti e richiedi le revisioni necessarie dopo la risoluzione del problema.

Nel caso di spam visibile nei motori di ricerca, il resoconto sui testi giapponesi e cinesi nei risultati Google tratta un sintomo differente. Non assumere che tutte le alterazioni derivino dallo stesso malware.

Se trovi modifiche analoghe, posso valutare il perimetro partendo dal CMS e dalle evidenze disponibili. Puoi consultare i servizi di assistenza Joomla e assistenza WordPress, indicando nella richiesta gli avvisi ricevuti senza allegare credenziali.

Ti auguro buona lettura e mi raccomando, se dopo aver letto questo articolo hai bisogno di aiuto non esitare a contattarmi.

Autore: Graziano De Maio | Titolare di Gdmtech