Undersökning av komprometterade och skadliga program

Den här artikeln innehåller vägledning om hur du identifierar och undersöker skadliga attacker på ett eller flera program i en kundklientorganisation. De stegvisa instruktionerna hjälper dig att vidta nödvändiga åtgärder för att skydda information och minimera ytterligare risker.

  • Förutsättningar: Omfattar de specifika krav som du måste uppfylla innan du påbörjar undersökningen. Till exempel loggning som ska aktiveras, roller och behörigheter som krävs, bland annat.
  • Arbetsflöde: Visar det logiska flöde som du bör följa för att utföra den här undersökningen.
  • Undersökningssteg: Innehåller en detaljerad stegvis vägledning för den här specifika undersökningen.
  • Inneslutningssteg: Innehåller steg för hur du inaktiverar de komprometterade programmen.
  • Återställningssteg: Innehåller övergripande steg för hur du återställer/åtgärdar en skadlig attack mot komprometterade program.
  • Referenser: Innehåller ytterligare läs- och referensmaterial.

Förutsättningar

Innan du påbörjar undersökningen kontrollerar du att du har rätt verktyg och behörigheter för att samla in detaljerad information om de program som du misstänker är komprometterade av den skadliga attacken.

Verktyg som krävs

För en effektiv undersökning installerar du följande PowerShell-modul och verktygslådan på undersökningsdatorn:

Arbetsflöde

Detailed flow of the investigation steps

Undersökningssteg

I den här undersökningen förutsätts det att du antingen har en indikation på ett potentiellt programintrång i form av en användarrapport, inloggningsloggar i Azure AD eller identifiering av identitetsskydd. Se till att slutföra och aktivera alla nödvändiga nödvändiga steg.

Den här spelboken skapas med avsikten att inte alla Microsoft-kunder och deras undersökningsteam kommer att ha hela Microsoft 365 E5- eller Azure AD Premium P2-licenspaketet tillgängligt eller konfigurerat i klientorganisationen som undersöks. Vi kommer dock att lyfta fram ytterligare automatiseringsfunktioner när det är lämpligt.

Fastställa programtyp

Det är viktigt att fastställa typen av program (flera eller enstaka klientorganisationer) tidigt i undersökningsfasen för att få rätt information som behövs för att kontakta programägaren. Mer information finns i Innehavarorganisation i Azure Active Directory.

Program för flera innehavare

För program med flera klientorganisationer hanteras programmet av en tredje part. Identifiera den process som krävs för att nå ut och rapportera problem till programägaren.

Program för en enda klientorganisation

Leta reda på kontaktuppgifterna för programägaren i din organisation. Du hittar den under fliken Ägare i avsnittet Företagsprogram . Din organisation kan också ha en databas med den här informationen.

Du kan också köra den här Microsoft Graph-frågan:

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

Kontrollera identitetsskydd – riskfyllda arbetsbelastningsidentiteter

Den här funktionen är i förhandsversion när den här spelboken skrivs och licenskraven gäller för dess användning. Riskfyllda arbetsbelastningsidentiteter kan utlösas för att undersöka tjänstens huvudnamn, men kan också användas för att undersöka andra utlösare som du kan ha identifierat. Du kan kontrollera risktillståndet för ett huvudnamn för tjänsten med hjälp av fliken Identitetsskydd – riskfyllda arbetsbelastningsidentiteter , eller så kan du använda Microsoft Graph API.

Risk Detection portal

Risk Detection details

A sample of Service Principal Risk Detection Graph API

Sök efter ovanligt inloggningsbeteende

Det första steget i undersökningen är att leta efter bevis på ovanliga autentiseringsmönster i användningen av tjänstens huvudnamn. I Azure-portalen, Azure Monitor, Azure Sentinel eller det SIEM-system (Security Information and Event Management) som organisationen väljer letar du efter följande i avsnittet Inloggningar för tjänstens huvudnamn :

  • Plats – autentiseras tjänstens huvudnamn från platser/IP-adresser som du inte förväntar dig?
  • Fel – finns det ett stort antal autentiseringsfel för tjänstens huvudnamn?
  • Tidsstämplar – finns det lyckade autentiseringar som inträffar vid tillfällen som du inte förväntar dig?
  • Frekvens – finns det en ökad frekvens av autentiseringar för tjänstens huvudnamn?
  • Autentiseringsuppgifter för läcka – hårdkodas och publiceras några programautentiseringsuppgifter på en offentlig källa som GitHub?

Om du har distribuerat identitetsskydd – riskfyllda arbetsbelastningsidentiteter kontrollerar du identifieringarna misstänkta inloggningar och autentiseringsuppgifter för läckage. Mer information finns i Riskförvar för arbetsbelastningsidentitet.

Kontrollera målresursen

I inloggningarna för tjänstens huvudnamn kontrollerar du även resursen som tjänstens huvudnamn hade åtkomst till under autentiseringen. Det är viktigt att ha indata från programägaren eftersom de känner till vilka resurser tjänstens huvudnamn ska komma åt.

Check the Resource for Service Principal

Sök efter onormala ändringar i autentiseringsuppgifter

Använd granskningsloggar för att få information om ändringar av autentiseringsuppgifter för program och tjänstens huvudnamn. Filtrera efter kategori efter programhantering och aktivitet efter uppdateringsprogram – certifikat och hemlighetshantering.

  • Kontrollera om det finns nyligen skapade eller oväntade autentiseringsuppgifter tilldelade till tjänstens huvudnamn.
  • Sök efter autentiseringsuppgifter för tjänstens huvudnamn med hjälp av Microsoft Graph API.
  • Kontrollera både programmets och den associerade tjänstens huvudnamnsobjekt.
  • Kontrollera alla anpassade roller som kanske har skapats eller ändrats. Observera de behörigheter som markerats nedan:

Check custom roles that may be created or modified

Om du har distribuerat appstyrningstillägget kontrollerar du om det finns aviseringar som är relaterade till programmet i Azure-portalen. Mer information finns i Kom igång med identifiering och reparation av apphot.

Om du har distribuerat Identity Protection kontrollerar du rapporten "Riskidentifieringar" och i användar- eller arbetsbelastningsidentiteten "riskhistorik".

Risk Detection portal

Om du har distribuerat Microsoft Defender för molnappar kontrollerar du att principen "Ovanligt tillägg av autentiseringsuppgifter till en OAuth-app" är aktiverad och söker efter öppna aviseringar. Mer information finns i Ovanligt tillägg av autentiseringsuppgifter till en OAuth-app.

Dessutom kan du fråga API: erna servicePrincipalRiskDetections och user riskDetections för att hämta dessa riskidentifieringar.

Sök efter avvikande appkonfigurationsändringar

  • Kontrollera de API-behörigheter som tilldelats appen för att säkerställa att behörigheterna överensstämmer med vad som förväntas för appen.
  • Kontrollera granskningsloggar (filtrera aktivitet efter uppdatera program eller uppdatera tjänstens huvudnamn).
  • Kontrollera om anslutningssträngarna är konsekventa och om utloggnings-URL:en har ändrats.
  • Kontrollera om domänerna i URL:en är i linje med de registrerade.
  • Ta reda på om någon har lagt till en obehörig omdirigerings-URL.
  • Bekräfta ägarskapet för den omdirigerings-URI som du äger för att säkerställa att den inte upphör att gälla och begärdes av en angripare.

Om du har distribuerat Microsoft Defender för molnappar kan du också gå till Azure-portalen och leta efter aviseringar som rör det program som du undersöker för närvarande. Alla aviseringsprinciper är inte aktiverade som standard för OAuth-appar, så se till att alla är aktiverade. Mer information finns i OAuth-appprinciper. Du kan också visa information om appars förval och senaste aktivitet under fliken Undersöka>OAuth-appar .

Sök efter misstänkta programroller

  • Detta kan också undersökas med hjälp av granskningsloggarna. Filtrera aktivitet efter Lägg till approlltilldelning till tjänstens huvudnamn.
  • Kontrollera om de tilldelade rollerna har hög behörighet.
  • Kontrollera om dessa privilegier är nödvändiga.

Sök efter overifierade kommersiella appar

  • Kontrollera om kommersiella galleriprogram (publicerade och verifierade versioner) används.

Sök efter indikationer på information om keyCredential-egenskapen

Granska din klientorganisation för potentiell information om keyCredential-egenskapen enligt beskrivningen i CVE-2021-42306.

Om du vill identifiera och åtgärda påverkade Azure AD-program som är associerade med påverkade Automation-Run-As-konton går du till github-lagringsplatsen för reparationsvägledning.

Viktigt

Bevis på kompromiss: Om du upptäcker tecken på komprometterande är det viktigt att vidta de åtgärder som är markerade i avsnitten för inneslutning och återställning. Detta hjälper till att ta itu med risken, men kommer att behöva undersökas ytterligare för att förstå källan till kompromissen för att undvika ytterligare påverkan och se till att dåliga aktörer tas bort.

Det finns två huvudsakliga metoder för att få åtkomst till system via användning av program. Det första innebär att ett program godkänns av en administratör eller användare, vanligtvis via en nätfiskeattack. Detta skulle vara en del av den första åtkomsten till ett system och kallas ofta "medgivandefiske".

Den andra metoden omfattar ett redan komprometterat administratörskonto som skapar en ny app för beständighet, datainsamling och för att hålla sig under radarn. Till exempel kan en OAuth-app skapas av en komprometterad administratör med ett till synes harmlöst namn, undvika identifiering och tillåta långsiktig åtkomst till data utan behov av ett konto. Detta ses ofta i nationalstatsattacker.

Nedan visas några av de steg som kan vidtas för att undersöka ytterligare.

Kontrollera M365 Unified Audit Log (UAL) för nätfiskeindikationer för de senaste 7 dagarna

Ibland, när angripare använder skadliga eller komprometterade program som ett medel för beständighet eller för att exfiltera data, är en nätfiskekampanj inblandad. Baserat på resultaten från föregående steg bör du granska identiteterna för:

  • Programägare
  • Medgivandeadministratörer

Granska identiteterna för indikationer på nätfiskeattacker under de senaste 24 timmarna. Öka det här tidsintervallet om det behövs till 7, 14 och 30 dagar om det inte finns några omedelbara indikationer. En detaljerad spelbok för nätfiskeundersökning finns i Spelboken för nätfiskeundersökning.

Sök efter medgivanden för skadliga program under de senaste 7 dagarna

För att få ett program tillagt i en klientorganisation förfalskar angripare användare eller administratörer att godkänna program. Mer information om tecken på en attack finns i playbooken för att bevilja undersökning av programmedgivande.

Kontrollera granskningsloggar

Om du vill se alla medgivandebidrag för programmet filtrerar du Aktivitet efter medgivande till programmet.

  • Använda Granskningsloggar för Azure AD-portalen

  • Använda Microsoft Graph för att köra frågor mot granskningsloggarna

    a) Filtrera efter en viss tidsram:

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

b) Filtrera granskningsloggarna efter granskningsloggposter för "Medgivande till program":

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) Använda Log Analytics

AuditLogs
| where ActivityDisplayName == "Consent to application"

Mer information finns i Spelboken för att bevilja undersökning av programmedgivande.

En användare kan auktorisera ett program att komma åt vissa data på den skyddade resursen, samtidigt som den fungerar som den användaren. Behörigheterna som tillåter den här typen av åtkomst kallas "delegerade behörigheter" eller användarmedgivande.

Om du vill hitta appar som har godkänts av användare använder du LogAnalytics för att söka i granskningsloggarna:

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

Kontrollera granskningsloggarna för att se om de behörigheter som beviljas är för breda (hela klientorganisationen eller administratörsmedgivande)

Att granska de behörigheter som beviljas till ett program eller tjänstens huvudnamn kan vara en tidskrävande uppgift. Börja med att förstå de potentiellt riskfyllda behörigheterna i Azure AD.

Följ nu vägledningen om hur du räknar upp och granskar behörigheter i undersökningen om beviljande av appmedgivande.

Kontrollera om behörigheterna har beviljats av användaridentiteter som inte ska ha möjlighet att göra detta, eller om åtgärderna utfördes vid konstiga datum och tider

Granska med hjälp av granskningsloggar:

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

Du kan också använda Azure AD-granskningsloggarna och filtrera efter Medgivande till program. I avsnittet Granskningslogginformation klickar du på Ändrade egenskaper och granskar sedan ConsentAction.Permissions:

Use the Azure AD Audit Logs

Inneslutningssteg

När du har identifierat ett eller flera program eller arbetsbelastningsidentiteter som antingen skadliga eller komprometterade kanske du inte omedelbart vill distribuera autentiseringsuppgifterna för det här programmet, och du vill inte heller omedelbart ta bort programmet. Vi rekommenderar starkt att du följer riktlinjerna för bästa praxis för incidenthantering.

Viktigt

Innan du utför följande steg måste din organisation väga in säkerhetspåverkan och påverkan på verksamheten när du inaktiverar ett program. Om affärseffekten av att inaktivera ett program är för stor kan du överväga att förbereda och flytta till återställningsfasen i den här processen.

Inaktivera komprometterat program

En typisk inneslutningsstrategi omfattar inaktivering av inloggningar till det identifierade programmet, för att ge ditt incidenthanteringsteam eller den berörda affärsenheten tid att utvärdera effekten av borttagning eller nyckelrullning. Om din undersökning får dig att tro att autentiseringsuppgifterna för administratörskontot också har komprometterats, bör den här typen av aktivitet samordnas med en borttagningshändelse för att säkerställa att alla vägar för åtkomst till klientorganisationen är avskurna samtidigt.

Toggle to disable users to sign-in

Du kan också använda följande PowerShell-kod för att inaktivera inloggningen till appen:

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

# Check if a service principal already exists for the app
$servicePrincipal = Get-AzureADServicePrincipal -Filter "appId eq '$appId'"
if ($servicePrincipal) {
   # Service principal exists already, disable it
   Set-AzureADServicePrincipal -ObjectId $servicePrincipal.ObjectId -AccountEnabled $false
} else {
   # Service principal does not yet exist, create it and disable it at the same time
   $servicePrincipal = New-AzureADServicePrincipal -AppId $appId -AccountEnabled $false
}

Återställningssteg

Reparera tjänstens huvudnamn

  1. Visa en lista över alla autentiseringsuppgifter som tilldelats till tjänstens huvudnamn för riskfyllda tjänster. Det bästa sättet att göra detta är att utföra ett Microsoft Graph-anrop med hjälp av GET ~/application/{id} där ID:t skickades är programobjekt-ID:t.

    • Parsa utdata för autentiseringsuppgifter. Utdata kan innehålla passwordCredentials eller keyCredentials. Registrera keyIds för alla.

      "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. Lägg till en ny (x509) certifikatautentiseringsuppgift i programobjektet med hjälp av api:et addKey.

    POST ~/applications/{id}/addKey
    
  3. Ta omedelbart bort alla gamla autentiseringsuppgifter. För varje gammal lösenordsautentiseringsuppgift tar du bort den med hjälp av:

    POST ~/applications/{id}/removePassword
    

    För varje gammal nyckelautentiseringsuppgift tar du bort den med hjälp av:

    POST ~/applications/{id}/removeKey
    
  4. Åtgärda alla tjänsthuvudnamn som är associerade med programmet. Följ detta om din klientorganisation är värd för/registrerar ett program för flera klientorganisationer och/eller registrerar flera tjänsthuvudnamn som är associerade med programmet. Utför liknande steg som ovan:

  • GET ~/servicePrincipals/{id}

  • Hitta passwordCredentials och keyCredentials i svaret, registrera alla gamla keyIds

  • Ta bort alla gamla lösenord och nyckelautentiseringsuppgifter. Använda:

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

Åtgärda berörda resurser för tjänstens huvudnamn

Åtgärda KeyVault-hemligheter som tjänstens huvudnamn har åtkomst till genom att rotera dem i följande prioritet:

  • Hemligheter som exponeras direkt med GetSecret-anrop .
  • Resten av hemligheterna i exponerade KeyVaults.
  • Resten av hemligheterna i exponerade prenumerationer.

Mer information finns i Ta bort och rulla över certifikat och hemligheter för ett tjänsthuvudnamn eller program interaktivt.

Vägledning för Azure AD SecOps om program finns i Azure Active Directory-säkerhetsåtgärdsguiden för program.

I prioritetsordning skulle det här scenariot vara:

  • Uppdatera Graph PowerShell-cmdletar (Lägg till/ta bort ApplicationKey + ApplicationPassword) så att det innehåller exempel på roll-over för autentiseringsuppgifter.
  • Lägg till anpassade cmdletar i Microsoft Graph PowerShell som förenklar det här scenariot.

Inaktivera eller ta bort skadliga program

Ett program kan antingen inaktiveras eller tas bort. Om du vill inaktivera programmet går du till Aktiverad för användare att logga in genom att flytta växlingsknappen till Nej.

Du kan ta bort programmet, antingen tillfälligt eller permanent, i Azure-portalen eller via Microsoft Graph API. När du mjuk borttagning kan programmet återställas upp till 30 dagar efter borttagningen.

DELETE /applications/{id}

Om du vill ta bort programmet permanent använder du det här Microsoft Graph API-anropet:

DELETE /directory/deletedItems/{id}

Om du inaktiverar eller om du mjuk tar bort programmet konfigurerar du övervakning i Azure AD-granskningsloggar för att ta reda på om tillståndet ändras tillbaka till aktiverat eller återställt.

Loggning för aktiverad:

  • Tjänst – Core Directory
  • Aktivitetstyp – Uppdatera tjänstprincip
  • Kategori – Programhantering
  • Initierad av (skådespelare) - UPN för skådespelare
  • Mål – App-ID och visningsnamn
  • Ändrade egenskaper – Egenskapsnamn = konto aktiverat, nytt värde = sant

Loggning för återställd:

  • Tjänst – Core Directory
  • Aktivitetstyp – Lägg till tjänstprincip
  • Kategori – Programhantering
  • Initierad av (skådespelare) - UPN för skådespelare
  • Mål – App-ID och visningsnamn
  • Ändrade egenskaper – Egenskapsnamn = konto aktiverat, nytt värde = sant

Implementera Identity Protection för arbetsbelastningsidentiteter

Misstänkta inloggningar: När riskidentifiering indikerar ovanliga inloggningsegenskaper eller mönster, samt ovanligt tillägg av autentiseringsuppgifter till en OAuth-app, kan det vara en indikator på komprometterande. Inloggningsbeteendet för identifieringsbaslinjer mellan 2 och 60 dagar och utlöses om en eller flera av följande okända egenskaper inträffar under en efterföljande inloggning:

  • IP-adress/ASN
  • Målresurs
  • Användaragent
  • Ip-ändring för värd/icke-värd
  • IP-land
  • Typ av autentiseringsuppgifter

När den här identifieringen utlöses markeras kontot som hög risk eftersom detta kan tyda på kontoövertagande för ämnesprogrammet. Observera att de legitima ändringarna i ett programs konfiguration ibland utlöser den här identifieringen.

Mer information finns i Skydda arbetsbelastningsidentiteter med Identity Protection.

Dessa aviseringar visas i Identity Protection-portalen och kan exporteras till SIEM-verktyg via Identity Protection-API:erna.

Review risks and alerts in the Identity Protection portal

Villkorlig åtkomst för riskfyllda arbetsbelastningsidentiteter

Med villkorsstyrd åtkomst kan du blockera åtkomst för specifika konton som du anger när Identity Protection markerar dem som "i riskzonen". Observera att tillämpningen via villkorsstyrd åtkomst för närvarande endast är begränsad till program med en enda klientorganisation.

Control user access based on conditional access policy

Mer information finns i Villkorlig åtkomst för arbetsbelastningsidentiteter.

Implementera principer för programrisk

Granska inställningarna för användarmedgivande under Azure Active Directory Enterprise-program>>Medgivande och behörigheter>Inställningar för användarmedgivande.

Select Allow user consent for apps from the options

Mer information om konfigurationsalternativ finns i Konfigurera hur användarna godkänner appar.

När en programutvecklare dirigerar användare till slutpunkten för administratörsmedgivande med avsikt att ge medgivande för hela klientorganisationen kallas det för administratörsmedgivandeflöde. För att säkerställa att flödet för administratörsmedgivande fungerar korrekt måste programutvecklare visa alla behörigheter i egenskapen RequiredResourceAccess i programmanifestet.

De flesta organisationer inaktiverar möjligheten för användarna att godkänna program. För att ge användarna möjlighet att fortfarande begära medgivande för program och ha en administrativ granskningsfunktion rekommenderar vi att du implementerar arbetsflödet för administratörsmedgivande. Följ stegen i arbetsflödet för administratörsmedgivande för att konfigurera det i din klientorganisation.

För högprivilegierade åtgärder, till exempel administratörsmedgivande, har du en strategi för privilegierad åtkomst som definieras enligt vår vägledning.

Riskbaserat step-up-medgivande hjälper till att minska användarnas exponering för skadliga appar. Till exempel anses medgivandebegäranden för nyligen registrerade appar med flera klientorganisationer som inte är utgivare verifierade och kräver icke-grundläggande behörigheter vara riskfyllda. Om en riskfylld begäran om användarmedgivande identifieras kräver begäran en "step-up" för administratörsmedgivande i stället. Den här step-up-funktionen är aktiverad som standard, men det resulterar i en beteendeförändring endast när användarens medgivande är aktiverat.

Kontrollera att den är aktiverad i din klientorganisation och granska konfigurationsinställningarna som beskrivs här.

Referenser

Ytterligare spelböcker för incidenthantering

Granska vägledningen för att identifiera och undersöka dessa ytterligare typer av attacker:

Incidenthanteringsresurser