Mensajes recientes
#21
Seguridad Wireless / hostbase-1.8 evil-twin script
Último mensaje por KoalaUnleashed - Octubre 10, 2026, 04:45:28 PMAqui estamos con hostbase-1.8 (se queda en beta testing por el momento)
Lo que cambia desde las versiones antiguas :
- revision del codigo entero en bash.Mas conocido, mas facilidad para las dependencias, rapido.
- Este script no usa ninguna método de DoS (dénial of service).Y es el primero script de evil-twin que hace eso...
- Usa codigo QR, tambien aqui es el primero a hacer eso
OJO : a no poner en todas las manos...
Tengo que hacer una video de demostracion pero se usa de manera You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login elige la tarjeta wifi (consejo de tener al menos 2 tarjetas) la interna del ordenador y un You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login tiene una mas mejor.
Este script usa hostapd o sea hay que tener cuenta de eso.Ahora muchas tarjetas wifi estan compatible pero si no el script te lo dice.
Con 1 2 o 3 se elige la You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login momento de hacer las redes con hostapd, si quieres hacer pruebas en 2,4GHz se eliger la tarjeta en :
Código: text
O si quiere hacer pruebas en 5GHz elige la tarjeta en :
Código: text
Para cada red tiene la opcion de saltar la red con 0 o sea asi puedes probar sin hacer tonterias...
Al fin eligimos el evil-twin con :
Código: text
Consejo con 2 tarjetas wifi : si antes de iniciar el script se ve bastante cliente en la red en 2,4GHz pues no salta el AP 1/3 elige la tarjeta y luego salta AP 2/3 (con en numéro 0).
Yo lo uso con 3 tarjetas (internal del odenador y 2 tarjetas wifi usb) me permite de hacer ataque en 2,4GHz y 5GHz al mismo tiempo.
Luego se inicia todo y si alguien se conecta, la clave wifi y los qrcode se encontraran en :
/var/www y /var/www/msftconnecttest
La clave es el ficherco cle.txt y ya se vera la carpetas de codigo QR
Soy francès o sea el script esta hecho para Francia pero hay una pagina por defecto si no encontra el modelo del router.
El script esta traducido al ingles.
Que no se olvida de leer el readme.
Este script no lo encontraras a parte de aqui, es une exclusividad para Undercode porqué me gusta el foro.En Francia esos typos de foro no duran bastante tiempo...
El script ha sido probado en Kali.
Y por el WPA3 ?
No hay DoS (denial of service) pero... no digo mas jaja.
Si quiere probar con wpa3, haces un scan de red con airodump antes de iniciar el script, mira los clientes, apunta la red, apunta si hay gente en bandas 2,4GHz o 5GHz y vuelve a iniciar el script mas tarde cuando no habra nadie (con el WPA3 no podemos desconnectar tan facil) PERO este script impide la proxima conexion, es aqui toda la diferencia.Con el WPA2 no tenemos que esperar.
Aqui lo dejo que disfrutais !
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
No usa las antiguas versiones, la nueva est : hostbase-1.8 se olvida de las otras
Esta todavia en beta testing, respondré aqui, no en github.Tengo que hacer una vidéo rapida del script.
++
Lo que cambia desde las versiones antiguas :
- revision del codigo entero en bash.Mas conocido, mas facilidad para las dependencias, rapido.
- Este script no usa ninguna método de DoS (dénial of service).Y es el primero script de evil-twin que hace eso...
- Usa codigo QR, tambien aqui es el primero a hacer eso
OJO : a no poner en todas las manos...
Tengo que hacer una video de demostracion pero se usa de manera You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login elige la tarjeta wifi (consejo de tener al menos 2 tarjetas) la interna del ordenador y un You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login tiene una mas mejor.
Este script usa hostapd o sea hay que tener cuenta de eso.Ahora muchas tarjetas wifi estan compatible pero si no el script te lo dice.
Con 1 2 o 3 se elige la You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login momento de hacer las redes con hostapd, si quieres hacer pruebas en 2,4GHz se eliger la tarjeta en :
AP 1/3 : hostapd.conf (WPA network)O si quiere hacer pruebas en 5GHz elige la tarjeta en :
AP 2/3 hostaghz.conf (WPA 5 GHz network) Para cada red tiene la opcion de saltar la red con 0 o sea asi puedes probar sin hacer tonterias...
Al fin eligimos el evil-twin con :
AP 3/3 hostapdd.conf (Evil twin) Consejo con 2 tarjetas wifi : si antes de iniciar el script se ve bastante cliente en la red en 2,4GHz pues no salta el AP 1/3 elige la tarjeta y luego salta AP 2/3 (con en numéro 0).
Yo lo uso con 3 tarjetas (internal del odenador y 2 tarjetas wifi usb) me permite de hacer ataque en 2,4GHz y 5GHz al mismo tiempo.
Luego se inicia todo y si alguien se conecta, la clave wifi y los qrcode se encontraran en :
/var/www y /var/www/msftconnecttest
La clave es el ficherco cle.txt y ya se vera la carpetas de codigo QR
Soy francès o sea el script esta hecho para Francia pero hay una pagina por defecto si no encontra el modelo del router.
El script esta traducido al ingles.
Que no se olvida de leer el readme.
Este script no lo encontraras a parte de aqui, es une exclusividad para Undercode porqué me gusta el foro.En Francia esos typos de foro no duran bastante tiempo...
El script ha sido probado en Kali.
Y por el WPA3 ?
No hay DoS (denial of service) pero... no digo mas jaja.
Si quiere probar con wpa3, haces un scan de red con airodump antes de iniciar el script, mira los clientes, apunta la red, apunta si hay gente en bandas 2,4GHz o 5GHz y vuelve a iniciar el script mas tarde cuando no habra nadie (con el WPA3 no podemos desconnectar tan facil) PERO este script impide la proxima conexion, es aqui toda la diferencia.Con el WPA2 no tenemos que esperar.
Aqui lo dejo que disfrutais !
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
No usa las antiguas versiones, la nueva est : hostbase-1.8 se olvida de las otras
Esta todavia en beta testing, respondré aqui, no en github.Tengo que hacer una vidéo rapida del script.
++
#22
Noticias Informáticas / Ucrania está construyendo «alg...
Último mensaje por AXCESS - Octubre 09, 2026, 05:03:06 PMYou are not allowed to view links.
You are not allowed to view links.
Register or Login or You are not allowed to view links.
Register or Login
Ucrania planea desarrollar su propio sistema similar a Starlink, diseñado para apoyar la planificación y el despliegue de operaciones de defensa militar contra Rusia; así lo afirmó el presidente Volodímir Zelenski, quien sostuvo además que sería «justo» que Starlink estuviera disponible para uso militar.
Los planes iniciales del proyecto contemplan el lanzamiento de 120 satélites en 2027 utilizando cohetes de SpaceX, dado que Ucrania carece de vehículos de lanzamiento orbital aptos para cargas pesadas. El despliegue de constelaciones de satélites como Starlink suele realizarse liberando múltiples unidades desde cada cohete.
Zelenski parece decidido a desarrollar, lanzar y desplegar esta alternativa ucraniana a Starlink lo antes posible, citando la posibilidad de que China comparta ciertas tecnologías con Rusia. De tener éxito, el plan de Zelenski dejaría en mal lugar al vergonzoso programa Rassvet de Rusia.
La constelación de Zelenski
En declaraciones a los periodistas esta semana, el presidente Zelenski reveló el plan para desarrollar un sistema de comunicaciones al estilo de Starlink. "Hay avances. Estamos trabajando en algo igual [similar] a Starlink".
Confirmando rumores que se remontan a julio de 2026 —y de los que informaron medios como Ukraine Business News—, el proyecto surge como respuesta a la constelación rusa Rassvet, la cual está teniendo dificultades para proporcionar la cobertura terrestre prevista.
Los primeros informes sobre la alternativa a Starlink de Zelenski indicaban que la empresa ucraniana Stetman está desarrollando las unidades de comunicación orbital, diseñándolas para dar soporte a las instituciones estatales y a las fuerzas de defensa, así como a la infraestructura crítica de Ucrania.
Al mismo tiempo, el presidente subrayó que sería justo brindar a Ucrania la posibilidad de utilizar el servicio de internet por satélite Starlink para llevar a cabo ataques contra la Federación de Rusia.
Fuente:
TechRadar
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
Ucrania planea desarrollar su propio sistema similar a Starlink, diseñado para apoyar la planificación y el despliegue de operaciones de defensa militar contra Rusia; así lo afirmó el presidente Volodímir Zelenski, quien sostuvo además que sería «justo» que Starlink estuviera disponible para uso militar.
Los planes iniciales del proyecto contemplan el lanzamiento de 120 satélites en 2027 utilizando cohetes de SpaceX, dado que Ucrania carece de vehículos de lanzamiento orbital aptos para cargas pesadas. El despliegue de constelaciones de satélites como Starlink suele realizarse liberando múltiples unidades desde cada cohete.
Zelenski parece decidido a desarrollar, lanzar y desplegar esta alternativa ucraniana a Starlink lo antes posible, citando la posibilidad de que China comparta ciertas tecnologías con Rusia. De tener éxito, el plan de Zelenski dejaría en mal lugar al vergonzoso programa Rassvet de Rusia.
La constelación de Zelenski
En declaraciones a los periodistas esta semana, el presidente Zelenski reveló el plan para desarrollar un sistema de comunicaciones al estilo de Starlink. "Hay avances. Estamos trabajando en algo igual [similar] a Starlink".
Confirmando rumores que se remontan a julio de 2026 —y de los que informaron medios como Ukraine Business News—, el proyecto surge como respuesta a la constelación rusa Rassvet, la cual está teniendo dificultades para proporcionar la cobertura terrestre prevista.
Los primeros informes sobre la alternativa a Starlink de Zelenski indicaban que la empresa ucraniana Stetman está desarrollando las unidades de comunicación orbital, diseñándolas para dar soporte a las instituciones estatales y a las fuerzas de defensa, así como a la infraestructura crítica de Ucrania.
Al mismo tiempo, el presidente subrayó que sería justo brindar a Ucrania la posibilidad de utilizar el servicio de internet por satélite Starlink para llevar a cabo ataques contra la Federación de Rusia.
Fuente:
TechRadar
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
#23
Noticias Informáticas / Secuestran el foro de la Dark ...
Último mensaje por AXCESS - Octubre 09, 2026, 04:45:50 PMYou are not allowed to view links.
You are not allowed to view links.
Register or Login or You are not allowed to view links.
Register or Login
Dread, uno de los foros de discusión basados en Tor más conocidos y utilizados por las comunidades de mercados de la *dark web* y por quienes monitorean el cibercrimen, parece haber sido secuestrado por operadores desconocidos que afirman controlar las claves del dominio del proyecto.
Hackread[.]com accedió a Dread y capturó imágenes de pantalla que mostraban una nueva publicación fijada titulada «Así que... ¡Dread ha sido hackeado! ¿Qué sigue?». La publicación fue realizada por una cuenta llamada «HugBunter» —el mismo seudónimo utilizado por el administrador histórico de Dread—, aunque no fue posible verificar de forma independiente quién controla realmente dicha cuenta.
Las capturas de pantalla se tomaron dos días antes de la publicación del artículo. En ese momento, el aviso fijado sobre el hackeo indicaba que se había publicado nueve días atrás, lo que sugiere que el mensaje había permanecido visible en Dread durante más de una semana.
Un mensaje emergente que aparece en el foro dice: «Dread ha sido hackeado». En él se afirma que los nuevos operadores tienen el control del proyecto Dread, incluidas las claves de su dominio, pero aclaran que no están chantajeando a nadie ni filtrando datos de los usuarios.
Captura de pantalla que muestra una ventana emergente de Dread2 afirmando que el foro de la *dark web* había sido hackeado y que los operadores tenían acceso al proyecto Dread, incluidas sus claves de dominio
Nuevos operadores reclaman el control del dominio de Dread
La publicación fijada indica que los usuarios ya se encuentran en el sitio de los nuevos operadores y que este se sirve a través del propio dominio de Dread. El mensaje afirma que el grupo tiene acceso a las «claves secretas» del proyecto y advierte a los operadores de Dread que no interfieran.
La publicación también sugiere que es posible llegar a un acuerdo, afirmando que el dominio podría devolverse o transferirse a otra parte. Aunque no aporta pruebas técnicas, la capacidad de mostrar mensajes a través de la interfaz del foro sería un indicio serio de que los atacantes han logrado controlar parte de la infraestructura o del sistema de firma de Dread.
Cabe señalar que Dread no es, en sí mismo, un mercado de la *dark web*. Funciona más bien como una versión de Reddit basada en Tor, con comunidades que debaten sobre mercados de la *darknet*, estafas, detenciones, privacidad, seguridad operativa y actividades de ciberdelincuencia. Esto hace que cualquier toma de control sea relevante, ya que muchos usuarios consideran a Dread una fuente de información sobre el estado de los mercados, alertas de estafas y anuncios verificados de la comunidad.
Afirman que no se publicarán datos de los usuarios
Los responsables de la publicación aseguran que no tienen intención de publicar datos de usuarios, eliminar cuentas ni filtrar información, "a menos que" los administradores de Dread realicen acciones que ellos califican de imprudentes.
Sin embargo, dicha afirmación no ha sido verificada y no aporta pruebas sobre a qué datos —si es que hubo alguno— se accedió. Tampoco confirman si se vieron expuestos mensajes privados, registros de cuentas, historiales de moderación, claves o sistemas internos.
La publicación también incluye datos de contacto, un bloque de mensaje firmado con PGP y una clave pública PGP. Informa a los usuarios de que los contactos de Jabber y Session son temporales, mientras que la huella digital PGP debe considerarse la credencial permanente para verificar futuros mensajes.
CafeDread promocionado como foro de reemplazo
La misma publicación promociona un nuevo foro llamado CafeDread e invita a los usuarios a registrarse. Indica que tanto las tiendas como los usuarios pueden crear sus propios foros e hilos de discusión, incluidas áreas VIP ocultas para personas seleccionadas.
El mensaje también señala que la dirección conocida de Dread podría mostrar aleatoriamente el foro original o el nuevo proyecto, lo que sugiere algún tipo de conflicto de dominio, réplica o enrutamiento. You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login no ha confirmado de forma independiente la causa técnica.
Captura de pantalla de la publicación fijada en Dread2 que afirmaba que el foro había sido hackeado; en ella, los operadores declaraban controlar las claves del dominio de Dread y promocionaban CafeDread como foro sustituto
Por el momento, los usuarios deben abordar con cautela todos los anuncios, sitios espejo y enlaces de reemplazo relacionados con Dread. Si las afirmaciones son ciertas, es posible que los operadores de Dread hayan perdido el control de la infraestructura clave utilizada para generar confianza entre los usuarios. Si no lo son, el incidente podría implicar, aun así, una suplantación convincente o un compromiso parcial del sistema.
Hasta que los operadores originales de Dread confirmen que mantienen el control a través de un canal de confianza, los usuarios deben evitar iniciar sesión a través de nuevos sitios espejo, seguir enlaces de reemplazo o confiar en mensajes privados que afirmen representar al foro.
En el momento de redactar este texto, el foro Dread se encontraba fuera de servicio.
Actualización:
Tras la publicación, se encontró un anuncio más reciente de Dread titulado «Informe de transparencia de Dread: 5 de octubre de 2026: Dread "hackeado"», publicado por la cuenta HugBunter dos días antes.
En dicha publicación, el operador de Dread afirmó que los servidores del foro no habían sido vulnerados, que no se había accedido a los datos de los usuarios y que la infraestructura del servidor permanecía protegida.
El mensaje indicaba que el problema se debía a una clave privada «onion» que se había incluido por error en un archivo actualizado del software GoBalance.
Según el comunicado, el dominio afectado debía considerarse retirado, ya que cualquier persona en posesión de la clave privada podría utilizarla, generando riesgos de ataques de intermediario (*man-in-the-middle*). Desde entonces ha aparecido una nueva dirección «onion» de Dread, pero Hackread[.]com no publicará dicha URL.
Fuente:
HackRead
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
Dread, uno de los foros de discusión basados en Tor más conocidos y utilizados por las comunidades de mercados de la *dark web* y por quienes monitorean el cibercrimen, parece haber sido secuestrado por operadores desconocidos que afirman controlar las claves del dominio del proyecto.
Hackread[.]com accedió a Dread y capturó imágenes de pantalla que mostraban una nueva publicación fijada titulada «Así que... ¡Dread ha sido hackeado! ¿Qué sigue?». La publicación fue realizada por una cuenta llamada «HugBunter» —el mismo seudónimo utilizado por el administrador histórico de Dread—, aunque no fue posible verificar de forma independiente quién controla realmente dicha cuenta.
Las capturas de pantalla se tomaron dos días antes de la publicación del artículo. En ese momento, el aviso fijado sobre el hackeo indicaba que se había publicado nueve días atrás, lo que sugiere que el mensaje había permanecido visible en Dread durante más de una semana.
Un mensaje emergente que aparece en el foro dice: «Dread ha sido hackeado». En él se afirma que los nuevos operadores tienen el control del proyecto Dread, incluidas las claves de su dominio, pero aclaran que no están chantajeando a nadie ni filtrando datos de los usuarios.
Captura de pantalla que muestra una ventana emergente de Dread2 afirmando que el foro de la *dark web* había sido hackeado y que los operadores tenían acceso al proyecto Dread, incluidas sus claves de dominio
Nuevos operadores reclaman el control del dominio de Dread
La publicación fijada indica que los usuarios ya se encuentran en el sitio de los nuevos operadores y que este se sirve a través del propio dominio de Dread. El mensaje afirma que el grupo tiene acceso a las «claves secretas» del proyecto y advierte a los operadores de Dread que no interfieran.
La publicación también sugiere que es posible llegar a un acuerdo, afirmando que el dominio podría devolverse o transferirse a otra parte. Aunque no aporta pruebas técnicas, la capacidad de mostrar mensajes a través de la interfaz del foro sería un indicio serio de que los atacantes han logrado controlar parte de la infraestructura o del sistema de firma de Dread.
Cabe señalar que Dread no es, en sí mismo, un mercado de la *dark web*. Funciona más bien como una versión de Reddit basada en Tor, con comunidades que debaten sobre mercados de la *darknet*, estafas, detenciones, privacidad, seguridad operativa y actividades de ciberdelincuencia. Esto hace que cualquier toma de control sea relevante, ya que muchos usuarios consideran a Dread una fuente de información sobre el estado de los mercados, alertas de estafas y anuncios verificados de la comunidad.
Afirman que no se publicarán datos de los usuarios
Los responsables de la publicación aseguran que no tienen intención de publicar datos de usuarios, eliminar cuentas ni filtrar información, "a menos que" los administradores de Dread realicen acciones que ellos califican de imprudentes.
Sin embargo, dicha afirmación no ha sido verificada y no aporta pruebas sobre a qué datos —si es que hubo alguno— se accedió. Tampoco confirman si se vieron expuestos mensajes privados, registros de cuentas, historiales de moderación, claves o sistemas internos.
La publicación también incluye datos de contacto, un bloque de mensaje firmado con PGP y una clave pública PGP. Informa a los usuarios de que los contactos de Jabber y Session son temporales, mientras que la huella digital PGP debe considerarse la credencial permanente para verificar futuros mensajes.
CafeDread promocionado como foro de reemplazo
La misma publicación promociona un nuevo foro llamado CafeDread e invita a los usuarios a registrarse. Indica que tanto las tiendas como los usuarios pueden crear sus propios foros e hilos de discusión, incluidas áreas VIP ocultas para personas seleccionadas.
El mensaje también señala que la dirección conocida de Dread podría mostrar aleatoriamente el foro original o el nuevo proyecto, lo que sugiere algún tipo de conflicto de dominio, réplica o enrutamiento. You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login no ha confirmado de forma independiente la causa técnica.
Captura de pantalla de la publicación fijada en Dread2 que afirmaba que el foro había sido hackeado; en ella, los operadores declaraban controlar las claves del dominio de Dread y promocionaban CafeDread como foro sustituto
Por el momento, los usuarios deben abordar con cautela todos los anuncios, sitios espejo y enlaces de reemplazo relacionados con Dread. Si las afirmaciones son ciertas, es posible que los operadores de Dread hayan perdido el control de la infraestructura clave utilizada para generar confianza entre los usuarios. Si no lo son, el incidente podría implicar, aun así, una suplantación convincente o un compromiso parcial del sistema.
Hasta que los operadores originales de Dread confirmen que mantienen el control a través de un canal de confianza, los usuarios deben evitar iniciar sesión a través de nuevos sitios espejo, seguir enlaces de reemplazo o confiar en mensajes privados que afirmen representar al foro.
En el momento de redactar este texto, el foro Dread se encontraba fuera de servicio.
Actualización:
Tras la publicación, se encontró un anuncio más reciente de Dread titulado «Informe de transparencia de Dread: 5 de octubre de 2026: Dread "hackeado"», publicado por la cuenta HugBunter dos días antes.
En dicha publicación, el operador de Dread afirmó que los servidores del foro no habían sido vulnerados, que no se había accedido a los datos de los usuarios y que la infraestructura del servidor permanecía protegida.
El mensaje indicaba que el problema se debía a una clave privada «onion» que se había incluido por error en un archivo actualizado del software GoBalance.
Según el comunicado, el dominio afectado debía considerarse retirado, ya que cualquier persona en posesión de la clave privada podría utilizarla, generando riesgos de ataques de intermediario (*man-in-the-middle*). Desde entonces ha aparecido una nueva dirección «onion» de Dread, pero Hackread[.]com no publicará dicha URL.
Fuente:
HackRead
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
#24
Noticias Informáticas / Exploit para una vulnerabilida...
Último mensaje por AXCESS - Octubre 09, 2026, 04:05:58 PMYou are not allowed to view links.
You are not allowed to view links.
Register or Login or You are not allowed to view links.
Register or Login
Investigadores de seguridad han publicado un exploit funcional para una vulnerabilidad de ejecución remota de código previa a la autenticación en AnyDesk para Linux, la cual otorga a los atacantes acceso root antes de que se apruebe la conexión.
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
AnyDesk corrigió la vulnerabilidad en la versión 8.0.3 el pasado mes de junio; sin embargo, el registro de cambios describía la solución simplemente como la corrección de un error que podía provocar un bloqueo del sistema, sin asignar un identificador CVE ni emitir un boletín de seguridad.
El exploit, denominado AnyPwn, aprovecha un desbordamiento de búfer en el área de memoria dinámica (*heap*) del protocolo de sesión de AnyDesk, una herramienta de escritorio remoto. El código se publicó en GitHub el 8 de octubre.
Se recomienda a los administradores actualizar AnyDesk para Linux, como mínimo, a la versión 8.0.3. La versión más reciente es la 8.1.0.
Lo que demuestra el exploit
El exploit publicado funciona únicamente a través de conexiones TCP directas en el puerto 7070.
El exploit es probabilístico: la disposición de la memoria dinámica (*heap*) debe situar un objeto objetivo junto al búfer desbordado; de lo contrario, el servicio se bloquea en lugar de ejecutar el comando del atacante. Los desplazamientos (*offsets*) del código publicado están dirigidos a una compilación específica de AnyDesk para Linux (la versión 8.0.2); otras compilaciones requerirían valores distintos.
Los investigadores afirman que también es posible acceder a la misma ruta de código vulnerable a través de los servidores de retransmisión (*relay servers*) de AnyDesk, los cuales utiliza el software cuando no hay una conexión directa disponible. Validaron este hecho mediante un activador de instrumentación con Frida, pero no demostraron la cadena completa de explotación a través de dichas retransmisiones.
En junio, AnyDesk declaró que la vulnerabilidad se limitaba a "conexiones directas en Linux (conexiones que no pasan por nuestros servidores de retransmisión). Windows y macOS no se ven afectados".
El *exploit* está dirigido a la versión 8.0.2 de AnyDesk para Linux. Los investigadores sugieren que versiones anteriores, como la 8.0.1, podrían compartir la misma ruta de código vulnerable, aunque no se ha confirmado la explotación en dichas versiones.
Los investigadores dieron a conocer la vulnerabilidad el 22 de junio. AnyDesk la reconoció al día siguiente y lanzó la versión 8.0.3 con la corrección.
A fecha de 9 de octubre, no se ha asignado ningún identificador CVE a la vulnerabilidad. AnyDesk no ha emitido ningún aviso de seguridad formal.
La página de descargas de AnyDesk ya no incluye la versión 8.0.2, aunque esta sigue apareciendo en el registro de cambios. "El proveedor parece haber eliminado (?) la compilación 8.0.2 de AnyDesk tras la publicación de nuestro vídeo de prueba de concepto (PoC)", señalaron los investigadores.
Los administradores que no puedan actualizar el software de inmediato pueden reducir la exposición restringiendo el acceso al puerto TCP 7070. Aún no se ha determinado si la vulnerabilidad es totalmente explotable a través de conexiones de retransmisión.
Cómo funciona la vulnerabilidad
El protocolo de sesión de AnyDesk utiliza paquetes de flujo de datos de modo 5. El controlador calcula el tamaño de la asignación de memoria subyacente sumando una cabecera de 16 bytes a la longitud declarada de la carga útil, empleando aritmética de 32 bits sin comprobación de desbordamiento.
El *exploit* declara una longitud de carga útil de 0xFFFFFFF0. Al sumar 0x10, el resultado de 32 bits vuelve a cero, por lo que el asignador reserva un búfer diminuto mientras el objeto registra la longitud original (que es grande). En consecuencia, basta con escribir un solo byte de datos del atacante para sobrepasar el límite de la memoria asignada.
El desbordamiento corrompe campos de objetos adyacentes en el *heap*, y el *exploit* utiliza una cadena ROP para ejecutar un comando arbitrario con privilegios de *root*.
La vulnerabilidad fue descubierta por Rick de Jager, del equipo de seguridad de V12, utilizando V12, un motor de revisión de código de seguridad. Los fundadores de V12 crearon anteriormente la empresa de seguridad Zellic y lideraron el equipo de hacking competitivo Perfect Blue.
Otra vulnerabilidad de desbordamiento de búfer en el *heap* de AnyDesk, identificada como CVE-2025-27918, se corrigió en la versión 7.0.0 en abril de 2025. Dicha vulnerabilidad afectaba a todas las plataformas de AnyDesk e implicaba un desbordamiento de enteros en el procesamiento de imágenes de usuario, un mecanismo distinto al fallo en el protocolo de sesión de AnyPwn.
AnyDesk sufrió un hackeo a principios de 2024 en un incidente independiente en el que se vulneraron los sistemas de producción de la empresa, lo que provocó la revocación de certificados y el restablecimiento obligatorio de contraseñas.
Fuente:
The Hacker News
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
Investigadores de seguridad han publicado un exploit funcional para una vulnerabilidad de ejecución remota de código previa a la autenticación en AnyDesk para Linux, la cual otorga a los atacantes acceso root antes de que se apruebe la conexión.
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
AnyDesk corrigió la vulnerabilidad en la versión 8.0.3 el pasado mes de junio; sin embargo, el registro de cambios describía la solución simplemente como la corrección de un error que podía provocar un bloqueo del sistema, sin asignar un identificador CVE ni emitir un boletín de seguridad.
El exploit, denominado AnyPwn, aprovecha un desbordamiento de búfer en el área de memoria dinámica (*heap*) del protocolo de sesión de AnyDesk, una herramienta de escritorio remoto. El código se publicó en GitHub el 8 de octubre.
Se recomienda a los administradores actualizar AnyDesk para Linux, como mínimo, a la versión 8.0.3. La versión más reciente es la 8.1.0.
Lo que demuestra el exploit
El exploit publicado funciona únicamente a través de conexiones TCP directas en el puerto 7070.
El exploit es probabilístico: la disposición de la memoria dinámica (*heap*) debe situar un objeto objetivo junto al búfer desbordado; de lo contrario, el servicio se bloquea en lugar de ejecutar el comando del atacante. Los desplazamientos (*offsets*) del código publicado están dirigidos a una compilación específica de AnyDesk para Linux (la versión 8.0.2); otras compilaciones requerirían valores distintos.
Los investigadores afirman que también es posible acceder a la misma ruta de código vulnerable a través de los servidores de retransmisión (*relay servers*) de AnyDesk, los cuales utiliza el software cuando no hay una conexión directa disponible. Validaron este hecho mediante un activador de instrumentación con Frida, pero no demostraron la cadena completa de explotación a través de dichas retransmisiones.
En junio, AnyDesk declaró que la vulnerabilidad se limitaba a "conexiones directas en Linux (conexiones que no pasan por nuestros servidores de retransmisión). Windows y macOS no se ven afectados".
El *exploit* está dirigido a la versión 8.0.2 de AnyDesk para Linux. Los investigadores sugieren que versiones anteriores, como la 8.0.1, podrían compartir la misma ruta de código vulnerable, aunque no se ha confirmado la explotación en dichas versiones.
Los investigadores dieron a conocer la vulnerabilidad el 22 de junio. AnyDesk la reconoció al día siguiente y lanzó la versión 8.0.3 con la corrección.
A fecha de 9 de octubre, no se ha asignado ningún identificador CVE a la vulnerabilidad. AnyDesk no ha emitido ningún aviso de seguridad formal.
La página de descargas de AnyDesk ya no incluye la versión 8.0.2, aunque esta sigue apareciendo en el registro de cambios. "El proveedor parece haber eliminado (?) la compilación 8.0.2 de AnyDesk tras la publicación de nuestro vídeo de prueba de concepto (PoC)", señalaron los investigadores.
Los administradores que no puedan actualizar el software de inmediato pueden reducir la exposición restringiendo el acceso al puerto TCP 7070. Aún no se ha determinado si la vulnerabilidad es totalmente explotable a través de conexiones de retransmisión.
Cómo funciona la vulnerabilidad
El protocolo de sesión de AnyDesk utiliza paquetes de flujo de datos de modo 5. El controlador calcula el tamaño de la asignación de memoria subyacente sumando una cabecera de 16 bytes a la longitud declarada de la carga útil, empleando aritmética de 32 bits sin comprobación de desbordamiento.
El *exploit* declara una longitud de carga útil de 0xFFFFFFF0. Al sumar 0x10, el resultado de 32 bits vuelve a cero, por lo que el asignador reserva un búfer diminuto mientras el objeto registra la longitud original (que es grande). En consecuencia, basta con escribir un solo byte de datos del atacante para sobrepasar el límite de la memoria asignada.
El desbordamiento corrompe campos de objetos adyacentes en el *heap*, y el *exploit* utiliza una cadena ROP para ejecutar un comando arbitrario con privilegios de *root*.
La vulnerabilidad fue descubierta por Rick de Jager, del equipo de seguridad de V12, utilizando V12, un motor de revisión de código de seguridad. Los fundadores de V12 crearon anteriormente la empresa de seguridad Zellic y lideraron el equipo de hacking competitivo Perfect Blue.
Otra vulnerabilidad de desbordamiento de búfer en el *heap* de AnyDesk, identificada como CVE-2025-27918, se corrigió en la versión 7.0.0 en abril de 2025. Dicha vulnerabilidad afectaba a todas las plataformas de AnyDesk e implicaba un desbordamiento de enteros en el procesamiento de imágenes de usuario, un mecanismo distinto al fallo en el protocolo de sesión de AnyPwn.
AnyDesk sufrió un hackeo a principios de 2024 en un incidente independiente en el que se vulneraron los sistemas de producción de la empresa, lo que provocó la revocación de certificados y el restablecimiento obligatorio de contraseñas.
Fuente:
The Hacker News
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
#25
Noticias Informáticas / Anthropic lanza escáner de vul...
Último mensaje por AXCESS - Octubre 09, 2026, 04:03:12 PM
El jueves, Anthropic presentó OSS Scanner, una herramienta de escaneo de vulnerabilidades de participación voluntaria diseñada para ayudar a proteger el ecosistema de código abierto mediante inteligencia artificial (IA).
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
"Se trata de un servicio de participación voluntaria que se basa en nuestra experiencia utilizando Claude para detectar vulnerabilidades durante el proyecto Glasswing", señaló Anthropic. "Los proyectos que se unan recibirán análisis de seguridad exhaustivos y periódicos realizados por nuestros modelos más potentes, sin coste alguno".
Anthropic también destacó que los resultados del escáner serán generados íntegramente por los modelos y no requerirán revisión ni clasificación manual, lo que facilitará la realización de análisis más rápidos y frecuentes. Se prevé que estos informes sean generados por sus modelos más avanzados, incluido Claude Mythos.
La empresa indicó que espera utilizar criterios similares a los de OSS-Fuzz de Google para seleccionar los proyectos, aunque subrayó que dicho proceso podría evolucionar con el tiempo. Se recomienda a los responsables de mantenimiento de los proyectos que proporcionen una breve descripción explicando la importancia de su iniciativa en aquellos casos en los que esta "no resulte evidente por sí misma".
Los mantenedores principales de un proyecto pueden inscribirse enviando una *pull request* al repositorio de GitHub de OSS Scanner, acompañada de un archivo de configuración YAML que proporcione la siguiente información:
Enlace al repositorio Git que debe clonarse.
Dirección de correo electrónico del contacto principal.
Ruta (relativa al repositorio) al Dockerfile que configura el entorno, preinstala todas las dependencias y compila el proyecto para permitir que un agente sin conexión realice la auditoría de seguridad.
"El Dockerfile configura el entorno en el que se ejecutará el proyecto e instala todas las dependencias para que el agente pueda realizar su auditoría de seguridad sin necesidad de acceso a Internet", señaló Anthropic. "Recomendamos verificar que los casos de prueba se ejecuten correctamente dentro del contenedor compilado".
A continuación, se detallan otros datos opcionales que pueden incluirse en el archivo YAML:
Direcciones de correo electrónico adicionales para recibir copia (CC) de todos los informes.
Página de inicio del proyecto.
Clave pública GPG para cifrar los correos electrónicos con los informes.
Ruta (relativa al repositorio) a un archivo de modelo de amenazas ("threat_model.md") que especifique qué código debe analizarse, la clasificación de vulnerabilidades o los formatos de los informes.
Opción para no recibir informes de errores estableciendo el parámetro "disabled: true".
Hasta el momento de redactar este texto, se han enviado un total de 116 *pull requests*. A diferencia de otros programas de notificación de vulnerabilidades, Anthropic declaró que no tiene intención de imponer un plazo de divulgación de 90 días para los hallazgos, dado el riesgo de que contengan falsos positivos.
"Si posteriormente validamos manualmente uno de estos informes a través de nuestro programa CVD existente, podríamos divulgarlo conforme a nuestra política de CVD, comenzando a contar 90 días desde el momento en que se le notifique que un humano ha validado dicho informe", añadió la empresa. "A medida que ganemos confianza en el rendimiento de OSS Scanner, es posible que en el futuro establezcamos un plazo de divulgación para ciertos informes de vulnerabilidades de alta gravedad".
La empresa de IA informó que ha identificado más de 29.000 posibles vulnerabilidades en algunos de los proyectos de software más importantes del mundo; de ellas, algo más de 6.000 fallos han sido comunicados a los responsables de su mantenimiento. Esto ha dado lugar a la emisión de 584 avisos de seguridad a fecha del 2 de octubre de 2026.
Este avance se produce al mismo tiempo que Anthropic presenta el Programa de Defensa de Infraestructuras Críticas (*Critical Infrastructure Defense Program*), destinado a proteger las infraestructuras críticas y el software de código abierto como parte de su "Misión Cibernética" (*Cyber Mission*).
Dado que la IA facilita cada vez más a los actores maliciosos el descubrimiento y la explotación de vulnerabilidades, la automatización de diversas fases de las operaciones cibernéticas y la ejecución de ataques a mayor velocidad y escala, el objetivo de esta iniciativa es dotar a los defensores de las herramientas adecuadas para combatir la amenaza, acelerar la implementación de correcciones y explorar nuevas arquitecturas y prácticas de programación seguras.
"Nuestra previsión es que, en un plazo de dos años, la IA favorecerá la defensa: resultará más sencillo detectar errores antes del lanzamiento, desarrollar software intrínsecamente seguro desde cero y defender activamente los sistemas mediante modelos", afirmó Anthropic.
Fuente:
The Hacker News
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
#26
Noticias Informáticas / Error crítico en Telegram Desk...
Último mensaje por AXCESS - Octubre 09, 2026, 03:29:14 PMYou are not allowed to view links.
You are not allowed to view links.
Register or Login or You are not allowed to view links.
Register or Login
Se ha descubierto una vulnerabilidad grave en Telegram Desktop en versiones anteriores a la 7.2.9, lanzada el 17 de septiembre de 2026.
«Alguien te añade a un grupo de Telegram. Aparece un enlace en el chat. Haces clic en él y tu cuenta de Telegram deja de ser exclusivamente tuya», afirmó un investigador de seguridad que utiliza el alias BeakSEK.
El investigador explica en GitHub que las versiones vulnerables de la aplicación Telegram Desktop no gestionan correctamente ciertos caracteres en los enlaces: no escapan los puntos y coma. La propia aplicación Telegram utiliza el carácter de punto y coma ( ; ) para separar instrucciones.
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
Los atacantes pueden aprovechar esto para añadir comandos maliciosos en enlaces `tg://` especialmente manipulados. Por ejemplo, un atacante puede enviar un enlace con comandos maliciosos separados por puntos y coma, y la aplicación los interpreta como comandos legítimos.
El segundo defecto radica en el alcance del comando inyectado.
Los atacantes solo tienen a su disposición cuatro comandos, y tres de ellos son inofensivos.
«Los atacantes pueden acceder al controlador del esquema *interpret:* para cargar archivos locales —incluidas las claves de sesión *tdata*— a un canal controlado por el atacante, lo que permite la toma de control de la cuenta», señala la descripción en la Base de Datos Nacional de Vulnerabilidades del NIST.
La función interna *interpret:* puede ejecutar una acción privilegiada: leer cualquier archivo del disco y enviarlo a un chat sin solicitar confirmación alguna.
Esta herramienta fue diseñada para uso interno y de confianza por parte de los desarrolladores de Telegram, pero no verificaba quién solicitaba la acción.
La vulnerabilidad tiene una puntuación de 8,6 sobre 10 en la escala de gravedad CVSS y se le ha asignado el identificador CVE-2026-10718.
La versión más reciente de Telegram es la 7.3, lanzada el 9 de octubre con una única palabra en las notas de la versión: «Money» (Dinero).
¿Cómo sería un ataque real?
El investigador detalló una prueba de concepto en la que un atacante crea un "supergrupo" en Telegram y añade a las víctimas, algo que permiten los ajustes de privacidad predeterminados de la aplicación.
Dentro del grupo, el atacante publica tres archivos de texto (.txt) con instrucciones diseñadas específicamente, los cuales Telegram descarga automáticamente en los equipos de las víctimas.
"Telegram Desktop, en su configuración predeterminada, descarga automáticamente los archivos recibidos en grupos siempre que no superen los 8 MiB (mebibytes),"
explica el investigador.
A continuación, el atacante publica un enlace que parece inofensivo, pero que en realidad redirige a un enlace malicioso con el protocolo `tg:` que contiene comandos inyectados.
Si una víctima hace clic en él, su sistema iniciará un segundo proceso de Telegram y se ejecutarán los comandos. La aplicación de Telegram filtrará archivos que permitirán al atacante recuperar la sesión y la cuenta de la víctima.
Los tres archivos de instrucciones especifican qué archivos deben exfiltrarse: la clave de cifrado local, los datos de autorización de la sesión y el índice de los datos almacenados de la cuenta. El uso de rutas relativas permite localizar los archivos de destino sin necesidad de conocer el nombre de usuario de Windows de la víctima.
Así, el atacante puede simplemente colocar los archivos robados en una nueva instancia de Telegram y restaurar la sesión de la víctima, siempre y cuando no se haya establecido un código de acceso local.
BeakSec insta a los usuarios a actualizar las aplicaciones de Telegram Desktop a la última versión disponible y a limitar quién puede añadirlos a grupos. El investigador también recomienda establecer un código de acceso local y activar la opción de preguntar dónde guardar cada archivo, ya que esto impide las descargas automáticas.
Fuente:
CyberNews
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
Se ha descubierto una vulnerabilidad grave en Telegram Desktop en versiones anteriores a la 7.2.9, lanzada el 17 de septiembre de 2026.
«Alguien te añade a un grupo de Telegram. Aparece un enlace en el chat. Haces clic en él y tu cuenta de Telegram deja de ser exclusivamente tuya», afirmó un investigador de seguridad que utiliza el alias BeakSEK.
El investigador explica en GitHub que las versiones vulnerables de la aplicación Telegram Desktop no gestionan correctamente ciertos caracteres en los enlaces: no escapan los puntos y coma. La propia aplicación Telegram utiliza el carácter de punto y coma ( ; ) para separar instrucciones.
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
Los atacantes pueden aprovechar esto para añadir comandos maliciosos en enlaces `tg://` especialmente manipulados. Por ejemplo, un atacante puede enviar un enlace con comandos maliciosos separados por puntos y coma, y la aplicación los interpreta como comandos legítimos.
El segundo defecto radica en el alcance del comando inyectado.
Los atacantes solo tienen a su disposición cuatro comandos, y tres de ellos son inofensivos.
«Los atacantes pueden acceder al controlador del esquema *interpret:* para cargar archivos locales —incluidas las claves de sesión *tdata*— a un canal controlado por el atacante, lo que permite la toma de control de la cuenta», señala la descripción en la Base de Datos Nacional de Vulnerabilidades del NIST.
La función interna *interpret:* puede ejecutar una acción privilegiada: leer cualquier archivo del disco y enviarlo a un chat sin solicitar confirmación alguna.
Esta herramienta fue diseñada para uso interno y de confianza por parte de los desarrolladores de Telegram, pero no verificaba quién solicitaba la acción.
La vulnerabilidad tiene una puntuación de 8,6 sobre 10 en la escala de gravedad CVSS y se le ha asignado el identificador CVE-2026-10718.
La versión más reciente de Telegram es la 7.3, lanzada el 9 de octubre con una única palabra en las notas de la versión: «Money» (Dinero).
¿Cómo sería un ataque real?
El investigador detalló una prueba de concepto en la que un atacante crea un "supergrupo" en Telegram y añade a las víctimas, algo que permiten los ajustes de privacidad predeterminados de la aplicación.
Dentro del grupo, el atacante publica tres archivos de texto (.txt) con instrucciones diseñadas específicamente, los cuales Telegram descarga automáticamente en los equipos de las víctimas.
"Telegram Desktop, en su configuración predeterminada, descarga automáticamente los archivos recibidos en grupos siempre que no superen los 8 MiB (mebibytes),"
explica el investigador.
A continuación, el atacante publica un enlace que parece inofensivo, pero que en realidad redirige a un enlace malicioso con el protocolo `tg:` que contiene comandos inyectados.
Si una víctima hace clic en él, su sistema iniciará un segundo proceso de Telegram y se ejecutarán los comandos. La aplicación de Telegram filtrará archivos que permitirán al atacante recuperar la sesión y la cuenta de la víctima.
Los tres archivos de instrucciones especifican qué archivos deben exfiltrarse: la clave de cifrado local, los datos de autorización de la sesión y el índice de los datos almacenados de la cuenta. El uso de rutas relativas permite localizar los archivos de destino sin necesidad de conocer el nombre de usuario de Windows de la víctima.
Así, el atacante puede simplemente colocar los archivos robados en una nueva instancia de Telegram y restaurar la sesión de la víctima, siempre y cuando no se haya establecido un código de acceso local.
BeakSec insta a los usuarios a actualizar las aplicaciones de Telegram Desktop a la última versión disponible y a limitar quién puede añadirlos a grupos. El investigador también recomienda establecer un código de acceso local y activar la opción de preguntar dónde guardar cada archivo, ya que esto impide las descargas automáticas.
Fuente:
CyberNews
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
#27
Noticias Informáticas / FBI arresta a otro hacker de S...
Último mensaje por AXCESS - Octubre 09, 2026, 03:27:08 PMYou are not allowed to view links.
You are not allowed to view links.
Register or Login or You are not allowed to view links.
Register or Login
El FBI ha detenido a otro presunto miembro del grupo de extorsión ShinyHunters, al que se considera implicado en la reciente vulneración de los sistemas del FBI, según anunció el viernes el director Kash Patel.
"Nuestros agentes sobre el terreno han detenido a otro presunto cómplice del grupo ShinyHunters, el grupo al que se atribuye la responsabilidad del reciente incidente en http://FBIjobs[.]gov, ocurrido en una plataforma gestionada por un proveedor externo", declaró Patel en X.
"Esta es la detención más reciente realizada por el FBI en cuestión de días en relación con esta red, mientras trabajamos sin descanso para desmantelar el grupo, seguir nuevas pistas y pruebas, y actuar con rapidez".
Aunque Patel no identificó al sospechoso ni reveló dónde se produjo la detención, *The New York Times* informa que se trata de un ciudadano canadiense arrestado en Pensilvania, considerado un cómplice principal en la intrusión.
Las autoridades no han revelado públicamente el nombre del sospechoso ni los cargos concretos que se le imputan.
Esta detención es la última de una serie de acciones policiales contra ShinyHunters tras la intrusión del grupo de hackers en los sistemas del FBI el mes pasado.
ShinyHunters declaró a *BleepingComputer* en septiembre que accedió a los sistemas del FBI explotando una supuesta vulnerabilidad de día cero en Oracle PeopleSoft, antes de realizar un movimiento lateral hacia la infraestructura AWS GovCloud gestionada por el FBI.
Los autores de la amenaza afirmaron haber robado entre 2 y 3 terabytes de datos, incluida información sobre empleados actuales y antiguos del FBI, candidatos a puestos de trabajo, historiales médicos y psiquiátricos, y registros internos de servicios.
Las muestras de datos compartidas con *BleepingComputer* y otros medios de comunicación confirmaron que la brecha expuso diversa información de los empleados, como domicilios particulares, números de la Seguridad Social, asignaciones laborales confidenciales, datos sobre familiares y otra información personal.
*The New York Times* también informa que un memorando interno del FBI indicaba que la agencia asumía que la brecha había afectado a todos los empleados.
Posteriormente, el FBI declaró que el incidente se originó en una plataforma gestionada por un contratista externo que no había instalado una actualización de seguridad. Desde el hackeo de FBIJobs, la agencia ha intensificado considerablemente la presión para identificar y capturar a la banda de extorsionadores ShinyHunters.
El 15 de septiembre, la policía holandesa detuvo a un hombre de 24 años residente en Ámsterdam como parte de una investigación sobre el grupo de hackers. El sospechoso fue identificado como Pepijn van der Stap, un hacker holandés conocido en línea anteriormente como "Umbreon".
ShinyHunters negó que van der Stap estuviera vinculado al grupo y declaró a BleepingComputer en aquel momento: "Ese individuo no tiene ninguna relación con nosotros. Francamente, nos hace gracia".
Poco después, el FBI tomó la inusual medida de advertir públicamente a los miembros de ShinyHunters que se entregaran, señalando que los investigadores seguían identificando a personas vinculadas al grupo.
"Las detenciones suelen cambiar quién está dispuesto a hablar, y la infraestructura incautada nos permite ver quiénes quedan", declaró entonces Brett Leatherman, subdirector de la División Cibernética del FBI.
"Cuanto más tiempo permanezcan en esto, más sabremos sobre ustedes. Saben cómo encontrarnos y nosotros sabemos cómo encontrarlos. Les sugiero que den el primer paso mientras aún pueden elegir".
Días más tarde, un presunto miembro de ShinyHunters conocido en línea como "Rey" fue detenido —según se informó— en Jordania y comenzó a colaborar con el FBI y con organismos internacionales encargados de hacer cumplir la ley.
Reuters informó que las autoridades jordanas detuvieron a Rey, identificado como Saif al-Din Khader, y que, según diversas fuentes, este estaba ayudando a los investigadores a localizar a otros presuntos miembros del grupo.
Por esa misma época, también empezaron a surgir indicios de desestabilización dentro de ShinyHunters.
El principal representante del grupo —quien se comunicaba habitualmente con BleepingComputer y otros periodistas, y conocía a fondo los ataques perpetrados por ShinyHunters en los últimos dos años— dejó de responder por Telegram el martes pasado.
Al parecer, dicha cuenta de Telegram ha sido eliminada.
Ese mismo representante siguió comunicándose con BleepingComputer tras la detención de van der Stap, lo que sugería que este último no era la persona que manejaba la cuenta. Casi al mismo tiempo que la detención de Rey, otro presunto colaborador de ShinyHunters —que poseía información detallada sobre el hackeo al FBI— cerró una cuenta de mensajería en línea, y el sitio web del grupo destinado a la filtración de datos dejó de estar operativo.
Más tarde se lanzó un nuevo sitio de filtraciones de ShinyHunters, lo que sugería que al menos algunos miembros de la organización seguían activos.
No está claro si la desaparición del principal representante del grupo guarda relación con alguna de las detenciones recientes.
«Seguiremos colaborando estrechamente con nuestros socios para desmantelar lo que queda del grupo ShinyHunters y a sus colaboradores, independientemente de dónde operen», declaró Patel el viernes.
¿Quién es ShinyHunters?
ShinyHunters es un grupo de extorsión conocido por robar datos de aplicaciones web y plataformas SaaS basadas en la nube, para luego exigir pagos de rescate a las organizaciones víctimas bajo la amenaza de filtrar la información sustraída.
El nombre ShinyHunters se ha asociado con numerosos actores de amenazas involucrados en brechas de seguridad de datos que se remontan, al menos, a 2018.
En los últimos dos años, los hackers que operan bajo el nombre de ShinyHunters han intensificado su actividad, llevando a cabo campañas de robo de datos y extorsión contra organizaciones de todo el mundo.
Las campañas recientes han tenido como objetivo Salesforce y otros entornos SaaS en la nube; estos actores de amenazas están vinculados a brechas que afectaron a empresas como Google, Cisco, PornHub y el gigante de las citas en línea Match Group.
En algunos ataques, el grupo vulneró empresas de integración de terceros y robó tokens de autenticación que luego utilizaron para acceder a entornos SaaS conectados y sustraer datos de clientes.
Más recientemente, ShinyHunters ha realizado campañas de *vishing* (phishing de voz) dirigidas a cuentas de inicio de sesión único (SSO) de Okta, Microsoft y Google, suplantando al personal de soporte técnico para engañar a los empleados y lograr que introduzcan sus credenciales y códigos de autenticación multifactor (MFA) en sitios de phishing.
Tal como informó inicialmente BleepingComputer, el grupo también ha empleado ataques de *vishing* basados en códigos de dispositivo para robar tokens de autenticación de cuentas de Microsoft.
Una vez obtenidas las credenciales y los códigos de autenticación, los atacantes utilizan las cuentas SSO comprometidas para acceder a plataformas empresariales conectadas, incluidas Salesforce, Microsoft 365, Google Workspace, SAP, Slack, Adobe, Atlassian, Zendesk y Dropbox.
ShinyHunters también estuvo detrás de un ataque masivo de robo de datos contra Instructure Canvas en mayo, el cual provocó importantes interrupciones en el servicio de la plataforma. Posteriormente, Instructure llegó a un "acuerdo" con los actores de amenazas para evitar que publicaran los datos sustraídos durante la brecha.
Además de perpetrar sus propias intrusiones, ShinyHunters operó como un grupo de "extorsión como servicio", ayudando a otros actores de amenazas a extorsionar a organizaciones que habían sido comprometidas. A lo largo de los años, las fuerzas del orden han detenido a numerosos sospechosos en casos vinculados al nombre ShinyHunters, incluidos individuos relacionados con los ataques de robo de datos a Snowflake, las brechas de seguridad en PowerSchool y la operación del foro de piratería informática Breached v2.
A pesar de estas detenciones, los ciberdelincuentes siguieron operando bajo el nombre de ShinyHunters mientras llevaban a cabo ataques de robo de datos y extorsión contra organizaciones de todo el mundo.
Fuente:
BleepingComputer
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
El FBI ha detenido a otro presunto miembro del grupo de extorsión ShinyHunters, al que se considera implicado en la reciente vulneración de los sistemas del FBI, según anunció el viernes el director Kash Patel.
"Nuestros agentes sobre el terreno han detenido a otro presunto cómplice del grupo ShinyHunters, el grupo al que se atribuye la responsabilidad del reciente incidente en http://FBIjobs[.]gov, ocurrido en una plataforma gestionada por un proveedor externo", declaró Patel en X.
"Esta es la detención más reciente realizada por el FBI en cuestión de días en relación con esta red, mientras trabajamos sin descanso para desmantelar el grupo, seguir nuevas pistas y pruebas, y actuar con rapidez".
Aunque Patel no identificó al sospechoso ni reveló dónde se produjo la detención, *The New York Times* informa que se trata de un ciudadano canadiense arrestado en Pensilvania, considerado un cómplice principal en la intrusión.
Las autoridades no han revelado públicamente el nombre del sospechoso ni los cargos concretos que se le imputan.
Esta detención es la última de una serie de acciones policiales contra ShinyHunters tras la intrusión del grupo de hackers en los sistemas del FBI el mes pasado.
ShinyHunters declaró a *BleepingComputer* en septiembre que accedió a los sistemas del FBI explotando una supuesta vulnerabilidad de día cero en Oracle PeopleSoft, antes de realizar un movimiento lateral hacia la infraestructura AWS GovCloud gestionada por el FBI.
Los autores de la amenaza afirmaron haber robado entre 2 y 3 terabytes de datos, incluida información sobre empleados actuales y antiguos del FBI, candidatos a puestos de trabajo, historiales médicos y psiquiátricos, y registros internos de servicios.
Las muestras de datos compartidas con *BleepingComputer* y otros medios de comunicación confirmaron que la brecha expuso diversa información de los empleados, como domicilios particulares, números de la Seguridad Social, asignaciones laborales confidenciales, datos sobre familiares y otra información personal.
*The New York Times* también informa que un memorando interno del FBI indicaba que la agencia asumía que la brecha había afectado a todos los empleados.
Posteriormente, el FBI declaró que el incidente se originó en una plataforma gestionada por un contratista externo que no había instalado una actualización de seguridad. Desde el hackeo de FBIJobs, la agencia ha intensificado considerablemente la presión para identificar y capturar a la banda de extorsionadores ShinyHunters.
El 15 de septiembre, la policía holandesa detuvo a un hombre de 24 años residente en Ámsterdam como parte de una investigación sobre el grupo de hackers. El sospechoso fue identificado como Pepijn van der Stap, un hacker holandés conocido en línea anteriormente como "Umbreon".
ShinyHunters negó que van der Stap estuviera vinculado al grupo y declaró a BleepingComputer en aquel momento: "Ese individuo no tiene ninguna relación con nosotros. Francamente, nos hace gracia".
Poco después, el FBI tomó la inusual medida de advertir públicamente a los miembros de ShinyHunters que se entregaran, señalando que los investigadores seguían identificando a personas vinculadas al grupo.
"Las detenciones suelen cambiar quién está dispuesto a hablar, y la infraestructura incautada nos permite ver quiénes quedan", declaró entonces Brett Leatherman, subdirector de la División Cibernética del FBI.
"Cuanto más tiempo permanezcan en esto, más sabremos sobre ustedes. Saben cómo encontrarnos y nosotros sabemos cómo encontrarlos. Les sugiero que den el primer paso mientras aún pueden elegir".
Días más tarde, un presunto miembro de ShinyHunters conocido en línea como "Rey" fue detenido —según se informó— en Jordania y comenzó a colaborar con el FBI y con organismos internacionales encargados de hacer cumplir la ley.
Reuters informó que las autoridades jordanas detuvieron a Rey, identificado como Saif al-Din Khader, y que, según diversas fuentes, este estaba ayudando a los investigadores a localizar a otros presuntos miembros del grupo.
Por esa misma época, también empezaron a surgir indicios de desestabilización dentro de ShinyHunters.
El principal representante del grupo —quien se comunicaba habitualmente con BleepingComputer y otros periodistas, y conocía a fondo los ataques perpetrados por ShinyHunters en los últimos dos años— dejó de responder por Telegram el martes pasado.
Al parecer, dicha cuenta de Telegram ha sido eliminada.
Ese mismo representante siguió comunicándose con BleepingComputer tras la detención de van der Stap, lo que sugería que este último no era la persona que manejaba la cuenta. Casi al mismo tiempo que la detención de Rey, otro presunto colaborador de ShinyHunters —que poseía información detallada sobre el hackeo al FBI— cerró una cuenta de mensajería en línea, y el sitio web del grupo destinado a la filtración de datos dejó de estar operativo.
Más tarde se lanzó un nuevo sitio de filtraciones de ShinyHunters, lo que sugería que al menos algunos miembros de la organización seguían activos.
No está claro si la desaparición del principal representante del grupo guarda relación con alguna de las detenciones recientes.
«Seguiremos colaborando estrechamente con nuestros socios para desmantelar lo que queda del grupo ShinyHunters y a sus colaboradores, independientemente de dónde operen», declaró Patel el viernes.
¿Quién es ShinyHunters?
ShinyHunters es un grupo de extorsión conocido por robar datos de aplicaciones web y plataformas SaaS basadas en la nube, para luego exigir pagos de rescate a las organizaciones víctimas bajo la amenaza de filtrar la información sustraída.
El nombre ShinyHunters se ha asociado con numerosos actores de amenazas involucrados en brechas de seguridad de datos que se remontan, al menos, a 2018.
En los últimos dos años, los hackers que operan bajo el nombre de ShinyHunters han intensificado su actividad, llevando a cabo campañas de robo de datos y extorsión contra organizaciones de todo el mundo.
Las campañas recientes han tenido como objetivo Salesforce y otros entornos SaaS en la nube; estos actores de amenazas están vinculados a brechas que afectaron a empresas como Google, Cisco, PornHub y el gigante de las citas en línea Match Group.
En algunos ataques, el grupo vulneró empresas de integración de terceros y robó tokens de autenticación que luego utilizaron para acceder a entornos SaaS conectados y sustraer datos de clientes.
Más recientemente, ShinyHunters ha realizado campañas de *vishing* (phishing de voz) dirigidas a cuentas de inicio de sesión único (SSO) de Okta, Microsoft y Google, suplantando al personal de soporte técnico para engañar a los empleados y lograr que introduzcan sus credenciales y códigos de autenticación multifactor (MFA) en sitios de phishing.
Tal como informó inicialmente BleepingComputer, el grupo también ha empleado ataques de *vishing* basados en códigos de dispositivo para robar tokens de autenticación de cuentas de Microsoft.
Una vez obtenidas las credenciales y los códigos de autenticación, los atacantes utilizan las cuentas SSO comprometidas para acceder a plataformas empresariales conectadas, incluidas Salesforce, Microsoft 365, Google Workspace, SAP, Slack, Adobe, Atlassian, Zendesk y Dropbox.
ShinyHunters también estuvo detrás de un ataque masivo de robo de datos contra Instructure Canvas en mayo, el cual provocó importantes interrupciones en el servicio de la plataforma. Posteriormente, Instructure llegó a un "acuerdo" con los actores de amenazas para evitar que publicaran los datos sustraídos durante la brecha.
Además de perpetrar sus propias intrusiones, ShinyHunters operó como un grupo de "extorsión como servicio", ayudando a otros actores de amenazas a extorsionar a organizaciones que habían sido comprometidas. A lo largo de los años, las fuerzas del orden han detenido a numerosos sospechosos en casos vinculados al nombre ShinyHunters, incluidos individuos relacionados con los ataques de robo de datos a Snowflake, las brechas de seguridad en PowerSchool y la operación del foro de piratería informática Breached v2.
A pesar de estas detenciones, los ciberdelincuentes siguieron operando bajo el nombre de ShinyHunters mientras llevaban a cabo ataques de robo de datos y extorsión contra organizaciones de todo el mundo.
Fuente:
BleepingComputer
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
#28
Noticias Informáticas / Microsoft: actualización KB512...
Último mensaje por AXCESS - Octubre 09, 2026, 03:24:29 PM
Microsoft confirmó durante el fin de semana que algunos juegos y aplicaciones que utilizan la decodificación de audio AC-3 (Dolby Digital) sufrirán cierres inesperados tras instalar la actualización preliminar KB5124010 de Windows 11, correspondiente a septiembre de 2026.
La KB5124010 es una actualización opcional que requiere que los usuarios hagan clic en el enlace "Descargar e instalar", lo cual debería reducir el número de usuarios de Windows potencialmente afectados. Sin embargo, se instala automáticamente en dispositivos que ejecutan Windows 11 24H2 y tienen activada la opción "Obtener las últimas actualizaciones tan pronto como estén disponibles".
"En algunos casos, la aplicación puede no iniciarse o cerrarse sin previo aviso. En otros, la aplicación funcionará con normalidad hasta que se utilicen ciertas funciones, como la reproducción de música", señaló Microsoft el viernes en una actualización del panel de estado de versiones de Windows. "Las aplicaciones afectadas pueden variar e incluir juegos, reproductores multimedia y ciertas aplicaciones de productividad".
No obstante, la compañía añadió que muchas aplicaciones modernas no utilizan Windows para este tipo de codificación y no se ven afectadas. Además, el componente de código que provoca estos fallos se utiliza principalmente en aplicaciones heredadas (*legacy*) que aún emplean la decodificación de audio integrada de Windows, mientras que las aplicaciones modernas que utilizan el códec AC-3 heredado suelen incluir sus propios componentes de decodificación de audio.
Aunque no ofreció un plazo estimado para una solución, Microsoft está trabajando para resolver este problema y comunicó que compartirá más información en una futura actualización.
El mes pasado, Microsoft lanzó actualizaciones de emergencia para corregir otro problema conocido que causaba fallos de audio USB, así como errores en los Servicios de Escritorio remoto y problemas con Hyper-V tras instalar las actualizaciones de seguridad KB5124008 y KB5124012 de septiembre de 2026.
El año pasado, la compañía solucionó un problema similar en enero que provocaba fallos en la reproducción de audio y errores de "Código 10" en sistemas Windows 11 24H2 con controladores de dispositivos de audio USB; asimismo, levantó un bloqueo de seguridad que impedía las actualizaciones y causaba un mal funcionamiento de auriculares y altavoces Bluetooth en sistemas con el software de mejora de audio Dirac. Hace dos años, también se confirmó un problema que provocaba que el audio del juego aumentara inesperadamente al volumen máximo al utilizar sistemas de sonido con DAC USB, y que bloqueaba las actualizaciones a Windows 24H2 en sistemas con controladores de audio Intel Smart Sound Technology (SST) incompatibles debido a errores de pantalla azul de la muerte (BSOD).
Fuente:
BleepingComputer
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
#29
Noticias Informáticas / Google suspende su programa de...
Último mensaje por AXCESS - Octubre 09, 2026, 03:22:14 PM
Google ha suspendido temporalmente la recepción de envíos para su Programa de Recompensas por Vulnerabilidades en Software de Código Abierto (OSS VRP) tras verse inundado por informes generados mediante inteligencia artificial.
El programa OSS VRP de la compañía incentiva a los investigadores de seguridad a divulgar de manera responsable fallos de seguridad en proyectos de código abierto mantenidos por Google —incluidos Golang, Angular, Bazel, Protocol Buffers, Fuchsia y dependencias críticas de terceros—, así como en configuraciones de repositorios como GitHub Actions, configuraciones de aplicaciones y reglas de control de acceso.
Google lanzó el OSS VRP en agosto de 2022 con recompensas que oscilaban entre los 100 y los 31.337 dólares, señalando que el programa se centraría en los fallos de seguridad con mayor impacto en la cadena de suministro de software.
"Hemos dejado de aceptar temporalmente envíos de vulnerabilidades de productos para el OSS VRP. Esto no afecta a los informes sobre la cadena de suministro del OSS VRP ni a los informes pendientes", declaró la empresa. "¿Por qué ocurre esto? Esta pausa se debe a un aumento significativo de los envíos automatizados, la gran mayoría de los cuales no son válidos".
No obstante, los investigadores aún pueden enviar parches de seguridad para software de código abierto a través del Programa de Recompensas por Parches de Google (que ofrece incentivos de hasta 15.000 dólares por correcciones de alto impacto) y reportar vulnerabilidades en repositorios de código abierto de Google Cloud que afecten a productos de Cloud mediante el programa Cloud VRP de la compañía.
Google añadió que actualmente está trabajando en reajustar el OSS VRP para abordar los problemas relacionados con los envíos automatizados, y que ofrecerá más información sobre los cambios el próximo año.
"Seguiremos reformulando y trabajando en este aspecto del OSS VRP y nos comprometemos a ofrecer una actualización en el primer trimestre de 2027", agregó Google en un comunicado en el sitio web Bug Hunters. "Mientras tanto, les animamos a buscar vulnerabilidades de impacto en nuestros otros programas VRP y enviarlas allí, o bien a participar en el Programa de Recompensas por Parches. Este cambio no afecta a las vulnerabilidades de productos enviadas antes del 1 de octubre de 2026".
Desde el lanzamiento de su primer programa de recompensas por vulnerabilidades (VRP) en 2010, Google ha recompensado a miles de investigadores de seguridad con más de 81,6 millones de dólares. En 2025, otorgó una cifra récord de 17,1 millones de dólares a más de 700 investigadores, lo que supone un aumento del 40 % con respecto a 2024, año en el que repartió un total de 12 millones.
Google no es la primera empresa que cierra un programa de recompensas por errores en el último año debido a la incesante avalancha de informes de baja calidad generados por inteligencia artificial.
En enero, el responsable de mantenimiento de la utilidad de línea de comandos y biblioteca *curl* puso fin al programa de recompensas por fallos de seguridad en HackerOne, tras verse desbordado por un flujo masivo de informes de vulnerabilidades de ínfima calidad generados por IA.
Más recientemente, a mediados de septiembre, Intel también eliminó todas las recompensas económicas por fallos de seguridad en su *software*, *firmware*, *hardware* y servicios notificados a través de su programa en Intigriti. Sin embargo, Intel aún no ha explicado esta decisión.
Aunque todavía no ha adoptado una medida similar, Microsoft advirtió en mayo que las herramientas de IA facilitan ahora la detección de muchas más vulnerabilidades, lo que provocará que "el ritmo y el alcance del descubrimiento de vulnerabilidades [...] aumenten en toda la industria del *software*" y "puedan incrementar las exigencias operativas".
El mes pasado, Microsoft publicó parches para una cifra récord de 966 fallos, incluidas dos vulnerabilidades de día cero que estaban siendo explotadas activamente.
Fuente:
BleepingComputer
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
#30
Dudas y pedidos generales / Porque se habla tanto de QA?
Último mensaje por Crb3n - Octubre 09, 2026, 10:30:44 AMHola muy buenas a todos, soy Cris un simple usuario del foro que después de muchísimos años de inactividad volvió y con muchas ganas de aprender, soy técnico en TI, estudie parcialmente desarrollo full stack pero nunca lo concluí, ahora comencé a estudiar ciberseguridad por cuenta propia en busca de crecer en alguna rama de tecnología para dedicarme laboralmente, al entrar al foro donde en su momento aprendí bastantes cosas, me di cuenta que se habla mucho de QA y me encantaría si alguno podría decirme si actualmente es una buena área para dedicarse y si tiene buena salida labora. un saludo a todos un gusto volver a este foro con mucha gente que se dedica a compartir sus conocimientos 
