En una publicación anterior del blog, hablé sobre cómo Splunk, y por extensión, otras herramientas de seguridad, pueden usarse con fines maliciosos. En ese ejemplo específico, analizamos una técnica directa de exfiltración de datos. Esa publicación generó algo de atención, pero sentí que no ejemplificaba el daño que el control malicioso de herramientas de seguridad puede causar a una empresa.
En esta publicación, detallaré cómo el Splunk Universal Forwarder (UF) puede usarse como traitorware para lograr persistencia y ejecución remota de código.
¿Sabías que? El traitorware, según lo definen Alberto Rodriguez y Erik Hunstad, es:
1. Software que traiciona la confianza depositada en él para realizar acciones maliciosas
2. Software confiable con una intención original benigna que se usa para acciones maliciosas
Para quienes no estén familiarizados, Splunk es una robusta herramienta de recolección de registros, estándar en entornos empresariales. Ciertas características y funcionalidades se pueden agregar mediante aplicaciones técnicas (TA) y complementos. Estas aplicaciones pueden ser tan simples como un archivo de configuración para monitorear un solo directorio, o tan complejas como una interfaz de usuario con funcionalidades de código ejecutable.
Un ejemplo es el Splunk Add-on for Windows, que le da a Splunk funcionalidad adicional para recolectar información de hosts Windows. Este es un complemento muy común de Splunk, con más de 415.000 descargas (al momento de escribir esto). Este complemento permite que el Splunk UF recolecte datos de registro adicionales del sistema mediante scripts de PowerShell y entradas personalizadas.
En este escenario, busco usar el Splunk UF como un troyano de acceso remoto (RAT) en el sistema, permitiendo que el Splunk UF reciba comandos arbitrarios de PowerShell desde un servidor remoto. Para esto, usaré una aplicación personalizada de Splunk que utiliza la funcionalidad de entrada de PowerShell que ofrece Splunk.
AVISO IMPORTANTE: Esta prueba de concepto es solo para fines demostrativos y no representa una vulnerabilidad, error o nuevo exploit dentro de Splunk. Estas son configuraciones compatibles con Splunk y provistas en su documentación. El objetivo es demostrar que los actores de amenazas pueden abusar de las herramientas de TI y seguridad, y usar su funcionalidad principal con fines maliciosos.
Profundicemos
Primero, debemos crear una aplicación personalizada de Splunk para abusar de la funcionalidad de entrada de PowerShell de Splunk. Una aplicación de Splunk es un conjunto de archivos de configuración instalados en cualquier dispositivo Splunk o, en este caso, en el UF. Estos archivos de configuración pueden habilitar nuevas funcionalidades, proporcionar entradas de datos o crear nuevos elementos de interfaz de usuario.
Crearemos nuestra aplicación de Splunk bajo <Splunk Install>\etc\apps, y contiene los siguientes componentes: un script de PowerShell y un archivo de configuración de entradas usado para ejecutar el script.
Aquí está la estructura de carpetas de nuestra aplicación:
Comenzando con inputs.conf, podemos empezar a dibujar el panorama:
Analicemos cada una de estas configuraciones.
Script
- Contiene la ruta a nuestro script de PowerShell. $SplunkHome se establece durante la instalación del UF y es el directorio de instalación.
Schedule
- El script se ejecutará según este horario en formato cron. Este ejemplo se ejecuta cada 10 minutos en punto (12:00, 12:10, 12:20, etc.) Este es un mecanismo de persistencia integrado, ya que Splunk volverá a ejecutar el script automáticamente. También podemos programarlo para que se ejecute una sola vez, o al iniciar el sistema, por ejemplo.
Disabled, Index y Sourcetype
- Estas configuraciones no siempre son necesarias y no son cruciales en este escenario. Splunk usa index y sourcetype para saber a dónde enrutar las salidas del script, pero no configuraré el UF para enviar registros a ningún lugar como parte de esta prueba de concepto.
Para git.ps1, usaremos Invoke-WebRequest para extraer el HTML de una página web, recolectar el contenido únicamente de la etiqueta de comentario HTML en la página, y luego ejecutar ese contenido como un comando.
Con fines demostrativos, 10.0.0.235 es un servidor web que controlo. Reemplazar la IP por un nombre de dominio mantendrá la misma funcionalidad.
Notarás que estamos usando [System.Text.Encoding] para decodificar un valor en base64 almacenado en $value. Las etiquetas de comentario HTML contienen comandos de PowerShell, y descubrí que algunos caracteres en los comandos de PowerShell se interpretarían como HTML, lo cual no devolvería el valor correcto con Invoke-WebRequest (< y >, por ejemplo.) Para evitar ese problema, simplemente codifiqué en base64 el contenido de la etiqueta de comentario.
Aquí está el HTML de la página web que estamos extrayendo:
Nuestro comando codificado en Base64 es d2hvYW1pID4gQzpcdXNlcnNcdXNlclxkZXNrdG9wXGhlbGxvLnR4dA==, que se decodifica como whoami > C:\users\user\desktop\hello.txt.
Después de juntar todo, el Splunk UF obtendrá un comando de la página web cada 10 minutos pasada la hora, lo que nos permite cambiar la página web para enviar nuevo código al endpoint víctima.
Aquí hay una captura de pantalla que muestra la conexión al servidor web y el contenido del archivo hello.txt que creamos. Por defecto, el Splunk UF se ejecuta como NT Authority\System y ejecutará scripts con el mismo contexto de usuario.
¿Por qué funciona esto?
Splunk UF configura el servicio SplunkUniversalForwarder para ejecutarse como NT Authority\System, y esto se debe a que varias de las tareas en segundo plano que Splunk realiza para la recopilación de datos requieren privilegios administrativos.
Si desglosamos el Splunk Add-on for Windows mencionado antes, encontraremos varios scripts de PowerShell para recopilar datos como información de DNS, registros de actualización de Windows, estado de replicación, etc. Esta es información estándar que la mayoría de los administradores encontraría útil. Aun así, el manejador de scripts del Universal Forwarder no limita el uso de PowerShell ni las conexiones de red, lo que nos permite inyectar casi cualquier comando y hacer conexiones salientes. Aunque creé una aplicación personalizada de Splunk para demostrar esto, es posible inyectar código malicioso de PowerShell en aplicaciones de Splunk existentes, como el Add-on for Windows.
Esta no es una técnica nueva; los investigadores de seguridad han usado el UF de Splunk como herramienta de seguridad ofensiva durante años. El blog de Tom Kopchak sobre cómo aprovechar Splunk como herramienta de seguridad ofensiva cubre esta técnica y una técnica similar para Linux con mucho más detalle.
Mitigación
Para Splunk:
- Monitorea tu entorno en busca de cambios, incluidas nuevas instalaciones del Splunk UF (especialmente si no usas Splunk) o UF de Splunk que se reinician de forma inesperada o que ya no se registran con el servidor de implementación.
- No ejecutes el Splunk UF como root o administrador.
- Esto puede ser un poco tedioso en Windows, ya que tendrás que configurar e implementar GPOs para gestionar las políticas de seguridad local en un entorno grande. La documentación de Splunk sobre este proceso está aquí.
- Para Linux, este proceso es más sencillo. Implica cambiar algunos permisos de carpetas y ajustar la configuración de inicio de Splunk. La documentación de Splunk sobre este proceso está aquí.
- Limita el tráfico saliente permitido por Splunk, como restringir el tráfico solo a los puertos de Splunk o deshabilitar el acceso a internet.
- Usa la arquitectura de referencia de Splunk como base para una implementación segura.
Mitigación general para prevenir el abuso de herramientas de TI/seguridad:
- Monitorea los registros internos de las herramientas de TI/seguridad en busca de comportamiento sospechoso.
- Monitorea el tráfico de red en busca de conexiones anómalas, persistencia o exposición innecesaria de puertos.
- Segmentación de redes de las herramientas de seguridad y la infraestructura crítica.
- Limita el tráfico saliente solo a los puertos y protocolos necesarios.
- Usa una estrategia de defensa por capas para los métodos de detección a nivel de red y endpoint.
- Usa SSO y MFA con políticas de contraseñas robustas para los administradores que acceden a estas herramientas.
¿Quieres más consejos de ciberseguridad? Únete a nosotros en Tradecraft Tuesdays.
