Implementierung

Als Testsystem wird Lenovo X1 2017 (20HQS03P00) und als Hypervisor VMware Workstation 15 Pro eingesetzt. Die virtuellen Maschinen sind in Tabelle 7 mit den entsprechenden Konfigurationen beschrieben:

Computername Betriebssystem CPU RAM Rolle winclient Windows 10

1909

2 vCPU 4GB Gehärtetes

System + Beats winsrv Windows Server

2019

2 vCPU 4GB Elastic Stack

Tabelle 7: Testumgebung virtueller Maschinen

Für den winclient sind gesonderte Konfigurationen notwendig, damit die Sicherheitskomponenten funktionieren. Dabei ist es wichtig, dass der virtuellen Maschine im VMware Management zusätzlich eine TPM Komponente hinzugefügt wird. Damit diese TPM Komponente genutzt werden kann, muss die virtuelle Maschine im VMware Management verschlüsselt werden. In den erweiterten Einstellungen der virtuellen Maschine ist Enabling VBS, will also enable UEFI, secure boot, Intel VT-x/EPT and IOMMU und bei Firmware Typ UEFI mit Enable secure boot zu konfigurieren.

4.2.1 Konfiguration des Elastic Stacks

Der Elastic Stack wird auf dem Windows Server 2019 installiert. Dabei werden die Installationsquellen von Elastic heruntergeladen und wie in den Dokumentationen konfiguriert [68]. Für die Elasticsearch Konfiguration ist elasticsearch.yml und für Kibana kibana.yml zuständig. In der Elasticsearch Konfiguration müssen die folgenden Parameter korrekt gesetzt werden, damit der Elasticsearch Server über das Netzwerk erreichbar ist: network.host, discovery.seed_hosts und cluster.initial_master_nodes. In der Kibana Konfiguration müssen folgende Parameter definiert werden, um die Verfügbarkeit im Netzwerk und die Kommunikation mit dem Elasticsearch Server zu ermöglichen: server.host und elasticsearch.hosts.

4.2.2 Sichere Konfiguration des Elastic Stacks

Ab der Elasticsearch Version 7.1.0 sind grundlegende Sicherheitsfeatures in der kostenlosen Version inkludiert [69]. Sowohl Elasticsearch als auch Kibana werden mit „Hypertext Transfer Protocol Secure“ (HTTPS) und User Authentifizierung abgesichert [70] [71] [72].

Abbildung 23: Elastic Stack sichere Kommunikation

Abbildung 23 zeigt die aktuelle Elastic Konfiguration in der Testumgebung. Für die sichere HTTP Verbindung wurden selbst signierte Zertifikate verwendet. Für die

Authentifizierung der Benutzer liegt eine entsprechend ausführbare Datei von Elastic bei, um diese anzulegen und ein Passwort zu vergeben. Zusätzlich wurde eine Windows Firewall am Windows Server 2019 konfiguriert, damit der Zugriff weiter eingeschränkt ist.

4.2.3 Einbindung des Windows 10 Clients

Beats (siehe Kapitel 4) liefern die Daten zum Elastic Stack. Es gibt viele unterschiedliche Beats für die unterschiedlichen Anwendungsbereiche. Für den Windows Logfile Transfer bietet sich winlogbeat an. Dieser Beat kann nativ Windows Events lesen und sendet diese aufbereitet an den Elastic Stack. In der Winlogbeat Konfiguration werden die Sicherheits- und Sysmonlogs (siehe Kapitel 4.2.3.2) definiert, um diese an den Elastic Stack zu übertragen.

4.2.3.1 Windows Events

Windows Event-log [73] gibt es seit Windows Vista und ist ein Teil der „Event Tracing for Windows“ (ETW) API. ETW besteht aus drei Komponenten [74]:

• „Controllers“

• „Providers“

• „Consumers“.

Abbildung 24: Event Tracing [74]

Abbildung 24 zeigt den Zusammenhang zwischen den drei Komponenten. Die

„Provider“ stellen Events zur Verfügung, die „Consumers“ können diese Events konsumieren. Ein „Provider“ registriert einen Namen mit einer GUID und benennt Events.

Die „Controllers“ sind zuständig für eine „Event tracing sessions“. Diese Sitzung ist notwendig und stellt den Buffer bereit, wodurch die „Provider“ Events entsprechend

senden und die „Consumers“ sie konsumieren können. Jedes Event hat vordefinierte Felder, die benutzt werden sollten, um das Event zu beschreiben. Die vordefinierten Felder sind:

• ID

• „Keyword“

• „Severity level“

• „Task“

• „Opcode“.

Die Event IDs repräsentieren einen bestimmten Status innerhalb eines Providers.

Die Kombination des Providers (GUID) mit der ID ist eindeutig. „Keywords“ sind in einer 64-bit Maske spezifiziert und beschreiben eine Subkomponente innerhalb eines Providers. „Severity level“ definiert den Detailgrad des Providers. Die Levels sind vordefiniert [75] und reichen von „Verbose“ bis „LogAlways“.

„Tasks“ identifizieren eine Übermenge von Subkomponenten innerhalb eines Providers. Die „Tasks“ sind als 16-bit Wert definiert und werden meist gemeinsam mit dem „Opcode“ betrachtet. „Opcode“ ist ein 8-bit Wert, der die ausführende Operation der Subkomponente beschreibt.

4.2.3.2 Sysmon

Die von Microsoft zur Verfügung gestellten Events sind beschränkt und beziehen sich oft auf das nicht-interaktive Systemverhalten. Sysmon [76] ist ein Tool der Sysinternals-Suite die es ermöglicht, verschiedene Aktivitäten zu protokollieren.

Die Protokollierung findet in dem Event-log statt, wodurch eine Übermittlung mittels winlogbeat möglich ist. Sysmon selbst besteht aus einem Boot-Treiber und installiert sich als Windows Service. Die generierten Events finden sich im

Eventviewer unter Applications and Services

Logs/Microsoft/Windows/Sysmon/Operational.

Sysmon unterstützt dabei die folgenden Hashes: SHA1, MD5, SHA256 und IMPHASH. IMPHASH [77] extrahiert die geladenen Module und bildet dadurch Hashwerte. Abhängig von der Änderung der Malware kann diese zwar selbst einen anderen beispielsweise SHA256 Wert haben, allerdings bleibt der IMPHASH ident.

Event-ID Funktion Beschreibung

1 Prozesserstellung Neu erzeugte Prozesse werden inklusiver kompletter Command-Line aufgezeichnet.

2 Ein Prozess ändert den Erstellungszeitstempel einer Datei

Manipuliert den Zeitstempel für die Erstellung einer Datei.

3 Netzwerkverbindung Zeichnet die Netzwerkverbindung auf (Quelle und Ziel) inkl. Prozess-ID.

4 Sysmon Service Status ändert sich

Dieses Event wird generiert, wenn das Sysmon Service gestoppt oder gestartet wird.

5 Prozessterminierung Verstorbene Prozesse werden inkl.

Zeit und Prozess-ID aufgezeichnet.

6 Treiber wurde geladen Wenn ein Treiber im System geladen wird, wird dies aufgezeichnet. Falls die Datei nach dem Laden gelöscht wird, wird das ebenfalls

aufgezeichnet.

7 Module wurde geladen Wenn ein Modul innerhalb eines Prozesses geladen wird, erfolgt eine Aufzeichnung.

8 „Remote Thread“ wird erzeugt

Dieses Event beschreibt den Vorgang, wenn ein Prozess ein

„Thread“ in einem anderen Prozess erzeugt.

9 „Raw Access Read“ Immer wenn ein Prozess mit der Annotation \\.\ versucht etwas zu lesen, wird dies in diesem Event vermerkt.

10 Prozess Zugriff Das Event wird ausgelöst, wenn ein Prozess einen anderen Prozess startet.

11 Datei wird erzeugt Wenn eine Datei erzeugt oder überschrieben wird, löst das Event 11 aus.

12,13,14 Registry Events In den Events 12,13 und 14 werden verschiedene Aktivitäten, im

Schreibzugriff oder in der Registry aufgezeichnet.

15 „File Create Stream Hash“ Wird erzeugt, wenn ein benannter

„File Stream“ geöffnet wird.

17 Pipe wird erzeugt Eine benannte Pipe wird erzeugt (meist für Interprozess-

Kommunikation).

18 Pipe wird verbunden Dieses Event zeichnet Client und Server bei einer Pipe-Verbindung auf.

19,20,21 WMI Events Verschiedene „Windows

Management Instrumentation“ (WMI) Aktivitäten werden aufgezeichnet.

22 DNS Events Wenn ein Prozess eine DNS-Abfrage

durchführt, wird dies, unabhängig von dem Ergebnis der DNS-Abfrage in diesem Event protokolliert.

255 Fehler Fehler innerhalb des Sysmon

Services.

In Tabelle 8 werden alle möglichen Sysmon Events aufgelistet. Die Steuerung, wodurch Events vom Sysmon Service aufgezeichnet werden, funktioniert über eine Konfigurationsdatei im XML-Format. Essentiell ist dabei, harmlose Events zu filtern, um eine hohe Qualität der Datenbasis zu erhalten. Die de-facto Standard Konfiguration ist SwiftOnSecurity [78]. Viele Sysmon Konfigurationen forken die Konfiguration von SwiftOnSecurity. Als Beispiel sei hier die Sysmon Konfiguration von ion-storm erwähnt [79]. Diese Konfiguration basiert darauf, die entsprechenden Vektoren von MITRE ATT&CK abzudecken [80]. ATT&CK kategorisiert verschiedene sicherheitsrelevante Techniken (beispielsweise „Privilege Escalation“ oder „Persistence“) [81]. Die Installation auf dem Testsystem erfolgt mit sysmon.exe -accepteula -i sysmonconfig-export.xml.