Rubeus contra YARA: ¿Quién ganará? Descubre la clave de la evasión
Introducción
En entornos corporativos, la ejecución de herramientas como Mimikatz, Rubeus y otros binarios ampliamente conocidos suele ser bloqueada debido a la implementación de medidas avanzadas de seguridad, como soluciones de antivirus (AV) y EDRs. Estas barreras representan un desafío significativo a la hora de demostrar vulnerabilidades de seguridad. Ante este problema, existen dos enfoques principales:
- Utilizar herramientas alternativas que implementen las mismas técnicas de explotación de forma diferente
- Modificar las herramientas existentes para evitar que sean detectadas
Objetivo
En esta píldora nos centraremos en el segundo enfoque: cómo modificar una herramienta cuyo código fuente está disponible, sin comprometer su funcionalidad. Para ello, es fundamental entender las metodologías que los sistemas de detección emplean para identificar y catalogar estas herramientas como maliciosas. Generalmente, estos sistemas utilizan dos estrategias principales:
- Análisis estático del binario: Examina el archivo sin ejecutarlo para identificar patrones, firmas y artefactos maliciosos
- Análisis dinámico y detección por comportamiento: Monitorea el binario en ejecución, evaluando sus acciones y cómo interactúa con el sistema
En este caso, nos enfocaremos en el análisis estático, que, en términos prácticos, se basa en la detección de firmas. Las herramientas de análisis estático pueden descompilar binarios y buscar patrones específicos en el código, determinando si una herramienta podría ser maliciosa. Por ejemplo, nombres de funciones, cadenas estáticas o secuencias de bytes características pueden ser marcadas como sospechosas.
Si adaptamos este concepto al uso de reglas YARA, la explicación se vuelve más intuitiva. Las reglas YARA son utilizadas por analistas de seguridad y herramientas de detección para identificar archivos sospechosos mediante un conjunto de patrones definidos. Estas reglas consisten en:
- Cadenas hexadecimales: Definen patrones binarios o bytes específicos en el archivo
- Cadenas de texto: Identifican palabras o frases relevantes
- Expresiones regulares: Permiten definir patrones más complejos y flexibles
En el ejemplo, existen ciertas cadenas desde $a – $d definidas inicialmente que más adelante son utilizadas en la condición de la regla. Si se cumple $a o $b y se cumple $c o $d, la regla será ejecutada y mostrada como resultado del análisis de la muestra.
Ejemplo
Para el siguiente ejemplo, utilizaremos un combo de reglas ya predefinidas Yaraforge para evadir Rubeus.
Rubeus es una herramienta escrita en C# para interactuar y abusar de Kerberos, permitiendo ataques como Kerberoasting, ASREPRoasting, Overpass-the-Hash, Pass-the-Ticket, abusos de delegación de recursos y persistencia en el directorio activo. Se puede encontrar el código fuente en su repositorio. Este dispone de una regla yara ya proporcionada por el creador y fácil de entender.
Si no se cumple una de las dos condiciones (definidas con el operador lógico AND), la regla no se ejecutará, evadiéndola. La cadena hace referencia al GUID del proyecto por defecto, por lo que creando un nuevo GUID y modificándolo en las propiedades del proyecto debería conseguir evadir la regla.
Para conocer las reglas que aplican al proyecto de Rubeus, se debe contar con:
- Rubeus inicial compilado
- Binario YARA para comprobar las reglas
- Las reglas de Yara Forge
Con la siguiente sintaxis se ejecutará el binario compilado inicialmente. Se pueden ver cuatro reglas yara que se van a evadir a continuación, utilizando Visual Studio con la utilidad Buscar y Reemplazar.
Regla: FIREEYE_RT_Hacktool_MSIL_Rubeus_1
Esta regla ya la comentamos previamente, puesto que es la misma que existe en el repositorio. Modificando el GUID del proyecto con otro válido, será posible evadir esta regla.
Se modifica el GUID en el código del proyecto de Rubeus. Al compilar nuevamente y lanzar el escaneo de reglas yara, eliminaremos la capacidad de detección basado en esta regla.
Regla: SIGNATURE_BASE_HKTL_NET_GUID_Rubeus
Durante la ejecución del anterior escaneo, nos daremos cuenta de que no solamente eliminamos una, sino que fueron dos, está incluida. Esto se debe a que esta regla contempla también el GUID del proyecto para su detección.
Regla: ELASTIC_Windows_Hacktool_Rubeus_43F18623
La siguiente regla tiene como objetivo buscar los literales de los mensajes de salida de Rubeus. En este caso, el operador lógico OR contempla ambos lados para tener en cuenta, tanto el GUID como obtener cuatro de los literales definidos previamente. Como en el lado izquierdo ya no existe el GUID al proyecto cambiado para las anteriores reglas, tan solo queda eliminar cuatro de los ocho literales. Todas ellas comparten algo en común, el identificador [Y] donde Y puede ser un valor entre *,+,X o !. Si utilizamos la funcionalidad de Buscar y Reemplazar, podremos cambiar todos estos valores entre corchetes para eliminar el match con el literal. Este cambio es seguro ya que los corchetes suelen ser usados como decoración en los mensajes de salida, pero dependiendo del escenario, hay que comprobar que no perdemos usabilidad del binario.
Repetimos el proceso en los símbolos restantes eliminado la detección de la regla yara
Regla: DITEKSHEN_INDICATOR_TOOL_PWS_Rubeus
Esta última regla contempla nombres de las funciones usadas internamente por Rubeus, así como algunos de los parámetros de entrada. En el primer caso no existe ninguna dificultad a la hora de modificar el código, pero con los parámetros hay que tener especial consideración, ya que alteramos parámetros de entrada que se deberá tener en cuenta. Uno de los casos es el de rc4opsec usado como parámetro de consulta para forjar un ticket seguro. Para que la regla se rompa, al ser un operador AND, se debe eliminar uno de los segmentos, por ejemplo, que existan ocho de los diez literales definidos anteriormente. Con la modificación de tres de ellos, esta regla ya no será marcada.
Buscamos tres literales y los modificamos con nombres alternativos para cumplir con los requisitos. Por ejemplo:
Repetimos este proceso con los siguientes literales:
- WriteUserPasswordToFile por WriteTheUserPasswordCredentialsToFile
- rc4opsec por errec4opsec
Esta regla ya no será ejecutada, eliminando la capacidad de detección de los sistemas de defensa que utilicen este escaneo.
Conclusiones
En esta entrega hemos explorado cómo, de una manera sencilla, es posible ocultar herramientas mediante la modificación de su código original. Este enfoque busca eliminar Indicadores de Compromiso (IOC) y trazas típicas de herramientas conocidas, que suelen ser rápidamente detectadas en entornos protegidos. Sin embargo, en escenarios reales, la complejidad es mucho mayor, y estas modificaciones básicas suelen ser insuficientes para evadir soluciones modernas de Antivirus (AV) y EDR, debido a factores como:
- Reglas de detección propietarias: Cada producto de seguridad cuenta con reglas específicas no públicas, lo que complica su evasión
- Análisis dinámico: Además de las firmas, muchos EDR incorporan análisis de comportamiento que monitorean cómo interactúan las herramientas con el sistema
A continuación, enumeramos algunos puntos clave y dificultades que deben considerarse al diseñar técnicas de evasión más avanzadas:
- Reglas YARA avanzadas: Algunas reglas no solo detectan cadenas literales o funciones específicas, sino que también consideran patrones de bytes o estructuras más complejas (como ocurre si utilizamos el mismo escenario pero con Mimikatz)
- Reglas propietarias de los productos de seguridad: Las detecciones no públicas requieren pruebas extensivas y un enfoque iterativo para encontrar técnicas eficaces de evasión
- Factores adicionales: Más allá de las reglas estáticas, los sistemas de seguridad evalúan acciones sospechosas, firmas digitales del binario y anomalías en el flujo de ejecución, por lo que la evasión debe ser integral.
Axel Losantos, Senior Offensive Security Consultant en Zerolynx by Cybertix
Powered by WPeMatico
