informatica ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please log in.

Mini Shai-Hulud: TeamPCP compromette 160+ pacchetti npm e PyPI in un supply chain attack che ha colpito TanStack, Mistral AI e OpenAI


@Informatica (Italy e non Italy)
Tra il 11 e il 14 maggio 2026, il gruppo TeamPCP ha compromesso oltre 160 pacchetti npm e 2 PyPI in un supply chain attack di nuova generazione


Mini Shai-Hulud: TeamPCP compromette 160+ pacchetti npm e PyPI in un supply chain attack che ha colpito TanStack, Mistral AI e OpenAI


Tra il 11 e il 14 maggio 2026, un attore di minacce tracciato come TeamPCP ha sferrato uno dei supply chain attack più sofisticati mai documentati nell’ecosistema open source: oltre 160 pacchetti npm e 2 pacchetti PyPI compromessi, tra cui componenti del popolare framework TanStack, librerie di Mistral AI e UiPath, e il fondamentale pacchetto node-ipc con 822.000 download settimanali. L’operazione, ribattezzata “Mini Shai-Hulud” dai ricercatori di Wiz, ha colpito le pipeline di sviluppo di migliaia di organizzazioni — inclusi due dipendenti di OpenAI — e ha dimostrato come un singolo punto debole nelle GitHub Actions possa trasformarsi in una bomba a orologeria lungo tutta la catena del software.

L’innesco: tre vulnerabilità GitHub Actions in sequenza


Il vettore iniziale dell’attacco non è stato una vulnerabilità nei pacchetti stessi, ma nell’infrastruttura CI/CD che li gestisce. TeamPCP ha sfruttato una catena di tre vulnerabilità nelle GitHub Actions, secondo quanto ricostruito dai ricercatori di Wiz e Orca Security. L’attaccante ha creato un fork del repository TanStack/router, ha aperto una pull request che ha innescato un workflow pull_request_target — una tipologia di workflow che, a differenza di pull_request, viene eseguita con i permessi completi del repository originale anche per PR da fork esterni — e ha avvelenato la cache pnpm di GitHub Actions con un payload malevolo.

Una volta avvelenata la cache, il malware si è auto-propagato: ogni volta che il workflow legittimo veniva eseguito, invece di scaricare le dipendenze originali recuperava le versioni compromesse dalla cache infetta. Questo meccanismo di auto-propagazione — il “worm” di Mini Shai-Hulud — ha permesso la compromissione a cascata di tutti i namespace associati al progetto.

I 373 pacchetti compromessi: la portata dell’operazione


La scala dell’attacco è stata eccezionale. In totale, 373 versioni malevole sono state pubblicate su npm, distribuite su 169 nomi di pacchetti distinti. I namespace colpiti includono @tanstack (83 voci: router, start, devtools e adapter packages), @uipath (66 voci), @squawk (87 voci), @mistralai, @tallyui, @beproduct e numerosi pacchetti non con scope. Su PyPI, i pacchetti colpiti sono stati guardrails-ai 0.10.1 e mistralai 2.4.6.

La natura cross-namespace dell’attacco è significativa: le organizzazioni che utilizzavano librerie di vendor diversi (UiPath per l’automazione, Mistral AI per i modelli LLM, TanStack per il routing frontend) erano tutte vulnerabili nello stesso intervallo temporale, senza che esistesse un singolo punto di allerta evidente.

node-ipc: il payload più insidioso


Parallelamente alla compromissione via GitHub Actions, TeamPCP ha eseguito un attacco separato ma correlato contro node-ipc, un pacchetto fondamentale di Node.js per la comunicazione inter-processo con oltre 10 milioni di download settimanali. Tre versioni malevole (9.1.6, 9.2.3 e 12.0.1) sono state pubblicate il 14 maggio 2026 tramite un account maintainer compromesso attraverso una tecnica di account takeover mirata.

L’attaccante aveva re-registrato il dominio atlantis-software.net — scaduto il 10 gennaio 2025 — il 7 maggio 2026 tramite Namecheap, e aveva utilizzato la procedura standard di reset password di npm per ottenere i permessi di pubblicazione senza che il maintainer originale venisse avvisato. Le versioni malevole contenevano un payload da 80 KB, fortemente offuscato, che veniva iniettato come IIFE (Immediately Invoked Function Expression) alla fine del file node-ipc.cjs.

Cosa rubava il malware: 90+ categorie di credenziali


Una volta caricato tramite require('node-ipc'), il payload eseguiva silenziosamente un harvesting massiccio di credenziali: chiavi AWS, Azure e GCP, chiavi SSH private, token Kubernetes, configurazioni GitHub CLI, impostazioni di Claude AI e dell’IDE Kiro, stati Terraform, password di database, cronologia della shell e molto altro — oltre 90 categorie di segreti in totale. I dati venivano compressi in un archivio gzip e esfiltrati verso un server controllato dagli attaccanti che si mascherava da infrastruttura Azure.

Prima di procedere, il payload effettuava un fingerprint SHA-256 dell’ambiente, confrontandolo con un hash hardcoded assemblato da otto frammenti offuscati presenti nel codice — presumibilmente per evitare l’esecuzione in sandbox di analisi. Le versioni malevole sono rimaste attive sul registry per circa due ore prima del rilevamento e della rimozione da parte di npm. Qualsiasi progetto che abbia eseguito npm install o aggiornato automaticamente le dipendenze in quella finestra temporale deve essere considerato potenzialmente compromesso.

OpenAI e Mistral AI tra le vittime: le implicazioni sistemiche


OpenAI ha confermato che due dispositivi di dipendenti nel suo ambiente aziendale sono stati compromessi nell’attacco. L’azienda ha ingaggiato una società di incident response, ha ruotato i certificati di firma del codice per le applicazioni macOS e ha dichiarato di non aver trovato evidenze di accesso a dati utente, sistemi di produzione o proprietà intellettuale. Mistral AI ha visto le sue librerie ufficiali compromise, sollevando preoccupazioni immediate tra gli sviluppatori che le utilizzano per integrare capacità AI nei loro applicativi.

Il fatto che TeamPCP abbia preso di mira specificamente pacchetti di aziende AI leader — Mistral AI, e indirettamente OpenAI attraverso i suoi sviluppatori — non è casuale: i developer che lavorano con questi strumenti hanno tipicamente accesso a chiavi API di alto valore, ambienti cloud critici e codice sorgente sensibile. I repo di Mistral AI rubati sono stati successivamente messi in vendita da TeamPCP, confermando la doppia finalità dell’operazione: furto di credenziali e esfiltrazione di proprietà intellettuale.

Difendersi dalla nuova generazione di supply chain attack


L’attacco di Mini Shai-Hulud rappresenta una nuova classe di minaccia per la quale molte organizzazioni non sono ancora attrezzate. La compromissione non avviene attraverso vulnerabilità nel codice stesso, ma nell’infrastruttura di distribuzione. Alcune misure pratiche per i difensori includono il pinning delle versioni esatte dei pacchetti (evitando range semver come ^1.2.3 o ~1.2.3), l’utilizzo di un lockfile verificato e mantenuto nel controllo versione, l’auditing regolare delle dipendenze con strumenti come npm audit o Snyk, e la verifica dell’integrità dei pacchetti tramite hash SHA-512 dove disponibili.

Sul fronte CI/CD, è fondamentale limitare i permessi dei workflow GitHub Actions, evitare l’uso di pull_request_target con checkout del codice della PR, e implementare cache poisoning prevention attraverso la verifica dell’integrità della cache. Le organizzazioni che hanno eseguito build tra il 11 e il 14 maggio 2026 utilizzando i namespace colpiti dovrebbero effettuare una revisione completa dei secret esposti.

Indicatori di Compromissione (IoC)

# Mini Shai-Hulud / TeamPCP Supply Chain Attack - Maggio 2026
# Fonti: Wiz, Orca Security, Snyk, StepSecurity

# Pacchetti npm malevoli (esempi principali)
node-ipc: 9.1.6, 9.2.3, 12.0.1
@tanstack/router: versioni pubblicate 11-14 maggio 2026
@mistralai/mistralai: 2.4.6 (correlato)

# Pacchetti PyPI malevoli
guardrails-ai==0.10.1
mistralai==2.4.6

# Account maintainer compromesso (node-ipc)
npm user: atiertant (a.tiertant@atlantis-software.net)
Dominio re-registrato: atlantis-software.net (7 maggio 2026)

# Tecniche MITRE ATT&CK
T1195.001 - Supply Chain Compromise: Compromise Software Dependencies
T1059.007 - Command and Scripting Interpreter: JavaScript
T1552.001 - Unsecured Credentials: Credentials in Files
T1041     - Exfiltration Over C2 Channel (verso infrastruttura Azure-like)

# Indicatori comportamentali
- Processi Node.js che effettuano richieste HTTP inattese post-installazione
- Archivi gzip creati in directory temporanee durante npm install
- Chiamate a endpoint Azure non riconosciuti da processi build

# Verifica hash (node-ipc versioni legittime)
SHA-256 v9.1.5 legittima: verificare su https://registry.npmjs.org/node-ipc/9.1.5

Fonti: Wiz Blog, Orca Security, The Hacker News, BleepingComputer, OpenAI Blog

informatica ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please log in.

UAT-8616: il gruppo d’élite sfrutta il sesto zero-day Cisco SD-WAN e prende di mira governi europei e asiatici


@Informatica (Italy e non Italy)
Un threat actor altamente sofisticato, UAT-8616, sfrutta CVE-2026-20182 — vulnerabilità critica CVSS 10.0 nel Cisco Catalyst SD-WAN — per compromettere organizzazioni governative, diplomatiche e


UAT-8616: il gruppo d’élite sfrutta il sesto zero-day Cisco SD-WAN e prende di mira governi europei e asiatici


Un threat actor di altissimo livello, tracciato da Cisco Talos come UAT-8616, sta sfruttando attivamente una vulnerabilità critica nei controller Cisco Catalyst SD-WAN — la sesta zero-day sfruttata su questa piattaforma nel solo 2026. Con un CVSS di 10.0, la falla consente a un attaccante non autenticato di ottenere privilegi amministrativi completi su dispositivi SD-WAN esposti su internet, prendendo di mira settori governativi, diplomatici e della difesa in Europa e Asia Centrale.

La Sesta Zero-Day in Sei Mesi: CVE-2026-20182


Il 15 maggio 2026, la CISA (Cybersecurity and Infrastructure Security Agency) ha aggiunto CVE-2026-20182 al suo catalogo di vulnerabilità attivamente sfruttate (KEV — Known Exploited Vulnerabilities), imponendo alle agenzie federali civili statunitensi di applicare la patch entro il 17 maggio. La vulnerabilità risiede nel processo di handshake del controllo peering via protocollo DTLS sulla porta 12346 del Cisco Catalyst SD-WAN Controller e Manager.

In termini pratici, un attaccante remoto e non autenticato può autenticarsi come peer interno ad alto privilegio, bypassando completamente l’autenticazione e acquisendo controllo amministrativo sull’appliance bersaglio. Il punteggio massimo CVSS (10.0) riflette la semplicità di sfruttamento combinata alla gravità dell’impatto: nessuna credenziale, nessuna interazione utente richiesta.

Il Profilo di UAT-8616: Un Attore Sofisticato con Radici Profonde


Cisco Talos ha tracciato questa campagna sotto la denominazione UAT-8616, classificandolo con alta confidenza come un “highly sophisticated cyber threat actor”. Sebbene Talos non abbia ancora rilasciato un’attribuzione definitiva a uno stato-nazione specifico, diversi elementi indicativi emergono dall’analisi:

  • Longevità operativa: le prime tracce di attività malevola risalgono al 2023, almeno tre anni prima della divulgazione pubblica — segnale che il gruppo operava con una zero-day tenuta segreta per molto tempo.
  • Sovrapposizione con ORB network: l’infrastruttura di UAT-8616 si sovrappone a reti di relay operazionali (Operational Relay Boxes) precedentemente associate a operazioni di cyber-spionaggio di attori China-nexus, secondo quanto documentato da Mandiant/Google.
  • Target geopoliticamente selettivi: il profilo dei bersagli — governo, diplomazia, difesa in Europa e Asia Centrale — è coerente con operazioni di intelligence offensiva state-sponsored.
  • Connessione con endpoint Gamaredon (Aqua Blizzard): la CISA ha segnalato sovrapposizioni con endpoint già compromessi da Gamaredon, il gruppo russo legato all’FSB che storicamente prende di mira organizzazioni ucraine e dell’Europa orientale.


Anatomia dell’Attacco: Dal Bypass all’Esfiltrazione


Le tecniche post-compromissione documentate da Talos rivelano un playbook operativo sofisticato, progettato tanto per la persistenza quanto per l’evasione forense:

  • SSH key injection: aggiunta di chiavi SSH nei file authorized_keys per garantire accesso permanente anche dopo il reboot o il cambio di credenziali.
  • Escalation a root via CVE-2022-20775: sfruttamento di una tecnica di downgrade della versione software per scalare i privilegi fino a root.
  • Manipolazione NETCONF: modifica delle configurazioni di rete tramite il protocollo NETCONF per alterare il traffico o creare tunnel nascosti.
  • Creazione di account malevoli: creazione di utenti backdoor per accesso persistente.
  • Anti-forensics sistematico: cancellazione di log da syslog, wtmp, lastlog, bash_history e cli-history per coprire le tracce dell’intrusione.


Un Pattern Preoccupante: Sei Zero-Day in Sei Mesi


CVE-2026-20182 non è un caso isolato. Come documenta SecurityWeek, si tratta della sesta vulnerabilità zero-day sfruttata attivamente sulle piattaforme Cisco SD-WAN nel corso del 2026, un dato che solleva interrogativi profondi sulla sicurezza dell’infrastruttura di rete enterprise. Gli SD-WAN sono sistemi critici che gestiscono il traffico di rete tra sedi aziendali distribuite, data center e cloud — la loro compromissione offre all’attaccante una visibilità strategica sull’intera architettura di rete della vittima.

La tendenza è chiara: i dispositivi di rete edge — firewall, VPN concentrator, SD-WAN controller — sono diventati il principale vettore di accesso iniziale per i gruppi APT più sofisticati al mondo. A differenza degli endpoint tradizionali, questi dispositivi raramente eseguono soluzioni EDR e spesso hanno cicli di aggiornamento lenti nelle organizzazioni.

Implicazioni Geopolitiche e per i Difensori


Il targeting di settori governativi e della difesa in Europa e Asia Centrale suggerisce una campagna di cyber-spionaggio strategico. Le sovrapposizioni infrastrutturali con attori Russia-linked come Gamaredon/Aqua Blizzard complicano ulteriormente l’attribuzione, un fenomeno sempre più comune nelle operazioni moderne dove la condivisione di infrastrutture (ORB network) oscura deliberatamente le responsabilità.

Per i team di sicurezza, le priorità immediate sono chiare:

  • Patching urgente: applicare immediatamente le patch Cisco per CVE-2026-20182 su tutti i Catalyst SD-WAN Controller e Manager esposti.
  • Audit delle authorized_keys: verificare l’integrità dei file SSH authorized_keys su tutti i sistemi SD-WAN.
  • Revisione account: identificare e rimuovere eventuali account non autorizzati creati sui sistemi.
  • Log integrity check: data la tendenza del gruppo a cancellare i log, implementare forwarding immediato su SIEM centralizzato.
  • Network segmentation review: limitare l’accesso amministrativo ai controller SD-WAN tramite reti di gestione dedicate e isolate.


CVE e Riferimenti Tecnici

CVE-2026-20182 — Cisco Catalyst SD-WAN Controller / Manager
CVSS Score: 10.0 (Critico)
Tipo: Authentication Bypass
Vettore: DTLS porta 12346 (handshake peering)
Impatto: Accesso amministrativo non autenticato

CVE correlati campagna UAT-8616:
- CVE-2026-20127 (zero-day precedente, sfruttato da febbraio 2026)
- CVE-2022-20775 (privilege escalation, usato per escalation a root)

Indicatori di Compromissione (comportamentali):
- SSH keys non autorizzate in authorized_keys
- Account di sistema inattesi
- Assenza di voci nei log syslog/wtmp/lastlog (log wiping)
- Configurazioni NETCONF alterate
- Traffico anomalo su porta DTLS 12346

Fonti: Cisco Talos, CISA KEV, SecurityWeek, Help Net Security, Tenable, Dark Reading

informatica ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please log in.

Kazuar si evolve: Secret Blizzard (Turla) trasforma il suo backdoor storico in una botnet P2P modulare invisibile


@Informatica (Italy e non Italy)
Il gruppo russo Secret Blizzard (Turla/FSB) ha trasformato il malware Kazuar in una botnet peer-to-peer con tre moduli distinti (Kernel, Bridge, Worker) e 150 parametri di configurazione. La


Kazuar si evolve: Secret Blizzard (Turla) trasforma il suo backdoor storico in una botnet P2P modulare invisibile


Si parla di:
Toggle

Il gruppo russo Secret Blizzard, operativo per conto dell’FSB (Federal Security Service) russo e meglio conosciuto come Turla, ha trasformato il proprio storico malware Kazuar in una botnet peer-to-peer modulare, progettata per mantenere accessi persistenti e praticamente invisibili nelle reti governative. La rivelazione arriva da Microsoft Security, che il 14 maggio 2026 ha pubblicato un’analisi approfondita dell’architettura del malware — descrivendo quello che è a tutti gli effetti un salto evolutivo nella sofisticazione operativa di uno dei gruppi APT più longevi al mondo.

Da backdoor tradizionale a ecosistema P2P


Kazuar è attivo almeno dal 2017 ed è stato impiegato in decine di campagne di cyberspionaggio contro governi, ambasciate e organizzazioni della difesa in Europa, Asia Centrale e Ucraina. La versione analizzata da Microsoft nel 2026 rappresenta però un cambio di paradigma: il malware non è più un semplice backdoor controllato centralmente, ma un ecosistema distribuito composto da tre moduli distinti che collaborano per garantire resilienza, persistenza e stealth.

La riorganizzazione è eloquente: non ogni macchina compromessa comunica con il server di comando e controllo (C2). Invece, un unico nodo “leader” — eletto dinamicamente dal modulo Kernel tra i sistemi infetti presenti nella stessa rete o segmento di rete — assume il ruolo di proxy verso l’infrastruttura esterna. Gli altri nodi entrano in modalità “silent”, eliminando quasi completamente il traffico verso l’esterno e riducendo drasticamente la superficie di rilevamento per i team di incident response.

Architettura modulare: Kernel, Bridge e Worker


Microsoft descrive tre componenti fondamentali della nuova architettura Kazuar:

  • Modulo Kernel: È il coordinatore centrale. Gestisce i task, controlla gli altri moduli, elegge il nodo leader e orchestra le comunicazioni e il flusso di dati attraverso la botnet.
  • Modulo Bridge: Agisce come proxy tra il nodo leader Kernel e il server C2 remoto. Filtra e instrada il traffico, permettendo ulteriore separazione tra i sistemi compromessi e l’infrastruttura degli attaccanti.
  • Modulo Worker: È il componente operativo. Registra i tasti premuti (keylogging), aggancia gli eventi Windows, traccia i task, raccoglie informazioni di sistema, listing di file e dettagli MAPI — incluse caselle email di Exchange.

Questa separazione funzionale non è casuale: in caso di rilevamento di un Worker, i nodi Kernel restano inalterati e possono continuare a operare silenziosamente. L’architettura è progettata per sopravvivere a rimozioni parziali.

150 parametri di configurazione: granularità operativa senza precedenti


Uno degli aspetti più rilevanti della nuova versione è il sistema di configurazione esteso: Kazuar supporta ora più di 150 parametri che gli operatori possono personalizzare per ogni campagna o vittima specifica. Questi parametri controllano metodi di esecuzione e persistenza (scheduled task, servizi Windows, chiavi di registro), bypass di AMSI e ETW, timing dell’esfiltrazione e dimensione dei chunk di dati, process injection e tecniche di lateral movement, e protocolli di comunicazione multipli: HTTP, WebSocket ed Exchange Web Services (EWS).

L’uso di EWS per mascherare le comunicazioni C2 nel traffico legittimo di Exchange è particolarmente insidioso: in ambienti enterprise dove Exchange Server è ubiquo, questo canale risulta quasi impossibile da distinguere dal traffico normale senza ispezione profonda dei payload.

Targeting: governi, ambasciate e settore difesa in Europa e Ucraina


Secret Blizzard (alias Turla, Uroburos, Venomous Bear) è noto per campagne di spionaggio ad altissimo valore strategico. Le vittime documentate includono ministeri degli esteri, ambasciate diplomatiche, dipartimenti della difesa e organizzazioni governative in Europa Orientale, Asia Centrale e — con intensità crescente — Ucraina nel contesto del conflitto in corso.

L’evoluzione di Kazuar verso un’architettura P2P suggerisce che il gruppo abbia tratto lezione dalle operazioni di takedown condotte negli ultimi anni contro infrastrutture di malware centralizzate. La distribuzione del controllo rende un’eventuale disruption dell’infrastruttura C2 molto meno efficace: rimuovere il server C2 non smantella la botnet, poiché il leader può essere eletto nuovamente tra i nodi sopravvissuti.

Due righe per i difensori


Microsoft raccomanda di concentrare il rilevamento su indicatori comportamentali piuttosto che su signature statiche. I team di sicurezza dovrebbero monitorare attività IPC insolite tra processi non correlati, rilevare pattern di elezione del leader nella rete interna tramite comunicazioni laterali anomale, identificare esfiltrazione dati staged e frammentata con timing irregolare, e controllare accessi anomali a EWS da processi non di posta elettronica. Dato il targeting storico di Secret Blizzard su entità diplomatiche e governative europee, le organizzazioni in questi settori dovrebbero considerare una revisione urgente dei log di rete e degli endpoint.

Indicatori di Compromissione (IoC)

# Kazuar - Secret Blizzard (Turla) - Maggio 2026
# Fonte: Microsoft Security Blog, 14 maggio 2026

# Tecniche MITRE ATT&CK associate
T1574.001 - DLL Search Order Hijacking
T1055     - Process Injection
T1071.001 - Application Layer Protocol: Web Protocols (HTTP/WebSocket)
T1071.003 - Application Layer Protocol: Mail Protocols (EWS)
T1030     - Data Transfer Size Limits (staged exfiltration)
T1053.005 - Scheduled Task/Job (persistence)
T1562.001 - Impair Defenses: Disable/Modify Tools (AMSI/ETW bypass)

# Comportamenti anomali da monitorare
- Comunicazioni IPC anomale tra processi non correlati
- Accessi Exchange Web Services (EWS) da processi non di posta
- Traffico P2P laterale interno su porte non standard
- Esfiltrazione dati in chunk temporizzati verso IP non categorizzati
- Moduli .NET iniettati in processi di sistema legittimi

# Referenza completa IoC
https://www.microsoft.com/en-us/security/blog/2026/05/14/kazuar-anatomy-of-a-nation-state-botnet/

Fonti: Microsoft Security Blog, BleepingComputer, The Hacker News

informatica ha ricondiviso questo.

MiniPlasma: la patch del 2020 su Windows che non c’è mai stata o è sparita


@Informatica (Italy e non Italy)
Una vulnerabilità Windows corretta nel 2020 potrebbe non essere mai stata davvero risolta. Con MiniPlasma, il ricercatore Chaotic Eclipse dimostra che il vecchio PoC di Google Project Zero funziona ancora su sistemi Windows 11 aggiornati. Il caso evidenzia i

informatica ha ricondiviso questo.

Parallelamente, la nuova regolazione #UE sulle #VPN rischia di limitare #privacy e sicurezza online, mentre iniziative come i 1,2 milioni di euro a #KDE puntano a rafforzare sicurezza e infrastrutture di #Linux #Plasma, simbolo di un’alternativa più libera e aperta.

(2/2)

@informatica

bit.ly/4tKkJbY

informatica ha ricondiviso questo.

Fuga da #BigTech: sempre più persone cercano di uscire dalle grandi piattaforme per costruire un #web più decentralizzato e controllato dagli utenti. Kauffman e l’#IA mostrano come l’intelligenza artificiale stia dividendo il capitalismo in due sistemi, uno dominato dalle grandi aziende tech e l’altro ancora in costruzione.

(1/2)

@informatica

bit.ly/4tKkJbY

informatica ha ricondiviso questo.

DeepSeek e Huawei sfidano Nvidia: così la Cina prepara l’autosufficienza nell’intelligenza artificiale

Per vedere altri post come questo, segui la comunità @Informatica (Italy e non Italy)

Il nuovo modello di DeepSeek ottimizzato per i semiconduttori di Huawei rafforza la strategia cinese di sganciamento tecnologico dagli Stati Uniti. L'articolo

informatica ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

MCP, A2A e AG-UI: lo stack dei protocolli per agenti AI nel 2026
#tech
spcnet.it/mcp-a2a-e-ag-ui-lo-s…
@informatica


MCP, A2A e AG-UI: lo stack dei protocolli per agenti AI nel 2026


Nel 2026, chi sviluppa agenti AI si trova inevitabilmente a fare i conti con tre acronimi: MCP, A2A e AG-UI. La domanda più comune è: sono standard in competizione tra loro? Devo usarli tutti e tre? Quale mi serve davvero?

La risposta breve è che non competono affatto — si completano. Ciascuno risolve un problema diverso a un livello diverso dell’architettura degli agenti. Un’analogia utile: pensateli come TCP, HTTP e HTML nel web — protocolli che operano a strati diversi e insieme rendono possibile il funzionamento del sistema.

Il quadro d’insieme


Prima di entrare nel dettaglio, ecco una tabella riassuntiva:

ProtocolloCreato daConnetteRisponde alla domanda
MCPAnthropicAgente ↔ Strumenti e dati“Come fa il mio agente a usare i tool?”
A2AGoogle / Linux FoundationAgente ↔ Agente“Come parlano gli agenti tra di loro?”
AG-UICopilotKitAgente ↔ Interfaccia utente“Come comunica il mio agente con l’utente?”

MCP — Il layer degli strumenti

Il problema che risolve


Il vostro agente deve fare cose concrete: interrogare un database, chiamare un’API, leggere un file, cercare sul web. Prima di MCP, ogni integrazione era custom: codice ad hoc per ogni strumento, ogni framework, ogni modello. MCP standardizza tutto questo in un unico protocollo.

Come funziona


MCP usa un’architettura client-server basata su JSON-RPC 2.0. Il server MCP espone:

  • Tools: funzioni che il modello può invocare, con nome, descrizione e schema tipizzato degli input
  • Resources: dati in sola lettura che l’agente può consultare (schemi DB, file di configurazione)
  • Prompts: template riutilizzabili

Il client MCP — tipicamente integrato nel framework dell’agente — scopre queste capacità e le invoca per conto del modello. I transport sono flessibili: stdio per tool locali (subprocess), Streamable HTTP per deployment remoti in produzione.

Quando usarlo


Usate MCP ogni volta che il vostro agente deve interagire con sistemi esterni: database, API REST, file system, servizi cloud. Se state wrappando un’API esistente per renderla accessibile agli agenti, MCP è il protocollo giusto. L’ecosistema è già maturo: AWS fornisce server MCP open source per S3, DynamoDB, CloudWatch; sono disponibili server per GitHub, Slack, PostgreSQL e decine di altri servizi.

Quando NON usarlo


MCP non è pensato per la comunicazione tra agenti, né per aggiornare interfacce utente. Se avete un agente che deve delegare sotto-task a un altro agente specializzato, quello è territorio di A2A.

A2A — Il layer di collaborazione tra agenti

Il problema che risolve


Avete costruito più agenti specializzati: uno per la ricerca, uno per la generazione di codice, uno per la gestione dei deployment. Come farli collaborare su task complessi senza condividere stato interno, tool o prompt? A2A standardizza come gli agenti si scoprono, delegano task e si scambiano risultati.

Come funziona


A2A usa un modello client-server su HTTP con JSON-RPC 2.0 (e opzionalmente gRPC dalla v0.3). Il principio chiave è l’opacità: gli agenti non espongono i propri internals, pubblicizzano solo ciò che sanno fare.

I concetti fondamentali:

  • Agent Cards: documenti JSON ospitati su /.well-known/agent.json che descrivono nome, capacità (“skills”), tipi di input/output supportati e requisiti di autenticazione. Un biglietto da visita machine-readable.
  • Tasks: l’unità di lavoro. Un client invia un messaggio al remote agent, che crea un task con lifecycle: submitted → working → completed (o failed, canceled).
  • Interaction patterns: sincrono per task semplici, SSE (Server-Sent Events) per streaming su task lunghi, webhook per workflow veramente asincroni.


Quando usarlo


A2A brilla nei sistemi multi-agente dove gli agenti non devono condividere stato interno. Pattern comuni:

  • Un agente supervisor che delega a specialisti
  • Collaborazione cross-organizzazione (il vostro agente che interagisce con quello del vendor)
  • Setup multi-framework: un agente LangGraph che coordina un agente CrewAI — grazie all’opacità, non importa cosa c’è “dentro”


Quando NON usarlo


Per agenti singoli che devono solo chiamare tool, A2A aggiunge overhead non necessario. Se avete bisogno di accoppiamento stretto tra agenti (condivisione di memoria o stato), A2A non è lo strumento giusto.

AG-UI — Il layer dell’interfaccia utente

Il problema che risolve


I vostri agenti hanno bisogno di comunicare con gli utenti in tempo reale: messaggi incrementali, aggiornamenti di stato, handoff per l’approvazione umana. Prima di AG-UI, ogni team implementava questo in modo proprietario — WebSocket custom, polling, SSE artigianali.

Come funziona


AG-UI è un protocollo a eventi strutturati che collega il backend dell’agente con il frontend. Definisce un insieme standard di eventi (message chunks, tool calls, state updates, human-in-the-loop requests) che qualsiasi UI può consumare. È leggero — basato su SSE — e disaccoppiato dal framework dell’agente.

Quando usarlo


Ogni volta che il vostro agente ha una UI interattiva: chatbot, assistenti embedded, dashboard con feedback in tempo reale. Se invece l’agente è un job in background senza interazione utente (elaborazione batch, task schedulati), AG-UI aggiunge complessità inutile.

Come si combinano in pratica


Lo stack completo per un sistema agente enterprise tipico appare così:

┌─────────────────────────────────────┐
│           Interfaccia Utente        │
│         (React, Vue, ecc.)          │
└─────────────┬───────────────────────┘
              │ AG-UI (SSE events)
┌─────────────▼───────────────────────┐
│         Agente Principale           │
│    (LangGraph / CrewAI / custom)    │
│                                     │
│  ┌──────────┐    ┌───────────────┐  │
│  │  MCP     │    │     A2A       │  │
│  │ (tools)  │    │ (subagenti)   │  │
│  └──────────┘    └───────────────┘  │
└─────────────────────────────────────┘
         │                 │
    DB, API, File    Agenti Specializzati


Un agente principale riceve l’input dell’utente via AG-UI, chiama tool esterni tramite MCP (database, API), e se il task è complesso delega a sotto-agenti specializzati tramite A2A — che a loro volta possono usare MCP per i propri tool.

Lo stato dell’ecosistema nel 2026


MCP ha vinto il layer dei tool: è supportato da praticamente tutti i framework principali (LangChain, LlamaIndex, AutoGen, Semantic Kernel) e ha un ecosistema di centinaia di server pre-costruiti. A2A sta emergendo come standard per il layer di coordinamento e la Linux Foundation ne gestisce ora la governance insieme a MCP. AG-UI è più giovane ma sta guadagnando terreno rapidamente grazie all’integrazione con CopilotKit e framework React.

La combinazione dei tre è sempre più considerata il baseline atteso per deployment agente enterprise — come HTTP, TLS e OAuth sono diventati il baseline per i servizi web.

Conclusione


Se state iniziando a costruire agenti AI, ecco un percorso pragmatico:

  1. Iniziate con MCP — è maturo, ha un ecosistema enorme e copre la maggior parte dei casi d’uso con un singolo agente
  2. Aggiungete A2A quando avete più agenti specializzati che devono collaborare
  3. Integrate AG-UI solo se l’agente ha una UI interattiva che richiede aggiornamenti in tempo reale

La buona notizia è che questi protocolli sono progettati per coesistere: adottarli incrementalmente è la strategia giusta.


Fonte originale: The Agent Protocol Stack: MCP vs. A2A vs. AG-UI (DZone) — approfondito con ulteriori riferimenti da Dev.to e subhadipmitra.com.


informatica ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

Zombie API: il rischio nascosto nelle tue vecchie integrazioni (e come eliminarlo)
#tech
spcnet.it/zombie-api-il-rischi…
@informatica


Zombie API: il rischio nascosto nelle tue vecchie integrazioni (e come eliminarlo)


Tre anni fa il vostro team ha costruito un’integrazione di pagamento. Funzionava perfettamente. Poi siete passati a una soluzione migliore, avete rilasciato la nuova versione e tutti si sono dedicati al progetto successivo. Nessuno ha aperto un ticket formale per disattivare il vecchio endpoint. Nessuno ci ha nemmeno pensato.

Quell’endpoint probabilmente sta ancora girando adesso. Benvenuti nel problema delle Zombie API.

Cosa sono le Zombie API


Una Zombie API è un’interfaccia applicativa che rimane accessibile ma che l’organizzazione non monitora più, non aggiorna e non supporta ufficialmente. Continua a funzionare in background, risponde alle richieste, restituisce dati — ma nessuno la presidia. Può trattarsi di:

  • Un’API versione 1 dimenticata dopo il lancio della v2
  • Un endpoint di test mai rimosso dall’ambiente di produzione
  • Un’integrazione con un sistema esterno deprecato ma mai formalmente chiusa
  • Un servizio interno esposto durante uno sprint e poi lasciato lì

La differenza rispetto alle Shadow API è sottile ma importante: le Shadow API sono endpoint mai documentati ufficialmente (spesso creati da sviluppatori senza seguire i processi aziendali); le Zombie API sono endpoint che erano ufficiali, ma sono sopravvissute alla loro utilità.

Perché le Zombie API sono pericolose

1. Controlli di sicurezza obsoleti


Le Zombie API nascono in un’epoca diversa. Possono ancora utilizzare meccanismi di autenticazione deboli come API key in plaintext, HTTP Basic Auth senza HTTPS, o sessioni senza scadenza. Non hanno mai ricevuto le patch per le vulnerabilità scoperte negli anni successivi alla loro creazione. I framework e le librerie che usano sono datati, spesso con CVE note e non risolte.

# Esempio: vecchio endpoint con autenticazione debole
GET /api/v1/payments?user_id=1234&token=abc123
# Nessuna validazione token server-side, nessun rate limiting,
# nessun log di accesso attivo


2. Assenza di monitoraggio


Gli endpoint zombie non compaiono nei dashboard di osservabilità, non generano alert, non vengono inclusi nei penetration test periodici. Eppure continuano a restituire dati: record di clienti, token di sessione, informazioni di sistema. Le violazioni che li coinvolgono possono passare inosservate per mesi.

3. Superficie di attacco invisibile


Dal punto di vista del team di sicurezza, l’endpoint non esiste. Dal punto di vista di un attaccante, invece, è perfettamente raggiungibile. Gli scanner automatici — e nel 2026 sempre più spesso gli agenti AI autonomi — individuano questi endpoint attraverso pattern comuni: /api/v1/, /api/legacy/, file Swagger dimenticati, entry in file robots.txt.

4. Il vettore degli agenti AI


Una dimensione nuova nel 2026: i sistemi agentic AI che chiamano autonomamente API per completare task possono scoprire e interagire con endpoint zombie che il team di sicurezza umano non ha mai pensato di inventariare. Un agente che esegue fuzzing automatico o che segue link nei file di documentazione può “risvegliare” endpoint che nessuno controllava da anni.

Come identificare le Zombie API nel vostro ambiente

Inventario tramite discovery automatica


Il primo passo è vedere ciò che non si riesce a vedere. Strumenti come OWASP ZAP, Burp Suite, o soluzioni enterprise come Noname Security, Salt Security e Traceable AI possono scansionare il traffico di rete per identificare endpoint che ricevono richieste ma non compaiono nella documentazione ufficiale.

# Con curl e grep: cerca pattern di API versionate nei log
grep -E "/api/v[0-9]+/" /var/log/nginx/access.log |   awk '{print $7}' | sort | uniq -c | sort -rn | head -50


Analisi del codice sorgente


Una scansione statica del codice può estrarre tutti i route definiti nell’applicazione e confrontarli con quelli registrati nel gateway API. La differenza è la lista candidata di zombie (o shadow).

# Esempio con grep per trovare route Express.js
grep -rE "app\.(get|post|put|delete|patch)\s*\(" ./src   | grep -oP "(?

Analisi del traffico reale


Anche se un endpoint non viene più mantenuto, potrebbe ancora ricevere traffico — da client legacy, da integrazioni di partner non aggiornate, o da attaccanti che lo scandagliano. Analizzare i log di accesso degli ultimi 90-180 giorni rivela endpoint “morti” che in realtà rispondono ancora.

Come mitigare il rischio

Governance del ciclo di vita delle API


La soluzione strutturale è implementare un API lifecycle management formale, con quattro fasi chiare:

  1. Active: l’API è in produzione, monitorata e manutenuta
  2. Deprecated: l’API funziona ancora ma è stata annunciata la dismissione. I client ricevono header Deprecation e Sunset in ogni risposta
  3. Sunset: la data di dismissione è imminente, le richieste restituiscono warning espliciti
  4. Retired: l’endpoint è stato disattivato, risponde con 410 Gone


# Header HTTP di deprecazione (RFC 8594)
HTTP/1.1 200 OK
Deprecation: Sat, 31 Dec 2025 23:59:59 GMT
Sunset: Sat, 30 Jun 2026 23:59:59 GMT
Link: <https://api.example.com/v2/payments>; rel="successor-version"


Applicate il principio del minimo privilegio anche alle API


Le API che non sono più in uso attivo non dovrebbero avere accesso ai sistemi di produzione. Prima di decommissionare formalmente, rimuovete le credenziali, revocate i token di accesso e isolate l’endpoint dalla rete interna.

Automatizzate il testing di sicurezza su tutto l’inventario


Il penetration test periodico deve includere anche gli endpoint “vecchi”. Configurate scanner DAST (Dynamic Application Security Testing) per coprire l’intero inventario API, non solo gli endpoint documentati nella versione corrente.

# Esempio con OWASP ZAP via CLI
docker run -t owasp/zap2docker-stable zap-api-scan.py   -t https://api.example.com/api/v1/openapi.yaml   -f openapi   -r zap-report.html


Risk scoring degli endpoint


Non tutti gli endpoint zombie hanno lo stesso livello di rischio. Prioritizzate in base a:

  • Metodo di autenticazione (nessuna > API key > OAuth 2.0)
  • Sensibilità dei dati esposti (PII, dati finanziari, credenziali)
  • Esposizione a traffico esterno vs. solo interno
  • Presenza di vulnerabilità note nel framework usato
  • Volume e origine del traffico recente


Un piano d’azione in tre settimane


Per team che vogliono affrontare il problema in modo pragmatico:

Settimana 1 — Discovery: Eseguite una scansione completa del traffico degli ultimi 90 giorni. Estraete tutti gli endpoint dal codice sorgente. Confrontate con il registro ufficiale dell’API gateway.

Settimana 2 — Triage: Per ogni endpoint non documentato, determinate se è un’API shadow (mai documentata) o zombie (precedentemente documentata). Applicate il risk scoring. Identificate i proprietari originali tramite git blame o cronologia dei ticket.

Settimana 3 — Remediation: Gli endpoint ad alto rischio vanno disabilitati immediatamente. Per quelli con traffico ancora attivo, notificate i client e stabilite una data di sunset. Implementate il processo di governance per prevenire il problema in futuro.

Conclusione


Le Zombie API non sono un problema teorico. Sono un debito tecnico e di sicurezza reale, spesso invisibile, che cresce silenziosamente ad ogni rilascio. Con l’aumento dei sistemi agentic AI che interagiscono autonomamente con le API, il rischio di “risvegliare” questi endpoint aumenta ulteriormente.

La buona notizia è che il problema è risolvibile con processi ben definiti: discovery sistematico, governance del ciclo di vita, e testing automatizzato su tutto l’inventario — non solo sulla versione corrente dell’API.

Non aspettate che sia un attaccante a scoprire cosa avete dimenticato.


Fonte originale: The “Zombie API” Attack: Why Your Old Integrations Are Your Biggest Security Risk (DZone) — approfondito con riferimenti da Salt Security, GetAstra e Checkmarx.


informatica ha ricondiviso questo.

Taiwan è la chiave per il dominio dell’AI. Report Wsj

Per vedere altri post come questo, segui la comunità @Informatica (Italy e non Italy)

Come e perché Taiwan è diventata il centro fisico della filiera produttiva dell’intelligenza artificiale. L'approfondimento del Wall Street Journal tratto dalla rassegnahttps://www.startmag.it/innovazione/taiwan-e-la-chiave-per-il-dominio-dellai-report-wsj/

informatica ha ricondiviso questo.

L’adozione dell’IA da parte di Meta sta rendendo infelici i suoi dipendenti. Report Nyt

Per vedere altri post come questo, segui la comunità @Informatica (Italy e non Italy)

Meta sta introducendo sistemi di monitoraggio del lavoro dei dipendenti per addestrare i propri modelli di intelligenza artificiale mentre accelera la trasformazione aziendale verso l’IA tra

informatica ha ricondiviso questo.

Con l'aiuto di Palantir, gli agenti dell'ICE hanno a disposizione sui loro iPhone una lista di 20 milioni di persone

L'utilizzo dei sistemi Palantir da parte dell'Immigration and Customs Enforcement (ICE) significa che i funzionari dell'agenzia hanno di fatto a disposizione sui propri iPhone un elenco di 20 milioni di persone, aumentando la velocità con cui l'ICE può individuare le abitazioni da perquisire e le persone da arrestare

404media.co/ice-agents-have-li…

@informatica

informatica ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please log in.

The Gentlemen smascherati: quando il secondo gruppo ransomware al mondo diventa la vittima


@Informatica (Italy e non Italy)
Il backend del gruppo ransomware-as-a-service The Gentlemen è stato violato e i dati interni pubblicati. Check Point Research ha analizzato il leak, rivelando struttura organizzativa, identità dell'amministratore, tattiche di


The Gentlemen smascherati: quando il secondo gruppo ransomware al mondo diventa la vittima


C’è una certa ironia nel vedere un gruppo ransomware diventare esso stesso vittima di una violazione dei dati. Il 4 maggio 2026, gli operatori di The Gentlemen — il secondo gruppo ransomware più attivo al mondo nel 2026 con oltre 400 vittime pubbliche — hanno dovuto ammettere sui forum underground che il loro database backend era stato compromesso. Check Point Research ha ottenuto una porzione di quei dati prima che venissero rimossi, producendo uno dei dossier più dettagliati mai pubblicati sull’anatomia interna di un’organizzazione RaaS moderna.

L’ascesa fulminante di un gruppo che usava l’AI per sviluppare ransomware


The Gentlemen è emerso nel panorama del cybercrime organizzato con una velocità insolita. Nei soli primi mesi del 2026 ha rivendicato oltre 240 attacchi, raggiungendo il secondo posto globale per numero di vittime secondo il Q1 2026 Ransomware Report di Check Point Research. Una crescita che non è casuale: gli analisti hanno documentato l’uso sistematico di assistenti AI per accelerare lo sviluppo del ransomware, riducendo drasticamente i tempi tra ideazione e deployment dei payload.

Il modello operativo è quello classico del Ransomware-as-a-Service: un nucleo di operatori gestisce la piattaforma, la crittografia, la negoziazione e l’infrastruttura, mentre affiliati terzi si occupano dell’accesso iniziale e del deploy nei sistemi delle vittime. Ciò che distingue The Gentlemen è la sofisticazione organizzativa e la velocità con cui ha scalato le operazioni.

La violazione: come un provider di hosting ha esposto tutto


La compromissione è stata possibile attraverso il provider di hosting 4VPS, utilizzato dal gruppo per gestire parti della propria infrastruttura backend. Una scelta operativa che si è rivelata fatale: quando 4VPS è stato compromesso, con esso è caduta anche la protezione dei database di The Gentlemen. L’annuncio è arrivato dai criminali stessi sui forum underground il 4 maggio 2026 — una mossa inusuale che testimonia quanto grave fosse la situazione.

Check Point Research è riuscita a recuperare una porzione significativa del database prima della rimozione. Il materiale ottenuto include chat interne tra operatori, roster organizzativi, trascrizioni di negoziazioni con le vittime, discussioni sugli strumenti e documentazione sulle infrastrutture utilizzate. Un tesoro informativo che i ricercatori hanno condiviso con le forze dell’ordine, con un’indagine in corso.

Anatomia di una gang: l’organigramma esposto


Il leak ha rivelato che il gruppo è gestito da circa nove operatori nominati, organizzati attorno a un singolo amministratore identificato con gli alias zeta88 e hastalamuerte. Questo profilo non è quello di un principiante: si tratta di un ex affiliato del programma ransomware Qilin, che ha imparato il mestiere sotto un’organizzazione consolidata prima di costruire una struttura concorrente. Una progressione di carriera nel crimine organizzato digitale che rispecchia schemi già visti con altre gang.

L’amministratore non si limita alla gestione della piattaforma, ma partecipa personalmente agli eventi di cifratura — un livello di coinvolgimento diretto insolito per gruppi di questa dimensione, dove solitamente il livello apicale delega completamente le operazioni tattiche agli affiliati. I log di chat mostrano un’organizzazione gerarchica con ruoli definiti: chi gestisce le trattative, chi monitora l’infrastruttura C2, chi coordina gli affiliati.

L’arsenale tecnico: SystemBC, GPO deployment e supply chain pivot


Dal punto di vista tecnico, il report di Check Point descrive una catena di attacco matura. Il punto di ingresso osservato in almeno un incident response tracciato è un Domain Controller già compromesso con privilegi Domain Admin. Da questa posizione, gli attaccanti eseguono una ricognizione sistematica della rete, utilizzando strumenti open-source come gogo per lo scanning automatizzato, validano le credenziali su tutti i sistemi raggiungibili e preparano il terreno per il deploy del payload.

Lo strumento chiave per la fase di persistenza e tunneling è SystemBC, un proxy malware che stabilisce tunnel SOCKS5 cifrati (RC4) verso il server C2 e consente il download e l’esecuzione di payload aggiuntivi, sia su disco che iniettati direttamente in memoria. Un C2 server SystemBC analizzato da Check Point ha rivelato un botnet di oltre 1.570 vittime, con un profilo di infezione orientato prevalentemente verso ambienti corporate.

Il deployment finale del ransomware avviene tramite Group Policy Object (GPO): il binario viene configurato per eseguirsi su tutti i sistemi domain-joined durante il refresh delle policy, producendo un evento di cifratura quasi simultaneo sull’intero dominio — massimizzando il danno e minimizzando la finestra di risposta per i difensori.

Particolarmente rilevante è un attacco documentato nell’aprile 2026 contro una software consultancy britannica: dopo aver violato questa azienda, The Gentlemen ha utilizzato i dati rubati — documentazione infrastrutturale, credenziali, informazioni sugli accessi dei clienti — per condurre un attacco successivo contro uno dei clienti della consultancy in Turchia. Un caso concreto di supply chain pivot che dimostra come il valore di un’intrusione non si misuri solo nei dati esfiltrati, ma nei vettori di attacco secondari che abilita.

Due righe per i difensori: cosa fare dopo questa disclosure


La violazione di The Gentlemen è un evento raro ma istruttivo. Il leak rivela tattiche, procedure e persino identità che possono supportare attività di threat intelligence proattiva. Alcuni elementi pratici: monitorare le connessioni SOCKS5 non autorizzate verso IP esterni; implementare alert su modifiche ai GPO che includono eseguibili non firmati; verificare l’integrità dei Domain Controller come primo indicatore di compromissione avanzata; e applicare il principio del minimo privilegio per limitare il blast radius nel caso di compromise di un affiliato o fornitore.

Check Point ha rilasciato regole YARA per il rilevamento basato su firma del ransomware di The Gentlemen. Per i team SOC, l’integrazione di questi indicatori nelle piattaforme SIEM/SOAR è raccomandata con priorità alta, data la velocità con cui il gruppo ha dimostrato di scalare le operazioni.

Indicatori di Compromissione (IoC)

# The Gentlemen Ransomware - IoC e TTPs
# Fonte: Check Point Research (maggio 2026)
## Tecniche MITRE ATT&CK
T1078 - Valid Accounts (credenziali rubate per lateral movement)
T1021.002 - Remote Services: SMB/Windows Admin Shares
T1484.001 - Group Policy Modification (GPO-based ransomware deployment)
T1090.001 - Proxy: Internal Proxy (SystemBC SOCKS5 tunneling)
T1486 - Data Encrypted for Impact
T1005 - Data from Local System
T1059 - Command and Scripting Interpreter
## SystemBC C2 Communication
Protocollo C2: custom RC4-encrypted SOCKS5
Botnet noto: 1.570+ vittime identificate da singolo C2 server
Caratteristica: payload iniettati in-memory per evasione AV
## Indicatori comportamentali
- Presenza di gogo scanner eseguito da account privilegiati
- Modifiche a GPO esistenti o creazione di nuovi GPO con executables
- Connessioni SOCKS5 in uscita da workstation non-server
- Autenticazioni a cascata originate da Domain Controller
  (pattern: failed auth → successful auth su multipli host)
## Operatore
Alias noti: zeta88, hastalamuerte
Background: ex affiliato Qilin ransomware
Infrastruttura: 4VPS hosting provider (compromesso maggio 2026)
## Nota
# YARA rules disponibili presso Check Point Research:
# https://research.checkpoint.com/2026/thus-spoke-the-gentlemen/

informatica ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please log in.

Ghostwriter colpisce il governo ucraino con PDF georeferenziati, PicassoLoader e Cobalt Strike


@Informatica (Italy e non Italy)
Il gruppo bielorusso Ghostwriter (FrostyNeighbor) ha lanciato una nuova campagna di spear-phishing contro enti governativi e militari ucraini, utilizzando PDF-esca che impersonano Ukrtelecom con geofencing per eludere il


Ghostwriter colpisce il governo ucraino con PDF georeferenziati, PicassoLoader e Cobalt Strike


A meno di ventiquattr’ore dalla pubblicazione del report ESET, emerge l’ennesima prova che il conflitto russo-ucraino si combatte su due fronti: quello fisico e quello cibernetico. Il gruppo Ghostwriter — noto anche come FrostyNeighbor, UNC1151, Storm-0257 e White Lynx — ha intensificato le proprie operazioni contro le istituzioni di Kiev, adottando una catena d’attacco sempre più sofisticata che combina phishing mirato, geofencing intelligente e payload a più stadi. La notizia, pubblicata il 14 maggio 2026 da The Hacker News sulla base della ricerca ESET, arriva mentre le operazioni cinetiche nel conflitto rimangono attive.

Chi è Ghostwriter / FrostyNeighbor


Ghostwriter è un APT attivo almeno dal 2016, ritenuto allineato con i servizi d’intelligence bielorussi. Nel corso degli anni ha condotto sia operazioni di cyberspionaggio che campagne di influenza — disinformazione, hack-and-leak, manipolazione di contenuti — contro Ucraina, Polonia, Lituania ed Estonia. ESET lo traccia con il moniker FrostyNeighbor; altri vendor lo conoscono come PUSHCHA, TA445, UAC-0057 o Umbral Bison. Il gruppo ha dimostrato una notevole capacità di adattamento: ogni campagna aggiorna strumenti e metodi di consegna per sfuggire ai sistemi di detection.

La nuova catena d’attacco: geofencing e PDF-esca


Le attività osservate da marzo 2026 evidenziano un salto qualitativo rispetto alle campagne precedenti. Il vettore iniziale è uno spear-phishing con allegato PDF che impersona la società di telecomunicazioni ucraina Ukrtelecom — un mittente di apparente legittimità per qualsiasi funzionario governativo di Kiev.

La caratteristica tecnica più rilevante è il geofencing lato server: quando il destinatario apre il PDF e clicca sul link incorporato, il server degli attaccanti verifica l’indirizzo IP del richiedente. Se l’IP non corrisponde a una geolocalizzazione ucraina, il server restituisce un documento PDF benigno e inoffensivo. Questa tecnica rende l’analisi in sandbox — tipicamente eseguita da infrastrutture cloud non ucraine — completamente inefficace, poiché l’analista riceverà sempre il file pulito.

Catena d’infezione a tre stadi


Per le vittime che superano il controllo geografico, il link nel PDF scarica un archivio RAR contenente un payload JavaScript. L’esecuzione di questo script avviene in parallelo su due binari:

  • Visualizzazione del documento-esca: viene aperto un file lure convincente per mantenere la credibilità dell’allegato originale.
  • Lancio di PicassoLoader: il downloader JavaScript viene eseguito in background, avviando il secondo stadio dell’attacco.

PicassoLoader, già noto dall’arsenale di Ghostwriter, svolge una funzione cruciale di fingerprinting e profilazione dell’host: raccoglie informazioni sul sistema (hostname, utente, sistema operativo, processi attivi, configurazione di rete) e le trasmette all’infrastruttura C2 degli attaccanti ogni 10 minuti. Questa telemetria consente agli operatori di valutare manualmente se la vittima è di interesse strategico.

Solo in caso di risposta affermativa da parte degli operatori, viene inviato un terzo stadio: un dropper JavaScript che installa il Cobalt Strike Beacon — il framework di post-exploitation preferito dagli APT di ogni nazionalità, qui usato per stabilire accesso persistente, esfiltrare dati e muoversi lateralmente nella rete della vittima.

Targeting selettivo: militare, difesa, governo


Secondo ESET, il targeting principale si concentra su organizzazioni militari, del settore difesa e governative in Ucraina. In Polonia e Lituania la campagna mostra un profilo vittimologico più ampio, includendo anche manifatturiero, healthcare, logistica e governo. Questa distinzione suggerisce che in Ucraina le operazioni abbiano un obiettivo di intelligence preciso — raccolta di informazioni militari e governative strategiche — mentre altrove Ghostwriter opera con una rete più larga, probabilmente per mantenere accesso a lungo termine in ottica NATO.

Il contesto più ampio: Gamaredon e BO Team


Le rivelazioni su FrostyNeighbor si inseriscono in un panorama di operazioni cyber parallele nel teatro ucraino. Contestualmente, il gruppo russo Gamaredon — attivo con campagne di spear-phishing contro istituzioni statali ucraine dal settembre 2025 — sta distribuendo GammaDrop e GammaLoad tramite archivi RAR che sfruttano la vulnerabilità CVE-2025-8088. HarfangLab descrive Gamaredon come un attore non sofisticato ma straordinariamente persistente, con un tempo operativo e una scala d’attacco difficilmente eguagliabili.

Sul fronte opposto, il gruppo filoukraino BO Team (alias Black Owl) starebbe collaborando con Head Mare (PhantomCore) in attacchi contro organizzazioni russe, impiegando backdoor come BrockenDoor, ZeronetKit e il nuovo ZeroSSH — un backdoor Go-based capace di stabilire canali SSH inversi e di compromettere anche sistemi Linux.

Indicatori di Compromissione

# Tattiche, Tecniche e Procedure (TTPs) - Ghostwriter / FrostyNeighbor (Marzo 2026)
## Vettore iniziale
- Spear-phishing con allegato PDF
- Lure document: impersonificazione Ukrtelecom
## Tecniche di evasione
- Geofencing IP lato server (solo IP ucraini ricevono payload malevolo)
- Anti-sandbox tramite user-agent check lato server
## Payload chain
1. PDF → link → server geofenzato
2. Archivio RAR → payload JavaScript
3. JavaScript → PicassoLoader (JavaScript variant)
4. PicassoLoader → fingerprint host (ogni 10 min → C2)
5. [Operatore approva] → JavaScript dropper → Cobalt Strike Beacon
## Malware families
- PicassoLoader (JavaScript variant, nuova versione 2026)
- Cobalt Strike Beacon
## Targeting primario
- Organizzazioni militari ucraine
- Settore difesa ucraino  
- Enti governativi ucraini
- Target secondari: Polonia, Lituania (industria, healthcare, logistica)
## Riferimenti
- ESET Research: FrostyNeighbor report, maggio 2026
- Tracking alias: UNC1151, Storm-0257, TA445, UAC-0057, PUSHCHA, White Lynx, Umbral Bison

Due righe per i difensori


La sofisticazione del geofencing rende inutili molte tecniche di sandboxing tradizionale. I team di difesa ucraini e dei paesi NATO nel mirino dovrebbero adottare le seguenti contromisure. Innanzitutto, simulare il download dei link presenti in PDF sospetti utilizzando proxy IP con geolocalizzazione ucraina, in modo da bypassare il filtro geografico e ottenere il payload reale. In secondo luogo, monitorare le connessioni HTTP/HTTPS in uscita ogni 10 minuti verso IP non noti, potenziale segnale di PicassoLoader in fase di beaconing. In terzo luogo, applicare una politica zero-trust sull’esecuzione di JavaScript tramite applicazioni utente: la catena d’infezione si basa interamente su JS. Infine, formare il personale governativo e militare a riconoscere le impersonificazioni di fornitori di servizi (come Ukrtelecom) come vettore di phishing ad alta credibilità.

Il report ESET sintetizza efficacemente la sfida: “FrostyNeighbor rimane un threat actor persistente e adattivo, con un elevato livello di maturità operativa. Il payload viene consegnato solo dopo una validazione lato server che combina controlli automatizzati con la validazione manuale degli operatori”. Una minaccia ibrida — tecnologica e umana — che richiede una risposta altrettanto ibrida.


informatica ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

Microsoft DSC v3.2.0: nuove risorse Windows, version pinning e integrazione Bicep
#tech
spcnet.it/microsoft-dsc-v3-2-0…
@informatica


Microsoft DSC v3.2.0: nuove risorse Windows, version pinning e integrazione Bicep


Cos’è Microsoft DSC v3 e perché è importante


Microsoft Desired State Configuration (DSC) è uno strumento di gestione della configurazione che permette di descrivere come deve essere configurato un sistema Windows o Linux — quali servizi devono essere in esecuzione, quali regole firewall applicare, quali funzionalità installare — e di applicare o verificare automaticamente quella configurazione. Con DSC v3, Microsoft ha riscritto l’engine da zero rispetto alla versione 2.x integrata in PowerShell, separando nettamente il motore DSC dai moduli PowerShell e aprendo la strada al supporto multi-piattaforma e multi-linguaggio.

Il 29 aprile 2026, il team PowerShell ha annunciato la General Availability di DSC v3.2.0. Questa release porta con sé risorse Windows native, l’integrazione sperimentale con Bicep via gRPC, il version pinning, un linguaggio di espressioni più ricco e miglioramenti agli adapter PowerShell. Vediamo in dettaglio cosa cambia per i sistemisti e gli amministratori di sistema che adottano DSC nei loro ambienti.

Come installare DSC v3.2.0


La modalità di installazione più semplice è tramite WinGet:

winget install --id Microsoft.DSC --version 3.2.0

In alternativa è disponibile un pacchetto MSIX e un archivio ZIP per ambienti disconnessi o air-gapped. Il pacchetto ZIP è necessario per le risorse OptionalFeatureList e FeatureOnDemandList che, per il momento, non sono incluse nel pacchetto MSIX.

Nuove risorse Windows built-in


Una delle novità più attese di DSC v3.2.0 è l’espansione significativa delle risorse Windows native, ovvero risorse incluse direttamente nel pacchetto DSC e utilizzabili senza installazioni aggiuntive.

Le nuove risorse disponibili sono le seguenti:

  • Microsoft.Windows/Service — gestione dei servizi Windows (stato, tipo di avvio, account di esecuzione)
  • Microsoft.Windows/OptionalFeatureList — gestione delle funzionalità opzionali di Windows
  • Microsoft.Windows/FeatureOnDemandList — gestione delle Features on Demand (FoD)
  • Microsoft.Windows/FirewallRuleList — gestione delle regole del Windows Firewall
  • Microsoft.OpenSSH.SSHD/sshd_config — gestione dell’intera configurazione del server SSH
  • Microsoft.OpenSSH.SSHD/Subsystem e SubsystemList — gestione dei sottosistemi SSH
  • Microsoft.OpenSSH.SSHD/Windows — configurazione Windows-specifica del server SSH (es. shell predefinita)

Un esempio pratico: per assicurarsi che il servizio Print Spooler sia disabilitato (pratica comune per ridurre la superficie d’attacco), basta ora scrivere:

$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
resources:
  - name: DisabilePrintSpooler
    type: Microsoft.Windows/Service
    properties:
      name: spooler
      startType: disabled
      state: stopped

Version pinning: configurazioni stabili e riproducibili


Una delle criticità di DSC v2 era la mancanza di un meccanismo affidabile per legare una configurazione a una specifica versione delle risorse. In ambienti enterprise con molti server e deployment automatizzati, una risorsa aggiornata poteva cambiare comportamento inaspettatamente.

DSC v3.2 risolve questo problema introducendo il version pinning sia a livello di documento di configurazione che a livello di singola risorsa. È possibile fissare la versione di DSC richiesta con la direttiva version e la versione di ogni risorsa con il campo requireVersion, usando la stessa sintassi semantica di npm/nuget:

$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
directives:
  version: '=3.2.0'          # Questa configurazione richiede esattamente DSC 3.2.0
resources:
  - name: os
    type: Microsoft/OSInfo
    requireVersion: '^1.0'   # Versioni >= 1.0.0 e =1.0.0, 

Se sul sistema non è disponibile una versione compatibile della risorsa, DSC solleva un errore esplicito invece di procedere in silenzio con una versione incompatibile. Questo rende le configurazioni DSC molto più affidabili nei pipeline CI/CD.

Supporto –what-if sulle singole risorse


Il flag --what-if esiste già da versioni precedenti per il comando dsc config set, ma era limitato all’esecuzione dell’intera configurazione. Con DSC v3.2, l’operazione di preview è disponibile anche sul comando dsc resource set, permettendo di testare il comportamento di una singola risorsa prima di applicarla:

dsc resource set --what-if \
  --resource Microsoft.Windows/Service \
  --input '{ "name": "spooler", "startType": "disabled" }'

Questo è particolarmente utile in fase di sviluppo di nuove risorse o durante troubleshooting di configurazioni complesse.

Integrazione sperimentale con Bicep via gRPC


La novità più ambiziosa di questa release è l’introduzione di un server gRPC in DSC, che permette a Bicep di orchestrare direttamente le risorse DSC senza passare per Azure Resource Manager (ARM). L’estensione dsc-bicep-ext è ora inclusa nel pacchetto MSIX e disponibile nel PATH di sistema.

In pratica, questo significa che sarà possibile scrivere configurazioni DSC nella sintassi Bicep, sfruttando il tooling e le funzionalità del linguaggio (modularità, parametri tipizzati, linting) per gestire la configurazione di sistema. L’integrazione è attualmente marcata come sperimentale, ma rappresenta una direzione strategica importante: avvicinare la gestione della configurazione di sistema agli strumenti Infrastructure-as-Code già adottati dagli ambienti Azure.

Miglioramenti al linguaggio di espressione


I documenti di configurazione DSC v3.2 supportano ora un linguaggio di espressione più ricco, che riprende in parte la sintassi ARM/Bicep:

  • Lambda expressions con le funzioni map() e filter()
  • Funzioni dataUri() e dataUriToString() per la gestione di contenuti encodati
  • Utilizzo di reference() all’interno di loop copy
  • secret() per il recupero di segreti a runtime tramite estensioni dedicate

Il campo requireVersion sostituisce il precedente apiVersion per specificare i requisiti di versione, uniformando la sintassi con i nuovi meccanismi di pinning.

Adapter PowerShell: trace automatica e manifest adattati


Per chi utilizza risorse PowerShell esistenti tramite gli adapter PSDSC, DSC v3.2 porta alcune novità significative. È stata aggiunta la conversione automatica degli stream PowerShell (Write-Verbose, Write-Warning, ecc.) in trace DSC, il che significa che le risorse esistenti partecipano automaticamente al modello di tracing senza modifiche al codice.

È stato inoltre corretto il passaggio di credenziali alle istanze di risorse PSDSC adattate, un bug che causava problemi in ambienti con configurazioni di sicurezza elevate.

Conclusione


DSC v3.2.0 consolida la piattaforma DSC v3 con funzionalità concrete e richieste dalla community: risorse Windows native, version pinning per deployment riproducibili, preview granulare con --what-if e l’avvio di un’integrazione Bicep che promette di semplificare notevolmente la gestione IaC negli ambienti Microsoft.

Per chi gestisce ambienti Windows Server, Intune o pipeline DevOps su infrastruttura Microsoft, vale la pena iniziare a esplorare DSC v3.2 e valutare la migrazione dalle configurazioni DSC v2, la cui architettura è ormai considerata legacy.

Fonte: Announcing Microsoft Desired State Configuration v3.2.0 – PowerShell Team Blog


informatica ha ricondiviso questo.

Xi, Trump e l’inevitabile ritorno di Musk

Per vedere altri post come questo, segui la comunità @Informatica (Italy e non Italy)

Le vere connotazioni del vertice Xi-Trump, i rapporti commerciali tra Cina e Usa, il ruolo di Elon Musk e non solo. Il commento di Aresu

startmag.it/innovazione/elon-m…

informatica ha ricondiviso questo.

Meta include le multe nei costi operativi. Oltre due miliardi di euro di multe per violazione del GDPR non hanno fermato Meta, Google e TikTok.

Un'analisi mostra perché le multe sono lo strumento sbagliato, come la macchina delle lobby delle multinazionali digitali mina sistematicamente la regolamentazione e cosa significano le dimissioni del Commissario federale per la protezione dei dati.

L'articolo di @denkstrom

denkstrom.org/artikel/datenmon…

@informatica

in reply to Francesco Costa

@costafrancesco94 lo sostengo da sempre. Solo una sospensione può cambiare le cose.

Se lasci giocare a calcio undici rugbisti e lasci che placchino gli avversari e prendano la palla con le mani, non puoi limitarti a fischiare ogni volta che fanno fallo, ma devi iniziare a espellerli uno dopo l'altro. Altrimenti vinceranno sempre loro!

@denkstrom @informatica

informatica ha ricondiviso questo.

Gli Stati Uniti ordinano ai passeggeri dell'Air Force One di buttare via regali, spille e telefoni usa e getta dopo un viaggio in Cina.

Prima di salire a bordo dell'Air Force One, i membri dello staff della Casa Bianca e i giornalisti hanno dovuto consegnare diversi oggetti raccolti durante il viaggio, tra cui telefoni usa e getta, tesserini di accreditamento e spille da bavero rilasciate dalla Cina. Secondo un giornalista del pool stampa della Casa Bianca, coloro che viaggiavano sull'Air Force One hanno gettato questi oggetti in un cestino in fondo alla scaletta dell'aereo.

L'articolo di @Lorenzo Franceschi-Bicchierai su #techcrunch

techcrunch.com/2026/05/15/us-o…

@Informatica (Italy e non Italy)


NEW: The U.S. government ordered people who traveled to the China summit to throw all objects from the trip into a bin before boarding Air Force One.

The items thrown away included gifts, pins, and burner phones.

techcrunch.com/2026/05/15/us-o…


informatica ha ricondiviso questo.

Mythos trova bug persino in Apple: una sveglia per tutte le aziende


@Informatica (Italy e non Italy)
Calif, con Claude Mythos Preview, ha scoperto un exploit su MacOS 26.4.1 su chip M5. Si conferma che con l'AI è urgente un cambio di passo nella cybersecurity
L'articolo Mythos trova bug persino in Apple: una sveglia per tutte le aziende proviene da Cyber Security 360.

informatica ha ricondiviso questo.

Il vertice di Pechino e l’inevitabile ritorno di Musk

Per vedere altri post come questo, segui la comunità @Informatica (Italy e non Italy)

Le vere connotazioni del vertice Xi-Trump, i rapporti commerciali tra Cina e Usa, il ruolo di Elon Musk e non solo. Il commento di Aresu

startmag.it/innovazione/elon-m…

informatica ha ricondiviso questo.

Cosa sappiamo sull’attacco hacker alla big dei chip Foxconn


@Informatica (Italy e non Italy)
Un attacco hacker allo stabilimento nel Wisconsin del colosso dei chip di Foxconn avrebbe fruttato ai pirati informatici 8 TB di dati interni che riguarderebbero anche progetti con Amd, Google e Intel, mentre non risulterebbero file riconducibili ad Apple, storico cliente dell'azienda

informatica ha ricondiviso questo.

Cyber Journey 2026: servono formazione, confronto e visione per una sicurezza efficace


@Informatica (Italy e non Italy)
A Cagliari si svolgerà il Cyber Journey 2026 dove hanno già confermato la presenza speaker di calibro internazionale. Ecco le tre direttrici che guidano l’edizione di quest'anno
L'articolo Cyber Journey 2026: servono formazione, confronto

informatica ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please log in.

ApocalypseZ: come gli hacker russi automatizzano il furto di account Signal su scala industriale


@Informatica (Italy e non Italy)
Un ricercatore di sicurezza di Amnesty International ha scoperto di essere tra i 13.500 bersagli di una campagna russa che utilizza lo strumento ApocalypseZ per dirottare account Signal tramite social engineering.


ApocalypseZ: come gli hacker russi automatizzano il furto di account Signal su scala industriale


Si parla di:
Toggle

Il 14 maggio 2026 TechCrunch ha pubblicato una storia che ha del cinematografico: un ricercatore specializzato nell’investigare attacchi spyware diventa lui stesso bersaglio di hacker governativi russi, ma invece di soccombere trasforma l’attacco in un’indagine che porta alla scoperta di un’infrastruttura di spionaggio capace di prendere di mira oltre 13.500 persone. La storia di Donncha Ó Cearbhaill, responsabile del Security Lab di Amnesty International, è la dimostrazione pratica di come lo spionaggio digitale di Stato oggi lavori in modo industrializzato, automatizzato e scalabile.

Il messaggio che non inganna (ma quasi)


Tutto è iniziato con un messaggio sul suo account Signal: “Dear User, this is Signal Security Support ChatBot. We have noticed suspicious activity on your device, which could have led to data leak. We have also detected attempts to gain access to your private data in Signal. To prevent this, you have to pass verification procedure, entering the verification code to Signal Security Support Chatbot. DON’T TELL ANYONE THE CODE, NOT EVEN SIGNAL EMPLOYEES.”

Il messaggio è grossolano per un esperto di sicurezza — nessuna piattaforma legittima chiede mai codici di verifica via chat — ma per un utente ordinario è sufficientemente convincente. La minaccia di una violazione imminente, il tono urgente, la richiesta di non condividere il codice: tutti elementi classici di ingegneria sociale progettati per innescare una risposta emotiva prima che quella razionale possa intervenire.

Il meccanismo tecnico: device linking via codice OTP


L’obiettivo dell’attacco non è rubare la password (Signal non ha password tradizionali), ma sfruttare la funzionalità legittima di linked devices di Signal. Quando si collega un nuovo dispositivo a un account Signal esistente, l’app genera un QR code o un codice numerico. Se l’utente viene ingannato a condividere questo codice con gli attaccanti, questi possono aggiungere un dispositivo controllato da loro come “dispositivo secondario” dell’account — ottenendo così accesso a tutti i messaggi futuri e a quelli precedenti sincronizzati.

La tecnica non richiede zero-day, exploit sofisticati o accesso fisico al dispositivo: bastano ingegneria sociale e un utente che si fida abbastanza da inserire un codice. Ó Cearbhaill, riconoscendo immediatamente la natura del tentativo, ha deciso di non bloccare l’interazione ma di utilizzarla come punto d’ingresso per investigare la campagna.

ApocalypseZ: la piattaforma di attacco di Stato


La scoperta più significativa dell’indagine è lo strumento che gli attaccanti utilizzano: ApocalypseZ. Si tratta di una piattaforma di automazione degli attacchi che consente agli operatori di prendere di mira molte persone simultaneamente con supervisione umana minima. Il codebase e l’interfaccia operativa sono in russo, e lo strumento include funzionalità di traduzione automatica dei messaggi delle vittime in russo — elemento che allinea l’attribuzione ai servizi intelligence russi confermata da CISA, NCSC britannico e intelligence olandese.

La logica operativa di ApocalypseZ funziona come un “funnel” automatizzato: il sistema invia messaggi di phishing in bulk, traccia le risposte, e quando una vittima interagisce attivamente, allerta un operatore umano per gestire la fase di convincimento finale. Questo approccio semi-automatizzato consente di scalare la campagna a decine di migliaia di bersagli mantenendo l’efficacia del social engineering.

La “snowball hypothesis”: come si espande il targeting


Ó Cearbhaill ha identificato un pattern importante nel modo in cui gli attaccanti selezionano i propri bersagli. Egli chiama questo meccanismo la “snowball hypothesis”: quando gli hacker compromettono con successo un account Signal, ottengono accesso alla lista dei contatti e alle chat di gruppo di quella persona. Questo fornisce una lista pronta di nuovi potenziali bersagli — colleghi, giornalisti, attivisti, fonti — che vengono aggiunti automaticamente alla coda di attacco.

Il ricercatore ritiene di essere diventato un bersaglio perché era membro di una chat di gruppo con qualcuno che era già stato compromesso. Tra i target identificati figurano giornalisti con cui aveva lavorato e un collega diretto — confermando che il network di contatti delle vittime è il principale meccanismo di espansione della campagna.

Scala e attribuzione: 13.500 bersagli e CISA


Analizzando l’infrastruttura di ApocalypseZ, Ó Cearbhaill ha determinato di essere tra almeno 13.500 bersagli identificati — e lui stesso precisa che il numero reale è certamente molto più alto, poiché la campagna era ancora attiva al momento della pubblicazione del suo report. Tra le vittime confermate vi sarebbero anche politici di alto profilo tedeschi, come riportato da Der Spiegel.

L’attribuzione a hacker governativi russi è stata formalizzata da più agenzie: la CISA statunitense, il NCSC britannico e i servizi d’intelligence olandesi hanno tutti emesso avvisi pubblici su questa campagna. Il targeting include giornalisti, ricercatori di sicurezza, funzionari governativi, attivisti e personale delle ONG — il tipico profilo di interesse dei servizi d’intelligence russi (FSB/GRU/SVR).

Il contesto: una campagna di lunga durata contro le app di messaggistica sicura


Questo attacco non è isolato. Da inizio 2026, Signal ha emesso avvisi pubblici su campagne di phishing contro i propri utenti. L’intelligence olandese aveva già messo in guardia a marzo 2026 contro hacker russi che prendono di mira Signal e WhatsApp. Il pattern è chiaro: man mano che la crittografia end-to-end è diventata lo standard per le comunicazioni sensibili, i servizi d’intelligence hanno spostato i propri sforzi dall’intercettazione delle comunicazioni al compromissione degli endpoint — cioè del dispositivo o dell’account dell’utente.

Signal stesso, nella sua architettura, è resistente agli attacchi a livello di rete. Ma nessuna crittografia può proteggere da un utente che viene convinto a consegnare volontariamente l’accesso al proprio account.

Indicatori e vettori di attacco

# Campagna phishing Signal - APT russo (ApocalypseZ)
# Rilevata: inizio 2026 | Pubblicata: 14 maggio 2026

## Vettore di attacco
- Piattaforma: Signal (messaggistica diretta)
- Metodo: impersonificazione "Signal Security Support ChatBot"
- Obiettivo: ottenere codice OTP per device linking
- Automazione: strumento ApocalypseZ (codebase in russo)

## Tecnica (MITRE ATT&CK)
- T1566 - Phishing
- T1078 - Valid Accounts (device linking tramite codice OTP legittimo)
- T1119 - Automated Collection (scraping lista contatti post-compromissione)

## Targeting
- 13.500+ bersagli identificati (numero reale superiore)
- Profili: giornalisti, ricercatori sicurezza, funzionari gov, attivisti, ONG
- Nazioni: USA, UK, Germania, Paesi Bassi, altri paesi NATO/UE

## Attribuzione
- CISA (USA): hacker governativi russi
- NCSC (UK): campagna attribuita a spie russe
- AIVD (NL): servizi intelligence russi

## Indicatori comportamentali (social engineering)
- Messaggio urgente da "Signal Security Support"
- Richiesta codice OTP/verifica
- Istruzione "non condividere il codice"
- Pressione temporale per completare verifica

## Difesa specifica
- Abilitare Registration Lock in Signal (Impostazioni > Account > PIN)
- Non condividere MAI codici OTP ricevuti su Signal
- Verificare dispositivi collegati: Impostazioni > Dispositivi collegati

Due righe per i difensori


La difesa contro questo tipo di attacco è paradossalmente semplice rispetto alla sofisticazione dell’infrastruttura offensiva. Ó Cearbhaill raccomanda di attivare immediatamente la funzione Registration Lock di Signal (nelle impostazioni come PIN di blocco registrazione): questa feature impedisce che il proprio numero di telefono venga registrato su un nuovo dispositivo senza conoscere il PIN, vanificando il device linking non autorizzato anche se l’attaccante ottiene il codice OTP.

Più in generale, per le organizzazioni che gestiscono profili ad alto rischio — giornalisti investigativi, difensori dei diritti umani, ricercatori di sicurezza, funzionari governativi — è fondamentale adottare un approccio sistematico alla sicurezza delle comunicazioni: audit periodico dei dispositivi collegati a ogni account, formazione sul riconoscimento del social engineering su piattaforme di messaggistica, e protocolli di verifica out-of-band quando si ricevono richieste inusuali anche da fonti apparentemente note.

La storia di Ó Cearbhaill termina con una nota di sfida aperta: il ricercatore ha dichiarato di dubitare che gli attaccanti proveranno a colpirlo di nuovo, e di dare il benvenuto a futuri messaggi — specialmente se contenessero zero-day da condividere. Un invito ironico che sintetizza l’essenza del lavoro di chi studia lo spionaggio digitale: trasformare ogni attacco in conoscenza.


informatica ha ricondiviso questo.

Asml, i Paesi Bassi sbuffano contro gli Stati Uniti per la nuova legge anti-Cina

Per vedere altri post come questo, segui la comunità @Informatica (Italy e non Italy)

I Paesi Bassi sono contrari al Match Act degli Stati Uniti, una legge che inasprisce le restrizioni alla vendita di macchinari per i microchip in Cina e che, di conseguenza, danneggerebbe gli affari del colosso Asml. Tutti i dettagli.

informatica ha ricondiviso questo.

L’esperto: “Hacker e dipendenti corrotti, l’Italia digitale è un colabrodo: cybersecurity sempre più sciatta e negligente. E nessuno paga”

L'analisi di Michele Colajanni dopo gli arresti della procura di Napoli: "600 mila accessi abusivi agli archivi riservati dello Stato? Tutto tracciato e con alert automatici. Qualcuno non ha vigilato"

ilfattoquotidiano.it/2026/05/1…

@informatica

informatica ha ricondiviso questo.

Sul ban dagli Usa di router e droni una nuova piroetta americana?

Per vedere altri post come questo, segui la comunità @Informatica (Italy e non Italy)

Nuovo intervento della Federal Communications Commission sul ban americano a droni e dispositivi di rete nel giro di poche settimane: adesso l'autorità consente pure di proseguire con la distribuzione degli aggiornamenti per i

informatica ha ricondiviso questo.

Rotto schermo/touch completamente del mio pixel 7a con grapheneos: come faccio a fare un backup?...


Sono talmente sfigato che del telefono non si è rotto nemmeno lo schermo ma direttamente, passatemi il termine da ignorante ,"sotto lo schermo" con due belle crepe dopo aver messo una pellicola nuova in modo impeccabile uguale all'altra che avevo prima che era tutta distrutta che con quella, nemmeno buttando il telefono per terra, si era mai rotto lo schermo.

Il telefono non ha adb/debug attivo di sicuro perché lo so ma ha un backup su seedvault di cui ho letteralmente smontato la camera di brutto per trovare le "12 words" per decriptarlo cercando in ogni possibile zona che ovviamente non ho trovato sennò non sarei qui visto che avevo backuppato tutto lì e avrei risolto.

Per due giorni non sono nemmeno riuscito ad accedere all'email (ora si) e attualmente sono riuscito ad accedere solo al server (con i miei dati di login) di nextcloud su cui ho alcuni dati tra cui seedvault in cloud (quello che dicevo prima) e anche le mie note di joplin che ho recuperato tutte.

Pure l'esim è ancora sul pixel rotto e non ho un telefono su cui metterla ma ho per fortuna un altro telefono (un dumbphone, il doov r77) con una sim a parte ma ovviamente avevo pure appena fatto la ricarica del telefono rotto principale due volte per sbaglio e se non la trasformo in sim normale perdo quei 20 euro di credito e avendo pochi soldi preferirei non spendere nulla (ho iliad e per trasformarla in sim fisica ci vuole quasi un mese in uno di quei "bidoni" di iliad che creano assai problemi a farlo ma non sto a dire tutto anche perché l'ho già fatto nel 2024 e so che problemi potrebbero creare, se volete chiedete).

Il pixel ha già due anni e mezzo e una cassa audio morta e l'altra quasi quindi ora avendo pure touch e schermo sfondati non sto di certo a sistemarlo per dei dati visto che non sono un enormità di dati ma qualcosa di importante c'è lì dentro...

La domanda vera e propria è:
Vista la mia disperazione, visto che se aggiustassi sto "catorcio" (mi piange il cuore chiamarlo così, è il telefono più bello che abbia mai avuto però ora è letteralmente da buttare) con boh 100 euro se va bene non ne varrebbe la pena, c'è qualche modo per tirare fuori questi dati, vedere lo schermo del cellulare su un monitor con un mouse o perlomeno trovare o cambiare le 12 parole di password da seedvault visto che lì ho tutto? O qualsiasi modo per fare qualcosa di utile per me? Ho già provato a collegarci un hub usb-c con hdmi ma non va nulla perché il pixel 7a è l'ultimo dispositivo a non supportare l'uscita hdmi e anche perché ho disattivato le connessioni usb totalmente tranne per la ricarica pure con device sbloccato (sono un pirla...).

Grazie mille davvero se mi aiutate perché sono disperato, i coinquilini iniziano seriamente a guardarmi male con la mia camera sottosopra.

reshared this

in reply to Solipsismo

wrote:

My Pixel 7a with Grapheneos has a completely broken touchscreen: how do I make a backup?
...
The phone definitely doesn't have ADB/Debugging enabled, because I know that, but it does have a backup on SeedVault. I literally tore the camera apart to find the "12 words" to decrypt it, searching every possible area. Obviously, I couldn't find it, otherwise I wouldn't be here, since I had everything backed up there and would have solved the problem.


Have you tried asking @GrapheneOS for information?

@admin

informatica ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

SimpleChat: un template Blazor provider-agnostico per chat AI con .NET 10 Aspire
#tech
spcnet.it/simplechat-un-templa…
@informatica


SimpleChat: un template Blazor provider-agnostico per chat AI con .NET 10 Aspire


Chi sviluppa applicazioni AI in .NET lo sa bene: ogni volta che si integra un LLM in un progetto Blazor, si finisce a riscrivere lo stesso boilerplate per connettere OpenAI, Azure OpenAI, Anthropic o Google. SimpleChat è un template open-source che risolve esattamente questo problema — un’applicazione Blazor Server + .NET 10 Aspire che gestisce quattro provider AI in modo intercambiabile, esponendo un unico IChatClient all’intera applicazione.

Il progetto è disponibile su GitHub: github.com/ADefWebserver/SimpleChat

Perché esiste SimpleChat


Il problema che SimpleChat risolve è concreto: ogni provider AI ha il proprio contratto REST, le proprie intestazioni e le proprie particolarità. OpenAI usa una API key e un base URL. Azure OpenAI richiede un endpoint, un deployment name e una versione API. Anthropic ha il proprio formato di richiesta e rifiuta il parametro temperature sui modelli Claude 4 con ragionamento. Google AI (Gemini) ha ancora un’altra struttura REST sotto generativelanguage.googleapis.com.

SimpleChat risolve tutto questo costruendo su Microsoft.Extensions.AI e centralizzando la logica di creazione del client in una sola classe: ChatClientFactory. Tutto il codice upstream non deve mai sapere quale provider è attivo.

Architettura del progetto


La soluzione Aspire è composta da tre progetti:

  • SimpleChat — l’app web Blazor Server
  • SimpleChat.AppHost — l’orchestratore Aspire
  • SimpleChat.ServiceDefaults — OpenTelemetry condiviso, health check e resilienza

I componenti principali dell’applicazione sono:

  • AIConfigurationService — legge la sezione AI della configurazione e scrive le modifiche dell’utente su disco
  • ChatClientFactory — l’unico posto dove l’app conosce la differenza tra i provider; restituisce un IChatClient
  • ChatService — orchestratore stateless che fa streaming delle risposte dall’IChatClient attivo
  • AIModelService — chiama l’endpoint /models di ogni provider, con una lista di fallback


Il modello di configurazione


Tutta la configurazione AI vive in una sezione AI di appsettings.json:

{
  "AI": {
    "ActiveProvider": "OpenAI",
    "Providers": {
      "OpenAI": {
        "Enabled": true,
        "ApiKey": "",
        "Endpoint": "https://api.openai.com/v1",
        "DefaultModel": "gpt-4o-mini",
        "Models": ["gpt-4o-mini", "gpt-4o", "gpt-5-mini", "o4-mini"]
      },
      "AzureOpenAI": {
        "Enabled": false,
        "ApiKey": "",
        "Endpoint": "",
        "DeploymentName": "",
        "ApiVersion": "2024-10-21"
      },
      "Anthropic": {
        "Enabled": false,
        "ApiKey": "",
        "Endpoint": "https://api.anthropic.com",
        "DefaultModel": "claude-sonnet-4-20250514"
      },
      "GoogleAI": {
        "Enabled": false,
        "ApiKey": "",
        "Endpoint": "https://generativelanguage.googleapis.com",
        "DefaultModel": "gemini-2.5-flash"
      }
    },
    "Defaults": {
      "Temperature": 0.7,
      "MaxOutputTokens": 1024,
      "SystemPrompt": "You are a helpful assistant."
    }
  }
}

Questa struttura è il contratto. Per scambiare il layer di storage (database, Key Vault, browser storage, file share), basta modificare solo AIConfigurationService — nient’altro nell’app cambia.

La ChatClientFactory: un solo posto per tutta la logica provider


La factory è il cuore del template. Dopo che questo metodo ritorna, tutto il codice downstream vede solo un IChatClient:

public (IChatClient Client, string Model) Create(string providerKey)
{
    var key = NormalizeProviderKey(providerKey);
    var settings = _config.GetProvider(key);

    if (!settings.Enabled)
        throw new InvalidOperationException($"Provider '{providerKey}' is disabled.");

    IChatClient inner;
    string model;

    switch (key)
    {
        case "OpenAI":
            model = settings.DefaultModel ?? "gpt-4o-mini";
            var openAI = new OpenAIClient(
                new ApiKeyCredential(settings.ApiKey!),
                new OpenAIClientOptions { Endpoint = ... });
            inner = openAI.GetChatClient(model).AsIChatClient();
            break;

        case "AzureOpenAI":
            model = settings.DeploymentName!;
            var azure = new AzureOpenAIClient(
                new Uri(settings.Endpoint!),
                new AzureKeyCredential(settings.ApiKey!));
            inner = azure.GetChatClient(model).AsIChatClient();
            break;

        case "Anthropic":
            model = settings.DefaultModel ?? "claude-sonnet-4-20250514";
            inner = new AnthropicChatClient(settings.ApiKey!, model, _httpClientFactory.CreateClient(...));
            break;

        case "GoogleAI":
            model = settings.DefaultModel ?? "gemini-2.5-flash";
            inner = new GoogleAIChatClient(settings.ApiKey!, model, _httpClientFactory.CreateClient(...));
            break;

        default:
            throw new InvalidOperationException($"Unknown provider '{providerKey}'.");
    }

    return (inner, model);
}

Per Anthropic e Google AI, SimpleChat include client personalizzati (AnthropicChatClient e GoogleAIChatClient) che adattano le rispettive REST API all’interfaccia IChatClient di Microsoft.Extensions.AI — necessari perché questi provider non hanno ancora un pacchetto MEAI ufficiale.

Streaming e configurazione runtime


ChatService.StreamAsync restituisce un IAsyncEnumerable<string> di chunk di token. L’interfaccia utente fa lo streaming degli aggiornamenti nella bolla dell’assistente man mano che arrivano, e supporta un pulsante Cancel che interrompe la chiamata in corso.

Una delle funzionalità più interessanti è il cambio di provider e modello a runtime senza riavviare l’app. Il dropdown viene popolato dall’endpoint /models live di ogni provider. Il trucco tecnico è in Program.cs:

builder.Configuration.AddJsonFile(userOverlay, optional: true, reloadOnChange: true);
// ...
builder.Services.AddOptions<AIOptions>()
    .Bind(builder.Configuration.GetSection(AIOptions.SectionName));

reloadOnChange: true fa sì che salvare il file faccia scattare IOptionsMonitor<AIOptions>.OnChange, al quale il ChatPanel è sottoscritto — così il dropdown del provider si aggiorna senza ricaricare la pagina.

Gestione sicura delle chiavi API


In Development, le modifiche alla pagina Settings vengono scritte su appsettings.Development.json. In Production vengono scritte su un file separato appsettings.User.json che viene sovrapposto ad appsettings.json all’avvio — così le chiavi reali non devono mai essere committate nel repository.

private string WritablePath => _env.IsDevelopment()
    ? Path.Combine(_env.ContentRootPath, "appsettings.Development.json")
    : Path.Combine(_env.ContentRootPath, "appsettings.User.json");

Come usarlo come template per i propri agenti AI


Il vero valore di SimpleChat non è l’applicazione in sé, ma il pattern riutilizzabile che porta con sé. Quando si inizia una nuova app, si può puntare un agente AI di coding verso questo repository con l’istruzione: “implementa la configurazione di SimpleChat, ma salva le impostazioni AI in un database (o in un file JSON, o in Azure Key Vault, o dove mi dici).” Tutta la logica di incollaggio specifica per provider è già fatta.

Il contratto è semplice: l’agente deve implementare solo AIConfigurationService per leggere e scrivere lo stesso grafo di oggetti AIOptions. Nient’altro nell’app deve cambiare.

Conclusione


SimpleChat è un punto di partenza concreto per chiunque voglia costruire applicazioni AI con Blazor e .NET 10 Aspire senza dover reinventare ogni volta la ruota dell’integrazione multi-provider. L’architettura è intenzionalmente piccola e comprensibile: un frontend Blazor Server, un servizio di configurazione, una factory che produce un IChatClient, e un orchestratore di streaming leggero sopra. Il codice è aperto e modificabile per adattarsi a qualsiasi layer di storage.

Per chi lavora regolarmente con LLM in progetti .NET, avere questo template a disposizione può fare risparmiare ore di lavoro ripetitivo ad ogni nuovo progetto.

Fonte originale: SimpleChat: A Provider-Agnostic AI Chat Starter for Blazor di Michael Washington — via Morning Dew #4664


informatica ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

LINQ in C#: guida completa alle operazioni di aggregazione (Count, Sum, MinBy, MaxBy, Aggregate)
#tech
spcnet.it/linq-in-c-guida-comp…
@informatica


LINQ in C#: guida completa alle operazioni di aggregazione (Count, Sum, MinBy, MaxBy, Aggregate)


Le operazioni di aggregazione sono tra le più frequenti in qualsiasi applicazione .NET che lavora con collezioni di dati. LINQ mette a disposizione un toolkit completo: dagli operatori di base come Count e Sum, alle più potenti MinBy/MaxBy introdotte in .NET 6, fino ad Aggregate, il fold generico che permette di sostituire loop complessi con pipeline dichiarative. In questo articolo approfondiamo ogni operatore con esempi pratici, evidenziamo le trappole di performance più comuni e mostriamo come costruire aggregazioni efficienti anche in scenari avanzati.

Il modello di dominio


Tutti gli esempi utilizzano tre record che rappresentano un sistema di ordini e vendite:

public record Order(int Id, string CustomerId, string Status, decimal Total, DateTimeOffset PlacedAt);
public record Product(int Id, string Name, string Category, decimal Price, int StockLevel);
public record SalesData(string Region, string ProductId, int UnitsSold, decimal Revenue, DateTimeOffset Period);


Count e LongCount


Count() restituisce il numero di elementi come int. La versione con predicato conta solo gli elementi che soddisfano la condizione:

IEnumerable<Order> orders = GetOrders();

int total        = orders.Count();
int pendingCount = orders.Count(o => o.Status == "Pending");
int paidCount    = orders.Count(o => o.Status == "Paid");

Console.WriteLine($"Totale: {total}, In attesa: {pendingCount}, Pagati: {paidCount}");


Per sequenze con più di int.MaxValue elementi (circa 2,1 miliardi), usare LongCount() che restituisce long. Nella pratica, questo scenario si presenta principalmente in contesti di log aggregation o telemetria su larga scala.

La trappola di performance: Count vs Any


Questo è uno degli errori di performance più diffusi con LINQ. Quando si vuole verificare l’esistenza di almeno un elemento, molti sviluppatori usano Count() > 0 invece di Any():

IEnumerable<Order> orders = GetOrders();

// ❌ Count() valuta l'intera sequenza — O(n)
if (orders.Count(o => o.Status == "Pending") > 0)
{
    Console.WriteLine("Ci sono ordini in attesa.");
}

// ✅ Any() si ferma al primo match — O(1) nel caso migliore
if (orders.Any(o => o.Status == "Pending"))
{
    Console.WriteLine("Ci sono ordini in attesa.");
}


Any(predicate) cortocircuita non appena trova il primo elemento corrispondente. Count(predicate) deve valutare ogni elemento per produrre un conteggio accurato, anche quando la risposta a “esiste almeno un elemento?” sarebbe nota immediatamente. La differenza di performance è particolarmente evidente con sorgenti lazy, query EF Core o sequenze molto lunghe.

Stesso principio per il test di sequenza vuota:

// ❌ Enumera tutta la sequenza
if (orders.Count() == 0) { }

// ✅ Si ferma al primo elemento
if (!orders.Any()) { }


La regola da memorizzare: usare Any() per verifiche di esistenza, Count() solo quando serve il numero esatto.

Sum e Average


Sum(selector) e Average(selector) accettano un selettore per proiettare ogni elemento a un valore numerico prima di aggregare:

IEnumerable<Order> orders = GetOrders();

decimal totalRevenue = orders.Sum(o => o.Total);
decimal averageOrder = orders.Average(o => o.Total);

Console.WriteLine($"Fatturato totale: €{totalRevenue:F2}");
Console.WriteLine($"Ordine medio: €{averageOrder:F2}");


Importante: Average() lancia InvalidOperationException su una sequenza vuota. È buona pratica proteggersi con un controllo preventivo:
decimal? safeAverage = orders.Any()
    ? orders.Average(o => o.Total)
    : null;


Un esempio più articolato che combina GroupBy con Sum e Average per ottenere statistiche per regione geografica:
IEnumerable<SalesData> sales = GetSalesData();

var revenueByRegion = sales
    .GroupBy(s => s.Region)
    .Select(g => new
    {
        Region       = g.Key,
        TotalRevenue = g.Sum(s => s.Revenue),
        AverageUnits = g.Average(s => s.UnitsSold)
    })
    .OrderByDescending(x => x.TotalRevenue);

foreach (var row in revenueByRegion)
{
    Console.WriteLine($"{row.Region}: €{row.TotalRevenue:F0}, media {row.AverageUnits:F1} unità");
}


Min e Max


Min(selector) e Max(selector) restituiscono il valore scalare minimo o massimo — non l’elemento che lo contiene:

IEnumerable<Product> products = GetProducts();

decimal cheapest      = products.Min(p => p.Price);
decimal mostExpensive = products.Max(p => p.Price);

Console.WriteLine($"Range prezzi: €{cheapest:F2} — €{mostExpensive:F2}");


Il limite: se serve il prodotto più economico (non solo il suo prezzo), prima di .NET 6 si era costretti a enumerare la sequenza due volte:
// Prima di .NET 6 — due passaggi, potenziale bug con prezzi duplicati
decimal minPrice     = products.Min(p => p.Price);
Product? cheapestOld = products.FirstOrDefault(p => p.Price == minPrice);


Questo approccio ha un bug sottile: se più prodotti condividono il prezzo minimo, FirstOrDefault sceglie il primo trovato nell’ordine di iterazione, che potrebbe non essere quello desiderato. Inoltre itera la sequenza due volte.

MinBy e MaxBy: l’elemento, non il valore (.NET 6+)


MinBy(keySelector) e MaxBy(keySelector) restituiscono l’elemento che ha il valore minimo o massimo della chiave, in un singolo passaggio sulla sequenza:

// .NET 6+ — singolo passaggio, restituisce l'elemento
Product? cheapest      = products.MinBy(p => p.Price);
Product? mostExpensive = products.MaxBy(p => p.Price);

Console.WriteLine($"Più economico: {cheapest?.Name} a €{cheapest?.Price:F2}");
Console.WriteLine($"Più costoso: {mostExpensive?.Name} a €{mostExpensive?.Price:F2}");


Quando più elementi condividono la stessa chiave minima/massima, MinBy/MaxBy restituiscono il primo incontrato, coerentemente con la semantica di OrderBy().First().

Esempio reale: trovare il periodo di vendita con fatturato più alto e la regione con performance peggiore:

// Periodo con il singolo record di fatturato più alto
SalesData? topPeriod = sales.MaxBy(s => s.Revenue);
Console.WriteLine($"Periodo migliore: {topPeriod?.Region} — €{topPeriod?.Revenue:F2}");

// Regione con fatturato totale più basso
var revenueSummary = sales
    .GroupBy(s => s.Region)
    .Select(g => (Region: g.Key, Total: g.Sum(s => s.Revenue)));

(string Region, decimal Total) worstRegion = revenueSummary.MinBy(r => r.Total);
Console.WriteLine($"Regione con fatturato minore: {worstRegion.Region} (€{worstRegion.Total:F2})");


Aggregate: fold personalizzato


Aggregate è l’operatore più generale: accetta un valore seed e una funzione accumulatrice, piegando ogni elemento nel risultato accumulato. È il fold funzionale di LINQ, e può fare tutto ciò che i metodi specializzati fanno — e molto di più:

IEnumerable<Order> orders = GetOrders();

// Concatena gli ID degli ordini come stringa CSV
string orderList = orders.Aggregate(
    string.Empty,
    (acc, order) => string.IsNullOrEmpty(acc)
        ? order.Id.ToString()
        : $"{acc},{order.Id}");

Console.WriteLine($"ID ordini: {orderList}");


Caso pratico: calcolo del fattore di sconto combinato (moltiplicativo):
decimal[] discounts = [0.10m, 0.05m, 0.15m]; // 10%, 5%, 15%

// Il fattore risultante dopo l'applicazione di tutti gli sconti in sequenza
decimal combinedFactor = discounts.Aggregate(
    1.0m,
    (factor, discount) => factor * (1 - discount));

Console.WriteLine($"Fattore combinato: {combinedFactor:P2}"); // es. 72,54%


Aggregate con result selector


La variante a tre argomenti aggiunge una proiezione finale applicata al risultato accumulato dopo aver processato tutti gli elementi. Questo permette di calcolare la media in un singolo passaggio senza dover iterare due volte:

IEnumerable<SalesData> sales = GetSalesData();

decimal averageRevenue = sales.Aggregate(
    seed: (Total: 0m, Count: 0),
    func: (acc, s) => (acc.Total + s.Revenue, acc.Count + 1),
    resultSelector: acc => acc.Count > 0 ? acc.Total / acc.Count : 0m);

Console.WriteLine($"Fatturato medio: €{averageRevenue:F2}");


Aggregazioni multiple in un singolo passaggio


Calcolare più aggregazioni sulla stessa sequenza in modo ingenuo significa iterarla più volte. Per sorgenti costose — query su database, chiamate di rete, lettura di file — questo ha un impatto reale. La soluzione è usare Aggregate con un accumulatore composito che raccoglie tutti i valori contemporaneamente:

public record AggregateSummary(int Count, decimal Sum, decimal Min, decimal Max);

IEnumerable<Order> orders = GetOrders();

AggregateSummary summary = orders.Aggregate(
    new AggregateSummary(0, 0m, decimal.MaxValue, decimal.MinValue),
    (acc, order) => new AggregateSummary(
        acc.Count + 1,
        acc.Sum   + order.Total,
        Math.Min(acc.Min, order.Total),
        Math.Max(acc.Max, order.Total)));

decimal average = summary.Count > 0 ? summary.Sum / summary.Count : 0m;

Console.WriteLine($"Count:   {summary.Count}");
Console.WriteLine($"Somma:   €{summary.Sum:F2}");
Console.WriteLine($"Minimo:  €{summary.Min:F2}");
Console.WriteLine($"Massimo: €{summary.Max:F2}");
Console.WriteLine($"Media:   €{average:F2}");


Un passaggio, quattro valori. Questo pattern è particolarmente utile nei query handler CQRS in cui il risultato richiede più statistiche e la sorgente dati è un database o un servizio esterno.

TryGetNonEnumeratedCount (.NET 6)


Prima di calcolare aggregazioni che richiedono il conteggio, conviene verificare se è disponibile senza enumerare la sequenza:

IEnumerable<Order> orders = GetOrders();

if (orders.TryGetNonEnumeratedCount(out int count))
{
    Console.WriteLine($"Conteggio rapido: {count}");
    // Disponibile senza iterare — usabile per pre-allocazione o logging
}
else
{
    // Fallback: deve enumerare
    count = orders.Count();
}


TryGetNonEnumeratedCount restituisce true per List<T>, array, HashSet<T> e altri tipi che implementano ICollection<T>. Restituisce false per pipeline lazy, risultati di GroupBy e qualsiasi IEnumerable che deve essere valutato per conoscere la propria lunghezza.

Novità .NET 9: CountBy e AggregateBy


.NET 9 ha introdotto due nuovi operatori di aggregazione per chiave che migliorano i pattern basati su GroupBy:

IEnumerable<Order> orders = GetOrders();

// CountBy: conta gli elementi per chiave — più conciso di GroupBy + Count
var countByStatus = orders.CountBy(o => o.Status);
foreach (var (status, count) in countByStatus)
{
    Console.WriteLine($"{status}: {count} ordini");
}

// AggregateBy: aggregazione personalizzata per chiave
var totalByCustomer = orders.AggregateBy(
    keySelector: o => o.CustomerId,
    seed: 0m,
    func: (total, order) => total + order.Total);

foreach (var (customerId, total) in totalByCustomer)
{
    Console.WriteLine($"Cliente {customerId}: €{total:F2}");
}


Per aggregazioni per chiave in .NET 9+, preferire CountBy e AggregateBy rispetto a GroupBy seguito da aggregazione: il codice è più leggibile e spesso più efficiente.

Guida rapida alla scelta dell’operatore


  • Verificare se esiste almeno un elementoAny(predicate)
  • Contare elementiCount() / Count(predicate)
  • Somma di valori proiettatiSum(selector)
  • Media di valori proiettatiAverage(selector)
  • Valore scalare minimo/massimoMin(selector) / Max(selector)
  • Elemento con chiave minima (.NET 6+)MinBy(keySelector)
  • Elemento con chiave massima (.NET 6+)MaxBy(keySelector)
  • Conteggio per chiave (.NET 9+)CountBy(keySelector)
  • Aggregazione personalizzata per chiave (.NET 9+)AggregateBy(keySelector, seed, func)
  • Fold generico con seedAggregate(seed, func)
  • Fold generico con proiezione finaleAggregate(seed, func, resultSelector)


Conclusione


Le operazioni di aggregazione LINQ coprono l’intero spettro delle necessità di riduzione dei dati. Conoscere la differenza tra Any e Count, sapere quando usare MinBy/MaxBy invece di un doppio passaggio, e saper costruire fold multi-valore con Aggregate sono competenze che migliorano sia le performance che la leggibilità del codice. Con l’aggiunta di CountBy e AggregateBy in .NET 9, il toolkit di aggregazione LINQ è oggi più completo che mai: vale la pena tenerlo presente come alternativa ai foreach loop ogni volta che si lavora con trasformazioni di collezioni.

Fonte: LINQ Aggregation in C#: Count, Sum, Min, Max, Average, and Aggregate — Dev Leader


informatica ha ricondiviso questo.

Ecco perché i marchi di tablet da disegno non collaboreranno sui driver FLOSS per Linux

"Devo scusarmi perché oggi ho parlato di nuovo con il nostro team tecnico e abbiamo deciso di non procedere con il progetto del driver Linux in questo momento"

davidrevoy.com/article1154/why…

@informatica