Spcnet.it

2026-05-16 06:34:12

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

Cos’è Microsoft DSC v3 e perché è importante

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

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

Come installare DSC v3.2.0

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

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

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

Nuove risorse Windows built-in

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

Le nuove risorse disponibili sono le seguenti:

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

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

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

Version pinning: configurazioni stabili e riproducibili

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

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

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

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

Supporto –what-if sulle singole risorse

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

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

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

Integrazione sperimentale con Bicep via gRPC

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

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

Miglioramenti al linguaggio di espressione

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

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

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

Adapter PowerShell: trace automatica e manifest adattati

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

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

Conclusione

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

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

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

Announcing Microsoft Desired State Configuration v3.2.0 - PowerShell Team

This post announces the General Availability of Microsoft Desired State Configuration (DSC) v3.2.0, with new Windows resources, Bicep gRPC integration, WhatIf support, expression language improvements, and adapter enhancements.

^{Jason Helmick (PowerShell Team)}

Ransomfeed

2026-05-15 15:23:23

Big milestone for Ransomfeed today 🚨

After the review process, the Ransomfeed connector for OpenCTI has now been officially approved ✅

This means that starting from this release, Ransomfeed will become part of the official OpenCTI connector ecosystem. ⏭️

#ThreatIntelligence

Release 7.260515.0 of OpenCTI/connectors official project, now show Ransomfeed contributor on code ❤️

Statement here: ransomfeed.it/?page=comunicati…

Release notes: github.com/OpenCTI-Platform/co…

Release Version 7.260515.0 · OpenCTI-Platform/connectors

Enhancements: #4919 [MISP] Add an option configuration to let users map the MISP threat level value on an OpenCTI score #4450 [CybelAngel] Create a connector #4413 [ransomfeed]: Create an external...

^GitHub

(in)sicurezza digitale

2026-05-15 09:04:54

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

Si parla di:
Toggle

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

Il messaggio che non inganna (ma quasi)

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

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

Il meccanismo tecnico: device linking via codice OTP

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

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

ApocalypseZ: la piattaforma di attacco di Stato

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

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

La “snowball hypothesis”: come si espande il targeting

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

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

Scala e attribuzione: 13.500 bersagli e CISA

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

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

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

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

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

Indicatori e vettori di attacco

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

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

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

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

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

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

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

Due righe per i difensori

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

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

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

Destinazione Stelle

2026-05-14 06:49:03

Sono finiti da poco i test ambientali di Blue Moon Mark 1, noto anche come Endurance: un lander lunare senza equipaggio sviluppato da Blue Origin, l’azienda spaziale di Jeff Bezos, il proprietario di Amazon.

I test termici si sono svolti nella colossale Camera A del Johnson Space Center, una struttura alta 36 metri, quanto un palazzo di dodici piani, costruita molti anni fa per il programma Apollo.

Questo tipo di test, chiamato in gergo “termovuoto”, è la mia specializzazione professionale. Per i satelliti è il collaudo più importante che si possa fare prima del lancio, perché riproduce le condizioni di vuoto e temperature estreme dello spazio e permette di verificare che il sistema funzioni correttamente in un ambiente del tutto diverso da quello a cui siamo abituati sulla Terra.

Una volta avviata, una campagna di termovuoto va avanti giorno e notte per settimane, con squadre di tecnici che si danno il cambio per simulare le operazioni più importanti previste durante la missione. Non può essere sostituito da simulazioni al computer, perché la combinazione del vuoto e delle temperature estreme calde e fredde può far emergere problemi che a temperatura e pressione ambiente non ci sarebbero e che non sono pienamente prevedibili. In vita mia ho fatto una trentina di test di questo genere e ogni volta ho incontrato qualche imprevisto che ha richiesto lavoro di gruppo e creatività per essere risolto. Per chi lavora nel settore il termovuoto è uno dei momenti più delicati, faticosi e gratificanti dello sviluppo di un veicolo spaziale.

La missione di Endurance è prevista per quest’anno, con un atterraggio nella regione del Polo Sud lunare. Servirà a dimostrare capacità di propulsione, navigazione e atterraggio essenziali per le successive missioni con equipaggio del lander Mark 2, nell’ambito del programma Artemis. Inoltre Endurance trasporterà sulla Luna due payload: un sistema di telecamere ad alta risoluzione che studierà l'interazione tra il getto dei motori del lander e la superficie lunare durante la discesa e l'atterraggio e un sistema laser che consentirà ai veicoli spaziali in orbita di determinare la propria posizione in modo più accurato.

Lo scorso mese di aprile il lanciatore New Glenn di Blue Origin ha avuto un problema al secondo stadio che ha impedito il corretto dispiegamento di un satellite in orbita bassa. Anche lo sviluppo del lander concorrente di SpaceX sta incontrando contrattempi. Se la missione di Endurance avrà successo, rafforzerà la posizione di Blue Origin come fornitore di lander lunari e sarà un segnale positivo per tutto il programma Artemis. Al contrario, problemi significativi potrebbero comportare ulteriori ritardi nel ritorno americano sulla Luna.