# Trainingsszenario - Speichermodifikation
## Gruppenname
**Trainingsdaten - Process Hollowing SQL (Hive)**
## Szenario
In diesem Trainingsszenario führen wir eine Ransomware-Payload mittels Process Hollowing aus, einer Injektions-/Umgehungstechnik, bei der ein Prozess gestartet und dessen ausführbarer Code so modifiziert wird, dass er ein anderes Verhalten ausführt.
In-Memory-Tradecraft gehört zu den am schwersten zu erkennenden Techniken, und noch schwerer ist es, eine automatisierte Reaktion darauf zu haben, weshalb sie oft ignoriert wird. Speicher ist per Definition flüchtig und ändert sich ständig. Um Änderungen im Speicher eines Prozesses zu identifizieren, müssen relevante Bereiche erkannt und zu unterschiedlichen Zeitpunkten im Lebenszyklus eines Prozesses ausgewertet werden, um festzustellen, ob er manipuliert wurde.
## Erkennung
Reaktionen auf Speichermodifikationen sind bei Weitem am schwierigsten zu untersuchen. Da Speicher vergänglich ist, wird er wie eine „Black Box“ behandelt und oft auf Abstand gehalten. Die gute Nachricht ist, dass wir seit Cyber Crucible 4.4.1.3 nun die Möglichkeit haben, automatisch Telemetriedaten für modifizierte Speicherproben zu erfassen und dabei zu identifizieren, welche Speicherbereiche verändert wurden und welche genauen Änderungen daran vorgenommen wurden.
Diese Art der Analyse ist jedoch sehr aufwendig, daher ist ein guter erster Schritt, die zugehörigen Prozesse im Dashboard zu überprüfen, um sich einen Eindruck vom zugehörigen Verhalten zu verschaffen. Da es sich bei dem betreffenden Prozess um eine signierte SQLCMD.exe handelt, sollte schnell klar werden, ob es sich um einen harmlosen SQL-Prozess oder etwas Schlimmeres handelt.
Bisher sieht alles gut aus, nur normale SQL-Prozesse, nichts, das notwendigerweise verdächtig oder unverdächtig ist. Allerdings sehen wir es nie gern, wenn CMDs an automatisierten Reaktionen beteiligt sind. Graben wir etwas tiefer.
Der eindeutige Beweis!Und da ist er! Wir können weiter scrollen und immer mehr solcher Verhaltensweisen sehen. Die SQLCMD.exe führt alle möglichen Befehle aus, um Dienste zu deaktivieren, Konfigurationen zu ändern, und alles, was Ransomware präventiv tun würde.
Hier können wir eine kleine Vorstellung davon bekommen, was uns erwartet, wenn wir tiefer graben und die Speicher-Diffs analysieren. Die meiste Tradecraft, die ausgereift genug ist, um vollständig speicherbasierte Malware zu erstellen, wird auch ihren Code im Speicher verschleiern. Dies macht die Analyse extrem schwierig, aber der Zugriff auf die zusätzlichen Telemetriedaten hat sich bereits als unschätzbar wertvoll für die Vorfallserkennung sowie die Verhaltensfeinabstimmung erwiesen.
## Relevante Dokumentation
- **Process Injection**
- [Mitre T1559](https://attack.mitre.org/techniques/T1559) - Inter-Process-Kommunikation kann nach Abschluss der Injektion Kontrolle über den Zielprozess vom Injektor aus ermöglichen.
- [Mitre T1106](https://attack.mitre.org/techniques/T1106) - Native APIs bieten oft den unmittelbarsten Zugriff auf Betriebssystemfunktionalität, um auf Dateien, laufende Prozesse und mehr zuzugreifen.
- [Mitre T1569](https://attack.mitre.org/techniques/T1569) - Das Injizieren in einen Systemdienst wie einen bestehenden `svchost` kann bösartigen Code so tarnen, dass er als von einem bekannten und vertrauenswürdigen Prozess ausgehend gemeldet wird.
- [Mitre T1055](https://attack.mitre.org/techniques/T1055) - Prozessinjektion, üblicherweise verwendet, um bösartigen Code in einem Zielprozess auszuführen, während der ursprüngliche Prozess weiterlaufen kann.
- [Mitre T1543](https://attack.mitre.org/techniques/T1543) - Das Erstellen oder Modifizieren eines Systemprozesses kann bösartigen Code als normalen, vertrauenswürdigen Systemprozess vor der Malware-Erkennung tarnen.