podcast

Sintesi cibernetica #12

Ancora una volta una riflessione che parte dall’incidente di OVH: sono andato a cercare i video con le dichiarazioni di Octave Klaba, fondatore di OVH, in cui, pochi giorni dopo l’ormai famoso incendio, dice:

It seems that globally, the customers … understand what we are delivering, but some customers, they don’t understand what exactly they bought

Considerando la dichiarazione nel suo contesto (qui in parte sintetizzato e spiegato) è chiaro il riferimento al fiume di critiche verso OVH in relazione al non disporre di un piano di Disaster Recovery. In realtà, come è ovvio che sia, è onere dei clienti sottoscrivere servizi di Disaster Recovery e dotarsi di una procedura di attuazione del piano. La frase azzeccatissima di Klaba sulla “non comprensione di cosa esattamente hanno acquistato” può sembrare un po’ cruda ma è tremendamente vera.

La vicenda aiuta a portare alla luce un dato preoccupante: molte organizzazioni ed aziende, anche non piccole come abbiamo visto, stanno affrontando l’era dell’informazione senza una strategia che sia in grado di tutelare il loro business. L’esigenza di una strategia di Disaster Recovery, l’esigenza di un piano per la gestione della sicurezza cibernetica o per la tutela delle informazioni strategiche, è qualcosa che ci si aspetta dal management. I team operativi si possono poi occupare di come implementare queste strategie. Conviene uscire dal modello in cui tutto ciò che è digitale è a carico dell’IT, non è più vero da anni e le conseguenze di queste antiche credenze oggi finiscono sui giornali.

Passo dalla ramanzina ad un tema virtuoso: il crescente interesse da parte dei produttori tecnologia IoT nel rendere i propri device sicuri. L’argomento mi sta particolarmente a cuore occupandomi principalmente di sicurezza informatica e mi ha fatto molto piacere osservare che alcune realtà si stanno concretamente muovendo per approcciare un percorso che le aiuti a produrre device safe and secure.

Il problema ha radici profonde: la pervasività di questi device è un fatto relativamente recete ed i loro utilizzatori non necessariamente hanno maturato una consapevolezza in relazione al livello di sicurezza di oggetti come gli smart device per uso domestico o i sistemi di automazione industriale con i loro sensori, rilevatori ed attuatori.

Ad un certo punto abbiamo semplicemente iniziato ad introdurre nelle nostre vite e nelle nostre aziende oggetti in gradi di dialogare tra loro attraverso reti locali ed attraverso la rete internet. Chi ha progettato le prime generazioni di questi meravigliosi device non era sempre al corrente del contesto e delle minacce che possono essere veicolate attraverso la rete ed ha di fatto prodotti oggetti safe ma non secure.

L’epilogo è noto: il mondo del crimine organizzato ha iniziato ad utilizzare lo strumento degli attacchi informatici per mettere in scacco aziende ed organizzazioni.

Diventa quindi necessario portare la cultura della sicurezza informatica in un mondo che non parlava questa lingua… con l’aggravante che anche chi dovrebbe parlarla ancora oggi fatica a tenere il passo nei confronti delle sempre molto aggiornate tecniche e tattiche di attacco.

Qualche spunto di riflessione nel podcast di domani (29 marzo).

hacking

Esperimento podcast

La riflessione che mi ha portato a valutare il podcast è che non tutti hanno il tempo di leggersi con calma uno o più articoli anche se molto corti. E’ un tema di contesto: chi si sposta con un mezzo pubblico potrebbe facilmente ritagliarsi uno spazio quotidiano di aggiornamento sul tema di interesse, mentre chi abitualmente utilizza l’auto ha dei vincoli oggettivi e deve eventualmente definire uno spazio di lettura in un momento che probabilmente è già allocato dalle attività del day-by-day.

Ho quindi pensato di proporre un podcast partendo direttamente con una rubrica settimanale, che ho chiamato Sintesi Cibernetica, spazio di 7-10 minuti dedicato a pochi temi che hanno catturato la mia attenzione nel corso delle settimana appena trascorsa.

Inizialmente avevo valutato un’uscita il venerdì pomeriggio per poi passare alla domenica. Un mix di cause hanno portato al cambio di giornata: vorrei essere costante ed il venerdì non è sempre un giorno semplice, inoltre ho avuto la sensazione ci fosse una bassa propensione all’attenzione. La domenica è diventato il giorno ufficiale e dopo i primi due episodi mi sento di confermarlo.

Primi feedback: contenuti buoni, tono di voce troppo basso. Altri suggerimenti spaziano dal mettere un sottofondo musicale al creare una sigla standard. Devo rifletterci un po’ su, non amo particolarmente la sovrastruttura in un progetto che ha come l’informare al fine di avviare delle riflessioni in chi vi si imbatte.

Oggi la terza puntata. Devo selezionare i temi.

hacking

Dove la rete satellitare “tocca” Internet

Come avevo accennato in un podcast di qualche giorno fa, uno dei temi di ricerca che sto portando avanti ha a che fare con le comunicazioni satellitari, o per meglio dire riguarda le tecnologie che ci consentono di comunicare con e tramite i sistemi satellitari.

Potrebbe sembrare un tema distante ma in questa epoca storica è in corso una vera e propria rivoluzione in merito a ciò che stiamo mandando in orbita bassa e a come possiamo utilizzare questi oggetti. Qualche nota di contestualizzazione è doverosa per comprendere il tema.

Scenario

Per prima cosa va detto che i satelliti moderni posso essere anche molto piccoli: esistono diverse aziende che producono e lanciano mini satelliti delle dimensioni di pochi centimetri ed equipaggiati con non poca tecnologia per la rilevazione e la comunicazione a terra (personalmente seguo il progetto CubeSat nato presso l’Università Politecnica della California). Parallelamente grazie a progetti come il celeberrimo SpaceX (e ne stanno arrivando altri) i costi per mandare asset in orbita si stanno riducendo enormemente.

L’ovvia conseguenza è un aumento del “traffico” in orbita bassa, ovvero in quella regione attorno al nostro pianeta in cui vengono tipicamente collocate le costellazioni di satelliti per le comunicazioni, il tracciamento della posizione e rilevamenti di ogni tipo, per uso civile, commerciale e militare.

Da quando i satelliti sono diventati uno strumento anche ad uso civile, se un’azienda ha bisogno di eseguire un determinato tipo di rilevamento o deve comunicare, ad esempio, con la propria flotta navale/aerea/stellare (Starfleet, cit.) si può rivolgere ad un ente che si occupa di lanciare e gestire i propri satelliti tramite cui eroga un servizio e, nei limiti della tecnologia e degli strumenti disponibili, l’azienda cliente è messa in condizione di fruire dei servizi offerti.

Il nuovo modello che sta emergendo frammenta ulteriormente le competenze, consentendo — per come la vedo io — un miglioramento in termini di usabilità ed accesso a questo tipo di tecnologia. Il modello si presenta più o meno così:

  • chi ne capisce di satelliti si dedica alla progettazione e realizzazione di strumenti ricchi di tecnologia ma molto piccoli e leggeri
  • chi ne capisce di razzi e vettori si dedica a progettare ed implementare un servizio di trasporto in orbita bassa
  • chi ne capisce di telecomunicazioni si dedica a costruire una rete di comunicazione satellitare che sia in grado di dialogare con molte tipologie di satellite e mette a disposizione le interfacce

A questo punto le aziende il cui modello di business dipende o sfrutta una tecnologia che necessita di una rete satellitare possono rivolgersi ad una serie di interlocutori specializzati che gli consentiranno di acquisire una tecnologia come i CubeSat, di spararla in orbita e di collegarla a sistemi a terra che consentano l’accesso ai dati/servizi di cui hanno bisogno, senza doverti preoccupare dell’immensa infrastruttura che c’è dietro e con investimenti molto inferiori rispetto a solo 10 anni fa.

Un bel tassello di questo complesso puzzle lo mette a disposizione Amazon con il servizio AWS Ground Station che da la possibilità ad un’azienda di interconnettere un proprio satellite alle “stazioni a terra” di Amazon che gestiranno la comunicazione con l’orbita bassa. Inoltre il servizio mette a disposizione gli strumenti per collezionare i dati ed eseguire le eventuali analisi. Anche su questo fronte credo si possa ipotizzare che Amazon non sarà certo l’unica a muoversi in questo campo.

Dal punto di vista del White Hat

Premetto che questo tipo di tecnologia mi affascina enormemente, tanto quanto mi affascina l’hacking, la fisica e l’esplorazione spaziale. Sono frontiere che vengono quotidianamente abbattute, sono nuovo opportunità per la specie se sapremo utilizzarle.

Chi lavora e fa ricerca nel campo della sicurezza cibernetica e ha un po’ di esperienza, al solo pensiero di prendere un oggetto che orbita attorno al pianeta e che rileva dati potenzialmente molto delicati e metterlo in comunicazione, seppur tramite più layer fisici e logici, con la rete internet attraverso un servizio cloud… probabilmente è svenuto prima di aver letto tutta la frase.

Non c’è nulla di sbagliato nelle intenzioni, esiste però qualche trilione di fattori da considerare per implementare e renderle fruibili queste infrastrutture in modo sicuro. Qualche tempo fa ho azzardato una previsione — non ricordo se l’ho scritta o detta — in relazione ai sistemi di comunicazione satellitare identificando come potenziale punto debole la Ground Station. Prendendo visione di come si stanno rendendo accessibili queste tecnologie mi viene qualche dubbio anche sulle possibilità di configurazione ed integrazione delle piattaforme cloud, non per fattori legati alla tecnologia, bensì in riferimento alla capacità di costruire adeguate policy di sicurezza.

Lo scenario e così complesso e la tecnologia così potente da richiedere una riflessione subito, ben prima che diventi qualcosa di largamente utilizzato. A questo tema sicuramente dedicherò qualche laboratorio di approfondimento e ne parlerò nei prossimi podcast. Mi piacerebbe sentire la campana di qualcuno del settore aerospaziale (militare e/o civile).

podcast

Sintesi cibernetica #11

Gestire un incident, che si tratti di un fault, un attacco o un malfunzionamento di un sistema critico, è una pratica che richiede elevate competenze tecniche ed una buona dose di sangue freddo. Non bisogna solo sapere ciò che c’è da fare, bisogna anche sapere perché va fatto in un modo specifico, applicando “quella procedura” e non “l’altra”. Serve esperienza e pratica acquisibile grazie a tecniche come l’addestramento. Improvvisare non aiuta, anzi, si rischia di trasformare l’incidente in un disastro.

Bisogna anche rendersi conto che esistono situazione che non sono ripristinabili, nel senso che non esiste il processo che annulla quanto accaduto, è però possibile, con la giusta strategia, ricostruire e ripartire.

La settimana appena trascorsa ha dato diversi spunti di riflessione sulla gestione degli incident, in particolare OVH è alle prese con le prime ripartenze ma a quanto pare ieri (20 marzo) i sistemi sono stati nuovamente spenti a causa di un principio di incendio in uno del locali dove erano posizionate delle batterie UPS in quel momento non operative. La prossima settimana doveva essere quella dell’accensione dei sistemi ma questo nuovo incidente rischia di generare nuovi ritardi.

La vicenda OVH va seguita lasciando da parte il pensiero critico, è una scuola per tutti coloro che lavorano nel campo delle infrastrutture ad alta disponibilità di servizio. Osserviamo ed impariamo dagli errori tanto quanto dai successi… e consiglio di partire proprio dalle scelte comunicative che CEO che in prima persona aggiorna gli utenti tramite Twiter: https://twitter.com/olesovhcom.

Su Exchange non dico nulla se non di stare in campana, questa settimana si è parlato di DearCry, un crypto malware in grado di sfruttare la vulnerabilità ProxyLogon… evidentemente in molto stanno cercando una scusa per lanciare qualche job di restore dei dati.

Nuovi interessanti movimenti li ho trovati sul fronte SolarWinds, a distanza di settimane si sono osservate delle ingegnose tecniche per guadagnare un accesso permanente alle mailbox Office 365 di alcune delle aziende interessate dall’attacco (miglia di aziende). La tecniche è spiegata in questo articolo ed è molto semplice: l’attacker utilizza credenziali legittime, ovviamente sottratte tramite l’attacco già in corso, per eseguire una modifica alla configurazione delle mailbox rendendole accessibili in read-only. Silenziosi ed efficaci.

Qualche riflessione in più sul podcast.

cyber security

Schermaglie cibernetiche e strategie di difesa

Mentre leggo curiose reazioni di chi si stupisce — a distanza di due settimane — della portata dell’attacco globale che sta interessando i sistemi Microsoft Exchange (lo ripeto: era chiaro dopo cinque minuti che sarebbe stato un disastro ed in questo post spiegavo i motivi) osservo con interesse le mosse del governo USA ben illustrate in un recente post di Bechis su Formiche.Net in cui, sintetizzo ma consiglio la lettura, viene riportata l’intenzione del governo americano di far cooperare le agenzie governative con i grandi gruppi privati per potenziare la propria capacità di anticipare azioni di attacco come quelle in corso.

Il problema è chiaro: NSA, USCYBERCOM e compagnia briscola (e scusate se è poco) faticano a tenere il passo con attacchi di questa portata in “rapida” successione, non si è ancora chiusa la non banale questione SolarWinds e si rende necessario preoccuparsi anche di questa nuova campagna di attacchi ben più estesa. Sarà interessante osservare le prossime mosse dei grandi gruppi che, a quanto pare, non sono così propensi ad avviare questa collaborazione.

Ora osserviamo lo scenario: abbiamo il Presidente degli Stati Uniti d’America che si rende conto di avere fior di strumenti come le agenzie e forze armate con risorse dedicate alla sicurezza cibernetica, ma il perimetro interessato dagli attacchi ed i relativi impatti vanno ben oltre la capacità di prevenzione e gestione delle forze in gioco. La mossa interessante e che vorrei sottolineare è in relazione alla scelta strategica: “come la gestiamo Joe” gli avrà chiesto un membro dello staff, “dobbiamo potenziare l’intelligence coinvolgendo le big tech” avrà risposto il Presidente… o almeno è così che mi immagino io il dialogo.

Primo tema da analizzare: Biden punta dritto all’intelligence. Ovviamente ha la necessità di essere un passo avanti, deve poter prevenire le mosse del suo nemico e per farlo ha bisogno di informazioni da analizzare e correlare. Non posso non citare Sun Tzu (chi mi ha incrociato in ambito professionale si è beccato tutta la trattazione filosofica):

Sun Tzu, L’arte della guerra

Ovviamente, aggiungo, conoscere le strategie del proprio nemico non solo permetterebbe agli USA di organizzare una difesa efficace, darebbe anche qualche spunto su come colpire a loro volta. Sì, stiamo parlando di Guerra Cibernetica. E quale potrebbe essere un asset ricco di dati, con elevate capacità di analisi e dove si annidano figure professionali particolarmente abili nella gestione della sicurezza cibernetica? Domanda retorica.

Non affronto, in questo pezzo, il tema delle figure legate al mondo del hacking e del cracking (nelle sue varie forme) che nel tempo hanno collaborato con enti governativi. E’ un altro capitolo e non ci interessa ai fini della riflessione.

Proviamo ad imparare qualcosa da questo macro esempio di strategia: è poco plausibile mantenere il “vecchio” modello in cui corriamo ai ripari quando qualcosa non va e mettiamo presidi sulla base di ciò che sappiamo senza considerare che non possiamo sapere tutto.

È molto più efficacie ed efficiente, anche dal punto di vista della sostenibilità economica, analizzare quali sono i nostri punti deboli in funzione dell’impatto che avrebbe una minaccia cibernetica nel nostro modello di business e, sulla base di dati reali, valutare una strategia di difesa. Un’analisi della nostra superficie d’attacco affiancata alla verifica delle potenziali minacce che, in un reale contesto, farebbero breccia nella nostra organizzazione ci consentirebbe di valutare appropriate precauzioni.

Un passaggio ulteriore è mettere a frutto questo percorso che può portare valore non solo in termini di maggiore sicurezza della propria organizzazione ma anche come garanzia di affidabilità nei confronti di altre aziende e clienti. È banale: se a parità di prodotto / servizio ciò che la vostra organizzazione eroga viene accompagnato da una nota che ne attesta la robustezza secondo specifici test (ad esempio) o scelte tattiche ne otterrete un vantaggio competitivo.

Non so voi ma se devo sottoscrivere un servizio o acquistare un prodotto e mi trovo a dover scegliere tra più proposte equivalenti dal punto di vista funzionale ed economico, quella che mi da maggiori garanzie dal punto di vista dell’affidabilità e della resilienza è la proposta che vince.

Dedicate qualche minuto al tema del vantaggio competitivo, ci torno nel prossimo podcast.

cyber security, podcast

Sintesi cibernetica #10

Inizio la mia rubrichetta (fatemi sperimentare un po’) su ciò che questa settimana ha calamitato la mia attenzione nel mondo cibernetico, ammesso che ci sia una qualche reale differenza rispetto al mondo fisico.

Lo 0-Day su Exchange ve lo siete già dimenticati tutti ma in realtà il tema è tutt’altro che chiuso e mi aspetto torni alla ribalta nel giro di qualche settimana. L’innesco è della settimana #9 e, oltre ad aver registrato una reattività non proprio eccellente da parte degli utilizzatori di questa piattaforma, i movimenti relativi alle vulnerabilità segnalate sono datati gennaio 2021 da diversi analisti. Ovviamente spero di sbagliarmi ma c’è la seria possibilità che fra qualche settimana vedremo gli effetti delle azioni di attacco in corso per mano di vari gruppi di criminali cibernetici.

Il tema della settimana è stato in realtà l’incendio che ha interessato il campus Datacenter di OVH a Strasburgo. Una delle quattro sale è andata completamente distrutta nella notte tra il 9 e 10 marzo, un’altra sala è stata in parte danneggiata. Tutto il sito è ovviamente stato spento per consentire le operazioni di verifica, pulizia e ripristino di ciò che si potrà accendere, ipostenicamente in settimana #12 come OVH stessa riporta sul proprio sito al seguente link: https://www.ovh.it/news/press/cpl1785.incendio-nel-dataceneter-strasburgo

L’evento è sicuramente qualcosa di eccezionale e le indagini chiariranno cosa è effettivamente accaduto considerando che questo tipo di installazioni sono tipicamente molto ben progettate e presidiate anche se in questo caso potrebbero esserci stati elementi o scelte architetturali un po’ datate. Per ora si possono fare solo supposizioni e speculazioni, cosa che personalmente eviterei fino a quando non ci saranno dei dati da analizzare e delle dichiarazioni da parte di OVH stessa che, proprio oggi, ha iniziato ha fornire qualche dettaglio sull’incidente che parrebbe essere stato causato da un guasto ad un UPS.

L’impatto è devastante: quattro sale spente di quella dimensione generano ripercussioni su migliaia di aziende e non saprei calcolale quanti utenti. Non si tratta semplicemente di avere dei siti web non disponibili, i Datacenter in oggetto ospitavano diversi sistemi e applicativi, oltre che molti archivi di dati al momento non disponibili. Per alcuni di questi archivi vi è la seria possibilità che non siano recuperabili.

Quasi tutti i commenti che ho letto ed ascoltato hanno il sapore del monito verso chi eroga servizi Datacenter o verso i clienti che ritengono di non aver bisogno di un Disaster Recovery. Propongo in alternativa una riflessione in relazione alla livello di dipendenza che abbiamo costruito nei confronti di una serie di tecnologie di cui generalmente non sappiamo nulla. Personalmente comincio a vedere delle debolezze nel paradigma dell’accessibilità alla tecnologie a prescindere da una consapevolezza di base, una sorta di livello minimo di cultura necessario per accedere ad una tecnologia di questo tipo. Soprattutto per chi ha poi intenzione di fare del business tramite questa tecnologia.

Ora l’evento in se è forse anche troppo estremo, ma i disservizi esistono anche nei migliori Service Provider che siano di qualche minuto, di qualche ora o di giorni interi come in questo caso. E’ qualcosa di cui bisogna essere consapevoli e solo quando ci sarà questa consapevolezza di base si potranno fare valutazioni di merito su temi tattici come i piani di recovery, la ridondanza geografica e tutto quello che volete metterci dentro.

Ultimo tema che mi ha interessato, un po’ in ritardo in realtà perché la notizia è della settimana #9, è la prossima missione che vedrà coinvolta Samantha Cristoforetti nel 2022. Da qualche tempo ho iniziato a seguire le evoluzioni tecnologie che ci stanno permettendo di avviare una nuova era di esplorazioni spaziali e, giusto per restare allineato al mio modo di approcciare la scienza e la tecnologia, ho iniziato a ragionare sulle implicazioni di un compromissione delle infrastrutture a supporto delle missioni spaziali e, più in generale, al tema della sicurezza cibernetica in uno scenario che vede l’umanità impegnata nell’esplorazione del sistema solare e nella colonizzazione di Marte. Una riflessione che è bene iniziare con largo anticipo.

hacking

Exchange 0-day, una settimana dopo

Mi ero ripromesso di dedicare qualche minuto ad un approfondimento su quanto accaduto dopo la pubblicazione del post del CSIRT ed aver atteso una settimana ha consentito di considerare diversi eventi e di approfondire alcune analisi così da elaborare qualche considerazioni su una situazione che, a parer mio, è tutt’altro che risolta.

I fatti sono noti a tutti: il 03 marzo viene annunciato da tutti i siti di settore che è stato individuato un attacco 0-day in grado di sfruttare una serie di vulnerabilità di Microsoft Exchange (2013, 2016, 2019) con l’obiettivo di compromettere il sistema e, potenzialmente, rubare informazioni sensibili come il contenuto della posta elettronica del server attaccato.

Come ho scritto in un post poco dopo l’annuncio, si è trattato della “ricetta perfetta”: Exchange è largamente utilizzato da aziende medie e grandi, le vulnerabilità sono sfruttabili da remoto se il sistema espone funzionalità fruibili via https (cosa che ovviamente fanno tutti) e l’annuncio parlava di 0-day, non solo di vulnerabilità… quindi doveva essere chiaro che l’attacco era già cominciato.

Un post interessante lo trovate sul blog di FireEye dove vengono illustrati alcuni comportamenti osservati già da gennaio 2021 in relazione alle vulnerabilità CVE-2021–26855 e CVE-2021–26858. Le attività analizzate si riferivano allo sfruttamento delle vulnerabilità per il posizionamento di una web shell sul sistema target.

Quello che di fatto abbiamo osservato è che la fase “1” dell’attacco, relativa all’exploiting atto al posizionamento della web shell, era già in corso e sono certo che molti di quelli che si sono apprestati ad installare le patch suggerite da Microsoft hanno potuto verificare la presenza della web shell nel path c:\inetpub\wwwroot\apsnet_client\ del sistema Exchange sotto forma di file *.aspx; nel seguente repo di GitHub è stato riportato un elenco di possibili nomi dei file che vengono caricati attribuiti ad una famosa web shell nota con il nome di China Chopper.

Note: questo potrebbe dar sostanza ai sospetti di Microsoft stessa sul gruppo responsabile di questa campagna di attacchi che si ritiene essere HAFNIUM.

La prima doverosa nota tecnica si riferisce al comportamento dei firewall che tipicamente vengono configurati con un NAT per esporre i servizi di Exchange: molti firewall sono in grado di rilevare specifiche minacce grazie alle funzionalità di inspection, ma nel caso specifico l’azione avviene all’interno di una sessione HTTPS e quindi, a meno che il Firewall o il WAF non sia configurato per eseguire attività di SSL decryption, resta assolutamente invisibile al sistema di presidio del perimetro esterno.

Una volta portata a termine la prima fase dell’attacco, avendo a disposizione una web shell ricca di funzionalità, l’attacker è in grado di tentare ulteriori azioni anche contando sulla presenza delle altre vulnerabilità rese note nello stesso contesto (CVE-2021–26857 utilizzata per eseguire codice arbitrario sul sistema con utente SYSTEM e CVE-2021–27065 utilizzata per la scrittura arbitraria di file sul file system del server Exchange).

Nel caso specifico ciò che avviene è un tentativo di garantirsi un accesso persistente al sistema (il mio Red Team ha intercettato l’installazione di DLL e la registrazione di servizi al fine di garantire il dialogo persistente verso il server di Command and Control) e successive azioni che puntano al furto delle informazioni contenute nel sistema con particolare riferimento ai dati in memoria gestiti dal processo LSASS (quindi anche le credenziali) ed i dati presenti sul file system (le mailbox).

Le evoluzioni di questi comportamenti sono presentate anche in un post di Microsoft che è stato via via aggiornato e che da qualche spunto interessante.

Sulle azioni successive al primo exploit ci sono ulteriori elementi di analisi che possono essere utili ad una detection e mitigation dell’attacco. In particolare le attività che portano ad un dialogo verso il C2 server possono essere intercettate dai firewall che mettono a disposizione specifiche funzionalità di verifica del traffico e delle destinazioni. Una certa reattività potremmo aspettarcela anche dai sistemi di anti-exploiting di cui, spero, tutti facciate uso anche se, devo essere onesto, i rilevamenti fatti mi hanno lasciato perplesso su quest’ultimo fronte.

Per chiudere qualche suggerimento (banale ma doveroso):

  • Non avere ancora installato i fix? Mi complimento per il coraggio… fateli ma mettete anche in conto una bonifica del sistema.
  • Avete versioni precedenti di Exchange? Avete un problema ben peggiore perché state utilizzando un sistema end of support per gestire un asset fondamentale per la vostra organizzazione.
  • Avete applicato i fix subito dopo gli annunci? Bene, assicuratevi che il primo exploit non sia stato lanciato e verificate il traffico del vostro Exchange server sul firewall.
  • Precauzionalmente eseguite un cambio password del Domain Admin (due volte) e, già che ci siete, forzate un cambio password all’utenza.

Come sempre mi piacerebbe confrontarmi con chi si trova a gestire il problema all’interno delle organizzazioni. Ogni vostro contributo è prezioso alla community.