Spcnet.it

2026-06-19 12:01:28

Processor Performance Boost Mode in Windows 11: come sbloccare le modalità nascoste di boost della CPU con una modifica al registro

Windows 11 nasconde una funzionalità di gestione avanzata della CPU che la maggior parte degli utenti — anche esperti — non conosce: il Processor Performance Boost Mode. Si tratta di un menu a tendina nascosto nelle opzioni di risparmio energia del Pannello di Controllo, disabilitato per impostazione predefinita su tutti i sistemi, che consente di controllare con granularità come Windows richiede e gestisce le frequenze turbo/boost del processore.

La funzionalità si basa su CPPC (Collaborative Processor Performance Control), uno standard incluso nelle specifiche ACPI (Advanced Configuration and Power Interface) e presente in praticamente tutti i processori Intel e AMD moderni. Con una semplice modifica al registro di sistema è possibile sbloccare queste impostazioni senza toccare il BIOS né ricorrere a tool di overclocking.

Background tecnico: P-States, C-States e CPPC

Per comprendere il funzionamento del Boost Mode è utile richiamare i concetti fondamentali della gestione energetica della CPU:

• P-States (Performance States): definiscono le coppie tensione/frequenza a cui il processore può operare. P0 è la frequenza massima (turbo), P1+ corrispondono a frequenze via via inferiori.
• C-States (Idle States): definiscono i livelli di “sonno” del processore quando non è sotto carico; C0 è lo stato attivo, C6/C7/C8 corrispondono a stati di risparmio energetico profondi.
• HWP/CPPC (Hardware P-States / Collaborative Processor Performance Control): a differenza dei P-States tradizionali gestiti dal sistema operativo, CPPC crea un dialogo diretto tra OS e hardware. Windows dichiara un “livello di performance desiderato” e il processore decide autonomamente come ottimizzare la risposta, tenendo conto di temperatura, consumo e capacità hardware.

Attivando il Processor Performance Boost Mode, Windows 11 espone questa interfaccia CPPC all’utente tramite il Pannello di Controllo, permettendo di scegliere tra sette profili distinti.

Come sbloccare il Processor Performance Boost Mode

La procedura richiede la modifica di un valore nel registro di sistema. Nessun riavvio del sistema è necessario per visualizzare le nuove opzioni, ma potrebbe essere richiesto per applicare il profilo scelto.

Passo 1 — Apri l’Editor del Registro di Sistema:

Win + R → regedit → OK

Passo 2 — Naviga al seguente percorso:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerSettingsť33251-82be-4824-96c1-47b60b740d00e337238-0d82-4146-a960-4f3749d470c7

Passo 3 — Fai clic destro sul valore Attributes e seleziona Modifica. Cambia il valore da 1 a 2.

Passo 4 — Chiudi il registro e apri le Opzioni risparmio energia nel Pannello di Controllo (non le impostazioni moderne di Windows 11). Clicca su Modifica impostazioni combinazione → Cambia impostazioni avanzate risparmio energia → espandi la sezione Gestione alimentazione del processore.

Troverai ora la nuova voce Processor performance boost mode con il suo menu a tendina.

Nota per script e automazione: la stessa modifica può essere eseguita da PowerShell (come amministratore):

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Power\PowerSettingsť33251-82be-4824-96c1-47b60b740d00e337238-0d82-4146-a960-4f3749d470c7" -Name "Attributes" -Value 2

I sette profili di boost disponibili

Una volta sbloccata, la voce espone le seguenti modalità:

Disabled

Il boost del processore è completamente disattivato. La CPU opera alla frequenza base senza mai entrare in modalità turbo. Utile per ambienti con vincoli termici severi, virtualizzazione rigorosa o quando si necessita di un comportamento deterministico (es. benchmark di precisione, server con carico costante).

Enabled

Comportamento standard: il boost è consentito nelle condizioni normali gestite dall’OS. Il processore può salire in frequenza in modo opportunistico, bilanciando performance e consumi.

Aggressive

Windows richiede frequenze boost più elevate e per periodi più lunghi. Il processore entra in turbo più rapidamente e vi rimane più a lungo. Aumenta la reattività nelle situazioni di burst, ma incrementa consumo energetico e temperatura.

Efficient Enabled

Il boost è permesso, ma con maggiore attenzione all’efficienza energetica. Il sistema evita picchi di frequenza non necessari quando il guadagno prestazionale sarebbe marginale.

Efficient Aggressive

Ibrido: il boost è ancora performante, ma il sistema bilancia continuamente efficienza e prestazioni. Riduce i consumi rispetto alla modalità Aggressive mantenendo buona reattività nei carichi variabili.

Aggressive at Guaranteed

Windows calcola il delta di performance desiderato al di sopra della guaranteed performance level (il livello di frequenza che il processore garantisce in condizioni termiche nominali) e chiede esplicitamente al processore di erogare quel livello specifico.

Efficient Aggressive at Guaranteed

Simile al precedente, ma Windows chiede sempre al processore il massimo livello di performance possibile al di sopra della guaranteed performance, con una gestione efficiente dal punto di vista energetico.

Quale profilo scegliere?

La scelta dipende dal contesto d’uso:

• Workstation desktop con raffreddamento adeguato: Aggressive o Efficient Aggressive offrono la massima reattività nei carichi interattivi e di compilazione.
• Laptop: Efficient Enabled o Efficient Aggressive bilanciano performance e durata della batteria senza surriscaldamento eccessivo.
• Server o VM host Hyper-V: Disabled garantisce comportamento prevedibile e riduce la variabilità delle latenze; Enabled è adeguato per workload misti.
• Sviluppo e CI/CD locale: Aggressive riduce i tempi di build e di esecuzione dei test, soprattutto su CPU con turbo elevato (es. Intel Core Ultra, AMD Ryzen 9).

Ripristino e considerazioni di sicurezza

Se dopo la modifica si osservano instabilità, crash o surriscaldamento eccessivo, è sufficiente riportare il valore Attributes a 1 via registro o con il comando PowerShell inverso:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Power\PowerSettingsť33251-82be-4824-96c1-47b60b740d00e337238-0d82-4146-a960-4f3749d470c7" -Name "Attributes" -Value 1

La modifica non costituisce overclocking nel senso tradizionale del termine: non altera tensioni, moltiplicatori o frequenze base, ma si limita a comunicare con il processore tramite l’interfaccia CPPC ufficiale prevista dallo standard ACPI. Il rischio di danni hardware è pertanto molto basso, ma su portatili con dissipazione borderline è consigliabile monitorare le temperature con tool come HWiNFO64 o Open Hardware Monitor.

Conclusioni

Il Processor Performance Boost Mode è una di quelle funzionalità che Microsoft ha scelto di nascondere per proteggere gli utenti meno esperti da configurazioni potenzialmente problematiche — ma che per un sistemista o uno sviluppatore offre un controllo prezioso sul comportamento del processore. Con una riga di registro o un comando PowerShell è possibile ottimizzare Windows 11 per scenari specifici, dal laptop in mobilità alla workstation di sviluppo, senza toccare il BIOS e senza strumenti di terze parti.

---

Fonte originale: Unlocking hidden processor performance boost modes in Windows 11 – 4sysops, con approfondimento da Neowin.

Unlocking hidden processor performance boost modes in Windows 11 – 4sysops

Windows 11 contains a hidden configuration menu called Processor Performance Boost Mode that allows for granular control over CPU frequency scaling. This featur

^{IT News (4sysops)}

Spcnet.it

2026-06-19 12:01:53

GitHub Copilot SDK è ora Generally Available: integra l’agente AI nelle tue applicazioni

Il GitHub Copilot SDK ha raggiunto la disponibilità generale (GA) il 2 giugno 2026, annunciata durante il Microsoft Build 2026. Questa milestone segna la maturità di uno degli strumenti più attesi dagli sviluppatori che vogliono integrare le capacità agentiche di GitHub Copilot direttamente nelle proprie applicazioni, servizi e tool di sviluppo.

Cos’è il GitHub Copilot SDK?

Il Copilot SDK espone l’agent runtime che alimenta GitHub Copilot — lo stesso motore responsabile di planning, invocazione di tool, modifica di file, streaming e sessioni multi-turn — attraverso un’API stabile e pronta per la produzione. Non è quindi una semplice libreria di completamento del codice, bensì un framework completo per costruire applicazioni agentiche basate su Copilot.

In pratica, con il Copilot SDK è possibile costruire:

• Assistenti CI/CD che analizzano e correggono pipeline fallite
• Developer tool interni con AI integrata
• Feature AI rivolte agli utenti finali delle proprie applicazioni
• Agent personalizzati per code review, test generation, documentazione automatica

Sei linguaggi supportati

Il Copilot SDK è ora disponibile in sei linguaggi di programmazione, con Rust e Java aggiunti al momento della GA:

# Node.js / TypeScript
npm install @github/copilot-sdk

# Python
pip install github-copilot-sdk

# Go
go get github.com/github/copilot-sdk/go

# .NET (C#)
dotnet add package GitHub.Copilot.SDK

# Rust
cargo add github-copilot-sdk

# Java (Maven/Gradle)
# disponibile su Maven Central

Per Node.js, Python e .NET, la Copilot CLI viene inclusa automaticamente come dipendenza: non è necessaria un’installazione separata.

Capacità chiave

Custom Tools e supporto MCP

Uno degli aspetti più potenti del SDK è la possibilità di registrare tool personalizzati che l’agente può invocare autonomamente. È supportato il Model Context Protocol (MCP), il che significa che è possibile connettere qualunque MCP server esistente, oppure sovrascrivere i tool predefiniti come grep e edit_file con implementazioni proprie.

// Esempio .NET: registrazione di un tool personalizzato
var session = await copilotClient.CreateSessionAsync(new SessionOptions
{
    Tools = new[]
    {
        new ToolDefinition
        {
            Name = "query_database",
            Description = "Esegue una query SQL sul database di produzione",
            Parameters = JsonSchema.FromType<QueryParams>()
        }
    }
});

Customizzazione fine del system prompt

A differenza di molti SDK AI che costringono a riscrivere l’intero system prompt, il Copilot SDK permette di modificare singole sezioni — identità, tono, istruzioni per i tool, regole di sicurezza — preservando il comportamento di base di Copilot.

OpenTelemetry tracing

Il SDK integra il supporto W3C trace context propagation per tracciamento distribuito attraverso startup CLI, chiamate JSON-RPC, operazioni di sessione e esecuzione dei tool. Questo facilita enormemente il debugging in ambienti di produzione complessi.

Autenticazione flessibile e BYOK

Sono supportate quattro modalità di autenticazione:

• GitHub OAuth — per applicazioni personali
• GitHub Apps — per integrazioni enterprise
• Environment tokens — per ambienti CI/CD
• BYOK (Bring Your Own Key) — per usare modelli propri da OpenAI, Microsoft Foundry, Anthropic e altri provider

Hook system

Il sistema di hook consente di intercettare il comportamento dell’agente in punti specifici del ciclo di vita:

• Pre/post invocazione di tool
• Avvio di sessione
• Chiamate a MCP tool
• Richieste di permesso

Cloud e remote sessions

È possibile creare sessioni cloud-backed con metadata del repository, oppure abilitare URL di sessione remota on demand. Questa funzionalità apre scenari interessanti per workflow multi-client dove diversi partecipanti contribuiscono tool e permessi alla stessa sessione.

Novità rispetto alla Public Preview

• Nuovo Rust SDK con Copilot CLI bundled di default
• Migliorato supporto per workflow multi-client: diversi client possono contribuire tool e permessi alla stessa sessione
• Slash command e interactive input prompt disponibili in tutti gli SDK
• API surface stabile e production-ready dopo il cleanup basato sul feedback della preview
• Diagnostica migliorata per connessioni lente o fallite

Pricing e disponibilità

Il GitHub Copilot SDK è disponibile per tutti i subscriber esistenti di GitHub Copilot, incluso il piano Copilot Free per uso personale. Per chi non ha una sottoscrizione Copilot attiva, è possibile usarlo tramite BYOK con il proprio provider AI.

Come iniziare

Per iniziare è sufficiente scegliere il linguaggio preferito, installare il pacchetto e seguire la Getting Started Guide ufficiale. GitHub mette a disposizione anche un cookbook con ricette pratiche per i casi d’uso più comuni in tutti i linguaggi supportati.

Per sviluppatori .NET, l’integrazione è particolarmente naturale dato che il pacchetto NuGet GitHub.Copilot.SDK è coerente con l’ecosistema esistente e supporta completamente async/await, dependency injection e il pattern di configurazione tipico di ASP.NET Core.

---

Fonte originale: GitHub Changelog — Copilot SDK is now generally available

Copilot SDK is now generally available - GitHub Changelog

The GitHub Copilot SDK is now generally available. You can embed GitHub Copilot’s agentic engine into your own applications, services, and developer tools with a stable API and production-ready support.…

^{Allison (The GitHub Blog)}

(in)sicurezza digitale

2026-06-19 12:03:56

LLMjacking si evolve: server Ollama esposti diventano il cervello di uno strumento di hacking autonomo, catturato in sviluppo da Sysdig

Si parla di:
Toggle

Il 12 giugno 2026, il Sysdig Threat Research Team (TRT) ha osservato qualcosa che i ricercatori di sicurezza prevedevano da almeno due anni: un threat actor che utilizzava un server AI accessibile su internet come cervello di uno strumento di hacking completamente automatizzato. Non si trattava di un esperimento accademico né di una proof-of-concept: il framework, denominato VAPT, era in sviluppo attivo, con stadi aggiornati in tempo reale, e operava contro ambienti benchmark privati usando capacità di inferenza sottratte tramite un server Ollama esposto senza autenticazione.

Dal furto di compute all’arma autonoma: l’evoluzione del LLMjacking

Il termine LLMjacking è stato coniato da Sysdig nel maggio 2024 per descrivere il pattern in cui attori malevoli utilizzano credenziali cloud sottratte per accedere a servizi AI a pagamento — OpenAI, Anthropic, Google Gemini — scaricando le spese sulla vittima, con costi potenziali fino a 46.000 dollari al giorno. Entro il 2025, questa pratica si era industrializzata in un mercato nero con infrastruttura di reverse-proxy che intermediava miliardi di token rubati.

Con la proliferazione di server AI auto-ospitati, la superficie di attacco si è spostata. Ollama, il popolare tool per servire modelli LLM in locale, ascolta sulla porta 11434 senza autenticazione per impostazione predefinita. Ricercatori indipendenti hanno catalogato circa 175.000 istanze Ollama pubblicamente esposte in più di 130 paesi, una superficie enorme di compute non protetto e non fatturato. Ciò che Sysdig TRT ha osservato a giugno 2026 è il passo successivo: non il furto di compute per rivenderlo, ma il suo utilizzo come motore ragionante per offensive tooling autonomo.

Il threat actor e le sessioni osservate

La prima sessione osservata dal Sysdig TRT ha avuto origine dall’IP 122.183.48.82, registrato a un provider residenziale/small-business di Hyderabad, India. La sessione è iniziata alle 15:43 UTC del 12 giugno 2026 e si è protratta per circa otto ore e mezza. Due giorni dopo, il 14 giugno, lo stesso tool è tornato operativo da tre IP aggiuntivi: 122.183.48.35, 122.183.48.195 (stessa rete del primo) e 47.15.69.15, tutti riconducibili a connessioni residenziali indiane.

Sysdig attribuisce tutte le sessioni allo stesso operatore per tre ragioni convergenti: identica pipeline VAPT, identici target benchmark privati, e comune origine geografica indiana. La rotazione tra ISP è la normale variazione di una connessione residenziale, non il segnale di operatori multipli indipendenti.

Architettura del framework VAPT: il modello AI come decision engine

Ciò che rende questa campagna eccezionale dal punto di vista dell’analisi è la visibilità completa ottenuta da Sysdig. Poiché il framework invia le proprie istruzioni complete al modello a ogni richiesta, il team ha potuto catturare l’architettura integrale: ogni stadio della pipeline logica, la struttura imposta agli output del modello, e la firma usata per confermare una compromissione.

Il framework VAPT opera come una pipeline sequenziale di stadi specializzati, ciascuno con un ruolo preciso:

• Service fingerprinting: normalizza i banner dei servizi di rete in un’identità software precisa per la ricerca CVE.
• Vulnerability matching e triage: incrocia prodotto e versione con le vulnerabilità note, filtrando quelle applicabili.
• Web reconnaissance: analizza testo della pagina, header, cookie, form field e path scoperti per costruire un profilo di attacco.
• Proof-of-concept synthesis: costruisce PoC per validare singole vulnerabilità, inclusi payload protocol-aware.
• Blind SQL injection crafting: costruisce payload time-based con logica di filter-evasion.
• Credential e secret extraction: analizza file di sistema compromessi alla ricerca di credenziali riusabili.
• Arbitrary file-read planning: data una primitiva di lettura file, pianifica quali file recuperare.
• Privilege escalation: decide il passo successivo per l’escalation dei privilegi.
• Autonomous orchestration: controller che guida l’intera catena fino al raggiungimento di command execution.

L’orchestratore autonomo: il codice catturato

Lo stadio di orchestrazione è il più rivelatore dell’intento del tool. L’istruzione inviata al modello specifica un agente di web-exploitation “autorizzato” che deve raggiungere la command execution sul target. Una volta confermata l’RCE tramite il pattern echo VAPTb3gin; id; echo VAPTfin, il tool congela la richiesta riuscita sostituendo il comando con il placeholder __VAPTCMD__, trasformando il singolo exploit in una ricetta riutilizzabile con qualsiasi comando.

Una variante dell’orchestratore rivela un ulteriore dettaglio architetturale: il modello opera in modalità “PROPOSE-ONLY”, mentre un verificatore deterministico separato (oracles.py) decide se un payload ha effettivamente avuto successo. Questa separazione tra componente AI (proposta) e componente deterministica (verifica) è il design pattern di software mantenuto professionalmente, non di uno script improvvisato.

Il tool era in sviluppo attivo

Uno degli aspetti più significativi della campagna è la prova che il tool era in sviluppo iterativo durante le sessioni osservate. Nella sessione dell’8 ore del 12 giugno, il set di stadi è cresciuto nel corso della giornata: service fingerprinting, vulnerability triage, blind SQL injection, PoC synthesis e orchestratore autonomo sono apparsi dopo circa tre ore. Credential extractor e file-read planner sono stati aggiunti in serata, gli stadi per il database SQL triage nelle ultime novanta minuti. Singoli stadi sono stati riscritti in-place più volte — la fase di web-reconnaissance ha attraversato tre versioni distinte.

Quando il tool è tornato il 14 giugno, il set completo di stadi — inclusi quelli apparsi solo nelle fasi finali della sessione precedente — era presente fin dalle prime richieste. Il threat actor aveva integrato ogni aggiunta nel codice baseline prima del run successivo. Sysdig descrive questo come un vantaggio di osservazione straordinariamente precoce: il tool è stato catturato prima di essere diretto contro vittime reali.

I modelli richiesti: agnosticismo del backend

Un dettaglio tecnico rivelatore è l’elenco dei modelli richiesti dal tool al server Ollama: gpt-4o-mini (OpenAI), claude-3-5-sonnet (Anthropic), gemini-2.0-flash-exp (Google), mistral:7b, deepseek-r1:8b, qwen3.5:4b, e una versione “abliterated” (con guardrail rimossi) di Llama-3.3-70B. I tre modelli commerciali non sono compatibili con Ollama: la loro presenza mostra che il tool è backend-agnostico e l’operatore aveva semplicemente reindirizzato il backend verso il server Ollama gratuito in sostituzione di un API key a pagamento. Il server esposto era un drop-in sostituto per l’inferenza a tariffazione.

Due righe per i difensori

Sysdig identifica un blind spot difensivo fondamentale: il rilevamento che monitora i log del proprio server modello presuppone che l’operatore possieda e monitori quel server. Un server esposto scoperto da un attore esterno è, per definizione, uno che il proprietario non sta osservando. I proprietari vedranno compute elevato e una porta aperta, non una pipeline di attacco multi-stadio.

Indicatori di Compromissione

# IP sorgente osservati
122.183.48.82    # Hyderabad, India - sessione 12 giugno
122.183.48.35    # Hyderabad, India - sessione 14 giugno
122.183.48.195   # Hyderabad, India - sessione 14 giugno
47.15.69.15      # India, secondo ISP - sessione 14 giugno

# Marker di compromissione (RCE oracle)
echo VAPTb3gin; id; echo VAPTfin

# Marker nel payload
VAPTb3gin        # Sentinel di apertura
VAPTfin          # Sentinel di chiusura
__VAPTCMD__      # Placeholder per replay exploit

# Target fittizi del benchmark
MediaVault Asset Portal
Reverb Studio

# Range di rete target
172.30.0.0/24    # Range benchmark privato
10.129.0.0/16    # Range HackTheBox lab VPN

# Porta esposta
11434            # Porta default Ollama (no auth)

# Pattern di detection (Falco)
richieste HTTP su porta 11434 con contenuto
matching /VAPTb3gin|VAPTfin|VAPTCMD/

Raccomandazioni operative

• Isolare i server modello dalla rete pubblica: Ollama e sistemi simili devono essere esposti solo su localhost o su interfacce interne, mai su internet. La porta 11434 non deve essere raggiungibile dall’esterno.
• Aggiungere autenticazione a livello di proxy: Ollama non implementa autenticazione nativa; deve essere aggiunta tramite un reverse proxy autenticante.
• Monitorare il volume di inferenza: picchi anomali di compute sul server AI sono un indicatore primario di abuso esterno.
• Cercare i marker VAPT nei log: scansionare i log delle applicazioni web per le stringhe VAPTb3gin, VAPTfin e __VAPTCMD__ — la loro presenza indica che un sistema è stato attaccato da questo framework o da varianti.
• Scansione proattiva dei propri asset: verificare internamente la presenza di server Ollama o altri inference endpoint esposti su internet con la stessa metodologia usata da un attaccante.

Fonte: Sysdig Threat Research Team, Michael Clark (Director of Threat Research). Research pubblicato il 17 giugno 2026. Full report: sysdig.com/blog/llmjacking-evolved

LLMjacking evolved: Attackers are using stolen AI compute to build offensive agentic tools | Sysdig

Sysdig TRT caught a threat actor using a stolen Ollama server to power an autonomous, multi-stage offensive hacking tool — live, in development, and in full detail.

^{Michael Clark (Sysdig)}

(in)sicurezza digitale

2026-06-19 12:06:52

Operation Endgame abbatte SocGholish: 100 server offline e 15.000 siti risanati nell’operazione contro Evil Corp

Il 18 giugno 2026, un’operazione congiunta di forze dell’ordine internazionali ha sferrato un colpo devastante contro TA569, il gruppo cybercriminale noto per la distribuzione del malware SocGholish. L’Operazione Endgame ha abbattuto oltre 100 server e domini, sanificato quasi 15.000 siti web compromessi in tutto il mondo e — soprattutto — ha colpito un’infrastruttura criminale che per anni ha aperto le porte a ransomware come LockBit, WastedLocker e RansomHub.

Chi è TA569 e perché importa

Proofpoint segue TA569 dal 2018, anno in cui il gruppo ha iniziato a dominare la scena dei web inject, ovvero l’iniezione di codice malevolo in siti web legittimi per reindirizzare i visitatori verso payload pericolosi. Il modus operandi è ormai tristemente noto: la vittima visita un sito compromesso e si trova davanti a un pop-up che imita fedelmente una notifica del browser, chiedendole di aggiornare Chrome o Edge. Un clic sul pulsante di aggiornamento avvia il download di GhoLoader, il payload di primo stadio che — in ambienti Active Directory — può rapidamente evolvere in un attacco ransomware devastante.

Il gruppo è stato associato da più ricercatori a Evil Corp, il famigerato sodalizio cybercriminale russo i cui membri sono stati sanzionati più volte da governi occidentali (USA, UK, Australia). Il collegamento non è formale ma è suffragato da sovrapposizioni infrastrutturali, utilizzo degli stessi strumenti e partnership operative. I ransomware distribuiti attraverso la catena SocGholish includono WastedLocker (firmato Evil Corp), LockBit e — più recentemente — RansomHub.

L’architettura di SocGholish: TDS, fake plugin e proxy inverso

La catena di attacco di TA569 si articola in tre componenti distinte. Prima di tutto, il web inject: il gruppo compromette siti WordPress attraverso password spraying, credenziali riutilizzate, vulnerabilità in plugin abbandonati o zero-day in componenti CMS. Una volta dentro, installa plugin falsi che si nascondono dall’interfaccia di amministrazione e iniettano JavaScript offuscato nelle risposte HTTP del sito, che funge da proxy inverso verso l’infrastruttura TA569.

Il secondo componente è il Traffic Distribution System (TDS): TA569 utilizza sia ParrotTDS (di proprietà del gruppo) sia il servizio Keitaro gestito da TA2726, un altro threat actor. Il TDS filtra il traffico in base a paese, browser, sistema operativo e comportamento dell’utente prima di decidere quale payload consegnare. Questa variabilità rende la documentazione degli attacchi particolarmente complessa: lo stesso sito compromesso può consegnare SocGholish a un utente Windows negli USA, FrigidStealer a un Mac in Gran Bretagna, o nulla a un sistema di sicurezza automatizzato.

Il terzo componente è GhoLoader: quando la vittima supera tutti i controlli anti-bot e clicca sul pulsante di aggiornamento, un iframe nascosto caricato da un URI data: recupera lo script malevolo dal C2, costruisce il file client-side tramite URL.createObjectURL() e innesca il download. Il file scaricato (Google Launcher.js) è in realtà GhoLoader Stage 1 — uno script WSH JScript che comunica con il C2 tramite ActiveXObject('MSXML2.XMLHTTP'). Questa tecnica aggira i sandbox che si limitano a simulare un click sul pulsante, senza gestire la comunicazione cross-frame tramite postMessage.

Operation Endgame: la risposta internazionale

Il 18 giugno 2026, autorità di quattro paesi — Paesi Bassi (NHCTU), Canada (RCMP), Stati Uniti (FBI) e Germania (BKA), con il supporto di Europol — hanno eseguito un’azione coordinata contro l’infrastruttura di TA569. I risultati, comunicati ufficialmente dalla polizia olandese, sono notevoli:

• Oltre 100 server e domini abbattuti a livello globale
• 14.971 siti web compromessi identificati e risanati
• Video di denuncia pubblica pubblicato sul sito di Operation Endgame
• Proofpoint ha fornito intelligence tecnica alle autorità per supportare l’operazione

Non si tratta del primo capitolo di Operation Endgame: nel 2024 la stessa operazione aveva colpito loader come IcedID, Smokeloader e SystemHeuristicZ. Il fatto che TA569 sia ora nel mirino delle forze dell’ordine segna un’escalation significativa, dato che SocGholish è stato il vettore di distribuzione per alcune delle campagne ransomware più dannose degli ultimi anni.

Impatto e ripercussioni nell’ecosistema dei web inject

TA569 è stato il capostipite dei web inject malevoli, ma nel tempo ha ispirato un ecosistema di imitatori: ClearFake, ZPHP, ErrTraffic, LandUpdate808 (noto anche come KongTuke) e altri attori monitorati da Proofpoint continuano ad operare in modo indipendente. L’operazione di law enforcement colpirà direttamente TA569 ma non eliminerà il problema alla radice: TA2726, il fornitore TDS che serve anche altri threat actor, non sembra direttamente coinvolto nell’azione.

Proofpoint stima che l’operazione causerà interruzioni operative significative per TA569, incluse perdite finanziarie, danni reputazionali nei circuiti criminali e perdita di clienti ransomware. Tuttavia, come accaduto dopo precedenti disruption (LockBit, ALPHV), è probabile che parte del traffico di web inject migri verso altri attori già attivi.

Indicatori di Compromissione (IoC)

# Domini C2 TA569 osservati (maggio-giugno 2026)
platform[.]exathomeswebuyarizona[.]com   # Delivery SocGholish Stage 1
js-new[.]newtoyoygame[.]com             # C2 GhoLoader Stage 1
# File osservati
Google Launcher.js                       # GhoLoader Stage 1 (WSH JScript)
# Tecnica di delivery
blob:    # URL createObjectURL() per delivery senza traccia di rete
data:    # iframe nascosto per comunicazione cross-frame
# Threat actors correlati
TA569   # Evil Corp-linked, SocGholish operator
TA2726  # Keitaro TDS provider (continua a operare)
ParrotTDS  # TDS di proprietà TA569

Due righe per i difensori

Per i team di sicurezza, la mitigazione richiede un approccio stratificato. Sul fronte della difesa di rete, è consigliabile adottare il ruleset Emerging Threats e implementare protezioni endpoint capaci di rilevare l’esecuzione di script WSH/JScript. Gli utenti vanno formati a riconoscere i falsi aggiornamenti del browser — un pattern che non cambierà anche se TA569 verrà completamente smantellato, perché i copycats lo perpetueranno.

Per gli amministratori WordPress, le autorità hanno pubblicato linee guida specifiche: abilitare MFA sull’account amministratore, restringere l’accesso a /wp-admin tramite IP allowlisting, bloccare l’esecuzione di PHP nella directory uploads, mantenere aggiornati core, plugin e temi e monitorare l’integrità dei file con strumenti dedicati. Particolarmente importante è verificare la presenza di plugin sconosciuti o nascosti a livello di filesystem, che potrebbero sfuggire all’interfaccia di amministrazione.