Hace unos días me encontré con una alerta que me llamo la atención, pues era la primera vez que la veía. La alerta en cuestión era ET TROJAN ABUSE.CH SSL Fingerprint Blacklist Malicious SSL Certificate Detected (Ixeshe CnC).
A primera vista, solo por el nombre de la alerta, queda claro que hay un fingerprint de SSL que está en la blacklist de Abuse.ch. Además, parece que es utilizado para acceder o conectarse al C2 Ixeshe. Para conocer con exactitud por qué ha saltado la alerta me dirijo a la web de documentación de Emerging Threats, en concreto a esta dirección http://doc.emergingthreats.net/bin/view/Main/2022960.
Desde la web de Emerging Threats queda claro el patrón de búsqueda. Lo primero es que haya una conexión establecida desde el servidor (flow:established,from_server;), que además aparezca el contenido 0900b5c752c98781b503 (content:”|09 00 b5 c7 52 c9 87 81 b5 03|”;) seguido de 550403 (content:”|55 04 03|”;) y finalmente que apareca 0x09localhost (content:”|09|localhost”;). Indicar que se han obviado algunas partes de la regla de Snort. Si el lector lo requiere puede dirigirse a http://manual-snort-org.s3-website-us-east-1.amazonaws.com/node32.html donde se documentan todas las opciones.
Bien, pues efectivamente Snort no falla y el contenido está dentro del paquete, se puede ver en la imagen 1. Pero como dije al principio del post, es la primera vez que veía este tipo de alertas, y claro, no sabia que significaban esos campos.
Ilustración 1: Resaltados en rojo los campos que detecta la alerta
Para identificar los campos de un paquete de red lo ideal es conocerse el protocolo y ya no solo el protocolo, sino otros formatos, pues para este caso hay que conocer el formato de certificados DER. ¿Pero quién conoce mejor los protocolos que Wireshark? Así que utilizando esta herramienta y descargando el pcap desde la web de Base pude interpretar rápidamente que significa cada campo.
En las siguientes imágenes vemos lo que representa el paquete capturado por Snort y cada uno de los campos que ha detectado la regla.
Ilustración 2: Contenido del paquete capturado por Snort
Ilustración 3: Número de serie del certificado (content:”|09 00 b5 c7 52 c9 87 81 b5 03|”)
Ilustración 4: Indicador de CommonName (content:”|55 04 03|”)
Ilustración 5: Valor del CommonName (content:”|09|localhost”)
Después de este pequeño análisis de los campos detectados ya tengo más información, y sé que es lo que está buscando detectar la regla de Snort. Básicamente es un certificado con un número de serie especifico y que el CommonName sea localhost.
Una vez situado en el contexto de la alerta, ya estoy listo para tratarla y ver si realmente se trata de un incidente de seguridad. Lo primero que debo hacer es conocer el fingerprint del certificado, pues es lo que me servirá para buscar en las listas negras de SSL y en concreto en esta https://sslbl.abuse.ch/.
Para calcular el fingerprint del certificado debemos tenerlo como un fichero y poder ejecutar openssl, no nos sirve que esté dentro de un fichero pcap. Ayudándome de Wireshark, consigo exportar el certificado. Para ello lo que hago es:
- Expandir “TLSv1 record Layer: Handsake Protocol Certificate“.
- Expandir “Handsake Protocol Certificate“.
- Expandir “Certificates“.
- Hacer clic derecho sobre el “Certificate” que me interesa, en este caso solo hay uno, y seleccionar “Export Packet Bytes“.
- Guardar con extensión .der.
Ahora que ya dispongo del certificado, tengo que calcular su fingerprint y para calcularlo utilizo el siguiente comando: openssl x509 -noout -fingerprint -text -inform der -sha1 -in <cert>.der. Se puede ver en la siguiente imagen el resultado.
Ilustración 6: En rojo el certificado exportado de Wireshark y el algoritmo para el fingerprint. En amarillo los campos detectados en el Wireshark referentes a la regla y en verde el fingerprint del certificado.
Con toda esta información ya puedo buscar en las listas negras mencionadas anteriormente y efectivamente, allí estaba: https://sslbl.abuse.ch/intel/b0238c547a905bfa119c4e8baccaeacf36491ff6. Ahora, ya sé el rango de IP, el tipo de atacante que es, el hash del malware, etc.
Para continuar la investigación consulto en https://urlquery.net la IP atacante. Parece que la IP responde por lo que el atacante sigue en activo. El reporte de urlQuery no es muy extenso, pero da información suficiente como para saber que se está sirviendo malware y que además las IP/dominios están en listas negras.
Con toda está investigación pude llegar al final del asunto: bloquear la IP atacante en el Firewall y acto seguido iniciar una gestión de incidente por ransomware.
