Erste Erfahrungen mit First Response

Kürzlich habe ich über die Freigabe einer neuen Version von MANDIANT First Response berichtet. Das Programm soll von einer zentralen Station aus die Live-Analyse ermöglichen, was sehr interessant klingt. Ich habe mir First Response deswegen einmal etwas genauer angesehen.

Nach dem Download der Version 1.1 von MANDIANT First Response bei c|net starte ich die Installation. Beim ersten Testlauf sind dabei bewußt nicht alle Systemvoraussetzungen erfüllt. Die Installationsroutine moniert erwartungsgemäß die fehlende .NET 2.0 Runtime. Die Fehlermeldung ist klar und hilfreich; der Installer verweist mich direkt auf die richtige Downloadseite bei Microsoft.

Nach dem Download von 22 Megabytes und einem Neustart ist die benötigte .NET 2.0 Runtime installiert. Jetzt läuft auch die Installationsroutine von First Response ohne weitere Schwierigkeiten. Zunächst erscheint ein Registrierungsdialog:

Registrierungsdialog

MANDIANT First Response ist eine Client-Server Anwendung. Der Anwender steuert das Programm weitestgehend über den Client, die First Response Command Console. Bei ihrem ersten Aufruf fragt sie nach einem Master-Passwort.

Festlegen des master-Passwortes

Dieses Passwort wird benötigt, um die Kommunikation zwischen Client und Server abzusichern und um die möglicherweise vertraulichen Audit-Ergebnisse auf der Festplatte zu verschlüsseln.

Die nächste Schritt besteht in der Installation des Servers, Agent genannt. Hier genügt es zunächst, auf Deploy zu klicken und ein Zielverzeichnis anzugeben. First Response erstellt dann die Dateien des Agents. Installiert wird die Software jedoch nicht, Sie können also unbesorgt auch ein Wechselmedium als Ziel angeben.

Den soeben erstellten Agenten können Sie nun entweder lokal oder auf entfernten Systemen ausführen. Außerdem müssen Sie sich entscheiden, ob Sie den Agenten von der Kommandozeile aus starten möchten, oder ob er als Systemdienst installiert werden soll. Einzelheiten hierzu finden Sie in der Online-Hilfe.

Für meinen Test verzichte ich auf die Installation als Dienst und führe den Agenten auf der Kommandozeile aus: fragent -d -bind:127.0.0.1 Diese Anweisung lässt den Agenten nur auf "localhost" auf Verbindungen warten. Per Voreinstellung akzeptiert er Verbindungen auf allen Interfaces.

Nachdem nun der Agent bereit ist, lege ich im Client "localhost" als neuen Host an und starte ein Audit. Im Fenster des Agenten beobachte ich den Verbindungsaufbau und die zahlreichen Ausgaben der einzelnen Audit-Schritte.

Starting an audit

Mit einem Doppelklick auf den Hosteintrag rufen Sie alle gespeicherten Audit-Daten ab. Die Ergebnisse werden thematisch auf mehrere Registerseiten aufgeteilt. System beschreibt die wichtigsten Eigenschaften des untersuchten Hosts, darunter Name, Windows-Version, Hauptspeicherausbau, CPU-Typ und -Geschwindigkeit.

Auswertung der Audit-Daten

Processes nennt alle für den Agent sichtbaren Prozesse mit PID, Startzeit und einigen weiteren Angaben. Die nächste Registerseite listet die offenen Ports und zeigt ihre Zuordnung zu Prozessen. Ausgewählte Registry Schlüssel erscheinen auf einer weiteren Seite. First Response liest auch die Event Logs aus und führt ihre Einträge zusammen. Services, die Systemdienste, werden mit ihrer PID, dem Konto und einer Beschreibung dargestellt. Tasks listet alle mit dem Dienstprogramm "at" und dem Scheduler für eine spätere bzw. wiederkehrende Ausführung definierten Kommandos auf. Die nächste Registerseite nennt auf dem Zielsystem aufgefundene Files mitsamt ihrer Zeitstempel. Kann schlißelich eine der Audit-Routinen nicht ausgeführt werden, so protokolliert First response dies auf der Seite Issues.

Alle Ergebnistabellen lassen sich nach jeder Spalte sortieren. Einträge könne mit einer von sechs Farben markiert werden. Auf der letzten Registerseite erstellen Sie aus allen markierten Einträgen einen Report. Der Bericht lässt sich anschließend als HTML-Datei speichern.

Markierte Einträge werden in den Bericht aufgenommen

Während des Tests ist mir aufgefallen, dass ein für Testzwecke definiertes Event Log von First Response nicht ausgewertet wird. Offenbar ist das Programm auf die drei standardmäßig vorhandenen Logs Anwendung, Sicherheit und System beschränkt.

Besonders interessiert hat mich, wie First Reponse die Prozesse enumeriert. Deshalb habe ich einen maliziösen Prozess (tatsächlich war es bloß das Notepad) gestartet und dann mit einer älteren Version des FU Rootkits versteckt. FU entfernt einen Prozess aus der vom Betriebssystem geführten doppelt verketteten Liste. Bei der Verwendung der API-Aufrufe ist der Prozess fortan unsichtbar. Entsprechend enttäuscht war ich, dass auch First Response mein maliziöses Notepad nicht mehr fand.

Ich folgere daraus, dass MANDIANT First Response lediglich die API-Funktionen benutzt. Je nach Art der zu entdeckenden und aufzuklärenden Angriffe kann das den Gebrauchswert des Programms einschränken. Dennoch ist First Response in der Version 1.1 ein klar strukturiertes und einfach zu nutzendes Werkzeug.

Archiv

Impressum

Dieses Blog ist ein Projekt von:
Andreas Schuster
Im Äuelchen 45
D-53177 Bonn
impressum@forensikblog.de

Copyright © 2005-2012 by
Andreas Schuster
Alle Rechte vorbehalten.