El juicio contra los creadores del troyano bancario Lurk por fin ha llegado a su fin. Fueron detenidos debido a una operación conjunta sin precedentes entre varias autoridades y la ayuda de nuestros expertos. El arresto tuvo lugar en el 2016; sin embargo, la investigación y el proceso judicial se han alargado otros cinco años. Pero esto no debería sorprendernos, dado que la cantidad de sospechosos y víctimas involucrados en el caso no tenía precedente. Incluso tuvieron que transportar a los miembros de Lurk en autobús y los archivos del caso ocupaban hasta 4000 volúmenes (un volumen = 250 páginas). La cantidad de trabajo era enorme y requería mucho tiempo, los sospechosos analizaron todos los registros y declaraciones con lupa, pero en el 2018, 27 acusados fueron llevados a juicio.
Kaspersky ha estado monitorizando las actividades del grupo desde el 2011. Escuché sobre Lurk por primera vez cuando llegué a la empresa en el 2013 y recuerdo que pensé: “Atrápalos y podrás retirarte fácilmente. Tu carrera estará prácticamente concluida”. En comparación con los ciberdelincuentes habituales de la época, estos parecían ser verdaderamente sofisticados, tanto en el aspecto técnico como en el organizativo. Dicho esto, si hoy me encontrara con Lurk, probablemente no estaría tan impresionado y los vería simplemente como un grupo que utiliza las mejores prácticas.
El veredicto de la corte es una buena excusa para echar la vista atrás y analizar los aspectos destacados de su actividad delictiva.
La estrategia de infección
Debemos iniciar con el vector de infección. Los atacantes utilizaban la táctica watering-hole, publicando una redirección a un kit de exploits en varios sitios web de medios comerciales. Este método no era nada nuevo, pero en este caso, para infectarse, la víctima (siempre un contable) visitaba el sitio durante la hora de la comida (y solo en ese momento). El kit de exploits descargaba un troyano sin archivos en su ordenador, que se utilizaba únicamente para espiar.
Los ciberdelincuentes primero estudiaban qué programas se ejecutaban en el equipo, ya fuera software bancario o cualquier rastro de software de investigación, y en qué subredes trabajaba la máquina (el foco principal eran las redes bancarias y gubernamentales). En otras palabras, evaluaban si el ordenador era interesante y sabían exactamente a quién querían atacar.
El malware principal se descargaba solo si el ordenador resultaba de interés. De lo contrario, robaban todas las contraseñas que podían, por si acaso, y eliminaban el malware del equipo de la víctima.
La comunicación con mando y control
El proceso de intercambio de información entre el troyano y el servidor de mando y control (C&C por sus siglas en inglés) no era menos notable. La mayoría de los troyanos de esa época incluían la dirección del C&C prefijada en el código fuente. Los autores simplemente especificaban el nombre de dominio, lo que les permitía, en caso de que fuera necesario, cambiar la dirección IP del servidor: es decir, si perdían el control de las direcciones principales del C&C, simplemente podían reemplazarlas con una copia de seguridad. En definitiva, era un mecanismo de seguridad bastante primitivo. En este aspecto, Lurk era muy diferente: el grupo empleaba un método digno de una novela de espías.
Antes de una sesión de comunicación, Lurk calculaba la dirección del servidor C&C. Los ciberdelincuentes buscaban en Yahoo! el precio de las acciones de una empresa específica (durante nuestra investigación, era McDonald’s). Dependiendo del valor de la acción en un momento específico, generaban un nombre de dominio y accedían a este. Es decir, para controlar el troyano, los ciberdelincuentes investigaban el precio de las acciones en ese momento preciso y registraban un nombre de dominio con base en estas cifras. Es decir, era imposible saber por adelantado qué nombre de dominio se utilizaría para el servidor C&C.
Esto plantea una pregunta legítima: si el algoritmo estaba incrustado en el troyano, ¿qué impedía a un investigador generar dicha secuencia, registrar un nombre de dominio antes que los ciberdelincuentes y simplemente esperar a que el troyano se conectara a él? Por desgracia, los creadores de Lurk habían tomado precauciones.
Utilizaban el cifrado asimétrico. Es decir, se generaban un par de claves, con lo que el bot, al acceder al servidor C&C, utilizaba la clave pública para comprobar si realmente pertenecía a sus propietarios (comprobando la firma digital). Esto resulta imposible de falsificar sin conocer la clave secreta. Por tanto, solo el propietario de la clave secreta puede recibir solicitudes de bots y emitir comandos, ningún investigador externo puede emular el servidor C&C. El resto de los ciberdelincuentes no utilizaban este método de protección, por lo que si detectábamos que la clave privada del servidor estaba protegida, podíamos estar seguros de que se trataba de un ataque de Lurk.
Una infraestructura organizada
La configuración de los procesos de Lurk merece una mención aparte. Si otros grupos de ciberdelincuentes de la época eran solo unos cuantos usuarios de un foro (uno encargado de la programación, otro de cobrar y un tercero de coordinar), en contraste, Lurk era casi una empresa informática hecha y derecha. De hecho, resulta más preciso compararlos con una gran corporación de software que con un grupo cibercriminal. Es más, a nivel organizativo, siguen siendo un modelo para muchos grupos hoy en día.
En Lurk operaban unos verdaderos profesionales (probablemente con buena experiencia en desarrollo) que construyeron una infraestructura altamente organizada con directivos y personal de recursos humanos. A diferencia de muchos otros grupos, les pagaban a sus empleados un salario (en lugar de un porcentaje de las ganancias). Incluso solían celebrar reuniones informativas semanales, lo que en aquella época era algo totalmente inaudito. En resumen, era una corporación maligna ejemplar.
Incluso contaban con un sistema claramente estructurado, basado en funciones, para restringir el acceso a la información. Después del arresto, algunos miembros del grupo leyeron la correspondencia de sus jefes y solo en ese momento se dieron cuenta de que no se les estaba tratando justamente.
Documentaron minuciosamente todas sus actividades, mucho más que muchas empresas informáticas hoy en día. Esto, por supuesto, ayudó en gran manera a la investigación. Y, tal vez, fue lo que finalmente causó su caída: cuanto más sistemática sea tu estrategia, más fácil será rastrearte. Estos son algunos ejemplos.
Las bases de conocimiento
El grupo Lurk mantuvo una base de conocimiento detallada que estaba claramente dividida en proyectos. Cada proyecto quedaba accesible solo a ciertas personas, es decir, los participantes de un proyecto no sabían sobre las actividades del resto. El alcance de los proyectos variaba, desde el punto de vista técnico hasta el organizativo. Y los proyectos técnicos también estaban subdivididos en niveles. Por ejemplo, los desarrolladores del troyano tenían acceso a la base de conocimiento solo en relación con este tipo de temas: cómo evitar los antivirus, cómo probar, etc. Pero también había bases de datos generales sobre seguridad operativa (similar a las regulaciones de seguridad en empresas grandes). Estas proporcionaban información sobre cómo los empleados de Lurk deberían configurar sus estaciones de trabajo para evitar la detección y cómo utilizar las herramientas de anonimato.
El acceso a la información
Para obtener acceso a los recursos de información de Lurk, los ciberdelincuentes necesitaban conectarse a algún servidor mediante varias VPN. Pero, incluso de esta forma, solo recibían acceso a la administración de bots. Después, cada empleado obtenía su propio certificado y su propia cuenta con diferentes derechos. En otras palabras, era como una red corporativa normal configurada para el trabajo remoto. En general, si no hubiera sido por su falta de la autentificación en dos pasos, podrían haber sido considerados una empresa modelo.
En físico, todos los servidores estaban ubicados en distintos centros de datos y países y, cuando llegabas a uno de estos a nivel virtual mediante una VPN, no conocías la verdadera dirección IP del servidor. Este fue uno de los motivos principales por los que el grupo resultaba tan difícil de detectar.
El desarrollo
El grupo Lurk contaba con repositorios adecuados de código fuente, desarrollo automatizado y procedimientos de pruebas de varios pasos, un servidor de producción, un servidor de prueba y un servidor de desarrollo. En esencia, estaban haciendo un producto de software serio: en todo momento contaban con una versión de producción, una de prueba y con los desarrolladores del troyano.
El servidor C&C promedio de un troyano típico entonces podía recibir solicitudes de bots, registrarlas en una base de datos y proporcionar un panel de administración para gestionarlas. Todo esto se implementaba de manera efectiva en una sola página. Lurk implementó el panel de administración y la base de datos por separado, mientras que el mecanismo para enviar respuestas a los bots se ocultó por completo mediante un servicio intermediario.
Los paquetes de exploits
Lurk tenía tres paquetes de exploits, cada uno de ellos con tres nombres: uno interno, creado por sus desarrolladores, uno para clientes y socios y uno asignado por los investigadores. Lo que sucedía es que no solo los autores de Lurk utilizaban sus propios desarrollos, sino que también vendían paquetes de exploits a otros ciberdelincuentes. Es más, las versiones para los “socios” tenían un código distinto, lo que era un intento claro de disfrazarlos como otros paquetes de exploits populares.
La caída de Lurk
Al final, no sirvieron todos los trucos de los ciberdelincuentes y la mayoría de los miembros del grupo fue arrestada. Pero esto sucedió después de que el daño ya estuviera hecho: durante su amplia carrera, los atacantes robaron aproximadamente 45 millones de dólares. Nuestros expertos estudiaron sus métodos durante casi seis años (lo cual, por cierto, proporcionó una valiosa experiencia que seguimos utilizando para luchar contra la ciberdelincuencia).
Si estás interesado en conocer todas las conclusiones comerciales relevantes de esta saga, te recomendamos leer este artículo. También encontrarás un análisis técnico detallado en nuestra publicación de Securelist.