Prüfung

Kontext und Aufgabe

Gegeben seien die Observables im Verzeichnis files aus einem oder mehreren mutmaßlichen IT-Sicherheitsvorfällen. Analysieren Sie die zur Verfügung gestellten Observables, geben Sie eine begründete Einschätzung, ob es sich um bösartige oder gutartige Inhalte handelt und verfassen Sie einen Threat Intelligence Report. Sollten mehrere Observables gegeben sein, ist unklar, ob diese zusammenhängen oder völlig unabhängig voneinander sind. Geben Sie auch hierzu Ihre Einschätzung. Halten Sie Ihre Ergebnisse in einem Bericht fest.

Die Observables sind als passwortgeschützte ZIP-Dateien (Passwort: infected) hinterlegt. Die Analyse der Observables unterscheidet sich möglicherweise hinsichtlich des Schwierigkeitsgrads.

Die Bearbeitung erfolgt in Kleingruppen. Pro Gruppe muss ein Bericht abgegeben werden und eine Gruppenpräsentation gehalten werden, bei der sich jedes Gruppenmitglied beteiligen muss.

Das Verzeichnis support enthält zusätzliche Dateien, die bei der Analyse hilfreich sein könnten, u.a. eine Email von Vladimir aus dem Forensik-Team.

Fristen, Abgabe und Prüfungsleistung

• Bericht: abzugeben bis 16.07.2022 09:00 CEST
• eine Präsentation pro Gruppe
  • wird am 29.06.2022 gehalten, 10:00 bis 10:20 Uhr
  • Folien als PDF im Nachgang der Präsentation, spätestens 16.07.2022 09:00 CEST

Es gibt kaum formale Anforderungen an den Bericht (keine Mindestseitenzahl, Schriftart, Schriftgröße o.ä.). Der Bericht sollte im PDF-Format als Datei eingereicht werden. Sie erhalten pro Gruppe ein GitLab-Repository, das den fertigen Bericht beinhalten sollte sowie - falls vorhanden - weitere technische Observables, die Sie in der Analyse abgeleitet haben (z.B. PCAPs, eingebettete Dateien). Der Bericht soll in dem Verzeichnis mit dem Namen report liegen.

Die Präsentation soll interessante Teilaspekte sinnvoll und fachlich anspruchsvoll darstellen. Gehen Sie davon aus, dass das Auditorium fachlich ebenbürtig ist und mit den Observables vertraut ist. Es ist nicht möglich, alle Ergebnisse des Berichts in der vorgegebenen Zeit unterzubringen (das sollten Sie auch gar nicht erst versuchen!). Vielmehr sollten Sie sich einzelne, interessante Aspekte herauspicken und so detailreich/tiefgehend wie möglich darstellen. Halten Sie sich exakt an die vorgegebene Zeit und liefern Sie eine Präsentation ab, die begeistert, fachlich einwandfrei, sprachlich wohlbedacht und keine Bleiwüste ist.

Bericht

Der abzugebende Bericht sollte keine lose Sammlung an Notizen sein, die bei der Analyse entstanden sind, sondern ein Konzentrat der Ergebnisse. In Ihren Augen unwichtige Details lassen Sie also weg.

Beispiel: Wenn die Menge der Imports einer PE-Datei keine Schlüsse zulässt (Ist die Datei gepackt? Gibt es nennenswerte Abhängigkeiten?), muss sie auch nicht in epischer Breite im Bericht enthalten sein, sondern es reicht ein kurzer Hinweis, dass es betrachtet wurde, aber keine sachdienlichen Hinweise z.B. zur Attribution zugelassen hat.

Orientieren Sie sich hinsichtlich des Berichts an folgenden Aspekten, die inhaltlich abgedeckt sein sollen:

• Management Summary: Kurze, ergebnisorientierte Beschreibung der Schlüsse, Bottom Line Up Front (BLUF)
• Identifikation der Observables (Datei-Hashwerte, Fuzzy-Hashwerte, ggf. Malware-Label, Dateityp, etc.)
• Beobachtung, Beschreibung und Analyse der Observables
  • Infektionsvektor: Wie kommt es zu einer Infektion? und Infektionskette: Wie hängen einzelne Observables zusammen?
  • Persistenz: Wie verankern sich die Samples im System (z.B. um bei einem Reboot wieder aktiv zu werden)?
  • Command-and-Control (C2): Welche Rolle spielt das Observable in der Interaktion zwischen Angreifer mit dem Ziel?
  • Capabilities: Pro Sample: Welche Funktionen stellt das Sample dem Angreifer zur Verfügung (hängt meist mit dem C2-Protokoll zusammen)? Wofür könnte das Sample benutzt werden?
  • Abhängigkeiten: Welche Abhängigkeiten beobachten Sie?
    • Beispiel: Es handelt sich um PE-Dateien, daher wird auf eine Windows-Umgebung abgezielt.
    • Beispiel: Es handelt sich um eine schadhafte Microsoft Word-Datei, die die Schwachstelle CVE-2016-0183 ausnutzt. Daher wird höchst wahrscheinlich auf eine Windows-Umgebung abgezielt, in der Microsoft Word 2010 zum Einsatz kommt.
    • Beispiel: Es handelt sich um eine dynamisch gelinkte PE-Datei, die eine Bibliothek (DLL) mit dem Namen msvcr120.dll benötigt. Diese DLL wird mit den Visual C++ Redistributable Packages für Visual Studio 2013 zur Verfügung gestellt. Die Verwendung dieser DLL lässt vermuten, dass der Autor Visual Studio 2013 verwendet hat und vermutlich die Programmiersprachen C und C++ genutzt hat.
    • Beispiel: Das C2-Protokoll aller untersuchter Samples ist ein vermutlich selbstgeschriebenes Protokoll mit TCP als Trägerprotokoll und TCP-Zielport 18992. Infizierte Umgebungen, die lediglich TCP-Port 80 ausgehend erlauben, lassen sich vermutlich nicht durch die analysierte Schadsoftware vom Angreifer kontrollieren.
  • Charakteristische Codestellen: Eigene Obfuskierungs-/Ver-/Entschlüsselungsverfahren, besondere Implementierungseigenheiten
• Verwandte Observables/Samples und Infrastruktur (Pivoting)
  • Angewandte Methoden zum Auffinden von verwandten Observables
    • Beispiel: Erstellung einer YARA-Regel über die charakteristischen Zeichenketten "Pommes", "Ketchup" und "Mayonnaise" aus Observable A und Anwendung auf den Sample-Korpus lieferte folgende 7 weitere Samples... Eine overflächliche Analyse der zusätzlich gefundenen Samples zeigt ähnliche Capabilities wie Observable A und legt daher nahe, dass sie vermutlich zusammen hängen.
    • Beispiel: Lookup der Domain wurstsalat.de in der Passive-DNS-Datenbank von PassiveTotal lieferte folgende 3 IP-Adressen: ... Eine der gefundenen IP-Adressen zeigt in Passive-DNS, dass die Domain kaesesalat.de im ähnlichen Zeitraum wie wurstsalat.de auf die IP-Adresse X.X.X.X auflöste.
  • Zusammenstellen der verwandten Observables/Samples in tabellarischer oder anderer geeigneter Form (Indicators of Compromise, IOC)
  • Infrastruktur-Analyse: Welche Infrastruktur wird genutzt, z.B. für C2, die Infektion oder die Weiterverbreitung?
• Kontext und Attribution
  • Ziel bzw. Ziele der Infektion bzw. der Infektionen: Hinweise darauf, wer Ziel sein könnte? Gibt es mehrere Ziele? Lassen sich die Ziele gruppieren, z.B. nach Sektoren?
  • Finden sich potentielle Hinweise, die bestimmte Rückschlüsse auf den Akteur zulassen?
    • Beispiele: Besondere Zeichenketten, Sprachhinweise, zeitliche Anker, Metadaten wie Autor, PE-Eigenschaften wie PDB-Pfade, Zeitstempel etc.
  • Level of sophistication: Wie erfahren ist der Akteur? Wie schätzen Sie die Codequalität ein? Wie schätzen Sie die Vorgehensweise ein (durchdacht oder unstrukturiert)?
• Actionable Threat Intelligence: Der Bericht enthält bzw. liefert Signaturen und Indikatoren mit, mit denen Erkennung und Abwehr durchgeführt werden können, z.B. in Form von
  • YARA-Regeln für Dateien und/oder Hauptspeicher-Abzüge
  • Snort- oder Suricata-Signaturen für Netzwerk-Verkehr
  • Sigma-Regeln für SIEM-Systeme
  • Beispielhafte Mitschnitte von C2-Netzwerk-Verkehr (PCAP)

Hilfsmittel

Als Hilfsmittel sind jegliche Informationsquellen und Werkzeuge erlaubt. Nicht erlaubt ist, Analyseergebnisse Dritter zu übernehmen. Als Hilfsmittel wird insbesondere eine Datenquelle bereit gestellt (die sog. Sample Collection), die für das Pivoting von Samples verwendet werden kann/soll. Details zur Sample Collection werden noch bekannt gegeben. Es bietet sich an, Ghidra für die statische Analyse und x64dbg für die dynamische Analyse von PE-Dateien und/oder Shellcode zu verwenden, sowie aus der Veranstaltung (Vorlesung/Praktikum) bekannte Werkzeuge und Datenquellen.

Bewertung

Die Gesamtbewertung eines Prüflings ergibt sich zu 60% aus der Gruppennote für den Bericht und zu 40% aus der Leistung in der Abschlusspräsentation.

Folgende Kriterien werden unter anderem der Bewertung zugrunde gelegt:

• Vollständigkeit des Berichts hinsichtlich der Observables: Sind alle initial zur Verfügung gestellten Observables bearbeitet worden?
• Wurde die Analyse der Observables in angemessenem Rahmen vorgenommen? (Infektionsvektor, Persistenz, C2, Capabilities)
• Wurden charakteristische Eigenheiten identifiziert?
• Wurde Pivoting betrieben? Wurden weitere Observables, die möglicherweise im Zusammenhang stehen, identifiziert und wurde plausibel begründet, warum sie im Zusammenhang stehen?
• Wurden Aussagen mit konkreten Beispielen (z.B. Code-Listing, Abbildungen, o.ä.) belegt?
• Sprachliche Aspekte: Wurden Formulierungen abgewogen? Zum Beispiel die Verwendung von einschätzenden Begrifflichkeiten wie: "unmöglich", "unwahrscheinlich", "möglicherweise", "wahrscheinlich", "höchst wahrscheinlich"
• Insbesondere Präsentation: Wurde die Zeit eingehalten? (pro Teilnehmer exakt 5 Minuten; z.B. 20 Minuten für eine Gruppe mit 4 Teilnehmern)