Recientemente en Ucrania y Polonia, una gran cantidad de organizaciones y empresas privadas de diversos sectores de la industria resultaron víctimas de ataques donde se utilizaba malware especialmente diseñado para detectar redes y ejecutar códigos remotos, así como para robar datos de los discos rígidos. Lo que hace interesantes a estos ataques (más allá de la tensa situación actual geopolítica en la región) es que se llevaron a cabo utilizando nuevas versiones de BlackEnergy, una familia de malware con una rica historia, además de los diversos mecanismos de distribución usados para introducirlo en los equipos de las víctimas.

Presentaremos los resultados de nuestra investigación esta semana en la conferencia Virus Bulletin en Seattle.

BlackEnergy es un troyano que experimentó cambios funcionales significativos desde que Arbor Networks lo analizó por primera vez en forma pública en 2007. Creado originalmente como un troyano simple para el ataque distribuido de denegación de servicio (DDoS), evolucionó hasta convertirse en un malware sofisticado con arquitectura modular: una herramienta adecuada para enviar spam y cometer fraudes bancarios online, así como para realizar ataques dirigidos.

La versión 2 de BlackEnergy, que incorporó técnicas de rootkits, fue documentada por Dell SecureWorks en 2010. Los ataques dirigidos descubiertos recientemente comprueban que, aún hoy, el troyano sigue con vida: las últimas variantes de BlackEnergy datan de septiembre de 2014.

BlackEnergy Lite: ¿menos es más?

Mientras que el troyano BlackEnergy original sigue circulando en forma activa en el mundo real, descubrimos variantes de la familia del malware que se pueden diferenciar fácilmente de sus antecesores.

Llamamos BlackEnergy Lite a las modificaciones de BlackEnergy (descubiertas por primera vez a comienzos de 2014) debido a la ausencia de un componente de controlador de modo kernel, menos compatibilidad para controladores y un impacto general menor en el sistema.

Es interesante señalar que los mismos creadores del malware lo llamaron de una forma similar, como se muestra en el directorio de exportación de una de las primeras versiones del DLL principal:

export_directory

Cabe notar que incluso las muestras originales de BlackEnergy detectadas este año evolucionaron de forma tal que el controlador de modo kernel solo se usa para inyectar la carga maliciosa en los procesos de modo usuario, y además ya no contienen la funcionalidad de rootkit para ocultar objetos en el sistema. Las nuevas versiones más livianas van un paso más allá y directamente ni siquiera usan el controlador. En cambio, el DLL principal se carga usando una técnica más ‘amable’ y ‘oficial’: simplemente se carga mediante rundll32.exe. F-Secure ya había mencionado esta evolución en publicaciones de su blog.

La omisión del controlador de modo kernel puede parecer un retroceso en cuanto a la complejidad de la amenaza; no obstante, en la actualidad es una tendencia en aumento dentro del panorama de los códigos maliciosos. Las amenazas que hace unos años se encontraban entre el malware de rango más alto en términos de sofisticación técnica (por ejemplo rootkits y bootkits, como Rustock, Olmarik/TDL4, Rovnix, entre otros) ya no siguen siendo tan comunes.

Podría haber varias razones tras esta tendencia, desde los obstáculos técnicos que deben superar los desarrolladores de rootkits en la actualidad (como los requisitos de firma del controlador de sistema de Windows, el Arranque seguro UEFI, un tema que tratarán Eugene Rodionov, Aleks Matrosov y David Harley en su presentación de VB2014 Bootkits: pasado, presente y futuro) hasta el simple hecho de que el desarrollo de ese tipo de malware es más difícil y costoso. Además, todo error del código suele tener la mala costumbre de desestabilizar el sistema y mostrar la pantalla azul; quizá hasta incluso advirtiendo sobre la presencia de un código malicioso en vez de ocultarlo en el sistema.

Existen varias diferencias más entre BlackEnergy Lite y su versión original: el marco de complementos, el almacenamiento de complementos, el formato de configuración, etc.

Campañas de BlackEnergy en 2014

La familia BlackEnergy se utilizó con muchos propósitos a lo largo de su historia, incluso para ataques distribuidos de denegación de servicio, distribución de spam y fraudes bancarios. Las variantes que rastreamos en 2014 (tanto de BlackEnergy como de BlackEnergy Lite) se utilizaron en ataques dirigidos a sectores específicos. Este hecho se demuestra tanto por los complementos utilizados como por la naturaleza y los objetivos de ataque de las campañas en propagación.

El propósito de estos complementos era principalmente la detección de redes y la ejecución remota de código, así como para recopilar datos de los discos rígidos de las víctimas.

Observamos más de cien víctimas individuales de estas campañas mientras monitoreábamos las botnets. Aproximadamente la mitad de estas víctimas residen en Ucrania y la otra mitad en Polonia, e incluyen organizaciones estatales, varias empresas privadas y otros objetivos que no logramos identificar.

Las campañas en propagación que observamos utilizaban métodos técnicos de infección a través del aprovechamiento de vulnerabilidades en el software, Ingeniería Social mediante correos electrónicos dirigidos y documentos señuelo, o una combinación de ambos.

En abril descubrimos un documento que aprovechaba la vulnerabilidad CVE-2014-1761 en Microsoft Word. Este exploit también se utilizó en otros ataques, incluyendo MiniDuke.

En este caso, como resultado de la ejecución exitosa del código Shell del exploit, se colocan dos archivos en el directorio temporal: la carga maliciosa llamada “WinWord.exe” y un documento señuelo denominado “Russian ambassadors to conquer world.doc”. A continuación, estos archivos se abren utilizando la función kernel32.WinExec. La carga WinWord.exe cumple la función de extraer y ejecutar el dropper que instala BlackEnergy Lite. El documento señuelo contiene un texto controversial pero evidentemente falso, que se muestra a continuación:

texto_falso

Al mismo tiempo, apareció otro documento que también aprovechaba la vulnerabilidad CVE-2014-1761. El texto, aunque menos controversial que el del ejemplo anterior, también trataba sobre relaciones exteriores. El tema era el foro GlobSEC, que se celebraría en Bratislava este año:

globsec_bratislava

Un mes después, en mayo, encontramos otro archivo diseñado para instalar BlackEnergy Lite. Sin embargo, en esta ocasión, no se usó ningún exploit: el archivo, llamado “список паролiв ,” (lo que significa “lista de contraseñas” en ucraniano) era un simple archivo ejecutable con un ícono de Microsoft Word:

adjunto_word

A pesar de ser un ejecutable, el archivo también contenía un documento señuelo integrado con (como habrán adivinado) una lista de contraseñas. F-Secure también describió este caso en una publicación del blog.

Estas son las claves listadas:

  1. 123456
  2. Admin
  3. Password
  4. Test
  5. 123
  6. 123456789
  7. 12345678
  8. 1234
  9. Qwerty
  10. Asdf
  11. 111111
  12. 1234567
  13. 123123
  14. Windows
  15. 123qwe
  16. 1234567890
  17. password123
  18. 123321
  19. asdf123
  20. Zxcv
  21. zxcv123
  22. 666666
  23. 654321
  24. pass
  25. 1q2w3e4r
  26. 112233
  27. 1q2w3e
  28. zxcvbnm
  29. abcd1234
  30. asdasd
  31. 555555
  32. 999999
  33. qazwsx
  34. 123654
  35. q1w2e3
  36. 123123123
  37. guest
  38. guest123
  39. user
  40. user123
  41. 121212
  42. qwert
  43. 1qaz2wsx
  44. qwerty123
  45. 987654321
  46. pass123
  47. trewq
  48. trewq321
  49. trewq1234
  50. 2014

También hubo campañas activas para la propagación de BlackEnergy Lite más recientemente, en agosto, e incluso en septiembre, según el sistema telemétrico de amenazas LiveGrid® de ESET. En uno de los casos se usaron documentos de PowerPoint especialmente diseñados, mientras que otros intentos de diseminar el malware al parecer utilizaron vulnerabilidades no identificadas de Java o el software de control remoto Team Viewer.

Se darán más detalles sobre estos casos este jueves en la conferencia de Virus Bulletin, que publicaremos posteriormente.

Traducción del post de Robert Lipovsky en We Live Security.