Forensik

Es passiert selten aber vielleicht ist ihnen oder einem Kunden von ihnen das schon mal passiert: Ein Mail ist in einem Postfach gelandet, die dort nie hätte landen sollen weil sie...

  • Informationen enthält, die der Empfänger nie hätte bekommen sollen
  • Der Inhalt strafbar, ehrverletzend, rassistisch o.ä., ist.
  • Verleumdungen enthält
  • Und viele andere üble Dinge

Auf jeden Fall kommt eine entsprechende Person auf den Administrator der Exchange Umgebung zu, und bittet um die Sicherung der entsprechenden Informationen, um z.B.. den urheber zu ermitteln. Da kommt es darauf an, das System und die Stellen zu können, an denen Sie nachschauen können. Unabhängig ob der Empfänger intern oder extern war, ist die Suche nach der Quelle natürlich das primäre Ziel. Kam die Mail von Extern und wurde nur vorgegeben von intern zu sein oder wurde die Mail sogar von intern versendet ? Exchange protokolliert per Default sehr viele Dinge und man muss nur an den richtigen Stellen suchen.

 

Hinweise und Ideen zur Analyse von Dateneinbrüchen in Exchange.

Es gibt mehrere Wege eine aktive oder vergangene unerlaubte Nutzung zu erkennen bzw. zu diagnostizieren. Voraussetzung ist aber, dass die Spuren nicht verwischt wurden und einige Einstellungen durchgeführt wurden. Leider sind in der Standardeinstellung die meisten Überwachungsfunktionen abgeschaltet! An folgenden Stellen können Sie "suchen":

  • Exchange Nachrichtentracking
    per Default nicht aktiv
    werden oft nach 7 bzw. 30 Tagen gelöscht
    kann von Administratoren gelöscht, verändert deaktiviert werden
    Jede Mail, die Exchange überträgt,. wird hier protokolliert. Damit ist es möglich Weiterleitungen, Regeln aber auch dern Versand von Informationen an externe oder andere Postfächer zu erkennen. Leider sieht man nicht die Inhalte. (Hinweis: Archivlösungen können hier aber oft helfen, da Sie jede Mail archivieren und der Anwender diese nicht löschen kann. Echte Angreifer werden Infos aber eher über andere Kommunikationswege übermitteln. (Freemailer, Papier, USB-Stick etc.)
  • Gesendete/Gelöschte Objekte
    kann vom Anwender gelöscht werden
    Oft übersehen Anwender, dass versendete Mails in "Gesendete Objekte" liegen. Mit entsprechenden Rechten kann man daher im Verdächtigen Quell aber auch Zielpostfach nach Spuren suchen.
  • Zugriffsprotokoll im Eventlog
    muss aktiviert werden
    kann von Administratoren gelöscht, deaktiviert werden
    Zugriff auf ein Postfach oder einen Store können ab Exchange 2000/2003 bei Aktivierung der richtigen Einstellungen im Sicherheitseventlog erkannt werden. Auch Zugriffe per POP3 etc. können hier bei Aktivierung einiger Diagnoseeinstellungen erkannt werden
  • IISLogs
    muss aktiviert werden
    kann von Administratoren gelöscht, verändert, deaktiviert werden
    Erfolgt der Zugriff per pop3; IMAP4, OWA, dann kann in den Logfiles des IIS erkannt werden.
  • Exchange Berechtigungen
    Kann von Administratoren verändert werden
    Um in ein Postfach oder einen öffentlichen Ordner zu schauen, muss der Anwender die notwendigen Rechte habe. Bei Exchange 5.5. ist hierzu das Dienstkonto bzw. der Administrator des Exchange Standorte berechtigt bzw. kann anderen Personen die Rechte geben. bei Exchange 2000/2003 ist der ADmin nicht mehr berechtigt und im native Mode gibt es kein Dienstkonto. Aber hier kann auf dem jeweiligen Informationsspeicher selbst das Recht gegeben werden. Alternativ kann ein Angreifer sich auf dem Postfach selbst (Exchange Berechtigungen des Users) das Recht auf das Postfach geben bzw. der Anwender kann es selbst tun. Sehr oft werden Computer nicht gesperrt, so dass z.B. ein Angreifer in einem unbeobachteten Moment im Outlook der Zielperson sich selbst als "Stellvertreter" eintragen kann. Dies erkennt der Anwender selbst meist nicht auf Abhieb. Solche Zugriffe sind aber im Eventlog nachweisbar (wenn aktiviert)
  • NetMon
    Nur für aktuell aktive Angriffe nutzbar
    Systemzugriff erforderlich
    Der Mitschnitt der Netzwerkpakete ist nur bei aktiven Zugriffen möglich und erfordert sehr viel Erfahrung und passende Filter und ist daher kaum praktikabel bzw. zum in Verbindung mit Intrusion Detection Systemen. MAPI Zugriffs sind verschlüsselt und kaum zu decodieren. Die Überwachung und Kontrolle mit Patterns ist aber für POP3, IMAP4, HTTP (alles ohne SSL) möglich.
  • Backups
    Gerade Protokolldateien und auch der Inhalt von "Gesendete Objekte" werden nicht sofort gelöscht. So kann es sein, dass diese auf einem älteren Backup vielleicht noch vorhanden sind.
  • Anmeldungen im Sicherheitseventlog
    muss erst aktiviert werden
    Kann von Administratoren gelöscht werden
    Sie können unter Windows die "Anmeldung/Abmeldung" von Benutzern überwachen lassen, so dass erfolgreiche und fehlerhafte Anmeldungen an Diensten im Sicherheitseventlog aufgeführt werden. Über diese Funktion lässt sich natürlich feststellen, ob ein Benutzerkonto gesperrt oder "versucht" wurde. Seit Windows 2003 erhalten Sie noch ausführlichere Informationen über den Dienst und den Client. Dies können Hinweise sein, um den Täter und Tatzeitpunkt weiter einzukreisen.
  • IP-Adressen tracken Internet Proxy und Webserver
    nur ergänzend zur Qualifizierung des Angreifers
    Wenn Sie IP-Adresse des fraglichen Systems feststeht, aber der Benutzer noch nicht zu ermitteln ist, dann kann es hilfreich sein, andere Dienste zu kontrollieren. Vielleicht hat der Angreifer parallel im Internet gesurft oder die Daten sogar über diesen Weg nach außen gesendet oder andere Informationen im Internet abgerufen, die Rückschlüsse auf die Person zulassen.

Sie sehen also, dass es sehr viele Stellen gibt, an denen Sie kleine Puzzlestücke finden können, aus denen dann am Ende ein Gesamtbild gibt. Ob dies natürlich zu einer lückenlosen Beweiskette führt, ist nicht sicher gestellt.

Grenzen

Am Ende kann dabei aber nur heraus kommen, von welchem Computer (IP-Adresse, NetBIOS Name) bzw. mit welchen Benutzerkonto (AD-Account) der Zugriff erfolgte. Leider sind diese beiden Informationen nur bedingt beweistauglich, da die IP-Adresse auch bei fester Vergabe keinen 100%tigen Rückschluss auf den Arbeitsplatz zulässt und der Zugriff über ein Benutzerkonto auch keine Aussage zulässt, wer letztlich das Benutzerkonto genutzt hat. So kann es durchaus sein, dass jemand das Kennwort eines anderen Benutzers kennt oder über einen Keylogger, Trojaner ö.ä. dieses ermittelt hat oder den PC fern bedient.

Insofern ist der beste Schutz eine klare Vergabe und Kontrolle der Berechtigungen, so dass ein Übergriff gar nicht erst möglich ist. Denn die Veruntreuung von Informationen können Sie nicht rückgängig machen.

Die folgenden Quellen sind natürlich nur so vertrauenswürdig, wie Sie nicht geändert worden sind.

Wenn jemand eine Mail durch Exchange routet, dann gibt es eine Quelle und

An den folgen Stellen können Sie also nachschauen

  1. HubTransport: Messagetracing
    Hier wird jede Mail protokolliert, die Exchange überträgt. Wenn eine Mail von Exchange empfangen, gesendet oder zugestellt wurde, dann ist hier der Weg nachvollziehbar
  2. RCA-Logs
    Exchange protokolliert durchaus auch Aktionen von Clients einen eigenen Logfiles mit, über die Sie z.B. ermitteln können, wie eine Mail in ein Postfach gelangt ist
  3. IISLogs
    Das gleiche gilt natürlich auch für Zugriffe per OWA. Mit der Information des Zeitpunkts können Sie vielleicht erkennen, von welchem Client in der Zeit das Postfach genutzt wurde.
  4. SMTP-Transport
    Wird eine Mail per SMTP zugestellt, dann steht es im Messagetracking. Sie können aber auch im SMTP-Logs eventuell weitere Informationen erhalten.
  5. Anmeldungen im DC Eventlog
    Wenn heraus kommt., dass die Mail von einem internen Postfach gekommen ist und die Benutzer eingekreist sind, dann kann das Eventlog auf den Domaincontrollern helfen die Anmeldeprofile eines Benutzers zu ermitteln und damit den Client einzukreisen.

Je nach Umgebung gibt es sicher noch weitere Logfiles, z.B. TMG, ReverseProxy etc und auch in Exchange lassen sich noch zusätzliche Protokollfunktionen aktivieren. Aber letztlich können die mit etwas Glück den Benutzer oder bei anonymen Zugriffen die IP-Adresse des Clients ermitteln. Wer aber letztlich davor gesessen hat, können Sie nicht in Erfahrung bringen. Noch zeichnen die Webcams kein Bild der Personen am PC auf. Es kann auch durchaus sein, dass jemand mit "SendAs" oder "Full Access" die Mail versendet hat, der Anwender sein Gerät nicht gesichert hatte oder natürlich der Anwender einen Virus oder Trojaner mitschleppt, der mit den Anmeldedaten des Anwenders agiert hat. Die Beweisbarkeit anhand von Logfiles hat seine Grenzen.

Vorbemerkung zu IP und Zeit

An vielen Stellen werden Sie mit Zeitstempeln und IP-Adressen arbeiten. Vertrauen Sie diesen Daten niemals zu 100%, denn alle Zeitangaben in Protokolldateien beziehen sich in der Regel auf die lokale Zeit des protokollierenden Systems. Sobald mehrere Systeme beteiligt sind, müssen Sie kontrollieren, wie stark die Systeme abweichen und selbst dann ist man nie sicher, dass zum Zeitpunkt des Vorfalls die Differenzen nicht andere waren. Auch sollten Sie immer das Thema Zeitzone und Sommerzeit/Winterzeit im Auge haben. Der IIS protokolliert gerne mit GMT, also 1-2 Stunden "vor" der deutschen Normalzeit.

Ein zweiter Punkt ist die IP-Adresse. Die meisten Protokolle nutzen TCP und damit eine Verbindung besteht, müssen die Partner auch tatsächlich miteinander sprechen. Ein Paket mit gefälschter IP-Adresse kommt am Ziel vielleicht an, aber die Rückantwort verläuft sich, zumindest wenn der Angreifer nicht im gleichen LAN ist, ARP-Spoofing einsetzt oder sich mit anderen Tricks verschleiert.

Wenn ein PC heute eine IP-Adresse hat, dann ist das aber keine Garantie, dass er zum Zeitpunkt des Eingriffs die gleiche IP-Adresse hatte. Es ist zwar wahrscheinlich aber eben nicht sicher. Genau genommen müssten Sie auch die ARP-Anfragen der Clients protokollieren und die MAC-Adressen im Switch auf Ports zuweisen. Dann können sie aber schon recht nahe das System einkreisen, welches die Daten versendet hat. Aber selbst dann kann dieses System missbraucht worden sein und der Anwender davor hat gar nichts bemerkt.

Ein weiterer Faktor bei den IP-Adressen sind Loadbalancer. Gerade bei einer "Single Arm Konfiguration" ersetzt der Loadbalancer die IP-Adresse des Clients auf dem Weg zum Server durch seine eigene IP-Adresse. Nur so kommen die Daten des Servers wieder über den Loadbalancer zurück. Der große Nachteil dieser Konfiguration besteht darin, dass der Server selbst nicht mehr die IP-Adresse des Clients sondern alle Clients hinter der IP-Adresse des Loadbalancers versteckt sind. In diesem Fall müssten die die Logdateien des Loadbalancers für eine Analyse heran ziehen.

Messagetracking mit Exchange 2010

Erste Anlaufstelle ist das Exchange Messagetracking, welches Exchange per Default für 30 Tage mitspeichert. Sie sollten sich also z.B. den Empfänger oder den Betreff der fraglichen Mail besorgen und danach im Messagetracking nachsuchen.

Beachten Sie dazu auch die Seite Message Tracking Grundlagen

 

 Wenn Sie den "Betreff" haben und die Mails nicht weniger als einen Tag zurück liegt, dann kann folgender Befehl helfen.

(get-transportserver | get-messagetrackinglog -messagesubject "GeheimeMail" -start (get-date).adddays(-1))[0]

In der Regel ist der erste Eintrag auch der älteste und damit der interessanteste Datensatz. Er enthält den Client aus Sicht der Hub-Transport-Rolle. Sie sollten hier also erkennen, ob die Mails per MAPI aus dem Postausgang des Postfachs oder per SMTP eingeliefert wurde. Hier die drei Beispiele des ersten Datensatze für Outlook (MAPI), OWA, ActiveSync und externer Eingang per SMTP

# Mail mit OWA gesendet

Timestamp                     EventId                       Source                        MessageSubject
---------                     -------                       ------                        --------------
20.03.2013 21:48:54           SUBMIT                        STOREDRIVER                   GeheimeMail OWA
20.03.2013 21:48:54           RECEIVE                       STOREDRIVER                   GeheimeMail OWA
20.03.2013 21:48:55           TRANSFER                      ROUTING                       GeheimeMail OWA
20.03.2013 21:48:55           SEND                          SMTP                          GeheimeMail OWA


Timestamp : 20.03.2013 21:48:55
ClientIp : fe80::88e0:5f25:ec62:97c8%10
ClientHostname : NAWEX001
ServerIp :
ServerHostname : NAWEX001
SourceContext : MDB:196a8f6b-2096-418e-8dd0-19c4c13fb0dc, Mailbox:e6721880-50d5-41a6-960c-6db2f5b1eb2a, Event
:85974944, MessageClass:IPM.Note, CreationTime:2013-03-20T20:48:54.892Z, ClientType:OWA
Source : STOREDRIVER
EventId : SUBMIT
MessageSubject : GeheimeMail OWA
# Mail mit Outlook gesendet

Timestamp                     EventId                       Source                        MessageSubject
---------                     -------                       ------                        --------------
20.03.2013 21:47:34           SUBMIT                        STOREDRIVER                   GeheimeMail Outlook
20.03.2013 21:47:34           RECEIVE                       STOREDRIVER                   GeheimeMail Outlook
20.03.2013 21:47:34           TRANSFER                      ROUTING                       GeheimeMail Outlook
20.03.2013 21:47:35           SEND                          SMTP                          GeheimeMail Outlook


ClientIp : fe80::88e0:5f25:ec62:97c8%10
ClientHostname : NAWEX001
ServerIp :
ServerHostname : NAWEX001
SourceContext : MDB:196a8f6b-2096-418e-8dd0-19c4c13fb0dc, Mailbox:e6721880-50d5-41a6-960c-6db2f5b1eb2a, Event
:85974865, MessageClass:IPM.Note, CreationTime:2013-03-20T20:47:33.529Z, ClientType:MOMT
Source : STOREDRIVER
EventId : SUBMIT
MessageSubject : GeheimeMail Outlook
# Mail mit ActiveSync gesendet


Timestamp                     EventId                       Source                        MessageSubject
---------                     -------                       ------                        --------------
20.03.2013 21:56:17           SUBMIT                        STOREDRIVER                   GeheimeMail Mobil
20.03.2013 21:56:17           RECEIVE                       STOREDRIVER                   GeheimeMail Mobil
20.03.2013 21:56:17           TRANSFER                      ROUTING                       GeheimeMail Mobil
20.03.2013 21:56:19           SEND                          SMTP                          GeheimeMail Mobil


Timestamp : 20.03.2013 21:56:17
ClientIp : fe80::88e0:5f25:ec62:97c8%10
ClientHostname : NAWEX001
ServerIp :
ServerHostname : NAWEX001
SourceContext : MDB:196a8f6b-2096-418e-8dd0-19c4c13fb0dc, Mailbox:e6721880-50d5-41a6-960c-6db2f5b1eb2a, Event
:85975210, MessageClass:IPM.Note, CreationTime:2013-03-20T20:56:15.855Z, ClientType:AirSync
Source : STOREDRIVER
EventId : SUBMIT
MessageSubject : GeheimeMail Mobil

# Mail per SMTP anonym gesendet

EventId  Source   Sender                            Recipients                        MessageSubject
-------  ------   ------                            ----------                        --------------
RECEIVE  SMTP     fra---nk@carius.de                   {frank.carius@netatwork.de}       GeheimeMail extern
RECEIVE  MAILB... fra---nk@carius.de                   {fcarius@msxfaq.net}              GeheimeMail extern
DELIVER  STORE... fra---nk@carius.de                   {frank.carius@netatwork.de}       GeheimeMail extern


Timestamp : 20.03.2013 22:05:00
ClientIp : 192.168.100.18
ClientHostname : mail.netatwork.de
ServerIp : 192.168.100.8
ServerHostname : NAWEX001
SourceContext : 08CFC8A85F954CA2;2013-03-20T21:05:00.009Z;0
ConnectorId : NAWEX001\Default NAWEX001 + Anonym
Source : SMTP
EventId : RECEIVE
InternalMessageId : 307626
MessageSubject : GeheimeMail extern
# Mail per SMTP authentifiziert gesendet

EventId  Source   Sender                            Recipients                        MessageSubject
-------  ------   ------                            ----------                        --------------
RECEIVE  SMTP     fra---nk@carius.de                   {frank.carius@netatwork.de}       GeheimeMail extern
RECEIVE  MAILB... fra---nk@carius.de                   {fcarius@msxfaq.net}              GeheimeMail extern
DELIVER  STORE... fra---nk@carius.de                   {frank.carius@netatwork.de}       GeheimeMail extern

Timestamp : 20.03.2013 22:37:57
ClientIp : 192.168.103.35
ClientHostname : [192.168.103.35]
ServerIp : 192.168.100.8
ServerHostname : NAWEX001
SourceContext : 08CFC8A85F954D22;2013-03-20T21:37:54.769Z;0
ConnectorId : NAWEX001\Client NAWEX001
Source : SMTP
EventId : RECEIVE
MessageSubject : GeheimeMail SMTPAuth

Es ist gut zu sehen, dass egal welchen Ursprung die Mail nimmt. Der erste Eintrag ist der "SUBMIT STORE" Eintrag, über den die Mail dem Hub-Transport signalisiert wird. Noch interessanter ist aber der "SourceContext" eben dieser Zeile. Hier ist der "ClientType" zu sehen. Nur bei der letzten Mail, die per SMTP zugestellt wurde, ist die "ConnectorID" mit dem Namen des Receive Connectors. Diese Mail kam also anonym per SMTP beim Server an. Die letzte Mail hingegen ist per SMTP mit Authentifizierung über den Client Connector angekommen. Leider gibt es in diesem ersten Datensatz keine Information, dass die Mail authentifiziert eingegangen ist.

Auch eine Betrachtung der "Client-IP" hilft hier nicht weiter da hier bei Zugriffen per OWA, ActiveSync und MAPI (MOMT bei Exchange 2010) als Adresse immer der CAS-Server erscheint und nicht der echte Client. Nur bei einer Zustellung per SMTP kann der HubTransport die IP-Adresse des Absenders protokollieren. Aber auch hier kann ihnen der Loadbalancer einen Strich durch die Rechnung machen. Wenn dieser nämlich als "Single-Arm"-Konfiguration arbeitet und die Quell-IP-Adresse durch seine Adresse ersetzen muss, damit Rückpakete den gleichen Weg nehmen, dann sehen Sie auf dem CAS und dem HubTransport nur noch Zugriffe von dem Loadbalancer.

Weitere Links