(in)sicurezza digitale

2026-05-23 20:58:09

Webworm evolve: i backdoor EchoCreep e GraphWorm trasformano Discord e Microsoft Graph in canali C2

Quando un gruppo APT decide di nascondere le proprie comunicazioni malevole dentro le API di prodotti Microsoft o nei canali Discord, il confine tra traffico legittimo e operazione di spionaggio si fa quasi invisibile per i tradizionali strumenti di sicurezza di rete. È esattamente la scelta operativa che ha compiuto Webworm, gruppo di allineamento cinese attivo da almeno il 2022, che nel 2025 ha arricchito il proprio toolkit con due nuovi implant: EchoCreep e GraphWorm.

Chi è Webworm: storia e attribuzioni

Webworm è stato documentato pubblicamente per la prima volta da Symantec (ora parte di Broadcom) nel settembre 2022. Il gruppo prende di mira agenzie governative e aziende nei settori IT, aerospaziale ed energia elettrica, con un focus geografico che comprende Russia, Georgia, Mongolia e diverse nazioni asiatiche ed europee. I ricercatori hanno identificato sovrapposizioni operative significative con cluster tracciati come FishMonger (alias Aquatic Panda), SixLittleMonkeys e Space Pirates — tutti threat actor con legami all’intelligence cinese.

La scelta dei bersagli — istituzioni governative, operatori di infrastrutture critiche e fornitori di servizi IT — è coerente con gli obiettivi strategici di raccolta intelligence attribuiti agli attori state-sponsored cinesi. Le recenti campagne hanno ampliato il raggio d’azione verso l’Europa, segnalando un’evoluzione geopolitica degli interessi del gruppo.

EchoCreep: Discord come infrastruttura C2

EchoCreep è il componente più semplice — ma non per questo meno insidioso — del nuovo arsenale. Utilizza Discord come canale di Command and Control, sfruttando le API della piattaforma di messaggistica per ricevere comandi dagli operatori e restituire output dalle macchine compromesse. Le funzionalità documentate dai ricercatori includono:

• Upload e download di file arbitrari verso/dal sistema vittima
• Esecuzione di comandi tramite cmd.exe con restituzione dell’output agli operatori
• Persistenza tramite canale Discord dedicato, non esposto pubblicamente

L’analisi del canale Discord utilizzato da EchoCreep rivela che i primi comandi risalgono al 21 marzo 2024: ciò significa che l’implant era già operativo in campagne reali ben prima della sua scoperta pubblica, probabilmente inosservato per oltre un anno.

La scelta di Discord come C2 non è casuale. Il traffico verso discord.com è quasi universalmente consentito nelle policy di rete aziendali, il protocollo è HTTPS e il volume di traffico legittimo è enorme — condizioni ideali per mascherare comunicazioni malevole nel rumore di fondo.

GraphWorm: Microsoft OneDrive come dead drop

GraphWorm è il componente più sofisticato del nuovo toolkit. Utilizza Microsoft Graph API — la stessa infrastruttura usata da milioni di applicazioni enterprise — per le comunicazioni C2, sfruttando specificamente gli endpoint di OneDrive. La tecnica del “cloud dead drop” — usare servizi cloud legittimi come proxy per i comandi — è in crescita tra gli APT più avanzati, ma GraphWorm la porta a un livello di granularità operativa notevole.

Per ciascuna vittima compromessa, GraphWorm crea una directory dedicata su OneDrive, permettendo agli operatori di gestire in modo indipendente le operazioni su target diversi senza interferenze. Le capacità documentate includono:

• Spawn di nuove sessioni cmd.exe per l’esecuzione interattiva di comandi
• Avvio di processi arbitrari sul sistema vittima
• Upload e download di file da/verso OneDrive tramite Graph API
• Self-termination controllata su segnale degli operatori, per ridurre le tracce forensi

Il traffico verso graph.microsoft.com è considerato trust implicito nella maggior parte degli ambienti enterprise Microsoft 365, rendendo il rilevamento basato sul blocco dei domini o sull’ispezione superficiale del traffico del tutto inefficace.

Tooling, proxy custom e TTP completi

Webworm integra i propri backdoor con un ecosistema di strumenti offensive collaudato. Per la fase di ricognizione, il gruppo usa tool open source come dirsearch e nuclei per eseguire brute-force dei path su web server delle vittime e identificare vulnerabilità sfruttabili. Sul lato infrastrutturale, Webworm ha sviluppato una suite di proxy custom: WormFrp, ChainWorm, SmuxProxy e WormSocket. Questi strumenti non si limitano a cifrare le comunicazioni: supportano il chaining su host multipli — sia interni che esterni alla rete bersaglio — permettendo la costruzione di tunnel multi-hop difficili da tracciare. Il gruppo utilizza inoltre SoftEther VPN per un ulteriore layer di offuscamento dell’infrastruttura C2.

Indicatori di compromissione (IoC)

# Webworm - EchoCreep / GraphWorm IoC (maggio 2026)
# Tool legittimi usati in contesto malevolo
TOOL: dirsearch (github.com/maurosoria/dirsearch)
TOOL: nuclei (github.com/projectdiscovery/nuclei)
# Custom proxy tools Webworm
TOOL: WormFrp
TOOL: ChainWorm
TOOL: SmuxProxy
TOOL: WormSocket
# Patterns comportamentali da monitorare
BEHAVIOR: cmd.exe spawned by non-standard parent process
BEHAVIOR: Unusual OneDrive API calls (graph.microsoft.com) with file creation in per-victim dirs
BEHAVIOR: Discord API traffic with binary/encoded payloads
BEHAVIOR: SoftEther VPN client installation/execution
# Cluster correlati
ALIAS: FishMonger / Aquatic Panda
ALIAS: SixLittleMonkeys
ALIAS: Space Pirates

Due righe per i difensori

L’abuso di servizi cloud legittimi per il C2 richiede un cambio di paradigma nel rilevamento. Il blocco a livello di dominio è inefficace — occorre spostare l’attenzione sul comportamento. I blue team dovrebbero implementare analisi comportamentale del traffico verso API cloud note, cercando pattern anomali di upload/download non correlati all’attività utente attesa. È fondamentale monitorare la creazione di directory insolite su OneDrive enterprise tramite i log di Microsoft 365 Defender e correlare gli accessi OAuth a Microsoft Graph con i baseline comportamentali degli account di servizio. Sul piano degli endpoint, qualsiasi processo che spawni cmd.exe con parent process inusuali dovrebbe attivare alert ad alta priorità. Infine, regole Sigma per i pattern di traffico Discord e Graph API anomali, combinate con threat intelligence sui cluster Webworm, permettono un rilevamento proattivo di queste campagne.

(in)sicurezza digitale

2026-05-23 17:51:48

Whatsapp compromesso su iPhone, la ricerca di Forenser sullo 0-click

Una premessa prima di iniziare: se hai un iPhone con iOS inferiore a 16.7.12, aggiorna, è già tardi e un miracolo che non sia ancora successo niente di brutto.

Detto questo, per anni l’ecosistema Apple è stato raccontato come una fortezza quasi inespugnabile. “Se hai un iPhone sei al sicuro” è diventato uno dei mantra più ripetuti anche fuori dalla bolla tech. Poi arrivano casi come quello documentato da Forenser e improvvisamente quella narrativa inizia a incrinarsi. Non perché iPhone sia diventato improvvisamente insicuro, ma perché il punto debole — come spesso accade — non è il dispositivo in sé. È la catena completa: notifiche, sessioni, social engineering, bug, sincronizzazioni cloud e fiducia implicita dell’utente.

La ricerca pubblicata da Forenser fotografa infatti una serie di compromissioni WhatsApp osservate su dispositivi Apple rimasti fermi a iOS 16 (specificatamente sotto il famoso aggiornamento alla 16.7.12). Non si parla di semplici tentativi di phishing “artigianali”, ma di account effettivamente presi in controllo, con accessi alle chat e utilizzo dell’identità digitale delle vittime per colpire ulteriori contatti.

Le vittime, infatti, non riportano comportamenti compatibili con il classico phishing. Nessun link cliccato volontariamente, nessuna installazione di applicazioni sospette, nessun QR code scansionato deliberatamente, nessuna richiesta di OTP condivisi. Eppure gli account risultano violati.

È questo il dettaglio che ha acceso l’interesse della comunità forense.

Secondo quanto riportato nell’analisi di Forenser, gli utenti colpiti avrebbero ricevuto messaggi specifici poco prima della compromissione. Messaggi che, in alcuni casi, sembrano avere un comportamento anomalo lato client. La ricostruzione tecnica suggerisce che il vettore d’attacco possa sfruttare una vulnerabilità legata alla gestione dei contenuti ricevuti da WhatsApp su iOS 16, permettendo l’esecuzione di operazioni malevole senza necessità di interazione diretta dell’utente.

In altre parole: il semplice ricevere il messaggio potrebbe essere sufficiente ad attivare la catena di compromissione.

È questo il vero significato di 0-click. Nessun tap. Nessun consenso. Nessun comportamento “sbagliato” da parte della vittima.

Nel mondo mobile moderno, questo tipo di attacco rappresenta uno degli scenari più pericolosi in assoluto, perché elimina completamente il principale livello difensivo su cui si basa gran parte della sicurezza consumer: l’utente stesso. Le campagne di phishing tradizionali funzionano solo se qualcuno sbaglia. Gli exploit 0-click invece trasformano il dispositivo in un bersaglio passivo.

La ricerca di Forenser suggerisce inoltre un elemento fondamentale: il problema sembrerebbe concentrarsi su device ancora fermi a certe release superate di iOS 16. Questo potrebbe indicare la presenza di vulnerabilità già corrette nelle versioni successive di iOS, ma ancora sfruttabili sui terminali non aggiornati. Ed è qui che emerge uno dei problemi più sottovalutati dell’ecosistema Apple: l’idea che “se hai un iPhone allora sei automaticamente al sicuro”.

In realtà il modello di sicurezza Apple funziona in maniera estremamente efficace proprio grazie agli aggiornamenti continui. Restare bloccati su una major release precedente significa esporsi progressivamente a vulnerabilità già note, studiate e potenzialmente weaponizzate.

Dal punto di vista operativo, un attacco del genere è devastante perché estremamente difficile da rilevare. Non lascia i classici indicatori di compromissione associati al malware tradizionale. Non rallenta necessariamente il dispositivo. Non mostra finestre sospette. Non installa applicazioni visibili. Tutto avviene all’interno di una superficie software considerata “trusted”: l’app di messaggistica stessa.

E WhatsApp rappresenta un bersaglio ideale.

Dentro quell’applicazione oggi transitano conversazioni personali, documenti, codici OTP, messaggi vocali, relazioni professionali e spesso persino elementi di autenticazione indiretta per servizi bancari o aziendali. Compromettere WhatsApp non significa più soltanto leggere chat private: significa ottenere accesso a una porzione enorme dell’identità digitale della vittima.

L’aspetto forse più interessante dell’indagine di Forenser è che porta l’attenzione su una categoria di minacce spesso percepite come lontane dal mondo reale. Quando si parla di exploit 0-click si pensa immediatamente ad attori statali, intelligence offensive e spyware da milioni di euro. Ma la linea che separa il cyberespionage dal cybercrime si sta assottigliando sempre di più. Tecniche un tempo esclusive delle operazioni governative iniziano lentamente a comparire anche in scenari meno sofisticati.

Ed è esattamente questo a rendere il caso così importante.

Perché al netto dei dettagli tecnici ancora da chiarire completamente, la ricerca di Forenser mostra un cambiamento preciso nel panorama delle minacce mobile: gli smartphone non vengono più attaccati soltanto inducendo l’utente a commettere errori. Sempre più spesso, basta semplicemente raggiungerli.

Account WhatsApp compromessi su iPhone con iOS 16: l’attacco 0click che bypassa i dispositivi collegati - Forenser Srl

Un weekend tranquillo, di fine maggio: il tempo passa senza problemi fino a quando non iniziano ad arrivare messaggi ambigui sull’applicazione di WhatsApp

^{forenser (Forenser Srl)}

Spcnet.it

2026-05-23 16:42:25

Hotpatching gratuito per Windows Server 2025 con Azure Arc: guida all’abilitazione

Cos’è l’Hotpatching e perché cambia tutto

Ogni amministratore di sistema conosce bene il problema: arriva il patch Tuesday, si pianifica una finestra di manutenzione, si notificano gli utenti, si aspetta il riavvio e si incrocia le dita sperando che tutto torni su senza intoppi. Con Windows Server 2025 e l’hotpatching abilitato da Azure Arc, questo ciclo faticoso si riduce drasticamente. E da maggio 2026, questa funzionalità è completamente gratuita per tutti i server Arc-enabled.

L’hotpatching consente di applicare aggiornamenti di sicurezza al sistema operativo senza riavviare il server nella maggior parte dei mesi. Microsoft ha annunciato che dal 15 maggio 2026 tutta la fatturazione per l’hotpatch è stata interrotta per i server Windows Server 2025 Standard e Datacenter connessi ad Azure Arc. Non sono più previsti costi per core, tariffe orarie o voci separate in fattura.

Come funziona il ciclo di aggiornamento

L’hotpatching non elimina completamente i riavvii, ma li riduce sensibilmente. Il ciclo funziona su base trimestrale:

• Mese baseline (1 riavvio ogni 3 mesi): viene installato un aggiornamento cumulativo completo che richiede un riavvio. Questo aggiornamento “alza l’asticella” del sistema per i mesi successivi.
• Mesi hotpatch (i 2 mesi successivi): vengono distribuiti solo gli aggiornamenti di sicurezza incrementali, applicati in-memory senza riavvio.

In un anno solare si ottengono fino a 8 aggiornamenti mensili senza riavvio e soli 4 riavvii baseline pianificabili. Per ambienti di produzione ad alta disponibilità, è una differenza sostanziale.

Prerequisiti tecnici

Prima di abilitare l’hotpatching, verificare che il server soddisfi i requisiti seguenti:

• Windows Server 2025 Standard o Datacenter (build 26100.1742 o successiva). Le build di anteprima non sono supportate.
• Il server deve essere connesso ad Azure Arc tramite il Connected Machine Agent.
• La macchina deve supportare la Virtualization-Based Security (VBS): firmware UEFI con Secure Boot abilitato. Per le VM Hyper-V, è richiesta una macchina virtuale di Generazione 2.
• Una subscription Azure attiva (esiste un tier gratuito per iniziare).

Nota: Windows Server 2025 Datacenter: Azure Edition ha l’hotpatching abilitato per impostazione predefinita e non richiede Azure Arc.

Verifica e abilitazione di Virtual Secure Mode (VBS)

Quando si abilita l’hotpatch dal portale Azure, il sistema verifica automaticamente se la Virtual Secure Mode (VSM) è attiva. Se non lo è, l’operazione fallisce con un errore. È conveniente verificare prima manualmente.

Verifica dello stato VSM con PowerShell

Get-CimInstance -Namespace 'root/Microsoft/Windows/DeviceGuard' `
    -ClassName 'win32_deviceGuard' | `
    Select-Object -ExpandProperty 'VirtualizationBasedSecurityStatus'

Se il valore restituito è 2, VSM è attivo e si può procedere. Se è 0 o 1, occorre abilitarlo.

Abilitazione di VSM tramite registro di sistema

New-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\DeviceGuard' `
    -Name 'EnableVirtualizationBasedSecurity' `
    -PropertyType 'Dword' `
    -Value 1 -Force

Dopo aver impostato il valore, riavviare il server e verificare nuovamente che VirtualizationBasedSecurityStatus restituisca 2.

In alternativa, VSM viene abilitato automaticamente configurando funzionalità come Credential Guard, Hypervisor-Protected Code Integrity (HVCI) o Secured-core server. Se il proprio ambiente utilizza già una di queste feature, VSM è probabilmente già attivo.

Connessione ad Azure Arc

Se il server non è ancora connesso ad Azure Arc, il modo più rapido per un singolo server è scaricare ed eseguire lo script di onboarding dal portale Azure:

1. Aprire il portale Azure e cercare Azure Arc → Machines.
2. Cliccare su Add/Create → Add a machine.
3. Selezionare Add a single server e seguire la procedura guidata.
4. Scaricare ed eseguire lo script PowerShell generato sul server target.

Per un deployment su scala (decine o centinaia di server), Azure Arc supporta l’installazione tramite Group Policy, service principal, Terraform o Configuration Manager. Il Connected Machine Agent è leggero e ha un impatto minimo sulle risorse del sistema.

Abilitazione dell’Hotpatch dal portale Azure

Una volta che il server è connesso ad Azure Arc e VSM è attivo, abilitare l’hotpatch richiede pochi click:

1. Nel portale Azure, navigare su Azure Arc → Machines.
2. Selezionare il nome del server target.
3. Nel pannello laterale, fare clic su Hotpatch.
4. Cliccare su Confirm.
5. Attendere circa 10 minuti per la propagazione delle modifiche.

Se lo stato rimane bloccato su Pending, verificare la connettività verso gli endpoint Azure Arc e controllare i log dell’agente in C:\ProgramData\AzureConnectedMachineAgent\Logs.

Automazione con Azure Update Manager

Per gestire l’hotpatching su scala, Azure Update Manager (AUM) è lo strumento consigliato. Permette di:

• Definire maintenance windows per controllare quando vengono applicati gli aggiornamenti baseline (quelli che richiedono il riavvio).
• Configurare update policies per applicare automaticamente gli hotpatch nei mesi non-baseline.
• Monitorare lo stato di conformità di tutti i server Arc da un’unica dashboard.
• Integrare con Azure Monitor per alert e reportistica.

Con AUM è possibile impostare una finestra di manutenzione mensile di 30 minuti per i riavvii baseline, sapendo che nei due mesi successivi nessun riavvio sarà necessario per gli aggiornamenti di sicurezza. Una politica ragionevole è schedulare i riavvii baseline nella notte del secondo mercoledì del mese baseline, allineandosi al ciclo Patch Tuesday di Microsoft.

Script PowerShell per il troubleshooting dell’agente Arc

Se dopo l’abilitazione l’hotpatch non si attiva correttamente, questo script PowerShell aiuta a diagnosticare i problemi più comuni:

# Verifica stato agente Azure Arc
$svc = Get-Service -Name "himds" -ErrorAction SilentlyContinue
if ($svc) {
    Write-Host "Azure Connected Machine Agent: $($svc.Status)"
} else {
    Write-Host "ERRORE: servizio HIMDS non trovato. Arc non e' installato."
}

# Verifica VBS
$vbs = Get-CimInstance -Namespace 'root/Microsoft/Windows/DeviceGuard' `
    -ClassName 'win32_deviceGuard' | `
    Select-Object -ExpandProperty 'VirtualizationBasedSecurityStatus'
Write-Host "VBS Status: $vbs (2 = attivo, 0/1 = non attivo)"

# Verifica Secure Boot
$sb = Confirm-SecureBootUEFI -ErrorAction SilentlyContinue
Write-Host "Secure Boot abilitato: $sb"

# Log agente Arc (ultimi 50 errori)
$logPath = "C:\ProgramData\AzureConnectedMachineAgent\Logs"
if (Test-Path $logPath) {
    Get-ChildItem $logPath -Filter "*.log" | 
        Sort-Object LastWriteTime -Descending | 
        Select-Object -First 1 | 
        Get-Content | Select-String "ERROR","WARN" | 
        Select-Object -Last 50
}

Considerazioni finali

Il passaggio dell’hotpatching a servizio gratuito rappresenta un cambiamento significativo nella gestione delle patch per Windows Server. Prima era necessario scegliere tra la semplicità operativa (nessun riavvio) e il costo aggiuntivo ($1.50 USD per core al mese, introdotto a luglio 2025). Ora quella scelta non esiste più.

Per chi gestisce ambienti Windows Server 2025 ibridi o on-premises, il percorso consigliato è: verificare i prerequisiti hardware (UEFI + Secure Boot), connettere i server ad Azure Arc, abilitare l’hotpatch dal portale e configurare Azure Update Manager per le finestre di manutenzione baseline. Il risultato pratico: meno riavvii, meno downtime, meno stress per il team IT — senza costi aggiuntivi.

---

Fonte originale: 4sysops — Free Windows Server 2025 hotpatching with Azure Arc. Documentazione ufficiale: Microsoft Learn — Enable Hotpatch for Azure Arc-enabled servers. Annuncio Microsoft: Microsoft Tech Community.

Simplified access to Hotpatching enabled by Azure Arc for Windows Server 2025 | Microsoft Community Hub

With Windows Server 2025, we introduced hotpatch enabled by Azure Arc, delivering security updates to Windows Server across hybrid and multicloud...

^{sharmajyoti (TECHCOMMUNITY.MICROSOFT.COM)}

informapirata ⁂

2026-05-23 09:53:56

I report di Microsoft stanno mettendo in luce il vero problema dei costi dell'intelligenza artificiale: utilizzare questa tecnologia costa più che pagare i dipendenti umani.

Secondo quanto riportato da The Verge , Microsoft avrebbe iniziato a cancellare la maggior parte delle sue licenze dirette di Claude Code, spingendo invece gli ingegneri a utilizzare GitHub Copilot CLI.
Sostituire il lavoro umano con l'IA potrebbe essere meno facile del previsto

ca.finance.yahoo.com/news/micr…

@aitech

Microsoft reports are exposing AI’s real cost problem: Using the tech is more expensive than paying human employees

Companies are racing to incentivize employees to use AI. But as some companies are finding, the more employees that use the technology, the heavier the bill.

^{Jake Angelo (Yahoo Finance)}

(in)sicurezza digitale

2026-05-23 06:55:44

Showboat e JFMBackdoor: il gruppo cinese Calypso spia le telecomunicazioni del Medio Oriente con malware Linux e Windows

I ricercatori di Lumen Technologies Black Lotus Labs hanno pubblicato il 21 maggio 2026 un’analisi dettagliata di due nuovi strumenti malevoli — Showboat (Linux) e JFMBackdoor (Windows) — impiegati in campagne di cyberspionaggio attribuite con moderata confidenza al gruppo cinese Calypso, noto anche come Red Lamassu. I bersagli: operatori di telecomunicazioni nel Medio Oriente, nell’Asia Pacifica e, più recentemente, entità negli Stati Uniti e in Ucraina.

Chi è Calypso / Red Lamassu

Calypso è un gruppo APT di matrice cinese attivo almeno dal 2018, storicamente orientato allo spionaggio su governi, settore energetico e telecomunicazioni in Asia Centrale e Medio Oriente. Il gruppo condivide infrastrutture e tooling con altri cluster affiliati alla Cina, in linea con il modello del cosiddetto digital quartermaster: una struttura centralizzata che rifornisce più gruppi APT di strumenti comuni come PlugX, ShadowPad e, ora, Showboat. Questa logica di condivisione complica l’attribuzione e amplifica la portata operativa.

Showboat: un framework post-exploitation modulare per Linux

Il punto di partenza dell’indagine è stato un binario ELF caricato su VirusTotal nel maggio 2025, inizialmente classificato come backdoor Linux sofisticato con capacità rootkit (Kaspersky lo traccia come EvaRAT). Showboat è progettato per sistemi Linux con un insieme di capacità modulari orientate alla persistenza silenziosa e al movimento laterale: shell remota per l’esecuzione di comandi arbitrari, trasferimento file bidirezionale, proxy SOCKS5 per il tunneling verso sistemi interni non esposti su internet, raccolta di informazioni di sistema, nascondimento dei processi dalla lista dei processi attivi, e recupero di payload da Pastebin (paste creato l’11 gennaio 2022) — tecnica che frammenta la kill chain su piattaforme legittime per eludere il rilevamento.

Il malware comunica con il server C2 trasmettendo informazioni di sistema in un campo PNG come stringa cifrata in Base64. La funzione proxy SOCKS5 è particolarmente significativa: consente agli attaccanti di interagire con macchine raggiungibili solo via LAN, espandendo silenziosamente il perimetro di compromissione verso asset interni critici.

JFMBackdoor: un impianto Windows a pieno spettro

A fianco di Showboat, i ricercatori hanno identificato JFMBackdoor, un impianto Windows distribuito tramite DLL side-loading. Si tratta di un RAT completo con accesso shell remoto, operazioni su file (upload, download, eliminazione), network proxying, cattura di screenshot e auto-rimozione (self-removal) per cancellare le tracce post-operazione. Il vettore DLL side-loading è un classico dei toolkit cinesi: consente di agganciare un processo legittimo per l’esecuzione del codice malevolo, riducendo la visibilità per le soluzioni EDR.

Vittime identificate e infrastruttura C2

L’analisi infrastrutturale ha rilevato le seguenti compromissioni: un provider di telecomunicazioni nel Medio Oriente (vittima principale, bersagliata almeno dal 2022), un ISP in Afghanistan, un’entità in Azerbaigian, due possibili compromissioni negli Stati Uniti e una in Ucraina, identificate tramite un cluster C2 secondario che condivide certificati X.509 con quello primario.

I nodi C2 mostrano correlazioni geografiche con indirizzi IP geolocalizzati a Chengdu, capoluogo della provincia del Sichuan — area già associata ad operazioni APT cinesi come quelle di APT41. La presenza di infrastruttura condivisa con altri cluster cinesi, tramite certificati e pattern C2 analoghi, rinforza l’ipotesi del digital quartermaster. Il gruppo ha registrato domini tematici che impersonano operatori telecom per rendere il traffico C2 meno sospetto.

Perché le telco sono obiettivi privilegiati dello spionaggio cinese

Le infrastrutture di telecomunicazione rappresentano un obiettivo di primaria importanza per le operazioni di intelligence offensiva. Il controllo, anche parziale, di un operatore telecom offre accesso a metadati di traffico, possibilità di intercettazioni mirate, informazioni su clienti governativi e aziendali, e capacità di prepararsi per operazioni disruptive in scenari di escalation geopolitica. Non è un caso che Showboat sia progettato specificatamente per Linux: i sistemi basati su questo OS costituiscono il backbone infrastrutturale della maggior parte delle telco mondiali. La funzione SOCKS5 rispecchia un obiettivo preciso: muoversi lateralmente e silenziosamente all’interno di reti segmentate, raggiungendo asset normalmente inaccessibili dall’esterno.

Indicatori di compromissione (IoC)

# Showboat - ELF binary (VirusTotal, maggio 2025)
SHA256: d6a4fad5448838dbc8cc6b33f1dbfbdc7a2fad36de58ff6a66dce96f729f7011
# Kaspersky classification: EvaRAT
# C2 infrastructure: IP geolocati a Chengdu (Sichuan, CN)
# Certificati X.509 condivisi tra cluster C2 primario e secondario
# Domini: pattern telecom-themed (impersonazione operatori target)
# Pastebin paste ID: creato 2022-01-11 (autoconcealment snippet)

Due righe per i difensori

Per le organizzazioni del settore telecomunicazioni e infrastrutture critiche, i ricercatori di Black Lotus Labs raccomandano: monitorare il traffico in uscita verso Pastebin e piattaforme di condivisione testo per rilevare scaricamenti di payload; analizzare le connessioni SOCKS5 anomale verso host interni non esposti; verificare l’integrità dei processi su sistemi Linux alla ricerca di tecniche di process hiding; implementare threat hunting specifico per DLL side-loading su endpoint Windows; correlare i certificati X.509 dei server C2 con quelli osservati da Black Lotus Labs. Come ha sottolineato il ricercatore Danny Adamitis: “La presenza di tali minacce dovrebbe essere interpretata come un segnale d’allarme precoce, indicativo di problemi di sicurezza potenzialmente più gravi e diffusi all’interno delle reti compromesse.”

Spcnet.it

2026-05-23 06:08:01

Microsoft Identity Manager 2016 SP3: supporto SQL Server 2022, Azure SQL con Managed Identity e AD FS SSO

MIM 2016 SP3: finalmente disponibile, con un percorso travagliato

Microsoft Identity Manager (MIM) 2016 Service Pack 3 è diventato generalmente disponibile il 14 maggio 2026, dopo una storia piuttosto movimentata: una prima versione era stata rilasciata a fine marzo 2026 ma Microsoft l’aveva silenziosa ritirata senza spiegazioni pubbliche. SP3 si posiziona come un aggiornamento di compatibilità di piattaforma più che una rivisitazione architetturale del prodotto, ma include alcune novità tecnicamente significative per gli scenari ibridi e cloud.

Per chi gestisce ambienti enterprise con Active Directory e sincronizzazione delle identità, MIM rimane un componente critico in molte organizzazioni. Con l’estensione del supporto fino al 9 gennaio 2029 (la data originale era gennaio 2026), Microsoft ha chiarito che il prodotto ha ancora vita davanti a sé, almeno come soluzione di transizione verso Entra ID Governance.

Principali aggiornamenti di compatibilità di piattaforma

SP3 estende la compatibilità ufficiale con le versioni più recenti degli stack Microsoft on-premise e cloud. I componenti aggiornati includono:

• SQL Server 2022 — supporto completo per il database di MIM Service e MIM Synchronization Service
• SharePoint Server Subscription Edition (SE) — il portale MIM può essere ospitato su SharePoint SE
• Exchange Server Subscription Edition (SE) — supporto per la gestione delle cassette postali Exchange tramite MIM
• System Center Service Manager DW 2022 — compatibilità aggiornata per gli scenari di data warehouse
• Windows Server 2025 — supporto per il sistema operativo host aggiornato

Questi aggiornamenti sono fondamentali per le organizzazioni che hanno già migrato i propri server on-premise alle versioni più recenti e si trovavano a gestire MIM su stack non ufficialmente supportati, una situazione rischiosa dal punto di vista del supporto Microsoft.

Azure SQL Database per MIM Synchronization: la novità più rilevante

La novità tecnicamente più interessante di SP3 è il supporto nativo per Azure SQL Database come backend del MIM Synchronization Service, con autenticazione tramite managed identity. Questa funzionalità apre un nuovo scenario di deployment ibrido dove il motore di sincronizzazione di MIM può connettersi a un database gestito nel cloud senza dover gestire credenziali SQL esplicite in chiaro.

System-assigned vs User-assigned Managed Identity

SP3 supporta entrambe le varianti di managed identity per l’autenticazione verso Azure SQL:

• System-assigned managed identity — legata al ciclo di vita del server MIM Sync, viene creata e dismessa automaticamente con la macchina virtuale. Più semplice da configurare, ma meno flessibile in scenari di disaster recovery o migrazione del server.
• User-assigned managed identity — un’identità indipendente che può essere assegnata a più risorse e sopravvive alla VM. Preferita negli ambienti enterprise per la flessibilità e la possibilità di condividere le autorizzazioni tra più istanze server.

In entrambi i casi, la managed identity deve essere configurata come External provider nel database Azure SQL e deve avere il ruolo db_owner (o i permessi minimi necessari) sullo schema MIM. La configurazione lato MIM avviene nel file di configurazione del Synchronization Service, specificando il tipo di autenticazione ActiveDirectoryManagedIdentity nella stringa di connessione.

Considerazioni pratiche sul deployment

Portare il database di MIM Sync su Azure SQL offre vantaggi concreti: alta disponibilità integrata, backup automatici, scaling elastico e riduzione del carico operativo sulla DBA. Tuttavia, le latenze di rete tra il server MIM Sync on-premise e Azure SQL devono essere valutate con attenzione. Cicli di sincronizzazione su connector con milioni di oggetti — come un Full Import su Active Directory con 200.000+ account — potrebbero risentire della latenza aggiuntiva rispetto a un SQL Server locale.

È consigliabile testare questa configurazione in ambiente di staging misurando i tempi dei management agent profile più pesanti (Full Import, Full Sync) prima di portarla in produzione.

AD FS SSO per il portale MIM: claims-based authentication

SP3 introduce il supporto per Active Directory Federation Services (AD FS) con autenticazione SSO basata su claims per il portale MIM. In precedenza, il portale si basava esclusivamente sull’autenticazione Windows integrata (Kerberos/NTLM). Con SP3, gli utenti possono autenticarsi al portale tramite AD FS, il che apre alcune possibilità interessanti:

• Supporto per scenari in cui i client non sono domain-joined (utenti che accedono dall’esterno tramite Web Application Proxy)
• Possibilità di applicare policy di autenticazione più granulari tramite AD FS, inclusi MFA e device compliance
• Percorso di transizione verso Entra ID per organizzazioni che già federano le identità tramite AD FS

La configurazione richiede la registrazione del portale MIM come Relying Party Trust in AD FS e la corretta configurazione delle claim rules per mappare gli attributi utente alle autorizzazioni MIM. Microsoft ha aggiornato la documentazione ufficiale su Microsoft Learn con le istruzioni dettagliate per questo scenario.

Estensione del supporto: una boccata d’aria per i team IT

Forse la notizia più impattante per molte organizzazioni non è tecnica, ma temporale. La data di fine supporto di MIM 2016 è stata estesa dal 13 gennaio 2026 al 9 gennaio 2029 — tre anni in più. Per i team IT che stavano affrontando una corsa contro il tempo per migrare a Entra ID Governance, questa estensione offre una finestra più ampia per pianificare la transizione con la dovuta attenzione.

È comunque importante non interpretare questa estensione come un segnale che MIM riceverà nuove funzionalità significative. Microsoft è chiara: il percorso raccomandato per la gestione del ciclo di vita delle identità punta a Microsoft Entra ID Governance. MIM è in maintenance mode.

Come pianificare l’upgrade a SP3

Per chi gestisce MIM 2016, ecco i passi raccomandati:

1. Verifica la versione corrente — la build di SP3 è 4.7.6.0. Controlla la versione installata tramite Programmi e Funzionalità o il registro di sistema.
2. Consulta la matrice di compatibilità ufficiale su Microsoft Learn per identificare eventuali combinazioni di piattaforma non più supportate.
3. Testa in staging prima della produzione, verificando la compatibilità con management agent personalizzati e regole di sincronizzazione custom.
4. Valuta Azure SQL con managed identity se vuoi ridurre il debito operativo del database on-premise.
5. Pianifica la migrazione a lungo termine verso Entra ID Governance, usando questo upgrade come occasione per documentare i processi attuali.

Conclusione

MIM 2016 SP3 è un aggiornamento pragmatico e necessario per le organizzazioni enterprise che ancora dipendono da questo strumento. L’aggiunta del supporto per Azure SQL con managed identity è la novità più rilevante dal punto di vista architetturale, mentre il supporto AD FS SSO colma una lacuna significativa per i deployment con accesso esterno al portale. L’estensione del supporto al 2029 completa il quadro, dando ai team IT il tempo necessario per una migrazione pianificata e non forzata verso le soluzioni cloud-native di Microsoft.

---

Fonti: 4sysops — MIM 2016 SP3 | Microsoft Learn — MIM 2016 news and updates | Identity Manager version history

Supported software platforms

Find the products and versions that are compatible with each of the MIM 2016 components

^{learn.microsoft.com}