Data/Locales/checks/it/TierZeroChecks.json
|
{ "_family": "TierZeroChecks.json", "ADTIER-001": { "name": { "value": "Audit dell'account di sincronizzazione Azure AD Connect (MSOL_)", "status": "machine-draft" }, "description": { "value": "Quando Azure AD Connect si installa in modalità Express, crea un account di dominio denominato MSOL_<esadecimale-casuale> e gli concede i diritti Replicating Directory Changes + Replicating Directory Changes All sul contesto di denominazione del dominio, ovvero i diritti DCSync. L'account è di fatto Tier-0, ma per impostazione predefinita risiede nel contenitore Users predefinito, ha una scadenza della password di 10 anni e raramente compare negli strumenti di enumerazione dei gruppi privilegiati, perché ottiene il proprio potere tramite ACL diretta anziché tramite appartenenza a gruppi. La compromissione di questo account equivale funzionalmente a un takeover del dominio.", "status": "machine-draft" }, "recommendedValue": { "value": "Tutti gli account MSOL_ sono inventariati, con password ruotata negli ultimi 180 giorni, collocati in una OU Tier-0 con diritti di accesso limitati, e il server AAD Connect stesso è rafforzato come sistema Tier-0.", "status": "machine-draft" }, "remediationSteps": { "value": "Individua l'account MSOL_: Get-ADUser -Filter {sAMAccountName -like 'MSOL_*'}. Conferma che abbia i diritti DCSync: dsacls 'DC=domain,DC=com' | findstr MSOL_. Spostalo in una OU di amministrazione Tier-0. Ruota la password usando gli strumenti di AAD Connect (NON reimpostarla con gli strumenti standard: usa Add-ADSyncADDSConnectorAccount nel modulo PowerShell ADSync sul server AAD Connect). Applica una GPO di restrizione dell'accesso affinché l'account possa accedere localmente solo al server AAD Connect stesso. Tratta l'host AAD Connect come Tier-0: limita chi può eseguirne l'amministrazione o l'accesso RDP.", "status": "machine-draft" } }, "ADTIER-002": { "name": { "value": "Account di servizio del software di backup nei gruppi privilegiati", "status": "machine-draft" }, "description": { "value": "Il software di backup (Veeam, Commvault, Rubrik, Cohesity, NAKIVO, Backup Exec, Vembu, Acronis) richiede in genere un account di servizio con autorizzazioni molto elevate. La documentazione suggerisce spesso Domain Admin per facilità di configurazione, e molti amministratori si adeguano. Una volta che un aggressore compromette il server di backup (un frequente vettore di accesso iniziale per il ransomware), eredita i privilegi di Domain Admin tramite l'account di servizio. Questo è il percorso di escalation del ransomware numero uno nei dati di risposta agli incidenti del 2023-2025.", "status": "machine-draft" }, "recommendedValue": { "value": "Nessun account di servizio del software di backup è membro di Domain Admins, Enterprise Admins, Schema Admins o Backup Operators. Usa account a privilegio minimo documentati dal vendor e credenziali di backup isolate.", "status": "machine-draft" }, "remediationSteps": { "value": "Individua il prodotto di backup in uso e segui la sua guida al privilegio minimo (Veeam: solo amministratore locale del server di backup + account AD con lettura degli oggetti; Rubrik: entità servizio dedicata in un ruolo solo cloud; ecc.). Rimuovi l'account di backup da Domain Admins. Migra a un gMSA dove supportato. Colloca il server di backup in una OU Tier-1 con diritti di accesso limitati. Se per un carico di lavoro specifico è realmente necessario il ruolo completo di DA, documentalo e isola quella parte del backup in un account proprio, separato da quello principale.", "status": "machine-draft" } }, "ADTIER-003": { "name": { "value": "Account di servizio di hypervisor / virtualizzazione nei gruppi privilegiati", "status": "machine-draft" }, "description": { "value": "Le integrazioni con AD di vCenter / Hyper-V / SCVMM / Citrix / Nutanix usano spesso un account di servizio configurato durante l'installazione. Se quell'account è un Domain Admin, la compromissione del piano di gestione dell'hypervisor (o del database SSO dell'host) si propaga fino ad AD. L'hypervisor è concettualmente già Tier-0; la sua identità AD dovrebbe essere coerente.", "status": "machine-draft" }, "recommendedValue": { "value": "Gli account di servizio degli hypervisor hanno solo i diritti documentati dal vendor (in genere lettura per l'inventario + scritture su OU specifiche se è in uso l'integrazione VM-AD). Non presenti in Domain Admins.", "status": "machine-draft" }, "remediationSteps": { "value": "Esamina l'account di servizio AD per ogni prodotto di hypervisor. Applica le indicazioni del vendor sul privilegio minimo. Per vCenter: usa il pattern documentato di sorgente di identità SSO anziché mappare un Domain Admin. Per Hyper-V/SCVMM: circoscrivi i diritti dell'account di servizio alle OU che ospitano gli account computer delle VM. Tratta l'host di gestione dell'hypervisor come Tier-0 nel tuo modello amministrativo.", "status": "machine-draft" } }, "ADTIER-004": { "name": { "value": "Account di servizio di gestione della configurazione nei gruppi privilegiati", "status": "machine-draft" }, "description": { "value": "Le piattaforme di gestione della configurazione (SCCM/MECM, Intune Connector, Jamf, KACE, Lansweeper, ManageEngine, Ivanti, BigFix) distribuiscono software su ogni endpoint per definizione: sono già una piattaforma privilegiata di movimento laterale. SCCM in particolare ha primitive di abuso ben note (esposizione del Network Access Account, coercizione NTLM verso il site server, client push). Un account di servizio di gestione della configurazione in Domain Admins consegna a un aggressore che approda su qualsiasi endpoint gestito le chiavi del dominio.", "status": "machine-draft" }, "recommendedValue": { "value": "Gli account di servizio di gestione della configurazione sono circoscritti ai diritti minimi documentati e mai presenti in Domain Admins / Enterprise Admins. Il Network Access Account di SCCM è un'identità dedicata non privilegiata.", "status": "machine-draft" }, "remediationSteps": { "value": "Individua il prodotto di gestione della configurazione ed esamina i diritti dell'account di servizio. Per SCCM: assicurati che il Network Access Account sia non privilegiato (NON un Domain Admin); assicurati che l'account macchina del site server non sia un Domain Admin; esamina gli account di servizio della gerarchia per il privilegio minimo. Sposta i site server e i management point in una OU Tier-0 con accessi limitati.", "status": "machine-draft" } }, "ADTIER-005": { "name": { "value": "Account di servizio SQL / database nei gruppi privilegiati", "status": "machine-draft" }, "description": { "value": "Gli account di servizio SQL Server / MySQL / PostgreSQL in Domain Admins sono comuni negli ambienti in cui il team DBA ha installato SQL con l'indicazione predefinita 'Usa un account AD esistente' e ha scelto un account amministrativo per comodità. Una volta che il server di database è raggiungibile in rete, la compromissione di una credenziale SQL o una vulnerabilità di SQL Server concede direttamente all'aggressore i privilegi di Domain Admin.", "status": "machine-draft" }, "recommendedValue": { "value": "Gli account di servizio dei database vengono eseguiti come gMSA o come identità di servizio dedicate senza appartenenza a gruppi privilegiati.", "status": "machine-draft" }, "remediationSteps": { "value": "Migra gli account di servizio SQL a gMSA dove supportato. Per gli account che devono rimanere basati su utente, rimuovi l'appartenenza ai gruppi privilegiati e concedi solo i diritti locali richiesti dal motore di database (Log on as a service, Bypass traverse checking, Adjust memory quotas for a process: consulta la documentazione Microsoft per i diritti specifici).", "status": "machine-draft" } }, "ADTIER-006": { "name": { "value": "Account amministrativi Tier-0 al di fuori di una OU Tier-0 dedicata", "status": "machine-draft" }, "description": { "value": "Se i tuoi Domain Admins risiedono nella stessa OU degli utenti normali, ogni GPO destinata agli utenti (script di accesso, criteri del browser, unità mappate, ecc.) si applica anche ai tuoi Domain Admins, il che significa che chiunque possa modificare quelle GPO può eseguire codice come Domain Admin al successivo accesso. Il modello a livelli di Microsoft raccomanda una OU di amministrazione Tier-0 dedicata con authorship delle GPO limitata e diritti di accesso limitati.", "status": "machine-draft" }, "recommendedValue": { "value": "Tutti i membri di Domain Admins, Enterprise Admins e Schema Admins si trovano in una OU Tier-0 dedicata (in genere OU=Tier-0,OU=Admin) con authorship delle GPO limitata.", "status": "machine-draft" }, "remediationSteps": { "value": "Crea OU=Tier-0,OU=Admin se non esiste. Sposta al suo interno tutti i membri di Domain/Enterprise/Schema Admins. Limita l'authorship delle GPO su quella OU (solo gli stessi amministratori Tier-0). Applica una GPO di restrizione dell'accesso dedicata affinché gli account Tier-0 possano accedere solo agli host Tier-0. Blocca l'ereditarietà sulla OU.", "status": "machine-draft" } }, "ADTIER-007": { "name": { "value": "Account di servizio con diritti di accesso interattivo tramite gruppo privilegiato", "status": "machine-draft" }, "description": { "value": "Gli account di servizio membri di Domain Admins (o di qualsiasi gruppo a cui è concesso 'Allow log on locally' tramite l'appartenenza predefinita a gruppi privilegiati) possono essere usati in modo interattivo. Gli aggressori adorano questo: catturano la password di un account di servizio (Kerberoasting, registro, script in SYSVOL), la usano in modo interattivo su una workstation, effettuano il dump di LSASS ed eseguono un pivot. Gli account di servizio non dovrebbero poter accedere in modo interattivo a nulla al di fuori dell'host che servono.", "status": "machine-draft" }, "recommendedValue": { "value": "Agli account di servizio (euristica: sAMAccountName che inizia con svc/sa/service o che ha uno SPN + nessun accesso interattivo recente) è esplicitamente negato 'Allow log on locally' e 'Allow log on through Remote Desktop Services' tramite il Default Domain Controllers Policy e una GPO dedicata di restrizione dell'accesso Tier-1/Tier-2.", "status": "machine-draft" }, "remediationSteps": { "value": "Individua gli account di servizio (dotati di SPN, convenzione di denominazione o inventario aziendale). Applica una GPO Default Domain Policy: Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment > 'Deny log on locally' = <gruppo-account-di-servizio>. Aggiungi gli stessi account a 'Deny log on through Remote Desktop Services'. Aggiungili a Protected Users dove supportato (Server 2012 R2+).", "status": "machine-draft" } } } |