Riesgo de Windows Attachment Manager: verificar directivas de usuario

¿Qué es el riesgo de Windows Attachment Manager?

El riesgo de Windows Attachment Manager plantea una cuestión de directiva de tratamiento de archivos: ¿qué archivo adjunto provoca una advertencia o un bloqueo, para qué usuario y en qué aplicación? Un inventario de GPO puede identificar ajustes que conviene revisar, pero cerrar la revisión exige pruebas del flujo de trabajo del usuario previsto.

Dos situaciones requieren decisiones distintas. Un inventario que no contiene ni DefaultFileTypeRisk ni LowRiskFileTypes plantea una pregunta sobre la configuración explícita. Una directiva que selecciona un riesgo predeterminado bajo o añade extensiones de script a una lista de bajo riesgo plantea una pregunta sobre una excepción explícita. Tratar ambos casos como prueba de que todos los scripts descargados se ejecutan sin advertencias exageraría lo que demuestran las pruebas.

Esta guía utiliza documentación de Microsoft Learn y el código de etc-collector revisado. Los comandos de Windows que aparecen a continuación son ejemplos de lectura basados en la documentación, no comandos ejecutados en un entorno Windows para este artículo. El procedimiento piloto es un método de verificación propuesto; no se afirma que haya habido una prueba satisfactoria, un número de estaciones afectadas ni un ataque.

Funcionamiento: valores predeterminados, listas y contexto de aplicación

La referencia de directivas de Attachment Manager de Microsoft sitúa estos ajustes en Configuración de usuario > Plantillas administrativas > Componentes de Windows > Attachment Manager, con las correspondencias de riesgo y listas en Software\Microsoft\Windows\CurrentVersion\Policies\Associations.

El comportamiento documentado distingue tres clases de riesgo:

Una directiva de riesgo predeterminado no configurada o deshabilitada conserva un riesgo moderado. Una directiva de bajo riesgo no configurada conserva la lógica de confianza predeterminada. La inclusión personalizada de alto riesgo tiene prioridad sobre las inclusiones de riesgo medio y bajo; la de riesgo medio precede a la de riesgo bajo. La inclusión de bajo riesgo prevalece sobre la lista integrada de alto riesgo, por lo que los solapamientos de listas personalizadas importan. La lógica de confianza predeterminada da preferencia al controlador; la directiva independiente de lógica de confianza puede cambiar esa evaluación. Definiciones de directivas de Microsoft

El contexto de aplicación también forma parte del mecanismo. La referencia de IAttachmentExecute de Microsoft describe una interfaz utilizada por aplicaciones cliente, que incluye comprobaciones de directivas, advertencias y operaciones de guardado y ejecución. SetSource proporciona información de origen y SetReferrer el contexto de zona; el cliente también tiene sus propios ajustes de archivos adjuntos. Esto no demuestra que todas las aplicaciones utilicen la interfaz de forma idéntica.

En una revisión, identifique la aplicación que recibe el archivo, la acción que realiza el usuario y la información de procedencia disponible en ese momento. Un hallazgo no puede cubrir esas lagunas. No pase de una cadena de directiva a nivel de dominio a una afirmación sobre un navegador, cliente de correo, asociación de archivos o ruta de lanzamiento desconocidos.

Detección: inventariar las directivas de usuario y comparar el piloto

Paso 1: conservar la configuración de las GPO

Inventaríe las GPO pertinentes antes de editarlas. Registre la identidad de cada GPO, sus vínculos, ámbito de usuario, filtrado, hora de recopilación y valores de directiva sin procesar. Examine Configuración de usuario y el archivo User\Registry.pol decodificado, en lugar de suponer que un informe de directivas de equipo contiene los ajustes de archivos adjuntos. Conserve las configuraciones contradictorias para conciliarlas.

La hoja de revisión debe incluir:

Distinga entre valores ausentes, vacíos, no recopilados y lecturas fallidas. En particular, el analizador utilizado por las dos comprobaciones de EtcSec no conserva una cadena LowRiskFileTypes vacía. Por tanto, la ausencia de un campo analizado no basta para reconstruir el estado original de la directiva.

Nuestras cuatro comprobaciones de seguridad GPO de Active Directory explican la misma disciplina para otros ajustes: conservar la configuración, identificar el ámbito receptor y verificar las pruebas del cliente. Sus controles LLMNR, WSUS, LSASS y UNC ofrecen un método de revisión útil, mientras que esta investigación trata del manejo de archivos adjuntos de usuario.

Paso 2: obtener el resultado de directivas del usuario de destino

En el equipo piloto, utilice la sesión del usuario previsto y obtenga el resumen del ámbito de usuario:

gpresult /scope user /r

Para un registro más detallado, ejecute por separado:

gpresult /scope user /z

La referencia de gpresult de Microsoft documenta el ámbito de usuario, la salida resumida y la salida detallada de directivas. Resuelva las discrepancias entre el inventario de GPO y el resultado informado antes de interpretar los valores locales. Conserve los errores como errores; un informe no disponible no puede sustituir a la prueba de que se aplicó la GPO prevista.

Paso 3: leer los valores del registro de usuario

Ejecute cada comando por separado en el contexto del usuario previsto. Estos ejemplos combinan la sintaxis de reg query documentada por Microsoft con la clave Associations indicada anteriormente:

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 identifica el subárbol del usuario actual. Ejecutar la consulta como un administrador distinto cambia el sujeto de la observación. Conserve el comando, la cuenta, el host, la hora, el tipo de valor y la salida; distinga un valor ausente de un fallo del comando. Compare esas lecturas con la GPO responsable y el resultado de directivas, en lugar de sustituir una salida ausente por un valor supuesto seguro o inseguro.

Paso 4: comparar la configuración con el tratamiento observado

Defina un piloto autorizado con archivos representativos inocuos y los responsables de las aplicaciones. Registre la extensión, la procedencia, la información de zona cuando esté disponible, la aplicación receptora, la acción seleccionada y si el acceso se bloqueó, generó una advertencia o se permitió. Conserve los resultados inesperados para investigarlos; no inserte una advertencia esperada en el registro como si se hubiera observado.

Utilice una matriz con una fila por flujo probado. Incluya una referencia de configuración antes/después y el resultado real. Un resultado obtenido mediante una acción de un cliente de correo respalda esa observación específica; no demuestra todas las rutas de lanzamiento locales ni todas las poblaciones de usuarios. Estas fuentes no establecen un Windows Event ID universal para esta revisión de configuración.

Corrección: revisar las excepciones antes de cambiar las advertencias (Remediation)

Paso 1: asignar la responsabilidad de la configuración

Identifique al administrador responsable de la directiva de usuario que prevalece y a los responsables de las aplicaciones que requieren excepciones. Reúna el valor predeterminado sin procesar y todas las listas de inclusión pertinentes en una misma revisión. Conserve la exportación inicial para que la decisión pueda vincularse a una configuración real, en lugar de a una descripción abreviada del hallazgo.

Clasifique el caso como ausencia de configuración explícita, debilitamiento explícito, conflicto de directivas o pruebas incompletas. No aplique la misma acción correctiva a los cuatro casos. Un ajuste ausente requiere decidir el comportamiento previsto; una excepción existente necesita justificación y revisión de compatibilidad; un fallo de recopilación necesita una medición satisfactoria.

Paso 2: eliminar el debilitamiento injustificado en una directiva piloto

Para un piloto gestionado por GPO, revise Nivel de riesgo predeterminado para archivos adjuntos y los ajustes de inclusión en la ruta de Attachment Manager indicada anteriormente. Revise DefaultFileTypeRisk = 6152, el valor que comprueba el detector de debilitamiento, y cada entrada de script en LowRiskFileTypes. Elimine las excepciones injustificadas mediante la directiva responsable y documente cualquier dependencia conservada.

Elija el valor predeterminado y las listas previstos después de revisar los requisitos de aplicación y procedencia. Evite sustituir una decisión de compatibilidad específica de una aplicación por un valor predeterminado bajo generalizado. Compruebe las inclusiones personalizadas de riesgo alto y moderado junto con las entradas de bajo riesgo antes de predecir el resultado. La presencia de una subcadena de script en la cadena de bajo riesgo recopilada es un motivo de revisión, no una evaluación completa del riesgo de Windows.

Paso 3: volver a recopilar pruebas de usuario y probar el flujo

Repita las lecturas de gpresult del ámbito de usuario y del registro después de aplicar la directiva, utilizando la misma identidad piloto. Vuelva a ejecutar los flujos inocuos acordados y registre los resultados reales con los responsables de las aplicaciones. Si la configuración cambió pero el comportamiento observado no coincidió con lo esperado, investigue la ruta de aplicación, la procedencia y el conflicto de directivas antes de ampliar el despliegue.

Paso 4: mantener controles de ejecución complementarios

La directiva de riesgo de archivos adjuntos por sí sola no puede demostrar un control integral de scripts. Nuestra guía de reglas ASR de Defender mediante GPO cubre reglas de comportamiento complementarias, con identificadores de reglas, acciones y exclusiones del dispositivo verificados por separado. Una revisión satisfactoria de la directiva de archivos adjuntos no valida ASR ni AppLocker.

Cierre la corrección del ámbito definido únicamente con la decisión de directiva, la configuración de usuario resultante, el comportamiento de aplicación revisado y la responsabilidad de las excepciones adjuntos. Trate la cobertura de un despliegue más amplio como una cuestión de pruebas independiente. Una edición de GPO finalizada o un cambio en el contador del recopilador no demuestra protección de toda la flota.

Cómo detecta EtcSec esta configuración

Las dos implementaciones de etc-collector revisadas son comprobaciones GPO de nivel Medium. Inspeccionan los campos de registro recopilados, con estas ramas exactas:

Para la segunda comprobación, las subcadenas probadas son .hta, .js, .vbs, .wsf, .wsh y .ps1. El código añade un motivo por el riesgo predeterminado 6152 y un único motivo combinado cuando aparece cualquiera de esas subcadenas. Varias extensiones coincidentes siguen aportando un solo motivo de lista. Se trata de coincidencia de subcadenas, no de análisis estricto de listas de extensiones; un token más largo que contenga .js, por ejemplo, puede coincidir.

Cada campo se selecciona de forma independiente. Los detectores buscan primero en los ajustes de registro Machine y solo consultan los ajustes User si el resultado Machine de ese campo es nil. El helper Machine da prioridad a Default Domain Controllers Policy, después a Default Domain Policy y después a otra GPO disponible. El helper User devuelve el primer valor non-nil encontrado en un mapa Go. Ese recorrido del mapa no proporciona una precedencia estable de directivas de Windows.

El analizador del registro asigna un DWORD válido llamado defaultfiletyperisk bajo una clave que contiene associations; asigna lowriskfiletypes solo cuando la cadena analizada no está vacía. Las comprobaciones revisadas no evalúan las listas de inclusión de riesgo alto o moderado, la lógica de confianza del cliente ni el comportamiento de aplicación. Como los dos campos se seleccionan por separado, sus valores también pueden proceder de GPO distintas.

Cualquier valor non-nil en uno de los campos seleccionados suprime el contador de ausencia, sin validar su seguridad. Del mismo modo, un contador de debilitamiento de cero no demuestra una recopilación completa, la aplicación correcta de directivas ni un tratamiento seguro de archivos adjuntos. Ninguna comprobación mide la ejecución universal sin advertencias, valida AppLocker o ASR ni demuestra la seguridad de la flota. Ningún hallazgo demuestra un ataque.

Utilice el hallazgo para abrir la revisión del ámbito descrita anteriormente. Conserve juntos el inventario de directivas, las pruebas de resultados de usuario y las observaciones reales del piloto, para que el editor o administrador pueda distinguir una señal de configuración de un comportamiento demostrado.