Consulente ICT ICT Consultant

Il Problema: L'escalation di privilegi tramite Kerberoasting

Immagine generata con Gemini AI

Active Directory (AD) è il cuore pulsante delle infrastrutture aziendali, ma le sue configurazioni legacy lo rendono un bersaglio primario. Uno degli attacchi più letali e silenziosi è il Kerberoasting. Gli attaccanti, pur avendo accesso con un account utente standard senza privilegi, possono richiedere i ticket di servizio (TGS) per qualsiasi account associato a un Service Principal Name (SPN). Poiché questi ticket sono cifrati con l'hash della password dell'account di servizio, gli hacker li esportano offline per tentare attacchi di brute-force ed estrarre la password in chiaro.

La Soluzione: Hardening degli SPN e policy crittografiche

La mitigazione di questa vulnerabilità richiede un approccio a due livelli, agendo sia sulla complessità delle credenziali che sugli algoritmi di cifratura utilizzati dal dominio.

1. Password complesse per i Service Account

La difesa più efficace contro il cracking offline è la lunghezza. Gli account di servizio con SPN registrati (come quelli usati per SQL Server o IIS) devono avere password generate casualmente di almeno 30 caratteri. Implementa le Managed Service Accounts (gMSA) dove possibile, affinché Windows gestisca e ruoti automaticamente queste password complesse in totale trasparenza.

2. Disabilitare la cifratura RC4

I ticket cifrati con il vecchio protocollo RC4 sono triviali da forzare. Forza l'utilizzo di AES-256 modificando la Group Policy Object (GPO) del dominio:

# Imposta i tipi di crittografia supportati per Kerberos tramite GPO
# Percorso: Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options
# Network security: Configure encryption types allowed for Kerberos
# Selezionare solo: AES128_HMAC_SHA1 e AES256_HMAC_SHA1

Una volta applicata la GPO, gli attaccanti che tenteranno di esportare i ticket si scontreranno con un algoritmo matematicamente impraticabile da forzare in tempi utili.

The Problem: The Overhead of Remote Desktop (RDP)

Image generated with Gemini AI

Managing dozens of Windows Servers by constantly opening Remote Desktop (RDP) sessions is slow, bandwidth-heavy, and often leaves orphaned GUI sessions hanging on the system. Furthermore, exposing the RDP protocol (port 3389) across inter-office networks unnecessarily increases the corporate attack surface.

The Solution: PowerShell Remoting via WinRM

The modern, scalable solution for IT Management is PowerShell Remoting. By utilizing the native WinRM (Windows Remote Management) protocol, you can open interactive sessions or execute batch scripts on remote machines directly from your terminal, exactly like you do with SSH on Linux.

1. Enabling WinRM on the Target Server

Log in to the target server (or deploy via Group Policy, GPO, if you are in an Active Directory environment) and open a PowerShell console with Administrator privileges. Execute the quick configuration cmdlet:

Enable-PSRemoting -Force

This command starts the WinRM service, sets it to start automatically, and creates the default firewall rules (TCP port 5985 HTTP). However, in zero-trust environments, HTTP is not enough.

2. Hardening: Forcing HTTPS (Port 5986)

To encrypt traffic at the transport layer and prevent Man-In-The-Middle attacks, you must bind WinRM to an SSL certificate. Assuming you have generated or requested a certificate for the server (via corporate PKI), you can create an HTTPS listener using PowerShell:

# Retrieve the certificate thumbprint
$Cert = Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object { $_.Subject -match "YourServerName" }
$Thumbprint = $Cert.Thumbprint

# Configure the HTTPS listener
New-Item -Path WSMan:\LocalHost\Listener -Transport HTTPS -Address * -CertificateThumbPrint $Thumbprint -Force

Do not forget to open port 5986 on the Windows Server firewall.

3. Initiating the Connection from the Client

Now, from your Sysadmin workstation, you can connect to the server in total security by opening an interactive session:

Enter-PSSession -ComputerName YourServerName -UseSSL -Credential (Get-Credential)

Your terminal prompt will change, confirming that every command you type from that moment on is executing locally on the remote server.

Il Problema: La Pesantezza del Remote Desktop (RDP)

Immagine realizzata con Gemini AI

Gestire dozzine di server Windows Server aprendo sessioni in Desktop Remoto (RDP) è lento, consuma banda e lascia sessioni grafiche orfane appese nel sistema. Inoltre, esporre il protocollo RDP (porta 3389) sulle reti inter-ufficio aumenta inutilmente la superficie di attacco aziendale.

La Soluzione: PowerShell Remoting via WinRM

La soluzione moderna e scalabile per l'IT Management è PowerShell Remoting. Utilizzando il protocollo nativo WinRM (Windows Remote Management), puoi aprire sessioni interattive o eseguire script in batch su macchine remote direttamente dal tuo terminale, proprio come fai con SSH su Linux.

1. Abilitare WinRM sul Server Destinazione

Collegati al server target (o usa una Group Policy, GPO, se sei in un ambiente Active Directory) e apri una console PowerShell con privilegi di Amministratore. Esegui il comando di configurazione rapida:

Enable-PSRemoting -Force

Questo comando avvia il servizio WinRM, lo imposta su avvio automatico e crea le regole predefinite sul firewall (porte TCP 5985 HTTP). Tuttavia, in ambienti zero-trust, HTTP non basta.

2. Hardening: Forzare HTTPS (Porta 5986)

Per criptare il traffico a livello di trasporto e prevenire attacchi Man-In-The-Middle, devi vincolare WinRM a un certificato SSL. Supponendo di aver generato o richiesto un certificato per il server (via PKI aziendale), puoi creare un listener HTTPS tramite PowerShell:

# Recupera il thumbprint del certificato
$Cert = Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object { $_.Subject -match "IlTuoServer" }
$Thumbprint = $Cert.Thumbprint

# Configura il listener HTTPS
New-Item -Path WSMan:\LocalHost\Listener -Transport HTTPS -Address * -CertificateThumbPrint $Thumbprint -Force

Non dimenticare di aprire la porta 5986 sul firewall di Windows Server.

3. Eseguire la Connessione dal Client

Ora, dalla tua postazione di lavoro Sysadmin, puoi connetterti al server in totale sicurezza aprendo una sessione interattiva:

Enter-PSSession -ComputerName IlTuoServer -UseSSL -Credential (Get-Credential)

Il terminale cambierà prompt, confermandoti che ogni comando che scriverai da quel momento in poi verrà eseguito localmente sul server remoto.

Image generated with Gemini AI

The Problem: Cleartext Passwords in Source Code

Automation via scripting is the beating heart of system administration. However, hardcoding credentials (passwords, API tokens, cryptographic keys) in cleartext inside .sh or .ps1 files is a critical security violation. Anyone with read access to the file system or the Git repository compromises the entire corporate ecosystem.

The Solution: Encrypted Secrets Management

We must decouple the script's logic from the sensitive data by leveraging the operating system's native protection mechanisms.

1. In PowerShell Environments (Windows)

In Microsoft infrastructures, we can use Export-Clixml to encrypt a credential object. The encryption is tightly bound to the user account that generated it and the physical machine (thanks to the Windows Data Protection API).

# Run once to save the encrypted password
Get-Credential | Export-Clixml -Path "C:\secure\admin_creds.xml"

# In the production script, call the file:
$cred = Import-Clixml -Path "C:\secure\admin_creds.xml"

2. In Bash Environments (Linux)

On Unix systems, the most immediate, zero-cost method to protect daemons and cron scripts is to isolate variables into a separate configuration file, restricting permissions exclusively to the root user.

# Create the protected configuration file
echo "DB_PASS='SuperSecret!'" > /etc/script_secrets.conf
sudo chmod 400 /etc/script_secrets.conf

In the main script (executed with elevated privileges), simply import the variables using the source /etc/script_secrets.conf command. The code remains clean, and credentials remain invisible to unauthorized users.

Il Problema: Password in Chiaro nei Sorgenti

L'automazione tramite scripting è il cuore nevralgico della gestione sistemistica. Tuttavia, hardcodare credenziali (password, token API, chiavi crittografiche) in chiaro all'interno di file .sh o .ps1 è una violazione critica della sicurezza. Chiunque abbia accesso in lettura al file system o al repository Git compromette l'intero ecosistema aziendale.

Immagine realizzata con Gemini AI

La Soluzione: Gestione Cifrata dei Segreti

Dobbiamo disaccoppiare la logica dello script dal dato sensibile, sfruttando i meccanismi di protezione nativi del sistema operativo.

1. In Ambiente PowerShell (Windows)

In infrastrutture Microsoft, possiamo usare Export-Clixml per cifrare un oggetto credenziale. La cifratura è legata a doppio filo all'account utente che l'ha generata e alla macchina fisica (grazie alle API di Data Protection di Windows).

# Eseguire una volta per salvare la password cifrata
Get-Credential | Export-Clixml -Path "C:\secure\admin_creds.xml"

# Nello script di produzione, richiamare il file:
$cred = Import-Clixml -Path "C:\secure\admin_creds.xml"

2. In Ambiente Bash (Linux)

Nei sistemi Unix, il metodo più immediato e a costo zero per proteggere i demoni e gli script cron è isolare le variabili in un file di configurazione separato, restringendo i permessi esclusivamente all'utente root.

# Creare il file di configurazione protetto
echo "DB_PASS='SuperSegreta!'" > /etc/script_secrets.conf
sudo chmod 400 /etc/script_secrets.conf

Nello script principale (eseguito con privilegi elevati), basta importare le variabili con il comando source /etc/script_secrets.conf. Il codice rimane pulito e le credenziali risultano invisibili agli utenti non autorizzati.

When managing an IT infrastructure, relying on consumer GUI tools like Microsoft's PC Health Check app to verify Windows 11 compatibility isn't scalable. As sysadmins, we need automated, fast tools that provide clear text output to integrate into broader deployment scripts.

The two most critical (and often blocking) requirements for upgrading from Windows 10 to Windows 11 concern hardware security: the presence of TPM 2.0 (Trusted Platform Module) and the enablement of Secure Boot at the UEFI level.

I wrote a quick PowerShell script that queries the operating system directly to extract this information without needing to reboot the machine or enter the BIOS/UEFI.

The Script

You can run this code block by opening PowerShell with Administrator privileges. The script checks the TPM status and Secure Boot configuration, returning immediate color-coded feedback.

<#
.SYNOPSIS
    Verifies system readiness for the Windows 11 upgrade (Focus on TPM and Secure Boot).
.DESCRIPTION
    The script checks if the TPM module is present, ready, and version 2.0.
    It also verifies whether Secure Boot is enabled in the UEFI firmware.
#>

Write-Host "=========================================" -ForegroundColor Cyan
Write-Host "  Windows 11 Requirements Check          " -ForegroundColor Cyan
Write-Host "=========================================`n" -ForegroundColor Cyan

# 1. Check TPM
Write-Host "[*] Checking TPM module..."
try {
    $tpm = Get-Tpm
    if ($tpm.TpmPresent) {
        # The TpmReady property indicates if it is ready for use
        if ($tpm.TpmReady) {
            Write-Host "    [OK] TPM detected and ready for use." -ForegroundColor Green
        } else {
            Write-Host "    [WARNING] TPM present but not initialized." -ForegroundColor Yellow
        }
    } else {
        Write-Host "    [ERROR] No TPM module detected on the motherboard." -ForegroundColor Red
    }
} catch {
    Write-Host "    [ERROR] Cannot query TPM. Ensure you are running as Administrator." -ForegroundColor Red
}

# 2. Check Secure Boot
Write-Host "`n[*] Checking Secure Boot..."
try {
    $secureBoot = Confirm-SecureBootUEFI
    if ($secureBoot) {
        Write-Host "    [OK] Secure Boot enabled in UEFI firmware." -ForegroundColor Green
    } else {
        Write-Host "    [ERROR] Secure Boot is disabled. You need to enable it in BIOS/UEFI." -ForegroundColor Red
    }
} catch {
    Write-Host "    [ERROR] Cmdlet not supported or system in Legacy BIOS mode (non-UEFI)." -ForegroundColor Red
}

Write-Host "`n=========================================" -ForegroundColor Cyan
Write-Host "Check complete." -ForegroundColor Cyan

How does it work under the hood?

Get-Tpm: This is a native Windows cmdlet that returns an object containing the details of the Trusted Platform Module. We check TpmPresent and TpmReady to ensure not only that the chip exists, but that it has been properly activated at the OS level.

Confirm-SecureBootUEFI: This cmdlet directly queries the firmware variables. If it returns True, Secure Boot is active. If the script falls into the catch block, it is highly likely that the system drive is MBR-partitioned and booting in Legacy BIOS mode (which prevents the installation of Windows 11).

Conclusion and Future Developments

This script is a great starting point for a security baseline. In Enterprise environments, these checks can be integrated into a larger PowerShell module, perhaps executed via GPO or RMM, to generate a CSV report of all machines in the corporate fleet that are ready (or not) for the new OS rollout.

You can find this and other automation scripts on my GitHub.

Quando si gestisce un'infrastruttura IT, affidarsi a tool grafici "consumer" come l'app Controllo integrità PC di Microsoft per verificare la compatibilità a Windows 11 non è scalabile. Come sistemisti, abbiamo bisogno di strumenti automatizzabili, rapidi e che forniscano output testuali chiari da poter integrare in script di deploy più ampi.

I due requisiti più critici (e spesso bloccanti) per l'upgrade da Windows 10 a Windows 11 riguardano la sicurezza hardware: la presenza del TPM 2.0 (Trusted Platform Module) e l'abilitazione del Secure Boot a livello UEFI.

Ho scritto un rapido script in PowerShell che interroga direttamente il sistema operativo per estrarre queste informazioni senza dover riavviare la macchina o entrare nel BIOS/UEFI.

<#
.SYNOPSIS
    Verifica la prontezza del sistema per l'upgrade a Windows 11 (Focus su TPM e Secure Boot).
.DESCRIPTION
    Lo script controlla se il modulo TPM è presente, pronto e in versione 2.0.
    Verifica inoltre se il Secure Boot è abilitato nel firmware UEFI.
#>

Write-Host "=========================================" -ForegroundColor Cyan
Write-Host "  Verifica Requisiti Windows 11          " -ForegroundColor Cyan
Write-Host "=========================================`n" -ForegroundColor Cyan

# 1. Verifica TPM
Write-Host "[*] Controllo modulo TPM..."
try {
    $tpm = Get-Tpm
    if ($tpm.TpmPresent) {
        # La proprietà TpmReady indica se è pronto all'uso
        if ($tpm.TpmReady) {
            Write-Host "    [OK] TPM rilevato e pronto all'uso." -ForegroundColor Green
        } else {
            Write-Host "    [WARNING] TPM presente ma non inizializzato." -ForegroundColor Yellow
        }
    } else {
        Write-Host "    [ERRORE] Nessun modulo TPM rilevato sulla scheda madre." -ForegroundColor Red
    }
} catch {
    Write-Host "    [ERRORE] Impossibile interrogare il TPM. Assicurati di eseguire come Amministratore." -ForegroundColor Red
}

# 2. Verifica Secure Boot
Write-Host "`n[*] Controllo Secure Boot..."
try {
    $secureBoot = Confirm-SecureBootUEFI
    if ($secureBoot) {
        Write-Host "    [OK] Secure Boot abilitato nel firmware UEFI." -ForegroundColor Green
    } else {
        Write-Host "    [ERRORE] Secure Boot disabilitato. È necessario attivarlo nel BIOS/UEFI." -ForegroundColor Red
    }
} catch {
    Write-Host "    [ERRORE] Cmdlet non supportata o sistema in modalità BIOS Legacy (non UEFI)." -ForegroundColor Red
}

Write-Host "`n=========================================" -ForegroundColor Cyan
Write-Host "Controllo terminato." -ForegroundColor Cyan

Come funziona sotto il cofano?

Get-Tpm: È una cmdlet nativa di Windows che restituisce un oggetto contenente i dettagli del Trusted Platform Module. Verifichiamo TpmPresent e TpmReady per assicurarci non solo che il chip esista, ma che sia stato attivato correttamente a livello di sistema operativo.

Confirm-SecureBootUEFI: Questa cmdlet interroga direttamente le variabili firmware. Se restituisce True, il Secure Boot è attivo. Se lo script finisce nel blocco catch, è altamente probabile che il disco di sistema sia partizionato in MBR e avvii in modalità Legacy BIOS (che impedisce l'installazione di Windows 11).

Conclusioni e Sviluppi Futuri

Questo script è un ottimo punto di partenza per una baseline di sicurezza. In ambienti Enterprise, questi controlli possono essere integrati in un modulo PowerShell più grande, magari eseguito tramite GPO o RMM, per generare un report CSV di tutte le macchine del parco aziendale pronte (o meno) per il rollout del nuovo OS.

Trovate questo e altri script di automazione sul mio GitHub.