Il Professionista della Sicurezza Informatica sotto la Lente del Codice Penale

L’inarrestabile metamorfosi delle tecnologie dell’informazione ha trasformato radicalmente i paradigmi di protezione dei beni giuridici. In un’epoca dove la robustezza delle infrastrutture critiche è diventata sinonimo di sicurezza nazionale, chi opera nella cybersecurity non è più un semplice tecnico ma un attore centrale investito di responsabilità che travalicano il perimetro dei bit per approdare nelle aule di giustizia. Come avvocato che da anni seziona i reati informatici in tribunale e come docente che cerca di trasmettere la dogmatica di questa materia, avverto l’urgenza di fare chiarezza su un punto fondamentale: oggi l’operatore IT non è solo il difensore del sistema ma può diventarne, per azione o per una fatale omissione, il responsabile legale davanti allo Stato.

La mappatura dei ruoli e l’identificazione della posizione di garanzia

L’Agenzia per la Cybersicurezza Nazionale ha adottato lo European Cybersecurity Skills Framework per classificare le figure professionali e questa non è una mera operazione burocratica. In sede giudiziaria, questa catalogazione funge da parametro per identificare quella che noi giuristi chiamiamo posizione di garanzia. Ogni ruolo porta con sé una specifica esposizione al rischio penale. Se pensiamo al CISO, ci troviamo di fronte al vertice della gestione della sicurezza. Ai sensi dell’articolo 40 del Codice Penale, non impedire un evento che si ha l’obbligo giuridico di evitare equivale a cagionarlo. Se un responsabile omette di segnalare vulnerabilità critiche o non richiede gli investimenti necessari pur consapevole del rischio imminente, potrebbe essere chiamato a rispondere degli effetti dannosi di un attacco come se lo avesse agevolato.

Operatività tecnica e il rischio di condotte attive illecite

Per le figure più operative come i Cybersecurity Architect o i Responder, il rischio è spesso legato alla condotta attiva. L’installazione di programmi di monitoraggio che possono essere interpretati come strumenti di intercettazione abusiva o la configurazione di backdoor non autorizzate integra fattispecie di reato se non supportata da una delega formale. Durante la gestione di un incidente, manovre di emergenza eccessivamente intrusive potrebbero causare il danneggiamento di dati o la violazione della segretezza delle comunicazioni. Ancora più delicata è la posizione del Digital Forensics Investigator. Un errore nella catena di custodia o l’alterazione di un supporto informatico può non solo invalidare un processo ma esporre il professionista ad accuse di falso o inquinamento probatorio.

Il sottile confine del penetration testing e il valore del consenso

L’articolo 615-ter c.p. rimane il pilastro della tutela del domicilio informatico e la sua interpretazione è più insidiosa di quanto sembri. La giurisprudenza della Cassazione ha chiarito che l’accesso è abusivo ogni volta che un soggetto pur dotato di credenziali legittime si trattiene nel sistema violando le disposizioni del titolare o agendo per scopi ontologicamente estranei alle finalità per cui il potere gli è stato conferito. Un amministratore di sistema che accede ai log di un collega per curiosità personale commette un reato anche se possiede tecnicamente le chiavi per farlo. In questi casi l’abuso della qualità di operatore costituisce un’aggravante che trasforma la procedibilità da querela a d’ufficio, rendendo l’azione penale inevitabile.

Il penetration tester si trova in una posizione paradossale: la sua attività materiale è formalmente identica a un attacco criminale. L’unica scriminante che separa la sua condotta dal reato è il consenso dell’avente diritto previsto dall’articolo 50 del Codice Penale. Tuttavia questo consenso deve essere preventivo, informato e soprattutto specifico. Un tester che durante un’attività autorizzata decide autonomamente di estendere il raggio d’azione a una rete interna non inclusa nel contratto commette il reato di accesso abusivo.

Affinché un professionista sia ritenuto penalmente responsabile per un data breach o un attacco ransomware, invece, la pubblica accusa deve dimostrare la sussistenza di un nesso di causalità ipotetica. Si deve cioè provare che se la misura di sicurezza omessa (come l’applicazione di una patch critica già disponibile) fosse stata adottata, l’evento con elevata probabilità non si sarebbe verificato. La colpa professionale si manifesta nell’ignorare i risultati di test di vulnerabilità o nella scelta di fornitori palesemente inadeguati per ragioni di risparmio. La Direttiva NIS 2 ha accentuato questo profilo eliminando lo scudo della sola responsabilità societaria e introducendo la responsabilità personale degli organi di gestione per l’inottemperanza agli obblighi di sicurezza.

La rivoluzione della Legge 90 del 2024 e le nuove sfide dell’IA

Il recente intervento legislativo ha inasprito le pene per l’accesso abusivo fino a dieci anni di reclusione se l’azione causa il danneggiamento del sistema o se colpisce infrastrutture di interesse pubblico. È stata inoltre introdotta un’aggravante specifica per l’estorsione commessa mediante reati informatici, un punto che tocca da vicino i CISO coinvolti nella gestione di trattative ransomware. A questo si aggiungono le nuove frontiere dell’intelligenza artificiale con il reato di diffusione illecita di contenuti generati tramite IA per trarre in inganno o causare danno. Per chi si occupa di sicurezza, l’uso di tecniche generative AI per simulazioni di social engineering deve essere ora più che mai autorizzato nei minimi dettagli per non incorrere nelle nuove sanzioni.

La complessità di questo quadro impone al professionista moderno l’adozione di rigorose strategie di compliance. È fondamentale verbalizzare ogni richiesta di budget o di intervento tecnico negata dalla direzione per poter dimostrare in sede penale la propria mancanza di colpa. Per i consulenti, la chiave della sicurezza legale risiede nelle Rules of Engagement. Il contratto deve definire in modo puntuale indirizzi IP target, finestre temporali e tecniche escluse. La sicurezza informatica non è più una disciplina esclusivamente tecnica e la tolleranza verso la zona grigia della gestione IT si è azzerata. Solo agendo nel perimetro della legge l’esperto di cybersecurity può dirsi realmente al sicuro dai rischi intrinseci alla sua professione.

L'articolo Il Professionista della Sicurezza Informatica sotto la Lente del Codice Penale proviene da Red Hot Cyber.

Il lato oscuro del sandboxing Windows: vulnerabilità nel Brokering File System

Microsoft ha introdotto circa due anni fa Win32 App Isolation, un meccanismo pensato per rafforzare l’isolamento delle applicazioni sui sistemi Windows client. In parallelo è stato rilasciato il Brokering File System (BFS), un driver incaricato di mediare l’accesso a file system, pipe e registro da parte delle applicazioni eseguite in ambienti isolati, rendendolo una componente potenzialmente interessante dal punto di vista della sicurezza.

In questo contesto si colloca il CVE-2025-29970, una vulnerabilità di tipo use-after-free individuata nel driver bfs.sys, inizialmente scoperta da HT3Labs. L’analisi tecnica è stata condotta sulla versione 26100.4061 del driver e riguarda un errore nella gestione della memoria associata alle strutture interne di BFS.

BFS nasce insieme ad AppContainer e successivamente ad AppSilo, con l’obiettivo di controllare le operazioni di I/O provenienti da contesti isolati. Per farlo utilizza una serie di strutture dati che consentono di applicare policy di accesso basate su utente, applicazione e percorso, garantendo al contempo buone prestazioni.

Al centro di questo meccanismo c’è la PolicyTable, che memorizza le singole PolicyEntry in una tabella hash. Ogni PolicyEntry rappresenta una regola di accesso e include informazioni come il SID dell’utente, il SID dell’AppContainer e un riferimento a uno StorageObject, oltre a un contatore di riferimenti utilizzato per la gestione del ciclo di vita.

Lo StorageObject contiene i dettagli sui percorsi regolati dalla policy e utilizza più strutture interne, tra cui una DirectoryBlockList, una lista concatenata che rappresenta file e sottodirectory associati alla policy. Questa lista viene allocata quando viene aperta una directory radice e popolata con una o più voci nel corso del tempo.

La vulnerabilità CVE-2025-29970 emerge durante la fase di rimozione di una policy, in particolare nella funzione BfsCloseStorage. Durante la deallocazione della DirectoryBlockList, l’inizio della lista viene liberata all’interno del ciclo che scorre gli elementi, causando una dereferenziazione di memoria già liberata nel caso in cui la lista contenga più di una voce.

Microsoft ha corretto il problema separando la logica di deallocazione. Con l’introduzione della funzione BfsCloseRootDirectory, tutti gli elementi della lista concatenata vengono liberati prima della deallocazione della sua testa, eliminando così la condizione di use-after-free alla radice.

Dal punto di vista dello sfruttamento, la vulnerabilità offre margini limitati: il puntatore coinvolto non consente letture o scritture arbitrarie e la finestra temporale tra la liberazione della memoria e il suo riutilizzo è estremamente ridotta. Nonostante ciò, il caso conferma come driver legati al sandboxing restino una superficie d’attacco rilevante, soprattutto con l’aumento delle funzionalità di isolamento su Windows.

L'articolo Il lato oscuro del sandboxing Windows: vulnerabilità nel Brokering File System proviene da Red Hot Cyber.

FibreSeeker 3: Continuous Carbon Fiber vs Chopped CF

Although you can purchase many types of FDM filaments containing ‘carbon fiber’ these days, they are in no way related to the carbon fiber (CF) composite materials used for rocket hulls and light-weight bicycles. This is because the latter use continuous fibers, often in weaved CF mats, whereas the FDM filaments just use small, chopped, fragments of CF. Obviously this will not result in the same outcome, which makes it interesting that a company called Fibre Seek is now running a KickStarter for a very affordable co-extrusion FDM printer that can add continuous CF to any part. They also sent a few test parts to [Dr. Igor Gaspar] for testing against regular FDM CF prints.

It should be noted here that continuous CF with FDM is not new, as Markforged already does something similar, though at a ‘Contact us for a price quote’ level. The advantage of the Fibre Seek solution is then the co-extrusion that would make printing with continuous CF much more flexible and affordable. Based on the (sponsored) [CNC Kitchen] video of a few weeks ago at a tradeshow, the FibreSeeker 3 printer is effectively a standard CoreXY FDM printer, with the special co-extrusion dual print head that allows for CF to be coated with the target thermoplastic before being printed as normal.

Unfortunately for [Igor] he did not have a FibreSeeker 3 to print on, and the print request for his usual test samples got mixed up by Fibre Seek, leaving him with only 4 out of 10 items to test with. This makes this a bit of an abbreviated test, but should still provide some useful data relative to the Polymaker PETG-CF filament that was used for comparison.

Based on the limited test set, it can be said that the FibreSeeker 3 parts did generally better than the PETG-CF parts, albeit with a few asterisks. Accordingly, [Igor] is left feeling somewhat confused by Fibre Seek, but sees the potential of this new co-extrusion technology. It just feels like the FibreSeeker 3 printer is not quite finished yet, and that the true value of this approach and this new printer will have to prove themselves.

youtube.com/embed/k9qs7uOwA64?…

youtube.com/embed/dQp7yz6fzH0?…

hackaday.com/2025/12/25/fibres…

Malware macOS nordcoreano sfrutta finti colloqui di lavoro per rubare credenziali

Un’analisi approfondita statica e dinamica ha portato all’individuazione di un malware per macOS denominato DriverFixer0428, classificato come ladro di credenziali e attribuito con un livello di confidenza medio-alto alla campagna nordcoreana nota come “Contagious Interview”. Il campione si presenta come una presunta utility di sistema, progettata per indurre l’utente a fidarsi dell’applicazione e a interagire con essa.

Il comportamento principale del malware consiste nella raccolta delle credenziali di accesso del sistema macOS. Per ottenere questo risultato, DriverFixer0428 utilizza finestre di dialogo artefatte che riproducono fedelmente i prompt di sicurezza del sistema operativo e le richieste di autorizzazione di Google Chrome, sfruttando tecniche di ingegneria sociale. Le credenziali inserite vengono successivamente inviate a infrastrutture controllate dagli attaccanti attraverso l’API di archiviazione cloud di Dropbox.

Il nome del campione deriva da riferimenti interni presenti nel binario analizzato. Durante l’analisi statica sono emersi identificatori come DriverFixer0428, OverlayWindowController e riferimenti a file Swift, suggerendo una struttura applicativa coerente con un progetto legittimo. Il suffisso “0428” viene interpretato come un possibile riferimento alla data di compilazione del malware, il 28 aprile, oppure a una numerazione interna di versione utilizzata dagli sviluppatori della minaccia.

Dal punto di vista tecnico, il campione analizzato corrisponde a un binario universale Mach-O, compatibile con architetture x86_64 e ARM64, scritto in Swift e basato su AppKit. Il file ha una dimensione di circa 235 KB, utilizza l’identificativo di pacchetto chrome.DriverFixer0428 ed è associato al percorso sorgente DriverFixer0428/ViewController.swift. L’hash SHA-256 del campione è 9aef4651925a752f580b7be005d91bfb1f9f5dd806c99e10b17aa2e06bf4f7b5.

L’attribuzione alla Corea del Nord si basa su una correlazione delle tecniche, tattiche e procedure con campagne già documentate pubblicamente. Sebbene l’hash specifico non risulti presente nei principali database di threat intelligence, le somiglianze operative collegano il campione alle famiglie FlexibleFerret, FrostyFerret, ChromeUpdate e CameraAccess, tutte associate alla stessa attività di minaccia. In particolare, l’infrastruttura di rete coincide con quella descritta da SentinelOne nel febbraio 2025.

Le comunicazioni di rete osservate includono il contatto con api.ipify.org per determinare l’indirizzo IP pubblico del sistema compromesso e l’utilizzo delle API di Dropbox per la gestione dei token OAuth e il caricamento dei dati esfiltrati. Questa scelta consente al malware di mascherare il traffico malevolo dietro servizi cloud legittimi, riducendo la probabilità di rilevamento da parte dei controlli di sicurezza basati sulla rete.

L’analisi dinamica condotta tramite il debugger LLDB ha evidenziato un articolato sistema di evasione delle sandbox. DriverFixer0428 esegue controlli runtime per individuare ambienti virtualizzati interrogando API di sistema come sysctlbyname, il registro IOKit e l’API NSScreen. In presenza di una macchina virtuale o di un ambiente di analisi, il malware evita di attivare il payload e rimane in uno stato di esecuzione inattivo.

Questo comportamento di “fallimento silenzioso” spiega la discrepanza tra i risultati dell’analisi statica, che indicano chiaramente attività malevole, e i punteggi relativamente bassi ottenuti nelle sandbox automatizzate, dove il campione viene classificato come probabilmente benigno. Secondo gli analisti, questa capacità operativa riflette un livello di maturità compatibile con attori sponsorizzati da uno Stato e conferma i limiti degli strumenti di rilevamento automatici nel contrasto a minacce avanzate.

L'articolo Malware macOS nordcoreano sfrutta finti colloqui di lavoro per rubare credenziali proviene da Red Hot Cyber.

Siamo tutti grandi e perciò ci facciamo regali di Natale sono se ci troviamo intorno alla stessa tavola il giorno di Natale.

Ok un set lego: non sono mai troppi e non fanno male.
Ok la 𝙏𝙧𝙞𝙡𝙤𝙜𝙞𝙖 𝙙𝙚𝙡𝙡𝙖 𝙛𝙧𝙤𝙣𝙩𝙞𝙚𝙧𝙖 di Cormac McCarthy: 2 su 3 non li avevo letti.

Ma come 🚀 può venire in mente a qualcuno di regalarmi una candela di sale dell'Himalaya?

In quale possibile universo può esistere una versione di me che potrebbe apprezzare una 𝗰𝗮𝗻𝗱𝗲𝗹𝗮-𝗱𝗶-𝘀𝗮𝗹𝗲-𝗱𝗲𝗹𝗹'𝗛𝗶𝗺𝗮𝗹𝗮𝘆𝗮?
Mi chiedo.

MQTT Pager Build is Bringing Beepers Back

Pagers were once a great way to get a message to someone out in public; they just had to be cool enough to have one. These days, they’re mostly the preserve of doctors and a few other niche operators. [Kyle Tryon] is bringing the beeper back, though, with a custom ESP32-based build.

The ESP32 is a great microcontroller for this kind of project, because it’s got WiFi and Bluetooth connectivity built right in. This let [Kyle] write some straightforward code so that it could receive alerts via MQTT. In particular, it’s set up to go off whenever there’s an app or service notification fired off by the Sentry platform. For [Kyle]’s line of work, it’s effectively an on-call beeper that calls them in when a system needs immediate attention. When it goes off, it plays the ringtone of your choice—with [Kyle] making it capable of playing tunes in Nokia’s old-school RTTTL music format.

The code was simple enough, and the assembly wasn’t much harder. By starting with an Adafruit ESP32 Reverse TFT Feather, the screen and buttons were all ready to go right out of the box. [Kyle] merely had to print up a rad translucent case on a resin printer to make it look like a sweet fashionable beeper from the 90s.

It’s a fun little project that should prove useful, while also being nicely reminiscent of a technology that has largely fallen by the wayside.

youtube.com/embed/lnWRui3_0X0?…

hackaday.com/2025/12/25/mqtt-p…