{"id":26921,"date":"2022-02-16T17:18:42","date_gmt":"2022-02-16T15:18:42","guid":{"rendered":"https:\/\/www.kaspersky.es\/blog\/?p=26921"},"modified":"2022-02-16T17:18:42","modified_gmt":"2022-02-16T15:18:42","slug":"lurk-cybercrime-inc","status":"publish","type":"post","link":"https:\/\/www.kaspersky.es\/blog\/lurk-cybercrime-inc\/26921\/","title":{"rendered":"Lurk: una empresa del cibercrimen ejemplar"},"content":{"rendered":"

El juicio contra los creadores del troyano bancario Lurk<\/a> por fin ha llegado a su fin. Fueron detenidos debido a una operaci\u00f3n conjunta sin precedentes entre varias autoridades y la ayuda de nuestros expertos. El arresto tuvo lugar en el 2016; sin embargo, la investigaci\u00f3n y el proceso judicial se han alargado otros cinco a\u00f1os. Pero esto no deber\u00eda sorprendernos, dado que la cantidad de sospechosos y v\u00edctimas involucrados en el caso no ten\u00eda precedente. Incluso tuvieron que transportar a los miembros de Lurk en autob\u00fas y los archivos del caso ocupaban hasta 4000 vol\u00famenes (un volumen = 250 p\u00e1ginas). La cantidad de trabajo era enorme y requer\u00eda mucho tiempo, los sospechosos analizaron todos los registros y declaraciones con lupa, pero en el 2018, 27 acusados fueron llevados a juicio.<\/p>\n

Kaspersky ha estado monitorizando las actividades del grupo desde el 2011. Escuch\u00e9 sobre Lurk por primera vez cuando llegu\u00e9 a la empresa en el 2013 y recuerdo que pens\u00e9: \u201cAtr\u00e1palos y podr\u00e1s retirarte f\u00e1cilmente. Tu carrera estar\u00e1 pr\u00e1cticamente concluida\u201d. En comparaci\u00f3n con los ciberdelincuentes habituales de la \u00e9poca, estos parec\u00edan ser verdaderamente sofisticados, tanto en el aspecto t\u00e9cnico como en el organizativo. Dicho esto, si hoy me encontrara con Lurk, probablemente no estar\u00eda tan impresionado y los ver\u00eda simplemente como un grupo que utiliza las mejores pr\u00e1cticas.<\/p>\n

El veredicto de la corte es una buena excusa para echar la vista atr\u00e1s y analizar los aspectos destacados de su actividad delictiva.<\/p>\n

La estrategia de infecci\u00f3n<\/h2>\n

Debemos iniciar con el vector de infecci\u00f3n. Los atacantes utilizaban la t\u00e1ctica watering-hole<\/a><\/em>, publicando una redirecci\u00f3n a un kit de exploits<\/em> en varios sitios web de medios comerciales. Este m\u00e9todo no era nada nuevo, pero en este caso, para infectarse, la v\u00edctima (siempre un contable) visitaba el sitio durante la hora de la comida (y solo en ese momento). El kit de exploits<\/em> descargaba un troyano sin archivos en su ordenador, que se utilizaba \u00fanicamente para espiar.<\/p>\n

Los ciberdelincuentes primero estudiaban qu\u00e9 programas se ejecutaban en el equipo, ya fuera software<\/em> bancario o cualquier rastro de software<\/em> de investigaci\u00f3n, y en qu\u00e9 subredes trabajaba la m\u00e1quina (el foco principal eran las redes bancarias y gubernamentales). En otras palabras, evaluaban si el ordenador era interesante y sab\u00edan exactamente a qui\u00e9n quer\u00edan atacar.<\/p>\n

El malware<\/em> principal se descargaba solo si el ordenador resultaba de inter\u00e9s. De lo contrario, robaban todas las contrase\u00f1as que pod\u00edan, por si acaso, y eliminaban el malware<\/em> del equipo de la v\u00edctima.<\/p>\n

La comunicaci\u00f3n con mando y control<\/h2>\n

El proceso de intercambio de informaci\u00f3n entre el troyano y el servidor de mando y control<\/a> (C&C por sus siglas en ingl\u00e9s) no era menos notable. La mayor\u00eda de los troyanos de esa \u00e9poca inclu\u00edan la direcci\u00f3n del C&C prefijada en el c\u00f3digo fuente. Los autores simplemente especificaban el nombre de dominio, lo que les permit\u00eda, en caso de que fuera necesario, cambiar la direcci\u00f3n IP del servidor: es decir, si perd\u00edan el control de las direcciones principales del C&C, simplemente pod\u00edan 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\u00e9todo digno de una novela de esp\u00edas.<\/p>\n

Antes de una sesi\u00f3n de comunicaci\u00f3n, Lurk calculaba la direcci\u00f3n del servidor C&C. Los ciberdelincuentes buscaban en Yahoo! el precio de las acciones de una empresa espec\u00edfica (durante nuestra investigaci\u00f3n, era McDonald\u2019s). Dependiendo del valor de la acci\u00f3n en un momento espec\u00edfico, generaban un nombre de dominio y acced\u00edan 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\u00e9 nombre de dominio se utilizar\u00eda para el servidor C&C.<\/p>\n

Esto plantea una pregunta leg\u00edtima: si el algoritmo estaba incrustado en el troyano, \u00bfqu\u00e9 imped\u00eda a un investigador\u00a0generar dicha secuencia, registrar un nombre de dominio antes que los ciberdelincuentes y simplemente esperar a que el troyano se conectara a \u00e9l? Por desgracia, los creadores de Lurk hab\u00edan tomado precauciones.<\/p>\n

Utilizaban el cifrado asim\u00e9trico<\/a>. Es decir, se generaban un par de claves, con lo que el bot<\/em>, al acceder al servidor C&C, utilizaba la clave p\u00fablica para comprobar si realmente pertenec\u00eda 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<\/em> y emitir comandos, ning\u00fan investigador externo puede emular el servidor C&C. El resto de los ciberdelincuentes no utilizaban este m\u00e9todo de protecci\u00f3n, por lo que si detect\u00e1bamos que la clave privada del servidor estaba protegida, pod\u00edamos estar seguros de que se trataba de un ataque de Lurk.<\/p>\n

Una infraestructura organizada<\/h2>\n

La configuraci\u00f3n de los procesos de Lurk merece una menci\u00f3n aparte. Si otros grupos de ciberdelincuentes de la \u00e9poca eran solo unos cuantos usuarios de un foro (uno encargado de la programaci\u00f3n, otro de cobrar y un tercero de coordinar), en contraste, Lurk era casi una empresa inform\u00e1tica hecha y derecha. De hecho, resulta m\u00e1s preciso compararlos con una gran corporaci\u00f3n de software<\/em> que con un grupo cibercriminal. Es m\u00e1s, a nivel organizativo, siguen siendo un modelo para muchos grupos hoy en d\u00eda.<\/p>\n

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\u00edan celebrar reuniones informativas semanales, lo que en aquella \u00e9poca era algo totalmente inaudito. En resumen, era una corporaci\u00f3n maligna ejemplar.<\/p>\n

Incluso contaban con un sistema claramente estructurado, basado en funciones, para restringir el acceso a la informaci\u00f3n. Despu\u00e9s 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.<\/p>\n

Documentaron minuciosamente todas sus actividades, mucho m\u00e1s que muchas empresas inform\u00e1ticas hoy en d\u00eda. Esto, por supuesto, ayud\u00f3 en gran manera a la investigaci\u00f3n. Y, tal vez, fue lo que finalmente caus\u00f3 su ca\u00edda: cuanto m\u00e1s sistem\u00e1tica sea tu estrategia, m\u00e1s f\u00e1cil ser\u00e1 rastrearte. Estos son algunos ejemplos.<\/p>\n

Las bases de conocimiento<\/h3>\n

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\u00edan sobre las actividades del resto. El alcance de los proyectos variaba, desde el punto de vista t\u00e9cnico hasta el organizativo. Y los proyectos t\u00e9cnicos tambi\u00e9n estaban subdivididos en niveles. Por ejemplo, los desarrolladores del troyano ten\u00edan acceso a la base de conocimiento solo en relaci\u00f3n con este tipo de temas: c\u00f3mo evitar los antivirus, c\u00f3mo probar, etc. Pero tambi\u00e9n hab\u00eda bases de datos generales sobre seguridad operativa (similar a las regulaciones de seguridad en empresas grandes). Estas proporcionaban informaci\u00f3n sobre c\u00f3mo los empleados de Lurk deber\u00edan configurar sus estaciones de trabajo para evitar la detecci\u00f3n y c\u00f3mo utilizar las herramientas de anonimato.<\/p>\n

El acceso a la informaci\u00f3n<\/h3>\n

Para obtener acceso a los recursos de informaci\u00f3n de Lurk, los ciberdelincuentes necesitaban conectarse a alg\u00fan servidor mediante varias VPN. Pero, incluso de esta forma, solo recib\u00edan acceso a la administraci\u00f3n de bots<\/em>. Despu\u00e9s, cada empleado obten\u00eda 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\u00f3n en dos pasos, podr\u00edan haber sido considerados una empresa modelo.<\/p>\n

En f\u00edsico, todos los servidores estaban ubicados en distintos centros de datos y pa\u00edses y, cuando llegabas a uno de estos a nivel virtual mediante una VPN, no conoc\u00edas la verdadera direcci\u00f3n IP del servidor. Este fue uno de los motivos principales por los que el grupo resultaba tan dif\u00edcil de detectar.<\/p>\n

El desarrollo<\/h3>\n

El grupo Lurk contaba con repositorios adecuados de c\u00f3digo fuente, desarrollo automatizado y procedimientos de pruebas de varios pasos, un servidor de producci\u00f3n, un servidor de prueba y un servidor de desarrollo. En esencia, estaban haciendo un producto de software<\/em> serio: en todo momento contaban con una versi\u00f3n de producci\u00f3n, una de prueba y con los desarrolladores del troyano.<\/p>\n

El servidor C&C promedio de un troyano t\u00edpico entonces pod\u00eda recibir solicitudes de bots<\/em>, registrarlas en una base de datos y proporcionar un panel de administraci\u00f3n para gestionarlas. Todo esto se implementaba de manera efectiva en una sola p\u00e1gina. Lurk implement\u00f3 el panel de administraci\u00f3n y la base de datos por separado, mientras que el mecanismo para enviar respuestas a los bots<\/em> se ocult\u00f3 por completo mediante un servicio intermediario.<\/p>\n

Los paquetes de exploits<\/em><\/h3>\n

Lurk ten\u00eda tres paquetes de exploits<\/em>, 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\u00eda es que no solo los autores de Lurk utilizaban sus propios desarrollos, sino que tambi\u00e9n vend\u00edan paquetes de exploits<\/em> a otros ciberdelincuentes. Es m\u00e1s, las versiones para los \u201csocios\u201d ten\u00edan un c\u00f3digo distinto, lo que era un intento claro de disfrazarlos como otros paquetes de exploits<\/em> populares.<\/p>\n

La ca\u00edda de Lurk<\/h2>\n

Al final, no sirvieron todos los trucos de los ciberdelincuentes y la mayor\u00eda de los miembros del grupo fue arrestada. Pero esto sucedi\u00f3 despu\u00e9s de que el da\u00f1o ya estuviera hecho: durante su amplia carrera, los atacantes robaron aproximadamente 45 millones de d\u00f3lares. Nuestros expertos estudiaron sus m\u00e9todos durante casi seis a\u00f1os (lo cual, por cierto, proporcion\u00f3 una valiosa experiencia que seguimos utilizando para luchar contra la ciberdelincuencia).<\/p>\n

Si est\u00e1s interesado en conocer todas las conclusiones comerciales relevantes de esta saga, te recomendamos leer este art\u00edculo<\/a>. Tambi\u00e9n encontrar\u00e1s un an\u00e1lisis t\u00e9cnico detallado en nuestra publicaci\u00f3n de Securelist<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"

Qu\u00e9 es lo que m\u00e1s recuerdan los investigadores sobre el grupo Lurk. <\/p>\n","protected":false},"author":2701,"featured_media":26923,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2202,2754,2755],"tags":[3402,1025,473,676],"class_list":{"0":"post-26921","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"category-smb","10":"tag-amenazas-bancarias","11":"tag-investigacion","12":"tag-justicia","13":"tag-troyano-bancario"},"hreflang":[{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/lurk-cybercrime-inc\/26921\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/lurk-cybercrime-inc\/23908\/"},{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/lurk-cybercrime-inc\/19394\/"},{"hreflang":"ar","url":"https:\/\/me.kaspersky.com\/blog\/lurk-cybercrime-inc\/9752\/"},{"hreflang":"en-us","url":"https:\/\/usa.kaspersky.com\/blog\/lurk-cybercrime-inc\/26146\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/lurk-cybercrime-inc\/24107\/"},{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/lurk-cybercrime-inc\/23917\/"},{"hreflang":"it","url":"https:\/\/www.kaspersky.it\/blog\/lurk-cybercrime-inc\/26465\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/lurk-cybercrime-inc\/32377\/"},{"hreflang":"tr","url":"https:\/\/www.kaspersky.com.tr\/blog\/lurk-cybercrime-inc\/10523\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/lurk-cybercrime-inc\/43683\/"},{"hreflang":"fr","url":"https:\/\/www.kaspersky.fr\/blog\/lurk-cybercrime-inc\/18559\/"},{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/lurk-cybercrime-inc\/19008\/"},{"hreflang":"pl","url":"https:\/\/plblog.kaspersky.com\/lurk-cybercrime-inc\/15804\/"},{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/lurk-cybercrime-inc\/28161\/"},{"hreflang":"ja","url":"https:\/\/blog.kaspersky.co.jp\/lurk-cybercrime-inc\/32446\/"},{"hreflang":"nl","url":"https:\/\/www.kaspersky.nl\/blog\/lurk-cybercrime-inc\/28118\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/lurk-cybercrime-inc\/24829\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/lurk-cybercrime-inc\/30251\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/lurk-cybercrime-inc\/30030\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.es\/blog\/tag\/amenazas-bancarias\/","name":"amenazas bancarias"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/posts\/26921","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/users\/2701"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/comments?post=26921"}],"version-history":[{"count":6,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/posts\/26921\/revisions"}],"predecessor-version":[{"id":26928,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/posts\/26921\/revisions\/26928"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/media\/26923"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/media?parent=26921"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/categories?post=26921"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/tags?post=26921"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}