Le “infrastrutture critiche”, comprese le strutture sanitarie, hanno molte caratteristiche comuni che riguardano le implementazioni e lo sviluppo di tecnologie IT e lo scambio e la trasmissione di dati e informazioni.

Oggi, di pari passo con lo sviluppo tecnologico, si parla sempre più di Sanità Connessa: un numero sempre crescente di aziende ospedaliere e di enti sanitari territoriali, utilizza il networking per la loro interconnessione, col fine di aumentare la quantità di servizi pubblici essenziali erogati, per ridurre i costi o per far fronte alle disponibilità economiche limitate.

Ne consegue che si sta assistendo ad un incremento delle integrazioni tra le infrastrutture ospedaliere e le reti esterne (es. cloud, reti proprietarie di fornitori, etc.).

Questo scenario fa sì che il comparto sanità sia maggiormente esposto alle minacce cyber che sfruttano vulnerabilità, non solo note, riducendo quindi il livello della sicurezza informatica del settore a livello nazionale, ma anche mondiale.

La situazione attuale

Nelle strutture sanitarie, sempre più spesso oggetto di attacchi informatici, risulta evidente la scarsa maturità dal punto di vista e dell’approccio olistico per quanto concerne le problematiche relative alla cybersecurity.

Premettendo che, com’è noto, la sicurezza totale è auspicabile ma non raggiungibile, le principali lacune che si riscontrano riguardano molteplici fattori, quali, ad esempio:

• rilevanza del servizio erogato;
• continuità operativa 365/365, 7/7, 24/24;
• peculiarità dei sistemi informatici sanitari;
• complessità dell’infrastruttura di rete;
• elevato numero di utenze;
• elevato turnover del personale;
• elevato numero di asset;
• quasi assenza della cultura cyber del personale parasanitario, sanitario, tecnico e amministrativo.

In aggiunta, la cybersecurity è considerata come un’appendice dell’IT, pertanto messa in pratica, troppo spesso, dopo le esigenze inerenti alla continuità operativa, ai requisiti tecnici ed operativi degli elettromedicali e alle necessità degli utenti.

Di conseguenza non sono rari problemi legati a svariati ambiti della cybersecurity, come misconfiguration degli apparati di sicurezza di rete, patching di sicurezza effettuato con difficoltà e non tempestivamente, gestione del networking frammentato e non strutturato, mancanza di un ISMS, giusto per citarne alcuni.

Come si può allora garantire un livello ottimale di sicurezza, dove la protezione dei dati sensibili e la continuità delle operazioni sono di vitale importanza?

Affrontare la sfida del miglioramento della postura cyber, con una approccio olistico, adattando allo specifico contesto la tradizionale strategia di Defense in Depth.

Da ospedali monolitici a ospedali interconnessi

L’OT (Operational Technology) a supporto delle strutture sanitarie, è rappresentato dalle tecnologie biomediche e dalle apparecchiature elettromedicali, le quali dipendono molto dall’IT per il loro funzionamento.

La segregazione, sia fisica sia logica, tra le reti IT aziendali e quelle di processo, ha costituito, tradizionalmente, il principale approccio per la messa in sicurezza delle stesse.

Presto però, ci si è resi conto che questa soluzione era riduttiva e limitante, in quanto non facilitava la condivisione, l’acquisizione e l’utilizzo dei dati e delle informazioni relative ad esempio ai pazienti, alle patologie, alle terapie, alla diagnostica per immagini etc., nonché il normale svolgimento di attività legate all’erogazione dei servizi sanitari.

Un altro ostacolo era costituito dalla technical security delle apparecchiature elettromedicali e dei loro sistemi, facendo si che si concretizzasse il concetto di “security through obscurity”, il quale poteva considerarsi valido fintanto che le strutture sanitarie erano monolitiche.

La security, per ovvie ragioni, raggiungeva livelli accettabili solo applicando la physical security, ovvero assicurandosi che solo il personale autorizzato ed incaricato avesse accesso al sistema e ai suoi componenti.

Lo sviluppo tecnologico in ambito sanitario e le moderne architetture dei sistemi, unite alla crescente richiesta di erogazione di maggiori servizi in tempi sempre più stretti e i budget disponibili in continua riduzione (i tagli alla Sanità non sono di certo una novità), ha inevitabilmente comportano un aumento delle integrazioni tra il mondo IT e quello OT e tra numerose strutture dislocate sul territorio nazionale e non solo.

Dunque, la segregazione delle reti, oggigiorno, non rappresenta più una valida soluzione, che sia tecnicamente ed economicamente sostenibile, per la gestione, il funzionamento e la protezione delle aziende ospedaliere.

Ancora oggi, molti ospedali fanno un massiccio uso di tecnologie legacy, che sono state progettate e costruite per durare anche più di un decennio e i progettisti e i costruttori non hanno tenuto conto di concetti quali security by design o security by default.

Molte strutture hanno cominciato e stanno continuando la migrazione verso tecnologie affini all’interconnessione, ma quest’ultima spesso non è supportata da un adeguato aggiornamento tecnologico, in quanto gli elettromedicali, seppur obsoleti dal punto di vista informatico, dal punto di vista sanitario assolvono egregiamente alle loro funzioni, e una loro sostituzione comporterebbe dei costi importanti non sostenibili.

Questa inversione di tendenza, assolutamente necessaria, ha dei pro e dei contro: facilita l’accesso a nuove e più efficienti tecnologie, tempi di erogazione dei servizi sanitari più rapidi e una maggiore interoperabilità. Di contro, la crescente integrazione delle architetture dei sistemi informativi sanitari introduce rischi cyber che prima non esistevano, aumentando in maniera considerevole la superficie di attacco.

Di ciò ne sono consapevoli gli attaccanti, che trovano terreno fertile per lo sfruttamento di vulnerabilità note attraverso tecniche usuali per il mondo IT, e con le quali hanno indubbiamente molta dimestichezza.

Una delle principali sfide per gli addetti ai lavori è rappresentata dal fatto che le contromisure tipiche del mondo IT, largamente utilizzate e implementate, spesso non possono essere utilizzate nel mondo OT.

Tutto ciò trova conferma nel crescente numero di incidenti cyber e attacchi ad ospedali e aziende sanitarie territoriali.

Dalla teoria alla pratica: implementare la DiD

E’ dunque necessario affrontare il problema della sicurezza informatica attraverso una serie di azioni e attività di hardening, mirate.

Il tutto può essere reso possibile avendo il consenso della dirigenza la quale deve riconoscere l’importanza della cybersecurity, consapevole che è un investimento e non un costo e pretendere che vengano applicate tutte le misure di sicurezza possibili su tutti i fronti.

E’ necessario instaurare un dialogo continuo, grazie al quale ci si possa allineare sull’importanza delle tematiche di sicurezza, si possa concordare la decisione di voler intraprendere un cammino, strutturato e programmato, che possa innalzare la postura cyber e che permetta di prendere coscienza dell’impegno e della costanza che questo richiede.

L’obiettivo ultimo deve essere quello di seguire tutte le best practice del modello DiD che deve essere rivisitato, facendone l’opportuno tailoring.

Si deve partire dalla gestione del rischio multi-tier, che prevede l’adozione di un modello basato su tre livelli:

• Livello 1: organizzativo;
• Livello 2: processo e mission aziendale;
• Livello 3: sistema informativo.

come descritto nei documenti NIST SP 800-37, Guide for Applying the Risk Management Framework to Federal Information Systems – A Security Life Cycle Approach, NIST SP 800-39, Managing Information Security Risk – Organization, Mission, and Information System View e NIST Framework for Improving Critical Infrastructure Cybersecurity.

Poi bisogna agire su diversi ambiti, quali, per esempio:

• sicurezza fisica;
• firewall perimetrali;
• DMZ e VLAN;
• MFA;
• patch management;
• segregazione;
• rilevazione e prevenzione delle intrusioni;
• data loss prevention;
• SIEM;
• supply chain;
• security awareness;
• asset assessment.

Conclusioni

Grazie alla DiD su misura, e una serie di pratiche di hardening, si può riuscire a mitigare in modo efficace un numero considerevole di minacce, garantendo la protezione delle risorse più critiche per la continuità delle operazioni.

Il percorso da intraprendere deve essere in continua evoluzione, che necessita di un impegno costante degli addetti ai lavori, per rimanere al passo con le minacce emergenti.

Procedendo in questa direzione, avendo bene a mente che si arriva in cima alla scala un gradino per volta, si può posare una solida base per ulteriori e continui miglioramenti, ricerche nel campo della cyber security e la protezione delle nostre strutture sanitarie.

L'articolo Perché la Defense in Depth è cruciale per la Cybersecurity delle Strutture Sanitarie proviene da il blog della sicurezza informatica.

In questo articolo ci occuperemo di Infection Monkey, un tool fondamentale da conoscere.

Per spiegarlo in modo semplice, in infection monkey, varie scimmiette inizieranno a rimbalzare tra un sistema all’altro sfruttando varie vulnerabilità e comunicando le varie mosse all’island, il quartier generale delle scimmiette (la nostra dashboard di controllo).

Prima di spiegare questo tool e capire come si differenzia dagli altri, facciamo un passo indietro: facciamo chiarezza su quelli più noti per la ricerca di vulnerabilità.

Tutti conosciamo già i sistemi di patch management che quelli di vulnerability scanner.

Le due tipologie di sistemi hanno lo stesso obiettivo ma utilizzano due approcci diversi:

I software di patch management lavorano solitamente tramite un agent e con metodo “white box” (collezionano per ogni sistema dove è installato i software installati e versioni). Questi sistemi sono in grado di capire “passivamente” quali software e sistemi operativi richiedono aggiornamenti e se sono affetti da vulnerabilità, fornendo un indice di rischio (utilizzando il CVSS) e la priorità di patching la data di pubblicazione della patch).

I sistemi di vulnerability scanner solitamente hanno un approccio differente dai precedenti. Non conoscono il sistema e lavorano con un metodo “black box”. Attraverso scansioni esterne ad IP e porte, vanno a “caccia” di vulnerabilità utilizzando tecniche di ricognizione standard utilizzate anche nel mondo offensive security, utilizzando sia appositi plugin( che sfruttano solo una prima parte dell’exploit) che i banner per capire passivamente le versioni installate. Anche questi tools infine prioritizzano le vulnerabilità dando un remediation report. Di scanner del genere ne ho parlato poco fa con quello open source di ARTEMIS in questo articolo.

redhotcyber.com/post/alla-scop…

L’insieme dei 2 approcci danno un quadro molto preciso delle vulnerabilità presenti e le mitigazioni da applicare.

Ma la storia non finisce qui. Ne esiste un altro molto interessate per misurare non solo il livello di aggiornamento e policy applicate, ma anche la solidità di un’infrastruttura informatica di fronte ad una minaccia per avere un riscontro oggettivo anche dai sistemi di difesa e monitoraggio: sono i software di breach and attack simulation.

Software di breach and attack simulation

Questi sistemi simulano un vero attacco tramite un malware distribuito nella rete o in un dispositivo.

Questo malware poi va a coprire tutto il ciclo di un attacco, dalla ricognizione, all’exploit dei sistemi, alla post exploiting come la collezione di hash e credenziali e privilege escalation,al movimento laterale, pivoting e per finire alla comunicazione con un C2 (Command e Control).

Sto parlando della metodologia della cyber kill chain, più precisamente della unified cyber kill chain che unisce gli step illustrati da Lockheed Martin con le tecniche, tattiche e procedure del MITRE.

Il tool poi fornirà un report su cosa è riuscito a compromettere ed uno di mitigazione.

Questi tool possono testare attivamente i sistemi di difesa nell’infrastruttura, policy applicate fino addirittura i propri sistemi di endpoint security, edr ed xdr. I SOC potranno analizzare i dati che verranno inviati e filtrati dai SIEM.

Questo tool non è nuovo e ne esistono molti commerciali, ma io come da tradizione mi occuperò di un tool open source e gratuito distribuito da Akamai.

La configurazione

Per prima cosa scegliamo l’ambiente dove installarlo, possiamo scegliere varie tipologie di installazione, in questo caso utilizziamo quella per linux.

sourceforge.net/projects/infec…

Abbiamo preparato una macchina con ubuntu 22, per comodità in modalità desktop per utilizzare la console direttamente all’interno.

Quindi scarichiamo l’eseguibile con WGET:

wget master.dl.sourceforge.net/proj…

Ora occorre solo avviarlo, però prima impostiamo i permessi di esecuzione:

chmod +x InfectionMonkey-v2.3.0.AppImage

Potrebbe ritornarci un errore di un componente mancante, quindi installiamolo.

sudo apt install libfuse2

A questo punto avviamo appimage come qui sotto

./InfectionMonkey-v2.3.0.AppImage

App farà una serie di operazioni indicando dove dobbiamo collegarci, molto importante non chiudere il terminale altrimenti il server verrà terminato:

Ora colleghiamoci al IP e porta indicato e creiamo un utente.

A questo punto rientrando saremo sulla dashboard generale:

Qui potremmo:

• Lanciare l’attacco, con questa funzione distribuiremo la prima “scimmia” che comincerà a saltare e a replicarsi sui vari sistemi
• Vedere la mappa dell’attacco una volta lanciato, vedremo quali sistemi abbiamo scansionato, quelli compromessi e quelli controllati dal C2.
• Vedere i report dell’attacco, mitigazione e il report della simulazione di cifratura (si, questo tool emulerà anche un ransomware, lo vedremo dopo…)
• Configurare agent, ci sono una serie di parametri che vedremo dopo da impostare.
• Leggere la documentazione

Per prima cosa però scarichiamo i plugin che verranno integrati negli agent.

Accedendo al menu plugin vediamo, appunto, che ci proporrà una serie di plugin, possiamo vedere che possiamo scaricare uno o più di essi che poi saranno inseriti nel finto malware.

Quasi tutti sono Safe, 2 degli altri sono usafe vuol dire che potrebbero compromettere irrimediabilmente

Quindi è molto importante sapere le conseguenze che può scatenare l’agente se eseguito in ambienti di produzione.

Scarichiamo i plugins sicuri, ma visto che nel nostro ambiente di test vogliamo fare il massimo dei danni, includiamo anche l’exploit Zerologon.

Ora ci spostiamo sulla configurazione

Propagation

Nella sezione propagazione ci sono tutte le configurazioni, payloads da usare, reti consentite ecc.

Ora selezioniamo tutti gli Exploiters:

Nella sezione analisi di rete inseriamo tutte le subnet in cui è “autorizzato” ad accedere:

Possiamo configurare anche altre opzioni perchè l’agent capisca che il sistema è acceso e vada a recuperare alcuni banner.

Nella parte credenziali possiamo, appunto inserire delle credenziali che potrà usare.

Dai test che ho fatto sembrerebbe che non utilizzi nessuna sorta di dizionario durante la fase di ricognizione.

Quello che manca è la possibilità di poter caricare un file, in quanto è concesso inserirne solo una alla volta.

Payloads

Oltre ai moduli di ricognizione ed exploit e collegamento con il C2, possiede un modulo per emulare un ransomware e la cifratura dei dati.

E’ necessario però indicare quale sarà la directory come nell’esempio, poi creare dei documenti di esempio (txt) in tutti i sistemi.

Credential Collector

Questa parte riguarda il recupero delle credenziali salvate da Chrome, token NTLM e credenziali SSH.

Masquerade

In questo punto possiamo fare in modo di impostare una firma specifica, i sistemi di rilevamento troveranno una specifica minaccia già rilevata.

Polimorfismo

Questa configurazione emulerà il polimorfismo per far in modo che tutti gli agent che si replicheranno verranno creati con firme diverse, quindi riconosciuti diversamente dai sistemi di rilevamento firme.

Avanzate

Ora è tutto pronto per salvare la configurazione, il software ci avvertirà solo che abbiamo selezionato una configurazione che potrà “rompere” i sistemi.

Distribuiamo il malware

Nel nostro laboratorio preparato sarà composto da:

• Windows 10 – client.offsec.local
• Windows Server 2016 – DC01.offsec.local
• Windows XP – admin-3add64b46.offsec.local
• Windows 2008 SP1 – srv2008.offsec.local
• Ubuntu 14.06
• Ubuntu 16.04
• Windows 7 – WORKGROUP

Ora passiamo alla fase di distribuzione accedendo a Run Monkey

Con l’opzione “From Island”, le nostre scimmie proveranno a muoversi nei sistemi direttamente dalla piattaforma. Questo approccio simula un dispositivo infetto che si collega alla rete aziendale.

In modalità manuale ci viene fornito un comando per lanciare attacco da un punto ben definito. Questo altro approccio invece potrebbe corrispondere ad uno script avviato aprendo un allegato da una mail di phishing oppure da un eseguibile camuffato o inserendo una chiave USB compromessa.

Avevamo già fatto già degli esempi su come camuffare e distribuire del contenuto malevolo in file word oppure eseguibili autentici “modificati”.

redhotcyber.com/post/sotto-att…

redhotcyber.com/post/sotto-att…

redhotcyber.com/post/attacchi-…

Ora la pagina ci chiede il sistema di partenza. Inizieremo da un client con diritti limitati (User) in un dominio Microsoft.

Una caratteristica di questo tool è che è compatibile solo con sistemi a x64 bit. Come vedremo dopo i sistemi a 32bit verranno segnati “exploitati”, ma l’agente non verrà avviato all’interno.

Ora è tutto pronto, abbiamo acceso una serie di macchine per studiare la compromissione. Alcune non sono aggiornate mentre altre utilizzano password di default.

Abbiamo anche creato in alcune macchine la cartella infection-monkey, così da verificare che l’agent una volta compromessa la macchina, esegua la cifratura dei dati.

Ci colleghiamo alla macchina, un W10 pro (CLIENT.offsec.local) non molto aggiornato: possiamo vedere che l’utente ha i privilegi minimi e niente altro.

Quindi avviamo lo script tramite IDE di powershell:

Vediamo subito che il C2 ha subito avviato e comunicato con la vittima, se notate ha un simbolo di una chiave, vuol dire che sta ancora completando la fase di ricognizione ed exploit.

Da notare le frecce e la direzione:

• Arancioni: indicano un’attività di scansione e la direzione
• Rosse: exploit e la direzione
• Blu: indica che è stato stabilito un tunnel, di solito da un agent una rete non visibile dal C2 (pivoting)
• Grigia: questi sono i collegamenti effettuati con successo al C2 da parte degli agent

Possiamo vedere anche che in ogni agent ci sarà il flag verde quando il C2 sta comunicando attivamente con l’agent stesso in esecuzione.

E’ possibile che la macchina sia “attaccata” da più agent compromessi successivamente.

Man mano che aspettiamo vediamo l’evoluzione dell’attacco…

E per completare vediamo tutta la propagazione. Selezionando su ciascun agent a sinistra vediamo la timeline dell’exploit.

Possiamo vedere che dal CLIENT del sistema di partenza infettato, il malware si è spostato in 4 sistemi: tutte le macchine in dominio e linux con password debole di cui una era un un’altra rete non accessibile inizialmente alla minaccia (freccia blu).

Degli altri 2 uno è totalmente fuori dominio e completamente aggiornato ed infatti non è stato compromesso (ragione per cui utilizzare sistemi sganciati dal dominio è una buona best practice per evitare i movimenti laterali). l’ultimo con le frecce rosse da 2 sistemi, è stato compromesso ma essendo a 32 bit non è stato avviato l’agent per comunicare con il C2 (questo è solo un limite tecnico del tool).

Selezionando Monkey Events vediamo tutte le attività fatte da un agente verso una vittima, se l’attività è andata a buon fine e la tipologia di attività.

Nella tipologia è fornito anche il codice del MITRE per identificare esattamente la tecnica e tattica usata.

Ora, quando si visualizzano tutte le spunte a destra, l’attacco è concluso. Non ci resta che analizzare i risultati.

Risultati

La pagina dei risultati ci fornisce 2 macro tipologie di risultati, quella legata alla sicurezza e quella legata all’attività di ransom.

Security report

In questo report iniziamo a vedere quale agente è stato manualmente installato, nel nostro caso 1, ma potrebbero essere stati di più se avessimo usato la propagazione dalla C2.

Inoltre troviamo gli utenti ed hash utili per eseguire attività di brute forcing

Proseguiamo con i suggerimenti dati per le macchine compromesse:

Per esempio buona idea è quella di alzare la complessità password, distribuire gli aggiornamenti, eseguire delle policy lato comunicazione nelle micro segmentazione di rete, ma ce ne sono molte altre selezionando i dettagli per ciascuna macchina.

Infine il report sulle porte aperte individuate, le macchine compromesse (e da chi) e le credenziali rubate (viene usato mimikatz).

Ultimo report, ma non meno importante, è quello legato all’attività di ransomware.

Qui abbiamo ancora indicazione da dove è partita la minaccia, il movimento laterale verso altri dispositivi:

E tutta la lista dei file cifrati:

Andando a verificare sugli endpoint verifichiamo effettivamente che sono stati compromessi:

Troviamo anche un simpatico README con la spiegazione, che ovviamente già sappiamo.

Analizziamo l’attacco con Wazuh

Se i dispositivi inviano gli eventi ad un sistema di audit o un SIEM come descritto precedentemente possiamo rilevare velocemente gli eventi di questo attacco.

Nel nostro caso abbiamo installato al volo Wazuh, un XDR dai superpoteri e oltretutto open source, e distribuito il suo agent su alcuni client prima di lanciare l’attacco per raccogliere gli eventi.

Questo strumento oltre a raccogliere dati da più fonti (es. agent, api, syslog, json file) e dispone già di default di molti decoder ed regole per adattarsi alle varie sorgenti dati, può anche costruire dashboard personalizzate con una moltitudine di widget in base a specifici eventi ed infine è anche un XDR. E’ possibile configurare e personalizzare una risposta (come isolamento tramite regole firewall o custom script) in base a specifici eventi.

Possiede anche un modulo di vulnerability detection, file integrity monitor, malware detection e altre funzionalità visibili qui sotto…

Oltretutto dispone di un agent già of the box per la maggior parte dei sistemi operativi. Una volta installato, Wazuh è già autonomo e raccoglie e cataloga i dati dai client utilizzando anche la matrice MITRE ATT&CK.

Qui per maggiori info:

wazuh.com/

github.com/wazuh/wazuh

Non mi dilungo molto, in quanto non è il tema di questo articolo, ma vediamo i risultati dopo aver lanciato l’attacco.

Infatti appena è stato lanciato l’attacco, tramite il modulo Threat Hunting ha iniziato a riportarci delle anomalie, riportando 207 possibili autenticazioni fallite e a categorizzare a destra i vari eventi in base al MITRE ATT&CKS.

Tra gli eventi possiamo riconoscere dei log riconducibili all’attività di Infection Monkey, come connessioni RDP, login falliti (brute forcing), autenticazione tramite pass-the-hash e creazione e modifica di account.

Conclusione

In questo articolo ho parlato di un’altra tipologia di tool per testare la sicurezza informatica nelle infrastrutture, utilizzando un approccio diverso dalla classica scansione di vulnerabilità o analisi di patch mancanti sui sistemi.

Ma soprattutto di un software open source gratuito.

Come sempre consiglio di prestare attenzione all’utilizzo di questi software e di avere le solite accortezze in quanto potrebbe causare danni.

L'articolo Infection Monkey: il tool di Breach and Attack Simulation (BAS) Open Source proviene da il blog della sicurezza informatica.

It’s a constant battle for musicians — how to practice your instrument without bothering those around you? Many of us live in apartments or shared accommodation, and having to wait until the apartment is empty or only being able to practice at certain times of day can be restrictive, especially if you need to practice for an upcoming gig or if the creative juices start flowing and it’s 3 AM! [Gavin] was having this issue and started developing Porter, a guitar/bass practice device which works with all effects pedals and is portable and rechargeable. So you can grind away your epic heavy metal solo no matter the time of day!

While there have been similar solutions, many musicians weren’t satisfied with the sound and often couldn’t support inputs from distortion pedals. They usually chewed through batteries and were just not a great solution to the problem. [Gavin] has spent the last two years fine-tuning the design. It’s a fully analog design, with built-in rechargeable batteries to boot. So it not only sounds great, but it can last as long as your practice session does with a 15-hour runtime when fully charged!

Initially, the project began as a headphone amplifier but morphed into a design specifically for guitar and bass, with preamp and power amp stages and adjustable input impedance – 500kΩ for guitars and 1MΩ for bass. The latest revision also changed to a different power amp that further reduced THD and led to an even better sound. The schematics are up on the Hackaday.io project page, but [Gavin] is also hoping to do a crowdfunding campaign to get these devices out into the hands of guitarists everywhere!

Nella giornata di oggi, la banda di criminali informatici di RansomHub rivendica all’interno del proprio Data Leak Site (DLS) un attacco informatico alla Coca Cola.

Ancora non sappiamo se tale attacco informatico abbia realmente colpito le infrastrutture IT della Coca Cola, dato che non è ancora presente all’interno del loro sito istituzionale nessun comunicato stampa relativamente all’accaduto.

Nel post pubblicato nelle underground dai criminali informatici di RansomHub, viene riportato che la gang è in possesso di 800GB di dati, esfiltrati dalle infrastrutture IT dell’azienda. Minacciano la pubblicazione tra 7 giorni.

Sul sito della gang è attivo anche un countdown che mostra che tra 7gg e 16 ore, quando ci sarà un aggiornamento del post. Questo modo di agire – come sanno i lettori di RHC – generalmente avviene quando ancora non è stato definito un accordo per il pagamento del riscatto richiesto da parte dei criminali informatici. In questo modo, i criminali minacciando la pubblicazione dei dati in loro possesso, aumenta la pressione verso l’organizzazione violata, sperando che il pagamento avvenga più velocemente.

Come spesso riportiamo, l’accesso alle Darknet è praticabile da qualsiasi persona che sappia utilizzare normalmente un PC. Questo è importante sottolinearlo in quanto molti sostengono il contrario, spesso nei comunicati dopo la pubblicazione dei dati delle cybergang ransomware e tali informazioni sono pubblicamente consultabili come fonti aperte.

Come nostra consuetudine, lasciamo sempre spazio ad una dichiarazione da parte dell’azienda qualora voglia darci degli aggiornamenti sulla vicenda. Saremo lieti di pubblicare tali informazioni con uno specifico articolo dando risalto alla questione.

RHC monitorerà l’evoluzione della vicenda in modo da pubblicare ulteriori news sul blog, qualora ci fossero novità sostanziali. Qualora ci siano persone informate sui fatti che volessero fornire informazioni in modo anonimo possono utilizzare la mail crittografata del whistleblower.

Cos’è il ransomware as a service (RaaS)

Il ransomware, è una tipologia di malware che viene inoculato all’interno di una organizzazione, per poter cifrare i dati e rendere indisponibili i sistemi. Una volta cifrati i dati, i criminali chiedono alla vittima il pagamento di un riscatto, da pagare in criptovalute, per poterli decifrare.

Qualora la vittima non voglia pagare il riscatto, i criminali procederanno con la doppia estorsione, ovvero la minaccia della pubblicazione di dati sensibili precedentemente esfiltrati dalle infrastrutture IT della vittima.

Per comprendere meglio il funzionamento delle organizzazioni criminali all’interno del business del ransomware as a service (RaaS), vi rimandiamo a questi articoli:

• Il ransomware cos’è. Scopriamo il funzionamento della RaaS
• Perché l’Italia è al terzo posto negli attacchi ransomware
• Difficoltà di attribuzione di un attacco informatico e false flag
• Alla scoperta del gruppo Ransomware Lockbit 2.0
• Intervista al rappresentante di LockBit 2.0
• Il 2021 è stato un anno difficile sul piano degli incidenti informatici
• Alla scoperta del gruppo Ransomware Darkside
• Intervista al portavoce di Revil UNKNOW, sul forum XSS
• Intervista al portavoce di BlackMatter

Come proteggersi dal ransomware

Le infezioni da ransomware possono essere devastanti per un’organizzazione e il ripristino dei dati può essere un processo difficile e laborioso che richiede operatori altamente specializzati per un recupero affidabile, e anche se in assenza di un backup dei dati, sono molte le volte che il ripristino non ha avuto successo.

Infatti, si consiglia agli utenti e agli amministratori di adottare delle misure di sicurezza preventive per proteggere le proprie reti dalle infezioni da ransomware e sono in ordine di complessità:

• Formare il personale attraverso corsi di Awareness;
• Utilizzare un piano di backup e ripristino dei dati per tutte le informazioni critiche. Eseguire e testare backup regolari per limitare l’impatto della perdita di dati o del sistema e per accelerare il processo di ripristino. Da tenere presente che anche i backup connessi alla rete possono essere influenzati dal ransomware. I backup critici devono essere isolati dalla rete per una protezione ottimale;
• Mantenere il sistema operativo e tutto il software sempre aggiornato con le patch più recenti. Le applicazioni ei sistemi operativi vulnerabili sono l’obiettivo della maggior parte degli attacchi. Garantire che questi siano corretti con gli ultimi aggiornamenti riduce notevolmente il numero di punti di ingresso sfruttabili a disposizione di un utente malintenzionato;
• Mantenere aggiornato il software antivirus ed eseguire la scansione di tutto il software scaricato da Internet prima dell’esecuzione;
• Limitare la capacità degli utenti (autorizzazioni) di installare ed eseguire applicazioni software indesiderate e applicare il principio del “privilegio minimo” a tutti i sistemi e servizi. La limitazione di questi privilegi può impedire l’esecuzione del malware o limitarne la capacità di diffondersi attraverso la rete;
• Evitare di abilitare le macro dagli allegati di posta elettronica. Se un utente apre l’allegato e abilita le macro, il codice incorporato eseguirà il malware sul computer;
• Non seguire i collegamenti Web non richiesti nelle e-mail;
• Esporre le connessione Remote Desktop Protocol (RDP) mai direttamente su internet. Qualora si ha necessità di un accesso da internet, il tutto deve essere mediato da una VPN;
• Implementare sistemi di Intrusion Prevention System (IPS) e Web Application Firewall (WAF) come protezione perimetrale a ridosso dei servizi esposti su internet.
• Implementare una piattaforma di sicurezza XDR, nativamente automatizzata, possibilmente supportata da un servizio MDR 24 ore su 24, 7 giorni su 7, consentendo di raggiungere una protezione e una visibilità completa ed efficace su endpoint, utenti, reti e applicazioni, indipendentemente dalle risorse, dalle dimensioni del team o dalle competenze, fornendo altresì rilevamento, correlazione, analisi e risposta automatizzate.

Sia gli individui che le organizzazioni sono scoraggiati dal pagare il riscatto, in quanto anche dopo il pagamento le cyber gang possono non rilasciare la chiave di decrittazione oppure le operazioni di ripristino possono subire degli errori e delle inconsistenze.

La sicurezza informatica è una cosa seria e oggi può minare profondamente il business di una azienda.

Oggi occorre cambiare immediatamente mentalità e pensare alla cybersecurity come una parte integrante del business e non pensarci solo dopo che è avvenuto un incidente di sicurezza informatica.

L'articolo Gli hacker criminali di RansomHub rivendica un attacco informatico alla Coca Cola proviene da il blog della sicurezza informatica.