Eine häufige Art von Angriffen ist die Ausführung eines schädlichen Prozesses innerhalb von scheinbar harmlosen Prozessen. Verdacht kann durch den Pfad zur ausführbaren Datei aufkommen: Häufig nutzt Malware die Ordner AppData oder Temp, was für legitime Programme untypisch ist. Gerechterweise sollte erwähnt werden, dass einige Update-Utilities in AppData ausgeführt werden, weshalb eine bloße Überprüfung des Startorts nicht ausreicht, um zu behaupten, dass ein Programm schädlich ist.
Ein weiterer Faktor für die Legitimität ist die kryptografische Signatur: Viele Originalprogramme sind vom Anbieter signiert. Das Fehlen einer Signatur kann als Methode zur Identifizierung verdächtiger Autostart-Elemente verwendet werden. Aber erneut gibt es auch Malware, die ein gestohlenes Zertifikat verwendet, um sich selbst zu signieren.
Es ist auch möglich, die Werte von kryptografischen Hashes wie MD5 oder SHA256 zu überprüfen, die möglicherweise bestimmten bereits entdeckten Malware-Exemplaren entsprechen. Eine statische Analyse kann durch Inspektion der Signaturen innerhalb der Software (mithilfe von Yara-Regeln oder Antivirenprodukten) erfolgen. Darüber hinaus gibt es dynamische Analysen (das Ausführen der Software in einer sicheren Umgebung und die Beobachtung ihres Verhaltens) und Reverse Engineering.
Es kann viele Anzeichen für einen bösartigen Prozess geben. In diesem Artikel erklären wir, wie man die Überwachung entsprechender Ereignisse in Windows aktiviert und welche Anzeichen dabei berücksichtigt werden, basierend auf der integrierten Regel zur Erkennung verdächtiger Prozesse. InTrust ist eine zum Sammeln, Analysieren und Speichern von unstrukturierten Daten, die bereits Hunderte von vorgefertigten Reaktionen auf verschiedene Arten von Angriffen enthält.
Wenn ein Programm gestartet wird, wird es in den Arbeitsspeicher des Computers geladen. Die ausführbare Datei enthält Computeranweisungen und unterstützende Bibliotheken (wie z. B. *.dll). Nachdem der Prozess bereits gestartet wurde, kann er zusätzliche Threads erstellen. Threads ermöglichen es dem Prozess, verschiedene Anweisungssets gleichzeitig auszuführen. Es gibt viele Möglichkeiten, wie schadhafter Code in den Speicher gelangen und ausgeführt werden kann. Schauen wir uns einige davon an.
Die einfachste Methode, einen schädlichen Prozess zu starten, besteht darin, den Benutzer zu zwingen, ihn direkt auszuführen (z. B. aus einem E-Mail-Anhang). Danach kann er mithilfe des RunOnce-Schlüssels bei jedem Einschalten des Computers gestartet werden. Dazu gehört auch „dateiloses“ Malware, das PowerShell-Skripte in Registrierungs-Schlüsseln speichert, die basierend auf einem Trigger ausgeführt werden. In diesem Fall ist das PowerShell-Skript der schadhafte Code.
Ein Problem bei der offensichtlichen Ausführung von Malware ist, dass es sich um einen bekannten Ansatz handelt, der leicht entdeckt werden kann. Einige Malware-Programme verwenden geschicktere Methoden, indem sie einen anderen Prozess nutzen, um im Speicher ausgeführt zu werden. Folglich kann der Prozess einen anderen Prozess erstellen, indem er einen bestimmten Computerbefehl ausführt und die ausführbare Datei (.exe) angibt, die gestartet werden soll.
Die Datei kann entweder mit dem vollständigen Pfad angegeben werden (z. B. C:\Windows\system32\cmd.exe) oder mit einem unvollständigen (z. B. cmd.exe). Wenn der ursprüngliche Prozess unsicher ist, erlaubt er die Ausführung von illegitimen Programmen. Ein Angriff könnte so aussehen: Der Prozess startet cmd.exe, ohne den vollständigen Pfad anzugeben, und der Angreifer platziert seine eigene cmd.exe an einem Ort, an dem der Prozess sie vor der legitimen ausführt. Nach dem Start der Malware kann diese wiederum ein legitimes Programm (z. B. C:\Windows\system32\cmd.exe) ausführen, damit das ursprüngliche Programm weiterhin ordnungsgemäß funktioniert.
Eine Variante des vorherigen Angriffs ist die DLL-Injektion in einen legitimen Prozess. Wenn der Prozess gestartet wird, sucht er nach und lädt Bibliotheken, die seine Funktionalität erweitern. Bei der Verwendung von DLL-Injektion erstellt der Angreifer eine bösartige Bibliothek mit demselben Namen und API wie die legitime. Das Programm lädt die bösartige Bibliothek, die wiederum die legitime lädt und bei Bedarf für die Ausführung von Operationen aufruft. Die bösartige Bibliothek fungiert dann als Proxy für die gute Bibliothek.
Ein weiterer Weg, bösartigen Code in den Speicher zu bringen, besteht darin, ihn in einen bereits laufenden unsicheren Prozess einzufügen. Prozesse erhalten Eingaben aus verschiedenen Quellen – sie lesen aus Netzwerken oder Dateien. Normalerweise führen sie Prüfungen durch, um die Legitimität der Eingaben zu gewährleisten. Aber einige Prozesse sind beim Ausführen von Anweisungen nicht ausreichend geschützt. Bei einem solchen Angriff gibt es keine Bibliothek auf der Festplatte oder eine ausführbare Datei mit dem bösartigen Code. Alles wird im Speicher zusammen mit dem ausgenutzten Prozess gespeichert.
Lassen Sie uns nun die Methode zur Aktivierung der Ereignissammlung in Windows und der Regel in InTrust betrachten, die Schutz vor solchen Bedrohungen bietet. Zuerst aktivieren wir sie über die InTrust-Verwaltungskonsole.
Die Regel nutzt die Möglichkeiten zur Prozessverfolgung im Betriebssystem Windows. Leider ist die Aktivierung der Sammlung solcher Ereignisse alles andere als offensichtlich. Es müssen drei verschiedene Gruppenrichtlinieneinstellungen geändert werden:
Computerkonfiguration > Richtlinien > Windows-Einstellungen > Sicherheitseinstellungen > Lokale Richtlinien > Überwachungsrichtlinie > Überwachung der Prozessverfolgung
Computerkonfiguration > Richtlinien > Windows-Einstellungen > Sicherheitseinstellungen > Erweiterte Überwachungsrichtlinieneinstellungen > Überwachungsrichtlinien > Detaillierte Verfolgung > Überwachung der Prozesserstellung
Computerkonfiguration > Richtlinien > Administrative Vorlagen > System > Überwachung der Prozesseerstellung > Befehlszeile in Ereignissen zur Prozesseerstellung einbeziehen
Nachdem die Einstellungen aktiviert wurden, ermöglichen die InTrust-Regeln die Erkennung zuvor unbekannter Bedrohungen, die verdächtiges Verhalten zeigen. Zum Beispiel kann man folgendermaßen identifizieren: die Malware Dridex. Durch das HP Bromium-Projekt ist bekannt, wie eine solche Bedrohung funktioniert.
In seinen Aktionen nutzt Dridex schtasks.exe, um einen geplanten Task zu erstellen. Der Einsatz dieses Kommandozeilen-Tools wird als äußerst verdächtiges Verhalten angesehen, ähnlich wie der Start von svchost.exe mit Parametern, die auf Benutzermappen hinweisen, oder mit Parametern, die den Befehlen „net view“ oder „whoami“ ähneln. Hier ist ein Auszug aus dem entsprechenden :
detection:
selection1:
CommandLine: '*svchost.exe C:Users\*Desktop\*'
selection2:
ParentImage: '*svchost.exe*'
CommandLine:
- '*whoami.exe /all'
- '*net.exe view'
condition: 1 von ihnenIn InTrust wird sämtliches verdächtiges Verhalten in einer Regel zusammengefasst, da die meisten dieser Aktionen nicht spezifisch für eine bestimmte Bedrohung sind, sondern eher im Gesamten verdächtig und in 99 % der Fälle für weniger noble Zwecke genutzt werden. Eine solche Liste von Aktionen umfasst, ist aber nicht beschränkt auf:
- Prozesse, die aus ungewöhnlichen Orten ausgeführt werden, wie z.B. benutzerspezifischen temporären Ordnern.
- Ein wohlbekannter Systemprozess mit verdächtiger Vererbung — einige Bedrohungen könnten versuchen, den Namen von Systemprozessen zu verwenden, um unentdeckt zu bleiben.
- Verdächtige Ausführungen administrativer Werkzeuge, wie cmd oder PsExec, wenn sie Anmeldeinformationen des lokalen Systems oder verdächtige Vererbungen verwenden.
- Verdächtige Schattenkopieroperationen — typisches Verhalten von Ransomware vor der Verschlüsselung des Systems, sie töten Backups ab:
— Über vssadmin.exe;
— Über WMI. - Registrierungs-Dumps ganzer Registry-Bäume.
- Horizontale Ausbreitung von Malware durch Fernstart von Prozessen mit Befehlen wie at.exe.
- Verdächtige lokale Gruppenoperationen und Gruppenoperationen im Netzwerk mit net.exe.
- Verdächtige Firewall-Operationen mit netsh.exe.
- Verdächtige Manipulationen von ACLs.
- Verwendung von BITS zur Datenexfiltration.
- Verdächtige Manipulationen mit WMI.
- Verdächtige Skriptbefehle.
- Versuche, sichere Systemdateien zu dumppen.
Die kombinierte Regel funktioniert hervorragend zur Erkennung von Bedrohungen wie RUYK, LockerGoga und anderen Ransomware-Viren, Malware und Cybercrime-Toolkits. Die Regel wurde vom Anbieter in Produktionsumgebungen getestet, um Fehlalarme zu minimieren. Dank des SIGMA-Projekts erzeugen die meisten dieser Indikatoren nur minimale Rauschereignisse.
Da es sich bei InTrust um eine Überwachungsregel handelt, können Sie ein Reaktionsszenario auf eine Bedrohung durchführen. Sie können eines der integrierten Szenarien verwenden oder Ihr eigenes erstellen, und InTrust wird es automatisch verbreiten.
Darüber hinaus können Sie alle mit dem Ereignis verbundenen Telemetriedaten überprüfen: PowerShell-Skripte, Prozessausführungen, Manipulationen an geplanten Aufgaben, administrative WMI-Aktivitäten und diese für Postmortems bei Sicherheitsvorfällen verwenden.
In InTrust gibt es Hunderte anderer Regeln, darunter:
- Erkennung eines Downversioning-Angriffs in PowerShell – wenn jemand absichtlich eine ältere Version von PowerShell verwendet, da in der älteren Version keine Auditierung des Geschehens möglich war.
- Identifizierung von Hochprivilegierten Systemzugängen – wenn Konten, die Mitglied einer bestimmten privilegierten Gruppe (wie z.B. Domänenadministratoren) sind, versehentlich oder aufgrund von Sicherheitsvorfällen interaktiv auf Arbeitsstationen anmelden.
InTrust ermöglicht die Umsetzung bewährter Sicherheitspraktiken durch vorinstallierte Erkennungs- und Reaktionsregeln. Wenn Sie der Meinung sind, dass etwas anders funktionieren sollte, können Sie eine Kopie der Regel erstellen und nach Ihren Bedürfnissen anpassen. Anfragen für Pilotprojekte oder zur Beschaffung von Distributionen mit vorübergehenden Lizenzen können über auf unserer Webseite.
Abonnieren Sie unsere , wo wir kurze Notizen und interessante Links veröffentlichen.
Lesen Sie auch unsere anderen Artikel zum Thema Informationssicherheit:
(beliebter Artikel)
Quelle: habr.com
