Lezen in het Engels

Delen via


Hoe kan ik herstellen van een Golden gMSA-aanval

In dit artikel wordt een benadering beschreven voor het herstellen van de referenties van een beheerd serviceaccount (gMSA) van een groep dat wordt beïnvloed door een incident met blootstelling van een domeincontrollerdatabase.

Symptomen

Zie het volgende Semperis-artikel voor een beschrijving van een Golden gMSA-aanval:

Introductie van de Golden GMSA-aanval

De beschrijving in het bovenstaande artikel is nauwkeurig. De aanpak voor het oplossen van het probleem is het vervangen van het hoofdsleutelobject van microsoft-sleuteldistributie (kdssvc.dll, ook wel KDS genoemd) en alle gMSA's die gebruikmaken van het gecompromitteerde KDS-hoofdsleutelobject.

Meer informatie

Bij een geslaagde aanval op een gMSA verkrijgt de aanvaller alle belangrijke kenmerken van het KDS-hoofdsleutelobject en de Sid kenmerken msds-ManagedPasswordID van een gMSA-object.

Het msds-ManagedPasswordID kenmerk is alleen aanwezig op een beschrijfbare kopie van het domein. Dus als de database van een domeincontroller wordt weergegeven, is alleen het domein dat door de domeincontroller wordt gehost, open voor de Golden gMSA-aanval. Als de aanvaller echter kan verifiëren bij een domeincontroller van een ander domein in het forest, heeft de aanvaller mogelijk voldoende machtigingen om de inhoud van msds-ManagedPasswordID. De aanvaller kan deze informatie vervolgens gebruiken om een aanval te maken tegen gMSA's in extra domeinen.

Als u extra domeinen van uw forest wilt beveiligen nadat één domein is blootgesteld, moet u alle gMSA's in het blootgestelde domein vervangen voordat de aanvaller de informatie kan gebruiken. Normaal gesproken weet u niet wat er is weergegeven. Daarom wordt voorgesteld om de resolutie toe te passen op alle domeinen van het forest.

Als proactieve meting kan controle worden gebruikt om de blootstelling van het KDS-hoofdsleutelobject bij te houden. Een systeemtoegangsbeheerlijst (SACL) met geslaagde leesbewerkingen kan worden geplaatst op de hoofdhoofdsleutelcontainer, waardoor controle van geslaagde leesbewerkingen op het msKds-RootKeyData kenmerk van de msKds-ProvRootKey klasse mogelijk is. Deze actie bepaalt het blootstellingslandschap van het object met betrekking tot een Golden gMSA-aanval.

Notitie

Controle helpt alleen bij het detecteren van een online aanval op de KDS-basissleutelgegevens.

U kunt de ManagedPasswordIntervalInDays parameter instellen op 15 dagen of een geschikte waarde kiezen bij het maken van een gMSA, omdat de ManagedPasswordIntervalInDays waarde alleen-lezen wordt nadat een gMSA is gemaakt.

In geval van inbreuk kan deze instelling de volgende rolling tijd verminderen.

Dit vermindert het theoretische aantal gMSA dat opnieuw moet worden gemaakt tussen de datum van de herstelde back-up en het einde van de blootstelling van de database, of ten minste de duur van het risicovenster tot deze gMSA-roll, als u zich houdt aan Scenario 1.

Hier volgt een voorbeeldscenario:

  1. Nadat een database is blootgesteld, voert u het herstel uit in 'Dag D'.

  2. De herstelde back-up is van D-15.

    Notitie

    D-15 betekent de dag die 15 dagen vóór 'Dag D' is.

  3. De gMSA-waarde ManagedPasswordIntervalInDays is 15.

  4. gMSA's bestaan en hebben D-1 gerolld.

  5. Nieuwere gMSA's zijn gemaakt op basis van D-10.

  6. Het compromis vindt plaats op D-5 en er zijn op deze datum enkele gMSA's gemaakt.

Dit zijn de resultaten:

  1. gMSA's die zijn gemaakt tussen D en D-5 zijn niet betrokken*.

  2. gMSA's die zijn gemaakt tussen D-15 (back-up hersteld) en D-5 (inbreuk)* moeten opnieuw worden gemaakt of de risicovensters moeten worden aangenomen als u kunt wachten vanaf D+5 tot en met D+10. Bijvoorbeeld:

    • Op D+5 moeten gMSA's die zijn gemaakt op D-10 opnieuw worden gemaakt.
    • Op D+10 moeten gMSA's die zijn gemaakt op D-5 opnieuw worden gemaakt.

    *Is afhankelijk van de exacte tijd van inbreuk of back-up.

Hier volgt een voorbeeldtijdlijn:

Diagram van een voorbeeldtijdlijn gMSA's.

Voor foutopsporing kunt u de gebeurtenis-id's voor het gebeurtenislogboek System, Security, Directory Services en Security-Netlogon bekijken.

Zie Microsoft- en Azure-beveiligingsresources gebruiken voor meer informatie over een inbreuk op systemische identiteiten.

Oplossing

Gebruik een van de volgende benaderingen om dit probleem op te lossen, afhankelijk van uw situatie. De benaderingen omvatten het maken van een nieuw KDS-hoofdsleutelobject en het opnieuw starten van de Microsoft Key Distribution-service op alle domeincontrollers van het domein.

Scenario 1: U hebt betrouwbare informatie over welke informatie beschikbaar is gesteld en wanneer

Als u weet dat de blootstelling vóór een bepaalde datum heeft plaatsgevonden en deze datum ouder is dan het oudste gMSA-wachtwoord dat u hebt, kunt u het probleem oplossen zonder de gMSA's opnieuw te maken, zoals wordt weergegeven in de onderstaande procedure.

De aanpak is het maken van een nieuw KDS-hoofdsleutelobject dat onbekend is voor de aanvaller. Wanneer de gMSA's hun wachtwoord implementeren, worden ze verplaatst naar het nieuwe KDS-hoofdsleutelobject. Als u gMSA's wilt herstellen die onlangs hun wachtwoord hebben gerolld met behulp van de oude KDS-hoofdsleutel, is een gezaghebbende herstelbewerking vereist om een wachtwoordupdate onmiddellijk na het herstellen af te dwingen.

Notitie

  • U hoeft gMSA's die zijn gemaakt nadat de Active Directory-domein Services -databaseblootstelling (AD DS) is beëindigd, niet handmatig te herstellen. De aanvaller weet de details van deze accounts niet en de wachtwoorden voor deze accounts worden opnieuw gegenereerd op basis van het nieuwe KDS-hoofdsleutelobject.
  • Houd rekening met het gMSA-object in de onderhoudsmodus totdat de procedure is voltooid en negeer mogelijke fouten die worden gerapporteerd met de accounts in het gebeurtenislogboek System, Security, Directory Services en Security-Netlogon.
  • In de handleiding wordt ervan uitgegaan dat de gMSA's onderliggende objecten zijn van de container Managed Service Accounts . Als u de accounts hebt verplaatst naar aangepaste bovenliggende containers, moet u de stappen uitvoeren die betrekking hebben op de container Beheerde serviceaccounts op de gMSA in deze containers.
  • Met een gezaghebbende herstelbewerking worden alle kenmerken teruggezet naar de status waarin ze zich bevonden op het moment van de back-up, inclusief de accounts die de gMSA-referenties (PrincipalsAllowedToRetrieveManagedPassword) mogen ophalen.

Voer in het domein met de gMSA's die u wilt herstellen de volgende stappen uit:

  1. Haal een domeincontroller offline en isoleer deze van het netwerk.

  2. Herstel de domeincontroller vanaf een back-up die is gemaakt vóór de blootstelling van de AD DS-database.

    Als het wachtwoordinterval voor de gMSA's langer is dan de leeftijd van de back-up, kunt u besluiten om het venster waarin het vorige sleutelmateriaal nog steeds werkt te tolereren. Als u niet zo lang kunt wachten en de overeenkomende oudere back-up te veel gMSA's mist, moet u het plan overschakelen naar Scenario 2.

  3. Voer een gezaghebbende herstelbewerking uit op de container Managed Service Accounts van het domein. Zorg ervoor dat de herstelbewerking alle onderliggende objecten van de containers bevat die mogelijk aan deze domeincontroller zijn gekoppeld. Met deze stap wordt de status van de laatste wachtwoordupdate teruggedraaid. De volgende keer dat een service het wachtwoord ophaalt, wordt het wachtwoord bijgewerkt naar een nieuwe op basis van het nieuwe KDS-hoofdsleutelobject.

  4. Stop en schakel de Microsoft Key Distribution-service uit op de herstelde domeincontroller.

  5. Volg op een andere domeincontroller de stappen in Sleuteldistributieservices KDS-hoofdsleutel maken om een nieuw KDS-hoofdsleutelobject te maken.

    Notitie

    In de productieomgeving moet u 10 uur wachten om ervoor te zorgen dat de nieuwe KDS-hoofdsleutel beschikbaar is. Controleer het EffectiveTime kenmerk om te weten wanneer de nieuwe KDS-hoofdsleutel bruikbaar is.

  6. Start de Microsoft Key Distribution-service opnieuw op alle domeincontrollers.

  7. Een nieuw gMSA maken. Zorg ervoor dat de nieuwe gMSA het nieuwe KDS-hoofdsleutelobject gebruikt om de waarde voor het msds-ManagedPasswordID kenmerk te maken.

    Notitie

    Deze stap is optioneel, maar hiermee kunt u valideren dat de nieuwe KDS-hoofdsleutel momenteel wordt gebruikt en wordt gebruikt in de Microsoft Key Distribution-service.

  8. Controleer de msds-ManagedPasswordID waarde van de eerste gMSA die u hebt gemaakt. De waarde van dit kenmerk is binaire gegevens die de GUID van het overeenkomende KDS-hoofdsleutelobject bevatten.

    Stel dat het KDS-hoofdsleutelobject het volgende CNheeft.

    Schermopname van de waarde van het CN-kenmerk van een KDS-hoofdsleutelobject.

    Een gMSA die met dit object wordt gemaakt, heeft een msds-ManagedPasswordID waarde die lijkt op het volgende.

    Schermopname van de waarde van het kenmerk msDS-ManagedPasswordId van een gMSA-object, waarin wordt getoond hoe het de onderdelen van het CN-kenmerk van de KDS-hoofdsleutel bevat.

    In deze waarde beginnen de GUID-gegevens bij offset 24. De onderdelen van de GUID bevinden zich in een andere volgorde. In deze afbeelding identificeren de rode, groene en blauwe secties de opnieuw gerangschikte onderdelen. De oranje sectie identificeert het deel van de reeks dat hetzelfde is als de oorspronkelijke GUID.

    Als de eerste gMSA die u hebt gemaakt gebruikmaakt van de nieuwe KDS-hoofdsleutel, gebruiken alle volgende gMSA's ook de nieuwe sleutel.

  9. Schakel de Microsoft Key Distribution-service op alle domeincontrollers uit en stop deze.

  10. Maak opnieuw verbinding en breng de herstelde domeincontroller weer online. Zorg ervoor dat de replicatie werkt.

    Nu worden de bindende herstelbewerking en alle andere wijzigingen (inclusief de herstelde GMSA's) gerepliceerd.

  11. Schakel Microsoft Key Distribution Service opnieuw in en start deze op alle domeincontrollers. De geheimen van de herstelde gMSA's worden samengevouwen en nieuwe wachtwoorden worden gemaakt op basis van het nieuwe KDS-hoofdsleutelobject op aanvraag.

    Notitie

    Als de gMSA's worden hersteld, maar niet worden gebruikt en de PrincipalsAllowedToRetrieveManagedPassword parameter is ingevuld, kunt u de Test-ADServiceAccount cmdlet uitvoeren op de herstelde gMSA met behulp van een principal die het wachtwoord mag ophalen. Als er een wachtwoordwijziging nodig is, worden met deze cmdlet de gMSA's naar de nieuwe KDS-hoofdsleutel gerold.

  12. Controleer of alle gMSA's zijn samengerold.

    Notitie

    De gMSA zonder de PrincipalsAllowedToRetrieveManagedPassword ingevulde parameter wordt nooit meegerold.

  13. Verwijder het oude KDS-hoofdsleutelobject en controleer de replicaties.

  14. Start de Microsoft Key Distribution-service opnieuw op alle domeincontrollers.

Scenario 2: U weet niet wat de details zijn van de blootstelling van het KDS-hoofdsleutelobject en u kunt niet wachten tot wachtwoorden worden gerold

Als u niet weet welke informatie beschikbaar is gesteld of wanneer deze werd weergegeven, kan een dergelijke blootstelling deel uitmaken van een volledige blootstelling van uw Active Directory-forest. Dit kan een situatie creëren waarin de aanvaller offlineaanvallen op alle wachtwoorden kan uitvoeren. In dit geval kunt u overwegen een forestherstel uit te voeren of alle accountwachtwoorden opnieuw in te voeren. Het herstellen van de gMSA's naar een schone status maakt deel uit van deze activiteit.

Tijdens het volgende proces moet u een nieuw KDS-hoofdsleutelobject maken. Vervolgens gebruikt u dit object om alle gMSA's in de domeinen van het forest te vervangen die gebruikmaken van het weergegeven KDS-hoofdsleutelobject.

Notitie

De volgende stappen lijken op de procedure in Aan de slag met door groepen beheerde serviceaccounts. Er zijn echter enkele belangrijke wijzigingen.

Volg vervolgens deze stappen:

  1. Schakel alle bestaande gMSA's uit en markeer ze als accounts die moeten worden verwijderd. Hiervoor stelt u voor elk account het userAccountControl kenmerk in op 4098 (deze waarde combineert WORKSTATION_TRUST_ACCOUNT- en ACCOUNTDISABLE-markeringen (uitgeschakeld ).

    U kunt een PowerShell-script als volgt gebruiken om de accounts in te stellen:

     $Domain = (Get-ADDomain).DistinguishedName
     $DomainGMSAs = (Get-ADObject -Searchbase "$Domain" -LdapFilter 'objectclass=msDS-GroupManagedServiceAccount').DistinguishedName
     ForEach ($GMSA In $DomainGMSAs)
     {
         Set-ADObject "$GMSA" -Add @{ adminDescription='cleanup-gsma' } -Replace @{ userAccountControl=4098 }
     }
    
  2. Gebruik één domeincontroller en volg deze stappen:

    1. Volg de stappen in Sleuteldistributieservices KDS-hoofdsleutel maken om een nieuw KDS-hoofdsleutelobject te maken.

    2. Start de Microsoft Key Distribution-service opnieuw. Nadat de service opnieuw is opgestart, wordt het nieuwe object opgehaald.

    3. Maak een back-up van DNS-hostnamen en SPN's (Service Principal Names) die zijn gekoppeld aan elke gMSA die is gemarkeerd om te worden verwijderd.

    4. Bewerk de bestaande gMSA's om de SPN's en DNS-hostnamen te verwijderen.

    5. Maak nieuwe gMSA's om de bestaande gMSA's te vervangen. Ze moeten ook worden geconfigureerd met de DNS-hostnamen en SPN's die u zojuist hebt verwijderd.

      Notitie

      U moet ook alle machtigingsvermeldingen controleren met behulp van de rechtstreeks verwijderde gMSA-SID's, omdat ze niet meer kunnen worden omgezet. Als u een toegangsbeheervermelding (ACE) vervangt, kunt u overwegen groepen te gebruiken om gMSA-machtigingsvermeldingen te beheren.

  3. Controleer de nieuwe gMSA's om ervoor te zorgen dat ze het nieuwe KDS-hoofdsleutelobject gebruiken. Hiervoor volgt u deze stappen:

    1. Noteer de CN waarde (GUID) van het KDS-hoofdsleutelobject.

    2. Controleer de msds-ManagedPasswordID waarde van de eerste gMSA die u hebt gemaakt. De waarde van dit kenmerk is binaire gegevens die de GUID van het overeenkomende KDS-hoofdsleutelobject bevatten.

      Stel dat het KDS-hoofdsleutelobject het volgende CNheeft.

      Schermopname van de waarde van het CN-kenmerk van een KDS-hoofdsleutelobject.

      Een gMSA die met dit object wordt gemaakt, heeft een msds-ManagedPasswordID waarde die lijkt op de afbeelding.

      Schermopname van de waarde van het kenmerk msDS-ManagedPasswordId van een gMSA-object, waarin wordt getoond hoe het de onderdelen van het CN-kenmerk van de KDS-hoofdsleutel bevat.

      In deze waarde beginnen de GUID-gegevens bij offset 24. De onderdelen van de GUID bevinden zich in een andere volgorde. In deze afbeelding identificeren de rode, groene en blauwe secties de opnieuw gerangschikte onderdelen. De oranje sectie identificeert het deel van de reeks dat hetzelfde is als de oorspronkelijke GUID.

      Als de eerste gMSA die u hebt gemaakt gebruikmaakt van de nieuwe KDS-hoofdsleutel, gebruiken alle volgende gMSA's ook de nieuwe sleutel.

  4. Werk de juiste services bij om de nieuwe GMSA's te gebruiken.

  5. Verwijder de oude gMSA's die het oude KDS-hoofdsleutelobject hebben gebruikt met behulp van de volgende cmdlet:

    $Domain = (Get-ADDomain).DistinguishedName
    $DomainGMSAs = (Get-ADObject -Searchbase "$Domain" -LdapFilter '(&(objectClass=msDS-GroupManagedServiceAccount)(adminDescription=cleanup-gsma))').DistinguishedName
    ForEach ($GMSA In $DomainGMSAs)
    {
        Remove-ADObject "$GMSA" -Confirm:$False
    }
    
  6. Verwijder het oude KDS-hoofdsleutelobject en controleer de replicaties.

  7. Start de Microsoft Key Distribution-service opnieuw op alle domeincontrollers.

Scenario 3: Het intrekken van een domeinbeheerder, er is op dat moment geen informatie gestolen en u kunt wachten totdat wachtwoorden worden gerold

Als een lid met hoge bevoegdheden met domeinbeheerders of gelijkwaardige rechten wordt ontslagen, is er geen bewijs van de blootstelling van de KDS-hoofdsleutel op het moment en kunt u zich een tijdvenster veroorloven voor het rollen van wachtwoorden. U hoeft de gMSA's niet opnieuw te maken.

Als preventieve maatregel moet de KDS-hoofdsleutel worden geïmplementeerd om aanvallen na misbruik te voorkomen. Een voormalige domeinbeheerder is bijvoorbeeld een rogue en heeft een aantal back-ups bewaard.

Er wordt een nieuw KDS-hoofdsleutelobject gemaakt en gMSA's worden op natuurlijke wijze geïmplementeerd.

Notitie

Voor een inbreuk met betrekking tot een domeinbeheerder raadpleegt u Scenario 1 of Scenario 2 op basis van wat er is weergegeven en volgt u de on-premises herstelactiviteiten in 'Microsoft- en Azure-beveiligingsresources gebruiken om te helpen herstellen van systemische identiteitscompromittatie'.

Voer in het domein met de gMSA's die u wilt implementeren de volgende stappen uit:

  1. Volg op een domeincontroller de stappen in Key Distribution Services KDS Root Key maken om een nieuw KDS-hoofdsleutelobject te maken.

    Notitie

    In de productieomgeving moet u 10 uur wachten om ervoor te zorgen dat de nieuwe KDS-hoofdsleutel beschikbaar is. Controleer het EffectiveTime kenmerk om te weten wanneer de nieuwe KDS-hoofdsleutel bruikbaar is.

  2. Start de Microsoft Key Distribution-service opnieuw op alle domeincontrollers.

  3. Een nieuw gMSA maken. Zorg ervoor dat de nieuwe gMSA het nieuwe KDS-hoofdsleutelobject gebruikt om de waarde voor het msds-ManagedPasswordID kenmerk te maken.

    Notitie

    Deze stap is optioneel, maar hiermee kunt u valideren dat de nieuwe KDS-hoofdsleutel momenteel wordt gebruikt en wordt gebruikt in de Microsoft Key Distribution-service.

  4. Controleer de msds-ManagedPasswordID waarde van de eerste gMSA die u hebt gemaakt. De waarde van dit kenmerk is binaire gegevens die de GUID van het overeenkomende KDS-hoofdsleutelobject bevatten.

    Stel dat het KDS-hoofdsleutelobject het volgende CNheeft.

    Schermopname van de waarde van het CN-kenmerk van een KDS-hoofdsleutelobject.

    Een gMSA die met dit object wordt gemaakt, heeft een msds-ManagedPasswordID waarde die lijkt op de volgende afbeelding.

    Schermopname van de waarde van het kenmerk msDS-ManagedPasswordId van een gMSA-object, waarin wordt getoond hoe het de onderdelen van het CN-kenmerk van de KDS-hoofdsleutel bevat.

    In deze waarde beginnen de GUID-gegevens bij offset 24. De onderdelen van de GUID bevinden zich in een andere volgorde. In deze afbeelding identificeren de rode, groene en blauwe secties de opnieuw gerangschikte onderdelen. De oranje sectie identificeert het deel van de reeks dat hetzelfde is als de oorspronkelijke GUID.

    Als de eerste gMSA die u hebt gemaakt gebruikmaakt van de nieuwe KDS-hoofdsleutel, gebruiken alle volgende gMSA's ook de nieuwe sleutel.

  5. Afhankelijk van de volgende wachtwoordroll worden de geheimen van de gMSA's op natuurlijke wijze geïmplementeerd en worden nieuwe wachtwoorden gemaakt op basis van het nieuwe KDS-hoofdsleutelobject op aanvraag.

    Notitie

    Als gMSA's zijn gerolld, maar ongebruikte gMSA's met hetzelfde roll-interval niet hebben en de PrincipalsAllowedToRetrieveManagedPassword parameter is ingevuld, kunt u de Test-ADServiceAccount cmdlet uitvoeren. Er wordt een principal gebruikt die het gMSA-wachtwoord mag ophalen. Met deze stap wordt de gMSA vervolgens verplaatst naar de nieuwe KDS-hoofdsleutel.

  6. Controleer of alle gMSA's zijn samengerold.

    Notitie

    De gMSA zonder de PrincipalsAllowedToRetrieveManagedPassword parameter wordt nooit meegerold.

  7. Nadat alle gMSA's zijn gerolld naar het nieuwe KDS-hoofdsleutelobject, verwijdert u het oude KDS-hoofdsleutelobject en controleert u de replicaties.

  8. Start de Microsoft Key Distribution-service opnieuw op alle domeincontrollers.

Verwijzingen

Overzicht van beheerde serviceaccounts voor groepen

Disclaimerinformatie van derden

Microsoft biedt contactgegevens van derden om u te helpen aanvullende informatie over dit onderwerp te vinden. Deze contactinformatie kan zonder voorafgaande kennisgeving worden gewijzigd. Microsoft garandeert niet de nauwkeurigheid van contactgegevens van derden.