Sichere PowerShell-Nutzung im Unternehmen
In diesem Artikel erklären wir sichere PowerShell-Nutzung – und stellen unten unsere Softwarelösung vor. PowerShell ist längst mehr als nur ein Administrationswerkzeug. Es ist ein zentrales Automatisierungs-Framework in Windows-Umgebungen, das sowohl mächtige Möglichkeiten für Administratoren als auch ein attraktives Ziel für Angreifer bietet. Die Kunst liegt darin, PowerShell so abzusichern, dass Sie die Vorteile nutzen können, ohne sich unnötigen Risiken auszusetzen.
Warum PowerShell-Sicherheit entscheidend ist
Viele Unternehmen verlassen sich auf PowerShell für alltägliche Aufgaben: Benutzerverwaltung, Konfigurationsänderungen oder Deployment-Prozesse. Gleichzeitig ist PowerShell aber ein häufiges Einfallstor für Cyberangriffe. Angreifer nutzen es, weil es bereits auf jedem Windows-System vorhanden ist, privilegierte Aktionen ausführen kann und in der Regel nicht blockiert wird.
Die Absicherung von PowerShell ist deshalb kein Luxus, sondern eine zentrale Maßnahme in jeder IT-Sicherheitsstrategie. Besonders im Hinblick auf die Empfehlungen des Bundesamtes für Sicherheit in der Informationstechnik (BSI) sollten Unternehmen konsequent Sicherheitsrichtlinien umsetzen.
Execution Policy: AllSigned als Standard
Ein wichtiger erster Schritt ist die Konfiguration der Execution Policy. Diese Richtlinie bestimmt, unter welchen Bedingungen PowerShell-Skripte ausgeführt werden dürfen. Standardmäßig ist oft „RemoteSigned“ aktiv – ein akzeptabler, aber nicht optimaler Schutz.
Sicherer ist die Einstellung AllSigned. Dabei müssen alle Skripte, egal ob lokal erstellt oder aus dem Netz geladen, mit einer vertrauenswürdigen digitalen Signatur versehen sein. Auf diese Weise verhindern Sie, dass unsignierte Skripte – sei es durch menschliche Fehler oder bösartige Absicht – unkontrolliert laufen.
Damit diese Policy wirksam bleibt, ist es jedoch entscheidend, dass Administratoren die Regel nicht einfach umgehen. Ein entsprechender organisatorischer Rahmen und klare Vorgaben sind unverzichtbar.
Authenticode-Signaturen verstehen und nutzen
Die Grundlage der AllSigned-Policy sind Authenticode-Signaturen. Sie ermöglichen es, Skripte kryptographisch eindeutig zu kennzeichnen. Mit einem Zertifikat wird der Herausgeber identifizierbar, und jede nachträgliche Manipulation am Skript macht die Signatur ungültig.
Unternehmen sollten ein internes Public-Key-Infrastructure-(PKI)-System aufbauen oder ein vertrauenswürdiges Zertifikat von einer anerkannten Zertifizierungsstelle verwenden. Das Ziel ist, dass jedes PowerShell-Skript eine überprüfbare Herkunft hat.
Besonders wichtig ist dabei die Automatisierung: Das Signieren von Skripten sollte in den Entwicklungs- und Rollout-Prozess integriert werden. Nur so wird sichergestellt, dass Sicherheit nicht vergessen oder manuell umgangen wird.
Logging und Nachvollziehbarkeit schaffen
Eine weitere Säule der sicheren PowerShell-Nutzung ist umfassendes Logging. PowerShell bietet mit der „Script Block Logging“-Funktion eine Möglichkeit, Befehle und Skriptinhalte lückenlos aufzuzeichnen. Zusätzlich können Transkript-Funktionen genutzt werden, um die komplette Sitzung mitsamt Eingaben und Ausgaben zu protokollieren.
Diese Daten sind für Sicherheitsanalysen unerlässlich. Angriffe lassen sich nur dann nachvollziehen, wenn ausreichende Spuren vorhanden sind. Besonders bei Vorfällen, die sich erst später zeigen, können historische Logdaten entscheidend sein.
Damit Logging effektiv ist, müssen die Daten zentral gesammelt und vor Manipulation geschützt werden – zum Beispiel durch Integration in ein SIEM-System (Security Information and Event Management).
AMSI: Angriffe direkt erkennen
Ein oft unterschätztes Werkzeug ist die Antimalware Scan Interface (AMSI). Sie wurde von Microsoft entwickelt, um Skripte – einschließlich PowerShell – in Echtzeit auf Schadcode zu prüfen.
AMSI kann Inhalte schon vor der Ausführung an die installierte Antiviren-Lösung übergeben. Das bedeutet: Selbst wenn ein Angreifer ein Skript verschleiert oder in den Speicher injiziert, bevor es ausgeführt wird, kann AMSI den schädlichen Code noch erkennen und blockieren.
Für Unternehmen heißt das: AMSI sollte nicht deaktiviert, sondern aktiv unterstützt werden. In Kombination mit moderner Endpoint-Security kann so ein zusätzlicher Schutzschild aufgebaut werden, der auch Zero-Day-Angriffe abwehrt.
Typische Angriffsmuster: Invoke-Expression und DownloadFile
Angreifer nutzen PowerShell besonders gerne für zwei Muster:
- Invoke-Expression (IEX): Mit diesem Cmdlet können Befehle dynamisch zur Laufzeit interpretiert werden. Ein klassischer Angriff lädt ein verschleiertes Skript aus dem Internet und führt es direkt aus – ohne dass eine Datei auf der Festplatte abgelegt wird.
- DownloadFile: Über .NET-Klassen wie
System.Net.WebClient
oderInvoke-WebRequest
können Angreifer Schadsoftware direkt aus dem Netz nachladen.
Beide Muster lassen sich durch konsequentes Logging und AMSI-Überwachung erkennen. Zudem sollten Unternehmen PowerShell-Constrained-Language-Mode und Just Enough Administration (JEA) nutzen, um die Angriffsfläche weiter einzuschränken.
BSI-Anforderungen für sichere PowerShell-Nutzung
Das Bundesamt für Sicherheit in der Informationstechnik (BSI) gibt klare Empfehlungen:
- Execution Policy AllSigned verpflichtend einsetzen.
- Skript-Signaturen konsequent nutzen und kontrollieren.
- Logging aktivieren und zentral auswerten.
- AMSI nicht deaktivieren, sondern aktiv in die Sicherheitsstrategie integrieren.
- Rollenbasierte Administration und eingeschränkte Berechtigungen einführen.
Die Umsetzung dieser Punkte erhöht die Sicherheit erheblich. Gerade im Kontext der KRITIS-Verordnung (kritische Infrastrukturen) und branchenspezifischer Sicherheitsstandards ist die Einhaltung dieser Vorgaben Pflicht.
Organisatorische Maßnahmen ergänzen die Technik
Technische Einstellungen reichen allein nicht aus. Unternehmen müssen sicherstellen, dass Administratoren geschult sind, Richtlinien verstehen und diese nicht leichtfertig umgehen. Auch regelmäßige Audits und Kontrollen gehören dazu.
Besonders in größeren Umgebungen empfiehlt es sich, Prozesse zur Skriptverwaltung aufzusetzen. Versionierung, Freigabeprozesse und automatisierte Signaturprüfung sorgen für ein hohes Maß an Verlässlichkeit.
Weiter unten im Artikel zeigen wir unsere Softwarelösung, die genau diese organisatorischen und technischen Aspekte unterstützt.

Praxisnahe Beispiele aus Angriffsszenarien
Ein realistisches Angriffsszenario könnte so aussehen: Ein Mitarbeiter erhält eine scheinbar harmlose E-Mail mit einem PowerShell-Befehl, der über „Invoke-Expression“ eine Datei aus dem Internet lädt. Ohne AllSigned-Policy und Logging läuft dieser Code unbemerkt.
In einem anderen Fall nutzt ein Angreifer einen kompromittierten Administrator-Account, um PowerShell-Remoting zu missbrauchen. Ohne JEA und Logging fällt dieser Angriff erst auf, wenn bereits Daten exfiltriert wurden.
Diese Beispiele zeigen: Ohne klare Regeln und technische Schutzmechanismen ist PowerShell ein gefährliches Werkzeug in den Händen von Angreifern.
Integration in den gesamten Sicherheitsprozess
PowerShell-Sicherheit darf nicht isoliert betrachtet werden. Sie ist Teil einer ganzheitlichen IT-Sicherheitsstrategie. Endpoint-Schutz, Netzwerksicherheit, Patchmanagement und Mitarbeiterschulungen greifen ineinander.
Gerade durch die zentrale Rolle von PowerShell ist es sinnvoll, es in den DevOps- oder CI/CD-Prozess einzubinden. Skripte werden dort automatisch getestet, signiert und überprüft. So wird Sicherheit nicht nachträglich, sondern von Anfang an integriert.
Unsere Softwarelösung als praktische Unterstützung
Die Umsetzung aller genannten Maßnahmen ist komplex. Hier setzt unsere Softwarelösung an: Sie unterstützt Unternehmen dabei, PowerShell-Skripte sicher zu prüfen, zu signieren und zu überwachen.
Ein besonderer Vorteil ist die einfache Integration in bestehende Prozesse. Skripte können automatisiert analysiert, mit Authenticode signiert und auf verdächtige Muster wie „Invoke-Expression“ oder „DownloadFile“ geprüft werden.
Damit entlasten Sie Ihre Administratoren, erfüllen die Anforderungen des BSI und schaffen eine konsistente Sicherheitsarchitektur.
Fazit: PowerShell sicher nutzen und Vorteile behalten
PowerShell ist mächtig – aber auch riskant. Unternehmen, die auf AllSigned setzen, Authenticode-Signaturen einsetzen, Logging konsequent umsetzen, AMSI nutzen und typische Angriffsmuster kennen, sind klar im Vorteil.
Die Einhaltung der BSI-Anforderungen schafft nicht nur Sicherheit, sondern auch Compliance. Organisatorische Prozesse, Schulungen und die richtige Softwareunterstützung machen das Gesamtpaket rund.
Unsere Software kann neben VBA-Makros auch PowerShell- und andere Skripte auf Schadcode prüfen und signieren.
Script-Prüfung & Signatur – unsere Softwarelösung
Wir haben eine Software, die jede Art von Skript (z. B. PowerShell, Python, Batch, WSH, Office) auf Schadcode prüft und signiert – und wir führen sie Ihnen gern live vor.
Hier geht es zur Online-Demo. Melden Sie sich gern bei uns für eine individuelle Vorführung.
Zusätzlich unterstützen wir Sie bei der Ablösung von Makros und Skripten – von der Bestandsaufnahme bis zur sicheren Migration. Nehmen Sie gerne Kontakt auf!
https://pixabay.com/illustrations/window-hand-magnifying-glass-binary-4354467/
https://agile-unternehmen.de/powershell-skripte-pruefen-signieren-tools-und-software-im-vergleich