Tabletop Tuesday

Vishing

Der falsche Kollege am Telefon – Gezielter Social-Engineering-Angriff

Herzlich willkommen zu einer neuen Ausgabe von "Tabletop Tuesday"! Heute nehmen wir einen der heimtückischsten Angriffsvektoren unter die Lupe: Social Engineering per Telefon, auch bekannt als Vishing. Stellen Sie sich vor, Ihre Mitarbeiter erhalten Anrufe von jemandem, der sich überzeugend als interner IT-Support ausgibt und versucht, an Zugangsdaten, interne Informationen oder direkten Systemzugriff zu gelangen.

Dieser Angriff zielt auf die Hilfsbereitschaft und das Vertrauen Ihrer Mitarbeiter ab. Sind Ihre Mitarbeiter gewappnet? Und wie reagiert Ihr Unternehmen, wenn der Verdacht aufkommt, dass der Angreifer bereits erfolgreich war?

Was ist eine Tabletop-Übung?

Eine Tabletop-Übung ist ein diskussionsbasiertes Training, bei der Teammitglieder die Rollen und Verantwortlichkeiten durchgehen, die sie während eines bestimmten Notfallszenarios hätten. Es geht nicht darum, Systeme live zu testen, sondern darum, Prozesse, Pläne und Kommunikationswege auf den Prüfstand zu stellen.

Phase 1: Erste Anzeichen

Szenariobeschreibung (Teil 1):

An einem geschäftigen Dienstagmorgen meldet eine Mitarbeiterin aus dem Vertrieb beim internen IT-Helpdesk, dass sie gerade einen "merkwürdigen Anruf" vom IT-Support erhalten habe. Der angebliche Supporter mit leichtem Akzent kannte ihren Namen und ihre Abteilung und sprach von "dringenden Sicherheitsupdates für ihr VPN", für die er sie bitten würde, eine Webseite zu besuchen und ihre Anmeldedaten zu bestätigen. Da die Mitarbeiterin gerade keine Zeit hatte und ihr der Anruf komisch vorkam (sie hatte kein Ticket eröffnet), beendete sie das Gespräch und rief den echten Helpdesk an. Der Helpdesk-Mitarbeiter ist zunächst unsicher, da keine solche Aktion bekannt ist, nimmt den Hinweis aber auf. Wenig später meldet sich ein Kollege aus der Buchhaltung mit einer ähnlichen Geschichte: ein Anruf vom "Security Team", der ihn aufforderte, TeamViewer zu installieren, um "eine verdächtige Aktivität auf seinem Rechner zu prüfen". Auch er wurde misstrauisch und legte auf.

Diskussionspunkte und Kernfragen für Ihr Team:

Erkennung und Meldung:

Wie werden solche verdächtigen Anrufe intern gemeldet? Gibt es einen klaren Prozess und eine zentrale Anlaufstelle (z.B. IT-Helpdesk, Security Operations Center - SOC)?
Wie werden die Mitarbeiter dazu ermutigt, auch "nur komische" Vorfälle zu melden, ohne Angst zu haben, sich lächerlich zu machen?
Werden diese Erstmeldungen ernst genommen und systematisch erfasst?

Erste Bewertung:

Wie werden die ersten Meldungen bewertet? Als Einzelfälle oder als potenzieller Beginn einer Kampagne?
Welche Informationen werden von den meldenden Mitarbeitern erfragt (angezeigte Rufnummer – falls vorhanden, genauer Wortlaut, Name des angeblichen Supporters, geforderte Aktionen)?

Sofortige interne Warnung:

Gibt es einen Mechanismus, um schnell eine erste, interne Kurzwarnung an andere Mitarbeiter oder zumindest an den IT-Helpdesk zu geben, um die Aufmerksamkeit zu erhöhen?

Mögliche Sofortmaßnahmen:

Sensibilisierung des IT-Helpdesks/SOC: Alle Mitarbeiter im First-Level-Support sofort über die gemeldeten Vorfälle informieren und anweisen, ähnliche Meldungen sehr ernst zu nehmen und detailliert zu dokumentieren.
Detaillierte Befragung der betroffenen Mitarbeiter: Alle verfügbaren Details zu den Anrufen sammeln (Uhrzeit, Inhalt, Akzent, geforderte Handlungen, ggf. angezeigte Telefonnummern).
Prüfung interner Systeme: Gibt es aktuell legitime Support-Aktionen oder Wartungsarbeiten, die zu Verwechslungen führen könnten? (Wahrscheinlich nicht, aber zur Sicherheit prüfen).
Erwägung einer ersten, knappen internen Kommunikation: z.B. eine E-Mail an alle Mitarbeiter "Aktuell gibt es Berichte über verdächtige Anrufe. Bitte seien Sie besonders wachsam und geben Sie keine Zugangsdaten am Telefon preis. Melden Sie verdächtige Anrufe sofort an [Anlaufstelle]."

Phase 2: Eine koordinierte Kampagne

Szenariobeschreibung (Teil 2):

Im Laufe des Vormittags gehen beim IT-Helpdesk weitere Meldungen über ähnliche Anrufe ein, diesmal aus verschiedenen Abteilungen (Marketing, Personal, Produktion). Die Anrufer scheinen gut vorbereitet zu sein: Sie kennen Namen, Abteilungen und teilweise sogar aktuelle Projekte der angerufenen Mitarbeiter. Die Geschichten variieren leicht (VPN-Update, Sicherheitscheck, Installation neuer Software), aber das Ziel ist immer dasselbe: Die Mitarbeiter sollen dazu gebracht werden, Zugangsdaten preiszugeben, Fernwartungssoftware zu installieren oder schädliche Webseiten zu besuchen. Es wird klar, dass es sich um eine gezielte und koordinierte Social-Engineering-Kampagne handelt. Es ist unklar, ob bereits Mitarbeiter auf die Masche hereingefallen sind.

Diskussionspunkte und Kernfragen für Ihr Team:

Krisenmanagement:

Wer übernimmt jetzt die Leitung der Incident Response? (IRT-Leiter, CISO).
Wie wird sichergestellt, dass alle Informationen zentral zusammenlaufen?
Welche Abteilungen müssen jetzt dringend einbezogen werden (IT-Sicherheit, Management, Unternehmenskommunikation, Datenschutzbeauftragter)?

Verifizierungsprozesse für Mitarbeiter:

Wie können Mitarbeiter überhaupt sicherstellen, dass ein Anruf vom internen IT-Support legitim ist?
Gibt es einen Rückrufprozess über eine bekannte, offizielle Helpdesk-Nummer?
Werden Support-Tickets mit eindeutigen Nummern verwendet, die der Anrufer nennen muss?
Gibt es ein internes Codewort-System (realistisch und praktikabel?)?
Werden Mitarbeiter angewiesen, bei unaufgeforderten Support-Anrufen grundsätzlich aufzulegen und den Helpdesk proaktiv über die offizielle Nummer zu kontaktieren?

Kommunikation und Aufklärung (kurzfristige Maßnahmen):

Welche Art von Warnung/Information muss jetzt an alle Mitarbeiter ausgegeben werden? (E-Mail, Intranet-Meldung, Durchsage).
Welche kurzfristigen Schulungsmaßnahmen oder Sensibilisierungs-Maßnahmen können sofort verteilt werden? (z.B. kurzes Merkblatt "So erkennen Sie Vishing-Anrufe", Info-Pop-up beim Systemstart, kurze Videobotschaft des CISO).
Welche klaren Verhaltensregeln sollen kommuniziert werden (niemals Passwörter am Telefon, keine Installation unbekannter Software auf Anweisung, Rückruf zur Verifizierung)?

Erste technische Überprüfungen:

Können die gemeldeten (ggf. gefälschten) Anrufernummern blockiert werden (sofern sie überhaupt angezeigt wurden und nicht unterdrückt waren)?
Gibt es erste verdächtige Aktivitäten in den Logs (z.B. fehlgeschlagene oder ungewöhnliche Login-Versuche, Installation neuer Software auf Endgeräten)?

Mögliche Maßnahmen:

Formelle Einberufung des Incident Response Teams (IRT).
Veröffentlichung einer dringenden, unternehmensweiten Warnung mit klaren Verhaltensanweisungen und Hinweisen zur Verifizierung legitimer Support-Anrufe.
Erstellung und Verteilung von Ad-hoc-Sensibilisierungsmaterialien (z.B. Top 5 Tipps zur Abwehr von Telefonbetrug).
Anweisung an den IT-Helpdesk, bei proaktiven Anrufen an Mitarbeiter immer eine Ticketnummer zu nennen und auf den Verifizierungsprozess (z.B. Rückruf) hinzuweisen.
Start einer initialen Log-Analyse auf verdächtige Aktivitäten, die mit den gemeldeten Anrufzeiten korrelieren könnten.

Phase 3: Schadensbegrenzung und Suche nach Kompromittierungen

Szenariobeschreibung (Teil 3):

Die unternehmensweite Warnung ist raus. Die Sensibilisierung läuft. Dennoch besteht die Sorge, dass einige Mitarbeiter bereits Opfer des Angriffs geworden sein könnten, bevor die Warnung sie erreichte oder weil sie die Anweisungen nicht befolgt haben. Manche Mitarbeiter könnten sich auch schämen, zuzugeben, dass sie auf den Trick hereingefallen sind. Es gibt erste vage Hinweise aus Logfiles über ungewöhnliche Anmeldeversuche von einer externen IP-Adresse auf ein Benutzerkonto.

Diskussionspunkte und Kernfragen für Ihr Team:

Identifizierung potenziell kompromittierter Mitarbeiter/Konten:

Wie kann überprüft werden, ob Mitarbeiter möglicherweise betroffen waren und es nicht zugeben möchten?
Gezielte (aber sensible) Befragung von Mitarbeitern in Abteilungen, die viele Anrufe erhalten haben?
Technische Analyse: Systematische Überprüfung von Login-Protokollen (VPN, wichtige Anwendungen, Cloud-Dienste) auf Anomalien (ungewöhnliche Zeiten, Geolokationen, fehlgeschlagene Versuche gefolgt von erfolgreichen).
Überprüfung von Installationen neuer Software (insbesondere Fernwartungstools) auf Endgeräten.
Auswertung von Proxy-Logs auf Besuche verdächtiger Webseiten, die von den Anrufern genannt wurden.
Einsatz von Endpoint Detection and Response (EDR) Tools zur Identifizierung verdächtiger Prozesse oder Netzwerkverbindungen.
Wie geht man mit Mitarbeitern um, die nachweislich Zugangsdaten preisgegeben haben? (Unterstützung und Aufklärung vor Strafe, es sei denn, es liegt grobe Fahrlässigkeit vor).

Umgang mit bestätigten Kompromittierungen:

Welche sofortigen Maßnahmen sind bei einem bestätigten kompromittierten Konto zu ergreifen? (Passwort-Reset, Überprüfung aller Systemzugriffe, Session-Beendigung, forensische Untersuchung des betroffenen Endgeräts).
Wie wird festgestellt, ob der Angreifer bereits auf Systeme oder Daten zugegriffen hat?

Datenschutzrechtliche Aspekte:

Wenn Zugangsdaten oder sensible Informationen abgeflossen sind, könnte dies eine meldepflichtige Datenschutzverletzung darstellen. Wer bewertet das (DSB)?

Externe Kommunikation:

Müssen externe Stellen informiert werden (z.B. Polizei, CERTs, Kunden – falls deren Daten betroffen sind)?

Mögliche Maßnahmen:

Intensivierte technische Untersuchung: Systematische Log-Analyse, Überprüfung von Endgeräten (insbesondere bei Mitarbeitern, die Anrufe erhalten haben und deren Verhalten auffällig ist oder deren Konten Anomalien zeigen).
Schaffung eines niedrigschwelligen, vertraulichen Meldekanals für Mitarbeiter, die befürchten, Opfer geworden zu sein (z.B. direkte Durchwahl zum CISO oder einer Vertrauensperson im IRT).
Bei bestätigter Kompromittierung: Sofortige Sperrung des Kontos, Passwort-Resets, Untersuchung des betroffenen Endgeräts, Analyse des potenziellen Schadens.
Kontinuierliche Information und Updates an das Management.
Einbindung des DSB zur Bewertung einer möglichen Datenschutzverletzung.

Phase 4: Aufarbeitung, Prävention und Stärkung der Abwehr

Szenariobeschreibung (Teil 4):

Die akute Angriffswelle scheint vorüber. Einige wenige Mitarbeiter haben tatsächlich Zugangsdaten preisgegeben oder Fernwartungssoftware installiert; die betroffenen Konten wurden gesichert und die Systeme überprüft. Glücklicherweise konnte kein größerer Datenabfluss oder Systemschaden festgestellt werden – die Angreifer wurden rechtzeitig gestoppt oder die kompromittierten Konten hatten nicht ausreichend Rechte. Es ist an der Zeit, Bilanz zu ziehen und nachhaltige Verbesserungen einzuleiten.

Diskussionspunkte und Kernfragen für Ihr Team:

Analyse des Angriffs und der Reaktion:

Was hat gut funktioniert bei der Abwehr? (z.B. schnelle Meldung durch aufmerksame Mitarbeiter, effektive interne Warnung).
Wo gab es Schwachstellen? (z.B. unklare Verifizierungsprozesse für Support-Anrufe, zu langsame Verbreitung der Erstwarnung, mangelndes Bewusstsein bei einigen Mitarbeitern).
Wie gut waren die Angreifer informiert? Gibt es Hinweise auf Datenlecks, die ihnen geholfen haben könnten (z.B. öffentlich zugängliche Mitarbeiterlisten mit Durchwahlen)?

Verbesserung der Verifizierungsprozesse:

Welche der diskutierten Verifizierungsmethoden (Rückruf, Ticketnummern etc.) werden nun verbindlich eingeführt? Wie wird dies technisch und organisatorisch umgesetzt?

Nachhaltige Sensibilisierung und Schulung:

Welche regelmäßigen Schulungsformate (Online-Kurse, Präsenzschulungen, simulierte Phishing/Vishing-Angriffe) werden eingeführt oder intensiviert?
Wie kann das Thema Social Engineering dauerhaft im Bewusstsein der Mitarbeiter verankert werden?

Technische und organisatorische Anpassungen:

Müssen Zugriffsrechte überprüft und nach dem Need-to-Know-Prinzip restriktiver gestaltet werden?
Können technische Maßnahmen die Auswirkungen von Social Engineering reduzieren (z.B. Multi-Faktor-Authentifizierung überall, verbesserte Endpoint Security)?
Sollten Informationen über Mitarbeiter (Telefonbücher, Organigramme) im Intranet oder auf der Webseite reduziert werden?

Umgang mit "erfolgreichen Opfern":

Wie wird sichergestellt, dass Mitarbeiter, die auf Tricks hereinfallen, daraus lernen und nicht stigmatisiert werden (Förderung einer positiven Fehlerkultur im Sicherheitsbereich)?

Mögliche Maßnahmen:

Durchführung eines detaillierten "Lessons Learned"-Workshops mit allen beteiligten Parteien.
Überarbeitung und klare Kommunikation der Verifizierungsprozesse für interne Support-Anfragen.
Entwicklung eines langfristigen Security-Awareness-Programms mit regelmäßigen, abwechslungsreichen Inhalten und Tests.
Implementierung oder Optimierung technischer Kontrollen (MFA, EDR, Zugriffsbeschränkungen).
Überprüfung und Anpassung der Informationsbereitstellung über Mitarbeiter.
Klare Kommunikation der Ergebnisse und der ergriffenen Maßnahmen an die gesamte Belegschaft, um Vertrauen und Wachsamkeit zu stärken.

Fazit

Social-Engineering-Angriffe per Telefon sind eine ernste Bedrohung, da sie den Faktor Mensch direkt ins Visier nehmen. Eine Kombination aus wachsamen, gut geschulten Mitarbeitern, klaren Verhaltens- und Verifizierungsregeln sowie unterstützenden technischen Maßnahmen ist der beste Schutz. Wichtig ist eine Kultur, in der Sicherheitsvorfälle ohne Angst gemeldet werden können und als Chance zur gemeinsamen Verbesserung gesehen werden.

Nutzen Sie dieses Szenario, um Ihre Abwehrmechanismen gegen Vishing zu testen und zu schärfen.