Come mitigare gli attacchi di Active Directory
che usano il toolset di KrbRelayUp

Gli aggressori stanno usando il set di strumenti KrbRelayUp per compromettere Kerberos nelle reti Active Directory locali. Ecco come proteggervi

Chi di voi ha Active Directory (AD) on-premise deve essere consapevole di un nuovo modo di abusare di Kerberos nella rete.  KrbRelayUp è un pacchetto di strumenti che semplifica l’uso di alcune funzionalità in Rubeus, KrbRelay, SCMUACBypass, Powermad/SharpMad, Whisker e ADCSPwn. Gli aggressori utilizzano il set di strumenti per impersonare un amministratore tramite delega vincolata basata sulle risorse ed eseguire il codice sull’account di sistema di un dispositivo.

Gli ambienti AD Pure Azure sono al sicuro da questo attacco, ma le reti AD ibride con AD on-premise e Azure AD sono a rischio. Se un utente malintenzionato compromette una macchina virtuale Azure sincronizzata con la directory attiva on-premise, l’utente malintenzionato otterrà i privilegi di sistema sulla macchina virtuale essendo in grado di fare progressi all’interno della rete tramite alcuni movimenti laterali.

Microsoft consiglia di eseguire le seguenti azioni:

Passo 1: Impedire all’attaccante di effettuare il primo passo della sequenza di attacco

Mentre Microsoft usa la frase, “le organizzazioni dovrebbero considerare” di fare alcune impostazioni, userei una formulazione molto più forte. Raccomandiamo all’organizzazione di effettuare le seguenti modifiche: Impostare l’attributo ms-DS-MachineAccountQuota su “0”. Questa impostazione consente agli utenti non amministratori che si trovano nel gruppo di utenti autenticati di aggiungere fino a 10 workstation alla rete. In questa era dell’autopilota e di altre metodologie di installazione, gli utenti non dovrebbero essere in grado di aggiungere workstation al dominio.

Invitate gli amministratori di AD ad utilizzare lo snap in ASDI Edit MMC (adsiedit.msc) per connettersi al Domain Naming Context. Cercate il valore di “DC=” e il vostro dominio. Fare clic con il pulsante destro del mouse su “Proprietà” e cercate il valore ms-DS-MachineAccountQuota. Di default ha un valore di “10”. Va impostato il valore a “0”.

In alternativa, è possibile impostare il valore con Windows PowerShell. Innanzitutto, utilizzare il cmdlet Get-ADObject per controllare il valore:

Get-ADObject -Identity ((Get-ADDomain).distinguishedname)  -Properties ms-DS-MachineAccountQuota

I risultati dovrebbero mostrare a quale valore è impostata la rete.

Use the Set-ADomain command to set the value:

Set-ADDomain -Identity <DomainName>
             -Replace @{"ms-DS-MachineAccountQuota"="0"}

Impostandolo a “0” si impedisce ai non amministratori di aggiungere nuovi dispositivi al dominio e si assicura che gli aggressori non possano iniziare da questo ma debbano utilizzare una tecnica più difficile per ottenere l’accesso alla rete.

Passo 2: Abilitare il binding del canale LDAP e la firma LDAP

KB4520412 documenta i passi successivi che sono raccomandati come best practice da un bel po’ di tempo. Inclusi nel 10 marzo 2020, gli aggiornamenti includono nuovi eventi relativi al binding del canale LDAP.

Innanzitutto abilitare la registrazione aggiuntiva per assicurarsi di poter regolare LDAP e non avere effetti collaterali. Ormai dovreste avere dal 10 marzo 2020 gli aggiornamenti di Windows installati sui controller di dominio. Successivamente, abilitare la registrazione diagnostica degli eventi LDAP a “2” o superiore.

Aggiungere la seguente chiave del Registro di sistema al dominio per abilitare la registrazione:

Reg Add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v "16 LDAP Interface Events" /t REG_DWORD /d 2

Guardate nel visualizzatore di eventi del controller di dominio e nella sezione “Applicazioni e servizi” e quindi sotto “Servizio directory”. Controllate gli eventi relativi alla firma LDAP e al token di associazione del canale.

Gli eventi di firma LDAP includono:

• Evento 2886: La sicurezza di questi controller di dominio può essere notevolmente migliorata configurando il server per imporre la convalida della firma LDAP.

• Evento 2887: la sicurezza di questi controller di dominio può essere migliorata configurandoli per rifiutare semplici richieste di bind LDAP e altre richieste di bind che non includono la firma LDAP.
• Evento 2888: la sicurezza di questi controller di dominio può essere migliorata configurandoli per rifiutare semplici richieste di bind LDAP e altre richieste di bind che non includono la firma LDAP.
• Evento 2889: la sicurezza di questi controller di dominio può essere migliorata configurandoli per rifiutare semplici richieste di bind LDAP e altre richieste di bind che non includono la firma LDAP.

Gli eventi Channel Binding Token includono:

• Event 3039: Il seguente client ha eseguito un bind LDAP su SSL/TLS e ha fallito la convalida del token di binding del canale LDAP (CBT).
• Evento 3040: Durante il precedente periodo di 24 ore, sono stati eseguiti i bind LDAP non protetti.
• Evento 3041: La sicurezza di questo server di directory può essere significativamente migliorata configurando il server per imporre la convalida dei token di binding del canale LDAP.

Si noti che l’aggiornamento non impone le impostazioni. È necessario apportare le modifiche per applicare la firma LDAP come indicato in ADV19023, ma si consiglia anche di rivedere le seguenti linee guida:

• KB4520412: 2020 LDAP channel binding and LDAP signing requirement for Windows
• KB4034879: LDAP channel binding
• KB935834: LDAP signing
• KB4546509: Frequently asked questions about changes to Lightweight Directory Access Protocol

Una volta applicata la firma LDAP, Microsoft prevede che si verificheranno problemi con i client LDAP che non consentono o supportano la firma che non si connetteranno e i semplici bind LDAP non funzionano se è richiesta la firma LDAP. Microsoft prevede inoltre che quando viene imposto il binding dei canali LDAP, i client LDAP che si connettono tramite SSL/TLS ma non forniscono CBT falliranno se il server richiede CBT. Le connessioni SSL/TLS che vengono interrotte da un server intermedio che a sua volta emette una nuova connessione a un controller di dominio Active Directory, falliranno. Il supporto per il binding dei canali potrebbe essere meno comune su sistemi operativi e applicazioni di terze parti rispetto alla firma LDAP.

Come nota Microsoft, non verranno apportate modifiche al controller di dominio; è necessario apportare le modifiche necessarie.

Microsoft Defender per l’identità e KrbRelayUp

Se si dispone di Microsoft Defender for Identity, questo rileva l’attività dai primi passi della sequenza di attacco KrbRelayUp monitorando il comportamento come visto dal controller di dominio. Prima esamina i tentativi sospetti di delega Kerberos da parte di un computer appena creato e poi esamina le modifiche sospette dell’attributo di delega vincolato basato sulle risorse di un account macchina.

Monitorare il numero di applicazioni client LDAP che avete e il loro possibile impatto può richiedere tempo, quindi cambiate la registrazione e iniziate a rivedere quale impatto avrà questo cambiamento sulla vostra rete. Lasciare questa opzione ai valori predefiniti potrebbe esporre il vostro dominio ad attacchi non necessari.