Una vez más se encendieron todas las alarmas, y prácticamente todos los que trabajamos en ciberseguridad tuvimos unos días de trabajo intenso analizando una amenaza que parecía repetir lo visto con WannaCry, a la vez que intentábamos contestar las numerosas preguntas de los medios.
Ciberataque masivo ¿otra vez?
Si repasamos las veces en las que se ha clasificado un ciberataque como “el más destructivo de la historia” o “sin precedentes” durante los últimos años, podríamos llenar páginas y páginas enteras de referencias. Sin embargo, no cabe duda de que este tipo de incidentes han ido ganando importancia entre el público generalista, y a día de hoy no es extraño ver como los noticiarios de medio mundo comentan estos ataques en sus titulares e incluso se realizan tertulias en programas orientados a un público no precisamente técnico.
Para no irnos muy atrás, vamos a recordar el caso de WannaCry y todo el revuelo que se produjo por un ransomware bastante mal diseñado pero que consiguió afectar a empresas de todo el mundo al utilizar algo que muchos temíamos: algunos de los exploits de la NSA publicados semanas antes.
Tras ese incidente, no era de extrañar que las primeras noticias que aparecieron durante el mediodía del pasado martes 27 de junio activaran todas las alarmas. Las primeras fotografías obtenidas de los equipos infectados mostraban equipos bloqueados con un mensaje que tenía toda la pinta de ransomware, concretamente de uno que analizamos el año pasado y de nombre Petya.
No tardaron en aparecer los nombres de grandes empresas entre los afectados, aunque a diferencia de WannaCry, la gran mayoría de noticias que hablaban de sistemas infectados apuntaban a Ucrania como principal víctima.
Tras ver la pantalla en la que se pedía el pago de un rescate, lo lógico era pensar que estábamos ante un nuevo caso de extorsión por parte de un grupo criminal que quería hacer dinero rápido. Además, tanto la forma de actuar como los análisis iniciales del código revelaron que este nuevo malware tenía muchas similitudes con Petya, por lo que todos los indicios apuntaban en esa dirección.
Descubriendo el vector de ataque inicial
No obstante, cuando nos paramos a revisar cómo funcionaba realmente este nuevo malware vimos que había mucho más de lo que parecía a primera vista. Se lanzaron varias hipótesis sobre el posible vector de ataque inicial, como la de un fichero Word con macros maliciosas, o incluso que se estuviesen volviendo a explotar las mismas vulnerabilidades aprovechadas por WannaCry mes y medio antes.
Sin embargo, la cosa era más complicada de lo que parecía, y tras revisar numerosos sistemas infectados por Diskcoder.C (o ExPetr, PetrWrap, Petya, o NotPetya, elíjase el nombre que más nos guste), se comprobó que el vector de infección inicial fue un software de contabilidad muy utilizado en Ucrania, de nombre M.E.Doc. Este software dispone de un sistema propio de mensajería e intercambio de documentos, por lo que el envío de un fichero infectado parecía factible como origen de este ciberataque. No obstante, este no fue el caso, al menos en esta ocasión.
Tras revisar el software de contabilidad a fondo, investigadores de ESET han podido demostrar cómo uno de los módulos legítimos de este programa fue comprometido por los atacantes, permitiéndoles obtener una puerta trasera. Parece también improbable que los atacantes pudieran hacer esto sin disponer del código fuente del software M.E.Doc, lo que demuestra un elevado nivel de especialización.
Con estos datos en la mano, estos investigadores han examinado las actualizaciones del software de contabilidad más recientes y han podido demostrar que al menos en tres de ellas se encontraba el módulo modificado con la puerta trasera, datando estas actualizaciones del 14 de abril, 15 de mayo y 22 de junio.
Asimismo, Diskcoder.C no fue el único que se aprovechó de esta situación, ya que a mediados de mayo se observó que (esta vez sí) un ransomware de nombre Win32/Filecoder.AESNI.C (también conocido como Xdata) tuvo cierto impacto entre empresas de Ucrania que utilizaban el software M.E.Doc.
Una vez los delincuentes conseguían infectar un sistema dentro de una red, comenzaban a moverse lateralmente en busca de nuevos equipos a los que infectar. Para ello utilizaron no solo los exploits conocidos de la NSA usados también por WannaCry (aunque esta vez solo para moverse dentro de una red local), sino también herramientas legítimas como PSExec de SysInternals o los proveedores WMI de Windows.
Además, se utilizaron herramientas específicas como CredRaptor o Plainpwd para el robo de credenciales almacenadas en la memoria de los equipos infectados y así conseguir propagarse por la red por si los otros métodos fallaban. Todo esto para asegurarse que conseguían infectar el mayor número de máquinas posible.
El ransomware que no fue
A pesar de los antecedentes y de las evidencias que apuntaban a un nuevo caso de ransomware, el análisis del código y su comportamiento revelaron que Diskcoder.C no tenía intención alguna de facilitar la recuperación de los ficheros cifrados. Ya hemos indicado que tomaba prestado funcionalidades de Petya y esto es visible en el momento en el que este malware reemplaza el MBR o sector de arranque del disco para mostrar su mensaje pidiendo el rescate.
Sin embargo, la modificación del MBR realizada en este caso no permitía su recuperación (algo que con Petya sí que se podía hacer) y, además, la víctima no podría introducir su clave de descifrado en la pantalla donde se solicita, puesto que esta incluiría caracteres no aceptados. Antes de llegar a la pantalla donde se explica lo sucedido y se solicita el rescate, se realiza un proceso de cifrado de los archivos del disco, proceso camuflado como una comprobación de disco CHKDSK.
El cifrado utilizado para cifrar los archivos del disco está mal implementado y esto dificulta sobremanera recuperarlos. Además, los delincuentes tan solo habilitaron una dirección de pago del rescate cuando lo normal en estos casos es generar varias, y el correo preparado para informar del pago del rescate fue dado de baja pocas horas después de descubrir el ataque.
Todos estos puntos indican que los atacantes nunca tuvieron la intención de posibilitar la recuperación de los datos y que la finalidad real de Diskcoder.C era dejarlos inservibles. Así pues, no podemos hablar de un ransomware en este caso, sino de un malware pensado para destruir información, especialmente la almacenada en empresas y administraciones de Ucrania.
El problema de las atribuciones y represalias
Una vez analizado este incidente con calma y con mucha información encima de la mesa, es cuando los analistas proceden a lanzar sus conjeturas. Está claro que Diskcoder.C es mucho más avanzado que WannCry y que su objetivo era claramente las empresas y organismos de este país. Los daños colaterales sufridos por empresas de otros países se explican por las conexiones VPN de estas empresas a sus filiales o socios comerciales en Ucrania.
Quién podría estar interesado en provocar daño a los sistemas informáticos de Ucrania ya es otro cantar. Obviamente, la tensa situación que vive este país con Rusia hace que muchos apuesten por un ataque organizado o apoyado por este país, pero eso es algo que no se puede atribuir a la ligera.
Ucrania ha sido víctima de numerosos ciberataques en los últimos años, y el análisis de Diskcoder.C ha revelado conexiones con ataques anteriores como el que afectó a la industria eléctrica de este país, y concretamente con el malware utilizado en diciembre de 2015, BlackEnergy. La vinculación de este y otros ataques con el perpetrado la semana pasada apunta hacia el grupo conocido como Telebots, aunque aún está por ver su relación con alguna nación-estado.
Es este un aspecto peliagudo, el de las atribuciones, ya que no se puede afirmar categóricamente quién está detrás de un ciberataque de estas características sin tener pruebas totalmente concluyentes. Se ha llegado a afirmar que este incidente podría llegar a ser considerado como un acto de guerra y siendo Ucrania un candidato a formar parte de la OTAN, algunos apuntan a que esta organización podría llegar a tomar en el futuro represalias en respuesta a este tipo de ataques.
De momento, y basándonos en el informe elaborado por expertos de esta organización, las represalias deberían ser proporcionadas al daño causado, e incluso se sugiere como ejemplo una operación de sabotaje de los sistemas informáticos del país atacante, aunque no se realice utilizando medios cibernéticos.
No debemos olvidar que la historia está llena de ataques realizados con una falsa bandera, e incluso la Segunda Guerra Mundial, considerado el peor enfrentamiento bélico sufrido por la humanidad por sus terribles consecuencias, tuvo operaciones en las que miembros de las SS atacaron instalaciones alemanas camuflados como agentes polacos para justificar la invasión de este país.
Conclusión
Si WannaCry supuso una llamada de atención con respecto a la lucha que se está llevando a cabo desde hace años contra un tipo de malware especialmente molesto como es el ransomware, Disckcoder.C debe considerarse como uno de los numerosos ejemplos en los que un ataque aparentemente común oculta otras intenciones, con una finalidad muy clara y un objetivo muy dirigido.
Debemos ser muy cautos a la hora de analizar casos como este, puesto que podríamos caer en la trampa de quedarnos analizando la superficie del problema, ignorando lo que se esconde bajo ella y haciendo falsas atribuciones que podrían tener graves consecuencias.