Parchada hace dos años, la vulnerabilidad Log4Shell sigue siendo un vector de ataque popular, incluso para los atacantes. Esto se evidencia en una campaña recientemente documentada contra empresas de múltiples industrias por parte del grupo estatal norcoreano APT Lazarus. Los ciberdelincuentes explotaron la falla de Log4Shell a la que se hace referencia CVE-2021-44228 en Servidores VMware Horizon públicos y sin parchesy utilizó su acceso para implementar troyanos de acceso remoto (RAT) personalizados escritos en DLang, un lenguaje de programación rara vez utilizado en el desarrollo de malware. Bautizado Operación Blacksmith por investigadores de Cisco TalosEsta campaña, que parece haber comenzado en marzo, continúa hasta el día de hoy. Es probable que los ataques sean más oportunistas que dirigidos, y las víctimas registradas se encuentran en los sectores manufacturero, agrícola y de seguridad física.
Apoyadas por el Gobierno norcoreano, las ofensivas llevadas a cabo por los equipos de hackers del Grupo Lazarus (APT38) tienen generalmente como objetivo el ciberespionaje y el sabotaje. Las actividades maliciosas del grupo se remontan a varios años y comparte algunas de sus herramientas e infraestructura con otros grupos APT de Corea del Norte. De hecho, los investigadores de Talos creen que lo más probable es que Lazarus esté formado por diferentes subgrupos que llevan a cabo sus propias acciones y desarrollan malware a medida para sus objetivos. Estos subgrupos pueden tener objetivos diferentes y no siempre se coordinan entre sí, a pesar de superposiciones ocasionales. “Durante su análisis, Talos encontró cierta superposición con ataques maliciosos revelados por Microsoft en octubre de 2023, atribuyendo la actividad a Onyx Sleet, también conocido como PLUTONIUM o Andariel”, dijeron los investigadores de Talos en su informe sobre la Operación Blacksmith. La campaña Andariel documentada por Microsoft aprovechó la falla referenciada CVE-2023-42793, una vulnerabilidad crítica que afecta al servidor JetBrains TeamCity, una herramienta CI/CD utilizada en DevOps. Lo común en la Operación Blacksmith de Lazarus es el uso de una herramienta proxy personalizada llamada HazyLoad, que solo se vio en estas dos campañas.
Una salida creada por los ciberhackers
Sin embargo, otros implantes de malware fueron diferentes. En Blacksmith, los atacantes implementaron tres programas maliciosos diferentes escritos en DLang, un lenguaje de programación lanzado originalmente en 2001 inspirado en C++, pero enriquecido con muchas características y paradigmas tomados de otros lenguajes. DLang es una opción inusual para el desarrollo de malware, pero Lazarus es conocido por utilizar tecnologías no tradicionales, como fue el caso anteriormente con QtFramework y PowerBasic. Uno de los implantes basados en DLang implementados durante la fase posterior a la explotación se llama NineRAT. Este troyano de acceso remoto utiliza Telegram como canal de comando y control (C2). "Cuando se activa NineRAT, el malware se convierte en el principal medio de interacción con el host infectado", explicaron los investigadores de Talos. “Sin embargo, los mecanismos de puerta trasera implementados anteriormente, incluida la herramienta de proxy inverso HazyLoad, siguen vigentes. Las múltiples herramientas proporcionan al Grupo Lazarus entradas de puerta trasera superpuestas, con redundancias en caso de que se descubra una herramienta, lo que permite un acceso altamente persistente”, agregaron.
Utilizando las muestras de NineRAT como referencia, los investigadores de Talos lograron localizar otros dos implantes basados en un código similar. El primero es un descargador también escrito en DLang al que los investigadores llamaron BottomLoader. Su propósito es descargar una carga útil adicional desde una URL codificada mediante un comando de PowerShell. El segundo implante, más sofisticado, es a la vez un descargador de carga útil y un troyano de acceso remoto, llamado DLRAT. A diferencia de NineRAT, DLRAT no utiliza Telegram como canal de comando y control (C2), sino que envía información sobre el host infectado a través de HTTP a un servidor web C2. A cambio, los atacantes pueden pedirle que cargue archivos locales en el servidor, cambie el nombre de los archivos y descargue cargas útiles adicionales. "Los actores de amenazas también crearon una cuenta de usuario adicional en el sistema, otorgándole privilegios administrativos", dijeron los investigadores. “Talos había documentado estas tácticas, técnicas y procedimientos (TTP) a principios de este año, pero la actividad observada anteriormente tenía como objetivo la creación de cuentas de usuario no autorizadas a nivel de dominio. En esta campaña, los operadores crearon una cuenta local, que corresponde a la cuenta de usuario documentada por Microsoft: krtbgt.
Log4j, una bendición para los hackers
La falla de Log4Shell, reportada por primera vez el 9 de diciembre de 2021, se encuentra en una biblioteca Java muy popular llamada Log4j. Debido al uso generalizado de esta biblioteca, la vulnerabilidad afectó a millones de aplicaciones Java, tanto aplicaciones desarrolladas internamente por empresas como productos comerciales ofrecidos por muchos desarrolladores de software. Los parches estuvieron disponibles para Log4j a los pocos días de anunciarse la vulnerabilidad, pero todos los proveedores afectados tardaron meses en lanzar parches y las empresas actualizaron sus aplicaciones internas. A pesar de la amplia publicidad en torno a esta falla, parece que, dos años después, una cantidad suficientemente grande de sistemas todavía son vulnerables para que grupos como Lazarus continúen usando el exploit. De acuerdo a Según la empresa de gestión de la cadena de suministro de software Sonatype, que también gestiona el repositorio central de componentes Java, más del 20% de las descargas de Log4j todavía implican versiones vulnerables.
La empresa de seguridad de aplicaciones Veracode informa que, según sus propios datos de telemetría, sólo el 2,8% de las aplicaciones probadas todavía utilizan versiones de Log4j con vulnerabilidades de Log4Shell. Sin embargo, otro 3,8% usa una versión de Log4j 2.x vulnerable a otro problema de alta gravedad al que se hace referencia CVE-2021-44832 y un tercio de todas las aplicaciones que incluyen Log4j continúan usando la serie 1.x anterior de la biblioteca que ha alcanzado su punto máximo. fin de vida y no ha recibido parches de seguridad durante mucho tiempo. Aunque Log4j 1.x no se ve afectado por la falla de Log4Shell, actualmente tiene otras siete vulnerabilidades importantes y críticas que no han sido reparadas. "Nuestra investigación también demostró que cuando los desarrolladores son alertados por un escaneo de vulnerabilidades de la biblioteca, lo parchean relativamente rápido: el 50% de las vulnerabilidades se reparan en 89 días en total, 65 días para vulnerabilidades de alta gravedad y en 107 días para vulnerabilidades de gravedad media", dijo Chris Eng, jefe de investigación de Veracode, en una publicación de blog. "Esto contradice los datos de Log4j anteriores, que muestran que la corrección no es rápida para esta biblioteca de código abierto, especialmente para Log4j 1.2.x", añadió.
Otras noticias que te pueden interesar