El módulo de persistencia de Duqu 2.0

Anteriormente explicamos por qué Duqu 2.0 no tenía un mecanismo normal de “persistencia”. Esto podría llevar a los usuarios a pensar que para deshacerse de este programa malicioso bastaría reiniciar todos los equipos infectados. Pero, en realidad, las cosas son un poco más complicadas de lo que parecen.

Los atacantes han creado un módulo poco habitual de persistencia que instalan en las redes atacadas, y que cumple una doble función, ya que también tiene un esquema oculto de comunicación con el servidor C&C. Esta persistencia a nivel organizativo se logra mediante un controlador que se instala como un servicio regular del sistema. En los sistemas 64-bit, esto implica un requisito estricto de una firma digital Authenticode. Ya hemos detectado dos de estos controladores de persistencia instalados en el transcurso de los ataques.

Durante sus operaciones, los actores de Duqu instalaron estos controladores maliciosos en cortafuegos, pasarelas y en aquellos servidores que tienen acceso directo a Internet, por un lado, y a la red corporativa, por otro. Estos controladores permiten cumplir varios objetivos al mismo tiempo: acceder a la infraestructura interna desde Internet, evitar entradas en los registros de los servidores proxy corporativos y, a pesar de todo, mantener alguna forma de persistencia.

Esencialmente, los controladores redirigen los flujos en la red hacia y desde el equipo pasarela que los ejecuta. Para renviar conexiones, el atacante primero debe pasar un mecanismo de “llamada” de red que está protegido por una contraseña. Hasta ahora hemos observado dos contraseñas diferentes en las muestras recopiladas: “romanian.antihacker” y “ugly.gorilla”.

Hemos descrito uno de estos controladores en nuestro documento sobre Duqu 2.0 (sección “The ”portserv.sys” driver analysis”). Revisemos algunos de los detalles más importantes: El controlador escucha la red y espera una contraseña especial (“romanian.antihacker” en ese caso). Después, guarda la IP del host que pasó la contraseña correcta y comienza a redirigir todos los paquetes del puerto 443 al puerto 445 (SMB) o 3389 (Escritorio Remoto) de ese servidor. En efecto, esto les permite a los atacantes canalizar el SMB (es decir, el acceso remoto al sistema de archivos) y el Escritorio Remoto a través del servidor pasarela, haciéndolos pasar como tráfico HTTPS (puerto 443).

Además del controlador “romanian.antihacker”, hemos descubierto otro que hace un trabajo similar, pero que admite más conexiones de una forma más genérica:

1. Cuando el controlador reconoce la contraseña “ugly.gorilla1”, todo el tráfico desde la IP de los atacantes se redirige desde el puerto 443 (HTTPS) al 445 (SMB).
2. Cuando el controlador reconoce la contraseña “ugly.gorilla2”, todo el tráfico desde la IP de los atacantes se redirige desde el puerto 443 (HTTPS) al 3389 (RDP).
3. Cuando el controlador reconoce la contraseña “ugly.gorilla3”, todo el tráfico desde la IP de los atacantes se redirige desde el puerto 443 (HTTPS) al 135 (RPC).
4. Cuando el controlador reconoce la contraseña “ugly.gorilla4”, todo el tráfico desde la IP de los atacantes se redirige desde el puerto 443 (HTTPS) al 139 (NETBIOS).
5. Cuando el controlador reconoce la contraseña “ugly.gorilla5”, todo el tráfico desde la IP de los atacantes se redirige desde el puerto 1723 (PPTP) al 445 (SMB).
6. Cuando el controlador reconoce la contraseña “ugly.gorilla6”, todo el tráfico desde la IP de los atacantes se redirige desde el puerto 443 (HTTPS) al 47012 (por ahora desconocido).

Queremos remarcar que uno de los puertos nos parece bastante sospechoso: el 47012. Por el momento, no hemos observado que otros componentes de Duqu 2.0, ni otros programas maliciosos, puertas traseras, o software comunes usen este puerto (también según SANS). Sin embargo, el hecho de que este número de puerto estaba incrustado en el programa malicioso podría ser una sólida señal de infección para Duqu 2.0.

Parte del programa malicioso con cadena de contraseñas

Este controlador de 64-bit contiene un nombre DLL interno, “termport.sys”, mientras que el nombre de archivo en el sistema de archivos era “portserv.sys”. Esto muy probablemente significa que los atacantes cambian los nombres de archivo para diferentes operativos, por lo que la detección de este ataque no debería depender únicamente de los nombres de archivo. Esta marca de tiempo de la compilación parece falsa: “Jul 23 18:14:28 2004”. Todos los archivos del controlador descubiertos se encontraban en “C:WindowsSystem32drivers”.

Quizás la parte más importante de esta estrategia de ataque sea la firma digital que utiliza el driver 64-bit. Puesto que se trata de un requisito obligatorio en los sistemas Windows 64-bit, el controlador tenía una firma digital válida. Estaba firmada por “HON HAI PRECISION INDUSTRY CO. LTD.” (también conocido como “Foxconn Technology Group”, uno de los principales fabricantes electrónicos del mundo).

Firma digital en el controlador de los atacantes

Según la información del controlador, fue firmado a las 20:31 el 19.02.2015. Abajo ofrecemos más detalles provistos por la utilidad Sigcheck de SysInternal:

Según Wikipedia, “Foxconn Technology Group” es el mayor fabricante de componentes electrónicos a nivel mundial, cuya sede se encuentra en Tucheng, Nuevo Taipéi, Taiwán.

Los principales clientes de Foxconn incluyen o incluyeron algunas de las compañías más grandes del mundo:

• Acer Inc.
• Amazon.com
• Apple Inc.
• BlackBerry Ltd.
• Cisco
• Dell
• Google
• Hewlett-Packard
• Huawei
• Microsoft
• Motorola Mobility
• Nintendo
• Nokia
• Sony
• Toshiba
• Xiaomi
• Vizio

Foxconn fabrica una serie de productos conocidos (https://es.wikipedia.org/wiki/Foxconn), como BlackBerry, iPad, iPhone, Kindle, PlayStation 4, Xbox One y Wii U.

El fabricante usó el mismo certificado para firmar varios controladores WatchDog Timer Kernel (WDTKernel.sys) para ordenadores portátiles Dell, en febrero de 2013.

Conclusiones

Durante nuestra anterior investigación sobre Stuxnet y Duqu, observamos programas maliciosos con firmas digitales (usaban certificados maliciosos Jmicron y Realtek). El robo de certificados digitales y la firma de programas digitales en nombre de compañías legítimas parece ser un ardid normal para los atacantes de Duqu. No tenemos ninguna confirmación de que alguno de estos fabricantes haya sido infectado, pero nuestros indicadores definitivamente muestran que los atacantes de Duqu concentran su interés en fabricantes de hardware, como Foxconn, Realtek y Jmicron. Esto quedó confirmado en los ataques de 2014/2015, cuando observamos infecciones que afectaron a fabricantes de hardware del área Asia-Pacífico, incluyendo a los fabricantes de equipos informáticos ICS y SCADA.

Otra observación interesante es que aparte de estos controladores de Duqu, no hemos detectado ningún otro programa malicioso firmado con los mismos certificados. Esto descarta la posibilidad de una filtración de certificados y de que estén en manos de otros grupos. También parece indicar que los atacantes de Duqu son los únicos que tienen acceso a estos certificados, lo que refuerza la teoría de que hackearon a los fabricantes de hardware para obtener dichos certificados.

Por último, resulta interesante que los atacantes de Duqu sean lo suficientemente cuidadosos como para no repetir el uso del mismo certificado digital. Esto es algo que hemos visto con Duqu desde 2011 y 2015. Si eso es cierto, entonces significa que los atacantes pueden tener en sus manos suficientes certificados digitales robados de otros fabricantes, y que podrían usarlos en su próximo ataque dirigido. Esto sería en extremo alarmante, ya que debilita la reputación de los certificados digitales.

Se ha informado tanto a Verisign como a HON HAI sobre el certificado utilizado para firmar el programa malicioso Duqu 2.0.

IOC

Muestra MD5 (portserv.sys): 92e724291056a5e30eca038ee637a23f

Número de serie del certificado Foxconn utilizado por los atacantes de Duqu:

‎25 65 41 e2 04 61 90 33 f8 b0 9f 9e b7 c8 8e f8

Certificado completo del controlador malicioso:

—–BEGIN CERTIFICATE—–
MIIFmTCCBIGgAwIBAgIQJWVB4gRhkDP4sJ+et8iO+DANBgkqhkiG9w0BAQUFADCB
tDELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug
YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykxMDEuMCwGA1UEAxMl
VmVyaVNpZ24gQ2xhc3MgMyBDb2RlIFNpZ25pbmcgMjAxMCBDQTAeFw0xMjA4MjUw
MDAwMDBaFw0xNTA4MjUyMzU5NTlaMIHcMQswCQYDVQQGEwJUVzEPMA0GA1UECBMG
VEFJV0FOMREwDwYDVQQHEwhUVS1DSEVORzEsMCoGA1UEChQjSE9OIEhBSSBQUkVD
SVNJT04gSU5EVVNUUlkgQ08uIExURC4xPjA8BgNVBAsTNURpZ2l0YWwgSUQgQ2xh
c3MgMyAtIE1pY3Jvc29mdCBTb2Z0d2FyZSBWYWxpZGF0aW9uIHYyMQ0wCwYDVQQL
FARQQ0VHMSwwKgYDVQQDFCNIT04gSEFJIFBSRUNJU0lPTiBJTkRVU1RSWSBDTy4g
TFRELjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALzM40T355R4ov9F
OcwiBpBwRk5047T5PxoabBPGyhqjqVyTJ3vxYWunUsGJpq2myS7uPmDkPXc+qExE
SRBIgruiGpazeqXsP7EfEr8BRU4iVvKmD//m5uZvqEAsz6FzJ/PMlfiZponm5PLa
hcIM9AtqdhqDek7taoAaPUbYjY2wgan8+jaNWo0BzmvimN74AC5N0aZgTFBvIRux
Ev2EO1x4Ypz3UqFwMTHHdexJqM19W20mmbpjGfoxkfl4yUuUg5O4tdgTbZVF9mui
rWpVCuGcB1iUpUxTCoidGfx1ROkzYgLV7XLt50Iir0btqM4tshG4GJUhAX+rEy+r
sr5gFnUCAwEAAaOCAXswggF3MAkGA1UdEwQCMAAwDgYDVR0PAQH/BAQDAgeAMEAG
A1UdHwQ5MDcwNaAzoDGGL2h0dHA6Ly9jc2MzLTIwMTAtY3JsLnZlcmlzaWduLmNv
bS9DU0MzLTIwMTAuY3JsMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwMwKjAoBggr
BgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTATBgNVHSUEDDAK
BggrBgEFBQcDAzBxBggrBgEFBQcBAQRlMGMwJAYIKwYBBQUHMAGGGGh0dHA6Ly9v
Y3NwLnZlcmlzaWduLmNvbTA7BggrBgEFBQcwAoYvaHR0cDovL2NzYzMtMjAxMC1h
aWEudmVyaXNpZ24uY29tL0NTQzMtMjAxMC5jZXIwHwYDVR0jBBgwFoAUz5mp6nsm
9EvJjo/X8AUm7+PSp50wEQYJYIZIAYb4QgEBBAQDAgQQMBYGCisGAQQBgjcCARsE
CDAGAQEAAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQA9niTkOi3raLWjtQBJK3br8RDS
X+6NtHj/OhSuFzVsJcmhvaf4DIhJ00ghScXcZZycod/7kYN9NBIrTMqlB5GsOuWI
/TPk9HoIvEoVEoliuEBwDiHbIidaLKcS3sPqgV0WNx46JYmCI/++KMCZ7zfDSlZb
213OpauHuQj7tUIKGlEKq7qIvGaR+EUcxpgVR/AxuxTtjUWaSItCM2vMGKUMDNXH
rN+2IYeHsnMqe68RoIRLlq3BPQkA+JcpjjV2Td5Q4Y2xj7E558EQ4utYduwCv+kq
OQgeV4KumDaoN9Y7+e79jWzoIkKM4IxQ8u1jfxGuG35l9k7seksYOwdM1dN5

—–END CERTIFICATE—–