Die dynamische Codeanalyse ist neben der statischen die komplexeste Analyseart im Malwareanalyse-Prozess. Im Grunde wird die Malware, wie bei der dynamischen Analyse, in einer isolierten Umgebung ausgeführt. Der Unterschied liegt darin, dass die Ausführung in einem Debugger kontrolliert durch den Analysten stattfindet, wodurch eine sehr detaillierte Analyse möglich wird. Die eigene Kontrolle ermöglicht Analysen von einzelnen oder mehreren Instruktionen, aber auch von ganzen Funktionen oder Programmen. Generell kann zwischen zwei Einstiegsmöglichkeiten zum Debugging unterschieden werden. Entweder wird der Debugger in einen laufenden Prozess eingehängt oder der Debugger startet einen neuen Prozess. Welcher Weg gewählt wird, hängt von der vorliegenden Konstellation ab. Ist der Debugging-Prozess gestartet kann er durch den Analysten auf zwei Weisen kontrolliert werden. Einerseits durch Befehle (Continue/Run, Step into, Step over etc.) oder durch das Setzen von Breakpoints. Es gibt unterschiedliche Arten von Breakpoints die genutzt werden können. Darauf möchte ich aber nicht weiter eingehen. Generell ermöglicht die Unterbrechung des Programmablaufs die genauere Analyse von Speicher- und Stackaufbau sowie des Inhalt der Register. Der Analyst kann daher sehr gezielt die Status verschiedener Variablen untersuchen, um Hinweise auf die Funktionalität der Malware zu erhalten. Daraus können letztlich Rückschlüsse auf die Auswirkungen auf das angegriffene System gefunden werden. Zur dynamischen Codenanalyse kann entweder IDA Pro Free oder auch OllyDbg verwendet werden. Problematisch ist allerdings, dass in der heutigen Malware einige Mechanismen bestehen, die diese Analysetechnik erschweren.
Ich hoffe du konntest aus der Artikelserie einige Dinge lernen und für deinen Einstieg in die komplexe Materie der Malwareanalyse nutzen.
Ein weiterer Schritt in dem Prozess der Malwareanalyse stellt die statische Codeanalyse dar. Bei diesem Schritt kommt es nicht zur Ausführung der mutmaßlichen Malware, stattdessen findet eine genaue Betrachtung des Programmcodes statt. Ziel ist es die inneren Abläufe und Komponenten der vorliegenden schädlichen Datei noch besser zu verstehen.Da die Malware in der Regel als Binärdatei zur Untersuchung vorliegt, müssen Techniken des Reverse Engineerings angewandt werden. D.h. die in Maschinencode vorliegende Binärdatei muss mithilfe einer Disassemblierung zurück in Assemblersprache übersetzt werden, sodass sie für Menschen lesbar wird. Anzumerken ist hier, dass der Malware-Analyst sehr gute Kenntnisse über die Assemblersprache haben muss, insbesondere auch deshalb, da diese von der jeweiligen Prozessorarchitektur abhängig ist. Ein gewisses Grundverständnis einer bestimmten Architektur erleichtert hier jedoch die Transformation auf andere Prozessorarchitekturen. Am häufigsten auf dem Markt vertreten ist die Prozessorarchitektur IA-32 von Intel. Nach dem Disassemblieren folgt die Analyse des Assemblercodes. Der Analyst sollte hier nicht Zeile für Zeile analysieren, da dies sehr zeitaufwendig werden kann, sondern vielmehr versuchen den Code zu gruppieren und auf einzelne Konstrukte zu fokussieren. Diese Konstrukte bieten letztlich Anhaltspunkte für die Übersetzung in eine Hochsprache (meist die Hochsprachen C und C++).
Da die Malwareanalyse ein umfangreicher Prozess ist, habe ich den Prozess in mehrere Artikel gegliedert, die dir einen Einblick in den die Thematik geben sollen.Malwareanalyse ist die Analyse der Verhaltensweise von Malware und daher als Teilgebiet des Reverse Engineerings zu verstehen. Erklärtes Ziel ist die Leistungsfähigkeit von Malware und deren Indikatoren zu ermitteln, um künftige Schutzmechanismen zu entwickeln. Zudem soll verstanden werden, welche Mechanismen ausgelöst werden, um ein System zu kompromittieren. Eine ganzheitliche Malwareanalyse besteht aus den folgenden Kategorien:
Um einen umfassenden Einblick in die Malware zu bekommen ist das Durchlaufen möglichst aller Kategorien notwendig. Dies ist jedoch nicht bei jedem Malware-Typ möglich, da Cyberkriminelle darauf bedacht sind ihre Malware gegen die Analyse zu schützen.
Statische Analyse Die statische Analyse ist in der Regel der erste Schritt der Malwareanalyse und dient einem ersten Überblick über die Funktionen, jedoch ohne Ausführung der Malware. Häufig wird nicht einmal der Quellcode der Malware genauer betrachtet. Es geht hier vielmehr darum mit effizienten Tools einen ersten Eindruck in die Malwarefunktionen, sowie deren Verhalten zu erhalten. Diese Erkenntnisse werden zur Einschätzung der Folgeschritte genutzt. Höher entwickelte Malware erschwer diese Analysekategorie jedoch mithilfe von Verschleierungs- und Verschlüsselungsmechanismen. Die einzelnen Schritte der statischen Analyse können variieren, weshalb ich hier die standardmäßigen Schritte vorstellen will. Ein erster Schritt ist häufig die Festlegung des Dateityps der vorliegenden Malware, womit das Zielsystem (z.B. Windows) und dessen Architektur (z.B. 64-Bit) ermittelt werden können. Ein erster Anhaltspunkt könnte die File-Extension (z.B. .exe, .pdf) liefern. Jedoch kann diese von einem Malwareautor sehr leicht verändert werden, sodass man im Bytecode nach typischen Bytesequenzen bzw. Strings für diesen Dateityp sucht. PE-Files (ausgeschrieben: Portable Executable Files, wie z.B. .exe oder .dll) haben bspw. den typischen String „…0x4D 0x5A…“ in den ersten zwei Bytes (Umgewandelt in ASCII-Zeichen: „…MZ…“). Der Bytecode kann, zur Analyse des Dateityps, automatisiert mittels entsprechender Programme auf diese Sequenzen abgeglichen werden. Ein weiterer Schritt ist das sog. Fingerprinting der Malware. Dabei wird die Malware gehasht, sodass ein identifizierender Hashstring entsteht. Dieser kann gegen eine Hash-Datenbank abgeglichen werden. So lässt sich eine schon bekannte Malware sehr schnell entlarven, auch wenn der Dateiname zunächst unverdächtig ist. Dieses Verfahren nutzen auch Antivirenprogramme (zum Artikel). Auch multiples Antiviren-Scanning der verdächtigen Datei ist von großer Bedeutung bei der statischen Analyse. Hierzu wird die verdächtige Datei auf ein Multi-Antiviren-Portal hochgeladen und automatisch mit deren Datenbank abgeglichen. Um dir dies bildlich zu zeigen, habe ich die Datei „smsniff.exe“ (Normales Programm der Nirsoft Suite) auf www.virustotal.com hochgeladen. Erkennbar sind der SHA-256 Hash, als auch andere Metadaten. Das Programm wird hier oft als unsicher bzw. „unwanted program“ oder „Tojan“ deklariert, was aus seiner Sniffing-Funktion resultiert. Mehrheitlich ist es jedoch als unbedenklich eingestuft.
Ebenfalls ein grundsätzlicher Schritt ist das Extrahieren von Strings aus der verdächtigen Datei. Diese Strings sind ASCII- und Unicode-Bytestrings, die Hinweise auf die Funktionalität von Malware geben können. Für diesen Schritt gibt es zahlreiche Programme, die automatisiert die Strings aus dem Code extrahieren (z.B. strings.exe aus der Sysinternal Suite).
Wichtiger Schritt: PE-Header Analyse Der umfangreichste Schritt der statischen Analyse stellt, im Falle von PE-Dateien, die Analyse des Headers dar. Im Grunde handelt es sich bei PE-Dateien um ein Set aus mehreren Unterkomponenten, die Informationen für das Betriebssystem bereitstellen und in der Regel importiert werden. Beim Kompilieren wird der PE-Header in die Gesamtdatei eingebunden und enthält Informationen über die Adressen wohin die PE-Datei in den Speicher geladen werden soll. Zudem enthält er eine Liste von Bibliotheken und Ressourcen auf die im Laufe der Ausführung zurückgegriffen wird. Die nachfolgende Tabelle zeigt die relevanten Headerfelder und die darin enthaltenen wertvollen Informationen für die statische Analyse.
Metadaten sind Informationen, die die Merkmale anderer Daten enthalten. Konkret auf ein Bild bezogen sind dies die Dateigröße, das Erstellungsdatum, die Anzahl der Pixel und vieles mehr. Neben den Inhaltsdaten, also dem was in einem Bild zu sehen ist, sind die Metadaten die wichtigste Informationsquelle für einen Ermittler in der IT-Forensik. Warum?Ganz einfach! Hier liegen so viele Daten, die einen normalen Nutzer wenig interessieren, die aber sehr viel über sein Verhalten verraten. Gerade bei Smartphones werden in der Regel Standorte in den Metadaten registriert (sog. Geotagging). Das ist schön für uns, wenn wir uns bei Urlaubsfotos per Google Maps später an den genauen Ort „zurückversetzen“ lassen wollen. Das ist aber auch schön für deinen Arbeitgeber, der dieses Bild in deinem Socialmedia-Account gefunden hat. Er fand dabei heraus, dass du dich in der Zeit in der du das Bild vom Strand in Thailand geschossen hast „krank gemeldet“ hast. Anhand der GPS-Daten konnte er dann ganz einfach herausfinden, dass du auf Ko Lon bei Phuket warst. Und als er dich darauf anspricht leugnest du die Sache und sagst, dass das ein Bild war, welches du irgendwo aus dem Internet heruntergeladen hast… Aber schade für dich. In den Metadaten steht in der Regel auch mit welchem Gerät das Foto gemacht wurde!
Wie bekomme ich nun diese Metadaten?…
Für diese Frage gibt es keine eindeutige Antwort, da es sehr viele Wege gibt solche Metadaten zu bekommen. Ich möchte dir nun einen einfachen Ansatz näher erläutern.
…mit dem Tool „IrfanView“
Wer den Foto-Viewer IrfanView auf seinem Computer hat kann die Metadaten sehr einfach auslesen. Über den Menüpunkt „Image“ –> „Information…“ lassen sich einfach Daten anzeigen. Interessant wird es aber erst, wenn man in diesem Popup-Fenster dann auf den Button „EXIF info“ geht. EXIF bedeutet Exchangeable Image Format und ist das Standardformat für die Speicherung von Metadaten bei Bildern. Wie ihr in dem Bild unten sehen könnt, sind wirklich viele Daten dabei sichtbar.
Das Bild habe ich geschossen, als ich den Artikel geschrieben habe (Eigentlich mache ich das Geotagging aus, da ich nicht will, dass Google weiß an welchen Orten ich meine Bilder machte).
In den EXIF-Daten ist zu sehen, dass ich das Bild mit einem Huawei Handy des Models „SNE-LX1“ geschossen habe. Eine kurze Suche in Google mit dem Begriff zeigt, dass es ein „Huawei Mate 20 lite“ war. Auch die genaue Softwareversion kann ausgelesen werden! Zudem sind Zeitstempel zu sehen, die Aufschluss über die Aufnahmezeit geben.Interessant wird es aber, wenn ich nach unten scrolle. Dort kann man sehen, dass die kompletten GPS-Daten mit in die Metadaten des Bildes geschrieben wurden. Sogar ein GPS-Zeitstempel wird registriert. Interessant..
Metadaten fälschen
Aber die Daten können trügerisch sein! Die GPS-Tags, die in meinen Metadaten zu sehen sind, sind nicht echt. Ich habe sie gefälscht. Dazu muss ich aber nicht digitale Forensik studieren. Ich musste hierzu lediglich ExifToolGUI herunterladen und konnte bequem die Metadaten bearbeiten. Ich öffnete darin das Bild und gab im Workspace ganz bequem neue Metadaten ein und speicherte sie ab. Das zeigt, dass es in der IT-Forensik sehr wichtig ist die gefundenen Informationen zu hinterfragen und mit anderen Spuren abzugleichen. Sind die Metadaten plausibel zu den anderen Metadaten? Können die Einträge wirklich echt sein?
Wie ihr hier im Bild seht, habe ich später mein Huawei zu einem „APPLE IPhoneX“ gemacht und den Eintrag in „Software“ auf „iOS 12.2.1“. Als IT-Forensiker könnte man nun im Internet prüfen, ob ein IPhone X wirklich solche Metadaten hinterlässt oder ob diese anders aussehen müssen. So hätten wir schon einen ersten Hinweis auf Änderung der Metadaten des Bildes. Im weiteren Verlauf müssten daher die Metadaten genauer mit weiteren gefundenen Bildern abgeglichen werden. Dies ist z.B. mit einer Zeitleiste grafisch sehr gut möglich, um die sog. MAC-Times abzugleichen (M = Modification, A = Access, C = Change). Diese spielen in den forensischen Analysen ohnehin bedeutende Rollen und werden in einem anderen Artikel noch erläutert werden.
Was haben die drei Themen IT-Security bzw. IT-Sicherheit, IT-Forensik und Hacking miteinander zu tun?
Die erste Antwort wäre spontan: ziemlich viel!
IT-Sicherheit ist Teil der Informationssicherheit. Vorrangig geht es hier um den Schutz von IT-Systemen, der darin enthaltenen Daten und deren Verarbeitung. Es geht dabei nicht nur um den Schutz deines Computers, sondern auch um den Schutz aller auf der Welt vorhandenen Server, Maschinen usw. Alle Komponenten in diesen Systemen können Sicherheitslücken aufweisen, weshalb es eine 100%ige Sicherheit nie geben kann. Durch geschickte Analysen (sog. Penetrationtests) und Schutzmaßnahmen kann man sich aber an diese Grenze annähern.
Hacking dagegen kommt von dem englischen Begriff „to hack“ und bedeutet im Zusammenhang mit Computern „in etwas eindringen“. Ein Hacker ist eine Person, die Dinge genau verstehen will und mit diesem Wissen die Mechanismen ausnutzen kann, um bösartige Aktionen durchzuführen. Trotz der negativen Besetzung des Begriffs hat Hacking auch etwas Gutes, was als „WhiteHat-Hacking“ bezeichnet wird. Darunter versteht man, dass IT-Sicherheitsspezialisten mit guten Absichten Systeme mit den Methoden von Hackern überprüfen und Sicherheitslücken aufspüren. Diese Penetrationtests dienen der Beseitigung bestehender Sicherheitslücken, sodass die Systeme immer sicherer werden. WhiteHat-Hacking kann demnach als Teil der IT-Sicherheit verstanden werden.
IT-Forensik wird im Leitfaden IT-Forensik des Bundesamt der Informationstechnik als „die streng methodisch vorgenommene Datenanalyse auf Datenträgern und in Computernetzen zur Aufklärung von Vorfällen, unter Einbeziehung der Möglichkeiten der strategischen Vorbereitung, insbesondere aus der Sicht des Anlagenbetreibers eines IT-Systems“ definiert. Das ist natürlich etwas kompliziert und bedeutet stark vereinfacht die Spurensuche auf Computersystemen zur Aufklärung von IT-Sicherheitsvorfällen. Ein guter Forensiker muss sowohl sehr gute Kenntnisse im Hacking, als auch von Maßnahmen der IT-Sicherheit haben. Eigentlich sollte er selbst sogar ein „Hacker“ sein und mit den Details verschiedener Computersysteme vertraut sein. Warum? Häufig muss man gerade im forensischen Prozess Sicherheitslücken ausnutzen, um die gewollten Daten zu bekommen.
Auch wenn Hacking und IT-Forensik gegensätzlicher nicht sein könnten sind sie doch miteinander verbunden. Hacking mit kriminellen Absichten dient dem Eindringen in ein Computersystem. IT-Forensik dient zur Aufklärung genau dieser Vorfälle nutzt aber teilweise selbst Methoden des Hackings. Man könnte es also so ausdrücken: Um ein guter IT-Forensiker zu sein muss man ein guter Hacker sein und umgekehrt!
