Hallo zusammen, Pat Reeves hier, zurück auf botsec.net. Es ist März 2026, und wenn es euch wie mir geht, seid ihr wahrscheinlich immer noch erstaunt über die schiere Dreistigkeit mancher Botnet-Aktivitäten, die wir im letzten Jahr gesehen haben. Während die großen Schlagzeilen sich auf die DDoS-Angriffe und Datenexfiltration konzentrierten, hat sich etwas anderes leise unter der Oberfläche entwickelt, etwas, das mich ehrlicherweise nachts wach hält: die zunehmend ausgeklügelten Taktiken, die Bots einsetzen, um traditionelle Authentifizierungsmethoden zu umgehen, insbesondere mit dem Aufstieg der Passkeys.
Uns wurde gesagt, dass Passkeys die Zukunft sind, oder? Phishing-resistent, kryptografisch sicher, gerätegebunden. Und das aus gutem Grund, sie beheben viele alte Schmerzpunkte. Aber was passiert, wenn der Mechanismus, der zu unserem Schutz entwickelt wurde, zu einem Vektor für Kompromittierung wird, nicht durch einen Fehler in der Kryptographie selbst, sondern durch die Art und Weise, wie er implementiert ist und, was entscheidend ist, wie Bots lernen, das menschliche Element darum zu manipulieren?
Das Passkey-Paradoxon: Eine neue Bot-Front
Denkt mal darüber nach. Das Versprechen der Passkeys ist, dass sie gemeinsame Geheimnisse (Passwörter) eliminieren und Interaktion des Benutzers auf einem vertrauenswürdigen Gerät erfordern. Super! Kein Credential Stuffing mehr, kein Spraying mehr, keine einfachen Wörterbuchangriffe mehr. Aber Bots, segne ihre hartnäckigen kleinen digitalen Herzen, geben nicht einfach auf. Sie passen sich an. Und was ich besonders bei Kontoübernahmen (ATO) auf Plattformen gesehen habe, die Passkeys vollständig angenommen haben, ist ein Trend hin zu Social Engineering in großem Stil, gefördert durch Automatisierung.
Meine eigene jüngste Erfahrung mit einem Kunden, einer mittelgroßen E-Commerce-Plattform, die letzten Sommer komplett auf Passkeys gesetzt hat, hat mir wirklich die Augen geöffnet. Sie erlebten einen massiven Rückgang der traditionellen, an Credentials basierten Angriffe, was fantastisch war. Aber dann, vor etwa drei Monaten, begannen sie, einen Anstieg bei „fehlgeschlagenen Anmeldeversuchen“ zu bemerken, die… anders waren. Diese waren keine Passwortfehler; das waren Versuche, die Passkey-Registrierung oder -Wiederherstellung von unrecognized devices zu initiieren, oft gefolgt von einem Fluss von Supportanfragen von legitimen Benutzern, die behaupteten, ihre Konten seien „gehackt“ worden, obwohl Passkeys aktiviert waren.
Was wir aufdeckten, war ein mehrstufiger Angriff. Bots versuchten nicht, Passkeys zu erraten; sie versuchten, Benutzer dazu zu bringen, neue Passkeys auf von Angreifern kontrollierten Geräten *zu generieren* oder *zu genehmigen*, oder sie dazu zu drängen, vorhandene Passkeys zurückzusetzen. Es ist eine Wendung der alten „genehmige diese Anmeldung“-MFA-Müdigkeit, aber mit höheren Einsätzen, denn ein kompromittierter Passkey bedeutet vollständige Kontrolle über das Konto.
Bot-gesteuerte Passkey-Entführungen: So funktioniert es
Lass uns das neue Bot-Playbook für die Kompromittierung von Passkeys aufschlüsseln. Es geht nicht um brute-forcing. Es geht um ausgeklügeltes Social Engineering im großen Stil, verstärkt durch Automatisierung.
- Aufklärung und Spear-Phishing Lite: Bots durchsuchen öffentliche Daten, Social Media und sogar Dark-Web-Dumps nach E-Mail-Adressen und Telefonnummern. Dann überprüfen sie diese mit Zielplattformen. Das Ziel ist nicht, ein Passwort zu erhalten, sondern aktive Benutzer zu identifizieren.
- Die „Neues Gerät“-Lockmittel: Ein Bot, der oft einen legitimen Browser oder eine mobile App nachahmt, versucht, eine Anmeldung oder Passkey-Registrierung für einen bekannten Benutzer auf der Zielplattform zu initiieren. Da der Benutzer auf diesem speziellen Gerät (der simulierten Umgebung des Bots) keinen registrierten Passkey hat, fordert die Plattform oft eine alternative Verifizierungsmethode oder dazu auf, „einen neuen Passkey hinzuzufügen“.
- Automatisiertes Social Engineering (ASE): Hier passiert die Magie (oder vielmehr, die Bedrohung). Der Bot, der eine legitime Systembenachrichtigung ausgelöst hat (E-Mail, SMS, Push-Benachrichtigung von der App selbst), folgt dann sofort mit einem gezielten Phishing-Versuch auf. Dies ist keine generische „setzen Sie Ihr Passwort zurück“-E-Mail. Sie ist stark kontextualisiert.
Stellt euch folgendes Szenario vor:
- Ihr bekommt eine legitime Push-Benachrichtigung von eurer Banking-App: „Neuer Passkey-Registrierungsversuch von einem unbekannten Gerät erkannt. Wenn das ihr wart, genehmigt. Wenn nicht, klickt hier, um euer Konto zu sichern.“
- Gleichzeitig erhaltet ihr eine sorgfältig gestaltete E-Mail, scheinbar von dem Sicherheitsteam eurer Bank, mit einem Betreff wie: „Dringend: Ungenehmigte Passkey-Registrierung erkannt – Aktion erforderlich.“
- Der Inhalt der E-Mail ist maßgeschneidert, möglicherweise wird sogar die spezifische Uhrzeit des versuchten Registrierung erwähnt. Sie leitet euch zu einer Phishing-Seite, die identisch mit dem Sicherheitsportal eurer Bank aussieht.
- Auf dieser Phishing-Seite werdet ihr aufgefordert, eure Identität zu „überprüfen“, indem ihr euer altes Passwort eingebt (wenn die Bank es noch zur Wiederherstellung unterstützt), oder, heimtückischer, „ungenutzte Passkeys zu widerrufen“, was euch tatsächlich dazu auffordert, *einen neuen Passkey* auf dem Gerät des Angreifers zu *registrieren*, das als Sicherheitsmaßnahme getarnt ist.
Der Schlüssel hier ist das *Timing* und der *Kontext*. Bots koordinieren diese Aktionen im großen Stil und treffen Tausende von Benutzern gleichzeitig. Der Benutzer, der eine legitime Benachrichtigung von der App und eine sehr überzeugende, zeitnahe E-Mail sieht, ist viel wahrscheinlicher, darauf hereinzufallen als auf einen generischen Phishing-Betrug.
Praktische Verteidigungsstrategien gegen bot-gesteuerten Passkey-Missbrauch
Also, was können wir tun? Wir können Passkeys nicht abschaffen; sie sind nach wie vor ein massiver Fortschritt. Aber wir müssen klüger darin werden, wie wir sie bereitstellen und schützen. Hier sind ein paar Dinge, bei denen ich meinen Kunden geraten habe, mit einigen praktischen Beispielen.
1. Stärken Sie Ihren „Neue Passkey“-Registrierungsablauf
Dies ist die kritischste Schwachstelle. Wenn ein Angreifer einen Benutzer dazu bringen kann, einen neuen Passkey auf seinem Gerät zu registrieren, ist es vorbei. Hier benötigt man mehrere Verifizierungsschichten, über die ursprüngliche Passkey-Aufforderung hinaus.
- Obligatorischer zweiter Faktor für neue Registrierungen: Selbst wenn ein Benutzer bereits angemeldet ist, ist es wichtig, eine zusätzliche, out-of-band-Verifizierung (wie einen einmaligen Code, der an eine *vorregistrierte* Telefonnummer oder E-Mail gesendet wird, nicht eine, die während des Registrierungsversuchs angegeben wurde) für *jede* neue Passkey-Registrierung oder Ersetzung zu verlangen.
- Geräteattestation (wo möglich): Auch wenn es nicht narrensicher ist, kann die Integration von Geräteattestierungsprüfungen während der Passkey-Registrierung helfen, offensichtliche virtuelle Maschinen oder Emulatoren herauszufiltern, die Bots möglicherweise verwenden. Es geht nicht darum, legitime Benutzer zu blockieren, sondern darum, Reibung für bekannte Angreiferumgebungen hinzuzufügen.
- Rate Limiting und Anomalieerkennung: Dies ist klassische Bot-Verteidigung, aber es gilt hier umso mehr. Aggressives Rate Limiting bei Passkey-Registrierungsversuchen von einzelnen IPs oder IP-Bereichen, gekoppelt mit Verhalten-anomalieerkennung (z. B. ein Benutzer, der plötzlich versucht, 5 neue Passkeys innerhalb einer Stunde von unterschiedlichen geografischen Standorten zu registrieren), kann verdächtige Aktivitäten kennzeichnen.
// Beispiel: Pseudocode für einen soliden neuen Passkey-Registrierungsablauf
function registerNewPasskey(userId, webauthnCredential) {
// 1. Überprüfen der bestehenden Sitzung und Authentifizierungsstärke
if (!isAuthenticatedStrongly(userId)) {
// Zurück zur erneuten Authentifizierung oder zusätzliche MFA zwingen
initiateMFAChallenge(userId, "new_passkey_registration");
return; // Warten auf MFA-Abschluss
}
// 2. FIDO2 Attestation Validierung durchführen
if (!validateWebAuthnAttestation(webauthnCredential)) {
logSecurityAlert(userId, "Ungültige WebAuthn-Attestation während der neuen Passkey-Registrierung");
return;
}
// 3. Optional: Gerätefingerabdruck/Attestierungsprüfung (serverseitig)
if (isSuspiciousDeviceFingerprint(request.headers['User-Agent'], request.ip)) {
logSecurityAlert(userId, "Verdächtiger Gerätefingerabdruck für die neue Passkey-Registrierung");
initiateMFAChallenge(userId, "suspicious_device_new_passkey");
return;
}
// 4. Rate limit check für neue Passkeys pro Benutzer/IP
if (rateLimitExceeded("new_passkey_registration", userId, request.ip)) {
logSecurityAlert(userId, "Rate Limit überschritten für neue Passkey-Registrierung");
return;
}
// 5. Den neuen Passkey-Credential speichern
storeUserPasskey(userId, webauthnCredential);
sendUserNotification(userId, "Neuer Passkey erfolgreich registriert.");
}
2. Verbessern Sie die Wiederherstellungsprozesse für Konten
Die Kontowiederherstellung ist ein weiteres Hauptziel. Wenn ein Angreifer einen Wiederherstellungsablauf initiieren und dann den Benutzer durch Social Engineering dazu bringen kann, ihn zu genehmigen, hat er einen Hintertür.
- Verzögern Sie die Kontowiederherstellung: Implementieren Sie eine verpflichtende Wartezeit (z. B. 24-48 Stunden) für kritische Kontowiederherstellungsaktionen, insbesondere für solche, die das Ersetzen aller bestehenden Passkeys betreffen. Während dieser Zeit sollte der Benutzer aggressiv über alle bekannten Kommunikationskanäle informiert werden. Dies gibt dem legitimen Benutzer die Chance, einzugreifen.
- Video KYC oder Live-Agentenverifizierung für vollständige Rücksetzung: Für Situationen, in denen ein Benutzer alle Passkeys verloren hat und andere Wiederherstellungsmethoden nicht funktionieren, sollten Sie eine Live-Video-Verifizierung mit einem Support-Agenten verlangen. Es ist eine hochgradig reibungslose Lösung, aber für kritische Konten ist es ein starker Abschreckungsfaktor gegen automatisiertes Social Engineering.
- “Breaking Glass”-Passkeys: Für interne Administrator-Konten oder hochsensible Systeme sollten Sie einen physischen „Breaking Glass“-Passkey in einem sicheren, überprüften Ort haben, der mehrere Genehmigungen zur Nutzung erfordert. Dies ist nicht für Verbraucher-Konten gedacht, sondern für hochgradige Ziele ein Muss.
3. Benutzerbildung, die tatsächlich funktioniert
Wir haben seit Jahrzehnten „Benutzerbildung“ gemacht, und ehrlich gesagt, der Großteil davon schlägt fehl. Für Passkeys benötigen wir gezielte, zeitnahe und spezifische Anleitung.
- “Was Sie Erwarten Können” Leitfäden: Erklären Sie den Nutzern klar, wie legitime Sicherheitsbenachrichtigungen und Wiederherstellungsprozesse aussehen. Zeigen Sie Screenshots.
- “Was NICHT zu tun” Warnungen: Warnen Sie die Nutzer ausdrücklich davor, Passkey-Registrierungen zu genehmigen, die sie nicht initiiert haben, oder Links in E-Mails zu klicken, die behaupten, Passkeys “zu widerrufen”, insbesondere wenn sie nicht selbst zuvor eine Sicherheitsaktion versucht haben.
- Sicherheitsschecks in der App: Bieten Sie einen leicht auffindbaren Abschnitt in Ihrer App oder auf Ihrer Website, in dem Nutzer alle registrierten Passkeys, deren Ursprung (wenn möglich) und die Möglichkeit, diese zu widerrufen, einsehen können. Gestalten Sie es einfach und intuitiv.
// Beispiel: In-App-Aufforderung bei verdächtigen Aktivitäten
function displaySuspiciousActivityWarning(userId, activityDetails) {
const warningMessage = `
⚠ Verdächtige Aktivitäten erkannt!
Wir haben einen Versuch festgestellt, einen neuen Passkey für Ihr Konto von einem nicht erkannten Gerät (${activityDetails.ipAddress} - ${activityDetails.location}) am ${activityDetails.timestamp} zu registrieren.
Wenn Sie das waren, können Sie dies sicher ignorieren. Wenn das NICHT Sie waren, ergreifen Sie bitte sofort Maßnahmen:
- Gehen Sie zu Ihren Sicherheitseinstellungen, um Passkeys zu überprüfen und zu widerrufen.
- Ändern Sie Ihre anderen Wiederherstellungsmethoden (z. B. E-Mail-Passwort).
- Kontaktieren Sie den Support, wenn Sie Hilfe benötigen.
`;
document.getElementById('security-alert-banner').innerHTML = warningMessage;
document.getElementById('security-alert-banner').style.display = 'block';
}
Diese Art von direkter, in-App-Warnung, die durch dieselbe Bot-Aktivität ausgelöst wird, gegen die wir uns verteidigen wollen, kann äußerst effektiv sein.
Handlungsfähige Erkenntnisse für Bot-Sicherheitsexperten
Der Bereich der Bot-Angriffe verändert sich ständig. Passkeys sind großartig, aber sie sind kein Allheilmittel, und Angreifer finden bereits neue Wege, um das menschliche Element auszunutzen. Hier ist meine Checkliste für Sie:
- Überprüfen Sie Ihre Passkey-Workflows: Gehen Sie jeden einzelnen Passkey-bezogenen Workflow – Registrierung, Anmeldung, Wiederherstellung, Widerruf – mit der Denkweise eines Bot-Angreifers durch. Wo kann ein Bot soziale Ingenieurarbeit leisten?
- Schichtungsverifikation ist der Schlüssel: Verlassen Sie sich niemals auf einen einzelnen Faktor für hochwirksame Aktionen wie die Registrierung eines neuen Passkeys oder die vollständige Wiederherstellung des Kontos. Fügen Sie eine MFA außerhalb des Bandes hinzu.
- Bildung, nicht nur Information: Gestalten Sie die Nutzerbildung proaktiv, hoch spezifisch auf Passkey-Bedrohungen und direkt in die Sicherheitsfunktionen Ihrer Anwendung integriert.
- Überwachen Sie Anomalien: Achten Sie genau auf Ihre Protokolle, um ungewöhnliche Muster bei Passkey-Registrierungsversuchen, Wiederherstellungsanfragen und Support-Tickets in Bezug auf diese zu erkennen. Bots arbeiten in großem Umfang, und diese Muster werden sichtbar werden.
- Vergessen Sie die Grundlagen nicht: Während Sie sich auf Passkeys konzentrieren, vernachlässigen Sie nicht Ihre grundlegenden Bot-Abwehrmaßnahmen für andere Teile Ihrer Anwendung: starke Ratenbegrenzung, IP-Reputation, Verhaltensanalyse und CAPTCHAs, wo angemessen. Bots entwickeln sich weiter, aber sie hinterlassen immer noch Spuren.
Die Zukunft der Authentifizierung ist stark, aber nur wenn wir voraussehen, wie böse Akteure versuchen werden, sie zu untergraben. Bleiben Sie wachsam, bleiben Sie sicher, und wir sehen uns das nächste Mal hier auf botsec.net.
Verwandte Artikel
- AI Bot Datenschutzschutz
- Meine Meinung: OmniMind AI ist ein Sicherheitsalbtraum
- AI-Sicherheitsnachrichten heute: Dringende Updates & Experteneinsichten
🕒 Published: