En el panorama actual de la ciberseguridad, la complejidad de las soluciones implementadas para la protección contra amenazas crecientes aumenta constantemente. Debido a esto, tanto los actores maliciosos, que tratan de comprometer a organizaciones y sistemas para su propio beneficio, como los operadores Red Team, cuya misión es identificar y reportar vulnerabilidades para su posterior corrección, se ven impulsados a identificar y explotar nuevas deficiencias en los sistemas, adaptando sus métodos y desarrollando nuevas TTPs que les permitan evadir las defensas existentes.
Las herramientas desarrolladas tanto por los operadores como por los atacantes hostiles están diseñadas para la evasión de soluciones de seguridad como los EDR. Esto se debe a que mantener la operación fuera del radar del Blue Team es de vital importancia. Ser detectado supondría la obtención de IOC por parte del equipo de defensa, el cual aprovecharía para desmantelar toda una operación, bloqueando direcciones IP y dominios, creando YARAs para los artefactos o implementando las últimas actualizaciones en todas sus soluciones de seguridad.
Estas acciones, además de incrementar el nivel de alerta del Blue Team, supondrían el fin o el reinicio de un ataque u operación, ya que el vector de entrada podría ser mitigado o directamente bloqueado y sería necesario volver a montar la infraestructura casi por completo. Es por ello por lo que mantener el OPSEC de una operación es de vital importancia, evitando generar alertas que puedan notificar a los defensores y de esta manera cumplir el objetivo sin llegar a ser detectado.
En este artículo se pretende comentar una técnica con un objetivo diferente al resto, ya que el enfoque que plantea no es algo visto comúnmente. A diferencia del resto de herramientas o técnicas las cuales tienen un objetivo específico que cumplir, como puede ser la ejecución de un shellcode malicioso, la creación de persistencia en un activo o el movimiento lateral en una red, esta herramienta podría categorizarse como un soporte, es decir, una herramienta que tiene como propósito asegurarse de mantener la operación fuera del radar silenciando las alertas que una solución de seguridad podría llegar a generar tras detectar actividad sospechosa. Es por esto por lo que la herramienta se categoriza como de apoyo, ya que su objetivo principal es el bloqueo del “ruido” que otras herramientas o técnicas puedan generar.
Concretamente se está hablando de EDRSilencer, una herramienta desarrollada en C que aprovechándose de la Windows Filtering Platform o WFP, la cual se presentará a continuación, bloquea la comunicación saliente de un agente de EDR hacía la central, evitando así la recopilación de telemetría del activo que se está tratando de comprometer o que ya ha sido comprometido.
El propósito del EDRSilencer, como su propio nombre indica, es silenciar las alertas generadas por un agente de EDR cuando detecta actividad maliciosa, evitando así que la notificación llegue a la central y alerte al Blue Team. Esto hace de esta herramienta el complemento perfecto a la hora de realizar acciones como el volcado de credenciales.
Un ejemplo práctico de su aplicación es la combinación con el uso de Mimikatz o procdump, herramientas comúnmente utilizadas para la extracción de credenciales que en la actualidad han perdido su efectividad debido a las mejoras implementadas en las soluciones de seguridad. Los AVs y EDRs instalados cuentan con una mayor capacidad de detección y mitigación ante acciones maliciosas.
Además, durante el volcado del proceso Local Security Authority Subsystem Service, más conocido como lsass, los activos no solo cuentan con la protección ofrecida por los AVs y EDRs, sino que también con la implementación de medidas como las Protected Process Light o PPLs que también pueden bloquear el volcado, por lo que evadir dichas soluciones no sería el único problema que resolver.
Debido a esto, a menudo, este proceso de volcado requiere de la instalación de un driver vulnerable para poder evadir estas medidas de seguridad. Este tipo de actividad, frecuentemente, es detectada como sospechosa por los agentes de EDR que envían telemetría a la central alertando así a los defensores e incrementando el riesgo de que la operación sea descubierta.
Utilizando esta herramienta como complemento, un atacante tiene la capacidad de bloquear la comunicación saliente del agente de EDR instalado en el activo que se está tratando de vulnerar, mientras, al mismo tiempo, ejecuta acciones como la evasión de las PPL mediante herramientas como PPLKiller, que requieren de la instalación de un driver vulnerable.
Como ya se ha mencionado anteriormente, la herramienta silencia el agente de EDR mediante la aplicación de filtros de Windows Filtering Platform (WFP) que es un conjunto de servicios de APIs que permiten la gestión y monitorización del tráfico de red dando la capacidad de interceptar, filtrar e inspeccionar los paquetes.
Esta plataforma es utilizada por múltiples soluciones de seguridad como, por ejemplo:
- Firewall: Utiliza WFP principalmente en el aplicado de filtros que determinan el tráfico de red que está permitido y el que es bloqueado.
- AVs y EDRs: Utilizan WFP para escanear el tráfico de red en busca de patrones maliciosos.
- VPNs: WFP se encarga del cifrado y descifrado de paquetes IPSec.
Los componentes principales de esta plataforma son los siguientes:
- Applications: Son las aplicaciones ejecutadas por el usuario que pueden enviar y recibir tráfico de red.
- Callout: Son extensiones que permiten a los desarrolladores crear operaciones más complejas para el procesamiento de paquetes de las que Filter Engine puede llegar a implementar por sí mismo.
- Filter: Es una regla que define los criterios para el procesamiento de paquetes.
- Filter Engine: Es el núcleo del WFP el cual se encarga de evaluar los paquetes que recibe en base a los filtros implementados.
- Network Stack: Es el conjunto de software que se encarga de la gestión y procesamiento del tráfico de red entrante y saliente.
- Network Hardware: Son los componentes físicos a través de los cuales fluye el tráfico de red.
Realizada esta breve introducción al WFP, podemos entender cómo se integra en las diferentes soluciones de seguridad. Pero, para aclarar cualquier posible duda, en el caso de las aplicaciones de control parental el flujo sería el siguiente:
Una vez instalada la aplicación, esta registrará e implementará una serie de filtros en el Filter Engine. Estos filtros procesarán el tráfico de red que circula a través de los dispositivos físicos del Network Hardware y limitarán la comunicación con las aplicaciones de usuario. Esta comunicación entre las aplicaciones y los dispositivos físicos requiere del software que compone el Network Stack para poder realizarse.
En esta ocasión, EDRSilencer realiza una acción similar al funcionamiento que un firewall podría llegar a tener, que, en este caso, trata de bloquear las comunicaciones salientes de un proceso. A diferencia del firewall, EDRSilencer bloquea un proceso que está ejecutando un agente de EDR, de esta forma, al interceptar la comunicación se impide que la alerta se transmita a la central, evitando que el Blue Team sea notificado en caso de detección de actividad maliciosa.
Para lograr esto, la herramienta implementa un nuevo filtro en el FilterEngine de WFP, el cual se encarga de identificar el proceso que se desea silenciar y restringe el tráfico saliente de este último.
El flujo de la herramienta al ejecutarse es el siguiente:
1. La herramienta verifica el nivel de integridad del proceso en ejecución para confirmar que posee un nivel High o SYSTEM, dado que para añadir filtros al Filter Engine de WFP es necesario contar, como mínimo, con privilegios de administrador. Esto lo consigue mediante la obtención del token de acceso, para lo que hace uso de la función GetTokenInformation. Esta función recoge como parámetro el nivel de integridad del proceso en la estructura denominada como TokenIntegrityLevel.
2. Una vez verificado que se dispone de los suficientes privilegios como para incluir el nuevo filtro, la siguiente fase es la identificación de procesos a silenciar. Con este propósito, la herramienta cuenta con un array compuesto por nombres de procesos generados por agentes de diferentes EDRs, entre los cuales es posible destacar MicrosoftDefender, ElasticEDR, SentinelOne, FortiEDR, CortexEDR y etc. Cabe mencionar que la herramienta facilita el bloqueo de comunicación de procesos mediante la especificación de la ruta a su ejecutable.
3. En el caso de la implementación realizada en C, con el objetivo de obtener el identificador del proceso al cual se le desea aplicar el filtro, es necesaria la activación del flag SeDebugPrivilege en el token de acceso, permitiendo así la interacción con cualquier proceso o hilo independientemente de los descriptores de seguridad. Con esta finalidad, la herramienta hace uso de la función AdjustTokenPrivileges y modifica el valor del flag SeDebugPrivilege en la estructura que pasa como parámetro con el nombre tokenPrivileges.
4. Posteriormente, la herramienta continua con la obtención del identificador necesario para la implementación del filtro WFP, el cual se denomina como AppId. Este identificador es generado a partir de la ruta al ejecutable. Concretamente, se genera mediante la ruta al ejecutable del agente de EDR en formato NT.
5. La obtención de la ruta, que generalmente se adquiere mediante la función CreateFileW, es la fase más crítica de la herramienta, ya que en múltiples ocasiones esta función suele estar hookeada. Esto se debe a que el acceso a la ruta de ejecutables categorizados como de alta criticidad suele estar limitado o vigilado por el EDR. Es por ello por lo que la herramienta implementa una aproximación diferente para la obtención del AppId.
6. Para terminar, utilizando los métodos y estructuras ofrecidas por el API fwpmu.h que implementa WFP, se inicia el Filter Engine y se define (1) y añade (2) el filtro WFP mediante la función FwpmFilterAdd0.
Este flujo de acciones se repite para cada proceso relacionado con cada agente de EDR que se detecte en el activo, consiguiendo así bloquear por completo cualquier comunicación entre un agente y la central del EDR.
A continuación, se pretende mostrar una PoC utilizando .NET Framework, concretamente la versión 4.8. El propósito del desarrollo realizado es dotar a un equipo de Red Team de una herramienta capaz de silenciar el “ruido” que se pueda generar en un activo mientras se trata de comprometer a lo largo de un ejercicio. Además, se ha adaptado la herramienta para su aplicación en otros tipos de entornos, donde la ejecución mediante un execute-assembly es necesaria o resulta ser más fiable.
El desarrollo requirió el uso de P/Invoke, una tecnología que facilita la interacción con las APIs de Windows y que, en este caso en concreto, permite el acceso a estructuras y métodos específicos de la Windows Filtering Platform (WFP), lo que le ha dado a la herramienta capacidades avanzadas para administrar filtros utilizados para bloquear agentes de EDR.
Es importante recalcar que actualmente no existe documentación oficial para las P/Invokes relacionadas con el WFP y, además, con la transición al nuevo portal web, gran parte de la documentación sobre las APIs se ha perdido. Por ello, ha sido necesaria la obtención de estructuras y métodos en diferentes fuentes públicas.
Por otro lado, en lo que respecta al flujo de ejecución, las fases no han cambiado, es decir, aunque se hayan realizado múltiples cambios en lo que respecta al código, tanto para la adaptación a .NET Framework como para la propia mejoría del funcionamiento, las etapas previamente mostradas en el diagrama se siguen aplicando.
Es por ello por lo que la estrategia planteada es la siguiente. En primer lugar, se obtiene el token de acceso del proceso y se verifica su nivel de integridad. En caso de que sea High o System, el siguiente paso es la activación del flag SeDebugPrivilege que permite la interacción con otros procesos. Gracias a esto, es posible la obtención del ejecutable y su transformación a formato NT para obtener así el AppId. Finalmente, se inicializan las estructuras necesarias para la creación del filtro que se aplica sobre dicho proceso.
Para la verificación de esta estrategia, se han planteado diferentes escenarios a partir de un mismo entorno de Windows 10 Pro. En el primero, se ha utilizado un agente de Microsoft Defender para el testeo. El objetivo ha sido el bloqueo de las comunicaciones salientes evitando así que comunique con el exterior y que pueda actualizarse. Por otro lado, como segundo escenario se ha utilizado un agente de BitDefender para el mismo propósito.
Los resultados obtenidos permiten ver cómo ha sido posible el bloqueo de las comunicaciones salientes del proceso MsMpEng.exe, también conocido como Microsoft Antimalware Service Executable, que como su propio nombre indica, es el proceso encargado de ejecutar el AV que traen instalados consigo las nuevas versiones de Windows.
Una vez ejecutada la herramienta, el tráfico saliente del proceso del Defender ha sido bloqueado, evitando la comunicación de este agente con la central e inhabilitando la opción de aplicar nuevas actualizaciones.
Por otro lado, hay que destacar que el tráfico de red del resto de procesos sigue habilitado evitando sospechas de cara a la víctima.
En conclusión, EDRSilencer es una herramienta de alto valor para situaciones donde evitar la detección de soluciones de seguridad es imprescindible. Además, La integración con otras herramientas de explotación convierte a esta herramienta en un complemento esencial para cualquier operación. Esto se debe a su capacidad para bloquear notificaciones generadas por comportamientos sospechosos, evitando así alertar al Blue Team. Por otro lado, en lo que respecta a la adaptación de la herramienta a .NET Framework, se publicará una vez el código sea reestructurado.
