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...

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 kennen, 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":

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. 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     frank@carius.de                   {frank.carius@netatwork.de}       GeheimeMail extern
RECEIVE  MAILB... frank@carius.de                   {fcarius@msxfaq.net}              GeheimeMail extern
DELIVER  STORE... frank@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     frank@carius.de                   {frank.carius@netatwork.de}       GeheimeMail extern
RECEIVE  MAILB... frank@carius.de                   {fcarius@msxfaq.net}              GeheimeMail extern
DELIVER  STORE... frank@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 "ClientIP" 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

Keywords:Forensik Analyse Berechtigungen Protokollierung