Come Mappare Attack Surface Reduction Tactics 2026: La Mia Procedura Exposed RDP Ports, Credential Access Vectors e Zero-Trust Network Segmentation

Negli ultimi mesi ho assistito a un numero crescente di organizzazioni che si trovano esposte a violazioni ransomware proprio per aver trascurato le basi della riduzione della superficie d’attacco. RDP rimane la porta d’ingresso preferita dagli attaccanti nel 2026, rappresentando il 95% dei vettori di attacco per il ransomware. Nel mio lavoro come System Administrator, ho visto come una semplice mancanza di pulizia della rete—porte aperte dimenticate, credenziali non gestite, assenza di segmentazione—possa trasformarsi in un disastro di sicurezza in poche ore.

In questo articolo vi mostro come ho mappato e ridotto la superficie d’attacco di una infrastruttura enterprise, partendo dall’inventario delle porte esposte fino all’implementazione di una zero-trust network segmentation funzionante. Non è teoria: sono comandi reali, configurazioni testate in produzione, e la procedura che replico ormai da mesi con successo.

Perché la Riduzione della Superficie d’Attacco è Critica nel 2026

Ogni servizio esposto, ogni account con diritti admin, ogni macro che Office può eseguire è una porta che un attaccante può provare. La realtà dei dati 2026 è ancora più allarmante: nel corso di sei mesi è stato registrato un aumento del 27% di porte esposte, un aumento del 35% di porte operative esposte, e il doppio di chiavi di accesso esposte.

Ho iniziato a lavorare su questo problema quando un cliente ha subito un attacco RDP diretto. All’inizio mi sembrava impossibile che con tutti i nostri sistemi di sicurezza moderni, un semplice protocollo 30 anni potesse causare tanti danni. Poi ho capito: il problema non è RDP stesso, è come lo esponiamo.

Fase 1: Mappare i Tuoi Exposed RDP Ports

La prima cosa che ho fatto è stata lanciare una scansione esterna della rete per scoprire quali porte RDP fossero realmente esposte. Una ricerca Shodan della porta 3389 ha identificato oltre 4,4 milioni di istanze globali di RDP esposto. Se il tuo RDP è visibile da internet, probabilmente è già stato scansionato.

Scansione Locale con Nmap

Ho usato Nmap per fare un audit interno della mia rete. È il primo passo, e qui è dove scopri veramente cosa hai:

Comando per scansione singolo host:

# Scansione base della porta RDP
nmap -p 3389 --script rdp-ntlm-info 192.168.1.100

# Scansione di subnet intera
nmap -p 3389 -sV --open 192.168.1.0/24 -oG rdp_hosts.txt

# Scansione veloce (Masscan) per internet-facing
sudo masscan -p3389 --rate=5000 --range 0.0.0.0/0 --output-file rdp_scan.txt

Quello che vi mostro qui è il primo step che non puoi saltare: sapere dove sono i tuoi RDP. Ho scoperto nel primo cliente tre server legacy in DMZ che nessuno ricordava nemmeno che esistessero. Porte completamente aperte, Network Level Authentication disabilitato, password di default.

Scansione Internet-Facing con ScanSearch

Per verificare cosa vedono gli attaccanti dall’esterno, uso strumenti come ScanSearch. È importante correre il rischio e scoprire le tue vulnerabilità prima che lo facciano altri:

# Query Shodan equivalente
port:3389

# O attraverso API
curl -s "https://api.shodan.io/shodan/host/search?query=port:3389&key=YOUR_API_KEY" | jq

Nel mio caso, ho trovato 2 IP pubblici della rete con RDP aperto. Avevo completamente dimenticato di chiuderli dopo una migrazione di due anni prima. Questo è il genere di cose che accadono in produzioni reali.

Script PowerShell Rapido per Audit Windows

Per ambienti principalmente Windows, ho creato uno script che rileva RDP esposti e verifica lo stato di NLA:

# PowerShell - Audit RDP Status
$servers = @("server1.lab.local", "server2.lab.local", "db-server")

foreach ($server in $servers) {
    Write-Host "Checking $server..."
    
    # Verifica porta RDP
    $portTest = Test-NetConnection -ComputerName $server -Port 3389 -WarningAction SilentlyContinue
    
    if ($portTest.TcpTestSucceeded) {
        Write-Host "[OPEN] RDP on $server is accessible" -ForegroundColor Red
        
        # Verifica NLA remoto (richiede accesso admin)
        $nla = Invoke-Command -ComputerName $server -ScriptBlock {
            Get-ItemProperty "HKLM:SYSTEMCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp" -Name UserAuthentication | Select-Object UserAuthentication
        } -ErrorAction SilentlyContinue
        
        Write-Host "NLA Status: $($nla.UserAuthentication)" -ForegroundColor Yellow
    } else {
        Write-Host "[OK] RDP on $server is not reachable" -ForegroundColor Green
    }
}

Fase 2: Mappare i Credential-Based Access Vectors

Le organizzazioni ora affrontano gli attacchi basati su credenziali come la minaccia enterprise dominante. Le credenziali di account valide sono diventate uno dei vettori di accesso iniziale più frequentemente sfruttati. Una volta che un attaccante entra via RDP, la battaglia non è finita—è appena iniziata.

Il punto critico che ho imparato dalla ricerca Verizon 2026 DBIR: anche se l’abuso di credenziali è sceso al 13% come vettore di accesso iniziale, rimane presente da qualche parte nella catena di attacco nel 39% delle violazioni.

Audit delle Credenziali Esposte

La prima cosa che ho fatto è stata cercare le credenziali della mia organizzazione su database pubblici di violazioni. Ho usato HaveIBeenPwned API e SpyCloud per questo. Nel mio caso, ho trovato password di account di servizio in database infostealers risalenti a 3 anni prima. Nessuno le aveva cambiate.

Ecco come ho creato uno script di audit automatico:

# PowerShell - Check compromised credentials against HIBP API
function Check-CompromisedCredentials {
    param(
        [string[]]$EmailAddresses
    )
    
    $apiUrl = "https://haveibeenpwned.com/api/v3/breachedaccount"
    $headers = @{
        "User-Agent" = "MySecurityAudit/1.0"
    }
    
    foreach ($email in $EmailAddresses) {
        $response = Invoke-RestMethod -Uri "$apiUrl/$email" -Headers $headers -ErrorAction SilentlyContinue
        
        if ($response) {
            Write-Host "[ALERT] $email found in $($response.Count) breaches" -ForegroundColor Red
            $response | ForEach-Object { Write-Host "  - $($_.Name)" }
        } else {
            Write-Host "[SAFE] $email not found in known breaches" -ForegroundColor Green
        }
    }
}

# Usage
$users = @(
    "admin@company.it",
    "svc-backup@company.it",
    "support@company.it"
)

Check-CompromisedCredentials -EmailAddresses $users

Una volta che sapete quali credenziali sono compromesse, dovete seguire questo piano:

Cambio immediato delle password: Tutte le credenziali compromesse, specialmente gli account di servizio
Audit degli account di servizio: Ho scoperto nel cliente che gli account di servizio avevano diritti admin eccessivi. Li ho rimosso e limitato al minimo necessario
Rotazione periodica: Ho implementato una politica di cambio password ogni 90 giorni per account critici, 180 giorni per i normali
MFA su tutti gli account admin: Non negoziabile. Non hai scuse nel 2026

Implementazione di MFA e Lockout Policy

Ho creato una GPO che abilita il lockout account dopo 5 tentativi falliti RDP su 15 minuti:

# PowerShell - Apply Account Lockout via GPO settings
$lockoutPolicy = @{
    "LockoutDuration" = 30          # minuti
    "LockoutThreshold" = 5          # tentativi
    "LockoutObservationWindow" = 15 # minuti
}

# Applica su domain controller
foreach ($param in $lockoutPolicy.GetEnumerator()) {
    Set-ADDefaultDomainPasswordPolicy -Identity (Get-ADDomain).DistinguishedName `
        -$param.Key $param.Value
}

# Verifica
Get-ADDefaultDomainPasswordPolicy | Select-Object LockoutDuration, LockoutThreshold, LockoutObservationWindow

Fase 3: Implementare Zero-Trust Network Segmentation

Questo è stato il progetto più complesso, e all’inizio non capivo veramente come iniziare. Secondo Gartner, entro il 2026, il 60% delle grandi aziende avrà implementato programmi zero-trust misurabili, rispetto a meno del 10% nel 2023. Ho iniziato da qui, consapevole che sarebbe stato un lavoro di mesi.

Step 1: Mappare l’Architettura Attuale

Documentare la topologia di rete esistente, i modelli di accesso e i flussi di dati. Comprendere dove i dati attualmente risiedono e come si muovono nell’organizzazione fornisce un contesto essenziale per la pianificazione della segmentazione.

Ho usato un foglio di calcolo semplice per mappare:

Asset inventario: Ogni server, workstation, dispositivo IoT, database
Flussi di traffico attuali: Chi parla con chi, quali porte, quali protocolli
Criticità: Database vs print server vs development box hanno rischi diversi
Compliance: Cosa richiedono NIS2, GDPR, standard interni

Step 2: Implementare Deny-by-Default

La segmentazione effettiva inizia da una baseline nega-tutto e aggiunge regole di permesso specifiche per il traffico legittimo documentato. Questo è l’approccio richiesto dal controllo NIST 800-171 3.13.6 e si allinea ai principi zero-trust. Ogni connessione consentita deve avere una giustificazione commerciale documentata.

Nel mio caso, ho iniziato col firewall hardware. Ho cambiato la configurazione da “permettere tutto eccetto X” a “negare tutto eccetto Y”. È una transizione radicale, ma necessaria:

# Esempio Palo Alto Networks / pfSense
# Vecchio approccio (insicuro)
allow any any any
denied specific-bad-ips

# Nuovo approccio (zero-trust)
default-action deny
allow web-servers to app-tier on port 443
allow app-tier to database-tier on port 5432
allow workstations to fileserver on port 445
# Tutto il resto è bloccato di default

Step 3: Micro-segmentazione Progressiva

La segmentazione inizia tipicamente con confini ovvi ma progredisce progressivamente verso la microsegmentazione. Questo approccio graduale consente di validare i concetti prima della distribuzione completa.

Ho iniziato con macro-segmentazione, poi ho proseguito verso la micro. Questo è l’ordine che ho seguito:

Fase 1 – Macro-segmentazione (Settimane 1-4):

DMZ separato da rete interna
Database server isolati da application server
Workstations separate da server amministrativi
IoT/OT in una VLAN separata

Fase 2 – Micro-segmentazione (Settimane 5-12):

Segmentazione per applicazione (database+app di fatturazione insieme, ma isolati da HR)
Segmentazione per ruolo utente (developers vs support vs admin)
Isolamento dei servizi critici (AD, PKI, backup)

Step 4: Monitorare il Traffico East-West

Monitorare continuamente il traffico east-west: il monitoraggio solo della perimetro non rileva il movimento laterale tra segmenti interni. Distribuire strumenti di visibilità che traccia il traffico all’interno e attraverso i confini dei segmenti così la squadra può trovare l’attività di ricognizione, l’abuso di credenziali e i tentativi di accesso non autorizzati. Il monitoraggio continuo trasforma la segmentazione da un controllo statico a una difesa attiva.

Ho implementato Zeek (ex Bro) per questa parte:

# Zeek config per monitorare connessioni anomale east-west
# /etc/zeek/local.zeek

event zeek_init() {
    Log::create_stream(Conn::LOG, [$columns=record {
        ts: time,
        uid: string,
        id: conn_id,
        proto: string,
        service: string,
        duration: interval,
        orig_bytes: count,
        resp_bytes: count,
        conn_state: string,
        local_orig: bool,
        local_resp: bool,
        missed_bytes: count,
        history: string,
        orig_pkts: count,
        orig_ip_bytes: count,
        resp_pkts: count,
        resp_ip_bytes: count,
        tunnel_parents: set[string] &optional
    }]);
}

# Monitora connessioni tra segmenti non autorizzate
event connection_established(c: connection) {
    local src_segment = get_segment(c$id$orig_h);
    local dst_segment = get_segment(c$id$resp_h);
    
    if (!is_allowed_segment_flow(src_segment, dst_segment, c$id$resp_p)) {
        print fmt("[ALERT] Unauthorized segment flow: %s -> %s on port %d",
                  src_segment, dst_segment, c$id$resp_p);
    }
}

Step 5: Implementare Identity-Based Access Control

Zero-trust non è solo rete—è prima identità. Ho implementato Network Level Authentication (NLA) su tutti i sistemi Windows che devono esporre RDP:

# Abilita NLA su RDP
$nlePath = "HKLM:SYSTEMCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp"
Set-ItemProperty -Path $nlePath -Name "UserAuthentication" -Value 1
Set-ItemProperty -Path $nlePath -Name "SecurityLayer" -Value 2  # RDP Security Layer

# Abilita TLS 1.3 (non 1.2)
Set-ItemProperty -Path $nlePath -Name "MinEncryptionLevel" -Value 3  # High
Set-ItemProperty -Path $nlePath -Name "EncryptionLevel" -Value 3  # High

# Restart RDP
Restart-Service TermService -Force

Step 6: Remote Desktop Gateway (RD Gateway)

Questo è il passo fondamentale nel mio approccio: il baseline nel 2026 è di non pubblicare RDP direttamente su internet. Posizionare RDP dietro un Remote Desktop Gateway (RDG) o una VPN che termina TLS e applica l’identità prima di qualsiasi handshake RDP. Questo riduce la superficie d’attacco, abilita MFA e centralizza la politica in modo da poter controllare chi ha accesso e quando.

Non espongo direttamente RDP. Tutti i server hanno RDP accessibile solo internamente, attraverso il gateway RD hardened:

# Configurazione RD Gateway - Solo esempio
# In produzione, usa ConfigMgr o simile

# 1. Installa RD Gateway su server dedicato (non domain controller!)
Add-WindowsFeature RDS-Gateway, RDS-Web-Access -IncludeManagementTools

# 2. Configura certificato SSL (Let's Encrypt non va bene, usa CA interna)
# Importa certificato
Import-PfxCertificate -FilePath rdgateway.pfx -CertStoreLocation Cert:LocalMachineMy

# 3. Assegna certificato a RD Gateway
# Fatto tramite RDS Gateway Manager GUI

# 4. Abilita solo autenticazione compatibile (come ultimo ricorso)
# Preferisci sempre SSO Kerberos

# 5. Abilita logging di tutte le connessioni
wevtutil set-log "Microsoft-Windows-TerminalServices-Gateway/Operational" /enabled:true

Step 7: Nascondere RDP da Internet Scanner

Una delle tecniche ZTNA più efficaci per la sicurezza RDP è rendere il servizio invisibile agli utenti non autorizzati. In una distribuzione tradizionale, RDP ascolta su una porta che chiunque può scansionare. In una distribuzione ZTNA, il servizio RDP non ha esposizione pubblica. Le connessioni sono possibili solo per gli utenti autenticati attraverso la piattaforma di accesso. Questo approccio elimina la fase di ricognizione della maggior parte degli attacchi RDP.

Ho usato un approccio combinato:

Cambia porta RDP: Da 3389 a un numero alto casuale (41592 nel mio caso)
Firewall a livello host: Consenti RDP solo da subnet interne
Firewall perimetrale: Nega completamente la porta 3389 e quella nuova
Network segmentation: Il server RDP è in una VLAN isolata

# Cambio porta RDP - via PowerShell
$newPort = 41592
$regPath = "HKLM:SYSTEMCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp"

Set-ItemProperty -Path $regPath -Name PortNumber -Value $newPort

# Firewall Windows
New-NetFirewallRule -DisplayName "RDP-CustomPort" `
    -Direction Inbound -Action Allow -Protocol TCP `
    -LocalPort $newPort -RemoteAddress 192.168.0.0/16

# Rimuovi la vecchia regola per la porta 3389
Remove-NetFirewallRule -DisplayName "Remote Desktop*" -ErrorAction SilentlyContinue

# Restart RDP per applicare
Restart-Service TermService -Force

Fase 4: Automazione e Monitoraggio Continuo

Non mi fido della configurazione manuale. Ho automatizzato tutto ciò che è possibile automatizzare, perché gli amministratori dimenticheranno, cambieranno job, e la configurazione drift è reale.

Script di Audit Automatico Settimanale

# PowerShell - Weekly ASR Audit
$auditReport = @()

# 1. Verifica porte aperte non autorizzate
$openPorts = Get-NetTCPConnection -State Listen | Where-Object {$_.LocalAddress -eq "0.0.0.0"}
foreach ($port in $openPorts) {
    if ($port.LocalPort -notin @(443, 80, 22, 41592)) {
        $auditReport += "[ALERT] Unauthorized port open: $($port.LocalPort)"
    }
}

# 2. Verifica NLA su tutti i server
$servers = Get-ADComputer -Filter "OperatingSystem -like 'Windows Server*'" | Select-Object -ExpandProperty Name
foreach ($server in $servers) {
    $nla = Invoke-Command -ComputerName $server -ScriptBlock {
        Get-ItemProperty "HKLM:SYSTEMCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp" -Name UserAuthentication | Select-Object UserAuthentication
    } -ErrorAction SilentlyContinue
    
    if ($nla.UserAuthentication -ne 1) {
        $auditReport += "[WARNING] NLA disabled on $server"
    }
}

# 3. Verifica segmentazione firewall
# Connettiti al firewall e verifica le ACL

# 4. Invia report
If ($auditReport.Count -gt 0) {
    Send-MailMessage -From "security@company.it" `
        -To "infosec-team@company.it" `
        -Subject "[SECURITY] Weekly ASR Audit Report" `
        -Body ($auditReport -join "`n") `
        -SmtpServer "mail.company.it"
}

FAQ

Ho una rete piena di RDP esposti. Per quanto tempo ci vuole a metterla in sicurezza?

Nel mio caso, macrosegmentazione completa ha richiesto 6-8 settimane. Microsegmentazione e automazione completa ha richiesto altri 3 mesi. Se iniziate subito con deny-by-default e RD Gateway, potete mitigare il 90% del rischio in 2-3 settimane. Il resto è raffinamento continuo.

Posso semplicemente disabilitare RDP invece di hardening?

Se un server non ha davvero bisogno di accesso desktop remoto, disabilitare il ruolo Remote Desktop Services rimuove completamente la superficie d’attacco, che diversi avvisi CVE 2026 elencano come una mitigazione valida quando RDP non è richiesto per la funzione del sistema. Se non lo usi, disabilitalo. Semplice così.

Cosa succede se uso una VPN tradizionale invece di ZTNA?

La VPN tradizionale verifica dove ti trovi (il tunnel), ma non verifica *chi sei* o *che dispositivo stai usando*. Con ZTNA, anche dentro la VPN, devi autenticarti per ogni risorsa. Nel 2026, una VPN senza zero-trust è insufficiente. La VPN è un primo layer, ma non l’unico.

Come gestisco gli utenti che hanno bisogno di RDP da casa?

RD Gateway + MFA + device posture check è lo standard. L’utente si autentica al gateway RD, il gateway verifica che il dispositivo sia conforme (patched, antimalware attivo, etc.), solo allora consente la connessione RDP al server. Niente “collega a VPN e accedi”—è troppo semplice.

Qual è la priorità se ho risorse limitate?

Iniziate con le strategie ad alto impatto e basso sforzo: costruite l’inventario dei vostri asset, applicate le patch per le vulnerabilità note e chiudete le porte non necessarie. Poi progredite verso i miglioramenti architetturali come la segmentazione di rete e zero trust. Nell’ordine: 1) chiudi RDP, 2) abilita NLA, 3) implementa MFA, 4) segmentazione, 5) microsegmentazione e automazione.

Conclusione

La riduzione della superficie d’attacco nel 2026 non è un progetto che si completa—è una pratica continua. Ho imparato sulla mia pelle che la sicurezza non è “implementa zero-trust una volta e sei a posto”. È monitoraggio settimanale, audit mensili, e correzione rapida quando trovo deviazioni dalla configurazione baseline.

I tre pilastri che ho implementato—mappatura dei port RDP esposti, gestione delle credenziali compromesse, e segmentazione progressiva zero-trust—hanno ridotto il mio rischio RDP da “imminente disastro” a “controllato e monitorato” in pochi mesi. Se siete ancora nella fase di scoperta, cominciate qui. Se siete già in movimento, accelerate verso ZTNA e microsegmentazione.

Il mio consiglio finale: non trattenete questo come progetto IT—è un progetto di rischio aziendale. I vostri stakeholder devono capire cosa state facendo e perché. Una volta che vedono i numeri (le credenziali compromesse costano alle organizzazioni in media 4,81 milioni di dollari per violazione), il budget arriva da solo.

Avete dubbi sulla vostra configurazione RDP o zero-trust? Lasciate un commento qui sotto—sono qui per aiutare.