Protezione da Ricognizione Interna utilizzando NetCease e SAMRi10

Cos'è la Ricognizione Interna?

Il riconoscimento interno è uno dei primi passi che un attaccante compie una volta che ha compromesso un account utente o computer nella tua rete. Utilizzando vari strumenti o script, enumerano e raccolgono informazioni che li aiuteranno a identificare quali risorse dovrebbero cercare di compromettere successivamente per ottenere ciò che desiderano. Ad esempio, BloodHound mappa i percorsi di attacco che possono consentire a un avversario di elevare i propri privilegi da utente ordinario a admin.

Quasi tutti i metodi di enumerazione comuni possono essere eseguiti da un utente non privilegiato, il che li rende estremamente difficili da rilevare e bloccare. In questo post, spiegherò come utilizzare per difendersi da due tipi di ricognizione interna:

• Enumerazione delle sessioni da parte di utenti non privilegiati
• Interrogazioni al protocollo MS-SAMR

Tipi di Ricognizione

Per trovare informazioni sulla rete che hanno penetrato, gli aggressori spesso enumerano i seguenti tipi di dati:

• Sessioni — Per scoprire chi è connesso e dove
• Utenti — Per comprendere tutti gli utenti nel dominio, idealmente con la loro appartenenza a gruppi
• Gruppi — Per vedere tutti i gruppi nel dominio, idealmente con i loro membri
• Liste di controllo degli accessi (ACL) di Active Directory — Per comprendere quali principi di sicurezza (come utenti e gruppi) possono accedere a quali risorse
• Appartenenza al gruppo locale — Per vedere chi ha diritti di accesso sulla macchina (specialmente chi ha diritti amministrativi)

Blocco dell'enumerazione delle sessioni con NetCease

Questo post del blog si concentra sull'enumerazione delle sessioni, che consente a un avversario di determinare dove sono registrati gli account utente e di servizio. Queste informazioni li aiutano a stabilire la priorità di quali host tentare di compromettere per primi, come ad esempio gli host che hanno un amministratore connesso.

Nota: Le autorizzazioni predefinite in Windows 10 sono state modificate per impedire agli aggressori di eseguire l'enumerazione delle sessioni; tuttavia, vale comunque la pena verificarle.

NetCease è uno script PowerShell breve che aiuta a prevenire l'enumerazione delle sessioni modificando il valore del Registro che controlla i permessi del metodo NetSessionEnum. (Il motivo per cui ciò viene eseguito tramite uno script anziché manualmente è perché la chiave, SrvsvcSessionInfo, è modificabile solo in un valore binario del registro.) Ecco il percorso per la chiave SrvsvcSessionInfo:

Percorso: HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/LanmanServer/DefaultSecurity

Il valore predefinito della chiave di registro SrvsvcSessionInfo è l'ACL che consente l'uso del metodo NetSessionEnum. Questo è assegnato ai seguenti:

• Membro degli Amministratori
• Membro degli Operatori del Server
• Membro dei Power Users
• Utenti autenticati

Il permesso degli Utenti Autenticati consente agli aggressori di eseguire il ricognizione della sessione utilizzando qualsiasi account utente compromesso.

Ciò che lo script NetCease fa è eseguire il backup del valore corrente del registro e poi modificare i permessi, in modo che le seguenti ACE siano nell'ACL:

• InteractiveSid
• ServiceSid
• BatchSid
• Amministratori
• Operatori del server
• PowerUsers

Verifica dell'ACL

Se vuoi visualizzare il descrittore di sicurezza, puoi utilizzare il seguente frammento di PowerShell, che ti mostrerà l'ACL:

      #Registry Key Information
$key = "HKLM:SYSTEMCurrentControlSetServicesLanmanServerDefaultSecurity"
$name = "SrvsvcSessionInfo"

#Get the Registry Key and Value
$Reg_Key = Get-Item -Path $key
$BtyeValue = $reg_Key.GetValue($name, $null)

#Create a CommonSecurityDescriptor Object using the Byte Value
$Security_Descriptor = New-Object -TypeName System.Security.AccessControl.CommonSecurityDescriptor -ArgumentList $true, $false, $ByteValue, 0

#Output of the ACL to make it simple to see for document. Use only $Security_Descriptor.DiscretionaryAcl if you want to see the full ACL!
$Security_Descriptor.DiscretionaryAcl | Select-Object SecurityIdentifier, ACEType | Format-Table -AutoSize
      

Output prima di eseguire NetCease:

Risultato dopo aver eseguito NetCease:

Nota: Le informazioni sui SID ben noti sono disponibili qui.

Test dell'enumerazione delle sessioni

Un modo semplice per verificare se hai bloccato l'enumerazione delle sessioni da parte degli account utente ordinari è utilizzare lo strumento NetSess di Joeware.net, ma ci sono molte altre opzioni, inclusa SharpHound. Quando fai questo, assicurati di utilizzare un account utente che non sia membro degli Amministratori, Operatori Server o Utenti con poteri avanzati.

Output prima di utilizzare NetCease

      Netsess.exe [Computer]
      

Output dopo aver utilizzato NetCease con un account non privilegiato

      Netsess.exe [Computer]
      

Output dopo l'uso di NetCease con un account utente privilegiato

      Netsess.exe [Computer]
      

Bloccare il ricognizione utilizzando Remote SAM (SAMR)

Gli aggressori possono eseguire attività di ricognizione utilizzando il protocollo SAMR, che può interrogare a distanza i dispositivi ma può anche interrogare Active Directory. Utilizzando SAMR, un attaccante senza alcun privilegio amministrativo può trovare gruppi e utenti altamente privilegiati, così come utenti e gruppi locali per ogni sistema nella rete. Strumenti come BloodHound possono poi mappare automaticamente queste informazioni in percorsi di attacco per compromettere Active Directory.

Microsoft ha introdotto protezioni per l'interrogazione di SAMR con Windows 10 e nel 2017 ha aggiunto aggiornamenti per i sistemi operativi precedenti fino a Windows 7 e Server 2008 R2 utilizzando la chiave di registro RestrictRemoteSAM. Questa chiave è una stringa (REG_SZ) che conterrà l'SDDL del descrittore di sicurezza che protegge le chiamate Remote SAM.

Nell'edizione anniversario di Windows 10 (1607) e Windows Server 2016 e successivi, l'SDDL predefinito è stato modificato per consentire solo agli amministratori locali di interrogare Remote SAM.

Di seguito è riportata una tabella che suddivide i requisiti, il comportamento predefinito e le opzioni di protezione per tutti i sistemi operativi:

Ci sono tre modi per impostare la chiave di registro RestrictRemoteSAM:

• Registro
• Group Policy
• SAMRi10 (Samaritano)

Rivediamo ciascuno di essi.

Opzione del registro

La chiave di registro RestrictRemoteSAM è disponibile per gli amministratori per aggiornarla come desiderano:

Percorso: HKLM/System/CurrentControlSet/Control/Lsa

Nome: RestrictRemoteSAM

Valore predefinito (SDDL) in Windows 10: O:SYG:SYD:(A;;RC;;;BA)

Componenti dell'SDDL

Come puoi vedere, il valore predefinito che Windows 10 imposta è SYSTEM per Proprietario e Gruppo principale e Controllo di lettura per gli Amministratori integrati.

Verificare l'SDDL prima di applicarlo

Per verificare che l'SDDL sia corretto prima di applicare la modifica, puoi utilizzare il comando ConvertFrom-SDDLString in PowerShell per convertirlo in un descrittore di sicurezza più facile da leggere.

Opzione di Group Policy o Local Security Policy

Le impostazioni di Group Policy e Local Security Policy consentono agli amministratori di configurare facilmente questa chiave. Questo può funzionare bene per gli amministratori che vogliono impostare lo stesso valore su tutti i sistemi o su più gruppi di sistemi (ad esempio, consentendo connessioni Remote SAM per tutti i server in una specifica OU o un determinato insieme di server applicativi).

I dettagli riguardanti l'impostazione sono i seguenti:

Opzione SAMRi10 (Samaritano)

SAMRi10 è uno script PowerShell che offre un vantaggio chiave rispetto alle opzioni precedenti: crea un nuovo gruppo locale e delega l'accesso al gruppo per poter eseguire chiamate SAM remote. Questo consente agli amministratori di controllare completamente questa funzionalità nelle Preferenze di Criteri di Gruppo o di concederla manualmente agli account quando necessario.

Lo script SAMRi10 fa quanto segue:

1. Crea un gruppo locale chiamato “Remote SAM Users”
2. Modifica l'SDDL per includere il nuovo gruppo creato:
   • Se non esiste un SDDL predefinito, allora concedi l'accesso agli Amministratori integrati.
   • Se esiste un SDDL, allora modificalo per includere la nuova ACE per il gruppo degli Utenti SAM Remoti.

Vantaggi dell'uso di SAMRi10

• Facile concedere accesso granulare per l'accesso Remote SAM
• Aiuta le organizzazioni che vogliono applicare l'accesso con i privilegi minimi
• Può essere utilizzato in combinazione con l'appartenenza a un local group membership Group Policy per concedere agli utenti l'accesso centralizzato utilizzando il targeting a livello di elemento
• Può essere utilizzato da un sistema di Privileged Access Management (PAM) per concedere facilmente accesso dinamico (just-in-time) se un account o un processo richiede questo permesso specifico

Difendersi dal Reconnaissance con le soluzioni Netwrix

Netwrix StealthAUDIT include un analizzatore di percorsi di attacco che fornisce agli amministratori informazioni dettagliate sui loro ACL di Active Directory in modo che possano colmare eventuali lacune prima che gli avversari le sfruttino. Netwrix StealthINTERCEPT può monitorare le query LDAP e poi inoltrarle a Netwrix StealthDEFEND, che può rilevare diversi scenari di ricognizione e query preconfigurate, inclusi BloodHound, query per tutti gli SPN e query per tutti gli account con password never expires.

FAQ

Cos'è il riconoscimento interno e perché dovresti preoccupartene?

Il riconoscimento interno si verifica quando gli aggressori che hanno già ottenuto l'accesso iniziale alla tua rete iniziano a mappare l'ambiente per trovare obiettivi preziosi. Non stanno più effettuando intrusioni – sono già loggati e stanno esplorando. Qui è dove la maggior parte delle strategie di sicurezza sono carenti, concentrando l'attenzione sulle difese perimetrali mentre gli aggressori si muovono liberamente all'interno utilizzando credenziali legittime.

La realtà è semplice: non puoi proteggere ciò che non riesci a vedere e non puoi controllare ciò che non comprendi. La ricognizione interna è la fase critica in cui gli aggressori raccolgono informazioni sulla struttura del tuo Active Directory, identificano account di alto valore e tracciano percorsi verso i tuoi dati più sensibili. Data Security inizia con l'identità, e ciò significa impedire agli aggressori di enumerare la tua infrastruttura di identità in primo luogo.

Come si implementa NetCease per la protezione dell'enumerazione delle sessioni?

NetCease blocca gli attacchi di enumerazione delle sessioni impedendo agli utenti non autorizzati di elencare le sessioni attive sui tuoi controller di dominio e server. L'implementazione è semplice ma richiede pianificazione. Prima, scarica NetCease dal repository ufficiale e verifica che lo stia eseguendo su un sistema con PowerShell 5.1 o versione successiva.

Prerequisiti:

• Privilegi amministrativi
• PowerShell 5.1 o versione successiva
• Server Windows o sistema unito a dominio

Lo strumento funziona modificando le impostazioni del registro che controllano come il servizio Windows Server risponde alle richieste di enumerazione delle sessioni. Esegui NetCease con privilegi amministrativi su ogni server che vuoi proteggere, iniziando dai sistemi non critici per il testing. Le modifiche hanno effetto immediatamente senza richiedere un riavvio, ma dovresti verificare che gli strumenti amministrativi legittimi e le soluzioni di monitoraggio continuino a funzionare correttamente.

La prassi migliore è implementare NetCease gradualmente nell'ambiente piuttosto che distribuirlo ovunque in una volta sola. Inizia con i server che non ospitano applicazioni critiche per l'attività, monitora per eventuali interruzioni, poi espandi ai controller di dominio e ad altri obiettivi ad alto valore. Ricorda che prevenire il ricognizione non significa rendere la tua rete invisibile – significa rendere il lavoro degli attaccanti più difficile e dare ai tuoi sistemi di rilevamento più tempo per identificare l'attività malevola.

Qual è la differenza tra SAMRi10 e le restrizioni di Group Policy SAM?

SAMRi10 e Group Policy limitano entrambi l'accesso al database Security Account Manager (SAM), ma operano a livelli diversi e servono casi d'uso differenti. SAMRi10 è uno script PowerShell che modifica direttamente le impostazioni del registro su singole macchine, offrendoti un controllo granulare sulle restrizioni di accesso SAM su sistemi specifici.

Le restrizioni di Group Policy SAM operano a livello di dominio, consentendoti di applicare politiche coerenti su più sistemi contemporaneamente. L'approccio di Group Policy è migliore per implementazioni su larga scala dove è necessaria una protezione uniforme su molte macchine. SAMRi10 è ideale per server specifici, ambienti di test o situazioni in cui sono necessarie configurazioni personalizzate che non si adattano ai template standard di Group Policy.

L'implementazione tecnica differisce anche. SAMRi10 modifica direttamente la chiave di registro RestrictRemoteSAM, mentre Group Policy utilizza il sistema di template amministrativi per ottenere lo stesso risultato. Entrambi i metodi sono efficaci, ma SAMRi10 offre maggiore flessibilità per la risoluzione dei problemi e le configurazioni personalizzate. Per la maggior parte delle organizzazioni, un approccio ibrido funziona meglio: utilizzare Group Policy per le restrizioni SAM di base in tutto il dominio, quindi utilizzare SAMRi10 per sistemi specifici che necessitano di un rafforzamento aggiuntivo.

Come si verifica che le misure di protezione dal ricognizione funzionino?

Testare la protezione del riconoscimento richiede un approccio metodico che simula le tecniche degli attaccanti reali senza interrompere le operazioni. Inizia con test di enumerazione di sessione di base utilizzando strumenti come NetSess o i comandi Get-WmiObject di PowerShell da un account non amministrativo. Se NetCease funziona correttamente, questi tentativi dovrebbero fallire o restituire informazioni limitate.

Per le restrizioni SAM, testare l'accesso remoto al database Security Account Manager utilizzando strumenti come enum4linux o rpcclient da un sistema Linux, o comandi net use da Windows. Le restrizioni SAM configurate correttamente dovrebbero bloccare i tentativi di enumerazione non autorizzati pur consentendo ancora l'accesso amministrativo legittimo.

La chiave è testare dalla prospettiva dell'attaccante. Creare account di test con privilegi di utente standard e tentare tecniche comuni di ricognizione come l'enumerazione di domini, la scoperta di condivisioni e l'elenco degli account utente. Documentare ciò che funziona e ciò che non funziona, poi adeguare di conseguenza le misure di protezione. Ricordarsi che una sicurezza efficace non riguarda il blocco di tutto – si tratta di controllare quali informazioni sono disponibili a chi, garantendo al contempo che le legittime funzioni aziendali continuino a operare correttamente.

Quando si dovrebbe eseguire il rollback delle modifiche di NetCease e SAMRi10?

Gli scenari di rollback coinvolgono tipicamente problemi di compatibilità con strumenti amministrativi legittimi, fallimenti inaspettati di applicazioni o interruzioni di processi aziendali che non sono stati identificati durante i test. NetCease e SAMRi10 offrono entrambi opzioni di rollback, ma il processo è diverso per ogni strumento.

Per NetCease, il rollback comporta l'inversione delle modifiche al registro che controllano l'enumerazione delle sessioni. Lo strumento include parametri per ripristinare le impostazioni originali, ma è sempre necessario documentare la baseline configuration prima di apportare modifiche. Testare il processo di rollback in un ambiente di laboratorio prima per assicurarsi di comprendere i passaggi e i tempi coinvolti.

Il rollback di SAMRi10 è più complesso perché coinvolge più chiavi di registro e potenziali interazioni con i Criteri di Gruppo. Se hai implementato restrizioni SAM tramite Criteri di Gruppo, utilizza gli strumenti di gestione delle policy per annullare le modifiche. Per le modifiche dirette al registro, SAMRi10 include funzioni di ripristino, ma è essenziale una verifica manuale per assicurare un rollback completo.

L'approccio migliore è proattivo: implementare modifiche durante le finestre di manutenzione, avere procedure di rollback documentate e testate, e monitorare attentamente i sistemi interessati per almeno 24-48 ore dopo l'implementazione. La maggior parte dei problemi di compatibilità emergono rapidamente, ma alcuni possono diventare evidenti solo durante processi aziendali specifici o operazioni di sistema.