🔒
Hay nuevos artículos disponibles. Pincha para refrescar la página.
✇LibreRed

Trump elige a un ejecutivo de Palantir para dirigir la ciberseguridad de EE.UU.

Por: E. Berraondo

El presidente de Estados Unidos, Donald Trump, ha seleccionado a Shyam Sankar, director de tecnología de Palantir Technologies, como principal candidato para dirigir la Agencia de Seguridad de Infraestructura y Ciberseguridad (CISA), según fuentes anónimas citadas por Recorded Future News. La designación pondría fin a un largo periodo sin director permanente en el organismo, encargado de proteger las infraestructuras críticas del país.

Un perfil polémico para un cargo clave

Sankar, ejecutivo de una empresa conocida por sus contratos de análisis de datos con agencias de inteligencia y defensa, representa la creciente influencia del sector privado en la seguridad nacional estadounidense. La Casa Blanca no ha confirmado oficialmente el nombramiento, pero las fuentes señalaron que la decisión está próxima.

La posible llegada de un cargo vinculado a Palantir —empresa cofundada por Peter Thiel, estrechamente alineada con el trumpismo— podría cambiar la orientación de CISA hacia enfoques comerciales y tecnológicos específicos, según analistas consultados. La agencia ha operado con directores interinos desde la salida de Jen Easterly en 2024.

La elección de un ejecutivo de Palantir refleja la apuesta de Trump por estrechar lazos entre el sector tecnológico y la seguridad nacional, en línea con su agenda de desregulación y privatización de servicios públicos.

El Senado deberá confirmar el nombramiento, donde se espera un debate sobre posibles conflictos de interés. Palantir ha sido criticada por su papel en programas de vigilancia masiva y por sus vínculos con agencias federales como el Pentágono y la CIA.

✇LibreRed

Una brecha de seguridad en la ONU expone los datos de los beneficiarios de ayuda en Gaza

Por: P. Llopart

El Programa Mundial de Alimentos (WFP) de la ONU ha abierto una investigación tras detectar un acceso no autorizado a los datos de los receptores de ayuda humanitaria en Gaza. El incidente, que afecta a información sensible almacenada en su aplicación de autorregistro, fue comunicado a los damnificados a través de Telegram durante el pasado fin de semana, según confirmó la agencia.

Riesgos para la seguridad de los afectados

En el mensaje remitido a los beneficiarios, el WFP advirtió de que «partes no autorizadas» habían accedido a los datos alojados en la plataforma de registro. Aunque la organización no ha precisado el número de afectados ni el volumen de información expuesta, la filtración en una zona de conflicto activo como Gaza podría tener consecuencias graves para la seguridad de los damnificados, expuestos a posibles represalias o estigmatización.

El organismo de la ONU ha indicado que colabora con las autoridades competentes para esclarecer el alcance de la brecha y reforzar las medidas de ciberseguridad. La investigación se centra en determinar cómo se produjo el acceso indebido y si los datos filtrados han sido utilizados de forma malintencionada.

Contexto de vulnerabilidad

El suceso se enmarca en el contexto del conflicto entre Israel y Hamás, que ha agravado la crisis humanitaria en la Franja. La ONU canaliza a través del WFP una parte significativa de la asistencia alimentaria a la población gazatí, que depende en gran medida de la ayuda internacional. La exposición de datos personales de los receptores —que pueden incluir nombres, ubicaciones y detalles de contacto— añade un factor de riesgo adicional en un entorno ya de por sí vulnerable.

La agencia de la ONU no ha facilitado un plazo para la conclusión de las pesquisas, pero asegura que tomará «todas las medidas necesarias» para evitar que incidentes similares se repitan y para proteger la privacidad de las personas asistidas.

✇LibreRed

Microsoft, en el punto de mira: un investigador publica exploit funcional que roba tokens de GitHub

Por: I. Lasagabaster

El investigador de seguridad Ammar Askar publicó el pasado 4 de junio un exploit de prueba de concepto capaz de robar tokens de acceso de GitHub, en un movimiento que ha generado controversia en la comunidad de ciberseguridad. Askar justificó la publicación alegando deficiencias en el proceso de divulgación de vulnerabilidades de Microsoft, propietaria de la plataforma de desarrollo.

El exploit fue divulgado en el blog personal de Askar y en el sistema público de seguimiento de incidencias de Visual Studio Code. Según el investigador, apenas notificó al equipo de seguridad de GitHub con una hora de antelación antes de hacer público el código, un plazo que consideró insuficiente para que la compañía pudiera reaccionar.

Críticas al proceso de Microsoft

En su publicación, Askar señaló que la empresa no habría gestionado adecuadamente las comunicaciones previas sobre la vulnerabilidad, lo que motivó la decisión de liberar el código de forma unilateral. Este tipo de acciones, conocidas como divulgación completa (full disclosure), son habituales en el ámbito de la seguridad cuando un investigador considera que el fabricante no actúa con la debida celeridad.

El exploit, aunque de prueba de concepto, es funcional y podría ser utilizado por terceros con fines maliciosos. La filtración de tokens de GitHub permite a un atacante acceder a repositorios privados, modificar código o incluso suplantar la identidad del desarrollador en integraciones continuas.

Por el momento, Microsoft no ha emitido un comunicado oficial sobre la publicación del exploit ni sobre las acusaciones de Askar. La empresa mantiene un programa de recompensas por errores (bug bounty) que, según detractores, a menudo prioriza plazos largos de parcheado frente a la urgencia de la divulgación.

✇LibreRed

CISA emitirá directiva obligatoria para gestionar vulnerabilidades de IA en infraestructuras críticas de EE.UU.

Por: E. Berraondo

La Agencia de Seguridad de Infraestructuras y Ciberseguridad de Estados Unidos (CISA) publicará a lo largo de esta semana una directiva operativa vinculante en el marco de la orden ejecutiva sobre inteligencia artificial firmada por la Casa Blanca. Así lo ha anunciado un funcionario de la agencia durante un evento público celebrado este jueves.

Eric Andersen, alto cargo de CISA, declaró en la conferencia TechNet Cyber celebrada en Baltimore que la directiva se centrará en el alivio y la gestión de vulnerabilidades en sistemas de inteligencia artificial aplicados a infraestructuras críticas. “La directiva abordará tanto el alivio de vulnerabilidades como la gestión de vulnerabilidades”, afirmó Andersen, sin precisar la fecha exacta de publicación dentro de la semana.

La directiva operativa vinculante forma parte de la implementación de la orden ejecutiva sobre inteligencia artificial que la administración Biden promulgó a finales de 2023. Esta orden establece requisitos de seguridad, transparencia y rendición de cuentas para los sistemas de IA utilizados en sectores sensibles. CISA, dirigida por Jen Easterly, tiene la responsabilidad de desarrollar normas específicas para garantizar que los sistemas de IA desplegados en infraestructuras críticas —como redes eléctricas, sistemas de agua o servicios financieros— cumplan con los estándares de ciberseguridad.

La noticia se produce en un contexto de creciente atención regulatoria hacia la inteligencia artificial. Varias agencias federales estadounidenses están desarrollando normativas sectoriales para mitigar los riesgos asociados a esta tecnología, especialmente en lo relativo a ciberseguridad y protección de datos.

✇LibreRed

CISA sufre un duro revés: la administración propone recortar cientos de puestos en su lucha contra la desinformación

Por: R. Tordesillas

El jefe del Departamento de Seguridad Nacional de Estados Unidos (DHS), Todd Mullin, ha señalado que la Agencia de Ciberseguridad e Infraestructuras (CISA) necesita «alrededor de» 2.800 empleados, una cifra inferior al límite actual de contratación de 3.400. La declaración se produjo el 3 de junio de 2026 durante su primera comparecencia ante el comité parlamentario desde que fue confirmado en el cargo en marzo.

Un giro en la misión de CISA

Mullin explicó que el DHS está trabajando para redimensionar y reorientar la misión de la agencia, alineándola con las prioridades políticas de la administración. Aunque no detalló los recortes exactos respecto a la plantilla actual, la cifra de 2.800 sugiere una reducción significativa respecto a la capacidad máxima autorizada por el Congreso.

La reestructuración de CISA ha sido un tema recurrente en el debate político en Washington. Algunos legisladores republicanos han criticado a la agencia por su enfoque en la lucha contra la desinformación, que consideran una extralimitación de su mandato original centrado en la ciberseguridad de infraestructuras críticas.

Implicaciones para la seguridad nacional

La posible reducción de personal ha suscitado preocupación entre los expertos en ciberseguridad, que advierten de que EE.UU. se enfrenta a amenazas crecientes por parte de actores estatales como China y Rusia. La CISA, creada en 2018, ha desempeñado un papel clave en la protección de redes gubernamentales y en la coordinación con el sector privado.

Según declaró Mullin ante el panel, los cambios buscan «modernizar y agilizar» la agencia, aunque no ofreció un calendario concreto para la reestructuración. El DHS deberá ahora presentar un plan detallado al Congreso, que tiene la última palabra sobre la financiación y el tamaño de la plantilla de CISA.

✇LibreRed

Trump firma una orden que pone condiciones de ciberseguridad al acceso federal a la IA sin imponer sanciones

Por: P. Llopart

El Gobierno de Estados Unidos ha publicado este martes una orden ejecutiva sobre inteligencia artificial que, aunque más limitada que los borradores previos, establece condiciones de ciberseguridad, confidencialidad y riesgo de insider para el acceso federal a los modelos de IA. La medida, firmada por el presidente Donald Trump, busca reforzar la protección de las infraestructuras críticas frente a posibles amenazas vinculadas al uso de estas tecnologías.

Condiciones para el acceso federal

La orden señala que el acceso de las agencias federales a los modelos de IA debe estar sujeto a “apropiada confidencialidad, ciberseguridad, riesgo de insider y protección de la propiedad intelectual”, según el texto difundido por la Casa Blanca. Aunque la orden no especifica sanciones ni plazos concretos, establece un marco regulatorio que afecta a todos los departamentos y agencias que contraten o utilicen sistemas de inteligencia artificial.

El acceso federal a los modelos debe estar sujeto a “apropiada confidencialidad, ciberseguridad, riesgo de insider y propiedad intelectual”.

La medida se enmarca en la estrategia del Ejecutivo estadounidense por equilibrar el impulso a la innovación en inteligencia artificial con la salvaguarda de la seguridad nacional. A diferencia de órdenes anteriores, esta versión ha sido descrita por fuentes oficiales como “más acotada”, centrada exclusivamente en los riesgos asociados al uso gubernamental de estas herramientas, sin abordar aspectos más amplios como la regulación del sector privado.

Reacciones y contexto

La orden ejecutiva llega en un momento de creciente debate en Washington sobre los riesgos de la inteligencia artificial, especialmente tras incidentes de filtración de datos y uso indebido de modelos generativos. El Gobierno ha insistido en que la iniciativa busca “proteger la información sensible” sin frenar el desarrollo tecnológico. Organizaciones de ciberseguridad han valorado positivamente el enfoque en el riesgo de insider, aunque advierten que la aplicación efectiva dependerá de los recursos asignados a las agencias para implementar los controles.

✇LibreRed

Android 12+ recibe señal secreta antiscam: Google verifica llamadas bancarias para frenar suplantaciones

Por: S. Marimón

Google ha comenzado a desplegar una nueva funcionalidad antiscam integrada en su aplicación Google Dialer que permite verificar la identidad del llamante mediante una señal de confirmación silenciosa. La función, disponible desde el 2 de junio de 2026, se activa sin intervención del usuario cuando recibe una llamada sospechosa.

La herramienta está orientada a combatir el creciente número de estafas telefónicas, especialmente aquellas en las que los ciberdelincuentes suplantan la identidad de entidades bancarias, organismos públicos o empresas conocidas. Según ha informado la compañía, la señal de confirmación se envía en segundo plano durante la comunicación, permitiendo al sistema validar que el número que llama corresponde realmente a la entidad que dice ser.

La función está disponible para todos los dispositivos con Android 12 y versiones posteriores, lo que cubre a la inmensa mayoría de los teléfonos Android actuales. No requiere configuración adicional ni activación manual: Google Dialer detecta automáticamente las llamadas entrantes y aplica el protocolo de verificación cuando es necesario.

La compañía no ha detallado el sistema criptográfico concreto que utiliza la señal de confirmación, pero fuentes de la división de seguridad de Google han confirmado que la verificación se realiza en tiempo real y que la información no se almacena en los servidores de la empresa, un gesto que busca apaciguar las preocupaciones sobre la privacidad de los usuarios.

La medida llega en un momento en que las estafas telefónicas se han convertido en un problema de seguridad cotidiano en todo el mundo, con pérdidas estimadas en miles de millones de dólares anuales. Con esta actualización, Google pretende ofrecer una capa adicional de protección sin sacrificar la experiencia del usuario.

✇LibreRed

Ciberdelincuentes secuestran cuentas de Instagram engañando a la IA de Meta

Por: R. Tordesillas

La inteligencia artificial de Meta que atiende las solicitudes de soporte al cliente ha sido utilizada por ciberdelincuentes para secuestrar cuentas de Instagram. En un video difundido en Telegram, un hacker muestra cómo lograba cambiar la dirección de correo electrónico asociada a un perfil ajeno —y, posteriormente, restablecer la contraseña— simplemente dialogando con el chatbot de la compañía.

El ataque explota una vulnerabilidad en la integración de la IA en los servicios de asistencia de Meta. Al solicitar a la máquina el cambio del email de un usuario, los atacantes eludían los mecanismos de verificación tradicionales. Una vez modificado el correo, el restablecimiento de la contraseña quedaba en manos del delincuente, que podía tomar el control total de la cuenta.

Meta ha confirmado que ya ha corregido la brecha, aunque no ha precisado cuántas cuentas se vieron afectadas. La compañía atribuyó el incidente a un error de configuración que permitía al chatbot procesar peticiones que deberían haber requerido una validación adicional. En un comunicado, la empresa aseguró que ha implementado medidas para evitar que la situación se repita.

El caso pone de relieve los riesgos de delegar funciones críticas de seguridad en sistemas automatizados. La explotación de la IA de Meta para secuestrar cuentas ilustra la fragilidad de la ciberinfraestructura en plataformas masivas y abre interrogantes sobre la gobernanza de la inteligencia artificial en entornos comerciales. Según fuentes cercanas a la investigación, los atacantes actuaron durante varias semanas antes de que la vulnerabilidad fuera detectada.

✇LibreRed

El colapso de la ciberseguridad global: el NIST deja 27.000 vulnerabilidades sin procesar

Por: P. Llopart

El inspector general del Departamento de Comercio de Estados Unidos ha determinado que errores de gestión en el Instituto Nacional de Estándares y Tecnología (NIST) han dejado ineficaz la Base de Datos Nacional de Vulnerabilidades (NVD), un repositorio global clave para la ciberseguridad. El informe, publicado en junio de 2026, revela que el backlog de vulnerabilidades sin procesar se ha duplicado, pasando de 13.000 a más de 27.000 entre febrero de 2024 y finales de 2025.

La NVD, gestionada por el NIST, es la fuente primaria para que empresas, gobiernos y organismos de todo el mundo prioricen los parches de seguridad informática. Su retraso en la catalogación de vulnerabilidades conocidas como CVE (Common Vulnerabilities and Exposures) amplía la ventana de exposición a ataques, según advierte el informe de la oficina del inspector general.

El organismo califica la situación como una «undermining of public trust» (pérdida de confianza pública), ya que la acumulación de 27.000 vulnerabilidades sin procesar deja sin cobertura a miles de sistemas críticos que dependen de los datos actualizados de la NVD para aplicar parches de forma eficaz. El colapso, atribuido a fallos de gestión internos del NIST, comenzó a gestarse en febrero de 2024 y se ha acelerado desde entonces, según el informe.

El documento no ofrece detalles sobre posibles sanciones o planes de recuperación, pero subraya que la falta de resolución del backlog ha convertido a la NVD en un repositorio cada vez menos fiable. La situación afecta a la ciberseguridad global, ya que la base de datos es utilizada por defensores y atacantes por igual para identificar vulnerabilidades explotables.

✇LibreRed

Investigador publica múltiples zero-days de Microsoft en GitHub y amenaza con más filtraciones

Por: E. Berraondo

Un investigador de seguridad no identificado ha publicado múltiples vulnerabilidades zero-day de Microsoft en la plataforma GitHub, propiedad de la propia compañía, acompañadas de código de prueba de concepto (PoC) funcional. La filtración, ocurrida el 29 de mayo, expone los fallos a atacantes y profesionales de la seguridad por igual, lo que ha provocado una dura reacción de Microsoft.

Según confirmó la empresa en un comunicado, el investigador ha amenazado con divulgar más vulnerabilidades sin parche. Microsoft calificó las publicaciones como «nunca justificables», argumentando que ponen en riesgo a los usuarios al facilitar ataques antes de que exista una solución oficial.

La acción del investigador se enmarca en el debate sobre las políticas de divulgación de vulnerabilidades. Al publicar el código en GitHub, el autor busca forzar a Microsoft a acelerar la publicación de parches, pero la compañía sostiene que este tipo de prácticas solo incrementan la ventana de exposición para los ciberdelincuentes.

Por el momento, Microsoft no ha detallado el número exacto de vulnerabilidades publicadas ni los productos afectados, aunque fuentes internas citadas por la prensa especializada señalan que podrían afectar a múltiples versiones del sistema operativo Windows y de la suite Office. Se recomienda a los administradores de sistemas revisar las alertas de seguridad y aplicar las mitigaciones disponibles hasta que se liberen los parches oficiales.

Este incidente reabre el debate sobre si la publicación de exploits sin parche es una herramienta legítima de presión o una irresponsabilidad que pone en peligro a millones de usuarios. Mientras tanto, la comunidad de ciberseguridad sigue de cerca la evolución del caso.

✇Elbinario

Aventuras con una honeypot custom de Linux: Perl y Botnets

Por: Terceranexus6

Hace un tiempo cree una honeypot para imitar un dispositivo de IoT con un OS de GNU Linux. La idea era investigar por mi cuenta y por diversión los ataques dirigidos a Linux, puesto que tiene tangencialmente que ver con mi trabajo pero quería hacerlo a mi manera. Los detalles técnicos de cómo la he montado están en este repositorio, pero el resumen es que he copiado el filesystem de OpenWRT con docker, lo he integrado en mi honeypot y he añadido detalles que sabía que solían formar parte del interés de un atacante en estos casos (documentos de configuración, claves SSH, librerias concretas, etc). Pero esta entrada no va de eso, va de una de las campañas que he investigado.

Cuando tienes una de estas honeypot, es posible que recibas muchos ataques, desde diferentes sitios, la mayoría automáticos. En mi caso me dedique a revisar tranquilamente los logs de la honeypot para ver qué había sucedido, por lo general hay algunos detalels que suelen llamar mi atención, para empezar las lineas de comando. La honeypot guarda cualquier comando que se haya intentado ejecutar, de modo que se puede comprobar con un simple grep CMD a través de los logs qué días se han detectado comandos y por parte de qué sesión, cuándo y desde qué dirección IP. Las direcciones IP por si solas dicen más bien poco y no son fiables a largo tiempo como método de detección, pero pueden ayudar a identificar un mismo ataque en un periodo corto de tiempo en una misma máquina. En mi caso cuando estuve revisando líneas de comando descubrí un comando que formaba parte de un ataque automático que resultaba interesante. El ataque descargaba y ejecutaba en segundo plano un script de perl, que tras analizarlo es para un DdoS muy característico, porque utiliza una botnet basada en IRC. Como hay muchos palabros hasta ahora, voy a hacer un inciso para explicar conceptos, puedes saltártelo si ya los conoces:

  • DDoS es literalmente “distributed denial-of-service” que es un tipo de ataque relativamente fácil d eprevenir, antiguo en términos de internet, pero que sigue existiendo. Se basa en usar tantas peticiones por unidades pequeñas de tiempo que provoque una sobrecarga de recursos de un servicio. Hemos visto ese ataque, por ejemplo, contra el salto.
  • Perl es un lenguaje de programación que suele venir por defecto configurado en los sistemas basados en unix. Interpretado, dinámico y flexible, suele ser utilizado para “one liners” es decir, comandos de una sola línea que hacen cosas útiles y eficientes. Perl6 pasó a llamarse Raku y es un lenguaje diferente.
  • Script es un programa pequeño normalmente con una función muy específica. En Linux es habitual usar lenguaje Perl o Bash para esto, pero también puede usarse Python y otros.
  • Botnet es una colección de dispositivos normalmente secuestrados que forman parte de una red activa o dormida para realizar a taques como el de DDoS. Los atacantes lo usan mucho para esconder sus huellas.
  • IRC, literalmente Internet Relay Chat es un sistema de mensajería bastante antiguo (se creó en 1988). Sin embargo se ha reutilizado para hacer un sistema que utiliza una Botnet para mandar comandos maliciosos y realizar ataques de denegación de servicio, entre otras cosas.

Pues bien, existe una de esas Botnet basada en IRC que está hecha en perl, y es característica de un grupo en particular: Outlaw. Los investigadores ponen nombres mega chulos a todos los atacantes, por algún motivo, no preguntéis. Tenía claro que lo que estaba viendo era un ataque automático de outlaw, pero no estaba segura cuántas de las cosas sospechosas de mi honeypot eran de la misma campaña. Outlaw ya atacó a diversos dispositivos de IoT y Linux hace unos años y a mediados de este año volvieron a llamar la atención, así que cuadraba que estuvieran de nuevo al ataque. Me interesaba averiguar si habían cambiado algo, si había algo nuevo.

Me llama la atención los users por defecto del script. No los pondré públicos por si son diferentes para cada grupo de víctimas, pero son bastante particulares. Si diré que la IP no está en virustotal. También os diré que el que lo ha configurado es un tío. ¿Que como lo se? No diré el nombré del canal que usan porque he visto que cada campaña cambia, pero tiene que ver con penes.

Que obsesión.

Y bueno, una confirmación de que es Outlaw, se les conoce como un grupo de habla rumana. Es más en otra versión del script que no es la que tengo dicen “La educación es como una erección, si la tienes, la ves”, en rumano. Puede ser cierto o una especie de carta para confundir, a mi me da igual, no me dedico a rastrear quiénes son en la vida real, sólo cómo hacen lo que hacen.

En el código puedo ver que utiliza recursos externos para intentar una vulnerabilidad de MD5 collision, con la intención de romper y descifrar hashes, es otra cosa que me llamó la atención. Es parte de los comandos que pueden usarse en la Botnet.

Otro de los ataques automáticos implicaba el uso de una sintaxis propia de perl. Sin embargo las IPs y los días no coincidían. Esto no quiere decir nada por si solo porque hay campañas con días de distancia entre un paso y el siguiente, además de que el uso de una Botnet complica el seguimiento por Ips. Estaba casi segura de que tenía relación pero necesitaba buscar algo más. Después de darle unas vueltas, caí en la cuenta de que los intentos de fuerza bruta contra la honeypot (había intentos de conexión con varias credenciales) parecían hechos con algún tipo de programa de shuffle con una lista de palabras. Me di cuenta de que algunas eran muy específicas, probablemente hechas con un generador automático, y no encontré esas listas en ningún lado (repositorios, pastebin, foros…) de modo que se me ocurrió que podía buscar coincidencias de credenciales especialmente particulares entre las de las sesiones que tenían que ver con el ataque sospechoso. Efectivamente, aunque las Ips variaban, las credenciales particulares se repetían (no exactamente iguales, pero si con combinaciones similares) en las sesiones del ataque sospechoso por una sintaxis de Perl.

Una vez hecha esa relación, la red del ataque era más amplia, y seguí investigando. A través de comandos usados en esas mismas sesiones o por esas mismas Ips, llegué a la conclusión de que estaban intentando explotar CVE-2017-9841, una vulnerabilidad de Linux que tuvo un impacto importante en su momento y sigue sin estar del todo parcheado en muchos contextos. Pero, si eso fuese así, para confirmarlo (siempre procuro confirmar una teoría con al menos dos pruebas) tendría que ver evidencias de que se ha intentado usar una shell en PHP, puesto que es la entrada más común de esa vulnerabilidad. Miré los detalles de red de las conexiones y vi como se intentaba hacer llamadas que implicaban shells de PHP de manual: ¡confirmado! Otro inciso técnico:

  • PHP es un lenguaje de scripting especialmente pensado para uso en aplicaciones y páginas web. Personalmente lo odio con todas mis fuerzas. No sólo incita a ser desordenado (puedes añadirlo por ejemplo a cachos en cualquier html) si no que suele ser el origen de múltiples vulnerabilidades. Pero gustos colores, que dicen.
  • Una shell es una terminal, desde la cual ejecutar comandos. Hay ataques (al que me refiero) que implican forzar al usuario sin saberlo a interactuar con una web para provocar las condiciones de una vulnerabilidad. Cuando se accede a una terminal, puedes intentar realizar ataques contra base de datos, servicios, etc.

Hasta aquí había conseguido: el script original del ataque, el conocimiento de que Outlaw estaba usando MAYDAY (el tipo de malware que aprovecha la vulnerabilidad mencionada, o al menos uno muy similar a ese) y más adelante un intento de sobrescribir claves ssh (¿recordáis lo que os dije de que las claves ssh tienen interés? Con frecuencia es para intentar extender el ataque a las claves ssh conocidas por la máquina afectada, pero en general dan credibilidad a un sistema de mentirijilla). Al investigar los ataques, también utilizaban binarios maliciosos, que se han guardado en mis logs, y he podido comprobar que coinciden con XMRig, usado como criptominero (y el objetivo de mi búsqueda, el por qué del filesystem que elegí para la honeypot). XMRig en si es un minero legítimo, pero se usa forzadamente en máquinas, en forma de malware, para aprovechar recursos para minar crypto (este es, con diferencia, el ataque más visto en Linux). Así que en conclusión en esta campaña:

  • He visto que siguen usando el Botnet IRC de Perl
  • He visto que usan XMRig (algo que ya usaban)
  • Aprovechan CVE-2017-9841, en forma del malware MAYDAY
  • Utilizan algún sistema para fuerza bruta con una lista personalizada, probablemente generada automáticamente con patrones que mezclen listas de contraseñas por defecto en sistemas y apps y contraseñas posibles.
  • En una versión más avanzada, procuran sobrescribir ssh, esta parte tiene relación con XMRig.

En realidad todo está basado en análisis de los logs durante un par de meses, quizás el tiempo permita ver más detalles, o quizás la campaña acabará antes de eso. El mundo de cyber es un poco como el de la moda textil, a veces vuelven cosas que se creían pasadas ya a la historia. Gracias a este pequeño proyecto, poco a poco, tengo algunos hashes, un script, comandos y TTPs, y espero poder hablar en más detalle (cómo mirar y parsear rápidamente estos logs, qué añadir a las honeypot para tunearlas, etc) de esto y otros que he visto si se me da la oportunidad en alguna charlilla el año que viene.

  • No hay más artículos
❌