Data/Locales/checks/da/TierZeroChecks.json
|
{ "_family": "TierZeroChecks.json", "ADTIER-001": { "name": { "value": "Revision af Azure AD Connect-synkroniseringskonto (MSOL_)", "status": "machine-draft" }, "description": { "value": "Når Azure AD Connect installeres i Express-tilstand, opretter den en domænekonto med navnet MSOL_<tilfældig-hex> og tildeler den Replicating Directory Changes + Replicating Directory Changes All på domænets navnekontekst, altså DCSync-rettigheder. Kontoen er reelt Tier 0, men den lever som standard i standardcontaineren Users, har et udløb på adgangskoden på 10 år og optræder sjældent i værktøjer til optælling af privilegerede grupper, fordi den får sin magt via en direkte ACL frem for gruppemedlemskab. Kompromittering af denne konto er funktionelt en domæneovertagelse.", "status": "machine-draft" }, "recommendedValue": { "value": "Alle MSOL_-konti er optalt, adgangskode roteret inden for de sidste 180 dage, placeret i en Tier 0-OU med begrænsede logonrettigheder, og selve AAD Connect-serveren er hærdet som et Tier 0-system.", "status": "machine-draft" }, "remediationSteps": { "value": "Find MSOL_-kontoen: Get-ADUser -Filter {sAMAccountName -like 'MSOL_*'}. Bekræft, at den har DCSync-rettigheder: dsacls 'DC=domain,DC=com' | findstr MSOL_. Flyt den til en Tier 0-admin-OU. Rotér adgangskoden med AAD Connect-værktøjerne (nulstil IKKE via standardværktøjer: brug Add-ADSyncADDSConnectorAccount i ADSync PowerShell-modulet på AAD Connect-serveren). Anvend en logonbegrænsnings-GPO, så kontoen kun kan logge lokalt på selve AAD Connect-serveren. Behandl AAD Connect-værten som Tier 0: begræns, hvem der kan RDP'e/administrere den.", "status": "machine-draft" } }, "ADTIER-002": { "name": { "value": "Tjenestekonti til backupsoftware i privilegerede grupper", "status": "machine-draft" }, "description": { "value": "Backupsoftware (Veeam, Commvault, Rubrik, Cohesity, NAKIVO, Backup Exec, Vembu, Acronis) beder typisk om en tjenestekonto med meget høje tilladelser. Dokumentationen foreslår ofte Domain Admin for at lette opsætningen, og mange administratorer efterkommer det. Når en angriber først kompromitterer backupserveren (en hyppig vektor for indledende adgang ved ransomware), arver de Domain Admin via tjenestekontoen. Dette er den mest udbredte ransomware-eskaleringssti i hændelsesresponsdata fra 2023-2025.", "status": "machine-draft" }, "recommendedValue": { "value": "Ingen tjenestekonti til backupsoftware er medlemmer af Domain Admins, Enterprise Admins, Schema Admins eller Backup Operators. Brug leverandørdokumenterede konti med mindste privilegium og isolerede backuplegitimationsoplysninger.", "status": "machine-draft" }, "remediationSteps": { "value": "Identificer det anvendte backupprodukt, og følg dets vejledning om mindste privilegium (Veeam: kun lokal administrator på backupserveren + AD-konto med objektlæsning; Rubrik: dedikeret tjenesteprincipal i en cloud-only-rolle; osv.). Fjern backupkontoen fra Domain Admins. Migrer til en gMSA, hvor det understøttes. Placér backupserveren i en Tier 1-OU med begrænsede logonrettigheder. Hvis fuld DA reelt er påkrævet til en specifik arbejdsbelastning, skal du dokumentere det og isolere den del af backup til sin egen konto adskilt fra hovedkontoen.", "status": "machine-draft" } }, "ADTIER-003": { "name": { "value": "Tjenestekonti til hypervisor/virtualisering i privilegerede grupper", "status": "machine-draft" }, "description": { "value": "vCenter- / Hyper-V- / SCVMM- / Citrix- / Nutanix-integrationer med AD anvender ofte en tjenestekonto, der konfigureres under opsætningen. Hvis den konto er en Domain Admin, kaskaderer kompromittering af hypervisorens administrationsplan (eller værtens SSO-database) til AD. Hypervisoren er konceptuelt allerede Tier 0; dens AD-identitet bør matche.", "status": "machine-draft" }, "recommendedValue": { "value": "Hypervisor-tjenestekonti har kun de rettigheder, der er dokumenteret af leverandøren (typisk læsning til oversigt + specifikke OU-skrivninger, hvis VM-AD-integration anvendes). Ikke i Domain Admins.", "status": "machine-draft" }, "remediationSteps": { "value": "Gennemgå AD-tjenestekontoen for hvert hypervisorprodukt. Anvend leverandørens vejledning om mindste privilegium. For vCenter: brug det dokumenterede SSO-identitetskildemønster frem for at tilknytte en Domain Admin. For Hyper-V/SCVMM: afgræns tjenestekontoens rettigheder til de OU'er, der hoster VM-computerkonti. Behandl hypervisorens administrationsvært som Tier 0 i din administrative model.", "status": "machine-draft" } }, "ADTIER-004": { "name": { "value": "Tjenestekonti til konfigurationsstyring i privilegerede grupper", "status": "machine-draft" }, "description": { "value": "Konfigurationsstyringsplatforme (SCCM/MECM, Intune Connector, Jamf, KACE, Lansweeper, ManageEngine, Ivanti, BigFix) skubber pr. definition software ud til hvert endepunkt: de er allerede en privilegeret platform for lateral bevægelse. SCCM har i særdeleshed velkendte misbrugsprimitiver (eksponering af Network Access Account, NTLM-tvang til site-serveren, client push). En konfigurationsstyringstjenestekonto i Domain Admins giver en angriber, der lander på et hvilket som helst administreret endepunkt, nøglerne til domænet.", "status": "machine-draft" }, "recommendedValue": { "value": "Konfigurationsstyringstjenestekonti er afgrænset til deres dokumenterede mindste rettigheder og aldrig i Domain Admins / Enterprise Admins. SCCM Network Access Account er en ikke-privilegeret, dedikeret identitet.", "status": "machine-draft" }, "remediationSteps": { "value": "Identificer konfigurationsstyringsproduktet, og gennemgå tjenestekontoens rettigheder. For SCCM: sørg for, at Network Access Account er ikke-privilegeret (IKKE en Domain Admin); sørg for, at site-serverens maskinkonto ikke er en Domain Admin; gennemgå hierarki-tjenestekonti for mindste privilegium. Flyt site-servere og management points til en Tier 0-OU med begrænsede logon.", "status": "machine-draft" } }, "ADTIER-005": { "name": { "value": "Tjenestekonti til SQL/database i privilegerede grupper", "status": "machine-draft" }, "description": { "value": "SQL Server- / MySQL- / PostgreSQL-tjenestekonti i Domain Admins er almindelige i miljøer, hvor DBA-teamet installerede SQL med standardvejledningen 'Use existing AD account' og valgte en administratorkonto af bekvemmelighed. Når databaseserveren først kan nås på netværket, giver en kompromittering af en SQL-legitimationsoplysning eller en SQL Server-sårbarhed angriberen Domain Admin direkte.", "status": "machine-draft" }, "recommendedValue": { "value": "Databasetjenestekonti kører som gMSA'er eller dedikerede tjenesteidentiteter uden medlemskab af privilegerede grupper.", "status": "machine-draft" }, "remediationSteps": { "value": "Migrer SQL-tjenestekonti til gMSA, hvor det understøttes. For konti, der skal forblive brugerbaserede, skal du fjerne medlemskab af privilegerede grupper og kun tildele de lokale rettigheder, databasemotoren kræver (Log on as a service, Bypass traverse checking, Adjust memory quotas for a process, se Microsoft-dokumentationen for de specifikke rettigheder).", "status": "machine-draft" } }, "ADTIER-006": { "name": { "value": "Tier 0-administratorkonti uden for en dedikeret Tier 0-OU", "status": "machine-draft" }, "description": { "value": "Hvis dine Domain Admins bor i den samme OU som almindelige brugere, gælder enhver GPO, der er rettet mod brugere (logonscripts, browserpolitik, tilknyttede drev osv.), også for dine Domain Admins, hvilket betyder, at enhver, der kan redigere de GPO'er, kan køre kode som en Domain Admin ved næste logon. Microsofts tiermodel anbefaler en dedikeret Tier 0-admin-OU med begrænset GPO-forfatterskab og begrænsede logonrettigheder.", "status": "machine-draft" }, "recommendedValue": { "value": "Alle medlemmer af Domain Admins, Enterprise Admins og Schema Admins er i en dedikeret Tier 0-OU (typisk OU=Tier-0,OU=Admin) med begrænset GPO-forfatterskab.", "status": "machine-draft" }, "remediationSteps": { "value": "Opret OU=Tier-0,OU=Admin, hvis den ikke findes. Flyt alle medlemmer af Domain/Enterprise/Schema Admins ind i den. Begræns GPO-forfatterskabet på den OU (kun Tier 0-administratorerne selv). Anvend en dedikeret logonbegrænsnings-GPO, så Tier 0-konti kun kan logge på Tier 0-værter. Bloker nedarvning på OU'en.", "status": "machine-draft" } }, "ADTIER-007": { "name": { "value": "Tjenestekonti med interaktive logonrettigheder via privilegeret gruppe", "status": "machine-draft" }, "description": { "value": "Tjenestekonti, der er medlemmer af Domain Admins (eller en hvilken som helst gruppe, der tildeles 'Allow log on locally' via standardmedlemskab af en privilegeret gruppe), kan anvendes interaktivt. Angribere elsker dette: opsnap en tjenestekontos adgangskode (Kerberoasting, registreringsdatabase, scripts i SYSVOL), brug den interaktivt på en arbejdsstation, dump LSASS, og pivotér. Tjenestekonti bør ikke kunne logge interaktivt på andet end den vært, de betjener.", "status": "machine-draft" }, "recommendedValue": { "value": "Tjenestekonti (heuristik: sAMAccountName starter med svc/sa/service eller har SPN + ingen interaktiv logon for nylig) nægtes eksplicit 'Allow log on locally' og 'Allow log on through Remote Desktop Services' via Default Domain Controllers Policy og en dedikeret Tier 1-/Tier 2-logonbegrænsnings-GPO.", "status": "machine-draft" }, "remediationSteps": { "value": "Identificer tjenestekonti (SPN-bærende, navngivningskonvention eller forretningsoversigt). Anvend en Default Domain Policy-GPO: Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment > 'Deny log on locally' = <tjenestekontogruppe>. Føj de samme konti til 'Deny log on through Remote Desktop Services'. Føj dem til Protected Users, hvor det understøttes (Server 2012 R2+).", "status": "machine-draft" } } } |