E-Mail-Dateien und Headeranalyse

E-Mails sind Beweismittel für Kommunikation: wer vorgab, wem zu schreiben, wann, über welche Systeme und mit welchen Anhängen. Auf einem Endgerät befinden sie sich in Postfachdateien, die Nachrichten noch lange aufbewahren, nachdem der Benutzer sie für gelöscht hält. Jede empfangene Nachricht trägt zudem einen Header, der ihren Übertragungsweg dokumentiert. Diese Lektion behandelt die auf Windows-Computern vorkommenden Postfachformate, den Fortbestand gelöschter Nachrichten und das Lesen eines Headers, damit Sie die Ursprungs-IP benennen, verlässliche Zeiten in UTC angeben und entscheiden können, ob der Absender echt ist.

E-Mail-Speicher auf dem Endgerät

Outlook PST und OST

Eine PST (Personal Storage Table) ist eine Postfachdatei des klassischen Outlook. Outlook 2003 führte die Unicode-PST ein, wodurch die 2 GB-Grenze des älteren ANSI-Formats entfiel; ab Outlook 2010 beträgt die standardmäßige Maximalgröße 50 GB. Jede PST und OST beginnt mit der 4-Byte-Signatur !BDN (21 42 44 4E) an Offset 0. An Offset 8 kennzeichnet die Clientsignatur SM eine PST und SO eine OST; die 2-Byte-Versionsnummer an Offset 10 ist in einer ANSI-Datei 14 oder 15, während Unicode-Dateien 23 oder höher verwenden (OST-Dateien ab Outlook 2013 weisen häufig 36 auf, eine Variante mit 4 KB-Seiten). Ein PST-„Kennwort“ verschlüsselt die Daten nicht: Der Inhalt wird höchstens durch eine umkehrbare Kodierung verschleiert, die Parsing-Werkzeuge ohne das Kennwort rückgängig machen.

Eine OST ist der Offline-Cache eines Exchange- oder Microsoft 365-Postfachs im Exchange-Cache-Modus. Sie ist an das Outlook-Profil und das Konto gebunden, weshalb Outlook sie nicht als eigenständige Datei öffnet; forensische Parser lesen sie jedoch direkt. Eine OST kann noch Elemente enthalten, die inzwischen auf dem Server gelöscht wurden, wenn der Client vor der Sicherung nicht synchronisiert wurde oder die Daten in nicht zugewiesenen Blöcken verbleiben. Sie kann auch unvollständig sein, da der Cache möglicherweise nur einen über einen Synchronisierungsregler festgelegten aktuellen Zeitraum abdeckt.

Das neue Outlook für Windows speichert Daten anders und verwendet OST-Dateien nicht auf dieselbe Weise wie das klassische Outlook. Stellen Sie daher fest, welcher Client verwendet wurde, bevor Sie auf einen fehlenden Postfach-Cache schließen. Lektion 4.5 behandelt Webmail- und Cloud-Kontospuren.

Thunderbird-Profile

Thunderbird speichert alles unter %APPDATA%\Thunderbird\Profiles\<profile>\. POP- und lokale Konten befinden sich in Mail\, IMAP-Konten in ImapMail\<server>\. Jeder Ordner entspricht einer MBOX-Datei ohne Erweiterung (Inbox, Sent), in der jede Nachricht mit einer Trennzeile beginnt, die mit From anfängt (Thunderbird schreibt From - , gefolgt von einem Datum). Unterordner befinden sich in einem Verzeichnis mit dem Suffix .sbd. Jede MBOX hat eine zugehörige .msf-Datei, einen Index (Zusammenfassung), den Thunderbird neu erstellen kann; sie ist daher nicht der Nachrichtenspeicher. Eine gelöschte Nachricht wird zunächst nur als gelöscht markiert (Bit 0x0008 im Header X-Mozilla-Status) und bleibt in der MBOX, bis der Ordner komprimiert wird. Das Profil enthält außerdem global-messages-db.sqlite, den Suchindex, der Betreffzeilen, Beteiligte und indexierten Nachrichtentext enthält und kürzlich erfolgte Löschungen möglicherweise nicht sofort widerspiegelt. Profile, die auf das optionale Maildir-Format eingestellt sind, speichern stattdessen eine Datei pro Nachricht.

Einzelne Nachrichten: EML und MSG

Eine EML-Datei enthält eine Nachricht im Textformat gemäß RFC 5322, mit Header und MIME-Nachrichtenkörper genau in der übertragenen Form. Eine MSG-Datei ist ein einzelnes Outlook-Element, das als OLE-Verbunddatei gespeichert wird (Signatur D0 CF 11 E0 A1 B1 1A E1). Ihre Eigenschaften sind Streams mit dem Namen __substg1.0_<tag><type>; der ursprüngliche Internet-Header einer empfangenen Nachricht ist die Eigenschaft 0x007D. Suchen Sie daher nach dem Stream __substg1.0_007D001F (007D001E, wenn die Zeichenfolge als ANSI gespeichert ist).

Gelöschte Nachrichten

Das Löschen in Outlook erfolgt in mehreren Stufen. Ein normaler Löschvorgang verschiebt das Element nach Gelöschte Elemente, einem weiterhin gewöhnlichen Ordner. Das Leeren dieses Ordners oder Umschalt+Entf entfernt es aus dem Ordnerbaum; bei Exchange- und Microsoft 365-Postfächern bewahrt der Server es anschließend für eine Aufbewahrungsfrist im Ordner Wiederherstellbare Elemente auf. Dies ist eine serverseitige Quelle, für die eine rechtliche Anforderung oder ein Mandantenexport erforderlich ist, statt einer Sicherung vom Endgerät. Innerhalb der PST oder OST werden die freigegebenen Blöcke nicht sofort überschrieben, sodass Parser gelöschte und verwaiste Elemente aus nicht zugewiesenem PST-Speicherplatz wiederherstellen können. Das Open-Source-Werkzeug pffexport aus libpff kann wiederhergestellte Elemente zusammen mit regulären Elementen exportieren; readpst konvertiert PST-Inhalte in MBOX- oder EML-Dateien. Kommerzielle PST-Anzeigeprogramme und forensische E-Mail-Programmpakete erledigen dasselbe über eine grafische Oberfläche, und eine Arbeitskopie eines Thunderbird-Profils kann in Thunderbird selbst geprüft werden. Geben Sie stets an, mit welcher Methode die jeweilige Nachricht gewonnen wurde.

Den Header lesen

RFC 5322 definiert den Nachrichtenheader. Die meisten Felder werden vom Client des Absenders eingetragen und beweisen nichts über die Herkunft.

Die Received-Kette

Jeder Server, der die Nachricht annimmt, fügt ganz oben einen Received-Header hinzu. Daher steht die neueste Übertragungsstation zuerst, und der Übertragungsweg wird von unten nach oben gelesen. Eine typische Zeile hat die Form from <claimed host> (<reverse DNS> [<IP>]) by <receiving host> with <protocol> id <queue ID>; <date>. Der Name nach from ist die Angabe, mit der sich das verbindende System vorgestellt hat, und kann beliebig sein; die IP in eckigen Klammern wurde vom empfangenden Server anhand der TCP-Verbindung aufgezeichnet. Die Protokollangabe verrät mehr: ESMTPS bedeutet TLS, und ESMTPSA bedeutet, dass sich der Client authentifiziert hat, was die Einlieferungsstation kennzeichnet.

Bestimmen Sie die Vertrauensgrenze: den untersten Received-Header, der von einem Server geschrieben wurde, dem Sie vertrauen, normalerweise dem MX der Empfängerorganisation. Die von ihm aufgezeichnete IP ist verlässlich. Alles darunter wurde von Systemen außerhalb Ihrer Kontrolle geschrieben und kann gefälscht sein. Behandeln Sie daher eine dort gefundene Ursprungs-IP als Ermittlungsansatz, der beispielsweise durch die Protokolle des Anbieters bestätigt werden muss. Rechnen Sie die Zeit jeder Übertragungsstation in UTC um, berechnen Sie die Verzögerungen und prüfen Sie, ob die Zeiten ansteigen; eine negative Verzögerung von Sekunden ist eine Uhrabweichung, während Minuten oder Stunden auf eine falsch gehende Uhr, eine Nachricht in der Warteschlange oder einen gefälschten Header hindeuten.

Authentifizierungsergebnisse: SPF, DKIM, DMARC und ARC

Der Server des Empfängers zeichnet seine Prüfungen in Authentication-Results (oder dem älteren Received-SPF) auf.

• SPF prüft, ob die verbindende IP für die Domain des Envelope-Absenders senden darf, dargestellt als spf=pass smtp.mailfrom=<address>. Es sagt nichts über das sichtbare From aus.
• DKIM überprüft eine Signatur in DKIM-Signature, wobei d= die signierende Domain und s= der Selektor ist; der öffentliche Schlüssel wird unter <selector>._domainkey.<domain> veröffentlicht. Das Ergebnis ist dkim=pass oder dkim=fail mit header.d=.
• DMARC ist nur dann erfolgreich, wenn SPF oder DKIM erfolgreich ist und diese Domain mit der From-Domain übereinstimmt. Es ist das einzige der drei Verfahren, das die für den Benutzer sichtbare Adresse schützt.
• ARC-Header (ARC-Seal, ARC-Message-Signature, ARC-Authentication-Results, nummeriert mit i=1, i=2…) bewahren frühere Ergebnisse auf, wenn eine Mailingliste oder ein Weiterleitungsdienst die Nachricht verändert.

Phishing-Indikatoren sind ein Anzeigename, der eine Marke nachahmt, während die Adresse abweicht, unterschiedliche Domains in From, Return-Path und Reply-To sowie dmarc=fail.

Durchgerechnetes Beispiel: eine Phishing-Nachricht

Ein Benutzer bei corp.example erhielt eine Nachricht, die scheinbar von einer Bank stammt. Der Header enthält (von oben nach unten):

Gehen Sie von unten nach oben vor und rechnen Sie um. UTC = Ortszeit minus Zeitversatz.

Die Zeiten steigen durchgängig an, und der gesamte Übertragungsweg dauerte 41 s. Der Date-Header ergibt umgerechnet 09:06:10 + 3 h = 12:06:10Z, also 7 min 48 s vor der Einlieferung: ein absenderseitiger Wert einer Nachricht aus einer Warteschlange oder einer falsch gehenden Uhr, keine als Empfangszeit anzugebende Zeit.

Vertrauensgrenze. R2 ist der erste Header, der vom eigenen MX des Empfängers geschrieben wurde. Daher ist die verlässlich aufgezeichnete Quelle 198.51.100.27. R3 und R4 wurden von der Infrastruktur des Absenders geschrieben; R4 nennt 203.0.113.45 als den Client, der sich authentifiziert hat (ESMTPSA), offenbar von einer privaten Adresse hinter NAT aus (HELO [192.168.1.23]). Geben Sie diese als behauptete Ursprungs-IP an, die durch den Anbieter von bank-secure.example bestätigt werden muss.

Bewertungen. SPF und DKIM sind beide erfolgreich, jedoch für bank-secure.example. DMARC schlägt fehl, weil keine der beiden Domains mit bank.example in From übereinstimmt, und die Richtlinie p=none der Bank ließ die Nachricht passieren. Da Antworten an eine Freemail-Adresse umgeleitet werden und die Message-ID von einem Hosting-VPS stammt, lautet die Schlussfolgerung: gefälschter Absender, über eine vom Angreifer kontrollierte Infrastruktur versendet, von der Organisation um 2026-03-03T12:14:37Z empfangen.

MIME-Struktur und Hashwerte von Anhängen

Eine Nachricht mit Anhängen ist üblicherweise multipart/mixed: Ein Teil ist ein verschachtelter multipart/alternative mit text/plain- und text/html-Versionen des Nachrichtenkörpers, und jeder weitere Teil ist ein Anhang mit Content-Disposition: attachment; filename="invoice.pdf". Die Teile werden durch die in Content-Type deklarierte boundary-Zeichenfolge getrennt. Binäre Anhänge verwenden Content-Transfer-Encoding: base64, wobei jeweils 4 Zeichen 3 Bytes kodieren, in Zeilen mit höchstens 76 Zeichen. Berechnen Sie den Hashwert der dekodierten Bytes, niemals des Base64-Texts: Ein PDF-Teil, der mit JVBERi0xLjcK beginnt, wird zu %PDF-1.7 plus einem Zeilenumbruch dekodiert. Nur der SHA-256-Hashwert der dekodierten Datei stimmt mit einer andernorts gefundenen Kopie überein, etwa im Downloads-Ordner oder im sicheren temporären Ordner von Outlook (dessen Pfad steht im Registrierungswert OutlookSecureTempFolder).

Prüfungsschwerpunkt: Rechnen Sie damit, eine Received-Kette von unten nach oben zu lesen, Zeiten von Übertragungsstationen mit unterschiedlichen Zeitversätzen in UTC umzurechnen und zwischen der vertrauenswürdigen Empfangszeit und dem Date-Header zu wählen. Seien Sie darauf vorbereitet, die erste verlässliche IP zu benennen, zu erklären, warum SPF und DKIM erfolgreich sein können, während DMARC fehlschlägt, und den Hashwert eines dekodierten Anhangs zu berechnen. Kennen Sie die Signatur !BDN, die Standardpfade von PST und OST sowie die Tatsache, dass Thunderbird noch nicht endgültig entfernte gelöschte Nachrichten bis zur Komprimierung in der MBOX aufbewahrt.

Kernpunkte

• PST- und OST-Dateien beginnen mit !BDN; die OST ist ein profilgebundener Cache, der bereits auf dem Server gelöschte Elemente enthalten kann, und gelöschte Elemente können aus nicht zugewiesenen PST-Blöcken wiederhergestellt werden.
• Thunderbird speichert pro Ordner eine MBOX-Datei, mit .msf-Indizes und global-messages-db.sqlite; gelöschte Nachrichten bleiben bis zur Komprimierung in der MBOX.
• Received-Header werden ganz oben hinzugefügt. Lesen Sie sie daher von unten nach oben und vertrauen Sie nur den Übertragungsstationen, die Ihre eigenen Server eingetragen haben.
• Geben Sie als Empfangszeit die Received-Zeit des vertrauenswürdigen Servers in UTC an; der Date-Header ist eine Behauptung des Absenders.
• DMARC verknüpft SPF oder DKIM mit der sichtbaren From-Domain; erfolgreiche SPF- und DKIM-Prüfungen für eine andere Domain authentifizieren den Absender nicht.
• Berechnen Sie Hashwerte von Anhängen nach der Base64-Dekodierung.