Día típico de otoño, por la ventana solo se aprecia un cielo gris. Es el típico día en el que crees que no va a suceder nada extraño. De repente nuestro sistema de vigilancia alerta de unas conexiones anómalas: un equipo ha intentado conectarse contra unas direcciones IP de origen desconocido. Estas direcciones IP son públicas y, según la configuración establecida en la organización, toda conexión HTTP hacia el exterior debe pasar a través de un proxy.
Las conexiones se buscan en los registros del proxy y no se encuentran, por lo tanto este equipo ha intentado conectarse directamente, haciendo caso omiso a la configuración del sistema.
El horario en el que se producen las conexiones es desde las 06:52 am hasta las 07:09 am.
Además, se ve que no solo ha intentado comunicarse por el puerto 80 sino que lo ha intentado por otros puertos como el 139, 445 y el 97.
Surgen muchas dudas. ¿Habrá llegado a su buzón un correo con un adjunto capaz de evadir todas las barreras de la organización? ¿Habrá visitado una Web con un watering hole? ¿Habrá conectado un pendrive infectado?
El antivirus local de su equipo no ha detectado nada extraño.
En las investigaciones sobre esas direcciones IP no se encuentra gran cosa salvo que pertenecen a o Akamai, o a una supuesta empresa de telecomunicaciones china:
Analizando la captura de tráfico se ve que no se ha producido una conexión efectiva:
Ahora toca averiguar porque se han producido esos intentos de conexión. Para ello se prepara una imagen de la memoria RAM del equipo y un triage con la herramienta CyLR.
Se comienza analizando la captura de memoria. Normalmente suelo consultar algún cheat sheet de Volatility, pero me he automatizado los comandos básicos para futuras ocasiones:
No se encuentra ni rastro de las conexiones ni evidencias que relacionen esos intentos de conexión en la imagen de la memoria.
Se procede a analizar la MFT con mftdump, exportando la información a formato CSV para una mejor lectura.
Acotando por el día y las horas de las conexiones se ve la modificación de un fichero que llama la atención:
WindowsSystem32winevtLogsMicrosoft-Windows-WPD-MTPClassDriver%4Operational.evtx
Este log hace referencia a un driver MTP (Media Transfer Protocol). Con el visor de eventos de Windows se procede a analizar dicho Event Log:
Es entonces cuando entra en juego una nueva dirección IP que nada tiene que ver con el rango asignado por DHCP en la organización. Se vuelve a investigar en el volcado de la memoria ese rango de red.
Al buscar en los strings generados con Volatility el rango de red anterior:
Se puede ver un identificador. Parece ser que el usuario ha conectado un dispositivo usb.
En una búsqueda rápida en Google, en el primer link de la Web de Microsoft, especifica que se trata de un dispositivo de red por usb:
Una información con la que poder contrastar en los log DLP (Data Loss Prevention) del endpoint y ver qué tipo de dispositivo ha conectado:
Se trata de un dispositivo móvil de la marca Xiaomi, concretamente el modelo Mi 5.
Además, si se tiene activada la opción Usb Tethering, el dispositivo automáticamente se instala en el equipo y hace de punto de acceso para conectarse a Internet:
Como prueba trato de conectar este mismo modelo en un equipo con Windows y viendo la configuración de red se ve que el rango asignado por el terminal es familiar:
Esta práctica es bastante habitual cuando el usuario quiere saltarse las restricciones de un proxy en una organización, haciendo Tethering y usando por ejemplo un navegador portable.
Una medida rápida para evitar este tipo de comportamiento sería deshabilitar la posibilidad de instalar automáticamente los drivers cada vez que se conecta un nuevo dispositivo:
Pero en un entorno corporativo muy grande puede dar problemas (incapacidad de conectar y usar impresoras, pendrives, etc.)
Por lo tanto existe una opción mucho más acertada que es imposibilitar el uso de dispositivos de red por usb. Para ello hay que modificar la entrada de registro:
Y modificar el valor “start” a 4.
Existe un problema, ya que si en el equipo nunca se ha conectado un dispositivo de red usb, esta entrada de registro no existirá. La solución viene por crear de forma manual la entrada de registro:
Se crea un fichero.reg que contenga:
Y Ejecutar fichero.reg
Nota: El driver C:Windowssystem32DRIVERSusb8023x.sys no existe, pero en las pruebas que he hecho, no hace falta copiar tal fichero ya que con la sola entrada de registro de forma manual es suficiente.
La entrada Mi5terio resuelto aparece primero en Security Art Work.
