Attack Surface Reduction Rules (ASRR) ist ein Feature von Windows, welches richtig eingesetzt, einen entscheidenden Vorteil bei der Abwehr von typischen Angriffen gegen die Windows Platform liefert!

Da ASRR nur wenig bekannt ist stelle ich in diesem Post den Mechanismus als solchen vor, beleuchte die Einstellmöglichkeiten und Verteiloptionen und erkläre, wie sich dies und in welchem Logging es sich widerspiegelt und wie damit umgegangen werden kann.

Agenda

1. Was sind Attack Surface Reduction Rules (ASRR)?
2. Wie werden ASR Regeln verteilt?
   1. MEM
   2. GPO
   3. PowerShell
3. Wie äußern sich ASRR Vorkommnisse bei den Usern?
4. Wie äußern sich ASRR Vorkommnisse in Windows Reporting?
5. Wie äußern sich ASRR Vorkommnisse in Microsoft Defender?
6. Fazit
7. Selbst Testen
8. Weiterführende Links

Was sind Attack Surface Reduction Rules (ASRR)?

Microsoft Windows ist ein über die Jahrzehnte gewachsenes Betriebssystem mit vielen Freiheiten und Möglichkeiten. Das heißt, dass es viele Möglichkeiten gibt „Dinge zu tun“, oder wie es bei Spiderman heißt „aus großer Macht folgt große Verantwortung“.

Sprich, es gibt natürlich Möglichkeiten diese Freiheiten zu missbrauchen. („Man kann mit einem Küchenmesser ein großartiges Essen zubereiten, oder spannende Horrorfilme beginnen.“)

Jetzt ist es so, dass es „typische“ Windows Features gibt, die gerne missbraucht werden, weil sie weitreichende Möglichkeiten, sowohl für ehrbare User*innen, als auch für die dunkle Seite der Macht, also die Angreifenden, bieten.

Einfachstes Beispiel – und dieses werde ich über den Blogpost durchgängig nutzen – ist die Möglichkeit per Makro aus einem Office Dokument ein Executable (z.B. „schadsoftware.exe“) zu starten.

Die ASRR Features ermöglichen eben jene gut bekannten Missbrauchsmöglichkeiten zu überwachen und einzuschränken, also in unserem Beispiel die Möglichkeit automatisiert aus einem Office Dokument eine Exe zu starten, zu protokolieren oder sogar zu unterbinden.

Diese Funktionalität ist ein Windows Feature, welches ab Windows [10|11] Enterprise zur Verfügung steht und eingeschränkt auch unter Windows Pro bzw. Business, aber ohne supportability Aussage!

Waaasss? In der Dokumentation steht doch immer „Applies to: Microsoft Defender for Endpoint“ oder so ähnlich, wieso dann plötzlich Windows 10 Pro???

Das erklärt sich damit, dass das Feature zwar ein Windows [10|11] Pro benötigt, aber die eigentliche Power der Analyse und Überwachung erst mit Microsoft Defender for Endpoint einzieht, dazu später mehr.

Wie werden ASR Regeln verteilt?

Es gibt mehrere Möglichkeiten ASR Regeln zu verteilen:

1. Microsoft Endpoint Manager (Intune, MECM)
2. Group Policy
3. PowerShell

Die einfachste Variante ist 1. Microsoft Endpoint Manager (Intune, MECM) – denn dort kann dies über einen schönen, per UI bedienbaren Workflow erfolgen, inklusive der korrekten und einfachen Zuweisungen (Assignments) auf User- oder Devicegruppen:

Abbildung 1: Screenshot von der Zusammenfassung einer ASRR in Microsoft Intune

Wenn die Entscheidung ist, dass diese Regeln über GPO oder PowerShell deployed werden, dann muss insbesondere durch eigene Mittel die korrekte Zuweisung durchgeführt und auch der IST-Verteilstatus ermittelt werden.
Außerdem ist die Konfiguration nicht trivial, da dies nicht über sprechende Namen, sondern über vorgegebene GUIDs erfolgen muss.
UND es muss gewusst werden, welche Id die jeweiligen Optionen haben, also

0. „Not configured“ oder „Disabled“ -> MERKE! Dass beide Optionen die „0“ sind mag überraschen! [Für den Client ist der Zustand egal, für die Dokumentation ggf. nicht!]

   In der GPO Beschreibung steht noch, dass NC==5 ist. In der Realität bedeutet „NC“ „wird nicht angewendet/angezeigt am Client“, d.h., dass die Konfig im Zweifel einfach nur vom Client entfernt wird.

1. „Block“
2. „Audit“

6. „Warn“ [== Block + Möglichkeit zum Override]

Deployment über GPO:

Es gibt zwei GPOs zu ASRR – und nur eine davon ist für die Config verantwortlich:
GPS: Configure Attack Surface Reduction rules (gpsearch.azurewebsites.net)

Group Policy Summary for 'Configure Attack Surface Reduction rules'
====================================================================
Policy name: Configure Attack Surface Reduction rules
Supported on: At least Windows Server, Windows 10 Version 1709
Category path: Computer Configuration\ Administrative Templates\ Windows Components\ Microsoft Defender Antivirus\ Microsoft Defender Exploit Guard\ Attack Surface Reduction\
Registry key: HKLM\Software\Policies\Microsoft\Windows Defender\Windows Defender Exploit Guard\ASR
Registry value: ExploitGuard_ASR_Rules
Admx file: WindowsDefender.admx

Abbildung 2: Screenshot der zuständigen GPO im gpedit.msc Interface

Abbildung 3: Geöffnete GPO „Configure Attack Surface Reduction rules“

Abbildung 4: Geöffnete Einstellungen für die ASR Regeln in der GPO

Deployment via Powershell

Microsoft wäre nicht Microsoft, wenn die ASRR nicht auch über PowerShell konfiguriert werden könnte. Die dafür verantwortlichen Cmdlets sind:

1. Add-MpPreference
2. Get-MpPreference
3. Remove-MpPreference
4. Set-MpPreference

Zum Beispiel könnte das „Block all Office applications from creating child processes“ so gesetzt werden:

Add-MpPreference -AttackSurfaceReductionRules_Ids d4f940ab-401b-4efc-aadc-ad5f3c50688a -AttackSurfaceReductionRules_Actions 2

Und die aktuell auf der Maschine angewendeten Regeln lassen sich so auslesen:

$a = (Get-MpPreference).AttackSurfaceReductionRules_Actions
$i = (Get-MpPreference).AttackSurfaceReductionRules_Ids
$c = 0; while($c -lt $a.count) { $i[$c] + ": "+ $a[$c++] }

Und das sieht dann z.B. so aus:

Abbildung 5: Powershell Output der lokal vorhandenen ASRR

Hinweis: Es macht einen Unterschied über welchen Weg die Settings auf die Maschine gekommen sind und ob die Session ein Admin Token hat oder nicht. Sprich, wenn ich eine nicht-admin Powershell nutze, dann sehe ich ggf. weniger/keine ASR Rules!

Wie äußern sich ASRR Vorkommnisse bei den Usern?

Je nach Einstellung passieren unterschiedliche Dinge (anhand des o.g. Beispiels „Block all Office applications from creating child processes“):

1. Wenn das Setting auf „Block“ (1) steht:

Abbildung 6: User Interface im Modus „Block“ beim Versuch ein Executable aus Word zu öffnen

und in der Windows Security:

Abbildung 7: UI in der Windows Security Ansicht

2. Wenn das Setting auf „Audit“ (2) steht:
   Dann wird die Exe natürlich „einfach“ gestartet, wird aber gelogged, siehe den Abschnitt „Wie äußern sich ASRR Vorkommnisse in Microsoft Defender?“.

6. Wenn das Setting auf „Warn“ (6) steht:

Abbildung 8: User Interface im Modus „Warn“ beim Versuch ein Executable aus Word zu öffnen, siehe die Buttons „ok“ und „unblock“

Merke: hier kann die User*in manuell eingreifen und durch den Klick auf „unblock“ beim nächsten (!!) Ausführen des Makros die gewünschte exe starten. Durch den Klick auf „ok“ wird lediglich das Toast-Fenster geschlossen.

Wie äußern sich ASRR Vorkommnisse in Windows Reporting?

Wie schon angedeutet werden die Events, die durch ASRR getriggert werden, lokal auf der Maschine in Windows Eventlogs aufgezeichnet. Das zuständige Eventlog ist
Applications and Services > Microsoft > Windows > Windows Defender > Operational.

Abbildung 9: Sicht auf den Ort für die lokalen ASRR Events

Und je nach Konfiguration der ASRR sieht das Event dann so aus:

1. Block:

Abbildung 10: Details des „Block“ Events im Eventlog

2. Audit:
   

Abbildung 11: Details des „Block“ Events im Eventlog

6. Warn:
   

Abbildung 12: Details des „Warn“ Events im Eventlog – es ist identisch zu „Block“!

Wie zu sehen ist, wird sowohl bei „Block“, als auch bei „Warn“ die Event ID 1121 [„Warning“] und bei „Audit“ die Event ID 1122 [„Information“] verwendet. Das identische Verhalten von Block und Warn erklärt sich damit, dass erstmal auch bei Warn die Ausführung unterbunden wird und alle zuständigen Mechanismen (auch das Reporting) greifen. Erst nachdem die User*in das „unblock“ ausgewählt hat, wird beim nächsten (!) Versuch das betroffene Executable gestartet ohne, dass der Block Mechanismus durchlaufen wird.

Wie äußern sich ASRR Vorkommnisse in Microsoft Defender?

Nachdem wir uns nun die lokalen Daten angeschaut haben, ist es jetzt natürlich spannend, wie sich die Aktionen in der Microsoft Defender Konsole darstellen (mindestens Windows E5/Microsoft Defender for Endpoint Plan 2 Lizensierung notwendig!):

Abbildung 13: Timeline Details im Microsoft Defender einer „betroffenen“ Maschine

Abbildung 14: Detailansicht des Events im Microsoft Defenders (1/3)

Abbildung 15: Detailansicht des Events im Microsoft Defenders (2/3)

Abbildung 16: Detailansicht des Events im Microsoft Defenders (3/3)

Bzw. im Audit Modus:

Abbildung 17: Das Audit Event hat „nur“ einen geänderten Titel und verweist auf „Audit“ anstelle von „Block“

Und im Falle des „Warn“ findet sich gleich nach dem ASR Event noch ein weiteres:

Abbildung 18: Auffälligkeit bei der Nutzung von „Warn“ und einem „Unblock“ durch eine User*in

Abbildung 19: Das „nachfolgende“ Event, wenn auf Warn ein Unblock und erneutes Starten folgt

Das heißt es gibt kein eigenes Event für „Warn“, sondern es ist die Kombination aus dem ASR „Block“ + „remotely create“ mit dem identischen Prozess, der im ASRR Event aufgeführt ist, sofern der/die User*in auf „unblock“ geklickt hat.

Wichtig: erstmal blockt ASRR die Aktion und dies wird wie beschrieben auch als „Block“ geloggt. Erst nach dem Unlock wird dann der entsprechende Befehl möglich – und das Makro/die Aktion muss durch den/die User*in erneut gestartet werden.

Fazit

Mittels des geschickten Einsatzes von ASRRs ist eine Organisation in der Lage „typische“ Angriffswege zu erschweren oder sogar zu verbauen!
Dies ist in vielen Fällen eine „eh-da“ Technologie und sollte daher unter allen Umständen verwendet werden.

Wichtig dabei ist, dass vor dem Verhindern durch Auditierung festgestellt wird, welche Konsequenzen das entsprechende Setting in der Realität des Tenants hat.

Auch wenn ich normalerweise kein Freund von „Warn – but allow override“ bin – denn wenn eine User*in auf „mach es trotzdem“ klicken kann, dann wird sie das auch! Aber zum einen ist das UI meines Erachtens „geschickt“ gewählt, denn ein „ok“ bewirkt nur, dass der Toast verschwindet, und es muss explizit auf „unblock“ geklickt werden und allein diese Hürde wird für viele ausreichend hoch sein.

Außerdem lassen sich über die gekonnte Auditierung und regelmäßige Überprüfung der ASRR Events Fehlkonfigurationen und false positives leicht aufdecken und durch Anpassung der Konfiguration beheben.

UND das Risiko ist sehr gering, denn die Konfiguration grade über MEM/Intune greift sofort und ist daher für betroffene Maschinen irrsinnig schnell wieder zu ändern.

Daher: ASRRs JETZT KONFIGURIEREN! Es kostet meist wenig/nichts und bringt immens viel!

Selber testen:

Wer die ASRRs selber testen möchte, der nehme am Besten eine nackte Windows 11 VM, füge diese in einen entsprechenden Test-Tenant hinzu, konfiguriere wie oben beschrieben die entsprechende ASRR in Intune und nutze dann folgendes Dokument zum Testen:

Weiterführende Links:

Demystifying attack surface reduction rules

Understand and use attack surface reduction (ASR) | Microsoft Docs