Im ersten Artikel dieser mehrteiligen Serie geben Malware-Forscher des Elastic Security Labs-Teams eine kurze Einführung in die REMCOS-Bedrohung und gehen detailliert auf die erste Hälfte ihres Ausführungsablaufs ein, vom Laden der Konfiguration bis zur Bereinigung der Webbrowser des infizierten Rechners.
Einführung
Elastic Security Labs setzt seine Untersuchung schwerwiegender Bedrohungen fort und konzentriert sich dabei auf die internen Komplexitäten von REMCOS Version 4.9.3. Pro (November 26, 2023).
REMCOS wurde von Breaking-Security entwickelt und ist eine Software, die ursprünglich als Red-Teaming-Tool gedacht war, aber mittlerweile von Bedrohungen aller Art eingesetzt wird, die praktisch jeden Sektor angreifen.
Als wir Mitte Januar unsere Analyse durchführten, war dies die am häufigsten von ANY.RUN gemeldete Malware-Familie. Darüber hinaus wird es weiterhin aktiv weiterentwickelt, wie die kürzlich erfolgte Ankündigung der Veröffentlichung der Version 4.9.4 durch das Unternehmen am 2. März 9, 2024 belegt.
Alle von uns analysierten Proben stammen aus demselben REMCOS 4.9.3-System. Professionelle x86-Architektur. Die Software ist in C++ geschrieben und nutzt intensiv die Klasse std::string für ihre String- und Byte-bezogenen Operationen.
REMCOS bietet eine Vielzahl von Funktionen, darunter Umgehungstechniken, Rechteausweitung, Prozessinjektion, Aufzeichnungsfunktionen usw.
Diese Artikelserie bietet eine umfassende Analyse der folgenden Punkte:
- Ausführung und Fähigkeiten
- Erkennungs- und Jagdstrategien mithilfe von ES|QL-Abfragen von Elastic
- Wiederherstellung von etwa 80 % der Konfigurationsfelder
- Wiederherstellung von etwa 90 % der C2-Befehle
- Beispielhafte virtuelle Adressen unter jedem IDA Pro-Screenshot
- Und vieles mehr!
Bei Fragen oder Feedback können Sie uns gerne über Social Media unter @elasticseclabs oder im Elastic Community Slack kontaktieren.
Konfiguration wird geladen
Die REMCOS-Konfiguration wird in einem verschlüsselten Blob innerhalb einer Ressource mit dem Namen SETTINGS gespeichert. Dieser Name scheint in verschiedenen Versionen von REMCOS einheitlich zu sein.
Die Malware beginnt damit, den verschlüsselten Konfigurations-Blob aus ihrem Ressourcenbereich zu laden.
Zum Laden der verschlüsselten Konfiguration verwenden wir das folgende Python-Skript und das Lief- Modul.
import lief
def read_encrypted_configuration(path: pathlib.Path) -> bytes | None:
if not (pe := lief.parse(path)):
return None
for first_level_child in pe.resources.childs:
if first_level_child.id != 10:
continue
for second_level_child in first_level_child.childs:
if second_level_child.name == "SETTINGS":
return bytes(second_level_child.childs[0].content)Wir können bestätigen, dass Version 4.9.3 die gleiche Struktur und das gleiche Entschlüsselungsschema beibehält, wie es zuvor von Fortinet-Forschern beschrieben wurde:
Wir bezeichnen die Struktur, die den Entschlüsselungsschlüssel und den verschlüsselten Datenblock enthält, als „verschlüsselte Konfiguration“. Diese Struktur sieht wie folgt aus:
struct ctf::EncryptedConfiguration
{
uint8_t key_size;
uint8_t key[key_size];
uint8_t data
};Die Konfiguration wird weiterhin mit dem RC4-Algorithmus entschlüsselt, wie im folgenden Screenshot zu sehen ist.
Zur Entschlüsselung der Konfiguration verwenden wir den folgenden Algorithmus.
def decrypt_encrypted_configuration(
encrypted_configuration: bytes,
) -> tuple[bytes, bytes]:
key_size = int.from_bytes(encrypted_configuration[:1], "little")
key = encrypted_configuration[1 : 1 + key_size]
return key, ARC4.ARC4Cipher(key).decrypt(encrypted_configuration[key_size + 1 :])Die Konfiguration dient dazu, einen globalen Vektor, den wir g_configuration_vector nennen, zu initialisieren, indem er mit der Zeichenkette \x7c\x1f\x1e\x1e\x7c als Trennzeichen aufgeteilt wird.
Eine detaillierte Erklärung der Konfiguration liefern wir später in dieser Reihe.
UAC-Umgehung
Wenn enable_uac_bypass_flag (Index 0x2e) in der Konfiguration aktiviert ist, versucht REMCOS, die Benutzerkontensteuerung (UAC) mithilfe einer bekannten COM-basierten Technik zu umgehen.
Zuvor verschleiert REMCOS seinen Prozess, um einer Entdeckung zu entgehen.
REMCOS modifiziert die PEB-Struktur des aktuellen Prozesses, indem der Bildpfad und die Befehlszeile durch die Zeichenkette explorer.exe ersetzt werden, während die ursprünglichen Informationen in globalen Variablen zur späteren Verwendung gespeichert werden.
Die bekannte Technik nutzt die CoGetObject API, um den Elevation:Administrator!new: Moniker zusammen mit der CMSTPLUA CLSID und ICMLuaUtil IID zu übergeben und so eine erweiterte COM-Schnittstelle zu instanziieren. REMCOS verwendet dann die ShellExec() -Methode der Schnittstelle, um einen neuen Prozess mit Administratorrechten zu starten und zu beenden.
Diese Technik wurde bereits in einem Artikel von Elastic Security Labs aus dem Jahr 2023 dokumentiert: Exploring Windows UAC Bypasses: Techniques and Detection Strategies.
Nachfolgend ein aktueller Screenshot der Erkennung dieser Sicherheitslücke mithilfe des Elastic Defend-Agenten.
Deaktivierung der Benutzerkontensteuerung
Wenn disable_uac_flag in der Konfiguration aktiviert ist (Index 0x27), deaktiviert REMCOS die Benutzerkontensteuerung (UAC) in der Registrierung, indem der Wert HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\SystemEnableLUA mithilfe der Windows-Binärdatei reg.exe auf 0 gesetzt wird.
Installation und Persistenz
Wenn enable_install_flag (Index 0x3) in der Konfiguration aktiviert ist, installiert sich REMCOS auf dem Host-Rechner.
Der Installationspfad wird anhand der folgenden Konfigurationswerte erstellt:
install_parent_directory(Index0x9)install_directory(0x30)install_filename(0xA)
Die Malware-Binärdatei wird nach {install_parent_directory}/{install_directory}/{install_filename} kopiert. In diesem Beispiel ist es %ProgramData%\Remcos\remcos.exe.
Wenn enable_persistence_directory_and_binary_hiding_flag (Index 0xC) in der Konfiguration aktiviert ist, werden der Installationsordner und die Malware-Binärdatei auf super versteckt gesetzt (selbst wenn der Benutzer die Anzeige versteckter Dateien oder Ordner aktiviert, wird die Datei von Windows zum Schutz von Dateien mit Systemattributen versteckt gehalten) und schreibgeschützt, indem ihnen die Attribute "Schreibgeschützt", "Versteckt" und "System" zugewiesen werden.
Nach der Installation stellt REMCOS eine dauerhafte Speicherung in der Registry sicher, abhängig davon, welche der folgenden Optionen in der Konfiguration aktiviert sind:
enable_hkcu_run_persistence_flag(Index0x4)HKCU\Software\Microsoft\Windows\CurrentVersion\Run\enable_hklm_run_persistence_flag(Index0x5)HKLM\Software\Microsoft\Windows\CurrentVersion\Run\enable_hklm_policies_explorer_run_flag(Index0x8)HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run\
Anschließend wird die Malware aus dem Installationsordner mit ShellExecuteW neu gestartet, woraufhin der ursprüngliche Prozess beendet wird.
Prozessinjektion
Wenn enable_process_injection_flag (Index 0xD) in der Konfiguration aktiviert ist, injiziert sich REMCOS entweder in einen angegebenen oder in einen Windows-Prozess, der aus einer fest codierten Liste ausgewählt wird, um einer Erkennung zu entgehen.
Der enable_process_injection_flag kann entweder ein boolescher Wert oder der Name eines Zielprozesses sein. Wenn auf „true“ (1) gesetzt, wird der einzufügende Prozess nach dem „Best-Effort“-Prinzip aus den folgenden Optionen ausgewählt:
iexplorer.exeieinstal.exeielowutil.exe
Hinweis: In REMCOS steht nur eine Injektionsmethode zur Verfügung. Wenn wir von Prozessinjektion sprechen, meinen wir speziell die hier beschriebene Methode.
REMCOS verwendet eine klassische ZwMapViewOfSection + SetThreadContext + ResumeThread Technik für die Prozessinjektion. Dies beinhaltet das Kopieren der Datei in die injizierte Binärdatei über den gemeinsam genutzten Speicher, der mit ZwMapViewOfSection abgebildet wird, und das anschließende Umleiten des Ausführungsablaufs zum REMCOS-Einstiegspunkt mit Hilfe der Methoden SetThreadContext und ResumeThread .
Zunächst wird der Zielprozess im angehaltenen Modus mithilfe der CreateProcessW -API erstellt und anschließend sein Thread-Kontext mithilfe der GetThreadContext -API abgerufen.
Anschließend wird mithilfe der ZwCreateSection -API ein gemeinsamer Speicher erstellt und dieser mithilfe der ZwMapViewOfSection -API zusammen mit dem Handle zum Remote-Prozess in den Zielprozess eingebunden.
Anschließend wird die Binärdatei in den entfernten Prozess geladen, indem ihr Header und ihre Abschnitte in den gemeinsam genutzten Speicher kopiert werden.
Bei Bedarf werden Umsiedlungen vorgenommen. Anschließend wird der PEB ImageBaseAddress mithilfe der WriteProcessMemory API korrigiert. Anschließend wird der Thread-Kontext mit einem neuen Einstiegspunkt, der auf den REMCOS-Einstiegspunkt verweist, gesetzt, und die Prozessausführung wird fortgesetzt.
Nachfolgend die Erkennungsmethode dieser Prozessinjektion durch unseren Agenten:
Protokollierungsmodus einrichten
REMCOS verfügt über drei Protokollierungsmodi, die über das Feld logging_mode (Index 0x28) der Konfiguration ausgewählt werden können:
- 0: Keine Protokollierung
- 1: Minimiertes Startsymbol in der Taskleiste
- 2: Konsolenprotokollierung
Durch Setzen dieses Feldes auf 2 wird die Konsole aktiviert, auch wenn die Prozessinjektion aktiviert ist, und es werden zusätzliche Informationen angezeigt.
Browser bereinigen
Wenn die enable_browser_cleaning_on_startup_flag (Index 0x2B) aktiviert ist, löscht REMCOS Cookies und Anmeldeinformationen aus den auf dem Host installierten Webbrowsern.
Laut offizieller Dokumentation besteht das Ziel dieser Funktion darin, die Systemsicherheit gegen Passwortdiebstahl zu erhöhen:
Aktuell werden die Browser Internet Explorer, Firefox und Chrome unterstützt.
Der Bereinigungsprozess beinhaltet das Löschen von Cookies und Anmeldedateien aus den bekannten Verzeichnispfaden der Browser mithilfe der APIs FindFirstFileA, FindNextFileA und DeleteFileA :
Wenn der Auftrag abgeschlossen ist, gibt REMCOS eine Meldung in der Konsole aus.
Erwähnenswert sind zwei zusammenhängende Felder in der Konfiguration:
enable_browser_cleaning_only_for_the_first_run_flag(Index0x2C)browser_cleaning_sleep_time_in_minutes(Index0x2D)
Der Konfigurationswert browser_cleaning_sleep_time_in_minutes bestimmt, wie lange REMCOS wartet, bevor der Job ausgeführt wird.
Wenn enable_browser_cleaning_only_for_the_first_run_flag aktiviert ist, erfolgt die Bereinigung nur beim ersten Start von REMCOS. Anschließend wird der Registrierungswert HKCU/SOFTWARE/{mutex}/FR gesetzt.
Bei nachfolgenden Ausführungen gibt die Funktion direkt zurück, ob der Wert existiert und in der Registrierung festgelegt ist.
Das ist das Ende des ersten Artikels. Im zweiten Teil wird die zweite Hälfte des Ausführungsablaufs von REMCOS behandelt, vom Watchdog bis zur ersten Kommunikation mit dem C2-Server.