Scenario:
During your shift as a tier-2 SOC analyst, you receive an escalation from a tier-1 analyst regarding a public-facing server. This server has been flagged for making outbound connections to multiple suspicious IPs. In response, you initiate the standard incident response protocol, which includes isolating the server from the network to prevent potential lateral movement or data exfiltration and obtaining a packet capture from the NSM utility for analysis. Your task is to analyze the pcap and assess for signs of malicious activity.
Tools:
- Wireshark
#1 Respuesta: 146.190.21.92
By identifying the C2 IP, we can block traffic to and from this IP, helping to contain the breach and prevent further data exfiltration or command execution. Can you provide the IP of the C2 server that communicated with our server?Obtención de la evidencia
Una manera simple de identificar comunicaciones en Wireshark es a través de la función ‘Statistics’ > ‘Conversations’. En la siguiente imagen, observamos tres conexiones, todas ellas implicando la dirección IP: «34.209.197.3». Es razonable concluir que esta dirección corresponde a nuestro servidor.
Asimismo, notamos que la IP: 146.190.21.92 se ha comunicado con nuestro servidor mediante un total de 4,867 paquetes.
En consecuencia, podemos inferir que la IP 146.190.21.92 es el C2.
#2 Respuesta: 61616
Initial entry points are critical to trace back the attack vector. What is the port number of the service the adversary exploited?
Obtención de la evidencia
Para determinar el puerto explotado por el adversario, podemos utilizar la misma ventana de comunicaciones que empleamos en la pregunta anterior. Aquí, debemos enfocarnos en que la solicitud debe originarse desde el C2 hacia el servidor, es decir, desde 146.190.21.92 hacia 134.209.197.3. La única entrada que cumple con esta lógica indica que la comunicación se realiza desde el puerto 47284 del C2 al puerto 61616 de nuestro servidor, con una transmisión de 504 bytes.
#3 Respuesta: Apache ActiveMQ
Following up on the previous question, what is the name of the service found to be vulnerable?El puerto 61616 está asociado comúnmente con el servicio de Apache ActiveMQ. Más información
#4 Respuesta: 128.199.52.72
The attacker's infrastructure often involves multiple components. What is the IP of the second C2 server?Obtención de la evidencia
Si volvemos a la sección Statistics > Conversations, podemos identificar otras dos direcciones IP: 84.239.49.16 y 128.199.52.72.
Al analizar estas dos direcciones IP, podemos observar lo siguiente:
84.239.49.16
El registro de comunicación muestra múltiples intentos fallidos de establecer una conexión TCP desde la dirección IP 84.239.49.16 al puerto 443 en la dirección IP 134.209.197.3, típicamente utilizado para conexiones HTTPS. A pesar de varios intentos de conexión, cada solicitud del cliente es respondida por el servidor con un restablecimiento de la conexión (RST, ACK), indicando una negativa o incapacidad para establecer la conexión solicitada. Este patrón sugiere posibles problemas de conectividad o configuración en el servidor destino.
128.199.52.72
Esta comunicación muestra una interacción entre un cliente (134.209.197.3) y un servidor (128.199.52.72), donde el cliente está realizando una solicitud HTTP GET al servidor para obtener el recurso «/docker». Aquí está el análisis de cada línea, con énfasis en la línea 34:
- El cliente envía un paquete SYN al servidor para iniciar una conexión TCP.
- El servidor responde con un paquete SYN-ACK, indicando que está dispuesto a establecer una conexión TCP.
- El cliente confirma la recepción del SYN-ACK con un paquete ACK.
- Este es el paquete crucial: el cliente envía una solicitud HTTP GET al servidor para obtener el recurso «/docker».
- El servidor confirma la recepción de la solicitud HTTP con un paquete ACK.
- El servidor envía una respuesta HTTP al cliente, indicada por el conjunto de bits PSH, ACK. El cuerpo de la respuesta está fragmentado, y este paquete contiene parte del cuerpo de la respuesta.
- El cliente confirma la recepción de la respuesta HTTP del servidor.
- El servidor envía la parte restante de la respuesta HTTP al cliente, confirmando la solicitud con un código de estado «200 OK».
- El cliente envía un paquete FIN-ACK al servidor, indicando que ha terminado de enviar datos.
- El servidor confirma el cierre de la conexión con un paquete ACK.
En resumen, la línea 34 muestra que el cliente está solicitando el recurso «/docker» al servidor utilizando el método HTTP GET. Esta solicitud inicia una comunicación entre el cliente y el servidor, seguida de la transmisión y recepción de datos adicionales.
Al realizar un seguimiento del flujo TCP de la comunicación que realiza la solicitud GET a /docker, observamos lo siguiente:
- Solicitud (Request):
- Método: GET
- Recurso solicitado: /docker
- Versión de HTTP: 1.1
- Host: 128.199.52.72
- User-Agent: curl/7.68.0
- Accept: /
- Respuesta (Response):
- Versión de HTTP: 1.0
- Código de estado: 200 OK
- Server: SimpleHTTP/0.6 Python/3.8.10
- Date: Tue, 12 Dec 2023 13:38:28 GMT
- Content-type: application/octet-stream
- Content-Length: 250 bytes
- Last-Modified: Tue, 12 Dec 2023 12:23:04 GMT
La solicitud (GET) indica que se está solicitando el recurso «/docker» desde el servidor con la dirección IP 128.199.52.72. El cliente que realiza la solicitud se identifica como «curl/7.68.0». El servidor responde con un código de estado «200 OK», lo que significa que la solicitud se completó con éxito. El servidor está utilizando SimpleHTTP/0.6 en Python/3.8.10 para manejar la solicitud. El contenido de la respuesta está en formato «application/octet-stream» y tiene una longitud de 250 bytes. La última modificación del recurso fue el «Tue, 12 Dec 2023 12:23:04 GMT».
Después de la sección de encabezado de la respuesta, parece haber datos binarios codificados en formato ELF (Executable and Linkable Format), que generalmente se usa para archivos ejecutables en sistemas basados en Unix. Estos datos binarios son la respuesta real del servidor al recurso solicitado «/docker».
Por lo tanto, podemos concluir que el segundo C2 se trata de: 128.199.52.72
#5 Respuesta: docker
Attackers usually leave traces on the disk. What is the name of the reverse shell executable dropped on the server?Obtención de la evidencia
Al filtrar por la dirección IP del primer C2 (146.190.21.92), se observa una solicitud GET que ocurre en la línea 11,
Al realizar un seguimiento del flujo TCP de esta comunicación, observamos lo siguiente:
El registro de comunicación revela una solicitud HTTP GET seguida de una respuesta del servidor. En el mismo, se observa que la Reverse Shell está identificada como «docker».
Análisis:
- Solicitud (Request):
- Método: GET
- Recurso solicitado: /invoice.xml
- Versión de HTTP: 1.1
- Cache-Control: no-cache
- Pragma: no-cache
- User-Agent: Java/11.0.21
- Host: 146.190.21.92:8000
- Accept: text/html, image/gif, image/jpeg, *; q=.2, /; q=.2
- Connection: keep-alive
Esta solicitud indica que el cliente (probablemente una aplicación Java) está solicitando el recurso /invoice.xml al servidor ubicado en la dirección IP 146.190.21.92 en el puerto 8000. La solicitud especifica que no se debe usar caché para la respuesta.
- Respuesta (Response):
- Versión de HTTP: 1.0
- Código de estado: 200 OK
- Server: SimpleHTTP/0.6 Python/3.8.10
- Date: Tue, 12 Dec 2023 13:38:28 GMT
- Content-type: application/xml
- Content-Length: 816
- Last-Modified: Tue, 12 Dec 2023 13:37:45 GMT
La respuesta del servidor indica que se ha encontrado el recurso solicitado y se envía correctamente. La respuesta tiene un código de estado «200 OK». El contenido de la respuesta está en formato XML con una longitud de 816 bytes. También se proporciona información sobre el servidor y la fecha de la respuesta.
Además, dentro del contenido XML devuelto, hay una configuración de Spring Beans que incluye un bean de tipo ProcessBuilder. Este bean parece estar configurado para ejecutar un comando de bash utilizando la herramienta curl para descargar un archivo llamado docker desde la dirección IP 128.199.52.72, darle permisos de ejecución y luego ejecutarlo. Este fragmento de código dentro del contenido XML podría ser un intento de ejecutar un script malicioso en el servidor que realiza la solicitud.
#6 Respuesta: java.lang.ProcessBuilder
What Java class was invoked by the XML file to run the exploit?
Obtención de la evidencia
Como vimos en la pregunta anterior y en el análisis del GET, el fragmento de código XML contenido en la respuesta del servidor indica la configuración de un bean de la clase java.lang.ProcessBuilder.
#7 Respuesta: CVE-2023-46604
To better understand the specific security flaw exploited, can you identify the CVE identifier associated with this vulnerability?Obtención de la evidencia
Simplemente buscando «java.lang.ProcessBuilder CVE» podemos encontrar el identificador asociado a esta vulnerabilidad.
#8 Respuesta: BaseDataStreamMarshaller.createThrowable
What is the vulnerable Java method and class that allows an attacker to run arbitrary code? (Format: Class.Method)Obtención de la evidencia
Para encontrar esta respuesta, realicé una búsqueda en mi navegador utilizando el término «CVE-2023-46604 método y clase Java vulnerables», lo que generó múltiples artículos relacionados. En el segundo resultado, en el sitio web fidelissecurity.com, encontré un análisis que proporcionaba la respuesta.
Asimismo, en la página de Trend Micro también podemos encontrar esta información.
