Destinazione Stelle

2026-06-04 11:40:33

Poche settimane fa, durante la diretta dell’ultimo lancio di Starship, SpaceX ha annunciato due nuove missioni commerciali con equipaggio, una intorno alla Luna e una intorno a Marte. La seconda ha suscitato più scalpore: dovrebbe avere come comandante Chun Wang, miliardario delle criptovalute che ha costruito la propria fortuna grazie a uno dei primi grandi sistemi di mining Bitcoin in Cina. Nel 2025 Wang ha già partecipato alla missione Fram2 di SpaceX in orbita bassa polare, finanziando personalmente il viaggio pur di ottenere il ruolo di comandante. La nuova missione dovrebbe durare circa due anni, con un sorvolo di Marte e il successivo rientro verso la Terra.

Trovo sorprendente la mancanza di senso critico con cui è stato accolto l’annuncio. Per ora Starship non ha ancora completato un volo in orbita bassa senza equipaggio, anche se ci è andata vicino. Ma dovrà superare molti altri traguardi prima di poter pensare a missioni interplanetarie, un obiettivo enormemente più ambizioso se consideriamo che la Luna è circa mille volte più distante dalla Terra dell’orbita bassa e Marte è oltre cento volte più distante della Luna.

Anche se i progressi sono evidenti, lo sviluppo di Starship è ancora in corso e non si può sapere con certezza quando sarà terminato. Il rifornimento in orbita, necessario sia per le missioni lunari sia per quelle verso Marte, è un’operazione estremamente delicata che non è ancora mai stata collaudata e potrebbe riservare sorprese e ritardi. Non si sa ancora con precisione quante tonnellate di propellente Starship riuscirà a portare in orbita bassa, ma per “fare il pieno” a una navetta diretta verso Marte potrebbero servire più di dieci lanci di rifornimento.

Anche quando questi passaggi saranno completati, SpaceX sarà ancora ben lontana dall’obiettivo dichiarato. Una missione con equipaggio intorno a Marte comporta infatti difficoltà tecniche formidabili.

Prima di tutto occorre un funzionamento estremamente affidabile dei sistemi di supporto vitale e il trasporto di grandi quantità di risorse come cibo, ossigeno e acqua. Il riciclo dell’acqua e dell’ossigeno sulla Stazione Spaziale Internazionale è arrivato ormai a percentuali piuttosto alte, che richiedono comunque rifornimenti periodici, mentre le tecniche per la coltivazione sperimentale di piccole quantità di ortaggi non sono ancora pronte per l’uso quotidiano. La capacità di carico di Starship potrebbe in teoria permettere il trasporto di risorse non riciclabili sufficienti per tutta la missione. Tuttavia, un viaggio di circa due anni richiederebbe di gestire i sistemi di supporto vitale con un’affidabilità quasi assoluta, senza possibilità di soccorso dalla Terra. È plausibile che servirebbero molte missioni preparatorie più brevi prima di affrontare un volo di questo tipo e che tali collaudi richiederebbero diversi anni.

La distanza dalla Terra e le limitazioni delle risorse mediche renderebbero inoltre molto difficile trattare eventuali emergenze gravi di tipo medico o tecnico. Mentre le comunicazioni con la Luna avvengono quasi in tempo reale, con pochi secondi di ritardo, i segnali radio diretti verso Marte possono impiegare fino a circa 22 minuti per la sola andata. Nei periodi di congiunzione solare, quando il Sole si trova tra i due pianeti, possono verificarsi blackout delle comunicazioni della durata di circa due settimane.

Gli astronauti si troverebbero per tutto il viaggio in condizioni di microgravità, con conseguente perdita di massa ossea, atrofia muscolare e problemi cardiovascolari. Finora il record di permanenza nello spazio appartiene a Valerij Poljakov, rimasto in orbita per 437 giorni consecutivi. Una missione marziana di questo tipo potrebbe durare circa 700 giorni, con conseguenze fisiologiche difficili da quantificare.

Lascio per ultimo il problema più grave. Durante un viaggio così lungo gli astronauti sarebbero esposti alle radiazioni prodotte dagli eventi solari e dai raggi cosmici galattici. Le prime si verificano in maniera ciclica e con intensità variabile; possono anche risultare mortali, ma si schermano piuttosto bene se si ha abbastanza massa a disposizione. I raggi cosmici galattici invece colpiscono continuamente l’equipaggio e, pur non essendo immediatamente pericolosi, aumentano nel lungo periodo il rischio di tumori e altre malattie degenerative. Poiché sono formati da particelle pesanti e molto energetiche, non si possono schermare nemmeno con protezioni molto massicce. Al momento non è ancora chiaro come questo problema sarebbe risolto in una missione con equipaggio verso Marte.

Insomma, non credo che l’annuncio prefiguri realmente una missione umana verso Marte nel giro di pochi anni. A mio parere il suo orizzonte temporale è molto più breve: ha a che fare con l’imminente quotazione in borsa di #SpaceX.

@astronomia

(in)sicurezza digitale

2026-06-05 05:34:10

Sophos scopre il laboratorio AI per testare l’evasione degli EDR: così il ransomware si evolve

Sophos ha scoperto che un gruppo ransomware attualmente attivo ha costruito un laboratorio automatizzato basato su agenti AI — tra cui Claude Opus 4.5 — per sviluppare e testare sistematicamente tecniche di evasione dagli endpoint detection and response (EDR). Non si tratta di fantascienza: l’infrastruttura era operativa, testava payload reali contro Sophos, CrowdStrike e Windows Defender, e i risultati venivano usati in attacchi reali contro organizzazioni globali.

Come è emersa la scoperta

L’indagine è partita da un alert anomalo su un endpoint cliente: payload malevoli provenivano da una directory di testing insolita. Approfondendo, i ricercatori di Sophos hanno trovato qualcosa di inaspettato — non solo malware, ma un intero framework di sviluppo e testing. L’ambiente conteneva profili Cobalt Strike configurati per mascherare il traffico beacon come richieste web legittime, un meccanismo di command-and-control via Telegram Bot API, script Python per l’iniezione di shellcode in processi Windows legittimi, e un Cloudflare Worker usato per nascondere il server C2 backend. Sophos ha collegato l’attività a operazioni di ransomware e furto di dati, ma non ha divulgato il nome del gruppo per via di indagini ancora in corso.

L’architettura del laboratorio: VM dedicate, agenti AI e MCP

Il nucleo dell’operazione era un laboratorio di test composto da più macchine virtuali Windows Server 2022, ognuna dedicata a un diverso prodotto EDR: una per Sophos, una per CrowdStrike, una terza come ambiente di controllo senza EDR installato. Una quarta VM Ubuntu ospitava un server Sliver per il command-and-control. L’attore ha utilizzato Ludus, una piattaforma per il deployment rapido di ambienti virtualizzati di sicurezza, per provisionare l’infrastruttura.

All’interno di questo ecosistema operavano più agenti AI coordinati tramite il protocollo Model Context Protocol (MCP), lo standard aperto che consente agli assistenti AI di interagire con strumenti e repository esterni. Un agente Claude Opus 4.5 fungeva da coordinatore principale, impostando le regole operative per gli altri agenti. Agenti specializzati si occupavano rispettivamente del testing EDR, della documentazione dei risultati, dell’hardening OPSEC, dei test di stress sul proxy e del deployment delle VM. Lo sviluppo del codice malevolo avveniva tramite Cursor, un IDE AI-native che integra capacità generative direttamente nell’ambiente di sviluppo.

Il workflow: da articoli di ricerca a payload ottimizzati

Il processo di sviluppo seguiva una pipeline iterativa ben strutturata. Gli agenti leggevano articoli di threat intelligence da blog di vendor come Kaspersky, Palo Alto Networks e Bishop Fox, oltre a post su X e Telegram. Le tecniche di bypass identificate venivano estratte, mappate sul framework MITRE ATT&CK, trasformate in moduli di test, eseguite nel laboratorio virtualizzato contro gli EDR target, e i risultati documentati per guidare l’iterazione successiva.

Il framework di generazione payload — uno strumento Python centrale — produceva eseguibili Windows personalizzati e DLL che incorporavano cifratura, tecniche di evasione e metodi di esecuzione alternativi. In totale, l’infrastruttura supportava quasi 80 moduli per testare oltre 70 tecniche di evasione distinte. Gli script Python erano in parte scritti in russo, e molti mostravano chiari pattern di generazione AI.

Un aspetto critico riguarda il pretesto usato con Claude: l’attore ha incorniciato il progetto come un framework di red team per eludere i guardrail del modello. Sophos ha segnalato il pattern ad Anthropic. “Tentativi di aggirare i limiti dei modelli usando framing benigno per prompt malevoli — come il pretesto del red team — sono stati osservati in numerosi casi negli ultimi dodici mesi,” ha dichiarato Rafe Pilling, Director of Threat Intelligence di Sophos.

Quanto è efficace davvero?

La documentazione interna al framework attestava un aumento progressivo del tasso di successo nell’evasione man mano che i moduli venivano raffinati. Tuttavia i dati di test effettivi analizzati durante l’indagine non supportavano queste affermazioni. “Non disponiamo dei dati per spiegare completamente le discrepanze, ma è probabile che le allucinazioni degli LLM abbiano avuto un ruolo,” ha concluso Pilling. Il risultato è paradossale: un laboratorio AI che produce documentazione ottimistica ma risultati meno convincenti di quanto dichiarato. Questo non riduce la pericolosità della tendenza, ma ne contestualizza i limiti attuali.

Due righe per i difensori

L’aspetto più preoccupante non è che l’AI abbia reso il ransomware invincibile — non è così, almeno per ora. Il problema è la scalabilità del processo di sviluppo: quello che richiedeva settimane di lavoro manuale per testare una singola tecnica di bypass può ora essere automatizzato in ore. I fondamentali della difesa restano invariati: patching, MFA/passkey, protezione degli endpoint. Ma l’accelerazione nel ciclo di sviluppo del malware significa che la finestra temporale tra la comparsa di una nuova tecnica di evasione e la sua adozione operativa da parte dei criminali si sta accorciando drasticamente.

Per i team di sicurezza, questa vicenda sottolinea l’importanza di monitorare attività anomale nelle directory di staging e testing, rilevare l’uso di tool di virtualizzazione come Ludus in ambienti non autorizzati, prestare attenzione all’abuso di strumenti di sviluppo AI-native per la generazione di codice sospetto, e verificare connessioni verso Telegram Bot API da endpoint aziendali come potenziale C2 channel.