Phishing-Meldungen in Jira Service Management bearbeiten

Wie Phishing-Meldungen in einer Anfrage ankommen

Die meisten Teams leiten Meldungen über den E-Mail-Kanal in JSM. Drei Muster sind üblich:

• Weiterleiten als Anhang. Der Nutzer leitet die verdächtige E-Mail als Anhang an die Service-Desk-Adresse weiter. Das Original kommt als .eml-Datei in der Anfrage an oder, wenn es durch Jiras Mail-Handler geht, als Datei ohne Endung.
• Melden-Schaltfläche in Microsoft 365. Wenn Ihr Tenant von Nutzern gemeldete Nachrichten an ein eigenes Postfach sendet und dieses Postfach der E-Mail-Kanal von JSM ist, wird jede Meldung zu einer Anfrage mit der ursprünglichen Nachricht als Anhang.
• Drag-and-drop. Ein Agent oder Nutzer zieht die Nachricht aus Outlook auf eine bestehende Anfrage. Das klassische Outlook erzeugt eine .msg-Datei, das neue Outlook und Mac-Programme erzeugen .eml.

Das Weiterleiten im Text (der Inhalt in den Nachrichtentext eingefügt) ist das eine Muster, von dem Sie abraten sollten: Dabei gehen die Header verloren, und genau die brauchen Sie, um die E-Mail zu beurteilen.

Die E-Mail ansehen, ohne sie in Outlook zu öffnen

JSM kann .eml- und .msg-Anhänge nicht anzeigen; es bietet sie zum Download an. Die Gewohnheit, die daraus folgt, herunterladen und in Outlook öffnen, ist genau das, wovor jede Phishing-Schulung warnt: Dabei können externe Tracking-Bilder geladen, aktive Inhalte gerendert und die Links auf einen versehentlichen Klick Entfernung gebracht werden. Sicherere Optionen, in dieser Reihenfolge:

1. Die rohe .eml in einem Texteditor lesen. Sicher, aber die Header sind schwer zu lesen und der Nachrichtentext ist oft Base64 oder ein HTML-Wust.
2. Einen Viewer verwenden, der die E-Mail ohne Skripte, Formulare und externe Bilder rendert und die Header in verständlichen Worten zeigt. Am besten direkt in JSM, damit die Prüfung in der Anfrage stattfindet und die Antwort über dasselbe Ticket zurückgeht.

Was Sie prüfen sollten

Authentifizierungsergebnisse. Der empfangende Mailserver hält drei Prüfungen in den Headern fest. SPF: Durfte der sendende Server für diese Domain senden? DKIM: Wurde die Nachricht von der Domain signiert und seitdem nicht verändert? DMARC: Passt die sichtbare Absenderadresse zu diesen beiden, und was hat der Domaininhaber für den Fehlerfall festgelegt? Ein Fail bei allen dreien ist ein starkes Signal; ein Pass bei allen dreien beweist nicht, dass die E-Mail sicher ist, nur dass sie wirklich von dieser Domain kam. Der E-Mail-Check auf dieser Website zeigt diese Ergebnisse für eine Datei oder eingefügte Header, so wie der empfangende Server sie festgehalten hat.

Die Absenderdomain. Achten Sie auf Nachahmungen: ein Buchstabe zu viel, ein vertauschtes Zeichen, ein Buchstabe mit Akzent, der wie das Original aussieht, oder der Markenname als Subdomain einer fremden Domain. Vergleichen Sie sie mit der Reply-To-Adresse, die Angreifer oft woandershin zeigen lassen.

Wohin Links wirklich führen. Der Linktext und das Linkziel sind zwei verschiedene Dinge. Prüfen Sie das Ziel jedes Links und jeder Schaltfläche, und werten Sie „der Text sagt unser Portal, das Ziel ist woanders" als Warnsignal. Wenn Sie einen Link ins Ticket einfügen, entschärfen Sie ihn (hxxps://, Punkte in eckigen Klammern), damit niemand versehentlich klickt.

Anhänge in der E-Mail. Notieren Sie Namen und Typen. Office-Dateien mit Makros, Archive und HTML-Dateien gehören in eine Sandbox, nicht per Doppelklick geöffnet.

Druck. „Innerhalb von 24 Stunden", „Ihr Postfach wird gesperrt", „letzte Mahnung". Dringlichkeit ist der älteste Trick und immer noch der häufigste.

Antworten und schließen

Schreiben Sie die Ergebnisse in verständlichen Worten in die Anfrage, damit die meldende Person etwas lernt: welche Prüfungen fehlgeschlagen sind, welche Domain gefälscht war, wohin der Link führte. Lassen Sie den ursprünglichen Anhang in der Anfrage; er ist Ihr Beweis. War die E-Mail echt, sagen Sie das und bedanken Sie sich, denn die nächste Meldung dieser Person kann die sein, auf die es ankommt.

Das Ganze direkt in JSM erledigen

Zur Transparenz: Dortus stellt genau dafür eine App her. MailView zeigt .eml- und .msg-Anhänge in der Anfrage in der Agentenansicht, mit blockierten Skripten und externen Bildern, und ergänzt einen Reiter „Details" mit den SPF-, DKIM- und DMARC-Ergebnissen aus den Headern in verständlichem Englisch, Warnungen bei Domains mit ähnlich aussehenden Buchstaben aus anderen Alphabeten oder mit Akzenten, der Adresse hinter jedem Link und einer Schaltfläche „Copy findings", die eine entschärfte Zusammenfassung für den Ticket-Kommentar in die Zwischenablage legt. Die App läuft auf Atlassian und speichert oder sendet nichts. Sie ist eine Hilfe für das Urteil des Agenten, kein Ersatz dafür.

Kurze Antworten

Kann JSM eine gemeldete E-Mail in der Vorschau anzeigen? Nein. .eml- und .msg-Anhänge sind nur als Download verfügbar.

Reicht ein DMARC-Pass, um eine Meldung als sicher einzustufen? Nein. Er zeigt, dass die E-Mail von der Domain kam, die sie angibt. Eine kompromittierte oder frisch registrierte Domain besteht die Prüfung problemlos.

Sollten Agenten gemeldete E-Mails in Outlook öffnen? Nicht als Routine. Verwenden Sie einen Texteditor oder einen Viewer, der aktive Inhalte entfernt, und prüfen Sie die Linkziele, bevor jemand klickt.

Fragen

Etwas auf dieser Seite ist falsch, oder wir haben einen Fall übersehen? Schreiben Sie an support@dortus.com.

Siehe auch: .msg- und .eml-Anhänge in Jira öffnen