La maggior parte degli articoli sul ransomware per Mac comincia o minimizzandolo («i Mac non prendono ransomware») o gonfiandolo («gli attacchi stanno esplodendo»). Nessuna delle due posizioni è onesta. La cronologia documentata è breve, precisa e merita una lettura attenta, perché dice esattamente a cosa serve ogni strato di una difesa. Questo articolo ripercorre quella cronologia, poi gli strati, ed è esplicito su quale di essi un firewall copre e quali no.
Cosa è davvero successo su macOS
KeRanger, marzo 2016. L’Unit 42 di Palo Alto Networks ha riferito il 6 marzo 2016 che un installer compromesso del client BitTorrent Transmission, scaricato dal sito ufficiale del progetto, conteneva il primo ransomware pienamente funzionante per OS X. Era firmato con un certificato di sviluppatore valido, che gli ha permesso di superare Gatekeeper. Il suo comportamento è la parte da ricordare: secondo Unit 42, ha aspettato tre giorni, poi si è connesso ai suoi server di comando e controllo attraverso la rete Tor, e solo dopo ha iniziato a cifrare i file. Apple ha revocato il certificato e aggiornato XProtect nel giro di pochi giorni.
ThiefQuest, chiamato anche EvilQuest, giugno 2020. Objective-See di Patrick Wardle ha pubblicato la prima analisi il 29 giugno 2020, descrivendo un campione che si diffondeva tramite installer trojanizzati di software piratato e restava persistente attraverso launch agent e daemon. ThreatDown (allora Malwarebytes) ha riferito il giorno successivo che gli installer piratati includevano Little Snitch e Mixed In Key. La cifratura era quasi un diversivo: il campione conteneva anche un keylogger e apriva una reverse shell verso un server di comando e controllo, motivo per cui i ricercatori lo hanno rinominato. Era un ladro di dati vestito da ransomware.
LockBit, aprile 2023. BleepingComputer ha riferito il 16 aprile 2023 che erano stati trovati encryptor compilati per macOS di LockBit, all’epoca una delle più grandi operazioni di ransomware-as-a-service. I ricercatori che hanno esaminato le build hanno concluso che si trattava molto probabilmente di versioni di prova, con riferimenti a sistemi incompatibili e parti mancanti di funzionalità specifiche per macOS, e non pronte per attacchi reali. La storia conta meno per ciò che la build faceva che per ciò che segnalava: una grande organizzazione criminale aveva deciso che il Mac meritava un budget di sviluppo.
Tre casi in sette anni non sono un’epidemia. Ma ognuno è entrato attraverso una via che esiste ancora oggi: un download affidabile sostituito in silenzio, software piratato e una filiera criminale industrializzata. Una difesa a strati si costruisce attorno a quelle vie, non attorno a un numero da titolo di giornale.
Primo strato: impedire l’esecuzione di codice non affidabile
La documentazione di Apple sulla sicurezza della piattaforma descrive la protezione di macOS contro il software ostile in tre fasi: impedirne l’avvio (App Store, Gatekeeper e notarizzazione), bloccarne l’esecuzione (gli stessi strumenti più XProtect) e porvi rimedio dopo che è stato eseguito (ancora XProtect). È questo lo strato che ha fermato KeRanger in pochi giorni, una volta che Apple ha revocato il certificato. È anche lo strato che il software piratato esiste per aggirare: ogni vittima di ThiefQuest aveva deliberatamente bypassato Gatekeeper per installare un’applicazione craccata. Il singolo controllo più efficace contro il ransomware su un Mac non è quindi un prodotto. È una regola di condotta: niente software craccato, niente da torrent, e nessun «clic destro, Apri» per forzare un avviso di Gatekeeper a meno che non si sappia esattamente perché l’avviso è comparso.
Secondo strato: sorvegliare la rete, perché il ransomware parla
La cifratura è l’ultimo passo, non il primo. MITRE ATT&CK la elenca come Data Encrypted for Impact (T1486), una tecnica della fase Impact, e le fasi precedenti coinvolgono la rete. Un campione recupera una chiave o istruzioni da un server di comando e controllo; può esfiltrare i file prima di cifrarli, così che il riscatto possa minacciare anche la pubblicazione, cosa che ATT&CK cataloga come Exfiltration Over C2 Channel (T1041); ThiefQuest ha perfino aperto una reverse shell. KeRanger è rimasto in silenzio per tre giorni e poi ha effettuato la sua prima connessione in uscita via Tor. Quella prima connessione è ciò che un firewall per applicazione è nella posizione di vedere.
È qui che si colloca FireAI, e la collocazione è stretta ma reale. FireAI non rileva la cifratura. Non osserva i file che cambiano, non analizza processi o memoria e non può decifrare nulla. Ciò che fa è trattare ogni connessione in uscita come una decisione. Un binario che non si è mai connesso prima fa scattare una richiesta di autorizzazione, con accanto la motivazione del modello locale; lo stesso modello può bloccare o segnalare da solo una connessione da un’app sconosciuta verso una destinazione sospetta. I feed di threat intelligence che FireAI applica in locale includono la lista dei nodi di uscita Tor, abuse.ch, Spamhaus, FireHOL e liste di phishing, così una prima connessione verso un’infrastruttura criminale nota viene bloccata da una regola e non da un giudizio. E se sospettate che qualcosa sia in esecuzione, il kill switch taglia l’accesso a internet mantenendo la rete locale, il che spezza il collegamento di comando e controllo senza staccare la spina a una macchina che potrebbe servirvi per l’analisi forense.
Siamo chiari sui punti deboli. Un campione che cifra senza mai connettersi, usando una chiave incorporata nel proprio codice, è invisibile a un firewall. Un campione che usa un’applicazione già autorizzata, un browser ad esempio, per raggiungere il suo server si confonde nel traffico consentito. Un firewall riduce le probabilità che l’attacco sia silenzioso e completo; non rende la cifratura impossibile.
Terzo strato: backup che l’aggressore non può raggiungere
Che un evento di cifratura sia un brutto pomeriggio o una settimana che chiude un’azienda lo decide interamente questo strato. La #StopRansomware Guide della CISA lo mette al primo posto tra i passi di preparazione: mantenere backup offline e cifrati dei dati critici e testarli regolarmente, e valutare storage immutabile che protegga i dati archiviati senza bisogno di un ambiente separato. La parola che fa il lavoro è offline. Un disco Time Machine sempre collegato è un volume montato, e un volume montato è un bersaglio; una cartella di sincronizzazione cloud non è affatto un backup se sincronizza fedelmente le versioni cifrate dei vostri file sopra gli originali.
Su un Mac la versione pratica è semplice. La guida di Apple a Time Machine spiega come impostare backup automatici su un disco esterno o su un volume di rete supportato. Alternate due dischi e tenetene uno scollegato, o almeno espellete il disco tra un backup e l’altro. Conservate una seconda copia in un luogo che versiona i file invece di rispecchiarli, così che la versione pulita di ieri sopravviva alla sovrascrittura di oggi. Poi provate il ripristino di un file reale, dal disco scollegato, per sapere che la procedura funziona prima di averne bisogno sotto pressione. FireAI non ha alcun ruolo in questo strato, e vale la pena dirlo: nessun firewall fa il backup di niente.
Quarto strato: limitare ciò che un singolo Mac può raggiungere
Nelle aziende il ransomware fa la maggior parte dei danni sullo storage condiviso, e un Mac con una condivisione montata può cifrare tutto ciò su cui può scrivere. Date alle persone accesso in scrittura solo alle condivisioni che usano davvero, e date agli account di servizio credenziali proprie, così che un singolo accesso compromesso non apra l’intero file server. Sul Mac stesso, le regole per applicazione di FireAI vi permettono di decidere quali applicazioni possono raggiungere il vostro NAS, i vostri host di storage cloud o la rete dell’ufficio: un binario sconosciuto che prova a raggiungere il file server sulla porta 445 deve superare una regola che non gli è mai stata concessa. Le modalità di sicurezza più severe, Paranoid e Under attack, vanno oltre e rifiutano del tutto l’accesso alla rete alle app non firmate.
Se succede comunque
- Scollegate prima di tutto il Mac dalla rete. Il kill switch di FireAI lo fa mantenendo disponibile la rete locale; staccare il cavo lo fa in modo più radicale.
- Non pagate prima di aver verificato i vostri backup. La guida della CISA accompagna attraverso isolamento, triage e segnalazione prima di qualsiasi decisione su un riscatto.
- Preservate la macchina. Cancellarla distrugge le prove che dicono come il campione è entrato e cosa ha inviato all’esterno.
- Segnalate l’accaduto. Negli Stati Uniti alla CISA o all’FBI; in Francia a Cybermalveillance.gouv.fr e con una denuncia alla polizia; altrove al CERT nazionale.
- Ripristinate dalla copia offline su un’installazione pulita, non sul sistema compromesso.
Cosa significa onestamente «difesa completa»
Nessun singolo strumento è una difesa contro il ransomware, e qualsiasi fornitore che dica il contrario sta vendendo uno strato come se fossero quattro. Gatekeeper e la vostra disciplina nei download tengono lontana dall’esecuzione la maggior parte del codice ostile. Un firewall per applicazione costringe il codice che comunque gira a chiedere prima di parlare, e blocca le destinazioni già note come criminali. I backup offline rendono la cifratura sopravvivibile. Il privilegio minimo sulle condivisioni impedisce che un Mac compromesso diventi un incidente per tutto l’ufficio. Gli strati si sovrappongono di proposito, perché ognuno ha una falla che gli altri coprono. Ecco com’è fatta una difesa che regge: non impenetrabile, ma costruita in modo che nessun singolo cedimento sia fatale.
Il ruolo di FireAI e di HisnLabs
Le due famiglie di ransomware per Mac meglio documentate, KeRanger e ThiefQuest, hanno entrambe parlato con un server prima o durante la cifratura — e sorvegliare quella conversazione, proveniente da un binario che non si è mai connesso prima, è l’unica parte della difesa che un firewall per applicazione come FireAI può onestamente rivendicare.
FireAI è il prodotto di HisnLabs: un firewall con IA che funziona direttamente sul Mac. Mostra in linguaggio chiaro ogni connessione che le tue app effettuano e ti lascia decidere cosa esce dal tuo Mac — la sua IA lavora in locale, quindi il tuo traffico non viene mai inviato a noi né a nessun altro. Il team di ricerca sulla sicurezza di HisnLabs è quello che mantiene affidabili queste decisioni: cataloga quali domini sono semplice telemetria e quali un servizio reale, traccia il Paese e la rete dietro una connessione e addestra il modello locale (la funzione Autopilot) su schemi di traffico reali, senza che nulla lasci il tuo Mac.
Puoi leggere le scelte tecniche che ci stanno dietro, oppure provare FireAI per 17 giorni, su FireAI, di HisnLabs.