Skip to content

Messenger-Forensik: Grundlagen für die Praxis

Messenger-Forensik erklärt: Sicherungswege, normalisiertes Nachrichtenmodell, Zeitstempelformate, Hashing von Beweismitteln und typische Fehlerquellen.

Veröffentlicht am 10 Min. Lesezeit

Messenger-Forensik umfasst das Sichern, Parsen, Normalisieren und Auswerten von Kommunikation, von E-Mail und SMS bis zu Chat-Apps und Kollaborationswerkzeugen im Unternehmen, um Tatsachenfragen zu beantworten: Wer hat wem was wann über welchen Kanal geschrieben, und was wurde dabei geteilt, bearbeitet oder gelöscht?

Sie liegt an der Schnittstelle von Mobilforensik, Computerforensik, eDiscovery und Incident Response. Ein Fall von Business E-Mail Compromise braucht Mail-Header. Ein Insider-Fall braucht Slack oder Teams. Ein Betrugsfall braucht WhatsApp, Telegram und SMS, oft alle drei für dieselben Personen. Die Schwierigkeit liegt selten darin, eine einzelne Nachricht zu lesen. Sie liegt darin, Hunderttausende davon aus Formaten, die sich in fast allem widersprechen, zu einer einzigen belastbaren Zeitleiste zusammenzuführen.

Dieser Leitfaden behandelt die Grundlagen, die für jede Quelle gelten: wie Beweismittel gesichert werden, wie eine normalisierte Nachricht aussieht, wie Zeitstempel kodiert sind, wie die Integrität gewahrt bleibt, wie Identitäten verknüpft werden und in welche Fallen auch erfahrene Forensiker tappen.

Sicherung: drei Wege, drei Kompromisse

Die Herkunft der Daten bestimmt, was sie enthalten. Grob gibt es drei Wege.

App-Exporte

Die meisten Plattformen bieten einen Export für Nutzer an: „Chat exportieren“ bei WhatsApp, den JSON-Export von Telegram Desktop, Slack-Workspace-Exporte, das Discord-Datenpaket, „Deine Informationen herunterladen“ bei Meta, Google Takeout, den Konversationsexport von Skype, den Chatverlauf-Export von LINE.

  • Vorteile: leicht zu beschaffen, oft mit Mitwirkung des Kontoinhabers; kein Gerätezugriff und kein Root nötig; strukturiert (JSON, CSV) oder zumindest vorhersehbarer Text.
  • Nachteile: Der Anbieter entscheidet, was enthalten ist. Exporte lassen meist gelöschte Nachrichten, Bearbeitungsverläufe, Lesebestätigungen und interne Kennungen weg. Manche sind reiner Text mit lokaler Gerätezeit und ohne Zeitzone. Viele beschränken sich auf das, was ein einzelnes Konto sehen kann.

Geräte- und Datenbankextraktion

Die Alternative ist, den app-eigenen Datenspeicher von einem Gerät, einem Backup oder einem Desktop-Profil zu sichern: chat.db unter macOS, sms.db aus einem iOS-Backup, msgstore.db und wa.db unter Android, ChatStorage.sqlite unter iOS, db.sqlite von Signal Desktop, viber.db von Viber, die alte main.db von Skype, mmssms.db für Android-SMS.

  • Vorteile: reichhaltigere Daten. Man erhält interne Zeilen-IDs, Zustell- und Lesestatus, Bearbeitungszeitstempel, Anhang-Metadaten und manchmal Reste gelöschter Datensätze in freien Seiten oder Write-Ahead-Logs (-wal-Dateien).
  • Nachteile: Der Zugriff ist das Problem. Mobile Datenspeicher liegen hinter der Sandbox des Betriebssystems und sind oft verschlüsselt: Signal Desktop nutzt SQLCipher, WhatsApp-Android-Backups sind verschlüsselt, und tdata von Telegram Desktop ist im Ruhezustand verschlüsselt. Zudem ändern sich Schemata zwischen App-Versionen ohne Vorankündigung.

Anbieter, Rechtsweg und eDiscovery

Der dritte Weg führt über den Betreiber des Dienstes: ein Auskunftsersuchen oder eine gerichtliche Anordnung an den Anbieter, oder ein administrativer Export aus dem eigenen Tenant, etwa Microsoft Purview eDiscovery für Teams und Exchange, ein Slack-Enterprise-Grid-Export oder Google Vault.

  • Vorteile: vollständige Abdeckung des Tenants, serverseitige Aufbewahrung (einschließlich lokal gelöschter Elemente, sofern Aufbewahrungsrichtlinien greifen) und eine klare Beweismittelkette ab einer maßgeblichen Quelle.
  • Nachteile: nur für die berechtigte Partei verfügbar (Arbeitgeber, Strafverfolgung, Prozesspartei), langsam und im Format des Anbieters geliefert, das Threads verflachen oder Chats als E-Mail-ähnliche Elemente darstellen kann. Teams-eDiscovery-Exporte etwa bilden Chatnachrichten als .msg-Elemente der Klasse IPM.SkypeTeams.Message ab.

In der Praxis kombiniert man die Wege. Ein Nutzerexport schließt Lücken, die eine Geräteextraktion nicht erreicht, und ein eDiscovery-Export bestätigt, was auf einem Laptop gefunden wurde.

Ein normalisiertes Nachrichtenmodell

Um eine E-Mail, einen Slack-Beitrag und eine WhatsApp-Zeile auf dieselbe Zeitleiste zu bringen, bildet man jede Quelle auf ein gemeinsames Schema ab. Das Werkzeug MessagingForensics verwendet pro Nachricht die folgenden Felder; sie sind eine gute Grundlage für jedes Toolkit:

FeldBedeutungHinweise
timestampSendezeitpunktISO 8601 in UTC, oder null, wenn die Quelle keine verwertbare Zeit hat
platformE-Mail, Slack, WhatsApp, Teams…Festes Vokabular, kein Freitext
conversationKanal, Chat, Thread oder PostfachordnerGruppennamen ändern sich; IDs in extra aufbewahren
sender / senderIdAnzeigename und stabile KennungNamen sind Kosmetik, IDs sind Beweis
recipientsEmpfänger, sofern das Format sie erfasstBei E-Mail immer, bei Chat-Exporten fast nie
text / subjectInhalt als KlartextHTML auf Text reduziert; Betreff bei E-Mail
attachmentsName, MIME-Typ, GrößeDer Inhalt ist meist eine separate Datei
editedZeitpunkt der letzten BearbeitungNur wenn die Quelle ihn erfasst
deletedLöschmarkierung„Diese Nachricht wurde gelöscht“ ist auch ein Befund
replyToVerweis auf die AusgangsnachrichtIn-Reply-To bei E-Mail, Thread- oder Zitat-IDs bei Chats
directionin oder out bezogen auf den InhaberNur bei Gerätedatenspeichern aussagekräftig
format / sourceVerwendeter Parser und Pfad des BeweismittelsZ. B. archive.zip!/general/2024-02-01.json
extraAlles QuellenspezifischeRohe Header, IDs, Flags zur Dokumentation

Zwei Gestaltungsregeln sind entscheidend. Erstens: Quellenspezifische Daten nie verwerfen, nur weil sie in keine Spalte passen; sie gehören in eine extra-Map, damit ein Prüfer darauf zurückgreifen kann. Zweitens: Jede Zeile muss auf die exakte Beweisdatei und den Parser verweisen, aus denen sie stammt. Ein Zeitleisteneintrag, der sich nicht zu seinem Ursprung zurückverfolgen lässt, ist eine Behauptung, kein Beweis.

Der Zeitstempel-Zoo

Nichts bringt Messenger-Zeitleisten so zuverlässig durcheinander wie die Zeit. Jede Plattform wählt ihre eigene Epoche, Einheit und Zeitzonenkonvention, manchmal mehrere innerhalb einer Datenbank. Die Tabelle kodiert denselben Zeitpunkt, 2024-02-01 10:15:00 UTC, in jedem Format.

KodierungEpoche und EinheitBeispielwertWo man ihr begegnet
Unix-Sekunden1970-01-01 UTC, Sekunden1706782500Slack ts (mit Mikrosekunden-Suffix), Telegram date_unixtime, alte Skype-main.db
Unix-Millisekunden1970-01-01 UTC, ms1706782500000Android-SMS date, WhatsApp Android, Signal Desktop sent_at, Messenger timestamp_ms
Apple-Cocoa-Sekunden2001-01-01 UTC, Sekunden728475300WhatsApp iOS ZMESSAGEDATE, ältere iMessage-chat.db
Apple-Cocoa-Nanosekunden2001-01-01 UTC, ns728475300000000000iMessage chat.db / sms.db unter aktuellem macOS und iOS
Windows FILETIME1601-01-01 UTC, 100-ns-Intervalle133512561000000000Eigenschaften von Outlook-.msg, Teams-eDiscovery-Elemente
RFC-2822-DatumText mit expliziter AbweichungThu, 01 Feb 2024 11:15:00 +0100E-Mail-Header Date: und Received:
ISO 8601Text, Abweichung optional2024-02-01T10:15:00.000+00:00Discord-Datenpakete, Microsoft Graph, Teams-JSON
Text in GerätezeitKeine Zeitzone erfasst01/02/2024, 11:15WhatsApp-.txt-Export, LINE-.txt-Export

Kennt man die Epoche, sind die Umrechnungen einfache Arithmetik:

unix_seconds = cocoa_seconds + 978307200
unix_seconds = cocoa_nanoseconds / 1e9 + 978307200
unix_seconds = filetime / 1e7 - 11644473600

Das Werkzeug wendet diese Regeln an und skaliert Unix-Werte automatisch: Alles über 1e13 wird aus Mikro- oder Nanosekunden heruntergerechnet, alles unter 1e11 als Sekunden behandelt. Werte, die vor 1990 oder nach 2100 landen, werden als unplausibel verworfen, und der Zeitstempel bleibt leer, statt erfunden zu werden. Diese Schutzregel ist wichtig: Eine Null, eine vertauschte Spalte oder ein als Unix gelesener Cocoa-Wert erzeugen Daten in 1970 oder 2001, die in einem Diagramm echt aussehen.

Textformate verdienen besonderes Misstrauen. Die Textexporte von WhatsApp und LINE geben die lokale Uhrzeit des Telefons ohne Zeitzone aus, und die Datumsreihenfolge (Tag/Monat oder Monat/Tag) hängt von den Regionaleinstellungen des Geräts ab. Ein Wert wie 03/04/2024 bleibt mehrdeutig, bis an anderer Stelle der Datei ein Tag größer als 12 auftaucht. Das Werkzeug leitet die Reihenfolge aus der gesamten Datei ab, zeigt die lokale Zeit unverändert mit der Kennzeichnung UTC an und gibt eine Warnung aus, damit niemand sie für echtes UTC hält. Ebenso werden ISO-ähnliche Zeichenketten ohne Zeitzone wie 2024-01-02 10:00:00 als UTC gelesen, was die meisten Exporte meinen, aber nicht alle. Halten Sie Ihre Annahme und die Zeitzoneneinstellung des Geräts in Ihren Notizen fest.

Bei E-Mail ist es umgekehrt: Jeder Header trägt eine explizite Abweichung, aber der Date:-Header wird vom Client des Absenders geschrieben und kann beliebig gesetzt sein. Die Received:-Kette, von jedem Relay gestempelt, ist die unabhängige Uhr zum Abgleich.

Integrität der Beweismittel

Messenger-Beweismittel sind klein, textlastig und leicht zu verändern. Deshalb muss die Integritätssicherung nüchterne Routine sein.

  1. Vor dem Parsen hashen. Berechnen Sie einen kryptografischen Hashwert (SHA-256 ist heute Standard) jeder Datei im Eingangszustand, bevor irgendein Werkzeug sie öffnet. MessagingForensics macht genau das zuerst: Jede Eingabedatei wird im Browser gehasht, bevor Archive entpackt oder irgendetwas geparst wird, und der Hashwert erscheint in der Beweismitteltabelle und in den Berichten.
  2. Mit Kopien arbeiten. Gerade SQLite verändert eine im Lese-/Schreibmodus geöffnete Datei bereitwillig: Es kann ein -wal-Journal einspielen und in die Hauptdatenbank übernehmen und damit den vorherigen Zustand zerstören. Bewahren Sie Original, -wal und -shm zusammen auf und parsen Sie Kopien.
  3. Parser und Format pro Datei dokumentieren. „Geparst als Slack-Workspace-Export“ oder „Geparst als WhatsApp iOS (ChatStorage.sqlite)“ gehört neben den Hashwert. Wurde eine Datei nicht erkannt, sagen Sie das ausdrücklich; stille Auslassungen sind der Weg, auf dem Lücken unbemerkt bleiben.
  4. Archivpfade beibehalten. Nachrichten aus einem ZIP sollten den Pfad des Archivmitglieds nennen (export.zip!/Messages/c123/messages.json), nicht nur das Archiv, damit ein Prüfer die exakten Bytes findet.
  5. Nach Möglichkeit lokal verarbeiten. Das Hochladen von Beweismitteln zu einem Drittanbieter erzeugt eine neue Kopie außerhalb Ihrer Kontrolle. Ein Parser im Browser hält die Daten auf dem Rechner des Forensikers.

Identitäten plattformübergreifend verknüpfen

Dieselbe Person erscheint als +1 202 555 0143 in SMS, 12025550143@s.whatsapp.net in WhatsApp, jdoe in Slack, als numerischer Snowflake in Discord und als j.doe@example.test in E-Mails. Anzeigenamen kollidieren und ändern sich; Kennungen sind das, woran man ansetzt.

Nützliche Anker:

  • Telefonnummern, normalisiert auf E.164 (+12025550143). WhatsApp-JIDs, Signal, Viber, iMessage-Handles und SMS-Adressen lassen sich alle darauf zurückführen.
  • E-Mail-Adressen in Kleinschreibung. Sie verbinden E-Mail, iMessage (Apple-ID-Handles), Teams- und Slack-Profile sowie Google Chat.
  • Nutzer-IDs der Plattformen aus den extra-Feldern: Slack-IDs U…, Discord-Snowflakes, Telegram-IDs user…. Sie überdauern Umbenennungen.
  • Gemeinsame Indikatoren im Inhalt: Dieselbe URL, dieselbe Krypto-Wallet oder dieselbe IBAN auf mehreren Plattformen ist oft die stärkste Verbindung zwischen Konten.

MessagingForensics extrahiert aus Nachrichtentext und Betreffzeilen URLs, E-Mail-Adressen, Telefonnummern im internationalen Format, IPv4-Adressen, Bitcoin- und Ethereum-Adressen sowie IBANs und zählt, wie viele Nachrichten jeden Wert enthalten. Die Muster sind bewusst konservativ: Eine Telefonnummer muss mit + beginnen, Nummern im nationalen Format werden daher nicht erfasst. Verstehen Sie die Liste als Ausgangspunkt für weitere Ermittlungsansätze, nicht als vollständiges Verzeichnis. Watchlists (Stichwörter, eines pro Zeile) filtern die kombinierte Zeitleiste anschließend auf die relevanten Nachrichten.

Typische Fehlerquellen

Verschlüsselte Datenspeicher. Die Datenbank von Signal Desktop ist mit SQLCipher verschlüsselt; man braucht den Schlüssel aus dem Profil, um sie zu entschlüsseln, bevor ein Parser sie lesen kann. WhatsApp-Android-Backups (.crypt14, .crypt15) erfordern die Schlüsseldatei oder das Passwort des Ende-zu-Ende-verschlüsselten Backups. Der Cache von Telegram Desktop ist verschlüsselt. Wer nur die verschlüsselte Datei hat, braucht eine andere Sicherung, keinen anderen Parser.

Exporte nur aus Sicht des Inhabers. Das Discord-Datenpaket enthält nur die Nachrichten, die das anfragende Konto gesendet hat, nicht die Gegenseite der Unterhaltung. Messenger- und Instagram-Exporte spiegeln wider, was dieses Konto zum Zeitpunkt des Exports sehen konnte. Geben Sie immer an, aus wessen Perspektive ein Export stammt.

Gelöschte Nachrichten. Exporte enthalten sie selten; Datenbanken manchmal, als markierte Zeilen oder in nicht zugewiesenen Seiten. Ein „gelöscht“-Flag im normalisierten Modell bedeutet, dass die Quelle eine Löschung erfasst hat. Das Fehlen einer Nachricht beweist nichts darüber, ob sie existiert hat.

Zeitzonen. Wer Textexporte in Gerätezeit mit UTC-Zeitstempeln aus Datenbanken mischt, kann Ereignisse um Stunden verschieben und eine Unterhaltung umsortieren. Normalisieren Sie alles auf UTC, markieren Sie die Zeilen, die sich nicht normalisieren ließen, und notieren Sie Sommerzeitumstellungen im betrachteten Zeitraum.

Duplikate über Quellen hinweg. Dieselbe Nachricht kann in einem WhatsApp-Export, in msgstore.db und auf dem Telefon des Gegenübers auftauchen, dieselbe E-Mail in zwei Postfächern und einer MBOX. Deduplizieren Sie anhand stabiler Kennungen (Message-ID, Nachrichten-IDs der Plattform), wo vorhanden, andernfalls anhand von Zeitstempel plus Absender plus Text-Hash, bewahren Sie aber jeden Quellenverweis auf: Eine auf beiden Geräten gefundene Nachricht ist ein stärkerer Beweis als eine, die nur auf einem gefunden wurde.

Bearbeitungen. Eine bearbeitete Nachricht trägt unter Umständen nur ihren endgültigen Text. Erfasst die Quelle einen Bearbeitungszeitpunkt, behalten Sie ihn; führt die Plattform einen Verlauf, liegt dieser in einer anderen Tabelle oder Datei.

Wandernde Anzeigenamen. Kontakte werden umbenannt, Gruppen erhalten neue Titel, und Exporte geben den Namen aus, der zum Zeitpunkt des Exports galt, nicht zum Zeitpunkt des Versands.

Weiterführend

Probieren Sie den MessagingForensics-Parser aus: Exporte oder Datenbanken in den Browser ziehen und SHA-256-Hashwerte für jede Datei, eine einheitliche UTC-Zeitleiste, extrahierte Indikatoren sowie CSV-, JSON- oder HTML-Berichte erhalten, ohne etwas hochzuladen.

Danach geht es quellenspezifisch in die Tiefe (Artikel auf Englisch):