La vulnerabilidad de Gitea expone imágenes de contenedores privados sin autenticación – CYBERDEFENSA.MX

Investigadores de ciberseguridad han revelado una falla de seguridad en Gitea, una plataforma autohospedada de código abierto para control de versiones, que permite a atacantes remotos no autenticados extraer imágenes de contenedores privados de las implementaciones de Gitea sin requerir una cuenta, contraseña u otras credenciales.

La vulnerabilidad, rastreada como CVE-2026-27771 (puntuación CVSS: N/A), afecta a todas las versiones de Gitea anteriores a 1.26.2que aborda el tema.

Según Noscope, el defecto de seguridad probablemente afecte a más de 30.000 implementaciones en más de 30 países y no fue detectado durante casi cuatro años. La gran mayoría de las exposiciones se encuentran en China, EE. UU., Alemania, Francia y el Reino Unido. Las organizaciones afectadas abarcan proveedores de atención médica, fabricantes aeroespaciales, infraestructura minorista y proveedores de servicios de Internet.

«En las versiones afectadas, la designación privada en un repositorio de contenedores no brindó la protección que los operadores esperaban razonablemente», Noscope dicho.

Ciberseguridad

«El registro de contenedores de Gitea ha permitido a cualquier persona en Internet, sin cuenta, sin contraseña y sin acceso previo, extraer lo que a primera vista se considerarían imágenes de contenedores privadas de las instancias afectadas como si fueran públicas».

La compañía de seguridad con sede en el Reino Unido también señaló que cualquier bifurcación de Gitea debe tratarse como potencialmente afectada por la vulnerabilidad hasta que haya sido verificada de forma independiente por los respectivos mantenedores. En sus propias pruebas, se confirmó que Forgejo estaba afectado. Actualmente no hay detalles técnicos adicionales disponibles.

Se recomienda a los usuarios de Gitea que actualicen a la versión 1.6.2 para una protección óptima. Si aplicar parches no es una opción inmediata, una solución temporal es establecer [service].REQUIRE_SIGNIN_VIEW=true en la configuración de Gitea. Sin embargo, vale la pena señalar que este enfoque no es ideal si algunos contenedores deben exponerse públicamente intencionalmente.

Omisión de autenticación del controlador Cisco Catalyst SD-WAN explotada activamente para obtener acceso de administrador – CYBERDEFENSA.MX

Cisco ha lanzado actualizaciones para abordar una falla de omisión de autenticación de máxima gravedad en el controlador Catalyst SD-WAN que, según dijo, ha sido explotada en ataques limitados.

La vulnerabilidad, rastreada como CVE-2026-20182tiene una puntuación CVSS de 10,0.

«Una vulnerabilidad en la autenticación de peering en Cisco Catalyst SD-WAN Controller, anteriormente SD-WAN vSmart, y Cisco Catalyst SD-WAN Manager, anteriormente SD-WAN vManage, podría permitir que un atacante remoto no autenticado evite la autenticación y obtenga privilegios administrativos en un sistema afectado», Cisco dicho.

El especialista en equipos de redes dijo que la falla se debe a un mal funcionamiento del mecanismo de autenticación de peering, que un atacante podría explotar enviando solicitudes manipuladas al sistema afectado.

Ciberseguridad

Un exploit exitoso podría permitir al atacante iniciar sesión en el controlador Cisco Catalyst SD-WAN como una cuenta de usuario interna, con altos privilegios y no root, y luego utilizarlo como arma para acceder a NETCONF y manipular la configuración de red para la estructura SD-WAN.

La vulnerabilidad afecta las siguientes implementaciones:

  • Implementación local
  • Cisco SD-WAN Cloud-Pro
  • Nube Cisco SD-WAN (administrada por Cisco)
  • Cisco SD-WAN para gobierno (FedRAMP)

Según Rapid7, que descubrió CVE-2026-20182, la deficiencia tiene sus ecos en CVE-2026-20127 (puntaje CVSS: 10.0), otra omisión de autenticación crítica que afecta al mismo componente. Se dice que este último ha sido explotado por un actor de amenazas llamado UAT-8616 desde al menos 2023.

«Esta nueva vulnerabilidad de omisión de autenticación afecta al servicio ‘vdaemon’ a través de DTLS (puerto UDP 12346), que es el mismo servicio que era vulnerable a CVE-2026-20127», dijeron los investigadores de Rapid7, Jonah Burgess y Stephen Fewer. dicho. «La nueva vulnerabilidad no es una omisión del parche CVE-2026-20127. Es un problema diferente ubicado en una parte similar de la pila de red ‘vdaemon’».

Dicho esto, el resultado final es el mismo: un atacante remoto no autenticado puede abusar de CVE-2026-20182 para convertirse en un par autenticado del dispositivo objetivo y realizar operaciones privilegiadas.

Ciberseguridad

Cisco, en su aviso, señaló que se dio cuenta de una «explotación limitada» de la falla en mayo de 2026, e instó a los clientes a aplicar las últimas actualizaciones lo antes posible.

La compañía también dijo que los sistemas Catalyst SD-WAN Controller a los que se puede acceder a través de Internet y que tienen puertos expuestos corren un mayor riesgo de verse comprometidos. Se recomienda a los clientes que auditen el archivo «/var/log/auth.log» en busca de entradas relacionadas con la clave pública aceptada para vmanage-admin de direcciones IP desconocidas o no autorizadas.

Otro indicador es la presencia de eventos de intercambio de tráfico sospechosos en los registros, incluidas conexiones de intercambio de tráfico no autorizadas que ocurren en momentos inesperados y se originan en direcciones IP no reconocidas, o involucran tipos de dispositivos que no son consistentes con la arquitectura del entorno.

PraisonAI CVE-2026-44338 Omisión de autenticación dirigida a las pocas horas de la divulgación – CYBERDEFENSA.MX

Se han observado actores de amenazas. intentando explotar una vulnerabilidad de seguridad recientemente revelada en AlabanzaAIun marco de orquestación de múltiples agentes de código abierto, dentro de las cuatro horas posteriores a la divulgación pública.

La vulnerabilidad en cuestión es CVE-2026-44338 (Puntuación CVSS: 7,3), un caso de autenticación faltante que expone puntos finales sensibles a cualquier persona, lo que potencialmente permite a un atacante invocar la funcionalidad protegida del servidor API sin un token.

«AlabanzaAI envía un servidor API Flask heredado con la autenticación deshabilitada de forma predeterminada», según un consultivo publicado por los mantenedores a principios de este mes. «Cuando se utiliza ese servidor, cualquier persona que llame y pueda comunicarse con él puede acceder a /agents y activar el flujo de trabajo de agentes.yaml configurado a través de /chat sin proporcionar un token».

Ciberseguridad

Específicamente, el servidor API heredado basado en Flask, src/praisonai/api_server.py, tiene códigos duros AUTH_ENABLED = False y AUTH_TOKEN = Ninguno. Según PraisonAI, la explotación exitosa de la falla puede tener diversos impactos, que incluyen:

  • Enumeración no autenticada del archivo del agente configurado a través de /agents
  • Activación no autenticada del flujo de trabajo «agents.yaml» configurado localmente a través de /chat
  • Consumo repetido del modelo/cuota API, y
  • Exposición de los resultados de PraisonAI.run() a la persona que llama no autenticada

«Por lo tanto, el impacto depende de lo que los agentes.yaml del operador puedan hacer, pero la omisión de autenticación es incondicional en el servidor heredado enviado», dijo PraisonAI.

La vulnerabilidad afecta a todas las versiones del paquete Python desde la 2.5.6 hasta la 4.6.33. Ha sido parcheado en la versión 4.6.34. Al investigador de seguridad Shmulik Cohen se le atribuye el mérito de descubrir e informar el error.

En un informe publicado por Sysdig esta semana, la empresa de seguridad en la nube dijo que observó intentos de explotar la falla pocas horas después de que se hiciera público.

«A las tres horas y 44 minutos de hacerse público el aviso, un escáner que se identificó como CVE-Detector/1.0 estaba investigando el punto final vulnerable exacto en instancias expuestas a Internet», dijo. «El aviso fue publicado [on May 11, 2026,] a las 13:56 UTC. La primera solicitud específica llegó a las 17:40 UTC del mismo día».

La actividad, según Sysdig, se originó en la dirección IP 146.190.133[.]49 y siguió un perfil de escáner empaquetado que llevó a cabo dos pases con ocho minutos de diferencia, y cada pase impulsó aproximadamente 70 solicitudes en aproximadamente 50 segundos.

Mientras que el primer paso escaneó rutas de divulgación genéricas (/.env, /admin, /users/sign_in, /eval, /calculate, /Gemfile.lock), el segundo paso destacó específicamente las superficies de agentes de IA, incluido PraisonAI.

«La sonda que coincidió directamente con CVE-2026-44338 fue un único GET /agents sin encabezado de Autorización y User-Agent CVE-Detector/1.0», dijo Sysdig. «Esa solicitud devuelve 200 OK con el cuerpo {«agent_file»:»agents.yaml»,»agents»:[…]}, confirmando que la omisión fue exitosa.»

Ciberseguridad

No se ha encontrado que el escáner envíe ninguna solicitud POST al punto final «/chat» durante ninguno de los pases, lo que indica que la actividad es consistente con una verificación inicial para determinar si la omisión de autenticación funciona y confirmar si el host es explotable a través de CVE-2026-44338.

La rápida explotación de PraisonAI es el último ejemplo de una tendencia más amplia en la que los actores de amenazas están adoptando cada vez más fallas recientemente reveladas en su arsenal antes de que puedan ser reparadas. Se recomienda a los usuarios que apliquen las últimas correcciones lo antes posible, auditen las implementaciones existentes, revisen la facturación del proveedor de modelos para detectar cualquier actividad sospechosa y roten las credenciales a las que se hace referencia en «agents.yaml».

«Las herramientas adversarias se han ampliado a todo el ecosistema de inteligencia artificial y agentes, sin importar el tamaño, y no solo los nombres conocidos, y el supuesto operativo para cualquier proyecto que genere un incumplimiento no autenticado debe ser que la ventana entre la divulgación y la explotación activa se mide en horas de un solo dígito», dijo Sysdig.

Progress parchea un error crítico de automatización de MOVEit que permite omitir la autenticación – CYBERDEFENSA.MX

Progress Software ha lanzado actualizaciones para abordar dos fallas de seguridad en MOVEit Automation, incluido un error crítico que podría resultar en una omisión de autenticación.

MOVEit Automation (anteriormente Central) es una solución segura de transferencia de archivos administrada (MFT) basada en servidor que se utiliza para programar y automatizar flujos de trabajo de movimiento de archivos en entornos empresariales sin necesidad de scripts personalizados.

Las vulnerabilidades en cuestión son CVE-2026-4670 (Puntuación CVSS: 9,8), una vulnerabilidad de omisión de autenticación, y CVE-2026-5174 (Puntuación CVSS: 7,7), una vulnerabilidad de validación de entrada inadecuada que podría permitir una escalada de privilegios.

«Las vulnerabilidades críticas y altas en MOVEit Automation pueden permitir la omisión de autenticación y la escalada de privilegios a través de las interfaces del puerto de comando del backend del servicio», Progress Software dicho en un aviso. «La explotación puede dar lugar a acceso no autorizado, control administrativo y exposición de datos».

Ciberseguridad

Las deficiencias afectan a las siguientes versiones:

  • MOVEit Automation <= 2025.1.4 (corregido en MOVEit Automation 2025.1.5)
  • MOVEit Automation <= 2025.0.8 (corregido en MOVEit Automation 2025.0.9)
  • MOVEit Automation <= 2024.1.7 (corregido en MOVEit Automation 2024.1.8)

Los investigadores de Airbus SecLab Anaïs Gantet, Delphine Gourdou, Quentin Liddell y Matteo Ricordeau han sido acreditado con descubrir e informar las dos vulnerabilidades. No existen soluciones alternativas que resuelvan los problemas.

Si bien Progress no menciona las fallas que se están explotando en la naturaleza, es esencial que los usuarios apliquen las correcciones lo antes posible para una protección óptima, particularmente teniendo en cuenta que las fallas anteriores en MOVEit Transfer han sido explotadas por bandas de ransomware como Cl0p.

El error de omisión de autenticación de cPanel está siendo explotado en la naturaleza, advierte CISA

Según investigadores de seguridad y proveedores de hosting, una grave vulnerabilidad de omisión de autenticación en cPanel, una de las plataformas de panel de control de alojamiento web más implementadas en Internet, está siendo explotada activamente en la naturaleza.

La vulnerabilidad, rastreada como CVE-2026-41940afecta a todas las versiones compatibles de cPanel y WebHost Manager (WHM) lanzadas después de la versión 11.40, así como a WP al cuadradoun panel de gestión de alojamiento de WordPress integrado en la plataforma cPanel. Escaneos de Internet realizados por la empresa de seguridad Rapid7 utilizando el motor de búsqueda Shodan identificados aproximadamente 1,5 millones Instancias de cPanel expuestas en línea, aunque se desconoce el número exacto de sistemas vulnerables.

cPanel lanzó un parche Martes. En ese momento, la explotación ya había comenzado. KnownHost, un proveedor de hosting que depende de cPanel, dijo a principios de esta semana que se habían observado exploits exitosos en la naturaleza antes de que cualquier solución estuviera disponible.

La Agencia de Seguridad de Infraestructura y Ciberseguridad agregó el CVE a su lista de vulnerabilidades explotadas conocidas (KEV) el jueves.

La empresa de ciberseguridad watchTowr proporcionó detalles técnicos en un blog publicado el miércoles: La falla surge del manejo inadecuado de la entrada del usuario durante el proceso de inicio de sesión. Cuando un usuario intenta iniciar sesión, cPanel escribe los datos de la solicitud en un archivo de sesión del lado del servidor antes de verificar la identidad del usuario. Un atacante puede aprovechar esto incorporando saltos de línea ocultos en el campo de contraseña de una solicitud de inicio de sesión (caracteres que cPanel no puede eliminar), lo que permite inyectar datos arbitrarios directamente en ese archivo.

A través de un paso secundario, que también involucra una solicitud deliberadamente mal formada, los datos inyectados se promueven al caché activo de la sesión, donde cPanel los lee como legítimos. Una vez que eso sucede, el sistema considera que la sesión ya está autenticada y omite por completo la verificación de la contraseña, otorgando acceso sin verificar las credenciales reales del usuario.

Panel c ha publicado un script de detección diseñado para escanear archivos de sesión en busca de indicadores de compromiso, incluidas sesiones que contienen marcas de tiempo de autenticación inyectadas, sesiones de autenticación previa con atributos autenticados y campos de contraseña que contienen nuevas líneas incrustadas. WatchTowr lanzado por separado un «generador de artefactos de detección» que los administradores pueden utilizar para verificar si sus instancias siguen siendo vulnerables.

Namecheap, un importante registrador de dominios y proveedor de alojamiento, tomó la medida de bloquear temporalmente las conexiones a los puertos 2083 y 2087 de cPanel y WHM antes de la disponibilidad del parche. citando la necesidad de proteger a los clientes mientras estaba pendiente una solución oficial. La compañía comenzó a aplicar el parche después del lanzamiento de cPanel a principios de esta semana.

Las versiones parcheadas de cPanel abordan el problema en siete ramas de versiones, desde 11.110.0 hasta 11.136.0, así como en la versión 11.136.1 de WP Squared. Las notas informativas de la empresa. que la solución garantiza que las entradas potencialmente peligrosas se eliminen automáticamente dentro del proceso principal de guardado de sesiones, en lugar de depender de que cada parte individual del código base lo haga por separado. El parche también agrega manejo para los casos en los que falta una clave de cifrado por sesión, una condición que el código original no tuvo en cuenta y que los atacantes pudieron aprovechar para evitar por completo la codificación de contraseñas.

El CVE recibió un 9,8 en la escala CVSS.

Greg Otto

Escrito por Greg Otto

Greg Otto es el editor en jefe de CyberScoop y supervisa todo el contenido editorial del sitio web. Greg ha dirigido una cobertura de ciberseguridad que ha ganado varios premios, incluidos los de la Sociedad de Periodistas Profesionales y la Sociedad Estadounidense de Editores de Publicaciones Empresariales. Antes de unirse a Scoop News Group, Greg trabajó para Washington Business Journal, US News & World Report y WTOP Radio. Tiene una licenciatura en periodismo televisivo de la Universidad de Temple.

Dónde termina la autenticación multifactor y comienza el abuso de credenciales – CYBERDEFENSA.MX

Las organizaciones suelen implementar la autenticación multifactor (MFA) y suponen que las contraseñas robadas ya no son suficientes para acceder a los sistemas. En entornos Windows, esa suposición suele ser errónea. Los atacantes siguen comprometiendo las redes todos los días utilizando credenciales válidas. La cuestión no es la ayuda macrofinanciera en sí, sino la cobertura.

Se aplica a través de un proveedor de identidad (IdP) como Microsoft Entra ID, Okta o Google Workspace. MFA funciona bien para aplicaciones en la nube e inicios de sesión federados. Pero muchos inicios de sesión de Windows dependen únicamente de rutas de autenticación de Active Directory (AD) que nunca activan mensajes de MFA. Para reducir el riesgo basado en credenciales, los equipos de seguridad deben comprender dónde ocurre la autenticación de Windows fuera de su pila de identidades.

Siete rutas de autenticación de Windows en las que confían los atacantes

1. Inicio de sesión interactivo de Windows (local o unido a un dominio)

Cuando un usuario inicia sesión directamente en una estación de trabajo o servidor de Windows, la autenticación normalmente la maneja AD (a través de Kerberos o NTLM), no mediante un IdP en la nube.

En entornos híbridosincluso si Entra ID aplica MFA para aplicaciones en la nube, los controladores de dominio locales validan los inicios de sesión tradicionales de Windows en sistemas unidos a un dominio. A menos que se implemente Windows Hello for Business, tarjetas inteligentes u otro mecanismo MFA integrado, no hay ningún factor adicional en ese flujo.

Si un atacante obtiene la contraseña de un usuario (o hash NTLM), puede autenticarse en una máquina unida a un dominio sin activar las políticas MFA que protegen las aplicaciones de software como servicio o el inicio de sesión único federado. Desde la perspectiva del controlador de dominio, esta es una solicitud de autenticación estándar.

Herramientas como Acceso seguro a Specops son clave para limitar el riesgo de abuso de credenciales en estos escenarios. Al aplicar MFA para el inicio de sesión de Windows, así como para las conexiones VPN y de Protocolo de escritorio remoto (RDP), esta herramienta dificulta que los atacantes obtengan acceso no autorizado a su red. Esto se extiende incluso a los inicios de sesión fuera de línea, que están protegidos con autenticación con contraseña de un solo uso.

Acceso seguro a Specops

2. Acceso RDP directo que evita el acceso condicional

RDP es uno de los métodos de acceso más específicos en entornos Windows. Incluso cuando RDP no está expuesto a Internet, los atacantes suelen llegar a través de movimiento lateral después del compromiso inicial. Una sesión RDP directa a un servidor no pasa automáticamente por los controles MFA basados ​​en la nube, lo que significa que el inicio de sesión puede depender únicamente de la credencial AD subyacente.

3. Autenticación NTLM

NTLM es un protocolo de autenticación heredado que, a pesar de estar en desuso a favor del protocolo Kerberos, más seguro, todavía existe por razones de compatibilidad. También es un vector de ataque común porque admite técnicas como pass-the-hash.

En los ataques pass-the-hash, el atacante no necesita la contraseña en texto plano; en su lugar, utilizan el hash NTLM para autenticarse. Ministerio de Asuntos Exteriores no ayuda si el sistema acepta el hash como prueba de identidad.

NTLM también puede aparecer en flujos de autenticación internos que las organizaciones tal vez no monitoreen activamente; sólo un incidente o una auditoría lo revelará a los equipos de seguridad.

4. Abuso de tickets de Kerberos

Kerberos es el protocolo de autenticación principal para AD. En lugar de robar contraseñas directamente, Los atacantes roban tickets de Kerberos. desde la memoria o generar tickets falsificados después de comprometer cuentas privilegiadas. Esto permite técnicas como:

  • Pase el boleto
  • Boleto Dorado
  • Boleto de Plata

Estos ataques permiten el acceso a largo plazo y el movimiento lateral y también reducen la necesidad de inicios de sesión repetidos, lo que reduce las posibilidades de detección. Estos ataques pueden persistir incluso después de restablecer la contraseña si el compromiso subyacente no se aborda por completo.

5. Cuentas de administrador local y reutilización de credenciales

Las organizaciones todavía dependen de cuentas de administrador local para tareas de soporte y recuperación del sistema. Si las contraseñas de administrador local se reutilizan en todos los puntos finales, los atacantes pueden escalar un compromiso hacia un acceso amplio.

Las cuentas de administrador local generalmente se autentican directamente en el punto final, evitando por completo los controles de MFA. No se aplican las políticas de acceso condicional de Entra ID. Ésta es una de las razones por las que el volcado de credenciales sigue siendo tan eficaz en entornos Windows.

6. Autenticación y movimiento lateral del Bloque de mensajes del servidor (SMB)

SMB se utiliza para compartir archivos y acceder remotamente a recursos de Windows. También es una de las rutas de movimiento lateral más confiables una vez que un atacante tiene credenciales válidas. Los atacantes suelen utilizar SMB para acceder a recursos compartidos administrativos como C$ o para interactuar con sistemas de forma remota utilizando credenciales válidas.

Si la autenticación SMB se trata como tráfico interno, rara vez se aplica MFA en esta capa. Si el atacante tiene credenciales válidas, puede usar SMB para moverse rápidamente entre sistemas.

7. Cuentas de servicio que nunca activan MFA

cuentas de servicio existen para ejecutar tareas programadas, aplicaciones, integraciones y servicios del sistema. Suelen tener credenciales estables, amplios permisos y una larga vida útil.

En muchas organizaciones, las contraseñas de las cuentas de servicio no caducan y rara vez se controlan. También son difíciles de proteger con MFA porque la autenticación está automatizada. Con frecuencia, estas cuentas se utilizan en aplicaciones heredadas que no pueden admitir controles de autenticación modernos.

Esta es una de las razones por las que los atacantes apuntan credenciales de soporte técnico y acceso de administrador de endpoints en las primeras etapas de una intrusión.

Cómo cerrar las brechas de autenticación de Windows

Los equipos de seguridad deben tratar la autenticación de Windows como su propia superficie de seguridad. Hay varias medidas prácticas que los equipos de seguridad pueden tomar para reducir la exposición:

1. Aplicar políticas de contraseñas más seguras en AD

Se debe aplicar una política de contraseñas segura frases de contraseña más largas de 15 o más caracteres. Las frases de contraseña son más fáciles de recordar para los usuarios y más difíciles de descifrar para los atacantes. Las políticas sólidas también deberían impedir la reutilización de contraseñas y bloquear patrones débiles que los atacantes puedan adivinar.

2. Bloquear continuamente las contraseñas comprometidas

El robo de credenciales no siempre es el resultado de ataques de fuerza bruta. Miles de millones de contraseñas ya están disponibles en conjuntos de datos violados para que los atacantes las reutilicen. ataques de credenciales. El bloqueo de contraseñas comprometidas en el momento de su creación reduce la posibilidad de que los usuarios establezcan credenciales que los atacantes ya tienen.

3. Reducir la exposición a protocolos de autenticación heredados

Siempre que sea posible, las organizaciones deben restringir o eliminar la autenticación NTLM. Los equipos de seguridad deben fijarse el objetivo de comprender dónde existe NTLM, reducirlo cuando sea posible y reforzar los controles cuando no se pueda eliminar.

4. Audite las cuentas de servicio y reduzca la pérdida de privilegios

Trate las cuentas de servicio como identidades de alto riesgo. Las organizaciones deben inventariarlos, reducir privilegios innecesariosrotar credenciales y eliminar cuentas que ya no sean necesarias. Si una cuenta de servicio tiene permisos a nivel de dominio, la organización debe asumir que será el objetivo.

Cómo puede ayudar Specops

Las políticas de contraseñas sólidas y las comprobaciones proactivas de credenciales comprometidas conocidas son dos de las formas más efectivas de reducir el riesgo de ataques basados ​​en credenciales. Política de contraseñas de Specops ayuda aplicando controles de contraseña flexibles que van más allá de lo que está disponible de forma nativa en Microsoft.

Política de contraseñas de Specops

Es Protección de contraseña violada La función verifica continuamente las contraseñas de Active Directory con una base de datos de más de 5,4 mil millones de credenciales expuestas, avisándole rápidamente si se descubre que la contraseña de un usuario está en riesgo. Si está interesado en ver cómo Specops puede ayudar a su organización, hable con un experto o reservar una demostración para ver nuestras soluciones en acción.

¿Encontró interesante este artículo? Este artículo es una contribución de uno de nuestros valiosos socios. Síguenos en noticias de google, Gorjeo y LinkedIn para leer más contenido exclusivo que publicamos.

Starkiller Phishing Suite utiliza el proxy inverso AitM para evitar la autenticación multifactor – CYBERDEFENSA.MX

Investigadores de ciberseguridad han revelado detalles de una nueva suite de phishing llamada asesino estrella que representa páginas de inicio de sesión legítimas para evitar las protecciones de autenticación multifactor (MFA).

Un grupo de amenazas que se hace llamar Jinkusu lo anuncia como una plataforma de cibercrimen y otorga a los clientes acceso a un panel que les permite seleccionar una marca para hacerse pasar por ella o ingresar la URL real de una marca. También permite a los usuarios elegir palabras clave personalizadas como «iniciar sesión», «verificar», «seguridad» o «cuenta» e integra acortadores de URL como TinyURL para ocultar la URL de destino.

«Se lanza un instancia de Chrome sin cabeza – un navegador que funciona sin una ventana visible – dentro de un contenedor acoplablecarga el sitio web real de la marca y actúa como un proxy inverso entre el sitio objetivo y el legítimo», afirman los investigadores de Abnormal Callie Baron y Piotr Wojtyla. dicho.

«Los destinatarios reciben contenido de página genuino directamente a través de la infraestructura del atacante, lo que garantiza que la página de phishing nunca quede desactualizada. Y debido a que Starkiller representa el sitio real en vivo, no hay archivos de plantilla para que los proveedores de seguridad tomen huellas dactilares o incluyan en la lista de bloqueo».

Esta técnica de proxy de página de inicio de sesión evita la necesidad de que los atacantes actualicen periódicamente sus plantillas de páginas de phishing a medida que se actualizan las páginas reales que están suplantando.

Ciberseguridad

Dicho de otra manera, el contenedor actúa como un proxy inverso de AitM, reenviando las entradas del usuario final ingresadas en la página en vivo falsificada al sitio legítimo y devolviendo las respuestas del sitio. En el fondo, cada pulsación de tecla, envío de formulario y token de sesión se enruta a través de una infraestructura controlada por el atacante y se captura para tomar el control de la cuenta.

«La plataforma agiliza las operaciones de phishing al centralizar la administración de la infraestructura, la implementación de páginas de phishing y el monitoreo de sesiones dentro de un único panel de control», dijo Abnormal. «Combinado con el enmascaramiento de URL, el secuestro de sesiones y la omisión de MFA, brinda a los ciberdelincuentes poco capacitados acceso a capacidades de ataque que antes estaban fuera de su alcance».

El desarrollo se produce cuando Datadog reveló que el kit 1Phish había evolucionado de un recolector de credenciales básico en septiembre de 2025 a un kit de phishing de varias etapas dirigido a los usuarios de 1Password.

La versión actualizada del kit incorpora una capa de validación y huella digital previa al phishing, soporte para capturar códigos de acceso de un solo uso (OTP) y códigos de recuperación, y lógica de huellas digitales del navegador para filtrar bots.

«Esta progresión refleja una iteración deliberada en lugar de una simple reutilización de plantillas», dijo el investigador de seguridad Martin McCloskey. dicho. «Cada versión se basa en la anterior e introduce controles diseñados para aumentar las tasas de conversión, reducir el análisis automatizado y admitir la recolección de autenticación secundaria».

Los hallazgos muestran que soluciones turcas como Starkiller y 1Phish están convirtiendo cada vez más el phishing en flujos de trabajo estilo SaaS, lo que reduce aún más la barrera de habilidades necesarias para llevar a cabo dichos ataques a escala.

También coinciden con una sofisticada campaña de phishing dirigida a empresas y profesionales norteamericanos al abusar del flujo de concesión de autorización de dispositivos OAuth 2.0 para eludir la autenticación multifactor (MFA) y comprometer las cuentas de Microsoft 365.

Para lograrlo, el atacante se registra en la aplicación Microsoft OAuth y genera un código de dispositivo único, que luego se entrega a la víctima a través de un correo electrónico de phishing dirigido.

«La víctima es dirigida al portal legítimo del dominio de Microsoft (microsoft.com/devicelogin) para ingresar un código de dispositivo proporcionado por el atacante«, investigadores Jeewan Singh Jalal, Prabhakaran Ravichandhiran y Anand Bodke dicho. «Esta acción autentica a la víctima y emite un token de acceso OAuth válido a la aplicación del atacante. El robo en tiempo real de estos tokens otorga al atacante acceso persistente a las cuentas de Microsoft 365 y a los datos corporativos de la víctima».

En los últimos meses, las campañas de phishing también se han dirigido a instituciones financieras, específicamente bancos y cooperativas de crédito con sede en Estados Unidos, para obtener credenciales. Se dice que la campaña se desarrolló en dos fases distintas: una ola inicial que comenzó a finales de junio de 2025 y un conjunto más sofisticado de ataques que comenzó a mediados de noviembre de 2025.

Ciberseguridad

«Los actores comenzaron a registrarse [.]co[.]com falsifican sitios web de instituciones financieras y presentan imitaciones creíbles de instituciones financieras reales», afirman los investigadores de BlueVoyant, Shira Reuveny y Joshua Green. dicho. «Estos [.]co[.]Los dominios com sirven como punto de entrada inicial en una refinada cadena de múltiples etapas».

El dominio, cuando se visita desde un enlace en el que se puede hacer clic en un correo electrónico de phishing, está diseñado para cargar una página CAPTCHA de Cloudflare fraudulenta que imita a la institución objetivo. El CAPTCHA no es funcional y crea un retraso deliberado antes de que un script codificado en Base64 redirija a los usuarios a la página de recolección de credenciales.

En un esfuerzo por evadir la detección y evitar que los escáneres automáticos marquen el contenido malicioso, accedan directamente al [.]co[.]Los dominios com desencadenan una redirección a un archivo «www» con formato incorrecto.[.]URL «www».

«El despliegue por parte del adversario de una cadena de evasión de múltiples capas más avanzada, que incorpora validación de referencia, controles de acceso basados ​​en cookies, retrasos intencionales y ofuscación de código, crea efectivamente una infraestructura más resistente que presenta barreras para las herramientas de seguridad automatizadas y el análisis manual», dijo BlueVoyant.