Delen via

Herstellen van systeemidentiteitscompromittatie

  • Artikel

In dit artikel worden Microsoft-resources en aanbevelingen beschreven voor het herstellen van een systemische identiteitsinbreukaanval tegen uw organisatie die zich kan voordoen tijdens een ransomware-aanval.

De inhoud in dit artikel is gebaseerd op richtlijnen van het Microsoft Incident Response-team (voorheen DART/CRSP), dat werkt om te reageren op compromissen en klanten te helpen cybertolerant te worden. Zie de microsoft-beveiligingsblogreeks voor meer richtlijnen van het Team voor Het reageren op incidenten van Microsoft.

Veel organisaties zijn overgestapt op een cloudbenadering voor sterkere beveiliging op hun identiteits- en toegangsbeheer. Uw organisatie kan echter ook on-premises systemen hebben en verschillende methoden voor hybride architectuur gebruiken. In dit artikel wordt bevestigd dat systeemaanvallen invloed hebben op cloud-, on-premises en hybride systemen en aanbevelingen en verwijzingen voor al deze omgevingen bieden.

Belangrijk

Deze informatie wordt als zodanig verstrekt en vormt gegeneraliseerde richtlijnen; de ultieme vastberadenheid over het toepassen van deze richtlijnen op uw IT-omgeving en tenant(s) moet rekening houden met uw unieke omgeving en behoeften, die elke klant het beste kan bepalen.

Over systeemidentiteitscompromittatie

Een systemische aanval op inbreuk op identiteiten op een organisatie treedt op wanneer een aanvaller een voet aan de grond krijgt in het beheer van de identiteitsinfrastructuur van een organisatie.

Als dit is gebeurd met uw organisatie, bent u in een race tegen de aanvaller om uw omgeving te beveiligen voordat verdere schade kan worden gedaan.

  • Aanvallers met beheerdersbeheer van de identiteitsinfrastructuur van een omgeving kunnen dat besturingselement gebruiken om identiteiten en identiteitsmachtigingen in die omgeving te maken, te wijzigen of te verwijderen.

    Als vertrouwde CERTIFICATEN voor SAML-tokenondertekening niet zijn opgeslagen in een HSM, bevat de aanval toegang tot dat vertrouwde SAML-tokenondertekeningscertificaat in een on-premises inbreuk.

  • Aanvallers kunnen vervolgens het certificaat gebruiken om SAML-tokens te vervalsen om een van de bestaande gebruikers en accounts van de organisatie te imiteren zonder toegang tot accountreferenties en zonder traceringen te verlaten.

  • Toegang tot accounts met hoge bevoegdheden kan ook worden gebruikt om door aanvallers beheerde referenties toe te voegen aan bestaande toepassingen, zodat aanvallers toegang hebben tot uw systeem dat niet is gedetecteerd, zoals API's aanroepen, met behulp van deze machtigingen.

Reageren op de aanval

Reageren op systemische identiteitscompromitties moet de stappen bevatten die worden weergegeven in de volgende afbeelding en tabel:

Stappen voor het herstellen van inbreuk op identiteiten.

Stap Beschrijving
Veilige communicatie tot stand brengen Een organisatie die een systeeminbreuk met een systemische identiteit heeft ervaren, moet ervan uitgaan dat alle communicatie wordt beïnvloed. Voordat u herstelacties uitvoert, moet u ervoor zorgen dat de leden van uw team die essentieel zijn voor uw onderzoek en reactie veilig kunnen communiceren.

Het beveiligen van communicatie moet uw eerste stap zijn, zodat u zonder de kennis van de aanvaller kunt doorgaan.
Uw omgeving onderzoeken Nadat u communicatie hebt beveiligd in uw kernonderzoeksteam, kunt u beginnen met het zoeken naar initiële toegangspunten en persistentietechnieken. Identificeer uw indicaties van inbreuk en zoek vervolgens naar initiële toegangspunten en persistentie. Begin tegelijkertijd met het tot stand brengen van continue bewakingsbewerkingen tijdens uw herstelinspanningen.
Beveiligingspostuur verbeteren Schakel beveiligingsfuncties en -mogelijkheden in volgens aanbevelingen voor aanbevolen procedures voor verbeterde systeembeveiliging.

Zorg ervoor dat u uw continue bewakingsinspanningen blijft voortzetten naarmate de tijd vordert en het beveiligingslandschap verandert.
Controle opnieuw krijgen/behouden U moet weer beheer van uw omgeving krijgen van de aanvaller. Nadat u de controle opnieuw hebt uitgevoerd en het beveiligingspostuur van uw systeem hebt vernieuwd, moet u alle mogelijke persistentietechnieken en nieuwe initiële toegangsexplotsies herstellen of blokkeren .

Veilige communicatie tot stand brengen

Voordat u reageert, moet u er zeker van zijn dat u veilig kunt communiceren zonder de aanvaller afluisteren. Zorg ervoor dat u alle communicatie met betrekking tot het incident isoleert, zodat de aanvaller niet wordt afgekeurd bij uw onderzoek en wordt uitgevoerd als verrassing bij uw reactieacties.

Voorbeeld:

  1. Voor eerste een-op-een- en groepscommunicatie wilt u mogelijk PSTN-oproepen, vergaderingsbruggen gebruiken die niet zijn verbonden met de bedrijfsinfrastructuur en end-to-end versleutelde berichtenoplossingen.

    Communicatie buiten deze frameworks moet worden behandeld als gecompromitteerd en niet-vertrouwd, tenzij geverifieerd via een beveiligd kanaal.

  2. Na deze eerste gesprekken wilt u mogelijk een volledig nieuwe Microsoft 365-tenant maken, geïsoleerd van de productietenant van de organisatie. Maak alleen accounts voor belangrijke medewerkers die deel moeten uitmaken van het antwoord.

Als u een nieuwe Microsoft 365-tenant maakt, moet u alle aanbevolen procedures voor de tenant volgen, met name voor beheerdersaccounts en -rechten. Beperk beheerdersrechten zonder vertrouwensrelaties voor externe toepassingen of leveranciers.

Belangrijk

Zorg ervoor dat u niet communiceert over uw nieuwe tenant op uw bestaande en mogelijk aangetaste e-mailaccounts.

Zie Aanbevolen procedures voor veilig gebruik van Microsoft 365 voor meer informatie.

Indicaties van inbreuk identificeren

We raden klanten aan updates van systeembeheerders te volgen, waaronder Zowel Microsoft als partners, en nieuwe detecties en beveiligingen te implementeren en gepubliceerde incidenten van inbreuk (IOC's) te identificeren.

Controleer op updates in de volgende Microsoft-beveiligingsproducten en implementeer eventuele aanbevolen wijzigingen:

Het implementeren van nieuwe updates helpt bij het identificeren van eventuele eerdere campagnes en het voorkomen van toekomstige campagnes op uw systeem. Houd er rekening mee dat lijsten met IOC's mogelijk niet volledig zijn en kunnen uitbreiden naarmate het onderzoek wordt voortgezet.

Daarom raden we u aan ook de volgende acties uit te voeren:

Zie de beveiligingsdocumentatie van Microsoft voor meer informatie:

Uw omgeving onderzoeken

Zodra uw incidentantwoorders en sleutelpersoneel een veilige plek hebben om samen te werken, kunt u beginnen met het onderzoeken van de gecompromitteerde omgeving.

U moet een balans vinden tussen elk afwijkend gedrag en snelle actie ondernemen om verdere activiteiten door de aanvaller te stoppen. Voor een geslaagd herstel is een goed begrip vereist van de initiële methode voor invoer- en persistentiemethoden die de aanvaller heeft gebruikt, zo volledig mogelijk op het moment. Eventuele persistentiemethoden die tijdens het onderzoek worden gemist, kunnen leiden tot voortdurende toegang door de aanvaller en een mogelijke hercompromise.

Op dit moment kunt u een risicoanalyse uitvoeren om prioriteit te geven aan uw acties. Zie voor meer informatie:

De beveiligingsservices van Microsoft bieden uitgebreide bronnen voor gedetailleerde onderzoeken. In de volgende secties worden de belangrijkste aanbevolen acties beschreven.

Notitie

Als u merkt dat een of meer van de vermelde logboekregistratiebronnen momenteel geen deel uitmaken van uw beveiligingsprogramma, raden we u aan deze zo snel mogelijk te configureren om detecties en toekomstige logboekbeoordelingen in te schakelen.

Zorg ervoor dat u uw logboekretentie configureert ter ondersteuning van de onderzoeksdoelen van uw organisatie. Bewaar het bewijs indien nodig voor juridische, wettelijke of verzekeringsdoeleinden.

Cloudomgevingslogboeken onderzoeken en controleren

Onderzoek en controleer de logboeken van de cloudomgeving op verdachte acties en aanvallers die inbreuk maken. Controleer bijvoorbeeld de volgende logboeken:

Controlelogboeken voor eindpunten controleren

Controleer uw auditlogboeken voor eindpunten op on-premises wijzigingen, zoals de volgende typen acties:

  • Wijzigingen in groepslidmaatschap
  • Nieuwe gebruikersaccount maken
  • Delegaties binnen Active Directory

Houd vooral rekening met een van deze wijzigingen die optreden samen met andere typische tekenen van inbreuk of activiteit.

Beheerrechten in uw omgevingen controleren

Controleer beheerrechten in zowel uw cloud- als on-premises omgevingen. Voorbeeld:

Environment Beschrijving
Alle cloudomgevingen - Controleer alle bevoegde toegangsrechten in de cloud en verwijder overbodige machtigingen
- Privileged Identity Management (PIM) implementeren
- Beleid voor voorwaardelijke toegang instellen om beheerderstoegang te beperken tijdens het beperken van de beveiliging
Alle on-premises omgevingen - Bevoegde toegang on-premises controleren en overbodige machtigingen verwijderen
- Lidmaatschap van ingebouwde groepen verminderen
- Active Directory-delegaties verifiëren
- Beperk uw Laag 0-omgeving en beperk wie toegang heeft tot laag 0-assets
Alle bedrijfstoepassingen Controleer op gedelegeerde machtigingen en toestemmingstoekenningen die een van de volgende acties toestaan:

- Bevoegde gebruikers en rollen wijzigen
- Alle postvakken lezen of openen
- E-mail verzenden of doorsturen namens andere gebruikers
- Toegang tot alle Inhoud van OneDrive- of SharePoint-sites
- Service-principals toevoegen die kunnen worden gelezen/geschreven naar de map
Microsoft 365-omgevingen Controleer de toegangs- en configuratie-instellingen voor uw Microsoft 365-omgeving, waaronder:
- Delen van SharePoint Online
- Microsoft Teams
- Power Apps
- Microsoft OneDrive voor Bedrijven
Gebruikersaccounts in uw omgevingen controleren - Controleer en verwijder gastgebruikersaccounts die niet meer nodig zijn.
- Controleer de e-mailconfiguraties voor gemachtigden, machtigingen voor postvakmappen, registraties van mobiele ActiveSync-apparaten, regels voor Postvak IN en opties voor de webversie van Outlook.
- Controleer applicationImpersonation-rechten en verminder het gebruik van verouderde verificatie zoveel mogelijk.
- Controleer of MFA wordt afgedwongen en of zowel MFA- als selfservice voor wachtwoordherstel (SSPR) contactgegevens voor alle gebruikers juist zijn.

Continue bewaking tot stand brengen

Het detecteren van het gedrag van een aanvaller omvat verschillende methoden en is afhankelijk van de beveiligingshulpprogramma's die uw organisatie beschikbaar heeft om te reageren op de aanval.

Microsoft-beveiligingsservices kunnen bijvoorbeeld specifieke resources en richtlijnen hebben die relevant zijn voor de aanval, zoals beschreven in de onderstaande secties.

Belangrijk

Als uw onderzoek bewijs vindt van beheerdersmachtigingen die zijn verkregen via de inbreuk op uw systeem, die toegang hebben verleend tot het globale beheerdersaccount van uw organisatie en/of het vertrouwde SAML-tokenondertekeningscertificaat, raden we u aan actie te ondernemen om beheerbeheer te herstellen en te behouden.

Bewaking met Microsoft Sentinel

Microsoft Sentinel heeft veel ingebouwde resources om u te helpen bij uw onderzoek, zoals opsporingswerkmappen en analyseregels waarmee aanvallen in relevante gebieden van uw omgeving kunnen worden gedetecteerd.

Gebruik de inhoudshub van Microsoft Sentinel om uitgebreide beveiligingsoplossingen en gegevensconnectors te installeren die inhoud van andere services in uw omgeving streamen. Zie voor meer informatie:

Bewaking met Microsoft Defender for IoT

Als uw omgeving ook resources voor operationele technologie (OT) bevat, hebt u mogelijk apparaten die gebruikmaken van gespecialiseerde protocollen, die prioriteit geven aan operationele uitdagingen ten opzichte van de beveiliging.

Implementeer Microsoft Defender for IoT om deze apparaten te bewaken en te beveiligen, met name apparaten die niet worden beveiligd door traditionele beveiligingsbewakingssystemen. Installeer Defender for IoT-netwerksensoren op specifieke nuttige plaatsen in uw omgeving om bedreigingen in lopende netwerkactiviteiten te detecteren met behulp van bewaking zonder agent en dynamische bedreigingsinformatie.

Zie Aan de slag met OT-netwerkbeveiligingsbewaking voor meer informatie.

Bewaking met Microsoft Defender XDR

U wordt aangeraden Microsoft Defender XDR voor Eindpunt en Microsoft Defender Antivirus te controleren op specifieke richtlijnen die relevant zijn voor uw aanval.

Controleer op andere voorbeelden van detecties, opsporingsquery's en bedreigingsanalyserapporten in het Microsoft-beveiligingscentrum, zoals in Microsoft Defender XDR, Microsoft Defender XDR voor identiteit en Microsoft Defender voor Cloud-apps. Zorg ervoor dat u de Microsoft Defender for Identity-agent installeert op ADFS-servers naast alle domeincontrollers om dekking te garanderen.

Zie voor meer informatie:

Bewaking met Microsoft Entra-id

Microsoft Entra-aanmeldingslogboeken kunnen laten zien of meervoudige verificatie correct wordt gebruikt. Open aanmeldingslogboeken rechtstreeks vanuit het gebied Microsoft Entra in Azure Portal, gebruik de cmdlet Get-MgBetaAuditLogSignIn of bekijk ze in het gebied Logboeken van Microsoft Sentinel.

Zoek of filter bijvoorbeeld de resultaten voor wanneer het veld MFA-resultaten een waarde heeft van de MFA-vereiste die is voldaan door claim in het token. Als uw organisatie ADFS gebruikt en de vastgelegde claims niet zijn opgenomen in de ADFS-configuratie, kunnen deze claims duiden op activiteiten van aanvallers.

Zoek of filter uw resultaten verder om extra ruis uit te sluiten. U kunt bijvoorbeeld alleen resultaten van federatieve domeinen opnemen. Als u verdachte aanmeldingen vindt, zoomt u nog verder in op basis van IP-adressen, gebruikersaccounts enzovoort.

In de volgende tabel worden meer methoden beschreven voor het gebruik van Microsoft Entra-logboeken in uw onderzoek:

Wijze Description
Riskante aanmeldingsgebeurtenissen analyseren Microsoft Entra ID en het Identity Protection-platform kunnen risicogebeurtenissen genereren die zijn gekoppeld aan het gebruik van door aanvaller gegenereerde SAML-tokens.

Deze gebeurtenissen kunnen worden gelabeld als onbekende eigenschappen, anoniem IP-adres, onmogelijke reizen, enzovoort.

We raden u aan alle risicogebeurtenissen die zijn gekoppeld aan accounts met beheerdersbevoegdheden nauwkeurig te analyseren, inclusief alle risicogebeurtenissen die mogelijk automatisch zijn verwijderd of hersteld. Een risicogebeurtenis of een anoniem IP-adres kan bijvoorbeeld automatisch worden hersteld omdat de gebruiker MFA heeft doorgegeven.

Zorg ervoor dat u ADFS Connect Health gebruikt, zodat alle verificatie-gebeurtenissen zichtbaar zijn in Microsoft Entra-id.
Eigenschappen van domeinverificatie detecteren Elke poging van de aanvaller om domeinverificatiebeleid te manipuleren, wordt vastgelegd in de auditlogboeken van Microsoft Entra en wordt weergegeven in het geïntegreerde auditlogboek.

Bekijk bijvoorbeeld alle gebeurtenissen die zijn gekoppeld aan domeinverificatie instellen in het geïntegreerde auditlogboek, Microsoft Entra-auditlogboeken en/of uw SIEM-omgeving om te controleren of alle vermelde activiteiten waren verwacht en gepland.
Referenties voor OAuth-toepassingen detecteren Aanvallers die de controle over een bevoegd account hebben verkregen, kunnen zoeken naar een toepassing met de mogelijkheid om toegang te krijgen tot e-mail van gebruikers in de organisatie en vervolgens door aanvallers beheerde referenties aan die toepassing toe te voegen.

U kunt bijvoorbeeld zoeken naar een van de volgende activiteiten, die consistent zijn met het gedrag van een aanvaller:
- Referenties voor service-principal toevoegen of bijwerken
- Toepassingscertificaten en -geheimen bijwerken
- Een toewijzing van een app-rol toevoegen aan een gebruiker
- Oauth2PermissionGrant toevoegen
Toegang tot e-mail detecteren via toepassingen Zoek naar toegang tot e-mail door toepassingen in uw omgeving. Gebruik bijvoorbeeld de Microsoft Purview-controle (Premium)-functies om gecompromitteerde accounts te onderzoeken.
Niet-interactieve aanmeldingen detecteren bij service-principals De Microsoft Entra-aanmeldingsrapporten bevatten details over niet-interactieve aanmeldingen waarvoor referenties voor de service-principal zijn gebruikt. U kunt bijvoorbeeld de aanmeldingsrapporten gebruiken om waardevolle gegevens te vinden voor uw onderzoek, zoals een IP-adres dat door de aanvaller wordt gebruikt voor toegang tot e-mailtoepassingen.

Beveiligingspostuur verbeteren

Als er een beveiligingsgebeurtenis in uw systemen is opgetreden, raden we u aan om na te denken over uw huidige beveiligingsstrategie en -prioriteiten.

Incident responders worden vaak gevraagd aanbevelingen te doen over welke investeringen de organisatie prioriteit moet geven, nu er nieuwe bedreigingen zijn.

Naast de aanbevelingen die in dit artikel worden beschreven, raden we u aan om prioriteit te geven aan de aandachtsgebieden die reageren op de technieken na exploitatie die door deze aanvaller worden gebruikt en de algemene hiaten in de beveiligingspostuur die hen in staat stellen.

De volgende secties bevatten aanbevelingen voor het verbeteren van zowel algemene als identiteitsbeveiligingspostuur.

Algemene beveiligingspostuur verbeteren

We raden de volgende acties aan om uw algemene beveiligingspostuur te garanderen:

Identiteitsbeveiligingspostuur verbeteren

U wordt aangeraden de volgende acties uit te voeren om het beveiligingspostuur voor identiteiten te waarborgen:

  • Bekijk de vijf stappen van Microsoft voor het beveiligen van uw identiteitsinfrastructuur en geef prioriteit aan de stappen die geschikt zijn voor uw identiteitsarchitectuur.

  • Overweeg om te migreren naar de standaardinstellingen voor Microsoft Entra-beveiliging voor uw verificatiebeleid.

  • Elimineer het gebruik van verouderde verificatie door uw organisatie als systemen of toepassingen dit nog steeds vereisen. Zie Verouderde verificatie blokkeren voor Microsoft Entra ID met voorwaardelijke toegang voor meer informatie.

  • Behandel uw ADFS-infrastructuur en AD Connect-infrastructuur als laag 0-asset.

  • Beperk lokale beheerderstoegang tot het systeem, inclusief het account dat wordt gebruikt om de ADFS-service uit te voeren.

    De minimale bevoegdheid die nodig is voor het account waarop ADFS wordt uitgevoerd, is de toewijzing van de gebruikersrechten van de service als een service .

  • Beperk beheerderstoegang tot beperkte gebruikers en van beperkte IP-adresbereiken met behulp van Windows Firewall-beleid voor Extern bureaublad.

    U wordt aangeraden een tier 0 jumpbox of gelijkwaardig systeem in te stellen.

  • Blokkeer alle binnenkomende SMB-toegang tot de systemen vanaf elke locatie in de omgeving. Zie Beyond the Edge voor meer informatie : SMB-verkeer beveiligen in Windows. U wordt ook aangeraden de Windows Firewall-logboeken naar een SIEM te streamen voor historische en proactieve bewaking.

  • Als u een serviceaccount en uw omgevingsondersteuning gebruikt, migreert u van een serviceaccount naar een door een groep beheerd serviceaccount (gMSA). Als u niet naar een gMSA kunt gaan, roteert u het wachtwoord op het serviceaccount naar een complex wachtwoord.

  • Zorg ervoor dat uitgebreide logboekregistratie is ingeschakeld op uw ADFS-systemen.

Beheerbeheer herstellen en behouden

Als uw onderzoek heeft vastgesteld dat de aanvaller beheerbeheer heeft in de cloud- of on-premises omgeving van de organisatie, moet u op een zodanige manier weer controle krijgen dat de aanvaller niet permanent is.

In deze sectie vindt u mogelijke methoden en stappen die u kunt overwegen bij het bouwen van uw herstelplan voor beheerbeheer.

Belangrijk

De exacte stappen die in uw organisatie nodig zijn, zijn afhankelijk van de persistentie die u in uw onderzoek hebt ontdekt en hoe zeker u bent dat uw onderzoek is voltooid en alle mogelijke invoer- en persistentiemethoden heeft gedetecteerd.

Zorg ervoor dat alle uitgevoerde acties worden uitgevoerd vanaf een vertrouwd apparaat, gebouwd op basis van een schone bron. Gebruik bijvoorbeeld een nieuw, bevoegd toegangswerkstation.

De volgende secties bevatten de volgende typen aanbevelingen voor het herstellen en behouden van beheerbeheer:

  • Vertrouwensrelatie op uw huidige servers verwijderen
  • Uw SAML-tokenondertekeningscertificaat roteren of uw ADFS-servers vervangen indien nodig
  • Specifieke herstelactiviteiten voor cloud- of on-premises omgevingen

Vertrouwensrelatie op uw huidige servers verwijderen

Als uw organisatie de controle over de certificaten voor token-ondertekening of federatieve vertrouwensrelatie heeft verloren, is het verwijderen van vertrouwensrelaties en het overschakelen naar een cloudidentiteit terwijl u on-premises herstelt.

Voor het verwijderen van vertrouwen en het overschakelen naar cloud-mastered identiteit is een zorgvuldige planning en een grondig begrip van de bedrijfsactiviteiteneffecten van het isoleren van identiteiten vereist. Zie Microsoft 365 beveiligen tegen on-premises aanvallen voor meer informatie.

Uw SAML-tokenondertekeningscertificaat roteren

Als uw organisatie besluit geen vertrouwensrelatie te verwijderen tijdens het herstellen van beheerbeheer on-premises, moet u uw SAML-tokenondertekeningscertificaat roteren nadat u on-premises beheer hebt hersteld en de aanvallers de mogelijkheid om opnieuw toegang te krijgen tot het handtekeningcertificaat hebben geblokkeerd.

Als u het tokenondertekeningscertificaat één keer roteert, kan het vorige tokenondertekeningscertificaat nog steeds werken. Het blijven toestaan dat eerdere certificaten werken, is een ingebouwde functionaliteit voor normale certificaatrotaties, waardoor organisaties een respijtperiode kunnen gebruiken om vertrouwensrelaties van relying party's bij te werken voordat het certificaat verloopt.

Als er een aanval is, wilt u niet dat de aanvaller de toegang behoudt. Zorg ervoor dat de aanvaller de mogelijkheid om tokens voor uw domein te splitsen niet behoudt.

Zie voor meer informatie:

Uw ADFS-servers vervangen

Als u in plaats van uw SAML-tokenondertekeningscertificaat te roteren, besluit u de ADFS-servers te vervangen door schone systemen, moet u de bestaande ADFS uit uw omgeving verwijderen en vervolgens een nieuwe maken.

Zie Een configuratie verwijderen voor meer informatie.

Cloudherstelactiviteiten

Naast de aanbevelingen die eerder in dit artikel zijn vermeld, raden we u ook de volgende activiteiten aan voor uw cloudomgevingen:

Activiteit Beschrijving
Wachtwoorden opnieuw instellen Stel wachtwoorden opnieuw in voor alle break-glass-accounts en verminder het aantal break-glass-accounts tot het absolute vereiste minimum.
Bevoegde toegangsaccounts beperken Zorg ervoor dat service- en gebruikersaccounts met bevoegde toegang alleen cloudaccounts zijn en niet on-premises accounts gebruiken die zijn gesynchroniseerd of gefedereerd met Microsoft Entra-id.
MFA afdwingen Multi-Factor Authentication (MFA) afdwingen voor alle gebruikers met verhoogde bevoegdheid in de tenant. U wordt aangeraden MFA af te dwingen voor alle gebruikers in de tenant.
Beheertoegang beperken Implementeer Privileged Identity Management (PIM) en voorwaardelijke toegang om beheerderstoegang te beperken.

Voor Microsoft 365-gebruikers implementeert u Privileged Access Management (PAM) om de toegang tot gevoelige vaardigheden te beperken, zoals eDiscovery, globale beheerder, accountbeheer en meer.
Gedelegeerde machtigingen en toestemmingstoekenningen beoordelen/verminderen Controleer en verminder alle gedelegeerde machtigingen of toestemmingstoekenningen voor bedrijfstoepassingen die een van de volgende functies toestaan:

- Wijziging van bevoegde gebruikers en rollen
- Lezen, e-mail verzenden of alle postvakken openen
- Toegang tot OneDrive-, Teams- of SharePoint-inhoud
- Service-principals toevoegen die kunnen worden gelezen/geschreven naar de map
- Toepassingsmachtigingen versus gedelegeerde toegang

On-premises herstelactiviteiten

Naast de aanbevelingen die eerder in dit artikel zijn vermeld, raden we u ook de volgende activiteiten aan voor uw on-premises omgevingen:

Activiteit Beschrijving
Getroffen systemen opnieuw opbouwen Bouw systemen die tijdens uw onderzoek zijn geïdentificeerd als aangetast door de aanvaller.
Onnodige beheerdersgebruikers verwijderen Verwijder overbodige leden uit de groepen Domeinadministratoren, Back-upoperators en Ondernemingsadministratoren. Zie Privileged Access beveiligen voor meer informatie.
Wachtwoorden opnieuw instellen op bevoegde accounts Stel wachtwoorden van alle bevoegde accounts in de omgeving opnieuw in.

Opmerking: bevoegde accounts zijn niet beperkt tot ingebouwde groepen, maar kunnen ook groepen zijn die gedelegeerde toegang hebben tot serverbeheer, werkstationbeheer of andere gebieden van uw omgeving.
Het krbtgt-account opnieuw instellen Stel het krbtgt-account tweemaal opnieuw in met behulp van het script New-KrbtgtKeys .

Opmerking: Als u alleen-lezen domeincontrollers gebruikt, moet u het script afzonderlijk uitvoeren voor lezen-schrijven domeincontrollers en voor alleen-lezen domeincontrollers.
Een systeem opnieuw opstarten plannen Nadat u hebt gevalideerd dat er geen persistentiemechanismen bestaan die door de aanvaller zijn gemaakt of op uw systeem blijven staan, plant u een systeem opnieuw opstarten om te helpen bij het verwijderen van malware die in het geheugen aanwezig is.
Het DSRM-wachtwoord opnieuw instellen Stel het DSRM-wachtwoord van elke domeincontroller (Directory Services Restore Mode) opnieuw in op iets unieks en complexs.

Persistentie herstellen of blokkeren die tijdens het onderzoek is gedetecteerd

Onderzoek is een iteratief proces en u moet de wens van de organisatie om te herstellen in balans brengen wanneer u afwijkingen identificeert en de kans dat herstel de aanvaller waarschuwt voor uw detectie en hen tijd geeft om te reageren.

Een aanvaller die zich bewust wordt van de detectie, kan bijvoorbeeld technieken wijzigen of meer persistentie creëren.

Zorg ervoor dat u alle persistentietechnieken herstelt die u in eerdere fasen van het onderzoek hebt geïdentificeerd.

Toegang tot gebruikers- en serviceaccounts herstellen

Naast de aanbevolen acties die hierboven worden vermeld, raden we u aan de volgende stappen te overwegen om gebruikersaccounts te herstellen en te herstellen:

  • Voorwaardelijke toegang afdwingen op basis van vertrouwde apparaten. Indien mogelijk raden we u aan om op locatie gebaseerde voorwaardelijke toegang af te dwingen voor uw organisatievereisten.

  • Stel wachtwoorden opnieuw in na verwijdering voor alle gebruikersaccounts die mogelijk zijn aangetast. Zorg ervoor dat u ook een tussentijdse planning implementeert om referenties voor alle accounts in uw directory opnieuw in te stellen.

  • Vernieuwtokens onmiddellijk intrekken nadat u uw referenties hebt gedraaid.

    Zie voor meer informatie:

Volgende stappen

  • Krijg hulp van microsoft-producten, waaronder de Microsoft Defender-portal, Microsoft Purview-nalevingsportal en het Office 365-beveiligings- en compliancecentrum door de knop Help (?) in de bovenste navigatiebalk te selecteren.

  • Neem voor hulp bij de implementatie contact met ons op via FastTrack

  • Als u productondersteuningsgerelateerde behoeften hebt, dient u een Microsoft-ondersteuningsaanvraag in.

    Belangrijk

    Als u denkt dat u bent gecompromitteerd en hulp nodig hebt via een incidentrespons, opent u een Sev A Microsoft-ondersteuningsaanvraag.