Untersuchen von kompromittierten und schädlichen Anwendungen

  • Artikel

Dieser Artikel enthält eine Anleitung zur Identifizierung und Untersuchung schädlicher Angriffe auf eine oder mehrere Anwendungen in einem Mandanten des Kunden. Die Schritt-für-Schritt-Anleitung hilft Ihnen, die erforderlichen Abhilfemaßnahmen zu ergreifen, um Informationen zu schützen und weitere Risiken zu minimieren.

  • Voraussetzungen: Beschreibt die zu erfüllenden spezifischen Anforderungen, bevor Sie mit der Untersuchung beginnen. Beispielsweise die Protokollierung, die aktiviert werden soll, Rollen und Berechtigungen, die u. a. erforderlich sind.
  • Workflow: Zeigt den logischen Flow an, den Sie befolgen sollten, um diese Untersuchung durchzuführen.
  • Untersuchungsschritte: Enthält einen ausführlichen schrittweisen Leitfaden für diese spezifische Untersuchung.
  • Schritte zur Eindämmung: Enthält Schritte zur Deaktivierung der kompromittierten Anwendungen.
  • Schritte zur Wiederherstellung: Enthält allgemeine Schritte zur Wiederherstellung/Maßnahmen nach einem bösartigen Angriff auf kompromittierte Anwendungen.
  • Referenzen: Enthält weiteres Lese- und Referenzmaterial.

Voraussetzungen

Vergewissern Sie sich vor Beginn der Untersuchung, dass Sie über die richtigen Tools und Berechtigungen verfügen, um detaillierte Informationen zu sammeln.

Erforderliche Tools

Für eine effektive Untersuchung sollten Sie das folgende PowerShell-Modul und das Toolkit auf Ihrem Untersuchungsrechner installieren:

Workflow

Detailed flow of the investigation steps

Untersuchungsschritte

Bei dieser Untersuchung wird davon ausgegangen, dass Sie entweder einen Hinweis auf eine potenzielle Gefährdung der Anwendung in Form eines Benutzerberichts, z. B. eines Microsoft Entra-Anmeldeprotokolls, oder einer Identitätsschutzerkennung haben. Vergewissern Sie sich, dass Sie alle erforderlichen Schritte abgeschlossen und aktiviert haben.

Dieses Playbook wurde mit der Absicht erstellt, dass nicht alle Microsoft-Kunden und ihre Untersuchungsteams über die vollständige Microsoft 365 E5- oder Microsoft Entra ID P2-Lizenzsuite verfügen oder diese konfiguriert haben. Dieses Playbook hebt jedoch andere Automatisierungsfunktionen hervor, wo dies angebracht ist.

Festlegen des Anwendungstyps

Es ist wichtig, die Art des Antrags (Multi oder Einzelner Tenant) bereits in der Ermittlungsphase zu bestimmen, um die richtigen Informationen zu erhalten, die für die Kontaktaufnahme mit dem Besitzer des Antrags erforderlich sind. Weitere Informationen finden Sie unter Mandanten in Microsoft Entra ID.

Mehrinstanzenfähige Anwendungen

Bei Anwendungen mit mehreren Mandanten wird die Anwendung von einer Drittpartei gehostet und verwaltet. Ermitteln Sie den Prozess, der erforderlich ist, um den/die Besitzer*in der Anwendung zu kontaktieren und Probleme zu melden.

Anwendungen mit einem Mandanten

Ermitteln Sie die Kontaktdaten des/der Besitzer*in der Anwendung innerhalb Ihrer Organisation. Sie finden ihn auf der Registerkarte Besitzer im Abschnitt Unternehmensanwendungen. Möglicherweise verfügt Ihre Organisation auch über eine Datenbank, die diese Informationen enthält.

Sie können auch diese Microsoft Graph-Abfrage ausführen:

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

Identitätsschutz überprüfen – riskante Workload-Identitäten

Diese Funktion befindet sich zum Zeitpunkt der Erstellung dieses Playbooks in der Vorschau und es gelten Lizenzanforderungen für ihre Nutzung. Riskante Workload-Identitäten können der Auslöser für die Untersuchung eines Dienstprinzipals sein, können aber auch zur weiteren Untersuchung anderer Auslöser verwendet werden, die Sie identifiziert haben. Sie können den Risikostatus eines Dienstprinzipals über die Registerkarte Identitätsschutz – Riskante Workload-Identitäten überprüfen oder die Microsoft Graph-API verwenden.

Risk Detection portal

Risk Detection details

A sample of Service Principal Risk Detection Graph API

Überprüfung auf ungewöhnliches Anmeldeverhalten

Der erste Schritt der Untersuchung besteht darin, nach Anzeichen für ungewöhnliche Authentifizierungsmuster bei der Verwendung des Dienstprinzipals zu suchen. Suchen Sie im Azure-Portal, in Azure Monitor, Microsoft Sentinel oder im SIEM-System (Security Information and Event Management) Ihrer Organisation im Abschnitt Dienstprinzipalanmeldungen nach Folgendem:

  • Standort – authentifiziert sich das Dienstprinzipal von Standorten\IP-Adressen, von denen Sie es nicht erwarten würden?
  • Fehlschläge – gibt es eine große Anzahl von Authentifizierungsfehlern für das Dienstprinzipal?
  • Zeitstempel – gibt es erfolgreiche Authentifizierungen, die zu Zeiten stattfinden, die Sie nicht erwarten würden?
  • Häufigkeit – gibt es eine erhöhte Häufigkeit von Authentifizierungen für das Dienstprinzipal?
  • Offengelegte Anmeldeinformationen – Sind die Anmeldeinformationen der Anwendung fest programmiert und in einer öffentlichen Quelle wie GitHub veröffentlicht?

Wenn Sie „Informationsschutz – riskante Workload-Identitäten“ implementiert haben, überprüfen Sie die Erkennungen verdächtiger Anmeldeinformationen und offengelegter Anmeldeinformationen. Weitere Informationen finden Sie unter Workload Identitätsrisiko Ingewahrsamnahmen.

Überprüfen der Zielressourcen

Überprüfen Sie bei Anmeldungen von Dienstprinzipalen auch die Ressource, auf die der Dienstprinzipal während der Authentifizierung zugegriffen hat. Es ist wichtig, Auskunft von dem/der Besitzer*in der Anwendung zu erhalten, da sie damit vertraut sind, auf welche Ressourcen der Dienstprinzipal zugreifen sollte.

Check the Resource for Service Principal

Überprüfen Sie auf ungewöhnliche Änderungen der Anmeldeinformationen

Verwenden Sie Protokolldateien, um Informationen über Anmeldeinformationen von Anwendungen und Dienstprinzipalen zu erhalten. Filtern Sie Kategorie nach Anwendungsverwaltung und Aktivität nach Anwendung aktualisieren – Verwaltung von Zertifikaten und Secrets.

  • Prüfen Sie, ob dem Dienstprinzipal neu erstellte oder unerwartete Anmeldeinformationen zugewiesen sind.
  • Prüfen Sie über die Microsoft Graph-API, ob Anmeldeinformationen für den Dienstprinzipal vorliegen.
  • Überprüfen Sie sowohl die Anwendung als auch die zugehörigen Objekte des Dienstprinzipals.
  • Überprüfen Sie alle benutzerdefinierten Rollen, die Sie gegebenenfalls erstellt oder geändert haben. Beachten Sie die unten markierten Berechtigungen:

Check custom roles that are created or have been modified

Wenn Sie App-Governance in Microsoft Defender für Cloud Apps bereitgestellt haben, überprüfen Sie das Azure-Portal auf Warnungen in Bezug auf die Anwendung. Weitere Informationen finden Sie unter Erste Schritte mit der Erkennung und Behebung von App-Bedrohungen.

Wenn Sie den Identitätsschutz bereitgestellt haben, überprüfen Sie den Bericht „Risikoerkennung“ und den „Risikoverlauf“ der Identität des/der Benutzer*in oder der Workload Identities.

Risk Detection portal

Wenn Sie Microsoft Defender for Cloud Apps bereitgestellt haben, vergewissern Sie sich, dass die Richtlinie „Ungewöhnliche Hinzufügung von Anmeldeinformationen zu einer OAuth-App“ aktiviert ist, und prüfen Sie, ob offene Warnungen vorliegen.

Weitere Informationen finden Sie unter Ungewöhnliche Hinzufügung von Anmeldeinformationen zu einer OAuth App.

Zusätzlich können Sie die APIs servicePrincipalRiskDetections und userRiskDetections abfragen, um diese Risikoerkennungen abzurufen.

Suche nach ungewöhnlichen Änderungen der App-Konfiguration

  • Überprüfen Sie die der App zugewiesenen API-Berechtigungen, um sicherzustellen, dass die Berechtigungen mit den Erwartungen für die App übereinstimmen.
  • Überprüfen Sie Audit-Protokolle (filtern Sie die Aktivität nach Update-Anwendung oder Update-Dienstprinzipal).
  • Überprüfen Sie, ob die Verbindungsstrings konsistent sind und ob die Abmelde-URL geändert wurde.
  • Überprüfen Sie, ob die Domains in der URL mit den registrierten Domains übereinstimmen.
  • Stellen Sie fest, ob jemand eine nicht autorisierte Umleitungs-URL hinzugefügt hat.
  • Bestätigen Sie den Besitz Ihres Umleitungs-URI, um sicherzustellen, dass er nicht abgelaufen ist und von einem Angreifer beansprucht wurde.

Wenn Sie Microsoft Defender for Cloud Apps bereitgestellt haben, überprüfen Sie außerdem das Azure-Portal auf Warnungen, die sich auf die Anwendung beziehen, die Sie gerade untersuchen. Nicht alle Warnungsrichtlinien sind standardmäßig für OAuth-Apps aktiviert. Stellen Sie also sicher, dass diese Richtlinien alle aktiviert sind. Weitere Informationen finden Sie in den Richtlinien für OAuth-Apps. Sie können auch Informationen über die Verbreitung der Apps und die jüngsten Aktivitäten unter der Registerkarte Untersuchung>OAuth Apps einsehen.

Auf verdächtige Anwendungsrollen prüfen

  • Sie können auch die Überwachungsprotokolle verwenden. Filtern Sie Aktivitäten nach Zuweisung einer App-Rolle zum Dienstprinzipal.
  • Überprüfen Sie, ob die zugewiesenen Rollen über hohe Privilegien verfügen.
  • Überprüfen Sie, ob diese Privilegien notwendig sind.

Prüfen Sie auf nicht verifizierte kommerzielle Apps

  • Prüfen Sie, ob kommerzielle Katalog-Anwendungen (veröffentlichte und verifizierte Versionen) verwendet werden.

Auf Hinweise auf die Offenlegung von keyCredential-Eigenschaftsinformationen prüfen

Überprüfen Sie Ihren Tenant auf eine mögliche Offenlegung von keyCredential-Eigenschaftsinformationen, wie in CVE-2021-42306 dargelegt.

Um betroffene Microsoft Entra-Anwendungen, die mit betroffenen Automation Run-As-Konten verknüpft sind, zu identifizieren und zu beheben, navigieren Sie bitte zum Richtlinie zur Behebung GitHub Repo.

Wichtig

Beweise für eine Kompromittierung: Wenn Sie Beweise für eine Kompromittierung entdecken, ist es wichtig, dass Sie die in den Abschnitten zur Eindämmung und Wiederherstellung genannten Schritte unternehmen. Diese Schritte werden dabei helfen, das Risiko einzudämmen, Sie müssen aber weitere Untersuchungen durchführen, um die Quelle der Kompromittierung zu verstehen, damit weitere Auswirkungen vermieden und bösartige Akteure entfernt werden können.

Es gibt zwei primäre Methoden, sich über Anwendungen Zugriff auf Systeme zu verschaffen. Die erste besteht darin, dass ein/eine Administrator*in oder Benutzer*in einer Anwendung sein Einverständnis gibt, in der Regel über einen Phishing-Angriff. Dieser Ansatz wäre Teil des ersten Zugriffs auf ein System und wird oft als „Consent-Phishing“ bezeichnet.

Bei der zweiten Methode erstellt ein bereits kompromittiertes Administratorkonto eine neue App mit dem Ziel der Persistenz, der Datenerfassung und um unter dem Radar zu bleiben. Beispielsweise könnte ein*e kompromittierter Administrator*in eine OAuth-App mit einem scheinbar harmlosen Namen erstellen, um eine Entdeckung zu vermeiden und einen langfristigen Zugriff auf Daten zu ermöglichen, ohne dass ein Konto erforderlich wäre. Diese Methode wird häufig bei Angriffen mit nationalem Charakter eingesetzt.

Im Folgenden finden Sie einige der Schritte, die Sie zur weiteren Untersuchung unternehmen können.

Überprüfen Sie Microsoft 365 Unified Audit Log (UAL) auf Phishing-Hinweise für die letzten sieben Tage

Manchmal, wenn Angreifer bösartige oder kompromittierte Anwendungen als Mittel zur Persistenz oder zum Exfiltrieren von Daten verwenden, handelt es sich um eine Phishing-Kampagne. Basierend auf den Erkenntnissen aus den vorherigen Schritten sollten Sie folgende Identitäten überprüfen:

  • Anwendungsbesitzer
  • Zustimmungs-Admins

Überprüfen Sie die Identitäten auf Hinweise auf Phishing-Angriffe in den letzten 24 Stunden. Erweitern Sie diese Zeitspanne bei Bedarf auf 7, 14 und 30 Tage, wenn es keine unmittelbaren Hinweise gibt. Ein detailliertes Playbook zur Phishing-Untersuchung finden Sie unter Playbook zur Phishing-Untersuchung.

Nach schädlichen Anwendungsgenehmigungen der letzten sieben Tage suchen

Um eine Anwendung zu einem Mandanten hinzuzufügen, täuschen Angreifer Benutzende oder Admins vor, um die Genehmigung für Anwendungen zu erhalten. Weitere Informationen zu den Anzeichen eines Angriffs finden Sie im Untersuchungs-Playbook zur Erteilung von Anwendungsgenehmigungen.

Überwachungsprotokolle prüfen

Um alle Genehmigungen für diese Anwendung zu sehen, filtern Sie Aktivität nach Genehmigung für Anwendung.

  • Verwenden Sie die Microsoft Entra Admin Center Audit-Protokolle

  • Verwenden Sie Microsoft Graph zur Abfrage der Audit-Protokolle

    a) Filtern Sie nach einem bestimmten Zeitrahmen:

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

b) Filtern Sie die Überwachungsprotokolle nach Überwachungsprotokoll-Einträgen vom Typ "Zustimmung zu Anwendungen":

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) Verwenden Sie Log-Datei-Analysen

AuditLogs
| where ActivityDisplayName == "Consent to application"

Weitere Informationen finden Sie im Untersuchungs-Playbook zur Erteilung von Anwendungsgenehmigungen.

Ein Benutzer kann eine Anwendung autorisieren, auf einige Daten in der geschützten Ressource zu zugreifen, während er als dieser Benutzer agiert. Die Berechtigungen, die diese Art von Zugriff ermöglichen, werden "delegierte Berechtigungen" oder Benutzerzustimmung genannt.

Um Apps zu finden, denen die Benutzenden zugestimmt haben, durchsuchen Sie mit LogAnalytics die Überwachungsprotokolle:

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

Überprüfen der Log-Dateien, um herauszufinden, ob die erteilten Berechtigungen zu weit gefasst sind (mandantenweit oder mit Admin-Zustimmung)

Die Überprüfung der einer Anwendung oder einem Service Principal erteilten Berechtigungen kann eine zeitraubende Aufgabe sein. Beginnen Sie damit, die potenziell riskanten Berechtigungen in Microsoft Entra ID zu verstehen.

Folgen Sie nun der Anleitung zum Aufzählen und Überprüfen von Berechtigungen in der App-Zustimmungsuntersuchung.

Prüfen Sie, ob die Berechtigungen von Benutzeridentitäten erteilt wurden, die dazu nicht in der Lage sein sollten, oder ob die Aktionen zu merkwürdigen Daten und Zeiten durchgeführt wurden

Überprüfung anhand von Audit-Protokollen:

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

Sie können auch die Audit-Protokolle von Microsoft Entra verwenden und nach Zustimmung zur Anwendung filtern. Klicken Sie im Abschnitt Details des Audit-Protokolls auf Geänderte Eigenschaften und überprüfen Sie dann die ConsentAction.Permissions:

Use the Microsoft Entra audit logs

Schritte zur Eingrenzung

Nachdem Sie eine oder mehrere Anwendungen oder Workload-Identitäten als schädlich oder kompromittiert identifiziert haben, sollten Sie nicht unbedingt sofort die Anmeldeinformationen für diese Anwendung ändern oder die Anwendung sofort löschen.

Wichtig

Bevor Sie den folgenden Schritt ausführen, muss Ihre Organisation die Auswirkungen auf die Sicherheit und die Auswirkungen der Deaktivierung einer Anwendung auf das Unternehmen abwägen. Wenn die geschäftlichen Auswirkungen der Deaktivierung einer Anwendung zu groß sind, sollten Sie die Vorbereitung und den Übergang zur Wiederherstellungsphase dieses Prozesses in Betracht ziehen.

Kompromittierte Anwendung deaktivieren

Eine typische Eindämmungsstrategie besteht darin, die Anmeldung bei der identifizierten Anwendung zu deaktivieren, um Ihrem Team für die Reaktion auf einen Vorfall oder der betroffenen Unternehmenseinheit Zeit zu geben, die Auswirkungen einer Löschung oder eines Schlüsselwechsels zu bewerten. Wenn Ihre Untersuchung zu der Annahme führt, dass auch Anmeldeinformationen für Admin-Konten kompromittiert wurden, sollte diese Art von Aktivität mit einem Evakuierungsereignis koordiniert werden, um sicherzustellen, dass alle Wege zum Zugriff auf den Mandanten gleichzeitig abgeschnitten werden.

Toggle to disable users to sign-in

Sie können auch den folgenden PowerShell-Code für Microsoft Graph verwenden, um die Anmeldung bei der App zu deaktivieren:

# 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
   
}

Wiederherstellungsschritte

Dienstprinzipale sanieren

  1. Listen Sie alle Anmeldeinformationen auf, die dem riskanten Dienstprinzipal zugewiesen sind. Am besten führen Sie dazu einen Microsoft Graph-Aufruf mit GET ~/application/{id} durch, wobei id die Objekt-ID der Anwendung ist.

    • Analysieren Sie die Ausgabe auf Anmeldeinformationen. Die Ausgabe kann passwordCredentials oder keyCredentials enthalten. Zeichnen Sie die keyIds für alle auf.

      "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. Fügen Sie dem Anwendungsobjekt mit der addKey-API eine neue Anmeldeinformation für ein Zertifikat (x509) hinzu.

    POST ~/applications/{id}/addKey

  3. Entfernen Sie sofort alle alten Anmeldeinformationen. Entfernen Sie für jede alte Anmeldeinformation das Kennwort:

    POST ~/applications/{id}/removePassword

    Entfernen Sie für jede alte Anmeldeinformation den Schlüssel:

    POST ~/applications/{id}/removeKey

  4. Sanieren Sie alle Dienstprinzipale, die mit der Anwendung verbunden sind. Diesen Schritt sollten Sie ergreifen, wenn Ihr Mandant eine mandantenfähige Anwendung hostet/registriert und/oder mehrere Dienstprinzipale registriert, die mit der Anwendung verbunden sind. Führen Sie dieselben Schritte aus wie vorstehend aufgeführt:

  • GET ~/servicePrincipals/{id}

  • passwordCredentials und keyCredentials in der Antwort suchen und alle alten keyIds aufzeichnen

  • Entfernen Sie alle alten Kennwörter und Anmeldeinformationen. Verwenden Sie:

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

Sanieren der betroffenen Ressourcen des Dienstprinzipals

Sanieren Sie die KeyVault-Secrets, auf die der Dienstprinzipal Zugriff hat, indem Sie sie in der folgenden Priorität rotieren:

  • Secrets, die direkt GetSecret-Aufrufen ausgesetzt sind.
  • Die restlichen Secrets in exponierten KeyVaults.
  • Die restlichen Secrets in offengelegten Abonnements.

Weitere Informationen finden Sie unter Interaktives Entfernen und Überschreiben von Zertifikaten und Geheimnissen eines Service Principal oder einer Anwendung.

Für Microsoft Entra SecOps-Anleitungen zu Anwendungen siehe Microsoft Entra Sicherheitsbetriebshandbuch für Anwendungen.

In der Reihenfolge der Priorität wäre dies ein Szenario:

  • Aktualisierung der Graph PowerShell-Cmdlets (Add/Remove ApplicationKey + ApplicationPassword), um Beispiele für den Rollover von Anmeldeinformationen einzubeziehen.
  • Hinzufügen angepasster Cmdlets zur Microsoft Graph PowerShell, die dieses Szenario vereinfachen.

Schädliche Anwendungen deaktivieren oder löschen

Eine Anwendung kann entweder deaktiviert oder gelöscht werden. Stellen Sie zum Deaktivieren der Anwendung unter Aktiviert für Benutzer zur Anmeldung den Schalter auf Nein.

Sie können die Anwendung entweder vorübergehend oder dauerhaft im Azure-Portal oder über die Microsoft Graph-API löschen. Wenn Sie ein Soft-Delete der Anwendung durchführen, kann sie bis zu 30 Tage nach der Löschung wiederhergestellt werden.

DELETE /applications/{id}

Um die Anwendung dauerhaft zu löschen, verwenden Sie diesen Aufruf der Microsoft Graph API:

DELETE /directory/deletedItems/{id}

Wenn Sie die Anwendung deaktivieren oder „sanft“ löschen, richten Sie eine Überwachung in den Microsoft Entra Audit-Protokollen ein, um zu erfahren, ob der Status wieder auf aktiviert oder wiederhergestellt wechselt.

Protokollierung für aktiviert:

  • Dienst – Core Directory
  • Aktivitätstyp – Dienstprinzipal aktualisieren
  • Kategorie – Anwendungsverwaltung
  • Initiiert von (Akteur) – UPN des Akteurs
  • Ziele – App-ID und Anzeigename
  • Geänderte Eigenschaften – Eigenschaftsname = Konto aktiviert, neuer Wert = Wahr

Log-Dateien für wiederhergestellt:

  • Dienst – Core Directory
  • Aktivitätstyp – Dienstprinzipal hinzufügen
  • Kategorie – Anwendungsverwaltung
  • Initiiert von (Akteur) – UPN des Akteurs
  • Ziele – App-ID und Anzeigename
  • Modifizierte Eigenschaften – Eigenschaftsname = Konto aktiviert, neuer Wert = true

Hinweis: Microsoft deaktiviert weltweit Anwendungen, die gegen seine Nutzungsbedingungen verstoßen. In diesen Fällen werden diese Anwendungen DisabledDueToViolationOfServicesAgreement in der Eigenschaft disabledByMicrosoftStatus der zugehörigen Ressourcentypen der Anwendung und des Dienstprinzipals in Microsoft Graph anzeigen. Um zu verhindern, dass die Objekte in Zukunft in Ihrer Organisation erneut instanziiert werden, können Sie diese nicht löschen.

Implementierung des Identitätsschutzes für Workload-Identitäten

Microsoft erkennt Risiken bei Workload-Identitäten über das Anmeldeverhalten und Offline-Indikatoren für eine Kompromittierung.

Weitere Informationen finden Sie unter Sichern von Workload-Identitäten mit Identitätsschutz.

Diese Benachrichtigungen werden im Identity Protection-Portal angezeigt und können über Diagnoseeinstellungen oder die Identity Protection-APIs in SIEM-Tools exportiert werden.

Review risks and alerts in the Identity Protection portal

Conditional Access für risikoreiche Workload-Identitäten

Der bedingte Zugriff bietet Ihnen die Möglichkeit, den Zugriff für bestimmte, von Ihnen festgelegte Konten zu sperren, wenn sie vom Identitätsschutz als "gefährdet" eingestuft werden. Beachten Sie, dass die Durchsetzung des bedingten Zugriffs derzeit auf Anwendungen mit einem einzigen Mandanten beschränkt ist.

Control user access based on conditional access policy

Weitere Informationen finden Sie unter Bedingter Zugriff für Workload-Identitäten.

Richtlinien für Anwendungsrisiken implementieren

Überprüfen Sie die Einstellungen für die Zustimmung des Benutzers unter Microsoft Entra ID>Enterpriseanwendungen>Zustimmung und Berechtigung>Benutzer Zustimmungseinstellungen.

Select Allow user consent for apps from the options

Um die Konfigurationsoptionen zu überprüfen, siehe Konfigurieren Sie, wie Benutzer Apps zustimmen.

Wenn ein*e Anwendungsentwickler*in Benutzer*innen mit der Absicht zum Administratoreinwilligungsendpunkt weiterleitet, die Einwilligung für den gesamten Mandanten zu erteilen, wird das als Administratoreinwilligungsflow bezeichnet. Um sicherzustellen, dass der Administratoreinwilligungsflow ordnungsgemäß funktioniert, müssen Anwendungsentwickler alle Berechtigungen in der Eigenschaft RequiredResourceAccess im Anwendungsmanifest auflisten.

Die meisten Organisationen deaktivieren die Möglichkeit für die Benutzenden, ihre Zustimmung für Anwendungen zu erteilen. Um den Benutzern die Möglichkeit zu geben, weiterhin die Zustimmung für Anwendungen anzufordern und über eine administrative Überprüfungsfunktionalität zu verfügen, empfiehlt sich die Implementierung des Workflow für die Administratoreinwilligung. Folgen Sie den Schritten zum Workflow für die Admin-Zustimmung, um ihn in Ihrem Mandanten zu konfigurieren.

Für Vorgänge mit hohen Berechtigungen wie der Administratoreinwilligung müssen Sie eine Strategie für den privilegierten Zugriff gemäß unserer Leitfaden definieren.

Die risikobasierte Step-up-Zustimmung trägt dazu bei, die Gefährdung von Benutzenden durch schädliche Apps zu verringern. Beispielsweise werden Anforderungen zur Einwilligung für neu registrierte Apps mit mehreren Mandanten, die nicht von einem verifizierten Herausgeber stammen und Nichtstandardberechtigungen erfordern, als riskant eingestuft. Wenn eine riskante Benutzereinwilligungsanforderung erkannt wird, erfordert die Anforderung stattdessen einen "Schritt nach oben" für die Administratoreinwilligung. Diese Funktion ist standardmäßig aktiviert, führt jedoch nur dann zu einer Änderung des Verhaltens, wenn die Benutzereinwilligung aktiviert ist.

Stellen Sie sicher, dass dieser in Ihrem Mandanten aktiviert ist, und überprüfen Sie die hier beschriebenen Konfigurationseinstellungen.

References

Zusätzliche Playbooks zur Reaktion auf Vorfälle

Überprüfen Sie den Leitfaden zum Identifizieren und Untersuchen dieser zusätzlichen Arten von Angriffen:

Ressourcen zur Reaktion auf Vorfälle