Chiunque abbia un ruolo di sysadmin o similare nel mese di marzo 2021 ha avuto a che fare con le vulnerabilità di Exchange on-prem: magari semplicemente per “patcharle” ed evitare il peggio, oppure per recuperare un sistema compromesso, che era stato attaccato con successo sfruttando proprio una delle vulnerabilità non ancora corrette.
Non andrò a discutere i dettagli delle vulnerabilità e la storia di come siano state sfruttate, Microsoft ne ha già parlato abbondantemente e ci sono anche innumerevoli documenti di terze parti che affrontano la questione. Qui trovate le linee guida di Microsoft per prevenire e rimediare eventuali problemi.
Mi voglio concentrare invece sul ripristino di un server Exchange compromesso, che mi ha insegnato qualcosa in più sulle tecniche di persistenza del malware, ossia come il malware prova ad evitare di essere rimosso, e su come porvi rimedio.
Disclaimer importante: il mio consiglio, in caso di un server compromesso, è quello di ricostruire un nuovo sistema da zero e migrare i dati. E’ impossibile determinare con sicurezza il livello di compromissione di un sistema dopo che un aggressore ha potuto eseguire del codice a suo piacere per giorni e giorni. Rimettere in servizio una macchina del genere è un rischio molto elevato. Tuttavia, un cliente a volte non vuole “sentire ragioni” e bisogna fare di necessità virtù (ahimè).
La storia inizia abbastanza comunemente: ricevo una chiamata per un server Exchange 2013 che non funziona bene e dopo poco non solo mi accorgo che il server non ha le patch richieste per le vulnerabilità di marzo 2021, ma che è anche privo di antivirus o altro software di sicurezza. Un’altra verifica mi conferma che il server è stato compromesso e passo quindi alla messa in sicurezza del sistema, facendo subito girare il MSERT di Microsoft ed aggiornando in seguito Exchange, con la ultima CU disponibile (la 23 di Exchange 2013, richiesta per l’installazione delle patch) e quindi la KB5000871, che risolve i problemi di sicurezza.
Il server risulta comunque gravemente compromesso, purtroppo anche dal cryptominer Lemon Duck:
Lemon Duck è un cryptominer che sta sfruttando ampiamente in questi giorni (marzo/aprile 2021, N.d.A.) gli Exchange compromessi per le attività di mining, potete trovare qui tutti i dettagli tecnici forniti da Microsoft.
Dopo il reboot, il server appare “sano”, ma tendo a non fidarmi molto e come prima cosa chiedo di far installare subito un antivirus, che poco dopo l’installazione inizia a mandare avvisi abbastanza preoccupanti:
Il processo W3WP.EXE (il worker process di IIS, sfruttato via PowerShell probabilmente da Lemon Duck) continua a provare a depositare dll con nome randomico nella cartella C:\Windows\temp ; in più viene rilevata un’altra dll “maligna” di un altro trojan. Direi che non ci siamo.
Altra cosa che non va, il sistema di filtraggio del traffico web dell’antivirus ogni ora manda un avviso di blocco per tre tentativi di accesso a siti con contenuto malevolo, legati a Lemon Duck, sempre via PowerShell. E’ probabilmente il tentativo per scaricare un payload:
L’antivirus fa il suo lavoro e rimuove a quel punto quello che può, ma decido comunque di far fare un nuovo giro al MSERT di Microsoft ed il secondo scan trova un’altra web shell, per qualche motivo non rilevata prima:
Rimossa anche questa web shell, il server potrebbe essere “al sicuro” (per modo di dire…), anche se Lemon Duck non dovrebbe usare web shell per i suoi attacchi e non credo che le cose siano correlate. L’antivirus però continua a mandare ogni ora, nei minuti dal 50 al 59, i tre avvisi di tentativo di download del payload maligno di Lemon Duck: c’è qualcosa di pianificato quindi che sta provando.
Tutti gli scheduled task impiantati dai malware sono stati correttamente rimossi, dai tool e da me in alcuni casi, non c’è nulla di sospetto. Una analisi più approfondita però svela il sistema usato da Lemon Duck per garantirsi la “persistenza” sui sistemi compromessi: WMI Event Subscription. In pratica, l’attaccante sfrutta la WMI (Windows Management Instrumentation) di Windows per impiantare un trigger che esegue del codice ogni volta che un certo evento si verifica.
Usando Autoruns di Sysinternals/Microsoft, andando alla voce WMI (dopo aver disattivato nel menu Options la voce “Hide Microsoft Entries”, importante!), trovo facilmente le entry nel database WMI della macchina, con il comando di PowerShell che prova a scaricare il payload maligno ogni ora:
Un bel post di David French su Medium affronta approfonditamente la questione delle event subscription WMI, vi consiglio di leggerlo.
A questo punto, per rimuovere le event subscription con Autoruns basta un click col destro e quindi “delete” su ogni voce. Le attività sospette ora sembrano azzerate e posso per far riprendere le normali attività al server: ripeto però ancora una volta che la cosa più saggia in questo caso sarebbe stato creare un nuovo server e migrare i dati. La macchina è stata compromessa in modalità FUBAR … e – se fosse dipeso da me – la avrei messa offline permanentemente.
Se dovete mettere le mani su un server Exchange compromesso, non fidatevi al 100% dei tool automatizzati, anche di Microsoft, e fate un controllo approfondito “a mano”, ne può valere la pena.
