Abwehr von Identity-First-Angriffen: Session-Diebstahl, AiTM-Phishing und 'Einloggen'-Angriffe

Identity-First-Angriffe sind mittlerweile ein praktisches Sicherheitsproblem, weil Angreifer nicht mehr immer “einbrechen” muessen. Branchenweite Bedrohungsberichte beschreiben konsequent eine breitere Verschiebung weg von teuren Einzeleinbruchstechniken hin zu effizienterem Missbrauch vertrauenswuerdiger Zugaenge, wobei gestohlene Session-Token als rentablere Option als viele traditionelle Exploit-Pfade aufkommen. Microsofts Token-Theft-Leitfaden beschreibt dasselbe Muster aus Verteidigersicht: Sobald ein Token gestohlen und wiedergegeben wird, kann der Angreifer Zugriff erlangen, selbst wenn der Benutzer bereits MFA erfuellt hat.

Dieses Tutorial behandelt die Identity-First-Angriffe, die die meisten Teams jetzt in realen Umgebungen sehen: Adversary-in-the-Middle-Phishing, Session-Cookie-Diebstahl, Token-Replay, Support-Pfad-Identitaetsmissbrauch und den “Einloggen”-Stil des Eindringens, bei dem der Angreifer vertrauenswuerdigen Identitaets- und SaaS-Zugang missbraucht, statt auffaellige Malware oder offensichtliche Brute Force einzusetzen. Moderne AiTM-Kampagnen sind besonders gefaehrlich, weil sie Anmeldedaten und Session-Cookies in Echtzeit stehlen, die Session wiedergeben und dann Persistenz durch Aendern von MFA-Methoden oder Posteingangsregeln herstellen koennen.

Am Ende haben Sie einen praktischen Haertungsplan: Identifizieren Sie die Konten, die am wahrscheinlichsten angegriffen werden, verlangen Sie staerkere Authentifizierung, reduzieren Sie Session-Replay-Moeglichkeiten, verschaerfen Sie Support-Workflows, fuegen Sie nuetzliches Monitoring hinzu und proben Sie die Reaktion auf einen Session-Diebstahl-Vorfall. Wenn Sie auch einen breiteren Workforce-Rollout staerkerer Authentifizierung planen, passt dieses Tutorial gut zu Enterprise Passkeys und Phishing-resistente MFA ausrollen.

Schritt 1: Identifizieren Sie Ihre risikoreichsten Identitaeten

Der schnellste Weg, die Identitaetssicherheit zu verbessern, ist nicht, jedes Konto gleich zu haerten. Es ist, mit den Konten zu beginnen, die Angreifer am wahrscheinlichsten zuerst ausnutzen. Aktuelle Bedrohungsforschung rahmt die aktuelle Landschaft als “High-Trust Exploitation” ein, was genau der Grund ist, warum Admin-, Entwickler-, Finanz-, Help-Desk- und Drittanbieter-Identitaeten besondere Behandlung verdienen.

Erstellen Sie ein Risikoinventar

Erstellen Sie eine kleine Datei, die Identitaetstypen mit Risiko, Privilegien und wahrscheinlichen Missbrauchspfaden abbildet.

admins:
  examples:
    - cloud-admins
    - idp-admins
    - email-admins
  risks:
    - tenant-wide compromise
    - privilege escalation
    - policy tampering
  priority: critical

developers:
  examples:
    - ci-cd-maintainers
    - repo-admins
    - secrets-managers
  risks:
    - source tampering
    - secret exposure
    - supply-chain abuse
  priority: high

finance_hr:
  examples:
    - payroll
    - accounts-payable
    - hr-ops
  risks:
    - bec-fraud
    - payroll diversion
    - pii exposure
  priority: high

help_desk:
  examples:
    - password-reset-agents
    - identity-support
  risks:
    - social-engineering pivot
    - mfa reset abuse
    - account recovery hijack
  priority: critical

third_party_access:
  examples:
    - contractors
    - vendors
    - managed-service-accounts
  risks:
    - weak endpoint hygiene
    - unmanaged-device access
    - supply-chain identity exposure
  priority: high

Erfassen Sie echte Berechtigungen, nicht nur Jobtitel

Nehmen Sie nicht an, dass “Finanzen” hohes Risiko ist und “Projektmanager” nicht. Schauen Sie sich die tatsaechlichen Berechtigungen an:

• Wer kann MFA zuruecksetzen
• Wer kann Zahlungen genehmigen
• Wer kann Mail-Flow verwalten
• Wer kann App-Registrierungen erstellen
• Wer kann auf Kundendaten-Exporte zugreifen
• Wer kann Code oder Artefakte veroeffentlichen

Eine Tabelle oder YAML-Datei reicht aus, solange sie die Realitaet widerspiegelt.

Schliessen Sie geteilten und ruhenden Zugriff ein

Inventarisieren Sie auch:

• Break-Glass-Konten
• Geteilte Admin-Geraete
• Service-Konten mit interaktiver Anmeldung
• Ruhende privilegierte Benutzer
• Drittanbieter-Support-Konten, die noch aktiviert sind

Sie sollten nun eine Liste der Identitaeten haben, die staerkere Kontrollen verdienen, bevor der Rest der Belegschaft an der Reihe ist.

Schritt 2: Authentifizierung haerten

Das Ziel hier ist nicht “mehr MFA-Prompts.” Es ist, Phishing und Token-Missbrauch materiell schwieriger zu machen. Microsofts aktuelle Identitaetsleitfaden sagt explizit, dass Passkeys Phishing-resistente Authentifizierung bieten, die Angreifer nicht phishen, abfangen oder wiedergeben koennen, und empfiehlt Phishing-resistente Methoden fuer privilegierte Konten und Conditional-Access-Richtlinien, die starke Authentifizierung fuer sensible Anwendungen erzwingen.

Verlangen Sie Phishing-resistente MFA zuerst fuer die richtigen Benutzer

Beginnen Sie mit IdP-Admins, Cloud-Admins, Finanzgenehmigern, Help-Desk-Mitarbeitern, Entwicklern mit Produktions- oder CI/CD-Privilegien und haeufig angegriffenen Fuehrungskraeften. Blockieren Sie SMS, Sprachanruf und Push-only-MFA fuer diese Benutzer. Verlangen Sie Passkeys oder Security Keys und setzen Sie ein 90-Tage-Migrationsziel fuer Standard-Hochrisikobenutzer.

Erzwingen Sie Geraetevertrauen fuer sensiblen Zugriff

Kombinieren Sie staerkere Authentifizierung mit Compliant-Device-Anforderungen und risikobasiertem Conditional Access, anstatt sich nur auf Authentifizierung zu verlassen. Hochwertige Apps sollten verwaltete oder konforme Geraete, Anmelde-Risikopruefungen und Step-Up-Auth fuer sensible Aktionen verlangen.

Behandeln Sie Passkeys und Security Keys als Standard-Ziel

Machen Sie Passkeys zur bevorzugten Methode und Security Keys zum starken Fallback fuer privilegierte oder Shared-Device-Szenarien. Fuer den vollstaendigen Registrierungsplan, Rollout-Modelle, Recovery-Design und Adoptionsmetriken siehe Enterprise Passkeys und Phishing-resistente MFA ausrollen.

Sie sollten nun eine priorisierte Authentifizierungs-Basislinie haben, die die Kosten von Phishing und Credential-Replay fuer die wichtigsten Konten erhoeht.

Schritt 3: Session-Diebstahl-Exposition reduzieren

Selbst starke Authentifizierung reicht nicht aus, wenn der Angreifer die resultierende Session stehlen oder wiedergeben kann. Microsofts Token-Theft-Playbook ist explizit: Ein Token-Theft-Angriff funktioniert, weil der Angreifer ein Token wiederverwendet, das an einen Benutzer ausgegeben wurde, der MFA bereits abgeschlossen hat. Microsofts Token-Protection-Leitfaden sagt auch, dass Token Protection Replay durch geraetegebundene Anmelde-Session-Token reduziert, obwohl die aktuelle Plattformunterstuetzung noch begrenzt ist und browserbasierte Anwendungen von dieser Kontrolle heute nicht unterstuetzt werden.

Verkuerzen Sie riskante Session-Lebensdauer wo angemessen

Verkuerzen Sie nicht jede Session blind, aber ueberpruefen Sie zuerst diese Faelle:

• Admin-Konsolen
• Finanz- und Gehalts-Apps
• Help-Desk- und Recovery-Tooling
• Sensible Dokumenten-Repositories
• E-Mail-Admin und Postfachverwaltung
• Benutzerdefinierte interne Admin-Apps

Eine einfache Session-Policy-Basislinie:

admin_apps:
  max_session_hours: 4
  sign_in_frequency_hours: 4
  require_reauth_for_sensitive_actions: true

finance_apps:
  max_session_hours: 8
  sign_in_frequency_hours: 8
  require_reauth_for_wire_or_payroll_changes: true

standard_apps:
  max_session_hours: 12
  sign_in_frequency_hours: 12
  require_reauth_for_profile_security_changes: true

Verlangen Sie erneute Authentifizierung fuer sensible Aktionen

Verlassen Sie sich nicht auf die urspruengliche Session fuer:

• MFA-Methoden-Aenderungen
• Passwort-Reset fuer einen anderen Benutzer
• Export grosser Datensaetze
• Zahlungsdetail-Aenderungen
• Posteingangsregel-Aenderungen
• Admin-Rollenzuweisung

Dies ist wichtig, weil moderne AiTM- und Token-Theft-Kampagnen oft in Persistenz umschwenken, indem sie MFA-Methoden aendern oder Kontowiederherstellungspfade hinzufuegen, nachdem die initiale Kompromittierung erfolgt ist. Microsofts AiTM-Fallstudie dokumentierte explizit Angreifer, die eine neue MFA-Methode nach dem Wiedergeben einer gestohlenen Session hinzufuegten, und empfahl, MFA-Re-Challenge fuer MFA-Updates zu verlangen.

Verwenden Sie Token Protection oder Binding, wo verfuegbar

Wenn Ihre Identitaetsplattform geraetegebundene Token oder Token Protection unterstuetzt, aktivieren Sie es zuerst fuer die Anwendungen und Geraete, die es tatsaechlich unterstuetzen. Microsoft dokumentiert Token Protection als Conditional-Access-Session-Kontrolle, die Replay reduziert, indem sichergestellt wird, dass nur geraetegebundene Anmelde-Session-Token akzeptiert werden, und empfiehlt, es zuerst mit einer Pilotgruppe und Report-Only-Validierung auszurollen.

Bereinigen Sie Browser- und Extension-Risiken

AiTM- und Session-Theft-Abwehr ist schwaecher, wenn Benutzer von nicht verwalteten Endpunkten voller riskanter Extensions browsen. Mindestens:

• Schraenken Sie Extension-Installationen fuer privilegierte Benutzer ein
• Blockieren Sie nicht verwaltete Browser von Admin-Apps
• Verlangen Sie sichere, unterstuetzte Browser fuer sensiblen Zugriff
• Ueberpruefen Sie Browser-Session-Persistenz-Einstellungen

{
  "ExtensionInstallBlocklist": ["*"],
  "ExtensionInstallAllowlist": [
    "aapocclcgogkmnckokdopfmhonfmgoek",
    "ghbmnnjooekpmoecnnnilnnbdlolhkhi"
  ],
  "PasswordManagerEnabled": false,
  "BrowserSignin": 0
}

Sie sollten nun weniger wertvolle Sessions fuer Angreifer, engeren Schutz gegen Session-Replay und weniger browserbasierte Exposition auf sensiblen Konten haben.

Schritt 4: AiTM- und Phishing-Workflows blockieren

AiTM-Angriffe sind erfolgreich, weil sie in normal aussehende Workflows passen: E-Mail-Link, vertrauenswuerdige Anbieternachricht, geklonte Login-Seite, MFA-Prompt, gestohlene Session, dann stilles Replay. Microsofts Kampagnen-Aufschreibung von 2023 zeigte genau dieses Muster, einschliesslich der Nutzung vertrauenswuerdiger Anbieter, legitimer Dienste als Koeder, gefaelschter Microsoft-Anmelde- und MFA-Seiten, Session-Cookie-Replay und nachfolgender BEC-Aktivitaet.

Staerken Sie E-Mail-Kontrollen fuer Identitaetsmissbrauch, nicht nur Malware

Stimmen Sie den E-Mail-Stack auf Folgendes ab:

• Anbieter- und Partner-Identitaetsmissbrauch
• Verdaechtige Login-thematisierte Koeder
• Missbrauch vertrauenswuerdiger Plattformen wie Cloud-Dateifreigaben
• Neu gesehene Domains und seltsame Redirect-Ketten
• Kampagnenkorrelation ueber mehrere Benutzer

Schuetzen Sie Login-Journeys

Fuer sensible Anwendungen und SSO-Pfade:

• Verwenden Sie nur Ihre offiziellen IdP-Domains
• Reduzieren Sie alternative Login-Oberflaechen
• Blockieren Sie direkte Legacy-Auth, wo moeglich
• Stellen Sie sicher, dass Benutzer auf die echte Anmeldeerfahrung trainiert sind
• Bevorzugen Sie origin-gebundene Phishing-resistente Methoden, damit gefaelschte Login-Seiten den Flow nicht erfolgreich abschliessen koennen

Aktualisieren Sie Benutzerschulung an aktuelle Angriffe

Bringen Sie Benutzern aktuelle Muster bei, nicht nur “suchen Sie nach Tippfehlern”:

• Gefaelschte MFA-Schritte auf einer geklonten Anmeldeseite
• “Oeffnen Sie dieses Dokument”-Links von echten Anbietern
• Passwort- + MFA-Erfassung, die zu stiller Kontoubernahme fuehrt
• Help-Desk- oder Support-Identitaetsmissbrauch nach Phishing
• Posteingangsregel-Missbrauch und Second-Stage-internes Phishing

Erkennen Sie ungewoehnliches MFA- und Session-Verhalten

Verlassen Sie sich nicht nur auf “unmoeliches Reisen.” Microsofts eigener AiTM-Leitfaden listet reichhaltigere Erkennungen auf wie verdaechtige Posteingangsmanipulation, unbekannte Anmeldeeigenschaften, anomale Token-Nutzung, moegliche AiTM-Phishing-Versuche und riskante Anmeldungen gefolgt von MFA-Aenderungen.

Sie sollten nun staerkere Kontrollen um die Phishing-Workflows haben, die typischerweise Session-Diebstahl und Token-Replay vorausgehen.

Schritt 5: Admin- und Support-Pfade absichern

Angreifer lieben Help-Desk- und Admin-Workflows, weil sie vertrauenswuerdig, dringend und oft unterdokumentiert sind. Wenn der Help Desk MFA nach einer schwachen Identitaetspruefung zuruecksetzen kann, ist Ihre ausgefeilte Login-Policy leicht zu umgehen.

Erstellen Sie einen echten Help-Desk-Verifikationsstandard

password_or_mfa_reset:
  allowed_identity_checks:
    - manager_callback_using_directory_number
    - verified_hr_attribute_plus_ticket_context
    - approved_video_or_in_person_check
  disallowed_identity_checks:
    - caller_knows_email_address
    - caller_knows_employee_id_only
    - incoming_phone_number_match_only
  extra_requirements:
    - second-analyst-approval_for_privileged_accounts
    - mandatory_case_notes
    - alert_to_user_after_reset

Isolieren Sie privilegierte Sessions

Fuer privilegierten Zugriff verwenden Sie:

• Dedizierte Admin-Konten
• Privileged Access Workstations oder isolierte Browser
• Kein taegliches E-Mail oder Web-Browsen aus Admin-Sessions
• Kuerzere Anmeldehaeufigkeit
• Staerkere Methodenanforderungen als normale Workforce-Konten

Fuegen Sie Step-Up-Anforderungen fuer Admin-Aenderungen hinzu

Verlangen Sie immer frische Authentifizierung fuer:

• Rollenaenderungen
• App-Registrierungsaenderungen
• Conditional-Access-Bearbeitungen
• Mail-Transport- und Postfachzugriffsaenderungen
• Foederations- und Identity-Provider-Einstellungen

Schuetzen Sie Break-Glass-Konten

Break-Glass-Konten sollten:

• Wenige an der Zahl sein
• Offline dokumentiert sein
• Nur dort ausgenommen sein, wo absolut notwendig
• Kontinuierlich ueberwacht werden
• Nicht fuer den taeglichen Betrieb verwendet werden

Sie sollten nun weniger leichte Umgehungen durch Support- und Admin-Workflows haben.

Schritt 6: Monitoring und Response hinzufuegen

Der Sinn des Monitorings ist nicht, mehr Anmeldeprotokolle zu sammeln. Es geht darum, Identitaetskompromittierung schnell genug zu erkennen, um Persistenz zu stoppen. Microsofts Token-Protection- und Token-Theft-Leitfaden betont aktives Monitoring, risikobasiertes Conditional Access, verdaechtige Anmeldeanalyse und schnelle Reaktion, weil Token-Replay und AiTM-Aktivitaet oft mehr als ein Passwort-Reset erfordern, um einzudaemmen.

Verwenden Sie Erkennungen, die besser sind als unmoeliches Reisen allein

Unmoeliches Reisen kann immer noch nuetzlich sein, aber es ist allein zu verrauscht. Bessere Erkennungen umfassen:

• Unbekannte Anmeldeeigenschaften
• Anmeldung von neuem Geraet plus neuem Netzwerk plus sensibler App
• Selber Benutzer von ungewoehnlicher IP- und User-Agent-Kombination
• MFA-Methode nach riskanter Anmeldung hinzugefuegt
• Neue Posteingangsregeln nach verdaechtiger Session-Aktivitaet
• Verdaechtige Token-Wiederverwendungsmuster
• Zugriff auf Mail und Dateien unmittelbar nach Login von ungewoehnlichen Eigenschaften

Beispiel KQL: MFA-Methode nach riskanter Anmeldung hinzugefuegt

let RiskyWindow = 4h;
let RiskySignins =
SigninLogs
| where TimeGenerated > ago(1d)
| where RiskLevelDuringSignIn in ("medium", "high")
| project UserPrincipalName, RiskySignInTime = TimeGenerated, IPAddress, UserAgent;
AuditLogs
| where TimeGenerated > ago(1d)
| where OperationName has_any ("Add authentication method", "Update user", "Register security info")
| extend TargetUser = tostring(TargetResources[0].userPrincipalName)
| join kind=inner RiskySignins on $left.TargetUser == $right.UserPrincipalName
| where TimeGenerated between (RiskySignInTime .. RiskySignInTime + RiskyWindow)
| project TimeGenerated, TargetUser, OperationName, IPAddress, UserAgent

Beispiel KQL: Verdaechtiges Session-Wiederverwendungsmuster

SigninLogs
| where TimeGenerated > ago(1d)
| summarize
    FirstSeen=min(TimeGenerated),
    LastSeen=max(TimeGenerated),
    IPs=make_set(IPAddress, 10),
    UserAgents=make_set(UserAgent, 10),
    Apps=make_set(AppDisplayName, 10)
  by UserPrincipalName
| where array_length(IPs) > 2 and array_length(UserAgents) > 1
| project UserPrincipalName, FirstSeen, LastSeen, IPs, UserAgents, Apps

Erstellen Sie ein Identity-Compromise-Response-Playbook

initial_actions:
  - revoke_active_sessions
  - block_sign_in_temporarily
  - require_password_reset_if_password_was_captured
  - investigate_mfa_method_changes
  - review_inbox_rules_and_forwarding
  - review_app_consent_and_tokens
  - review_recent_admin_actions

containment:
  - require_reauthentication_for_sensitive_apps
  - restrict_access_to_managed_devices_only
  - increase_sign_in_risk_enforcement

post_incident:
  - confirm_user_device_health
  - remove_attacker_added_mfa_methods
  - review_affected_contacts_for_follow_on_phishing
  - document_root_cause_and_detection_gaps

Microsofts AiTM-Leitfaden ist klar, dass ein Passwort-Reset allein nicht ausreicht, wenn der Angreifer eine Session stiehlt und MFA-Einstellungen aendert; Session-Widerruf und Ruecknahme von Angreifer-erstellten MFA-Aenderungen sind Teil der ordnungsgemaessen Behebung.

Sie sollten nun eine Monitoring-Basislinie und einen initialen Response-Flow fuer Identitaetskompromittierung haben, der ueber Passwort-Resets hinausgeht.

Schritt 7: Fuehren Sie ein Tabletop oder eine Simulation durch

Ein Tabletop ist der Ort, an dem Sie herausfinden, ob Ihre Kontrollen zusammenarbeiten oder nur auf Folien gut aussehen. Verwenden Sie Szenarien, die aktuelle Identity-First-Angriffsketten abbilden.

Szenario 1: Phishing zu Session-Diebstahl

# Scenario: Phishing to Session Theft

1. A finance user receives an email from a known vendor with a cloud-document link.
2. The link leads to a fake SSO login page and a fake MFA prompt.
3. The attacker captures the password, MFA challenge result, and session token.
4. Two hours later, the attacker replays the session from a new network.
5. The attacker creates inbox rules and tries to change payment details.

Questions:
- Which control should have blocked the initial sign-in?
- Which detections should fire after replay?
- Who revokes sessions?
- Who reviews inbox rules and outbound payment changes?

Szenario 2: Support-Identitaetsmissbrauch

# Scenario: Support Impersonation

1. An attacker calls the help desk posing as an executive traveling internationally.
2. They claim they lost their phone and cannot complete MFA.
3. They pressure support for a fast reset before a payroll deadline.
4. They ask to add a temporary recovery method.

Questions:
- What verification steps are mandatory?
- Can one analyst approve this alone?
- Is the user notified out-of-band?
- What extra control applies because the target is high risk?

Szenario 3: Gestohlener Token mit Persistenzversuch

# Scenario: Stolen Token with Persistence Attempt

1. A developer's session is replayed successfully.
2. The attacker creates a new OAuth app consent and tries to add an MFA method.
3. They access source repositories and CI/CD settings.

Questions:
- Which detections should fire first?
- What gets revoked?
- Which secrets and tokens must be reviewed?
- How do you determine whether code or pipeline changes occurred?

Bewerten Sie die Uebung

Verfolgen Sie:

• Zeit bis zur Erkennung
• Zeit bis zur Eindaemmung
• ob Sessions widerrufen wurden
• ob MFA-Aenderungen gefunden wurden
• ob die Help-Desk-Policy gehalten hat
• ob die Kommunikation klar war

Haeufige Einrichtungsprobleme

MFA verlangen, aber nicht Phishing-resistente MFA

Dies laesst Hochrisikobenutzer anfaellig fuer AiTM-Erfassung und Token-Replay, obwohl die Organisation glaubt “MFA ist an.”

Fokus auf Passwoerter, aber nicht auf Sessions

Teams setzen oft Passwoerter zurueck und hoeren dort auf, obwohl der Angreifer moeglicherweise bereits eine gueltige Session, einen Refresh-Pfad oder eine vom Angreifer hinzugefuegte MFA-Methode hat.

Alle Benutzer gleich behandeln

Identity-First-Haertung funktioniert am besten, wenn Sie Admins, Help Desk, Finanzen, Entwickler und Drittanbieter-Zugriff zuerst priorisieren.

Unmoeliches Reisen als Haupterkennung verwenden

Unmoeliches Reisen hilft, aber es uebersieht zu viel und erzeugt zu viel Rauschen, um das einzige Identity-Compromise-Signal zu sein.

Support- und Recovery-Workflows schwach lassen

Eine starke Front-Door-Anmelde-Policy kann immer noch durch schwaches MFA-Reset, Kontowiederherstellung oder Break-Glass-Handling umgangen werden.

Zusammenfassung

Identity-First-Angriffe funktionieren, weil sie bereits bestehendes Vertrauen missbrauchen: vertrauenswuerdige Benutzer, vertrauenswuerdige Geraete, vertrauenswuerdige Sessions, vertrauenswuerdige Anbieter und vertrauenswuerdige Support-Prozesse. Branchenweite Bedrohungsberichte beschreiben diese breitere Verschiebung als Angreifer, die fuer “Einloggen” und hoeherwertigen vertrauenswuerdigen Zugriff optimieren, waehrend Microsofts Token-Theft-Leitfaden zeigt, warum ein wiedergegebenes Token Verteidigungen besiegen kann, die bei der initialen MFA aufhoeren.

Wenn die Ressourcen begrenzt sind, verbessern Sie diese zuerst: Verlangen Sie Phishing-resistente Methoden fuer privilegierte Benutzer, erzwingen Sie staerkere Kontrollen fuer sensible Apps, verlangen Sie erneute Authentifizierung fuer Kontosicherheitsaenderungen, haerten Sie die Help-Desk-Verifizierung und deployen Sie ein Response-Playbook, das Sessions widerruft und nach Angreifer-hinzugefuegter Persistenz prueft. Im Laufe der Zeit ist das Reifeziel einfach: weniger phishbare Methoden, weniger langlebige maechtige Sessions, weniger nicht verwaltete Pfade zu sensiblen Apps und schnellere Reaktion, wenn eine Identitaet missbraucht wird.

Fuer eine detaillierte Anleitung zum Deployment von Phishing-resistenter Authentifizierung in Ihrer Belegschaft, siehe Enterprise Passkeys und Phishing-resistente MFA ausrollen. Fuer mehr ueber die identitaetsbasierten Ransomware-Trends, die diese Verteidigungen antreiben, siehe Identity-Based Ransomware.