Onderzoek naar gecompromitteerde en schadelijke toepassingen

  • Artikel

Dit artikel bevat richtlijnen voor het identificeren en onderzoeken van schadelijke aanvallen op een of meer toepassingen in een klanttenant. De stapsgewijze instructies helpen u de vereiste herstelactie uit te voeren om informatie te beschermen en verdere risico's te minimaliseren.

  • Vereisten: behandelt de specifieke vereisten die u moet voltooien voordat u het onderzoek start. Logboekregistratie die bijvoorbeeld moet worden ingeschakeld, rollen en machtigingen die vereist zijn, zijn onder andere vereist.
  • Werkstroom: Toont de logische stroom die u moet volgen om dit onderzoek uit te voeren.
  • Onderzoeksstappen: Bevat een gedetailleerde stapsgewijze handleiding voor dit specifieke onderzoek.
  • Insluitingsstappen: bevat stappen voor het uitschakelen van de aangetaste toepassingen.
  • Herstelstappen: bevat stappen op hoog niveau voor het herstellen/beperken van een schadelijke aanval op aangetaste toepassingen.
  • Verwijzingen: Bevat andere lees- en referentiemateriaal.

Vereisten

Voordat u begint met het onderzoek, moet u ervoor zorgen dat u over de juiste hulpprogramma's en machtigingen beschikt om gedetailleerde informatie te verzamelen.

Vereiste hulpprogramma's

Installeer voor een effectief onderzoek de volgende PowerShell-module en de toolkit op uw onderzoekscomputer:

Workflow

Detailed flow of the investigation steps

Onderzoeksstappen

Voor dit onderzoek wordt ervan uitgegaan dat u een indicatie hebt voor een mogelijk inbreuk op een toepassing in de vorm van een gebruikersrapport, microsoft Entra-aanmeldingslogboeken of een detectie van identiteitsbeveiliging. Zorg ervoor dat u alle vereiste stappen voltooit en inschakelt.

Dit playbook wordt gemaakt met de bedoeling dat niet alle Microsoft-klanten en hun onderzoeksteams de volledige Microsoft 365 E5- of Microsoft Entra ID P2-licentiesuite beschikbaar of geconfigureerd hebben. In dit playbook worden andere automatiseringsmogelijkheden gemarkeerd, indien van toepassing.

Toepassingstype bepalen

Het is belangrijk om het type toepassing (meerdere of één tenant) vroeg in de onderzoeksfase te bepalen om de juiste informatie op te halen die nodig is om contact op te halen met de eigenaar van de toepassing. Zie Tenancy in Microsoft Entra ID voor meer informatie.

Toepassingen met meerdere tenants

Voor toepassingen met meerdere tenants wordt de toepassing gehost en beheerd door een derde partij. Identificeer het proces dat nodig is om problemen aan de eigenaar van de toepassing te melden en te melden.

Toepassingen met één tenant

Zoek de contactgegevens van de eigenaar van de toepassing binnen uw organisatie. U vindt deze op het tabblad Eigenaren in de sectie Bedrijfstoepassingen . Uw organisatie kan ook een database met deze gegevens hebben.

U kunt deze Microsoft Graph-query ook uitvoeren:

GET https://graph.microsoft.com/v1.0/applications/{id}/owners

Identity Protection controleren - riskante workloadidentiteiten

Deze functie is in preview op het moment van schrijven van dit playbook en licentievereisten van toepassing op het gebruik ervan. Riskante workloadidentiteiten kunnen de trigger zijn om een service-principal te onderzoeken, maar kunnen ook worden gebruikt om verder te onderzoeken naar andere triggers die u hebt geïdentificeerd. U kunt de risicostatus van een service-principal controleren met behulp van het tabblad Identity Protection - riskante workloadidentiteiten of u kunt Microsoft Graph API gebruiken.

Risk Detection portal

Risk Detection details

A sample of Service Principal Risk Detection Graph API

Controleren op ongebruikelijk aanmeldingsgedrag

De eerste stap van het onderzoek is het zoeken naar bewijs van ongebruikelijke verificatiepatronen in het gebruik van de service-principal. Zoek in Azure Portal, Azure Monitor, Microsoft Sentinel of het SIEM-systeem (Security Information and Event Management) van uw organisatie naar het volgende in de sectie Aanmeldingen van de service-principal:

  • Locatie: wordt de service-principal geverifieerd vanaf locaties\IP-adressen die u niet zou verwachten?
  • Fouten: zijn er een groot aantal verificatiefouten voor de service-principal?
  • Tijdstempels: zijn er geslaagde verificaties die zich voordoen op tijdstippen die u niet zou verwachten?
  • Frequentie: is er een verhoogde frequentie van verificaties voor de service-principal?
  • Lekreferenties: zijn er toepassingsreferenties vastgelegd en gepubliceerd op een openbare bron, zoals GitHub?

Als u Entra ID Identity Protection - riskante workloadidentiteiten hebt geïmplementeerd, controleert u de detecties van verdachte aanmeldingen en lekreferenties. Zie bewaringen van identiteitsrisico's voor werkbelastingen voor meer informatie.

De doelresource controleren

Controleer binnen aanmeldingen van de service-principal ook de resource waartoe de service-principal toegang had tijdens de verificatie. Het is belangrijk om invoer te krijgen van de eigenaar van de toepassing, omdat ze bekend zijn met welke resources de service-principal toegang moet hebben.

Check the Resource for Service Principal

Controleren op abnormale referentiewijzigingen

Gebruik auditlogboeken om informatie op te halen over referentiewijzigingen in toepassingen en service-principals. Filter op categorie op toepassingsbeheer en activiteit op updatetoepassing: certificaten en geheimenbeheer.

  • Controleer of er nieuw gemaakte of onverwachte referenties zijn toegewezen aan de service-principal.
  • Controleer op referenties voor service-principals met behulp van Microsoft Graph API.
  • Controleer zowel de toepassing als de bijbehorende service-principal-objecten.
  • Controleer een aangepaste rol die u hebt gemaakt of gewijzigd. Let op de machtigingen die hieronder zijn gemarkeerd:

Check custom roles that are created or have been modified

Als u app-beheer hebt geïmplementeerd in Microsoft Defender voor Cloud Apps, controleert u de Azure-portal op waarschuwingen met betrekking tot de toepassing. Zie Aan de slag met detectie en herstel van app-bedreigingen voor meer informatie.

Als u Identity Protection hebt geïmplementeerd, controleert u het rapport Risicodetecties en in de identiteitsgeschiedenis van de gebruiker of workload.

Risk Detection portal

Als u Microsoft Defender voor Cloud-apps hebt geïmplementeerd, controleert u of het beleid 'Ongebruikelijke toevoeging van referenties aan een OAuth-app' is ingeschakeld en controleert u op geopende waarschuwingen.

Zie Ongebruikelijke toevoeging van referenties aan een OAuth-app voor meer informatie.

Daarnaast kunt u query's uitvoeren op de servicePrincipalRiskDetections - en user riskDetections-API's om deze risicodetecties op te halen.

Afwijkende app-configuratiewijzigingen zoeken

  • Controleer de API-machtigingen die aan de app zijn toegewezen om ervoor te zorgen dat de machtigingen consistent zijn met wat er voor de app wordt verwacht.
  • Controleer auditlogboeken (filter activity by Update Application or Update Service Principal).
  • Controleer of de verbindingsreeks consistent zijn en of de afmeldings-URL is gewijzigd.
  • Controleer of de domeinen in de URL in overeenstemming zijn met de domeinen die zijn geregistreerd.
  • Bepaal of iemand een niet-geautoriseerde omleidings-URL heeft toegevoegd.
  • Bevestig het eigendom van de omleidings-URI waarvan u de eigenaar bent om ervoor te zorgen dat deze niet is verlopen en is geclaimd door een kwaadwillende persoon.

Als u Microsoft Defender voor Cloud Apps hebt geïmplementeerd, controleert u de Azure-portal op waarschuwingen met betrekking tot de toepassing die u momenteel onderzoekt. Niet alle waarschuwingsbeleidsregels zijn standaard ingeschakeld voor OAuth-apps, dus zorg ervoor dat deze beleidsregels allemaal zijn ingeschakeld. Zie het OAuth-app-beleid voor meer informatie. U kunt ook informatie bekijken over de prevalentie van apps en recente activiteit op het tabblad Onderzoek>OAuth-apps.

Controleren op verdachte toepassingsrollen

  • U kunt ook de auditlogboeken gebruiken. Filter Activiteit op Roltoewijzing van app toevoegen aan service-principal.
  • Controleer of de toegewezen rollen hoge bevoegdheden hebben.
  • Controleer of deze bevoegdheden nodig zijn.

Controleren op niet-geverifieerde commerciële apps

  • Controleer of commerciële galerietoepassingen (gepubliceerde en geverifieerde versies) worden gebruikt.

Controleren op indicaties van openbaarmaking van keyCredential-eigenschappen

Controleer uw tenant op mogelijke openbaarmaking van keyCredential-eigenschappen zoals beschreven in CVE-2021-42306.

Als u betrokken Microsoft Entra-toepassingen wilt identificeren en herstellen die zijn gekoppeld aan beïnvloede Automation Run-As-accounts, gaat u naar de richtlijnen voor herstel in GitHub-opslagplaats.

Belangrijk

Bewijs van inbreuk: Als u bewijs van inbreuk ontdekt, is het belangrijk om de stappen uit te voeren die zijn gemarkeerd in de secties voor insluiting en herstel. Deze stappen helpen het risico aan te pakken, maar voer verder onderzoek uit om inzicht te krijgen in de bron van het compromis om verdere impact te voorkomen en ervoor te zorgen dat slechte actoren worden verwijderd.

Er zijn twee primaire methoden voor het verkrijgen van toegang tot systemen via het gebruik van toepassingen. De eerste is dat een toepassing wordt toegestaan door een beheerder of gebruiker, meestal via een phishing-aanval. Deze methode maakt deel uit van de eerste toegang tot een systeem en wordt vaak 'toestemming phishing' genoemd.

De tweede methode omvat een al gecompromitteerd beheerdersaccount dat een nieuwe app maakt voor persistentie, gegevensverzameling en om onder de radar te blijven. Een gecompromitteerde beheerder kan bijvoorbeeld een OAuth-app maken met een schijnbaar onschuldige naam, detectie voorkomen en langetermijntoegang tot gegevens toestaan zonder dat er een account nodig is. Deze methode wordt vaak gezien in nationale staatsaanvallen.

Hier volgen enkele van de stappen die kunnen worden ondernomen om verder te onderzoeken.

Controleer Microsoft 365 Unified Audit Log (UAL) op phishing-indicaties voor de afgelopen zeven dagen

Wanneer aanvallers schadelijke of gecompromitteerde toepassingen gebruiken als een middel voor persistentie of om gegevens te exfiltreren, is er een phishingcampagne betrokken. Op basis van de resultaten uit de vorige stappen moet u de identiteiten van:

  • Toepassingseigenaren
  • Toestemming Beheer s

Bekijk de identiteiten voor indicaties van phishingaanvallen in de afgelopen 24 uur. Verhoog deze periode indien nodig tot 7, 14 en 30 dagen als er geen directe aanwijzingen zijn. Zie het Playbook Phishing Investigation voor een gedetailleerd playbook voor phishingonderzoek.

Zoeken naar schadelijke toepassingstoestemmingen voor de afgelopen zeven dagen

Om een toepassing toe te voegen aan een tenant, spoofen aanvallers of beheerders om toestemming te geven voor toepassingen. Zie het Playbook Application Consent Grant Investigation voor meer informatie over de tekenen van een aanval.

Auditlogboeken controleren

Als u alle toestemmingstoestemmingen voor die toepassing wilt zien, filtert u activiteit op toestemming voor de toepassing.

  • De auditlogboeken van het Microsoft Entra-beheercentrum gebruiken

  • Microsoft Graph gebruiken om query's uit te voeren op de auditlogboeken

    a) Filteren op een bepaald tijdsbestek:

GET https://graph.microsoft.com/v1.0/auditLogs/auditLogs/directoryAudits?&$filter=activityDateTime le 2022-01-24

b) Filter de auditlogboeken op vermeldingen in het auditlogboek 'Toestemming voor toepassingen':

https://graph.microsoft.com/v1.0/auditLogs/directoryAudits?directoryAudits?$filter=ActivityType eq 'Consent to application'


"@odata.context": "https://graph.microsoft.com/v1.0/$metadata#auditLogs/directoryAudits",
"value": [
    {
        "id": "Directory_0da73d01-0b6d-4c6c-a083-afc8c968e655_78XJB_266233526",
        "category": "ApplicationManagement",
        "correlationId": "0da73d01-0b6d-4c6c-a083-afc8c968e655",
        "result": "success",
        "resultReason": "",
        "activityDisplayName": "Consent to application",
        "activityDateTime": "2022-03-25T21:21:37.9452149Z",
        "loggedByService": "Core Directory",
        "operationType": "Assign",
       "initiatedBy": {
            "app": null,
            "user": {
                "id": "8b3f927e-4d89-490b-aaa3-e5d4577f1234",
                "displayName": null,
                "userPrincipalName": "admin@contoso.com",
                "ipAddress": "55.154.250.91",
                "userType": null,
                "homeTenantId": null,
                "homeTenantName": null
            }
        },
        "targetResources": [
            {
                "id": "d23d38a1-02ae-409d-884c-60b03cadc989",
                "displayName": "Graph explorer (official site)",
                "type": "ServicePrincipal",
                "userPrincipalName": null,
                "groupType": null,
                "modifiedProperties": [
                    {
                        "displayName": "ConsentContext.IsAdminConsent",
                        "oldValue": null,
                        "newValue": "\"True\""
                    },

c) Log Analytics gebruiken

AuditLogs
| where ActivityDisplayName == "Consent to application"

Zie het Playbook Application Consent Grant Investigation voor meer informatie.

Een gebruiker kan een toepassing machtigen om toegang te krijgen tot bepaalde gegevens in de beveiligde resource, terwijl deze als die gebruiker fungeert. De machtigingen die dit type toegang toestaan, worden 'gedelegeerde machtigingen' of gebruikerstoestemming genoemd.

Gebruik LogAnalytics om apps te vinden die zijn toegestaan door gebruikers om de auditlogboeken te doorzoeken:

AuditLogs
| where ActivityDisplayName == "Consent to application" and (parse_json(tostring(parse_json(tostring(TargetResources[0].modifiedProperties))[0].newValue)) <> "True")

Controleer auditlogboeken om te bepalen of de verleende machtigingen te breed zijn (tenantbrede of beheerderstoestemming)

Het controleren van de machtigingen die zijn verleend aan een toepassing of service-principal, kan een tijdrovende taak zijn. Begin met het begrijpen van de potentieel riskante machtigingen in Microsoft Entra-id.

Volg nu de richtlijnen voor het inventariseren en controleren van machtigingen in het onderzoek naar toestemming van de app.

Controleer of de machtigingen zijn verleend door gebruikersidentiteiten die dit niet mogen doen, of of de acties zijn uitgevoerd op vreemde datums en tijden

Controleren met auditlogboeken:

AuditLogs
| where OperationName == "Consent to application" 
//| where parse_json(tostring(TargetResources[0].modifiedProperties))[4].displayName == "ConsentAction.Permissions"

U kunt ook de Auditlogboeken van Microsoft Entra gebruiken, filteren op Toestemming voor de toepassing. Klik in de sectie Details van auditlogboek op Eigenschappen gewijzigd en controleer vervolgens de ConsentAction.Permissions:

Use the Microsoft Entra audit logs

Insluitingsstappen

Nadat u een of meer toepassingen of workloadidentiteiten hebt geïdentificeerd als schadelijk of gecompromitteerd, wilt u mogelijk niet onmiddellijk de referenties voor deze toepassing uitrollen, noch wilt u de toepassing onmiddellijk verwijderen.

Belangrijk

Voordat u de volgende stap uitvoert, moet uw organisatie de beveiligingsimpact en de bedrijfsimpact van het uitschakelen van een toepassing afwegen. Als het bedrijfseffect van het uitschakelen van een toepassing te groot is, kunt u overwegen om de herstelfase van dit proces voor te bereiden en over te stappen.

Gecompromitteerde toepassing uitschakelen

Een typische insluitingsstrategie omvat het uitschakelen van aanmeldingen voor de geïdentificeerde toepassing, om uw incidentresponsteam of de betreffende bedrijfseenheidtijd te geven om de impact van verwijdering of het rollen van sleutels te evalueren. Als uw onderzoek ertoe leidt dat u denkt dat de referenties van het beheerdersaccount ook worden aangetast, moet dit type activiteit worden gecoördineerd met een verwijderingsgebeurtenis om ervoor te zorgen dat alle routes voor toegang tot de tenant gelijktijdig worden afgesloten.

Toggle to disable users to sign-in

U kunt ook de volgende Microsoft Graph PowerShell-code gebruiken om de aanmelding bij de app uit te schakelen:

# The AppId of the app to be disabled
$appId = "{AppId}"

# Check if a service principal already exists for the app
$servicePrincipal = Get-MgServicePrincipal -Filter "appId eq '$appId'"

if ($servicePrincipal) {
   # Service principal exists already, disable it

  $ServicePrincipalUpdate =@{
    "accountEnabled" = "false"
  }
   Update-MgServicePrincipal -ServicePrincipalId $servicePrincipal.Id -BodyParameter $ServicePrincipalUpdate
   
} else {
   # Service principal does not yet exist, create it and disable it at the same time
   
   $ServicePrincipalID=@{
	"AppId" = $appId
	"accountEnabled" = "false"
   }
   
   $servicePrincipal = New-MgServicePrincipal -BodyParameter $ServicePrincipalId
   
}

Herstelstappen

Service-principals herstellen

  1. Geef alle referenties weer die zijn toegewezen aan de riskante service-principal. De beste manier om dit te doen, is door een Microsoft Graph-aanroep uit te voeren met GET ~/application/{id} waar de id is doorgegeven, is de object-id van de toepassing.

    • Parseert de uitvoer voor referenties. De uitvoer kan passwordCredentials of keyCredentials bevatten. Noteer de keyIds voor iedereen.

      "keyCredentials": [],
     "parentalControlSettings": {
         "countriesBlockedForMinors": [],
         "legalAgeGroupRule": "Allow"
     },
     "passwordCredentials": [
         {
             "customKeyIdentifier": null,
             "displayName": "Test",
             "endDateTime": "2021-12-16T19:19:36.997Z",
             "hint": "7~-",
             "keyId": "9f92041c-46b9-4ebc-95fd-e45745734bef",
             "secretText": null,
             "startDateTime": "2021-06-16T18:19:36.997Z"
         }
     ],

  2. Voeg een nieuwe certificaatreferentie (x509) toe aan het toepassingsobject met behulp van de addKey-API van de toepassing.

    POST ~/applications/{id}/addKey

  3. Verwijder onmiddellijk alle oude referenties. Verwijder deze voor elke oude wachtwoordreferentie met behulp van:

    POST ~/applications/{id}/removePassword

    Verwijder deze voor elke oude sleutelreferentie met behulp van:

    POST ~/applications/{id}/removeKey

  4. Herstel alle service-principals die aan de toepassing zijn gekoppeld. Volg deze stap als uw tenanthosts/registreert een toepassing met meerdere tenants en/of meerdere service-principals registreert die aan de toepassing zijn gekoppeld. Voer vergelijkbare stappen uit als wat eerder wordt vermeld:

  • GET ~/servicePrincipals/{id}

  • Find passwordCredentials and keyCredentials in the response, record all old keyIds

  • Verwijder alle oude wachtwoord- en sleutelreferenties. Gebruik:

    POST ~/servicePrincipals/{id}/removePassword and POST ~/servicePrincipals/{id}/removeKey for this, respectively.

Betrokken service-principalresources herstellen

Herstel KeyVault-geheimen waartoe de service-principal toegang heeft door ze te roteren, met de volgende prioriteit:

  • Geheimen die rechtstreeks worden weergegeven met GetSecret-aanroepen .
  • De rest van de geheimen in blootgestelde KeyVaults.
  • De rest van de geheimen voor weergegeven abonnementen.

Zie Interactief verwijderen en rollen van certificaten en geheimen van een service-principal of toepassing voor meer informatie.

Zie de Handleiding voor beveiligingsbewerkingen van Microsoft Entra voor toepassingen voor Microsoft Entra SecOps-richtlijnen voor toepassingen.

In volgorde van prioriteit is dit scenario:

  • Werk Graph PowerShell-cmdlets (Add/Remove ApplicationKey + ApplicationPassword) bij met voorbeelden voor referentieroll-over.
  • Voeg aangepaste cmdlets toe aan Microsoft Graph PowerShell die dit scenario vereenvoudigt.

Schadelijke toepassingen uitschakelen of verwijderen

Een toepassing kan worden uitgeschakeld of verwijderd. Als u de toepassing wilt uitschakelen, verplaatst u de wisselknop onder Ingeschakeld voor gebruikers om zich aan te melden naar Nee.

U kunt de toepassing tijdelijk of permanent verwijderen in Azure Portal of via de Microsoft Graph API. Wanneer u voorlopig verwijdert, kan de toepassing tot 30 dagen na verwijdering worden hersteld.

DELETE /applications/{id}

Als u de toepassing definitief wilt verwijderen, gebruikt u deze Microsoft Graph API-aanroep:

DELETE /directory/deletedItems/{id}

Als u de toepassing uitschakelt of als u de toepassing voorlopig verwijdert, stelt u bewaking in microsoft Entra-auditlogboeken in om te zien of de status weer wordt ingeschakeld of hersteld.

Logboekregistratie voor ingeschakeld:

  • Service - Core Directory
  • Activiteitstype - Service-principal bijwerken
  • Categorie - Toepassingsbeheer
  • Gestart door (actor) - UPN van actor
  • Doelen - App-id en weergavenaam
  • Gewijzigde eigenschappen - Eigenschapsnaam = account ingeschakeld, nieuwe waarde = true

Logboekregistratie voor hersteld:

  • Service - Core Directory
  • Activiteitstype - Service-principal toevoegen
  • Categorie - Toepassingsbeheer
  • Gestart door (actor) - UPN van actor
  • Doelen - App-id en weergavenaam
  • Gewijzigde eigenschappen - Eigenschapsnaam = account ingeschakeld, nieuwe waarde = true

Opmerking: Microsoft schakelt wereldwijd toepassingen uit die zijn servicevoorwaarden schenden. In die gevallen worden deze toepassingen weergegeven DisabledDueToViolationOfServicesAgreement in de disabledByMicrosoftStatus eigenschap van de gerelateerde toepassing en resourcetypen van de service-principal in Microsoft Graph. Als u wilt voorkomen dat ze in uw organisatie in de toekomst opnieuw worden geïnstantieerd, kunt u deze objecten niet verwijderen.

Identity Protection implementeren voor workloadidentiteiten

Microsoft detecteert risico's voor workloadidentiteiten voor aanmeldingsgedrag en offline-indicatoren van inbreuk.

Zie Workloadidentiteiten beveiligen met Identity Protection voor meer informatie.

Deze waarschuwingen worden weergegeven in de Identity Protection-portal en kunnen worden geëxporteerd naar SIEM-hulpprogramma's via diagnostische Instellingen of de Identity Protection-API's.

Review risks and alerts in the Identity Protection portal

Voorwaardelijke toegang voor riskante workloadidentiteiten

Met voorwaardelijke toegang kunt u de toegang blokkeren voor specifieke accounts die u aanwijst wanneer Identity Protection deze als 'risico' markeert. Houd er rekening mee dat de afdwinging via voorwaardelijke toegang momenteel beperkt is tot toepassingen met één tenant.

Control user access based on conditional access policy

Zie Voorwaardelijke toegang voor workloadidentiteiten voor meer informatie.

Beleid voor toepassingsrisico's implementeren

Controleer de instellingen voor gebruikerstoestemming onder Microsoft Entra ID>Enterprise-toepassingen>Toestemming en machtigingen>voor gebruikerstoestemmingsinstellingen.

Select Allow user consent for apps from the options

Zie Configureren hoe gebruikers toestemming geven voor apps om de configuratieopties te bekijken.

Wanneer een toepassingsontwikkelaar gebruikers omwijst naar het eindpunt voor beheerderstoestemming met de intentie om toestemming te geven voor de hele tenant, wordt dit de stroom voor beheerderstoestemming genoemd. Om ervoor te zorgen dat de stroom voor beheerderstoestemming goed werkt, moeten toepassingsontwikkelaars alle machtigingen vermelden in de eigenschap RequiredResourceAccess in het toepassingsmanifest.

De meeste organisaties schakelen de mogelijkheid voor hun gebruikers uit om toestemming te geven voor toepassingen. Als u gebruikers de mogelijkheid wilt geven om nog steeds toestemming te vragen voor toepassingen en beheerdersbeoordelingsmogelijkheden te hebben, is het raadzaam om de werkstroom voor beheerderstoestemming te implementeren. Volg de stappen voor de werkstroom voor beheerderstoestemming om deze in uw tenant te configureren.

Voor bewerkingen met hoge bevoegdheden, zoals beheerderstoestemming, hebt u een strategie voor bevoegde toegang gedefinieerd in onze richtlijnen.

Stapsgewijze toestemming op basis van risico's helpt de blootstelling van gebruikers aan schadelijke apps te verminderen. Toestemmingsaanvragen voor nieuw geregistreerde multitenant-apps die niet door de uitgever zijn geverifieerd en waarvoor niet-basismachtigingen zijn vereist, worden bijvoorbeeld als riskant beschouwd. Als er een riskante gebruikerstoestemmingsaanvraag wordt gedetecteerd, is voor de aanvraag een 'step-up' vereist voor beheerderstoestemming. Deze stapfunctie is standaard ingeschakeld, maar resulteert in een gedragswijziging alleen wanneer toestemming van de gebruiker is ingeschakeld.

Zorg ervoor dat deze is ingeschakeld in uw tenant en controleer de configuratie-instellingen die hier worden beschreven.

Verwijzingen

Aanvullende playbooks voor reactie op incidenten

Bekijk richtlijnen voor het identificeren en onderzoeken van deze aanvullende typen aanvallen:

Resources voor reactie op incidenten