Dateilose Malware
Wie man das Risiko von PowerShell-Angriffen minimiert
Fortsetzung des Artikels von Teil 1
Warum gängige Präventionsmaßnahmen nicht greifen
Für die Entdeckung und spätere forensische Analyse ist dateilose Malware eine große Herausforderung. So sind File-Scanning-Technologien, sprich dateibasierte Sicherheitsmaßnahmen wie der klassische Anti-Viren-Schutz (AV), zwar eine bewährte erste Verteidigungslinie, um Cyberkriminelle daran zu hindern, sich in eine Infrastruktur zu hacken, im Kampf gegen hoch entwickelte Bedrohungen sind sie allerdings unbrauchbar.
Da Fileless-Malware nicht in einer auf einem Server gespeicherten Datei stagniert, sondern direkt im Speicher des Systems ausgeführt wird, umgeht sie datei- und signatur-basierte Scanner problemlos. Durch einen einfachen Neustart lässt sie sich zudem einfach von einem Rechner entfernen, was eine Identifikation zusätzlich erschwert. Gleichzeitig bleiben die Änderungen in der System-Registrierung, welche die Skripte vorgenommen haben, bestehen, sodass bösartiger Code bei jedem Neustart wieder ausgeführt werden kann und dabei nahezu unsichtbar bleibt. Der Albtraum eines jeden Sicherheitsprofis. Um sich vor diesen Bedrohungen zu schützen, sind weiterführende Erkennungsmechanismen erforderlich, ebenso wie eine konsequente Minimierung der unternehmensweiten Angriffsfläche.
Dateilose PowerShell-Angriffe reduzieren
Um dateilose PowerShell-Angriffe zuverlässig zu erkennen und zu blocken, bedarf es eines mehrstufigen Sicherheitsansatzes, der verschiedene Techniken und Maßnahmen kombiniert. Wichtig ist dabei eine multiplexe Endpunktschutz-Strategie, die neben klassischem AV auch Technologien umfasst, die nicht nur auf Signaturen oder heuristischen Analysen beruhen, die ausschließlich bei Dateien funktionieren. Vielmehr braucht es Lösungen, die mit Verhaltensanalyse arbeiten und schadhaften Code anhand seines Verhaltens bei der Ausführung erkennen.
Eine weitere wichtige Schutzmaßnahme ist das Einschränken der unternehmensweiten Zugriffsrechte nach dem Least-Privilege-Prinzip. So sollte jeder Mitarbeiter ausschließlich über die Berechtigungen verfügen, die er zur Erledigung seiner Aufgaben benötigt. Zu weit gefasste Privilegien, aber auch das Teilen von Accounts (Shared Accounts) führen zu einer unnötigen Vergrößerung der potenziellen Angriffsfläche. Lokale Administratorrechte sollten sorgfältig von Workstations und Desktops entfernt und Administratorzugriffe für gewöhnliche Benutzer soweit es geht eingeschränkt werden.
Darüber hinaus sollten kritische Anwendungen wie PowerShell, aber auch wscript, cscript oder cmd.exe, aktiv überwacht werden. Hierzu eignen sich Privileged-Access-Management-Lösungen mit spezieller Anwendungskontrolle. Indem Security-Verantwortliche Richtlinien für gefährdete Applikationen erstellen, können sie eigenständig festlegen, welche Skripts für welche Benutzer zulässig sind und welche Rechner, Benutzergruppen oder bestimmte Einzelnutzer gesperrt sind. Gleichzeitig empfiehlt es sich, eine Whitelist-Bibliothek mit sicheren Scripts aufzustellen, die von Usern ausgeführt werden können, die normalerweise nicht über ausreichende Privilegien zum Ausführen von Skripts verfügen. Das versetzt IT-Abteilungen in der Lage, selbstständig einzuschränken, wer Zugang zu diesen leistungsfähigen Werkzeugen hat. Gleichzeitig können sie so überwachen, ob und von wem ein Skript ausgeführt wird, wodurch sich die Angriffsfläche reduziert. Dabei minimiert die Einschränkung der Skript-Verbreitung nicht nur Angriffe durch externe Akteure, sondern auch Insider-Attacken.
Auch Microsoft hat in den letzten Jahren einiges getan, um den Einsatz von PowerShell sicherer zu machen. So verfügt das Tool über Security-Funktionen, die sowohl die Nutzung der Skriptsprache einschränken als auch andere Angriffswege blockieren. In Kombination mit einer wirksamen Endpunktsicherheit und einer aktiven Anwendungskontrolle, ist auf diese Weise jedes Sicherheitsteam in der Lage, PowerShell-Bedrohungen zu bekämpfen.
Markus Kahmen ist Regional Director DACH bei Thycotic.
- Wie man das Risiko von PowerShell-Angriffen minimiert
- Warum gängige Präventionsmaßnahmen nicht greifen
Lesen Sie mehr zum Thema
