Verdächtige Anmeldungen untersuchen

Verfügbare Beweise kennen

Microsoft 365 Business Standard kann aktuelle Anmeldungen im Portal untersuchen. Aufbewahrung und erweiterte Risikofunktionen hängen jedoch von der Entra-Lizenz ab. Ein fehlendes Premium-Signal beweist keine Sicherheit.

Least-Privilege-Aktionsmatrix

Das zu prüfende Signal benennen

Beginnen Sie mit dem ursprünglichen Signal. Eine verdächtige Anmeldung ist eine zu beantwortende Frage und kein automatischer Kompromittierungsnachweis.

Was ist zu tun?

• Ursprüngliche Warnung oder Meldung sichernID, Melder, Zeit, betroffene UPN und genaue Fragestellung speichern.
• Enges UTC-Zeitfenster setzenMit 30 Minuten vor und nach dem Ereignis beginnen und nur bei Bedarf erweitern.
• Sensitivität erfassenAdministratorrollen, Finanz- oder Leitungsaufgaben, privilegierte Anwendungen und regulierte Daten notieren.

Ereignis vor dem Handeln klassifizieren

Beantworten Sie wer, wie und was. Entscheiden Sie danach, ob das Ereignis sicher, ein technisches Problem, verdächtig oder Teil eines breiteren Angriffs ist.

Was ist zu tun?

• Anmeldetyp bestimmenBenutzer interaktiv, Benutzer nicht interaktiv, Dienstprinzipal oder verwaltete Identität.
• Status und Fehlercode lesenErfolg kann ein ausgestelltes Token bedeuten. Fehler gilt für diesen Versuch. Unterbrochen bedeutet oft, dass ein weiterer Kontroll- oder Benutzerschritt nötig war.
• WerUser ID, UPN, Tenant, Identitätstyp, Rollen und jüngste Änderungen bestätigen.
• WieAuthentifizierungsanforderung, Methoden, Reihenfolge, Client, User Agent, Conditional Access und Tokenschutz prüfen.
• WasAnwendung, Ressource, IP, Gerät, Standort, Risiko, Request ID und Correlation ID prüfen.
• Sicher beim Benutzer bestätigenÜber einen bekannten separaten Kanal nach UTC-Zeit, Anwendung und Aktion fragen, ohne die erwartete Antwort vorzugeben.

• Tenant-Grenze bestimmenBei Gast- oder externen Identitäten Benutzertyp, Cross-Tenant-Zugriffstyp, Home Tenant ID und Resource Tenant ID dokumentieren.

Nur bei entsprechender Entscheidung eindämmen

Diese SOP entscheidet, ob Eindämmung nötig ist. Die SOP Kompromittiertes Konto verwaltet Deaktivierung, Sitzungswiderruf, Kennwort, MFA und Persistenz.

Vorher sichern

• EreigniskennungenRequest ID, Correlation ID, UTC-Zeit und Warnungs-ID.
• OriginalexporteInteraktive und nicht interaktive Dateien mit den genauen Filtern.
• Aktueller ZustandRisiko, Kontostatus, Rollen, Authentifizierungsmethoden und Conditional-Access-Ergebnis.

Anmeldung Schritt für Schritt untersuchen

Beginnen Sie im Portal. Dort lässt sich das Ereignis schnell vergleichen und exportieren. Graph nur mit passender Lizenz und bei echtem Mehrwert verwenden.

1. Interaktive und nicht interaktive Protokolle exportieren

• Benutzeranmeldungen, interaktivRegisterkarte öffnen, Benutzer- und UTC-Filter beibehalten, Download wählen und CSV oder JSON speichern.
• Benutzeranmeldungen, nicht interaktivSeparat exportieren. Gruppierte Zeilen erweitern, da eine Zeile mehrere Versuche enthalten kann.
• Exportkontext dokumentierenUTC-Zeitraum, Filter, Exportzeit, Operator und Tenant speichern. Originaldateien schreibgeschützt halten.

2. Ein Ereignis immer in derselben Reihenfolge lesen

3. Vergleichen, nicht anhand eines Feldes urteilen

• Normales Benutzerverhalten vergleichenFrühere erfolgreiche Anmeldungen für Anwendungen, Geräte, Standorte, IP-Bereiche und Methoden prüfen.
• Verwandte Tenant-Aktivität suchenDieselbe IP, Anwendung, Browser, Gerät oder UTC-Zeitfenster bei anderen Benutzern filtern.
• Risikodetails bei vorhandener Lizenz öffnenErkennungstyp, Zeitpunkt, Verlauf und verbundenes Benutzerrisiko prüfen.
• Anmeldediagnose für Fehler verwendenFehlerereignis → Grundlegende Informationen → Anmeldediagnose starten. Als technische Erklärung verwenden, nicht als Sicherheitsfreigabe.

# Read-only example. Requires Entra ID P1/P2 and an authorized reader role.
$ErrorActionPreference = 'Stop'
Import-Module Microsoft.Graph.Reports
$tenantId = [guid](Read-Host 'Tenant ID (GUID)')
if ($tenantId -eq [guid]::Empty) { throw 'A tenant ID is required.' }
$upn = (Read-Host 'Exact user principal name').Trim()
if (-not $upn -or $upn.Contains("'")) { throw 'Enter a valid user principal name.' }
$startInput = Read-Host 'Start, with UTC offset (e.g. 2026-09-15T08:00:00Z)'
$endInput = Read-Host 'End, with UTC offset (e.g. 2026-09-15T10:00:00Z)'
if ($startInput -notmatch 'T.*(Z|[+-][0-9]{2}:[0-9]{2})$' -or $endInput -notmatch 'T.*(Z|[+-][0-9]{2}:[0-9]{2})$') {
  throw 'Both timestamps must include Z or an explicit UTC offset.'
}
$startUtc = [datetimeoffset]::Parse($startInput, [cultureinfo]::InvariantCulture)
$endUtc = [datetimeoffset]::Parse($endInput, [cultureinfo]::InvariantCulture)
if ($endUtc -le $startUtc) { throw 'End must be after start.' }
$start = $startUtc.UtcDateTime.ToString("yyyy-MM-ddTHH:mm:ss.fffffffZ", [cultureinfo]::InvariantCulture)
$end = $endUtc.UtcDateTime.ToString("yyyy-MM-ddTHH:mm:ss.fffffffZ", [cultureinfo]::InvariantCulture)

$connected = $false
try {
  Connect-MgGraph -TenantId $tenantId -ContextScope Process -Scopes 'AuditLog.Read.All'
  $connected = $true
  if ([guid](Get-MgContext).TenantId -ne $tenantId) { throw 'Wrong tenant context.' }
  $filter = "userPrincipalName eq '$upn' and createdDateTime ge $start and createdDateTime lt $end"
  Get-MgAuditLogSignIn -Filter $filter -All |
    Select-Object Id,CreatedDateTime,UserPrincipalName,IsInteractive,
      AppDisplayName,ResourceDisplayName,IpAddress,ClientAppUsed,
      ConditionalAccessStatus,CorrelationId,
      @{Name='ErrorCode';Expression={$_.Status.ErrorCode}}
  # This selected-field view does not preserve the full event. Keep original exports.
} finally {
  if ($connected) { Disconnect-MgGraph }
}

Ein klares Ergebnis dokumentieren

Das Ergebnis muss Beweise und nächste Aktion erklären. Risiko nicht nur zum Entfernen einer Warnung verwerfen.

Diese Ergebnisse beziehen sich auf das untersuchte Ereignis und Zeitfenster. Sie bestätigen nicht die Sicherheit jeder Sitzung oder des gesamten Kontos. Erfassungslücken bleiben ausdrücklich dokumentiert.

Was ist zu tun?

• Ein Ergebnis wählenSicher, Problembehandlung, Ungeklärt, Verdächtig oder Breiter Angriff. Sicherheit und widersprechende Beweise dokumentieren.
• Risikostatus sorgfältig aktualisierenNur bestätigte falsche oder harmlose Ergebnisse verwerfen. Kompromittierung nur nach Untersuchung bestätigen und sofort eindämmen.
• Nächsten Datensatz verknüpfenSupportticket oder Incident-ID der SOP Kompromittiertes Konto hinzufügen.
• Ergebnis validierenBei Problembehandlung eine erfolgreiche geschützte Anmeldung reproduzieren. Bei Kompromittierung das Abschluss-Gate der Haupt-SOP verwenden.

Das nächste Ereignis leichter verhindern und erklären

Jede erkannte Lücke in eine kleine, verantwortete Verbesserung umwandeln.

Was ist zu tun?

• Beobachtete Lücke beschreibenBeispiel: nur sieben Tage Verlauf, Legacy-Client, schwache MFA oder kein Owner für Risikowarnungen.
• Eine verantwortete Aktion erstellenOwner, Fälligkeitsdatum, Erfolgstest und Rollback festlegen.
• Erkennung und Reaktion testenWarnung, Untersuchungsrolle, Export und Eskalationsweg validieren.

Eine reproduzierbare Entscheidung sichern

Ein Screenshot liefert Kontext. Originalexport, Kennungen, Filter und Begründung machen die Entscheidung wiederholbar.

Was sichern?

• Quelle und UmfangTenant, UPN, Signal, UTC-Zeitfenster, Filter, Exportzeit und Operator.
• OriginaldateienInteraktive und nicht interaktive CSV- oder JSON-Exporte getrennt und unverändert.
• Genaues EreignisErgebnis, Fehler, Request ID, Correlation ID, App, Ressource, IP, Gerät, Authentifizierung, Richtlinien und Risiko.
• BenutzeraussageKontaktperson, vertrauenswürdiger Kanal, genaue Frage, Antwort und UTC-Zeit.
• Vergleich und GrenzenBasisverhalten, verwandte Suche, unterstützende und widersprechende Beweise, Aufbewahrungs- und Lizenzlücken.
• Entscheidung und FolgedatensatzErgebnis, Sicherheit, Genehmiger, Risikoaktion und verknüpfter Support- oder Incident-Datensatz.

• Integritäts-HashesFür jeden Originalexport einen SHA-256-Hash berechnen und dokumentieren, bevor mit einer Kopie gearbeitet wird.

FALL- / WARNUNGS-ID:
TENANT:
UPN:
SIGNAL UND QUELLE:
UTC-ZEITFENSTER UND FILTER:
EREIGNISZEIT / ERGEBNIS / FEHLER:
REQUEST ID / CORRELATION ID:
ANWENDUNG / RESSOURCE / CLIENT:
IP / STANDORT / GERÄT / USER AGENT:
AUTHENTIFIZIERUNGSDETAILS:
CONDITIONAL ACCESS:
RISIKODETAILS:
BENUTZERBESTÄTIGUNG UND KANAL:
VERWANDTE TENANT-AKTIVITÄT:
DATEINAMEN DER ORIGINALEXPORTE:
SHA-256-HASHES DER ORIGINALEXPORTE:
DATEN- ODER LIZENZGRENZEN:
ENTSCHEIDUNG: SICHER | PROBLEMBEHANDLUNG | UNGEKLÄRT | VERDÄCHTIG | BREITER ANGRIFF
SICHERHEIT UND GRUND:
FOLGEDATENSATZ / OWNER / UTC-ZEIT:

Für einen JSON-Export kann die lokale Beweisanalyse den Hash berechnen und gelieferte Datensätze ohne Upload zusammenfassen. Zählungen sind kein Sicherheitsurteil. Diese ausführliche Notiz intern aufbewahren und Identitäten vor einer externen Anfrage schwärzen.

Get-FileHash -LiteralPath "<original-export.csv>" -Algorithm SHA256

Entscheidung klar verantworten

Eine Person verantwortet Untersuchung und Schlussfolgerung. Spezialisten kommen nur hinzu, wenn ihre Systeme oder Befugnisse benötigt werden.

Sofort eskalieren bei

• Privilegierte oder kritische IdentitätAdministrator, Notfallzugriff, Dienst, Leitung oder Finanzen.
• Abgelehnter erfolgreicher ZugriffBenutzer bestreitet das Ereignis, verdächtiges Token besteht oder Zugriff lief ohne erneute Abfrage weiter.
• Mehrere Benutzer oder gemeinsames AngriffsmusterKennwortspray, gleiche bösartige IP, Anwendung oder Tokenmuster.
• Unbekannte Anwendung oder DienstprinzipalUnerwartete Zustimmung, unbekannte Ressource oder tenantweite Berechtigung.
• Daten-, Betrugs- oder GeräterisikoRegulierte Daten, Massendownload, Zahlungen, Malware oder Tokendiebstahl.
• Benutzer nicht erreichbarUngeklärte erfolgreiche Aktivität bei sensitiven Identitäten vorsorglich behandeln.

Abschluss-Gate

• Ergebnis ist eindeutigSicher, Problembehandlung, Ungeklärt, Verdächtig oder Breiter Angriff mit Sicherheit und Grund.
• Beweise sind reproduzierbarExporte, Kennungen, Benutzeraussage, Vergleich und Grenzen sind gespeichert.
• Risikostatus ist korrektRisiko wurde nicht nur zum Schließen der Warnung verworfen.
• Folgearbeit ist verknüpft und verantwortetSupportkorrektur, Präventionsaktion oder Incident Kompromittiertes Konto hat einen Owner.