Quishing-Simulator: Sichere QR-Phishing-Tests auswerten
Ein Leitfaden für Käufer zu kontrollierten QR-Zielen, mobilgerichten Telemetriedaten, Berichtsworkflows, Datenschutz und messbarem Lernen.

Ein Quishing-Simulator sollte Sicherheitsteams ermöglichen, zu testen, wie Mitarbeiter mit QR-Code-Aufforderungen umgehen, ohne dabei Anmeldedaten zu erfassen, Nutzer unkontrollierten Zielen auszusetzen oder die Übung auf eine reine Scan-Zählung zu reduzieren. Die richtige Plattform kombiniert sichere Weiterleitungen, mobiloptimierte Ereignisdaten, Berichtsfunktionen, Datenschutzkontrollen und sofortiges Lernen. Käufer sollten diesen gesamten Workflow bewerten – und nicht nur, ob ein Tool einen QR-Code generieren kann.
QR-Code-Phishing, oft als „Quishing“ bezeichnet, verändert die Testherausforderung. Ein Code kann einen Mitarbeiter von einem verwalteten Laptop auf sein privates Smartphone leiten, das Ziel erst nach dem Scannen offenbaren und in E-Mails, Dokumenten, Plakaten oder Service-Desk-Workflows auftauchen. Das macht herkömmliche Kontrollen für E-Mail-Simulationen zwar notwendig, aber nicht ausreichend.
Warum ein Quishing-Simulator andere Kontrollen benötigt
Herkömmliche Phishing-Simulationen beobachten in der Regel Ereignisse innerhalb eines Kanals: Zustellung, Öffnen, Klicken, Melden und Abschluss der Schulung. QR-Tests können geräte- und Vertrauensgrenzen überschreiten. Der Mitarbeiter sieht den Code vielleicht auf einem Unternehmensbildschirm, scannt ihn mit seinem privaten Smartphone, öffnet das Ziel in einem mobilen Browser und meldet die ursprüngliche Nachricht von einem anderen Gerät aus.
Ein glaubwürdiger Simulator muss daher vier Fragen beantworten:
- Wurde das QR-Ziel während des gesamten Tests kontrolliert?
- Welche aussagekräftigen Aktionen kann die Plattform ohne invasive Geräteverfolgung messen?
- Können Mitarbeiter verdächtige QR-Aufforderungen über einen vertrauten, erprobten Workflow melden?
- Können Sicherheitsteams die Ergebnisse in gezielte Lernmaßnahmen umsetzen, ohne sensible Daten zu speichern?
Wenn ein Anbieter diese Grenzen nicht klar erklären kann, schafft die Übung möglicherweise mehr Unsicherheit als Beweise.
Sieben Funktionen zum Vergleich
1. Kontrollierte Zielseiten ohne Erfassung von Anmeldedaten
Jeder simulierte Code sollte zu einer Infrastruktur führen, die das Unternehmen genehmigt hat. Das Ziel sollte HTTPS verwenden, Werbung oder Analysen von Drittanbietern vermeiden und den Nutzer niemals auffordern, ein echtes Passwort, einen MFA-Code, Zahlungsdaten oder andere geheime Informationen anzugeben.
Frag nach, ob die Plattform eine eigene Schulungsdomain nutzen kann, nach der gemessenen Aktion einen klaren Hinweis auf die Simulation anzeigt und frei wählbare Weiterleitungen zu beliebigen externen Seiten deaktiviert. Überprüfe außerdem, was passiert, wenn eine Kampagne abläuft: Alte, ausgedruckte Codes sollten zu einer harmlosen Seite führen und nicht zu einem verlassenen oder wiederverwendbaren Ziel.
2. Eine für Mobilgeräte geeignete Lernerfahrung
Der lehrreiche Moment findet oft auf einem Smartphone statt, daher muss die Landingpage schnell, gut lesbar und auf einem kleinen Bildschirm zugänglich sein. Sie sollte die relevanten Warnzeichen erklären, ohne den Mitarbeiter zu beschämen oder ein realistisches Anmeldeformular nachzubilden.
Gute Folgeinhalte konzentrieren sich auf wiederholbare Verhaltensweisen: Zeige eine Vorschau des Ziels an, wenn das Gerät dies unterstützt, behandle unerwartete QR-Aufforderungen als Links, nutze eine vertrauenswürdige App oder ein Lesezeichen für sensible Dienste und melde Unsicherheiten, bevor du fortfährst. Die CISA-Leitlinien zum Erkennen und Melden von Phishing bieten eine nützliche Grundlage für klare, handlungsorientierte Ratschläge.
3. Ereignisdaten, die den Gerätewechsel überstehen
Eine reine Scan-Zahl reicht nicht aus. Darin können Sicherheitsscanner, wiederholte Scans, Testverkehr oder ein Mitarbeiter enthalten sein, der den Code nur öffnet, um ihn zu überprüfen. Käufer sollten ein dokumentiertes Ereignismodell verlangen, das – sofern technisch und rechtlich möglich – folgende Punkte unterscheidet:
- Zustellung von Nachrichten oder Assets;
- Öffnen des QR-Ziels;
- Erreichen der Simulationsanzeige;
- Melden eines verdächtigen Elements;
- Abschluss von Lerninhalten; und
- doppelte, automatisierte oder Qualitätssicherungsereignisse.
Die Plattform sollte die Grenzen der Zuordnung erläutern. Wenn ein QR-Code ausgedruckt, weitergeleitet oder fotografiert wird, ist eine lückenlose Zuordnung auf Personenebene möglicherweise unmöglich – und so zu tun, als wäre dies der Fall, führt zu irreführenden Kennzahlen. Aggregierte oder kohortenbasierte Berichte sind oft vertretbarer als invasives Tracking.
4. Vielfältige Übermittlungskontexte mit einheitlichen Sicherheitsvorkehrungen
Quishing findet nicht nur in E-Mails statt. Mitarbeiter begegnen QR-Codes in PDF-Dokumenten, Kollaborationstools, Beschilderungen für Besucher, Rechnungen, Anleitungen zur Geräteregistrierung und internen Service-Workflows. Eine nützliche Plattform sollte kontrollierte Tests in allen Kontexten unterstützen, die das Unternehmen tatsächlich nutzt, und dabei dieselben Regeln für Ziel, Ablauf, Offenlegung und Datenaufbewahrung anwenden.
Hier kann eine Szenario-Bibliothek helfen, doch ein sicheres Programmdesign ist wichtiger als der Umfang. Schau dir sichere Quishing-Simulationsszenarien getrennt von den hier beschriebenen Plattformkontrollen an. Der Simulator sollte genehmigte Szenarien wiederholbar machen, ohne Teams dazu zu verleiten, riskante Ziele zu improvisieren.
5. Meldeverfahren über alle Kanäle hinweg
Ein Mitarbeiter erkennt vielleicht eine verdächtige QR-Aufforderung, hat aber trotzdem keine naheliegende Möglichkeit, sie zu melden. E-Mail-Meldeschaltflächen decken keine Plakate, PDFs oder Codes ab, die auf einem anderen Bildschirm zu sehen sind.
Teste während eines Pilotprojekts den Meldeweg genauso gründlich wie den Scan-Weg. Zu den Optionen können die bestehende E-Mail-Meldemöglichkeit des Unternehmens, eine Service-Desk-Kategorie, ein mobilfreundliches internes Formular oder ein dokumentierter Sicherheitskontakt gehören. Die Plattform sollte es Teams ermöglichen, korrekte Meldungen anzurechnen, ohne dass Mitarbeiter persönliche Screenshots oder Gerätedaten hochladen müssen.
Die Meldung sollte mit der Triage verknüpft sein. Der Sicherheitsbetrieb benötigt genügend Kontext, um eine Simulation von einem echten QR-Vorfall zu unterscheiden, doppelte Tickets zu vermeiden und die Reaktionszeit zu messen. Der umfassendere Leitfaden für den Kauf von Schulungen zur Phishing-Sensibilisierung von Mitarbeitern erklärt, wie sich die Meldepraxis in ein laufendes Programm zur Verhaltensänderung einfügt.
6. Datenschutz, Datenaufbewahrung und Mitarbeiter-Governance
Geräteübergreifende Tests können Mitarbeiter überraschen, besonders wenn private Handys im Spiel sind. Dokumentiere vor dem Kauf, ob der Simulator IP-Adressen, User-Agents, Gerätekennungen, Telefonnummern, genaue Zeitstempel oder standortbezogene Daten aufzeichnet. Entscheide dann, welche Felder für das Lernziel tatsächlich erforderlich sind.
Achte auf konfigurierbare Aufbewahrungsfristen, rollenbasierten Zugriff, Prüfprotokolle, Kontrollen beim Datenexport, Informationen zum regionalen Hosting und einen klaren Löschprozess. Vergewissere dich, dass aggregierte Berichte und pseudonyme Identifikatoren verfügbar sind, wenn eine individuelle Nachverfolgung nicht erforderlich ist. Betriebsräte, Datenschutzteams, die Personalabteilung und juristische Ansprechpartner sollten den Zweck und die Grenzen vor der ersten Übung prüfen – nicht erst nach einer Beschwerde.
7. Integration ohne Umgehung von Sicherheitskontrollen
Ein Simulator sollte sich nahtlos in die E-Mail-, Identitäts-, Lern-, Ticketing- und Berichts-Infrastruktur einfügen, ohne weitreichende Ausnahmen zu erfordern. Käufer sollten vorsichtig sein, wenn der Bereitstellungsplan eines Anbieters damit beginnt, die URL-Prüfung zu deaktivieren, den Schutz mobiler Geräte zu schwächen oder mehr Infrastruktur auf die Whitelist zu setzen, als der Test erfordert.
Fordere eine möglichst eng gefasste Konfiguration, einen Rollback-Plan und eine Dokumentation, die den Simulationsverkehr von echten Bedrohungen unterscheidet. Das Ziel ist ein zuverlässiger Test unter bekannten Bedingungen – nicht der Nachweis, dass ein Anbieter defensive Kontrollen umgehen kann.
So führst du einen Quishing-Simulator sicher ein
Nutze einen kleinen, repräsentativen Pilotversuch, um die Kontrollen vor einer breiteren Einführung zu validieren.
- Definiere ein Verhaltensziel. Wähle ein konkretes Ziel wie die Meldung einer unerwarteten QR-Abfrage, statt eines vagen Ziels wie „Risiko reduzieren“.
- Genehmige die Datenzuordnung. Erfasse jedes Ereignis und jede Kennung, die die Plattform speichert, sowie den Zweck, wer darauf zugreifen darf und wann die Daten gelöscht werden.
- Überprüfe das Ziel. Vergewissere dich über HTTPS, die Domain-Inhaberschaft, das Ablaufverhalten, den offengelegten Inhalt, die Barrierefreiheit und das Fehlen von Feldern für Anmeldedaten.
- Teste gängige Geräte. Überprüfe die Benutzererfahrung auf verwalteten und privaten Geräten, ohne aufdringliche Software zu installieren oder Sicherheitskontrollen zu schwächen.
- Übe die Meldung und Triage. Stelle sicher, dass Nutzer aus dem relevanten Kontext heraus Meldungen machen können und dass das Sicherheitsteam Simulationsmeldungen schnell erkennt.
- Führe eine begrenzte Kohorte durch. Beziehe verschiedene Rollen und Arbeitsmuster ein, vermeide jedoch Zeiten mit hohem Arbeitsdruck oder Gruppen, die noch keine Benachrichtigung über das Programm erhalten haben.
- Überprüfe die Ergebnisse vor der Ausweitung. Filtere automatisierten Datenverkehr und Duplikate heraus, bewerte das Meldeverhalten, sammle Feedback von Mitarbeitern und behebe Lücken im Arbeitsablauf.
Dieser Pilot sollte zu einer Go/No-Go-Entscheidung und einer kurzen Liste mit Korrekturmaßnahmen führen. Er sollte nicht zu einer informellen Produktionskampagne werden.
Kennzahlen, die Lernen zeigen – nicht nur das Scannen
Die Scan-Rate kann Schwachstellen aufdecken, sollte aber nicht der wichtigste Erfolgsmesser sein. Bessere Kennzahlen sind:
- Melderate bei verdächtigen QR-Aufforderungen;
- die Medianzeit vom ersten Kontakt bis zur ersten gültigen Meldung;
- der Anteil der Meldenden, die den genehmigten Kanal nutzen;
- wiederholtes sicheres Verhalten in späteren Übungen;
- Abschluss und Verständnis des unmittelbaren Lernschritts;
- die Rate automatisierter, doppelter oder nicht zuordenbarer Ereignisse; und
- Mitarbeiter-Feedback zu Klarheit, Fairness und Meldehürden.
Segmentiere die Ergebnisse nur, wenn die Gruppe groß genug ist, um die Privatsphäre zu schützen, und der Vergleich eine echte Entscheidung stützt. Ranglisten für kleine Teams und individuelle „Risikobewertungen“ können Störsignale überbewerten, von der Meldung abhalten und Sensibilisierungsarbeit in Überwachung verwandeln.
Fragen an Anbieter
Stell diese Fragen bei der Beschaffung oder einer technischen Vorführung:
- Kann jedes QR-Ziel auf genehmigte, vom Anbieter oder vom Kunden kontrollierte Domains beschränkt werden?
- Wohin führt ein abgelaufener oder weitergeleiteter Code?
- Können wir die Erfassung von Anmeldedaten, MFA-Daten, Zahlungsdaten und Freitext auf Plattformebene unterbinden?
- Welche Ereignisse werden auf dem Smartphone gemessen und welche Identifikatoren werden gespeichert?
- Wie filtert ihr automatisierte Scanner, doppelte Scans und interne Tests heraus?
- Können gedruckte und digitale Codes denselben Richtlinien für Ablauf und Offenlegung folgen?
- Wie können Mitarbeiter eine QR-Aufforderung melden, die nicht per E-Mail angekommen ist?
- Können Berichte aggregiert oder pseudonymisiert werden?
- Welche Optionen für Aufbewahrung, Löschung, Zugriffskontrolle und Prüfprotokolle stehen zur Verfügung?
- Welche Integrationen oder Änderungen an der Whitelist sind erforderlich, und wie lassen sie sich rückgängig machen?
- Kann die Plattform Nachweise exportieren, ohne unnötige Daten auf Mitarbeiterebene offenzulegen?
- Wie funktioniert die Lernerfahrung auf kleinen Bildschirmen und mit assistiver Technologie?
Die besten Antworten sind konkret, nachweisbar und dokumentiert. Ein ausgefeiltes Dashboard kann eine unkontrollierte Weiterleitung oder ein unklares Datenmodell nicht ausgleichen.
Häufig gestellte Fragen
Was ist ein Quishing-Simulator?
Ein Quishing-Simulator ist ein Tool zur Sensibilisierung für Sicherheitsfragen, das kontrollierte QR-Code-Phishing-Tests erstellt. Er hilft Unternehmen dabei, zu beurteilen, ob Mitarbeiter verdächtige QR-Aufforderungen erkennen und melden, und bietet anschließend sichere Nachschulungen an, ohne die Nutzer auf eine echte bösartige Website weiterzuleiten.
Reicht ein QR-Code-Generator für Quishing-Schulungen aus?
Nein. Ein Generator erstellt zwar den Code, aber ein sicheres Programm benötigt außerdem kontrolliertes Hosting, Ablaufzeiten, Ereignisfilterung, mobiles Lernen, Datenschutzkontrollen, Berichtsworkflows und Prüfnachweise. Genau diese operativen Kontrollmechanismen sollten Käufer bewerten.
Sollte ein Simulator Passwörter sammeln, um Risiken nachzuweisen?
Nein. Eine Simulation kann eine sichere Interaktion messen und Schulungen durchführen, ohne echte Anmeldedaten oder MFA-Codes zu speichern. Das Sammeln vertraulicher Daten birgt vermeidbare rechtliche, datenschutzrechtliche und sicherheitstechnische Risiken.
Funktionieren Quishing-Simulationen auch mit privaten Handys?
Ja, das geht, aber das Programm sollte die Erfassung mobiler Daten auf ein Minimum beschränken, den Zweck erklären, einen klaren Berichtsweg vorgeben und die Verantwortlichen für Datenschutz sowie die Mitarbeiter einbeziehen. Für eine umfassendere mobile Governance schau dir den Leitfaden zu Phishing-Richtlinien für SMS, WhatsApp und QR an.
Wie oft sollten Teams QR-Phishing-Tests durchführen?
Die Häufigkeit sollte sich nach dem Risiko und dem Lernziel richten. Eine kontrollierte Ausgangsbasis, gezielte Nachverfolgung nach Änderungen im Arbeitsablauf und regelmäßige Wiederholungen sind in der Regel sinnvoller als häufige Überraschungstests. Überprüfe das Meldeverhalten und das Feedback der Mitarbeiter, bevor du die Häufigkeit erhöhst.
Mach QR-Tests zu einem Teil des Sensibilisierungsprogramms
„Quishing“ sollte keine isolierte, kurzlebige Kampagne werden. Behandle es als Teil eines umfassenderen Sensibilisierungsprogramms, das den Mitarbeitern beibringt, wie sie mit unerwarteten Links in E-Mails, auf Mobilgeräten, in Dokumenten und im physischen Raum umgehen sollen. Wähle einen Simulator, der das Einüben von sicherem Verhalten erleichtert und Sicherheitsteams verlässliche Nachweise liefert.
Bist du bereit, kontrollierte Phishing-Simulationen für dein Unternehmen zu testen? Melde dich an und entwickle ein messbares, datenschutzbewusstes Sensibilisierungsprogramm.