Salta al contenuto principale




Cloud sì o cloud no: quando il cielo digitale si oscura


L’interruzione dei servizi cloud di Microsoft, avvenuta poche ore prima della pubblicazione dei risultati trimestrali, è solo l’ultimo episodio di una lunga serie di blackout che stanno mettendo in luce una vulnerabilità strutturale del nostro ecosistema digitale. Quando piattaforme come Azure o AWS si bloccano, l’effetto a catena si propaga ben oltre l’ambito tecnologico: intere aziende, servizi pubblici, piattaforme di comunicazione e persino compagnie aeree si ritrovano paralizzate.

Il cloud, nato come simbolo di efficienza, flessibilità e scalabilità, è diventato oggi una dipendenza critica. La sua promessa di disponibilità “always on” si scontra con una realtà fatta di punti di fallimento centralizzati. Bastano poche ore di inattività per mostrare quanto il mondo digitale sia fragile quando affidato a pochi provider globali.

Gli utenti sui social media hanno segnalato di non essere in grado di accedere ai siti web e ai servizi Microsoft in esecuzione sui prodotti Microsoft; anche diversi siti web Microsoft (tra cui il sito web di Xbox e la pagina dedicata alle relazioni con gli investitori) erano inattivi.

Secondo Downdetector, una piattaforma di monitoraggio degli errori che si basa sulle segnalazioni degli utenti, il problema ha iniziato a manifestarsi intorno alle 11:40 (fuso orario orientale).

Un portavoce di Microsoft ha dichiarato in un’e-mail: “Stiamo lavorando per risolvere un problema che riguarda Azure Front Door e che ha causato una riduzione della disponibilità di alcuni servizi. Gli utenti devono continuare a monitorare gli “Avvisi sullo stato dei servizi” per aggiornamenti su questo problema nella pagina Stato di Azure”.

Questa interruzione del servizio si è verificata poco più di una settimana dopo che il principale concorrente di Microsoft, Amazon Web Services, aveva subito un’interruzione di massa che aveva paralizzato numerosi siti web. Il 20 ottobre, AWS ha segnalato un “aumento significativo dei tassi di errore” quando gli utenti hanno tentato di avviare nuove istanze del suo popolare servizio cloud EC2.

Secondo i dati della società di ricerche di mercato Canalys, nel primo trimestre del 2025, AWS era leader nel mercato delle infrastrutture cloud con una quota di mercato del 32%; Microsoft Azure si è classificata al secondo posto con il 23% e Google Cloud al terzo posto con il 10%. Di recente, spinti dalla crescente domanda di carichi di lavoro di intelligenza artificiale, Azure e Google Cloud hanno superato AWS in termini di tasso di crescita.

Tutti e tre i giganti dei servizi cloud pubblicheranno i loro resoconti trimestrali sugli utili questa settimana: Microsoft e Alphabet, la società madre di Google, saranno i primi a divulgare i loro risultati dopo la chiusura del mercato mercoledì; Amazon pubblicherà il suo resoconto sugli utili giovedì.

Mercoledì pomeriggio Alaska Airlines ha dichiarato che i suoi “sistemi critici stanno subendo interruzioni” (incluso il suo sito web) a causa di un’interruzione del servizio Azure: “molti servizi di Alaska Airlines e Hawaiian Airlines sono ospitati sulla piattaforma Azure”. Alaska Airlines ha completato l’acquisizione di Hawaiian Airlines per 1,9 miliardi di dollari lo scorso anno.

L'articolo Cloud sì o cloud no: quando il cielo digitale si oscura proviene da Red Hot Cyber.



Taiwan: fino a 7 anni di carcere per chi danneggia i cavi sottomarini


Taipei, 30 ottobre 2025 – La Commissione Economica dello Yuan Legislativo di Taiwan ha approvato la prima lettura di una serie di emendamenti alle cosiddette “Sette Leggi sui Cavi Sottomarini, introdotte per contrastare i frequenti episodi di danneggiamento delle infrastrutture sottomarine che circondano l’isola.

Le modifiche – che interessano la Legge sull’Elettricità, la Legge sulle Attività del Gas Naturale e la Legge sull’Approvvigionamento Idrico – prevedono pene più severe per chi distrugge intenzionalmente condotte idriche, cavi elettrici o gasdotti subacquei, con sanzioni che possono arrivare fino a sette anni di reclusione. Inoltre, le autorità avranno il potere di confiscare le imbarcazioni impiegate per commettere tali reati.

Un pacchetto legislativo più severo


Il 18 settembre, lo Yuan Esecutivo aveva già approvato le modifiche preliminari alle sette normative: la Legge sulla Gestione delle Telecomunicazioni, la Legge sull’Elettricità, la Legge sulle Attività del Gas Naturale, la Legge sull’Approvvigionamento Idrico, la Legge sulla Meteorologia, la Legge sui Porti Commerciali e la Legge sulla Navigazione.

Con queste modifiche, il danneggiamento intenzionale di condotte sottomarine viene equiparato, dal punto di vista penale, alla distruzione dei cavi di telecomunicazione. I reati più gravi saranno puniti con pene detentive più alte, mentre per i casi di minore entità restano previste sanzioni pecuniarie e detentive proporzionate. Le nuove disposizioni includono inoltre l’obbligo di attivare i sistemi di identificazione automatica (AIS) sulle navi e la possibilità di confisca dei mezzi utilizzati per le violazioni.

Dettagli delle modifiche


Il 29 ottobre, durante una sessione di domande e risposte, la Commissione Economica ha avviato l’esame articolo per articolo delle proposte di emendamento. Tra queste figurano l’Articolo 71-1 della Legge sull’Elettricità, l’Articolo 55-1 della Legge sulle Imprese del Gas Naturale e l’Articolo 97-1 della Legge sull’Approvvigionamento Idrico.

Le bozze stabiliscono che chiunque provochi danni o interferenze al normale funzionamento delle infrastrutture di gas o acqua, o dei cavi sottomarini utilizzati per la distribuzione di energia e risorse, potrà essere condannato da uno a sette anni di carcere e multato fino a 10 milioni di dollari taiwanesi (circa 287.000 euro).

Per i reati colposi, invece, restano in vigore le norme già previste dalla Legge sulla Gestione delle Telecomunicazioni, che prevedono fino a sei mesi di reclusione o ammende fino a 2 milioni di dollari taiwanesi.

Confisca obbligatoria e prevenzione


La bozza include anche una clausola specifica che impone la confisca di tutti gli strumenti, macchinari o imbarcazioni utilizzati per commettere il reato, indipendentemente dal proprietario. L’obiettivo è quello di impedire che tali mezzi vengano riutilizzati per attività illegali.

Durante la stessa riunione, è stata inoltre approvata una risoluzione supplementare che incarica il Ministero dell’Interno di pubblicare mappe e informazioni aggiornate sui cavi e le condotte sottomarine prima della ratifica finale delle leggi. Il provvedimento prevede anche campagne di sensibilizzazione pubblica e una maggiore cooperazione tra le agenzie competenti per facilitare l’applicazione della legge e l’azione giudiziaria.

L'articolo Taiwan: fino a 7 anni di carcere per chi danneggia i cavi sottomarini proviene da Red Hot Cyber.



Il 95% delle aziende si crede pronta al ransomware. Ma solo il 15% lo è davvero!


La diffusa fiducia delle aziende nella propria resilienza informatica si trova ad affrontare una nuova ondata di minacce, questa volta provenienti dall’intelligenza artificiale. Secondo l’OpenText Cybersecurity 2025 Report, il 95% delle organizzazioni in tutto il mondo ritiene di potersi riprendere da un attacco ransomware.

Tuttavia, la realtà si è rivelata molto più complessa: solo il 15% delle vittime ha effettivamente recuperato tutti i propri dati e un numero crescente di incidenti è attribuito all’uso dell’intelligenza artificiale per scopi offensivi.

Uno studio condotto su quasi 1.800 professionisti della sicurezza e dirigenti aziendali provenienti da Stati Uniti, Canada, Europa e Australia mostra che i livelli di fiducia stanno aumentando di pari passo con l’entità dei rischi.

Le aziende stanno implementando attivamente strumenti generativi per migliorare l’efficienza operativa, ma così facendo espongono anche nuove vulnerabilità. Quasi il 90% degli intervistati consente ai dipendenti di utilizzare servizi di intelligenza artificiale, ma meno della metà (48%) ne ha formalizzato l’utilizzo nelle policy. Le piccole e medie imprese sono particolarmente vulnerabili, con solo il 43% che ha implementato tali misure.

Il problema è aggravato non solo da errori interni, ma anche da dipendenze esterne. Un’azienda su quattro ha segnalato una violazione tramite i fornitori di software e quasi la metà (45%) delle aziende che hanno subito la crittografia dei dati ha infine pagato il riscatto. Il 30% ha trasferito oltre 250.000 dollari agli aggressori, ma solo il 2% ha ripristinato completamente i propri sistemi. Ciononostante, tre quarti delle organizzazioni hanno iniziato a sottoporre a audit sistematici i propri fornitori e a implementare procedure di gestione delle patch.

Oltre la metà degli intervistati ha riconosciuto un aumento degli attacchi di phishing e basati sull’intelligenza artificiale, e il 44% ha riscontrato tentativi di impersonare individui tramite deepfake . Le principali preoccupazioni riguardano le fughe di dati (29%), gli attacchi automatizzati (27%) e i video falsi (16%). Nel frattempo, il 71% dei senior manager ha incluso la minaccia del ransomware tra i tre principali rischi aziendali e due terzi hanno osservato che partner e clienti hanno iniziato a informarsi regolarmente sulla sicurezza aziendale.

I piani per il 2026 riflettono questo cambiamento di priorità: le aziende prevedono di investire principalmente nella sicurezza delle infrastrutture cloud (58%), nei backup (52%) e nella formazione dei dipendenti (52%). Quasi l’80% svolge già regolarmente corsi di formazione sulla sicurezza informatica, sebbene il 4% non abbia alcuna iniziativa del genere.

OpenText Cybersecurity sottolinea che la lotta al ransomware richiede ora non solo misure interne, ma anche una stretta collaborazione tra organizzazioni, fornitori e partner tecnologici. Questo è l’unico modo per correggere le vulnerabilità prima che vengano sfruttate dall’intelligenza artificiale, che sta rapidamente diventando un nuovo strumento a disposizione dei criminali informatici.

L'articolo Il 95% delle aziende si crede pronta al ransomware. Ma solo il 15% lo è davvero! proviene da Red Hot Cyber.



Making RAM for a TMS9900 Homebrew Computer


Schematic diagram of part of RAM

Over on YouTube [Usagi Electric] shows us how to make RAM for the TMS9900.

He starts by remarking that the TI-99/4A computer is an excellent place to start if you’re interested in getting into retro-computing. Particularly there are a lot of great resources online, including arcadeshopper.com and the AtariAge forums.

The CPU in the TI-99 is the TMS9900. As [Usagi Electric] explains in the video this CPU only has a few registers and most actual “registers” are actually locations in RAM. Because of this you can’t do much with a TMS9900 without RAM attached. So he sets about making some RAM for his homebrew TMS9900 board. He uses Mitsubishi M58725P 16 kilobit (2 kilobyte) static RAM integrated circuits; each has 11 address lines and 8 data lines, so by putting two side-by-side we get support for 16-bit words. Using six M58725Ps, in three pairs, we get 6 kilowords (12 kilobytes).

He builds out his RAM boards by adding 74LS00 Quad 2-input NAND gates and 74LS32 Quad 2-input OR gates. Anticipating the question as to why he uses NAND gates and OR gates he explains that he uses these because he has lots of them! Hard to fault that logic. (See what we did there?)

After a quick introduction to the various animals in his household [Usagi Electric] spends the rest of the video assembling and testing his RAM. For testing the RAM with full feature coverage a simple assembly program is written and then compiled with a custom tool chain built around a bunch of software available on the internet. Success is claimed when the expected trace is seen on the oscilloscope.

Of course we’ve seen plenty of TMS9900 builds before, such as with this TMS9900 Retro Build.

youtube.com/embed/YMdh74Grcqo?…


hackaday.com/2025/10/29/making…



Il SEO dell’inganno! La rete fantasma scoperta da RHC che penalizza la SERP


Analisi RHC sulla rete “BHS Links” e sulle infrastrutture globali di Black Hat SEO automatizzato

Un’analisi interna di Red Hot Cyber sul proprio dominio ha portato alla luce una rete globale di Black Hat SEO denominata “BHS Links”, capace di manipolare gli algoritmi di Google attraverso backlink automatizzati e contenuti sintetici.

Molti di questi siti, ospitati su reti di proxy distribuite in Asia, generavano backlink automatizzati e contenuti sintetici con l’obiettivo di manipolare gli algoritmi di ranking dei motori di ricerca.

Queste infrastrutture combinavano IP rotanti, proxy residenziali e bot di pubblicazione per simulare segnali di traffico e autorità, una strategia pensata per rendere l’attacco indistinguibile da attività organica e per aggirare i controlli automatici dei motori di ricerca.

Dalle infrastrutture asiatiche a “BHS Links”


Nel corso dell’indagine però, tra i vari cluster osservati, uno in particolare ha attirato l’attenzione per dimensioni, coerenza e persistenza operativa: la rete non asiatica denominata “BHS Links”, attiva almeno da maggio 2025.

A differenza dei gruppi asiatici frammentati, BHS Links si presenta come un ecosistema strutturato di “Black Hat SEO as a Service”, che sfrutta automazione, tecniche antiforensi e domini compromessi per vendere ranking temporanei a clienti anonimi di vari settori, spesso ad alto rischio reputazionale (scommesse, pharma, trading, adult).

Architettura e domini coinvolti


L’infrastruttura di BHS Links comprende decine di domini coordinati, tra cui:

  • bhs-links-anchor.online
  • bhs-links-ass.online
  • bhs-links-boost.online
  • bhs-links-blast.online
  • bhs-links-blastup.online
  • bhs-links-crawlbot.online
  • bhs-links-clicker.online
  • bhs-links-edge.online
  • bhs-links-elite.online
  • bhs-links-expert.online
  • bhs-links-finder.online
  • bhs-links-fix.online
  • bhs-links-flux.online
  • bhs-links-family.online
  • bhs-links-funnel.online
  • bhs-links-genie.online
  • bhs-links-hub.online
  • bhs-links-hubs.online
  • bhs-links-hive.online
  • bhs-links-info.online
  • bhs-links-insight.online
  • bhs-links-keyword.online
  • bhs-links-launch.online
  • bhs-links-move.online
  • bhs-links-net.online
  • bhs-links-power.online
  • bhs-links-pushup.online
  • bhs-links-rankboost.online
  • bhs-links-rise.online
  • bhs-links-signal.online
  • bhs-links-snap.online
  • bhs-links-spark.online
  • bhs-links-stack.online
  • bhs-links-stacker.online
  • bhs-links-stats.online
  • bhs-links-storm.online
  • bhs-links-strategy.online
  • bhs-links-target.online
  • bhs-links-traffic.online
  • bhs-links-vault.online
  • bhs-links-zone.online

Ogni dominio funge da nodo di ridistribuzione: aggrega backlink, genera nuove pagine, replica codice HTML da siti legittimi e rimanda al canale Telegram ufficiale t.me/bhs_links.

Molti domini sono protetti da Cloudflare e ospitati su server offshore, rendendo difficile la tracciabilità. I log forensi indicano anche filtraggio selettivo di Googlebot e pattern di cloaking deliberato.

Cloaking attivo rilevato su bhs-links-blaze.online


Un test condotto da RHC tramite curl con differenti User-Agent ha evidenziato un comportamento di cloaking selettivo, pratica vietata dalle Google Search Essentials.

C:\Users\OSINT>curl -I -A "Googlebot/2.1 (+google.com/bot.html)" bhs-links-blaze.online
HTTP/1.1 403 Forbidden
Server: cloudflare

C:\Users\OSINT>curl -I -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64)" bhs-links-blaze.online
HTTP/1.1 200 OK
Server: cloudflare


Il sito blocca deliberatamente i crawler di Google, rendendo invisibili i propri contenuti promozionali per evitare penalizzazioni. La regola Cloudflare è simile a:

Regola: Block Googlebot
Condizione: (http.user_agent contains “Googlebot”)
Azione: Block


Dal punto di vista forense, si tratta di una tecnica antiforense deliberata, utile a eludere i controlli automatici di Google, nascondere la rete di clienti e backlink generati artificialmente e disturbare l’analisi OSINT basata su crawling.

Target italiani e sfruttamento del “trust locale”


Durante l’analisi del codice sorgente di più domini BHS, RHC ha rilevato centinaia di link verso siti italiani legittimi, tra cui:

Ansa, repubblica.it, gazzetta.it, fanpage.it, legaseriea.it, adm.gov.it, gdf.gov.it, liceoissel.edu.it, meteofinanza.com, aranzulla.it, superscudetto.sky.it.

Tutti i domini citati sono vittime passive di citazione algoritmica e non coinvolti in attività illecite.

Questi siti web non sono compromessi: vengono citati in modo passivo per sfruttarne la reputazione. È una strategia basata sul cosiddetto trust semantico, dove la semplice co-occorrenza tra un sito affidabile e un dominio malevolo induce l’algoritmo a interpretare quest’ultimo come credibile. In altre parole, BHS Links non buca i siti, ma li usa come riflettori reputazionali. Una tattica che consente ai clienti di ottenere boost di ranking temporanei, soprattutto nei settori gambling, forex e adult.

Come nascondono i link


Nel codice sorgente delle pagine analizzate compare un elemento ricorrente: una lista racchiusa in un blocco <ul style="display:none">. Questa sintassi HTML/CSS significa letteralmente “crea una lista non ordinata, ma non mostrarla all’utente”, il browser riceve il markup ma non lo rende visibile perché la regola CSS display:none impedisce la visualizzazione dell’elemento e di tutto il suo contenuto.

A prima vista può sembrare innocuo, ma in realtà rappresenta una delle tattiche più subdole del cloaking semantico: i link vengono resi invisibili ai visitatori umani, ma restano presenti nel sorgente e dunque leggibili dai crawler dei motori di ricerca.

In questo modo il network BHS Links inietta decine di riferimenti nascosti verso domini esterni, forum, casinò online e siti di affiliazione, tutti corredati dal marchio “TG @BHS_LINKS – BEST SEO LINKS – https://t.me/bhs_links”. Il server può servire due versioni della stessa pagina, una pubblica e “pulita” per gli utenti e una destinata ai bot, oppure lasciare lo stesso HTML che, pur essendo nascosto via CSS, viene comunque indicizzato come shadow content: un contenuto fantasma che vive nel codice ma non sulla pagina visibile.

Googlebot e altri crawler analizzano il sorgente e i link anche quando sono nascosti tramite CSS; di conseguenza i riferimenti invisibili vengono interpretati come segnali di co-occorrenza e autorevolezza, attribuendo al dominio malevolo una falsa credibilità. In termini pratici, BHS Links crea così un ponte reputazionale artificiale tra i propri domini e portali reali (testate giornalistiche, siti regolamentati, blog autorevoli). Per l’utente tutto appare normale; per l’algoritmo si tratta invece di una rete ricca di collegamenti tematici e autorevoli. È proprio questa discrepanza, tra ciò che vede l’uomo e ciò che interpreta l’algoritmo, a rendere l’avvelenamento semantico così efficace e difficile da individuare.

Le prove dell’inganno semantico: oltre l’iniezione


In tutti i casi analizzati, dopo l’iniezione di codice già descritta, le evidenze tecniche convergono su altri due indizi ricorrenti che completano la triade dell’inganno semantico:

  • hash differenti tra la versione “normale” e quella servita a Googlebot,
  • rotazione semantica dei blocchi dinamici del CMS

Questi elementi, nel loro insieme, costituiscono la firma tecnica ricorrente dell’operazione BHS Links.

Gli Hash divergenti


Gli hash SHA-256 calcolati per ogni file confermano con precisione la manipolazione semantica.
Nel caso d’esempio, i valori rilevati mostrano due versioni distinte della stessa pagina:

  • 2C65F50C023E58A3E8E978B998E7D63F283180495AC14CE74D08D96F4BD81327normal.html, versione servita all’utente reale
  • 6D9127977AACF68985B9EF374A2B4F591A903F8EFCEE41512E0CF2F1EDBBADDEgooglebot.html, versione destinata al crawler di Google

La discrepanza tra i due hash è la prova più diretta di cloaking attivo: il server restituisce due codici HTML diversi a seconda di chi effettua la richiesta.
Il file diff.txt, con hash FF6B59BB7F0C76D63DDA9DFF64F36065CB2944770C0E0AEBBAF75AD7D23A00C6, documenta le righe effettivamente differenti tra le due versioni, costituendo la traccia forense della manipolazione.

Ecco invece come appare uno dei siti citati, rimasto intatto e non alterato da cloacking


La rotazione semantica: la riscrittura invisibile


Dopo la verifica degli hash, l’analisi del codice rivela un’ulteriore strategia di manipolazione: la rotazione semantica dei contenuti.

In questo schema, il CMS Bitrix24 genera blocchi dinamici con ID diversi a seconda dello user-agent. I file normal.html e googlebot.html mostrano lo stesso contenuto ma con ordine invertito, una rotazione semantica che modifica la priorità logica dei link interni. Agli occhi di Googlebot il sito appare semanticamente riscritto: alcune sezioni, spesso quelle contenenti riferimenti nascosti al marchio BHS Links, acquisiscono un peso maggiore nel grafo semantico, influenzando la valutazione di autorevolezza. È una manipolazione invisibile ma precisa, che agisce sulla gerarchia cognitiva dell’algoritmo.

Per verificare l’anomalia, RHC ha confrontato le due versioni di alcuni siti acquisite in locale: normal.html (utente reale) e googlebot.html (crawler Google).
Nel codice servito a Googlebot compaiono ID di sezione diversi generati dal CMS, come helpdesk_article_sections_lGqiW e helpdesk_article_sections_0A6gh, mentre nella versione normale gli stessi blocchi assumono ID differenti, ad esempio C7TgM e pAZJs.

Questa variazione non cambia l’aspetto visivo della pagina, ma modifica la struttura logica letta dal motore di ricerca: Googlebot interpreta i contenuti con una gerarchia diversa, assegnando maggiore rilevanza a certi link interni. È il meccanismo della rotazione semantica: una riscrittura invisibile che orienta la comprensione algoritmica della pagina.

Nel codice della versione per bot, è inoltre presente una riga che non esiste nel file normale:
form.setProperty("url_page","https://helpdesk.bitrix24.it/open/19137184/,TG @BHS_LINKS - BEST SEO LINKS - https://t.me/bhs_links")

Il furto semantico: quando il Black Hat SEO diventa un’arma reputazionale


Le stesse tecniche di manipolazione semantica impiegate dal network BHS Links, se rivolte contro domini legittimi, si trasformano in Negative SEO: un’arma reputazionale capace di contaminare i risultati di ricerca, duplicare contenuti e indurre l’algoritmo di Google a svalutare la fonte originale.

Il caso Red Hot Cyber


Durante l’analisi, RHC ha documentato la duplicazione dell’headline istituzionale

“La cybersecurity è condivisione. Riconosci il rischio, combattilo, condividi le tue esperienze ed incentiva gli altri a fare meglio di te.”

Questa frase, appartenente al portale ufficiale Red Hot Cyber, è comparsa su portali spam e domini compromessi di varia provenienza, accostata a titoli pornografici o clickbait.

Le evidenze raccolte mostrano risultati su Google come:

  • peluqueriasabai.esDonna cerca uomo Avezzano contacted the booker and set up
  • restaurantele42.frEmiok OnlyFans porn I have seen a few delightful FBSM
  • lucillebourgeon.frLa Camila Cruz sex total GFE and I walked away as super
  • benedettosullivan.frBaad girl Sandra her images caught my eye and I had time
  • serrurier-durand.frSexs web the girl is a striking bisexual African American

In tutti i casi, la descrizione sotto il titolo riportava il testo di Red Hot Cyber, creando un effetto paradossale:
contenuti pornografici o spam presentati con il tono di una testata di cybersecurity affidabile.

Questo meccanismo è il cuore del furto semantico: l’algoritmo di Google unisce automaticamente titolo e descrizione in base a indizi semantici, generando risultati ibridi e apparentemente credibili.
Così, brand reali e frasi autorevoli diventano involontarie esche reputazionali per spingere in alto network malevoli.

Nel caso Red Hot Cyber, la frase originale è stata estratta dal dominio principale, indicizzata in cache e riutilizzata per costruire falsi snippet di autorevolezza, che rafforzano l’immagine di affidabilità dei siti compromessi.

È una forma di Negative SEO di terza generazione: non distrugge direttamente il sito bersaglio, ma ne riutilizza l’identità per ingannare gli algoritmi di ranking e, con essi, la percezione stessa della reputazione digitale.

Il secondo livello dell’inganno: il circuito TDS


Dietro al furto semantico si nasconde una struttura più profonda e funzionale: il Traffic Direction System (TDS) della rete BHS Links.
L’analisi dei dump HTML e delle stringhe Base64 decodificate ha permesso di risalire a questa infrastruttura, progettata per smistare e monetizzare il traffico manipolato attraverso il SEO.

I reindirizzamenti individuati puntano verso un gruppo stabile di domini che costituisce il cuore del circuito dating-affiliate della rete, attivo da mesi e già osservato in contesti internazionali.

Tra i principali, seekfinddate.com agisce come nodo centrale di smistamento, presente nella quasi totalità dei dump analizzati.
Da lì, il traffico viene indirizzato verso romancetastic.com, singlegirlsfinder.com, finddatinglocally.com, sweetlocalmatches.com e luvlymatches.com, che operano come landing page di reti di affiliazione riconducibili a circuiti come Traffic Company, AdOperator e ClickDealer.

A collegare questi livelli si trovano domini-ponte come go-to-fl.com, bt-of-cl.com e bt-fr-cl.com, che mascherano i redirect e spesso si appoggiano a Cloudflare per nascondere l’origine del traffico.
Completano la catena front-end alternativi come mydatinguniverse.com, chilloutdate.com, privatewant.com e flirtherher.com, che reindirizzano dinamicamente in base all’indirizzo IP, alla lingua o al dispositivo dell’utente.

In pratica, le pagine compromesse o sintetiche della rete BHS includono redirect cifrati che portano prima ai nodi TDS e poi alle landing di affiliazione o alle truffe a tema dating.
L’analisi dei parametri (tdsid, click_id, utm_source, __c) conferma il tipico schema di tracciamento d’affiliazione: una pagina BHS, un dominio TDS (ad esempio seekfinddate.com), e infine una landing commerciale o fraudolenta.

Molti di questi domini risultano ospitati su Cloudflare (AS13335) o su server offshore nei Paesi Bassi, a Cipro o a Panama, con TTL molto bassi e registrazioni recenti, una firma operativa tipica delle reti di cloaking SEO.

L’analisi incrociata degli indirizzi IP e dei sistemi autonomi (ASN) conferma la sovrapposizione infrastrutturale tra i due livelli della rete.
I domini del circuito “dating-affiliate”, come seekfinddate.com, romancetastic.com, singlegirlsfinder.com e mydatinguniverse.com, risultano ospitati su Amazon AWS (AS16509), mentre i domini del network BHS Links, come bhs-links-zone.online, bhs-links-anchor.online e bhs-links-suite.online, sono serviti da Cloudflare (AS13335).

Questa doppia architettura lascia pensare a una divisione di ruoli precisa: Amazon ospita i nodi di smistamento e monetizzazione, mentre Cloudflare garantisce l’offuscamento e la persistenza dei domini SEO.
La ripetizione degli stessi blocchi IP e la coincidenza tra ASN dimostrano che si tratta di un’infrastruttura coordinata, in cui la reputazione viene manipolata su un fronte e monetizzata sull’altro.

Caso correlato: backlinks.directory e indici automatizzati


Durante l’indagine è emerso anche il dominio backlinks.directory (mirror di backlinksources.com), un portale che pubblica elenchi automatizzati di oltre un milione di domini, organizzati in blocchi numerati da 1000 record ciascuno (es. domain-list-403, domain-list-404).

Le verifiche tecniche condotte con User-Agent differenti (Googlebot e browser standard) hanno restituito in entrambi i casi una risposta HTTP 200 OK, escludendo la presenza di cloaking o blocchi selettivi. Il dominio risulta pienamente accessibile e consultabile anche da bot di scansione, suggerendo una funzione di archivio automatizzato più che di infrastruttura antiforense.

La struttura progressiva degli URL e la presenza di parametri come “Domain Power” indicano l’impiego di crawler o scraper automatici per replicare e classificare backlink su larga scala. Questi indici possono essere utilizzati per alimentare link farm di seconda generazione, impiegate come proof-of-delivery per servizi di Black Hat SEO o per simulare una crescita organica di backlink acquistati.

Negative SEO: confine e relazione con il Black Hat SEO (BHS)


Il Negative SEO (NSO) rappresenta la declinazione offensiva delle stesse tecniche impiegate nel Black Hat SEO (BHS), ma con finalità distruttiva. Invece di migliorare la visibilità di un sito, l’obiettivo è danneggiare un dominio concorrente, compromettendone la reputazione digitale fino a causarne la perdita di ranking o addirittura una penalizzazione algoritmica o manuale da parte dei motori di ricerca.

Le pratiche più comuni di BHS, link farm, reti PBN (Private Blog Network), cloaking, reindirizzamenti ingannevoli e compromissioni di CMS, diventano, se applicate contro terzi, vere e proprie armi di Negative SEO, capaci di infettare la reputazione di un dominio legittimo con migliaia di backlink tossici o contenuti manipolati.

A rendere il fenomeno più subdolo è il fatto che molti servizi BHS nati con finalità promozionali, come la vendita di backlink o guest post su siti compromessi, possono generare effetti collaterali di Negative SEO anche in assenza di un intento malevolo diretto. La diffusione automatizzata di link su larga scala, senza filtri di qualità o controllo sull’origine dei domini, finisce per creare una rete di contaminazioni digitali che colpisce indistintamente vittime e aggressori, rendendo il confine tra promozione e sabotaggio sempre più labile.

Rilevamento e analisi dei segnali di attacco SEO


La diagnostica forense SEO parte spesso da segnali visibili direttamente nella Google Search Console (GSC), che rappresenta il primo strumento di allerta in caso di inquinamento o attacco.
Tra i sintomi più frequenti si osservano:

  • un crollo improvviso del traffico organico, non giustificato da aggiornamenti di algoritmo o stagionalità;
  • una perdita anomala di ranking su keyword strategiche, spesso sostituite da risultati di siti di scarsa qualità;
  • la comparsa di Azioni manuali per link non naturali o contenuti sospetti.

Questi indizi, presi insieme, suggeriscono che il dominio possa essere stato esposto a campagne di link tossici o schemi di manipolazione tipici del Negative SEO. Da qui si procede all’analisi tecnica dei backlink, alla verifica dei referral sospetti e all’eventuale bonifica tramite strumenti di disavow.

Audit dei backlink


L’audit dei backlink è una delle fasi più importanti nella diagnosi di compromissioni SEO.
Attraverso l’analisi sistematica dei collegamenti in ingresso, è possibile distinguere i link organici e progressivi, generati nel tempo da contenuti autentici o citazioni spontanee, da quelli artificiali o tossici, prodotti in modo massivo da reti automatizzate come BHS Links.

Un’analisi di questo tipo non si limita a contare i link, ma valuta la qualità semantica, la coerenza tematica e la distribuzione geografica delle sorgenti. Quando numerosi backlink provengono da domini appena registrati, con struttura HTML simile o ancore ripetitive, il segnale diventa chiaro: si è di fronte a un ecosistema costruito per alterare il ranking.

Nel caso specifico di BHS Links, il tracciamento dei collegamenti ha evidenziato pattern ricorrenti: picchi improvvisi di link in uscita, ancore manipolate con parole chiave commerciali, e riferimenti incrociati verso directory nascoste. Tutti indizi tipici di un’operazione di SEO artificiale, mirata non solo a spingere i propri domini, ma anche a inquinare semanticamente quelli legittimi collegati.

Risposta e mitigazione


Quando un dominio mostra segnali di compromissione o riceve backlink tossici, la prima azione consiste nel mappare e isolare i domini sospetti. I link dannosi possono essere raccolti in un semplice file di testo (.txt, codifica UTF-8) nel seguente formato:

domain:bhs-links-hive.online
domain:bhs-links-anchor.online
domain:bhs-links-blaze.online
domain:backlinks.directory

Il file va poi caricato nella Google Search Console, sezione Disavow Tool, per comunicare al motore di ricerca di ignorare i link provenienti da quei domini. È importante monitorare nel tempo gli effetti dell’operazione: la rimozione dell’impatto negativo può richiedere settimane, a seconda della frequenza di scansione del sito da parte di Googlebot.

In caso di penalizzazione manuale, è possibile presentare una richiesta di riconsiderazione, fornendo una documentazione chiara delle azioni intraprese:

  • descrivere il tipo di manipolazione o attacco subito (p.es. link innaturali, contenuti generati automaticamente);
  • spiegare in dettaglio le misure correttive adottate (rimozione e/o disavow dei link, bonifica del server, rimozione di contenuti spam);
  • allegare documentazione pertinente (per esempio screenshot, elenco dei cambiamenti, file di disavow, registri delle richieste di rimozione link) per illustrare l’intervento;
  • verificare che il sito sia accessibile a Googlebot (nessun blocco in robots.txt, pagine chiave indicizzabili e sitemap aggiornate)


Difesa preventiva e monitoraggio


Una strategia di difesa realmente efficace passa dalla prevenzione continua e dal controllo costante dell’ecosistema digitale. Le pratiche più raccomandate includono:

  • audit periodici dei backlink (almeno mensili), per intercettare rapidamente picchi anomali o nuovi domini di provenienza sospetta;
  • verifica regolare dei file .htaccess e robots.txt, per individuare tempestivamente eventuali iniezioni di codice, redirect non autorizzati o blocchi impropri al crawler;
  • monitoraggio dei DNS e delle classi IP condivise (Class C), utile per individuare co-hosting rischiosi o connessioni con reti compromesse;
  • formazione SEO interna e sensibilizzazione del personale, per evitare la collaborazione con fornitori o agenzie che utilizzano tecniche “black hat” mascherate da strategie di link building aggressive


I danni causati da una operazione di SEO Negativa


Un’operazione di SEO negativa può iniziare con una serie di azioni malevole mirate a compromettere la sua reputazione agli occhi dei motori di ricerca. Gli attaccanti possono, come in questo caso, generare migliaia di backlink di bassa qualità da siti spam o penalizzati, facendo sembrare che il portale stia tentando di manipolare artificialmente il proprio posizionamento. Questo tipo di attacco può indurre Google a ridurre la fiducia nel dominio, con un conseguente calo drastico del ranking organico e una perdita significativa di traffico.

Un caso tipico è la duplicazione dei contenuti, e questo può avvenire quando elementi distintivi del portale, come headline originali o slogan, vengono copiati e riutilizzati da siti terzi in modo malevolo. Ad esempio, l’headline “La cybersecurity è condivisione. Riconosci il rischio, combattilo, condividi le tue esperienze ed incentiva gli altri a fare meglio di te.”, originariamente concepita per promuovere la filosofia di Red Hot Cyber, è stata rilevata in diversi post pubblicati su portali sconosciuti o di scarsa qualità, come visto in precedenza, utilizzati per pratiche di black SEO.

I danni derivanti da un’operazione di black SEO possono essere profondi e di lunga durata, andando ben oltre la semplice perdita di posizionamento sui motori di ricerca. Oltre al calo di traffico organico e alla riduzione della visibilità, il portale può subire un deterioramento della fiducia sia da parte degli utenti sia degli algoritmi di ranking. Quando un sito viene associato, anche indirettamente, a pratiche di spam, link farming o duplicazione di contenuti, i filtri di Google e Bing possono applicare penalizzazioni algoritmiche o manuali che richiedono mesi per essere rimosse.

Conclusioni


La rete BHS Links rappresenta un caso emblematico di Black Hat SEO industrializzato, in cui tecniche di manipolazione un tempo marginali si trasformano in servizi globali automatizzati.

L’inclusione di siti italiani reali all’interno del codice HTML dimostra come la frontiera del [strong]Black Hat SEO[/strong]e del Negative Seo non passi più dall’hacking tradizionale, ma da una forma più sottile di sovrapposizione semantica e reputazionale, capace di confondere gli algoritmi di ranking e i criteri di autorevolezza.

Per Google e per i webmaster il rischio è duplice:

  • a perdita temporanea di ranking, con impatti economici immediati;
  • l’erosione della fiducia negli algoritmi di valutazione, su cui si fonda l’intero ecosistema della ricerca

Quando la fiducia è l’unico algoritmo che non si può corrompere, difendere la trasparenza non è più una scelta tecnica, ma un atto di resistenza digitale.

L'articolo Il SEO dell’inganno! La rete fantasma scoperta da RHC che penalizza la SERP proviene da Red Hot Cyber.



La gestione degli incidenti informatici nell’epoca del NIS2


Il Decreto NIS 2 (D. Lgs. 138/2024), in vigore dal 16 ottobre 2024, recepisce i principi della Direttiva Europea NIS2, ponendo le basi per un modello operativo di collaborazione tra i soggetti interessati e l’autorità competente più articolato rispetto al passato, per quanto attiene la gestione degli incidenti informatici. Tale gestione si fa, in buona sostanza, più rigorosa, strutturata e vincolante, con obblighi di notifica estesi e tempistiche precise per imprese e pubbliche amministrazioni.

Infatti, per l’adempimento degli obblighi di cui agli articoli 23, 24, e 25 del decreto, i soggetti NIS sono tenuti ad adottare le misure di sicurezza e a notificare al CSIRT Italia – ovvero l’unità istituita presso l’ACN per monitorare e rispondere agli incidenti di cyber security in Italia – gli incidenti più significativi, come stabilito dalla determinazione ACN 164179 del 14 aprile 2025 e relativi allegati.

In questo contesto, grande importanza è assunta dall’articolo 25, che prevede non solo obblighi più rigorosi in materia di notifica di incidenti all’autorità competente, ma anche un processo disegnalazione strutturato a più fasi.

Tutti i soggetti pubblici e privati che rientrano nel campo di applicazione del Decreto si sono dovuti obbligatoriamente registrare sulla piattaforma digitale dedicata dell’ACN, indicando un Punto di Contatto e trasmettendo le informazioni essenziali, inclusi indirizzi IP, domini e organi direttivi. Obbligo che si rinnoverà annualmente per quanto attiene all’aggiornamento di tali informazioni.

A partire da gennaio 2026 i soggetti importanti dovranno notificare al CSIRT Italia gli incidenti significativi elencati nell’allegato 3 della determinazione ACN mentre i soggetti essenziali quelli indicati nell’allegato 4.

A questo proposito, al Punto di Contatto si è recentemente aggiunto l’obbligo del Referente CSIRT (determinazione ACN 250916), che dovrà essere designato entro il 31 dicembre, con il compito specifico di interloquire con lo CSIRT Italia per la notifica degli incidenti, avendo le competenze necessarie per ricoprire questo ruolo.

Ma notificare gli incidenti significa anche strutturarsi con tecnologie e processi che permettano di rilevare tempestivamente gli incidenti e di gestirne correttamente tutte le fasi tipiche dell’incident handling, conformemente anche a quanto previsto dalla normativa stessa.

I soggetti, pertanto, entro la fine dell’anno in corso devono già adempiere ad una serie di obblighi specificatamente riferiti alla gestione degli incidenti, ancor prima di completare tutti gli altri adempimenti previsti dal Decreto, la cui scadenza è stata fissata ad ottobre 2026.

Obblighi e criteri più stringenti


Tutte le organizzazioni che rientrano fra i soggetti identificati dal Decreto sono tenuti a:

  1. Adottare misure tecniche, organizzative e procedurali proporzionate al rischio.
  2. Implementare piani di gestione degli incidenti (inclusi rilevamento, risposta e recupero).
  3. Mantenere registri aggiornati degli incidenti.

In forza dell’articolo 25 del Decreto, i soggetti essenziali e i soggetti importanti sono tenuti a notificare al CSIRT Italia ogni incidente che abbia un impatto significativo sulla fornitura dei propri servizi. Le notifiche devono contenere tutte le informazioni necessarie affinché il CSIRT Italia possa valutare l’eventuale impatto sia a livello nazionale che transfrontaliero dell’incidente.

Tale comunicazione non comporta, per il soggetto che la effettua, un incremento delle responsabilità rispetto a quelle già connesse all’evento stesso, sebbene esso stesso sia una sorta di autodenuncia verso l’Autorità competente e quindi andrà svolta con tutte le cautele del caso, coinvolgendo sia le funzioni tecniche (interne o esterne) per le analisi approfondite, che gli organi direttivi e legali per valutare accuratamente gli impatti.

Inoltre, per essere considerato “significativo”, un incidente deve causare o potenzialmente determinare gravi perturbazioni operative o perdite finanziarie, oppure avere ripercussioni rilevanti, con danni materiali o immateriali considerevoli su persone fisiche o giuridiche. In questo modo, la definizione si estende oltre la mera dimensione tecnica, includendo anche le conseguenze economiche e sociali dell’evento.

Da notare che la definizione di “incidente significativo” fornita da ACN nei citati allegati si discosta da quella del Regolamento Esecutivo NIS2 2690/2024 emesso dalla CE. Tale regolamento, sebbene si applichi ai soli soggetti che erogano servizi digitali, resta pur sempre di valido aiuto per la comprensione di tale definizione (cfr. Artt 3-14) e, in generale, rappresenta un validissimo framework di sicurezza che compendia tutte le misure previste dalla NIS2 (cfr. allegato al Regolamento).

Tempistiche e fasi di notifica


Il decreto impone a tutti i soggetti essenziali e importanti una sequenza di comunicazioni progressive, finalizzate a fornire al CSIRT un quadro costantemente aggiornato della situazione:

  • Entro 24 ore dalla scoperta dell’incidente, deve essere inviata una pre-notifica, che indichi – se possibile – la natura dell’evento, l’eventuale origine malevola e il potenziale impatto transfrontaliero.
  • Entro 72 ore, deve essere trasmessa una notifica completa e dettagliata, contenente una prima valutazione della gravità e dell’impatto, nonché eventuali indicatori di compromissione.
  • Su richiesta del CSIRT Italia, possono seguire relazioni intermedie per aggiornare lo stato dell’incidente.
  • Entro un mese dalla notifica va inviata una relazione finale, che ne descriva gravità ed impatto, il tipo di minaccia o la sua origine (root cause), le misure di mitigazione adottate e in corso e l’eventuale impatto transfrontaliero. Se l’incidente è ancora in corso al momento della trasmissione della relazione finale, è prevista una relazione mensile sui progressi e una relazione finale entro un mese dalla conclusione della gestione dell’incidente.

La notifica va svolta caratterizzando l’incidente mediante la Tassonomia Cyber di ACN che ha lo scopo di agevolare lo scambio di informazioni mediante un lessico comune per la condivisione di informazioni riguardo eventi cyber tra le entità impattate, nonché per la notifica al CSIRT Italia. Purtroppo, tale tassonomia è adottata solo in Italia per cui, per incidenti transfrontalieri, perde un po’ della sua efficacia.

Nel caso in cui l’incidente significativo comporta anche una violazione di dati personali (data breach) sarà necessaria un’ulteriore notifica, questa volta verso l’autorità Garante per la Protezione dei Dati Personali, ma con tempistiche e modalità differenti (entro le 72 ore).

Se poi, il soggetto è un istituto bancario che rientra nel perimetro del Regolamento DORA, è prevista una ulteriore notifica verso l’autorità nazionale di vigilanza finanziaria (Banda d’Italia).

Insomma, il processo di notifica si può complicare notevolmente, per cui il soggetto dovrà adeguatamente strutturarsi per poter far fronte a tutti questi adempimenti, avvalendosi di profili professionali (interni e/o esterni) in grado di potersi districare agevolmente in questo ginepraio normativo, rispettando tempistiche molto stringenti che escludono qualsiasi sorta di improvvisazione.

Infatti, la mancata notifica o l’inadempienza agli obblighi può comportare limitazioni operative, soprattutto per i soggetti essenziali, e sanzioni economiche rilevanti, significativamente più severe rispetto a quelle previste dalla NIS1, con massimi edittali sino a 10M€ (o 2% del fatturato annuo) per i soggetti essenziali e a 7M€ (o 1,4% del fatturato annuo) per i soggetti importanti.

Altra novità riguarda i minimi edittali, proporzionali al massimo (1/20 o 1/30), il che significa che ci potrà essere molto meno discrezionalità sulla sanzione minima irrogata. Per i soggetti pubblici le sanzioni previste sono più ridotte (da 25K€ a 125K€), ma possono essere anche personali, degli amministratori e dirigenti preposti, per esempio per gravi negligenze nella governance della cybersecurity o per non aver dato seguito alle diffide di ACN.

Il ruolo chiave dello CSIRT


La NIS2 rafforza il ruolo di supervisione dell’Authority sugli incidenti informatici e, in questo contesto, il CSIRT Italia svolge un ruolo centrale, ricevendo le notifiche e fornendo supporto tecnico ai soggetti pertinenti.

Il CSIRT Italia è l’organo di ACN che si occupa di monitoraggio preventivo e risposta agli incidenti informatici e fa parte della comunità dei CERT mondiali (FIRST). Ha iniziato ad operare dal 2020 assumendo i compiti in precedenza in capo al CERT Nazionale e al CERT-PA.

Nell’ambito della NIS2 il CSIRT dovrà assumere diversi compiti, sia di tipo reattivo (monitoraggio e analisi, supporto operativo nella risposta, analisi forense, awareness, ecc.) che proattivo (emissioni bollettini, alert, early warning, scansioni periodiche, ecc.).

Entro 24 ore dalla pre-notifica, deve fornire un riscontro iniziale, con eventuali suggerimenti di mitigazione, e può offrire ulteriore assistenza su richiesta. In caso di eventi con carattere criminale, il CSIRT indirizza il soggetto verso le Autorità competenti, garantendo il raccordo tra risposta tecnica e investigativa.

I soggetti, solo a seguito del parere favorevole del CSIRT, devono informare i propri utenti senza ingiustificato ritardo, quando l’incidente può avere un impatto significativo sulla fornitura dei servizi, comunicando le misure di mitigazione intraprese in presenza di minacce significative.

Infine, il CSIRT può condividere pubblicamente gli incidenti significativi per prevenire ulteriori attacchi o tutelare l’interesse pubblico, eventualmente estendendo tale comunicazione agli altri Stati membri.

È evidente, quindi, che i compiti del CSIRT sono davvero gravosi, per cui dovrà ulteriormente rafforzarsi considerando il numero elevato di soggetti già ad oggi in perimetro (si è superati i 25.000, a fronte di meno di 500 della NIS1), per poter essere ancora più efficiente a partire dal prossimo gennaio, da quando cioè tutti i soggetti NIS2 saranno obbligati a notificare gli incidenti significativi.

Perché questo processo è cruciale: impatti per aziende e PA


La nuova procedura di segnalazione degli incidenti, innanzi descritta, introduce un modello strutturato e formale che cambia significativamente il modo in cui imprese e pubbliche amministrazioni dovranno gestire gli incidenti di sicurezza informatica.

Se per le realtà più mature ed organizzate dal punto di vista della sicurezza significa per lo più adattare e migliorare i processi esistenti, per tantissime altre (leggi PMI) comporterà avviare ex-novo dei progetti di adeguamento tecnologico e organizzativo che richiederanno diversi mesi, se non anni, prima che possano essere completati.

Ridursi all’ultimo momento non giova a nessuno e porta a risultati insoddisfacenti, come l’esperienza dell’adeguamento al GDPR ha dimostrato: troppo spesso si è rivelato un mero adempimento burocratico, anziché apportare un sostanziale miglioramento nella protezione dei dati personali.

La NIS2, invece, anche dal punto di vista della gestione incidenti, deve essere vista come un’occasione fondamentale per tutti i soggetti coinvolti:

  • Per le imprese: definire processi di incident management più strutturati, con precisi ruoli e responsabilità, capacità di prevenzione e analisi post-incidente, trasformando la sicurezza in un asset strategico, investendo in processi, competenze e tecnologie per ridurre rischi, prevenire blocchi operativi e rafforzare la fiducia di clienti e partner.
  • Per le PA: maggiore trasparenza, coordinamento e capacità di risposta centralizzata avvalendosi del CSIRT, al fine di potenziare prevenzione, rilevamento e risposta agli incidenti, anche avvalendosi di aziende specializzate che garantiscano servizi efficaci e di qualità.

Questo approccio più disciplinato è fondamentale perché consente di rilevare e contenere rapidamente gli incidenti, prevenire reazioni a catena, migliorare la governance interna e la compliance, e garantire cooperazione e visibilità a livello nazionale ed europeo, rafforzando concretamente la resilienza di sistemi e servizi critici.

Conclusioni


L’entrata in vigore del Decreto NIS2 segna un punto di svolta nella gestione degli incidenti informatici, imponendo un approccio più rigoroso, strutturato e coordinato. Non si tratta di un semplice adeguamento normativo, ma di un cambiamento culturale che richiede alle organizzazioni di ripensare i propri processi di sicurezza, passando da una logica reattiva a una strategia proattiva e integrata.

Le imprese e le pubbliche amministrazioni devono considerare questi obblighi come un’opportunità per rafforzare la propria resilienza, investendo in tecnologie, competenze e governance. La tempestività nella rilevazione e nella notifica degli incidenti, unita alla collaborazione con il CSIRT Italia, diventa un elemento chiave per ridurre i rischi, prevenire impatti sistemici e garantire la continuità operativa.

In un contesto in cui le minacce cyber sono sempre più sofisticate e pervasive, la conformità alla NIS2 non è solo una questione di compliance, ma un fattore strategico per tutelare la fiducia di clienti, partner e cittadini. Agire oggi significa non solo evitare sanzioni, ma costruire un ecosistema digitale più sicuro e resiliente, a beneficio dell’intero sistema Paese.

L'articolo La gestione degli incidenti informatici nell’epoca del NIS2 proviene da Red Hot Cyber.



Gli USA costruiscono il più grande supercomputer AI della storia


Il Dipartimento dell’Energia degli Stati Uniti (DOE) ha avviato una collaborazione strategica con Nvidia e Oracle per costruire sette supercomputer di nuova generazione basati sull’intelligenza artificiale, destinati a rivoluzionare la ricerca scientifica e lo sviluppo di agenti intelligenti.

Due di questi sistemi saranno installati presso l’Argonne National Laboratory in Illinois, che ospiterà così la più vasta infrastruttura di supercalcolo AI mai realizzata dal Dipartimento dell’Energia.

Durante la GPU Technology Conference di NVIDIA, il CEO Jensen Huang ha annunciato il progetto Solstice, descritto come il più grande supercomputer AI mai costruito per il DOE. Il sistema sarà equipaggiato con 100.000 GPU Blackwell e realizzato in collaborazione con Oracle e il laboratorio Argonne.

Solstice sarà affiancato da Equinox, un secondo supercomputer in fase di sviluppo con 10.000 GPU Blackwell, anch’esso ospitato presso Argonne. L’interconnessione tra i due sistemi permetterà di raggiungere una potenza combinata di 2.200 exaFLOP, segnando un nuovo traguardo nelle capacità di calcolo dedicate all’intelligenza artificiale.

Huang ha sottolineato che questa infrastruttura “diventerà il motore di scoperta americano”, mettendo a disposizione dei ricercatori strumenti avanzati per accelerare studi in ambiti che vanno dalla medicina alla scienza dei materiali.

Oltre a fornire maggiore capacità di calcolo per gli esperimenti scientifici, Solstice ed Equinox saranno parte integrante del programma “Developing Agent Scientists” del laboratorio Argonne. L’iniziativa mira a introdurre sistemi di intelligenza artificiale basati su agenti autonomi nella ricerca, con l’obiettivo di incrementare la produttività e favorire nuove scoperte nel prossimo decennio.

Secondo le prime previsioni, Equinox dovrebbe entrare in funzione il prossimo anno, mentre non è ancora stata comunicata una data ufficiale per il completamento di Solstice.

Parallelamente, NVIDIA ha annunciato una nuova collaborazione con Palantir Technologies, che integrerà le tecnologie di calcolo accelerato NVIDIA – comprese le librerie CUDA-X e i modelli AI Nemotron – nella propria piattaforma di intelligenza artificiale. L’obiettivo è aumentare la velocità di elaborazione dei dati e introdurre agenti AI personalizzabili all’interno dei sistemi Palantir.

La combinazione delle due tecnologie è già stata sperimentata da Lowe’s, la catena statunitense di articoli per la casa, che ha utilizzato un gemello digitale della propria rete di fornitura per ottimizzare i flussi logistici attraverso modelli di intelligenza artificiale.

Il laboratorio Argonne, inoltre, prevede di ampliare la propria infrastruttura con altri tre sistemi basati su GPU NVIDIA: Tara, Minerva e Janus. Questi supercomputer saranno messi a disposizione della comunità scientifica per favorire l’accesso condiviso alle risorse di calcolo AI.

Anche il Los Alamos National Laboratory sarà parte dell’iniziativa e riceverà due nuovi sistemi basati sulla piattaforma NVIDIA Vera Rubin. Il primo, denominato Vision, sarà operativo nel 2027 e dedicato a progetti di ricerca non classificati – dalla sicurezza nazionale alla scienza dei materiali, fino alla ricerca biomedica. Il secondo, chiamato Mission, sarà destinato a carichi di lavoro classificati, sostituendo il supercomputer Crossroads, entrato in funzione nel 2023.

I sistemi Mission e Vision rappresentano un investimento cruciale nelle nostre capacità scientifiche e nella sicurezza nazionale“, ha affermato Tom Mason, direttore del Los Alamos Laboratory. “Sono progettati per il supercalcolo dell’era dell’intelligenza artificiale.”

L'articolo Gli USA costruiscono il più grande supercomputer AI della storia proviene da Red Hot Cyber.



Hello World in C Without Linking in Libraries


If there’s one constant with software developers, it is that sometimes they get bored. At these times, they tend to think dangerous thoughts, usually starting with ‘What if…’. Next you know, they have gone down a dark and winding rabbit hole and found themselves staring at something so amazing that the only natural conclusion that comes to mind is that while educational, it serves no immediate purpose.

The idea of applying this to snipping out the <stdio.h> header in C and the printf() function that it provides definitely is a good example here. Starting from the typical Hello World example in C, [Old Man Yells at Code] over at YouTube first takes us from the standard dynamically linked binary at a bloated 16 kB, to the statically linked version at an eyepopping 767 kB.

To remove any such dynamic linkages, and to keep file sizes somewhat sane, he then proceeds to first use the write()function from the <unistd.h> header, which does indeed cut out the <stdio.h> include, before doing the reasonable thing and removing all includes by rewriting the code in x86 assembly.

While this gets the final binary size down to 9 kB and needs no libraries to link with, it still performs a syscall, after setting appropriate register values, to hand control back to the kernel for doing the actual printing. If you try doing something similar with syscall(), you have to link in libc, so it might very well be that this is the real way to do Hello World without includes or linking in libraries. Plus the asm keyword part of C, although one could argue that at this point you could just as well write everything in x86 ASM.

Of course, one cannot argue that this experience isn’t incredibly educational, and decidedly answers the original ‘What if…’ question.

youtube.com/embed/gVaXLlGqQ-c?…


hackaday.com/2025/10/29/hello-…



10 Cent Microcontroller Makes Tracker Music


We are absurdly spoiled these days by our microcontrollers. Take the CH32V00X family– they’ve been immortalized by meme as “the ten cent micro” but with a clock speed of 48MHz and 32-bit registers to work with, they’re astoundingly capable machines even by the standards of home computers of yore. That’s what motivated [Tim] to see if he could use one to play MOD files, with only minimal extra parts– and quite specifically no DAC.

Well, that’s part of what motivated him. The other part was seeing Hackaday feature someone use a CH32V003 making chiptune-like beeps. [Tim] apparently saw that post as a gauntlet thrown down, and he picked it up with an even smaller chip: the CH32V002, which he proceeded to turn into a MOD player. For those of you who slept through 80s and early 90s (or for those precocious infants reading this who hadn’t then yet been born), MOD files are an electronic music format, pioneered on the Amiga home computers. Like MIDI, the file specifies when to play specific voices rather than encoding the sound directly. Unlike MIDI, MOD files are self-contained, with the samples/voices used being stored inside the file. The original version targeted four-channel sound, and that’s what [Tim] is using here.

As you can see from the demo video, it sounds great. He pulled it off by using the chip’s built-in PWM timer. Since the timer’s duty cycle is determined by a variable that can be changed by DMA, the CPU doesn’t end up with very much to do here. In the worst case, with everything in flash memory instead of SRAM, the CPU is only taxed at 24%, so there’s plenty of power to say, add graphics for a proper demo. Using the existing MODPlay Library, [Tim]’s player fits into 4kB of memory, leaving a perfectly-usable 12kB for the MOD file. As far as external components needed, it’s just an RC filter to get rid of PWM noise.

[Tim] has put his code up on GitHub for anyone interested, and has perhaps inadvertently cast down another gauntlet for anyone who wants to use these little RISC V microprocessors for musical tasks. If you can do better, please do, let us know.

youtube.com/embed/IQmQ0Qlt3V8?…


hackaday.com/2025/10/29/10-cen…




no n ne parla nessuno ma a me pare una cosa molto grave...