Wissen / Checklisten / IT-Sicherheit

Phishing erkennen: Checkliste für Teams

Verdächtige Nachrichten erkennen und sicher reagieren.

Stand: 27.10.2026 · Redaktion: Carl Thorns · Kostenlos und ohne Anmeldung

Dieser Leitfaden führt dich vom konkreten Ausgangsproblem über die praktische Umsetzung bis zur überprüfbaren Abnahme. Jeder Abschnitt nennt eine Methode, ein Beispiel, ein Erfolgskriterium und eine typische Fehlerquelle.

Arbeitsablauf auf einen Blick

1. Absender und Kontext prüfen

Beurteile nicht nur den angezeigten Namen. Vergleiche Domain, erwarteten Kommunikationsweg und Anlass der Nachricht.

Praxisbeispiel
„Rechnung“ von einer neuen, ähnlichen Domain statt dem bekannten Lieferanten.
So erkennst du, dass es funktioniert: Rückfrage erfolgt über einen bereits bekannten Kontaktkanal.
Typischer Fehler: Auf die in der verdächtigen Mail angegebene Nummer zurückrufen.

2. Links und Anhänge

Prüfe Zieladressen vor dem Öffnen und öffne unerwartete Anhänge nicht unkontrolliert. Mobil ist das Ziel oft schwerer sichtbar.

Praxisbeispiel
login.microsoft.example.attacker.tld ist nicht microsoft.com.
So erkennst du, dass es funktioniert: Ziel-Domain und erwarteter Dienst stimmen überein.
Typischer Fehler: Nur auf ein Schloss-Symbol im Browser vertrauen.

3. Druck und Manipulation

Achte auf künstliche Fristen, Drohungen, ungewöhnliche Zahlungsänderungen und MFA-Code-Anfragen.

Praxisbeispiel
„Überweise heute auf neue IBAN, sonst wird gesperrt.“
So erkennst du, dass es funktioniert: Zahlungsänderungen sind über einen unabhängigen Kanal bestätigt.
Typischer Fehler: Dringlichkeit als Ersatz für Verifikation akzeptieren.

4. Verdacht melden

Leite verdächtige Nachrichten nach interner Richtlinie an IT/Security weiter, ohne Anhänge zu öffnen.

Praxisbeispiel
Meldung mit Zeitpunkt, Absender und Screenshot; Original bei Bedarf sicher bereitstellen.
So erkennst du, dass es funktioniert: Mitarbeiter kennen Meldeweg und bekommen Rückmeldung.
Typischer Fehler: Aus Scham nicht melden oder nur löschen.

5. Nach Klick reagieren

Bei eingegebenen Zugangsdaten sofort IT informieren, Sitzung widerrufen und Zugang absichern; nicht eigenmächtig Spuren beseitigen.

Praxisbeispiel
Incident-Ticket mit Uhrzeit und betroffenen Konten.
So erkennst du, dass es funktioniert: Security-Team kann Risiko und Reichweite einschätzen.
Typischer Fehler: Nur Passwort ändern, ohne aktive Sitzungen oder MFA zu prüfen.

Abnahmeprotokoll für die Praxis

Nutze die folgenden Punkte als dokumentierbare Abnahme. Trage bei jedem Punkt Datum, getestete URL beziehungsweise System, Ergebnis und gegebenenfalls einen offenen Befund ein.

  1. Abnahmekriterium: Rückfrage erfolgt über einen bereits bekannten Kontaktkanal.

  2. Abnahmekriterium: Ziel-Domain und erwarteter Dienst stimmen überein.

  3. Abnahmekriterium: Zahlungsänderungen sind über einen unabhängigen Kanal bestätigt.

  4. Abnahmekriterium: Mitarbeiter kennen Meldeweg und bekommen Rückmeldung.

  5. Abnahmekriterium: Security-Team kann Risiko und Reichweite einschätzen.

Fachquellen und weiterführende Dokumentation

Diese Primärquellen dienen zur Vertiefung und zur Prüfung versionsabhängiger Details. Bei rechtlichen Themen ersetzt der Leitfaden keine individuelle Rechtsberatung.

Praxisvertiefung: Warnsignale mit einem sicheren Prozess verbinden

Prüfe unerwartete Zahlungsänderungen, künstlichen Zeitdruck, abweichende Domains und Aufforderungen zur MFA-Code-Weitergabe. Öffne keine verdächtigen Anhänge zur Prüfung.

Technische Umsetzung

Verifiziere kritische Anfragen über einen bekannten zweiten Kanal. Melde Nachrichten über den definierten Prozess; SPF, DKIM und DMARC helfen, verhindern aber nicht jede Täuschung.

So überprüfst du das Ergebnis

Übe an Beispielen und messe Meldewege statt Mitarbeitende bloßzustellen. Bei geklicktem Link Zugangsdaten ändern und IT-Sicherheit informieren.