As part of the payloads on the Firefly Blue Ghost Mission 1 (BGM1) that recently touched down on the Moon, the Lunar GNNS Receiver Experiment (LuGRE) has become the first practical demonstration of acquiring and tracking Earth orbital GNSS satellites. LuGRE consists of a weak-signal GNSS receiver, a high-gain L-band patch antenna the requisite amplification and filter circuits, designed to track a number of GPS and Galileo signals.

Designed by NASA and the Italian Space Agency (ISA), the LuGRE payload’s goal was to demonstrate GNSS-based positioning, navigation and timing at the Moon. This successful demonstration makes it plausible that future lunar missions, whether in orbit or on the surface, could use Earth’s GNSS satellites to navigate and position themselves with. On the way to the lunar surface, LuGRE confirmed being able track GNSS at various distances from the Earth.

Both LuGRE and BGM1 are part of NASA’s Commercial Lunar Payload Services (CLPS) program, with BGM1 delivering a total of ten payloads to the Moon, each designed to study a different aspect of the lunar environment, as well as hardware and technologies relevant to future missions.

hackaday.com/2025/03/07/gnss-s…

Dal marzo 2023, un sospetto gruppo APT (Advanced Persistent Threat) di origine cinese ha iniziato a prendere di mira vari settori critici a livello globale, con particolare attenzione a governi, difesa, telecomunicazioni, aviazione ed educazione nel Sud-Est asiatico e in Sud America. Questo attore malevolo ha dimostrato capacità avanzate di attacco grazie all’impiego di Squidoor, una backdoor sofisticata e modulare progettata per operare in modo furtivo su sistemi Windows e Linux.

L’attacco, come evidenziato dalla mappatura delle connessioni di Threat Intelligence (vedi immagine allegata), mostra un’infrastruttura articolata, con l’uso di molteplici tecniche di persistenza e di esfiltrazione dei dati. Un’analisi dettagliata su questa minaccia è disponibile nel report pubblicato da Palo Alto Networks Unit 42, consultabile al seguente link: Unit 42 – Advanced Backdoor Squidoor. In questo articolo analizzeremo in dettaglio il funzionamento di Squidoor, le sue tecniche di evasione, i vettori di infezione e le contromisure necessarie per difendersi da questa minaccia.

Le caratteristiche tecniche di Squidoor

Squidoor non è una semplice backdoor, ma un sistema modulare avanzato che sfrutta diversi protocolli di comunicazione per mantenere l’accesso ai sistemi compromessi senza destare sospetti. Tra questi protocolli troviamo:

• Outlook API: Il malware utilizza l’API di Outlook per trasmettere comandi e dati al server di comando e controllo (C2). Questo approccio rende difficile il rilevamento, poiché il traffico appare come normale comunicazione email.
• Tunneling DNS: Squidoor può sfruttare richieste DNS per inviare dati ai server C2, eludendo firewall e sistemi di monitoraggio del traffico.
• Tunneling ICMP: L’uso di pacchetti ICMP (tipicamente impiegati per il ping) consente al malware di stabilire canali di comunicazione nascosti, complicando ulteriormente il rilevamento.

Oltre a queste capacità, Squidoor implementa sofisticate tecniche di offuscamento del codice (MITRE ATT&CK T1027), rendendo difficile la sua analisi e individuazione da parte dei sistemi di difesa tradizionali.

Le tecniche di infezione e persistenza

L’attacco inizia con la compromissione di server Microsoft Internet Information Services (IIS). Gli aggressori sfruttano vulnerabilità note per ottenere accesso iniziale e poi installano web shell offuscate, che garantiscono un accesso persistente ai sistemi infetti.

Queste web shell si caratterizzano per l’uso di chiavi di decrittazione simili e una struttura del codice che suggerisce una matrice comune. L’obiettivo è mantenere il controllo della macchina infetta, consentendo l’esecuzione di comandi remoti e l’esfiltrazione di dati sensibili.

Dalla mappatura delle connessioni di Threat Intelligence (vedi immagine), emergono diversi indirizzi IP e domini malevoli associati alla campagna, tra cui:

• 104.244.72.123
• update.hciiter.com
• support.vmphere.com
• microsoft-beta.com
• zimbra-beta.info

Questi domini vengono utilizzati per le comunicazioni C2, permettendo agli attori della minaccia di eseguire operazioni di controllo e gestione dei dispositivi compromessi.

Le implicazioni per la sicurezza e le contromisure

L’uso di Squidoor rappresenta una minaccia significativa per le organizzazioni colpite, sia per la sua capacità di operare sotto traccia sia per la varietà di vettori di attacco impiegati. La capacità del malware di sfruttare protocolli legittimi come l’Outlook API e il DNS tunneling rende difficile il rilevamento mediante strumenti di sicurezza tradizionali.

Per proteggersi da questa minaccia, le organizzazioni devono adottare un approccio proattivo che includa:

• Aggiornamento e patching: Garantire che i sistemi, in particolare i server IIS, siano sempre aggiornati con le ultime patch di sicurezza per ridurre le superfici di attacco disponibili.
• Monitoraggio del traffico: Implementare soluzioni avanzate di monitoraggio in grado di individuare anomalie nel traffico di rete, soprattutto per quanto riguarda l’uso non convenzionale di DNS e ICMP.
• Analisi delle email: Monitorare le API di Outlook per identificare possibili abusi da parte di malware.
• Threat Intelligence e Response: Integrare strumenti di Threat Intelligence per individuare in anticipo gli indicatori di compromissione (IoC) associati a Squidoor e attivare contromisure adeguate.

L’attacco Squidoor dimostra l’evoluzione delle minacce APT e la necessità di difese avanzate per contrastarle. L’adozione di protocolli legittimi per scopi malevoli, unita alla capacità di operare su sistemi multipiattaforma, evidenzia l’importanza di strategie di sicurezza multilivello.

Le aziende e gli enti governativi devono essere consapevoli dei rischi e implementare misure di sicurezza avanzate per prevenire, rilevare e mitigare attacchi come questo. Solo attraverso un approccio basato su intelligence, monitoraggio continuo e aggiornamenti costanti è possibile contrastare minacce sofisticate come Squidoor e proteggere dati e infrastrutture critiche.

Resta aggiornato sulle ultime minacce di cybersecurity seguendo Red Hot Cyber.

L'articolo Squidoor: un’analisi della backdoor cinese che minaccia le organizzazioni globali proviene da il blog della sicurezza informatica.

Akira rappresenta una delle più recenti minacce ransomware in grado di aggirare i tradizionali strumenti di difesa delle organizzazioni. Un recente caso analizzato dal team di S-RM ha evidenziato come questo gruppo abbia utilizzato una webcam non protetta per distribuire il proprio payload, eludendo le difese di un sistema EDR (Endpoint Detection and Response).
Catena di attacco

Il modus operandi iniziale

L’attacco ha avuto inizio con la compromissione della rete della vittima attraverso una soluzione di accesso remoto esposta a internet. Dopo l’accesso, Akira ha implementato AnyDesk.exe, uno strumento di gestione remota, per mantenere il controllo dell’ambiente e procedere con l’esfiltrazione dei dati.

Durante la fase avanzata dell’attacco, gli aggressori hanno utilizzato il protocollo RDP (Remote Desktop Protocol) per spostarsi lateralmente all’interno della rete. Hanno poi tentato di distribuire il ransomware su un server Windows inviando un file ZIP protetto da password contenente l’eseguibile dannoso. Tuttavia, l’EDR implementato dall’organizzazione ha rilevato e bloccato la minaccia prima che potesse essere eseguita.

Il pivot sulla webcam

Dopo aver realizzato che l’EDR ostacolava la diffusione del ransomware, gli attaccanti hanno modificato la loro strategia. Un’analisi della rete interna ha rivelato la presenza di dispositivi IoT vulnerabili, tra cui webcam e scanner biometrici. In particolare, una webcam risultava esposta con le seguenti criticità:

• Presenza di vulnerabilità critiche che consentivano l’accesso remoto e l’esecuzione di comandi.
• Sistema operativo basato su Linux, compatibile con la variante ransomware per Linux di Akira.
• Assenza di protezione da parte dell’EDR o di altri strumenti di sicurezza.

Gli attaccanti hanno quindi utilizzato la webcam compromessa come punto di ingresso per distribuire il ransomware sulla rete della vittima. Il traffico SMB (Server Message Block) generato dal dispositivo per trasmettere il payload è passato inosservato, permettendo ad Akira di cifrare con successo i file sui sistemi aziendali.

Lessons learned

L’incidente ha messo in evidenza tre aspetti cruciali della sicurezza informatica:

1. Priorità nelle patch: Le strategie di gestione delle patch spesso si concentrano sui sistemi critici per il business, tralasciando dispositivi IoT che possono diventare punti di ingresso per gli attaccanti.
2. Evoluzione degli attaccanti: Akira ha dimostrato una notevole capacità di adattamento, passando da implementazioni in Rust a versioni in C++ e supportando sia ambienti Windows che Linux.
3. Limitazioni dell’EDR: L’EDR è uno strumento essenziale, ma la sua efficacia dipende dalla copertura, dalla configurazione e dal monitoraggio continuo. Dispositivi IoT spesso non sono compatibili con EDR, rendendoli vulnerabili agli attacchi.

Contromisure di sicurezza

Per mitigare minacce simili, le organizzazioni dovrebbero adottare le seguenti misure:

• Segmentazione della rete: Gli IoT dovrebbero essere isolati dai server e dai sistemi critici, limitando la loro connettività a porte e indirizzi IP specifici.
• Audit della rete interna: Controlli regolari sui dispositivi connessi possono identificare vulnerabilità e dispositivi non autorizzati.
• Gestione delle patch e delle credenziali: Aggiornare regolarmente il firmware dei dispositivi e sostituire le password di default con credenziali robuste.
• Spegnere i dispositivi non in uso: Se un dispositivo IoT non è necessario, dovrebbe essere disattivato per ridurre la superficie d’attacco.

Conclusioni

Il caso Akira evidenzia come gli attori delle minacce siano in grado di aggirare le misure di sicurezza tradizionali sfruttando punti deboli spesso trascurati, come i dispositivi IoT. Un’adeguata strategia di sicurezza che includa segmentazione di rete, monitoraggio continuo e aggiornamenti costanti è essenziale per ridurre il rischio di attacchi di questo tipo.

L'articolo Akira ransomware: la nuova minaccia che usa le webcam come porte d’ingresso proviene da il blog della sicurezza informatica.

Via libera al risarcimento per un gruppo di migranti a cui, dal 16 al 25 agosto del 2018, fu impedito di sbarcare al porto di Catania dalla nave Diciotti della guardia costiera che li aveva soccorsi in mare al largo di Lampedusa. È stato deciso dalle sezioni unite della Cassazione che, condannando il governo, ha rinviato il procedimento a un giudice per stabilire la quantificazione del danno.

Dice Meloni, "Così non si avvicinano i cittadini alle Istituzioni".

Questo varrà forse per i suoi elettori, a me sentenze del genere mi avvicinano eccome, mi ricordano che la legge è uguale per tutti e che neanche un Ministro dell'Interno infoiato contro i migranti può fare quello che gli pare.

#immigrazione #portichiusi

agi.it/cronaca/news/2025-03-07…

Mi chiedo cosa propongano all'atto pratico le persone che chiedono una "pace" indiscriminata, niente riarmo, "stop alla guerra".

In concreto cosa dovremmo fare? Aprire i confini e dire "prego!" ?

Il mondo buono, il mondo in cui si parla e le difficoltà si appianano diplomaticamente, lasciatevelo dire, NON ESISTE!

The fine researchers at Google have released the juicy details on EntrySign, the AMD Zen microcode issue we first covered about a month ago. And to give away the punchline: cryptography is hard. It’s hard in lots of ways, but the AMD problem here is all about keeping track of the guarantees provided by cryptographic primitives.

The vulnerability is in the verification of microcode updates for AMD’s Zen processor family. To understand microcode, you have to understand that X86-64 processors are actually built out of proprietary Reduced Instruction Set Computer (RISC) cores, that then emulate the more complex X86-64 complex instruction set computer (CISC) cores. Microcode is the firmware that controls that emulation step. For the security guarantees of modern computing, it’s rather important that CPUs only run signed microcode from the CPUs vendor. AMD has a pretty straightforward system to sign and then verify microcode patches.

Each patch includes a 2048-bit RSA public key and signature, verifying that the microcode was actually signed by the holder of the corresponding private key. The CPU hashes that public key, and compares it to a 128-bit value that was burned into the CPU at manufacture time. The intent is that if the hash matches, the public key must be the same. The problem was the hashing algorithm used for this step.

For this scheme to work, it would need a collision resistant cryptographic hashing function. The security of the scheme relies on the idea that it’s effectively impossible to find another public key that results in the same hash output. Finding a collision on that output value completely breaks the scheme.

AMD chose the AES Cipher Message Authentication Code (AES-CMAC) hash algorithm. AES-CMAC takes a message and key, and generates a Message Authentication Code (MAC). That MAC can then be used to verify that the message has not been tampered with. It can be thought of as a keyed hash with conditional collision resistance. But most importantly, if the secret key is known, none of those guarantees are valid. If the key is known, AES-CMAC fails to provide effective collision resistance in its output. And of course, the specific AES-CMAC key used in AMD Zen processors could be extracted, and turned out to be a NIST example key. To be clear, there is nothing wrong with AES-CMAC itself, it’s just the wrong algorithm for this use.

There’s one more clever trick that was needed to pull this together. The AES-CMAC collision only generates a public RSA key. How would an attacker take this arbitrary public key and produce the private key needed to sign these microcode updates? Isn’t one of the primary guarantees of RSA itself, that the private key can’t be derived from the public key? Only if the keypair is actually based on large prime numbers. After generating a few of these candidate public keys, one was discovered that was relatively easy to factor, as it was the product of more than just two primes. AMD’s fix replaces this hashing function with an appropriate cryptographic hash, preventing any microcode tampering.

Telegram and EvilLoader

The Telegram app has a weird problem deciding what to do with a .htm file sent as a video using the telegram API. Telegram tries to treat it as a video, and offers to open an external program to play the video. Because it’s actually HTML content, the “video” is opened in the browser, potentially running malicious JavaScript in that context.

This can be further used to trick an unsuspecting user into downloading a fake video player APK, to try to play this video, potentially leading to device compromise. This vulnerability is still unpatched as of time of writing, but has been widely known in the expected places. It may not be a 0-click RCE, but this one still has the potential for misuse.

More Info on The Heist

Last week we told you about the biggest heist in history, with Bybit getting hacked for cryptocurrency worth $1.5 billion. We know a bit more now, as the Bybit CEO has published the preliminary security report. The short story is that the North Korean Lazarus Group compromised a Safe{Wallet} developer workstation and gained access to an AWS or CloudFront API key. This was used to serve malicious JavaScript to Bybit, and that JavaScript disguised a malicious transaction, leading to the loss.

In retrospect there’s a glaring security problem with the Safe{Wallet} system that Bybit used: The reliance on JavaScript served from an outside server. It should take more than simple access to an AWS account to pull off a $1.5 billion heist.

Hyperjack

What happens when a process in a Virtual Machine (VM) can escape the virtual environment and take over the hypervisor? Nothing good. It’s known as hyperjacking, and VMware has a trio of vulnerabilities that makes it possible, across every version of ESXi, Workstation, Fusion, and Telco platforms — everything containing the ESX hypervisor.

And VMware says the vulnerabilities are being used in-the-wild. Patches are available, and this seems like a definite hair on fire scenario for anyone that may have untrusted tenants on VMware powered VMs.

Bits and Bytes

Have you ever wondered if a Stingray was operating in your area? That’s the cell tower simulator used to capture and analyze cell traffic, potentially breaking cell phone call encryption. EFF has released Rayhunter, and open source tool that captures cellular traffic and tries to detect Stingray-style traffic manipulation. The best part is that it runs on the Orbic RC400L mobile hotspot, a $20 piece of hardware.

How long does it take for your infrastructure to be probed after accidentally posting an AWS key online? As little as 10 hours, according to tests done by Clutch Security. Some forums are a bit friendlier, with Reddit users pointing out the leaked key and the post eventually getting deleted for the same reason.

And finally we have the four horsemen of WordPress Backdoors. About a thousand WordPress sites were infected with a JavaScript file, and this campaign spared no expense with adding backdoors to the sites. The infection added a malicious plugin, code into wp-config.php, new SSH keys, and what looks like a reverse shell. Somebody really wants to maintain access to those WordPress sites.

hackaday.com/2025/03/07/this-w…

Ieri sera lui mi dice: "Non capisco perché devo avere queste raccolte organizzate in automatico e non posso banalmente avere una cartella con le foto e una con i video."

E io: "Vedi, per quanto, dopo 20 anni, il tuo utilizzo del computer continui ad essere basico, la logica ti dice che dovresti avere delle cartelle organizzate come vuoi tu. Ma Mr. Google, per farti sentire servito e riverito, decide di pulirti il sedere ogni volta che ne hai bisogno... Solo che non te lo pulisce come vuoi tu, e inoltre, racconta a tutti quante volte vai al cesso!"

Da "Colonne", la newsletter del Post su Milano.

Dall'inizio di marzo le persone trans e non binarie la cui identità di genere non è ancora stata riconosciuta dallo stato possono fare richiesta per far scrivere il nome che hanno scelto (e non quello registrato all'anagrafe) sulla tessera dell'abbonamento ai mezzi pubblici Atm.

atm.it/it/ViaggiaConNoi/Abbona…

Saying farewell is hard, and in the case of the Voyager 1 & 2 spacecraft doubly so, seeing as how they have been with us for more than 47 years. From the highs of the 1970s and 1980s during their primary mission in our Solar System, to their journey into the unknown of Deep Space, every bit of information which their instruments record and send back is something unique that we could not obtain any other way. Yet with the shutting down of two more instruments, both spacecraft are now getting awfully close to the end of their extended missions.

Last February 25 the cosmic ray system (CRS) on Voyager 1 was disabled, with the Low Energy Charged Particle Instrument (LECP) on Voyager 2 to follow on March 24. With each spacecraft losing about 4 watts of available power per year from their RTGs, the next few instruments to be turned off are already known. Voyager 1’s LECP will be turned off next year, with that same year Voyager 2’s CRS also getting disabled.

This would leave both spacecraft with only their magnetometer (MAG) and plasma wave subsystem (PWS). These provide data on the local magnetic field and electron density, respectively, with at least one of these instruments on each spacecraft likely to remain active until the end of this decade, possibly into the next. With some luck both spacecraft will see their 50th birthday before humanity’s only presence in Deep Space falls silent.

Thanks to [Mark Stevens] for the tip.

hackaday.com/2025/03/07/the-lo…