Wie Push‑basierte 2FA umgangen wird — Angriffe und Schutzmaßnahmen

Wichtiger Hinweis: Akzeptiere niemals ungefragte Genehmigungsanfragen. Solche Anfragen bedeuten meist, dass dein Passwort kompromittiert wurde.

Einleitung

Push‑basierte 2FA (auch „Prompt‑2FA“ oder „Push Notifications“ zur Verifikation) bietet eine bequeme zweite Authentifizierungsschicht. Im Vergleich zu SMS‑Codes reduziert sie Risikoquellen wie SMS‑Hijacking. Dennoch ist sie nicht unfehlbar: Angreifer kombinieren gestohlene Passwörter, Social Engineering und Geräte‑Malware, um Push‑Anfragen zu genehmigen. Dieser Artikel ist praxisorientiert: verständliche Begriffe, klare Erkennungsmerkmale, Handlungsanweisungen für Nutzer und Administratoren sowie ein kurzes Incident‑Playbook.

Begriffe in einer Zeile

• Push‑2FA: Eine App sendet eine Bestätigungsanfrage an dein Gerät, statt SMS‑Codes zu verwenden.
• MFA‑Fatigue: Dauerhafte Push‑Anfragen, bis der Nutzer aus Ermüdung zustimmt.
• SIM‑Swap: Angreifer übernehmen deine Rufnummer beim Mobilfunkanbieter.
• Overlay: Schadsoftware zeigt gefälschte Bildschirme über legitime Apps.
• Passkey / Hardware‑Key: Stärkere Alternativen zu Push‑2FA (z. B. FIDO2‑Schlüssel).

1. MFA‑Fatigue Attack (Ermüdungsangriff)

Beschreibung Die Angreifer kennen bereits das Passwort und schicken wiederholt Push‑Benachrichtigungen an das 2FA‑Gerät. Ziel: den Nutzer so lange irritieren, bis er versehentlich zustimmt, um die Mitteilungen zu stoppen.

Erkennungsmerkmale

• Plötzlich wiederholte Push‑Anfragen ohne eigenen Loginversuch.
• Anfragen in ungewöhnlichen Intervallen oder zur falschen Tageszeit.
• Mehrere Anfragen nacheinander mit leicht veränderten Texten.

Prävention (Nutzer)

• Niemals ungefragte Anfragen bestätigen.
• Sofortiges Zurücksetzen des Passworts bei unaufgeforderten Anfragen.
• Aktivieren von „Nur Anfragen mit Nummern“ oder anderen bestätigenden Attributen, falls App es unterstützt.
• Starke, einzigartige Passwörter und Passwortmanager verwenden.

Prävention (Organisation)

• Ratenbegrenzung für Push‑Anfragen serverseitig.
• Verdächtige Anmeldeversuche blockieren und Sicherheits‑Eskalation anstoßen.
• Schulungen zu MFA‑Fatigue in Awareness‑Programmen.

Wann das Gegenmittel fehlschlägt Eine nummernbasierte Bestätigung (z. B. „Wählen Sie 1 von 3“) kann den Angriff erschweren, ist aber nicht narrensicher — Nutzer können trotzdem die richtige Zahl wählen.

Sofortmaßnahmen

• Passwort ändern und aktive Sessions beenden.
• Gerät auf kompromittierende Apps prüfen.

2. Social‑Engineering‑Push‑Prompts

Beschreibung Angreifer kontaktieren das Opfer (Telefonanruf, SMS, Chat) und geben vor, Mitarbeiter des Unternehmens zu sein. Sie bitten darum, die Push‑Anfrage zu bestätigen mit dem Vorwand „Verifizierung“ oder „Support‑Test“. Meist haben sie bereits das Passwort.

Erkennungsmerkmale

• Anrufe oder Nachrichten mit konkreter Aufforderung zur Bestätigung.
• Dringlichkeit („Sofort bestätigen, sonst sperren wir Ihr Konto“).
• Der Anrufer fordert niemals Zugangsdaten, fordert aber zur Bestätigung auf.

Prävention

• Richtlinie: Support/Mitarbeiter fordern niemals Passwort, TOTP oder Zustimmung zu Push‑Anfragen an.
• Schulungen mit Rollenspielen: wie eine echte Support‑Interaktion aussieht.
• Implementiere kontrollierte Support‑Flows (z. B. Rückruf an eine bekannte Nummer).

Gegenbeispiel — wann Social‑Engineering scheitert Wenn Nutzer genau wissen, dass Support niemals nach Zustimmung fragt, wird der Angriff meist abgewehrt.

3. SMS‑Fallback‑Exploit

Beschreibung Manche Dienste erlauben Push‑2FA, behalten aber SMS als Fallback. Ein Angreifer wechselt zur SMS‑Option (oder nutzt sie automatisch) und nutzt bekannte SMS‑Angriffe wie SIM‑Swap oder Nummernrecycling.

Erkennungsmerkmale

• Plötzliches Anmelden über SMS‑Code oder Benachrichtigung „Neue Rufnummer registriert“.
• Benachrichtigungen vom Mobilfunkanbieter über SIM‑Änderung.

Prävention

• SMS als 2FA‑Fallback deaktivieren, wenn möglich.
• Rufnummer nur dann angeben, wenn zwingend notwendig.
• Mobilfunkanbieter über Sicherheitsmaßnahmen informieren (PIN/Passwort für Rufnummeränderungen).

Organisationsempfehlung

• Konten mit sensiblen Rechten: erzwinge starke 2FA‑Methoden (Passkeys, Hardware‑Tokens) und deaktiviere SMS komplett.

4. Automatische Genehmigung durch infiziertes Gerät

Beschreibung Malware mit hohen Berechtigungen (z. B. Accessibility, Geräteadministrator) kann Bildschirminhalte lesen und Eingaben simulieren, sodass sie Push‑Anfragen automatisch bestätigen.

Erkennungsmerkmale

• Unerklärliche Logins von neuem Gerät ohne Nutzerbestätigung.
• Ungewöhnliche App‑Berechtigungen oder unbekannte Apps mit Accessibility‑Rechten.

Prävention

• Biometrische Bestätigung für Push‑Zustimmung aktivieren (wenn verfügbar).
• Gerätehygiene: Apps nur aus offiziellen Stores, Sideloading vermeiden.
• Regelmäßige Prüfungen installierter Apps und Berechtigungen.

Erkennung & Reaktion

• MDM/EMM‑Lösungen nutzen, um App‑Berechtigungen zu überwachen.
• Wenn Infektion vermutet: Gerät isolieren, Backup löschen/überprüfen, Werkseinstellungen und Neuinstallation aus vertrauenswürdiger Quelle.

5. Fake‑Overlay‑Attacke

Beschreibung Schadsoftware legt eine gefälschte Oberfläche (Overlay) über die echte 2FA‑App, zeigt einen harmlosen Dialog (z. B. „App‑Update erforderlich“) und trickst den Benutzer zu einer Aktion, die tatsächlich die Zustimmung zur Anmeldung bewirkt.

Erkennungsmerkmale

• Plötzliche „System‑Dialoge“ in Momenten, in denen du nichts getan hast.
• Dialoge, die untypische Formulierungen oder Rechtschreibfehler enthalten.

Prävention

• Keine Apps mit unnötigen Overlay‑Rechten erlauben.
• Regelmäßige Malware‑Scans und App‑Audit durch Security‑Tools.
• Benutzer auf typische Overlay‑Tricks sensibilisieren.

Sofortmaßnahmen bei Verdacht auf Overlay

• Gerät sperren und Verbindungen trennen (Flugmodus).
• Support kontaktieren, Passwort ändern und Sessions beenden.

Alternativen und strategische Empfehlungen

Kurzfassung der stärkeren Methoden

• Passkeys (FIDO2): Phishing‑resistent und benutzerfreundlich.
• Hardware‑Tokens (z. B. YubiKey): Sehr hohe Sicherheit, gut für Admin‑Konten.
• TOTP‑Apps auf dediziertem, gesicherten Gerät: Besser als SMS, aber anfällig bei Gerätekompromittierung.

Wann Push‑2FA weiterhin sinnvoll ist

• Für große Nutzerbasen mit begrenzter Hardwareausstattung bietet Push‑2FA ein gutes Usability‑/Sicherheits‑Verhältnis.
• Kombination: Push‑2FA plus Risikobasierte Authentifizierung (z. B. zusätzliche Hürde bei neuen Geräten).

Risiko‑Matrix (qualitativ)

• Niedrig: Nutzerfehler durch Unwissenheit — Mit Schulung senkbar.
• Mittel: Social Engineering — Mit Prozessen & Awareness handhabbar.
• Hoch: Geräte‑Malware / SIM‑Swap — Technische Kontrollen und starke 2FA erforderlich.

Empfohlene Gegenmaßnahmen (priorisiert)

1. Deaktiviere SMS‑Fallback für kritische Konten.
2. Setze Passkeys/Hardware‑Keys für Administratoren.
3. Implementiere serverseitige Ratenbegrenzung für Push‑Anfragen.
4. Schulungen und klare Support‑Richtlinien.

Rollenbasierte Checklisten

Nutzer

• Niemals ungefragte Anfragen bestätigen.
• Passwort sofort ändern bei verdächtigen Anfragen.
• Biometrie aktivieren, Apps aus offiziellen Stores.

Helpdesk / Support

• Rückruftest: Anrufe nur an gespeicherte Nummern bestätigen.
• Nie Nutzer auffordern, eine Push‑Anfrage zur Legitimation zu bestätigen.

IT‑/Security‑Team

• MFA‑Einstellungen zentral verwalten; SMS‑Fallback abschalten.
• Monitoring für ungewöhnliche Anmelde‑/MFA‑Muster einrichten.
• Incident‑Runbook pflegen und regelmäßig testen.

Incident‑Runbook: Wenn eine Push‑Anfrage fälschlich akzeptiert wurde

1. Sofort: Konto sperren oder Sitzung terminieren.
2. Passwort zurücksetzen und Multi‑Factor‑Methoden zurücksetzen.
3. Prüfen: Letzte Login‑IP/Standort und Gerätelisten kontrollieren.
4. Für betroffene Geräte: Malware‑Scan, bei Bedarf Zurücksetzen auf Werkseinstellungen.
5. Kommunikationsplan: Betroffene informieren, ggf. Recht/Compliance benachrichtigen.
6. Lessons Learned: Ursache analysieren, Maßnahmen zur Wiederholung verhindern.

Entscheidungsbaum: Soll ich eine Push‑Anfrage genehmigen?

flowchart TD
  A[Push‑Anfrage erhalten] --> B{Habe ich mich gerade angemeldet?}
  B -- Ja --> C{Erkenne ich das Gerät und den Ort?}
  B -- Nein --> X[NEIN: Anfrage ablehnen und Passwort ändern]
  C -- Nein --> X
  C -- Ja --> D{Wurde ich vom Support direkt kontaktiert?}
  D -- Ja --> E[Support prüfen: Rückruf an bekannte Nummer]
  D -- Nein --> F[Genehmigen nur wenn sicher, sonst ablehnen]

Datenschutz‑Hinweis (GDPR / DSGVO)

• Minimiert die Speicherung von Rufnummern und 2FA‑Metadaten, wenn nicht zwingend erforderlich.
• Informiert Nutzer transparent über Backup‑Methoden (z. B. SMS) und deren Risiken.

1‑Zeilen Glossar

• Push‑2FA: Bestätigung per App‑Benachrichtigung auf deinem Gerät.
• SIM‑Swap: Übernahme der Mobilfunknummer durch Dritte.
• Overlay: Gefälschte Bildschirme, die echte Dialoge überlagern.

Zusammenfassung — Was zu tun ist

• Akzeptiere niemals ungefragte Push‑Anfragen.
• Deaktiviere SMS‑Fallback dort, wo möglich.
• Nutze Passkeys oder Hardware‑Token für sensible Konten.
• Halte Geräte sauber: keine Sideload‑Apps, beschränke Berechtigungen.
• Schulen: Support darf nie zur Zustimmung bei 2FA auffordern.

Wichtig: Push‑2FA bleibt eine gute Balance aus Sicherheit und Usability. Mit den beschriebenen technischen Kontrollen, klaren Prozessen und regelmäßiger Sensibilisierung lässt sich das Risiko deutlich senken.

Quellenhinweis: Dieser Leitfaden fasst allgemein bekannte Angriffsvektoren und Best‑Practices zusammen, ohne konkrete Vorfälle zu behaupten oder statistische Angaben zu erfinden.