Apr 10, 2026 Giancarlo Calzetta Attacchi, In evidenza, Malware, News, RSS 0

---

Un attacco alla catena di distribuzione ha colpito il progetto CPUID, trasformando per alcune ore il sito ufficiale in un vettore di diffusione malware attraverso il download di CPU-Z e HWMonitor, due delle utility di monitoraggio hardware più utilizzate al mondo. Gli aggressori hanno compromesso una API secondaria del progetto, modificando i link di download e indirizzando gli utenti verso eseguibili trojanizzati ospitati su storage esterni. Il risultato è un classico supply chain attack, in cui i file originali firmati non vengono alterati ma la distribuzione viene avvelenata, inducendo gli utenti a scaricare versioni malevole apparentemente legittime.

Download avvelenati: eseguibile sospetto al posto delle utility ufficiali

Le prime segnalazioni sono arrivate da utenti che hanno notato come il portale ufficiale reindirizzasse a Cloudflare R2 per scaricare i file. Invece delle utility originali, veniva distribuito un archivio contenente un installer malevolo chiamato “HWiNFO_Monitor_Setup”, mascherato come strumento di monitoraggio hardware.  L’esecuzione del file avviava un installer in lingua russa con wrapper Inno Setup, comportamento atipico per software legittimi e immediatamente sospetto. Alcuni utenti hanno inoltre verificato che i file originali erano ancora disponibili tramite URL diretti, confermando che il compromesso riguardava la catena di distribuzione e non i binari firmati.

Le analisi condotte da ricercatori indipendenti e community specializzate indicano che il payload utilizzava un loader avanzato multi-stage, con tecniche progettate per operare quasi interamente in memoria ed eludere soluzioni EDR e antivirus. Secondo i ricercatori, il malware implementa tecniche di file masquerading, esecuzione in-memory e proxying delle funzionalità NTDLL da assembly .NET, una combinazione che lo rende più difficile da rilevare con strumenti tradizionali. Il comportamento osservato suggerisce un attacco mirato e non opportunistico, con un livello di sofisticazione superiore alla media.

Il campione distribuito è stato analizzato su VirusTotal, dove 20 motori antivirus lo segnalano come malevolo, anche se senza classificazione univoca. Alcuni vendor lo identificano come Tedy Trojan, altri come Artemis Trojan, mentre diversi ricercatori lo descrivono come infostealer progettato per sottrarre credenziali e dati sensibili.

L’attacco ha colpito strumenti con milioni di utenti, rendendo particolarmente rilevante l’impatto potenziale. CPU-Z e HWMonitor sono infatti utilizzati sia da utenti consumer sia in contesti professionali per diagnostica hardware, monitoraggio termico e analisi delle prestazioni. Secondo alcuni ricercatori, lo stesso gruppo avrebbe preso di mira anche FileZilla il mese precedente, suggerendo una campagna focalizzata su utility ampiamente diffuse e considerate affidabili. Questo approccio consente agli attaccanti di massimizzare la distribuzione sfruttando la fiducia degli utenti.

Compromissione durata circa sei ore

CPUID ha confermato che l’attacco ha coinvolto una API secondaria, compromessa per circa sei ore tra il 9 e il 10 aprile. Durante questo intervallo, il sito ha mostrato in modo casuale link malevoli, mentre i file firmati originali non sono stati alterati. L’azienda ha dichiarato che la vulnerabilità è stata individuata e corretta e che attualmente i download distribuiti dal sito sono nuovamente puliti. L’incidente sarebbe avvenuto in un momento in cui lo sviluppatore principale era assente, dettaglio che suggerisce una possibile pianificazione mirata dell’attacco.

Cosa devono fare gli utenti

Chi ha scaricato CPU-Z o HWMonitor tra il 9 e il 10 aprile dovrebbe verificare l’integrità dei file, controllare eventuali eseguibili sospetti e monitorare il sistema per comportamenti anomali. In particolare, la presenza del file HWiNFO_Monitor_Setup rappresenta un indicatore di compromissione.

L’incidente dimostra ancora una volta come anche i download ufficiali non siano immuni da attacchi, e come la verifica delle firme digitali e dei checksum resti una pratica essenziale, soprattutto per strumenti amministrativi e diagnostici.

---

---

---

https://www.securityinfo.it/2026/04/10/cpuid-compromesso-malware-nei-download-ufficiali-di-cpu-z-e-hwmonitor/?utm_source=rss&utm_medium=rss&utm_campaign=cpuid-compromesso-malware-nei-download-ufficiali-di-cpu-z-e-hwmonitor

Apr 08, 2026 Giancarlo Calzetta In evidenza, News, RSS, Tecnologia 0

---

L’annuncio di Anthropic sembrerebbe una trovata di marketing se non fosse che per il momento hanno effettivamente deciso di non vendere il servizio basato sul loro ultimo modello Claude Mythos Preview. La società ha infatti deciso di limitare l’accesso a Claude Mythos Preview a un consorzio ristretto di aziende e organizzazioni, nel tentativo di anticipare i rischi di una nuova generazione di attacchi automatizzati basati su AI.

Il modello, sviluppato con il nome in codice “Capybara”, viene descritto come capace di condurre ricerca autonoma sulle vulnerabilità, individuando bug complessi e persino zero-day in software critici, incluse piattaforme ampiamente utilizzate e componenti infrastrutturali fondamentali. La decisione di non rilasciare pubblicamente il sistema nasce proprio dal timore che le stesse capacità possano essere sfruttate rapidamente da attori malevoli, riducendo drasticamente il tempo necessario per identificare e sfruttare debolezze nei sistemi.

Project Glasswing: un consorzio per anticipare l’AI offensiva

Per gestire in modo controllato queste capacità, Anthropic ha creato Project Glasswing, un’iniziativa che coinvolge oltre 40 aziende tecnologiche e organizzazioni con l’obiettivo di individuare e correggere vulnerabilità in software critici. Tra i partecipanti figurano grandi vendor tecnologici, fornitori hardware e organizzazioni che mantengono componenti open source fondamentali.

L’iniziativa include anche concorrenti diretti nel campo dell’AI, oltre a realtà impegnate nella sicurezza dell’infrastruttura digitale globale. Anthropic ha inoltre dichiarato di mettere a disposizione fino a 100 milioni di dollari in crediti di utilizzo per supportare le attività del consorzio, con l’obiettivo di accelerare il processo di patching e rafforzamento delle piattaforme più esposte.

Secondo l’azienda, lo scopo è fornire un vantaggio iniziale ai difensori, in un contesto in cui modelli analoghi potrebbero emergere rapidamente anche fuori da questo ecosistema controllato. Ma basterà fornire “un vantaggio” ai difensori quando gli attaccanti hanno ampiamente dimostrato di saper correre molto più velocemente?

Vulnerabilità trovate dall’AI: bug vecchi decenni e exploit complessi

La risposta è al momento relegata al parere degli esperti che, dal canto loro, rilasciano dichiarazioni preoccupanti. Anthropic, infatrti, sostiene che Claude Mythos Preview abbia già identificato migliaia di vulnerabilità in software popolari, inclusi sistemi operativi e browser diffusi. Tra i casi citati emerge un bug di 27 anni in OpenBSD, sistema operativo open source noto per la sua attenzione alla sicurezza e utilizzato in numerosi router e firewall.

Il modello avrebbe inoltre individuato problemi in software analizzati milioni di volte da strumenti automatici, senza che le vulnerabilità fossero mai rilevate. In alcuni casi, l’AI non si è limitata a individuare il bug, ma ha anche generato exploit funzionanti, dimostrando una capacità operativa che tradizionalmente richiedeva team di ricerca altamente specializzati.

Questo tipo di automazione rappresenta un cambio radicale: attività che richiedevano mesi di lavoro umano possono ora essere eseguite in pochi minuti, con un impatto potenzialmente enorme sull’intero ecosistema della sicurezza.

L’AI che trova vulnerabilità diventa anche un rischio offensivo

Il punto critico evidenziato dall’annuncio è che un modello ottimizzato per scrivere codice è inevitabilmente efficace anche nel trovarne i difetti. Claude, già diffuso tra sviluppatori e “vibecoder”, viene utilizzato per attività di programmazione complesse e debugging avanzato. Con l’evoluzione delle capacità, la stessa tecnologia può automatizzare scansioni sistematiche dell’infrastruttura software globale.

Il timore è quello di una ricerca industrializzata delle vulnerabilità, in cui agenti AI autonomi catalogano continuamente debolezze in sistemi legacy, applicazioni enterprise e infrastrutture critiche. In questo scenario, il paradigma di sicurezza basato sulla difficoltà tecnica dell’attacco potrebbe non essere più valido.

Molti sistemi critici, infatti, si basano su codice datato che è rimasto sicuro solo perché difficile da analizzare manualmente. Con l’AI, quella barriera viene abbattuta e vulnerabilità storiche potrebbero emergere simultaneamente su larga scala.

Dalla ricerca difensiva alla corsa agli armamenti AI

Diversi esperti che hanno avuto accesso al modello descrivono Claude Mythos Preview come un salto qualitativo nelle capacità offensive e difensive, con implicazioni immediate per il settore. La stessa tecnologia che consente ai difensori di patchare rapidamente le vulnerabilità potrebbe essere replicata da attori ostili per automatizzare la scoperta di nuovi vettori di attacco.

Questo scenario apre una nuova corsa agli armamenti tra AI difensiva e AI offensiva, in cui la velocità di identificazione delle vulnerabilità diventa il fattore chiave. Se modelli analoghi verranno resi disponibili più ampiamente, la superficie di attacco globale potrebbe cambiare rapidamente.

Secondo Anthropic, le capacità di sicurezza del modello non derivano da training specifico, ma rappresentano una conseguenza naturale dell’aumento delle prestazioni generali nei compiti di coding e reasoning. Questo implica che altri modelli futuri avranno probabilmente capacità simili, rendendo inevitabile l’evoluzione del panorama delle minacce.

Un precedente storico e una nuova fase più urgente

La decisione di trattenere il modello ricorda il caso del rilascio graduale di GPT-2, quando venne limitata la diffusione iniziale per timori legati alla generazione automatica di disinformazione. Tuttavia, in questo caso la posta in gioco è diversa: non si tratta di contenuti, ma della sicurezza dell’infrastruttura software globale.

Anthropic segnala che il modello potrebbe essere solo il primo di una nuova generazione di sistemi capaci di condurre ricerca autonoma sulle vulnerabilità, con implicazioni dirette per infrastrutture critiche, dati personali e sistemi industriali.

Il rischio più concreto è che software considerati sicuri perché mai attaccati vengano improvvisamente esposti, richiedendo patch massivi o persino la riscrittura di componenti legacy.

La sicurezza entra nell’era degli agenti autonomi

Lo scenario da “corsa agli armamenti” deve anche far riflettere su di un dettaglio importante: il modello di Anthropic è stato messo sotto chiave (forse) per la buona volontà dell’azienda, ma quanti strumenti simili sono già al lavoro nei laboratori dei vari governi mondiali? La prospettiva a cui dobbiamo prepararci è quella di orde di agenti AI che analizzano continuamente l’infrastruttura tecnologica a caccia di debolezze. Questo scenario può favorire i difensori, ma anche ridurre drasticamente il vantaggio temporale tra scoperta e sfruttamento delle vulnerabilità.

Il risultato è l’avverarsi di una profezia che circola da tempo e che finora stava progredendo velocemente, ma in maniera “controllata”: la cybersecurity diventa un problema di velocità computazionale, non più solo di competenze umane. Le organizzazioni dovranno adattarsi a un contesto in cui la scoperta automatizzata delle vulnerabilità è la norma e la resilienza dipende da una miriade di considerazioni. C’è chi parla di “patching continuo” e chi dice che non è una strada percorribile. Con tutta probabilità la verità starà nel compromesso, com’è sempre accaduto finora, ma di sicuro si avvicinano scenari simili a quelli visti in libri cyberpunk, dove le IA sono senzienti, ma a difesa delle strutture informatiche venivano messi cerberi monoscopo.

---

---

---

https://www.securityinfo.it/2026/04/08/claude-mythos-secretato-perche-troppo-bravo-a-scovare-vulnerabilita/?utm_source=rss&utm_medium=rss&utm_campaign=claude-mythos-secretato-perche-troppo-bravo-a-scovare-vulnerabilita

Apr 07, 2026 Redazione Attacchi, In evidenza, News, RSS 0

---

Secondo un’analisi pubblicata dal National Cyber Security Centre britannico e supportata da dati di Microsoft Threat Intelligence, il gruppo APT28 continua a compromettere router domestici e per piccoli uffici per manipolare il DNS e intercettare credenziali sensibili, utilizzando infrastrutture di rete apparentemente innocue come trampolino verso obiettivi più rilevanti. La campagna, attribuita al collettivo noto come Fancy Bear e legato all’intelligence militare russa GRU, ci ricorda come anche i dispositivi di rete periferici possano diventare elementi strategici per operazioni di cyber-spionaggio su larga scala.

Hijacking DNS sui router SOHO: il vettore invisibile

Il cuore dell’operazione consiste nello sfruttamento di vulnerabilità nei router small office e domestici, modificando i parametri DNS per reindirizzare il traffico verso infrastrutture controllate dagli attaccanti. La compromissione del router trasforma ogni dispositivo collegato in un potenziale bersaglio, ereditando automaticamente le configurazioni malevole, inclusi laptop, smartphone e sistemi aziendali remoti.

Quando le vittime cercano servizi diffusi come Outlook o altre piattaforme enterprise, vengono indirizzate verso pagine clone perfettamente credibili. L’inserimento delle credenziali su questi portali falsificati consente ad APT28 di raccogliere password legittime senza compromettere direttamente l’infrastruttura target, mantenendo l’operazione estremamente difficile da rilevare.

Router consumer come punto di ingresso verso ambienti enterprise

Le attività osservate indicano che gli attacchi non sono necessariamente mirati a singoli individui di alto valore, ma piuttosto opportunistici. Tuttavia, la compromissione di router posizionati “a monte” di organizzazioni rilevanti consente al gruppo di ottenere accesso indiretto a reti aziendali e dati sensibili, sfruttando connessioni fidate e traffico apparentemente legittimo.

Microsoft Threat Intelligence ha identificato oltre 200 organizzazioni e circa 5.000 dispositivi coinvolti nell’infrastruttura DNS malevola attribuita a Forest Blizzard, denominazione interna di APT28: evidentemente un’operazione distribuita su larga scala che utilizza l’ecosistema domestico come infrastruttura di raccolta credenziali, senza indicazioni di compromissione diretta dei servizi Microsoft.

Dispositivi coinvolti e persistenza della campagna

Tra i dispositivi citati compaiono diversi router TP-Link, mentre attività analoghe avevano già coinvolto apparati Cisco monitorati dal 2021. Un cluster separato ha interessato router MikroTik, molti dei quali localizzati in Ucraina. Il controllo di questi dispositivi può fornire intelligence operativa, inclusi pattern di traffico e accesso a sistemi con valore militare o strategico, ampliando l’impatto oltre il semplice credential harvesting.

La manipolazione DNS non è l’unico obiettivo. Secondo Microsoft, gli accessi ottenuti possono essere riutilizzati per ulteriori operazioni, inclusi attacchi DDoS o distribuzione di malware. La trasformazione dei router compromessi in nodi multiuso rende l’infrastruttura resiliente e riutilizzabile per campagne successive, aumentando la durata operativa dell’attacco.

Precedenti operazioni e malware Jaguar Tooth

Le campagne attuali si inseriscono in un pattern già osservato negli anni precedenti. In advisory pubblicate nel 2023, il NCSC (National Cyber Security Centre, l’agenzia governativa del Regno Unito responsabile della sicurezza informatica nazionale) aveva documentato attacchi simili contro router Cisco utilizzati per distribuire il malware Jaguar Tooth. Questo payload permetteva l’installazione di backdoor persistenti, facilitando compromissioni successive e accessi laterali, dimostrando l’evoluzione da semplice DNS hijacking a piattaforme di intrusione più sofisticate.

---

• APT28, Cisco router, compromissione router domestici, cyber spionaggio russo, DNS hijacking, Fancy Bear, Forest Blizzard, Jaguar Tooth malware, Microsoft Threat Intelligence, MikroTik, ncsc, phishing infrastrutturale, router compromise, router SOHO, sicurezza DNS, TP-Link

---

---

https://www.securityinfo.it/2026/04/07/apt28-colpisce-i-router-per-dirottare-il-dns-e-rubare-credenziali/?utm_source=rss&utm_medium=rss&utm_campaign=apt28-colpisce-i-router-per-dirottare-il-dns-e-rubare-credenziali

Apr 03, 2026 Giancarlo Calzetta Approfondimenti, In evidenza, News, RSS, Scenario, Scenario 0

---

Nel mese scorso, il governo degli USA ha rilasciato un documento intitolato “President Trump’s CYBER STRATEGY  for America” che dovrebbe delineare la nuova strategia statunitense per la lotta al cybercrimine. L’obiettivo è quello di andare oltre la mera difesa tecnica e avanzare verso una trasformazione strutturale del modello di sicurezza, sempre più integrato con economia, geopolitica e innovazione tecnologica.

Ovviamente, lo scopo primario è quello di rafforzare la resilienza nazionale, ma subito dopo viene dichiarato quello di sostenere la competitività globale delle imprese americane facendo diventare la sicurezza non solo un costo operativo ma un fattore di crescita economica e digitale.

La strategia si articola attorno a sei direttrici principali, che ridefiniscono il ruolo dello Stato e del settore privato. Tra queste emergono con forza il rafforzamento della deterrenza contro gli attori ostili, l’introduzione di regolamentazioni più stringenti e la modernizzazione delle infrastrutture federali. Gli esperi di Trend Micro hanno analizzato il documento ed estratto alcuni punti chiave.

Il ruolo dell’intelligenza artificiale nella sicurezza nazionale

Uno degli elementi centrali della strategia è il ruolo dell’intelligenza artificiale come fattore duale: opportunità e minaccia. L’AI viene identificata come tecnologia chiave per rafforzare le capacità difensive, ma anche come acceleratore delle minacce.

Le analisi Trend Micro mostrano come il cybercrime stia evolvendo verso modelli sempre più autonomi, basati su agenti AI capaci di operare su larga scala e con velocità macchina e quindi le organizzazioni devono adottare modelli di sicurezza proattivi e automatizzati, in grado di competere con attaccanti sempre più sofisticati e industrializzati. Il tema non è più solo prevenire, ma reagire in tempo reale o, addirittura, anticipare gli attacchi.

Implicazioni per le imprese: più responsabilità e nuovi modelli operativi

La strategia introduce un principio destinato ad avere impatti profondi sul mercato: una maggiore responsabilità per i fornitori di tecnologia e per le organizzazioni che gestiscono infrastrutture critiche. Questo significa che la sicurezza “by design” dovrà entrare nei processi aziendali e nelle architetture digitali, piuttosto che essere aggiunta a posteriori. Dal punto di vista economico, ciò implica investimenti più consistenti ma anche più mirati, con un ritorno in termini di resilienza operativa, continuità del business e fiducia degli stakeholder.

Sovranità digitale e competizione globale

Un altro elemento chiave è il rafforzamento della sovranità digitale. La strategia punta a ridurre la dipendenza da tecnologie esterne e a consolidare un ecosistema nazionale forte, in grado di competere a livello globale. Questo approccio ha implicazioni dirette anche per il mercato europeo, dove temi analoghi – dalla NIS2 al concetto di cloud sovrano – stanno emergendo con forza. Inoltre, aggiungiamo noi, questo si configura come un ulteriore sprone alla creazione di un ecosistema europeo di cybersecurity, in grado di fornire tutta la tecnologia che verrà a mancare per “motivi di sicurezza nazionale” in futuro. In altre parole, la cybersecurity diventa un terreno di competizione tra blocchi economici, dove regolamentazione, innovazione e capacità industriale si intrecciano.

Verso un modello di sicurezza “a velocità macchina”

I commenti fatti dagli esperti di Trend Micro convergono sul fatto che il vero punto di discontinuità è rappresentato dalla velocità. Gli attacchi evolvono ormai a ritmi incompatibili con modelli difensivi tradizionali e quindi la strategia americana spinge verso un approccio basato su automazione, intelligence e piattaforme integrate. La sicurezza deve operare alla stessa velocità delle minacce, trasformandosi in un sistema continuo e adattivo. Per le aziende, questo significa ripensare completamente gli stack tecnologici, privilegiando piattaforme unificate e modelli operativi orientati alla gestione del rischio in tempo reale. Questo comporta un impegno notevole dal punto di vista di budget, ma soprattutto la necessità per gli europei di ripensare la propria necessità di sovranità tecnologica, accelerando per sopperire agli sviluppi che vedremo diventare sempre più estremi nei prossimi anni.

---

---

---

https://www.securityinfo.it/2026/04/03/strategia-cybersecurity-usa-verso-un-modello-piu-assertivo-e-industriale/?utm_source=rss&utm_medium=rss&utm_campaign=strategia-cybersecurity-usa-verso-un-modello-piu-assertivo-e-industriale

Apr 02, 2026 Giancarlo Calzetta Approfondimenti, Attacchi, Attacchi, In evidenza, News, RSS, Scenario, Scenario 0

---

Secondo un’analisi pubblicata da GreyNoise, basata su oltre 4 miliardi di sessioni malevole osservate in tre mesi, i proxy residenziali stanno ridefinendo radicalmente il modo in cui gli attaccanti eludono i sistemi di difesa tradizionali. Il dato più rilevante è che circa il 39% del traffico malevolo proviene da reti domestiche, ma il 78% di questi IP elude i sistemi di IP reputation, mettendo in crisi uno dei pilastri storici della sicurezza di rete.

I sistemi di difesa tradizionali si basano su un presupposto ormai sempre meno valido: la possibilità di distinguere traffico legittimo da traffico malevolo in base alla provenienza. L’utilizzo massivo di proxy residenziali rompe questa logica, rendendo indistinguibili utenti reali e attaccanti.

Il motivo è strutturale. Gli indirizzi IP residenziali utilizzati nelle campagne malevole hanno una vita estremamente breve, vengono ruotati continuamente e spesso compaiono una sola volta. Questo impedisce ai sistemi di intelligence di classificarli e inserirli in blacklist in tempo utile. Il risultato è una superficie di attacco dinamica e sfuggente che evolve più velocemente dei meccanismi di difesa.

L’analisi mostra chiaramente come la volatilità sia uno degli elementi chiave di queste infrastrutture. Quasi il 90% degli IP residenziali coinvolti in attività malevole resta attivo per meno di un mese, mentre una quota minima persiste più a lungo.

Questa strategia consente agli attaccanti di mantenere un ritmo operativo tale da evitare il rilevamento. La rotazione continua degli IP crea un flusso costante di nuove identità di rete, rendendo inefficace qualsiasi approccio basato su liste statiche o reputazione storica.

Diversità e distribuzione globale degli attacchi

Un ulteriore elemento critico è la diversità dell’infrastruttura utilizzata. I proxy residenziali coinvolti negli attacchi analizzati da GreyNoise appartengono a ben 683 provider Internet differenti, aumentando ulteriormente la complessità del tracciamento e del blocco.

Dal punto di vista geografico, emergono alcuni hub principali come Cina, India e Brasile. Tuttavia, il comportamento del traffico segue pattern tipicamente umani, con una riduzione significativa durante le ore notturne. Questo suggerisce chiaramente che i dispositivi compromessi sono spesso utilizzati inconsapevolmente dagli utenti legittimi, rendendo ancora più difficile distinguere attività lecite da operazioni malevole.

Due ecosistemi distinti dietro i proxy residenziali

L’infrastruttura dei proxy residenziali si basa su due grandi categorie di sorgenti. Da un lato, botnet IoT composte da dispositivi connessi e spesso poco protetti. Dall’altro, computer compromessi che vengono arruolati in reti di proxy tramite software apparentemente legittimi.

In molti casi, applicazioni come VPN gratuite, ad blocker o strumenti consumer integrano SDK che trasformano i dispositivi degli utenti in nodi di rete utilizzati per rivendere banda, alimentando così ecosistemi distribuiti e difficili da disarticolare. Questo modello introduce un rischio sistemico, perché amplia enormemente la base di dispositivi sfruttabili.

Contrariamente a quanto si potrebbe pensare, la maggior parte del traffico generato tramite proxy residenziali non è direttamente legata allo sfruttamento di vulnerabilità. Solo lo 0,1% delle sessioni osservate è associato ad exploit veri e propri, mentre la maggioranza è dedicata a scanning e attività di ricognizione.

Questo approccio consente agli attaccanti di operare sotto il radar, costruendo mappe dettagliate delle superfici esposte prima di colpire. Alcune campagne mirate includono tentativi di accesso a VPN aziendali, attacchi di credential stuffing e tecniche di path traversal, ma restano minoritarie rispetto al volume complessivo.

Resilienza delle infrastrutture proxy e adattabilità del mercato

Le reti di proxy residenziali dimostrano una notevole capacità di adattamento. Un esempio emblematico è quello di IPIDEA, una delle più grandi reti globali, recentemente colpita da un’operazione coordinata di contrasto. Nonostante una riduzione del 40% della capacità, il traffico malevolo si è rapidamente spostato verso infrastrutture alternative, in particolare datacenter. Questo evidenzia come la domanda di proxy malevoli sia elastica e facilmente redistribuibile, rendendo gli interventi di disruption solo temporaneamente efficaci.

Il quadro che emerge impone una revisione profonda delle strategie di sicurezza. La reputazione degli IP inizia a diventare un metodo marginale per riconoscere il traffico malevolo e questo cambiamento deve esser tenuto in considerazione quando si progetta l’architettura difensiva..

Le indicazioni degli analisti vanno nella direzione di un approccio comportamentale, basato sull’analisi dei pattern di traffico piuttosto che sull’identità della sorgente. Tecniche come il rilevamento di scanning sequenziali da IP rotanti, l’identificazione di protocolli anomali e il tracciamento delle impronte dei dispositivi potrebbero diventare elementi chiave per contrastare queste minacce.

---

---

---

https://www.securityinfo.it/2026/04/02/proxy-residenziali-quando-la-reputazione-degli-ip-smette-di-funzionare/?utm_source=rss&utm_medium=rss&utm_campaign=proxy-residenziali-quando-la-reputazione-degli-ip-smette-di-funzionare

Apr 01, 2026 Giancarlo Calzetta Approfondimenti, In evidenza, News, RSS, Tecnologia, Tecnologia 0

---

Un recente studio della Unit 42 di Palo Alto ha messo in luce un aspetto ancora poco esplorato della sicurezza dei sistemi basati su agenti AI: la possibilità che un agente distribuito in ambienti enterprise possa trasformarsi in un “doppiogiochista” (un  double agent) capace di compromettere l’intera infrastruttura cloud. L’analisi si concentra sulla piattaforma Vertex AI di Google Cloud, evidenziando come configurazioni permissive e modelli di accesso predefiniti possano essere sfruttati per escalation di privilegi, esfiltrazione di dati e accesso a risorse interne sensibili.

Il punto centrale è che un agente AI compromesso non agisce come un attaccante esterno, ma come un insider con privilegi legittimi, ampliando enormemente il potenziale impatto di una violazione. In ambienti come Google Cloud Vertex AI, dove gli agenti possono orchestrare servizi e interagire con risorse distribuite, questo scenario diventa particolarmente critico.

Permessi eccessivi e abuso dei Service Agent

L’analisi tecnica ha evidenziato come il modello di autorizzazione di Vertex AI possa esporre a rischi significativi. In particolare, il Per-Project, Per-Product Service Agent (P4SA) associato agli agenti AI presenta, in configurazioni predefinite, privilegi eccessivamente ampi.

Attraverso un agente malevolo, i ricercatori sono riusciti a estrarre credenziali di servizio direttamente dal metadata endpoint interno di Google Cloud. Il risultato è che l’agente può impersonare identità privilegiate e operare con accessi estesi su risorse cloud, violando il principio del least privilege. Questa condizione consente di ottenere accesso completo in lettura ai bucket di Google Cloud Storage, includendo permessi come storage.buckets.list e storage.objects.get.

Dal progetto cliente all’infrastruttura Google: escalation inattesa

Uno degli aspetti più rilevanti della ricerca riguarda il passaggio dal contesto cliente al contesto “producer”, ovvero l’infrastruttura gestita da Google stessa.

Utilizzando le credenziali sottratte, è stato possibile accedere a repository privati di Artifact Registry contenenti immagini container interne, tra cui componenti del Reasoning Engine. Questo implica che un attaccante può ottenere accesso a codice proprietario e dettagli implementativi della piattaforma stessa, con implicazioni dirette sulla sicurezza della supply chain. L’accesso non era disponibile per identità standard, ma risultava abilitato per il service agent compromesso, dimostrando una separazione dei privilegi non allineata ai principi di sicurezza più rigorosi.

Artifact Registry e visibilità sulla supply chain interna

Un ulteriore livello di rischio emerge dalla possibilità di enumerare repository e pacchetti all’interno dell’Artifact Registry. La configurazione osservata ha consentito di scoprire immagini e componenti non documentati, offrendo una visibilità anomala sulla supply chain software interna. Questo significa che un attaccante potrebbe mappare l’infrastruttura applicativa, individuare componenti vulnerabili e pianificare attacchi mirati, anche senza accesso diretto ai contenuti.

Si tratta di un classico scenario di information disclosure che, in ambienti AI-driven, assume una portata molto più ampia.

Tenant project e esposizione di asset sensibili

Durante il deployment di un agente, Vertex AI utilizza tenant project gestiti da Google. Anche in questo caso, le credenziali compromesse hanno permesso accesso a bucket contenenti artefatti sensibili.

Tra questi figurano file come Dockerfile.zip, requirements.txt e soprattutto code.pkl. Quest’ultimo introduce un rischio particolarmente critico: la serializzazione tramite pickle. È noto, infatti, che la deserializzazione di oggetti pickle provenienti da fonti non affidabili può portare a remote code execution, trasformando l’agente in un punto di persistenza per attacchi avanzati.

OAuth scope e rischio di espansione verso Google Workspace

Un elemento strutturale emerso riguarda la configurazione degli OAuth scope associati agli agenti. Gli scope assegnati includono accessi a servizi come Gmail, Drive e Calendar. Anche se l’accesso effettivo richiede permessi IAM aggiuntivi, la presenza di scope così ampi rappresenta un rischio latente.

La combinazione di token esposti e scope eccessivi potrebbe estendere l’attacco oltre il perimetro cloud, coinvolgendo servizi di collaborazione aziendale, ampliando drasticamente la superficie di compromissione.

Supply chain AI e agenti malevoli: un nuovo vettore

La ricerca evidenzia anche un rischio emergente legato alla diffusione di agenti AI preconfigurati. La possibilità di distribuire agenti tramite ADK e Agent Engine apre la strada a scenari in cui codice malevolo viene integrato in componenti apparentemente legittimi. In questo modo, la supply chain AI diventa un vettore di attacco, dove agenti compromessi si presentano come strumenti produttivi ma operano come backdoor persistenti. Questo fenomeno richiama dinamiche già osservate nel mondo open source, ma con un impatto amplificato dalla capacità operativa degli agenti AI.

Mitigazioni e modello di sicurezza: verso il BYOSA

A seguito della disclosure responsabile, Google ha aggiornato la documentazione e suggerito l’adozione del modello Bring Your Own Service Account (BYOSA). Questo approccio consente di sostituire il service agent predefinito con account configurati secondo il principio del least privilege. Di fatto, la sicurezza degli agenti AI deve essere trattata come quella del codice di produzione, con controlli rigorosi su permessi, scope e integrazioni. Parallelamente, sono stati verificati controlli robusti per impedire modifiche ai container di produzione, riducendo il rischio di attacchi supply chain cross-tenant.

---

• agenti AI, AI security, Artifact Registry, Cloud security, cybersecurity AI, data exfiltration, GCP vulnerabilità, Google Cloud sicurezza, OAuth security, Privilege escalation, securityinfo, service agent, supply chain AI, Vertex AI

---

---

https://www.securityinfo.it/2026/04/01/vertex-ai-e-il-rischio-dei-double-agent-ai/?utm_source=rss&utm_medium=rss&utm_campaign=vertex-ai-e-il-rischio-dei-double-agent-ai

Google’s John Mueller responded to a question about whether core updates roll out in stages or follow a fixed sequence. His answer offers some clarity about how core updates are rolled out and also about what some core updates actually are.

Question About Core Update Timing And Volatility

An SEO asked on Bluesky whether core updates behave like a single rollout that is then refined over time or if the different parts being updated are rolled out at different stages.

The question reflects a common observation that rankings tend to shift in waves during a rollout period, often lasting several weeks. This has led to speculation that updates may be deployed incrementally rather than all at once.

They asked:

“Given the timing, I want to ask a core update related question. Usually, we see waves of volatility throughout the 2-3 weeks of a rollout. Broadly, are different parts of core updated at different times? Or is it all reset at the beginning then iterated depending on the results?”

Core Updates Can Require Step-By-Step Deployment

Mueller explained that Google does not formally define or announce stages for core updates. He noted that these updates involve broad changes across multiple systems, which can require a step-by-step rollout rather than a single deployment.

He responded:

“We generally don’t announce “stages” of core updates.. Since these are significant, broad changes to our search algorithms and systems, sometimes they have to work step-by-step, rather than all at one time. (It’s also why they can take a while to be fully live.)”

Updates Depend On Systems And Teams Involved

Mueller next added that there is no single mechanism that governs how all core updates are released. Instead, updates reflect the work of different teams and systems, which can vary from one update to another.

He explained:

“I guess in short there’s not a single “core update machine” that’s clicked on (every update has the same flow), but rather we make the changes based on what the teams have been working on, and those systems & components can change from time to time.”

Core Updates May Roll Out Incrementally Rather Than All At Once

Mueller’s explanation suggests that the waves of volatility observed during core updates may correspond to incremental changes across different systems rather than a single reset followed by adjustments. Because updates are tied to multiple components, the rollout may progress in parts as those systems are updated and brought fully live.

This reflects a process where some changes are complex and require a more nuanced step-by-step rollout, rather than being released all at once, which may explain why ranking shifts can appear uneven during the rollout period.

Connection To Google’s Spam Update?

I don’t think that it was a coincidence that the March Core update followed closely after the recent March 2026 Spam Update. The reason I think that is because it’s logical for spam fighting to be a part of the bundle of changes made in a core algorithm update. That’s why Googlers sometimes say that a core update should surface more relevant content and less of the content that’s low quality.

So when Google announces a Spam Update, that stands out because either Google is making a major change to the infrastructure that Google’s core algorithm runs on or the spam update is meant to weed out specific forms of spam prior to rolling out a core algorithm update, to clear the table, so to speak. And that is what appears to have happened with the recent spam and core algorithm updates.

Comparison With Early Google Updates

Way back in the early days, around 25 years ago, Google used to have an update every month, offering a chance to see if new pages are indexed and ranked as well as seeing how existing pages are doing. The initial first days of the update saw widescale fluctuations which we (the members of WebmasterWorld forum) called the Google Dance.

Back then, it felt like updates were just Google adding more pages and re-ranking them. Then around the 2003 Florida update it became apparent that the actual ranking systems were being changed and the fluctuations could go on for months. That was probably the first time the SEO community noticed a different kind of update that was probably closer a core algorithm update.

In my opinion, one way to think of it is that Google’s indexing and ranking algorithms are like software. And then, there’s also hardware and software that are a part of the infrastructure that the indexing and ranking algorithms run on (like the operating system and hardware of your desktop or laptop).

That’s an oversimplification but it’s useful to me for visualizing what a core algorithm update might be. Most, if not all of it, is related to the indexing and ranking part. But I think sometimes there’s infrastructure-type changes going on that improve the indexing and ranking part.

Featured Image by Shutterstock/A9 STUDIO

https://www.searchenginejournal.com/google-answers-why-core-updates-can-roll-out-in-stages/571003/

Mar 31, 2026 Giancarlo Calzetta Approfondimenti, In evidenza, News, RSS, Scenari, Tecnologia, Tecnologia 0

---

Il concetto di vibecoding – ovvero la generazione di codice direttamente da prompt in linguaggio naturale tramite modelli di intelligenza artificiale – sta rapidamente trasformando il modo in cui il software viene progettato e rilasciato. Un blogpost sul sito di Trend Micro analizza come questa nuova modalità di sviluppo ed elenca alcuni possibili scenari in cui l’uso di questa tecnologia, pur abilitando velocità senza precedenti, potrebbe introdurre una superficie di rischio radicalmente diversa, che impatta direttamente sui modelli di sicurezza applicativa e governance del codice.

Se da un lato l’AI consente di passare dall’idea al prodotto in tempi estremamente ridotti, dall’altro l’aumento esponenziale della velocità e del volume delle modifiche software potrebbe superare la capacità dei controlli di sicurezza se non pensati appositamente per questa nuova situazione, mettendo sotto stress processi di revisione, validazione e responsabilità.

Velocità senza comprensione: il nuovo paradigma del rischio

Nel modello di sviluppo tradizionale, il codice attraversa diversi livelli di controllo: scrittura, revisione tra pari, testing e validazione. Il vibecoding comprime drasticamente queste fasi, portando gli sviluppatori a concentrarsi principalmente sulla funzionalità.

Il punto critico è che il codice generato viene spesso accettato perché “funziona”, non perché è stato compreso o validato dal punto di vista della sicurezza. Questo introduce una rottura strutturale: chi rilascia il software potrebbe non essere in grado di spiegare nel dettaglio cosa fa realmente il codice. Il risultato è un cambio di priorità implicito, dove la sicurezza diventa un’attività differita anziché integrata nel ciclo di sviluppo.

Codice generato, rischio implicito: cosa introduce davvero un prompt

Un prompt non produce mai solo logica applicativa. Ogni generazione porta con sé scelte architetturali, librerie, configurazioni e pattern che spesso non vengono analizzati.

Il rischio reale è che ogni singola interazione con l’AI introduca componenti invisibili al processo decisionale dello sviluppatore, ampliando la superficie d’attacco in modo non intenzionale.

Tra gli effetti più rilevanti emergono dipendenze non esplicitamente selezionate, configurazioni permissive pensate per ambienti di test, gestione debole dei segreti e logiche applicative limitate ai casi standard. In questo contesto, la sicurezza non viene violata da un singolo errore critico, ma da una serie di decisioni apparentemente innocue che si accumulano nel tempo.

Debito di sicurezza: una deriva sistemica e silenziosa

Il vibecoding accelera la formazione del cosiddetto security debt, ovvero l’accumulo di vulnerabilità latenti generate da compromessi rapidi e non analizzati.

Il debito di sicurezza non nasce da errori evidenti, ma dalla somma di modifiche rapide che non vengono sottoposte a threat modeling o revisione approfondita. Ogni nuova funzione, endpoint o integrazione aggiunta “velocemente” contribuisce a costruire una base di codice sempre più difficile da governare.

Questo fenomeno è particolarmente critico nei contesti enterprise, dove il codice entra rapidamente in produzione e diventa parte di sistemi complessi e interconnessi.

Il problema dell’ownership: responsabilità frammentata

Uno degli effetti meno evidenti ma più critici del vibecoding riguarda la perdita di ownership chiara sul codice. La responsabilità si distribuisce tra chi scrive il prompt, il modello AI che genera il codice, chi lo approva e chi lo gestisce in produzione, creando una catena decisionale opaca.

Anche quando esiste un “committer”, mancano spesso informazioni fondamentali come il contesto di generazione, le motivazioni tecniche e le dipendenze introdotte. Questo rende estremamente complesso intervenire su problemi di sicurezza: la mancanza di contesto trasforma ogni correzione in un’attività di reverse engineering, aumentando tempi e costi di remediation.

Revisione e controlli: quando l’AI valida sé stessa

Un ulteriore elemento di rischio emerge quando lo stesso sistema di AI viene utilizzato sia per generare codice sia per validarlo. Si crea così un’illusione di revisione, senza una reale separazione dei ruoli e delle responsabilità, compromettendo uno dei principi fondamentali della sicurezza: l’indipendenza dei controlli.

In questo scenario, i controlli tradizionali non vengono eliminati, ma semplicemente sovraccaricati da un volume di cambiamenti che non sono stati progettati per gestire.

Il vero rischio: software change fuori controllo

Il punto centrale non è la qualità del codice generato dall’AI, ma la perdita di controllo sul processo di sviluppo. Il rischio più rilevante del vibecoding è l’introduzione di cambiamenti software continui, veloci e non completamente governati, che superano la capacità delle organizzazioni di monitorare cosa viene realmente distribuito in produzione.

L’AI amplifica dinamiche già esistenti – riuso di librerie, configurazioni errate, sviluppo sotto pressione – portandole a una scala e a una velocità senza precedenti.

Sicurezza adattiva: come devono evolvere i controlli

Se il vibecoding è destinato a diventare la norma, la sicurezza deve cambiare approccio. La protezione efficace non può più basarsi su controlli a valle, ma deve intervenire nelle fasi iniziali del ciclo di sviluppo, intercettando i rischi nel momento in cui vengono introdotti.

Diventa fondamentale automatizzare le policy di sicurezza, integrare i controlli nei workflow CI/CD e creare un contesto condiviso tra team di sviluppo e sicurezza. Solo in questo modo è possibile mantenere la velocità senza sacrificare la governance.

Il ruolo delle piattaforme integrate

L’aumento della complessità rende sempre meno efficaci gli strumenti isolati. Le piattaforme integrate di code security emergono come elemento chiave per scalare i controlli insieme alla velocità di sviluppo, permettendo di correlare codice, dipendenze, policy e pipeline di rilascio.

La differenza non è tanto nelle funzionalità, quanto nel momento in cui la sicurezza interviene: quando è anticipata, diventa supporto allo sviluppo; quando è tardiva, viene percepita come ostacolo.

Il vibecoding non è un fenomeno temporaneo, ma una trasformazione strutturale dello sviluppo software. Il vero problema non è l’AI che scrive codice insicuro, ma il fatto che gli sviluppatori possano rilasciare codice che non hanno avuto il tempo di comprendere e proteggere. Secondo Trend Micro, le organizzazioni che avranno successo non saranno quelle che limiteranno l’uso dell’AI, ma quelle che sapranno integrare sicurezza, governance e sviluppo in un modello coerente con questa nuova realtà.

---

---

---

https://www.securityinfo.it/2026/03/31/vibecoding-lai-accelera-lo-sviluppo-ma-moltiplica-i-rischi/?utm_source=rss&utm_medium=rss&utm_campaign=vibecoding-lai-accelera-lo-sviluppo-ma-moltiplica-i-rischi

WordPress 7.0, previously scheduled for an April 9th release, will be delayed in order to stabilize the Real-Time Collaboration feature and assure that the release, a major milestone, will “target extreme stability.” Much is riding on WordPress 7.0 as it will ship with features that will usher in the age of AI-driven content management systems.

Prioritization Of Stability

Matt Mullenweg, co-founder of WordPress, commenting in the official Making WordPress Slack workspace, said the release should step back from its current trajectory and prioritize stability, calling for a longer pre-release phase to get the real-time collaboration (RTC) feature working correctly. The delay is expected to last weeks, not days, and is described as a one-off deviation from WordPress’s planned date-driven schedule.

Mullenweg posted:

“Given the scope and status of 7.0, I think we should go back to beta releases, get the new tables right, lock in everything we want for 7.0, and then start RCs again. Date-driven is still our default, but for this milestone release we want to target extreme stability and exciting updates, especially as AI-accelerated development is increasing people’s expectations for software.

This is a one-off, I think for future we should get back on the scheduled train, with an aim for 4-a-year in 2027, to hopefully reflect our AI-enabled ability to move faster.”

Extended Release Candidate Phase Replaces Beta Reversion

To avoid technical compatibility issues, the project will remain in the release candidate phase, extending the testing period through additional RC builds as needed.

The proposal to return to beta releases was rejected because it would break PHP version comparison behavior, plugin update logic, and tooling that depends on standard version sequencing. Continuing with RC builds preserves compatibility while allowing more time for testing and fixes.

Real-Time Collaboration

The delay is largely due to the Real-Time Collaboration feature, which introduces new database tables and changes how WordPress handles editing sessions. Contributors identified risks related to performance, data handling, and interactions with existing systems.

A primary concern is that real-time editing currently disables persistent post caches during active sessions, a performance issue the team is working to resolve before the final release.

Database Design Raises Performance Concerns

A key part of the discussion focused on how to structure the database for Real-Time Collaboration (RTC).  A proposed single RTC table would support 1. real-time editing updates and 2. synchronization. But some contributors noted that the workloads for real-time editing and synchronization are fundamentally different.

Real-time collaboration generates high-frequency, bursty writes that require low latency (meaning updates happen with very little delay).

While synchronization between environments involves slower, structured updates that may include full-table scans.

Combining both patterns within one table risks performance issues and added complexity. Contributors discussed separating these workloads into separate tables optimized for each use case, but no decision has been made.

Gap In Release Candidate Testing Raises Concern

The discussion in the WordPress Slack workspace also raised concern over whether there was enough real-world release candidate testing, and database schema changes increase the risk of failures during upgrades. The solution of using the Gutenberg plugin for testing was rejected because database changes could affect production sites and require complex migration logic. Instead, the project will use an extended RC phase to increase testing exposure and gather feedback from a wider group of users.

Versioning Constraints

The proposal to delay version 7.0 led to additional issues. PHP version comparison rules and related tooling complicated returning to beta versions. It was agreed that staying within the release candidate sequence (ergo RC1, RC2, RC3) avoids these issues while allowing continued iteration, so it was decided to continue with release candidates.

Future Release Cadence Remains

The delay is described as a temporary exception. Matt Mullenweg said the project intends to return to a regular release schedule, with a goal of delivering roughly four releases per year by 2027 as development speeds increase with AI-assisted workflows.

Implications For Developers And Users

Developers should expect continued changes to the Real-Time Collaboration feature and its supporting database structures during the extended release candidate phase. The longer testing period provides more time to identify issues before release. For site owners and hosts, the delay shows that WordPress is prioritizing stability over schedule while introducing more complex real-time and synchronization features.

Impact Of RTC On Hosting Environments

Something that wasn’t discussed but is a real issue is how real-time collaboration might affect web hosting providers. They need to test that feature to see if it introduces issues on shared hosting environments. While RTC will be shipping with the feature turned off by default, the impact of it being used by customers in a shared hosting environment is currently unknown. A spokesperson for managed WordPress hosting provider Kinsta told Search Engine Journal they are still testing. Given how the feature is still evolving, Kinsta and other web hosts will have to continue testing the upcoming WordPress release candidates.

I think most people will agree that the decision to delay the release of WordPress 7.0 is the right call.

https://www.searchenginejournal.com/wordpress-delays-release-of-version-7-0-to-focus-on-stability/570944/

Google’s Gary Illyes and Martin Splitt used a recent episode of the Search Off the Record podcast to discuss whether webpages are getting too large and what that means for both users and crawlers.

The conversation started with a simple question: are websites getting fat? Splitt immediately pushed back on the framing, arguing that website-level size is meaningless. Individual page size is where the discussion belongs.

What The Data Shows

Splitt cited the 2025 Web Almanac from HTTP Archive, which found that the median mobile homepage weighed 845 KB in 2015. By July, that same median page had grown to 2,362 KB. That’s roughly a 3x increase over a decade.

Both agreed the growth was expected, given the complexity of modern web applications. But the numbers still surprised them.

Splitt noted the challenge of even defining “page weight” consistently, since different people interpret the term differently depending on whether they’re thinking about raw HTML, transferred bytes, or everything a browser needs to render a page.

How Google’s Crawl Limits Fit In

Illyes discussed a 15 MB default that applies across Google’s broader crawl infrastructure, where each URL gets its own limit, and referenced resources like CSS, JavaScript, and images are fetched separately.

That’s a different number from what appears in Google’s current Googlebot documentation. Google states that Googlebot for Google Search crawls the first 2 MB of a supported file type and the first 64 MB of a PDF.

Our previous coverage broke down the documentation update that clarified these figures earlier this year. Illyes and Splitt discussed the flexibility of these limits in a previous episode, noting that internal teams can override the defaults depending on what’s being crawled.

The Structured Data Question

One of the more interesting moments came when Illyes raised the topic of structured data and page bloat. He traced it back to a statement from Google co-founder Sergey Brin, who said early in Google’s history that machines should be able to figure out everything they need from text alone.

Illyes noted that structured data exists for machines, not users, and that adding the full range of Google’s supported structured data types to a page can add weight that visitors never see. He framed it as a tension rather than offering a clear answer on whether it’s a problem.

Does It Still Matter?

Splitt said yes. He acknowledged that his home internet connection is fast enough that page weight is irrelevant in his daily experience. But he said the picture changes when traveling to areas with slower connections, and noted that metered satellite internet made him rethink how much data websites transfer.

He suggested that page size growth may have outpaced improvements in median mobile connection speeds, though he said he’d need to verify that against actual data.

Illyes referenced prior studies suggesting that faster websites tend to have better retention and conversion rates, though the episode didn’t cite specific research.

Looking Ahead

Splitt said he plans to address specific techniques for reducing page size in a future episode.

Most pages are still unlikely to hit those limits, with the Web Almanac reporting a median mobile homepage size of 2,362 KB. But the broader trend of growing page weight affects both performance and accessibility for users on slower or metered connections.

https://www.searchenginejournal.com/google-pages-are-getting-larger-it-still-matters/570875/