El juicio de los creadores del troyano bancario Lurk finalmente terminó. Fueron detenidos debido a una operación conjunta sin precedentes entre varias autoridades y la ayuda de nuestros expertos. Los criminales fueron arrestados en el 2016; sin embargo, la investigación y el caso en el tribunal se alargaron durante otros cinco años. Pero esto no debería sorprendernos, ya que la cantidad de sospechosos y víctimas involucrados no tenía precedente. Incluso fue necesario 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 a juicio.
Kaspersky ha estado monitoreando las actividades del grupo desde el 2011. Escuché sobre Lurk por primera vez cuando llegué a la empresa en el 2013. Recuerdo que pensé: “Atrápalos y puedes retirarte fácilmente. Tu carrera estará prácticamente concluida.” En comparación con los cibercriminales usuales de ese entonces, estos parecían ser verdaderamente sofisticados, tanto en el aspecto técnico como en el de organización. Habiendo dicho esto, si el día de hoy me encontrara a Lurk, probablemente no estaría tan impresionado y los vería como un grupo que se apegó a las mejores prácticas.
El veredicto de la corte es una buena excusa para poner la mira retrospectiva sobre los aspectos destacados de su actividad cibercriminal.
Esquema de infección
Debemos iniciar con el vector de infección. Los atacantes utilizaron una táctica watering-hole, la cual publicaba un redireccionamiento a un kit de exploits en varios sitios web de medios de empresas. Este método no era nuevo, pero en este caso, para infectarse, la víctima (siempre un contador) había visitado el sitio durante su hora de comida (y solo en este momento). El kit de exploits descargó un troyano sin archivos en su computadora, el cual se utilizó únicamente para espiar.
Los cibercriminales primero estudiaron qué programas se ejecutaban en la máquina, ya sea que fueran software bancario o cualquier rastro de software de investigación, y en qué subredes trabajaba la máquina (el enfoque principal eran las redes bancarias y gubernamentales). En otras palabras, evaluaron qué tan interesante era la computadora, y sabían exactamente a quién querían afectar.
El malware principal se descargaba solo si la computadora era de interés. De no ser así, robaban todas las contraseñas que podían obtener, por si acaso, y eliminaban el malware de la máquina de la víctima.
Comunicación con C&C
El proceso de intercambio de información entre el troyano y el servidor comando-y-control (C&C) 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 especificaron el nombre de dominio, lo que les dejó la opción, de ser necesario, de cambiar la dirección IP del servidor: es decir, si perdían control de las direcciones principales del C&C, simplemente podían reemplazarlas con un respaldo. En definitiva, era un mecanismo de seguridad bastante primitivo. En este respecto, 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 cibercriminales 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 cibercriminales investigaron el precio de las acciones en ese momento preciso y registraron un nombre de dominio con base en estas cifras. En otras palabras, era imposible saber por adelantado qué nombre de dominio se utilizará para el servidor C&C.
Esto plantea una pregunta legítima: si el algoritmo estaba incrustado en el troyano, ¿qué evitaba que un investigador generara esta secuencia, registrara un nombre de dominio antes que los cibercriminales, y solo esperara el troyano para conectarse a este? Pero los creadores de Lurk habían tomado sus precauciones. Utilizaron criptografía asimétrica. Es decir, se generaba 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 (verificando la firma digital). Esto es imposible de falsificar sin conocer la clave secreta. Así que, 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. Otros cibercriminales no utilizaron este método de protección en ese entonces, de manera que si detectábamos protección de la clave privada en el servidor, podríamos asegurarnos de que era un ataque de Lurk.
Infraestructura organizada
La configuración de los procesos de Lurk merece una mención aparte. Si otros grupos cibercriminales de ese momento era solo un montón de usuarios de foros (uno se encargó de la programación, otro de cobrar, un tercero fue el coordinador), entonces, en contraste, Lurk fue casi una empresa de TI hecha y derecha. Es más preciso compararlos con una gran corporación de software que con un grupo cibercriminal. Es más, en términos de nivel organizativo, siguen siendo un modelo para muchos grupos hasta este día.
Verdaderos profesionales operaban Lurk (muy probablemente con buena experiencia en desarrollo) quienes construyeron una infraestructura altamente organizada con gerentes y personal de recursos humanos. A diferencia de muchas 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 totalmente inaudito. En resumen, era una corporación maligna ejemplar.
Incluso contaban con un sistema claro estructurado basado en funciones, para restringir el acceso a la información. Después de su 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 de TI 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: mientras más sistemático sea tu enfoque, es más fácil rastrearte. Estos son algunos ejemplos.
Base de conocimiento
El grupo Lurk mantuvo una base de conocimiento detallada que estaba claramente dividida en proyectos. Cada proyecto estaba accesible solo a ciertas personas, es decir, los participantes de un proyecto no sabían sobre las actividades de otro. 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 los temas: cómo evitar los antivirus, cómo probar, etc. Pero también había bases de datos generales en seguridad operativa (similar a las regulaciones de seguridad en empresas grandes). Estos 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.
Acceso a la información
Para obtener acceso al recurso de información de Lurk, los cibercriminales necesitaban conectarse a algún servidor mediante varias VPN. Incluso así, solo recibieron acceso a la administración de bots. Después, cada empleado obtuvo 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 2FA, podrían haber sido considerados una empresa modelo.
En físico, todos los servidores estaban ubicados en distintos centros de datos y en distintos países. Cuando llegas a uno de estos a nivel virtual mediante una VPN, no conoces la verdadera dirección IP del servidor. Y eso fue en gran manera por lo que el grupo era tan difícil de detectar.
Desarrollo
El grupo Lurk tenía 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 cualquier momento tenían una versión de producción, de prueba y de los desarrolladores del troyano.
El servidor C&C promedio de un troyano típico en ese entonces podría recibir solicitudes de bots, registrarlas en una base de datos y proporcionar un panel de administración para gestionarlas. Todo esto se implementó 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 para los bots se oscureció por completo mediante un servicio intermediario.
Kits de exploits
Lurk tenía tres kits de exploits, cada uno de los cuales tenía 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 kits de exploits por su lado, a otros cibercriminales. Es más, las versiones para los “socios” tenían un código distinto, lo que era un intento claro por disfrazarlos como otro kits de exploits muy popular.
La caída de Lurk
Al final, todos los trucos de los cibercriminales no sirvieron. La mayoría de los miembros del grupo fue arrestada. Pero solo después de que el daño estaba hecho: durante su amplia carrera, los atacantes pudieron robar aproximadamente 45 millones de dólares. Nuestros expertos estuvieron estudiando sus métodos durante casi seis años (que, por cierto, proporcionó una valiosa experiencia que seguimos empleando para derrotar al cibercrimen).
Para aquellos interesados en los aprendizajes de esta saga importante para las empresas, recomendamos leer este artículo. Y un análisis técnico detallado está disponible en nuestra publicación de Securelist.