FTPSHADOWMOVE, ¿SUFICIENTEMENTE SIGILOSO? PARTE 1

RESUMEN

Como inicio de una serie de publicaciones sobre la capacidad de sigilo de FTPShadowMove, en esta primera parte se describirán los diferentes módulos que componen la arquitectura de esta técnica de movimiento lateral, mediante el protocolo FTP. Tras esto, se empleará la base de conocimiento de analíticas que ha sido desarrollada por MITRE y se conoce como «The MITRE Cyber Analytics Repository (en adelante mencionado como MITRE CAR), como el eje principal que conducirá las siguientes publicaciones sobre ShadowMove y la ejecución de su vertiente, FTPShadowMove,en una infraestructura de pruebas que disponga del despliegue del software de instrumentación de sistemas operativos, osquery.

Palabras clave: ShadowMove, osquery, MITRE, CAR, hipótesis, polylogyx, FTP

FTPSHADOWMOVE COMO PRUEBA DE CONCEPTO

Como ya se describió en el anterior artículo publicado en esta plataforma, titulado como “ShadowMove, osquery y el Threat Hunting”, se presentó la vertiente FTPShadowMove como un experimento a tratar en un ejercicio propuesto de caza de amenazas, dado que es una técnica que actualmente consigue evadir la detección de osquery y se espera poder desarrollar un método de seguridad defensiva con enfoque proactivo, que consiga alcanzar esa detección.

La arquitectura y el diseño de ShadowMove se basa en 6 módulos principales:

• Detector de conexiones.
• Duplicador de sockets.
• Controlador de peers (en inglés, Peer Handler).
• Administrador de vista de red.
• Mecanismo de planificación de movimiento lateral.
• Actuador de planificación de movimiento lateral.

En los siguientes apartados se describirán estos módulos más detalladamente, para poder conducir las siguientes publicaciones mediante la metodología de MITRE CAR.

DETECTOR DE CONEXIONES

En este caso, el Detector de conexiones es el responsable de la detección de nuevas conexiones TCP que puedan ser explotadas para realizar movimiento lateral. Los investigadores que primeramente publicaron esta técnica, eligieron un enfoque para la detección de conexiones que se basaba en la obtención periódica de información de conexiones TCP y comparar la información devuelta con los resultados previos, las cuales se dividen en diferentes aplicaciones para diferentes sistemas operativos:

• Para sistemas operativos Windows, obtenían esta detección de conexiones al llamar a la API de Windows mediante las funciones “GetTcpTable” y “GetTcpTable2”, las cuales recuperan la tabla de conexiones TCP IPv4 y depende de la DLL “Iphlpapi.dll” [1]. Para poder realizar esto, emplearon la herramienta TCPView.
• Para sistemas operativos Linux, ejecutan el comando “netstat –ntp” mediante el que obtenían información básica de conexiones TCP como estado de la conexión, puerto remoto, dirección IP local, puerto local, etcétera.

DUPLICADOR DE SOCKETS

El duplicador de sockets de ShadowMove secuestra las conexiones TCP dadas cuando recibe una solicitud desde el detector de conexiones o el controlador de peers. La idea subyacente es la duplicación de un socket dentro de un proceso y abusar del socket resultante para acceder a la conexión TCP, que puede describirse para diferentes sistemas operativos de la siguiente manera:

• Para sistemas operativos Windows, se puede emplear la llamada a la API de Windows “WSADuplicateSocket” para duplicar un socket, pero no se puede emplear directamente dado que requiere cooperación entre procesos, por lo que el proceso origen de FTPShadowMove debe realizar 10 pasos previos que le permita usar el socket duplicado, de la siguiente forma:
  1. 1. Para abrir el proceso objetivo se emplea “OpenProcess(PROCESS_DUP_HANDLE, pid)”.
     2. Para cada manejador de conexiones o handle de tipo 0x24, emplea “NtQuerySystemInformation(SystemHandleInformation, …)”.
     3. Para duplicar el handle, usa la función “NtDuplicateObject”.
     4. Para recuperar los nombres de los handlesduplicados, debe emplear la función “NtQueryObject(ObjectNameInformation)”.
     5. Si el nombre recibido no es “\device\afd”, omite este paso.
     6. Obtiene la dirección IP remota y el puerto remoto mediante “getpeername(handle, …)
     7. Si la dirección IP y puerto remotos no son iguales a los parámetros de entrada de datos, omite este paso.
     8. Llama a “WSADuplicateSocketW” para obtener una estructura especial de WSAPROTOCOL_INFO mediante la siguiente llamada “WSADuplicateSocketW(handle, …).
     9. Crea un socket duplicado empleado “WSASocketW(WSAPROTOCOL_INFO, …)”.
     10. Emplea ese socket mediante “recv()” y “send()”.
• Para sistemas operativos Linux, debido al estricto aislamiento de procesos no se puede duplicar un socket desde otro proceso directamente, pero si se pueden compartir sockets aunque requiere la cooperación de procesos. Dado que se entiende que la aplicación de la víctima no coopera, se fuerza a la cooperación al inyectar código, aprovechando “ptrace” [2],cuya función es rastrear procesos. Los investigadores crearon un lanzador que podría ejecutarse en la aplicación víctima como un proceso hijo y aprovecharía a “ptrace” para inyectar código, en calidad de librería compartida.

CONTROLADOR DE PEERS

Este módulo sirve para comunicarse con instancias vecinas de ShadowMove para sincronizar visiones de la red comprometida. Por un lado, actualiza el Gestor de vista de red con la información aprendida de sus peers(en castellano, iguales). Por otro lado, envía la vista de red de una instancia local de ShadowMove a otras instancias de ShadowMove remotas.

ADMINISTRADOR DE VISTA DE RED

Este gestor combina unos cuantos métodos que mantiene una imagen global de la red comprometida, basándose en notificaciones del módulo anteriormente descrito como el Detector de conexiones y el Controlador de peers. También ayuda a determinar si el tipo de servicio que soporta a cada socket duplicado y mantiene vivos a estos mismos sockets.

Su funcionamiento se basa en la gestión del conjunto de sockets duplicados y mantiene una tupla para cada socket del grupo. La mayoría de estos campos los pasa el Detector de conexiones, excepto el tipo de servicio (o protocolo), que determina en un submódulo llamado “Layer 7 Protocol Detector”,combinando algunos métodos. Primero, supone el puerto de destino, dado que muchos servicios se ejecutan detrás de puertos predeterminados conocidos, por ejemplo, el número de puerto 21 para FTP. Segundo, supone, a partir de los procesos del propietario, si son herramientas conocidas del lado del cliente para algunos servicios. Luego, si el número de puerto y la información del proceso del propietario no son suficientes para una suposición confiable, rastrea pasivamente el tráfico de la red llamando a la cvAPI en cada socket y configura la flag MSG_PEEK. Finalmente, analiza la carga útil recibida para reconocer el protocolo de nivel de aplicación, aprovechando las técnicas de análisis de protocolos existentes, como la función de detección automática de protocolos en Suricata.

MECANISMO DE PLANIFICACIÓN DE MOVIMIENTO LATERAL

De forma periódica, este mecanismo (en inglés, Lateral MovementPlanner) crea un plan de movimiento lateral basándose en la vista actual de la red comprometida y las capacidades soportadas por los sockets duplicados.En cada plan generado, se especifica el socket que debe ser empleado, el tipo de acción que debe realizarse y la carga final o payload que debe usarse.

ACTUADOR DE PLANIFICACIÓN DE MOVIMIENTO LATERAL

Finalmente, este último módulo en el que reposa la arquitectura de ShadowMove, ejecuta los pasos individuales del plan de movimiento lateral como puede ser la transferencia de un fichero a un servidor remoto, al enviar paquetes o recibir paquetes de los sockets dados.

Teniendo en mente la instanciación de FTPShadowMove, anteriormente descrita, se define como se realizará una analítica mediante la metodología de MITRE CAR.

The MITRE Cyber Analytics Repository

Para el desarrollo de la prueba de concepto que se realizará sobre FTPShadowMove, se empleará el marco de MITRE CAR [3], que establece una metodología para poder analizar tácticas, técnicas y procedimientos de los ciberatacantes, definiendo el tipo de analíticas que se pueden almacenar en este repositorio de analíticas.

Para que una analítica sea almacenada en MITRE CAR, debe cumplir los siguientes requisitos:

1. Una hipótesis que explique la idea detrás de la analítica, que en este caso es la proposición de detección de FTPShadowMove mediante osquery, una plataforma que ha sido identificado como evadible, por los propios investigadores [4] de la técnica.
2. El dominio de la información o dominio principal sobre en el que la analítica ha sido diseñada para operar (un host, una red, un proceso o un laboratorio). Para el desarrollo de estas pruebas, el dominio principal en el que se operará a FTPShadowMove será un conjunto de tres máquinas:

• • Máquina orquestadora: Máquina con sistema operativo Linux, donde estará desplegada la plataforma de Polylogyx para monitorización de flotas de hosts osquery.
  • Cliente FTP: Cliente con instalación de servicio ftp por defecto, en sistemas operativos Windows.
  • Servidor FTP: Servidor vsftpd con sistema operativo Linux.

3. Se deben proveer referencias de las técnicas y tácticas de ATT&CK, que se acojan en la detección que puede realizar la analítica. En este caso, puede que la técnica que mejor aplique para FTPShadowMove sea Application LayerProtocol: File Transfer Protocols – T1071.002.
4. El uso del glosario específico de MITRE CAR.
5. Una descripción de pseudocódigo que describirá como la analítica generada puede ser implementada, pudiendo realizar reglas de detección SIGMA que describan casos de uso.
6. Una unidad de prueba que puede ser ejecutada para desencadenar la analítica, como puede ser el código resultante de FTPShadowMove que será compartido en siguientes publicaciones.

CONCLUSIÓN

Como ya se describió en el anterior artículo publicado en esta plataforma, titulado como “ShadowMove, osquery y el Threat Hunting”, se presentó la vertiente FTPShadowMove como una técnica especialmente evasiva para agentes osquery. En esta publicación se ha desarrollado más los módulos que componen la arquitectura de esta técnica, así como el funcionamiento de la misma.

En siguientes publicaciones se desglosarán los apartados que corresponden a la metodología de MITRE CAR sobre el caso de uso que será FTPShadowMove.

Silvia Hernández Sánchez – Cyber Threat Intelligence Technical Analyst en Mnemo

BIBLIOGRAFÍA

[1] Microsoft Docs – Windows Developer. GetTcpTablefunction, 2018: https://docs.microsoft.com/en-us/windows/win32/api/iphlpapi/nf-iphlpapi-gettcptable

[2] ptrace(2) – Linux manual page, 2021: https://man7.org/linux/man-pages/man2/ptrace.2.html

[3] Mitre Cyber Analytics Repository, 2021: https://car.mitre.org/

[4] AmirrezaNiakanlahiji, JinpengWei, Md RabbiAlam, Qingyang Wang y Bei-TsengChu. ShadowMove: A Stealthy Lateral MovementStrategy, 2020: https://www.usenix.org/system/files/sec20-niakanlahiji.pdf