Data/Locales/checks/it/ADTradecraftChecks.json
|
{ "_family": "ADTradecraftChecks.json", "ADTRADE-001": { "name": { "value": "Residui di cpassword delle Group Policy Preferences in SYSVOL", "status": "machine-draft" }, "description": { "value": "Dal 2008 al maggio 2014, le Group Policy Preferences consentivano agli amministratori di distribuire attività pianificate, password di utenti locali, unità mappate e servizi usando un campo 'cpassword', cifrato con una chiave AES-256 documentata pubblicamente da Microsoft. La correzione in MS14-025 ha disabilitato il campo cpassword nelle NUOVE preferenze, ma ha lasciato intatte quelle esistenti in SYSVOL. Ogni ingaggio red-team le trova ancora. Qualsiasi utente di dominio autenticato può leggere SYSVOL, prelevare la cpassword e decifrarla offline. Se trovi qualcosa qui, considera compromessa ogni credenziale esposta e rinnovala.", "status": "machine-draft" }, "recommendedValue": { "value": "Zero attributi cpassword ovunque sotto \\\\domain\\SYSVOL\\domain\\Policies\\**\\*.xml.", "status": "machine-draft" }, "remediationSteps": { "value": "Analizza SYSVOL: Get-ChildItem -Path \\\\<domain>\\SYSVOL\\<domain>\\Policies -Recurse -Include *.xml | Select-String 'cpassword'. Per ogni corrispondenza: (1) rinnova la password dell'account la cui credenziale è esposta (il nome utente si trova nello stesso XML), (2) verifica nei log l'uso di quella credenziale da quando la preferenza è stata creata, (3) elimina la preferenza GPP una volta messa in atto la nuova credenziale. La KB2962486 di Microsoft contiene le indicazioni per la pulizia.", "status": "machine-draft" } }, "ADTRADE-002": { "name": { "value": "Indicatore DCShadow (server non autorizzati nella partizione di configurazione)", "status": "machine-draft" }, "description": { "value": "DCShadow (Vincent LE TOUX / Benjamin Delpy, BlueHat IL 2018) registra un host controllato dall'aggressore come controller di dominio scrivendo oggetti nTDSDSA + server sotto CN=Sites,CN=Configuration. Il DC falso viene quindi usato per iniettare dati di replica dannosi (SID history, hash delle password) senza mai essere un vero DC. NOTA: nei domini di lunga durata un oggetto server senza corrispondenza è molto più spesso METADATI DC RESIDUI (un DC rimosso senza 'ntdsutil metadata cleanup') che un vero attacco DCShadow, quindi è classificato come High anziché Critical: esamina il timestamp whenCreated per distinguere un oggetto creato di recente (sospetto) da vecchi metadati non aggiornati.", "status": "machine-draft" }, "recommendedValue": { "value": "Tutti gli oggetti server sotto CN=Sites,CN=Configuration corrispondono a controller di dominio reali e inventariati. Nessun oggetto server creato di recente che non corrisponda a un DC noto.", "status": "machine-draft" }, "remediationSteps": { "value": "Enumera: Get-ADObject -Filter {objectClass -eq 'server'} -SearchBase \"CN=Sites,$((Get-ADRootDSE).configurationNamingContext)\" -Properties whenCreated, dNSHostName | Sort whenCreated. Effettua un confronto incrociato con l'inventario dei DC (Get-ADDomainController -Filter *). Qualsiasi oggetto server che non corrisponda a un DC reale, specialmente se creato di recente, richiede una risposta agli incidenti immediata: DCShadow è una primitiva di livello domain-takeover. Monitora gli eventi 5137 / 5141 sul contenitore dello schema come segnale in fase di rilevamento.", "status": "machine-draft" } }, "ADTRADE-003": { "name": { "value": "Chiavi di ripristino BitLocker non aggiornate", "status": "machine-draft" }, "description": { "value": "Le chiavi di ripristino BitLocker sono archiviate in AD come oggetti figlio msFVE-RecoveryInformation del computer che ne ha eseguito il backup. Quando un computer viene dismesso ma l'oggetto AD viene lasciato pendente, le chiavi di ripristino restano interrogabili da chiunque disponga dei diritti di ripristino BitLocker, in genere un gruppo più ampio del 'Tier-0'. Chiavi non aggiornate significano che i dischi smaltiti sono decifrabili se recuperati da un rigeneratore o da un cassonetto.", "status": "machine-draft" }, "recommendedValue": { "value": "Tutti gli oggetti msFVE-RecoveryInformation appartengono a computer attivi negli ultimi 90 giorni. Nessuna chiave orfana associata ad account computer disabilitati o modificati di recente e poi rimasti inattivi.", "status": "machine-draft" }, "remediationSteps": { "value": "Enumera le informazioni di ripristino: Get-ADObject -Filter {objectClass -eq 'msFVE-RecoveryInformation'} -Properties whenCreated. Per ciascuna, risali all'oggetto computer padre e verificane lastLogonTimestamp / Enabled. Per i computer inattivi da oltre 90 giorni: conferma che il disco sia stato cancellato o distrutto, quindi elimina l'oggetto computer AD (operazione che elimina a cascata le informazioni di ripristino). Per i computer in uso attivo ma con chiavi di ripristino molto vecchie: ruotale tramite Backup-BitLockerKeyProtector. Verifica che il gruppo di ripristino BitLocker abbia un'appartenenza ristretta.", "status": "machine-draft" } }, "ADTRADE-004": { "name": { "value": "Igiene del criterio di replica delle password RODC", "status": "machine-draft" }, "description": { "value": "I controller di dominio di sola lettura memorizzano nella cache le password delle entità elencate nel loro criterio di replica delle password (PRP). Se un account Tier-0 (Domain Admin, Enterprise Admin, krbtgt) è raggiungibile dal PRP di un RODC, direttamente o tramite annidamento di gruppi, la compromissione dell'RODC compromette quegli account. Il gruppo predefinito 'Denied RODC Password Replication Group' dovrebbe contenere esplicitamente DA / EA / SA / Schema Admins / krbtgt; alcuni ambienti personalizzano il criterio e rimuovono accidentalmente quei divieti.", "status": "machine-draft" }, "recommendedValue": { "value": "Tutti gli RODC del dominio hanno un criterio di replica delle password in cui Domain Admins, Enterprise Admins, Schema Admins, krbtgt e Account Operators sono membri del lato Deny. Nessun account ad alto privilegio è membro del lato Allow.", "status": "machine-draft" }, "remediationSteps": { "value": "Per ogni RODC: Get-ADDomainController -Filter {IsReadOnly -eq $true} | ForEach-Object { Get-ADDomainControllerPasswordReplicationPolicy -Identity $_ -Allowed; Get-ADDomainControllerPasswordReplicationPolicy -Identity $_ -Denied }. Verifica che l'elenco Denied contenga il gruppo integrato 'Denied RODC Password Replication Group'. Se il tuo ambiente non ha RODC, questo controllo è N/A: PASS. La guida di pianificazione RODC di Microsoft contiene il modello canonico del PRP.", "status": "machine-draft" } }, "ADTRADE-005": { "name": { "value": "Rotazione della chiave dell'account computer Entra Seamless SSO (AZUREADSSOACC$)", "status": "machine-draft" }, "description": { "value": "Quando l'accesso Single Sign-On integrato (Seamless SSO) di Entra (Azure AD) è abilitato per l'identità ibrida, AD crea un account computer denominato AZUREADSSOACC$. La sua password è la chiave Kerberos condivisa che Entra usa per convalidare i ticket SSO. Microsoft documenta che questa chiave NON viene ruotata automaticamente: gli amministratori devono ruotarla. Se un aggressore estrae la chiave AZUREADSSOACC$ (è un normale hash NT leggibile tramite DCSync o da un DC), può falsificare Silver Ticket Kerberos per il servizio Azure AD e autenticarsi come QUALSIASI utente ibrido sincronizzato, senza ulteriore interazione, per tutto il tempo in cui la chiave resta valida. Una chiave non ruotata da oltre 90 giorni amplia drasticamente quella finestra.", "status": "machine-draft" }, "recommendedValue": { "value": "Chiave Kerberos AZUREADSSOACC$ ruotata almeno ogni 90 giorni (ruotala due volte per rotazione per invalidare la chiave precedente).", "status": "machine-draft" }, "remediationSteps": { "value": "Ruota la chiave Seamless SSO su una macchina con il modulo Entra Connect / Azure AD: Import-Module 'C:\\Program Files\\Microsoft Azure Active Directory Connect\\AzureADSSO.psd1'; New-AzureADSSOAuthenticationContext; Update-AzureADSSOForest. Esegui la rotazione due volte (l'account memorizza la chiave corrente + precedente) e pianificala su base ricorrente. Se il Seamless SSO non è più usato, disabilitalo ed elimina l'oggetto AZUREADSSOACC$.", "status": "machine-draft" } }, "ADTRADE-006": { "name": { "value": "Shadow Credentials (msDS-KeyCredentialLink) su entità privilegiate", "status": "machine-draft" }, "description": { "value": "L'attributo msDS-KeyCredentialLink contiene le chiavi pubbliche usate per l'accesso Windows Hello for Business / PKINIT senza password. Un aggressore con accesso in scrittura a questo attributo su un bersaglio può aggiungere la PROPRIA coppia di chiavi (Whisker / pyWhisker) e quindi richiedere un TGT Kerberos come quell'account usando la chiave privata corrispondente: una tecnica furtiva di persistenza e impersonificazione nota come 'shadow credentials'. Qualsiasi credenziale chiave inattesa su un oggetto Tier-0 (un domain admin, un controller di dominio o qualsiasi account adminCount=1) dovrebbe essere trattata come potenziale backdoor finché non si dimostri che è una registrazione WHfB legittima.", "status": "machine-draft" }, "recommendedValue": { "value": "Nessun valore msDS-KeyCredentialLink non riconosciuto su entità privilegiate/Tier-0; ogni chiave corrisponde a una registrazione WHfB/senza password nota.", "status": "machine-draft" }, "remediationSteps": { "value": "Per ogni entità segnalata, ispeziona le credenziali chiave (Get-ADObject -Properties msDS-KeyCredentialLink, oppure il cmdlet Get-ADKeyCredential di DSInternals) e correla ogni chiave di dispositivo a una registrazione Windows Hello for Business legittima. Rimuovi qualsiasi voce non attribuibile a una registrazione autorizzata. Limita chi può scrivere msDS-KeyCredentialLink (esamina Key Admins / Enterprise Key Admins e le DACL di OU/oggetti che concedono tale scrittura). Reimposta gli account interessati se si sospetta una compromissione.", "status": "machine-draft" } }, "ADTRADE-007": { "name": { "value": "Superficie di escalation della migrazione dMSA BadSuccessor", "status": "machine-draft" }, "description": { "value": "Windows Server 2025 ha introdotto i Managed Service Account delegati (dMSA, classe di oggetto msDS-DelegatedManagedServiceAccount) con una funzione di migrazione: un dMSA può essere contrassegnato come sostituto di un account esistente, dopodiché eredita i privilegi e le chiavi Kerberos di quell'account. La tecnica 'BadSuccessor', divulgata nel 2024, ne abusa: un'entità che può semplicemente CREARE un dMSA in una OU (CreateChild sulla classe dMSA, o ampio write/GenericAll sulla OU) può crearne uno, puntarlo a un account privilegiato ed ereditarne le chiavi, effettuando l'escalation verso quell'account senza mai detenere diritti diretti su di esso. Questo controllo inventaria le OU in cui un'entità non Tier-0 possiede tale capacità.", "status": "machine-draft" }, "recommendedValue": { "value": "Nessuna entità non Tier-0 può creare o scrivere un MSA delegato (msDS-DelegatedManagedServiceAccount) in alcuna OU.", "status": "machine-draft" }, "remediationSteps": { "value": "Su ogni OU segnalata, rimuovi CreateChild (per la classe msDS-DelegatedManagedServiceAccount), GenericAll, WriteDacl e WriteOwner dalle entità non amministrative. Esamina ampiamente le autorizzazioni delegate delle OU: gli stessi ACE che abilitano BadSuccessor abilitano anche altri abusi di creazione di oggetti. Fino all'applicazione della correzione/mitigazione, monitora la creazione di oggetti msDS-DelegatedManagedServiceAccount (eventi 4662/5137). Questo controllo effettua uno SKIP sulle foreste il cui schema precede Server 2025.", "status": "machine-draft" } }, "ADTRADE-008": { "name": { "value": "Appartenenza ai gruppi Key Admins / Enterprise Key Admins", "status": "machine-draft" }, "description": { "value": "Ai gruppi Key Admins (RID di dominio 526) ed Enterprise Key Admins (RID 527) è concesso il diritto di scrivere l'attributo msDS-KeyCredentialLink in tutto il dominio/foresta. Ciò rende qualsiasi membro una primitiva di shadow credential a livello di dominio: un membro può piantare credenziali chiave su qualsiasi account e autenticarsi come tale tramite PKINIT. Questi gruppi vengono forniti VUOTI e dovrebbero restare vuoti, a meno che un flusso di lavoro specifico di provisioning delle chiavi Windows Hello for Business non li richieda in modo dimostrabile. Qualsiasi membro è un percorso di escalation che deve essere giustificato.", "status": "machine-draft" }, "recommendedValue": { "value": "I gruppi Key Admins ed Enterprise Key Admins sono vuoti (nessun membro permanente).", "status": "machine-draft" }, "remediationSteps": { "value": "Esamina ogni membro di Key Admins ed Enterprise Key Admins. Rimuovi qualsiasi account che non abbia un'esigenza documentata e continuativa di effettuare il provisioning delle chiavi Windows Hello for Business. Se il provisioning delle chiavi WHfB richiede diritti delegati, circoscrivili a un account di servizio dedicato con le autorizzazioni più ristrette possibili anziché all'appartenenza a questi gruppi a livello di dominio. Tratta i membri inattesi come un potenziale meccanismo di persistenza.", "status": "machine-draft" } }, "ADTRADE-009": { "name": { "value": "Appartenenza al gruppo Cert Publishers", "status": "machine-draft" }, "description": { "value": "I membri del gruppo Cert Publishers (RID di dominio 517) sono autorizzati a pubblicare certificati nell'archivio NTAuth e sugli oggetti utente/computer. Per impostazione predefinita, il gruppo contiene solo gli account computer della CA Enterprise. Un account utente o di servizio inserito in questo gruppo acquisisce la capacità di influenzare quali certificati sono considerati attendibili per l'autenticazione, il che costituisce un trampolino in diversi percorsi di escalation di AD CS (attacchi di classe ESC) e può abilitare l'impersonificazione basata su certificati. L'appartenenza di account computer (gli host della CA stessi) è prevista; qualsiasi membro non computer è un riscontro.", "status": "machine-draft" }, "recommendedValue": { "value": "Cert Publishers contiene solo gli account computer della CA Enterprise, nessun account utente o di servizio.", "status": "machine-draft" }, "remediationSteps": { "value": "Rimuovi qualsiasi account utente o di servizio dal gruppo Cert Publishers; solo gli account computer della CA Enterprise vi appartengono. Esamina il contenuto dell'archivio NTAuth (certutil -viewstore -enterprise NTAuth) alla ricerca di certificati CA inattesi. Rafforza ampiamente AD CS: esamina le autorizzazioni di registrazione dei modelli di certificato e la superficie di configurazione errata ESC1-ESC8.", "status": "machine-draft" } }, "ADTRADE-010": { "name": { "value": "Postura e esposizione delle password dei group Managed Service Account (gMSA)", "status": "machine-draft" }, "description": { "value": "I group Managed Service Account (gMSA) contengono password a 240 bit che AD genera e ruota automaticamente, eliminando il Kerberoasting delle password deboli degli account di servizio e la fatica della rotazione manuale. Due aspetti di postura: (1) se i gMSA siano effettivamente usati per le identità di servizio, e (2) chi è autorizzato a recuperare la password gestita, controllato dal descrittore di sicurezza msDS-GroupMSAMembership (PrincipalsAllowedToRetrieveManagedPassword). Se quel descrittore concede il diritto a un'entità ampia (Everyone, Authenticated Users, Domain Users) o a un'entità non privilegiata, tale entità può recuperare la password gMSA in chiaro (ad esempio con GMSAPasswordReader) e impersonare completamente il servizio.", "status": "machine-draft" }, "recommendedValue": { "value": "Le identità di servizio vengono eseguite come gMSA; msDS-GroupMSAMembership è circoscritto solo agli host specifici che devono eseguire il servizio (nessuna entità ampia o non privilegiata).", "status": "machine-draft" }, "remediationSteps": { "value": "Per ogni gMSA, imposta PrincipalsAllowedToRetrieveManagedPassword esattamente sugli account computer (o su un gruppo strettamente circoscritto) che eseguono il servizio: Set-ADServiceAccount -Identity <gmsa> -PrincipalsAllowedToRetrieveManagedPassword <hosts>. Rimuovi Everyone / Authenticated Users / Domain Users da quell'elenco. Dove gli account di servizio usano ancora password statiche di account utente, migrali a gMSA per ottenere la rotazione automatica e la resistenza al Kerberoasting.", "status": "machine-draft" } } } |