Was bedeutet das Windows Attachment Manager Risiko?
Das Windows Attachment Manager Risiko betrifft Richtlinien für den Umgang mit Dateien: Bei welchem Anhang erscheint eine Rückfrage oder eine Sperre, für welchen Benutzer und in welcher Anwendung? Ein GPO-Inventar kann prüfenswerte Einstellungen identifizieren. Für den Abschluss der Prüfung sind jedoch Nachweise aus dem vorgesehenen Benutzerablauf erforderlich.
Zwei Situationen verlangen unterschiedliche Entscheidungen. Enthält ein Inventar weder DefaultFileTypeRisk noch LowRiskFileTypes, stellt sich die Frage nach einer expliziten Konfiguration. Wählt eine Richtlinie ein niedriges Standardrisiko oder nimmt Skripterweiterungen in eine Liste mit niedrigem Risiko auf, geht es um eine explizite Ausnahme. Beide Fälle als Beweis dafür zu behandeln, dass jedes heruntergeladene Skript ohne Rückfrage ausgeführt wird, würde die Aussagekraft der Nachweise überschreiten.
Dieser Leitfaden verwendet die Dokumentation von Microsoft Learn und den geprüften Code von etc-collector. Die folgenden Windows-Befehle sind dokumentationsgestützte Lesebeispiele. Sie wurden für diesen Artikel nicht in einer Windows-Umgebung ausgeführt. Das Pilotverfahren ist eine vorgeschlagene Prüfmethode; weder ein erfolgreicher Test noch eine Anzahl betroffener Arbeitsstationen oder ein Angriff wird behauptet.
Funktionsweise: Standardwerte, Listen und Anwendungskontext
Microsofts Richtlinienreferenz für Attachment Manager ordnet diese Einstellungen unter Benutzerkonfiguration > Administrative Vorlagen > Windows-Komponenten > Attachment Manager ein. Die Zuordnungen für Risiken und Listen liegen unter Software\Microsoft\Windows\CurrentVersion\Policies\Associations.
Das dokumentierte Verhalten unterscheidet drei Risikoklassen:
| Einstufung | Eingeschränkte Zone | Internetzone |
|---|---|---|
| Hoch | Zugriff blockieren | Vor dem Zugriff nachfragen |
| Moderat | Vor dem Zugriff nachfragen | Vor dem Zugriff nachfragen |
| Niedrig | Keine Rückfrage | Keine Rückfrage |
Eine nicht konfigurierte oder deaktivierte Richtlinie für das Standardrisiko behält das moderate Risiko bei. Eine nicht konfigurierte Richtlinie für niedriges Risiko behält die standardmäßige Vertrauenslogik bei. Benutzerdefinierte Einträge für hohes Risiko haben Vorrang vor Einträgen für mittleres und niedriges Risiko; mittlere Einträge haben Vorrang vor niedrigen. Einträge für niedriges Risiko überschreiben die integrierte Liste für hohes Risiko, weshalb Überschneidungen zwischen benutzerdefinierten Listen relevant sind. Die standardmäßige Vertrauenslogik bevorzugt den Dateihandler; die separate Richtlinie für die Vertrauenslogik kann diese Bewertung ändern. Microsoft-Richtliniendefinitionen
Auch der Anwendungskontext gehört zum Mechanismus. Microsofts Referenz zu IAttachmentExecute beschreibt eine Schnittstelle für Clientanwendungen mit Richtlinienprüfungen, Rückfragen sowie Speicher- und Ausführungsvorgängen. SetSource liefert Herkunftsinformationen und SetReferrer den Zonenkontext; der Client besitzt außerdem eigene Einstellungen für Anhänge. Daraus folgt nicht, dass jede Anwendung die Schnittstelle identisch verwendet.
Identifizieren Sie für die Prüfung die Anwendung, die die Datei empfängt, die vom Benutzer ausgeführte Aktion und die zu diesem Zeitpunkt verfügbare Herkunftsinformation. Ein Befund kann diese Lücken nicht schließen. Leiten Sie aus einer Richtlinienzeichenfolge auf Domänenebene keine Aussage über einen unbekannten Browser, E-Mail-Client, eine Dateizuordnung oder einen Startpfad ab.
Erkennung: Benutzerrichtlinien erfassen und mit dem Pilotbetrieb vergleichen
Schritt 1: Die GPO-Konfiguration sichern
Erfassen Sie die relevanten GPOs vor einer Änderung. Dokumentieren Sie für jedes GPO Identität, Verknüpfungen, Benutzerbereich, Filterung, Erfassungszeitpunkt und unverarbeitete Richtlinienwerte. Prüfen Sie die Benutzerkonfiguration und die dekodierte Datei User\Registry.pol, statt anzunehmen, dass ein Bericht zu Computerrichtlinien die Einstellungen für Anhänge enthält. Bewahren Sie widersprüchliche Konfigurationen zur späteren Klärung auf.
Das Prüfarbeitsblatt sollte Folgendes enthalten:
| Element | Aufzubewahrender Nachweis | Zu klärende Frage |
|---|---|---|
DefaultFileTypeRisk | Vorhandensein, Typ und exakter Wert | Ist der beabsichtigte Standard explizit festgelegt oder dem Standardverhalten überlassen? |
LowRiskFileTypes | Exakte Zeichenfolge und Konfigurationszustand | Welche Ausnahmen haben einen Verantwortlichen und eine Anwendungsabhängigkeit? |
HighRiskFileTypes | Exakte Zeichenfolge und Konfigurationszustand | Fehlen benutzerdefinierte Einträge im ersten Vergleich? |
| Einträge für moderates Risiko und Vertrauenslogik | Konfiguration aus derselben Richtlinienprüfung | Könnte eine andere Einstellung die Interpretation ändern? |
| Zielbenutzer und Anwendung | Identität, Host, Anwendungsversion und Ablauf | Welche Benutzergruppe beschreiben diese Nachweise tatsächlich? |
Unterscheiden Sie fehlende, leere und nicht erfasste Werte sowie fehlgeschlagene Lesevorgänge. Insbesondere bewahrt der Parser der beiden EtcSec-Prüfungen eine leere Zeichenfolge in LowRiskFileTypes nicht auf. Ein fehlendes geparstes Feld reicht daher nicht aus, um den ursprünglichen Richtlinienzustand zu rekonstruieren.
Unsere vier Prüfungen für Active Directory GPO-Sicherheitseinstellungen erläutern dieselbe Vorgehensweise für andere Einstellungen: Konfiguration sichern, den empfangenden Geltungsbereich identifizieren und Clientnachweise prüfen. Ihre Kontrollen für LLMNR, WSUS, LSASS und UNC liefern eine hilfreiche Prüfmethode; diese Untersuchung betrifft dagegen den Umgang mit Benutzeranhängen.
Schritt 2: Das Richtlinienergebnis des Zielbenutzers abrufen
Verwenden Sie auf dem Pilotcomputer die Sitzung des vorgesehenen Benutzers und rufen Sie die Zusammenfassung für den Benutzerbereich ab:
gpresult /scope user /r
Führen Sie für eine detailliertere Aufzeichnung diesen Befehl separat aus:
gpresult /scope user /z
Microsofts gpresult-Referenz dokumentiert den Benutzerbereich, die zusammengefasste Ausgabe und die detaillierte Richtlinienausgabe. Klären Sie Abweichungen zwischen dem GPO-Inventar und dem gemeldeten Ergebnis, bevor Sie lokale Werte interpretieren. Bewahren Sie Fehler als Fehler auf; ein nicht verfügbarer Bericht ersetzt keinen Nachweis dafür, dass das vorgesehene GPO angewendet wurde.
Schritt 3: Die Registrierungswerte des Benutzers lesen
Führen Sie jeden Befehl separat im Kontext des vorgesehenen Benutzers aus. Diese Beispiele verbinden Microsofts dokumentierte Syntax für reg query mit dem oben genannten Associations-Schlüssel:
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Associations" /v DefaultFileTypeRisk
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Associations" /v LowRiskFileTypes
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Associations" /v HighRiskFileTypes
HKCU bezeichnet die Registrierungsstruktur des aktuellen Benutzers. Eine Abfrage als anderer Administrator ändert den Gegenstand der Beobachtung. Bewahren Sie Befehl, Konto, Host, Zeitpunkt, Werttyp und Ausgabe auf; unterscheiden Sie einen fehlenden Wert von einem fehlgeschlagenen Befehl. Vergleichen Sie diese Leseergebnisse mit dem zuständigen GPO und dem Richtlinienergebnis, statt eine fehlende Ausgabe durch einen angenommenen sicheren oder unsicheren Wert zu ersetzen.
Schritt 4: Konfiguration und beobachteten Umgang vergleichen
Definieren Sie einen autorisierten Pilotbetrieb mit harmlosen repräsentativen Dateien und den Anwendungsverantwortlichen. Dokumentieren Sie Erweiterung, Herkunft, verfügbare Zoneninformationen, empfangende Anwendung, ausgewählte Aktion und ob der Zugriff blockiert, nach einer Rückfrage oder ohne Rückfrage erlaubt wurde. Bewahren Sie unerwartete Ergebnisse für die Untersuchung auf; tragen Sie eine erwartete Rückfrage nicht als tatsächliche Beobachtung ein.
Verwenden Sie eine Matrix mit einer Zeile pro geprüftem Ablauf. Nehmen Sie einen Verweis auf die Konfiguration vor und nach der Änderung sowie das tatsächliche Ergebnis auf. Ein Ergebnis aus einer bestimmten Aktion eines E-Mail-Clients stützt genau diese Beobachtung; es belegt nicht jeden lokalen Startpfad oder jede Benutzergruppe. Diese Quellen definieren keine universelle Windows-Ereignis-ID für diese Konfigurationsprüfung.
Behebung: Ausnahmen vor Änderungen an Rückfragen prüfen (Remediation)
Schritt 1: Verantwortlichkeit für die Konfiguration zuweisen
Identifizieren Sie den Administrator der wirksamen Benutzerrichtlinie und die Verantwortlichen der Anwendungen, die Ausnahmen benötigen. Prüfen Sie den unverarbeiteten Standardwert und alle relevanten Aufnahmelisten gemeinsam. Bewahren Sie den ursprünglichen Export auf, damit sich die Entscheidung auf eine reale Konfiguration statt auf eine verkürzte Befundbeschreibung zurückführen lässt.
Ordnen Sie den Fall als fehlende explizite Konfiguration, explizite Abschwächung, widersprüchliche Richtlinie oder unvollständige Nachweise ein. Wenden Sie nicht dieselbe Korrektur auf alle vier Fälle an. Eine fehlende Einstellung erfordert eine Entscheidung zum beabsichtigten Verhalten; eine vorhandene Ausnahme benötigt eine Begründung und Kompatibilitätsprüfung; ein Erfassungsfehler erfordert eine erfolgreiche Messung.
Schritt 2: Unbegründete Abschwächungen in einer Pilotrichtlinie entfernen
Prüfen Sie für einen per GPO verwalteten Pilotbetrieb Standardrisikostufe für Dateianlagen und die Aufnahmeeinstellungen im oben genannten Attachment Manager-Pfad. Prüfen Sie DefaultFileTypeRisk = 6152, den vom Detektor für Abschwächungen getesteten Wert, sowie jeden Skripteintrag in LowRiskFileTypes. Entfernen Sie unbegründete Ausnahmen über die zuständige Richtlinie und dokumentieren Sie jede beibehaltene Abhängigkeit.
Wählen Sie den beabsichtigten Standard und die Listen nach Prüfung der Anforderungen an Anwendung und Herkunft. Ersetzen Sie eine anwendungsspezifische Kompatibilitätsentscheidung nicht durch einen pauschalen niedrigen Standard. Prüfen Sie benutzerdefinierte Einträge für hohes und moderates Risiko gemeinsam mit niedrigen Einträgen, bevor Sie das Ergebnis vorhersagen. Eine Skriptteilzeichenfolge in der erfassten Zeichenfolge für niedriges Risiko ist ein Prüfanlass, keine vollständige Windows-Risikobewertung.
Schritt 3: Benutzernachweise erneut erfassen und den Ablauf testen
Wiederholen Sie nach Anwendung der Richtlinie die gpresult-Abfrage für den Benutzerbereich und die Registrierungsabfragen mit derselben Pilotidentität. Führen Sie die vereinbarten harmlosen Abläufe erneut aus und dokumentieren Sie mit den Anwendungsverantwortlichen die tatsächlichen Ergebnisse. Wenn sich die Konfiguration geändert hat, das beobachtete Verhalten aber nicht den Erwartungen entspricht, untersuchen Sie Anwendungspfad, Herkunft und Richtlinienkonflikte, bevor Sie die Bereitstellung ausweiten.
Schritt 4: Ergänzende Ausführungskontrollen beibehalten
Eine Richtlinie für Anhangrisiken allein kann keine umfassende Skriptkontrolle belegen. Unser Leitfaden zu Defender ASR-Regeln per GPO behandelt ergänzende Verhaltensregeln, deren Regelkennungen, Aktionen und Ausnahmen am Endpunkt separat geprüft werden. Eine erfolgreiche Prüfung der Anhangrichtlinie validiert weder ASR noch AppLocker.
Schließen Sie die Behebung im definierten Umfang nur ab, wenn Richtlinienentscheidung, resultierende Benutzerkonfiguration, geprüftes Anwendungsverhalten und Verantwortlichkeit für Ausnahmen beigefügt sind. Behandeln Sie eine breitere Bereitstellungsabdeckung als separate Nachweisfrage. Eine abgeschlossene GPO-Änderung oder eine geänderte Anzahl im Collector belegt keinen flottenweiten Schutz.
Wie EtcSec dies erkennt
Die beiden geprüften Implementierungen von etc-collector sind GPO-Prüfungen mit Schweregrad Medium. Sie untersuchen erfasste Registrierungsfelder mit diesen exakten Bedingungen:
| Katalogkennung | Implementierte Bedingung | Bedeutung von Count |
|---|---|---|
FOLDER_OPTIONS_SCRIPT_NOT_HARDENED | Die ausgewählten Werte von DefaultFileTypeRisk und LowRiskFileTypes sind beide nil | 1 für diese Abwesenheitsbedingung; andernfalls 0 |
GPO_FOLDER_OPTIONS_SCRIPT_EXEC | Das ausgewählte Standardrisiko ist 6152, oder die in Kleinbuchstaben umgewandelte Zeichenfolge für niedriges Risiko enthält eine geprüfte Skriptteilzeichenfolge | Anzahl der Gründe, nicht der GPOs, Dateien oder Arbeitsstationen |
Bei der zweiten Prüfung werden die Teilzeichenfolgen .hta, .js, .vbs, .wsf, .wsh und .ps1 getestet. Der Code fügt einen Grund für das Standardrisiko 6152 und einen gemeinsamen Grund hinzu, wenn irgendeine dieser Teilzeichenfolgen vorkommt. Mehrere übereinstimmende Erweiterungen tragen weiterhin nur einen Listengrund bei. Es handelt sich um Teilzeichenfolgensuche, nicht um striktes Parsen einer Erweiterungsliste; beispielsweise kann ein längeres Token, das .js enthält, einen Treffer erzeugen.
Jedes Feld wird unabhängig ausgewählt. Die Detektoren durchsuchen zuerst die Registrierungseinstellungen von Machine und ziehen User nur heran, wenn das Machine-Ergebnis für dieses Feld nil ist. Die Machine-Hilfsfunktion priorisiert Default Domain Controllers Policy, dann Default Domain Policy und danach ein anderes verfügbares GPO. Die User-Hilfsfunktion liefert den ersten nicht-nil-Wert aus einer Go-Map. Diese Map-Traversierung bildet keine stabile Windows-Richtlinienrangfolge ab.
Der Registrierungsparser ordnet einen gültigen DWORD-Wert namens defaultfiletyperisk unter einem Schlüssel zu, der associations enthält. Er ordnet lowriskfiletypes nur zu, wenn die geparste Zeichenfolge nicht leer ist. Die geprüften Kontrollen bewerten weder Aufnahmelisten für hohes oder moderates Risiko noch die Vertrauenslogik des Clients oder das Anwendungsverhalten. Da beide Felder separat ausgewählt werden, können ihre Werte außerdem aus verschiedenen GPOs stammen.
Jeder nicht-nil-Wert in einem der ausgewählten Felder unterdrückt den Abwesenheitszähler, ohne seine Sicherheit zu validieren. Ebenso belegt ein Abschwächungszähler von null weder eine vollständige Erfassung noch eine korrekte Richtlinienanwendung oder einen sicheren Umgang mit Anhängen. Keine der Prüfungen misst eine universelle Ausführung ohne Warnungen, validiert AppLocker oder ASR oder belegt die Sicherheit der Flotte. Keiner der Befunde belegt einen Angriff.
Verwenden Sie den Befund, um die oben beschriebene Prüfung im definierten Umfang einzuleiten. Halten Sie Richtlinieninventar, Nachweise zum Benutzerergebnis und die tatsächlichen Pilotbeobachtungen zusammen, damit der Redakteur oder Administrator ein Konfigurationssignal von einem nachgewiesenen Verhalten unterscheiden kann.
Entdecken Sie die Identity-Security-Seiten zu diesem Thema
