Office-Makros und PowerShell-Skripte signieren – Teil 1

Code signieren und Policy einrichten

Die letzten Jahre haben gezeigt, dass sich Ransomware und Banking-Trojaner wie Emotet und Co. gerne über Skripte und Makros verbreiten. Das Signieren von Skripten und insbesondere von Makros – bekannt aus der Office-Produktlinie von Microsoft – wird entsprechend immer wichtiger.

Oneconsult kann dies durch diverse Incident-Response-Einsätze bestätigen und konnte dabei auch die Auswirkungen von Ransomware ^[1], wie zum Beispiel Ryuk, miterleben. Den Kunden wird in solchen Fällen sowie auch vorbeugend, etwa bei einem Configuration Review, empfohlen, Makros in Dokumenten abzuschalten oder möglichst eingeschränkt zuzulassen.

In diesem zweiteiligen Beitrag möchte ich darauf eingehen, welche Eigenheiten zu beachten sind, wenn Sie mittels Zertifikaten Makros signieren und nur noch solch signierten Code in Ihrem Unternehmen zur Ausführung zulassen möchten. Da ich oft mit PowerShell arbeite, ist es für mich naheliegend, dass ich in diesem Zuge auch auf das Signieren von PowerShell-Skripten eingehe.

Der erste Teil beschreibt das Einrichten und die Reichweite des Schutzes in Office und PowerShell sowie das Signieren von Makros und PowerShell-Skripten. Im folgenden zweiten Teil «Office-Makros und PowerShell-Skripte signieren – Teil 2» wird auf die Eigenheiten eingegangen, die es im Umgang mit signiertem Code geben kann. Um den Rahmen nicht zu sprengen, wird in diesem Artikel auf die Erklärung verzichtet, wie Sie mittels einer internen oder externen Zertifizierungsstelle (Certificate Authority, CA) ein in Ihrem Unternehmen akzeptiertes Code-Signing-Zertifikat ausstellen können.

Makros in Office einschränken

Immer dann, wenn Makros nicht ganz abgeschaltet werden können, muss ein Mittelweg gefunden werden. Eine Möglichkeit besteht darin, die Ausführung von Makros in Office soweit einzuschränken, dass nur noch signierte Makros zugelassen werden. Nachfolgend wird gezeigt, wie dies per Gruppenrichtlinienobjekten (Group Policy Objects, kurz GPO) eingestellt werden kann und welche Grenzen dabei bestehen. Hier ist zu beachten, dass die Richtlinien nur für folgende Office-Versionen gelten:

• Office Professional Plus 2013
• Office Professional Plus 2016
• Office Professional Plus 2019
• Microsoft 365 Apps for Enterprise (Office 365 ProPlus)
• Microsoft 365 Enterprise E3
• Microsoft 365 Enterprise E5

Für Versionen wie Microsoft 365 Business oder Enterprise E1 sowie weitere Editionen gelten die Gruppenrichtlinien nicht. Man kann die Einstellungen zwar auch per Registry festlegen, dies wird jedoch nicht empfohlen. Die Einstellung kann vom Benutzer trotzdem jederzeit geändert werden. Wenn man prüfen möchte, welche Version nun die Gruppenrichtlinien unterstützt oder nicht, kann man online bei Microsoft ^[2] nachsehen und nach «Group Policy support» suchen. Sollte Interesse an den Registry Keys bestehen, so gibt es dazu diverse Foren ^[3], in denen das Thema behandelt wird.

Um GPOs für Office verwenden zu können, müssen zunächst ADMX-Vorlagen installiert werden. Diese können bei Microsoft heruntergeladen werden, z. B. für Office 2016, Office 2019 und Microsoft 365 (vormals Office 365): https://www.microsoft.com/en-us/download/details.aspx?id=49030. Die Installation der Vorlagen ist relativ einfach: Man muss die ADMX- und-ADML Dateien in den zentralen Speicher für administrative Vorlagen kopieren. Dieser Speicher liegt auf dem Domänencontroller unter \\domain.com\SYSVOL\domain.com\policies\PolicyDefinitions. Sollte der Ordner «PolicyDefinitions» noch nicht existieren, muss er neu angelegt werden.

Die Einstellungen zu Makros sind nach dem Import in den GPOs in den Benutzereinstellungen unter «Policies\Administrative Templates» zu finden.

Für folgende Office-Produkte kann man Makros mit der angegebenen Policy einschränken:

Mit folgender Einstellung werden alle ausser die signierten Makros deaktiviert:

Sobald die GPOs auf einem Arbeitsplatzrechner angewendet wurden, wird etwa Word eine Warnung anzeigen, wenn unsignierte Makros in einem Dokument enthalten sind. Der Benutzer kann die Makros nicht starten. Über die Schaltfläche «Optionen» kann er sich darüber informieren, weshalb die Makros nicht ausgeführt werden.

Leider wird bei diesen Einstellungen jedes Makro zugelassen, das mit einem Zertifikat von einer als vertrauenswürdig eingestuften Zertifizierungsstelle (Certificate Authority, CA) signiert wurde. Der Autor vermisst die Möglichkeit bestimmen zu können, welche Zertifikate oder CAs explizit zugelassen werden und welche nicht.

Für mehr Sicherheit wäre eine (optionale) Whitelisting-Möglichkeit zu begrüssen. Viele Unternehmen betreiben etwa eine eigene interne CA. Da wäre es ein Sicherheitsvorsprung, würden z. B. nur Makros zugelassen, die mit einem durch die interne CA ausgestelltem Zertifikat signiert sind.

Execution Policy unter PowerShell nutzen

Bei PowerShell kann man, ähnlich wie bei Office, die Ausführung von Skripten ohne gültige Signatur unterbinden: mit der Execution Policy. Ein Angreifer kann die Policy recht einfach umgehen, dennoch ist sie eine Schutzmassnahme: So verhindert die Execution Policy z. B. einfacher gestrickte Malware, welche per PowerShell Skripte ausführen will, und unterbindet unerwünschte Skripte, gestartet durch unerfahrene Benutzer.

Die Execution Policy kann per GPO auf die Geräte verteilt werden.

Sie ist unter folgendem Pfad zu finden:

Computer Configuration\Policies\Administrative Templates\Windows Components\Windows PowerShell\Turn on Script execution

Nach der Synchronisation der GPOs auf einen Computer werden unsignierte PowerShell-Skripte nicht mehr ausgeführt.

Auch hier kann nicht eingeschränkt werden, welchen Zertifikaten bzw. welchen CAs vertraut werden soll. Ein signiertes Skript, dessen Signing-Zertifikat von einer vertrauenswürdigen CA ausgestellt wurde, wird ausgeführt.

Die eingestellte Execution Policy kann per PowerShell mit folgendem Befehl überprüft werden:

Get-ExecutionPolicy

Leider kann die Execution Policy von PowerShell auf verschiedene Art und Weise umgangen werden ^[4]. Die wohl einfachste ist, den Inhalt eines Skriptes zu kopieren und in ein offenes PowerShell-Fenster einzufügen.

Office-Makros signieren

Makros können mit wenig Aufwand direkt mit Office-Programmen signiert werden. Nachfolgend wird ein Beispiel an Word gezeigt.

Um neue Makros zu signieren, muss bereits ein Signing-Zertifikat im Windows Certificate Manager für den entsprechenden Bearbeiter vorliegen. Im Makro-Editor von Word kann nun über das Menü «Tools -> Digital Signature» ein Zertifikat zur Signatur ausgewählt werden. Beim nächsten Speichern wird das Makro mit dem angegebenen Zertifikat signiert. Sollte der Private Key des Zertifikats mittels PIN oder Smartcard geschützt sein, wird der Benutzer dazu aufgefordert, die PIN einzugeben bzw. die Smartcard einzustecken.

Werden die Makros später vom gleichen Benutzer verändert, wiederholt sich der Vorgang beim Speichern automatisch. Sollte jedoch ein anderer Benutzer die Makros verändern, muss er ein Zertifikat angeben, das in seinem Besitz ist. Das Makro wird dann mit dem neuen Zertifikat signiert.

Makros müssen nur dann neu signiert werden, wenn unmittelbar ihr Code verändert wurde. Wenn im Unternehmen z. B. Word-Vorlagen Makros enthalten, werden bereits signierte Makros auch nach Bearbeiten des Textinhaltes beibehalten und ausgeführt.

PowerShell-Skripte signieren

PowerShell-Skripte werden am einfachsten mit PowerShell selbst signiert. Dazu muss ebenfalls ein Signing-Zertifikat im Certificate Manager für den entsprechenden Benutzer vorhanden sein.

Mit folgenden Befehlen kann man ein Skript signieren:

# Zertifikat auswählen:
$cert = Get-ChildItem -Path Cert:\CurrentUser\My\ -CodeSigningCert | Out-GridView -Title "Zertifikat auswählen" -OutputMode Single

# Mittels ausgewähltem Zertifikat signieren:
Set-AuthenticodeSignature -Certificate $cert -FilePath \SKRIPT.ps1 -TimestampServer "https://timestamp.digicert.com"

Mit der ersten Befehlszeile wird ein Zertifikat zum Signieren ausgewählt und in der Variable «$cert» festgehalten. Im zweiten Schritt wird mit dem Befehl «Set-AuthenticodeSignature» ein Skript signiert.

Dabei wird – optional – ein Zeitserver angegeben. Dies bewirkt, dass neben der Signatur auch der exakte Zeitpunkt der Signaturerstellung erfasst wird. Sollte ein Zertifikat nach Ende der Laufzeit ablaufen, würde PowerShell das signierte Skript nicht mehr ausführen, da das Zertifikat der Signatur nicht mehr gültig ist. Mittels Zeitstempel kann PowerShell jedoch überprüfen, ob das Zertifikat zum Zeitpunkt der Signatur gültig war, und führt das Skript weiterhin aus. Dies ist vor allem dort wichtig, wo Skripte wenig bis nie verändert und automatisch ausgeführt werden. Weiter sollte beim Verwenden von Zeitstempeln beachtet werden: Wenn einem Zertifikat nicht mehr vertraut werden kann und es revoziert (zurückgezogen) wird, muss die Revozierung rückdatiert werden bis zu einem Zeitpunkt, an welchem dem Zertifikat noch vertraut wurde. Bösartige Skripte, signiert mit dem inzwischen revozierten Zertifikat, würden sonst weiterhin ausgeführt werden, sofern sie vor der Revozierung signiert wurden.

Fazit

Office-Makros und PowerShell-Skripte per Policy im Unternehmen einzuschränken, damit nur signierter Code zur Ausführung kommt, ist nicht schwierig.

Trotzdem wird dadurch die Sicherheit im Unternehmen gesteigert, da die meisten bösartigen Makroviren keine Signatur besitzen. Auch bei PowerShell können einige Angriffe verhindert und das Ausführen unerwünschter Skripte, zumindest von unerfahrenen Benutzern, unterbunden werden.

Bedauerlich ist die fehlende Möglichkeit zur Einschränkung von vertrauenswürdigen CAs, um z. B. nur Zertifikate der internen CA zum Signieren zuzulassen, sowie die fehlende Umsetzung der Gruppenrichtlinien bei günstigeren Microsoft-365- und Office-Angeboten.

Falls Sie Unterstützung brauchen oder noch offene Fragen sind, freuen wir uns auf Ihre Kontaktaufnahme:

Über den Autor

Marco Wohler ist seit November 2014 für den reibungslosen Betrieb der unternehmensinternen IT-Infrastruktur der Oneconsult verantwortlich. Er leitet seit Oktober 2016 das IT-Team. In dieser Funktion konzipierte und implementierte Marco Wohler mit seinem Team die verschiedenen Generationen der IT-Infrastruktur. In Kundenprojekten und intern sammelte er umfassende Erfahrungen in der Verteidigung von Systemen und Unternehmen. Als Gegenpol zu den Penetration Testing Teams, die sich auf Angriffsszenarien ausrichten, ist Marco Wohler ein gefragter Spezialist für die Absicherung von IT-Systemen. Er ist GIAC Certified Enterprise Defender (GCED) und zertifizierter OSSTMM Professional Security Tester (OPST).

Über Oneconsult

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

Erhalten Sie kompetente Beratung vom inhabergeführten und herstellerunabhängigen Cybersecurity-Spezialisten mit 40+ hochqualifizierten Cybersecurity Experten, darunter zertifizierte Ethical Hacker / Penetration Tester (OPST, OPSA, OSCP, OSCE, GXPN), IT-Forensiker (GCFA, GCFE, GREM, GNFA), ISO Security Auditoren (ISO 27001 Lead Auditor, ISO 27005 Risk Manager, ISO 27035 Incident 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 Digital Forensics & Incident Response (DFIR) Expertenteams von Oneconsult zählen.

www.oneconsult.com