Reglas de reducción de la superficie de ataque para las aplicaciones de productividad de Microsoft

El aumento del trabajo remoto, junto con un mayor uso de múltiples dispositivos de empleados, está creando una superficie de ataque empresarial en constante expansión. El uso de la reducción de la superficie de ataque, o ASR, puede ayudar a las organizaciones a evitar que los actores maliciosos exploten las vulnerabilidades y debilidades que crean estas dos variables.

Hay una variedad de productos y plataformas disponibles para ayudar a reducir la superficie de ataque. Las organizaciones que buscan proteger y administrar puntos finales específicamente pueden considerar Microsoft Defender para puntos finales. Para ayudar a los profesionales de la seguridad a comprender esta plataforma de Microsoft y sus características, los autores Paul Huijbregts, Joe Anich y Justen Graves escribieron Microsoft Defender for Endpoint in Depth.

El libro se sumerge específicamente en cómo abordar ASR en aplicaciones de productividad comunes, incluidos Microsoft Office y Outlook. En el siguiente extracto del Capítulo 3, los autores explican cómo usar Microsoft Defender para las reglas de ASR de Endpoint para impedir que dichas aplicaciones de productividad realicen acciones específicas, como la creación de contenido ejecutable o procesos secundarios.

Descargue un PDF del Capítulo 3 para obtener más información. Además, asegúrese de leer nuestra entrevista con Huijbregts, Anich y Graves, donde analizan el uso de Microsoft Defender para Endpoint para la administración de la postura de seguridad.

Estas reglas se utilizan para bloquear comportamientos o ataques que intentan explotar las aplicaciones de productividad:

En los ataques que involucran la explotación de vulnerabilidades en los procesos de Office o el abuso de las características y funcionalidades de las aplicaciones de Office, una de las etapas sucesivas comunes es colocar y ejecutar un archivo malicioso en el dispositivo afectado. Aquí es donde el atacante logra entrometerse con éxito en el dispositivo y puede realizar cualquier cantidad de actividades maliciosas a partir de este punto.

Esta regla evita que las aplicaciones de Office, Word, Excel, PowerPoint y OneNote suelten el contenido ejecutable en el disco. Al hacerlo, la regla tiene como objetivo bloquear los ataques en una etapa crucial en la que los atacantes buscan obtener acceso y afianzarse en las máquinas.

En el caso de los archivos ejecutables de Windows, es decir, los archivos Portable Executable (PE), la regla solo bloquea la escritura en el disco de los archivos que no son de confianza y no están firmados. Esto evita que se bloqueen algunos de los casos de uso previstos. Sin embargo, los archivos de script se bloquean por completo sin validar el estado de confianza o amistad.

Algunas aplicaciones populares ya se han excluido de la regla mediante exclusiones de back-end o exclusiones globales. Sin embargo, para protegerlo de ataques que puedan abusar de estas exclusiones, Microsoft se ha abstenido intencionalmente de publicar una lista de las aplicaciones/procesos excluidos. A pesar de implementar exclusiones globales, es posible que aún deba implementar exclusiones locales para aplicaciones LOB internas propias o de terceros bloqueadas por la regla.

Como se mencionó anteriormente, los atacantes que usan aplicaciones de Office (es decir, Word, Excel, PowerPoint, OneNote y Access) como vector de punto de entrada a menudo intentan descargar y ejecutar archivos maliciosos en el dispositivo afectado o en los procesos de Office. se utilizan para ejecutar procesos del sistema o herramientas de administración o procesos benignos de terceros para profundizar o ampliar la infección, por ejemplo, iniciar el símbolo del sistema o PowerShell para desactivar un control de seguridad importante o realizar algunos cambios en el registro.

Como tal, esta regla proporciona otro control importante: bloquea todas las aplicaciones de Office para que no inicien ningún proceso secundario. No se permite la ejecución de archivos confiables, archivos amigables, archivos de sistema, herramientas de administración o aplicaciones benignas de terceros.

Inyectar código en procesos limpios legítimos (en su mayoría, procesos firmados) es una técnica de evasión de detección muy conocida. Los procesos de oficina no han sido inmunes a esta técnica. Sin embargo, los investigadores de Microsoft entienden que no hay una buena razón para que los procesos de Office inyecten código en otros procesos en ejecución. Esta regla impide que los procesos relacionados con las aplicaciones de Word, Excel y PowerPoint Office realicen actividades de inyección de código.

Al igual que con el resto de las reglas de la aplicación de productividad, esta regla también admite exclusiones de ASR.

La macro Office VBA es una característica extremadamente popular entre los usuarios de Office. Sin embargo, aunque Office admite llamar a las API de Win32 desde el interior del código de macro de VBA, la mayoría de las organizaciones no utilizan la funcionalidad con tanta frecuencia. Por otro lado, los atacantes pueden usarlo para realizar una gran cantidad de actividades maliciosas, incluida la ejecución sin archivos del código de shell malicioso, lo que hace que sea extremadamente difícil de detectar. Esta regla bloquea la ejecución de código de macro que contiene llamadas a la API de Win32.

La regla admite exclusiones. Como tal, las organizaciones que necesitan macros para realizar llamadas a la API de Win32 pueden excluir archivos específicos de Office y continuar bloqueando el resto.

Al igual que con las aplicaciones de Office, los atacantes también pueden usar varias técnicas para realizar ataques utilizando los procesos de Adobe Reader. En tales ataques, el proceso de Adobe Reader a menudo lanza cargas útiles o herramientas de administración adicionales. Esta regla bloquea tales ataques al impedir que Adobe Reader inicie procesos secundarios.

Al igual que con las reglas de Office, algunas aplicaciones populares ya se han excluido de la regla mediante exclusiones globales. Como siempre, también puede implementar exclusiones en el cliente.

Estas dos reglas están enfocadas a que los clientes de correo creen y lancen contenido ejecutable, algo muy popular entre los documentos maliciosos enviados en campañas de phishing o spearphishing:

La ofuscación de scripts (por ejemplo, que contengan código JavaScript/VBScript/PowerShell (PS)/macro) es una práctica habitual entre los autores de scripts. Proporciona una forma de ocultar los contenidos para proteger la información de propiedad, ya que a veces puede incluir propiedad intelectual. Sin embargo, los autores de malware abusan de esta capacidad para dificultar la lectura, el análisis y la detección de sus scripts maliciosos.

Esta regla busca propiedades que sean indicativas de ofuscación y utiliza modelos de aprendizaje automático (ML) además de las propiedades identificadas para clasificar y bloquear sucesivamente los scripts.

Dado que la regla utiliza modelos ML, siempre hay un cierto grado de FP asociado con esta regla. Para mitigar el impacto adverso de dichos FP, como las reglas de aplicaciones de productividad, esta regla también admite exclusiones.

Descargar scripts o binarios maliciosos y usarlos para realizar actividades maliciosas durante las etapas de un ataque es una práctica bastante extendida. Como sugiere el nombre, el objetivo de esta regla es bloquear los scripts de JavaScript y VBScript para que no lancen contenido malicioso descargado. Una vez habilitada, la regla bloquea la ejecución de dichos scripts en el dispositivo protegido.

Sin embargo, varios escenarios reales necesitan scripts para poder descargar y ejecutar contenido alojado. Como tal, la regla también admite exclusiones de ASR.

Estas reglas están destinadas a reducir la posibilidad de que se abuse de las aplicaciones de comunicación como vector de ataque inicial:

En los ataques que involucran el correo electrónico como vector, a menudo se ve que algún tipo de archivo ejecutable malicioso se envía al dispositivo afectado en forma de archivo adjunto de correo electrónico. Por lo tanto, esta regla se creó para bloquear todos los archivos ejecutables (como .exe, .dll y .scr), así como los archivos de script populares (como .ps1, .vbs y .js) enviados por correo electrónico. Cuando se abren dichos correos electrónicos y se accede al archivo ejecutable o script, la regla inspecciona y bloquea los archivos en cuestión.

La regla funciona para la aplicación cliente de Outlook, así como para Outlook.com y otros proveedores de correo web populares.

En general, la mayoría de las organizaciones no aprueban compartir archivos ejecutables o scripts por correo electrónico. Sin embargo, siempre hay un bolsillo de usuarios o dispositivos en los que se observa la actividad y, sucesivamente, se permite o simplemente se ignora. Nunca se recomienda permitir dicho intercambio por correo electrónico; sin embargo, en caso de que necesite permitir esto, al menos para un pequeño conjunto de dispositivos, esta regla también admite exclusiones de ASR.

Como se mencionó anteriormente, el correo electrónico se ha utilizado como vector de punto de entrada durante mucho tiempo. El bloqueo de los archivos ejecutables entregados mediante el correo electrónico es solo un escenario. Otros escenarios populares incluyen la explotación de vulnerabilidades o el abuso de lagunas en la aplicación de Outlook. En tales casos, la cadena de eliminación de ataques generalmente contiene la aplicación de Outlook que inicia algunos procesos en los dispositivos afectados. En la mayoría de los casos, se trata de herramientas de administración de las que se puede abusar para reducir la seguridad del dispositivo y descargar archivos binarios maliciosos adicionales o herramientas necesarias para el ataque.

Esta regla protege contra tales ataques al bloquear todos los procesos secundarios creados por la aplicación de Outlook.

Tenga en cuenta que, al igual que con las reglas relacionadas con Office de la sección de reglas de la aplicación Productividad, algunas aplicaciones populares ya se han excluido de la regla mediante exclusiones globales. La regla también admite exclusiones de ASR. Los usuarios siempre pueden excluir aplicaciones internas o LOB bloqueadas por esta regla.