Aufbau einer besseren Sandbox

Transkript

1 Whitepaper Aufbau einer besseren Sandbox Eine funktionierende Strategie für umfassenden Malware-Schutz

2 Inhaltsverzeichnis Die parallele Evolution von Malware und Erkennungsanalysen 3 Dynamische und statische Analyse im Vergleich 3 Leistungsdruck 3 Stufe 1: Erkennung bekannter Angriffe 4 Stufe 2: Schutz durch Echtzeit-Verhaltensanalyse 4 Stufe 3: Dynamische Analyse 5 Zielspezifische Sandbox 5 Die Bedeutung von Interaktion 5 Interpretation dynamischer Analysen 5 Stufe 4: Statische Code-Analyse 6 Packen, Entpacken und Reverse Engineering 7 Stufenweise Strategie für herausragenden Sandbox-Ansatz 9 2 Aufbau einer besseren Sandbox

3 Die parallele Evolution von Malware und Erkennungsanalysen Internetkriminelle und IT-Sicherheitsstrategen sind in einer immer engeren Spirale des Wettrüstens gefangen. Mit zunehmender Raffinesse und Verschleierungsfähigkeit von Malware, die zur Unterwanderung von IT-Umgebungen verwendet wird, kommen neue Technologien zum Einsatz, um selbst die am besten getarnten Nadeln im Heuhaufen zu finden. Eine der vielversprechendsten Entwicklungen auf der Defensivseite erfolgt im Bereich der Erkennung durch dynamische Analysen, auch als Sandbox bekannt. Derzeit sind zahlreiche solche Produkte verfügbar, und weitere stehen kurz vor der Einführung. Wenig überraschend weichen die Architekturansätze der führenden Anbieter erheblich voneinander ab, was auch an ihrer Rolle in der Sicherheitsstrategie liegt. Aktuell ist es schwierig, diese Technologien realistisch zu vergleichen oder auch nur sicherzustellen, dass selbst grundlegende Terminologien durchgängig Anwendung findet. In diesem Whitepaper wird eine logische Entwicklungsstrategie für dynamische Malware-Analysen vorgestellt, mit der die Effektivität, Effizienz sowie Wirtschaftlichkeit der Erkennung optimiert wird. Wir werden versuchen, die Grenzen der dynamischen Erkennung aufzuzeigen sowie ergänzende Methoden vorstellen, die für die Gewährleistung zuverlässiger Sicherheit notwendig sind. Zum Schluss schlagen wir wichtige Unterscheidungsmerkmale vor, die häufig aufgrund ungenauer Terminologien unklar sind. Dynamische und statische Analyse im Vergleich Der wahrscheinlich wichtigste Faktor bei jeder Untersuchung von Sandbox-Lösungen zur Analyse hochentwickelter Malware ist die Unterscheidung zwischen dynamischer und statischer Analyse. Bei der dynamischen Analyse werden ausführbare Dateien in einer sicheren (meist virtuellen) Umgebung ausgeführt. Dabei wird ihr Verhalten über einen definierten Zeitraum hinweg beobachtet, um auf diese Weise böswillige Dateien zu ermitteln. Wenn wir diesen Ansatz mit statischer Analyse vergleichen wollen, müssen wir zuerst einen häufigen Fehler bei der Benutzung dieses Begriffs ausräumen. Echte statische Analyse (die auch als statische Code-Analyse bezeichnet wird) trifft eine Vorhersage über das wahrscheinliche Verhalten einer ausführbaren Datei. Dazu führt sie eine detaillierte Untersuchung ihres Codes durch. Der Begriff statische Analyse wird häufig fälschlicherweise auf einfachere und weniger präzise Techniken angewandt, die als statische Dateianalysen bezeichnet werden und beispielsweise lediglich einen Teil des Datei-Headers oder nur die nicht verschleierten Dateiinhalte überprüfen. Diese Techniken bieten bei der Erkennung hochentwickelter Malware nur begrenzt Nutzen. Wenn wir also von statischer Analyse sprechen, bezeichnen wir Methoden zur Extrahierung, Untersuchung und Analyse des vollständigen Codes einer Datei. Der dynamische und der echte statische Ansatz haben jeweils Stärken und Schwächen. Die dynamische Analyse kann Malware durch direkte Beobachtung ihres Verhaltens mit hoher Zuverlässigkeit erkennen. Sie bietet die zuverlässigste Möglichkeit zur präzisen Entdeckung verborgener Bedrohungen in komplexen ausführbaren Dateien, kann jedoch mithilfe verschiedener Strategien problemlos überlistet werden. Da der Beobachtungszeitraum in einer Sandbox-Untersuchung durch wirtschaftliche Gesichtspunkte eingeschränkt wird, muss eine Datei lediglich diese Zeitspanne aussitzen und den Beginn ihres böswilligen Verhaltens verzögern. Eine Datei kann auch so programmiert werden, dass sie eine sichere Umgebung durch das Fehlen (oder Vorhandensein) bestimmter Ressourcen erkennt und nur die Ausführung harmloser Aktivitäten vortäuscht. Die statische Untersuchung kann böswilligen Code deutlich weniger zuverlässig als die dynamische Analyse erkennen, da sie sich auf Schlussfolgerung anstatt auf Beobachtung verlässt. Dennoch bietet sie Einblick in ruhenden (also nicht ausgeführten) Code, der für eine dynamische Analyse vollkommen unsichtbar ist. Die statische Code-Analyse kann beispielsweise strukturelle Übereinstimmungen zwischen ruhendem Code und bekannten Malware-Exemplaren erkennen. Sie ermittelt den Anteil des Codes, der während der Sandbox-Überprüfung ausgeführt wird und kann sogar die logischen Ausführungspfade einer komplexen Datei nachvollziehen, ohne dazu den Code selbst auszuführen. Es überrascht immer wieder, wie sehr sich die Stärken und Schwächen statischer und dynamischer Analysen ergänzen. Obwohl bei Malware-Sandboxes dynamische Techniken zum Einsatz kommen, kann eine zuverlässige und präzise Erkennung nur dann erfolgen, wenn dynamische und echte statische Code-Analysen eng verzahnt zum Einsatz kommen. Daher muss eine effektive Sandbox gleichzeitig dynamisch und statisch arbeiten. Leistungsdruck Eine Eigenschaft, die dynamische und statische Code-Analysen gemein haben, ist die hohe Rechenlast. Das führt dazu, dass keines der beiden Verfahren in Echtzeit auf den Datenverkehr angewendet werden kann, sondern selektiv eingesetzt werden muss, um eine Verschlechterung der Netzwerk- und Anwendungsleistung zu vermeiden. Je nach Produkt und Hersteller können die Analysen mehrere Minuten oder sogar Stunden dauern. Es ist daher sinnvoll, ihnen ressourcenschonende Techniken voranzustellen, die einfach erkennbare Bedrohungen schnell und effizient abwehren können. Wir sind der Meinung, dass eine hocheffiziente und effektive Malware-Sandbox aus mehreren aufeinander folgenden Ebenen von Analysemodulen aufgebaut ist, die jeweils höhere Anforderungen an die Verarbeitungsleistung stellen. Alle unbekannten Dateien, die von Netzwerksicherheitssensoren erkannt werden, können zur Überprüfung an diesen Dienst weitergeleitet werden. Jede Datei passiert die aufeinander folgenden Analysemodule, wobei das schnellste und ressourcenschonendste Verfahren den Anfang macht. Sobald eine Ebene eine Datei als böswillig erkennt, blockiert sie diese Datei sofort und entfernt sie aus der Analysereihe. Dadurch reduziert sich die Zahl der zu analysierenden Dateien zunehmend immer weiter. 3 Aufbau einer besseren Sandbox

4 Umfassender mehrstufiger Ansatz für ein Gleichgewicht aus Schutz und Leistung Hochentwickelte Sandbox Statische und dynamische Code-Analyse Lokale Listen Virenschutz- Signaturen Weltweite Datei-Reputation Emulationsmodul Abbildung 1. Abgestufter Malware-Analyseprozess mit mehreren Modulen. Der Aufbau der Untersuchungsreihe sollte erweiterbar sein, um neue Erkennungstechnologien aufnehmen zu können. Dennoch kann der heutige Stand der Technik auch jetzt schon sehr gut durch eine Reihe dargestellt werden, beginnend bei der Erkennung bekannter Angriffe (Signaturen und Reputationsdienste), gefolgt von Echtzeit-Verhaltenserkennung (Heuristik und Emulation) und schließlich dynamischer und statischer Code-Analyse. Wir bezeichnen das als abgestufte Analysearchitektur. Im Folgenden stellen wir diese schrittweise Verarbeitungssequenz Stufe für Stufe vor. Stufe 1: Erkennung bekannter Angriffe Die beiden Malware-Erkennungstechniken, die bei der ersten Analysestufe eingesetzt werden, sind die ältesten und am weitesten verbreiteten. Sie sind auch am wenigsten rechenintensiv und erfolgen weitgehend in Echtzeit. Signaturbasierte Analysen bilden den Kern aller Virenschutzprodukte und bieten schnelle sowie zuverlässige Erkennung anhand eines Musterabgleichs mit einer Bibliothek bekannt böswilliger Code-Varianten. Reputationsdienste hingegen erfassen Informationen von bekannten Quellen früherer Angriffe, einschließlich Hashes der eigentlichen Malware, geografischer Standorte, Domänen, URLs und IP-Adressen. Dadurch bieten sie eine Grundlage zur Erkennung bekannter, unbekannter als auch Zero-Day-Angriffe, die aus bekannt böswilligen Vektoren stammen. Beide Techniken sind schnell, erfordern wenig Rechenleistung und bieten eine sehr zuverlässige Erkennung von Bedrohungen in Echtzeit. Wichtigste Merkmale dieser Techniken sind (1) eine umfangreiche Bibliothek von Signaturen bekannter Bedrohungen sowie (2) eine schnelle und zuverlässige Infrastruktur, die den Abruf neuer weltweiter Bedrohungsdaten und ihre Verteilung an lokale Sensoren möglich macht. Diese beiden Technologien (und zu einem geringeren Teil auch die in der weiter unten vorgestellten Stufe 2) sind bereits in den meisten Sicherheitsprodukten enthalten. Daher ist es sehr hilfreich, wenn die Sandbox-Verwaltung die Möglichkeit bietet, den von den jeweiligen Sensoren gemeldeten Dateien separat Analysemodule zuzuweisen, sodass beispielsweise die signaturbasierte Untersuchung eines IPS-Dienstes nicht erneut in der Sandbox durchgeführt wird. Stufe 2: Schutz durch Echtzeit-Verhaltensanalyse Auch in der zweiten Analysestufe werden zwei unterschiedliche Erkennungsmethoden eingesetzt: Heuristik und Emulation. Die heuristische Identifizierung erstellt mithilfe von Regeln und Verhaltensmustern generische Konstrukte und sucht nach Ähnlichkeiten zwischen einer verdächtigen Datei und Gruppen oder Familien von bekannten Bedrohungen. Bei der Emulation wiederum wird die Dateiausführung in einer abgespeckten Host-Umgebung simuliert und das Ergebnis protokolliert. Die Emulationsumgebung kann eine Teilmenge der Ressourcen von Prozessor, Arbeitsspeicher und Betriebssystem-API enthalten. Die Emulation wird manchmal als halbe dynamische Analyse (oder als Sandbox Light ) bezeichnet, ist jedoch erheblich weniger ressourcenintensiv und bietet Ergebnisse in Echtzeit. Heuristik und Emulation ermöglichen die Echtzeitidentifizierung bislang unbekannter Bedrohungen und sind nur minimal weniger zuverlässig als signaturbasierte Techniken. Sie umfassen Methoden wie eine teilweise Dekompilierung sowie das Entpacken von Code, doch da es sich um Echtzeitprozesse handelt, stehen für das Entpacken oder Reverse Engineering nur geringe Ressourcen zur Verfügung. Wir sollten darauf hinweisen, dass für unterschiedliche Inhalte (ausführbare Dateien, Shell-Code, JavaScript, HTML und Java) unterschiedliche sprachenspezifische Emulatoren erforderlich sind. Die Zuverlässigkeit und Effektivität eines Emulationsmoduls hängen unmittelbar von seinem Funktionsumfang ab. 4 Aufbau einer besseren Sandbox

5 Stufe 3: Dynamische Analyse Die dritte Stufe in unserer beispielhaften Sandbox-Architektur stellt den Scheideweg zwischen nahezu in Echtzeit ablaufenden Analysen und den ressourcenintensiveren Techniken dar, die eine unvermeidbare höhere Latenz bedingen. Hier werden Dateien, die in früheren Analysestufen nicht zweifelsfrei als böswillig identifiziert wurden, in einer sicher isolierten virtuellen Umgebung ausgeführt. Echte dynamische Analysen unterscheiden sich dadurch von Emulation, dass sie eine vollständige Laufzeitumgebung verwenden, die virtualisiert und isoliert ist, um potenziell böswilligen Code sicher ausführen und das beobachtete Verhalten anschließend protokollieren sowie klassifizieren zu können. Zielspezifische Sandbox Bei der Konfiguration der virtuellen Umgebungen für die Malware-Sandbox werden vor allem zwei Ansätze häufig genutzt. Die Unterschiede sind wichtig, da die meisten IT-Umgebungen eine Vielzahl an Hard- sowie Software-Plattformen umfassen und die meisten Malware-Exemplare auf eine bestimmte Betriebsumgebung oder Anwendung abzielen. Beim ersten Ansatz wird eine einzelne generische Umgebung virtualisiert und in allen Analysen eingesetzt. Dabei steigt jedoch die Gefahr, böswilliges Verhalten zu übersehen, das an bestimmte Ressourcen oder Konfigurationsparameter gebunden ist, die in einem generischen Abbild möglicherweise nicht vorhanden sind. Gleichzeitig ist diese Methode jedoch ressourcenschonend, da nur ein Analysevorgang erforderlich ist. Beim zweiten Ansatz werden mehrere Umgebungen virtualisiert (z. B. verschiedene Windows Server-Plattformen und Konfigurationen sowie eine Reihe von PC- und Mobilplattform-Abbildern). Verdächtige Exemplare werden in allen diesen Umgebungen ausgeführt. Doch auch diese Strategie birgt die Gefahr, die eigentliche Zielumgebung zu verfehlen. Zudem kann sie False-Positives erzeugen und ist um ein Vielfaches verarbeitungsintensiver. Es ist daher erheblich effektiver und effizienter, eine verdächtige ausführbare Datei in einer virtuellen Umgebung auszuführen, die weit genug mit dem System übereinstimmt, für das die Dabei bestimmt war. Bei diesem Ansatz müssen verschiedene Betriebssysteme verfügbar sein oder Gold-Abbilder aller Endgeräte-Plattformen in der Umgebung zum Import bereitstehen. Die Sandbox muss die Ziel-Host-Umgebung schnell erkennen und unverzüglich eine entsprechende VM starten können. Dies kann nicht über das Netzwerk erfolgen, sondern muss in die Endgerätesysteme integriert werden. Wenn diese Bedingungen erfüllt werden, steigt die Wahrscheinlichkeit erheblich, dass das volle potenzielle Verhalten einer verdächtigen Datei ausgelöst und beobachtet werden kann, um ihre Absichten genau zu analysieren. Die Bedeutung von Interaktion Damit die Absicht einer ausführbaren Datei während der Sandbox-Untersuchung vollständig ermittelt werden kann, muss die virtuelle Umgebung interaktiv auf das Verhalten der Datei reagieren, wie das auch in einem normalen Host-System der Fall wäre. Die Sandbox muss insbesondere die normale Host-Reaktion auf Netzwerkverbindungsanfragen automatisch emulieren. Wenn diese erwarteten Reaktionen ausbleiben, könnte die Malware das als Anzeichen dafür betrachten, dass sie in einer Sandbox analysiert wird, und entsprechende Verschleierungsmaßnahmen ergreifen. Daher müssen auch in der Sandbox Reputationsdienste verfügbar sein, sodass hochriskante Anfragen zum Zugriff auf bekannt gefährliche IP Adressen, URLs und Dateien sofort als sehr wahrscheinliche Bedrohungsindikatoren ermittelt werden. Neben der Interaktivität für automatisch ausgelöste Inline-Dateiuntersuchungen sollte für Sicherheitsanalysten ein vollständig interaktiver Modus für manuelle Offline-Analysen zur Verfügung stehen. In diesem Modus kann ein Analyst eine virtuelle Maschine manuell starten und ein Exemplar der ausführbaren Datei mit vollem KVM-Funktionsumfang ausführen. Häufig kann spezifisches Bedrohungsverhalten nur mithilfe der Möglichkeit zum Starten von Browser-Sitzungen und weiteren üblichen Arbeitsplatzanwendungen ausgelöst und beobachtet werden. Interpretation dynamischer Analysen Die ersten beiden Stufen unserer Untersuchung erzeugen einfache Ausgaben in Echtzeit. Eine unbekannte Datei wird mithilfe einer Signaturzuordnung schnell als bekannte Bedrohung erkannt oder in Echtzeit-Emulationsumgebungen als hinreichend böswillig eingestuft. In beiden Fällen wird eine Entweder-oder-Entscheidung über das Blockieren oder Zulassen getroffen. Ganz anders das Erstergebnis einer dynamischen Analyse: Hier wird eine Protokolldatei generiert, die nur durch Korrelation Aussagekraft erhält. Spezifische Verhaltensereignisse müssen identifiziert sowie aggregiert und ihre Bedeutung im Kontext anderer Ereignisse ermittelt werden. Die Ausgabe einer unternehmensgerechten Sandbox ist kein langes oder kompliziertes Protokoll und auch keine einfache Entscheidung über das Blockieren oder Zulassen. Ein nützliches Sandbox- Tool für Unternehmen muss einen aggregierten und organisierten Bericht erstellen, der relevantes Verhalten hervorhebt und klassifiziert sowie eine Gesamtbewertung vergibt. Diese Wertung kann eine Blockierungsentscheidung auslösen oder weitere Informationen aus einer nachfolgenden statischen Analyse erfordern. In jedem Falle erhalten Sicherheitsfachleute umsetzbare Informationen, anhand derer sie weitere Entscheidungen treffen können. 5 Aufbau einer besseren Sandbox

6 Datei durch Änderung ihrer Attribute versteckt Von Datei abgelegter erkannter ausführbarer Inhalt Ausführbaren Inhalt im temporären Administrator- Verzeichnis erstellt Von Microsoft: CreateURLMoniker kann Ergebnisse liefern, die nicht mit der Eingabe übereinstimmen und zu Sicherheitsproblemen führen können Speicherbereich im virtuellen Adressraum eines Fremdprozesses belegt Verbindungsversuch zu einem bestimmten Dienstanbieter Inhalte im Windows-Systemverzeichnis erstellt Durch aktive Inhalte im temporären Administrator-Verzeichnis verändert Symbol einer legitimen Systemanwendung abgerufen und verwendet Ausführbaren Inhalt im Windows- Verzeichnis erstellt Aktiven Inhalt aus dem Windows- Systemordner ausgeführt Rückruffunktion zur Kontrolle von System- und Computer-Hardware- Ereignissen festgelegt Daten von einem Web-Server heruntergeladen Dienstnamen in einem DDE-Server- Austausch (Dynamic Data Exchange) registriert (nicht registriert) Abbildung 2. Zusammenfassender Verhaltens- und Klassifizierungsbericht nach einer dynamischen Analyse. Stufe 4: Statische Code-Analyse Die letzte Stufe in unserer mehrstufigen Sandbox ist die echte statische Code-Analyse, die wir auch präziser als Listen- Code-Disassemblierungs-Analyse bezeichnen können. Dieser Prozess startet zusammen mit der dynamischen Analyse in Stufe 3 und verarbeitet einige Ergebnisse der dynamischen Untersuchung, sobald diese verfügbar sind. Wie bereits erwähnt, greifen die Untersuchungstechniken auf Stufe 2 (Heuristik und Emulation) auf den Quell-Code einer Datei zu. Bei diesen Echtzeitanalysen stehen jedoch nur wenige Ressourcen für das Extrahieren von verschleiertem oder gepacktem Code zur Verfügung. Diese umfassende forensische Untersuchung ist jedoch hier in Stufe 4 unser Ziel. Abbildung 3. Dynamische Analyse für sich allein ist nicht ausreichend. 6 Aufbau einer besseren Sandbox

7 Packen, Entpacken und Reverse Engineering Es gibt durchaus legitime Gründe für das Verbergen oder Verschleiern des kompilierten ausführbaren Codes eines Programms. Der offensichtlichste Grund ist der Schutz geistigen Eigentums. Software-Entwickler versuchen verständlicherweise, Mitbewerber am Reverse Engineering ihrer Produkte zu hindern. Dabei wird versucht, sich rückwärts vom öffentlich verfügbaren Assembler-Code zur Quelle zu arbeiten. Wenig überraschend bieten andere geschäftstüchtige Entwickler unterschiedlichste kommerzielle Tools so genannte Packer an, die dieses Reverse Engineering erheblich erschweren. Tools wie Themida oder Armadillo ermöglichen die einfache Implementierung von Maskierungs- und Randomisierungstechniken in kompiliertem Programm-Code, sodass es extrem schwer ist, den Assembler-Code zu rekonstruieren und damit auf die Quelle zuzugreifen. Malware-Entwickler mussten lediglich die Techniken der Software-Branche einsetzen, um die Unterscheidung ihrer verschleierten Angriffe von legitimen Dateien erheblich zu erschweren. Erschweren bedeutet jedoch nicht, dass es unmöglich wäre. Abbildung 4. Das Verschleierungsmenü von Themida, einem leistungsfähigen Packer-Tool für Windows-Anwendungen. In der vierten Stufe unserer Malware-Sandbox wird ein Reverse Engineering von gepackten und verschleierten Dateien durchgeführt, um intakte Versionen des kompilierten Assembler-Codes zu finden. Dieser Code wird anschließend analysiert und einer statischen Analyse unterzogen, die folgende Ergebnisse liefert: Eine Bewertung der Ähnlichkeit mit bekannten Malware-Familien Den Umfang des latenten Codes, der bei der dynamischen Analyse nicht ausgeführt wurde Eine logische Karte der vollständigen Ausführungspfade der Datei Aktuelle APTs (Advanced Persistent Threats, hochentwickelte hartnäckige Bedrohungen) sind meist Varianten von bekanntem und effektivem Malware-Code. Schon geringe Änderungen ermöglichen das Aushebeln der Signaturprüfung, die für die Erkennung eine hundertprozentige Übereinstimmung erfordert. Bei der Untersuchung des gesamten Codes wird anders als beim Vergleich mit einer Bibliothek bekannter Malware-Familien häufig stark getarnte Stealth-Malware entdeckt. Beispielsweise kann eine verdächtige Datei unwesentliche Kompromittierungsindikatoren aufweisen, die jedoch nicht schwerwiegend genug sind, um die Datei zu blockieren. Da aber eine Übereinstimmung von mehr als 70 Prozent mit einer bekannten Malware-Familie (zum Beispiel conficker oder voter_1) besteht, sollte die Datei blockiert werden. Ohne die statische Code-Analyse wäre diese Malware in das Netzwerk eingedrungen. 7 Aufbau einer besseren Sandbox

8 Abbildung 5. Ähnlichkeiten mit Malware-Familien sind ein deutlicher Hinweis auf böswillige Absichten. Auf ähnliche Weise versuchen APTs zunehmend, Informationen zur Umgebung abzurufen oder warten auf bestimmte Interaktionen, bevor sie aktiv werden. Das bedeutet, dass ein Großteil des verschleierten Malware-Codes während der dynamischen Analyse inaktiv sein kann. Doch selbst wenn das Verhalten dieses ruhenden Codes nicht ermittelt werden kann, ist diese Tatsache allein bereits ein wichtiger Hinweis für die Untersuchung eines Sicherheitsanalysten. Stellen Sie sich eine verdächtige Datei vor, die kein böswilliges Verhalten zeigt. Eine dynamische Analyse für sich allein würde ergeben, dass die Datei sicher ist. Doch was ist, wenn diese Datei eine mehr als 70-prozentige Ähnlichkeit mit einer bekannten Malware-Familie aufweist und mehr als 40 Prozent des Datei-Codes nicht aktiv ist oder nicht in der Sandbox analysiert wurde? Diese beiden Indizien reichen aus, um die Übertragung der Datei so lange zu blockieren, bis sie von einem Sicherheitsexperten untersucht wurde. Zusammenfassung des Verhaltens (nach Ausführung von 57 Prozent des Codes): Datei durch Änderung ihrer Attribute versteckt Von Datei abgelegter erkannter ausführbarer Inhalt Ausführbaren Inhalt im temporären Administrator- Verzeichnis erstellt Von Microsoft: CreateURLMoniker kann Ergebnisse liefern, die nicht mit der Eingabe übereinstimmen und zu Sicherheitsproblemen führen können Speicherbereich im virtuellen Adressraum eines Fremdprozesses belegt Verbindungsversuch zu einem bestimmten Dienstanbieter Inhalte im Windows-Systemverzeichnis erstellt Durch aktive Inhalte im temporären Administrator-Verzeichnis verändert Symbol einer legitimen Systemanwendung abgerufen und verwendet Ausführbaren Inhalt im Windows- Verzeichnis erstellt Aktiven Inhalt aus dem Windows- Systemordner ausgeführt Rückruffunktion zur Kontrolle von System- und Computer-Hardware- Ereignissen festgelegt Daten von einem Web-Server heruntergeladen Dienstnamen in einem DDE-Server- Austausch (Dynamic Data Exchange) registriert (nicht registriert) Abbildung 6. Ein erheblicher Anteil von ruhendem Code weist auf Lücken der rein dynamischen Analyse hin. Wenn ein menschlicher Eingriff notwendig ist, kann ein Diagramm der Dateioperationen wertvolle Hilfe bei der Forensik leisten. Im Gegensatz zu Protokolldateien oder Verhaltensbeobachtungen (also einer dynamischen Analyse) können Sicherheitsexperten anhand eines Diagramms verborgene Bereiche und Interaktionen des Codes untersuchen. Dies ist häufig der Schlüssel zu böswilligem, jedoch ruhendem Code, insbesondere wenn die Methode zusammen mit einer Sandbox eingesetzt wird, die eine manuelle Interaktion mit der verdächtigen Datei in einer virtuellen Maschine erlaubt. 8 Aufbau einer besseren Sandbox

9 Interaktive Code-Übersicht starten Blaue Linien kennzeichnen dynamisch ausgeführten Code. Rote Linien kennzeichnen statisch ausgeführten Code. Abbildung 7. Durch die Visualisierung von Dateiprozessen können Sicherheitsexperten latenten Code auslösen. Diese Ergebnisse fließen anschließend in die Beobachtungen der dynamischen Analyse aus Stufe 3 ein, um in einer Gesamtbewertung zu zeigen, mit welcher Wahrscheinlichkeit die untersuchte Datei böswillig ist. Stufenweise Strategie für herausragenden Sandbox-Ansatz Ein Erkennungsdienst für hochentwickelte Malware, der auf dem zuvor beschriebenen stufenweisen Ansatz basiert, stellt eine fortschrittlichere, zuverlässigere und kostengünstigere Lösung als alle anderen derzeit verfügbaren Angebote dar. Die Lösung vermeidet die Überlastung der Sandbox, indem sie mithilfe schneller und ressourcenschonender signaturbasierter Untersuchungen und Reputationsdienste bekannte und einfach zu erkennende Bedrohungen herausfiltert. Die zielspezifische Ausführung in einer Sandbox steigert die Effizienz und Genauigkeit der dynamischen Analyse erheblich. Und schließlich deckt echte statische Code-Analyse die Verschleierung auf und legt ruhenden sowie verborgenen Code offen. Zum ersten Mal in der abwechslungsreichen Geschichte der parallelen Evolution von Malware und Sicherheits-Software macht die Sicherheit einen großen Sprung nach vorn. Weitere Informationen finden Sie unter McAfee GmbH Ohmstr Unterschleißheim Deutschland +49 (0) McAfee und das McAfee-Logo sind Marken oder eingetragene Marken von McAfee, Inc. oder der Tochterunternehmen in den USA und anderen Ländern. Alle anderen Namen und Marken sind Eigentum der jeweiligen Besitzer. Die in diesem Dokument enthaltenen Produktpläne, Spezifikationen und Beschreibungen dienen lediglich Informationszwecken, können sich jederzeit ohne vorherige Ankündigung ändern und schließen alle ausdrücklichen oder stillschweigenden Garantien aus. Copyright 2014 McAfee, Inc wp_build-sandbox_0214_fnl_ETMG