Recovering Data from the OceanGate depths

When the files on the Titan submersible disaster were published, most people skimmed for drama. Hackers, however, would likely zoom in on the hardware autopsy. [Scott Manley] actually did this. He faced a hacker’s nightmare: three crushed PCs, bent SSDs, and an encrypted SD card from a camera that survived six kilometres under pressure, all sealed in titanium and silence.

[Scott] went all in to resurrect data. First came CT scans: firing 320 kV X-rays through a kilo of mangled electronics to hunt for intact NAND chips. When that failed, he desoldered UFS memory by hand, used custom flash readers, cloned NV-RAMs, and even rebuilt boards to boot salvaged firmware. The ultimate test was grafting the recovered chips onto donor hardware in Canada. Like the monster of Frankenstein, the system came to life.

In the end, it partially worked. Twelve stills and nine videos were retrieved, albeit none from the fatal dive. The process itself was a masterclass in deep hardware forensics, here covered in a video worth watching.

youtube.com/embed/qMUjCZ7MMWQ?…

hackaday.com/2025/10/31/recove…

Building A Clamshell Writer Deck

Most of us do our writing on computers these days, but the modern computing environment does present a lot of distractions. That’s let to the concept of the writer deck, a simplified device intended more specifically for word processing tasks. [Ashtf] has built a great example of the form with a modified version of the PocketMage device.

The PocketMage is a clamshell PDA device that [Ashtf] has been working on for some time. It’s powered by an ESP32, hooked up to a nice e-ink display. In its basic form, it’s not the ideal device for doing serious writing work, mostly because of its tiny keyboard. However, [Ashtf] has since added external keyboard support, which completely changes the game. With the use of a small USB C to USB A adapter, you can hook up any conventional USB keyboard that you like to best attain your maximum typing speed.

The result is a compact, simple device that lets you type away without distractions. If your latest fanfic isn’t coming along quickly enough because you keep losing focus to social media, perhaps this is a route you might like to go. [Ashtf] also included Markdown support so you can create richer documents on the device while operating in what is still fundamentally a text-only environment.

It’s neat to build custom devices that suit your own personal productivity needs. If you dig the PocketMage, you might like to check out the design files on Github. We’ve featured some other fun writer decks before, too. Video after the break.

youtube.com/embed/TXqvZpyvmZY?…

hackaday.com/2025/10/31/buildi…

This Week in Security: Vibecoding, Router Banning, and Remote Dynamic Dependencies

Vibecoding. What could possible go wrong? That’s what [Kevin Joensen] of Baldur wondered, and to find out he asked Anthropic’s Sonnet 4.5 to build a secure login with Two Factor Authentication (2FA). And to the LLM’s credit, it builds the app as requested. [Kevin] took a peek under the hood to see how well the security was handled, and it wasn’t great.

Up first, the Flask app doesn’t have any rate-limiting for guessing that time-based 2FA code. A 6-digit time-based 2FA only works if you can’t try all the possibilities before a given code expires. So what does a vibecoder do, once this has been noticed? Ask the LLM to fix it of course. Here we take a slightly different approach, prompting the AI to double-check its work: “Is there any security features missing in 2fa verify step?” The answer is an impressive:

Great question! Yes, there are several critical security features missing from the 2FA verification step. Let me highlight the most important ones: Critical Security Issues1. No Rate Limiting (MOST CRITICAL)

But the critical question, can it properly fix its mistake? The AI adds the flask-limiter library and chooses 10 attempts per minute, which is a bit loose, but not unreasonable. There’s still an issue, that those attempts are limited by IP address instead of user login. All it takes to bypass that rate limiting is a pool of IP addresses.

This experiment starts to go off the rails, as [Kevin] continues to prompt the LLM to look for more problems in its code, and it begins to hallucinate vulnerabilities, while not fixing the actual problem. LLMs are not up to writing secure code, even with handholding.

But surely the problem of LLMs making security mistakes isn’t a real-world problem, right? Right? Researchers at Escape did a survey of 5,600 vibecoded web applications, and found 2,000 vulnerabilities. Caveat Vibetor.

“Secure” Enclave

A few weeks ago we talked about Battering RAM and Wiretap — attacks against Trusted Execution Environments (TEEs). These two attacks defeated trusted computing technologies, but were limited to DDR4 memory. Now we’re back with TEE-fail, a similar attack that works against DDR5 systems.

This is your reminder that very few security solutions hold up against a determined attack with physical access. The Intel, AMD, and Nvidia TEE solutions are explicitly ineffective against such physical access. The problem is that no one seemed to be paying attention to that part of the documentation, with companies ranging from Cloudflare to Signal getting this detail wrong in their marketing.

Banning TP-Link

News has broken that the US government is considering banning the sale of new TP-Link network equipment, calling the devices a national security risk.

I have experience with TP-Link hardware: Years ago I installed dozens of TL-WR841 WiFi routers in small businesses as they upgraded from DSL to cable internet. Even then, I didn’t trust the firmware that shipped on these routers, but flashed OpenWRT to each of them before installing. Fun fact, if you go far enough back in time, you can find my emails on the OpenWRT mailing list, testing and even writing OpenWRT support for new TP-Link hardware revisions.

From that experience, I can tell you that TP-Link isn’t special. They have terrible firmware just like every other embedded device manufacturer. For a while, you could run arbitrary code on TP-Link devices by putting it inside backticks when naming the WiFi network. It wasn’t an intentional backdoor, it was just sloppy code. I’m reasonably certain that this observation still holds true. TP-Link isn’t malicious, but their products still have security problems. And at this point they’re the largest vendor of cheap networking gear with a Chinese lineage. Put another way, they’re in the spotlight due to their own success.

There is one other element that’s important to note here. There is still a significant TP-Link engineering force in China, even though TP-Link Systems is a US company. TP-Link may be subject to the reporting requirements of the Network Product Security legislation. Put simply, this law requires that when companies discover vulnerabilities, they must disclose the details to a particular Chinese government agency. It seems likely that this is the primary concern in the minds of US regulators, that threat actors cooperating with the Chinese government are getting advanced notice of these flaws. The proposed ban is still in proposal stage, and no action has been taken on it yet.

Sandbox Escape

In March there was an interesting one-click exploit that was launched via phishing links in emails. Researchers at Kaspersky managed to grab a copy of the malware chain, and discovered the Chrome vulnerability used. And it turns out it involves a rather novel problem. Windows has a pair of APIs to get handles for the current thread and process, and they have a performance hack built-in: Instead of returning a full handle, they can return -1 for the current process and -2 for the current thread.

Now, when sandboxed code tries to use this pseudo handle, Chrome does check for the -1 value, but no other special values, meaning that the “sandboxed” code can make a call to the local thread handle, which does allow for running code gadgets and running code outside the sandbox. Google has issued a patch for this particular problem, and not long after Firefox was patched for the same issue.

NPM and Remote Dynamic Dependencies

It seems like hardly a week goes by that we aren’t talking about another NPM problem. This time it’s a new way to sneak malware onto the repository, in the form of Remote Dynamic Dependencies (RDD). In a way, that term applies to all NPM dependencies, but in this case it refers to dependencies hosted somewhere else on the web. And that’s the hook. NPM can review the package, and it doesn’t do anything malicious. And when real users start downloading it, those remote packages are dynamically swapped out with their malicious versions by server-side logic.

Installing one of these packages ends with a script scooping up all the data it can, and ex-filtrating it to the attacker’s command and control system. While there isn’t an official response from NPM yet, it seems inevitable that NPM packages will be disallowed from using these arbitrary HTTP/HTTPS dependencies. There are some indicators of compromise available from Koi.

Bits and Bytes

Python deserialization with Pickle has always been a bit scary. Several times we’ve covered vulnerabilities that have their root in this particular brand of unsafe deserialization. There’s a new approach that just may achieve safer pickle handling, but it’s a public challenge at this point. It can be thought of as real-time auditing for anything unsafe during deserialization. It’s not ready for prime time, but it’s great to see the out-of-the-box thinking here.

This may be the first time I’ve seen remote exploit via a 404 page. But in this case, the 404 includes the page requested, and the back-end code that injects that string into the 404 page is vulnerable to XML injection. While it doesn’t directly allow for code execution, this approach can result in data leaks and server side request forgeries.

And finally, there was a sketchy leak, that may be information on which mobile devices the Cellebrite toolkit can successfully compromise. The story is that [rogueFed] sneaked into a Teams meeting to listen in and grab screenshots. The real surprise here is that GrapheneOS is more resistant to the Cellebrite toolkit than even the stock firmware on phones like the Pixel 9. This leak should be taken with a sizable grain of salt, but may turn out to be legitimate.

hackaday.com/2025/10/31/this-w…

Scared for a Drink?

Halloween is about tricks and treats, but who wouldn’t fancy a bit to drink with that? [John Sutley] decided to complete his Halloween party with a drink dispenser looking as though it was dumped by a backstreet laboratory. It’s not only an impressive looking separating funnel, it even runs on an Arduino. The setup combines lab glassware, servo motors, and an industrial control panel straight from a process plant.

The power management appeared the most challenging part. The three servos drew more current than one Arduino could handle. [John] overcame voltage sag, brownouts, and ghostly resets. A healthy 1000 µF capacitor across the 5-volt rail fixed it. With a bit of PWM control and some C++, [John] managed to finish up his interactive bar system where guests could seal their own doom by pressing simple buttons.

This combines the thrill of Halloween with ‘the ghost in the machine’. Going past the question whether you should ever drink from a test tube – what color would you pick? Lingonberry juice or aqua regia, who could tell? From this video, we wouldn’t trust the bartender on it – but build it yourself and see what it brings you!

youtube.com/embed/8pY9TOOwmnc?…

hackaday.com/2025/10/31/scared…

Le Security Operations al tempo dell’Artificial Intelligence

A cura di Vicki Vinci, SOC Architect – International di Fortinet

Il trend tecnologico di assoluto maggior rilievo degli ultimi anni è senza dubbio l’avvento dell’Artificial Intelligence soprattutto declinata nella sua componente generativa (GenAI). Accantonando per il momento le considerazioni su come il mercato ne abbia fatto adozione, non è negabile che nel mondo della sicurezza questa evoluzione abbia portato una serie di cambiamenti molto significativi.
A cura di Vicki Vinci, SOC Architect – International di Fortinet
Proviamo ad analizzare alcuni casi d’uso su cui l’industria della security e la community hanno provato a focalizzare maggiormente l’attenzione:

1. Come l’AI viene utilizzata dagli attaccanti
2. L’ AI nelle attività di chi deve difendere
3. Come le soluzioni di GenAI possono venire attaccate
4. Le modalità in cui si possono proteggere i motori di LLM

Partendo dal primo esempio non v’è dubbio che la possibilità di utilizzare strumenti di GenAI abbia facilitato e di molto il compito degli attaccanti su molteplici fronti:

• La facilità nella creazione di codice malevolo in grado di aggirare le difese classiche messe in atto dalle organizzazioni
• Il supporto al perfezionamento di campagne di phishing con testi sempre più perfezionati e repliche fedeli di messaggi e portali realmente in uso da parte degli utenti
• L’integrazione delle funzionalità native degli LLM a supporto di variegate campagne d’attacco automatizzandone ed ottimizzandone le fasi partendo dallaReconnaissance, la Weaponization, fino a Installation, Command and Control (C2) terminando con Actions on Objectives

Allo stesso tempo chi ha come sua missione la difesa, viene affiancato da soluzioni in grado di:

• Accelerare la capacità di Triage aumentandone anche la profondità di dettaglio
• Produrre componenti delle soluzioni di SecOps (playbooks, connettori, ecc.) in maniera semplificata e quanto più sempre nella direzione di uno sviluppo codeless
• Mettere in campo specifiche attività di riconoscimento, contenimento e remediation automatizzate attraverso soluzioni di AgenticAI

Perché questa serie di opzioni possa essere messa in campo, uno degli elementi fondamentali è la disponibilità di un motore di LLM (pubblico o privato che sia) che inevitabilmente diventa a sua volta oggetto di possibili attacchi. La disponibilità, l’integrità e confidenzialità dei contenuti sono messi in pericolo sia singolarmente che in modo congiunto a seconda delle metodologie utilizzate.

A tal proposito i modus operandi che vediamo essere messi in atto dai Threat Actors con maggiore frequenza sono:

• Attacchi volumetrici e qualitativi sulle risorse di calcolo destinate alla fruizione del LLM (DdoS)
• Prompt injection per costruire Bias tali da produrre allucinazioni da parte del motore di LLM o attività di mass-query per estrapolazione delle informazioni contenute
• Attacchi “tradizionali” per colpire le componenti infrastrutturali coinvolte nell’erogazione del servizio (network, compute, application-layer)
• Accessi non autorizzati a motori di LLM privati tramite credenziali compromesse o accessi di rete non correttamente presidiati

In ultima istanza l’industria della Cyber Security si è messa in movimento per dare il suo contributo nella difesa di questa componente sempre più fondamentale nella nostra economia digitale. Mappando le tipologie di attacco appena citate, le soluzioni che stanno guidando il mercato sono:

• Soluzioni di GSLB, Waf e CNAPP
• Prodotti di Deep Inspection che disaccoppiano la sessione dell’utente rispetto all’accesso sulla componente di front-end del motore di LLM, strumenti di DLP e di monitoraggio
• Firewalling, strumenti di API protection
• Unified SASE, ZTNA, MFA e segregazione della rete

In ognuno di questi casi d’uso, l’ingresso degli strumenti di Artifical Intelligence ha cambiato radicalmente il livello qualitativo ma anche le tempistiche collegate alle varie fasi dell’attacco. Se in precedenza l’intervento umano era ancora una componente fondamentale in alcuni dei passaggi, oggi molte di queste attività possono essere delegate a macchine che sono in grado sia di accelerare che di parallelizzare i task accorciandone le tempistiche e moltiplicandone i volumi.

Con queste premesse diventa mandatorio mettere a disposizione dei Blue-Team strumenti che possano contrastare le nuove modalità d’attacco pareggiandone sia i tempi che le quantità. L’obiettivo finale è quello di mettere a disposizione dell’analista informazioni quanto più possibile ricche di dettaglio e che minimizzino il tempo di analisi e decisione delle contromisure, quando non siano già state messe in campo in maniera automatizzata.

Se gli attaccanti stanno utilizzando sempre più la tecnologia (oltre che le tecniche di Social Engineering) elevando la potenza delle loro attività nella scala del “tempo-macchina”, anche i difensori non possono esimersi da adottare strategie e strumenti che permettano loro di rispondere nello stesso ordine di grandezza della scala temporale. Minimizzare il dwell time farà sempre più la differenza tra un attacco andato a buon fine da un’eccellente capacità di risposta e contenimento.

Per tutti gli approfondimenti del caso è disponibile la pagina dedicata.

L'articolo Le Security Operations al tempo dell’Artificial Intelligence proviene da Red Hot Cyber.

La corsa alla cybersicurezza è partita e l’Italia corre con le scarpe legate

Negli ultimi anni la cybersecurity è balzata in cima all’agenda di imprese, istituzioni e pubblica amministrazione. Ma se guardiamo ai numeri, l’Italia sembra ancora correre con le scarpe legate: investe circa lo 0,12% del PIL in sicurezza digitale, meno della metà di Francia e Germania e appena un terzo rispetto a Regno Unito e Stati Uniti (fonti: Rapporto Clusit 2025, DeepStrike Cybersecurity Spend Report 2025).

Questo budget ridotto si traduce in un parco strumenti spesso vecchio e polveroso, incapace di tenere il passo con la mole e la complessità degli attacchi. Il Rapporto Clusit 2025 fotografa una realtà che non lascia spazio a speranze: gli attacchi gravi nel nostro Paese sono cresciuti del 15,2% nell’ultimo anno e quasi ogni giorno qualcuno subisce danni rilevanti, certificati da 357 incidenti gravi che sono stati registrati nel 2024.

Aggiungiamo al quadro un ritardo digitale che pesa come un macigno: appena il 45% degli italiani ha competenze digitali di base, e molte aziende arrancano a trovare profili specializzati per difendersi (fonte: DESI Digital Skills Report 2025). In pratica, questa carenza crea una rete di sicurezza fatta più di buchi che di protezione.

Nulla di nuovo per gli attaccanti, che ci attaccano con automatismi che nelle realtà italiane pubbliche e private – dove anche acquistare una tecnologia, un corso di formazione, oppure un servizio di consulenza è una corsa ad ostacoli – sono pura fantasia: è la nuova realtà, non un’eccezione da tamponare.

E qui salta fuori il CISO, il capo della sicurezza digitale, figura che non può più essere solo un tecnico ingegnoso o un giurista pedante: serve un mix tra diritto, tecnologia, gestione e comunicazione. Chi occupa questo ruolo deve saper trasformare un linguaggio tecnico complesso in argomentazioni convincenti per i vertici dell’organizzazione, spesso poco inclini a capire che la sicurezza non è tecnologia, ma strategia.

L’asimmetria tra chi difende e chi attacca è quasi una barzelletta a denti stretti: i malintenzionati spesso hanno più budget, meno regole e più libertà d’azione. È urgente un cambio di passo che prenda in considerazione investimenti coordinati, sviluppo di competenze ampie e un cambio culturale profondo.

Ogni giorno che passa senza un cambio deciso, il rischio per il sistema Paese cresce fino al prossimo report. La cybersecurity non è più un’opzione, ma è un asset fondamentale per la sopravvivenza in un mondo iperconnesso.

Per approfondire come preparare professionisti capaci di questo salto, rimando al “Manuale CISO Security Manager”, che offre un percorso concreto di formazione multidisciplinare.

L'articolo La corsa alla cybersicurezza è partita e l’Italia corre con le scarpe legate proviene da Red Hot Cyber.