QuasarRAT: Nachrichtenverträge, Fernzugriff und Kampagnengrenzen

Prüfauftrag, Stand und Beleggrenze

Archivierte Upstream-Codebasis von Quasar und MITRE-Technikzuordnung; keine Kampagne oder unbekannte Binärdatei. Die Leitfrage lautet: Welche Architektur- und Verhaltensaussagen trägt dieser konkrete Prüfstand, und welche bleiben ausschließlich der Quelle zugeschrieben?

Was belegt ist — und was fehlt

Primärquellen, statisch prüfbarer Code und Laufzeitbeobachtungen haben unterschiedliche Aussagekraft. Die Karte hält diese Ebenen auseinander; fehlende Eigenbeobachtung wird nicht durch Plausibilität ersetzt.

Eintritt und Lieferkette

QuasarRAT ist eine offen verfügbare Fernzugriffscodebasis und kein einzelner unveränderlicher Kampagnen-Hash. Verteilung geschieht außerhalb des Projekts und variiert nach Akteur. Dieser Bericht beginnt deshalb beim prüfbaren Client/Server- und Nachrichtenmodell, nicht bei einer erfundenen universellen Infektionskette.

Architektur und Datenfluss

Gemeinsame protobuf-Verträge definieren Anfragen und Antworten für Systeminformationen, Prozesse, Laufwerke, Dateien, Registry, Desktop und weitere Funktionen. Separate Handler auf Client und Server setzen sie um. Diese explizite Typisierung erlaubt strukturelle Netzwerk- und Speicheranalyse, ohne eine aktive Steuerverbindung aufzubauen.

Originalcode als Architekturbeleg

Der kurze Auszug zeigt nur die im Kapitel benannte Struktur. Er wird nicht ausgeführt und enthält keine vollständige operative Implementierung.

7    [ProtoContract]
8    public class GetSystemInfoResponse : IMessage
9    {
10        [ProtoMember(1)]
11        public List<Tuple<string, string>> SystemInfos { get; set; }
12    }

Analyseabwehr und Persistenz

MITRE dokumentiert unter anderem Run-Key-/Startup-Persistenz und Varianten mit zusätzlichen Umgehungstechniken. Solche Funktionen können in Forks verändert oder entfernt sein. Ein Namespace, Zertifikat oder Klassenname ist deshalb nur zusammen mit Protokoll- und Hostverhalten aussagekräftig.

Fähigkeiten, Ziel und Wirkung

Die Codebasis umfasst Fernshell, Dateiverwaltung, Registry-, Prozess-, Desktop- und Zugangsdatenfunktionen. Diese Capability-Liste beschreibt mögliche Wirkung des geprüften Stands; sie beweist nicht, welche Funktion in einer konkreten Infektion benutzt wurde.

Telemetrieplan und Beweiskette

Defensive Modelle sollten .NET-/protobuf-Struktur, persistente Clientinstallation, ausgehende langlebige Verbindung und nachfolgende sensitive Aktionen verbinden. Forks reduzieren den Wert reiner String- oder Namespace-Regeln; Sequenzen bleiben robuster. Für eine belastbare Untersuchung werden Prozess-GUID und vollständige Elternkette, Nutzer und Sitzung, Befehlszeile, Signatur- und Hashstatus, Datei- und Registryänderungen, DNS-/Verbindungsziele sowie nachgelagerte Zugriffe auf sensible Daten in einer gemeinsamen Zeitleiste erhalten. Zeitnähe ist dabei ein Belegparameter, keine bloße Visualisierung. Fehlende Sensorabdeckung wird pro Stufe markiert, damit ein nicht sichtbares Ereignis nicht fälschlich als nicht erfolgt gilt.

Detection Engineering und Gegenprüfung

Defensive Modelle sollten .NET-/protobuf-Struktur, persistente Clientinstallation, ausgehende langlebige Verbindung und nachfolgende sensitive Aktionen verbinden. Forks reduzieren den Wert reiner String- oder Namespace-Regeln; Sequenzen bleiben robuster. Das folgende Modell ist bewusst eng, nicht engine-validiert und muss gegen legitime Administrations- und Softwarepfade getestet werden.

1title: QuasarRAT remote-shell sequence candidate
2status: experimental
3logsource:
4  product: windows
5  category: process_creation
6detection:
7  selection:
8    Image|endswith: '\\cmd.exe'
9    ParentImage|contains:
10      - '\\AppData\\'
11      - '\\Temp\\'
12    CommandLine|contains: '/c'
13  condition: selection
14falsepositives:
15  - Legitimate administrative or software activity with the same isolated pattern
16level: medium

Alternativhypothesen und Negativtests

Vor einer Familienzuordnung werden die im Modell verwendeten Einzelmerkmale getrennt gegen Softwareverteilung, Administratorwerkzeuge, Installer, Browser- oder Backupsoftware und bekannte interne Skripte geprüft. Mindestens ein struktureller Anker und eine zeitlich passende Verhaltenskette müssen zusammenpassen. Offener Upstream-Code ist Architekturbeleg, aber keine Zuordnung einer Binärdatei oder eines Akteurs. Der Stand ist archiviert; Forks können Protokoll, Persistenz und Fähigkeiten verändern. Ein negativer Gegencheck verwirft nur die geprüfte Hypothese; er ist keine allgemeine Entwarnung.

Attribution und Variantenrisiko

Offener Upstream-Code ist Architekturbeleg, aber keine Zuordnung einer Binärdatei oder eines Akteurs. Der Stand ist archiviert; Forks können Protokoll, Persistenz und Fähigkeiten verändern.

Abschließende Bewertung

Die Analyse liefert eine belastbare Architektur- und Detektionsgrundlage für den benannten Stand. Sie ist kein Beweis für aktuelle Aktivität, vollständige Variantenabdeckung oder einen bestimmten Betreiber.

Grenzen der Prüfung

• Keine unabhängige Sample-, Laufzeit-, C2- oder Kampagnenverifikation.
• Offener Upstream-Code ist Architekturbeleg, aber keine Zuordnung einer Binärdatei oder eines Akteurs. Der Stand ist archiviert; Forks können Protokoll, Persistenz und Fähigkeiten verändern.
• Defensive Modelle sind nicht mit einer Zielengine validiert.