No results found
La massiccia informatizzazione e soprattutto l’utilizzo delle reti locali e Internet espone sempre più le infrastrutture IT ai rischi legati agli attacchi informatici portati dall’esterno; in questo tutorial verrà spiegato come rilevarli anche da piccoli segnali e anomalie che spesso passano inosservati, ma che se vengono riconosciuti possono consentire di anticiparne “le mosse” e limitare o prevenire i danni.
Per introdurre il discorso partiamo subito con una domanda: “che cosa hanno in comune Facebook, Sing Health e British Airways?”. Di primo acchito risponderemmo: “nulla”. In realtà qualcosa, ossi un evento infausto, le accomuna: a Facebook sono stati rubati i contatti personali di 15 milioni di utenti, a Sing Health sono state sottratte le cartelle cliniche di 1,5 milioni di pazienti e a British Airways i dati personali di 380 mila passeggeri.
Insomma, tutte e tre hanno subito eclatanti Cyber Attack.
Per aggirare o arrestare tali insidie, una soluzione potrebbe essere rilevare i segnali di un Cyber Attack in tempo e per poterlo fare occorre:
Quindi è essenziale prima definire il modello è poi andare a cercare di capire quali sono questi segnali che ci fanno comprendere che stia avvenendo un attacco.
Per quanto riguarda la definizione della Cyber Attack Chain, innanzitutto diamo alcune definizioni: la prima quella di Cyber Attack Risk, che praticamente è il rischio che un’azienda sia è colpita da un Cyber Attack con conseguente perdita di dati, di reputazione e con compromissioni di varia natura.
Innanzitutto cioè noi in qualche modo cercheremo di lavorare con questo Cyber Attack cercheremo di mitigarlo e questo poi ci aiuterà quindi definire quella che è la nostra Cyber Attack Chain, o meglio allo scopo di gestire il Cyber Risk, introduce il concetto di Cyber Attack Chain; quindi Cyber Risk e Cyber Attack Chain sono strettamente legati tra loro.
Cyber Attack Chain è quel modello che definisce degli schemi comuni che gli attaccanti tendono a prescindere da uno specifico contesto cui l’attacco va portato. Quindi ci saranno contesti e situazioni infrastrutturali differenti, ma la sequenza di passaggi è comune a tutti gli attaccanti.
Un esempio di tale modello è la Mitre Matrix, la quale è una rappresentazione sotto forma di matrice che sintetizza in 11 punti il comportamento tipico di un attaccante; la matrice è formata nelle colonne dai vari passi che l’attaccante tende a seguire sempre e poi per ognuna delle righe c’è lo specifico vettore d’attacco. Ovviamente ogni attacco avrà le proprie caratteristiche in base a cosa punta: ci sarà un dettaglio molto specifico.
La matrice è abbastanza complessa, quindi ci limiteremo ad analizzare alcuni passi significativi per il modello che prenderemo a riferimento; la matrice è formata da 11 colonne e analizziamo 5 passi, che sono:
Il primo (External Reconaissance) corrisponde alla fase in cui l’attaccante Indaga su un bersaglio al fine di identificare eventuali vulnerabilità; quindi è la fase di un Ciber Attack dove l’attaccante cerca di raccogliere tutte le informazioni la fase di Information Gathering, in cui semplicemente si indaga per ottenere più informazioni possibile.
Una volta che l’attaccante avrà identificato le vulnerabilità cercherà di sfruttarle per accedere alla rete bersaglio, ossia andare alla fase dell’intrusione (Intrusion).
Ovviamente non è che tutte le vulnerabilità trovate siano sfruttabili ai fini dell’intrusione nell’infrastruttura target, perché alcune lo sono e altre no, ma lo scopo è accedere alla rete bersaglio.
Nella fase seguente, ossia Lateral Movement, l’attaccante è all’interno della rete, quindi è riuscito a sfruttare una vulnerabilità e adesso quello che cercherà di fare sarà muoversi lateralmente nella rete; ovviamente l’attaccante arriverà all’interno di una sottorete e da qui il suo scopo sarà muoversi all’interno delle altre sottoreti, così da ottenere più informazioni possibile in modo da fare quella che è la fase Command and control: qui l’attaccante si prepara per comunicare con l’esterno, allo scopo di portare all’esterno dell’azienda cui corrisponde la rete target i dati che è riuscito a trovare.
Quindi questa è la fase di comando dall’esterno, dove un’entità dall’esterno, che può essere un server o comunque qualcosa di simile, si prepara a comunicare e nella quinta fase (Execution) andrà a inviare all’esterno i dati sensibili carpiti e qui l'attacco viene completato.
Abbiamo quindi definito il Cyber Attack Chain in cinque fasi e questo è il primo punto importante; una volta definito questo, poi possiamo andare a comprendere quali sono i segnali rivelatori del Cyber Attack, così da andarli a cercare.
In ognuna delle fasi suaccennate, le attività svolte dall’attaccante forniscono delle evidenze rilevabili sotto determinate condizioni e che possiamo rilevare in tempo; quindi queste evidenze vengono lasciate all’interno della Cyber Attack Chain, a partire dall’Information Gathering fino ad arrivare all’Execution finale.
Ora il problema è che la maggior parte delle aziende tende a non considerare oppure ignorare questi segnali, cioè, nello specifico ci si concentra sui sistemi di sicurezza standard come firewall,
IPS (Intrusion Protection System), IDS (Intrusion Detection System) SIM (Security Information and Event Management) ma non prestano la dovuta attenzione a questi piccoli segnali che poi in verità sono molto importanti, perché saranno quelli che ci permetteranno di identificare un Cyber Attack in tempo.
Quindi, una volta definita la Cyber Attack Chain possiamo determinare i Cyber Attack Signal; innanzitutto va specificato che si tratta dei segnali indicanti che è che indica che è in corso un Cyber Attack, ossia che una delle fasi della Cyber Attack Chain è in corso. Tutti questi segnali si trovano all’interno di questo modello e necessariamente saranno una delle cinque fasi esposte.
Ignorare questi segnali aumenta il Cyber Attack Risk.
Adesso abbiamo definito tutti gli attori in gioco: abbiamo definito il Cyber Attack Risk e la Cyber Attack Chain ed ora andremo effettivamente a capire quali sono segnali da valutare. Il primo segnale è il Vulnerability Pathing Time, che è la finestra temporale che intercorre tra quando la vulnerabilità è resa nota e quando viene implementata la relativa patch; il concetto è che da quando una vulnerabilità viene resa pubblica intercorre una certa quantità di tempo prima che venga implementata la patch o installata.
Un eventuale attaccante potrebbe quindi approfittare di questa vulnerabilità prima che vi si ponga rimedio.
Un possibile rimedio è cercare di applicare le patch nel più breve tempo possibile, oppure se comunque non fosse possibile implementare un workaround efficace e subito applicabile. Quindi bisogna cercare di essere sempre informati sulle nuove vulnerabilità e appena una di queste potrebbe essere relativa ai nostri sistemi cercare di applicare la patch o comunque implementare un workaround.
Passiamo al secondo segnale che è la presenza di una Web Shell: è praticamente una porzione di codice malevolo che viene utilizzato dall’attaccante allo scopo di accedere in remoto ad un web server ed acquisirne il controllo in ogni momento; quindi quello che l’attaccante fa è iniettare nella rete in qualche modo questa porzione di codice, così da ottenere il controllo del web server e a quel punto impartire i più svariati comandi all’interno del server per controllarlo.
Questo questo segnale si può carpire analizzando i log dei web server al fine di individuare comandi sospetti: ad esempio command.exe, IPconfig ecc. (dipende se siamo in ambiente Windows o Linux); quindi andando a esaminare i log in maniera specifica relativa a questi comandi, vale a dire cercando se sono presenti comandi come Ipconfig, che fornisce la configurazione delle schede di rete o anche comandi relativi ad esempio al (che permettono di visualizzare la route table).
Comunque basta andare proprio a filtrare questi comandi così da individuarli e se ci sono dei comandi sospetti bisogna capire chi li ha lanciati e fare delle analisi più approfondite.
Altra attività di ricerca dei segnali è controllare se è presente un trasferimento di dati anomalo con un eccessivo numero di richieste di tipo GET; quindi ancora una volta andiamo nei log e se vediamo in un arco temporale ristretto una quantità di decine e decine di richieste GET questo è un chiaro segnale che in qualche modo chi sta effettuando un attacco vuole ottenere delle informazioni dal web server.
Ancora, si può andare a verificare se sono presenti numerosi tentativi di logon, perché l’attaccante sta tentando un attacco di tipo Brute Force e quindi cerca di fare moltissimi tentativi di logon cercando di trovare le credenziali per tentativi.
Per quanto riguarda gli eventi di logon, arriviamo al terzo segnale: gli attuali sistemi di difesa IDS e IPS spesso si focalizzano maggiormente sul traffico di rete e non sono in grado di distinguere, perlomeno in maniera precisa, i tentativi di logon legittimi da quelli malevoli; questo perché nella situazione ipotetica in cui l’attaccante ha rubato le credenziali per accedere ai sistemi, ovviamente avrà delle credenziali legittime che normalmente gli utenti abilitati utilizzano per accedere ai sistemi. Però se l'attaccante utilizza queste credenziali legittime per accedere da e verso location che sono differenti da quelle normalmente utilizzate, ecco che abbiamo un comportamento anomalo da considerare come segnale.
Quindi da una parte abbiamo delle credenziali legittime, ma dall’altra parte con queste credenziali legittime accediamo a delle sottoreti che normalmente non utilizzeremmo e ciò rappresenta un segnale da non trascurare.
Inoltre è necessario monitorare con attenzione tutti gli accessi verso sistemi critici dell’azienda, così da rilevare eventuali tentativi di accesso sospetti; questo punto è molto importante perché all’interno di un’azienda ci saranno decine e decine di macchine tra server workstation, perciò quello che dobbiamo fare è individuare gli asset critici che potrebbero essere i database, i Web Server e i Domain Controller e tutti questi sistemi critici, di cui monitorare attentamente gli accessi. Quindi concentrarsi su queste poche macchine, però tenerle sotto controllo in maniera abbastanza intensa.
Passiamo al quarto segnale: gli utenti con privilegi elevati. Il fatto è che un attaccante una volta che è riuscito ad accedere all’interno della rete cercherà di elevare i propri privilegi ossia di effettuare la Privilege Escalation; quindi l'attaccante che magari è entrato all’interno della nostra rete come utente standard, avrà bisogno di eseguire comandi più specifici, ossia comandi possano fornire all’esterno maggiori informazioni e quindi avrà necessità di elevare i propri privilegi per effettuare delle azioni che richiedono, appunto, privilegi di root e admin.
Come si può rilevare, anche in questo caso dobbiamo cercare degli eventi che si discostano da quello che è il comportamento tipico di tali utenti con elevati privilegi, quindi innanzitutto dobbiamo capire realmente cosa fanno gli utenti che hanno questi privilegi elevati e quali sono le azioni corrispondenti. Quindi dobbiamo innanzitutto fare un’analisi accurata e una volta fatta questa analisi possiamo cercare tutti quegli eventi che si discostano dalla normalità; alcuni esempi sono il numero di eventi di logon, la durata dell’accesso, le attività che vengono svolte e gli accessi da altri sistemi. Questi sono fattori da considerare.
Passiamo al quinto segnale, che è la gestione anomala del WMI (Windows Management Instrumentation) che permette agli amministratori di sistema di effettuare attività di gestione sia in locale che da remoto; dal momento che viene normalmente utilizzato per l’esecuzione di comandi di trasferimento di file, per leggere file e chiavi di registro, per esaminare filesystem e per esaminare gli eventi, si utilizza normalmente per questo genere di operazioni.
Il problema è che l’eventuale attaccante cercherà senz’altro di utilizzare tale strumento per i suoi scopi.
Come si può rilevare ciò? Anche in questo caso, ad azioni compiute tramite WMI corrispondono degli alert e dei log che è possibile esaminare, quindi dobbiamo esaminarli, cercare di fare un’analisi iniziale così da individuare comandi sospetti o comunque dei comportamenti anomali.
Allora vediamo alcuni esempi sempre legati al WMI che indicano che ci potrebbe essere un’attività sospetta in corso: il primo di questi è l’Instance Creation Event e quando vediamo questo evento nel WMI significa che l’attaccante tenta di utilizzare quest’ultimo come meccanismo di persistenza. Infatti l’attaccante cercherà sempre tale meccanismo perché il suo obiettivo dell’attaccante non è accedere alla nostra rete una volta sola ma accedere più volte, quindi di avere una certa persistenza all'interno della nostra infrastruttura; quindi questo è un evento importante.
Poi abbiamo il Namespace Creation Event: quando vediamo questo evento c’è la possibilità che l’attaccante stia utilizzando la WMI shell come canale di tipo Command and control Server, quindi se torniamo alla Cyber Attack Chain, qui siamo nella fase di execution, ossia nella fase in cui l’attaccante cercherà di contattare qualcosa all’esterno e perciò il fatto che ci sia questo evento ne è un’evidenza abbastanza significativa.
Il terzo evento su cui ci soffermiamo è il Class Creation Event: in questo caso l’attaccante potrebbe utilizzare il WMI per salvare i propri dati, quindi quando vediamo questo evento dobbiamo analizzarlo. Chiaro che eventi del genere possono essere utilizzati anche per scopi legittimi, quindi non é detto che la loro presenza sia inequivocabilmente segnale di un attacco.
Comunque se facciamo un’analisi mettendolo insieme ad altri fattori diventa abbastanza significativo.
Quarto evento analizzato è win32 Services Classi Instance o Instance Creation event: quando vediamo questi, significa che l’attaccante installa dei servizi sul sistema bersaglio al fine di rimanere persistente: magari sta migrando su un certo servizio o vuole installare questo servizio e tali eventi ne sono segnale evidente.
Adesso passiamo a un nuovo segnale, che è l’Internal Reconaissance: come l’External Reconaissance che abbiamo visto prima è la fase in cui l’attaccante cerca di identificare tutte le vulnerabilità, l’Internal reconaissance è la fase corrispondente in cui l’attaccante è all’interno della rete; se pensiamo alla Cyber Attack Chain ci troviamo nella fase di lateral movement, in cui l’attaccante si muove all’interno delle sottoreti e cercherà di raccogliere più informazioni possibili. Ecco che quindi abbiamo l’Internal Reconaissance.
In sintesi, per Internal Reconaissance si intendono le attività svolte da un attaccante già presente all’interno della nostra rete, finalizzati a raccogliere più informazioni possibili su gli host che ne fanno parte, quindi tenterà proprio di raccogliere informazioni ad esempio enumerando le risorse. Quindi se pensiamo a un Domain controller, cercherà di enumerare il più possibile per ottenere le informazioni sulle workstation e quant’altro; la stessa cosa serve quindi raccogliere le informazioni
Possiamo rilevare questo segnale analizzando eventuali script in esecuzione su web server o su Domain Controller, che eseguono comandi allo scopo di raccogliere screenshot, enumerare delle risorse. Quindi se vediamo tantissimi comandi relativi all’ottenimento di screenshot o il fatto di chiedere a un web server o ad un Domain Controller di enumerare le risorse, questi sono dei chiari segnali che ci spingono ad analizzare la presenza di eventuali script.
Adesso passiamo al settimo segnale: il gruppo di quelli generati da malware e ransomware. Il punto è che essi vanno ad agire su utenti, file processi o task, quindi in qualche modo vanno ad alterarli, alterando quello che possiamo definire uno schema di comportamento standard. Quindi anche qui dobbiamo definire sempre inizialmente un modello e in base ad esso possiamo andare a vedere i comportamenti che vi si discostano.
È sempre necessario procedere con una fase di analisi iniziale perché se non sappiamo qual è il comportamento standard non possiamo sicuramente riuscire a identificare nella maniera corretta tali segnali.
Alcuni esempi sono la creazione di nuovi file con estensione .pky (Public Encryption Key) oppure la creazione di nuovi file con estensione .res, che sono quelli che indicano che c'è una comunicazione command-and-control, oppure la creazione di nuovi file con estensione .eky (Private Encryption Key). Quindi praticamente abbiamo dei file che da una parte ci riportano alla cifratura dei file, quindi le attività svolte da malware, ransomware e dall’altra parte alla comunicazione command and control.
L’ottavo segnale è la presenza di codice malevolo di tipo PowerShell: PowerShell è una potente shell integrata nei recenti sistemi Windows, che grazie a un versatile linguaggio di scripting permette di eseguire molteplici operazioni.
Si tratta di uno strumento normalmente utilizzato dagli amministratori di sistema, che però può essere utilizzato da un potenziale attaccante facendo non pochi danni.
Quello che dobbiamo fare per rilevare l’attacco è esaminare i log e vedere tutte le volte che è stato richiamato powershell.exe e se questo è avvenuto da parte di utenti anomali e soprattutto in orari non standard, perché questo è un chiaro segnale o quantomeno un comportamento sospetto.
Passiamo al nono segnale, rappresentato dagli accessi anomali tramite protocollo RDP (Remote Desktop Protocol); quest’ultimo è normalmente utilizzato per accedere da remoto alle macchine di rete: basta cliccare su Remote Desktop Protocol, inserire l’indirizzo IP della macchina e si accede a quella desiderata.
Quindi un attaccante potrebbe sfruttare questo protocollo per connettersi ad altre macchine della rete che hanno l’RDP abilitato, perciò questo è un protocollo da tenere sotto controllo perché è molto significativo. Possiamo rilevare un attacco se si riscontrano delle connessioni RDP eseguite da utenti anomali; magari il protocollo viene utilizzato dall’help desk o dal team di supporto per accedere e fare assistenza sulle macchine, però se vediamo un utente che di solito non ha necessità di accedere in RDP e invece lo fa perché magari è stato compromesso e quindi viene utilizzato da un attaccante, oppure connessioni RDP da parte di un utente su più sistemi, dobbiamo allarmarci.
Veniamo al decimo segnale: le attività sospette sul protocollo SMB; quest’ultimo, che sta per Server Message Block, è utilizzato in ambienti Windows e permette la condivisione di file, cartelle e stampanti e altre comunicazioni di varia natura. Il problema è che questo protocollo è tristemente famoso perché nel corso degli anni è stato preso di mira dagli attaccanti molto spesso e quindi ovviamente bisogna fare molta attenzione perché è un protocollo un po’ delicato, non a caso gli attaccanti di frequente cercano di effettuare l’exploitation del protocollo SMB.
Quindi come possiamo rilevarlo come segnale? L’uso del comando ps.exec e la condivisione ad esempio di C: o di admin sono dei significativi campanelli d'allarme; pertanto quando rileviamo l’utilizzo di tale comando e comunque la condivisione delle risorse suddette, probabilmente bisogna stare attenti perché potrebbe essere in corso un attacco sul protocollo SMB.
Undicesimo segnale da considerare sono le attività sospette relative ai log. Qui il fatto è che un attaccante cercherà sempre di rimuovere eventuali tracce lasciate, perché lo scopo dell’attaccante è di essere persistente, quindi di poter più volte accedere all’interno della rete bersaglio; se lascia tracce può essere scoperto, pertanto cercherà innanzitutto di rimuovere eventuali tracce lasciate.
Come si rileva questo attacco? Si può perché ogni log che viene rimosso, modificato o alterato e che contiene delle informazioni quali dettagli dell’utente, orario e comando eseguito, è un segno dell’attività malevola in atto. Quindi se questi log che vanno a darci tali informazioni sono eliminati o comunque oggetto di tentativi eliminazione, va considerato come un altro segnale importante.
Dodicesimo segnale è il verificarsi di traffco di rete sospetto: un attaccante arrivato alla quarta fase della Cyber Attack Chain, quindi nella fase di Execution di comunicazione con il Command and control Server e poi di exportation dei dati (quindi il fatto poi di mandare fuori i dati carpiti dalle macchine della rete target), cerca di comunicare con un Command and control. Questo si può rilevare esaminando il traffico di rete, che evidenzierà delle anomalie e scostamenti rispetto allo standard. Quindi si tratta proprio di effettuare un'analisi specifica sul traffico di rete.
Alcuni esempi di cosa andare a cercare sono tutte le richieste DNS verso dei domini anomali che possano indicare l’esistenza una comunicazione con l’esterno, oppure la richiesta di indirizzo IP come Domain Name per un Host o anche la richiesta verso IP Domain Name a intervalli ricorrenti e frequenti. Queste sono tutte attività che in qualche modo vanno a riguardare il traffico di rete, perciò è necessario effettuare un’analisi specifica di un certo tipo di traffico.
Tredicesimo segnale da considerare sono pacchetti di rete di tipo ICMP: il protocollo Internet Control Message Protocol permette di inviare pacchetti di controllo all’interno della rete allo scopo di rilevare eventuali problematiche; un esempio è il comando Ping che normalmente si utilizza per verificare se un determinato IP sia raggiungibile o meno. Però tale protocollo potrebbe essere utilizzato da un attaccante, il quale potrebbe sfruttarlo per scopi diversi da quelli per cui è stato creato.
Alcuni esempi: una dimensione eccessiva del pacchetto ICMP potrebbe indicare che sono presenti dati al suo interno, quindi si va a prendere il pacchetto e nella parte di payload si vanno a inserire dei dati. Ricercando pacchetti ICMP di dimensioni più grandi del normale si puà smascherare l’attacco.
Inoltre una frequenza di pacchetti con tipo di sorgente o destinazioni anomale potrebbe segnalare un movimento di dati in corso o comunque imminente, quindi anche in questo caso bisogna analizzare più nel dettaglio il traffico e ottenere informazioni utili.
In conclusione, gli attuali sistemi di sicurezza ad esempio IDS, IPS e SIEM spesso si dimostrano inefficaci perché magari sicuramente comportano una difficoltà di configurazione; inoltre si deve fare i conti con la difficoltà di formare del personale interno che sappia adeguatamente usare questi strumenti o comunque con gli effetti collaterali come l’eccessivo numero di alert o di falsi positivi.
Quale può essere, quindi, una soluzione? Innanzitutto identificare con esattezza gli asset critici da proteggere, ossia quelli vitali per l’azienda che vanno protetti in maniera assoluta.
Il secondo passo è che per ognuno di questi asset critici dobbiamo identificare tutti i possibili scenari di attacco e questo lo possiamo fare utilizzando il modello che abbiamo visto (Cyber Attack Chain) formato da 5 passi.
Terzo punto è mappare ogni Cyber Attack Signal (quindi quelli che abbiamo visto finora) in ogni fase della Cyber Attack Chain, ossia nelle fasi degli schemi comuni che ripercorrono le fasi di un attacco e poi andiamo a farlo per ogni asset critico.
Praticamente quello che dobbiamo fare è sfruttare i sistemi di sicurezza già presenti (ad esempio il SIEM) come ausilio per identificare ogni Cyber Attack Signal per ogni asset critico; così avremo fatto un’analisi basata sui segnali rapportata alla Cyber Attack Chain per gli asset critici.
A questo punto possiamo andare a configurare in maniera adeguata gli strumenti di sicurezza già presenti in azienda, che così sicuramente ci permettono di ottenere risultati migliori.
