EDRChoker: bloquea los procesos del EDR mediante QoS

Una nueva herramienta de código abierto para pruebas de penetración, llamada EDRChoker, introduce una técnica innovadora para silenciar agentes de detección y respuesta de endpoints (EDR) conectados a la nube, no mediante la eliminación de sus procesos ni la inyección de código, sino reduciendo silenciosamente su ancho de banda de red a casi cero utilizando el motor de calidad de servicio (QoS) basado en políticas nativo de Windows.

Desarrollada por el investigador de seguridad @TwoSevenOneT, la herramienta aprovecha la calidad de servicio (QoS) basada en políticas de Windows para limitar el ancho de banda de los procesos EDR a casi cero, aislándolos eficazmente de su infraestructura de comandos.

Las plataformas EDR modernas dependen de una conexión persistente y de baja latencia entre el agente de endpoint y un servidor de administración en la nube. Esta relación con el servidor es fundamental para la recopilación de telemetría, la correlación de amenazas y el control administrativo.

Herramienta EDRChoker

Al interrumpir esta conexión, el agente EDR queda inactivo, incapaz de informar sobre detecciones, recibir políticas actualizadas o aceptar comandos remotos de los administradores. Esta dependencia arquitectónica es precisamente lo que EDRChoker aprovecha.

Históricamente, los equipos rojos han utilizado dos métodos principales para interrumpir las comunicaciones EDR: las reglas del Firewall de Windows Defender y las llamadas a la API de la Plataforma de Filtrado de Windows (WFP).

Herramientas como EDRSilencer utilizan la API FwpmFilterAdd0 para registrar filtros de red salientes que descartan selectivamente los paquetes del agente EDR.

La limitación crítica es que el bloqueo basado en WFP, con visibilidad forense, genera eventos de bloqueo y descarte de paquetes que las plataformas de seguridad como Elastic Defend detectan activamente mediante reglas de detección específicas, lo que genera alertas inmediatas en la categoría de reglas de Evasión Potencial mediante la Plataforma de Filtrado de Windows.

New-NetQosPolicy -Name "EDRProcess_" -AppPathNameMatchCondition "agent.exe"
-ThrottleRateActionBitsPerSecond 8 -PolicyStore ActiveStore

A 8 bps, un protocolo de enlace TLS estándar, que requiere entre 3 KB y 6 KB de datos de la cadena de certificados, se vuelve imposible de completar. El agente EDR agota continuamente el tiempo de espera antes de intercambiar un solo paquete, lo que produce errores de conexión interrumpida en lugar de eventos de bloqueo del firewall detectables.

La ventaja técnica de EDRChoker es arquitectónica. La limitación de QoS se aplica mediante pacer.sys, un controlador de filtro ligero NDIS que opera directamente sobre la NIC física, una capa por debajo de WFP en la pila de red de Windows. El orden de la pila es importante:

• WFP se ubica dentro de tcpip.sys en la capa de transporte.
• pacer.sys intercepta tramas Ethernet sin procesar en el límite de NDIS, más cerca del hardware.
• Debido a que opera en un nivel de privilegio inferior en la pila, las reglas de pacer.sys rigen paquetes a los que las herramientas de monitorización EDR de nivel WFP nunca llegan.

El investigador @TwoSevenOneT afirmó que EDRChoker acepta un archivo de entrada con los nombres de los procesos EDR y genera automáticamente políticas de QoS con nombres únicos (nombre del proceso + GUID aleatorio por ejecución) para garantizar que no haya dos implementaciones que produzcan firmas de reglas idénticas.

La herramienta, disponible en GitHub, funciona en dos modos:

• Modo de eliminación: Se ejecuta sin parámetros para eliminar por completo todas las políticas de QoS instaladas.
• Modo de instalación: Acepta un archivo de entrada con los nombres de los procesos EDR y crea políticas de QoS con nombres únicos (nombre del proceso + GUID aleatorio) que se mantienen incluso después de reiniciar el sistema.

A principios de enero, el investigador también demostró EDRStartupHinder, que impide que se inicie un programa EDR. EDRStartupHinder pretende explotar la vulnerabilidad Bindlink de Windows para redirigir una DLL de System32 a otra ubicación, además de aprovechar la función que solo carga DLL firmadas por un programa protegido con Protected Process Light (PPL) para evitar que se inicien los servicios AV/EDR", explicó el investigador.

Otra técnica ideada por Binary Defense consiste en deshabilitar servicios de seguridad críticos, como Windows Defender y Sysmon, sin activar las alertas de malware tradicionales. Modifica las Listas de Control de Acceso (ACL) de Windows para agregar Entradas de Control de Acceso (ACE) de "Denegar" contra bibliotecas esenciales del sistema como "kernel32.dll". Dado que estos servicios dependen de la DLL para funcionar, se rompe la cadena de dependencias. Al reiniciar el sistema, los servicios protegidos no se inician, dejando el equipo sin ninguna defensa.

La técnica EDRChoker pone de manifiesto una realidad arquitectónica crucial: las herramientas EDR que dependen totalmente de la conectividad en la nube presentan un punto único de fallo inherente.

A medida que los atacantes profundizan en la pila de red de Windows para evadir la detección, los defensores deben extender la monitorización al mismo nivel o corren el riesgo de operar a ciegas precisamente cuando más importa.

Fuente: CyberSecurityNews

Seguir leyendo...

Ataque AirSnitch evita el cifrado de Wi-Fi

Es difícil exagerar el papel que desempeña el Wi-Fi en prácticamente todos los aspectos de la vida. La organización que gestiona el protocolo inalámbrico afirma que se han distribuido más de 48 mil millones de dispositivos con Wi-Fi desde su debut a finales de la década de 1990. Se estima que el número de usuarios individuales es de 6 mil millones, aproximadamente el 70 % de la población mundial.

A pesar de la dependencia y la inconmensurable cantidad de datos confidenciales que fluyen a través de las transmisiones Wi-Fi, la historia del protocolo ha estado plagada de problemas de seguridad derivados tanto de las debilidades de confidencialidad heredadas de su predecesor, Ethernet (antes era posible que cualquier persona en una red leyera y modificara el tráfico enviado a cualquier otra), como de la capacidad de cualquier persona cercana para recibir las señales de radio de las que depende el Wi-Fi.

Un fantasma en la máquina

En sus inicios, las redes Wi-Fi públicas solían parecerse al Viejo Oeste, donde eran comunes los ataques de suplantación de ARP que permitían a usuarios no autorizados leer el tráfico de otros usuarios. La solución fue construir protecciones criptográficas que impidieran que las partes cercanas, ya fuera un usuario autorizado en la red o alguien cerca del punto de acceso (AP), leyeran o manipularan el tráfico de cualquier otro usuario.

Una nueva investigación muestra que los comportamientos que ocurren en los niveles más bajos de la pila de red hacen que el cifrado, en cualquier forma, no solo aquellos que han sido vulnerados en el pasado, sea incapaz de proporcionar aislamiento de cliente, una protección basada en cifrado prometida por todos los fabricantes de routers, cuyo objetivo es bloquear la comunicación directa entre dos o más clientes conectados.

El aislamiento puede anularse eficazmente mediante AirSnitch, el nombre que los investigadores dieron a una serie de ataques que aprovechan las vulnerabilidades recién descubiertas. Diversas formas de AirSnitch funcionan en una amplia gama de routers, incluyendo los de Netgear, D-Link, Ubiquiti, Cisco y aquellos que ejecutan DD-WRT y OpenWrt.

AirSnitch "rompe el cifrado de Wi-Fi mundial y podría tener el potencial de permitir ciberataques avanzados", declaró Xin’an Zhou, autor principal del artículo de investigación, en una entrevista. "Los ataques avanzados pueden aprovechar nuestras primitivas para robar cookies y envenenar el DNS y la caché. Nuestra investigación intercepta físicamente la red para que estos ataques sofisticados funcionen. Es una verdadera amenaza para la seguridad de las redes mundiales". Zhou presentó su investigación el miércoles en el Simposio de Seguridad de Redes y Sistemas Distribuidos de 2026.

El coautor del artículo, Mathy Vanhoef, declaró pocas horas después de la publicación que el ataque podría describirse mejor como una "evasión" del cifrado de Wi-Fi, "en el sentido de que podemos eludir el aislamiento del cliente. No rompemos la autenticación ni el cifrado de Wi-Fi. El cifrado a menudo se elude en lugar de romperse. Y lo evitamos ;)". Quienes no dependen del aislamiento del cliente o de la red, añadió, están a salvo. Los ataques Wi-Fi anteriores que de la noche a la mañana vulneraron las protecciones existentes, como WEP y WPA, funcionaban explotando vulnerabilidades en el cifrado subyacente. AirSnitch, en cambio, se dirige a una superficie de ataque previamente ignorada: los niveles más bajos de la pila de red, una jerarquía de arquitectura y protocolos basada en sus funciones y comportamientos.

El nivel más bajo, Capa 1, abarca dispositivos físicos como cableado, nodos conectados y todo lo que les permite comunicarse. El nivel más alto, Capa 7, es donde se ejecutan aplicaciones como navegadores, clientes de correo electrónico y otro software de Internet. Los niveles 2 a 6 se conocen como capas de Enlace de Datos, Red, Transporte, Sesión y Presentación, respectivamente.

Crisis de identidad

A diferencia de los ataques Wi-Fi anteriores, AirSnitch explota las características principales de las Capas 1 y 2 y la falla al vincular y sincronizar un cliente a través de estas y capas superiores, otros nodos y otros nombres de red como SSID (Identificadores de conjunto de servicios). Esta desincronización de identidad entre capas es el factor clave de los ataques AirSnitch.

El ataque más poderoso de este tipo es un ataque completo y bidireccional de máquina en el medio (MitM), lo que significa que el atacante puede ver y modificar datos antes de llegar al destinatario previsto. El atacante puede estar en el mismo SSID, en uno separado o incluso en un segmento de red separado vinculado al mismo AP. Funciona con pequeñas redes Wi-Fi tanto en hogares como en oficinas y con grandes redes en empresas.

Con la capacidad de interceptar todo el tráfico de la capa de enlace (es decir, el tráfico que pasa entre las Capas 1 y 2), un atacante puede realizar otros ataques en capas superiores. La consecuencia más nefasta ocurre cuando una conexión a Internet no está cifrada, algo que Google estimó recientemente que ocurrió cuando hasta el 6 por ciento y el 20 por ciento de las páginas se cargaron en Windows y Linux, respectivamente. En estos casos, el atacante puede ver y modificar todo el tráfico de forma clara y robar cookies de autenticación, contraseñas, detalles de tarjetas de pago y cualquier otro dato confidencial. Dado que muchas intranets empresariales se envían en texto plano, también se puede interceptar el tráfico procedente de ellas.

Incluso cuando HTTPS está implementado, un atacante aún puede interceptar el tráfico de búsqueda de dominio y utilizar el envenenamiento de la caché de DNS para dañar las tablas almacenadas por el sistema operativo del objetivo. AirSnitch MitM también coloca al atacante en posición de lanzar ataques contra vulnerabilidades que tal vez no se puedan parchear. Los atacantes también pueden ver las direcciones IP externas que alojan las páginas web que se visitan y, a menudo, correlacionarlas con la URL precisa.

Dada la gama de posibilidades que ofrece, AirSnitch brinda a los atacantes capacidades que no han sido posibles con otros ataques Wi-Fi, incluido KRACK de 2017 y 2019 y ataques Wi-Fi más recientes que, como AirSnitch, inyectan datos (conocidos como marcos) en túneles GRE remotos y eluden las listas de control de acceso a la red.

"Este trabajo es impresionante porque, a diferencia de otros métodos de inyección de fotogramas, el atacante controla un flujo bidireccional", dijo HD Moore, experto en seguridad y fundador y director ejecutivo de runZero.

Atrapado en el medio contigo

El MitM apunta a las Capas 1 y 2 y la interacción entre ellas. Comienza con el robo de puertos, una de las primeras clases de ataque de Ethernet que está adaptada para funcionar contra Wi-Fi. Un atacante lo lleva a cabo modificando el mapeo de Capa 1 que asocia un puerto de red con la MAC de la víctima, una dirección única que identifica cada dispositivo conectado. Al conectarse al BSSID que une el AP a una frecuencia de radio que el objetivo no está usando (generalmente 2,4 GHz o 5 GHz) y completar un protocolo de enlace Wi-Fi de cuatro vías, el atacante reemplaza la MAC del objetivo con una propia.

En otras palabras, el atacante se conecta a la red Wi-Fi utilizando la MAC del objetivo y luego recibe el tráfico del objetivo. Con esto, un atacante obtiene todo el tráfico de enlace descendente (datos enviados desde el enrutador) destinado al objetivo. Una vez que el conmutador de Capa 2 ve la respuesta, actualiza su tabla de direcciones MAC para preservar la nueva asignación durante el tiempo que el atacante lo necesite.

Esto completa la primera mitad del MitM, permitiendo que todos los datos fluyan hacia el atacante. Eso por sí solo daría lugar a poco más que una denegación de servicio para el objetivo. Para evitar que el objetivo se dé cuenta (y, lo que es más importante, para obtener la capacidad MitM bidireccional necesaria para realizar ataques más avanzados), el atacante necesita una forma de restaurar el mapeo original (el que asigna la MAC de la víctima al puerto de Capa 1). Un atacante realiza esta restauración enviando un ping ICMP desde una MAC aleatoria. El ping, que debe estar incluido en una clave temporal de grupo compartida entre todos los clientes, desencadena respuestas que hacen que la asignación de Capa 1 (es decir, los estados de los puertos) vuelva a ser la original.

"En un conmutador de Capa 2 normal, el conmutador aprende la MAC del cliente al verlo responder con su dirección de origen", explicó Moore. "Este ataque confunde al AP haciéndole creer que el cliente se reconectó en otro lugar, lo que permite al atacante redirigir el tráfico de Capa 2. A diferencia de los conmutadores Ethernet, los AP inalámbricos no pueden vincular un puerto físico del dispositivo a un solo cliente; los clientes son móviles por diseño".

El cambio de MAC de un lado a otro del atacante al objetivo, y viceversa, puede continuar tanto tiempo como el atacante lo desee. Con ello se ha conseguido el MitM bidireccional. Luego, los atacantes pueden realizar una serie de otros ataques, tanto relacionados con AirSnitch como como el envenenamiento de caché discutido anteriormente. Dependiendo del enrutador que esté utilizando el objetivo, el ataque se puede realizar incluso cuando el atacante y el objetivo están conectados a SSID separados conectados por el mismo AP. En algunos casos, dijo Zhou, el atacante puede incluso conectarse desde Internet.

"Incluso cuando el SSID del invitado tiene un nombre y una contraseña diferentes, aún puede compartir partes de la misma infraestructura de red interna que su Wi-Fi principal", explicó el investigador. "En algunas configuraciones, esa infraestructura compartida puede permitir una conectividad inesperada entre dispositivos invitados y dispositivos confiables".

No, las defensas empresariales no te protegerán.

Variantes del ataque anulan el aislamiento de cliente prometido por los fabricantes de routers empresariales, que suelen utilizar credenciales y una clave de cifrado maestra únicas para cada cliente. Uno de estos ataques funciona con varios puntos de acceso cuando comparten un sistema de distribución cableado, como es habitual en redes empresariales y de campus.

Este descubrimiento expone un punto ciego en el aislamiento de cliente: incluso los puntos de acceso físicamente separados, que transmiten diferentes SSID, ofrecen un aislamiento ineficaz si se conectan a un sistema de distribución común. Al redirigir el tráfico en el conmutador de distribución, los atacantes pueden interceptar y manipular el tráfico de las víctimas a través de los límites de los puntos de acceso, ampliando así el modelo de amenaza para las redes Wi-Fi modernas.

Los investigadores demostraron que sus ataques pueden permitir la vulneración de RADIUS, un protocolo de autenticación centralizado para mejorar la seguridad en redes empresariales. "Al suplantar la dirección MAC de una puerta de enlace y conectarse a un punto de acceso", escribieron los investigadores, "un atacante puede robar paquetes RADIUS de enlace ascendente". El atacante puede, a su vez, vulnerar un autenticador de mensajes utilizado para la protección de la integridad y, a partir de ahí, obtener una contraseña compartida. "Esto le permite configurar un servidor RADIUS fraudulento y un punto de acceso WPA2/3 fraudulento asociado, lo que permite que cualquier cliente legítimo se conecte, interceptando así su tráfico y credenciales".

Los investigadores probaron los siguientes 11 dispositivos:

• Netgear Nighthawk x6 R8000
• Tenda RX2 Pro
• D-LINK DIR-3040
• TP-LINK Archer AXE75
• ASUS RT-AX57
• DD-WRT v3.0-r44715
• OpenWrt 24.10
• Ubiquiti AmpliFi Alien Router
• Ubiquiti AmpliFi Router HD
• LANCOM LX-6500
• Cisco Catalyst 9130

Como se mencionó anteriormente, todos los routers probados fueron vulnerables a al menos un ataque. Zhou afirmó que algunos fabricantes de routers ya han publicado actualizaciones que mitigan algunos de los ataques y que se esperan más actualizaciones en el futuro. Sin embargo, también indicó que algunos fabricantes le han comentado que algunas de las debilidades sistémicas solo pueden abordarse mediante cambios en los chips subyacentes que compran a los fabricantes de silicio.

Los fabricantes de hardware se enfrentan a otro desafío: los mecanismos de aislamiento del cliente varían según el fabricante. Al no existir un estándar para toda la industria, estas soluciones únicas están fragmentadas y es posible que no reciban la atención de seguridad concertada que se les da a los protocolos formales.

¿Qué tan peligroso es realmente AirSnitch?

Con un conocimiento básico de AirSnitch, el siguiente paso es contextualizarlo y evaluar la magnitud de su amenaza en el mundo real. En algunos aspectos, se asemeja al ataque PTW de 2007 (llamado así por sus creadores, Andrei Pyshkin, Erik Tews y Ralf-Philipp Weinmann), que rompió el protocolo WEP completa e inmediatamente, dejando a los usuarios de Wi-Fi de todo el mundo sin medios para protegerse de los adversarios cercanos. Por ahora, el aislamiento del cliente se ha anulado de forma similar, casi por completo y de la noche a la mañana, sin una solución inmediata disponible.

Al mismo tiempo, el requisito para lanzar ataques WEP era significativamente menor, ya que estaba disponible para cualquiera dentro del alcance de un punto de acceso. AirSnitch, en cambio, requiere que el atacante ya tenga algún tipo de acceso a la red Wi-Fi. Para muchos, esto puede significar evitar por completo las redes Wi-Fi públicas.

Si la red está correctamente protegida (es decir, con una contraseña segura que solo conocen los usuarios autorizados), AirSnitch podría no ser de gran utilidad para un atacante. La cuestión es que, incluso si un atacante no tiene acceso a un SSID específico, podría usar AirSnitch si tiene acceso a otros SSID o BSSID que utilicen el mismo punto de acceso u otra infraestructura de conexión.

Otra diferencia con el ataque PTW (y otros posteriores que vulneraron las protecciones WPA, WPA2 y WPA3) es que se limitaron a ataques mediante señales de radio terrestres, un escenario mucho más limitado que el de AirSnitch. En definitiva, los ataques de AirSnitch son más amplios, pero menos graves.

Además, a diferencia de los ataques anteriores, las mitigaciones mediante firewall pueden ser más problemáticas.

"Ampliamos el modelo de amenazas, mostrando que un atacante puede estar en otro canal o puerto, o puede provenir de Internet", afirmó Zhou. Los firewalls también son dispositivos de red. Solemos decir que un firewall es un dispositivo de Capa 3 porque funciona en la capa IP. Pero, fundamentalmente, está conectado por cable a diferentes elementos de la red. Ese cable no es seguro.

Algunas de las amenazas se pueden mitigar mediante el uso de VPN, pero esta solución presenta todas las desventajas habituales. Por un lado, las VPN son conocidas por filtrar metadatos, consultas DNS y otro tráfico que puede ser útil para los atacantes, lo que limita la protección. Por otro lado, encontrar un proveedor de VPN confiable y de buena reputación ha resultado ser históricamente extremadamente difícil, aunque la situación ha mejorado recientemente. En definitiva, una VPN no debería considerarse más que una solución provisional.

Otra posible mitigación es el uso de VLAN inalámbricas para aislar un SSID de otro. Zhou afirmó que estas opciones no están disponibles universalmente y que, además, son muy fáciles de configurar incorrectamente. En concreto, explicó que las VLAN a menudo pueden implementarse de forma que permitan el salto de vulnerabilidades. Además, Moore ha argumentado por qué las VLAN no son una barrera práctica contra todos los ataques AirSnitch.

La solución más eficaz podría ser adoptar una postura de seguridad conocida como confianza cero, que trata a cada nodo de una red como un adversario potencial hasta que demuestre que es confiable. Este modelo es difícil de adoptar incluso para empresas con una sólida financiación, aunque cada vez es más fácil. No está claro si alguna vez será viable para usuarios ocasionales de Wi-Fi en hogares y pequeñas empresas.

Probablemente la respuesta más razonable sea ser prudente con todas las redes Wi-Fi administradas por desconocidos. Siempre que sea posible, utilice una VPN fiable en puntos de acceso públicos o, mejor aún, conecte una conexión desde un teléfono móvil.

El Wi-Fi siempre ha sido una opción arriesgada, y AirSnitch solo aumenta el potencial de malicia. Sin embargo, las nuevas capacidades pueden tener poca importancia en el mundo real, donde los ataques de gemelo maligno logran muchos de los mismos objetivos con mucha menos dificultad.

Moore afirmó que los ataques posibles antes del aislamiento del cliente solían ser tan sencillos como ejecutar ettercap o herramientas similares en cuanto se establecía una conexión Wi-Fi normal. Los ataques AirSnitch requieren considerablemente más trabajo, al menos hasta que alguien desarrolle un script fácil de usar que los automatice.

"Será interesante ver si los proveedores de servicios inalámbricos se preocupan lo suficiente como para resolver estos problemas por completo y si los atacantes se preocupan lo suficiente como para integrar todo esto cuando podría haber opciones más sencillas (como ejecutar un punto de acceso falso)", declaró Moore. "Como mínimo, debería hacer la vida de los pentesters más interesante, ya que abre una gran cantidad de vulnerabilidades con las que muchos podrían no tener experiencia".

Fuente: Arstechnica

Seguir leyendo...

Pentesting en Android: metodología completa (II)

El documento "All About Android Pentesting: A Complete Methodology" fue desarrollador por Xcheater

Ver Parte I

---

Analizar el código fuente

Al descompilar un APK, se obtiene el código fuente y se puede analizar. Sin embargo, hoy en día, la mayoría de las aplicaciones lo protegen mediante ofuscación, lo que impide que un atacante comprenda la lógica.

Tal y como se explica en el post anterior, En general se puede revisar algunos archivos para obtener ideas sobre la lógica escrita, como la detección de root, SSL Pinning, la comprobación del depurador, la comprobación del lado del cliente, etc. Analizar el código fuente te dará ideas para comprender cómo realizar un buen análisis dinámico, incluyendo ataques como vistas web o enlaces profundos, e inyecciones.

Se puede analizar el código directamente con semgrep o MobSF. Esto te dará una idea rápida del estado de seguridad. A continuación, se encuentra el repositorio semgrep-rules-android-security, que puede ser útil.

Qué buscar manualmente en el código fuente:

• Lógica de detección de root: verificar las comprobaciones binarias `su` y las comprobaciones de integridad de SafetyNet/Play.
• Implementación de SSL Pinning: busca `CertificatePinner`, `TrustManager` y validación SSL personalizada.
• Comprobaciones del depurador: buscar `isDebuggerConnected()` y comprobaciones de indicadores de depuración.
• Validación del lado del cliente: buscar comprobaciones de autenticación/autorización que se puedan omitir.
• Uso de WebView: Comprrobar `loadUrl()` y `evaluateJavascript()` (son posible fuente de XSS).
• Gestión de intenciones: comprobar cómo se procesan las intenciones (posible inyección de intenciones).
• Gestión de enlaces profundos: comprobar la validación de URL en los controladores de enlaces profundos.

Firma APK - Vulnerabilidad Janus

La verificación de la firma APK es importante para la integridad de la aplicación. Sin embargo, existe una vulnerabilidad llamada Janus (CVE-2017–13156) que permite a los atacantes modificar los archivos APK sin invalidar la firma.

Comprobación de integridad (anti-tampering): descompila el APK con APKtool y modifica algunos archivos, como el manifest.xml y cambia la cadena de "true" a "false". Recompila el APK con APKtool, fírmalo con tu propia clave e instala y ejecuta la aplicación.

Si la aplicación detecta una manipulación, debería rechazar su ejecución o mostrar un error. Si se ejecuta con normalidad, la aplicación no cuenta con la detección de manipulaciones adecuada. Esto constituye una vulnerabilidad.

Comprobación de integridad: descompila el APK y modifica algunos archivos, como el archivo manifest.xml o la cadena "true" (verdadero) a "false". Recompila el APK con apktool, fírmalo con tu propia clave e instala y ejecuta la aplicación.

Ahora hablemos de una de las medidas de seguridad más importantes: la detección de root y SSL Pinning.

Generalmente, las aplicaciones modernas cuentan con todas estas medidas de seguridad, por lo que para realizar la evaluación dinámica y otras comprobaciones de seguridad, es necesario omitirlas. Echemos un vistazo rápido a ellas; no profundizaremos en ellas, solo les daré una descripción general.

¡Detección de root!

Si la aplicación detecta que su dispositivo está rooteado, podría negarse a ejecutarse, mostrar algún error o restringir ciertas funciones.

Las aplicaciones utilizan diversas técnicas para detectar el root. Veamos las más comunes que encontrará durante la evaluación:

• Uso de bibliotecas de detección de root: muchos desarrolladores no escriben código personalizado para la detección de root. Simplemente utilizan bibliotecas predefinidas que realizan todas las comprobaciones de detección de root, como RootBeer, RootCloak y RootInspector.
• Comprobación del binario "su": la aplicación busca el binario "su" en rutas comunes como /system/bin/su, /system/xbin/su o /sbin/su. Si lo encuentra, sabe que el dispositivo está rooteado.
• Buscando aplicaciones de administración de root: las aplicaciones comprueban si Magisk, SuperSU u otras aplicaciones de administración de root están instaladas en el dispositivo. Buscan nombres de paquetes como com.topjohnwu.magisk o eu.chainfire.supersu.
• Comprobación de las propiedades del sistema: las aplicaciones leen propiedades como ro.debuggable, ro.secure o ro.build.tags para detectar el root o las compilaciones de prueba.
• Google SafetyNet / API de Integridad de Play: la solución oficial de Google para la comprobación de la integridad de los dispositivos. Está basada en la nube y comprueba si hay root, un gestor de arranque desbloqueado y manipulación del sistema. Esto es más difícil de eludir que las comprobaciones de root personalizadas.
• Comprobación de particiones del sistema con permisos de escritura: los dispositivos rooteados suelen tener /system montado como lectura y escritura, lo cual las aplicaciones pueden detectar.
• Detección de Magisk o Zygisk: algunas aplicaciones buscan específicamente archivos, procesos o puntos de montaje relacionados con Magisk, como /sbin/.magisk/, /data/adb/magisk, etc.

¿Cómo eludir la detección de root?

Hay varias maneras de eludir la detección de root. Estos son los métodos más comunes:

• Magisk Hide / Zygisk DenyList: habilita DenyList en la configuración de Magisk y añade la aplicación de destino.
• Scripts de Frida: usa la aplicación Frida para enlazar funciones de detección de root y hacer que devuelvan falso. Puedes explorar más scripts personalizados de Frida en GitHub o escribir los tuyos propios si entiendes la lógica de detección.
• Objection: Basado en Frida, proporciona una interfaz de línea de comandos sencilla para desactivar las comprobaciones de root.
• Parchear el APK: descompilar, encontrar la lógica de detección de root, parchearlo, recompilar y firmar.
• Módulos Magisk/LSposed: usar módulos como Hide My Applist, Shamiko, LSPosed con RootCloak o Zygisk-Assistant para ocultar el root de las aplicaciones. Estos funcionan a nivel de sistema.

Recuerda que la omisión es más fácil una vez que comprendes cómo la aplicación detecta el root. Lee el código, identifica las comprobaciones y elige el método de omisión según corresponda.

SSL Pinning

La fijación SSL (también conocida como fijación de certificados) es un mecanismo de seguridad mediante el cual la aplicación valida el certificado SSL del servidor con un certificado predefinido o una clave pública integrada en la aplicación. Esto evita ataques de intermediario (MitM), incluso si instalas un certificado de CA personalizado en el dispositivo.

Al implementar la fijación SSL, no puedes interceptar el tráfico de la aplicación con Burp Suite ni con ningún otro proxy, ya que la aplicación rechazará el certificado de tu proxy.

¿Implementación de la fijación SSL?

Los desarrolladores pueden implementar la fijación SSL de diversas maneras. Veamos las más comunes que observarás durante la evaluación:

• Configuración de seguridad de red (basada en XML): la aplicación define certificados de confianza en un archivo XML, generalmente en res/xml/network_security_config.xml.
• TrustManager personalizado: algunos desarrolladores crean su propio TrustManager para validar certificados manualmente.
• Bibliotecas de terceros: Bibliotecas como OkHttp y TrustKit ofrecen implementaciones de anclaje SSL listas para usar que los desarrolladores pueden integrar fácilmente.

¿Cómo evitarlo?

Necesitamos evitar esta comprobación de anclaje SSL, ya que ya sabe que no se puede interceptar la solicitud ni la respuesta. Sin embargo, para completar la evaluación, también debe analizar estas áreas. Generalmente, se puede solicitar al desarrollador que elimine estas comprobaciones de seguridad, como la detección de root y el anclaje SSL, pero en un escenario de caja negra, este acceso no es posible.

Veamos algunas soluciones comunes para eludir la fijación de SSL:

• Objection: desactiva la fijación de SSL con un solo comando.
• Scripts de Frida: usa scripts universales para eludir la fijación de SSL. Puedes encontrar scripts ya preparados en GitHub, escribir los tuyos propios si entiendes la implementación o usar IA para generarlos.
• HTTP Toolkit: una herramienta GUI que gestiona automáticamente la instalación de certificados y la elusión de la fijación de SSL.
• Aplicación manual de parches: descompilar la aplicación, encontrar la implementación de fijación (buscar CertificatePinner, TrustManager, etc.), modificarla o eliminarla, volver a compilarla y firmarla. Es un proceso lento, pero funciona siempre.

Conclusión

Bien, hemos cubierto mucho en este artículo, desde los fundamentos del análisis estático. Esto debería darte una base sólida para comenzar tu experiencia con las pruebas de penetración en Android. Pero sí, las pruebas de penetración en Android son mucho más que eso. Aún hay muchas áreas que no hemos profundizado aquí. Por ejemplo, WebView, enlaces profundos, problemas relacionados con la memoria y problemas de criptografía, etc.

Abordaré estos temas en detalle en futuros artículos, ¡así que queda atento!

El documento "All About Android Pentesting: A Complete Methodology" fue desarrollador por Xcheater

Ver Parte I

Seguir leyendo...

Pentesting en Android: metodología completa (I)

El documento "All About Android Pentesting: A Complete Methodology" fue desarrollador por Xcheater

---

Android está en todas partes. Miles de millones de dispositivos, millones de aplicaciones y una enorme superficie de ataque que crece día a día. Así que, por supuesto, debemos centrarnos en su seguridad. Hoy voy a hablar sobre mi metodología de pentesting en Android, que sigo desde hace años. Esto será útil tanto para los nuevos usuarios como para algunos con experiencia.

Pero sí, la verdad es que esta lista de verificación o metodología puede ser demasiado larga. Y no siempre se recomienda seguir todos los pasos. Pero sí, tenla en cuenta.

Supongo que ya tienes una configuración para el pentesting en Android. Tienes tu dispositivo rooteado y cumples con otros requisitos básicos. No vamos a cubrirlos. Además, para esta metodología, me centro en un enfoque de dispositivo rooteado, que te dará libertad para múltiples cosas, las cuales utilizaremos en nuestras pruebas de penetración.

Recopilación de información básica

¿Qué archivos incluye el paquete?

Extrae el APK y examina su estructura. Puedes usar APKtool para esto o simplemente renombra test.apk a test.zip y extráelo.

¿Qué biblioteca nativa usa la aplicación?

Aunque podemos obtener esta información más tarde, después de descompilar, puedes revisar la carpeta `lib/` para encontrar las bibliotecas nativas. A veces también se pueden ver algunos archivos `.so` personalizados.

Si estás realizando pruebas de penetración de caja blanca, solicita estos detalles al desarrollador.

Ahora es necesario entender que en las pruebas de penetración de Android tenemos dos partes: análisis estático y análisis dinámico. El análisis estático implica examinar el código de la aplicación sin ejecutarlo. Aquí es donde encontramos secretos codificados, claves API y fallos lógicos.

Primero, profundicemos en el análisis estático. El primer paso es descompilar la aplicación. Puedes usar apktool o la interfaz gráfica de JADX. Prefiero la interfaz gráfica de JADX, que es muy útil y fácil de entender en comparación con apktool. Aunque también puedes encontrar la interfaz gráfica de APKtool UI.

AndroidManifest.xml

Empecemos directamente con AndroidManifest.xml. Piensa en este archivo como el plano de toda la aplicación. Es como un mapa que te muestra todo sobre la estructura, los permisos, los componentes y la configuración de seguridad de la aplicación, todo en un solo lugar. Este único archivo puede revelar una gran superficie de ataque.

Se pueden encontrar muchísimas vulnerabilidades con solo leer este archivo: actividades exportadas sin autenticación, aplicaciones de producción depurables, copias de seguridad habilitadas con datos confidenciales; todo visible en XML simple. Por eso siempre empiezo aquí. Es la forma más rápida de encontrar las oportunidades más fáciles.

Permisos de la aplicación: comprueba qué permisos solicita la aplicación y busca permisos peligrosos que los requieran. ¿Por qué la aplicación necesita esos permisos? ¿Son necesarios?

<uses-permission android:name="android.permission.READ_CONTACTS" />
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
<uses-permission android:name="android.permission.CAMERA" />
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />

Copia de seguridad habilitada: comprueba si <application android:allowBackup="true"> está habilitado. Si está habilitado, un usuario adversario puede usar la herramienta ADB para acceder a los datos de copia de seguridad de la aplicación, lo que puede exponer preferencias compartidas, bases de datos y archivos internos. Si esta opción no aparece en el manifiesto, se define como "true" por defecto. Por lo tanto, si no ves el atributo "allowBackup", la copia de seguridad sigue habilitada.

Indicador de depuración: comprueba si <application android:debuggable=true> está configurado como verdadero. Un usuario adversario puede adjuntar el depurador, leer la memoria del proceso y modificar variables en tiempo de ejecución. A diferencia de "allowBackup", este indicador NO está habilitado por defecto (su valor predeterminado es `false`). Sin embargo, a veces los desarrolladores lo dejan habilitado accidentalmente en compilaciones de producción o se configura como verdadero durante el desarrollo.

Configuración de seguridad de red: Comprueba si la fijación de certificados está implementada o si se permite el tráfico de texto sin cifrar. Si se permite el tráfico de texto sin cifrar, se trata de una vulnerabilidad.

<network-security-config>
    <base-config cleartexttrafficpermitted="true">
        <trust-anchors>
            <certificates src="system">
        </certificates></trust-anchors>
    </base-config>
</network-security-config>

Si se establece cleartextTrafficPermitted=true, la aplicación permite conexiones HTTP, lo que significa que el tráfico puede ser interceptado y modificado. Esto representa una vulnerabilidad.

Versiones mínima, máxima y de destino del SDK: Las versiones anteriores del SDK tienen una seguridad más débil. Si la aplicación utiliza SDK antiguos, no será compatible con las funciones de seguridad modernas. La aplicación debe usar la versión más reciente del SDK.

Componentes de la aplicación exportados: Busca los componentes exportados. Hay cuatro componentes (actividades, servicios, proveedores y receptores). Si android:exported = true está presente, significa que se puede llamar de forma independiente, lo que puede usarse con fines maliciosos o para eludir algunas funciones de seguridad.

• Actividades (Activities): son básicamente las pantallas de la interfaz de usuario, como la página de inicio, la pantalla de inicio, etc. Si se exportan, otras aplicaciones pueden iniciarlas directamente. Así, puedes omitir la pantalla de inicio e ir directamente a la página de inicio.
• Servicios (Services): se ejecutan en segundo plano, realizando algunas tareas sin mostrar la interfaz de usuario. Si se exportan, otras aplicaciones pueden iniciarlos o detenerlos. Pueden usarse para activar algunas acciones sin que el usuario lo sepa.
• Proveedores de contenido (Content Providers): comparten datos entre aplicaciones. Si se exportan, otras aplicaciones pueden consultarlos y leerlos, como información del usuario, tokens y datos de la base de datos. Aquí es donde se encuentran las fugas de datos.
• Receptores de difusión (Broadcast Receivers): escuchan los mensajes del sistema, como cuando se inicia el teléfono o se reciben SMS, etc. Si se exportan, las aplicaciones maliciosas pueden activarlos. Se puede utilizar para realizar acciones sin interacción del usuario.

Busca cadenas interesantes: busca cadenas interesantes como contraseñas, URL, claves API, claves de cifrado, puertas traseras, tokens y UUID. En ocasiones, puedes obtener secretos codificados e incrustados en la aplicación. Estos secretos pueden utilizarse posteriormente, tal vez aprovechando filtraciones de claves API o algún hallazgo lógico.

Aquí se puede usar automatización, con una herramientas como apkurlgrep o una utilidad como string o regex a través de la interfaz gráfica de usuario de JADX.

Configuración incorrecta de Firebase: al analizar una cadena interesante, podrías obtener una URL de Firebase como https://xyz.firebaseio.com/; generalmente la encontrarás en res/values/strings.xml. Por lo tanto, vale la pena revisar los problemas de configuración incorrecta de Firebase. Simplemente ve al navegador y navega a la URL encontrada: https://xyz.firebaseio.com/.json.

Observarás dos tipos de respuesta:

• Permiso denegado: Esto significa que no puedes acceder a ella, por lo que está bien configurada. Continúa.
• Respuesta nula o un montón de datos JSON: Esto significa que la base de datos es pública y que al menos tienes acceso de lectura.

Si recibiste la segunda respuesta, no te quedes ahí, comprueba si tienes más que acceso de lectura; es decir, si puedes escribir algo allí.

curl -X PUT "https://xyz.firebaseio.com/test.json" -d '{"test":"data"}'
# If successful, check for delete access (be careful!)
curl -X DELETE "https://xyz.firebaseio.com/test.json"

Bien, ya hemos cubierto los fundamentos del análisis estático. Ahora hablemos de dónde almacenan las aplicaciones datos confidenciales. Aquí es donde se encuentran muchas vulnerabilidades.

Ver Parte II

Seguir leyendo...

Lista actualizada de exploits y PoC para todos los CVE

Este repositorio "Recently updated Proof-of-Concepts" del investigador y experto en Bug Bounty Marc K. (aka 0xMarcio) registra todos los exploits y PoC para todos los CVE que se publican diariamente.

Además del listado actualizado de CVE y PoC, el repositorio tiene scripts para autmatica la búsqueda y tratamiento de dichos CVE.

Seguir leyendo...

Sliver: framework de Comando y Control

Sliver es un potente framework de Comando y Control (C2) creado por BishopFox, de código abierto y diseñado para proporcionar capacidades avanzadas para la gestión y el control encubiertos de sistemas remotos.

Organizaciones de todos los tamaños equipos rojos y testers de penetración pueden utilizarlo para realizar pruebas de seguridad. Los implantes de Sliver son compatibles con C2 sobre Mutual TLS (mTLS), WireGuard, HTTP(S) y DNS, y se compilan dinámicamente con claves de cifrado asimétrico por binario.

El servidor y el cliente son compatibles con macOS, Windows y Linux. Los implantes son compatibles con macOS, Windows y Linux (y posiblemente con todos los compiladores Golang).

Esto les permite ejecutar comandos, recopilar información y realizar diversas actividades posteriores a la explotación. El framework ofrece una interfaz de consola intuitiva, amplia funcionalidad y compatibilidad con múltiples sistemas operativos y arquitecturas de CPU, lo que lo convierte en una herramienta indispensable para llevar a cabo operaciones integrales de seguridad ofensiva.

Fuente: Sliver

Seguir leyendo...

Las pruebas de penetración (automatizadas) ya están muertas. ¡Bienvenido la Ingeniería en Seguridad!

Este artíoculo ha sido publicado por Hamid Kashfi en X

Llevo unos 22 años realizando una amplia gama de pruebas de penetración y auditorías (más de 400 proyectos). Así que algo sé del tema. Pero sigo considerando que las pruebas de penetración automatizadas están obsoletas. Aunque no como podrías pensar. Inicialmente escribí un borrador más extenso, pero al final lo descarté y dejé que Gemini lo acortara y perfeccionara, ¿por qué no?

¿Por qué las pruebas de penetración automatizadas están muertas?

Está obsoleto, al igual que lo estaba hace 10 años el uso de herramientas automatizadas como Nessus y Core Impact y la entrega de informes de 50 páginas. La nueva era de la automatización impulsada por IA está reviviendo precisamente ese enfoque de bajo valor.

No estoy en contra de la IA; mejorará. Yo mismo pago ocasionalmente más de 1.000 dólares al mes en tokens. Ya funciona para muchas cosas, pero aún no es escalable para realizar pruebas de penetración eficientes. No porque los tokens sean demasiado caros (bajarán de precio) ni porque los modelos no sean fiables (mejorarán; XBow es un ejemplo). Está obsoleta por distintas razones interrelacionadas.

1. El problema del ruido y la fatiga

Del mismo modo que se ignoraban los antiguos informes con decenas o cientos de hallazgos válidos, esta nueva era de problemas generados por IA también será ignorada. Actualmente, un informe puede contener 2 o 3 hallazgos clave. Pronto, agentes de IA analizarán su red a fondo y generarán 100 problemas graves y perfectamente válidos.

Si llevas cinco años realizando pruebas trimestrales a clientes de Fortune 50/500 y has obtenido resultados similares una y otra vez, sabes a qué me refiero. La priorización de las medidas correctivas y el cansancio que esto genera son un problema grave. Al final te das cuenta de que lo que vendemos (hacking, pruebas, seguridad) no es la prioridad de las grandes empresas. Es una obligación, a menudo por motivos de cumplimiento normativo, entre otras cosas.

No juzgues a un CISO por archivar un informe con todas las vulnerabilidades en rojo y solucionar solo cinco problemas al día siguiente, la semana siguiente, el mes siguiente o el año siguiente. Tu "hallazgo crítico" es simplemente una decisión de negocio.

Su funcionamiento es más bien similar a: "¿Nos costará un millón de dólares si se explota?". Si la respuesta es no, no se categoriza, prioriza ni gestiona como crítico, porque hacerlo inicia una compleja cadena de acciones internas que, por sí misma, consume tiempo y dinero.

Por lo tanto, en muchos casos, la razón por la que las pruebas de penetración no son eficientes no se debe a la falta de pruebas, sino a la falta de prioridad empresarial. No necesitas una prueba de concepto funcional (generada por un humano o un LLM) para abordar esto. 

Obtener acceso a una shell en un sistema que inherentemente no es crítico para el negocio en una infraestructura, no lo convertirá mágicamente en una prioridad. Esta es una gran promesa que ofrecen las startups de pruebas de penetración automatizadas con IA. Sin duda funciona, y pueden generar acceso a shells sin parar, pero eso no resolverá ningún problema que no se haya abordado ya con las pruebas de penetración tradicionales.

2. El verdadero cuello de botella

La industria de la seguridad acaba de empezar a ofrecer a sus clientes un respiro del ruido de los informes de pruebas automatizadas, centrándose en la investigación manual exhaustiva. Por fin, lo normal es entregar solo media docena de hallazgos realmente importantes, en lugar de tonterías como la falta de una cabecera HSTS.

Espero que esta nueva ola de pruebas automatizadas con IA no traiga de vuelta los informes de Nessus o Core Impact, que ahora solo son más precisos. Ah, se me olvidaba: ya hemos vivido una era centrada en la detección automática, la validación basada en exploits y la notificación de vulnerabilidades. No digo que vayamos hacia el mismo destino, pero se parece demasiado.

Es mucho más fiable y mucho más interesante que un script de Python que razona con un bucle IF para decidir si explotar o no un exploit de SMB1. ¿Significa eso que deberíamos dejar de buscar y notificar cosas de esta manera? No necesariamente.

El principal problema no es la precisión de los resultados. Bueno, lo fue durante un tiempo a mediados de la década de 2000, pero mejoramos y las herramientas se perfeccionaron. El problema radica en que quienes reciben estas automatizaciones e informes no están automatizados. El proceso y el personal que gestiona estos hallazgos no han evolucionado al mismo ritmo que las herramientas. No importa cuántos problemas críticos se detecten y se exploten; siguen siendo gestionados por personas, tratados como decisiones empresariales y revisados ​​caso por caso.

3. Las pruebas de caja negra son ineficientes

Generar 50 hallazgos válidos mediante Nessus, Burp Scanner o sus equivalentes basados ​​en LLM simplemente no es eficiente. Una prueba de caja negra es inherentemente ineficiente hoy en día porque no encuentra ni reporta los problemas en su origen. Solo encuentra y reporta síntomas que se repiten constantemente. ¿Alguna vez has accedido a la plataforma de gestión de vulnerabilidades Qualys o Tenable de una empresa? ¡Te aseguro que no es una imagen agradable! ¡Esos son los resultados máximos de las pruebas de penetración automatizadas a gran escala!

Por mucho que repitas una prueba de penetración de caja negra, siempre encontrarás problemas nuevos y recurrentes. ¿No me crees? Pregúntale a Fortinet. Siguen publicando parches para SQLi, CMDi, RCE y corrupción de memoria básica mensualmente, año tras año.

Todos ellos descubiertos y explotados mediante pruebas de caja negra por tus APT favoritos. Sí, eso también es una forma de prueba. Simplemente no comparten sus hallazgos con el proveedor. Fortinet no es un caso aislado. Si la solución fuera esta, las plataformas de recompensas por errores y negocios similares no estarían tan bien.

Generan enormes ganancias, tanto para ellos como para los cazadores de errores, aprovechándose de que durante más de dos décadas, como industria, no hemos solucionado de forma adecuada y fundamental algunos de estos problemas.

Por cierto, si una empresa ha seguido el camino correcto de madurez (en seguridad) antes de exponerse a las plataformas de recompensas por errores, significa que ya ha superado múltiples rondas de todo tipo de pruebas de penetración. ¡Y aun así, la gente sigue encontrando cosas interesantes, muchísimas!

No entremos en el tema de que "ya éramos conscientes del problema" ni en discusiones interminables. Además, si las pruebas automatizadas basadas en IA son tan buenas y representan el futuro (de hecho, lo son), surge la pregunta de por qué se les prohíbe operar de forma autónoma en plataformas de recompensas por errores. ¿Se debe al ruido? ¿Acaso estas plataformas están monopolizando el mercado para sus propias implementaciones de agentes?

4. El método eficiente: Ingeniería de seguridad

Bien, ¿cuál es la forma más eficiente de hacer las cosas entonces? Me alegra que lo preguntes. La ingeniería de seguridad es la respuesta más breve. Consulta con cualquier empresa de consultoría y pentesting respetable. Verás que la mayoría de sus proyectos con clientes no son pruebas de caja negra.

Las consultoras típicas prefieren las auditorías de caja blanca: revisan el código, las configuraciones, la infraestructura como código o la postura de seguridad en la nube. Básicamente, vendemos ingeniería de seguridad como un servicio.

La idea es obtener el máximo rendimiento en el menor tiempo posible, generalmente una o dos semanas. No se les contrata para resolver problemas sencillos, sino para profundizar en ellos. Detectan problemas lógicos o complejas cadenas de problemas con un impacto inesperado. Es probable que su JIRA ya esté repleto de hallazgos generados por sus propias herramientas automatizadas.

Curiosamente, si revisas algunos de sus informes, verás que en los informes centrados en la ingeniería de seguridad no se incluyen pruebas de concepto ni demostraciones reales de explotación exitosa. La prueba ya está en el código. La explotación es una tarea redundante y que consume mucho tiempo, sin ningún valor añadido real para el cliente. ¿En un equipo rojo? ¡Por supuesto! Pero en pruebas de penetración, no tanto.

Estadísticamente, y por experiencia propia, se encuentran más y mejores vulnerabilidades al leer el código o realizar ingeniería inversa del sistema, en comparación con explorar a ciegas algo expuesto en la red.

Te centras en los componentes clave y localizas la causa raíz. Cuando detectas un patrón, dejas de informar casos individuales y te dedicas a describir la naturaleza de la práctica insegura repetida.

Identificas la causa raíz en el código. Si dispones de tiempo y el cliente también puede dedicarle tiempo, puedes ofrecer soluciones de detección y mitigación a largo plazo: una herramienta de fuzzing, una consulta CodeQL, una recomendación de cambio para CI/CD, etc.

En cambio, las típicas pruebas de penetración de caja negra se pueden resumir en pocas palabras: parchea tus sistemas, actualiza tus dependencias, audita tus contraseñas, evita el phishing y sigue las recomendaciones de seguridad. Luego, corrige esto, esto, esto, esto, esto, esto, esto y esto. Estarás bien hasta el año que viene, cuando volvamos a realizar la prueba y te digamos lo mismo, con nuestra plantilla de informe actualizada y un lenguaje ligeramente mejorado.

5. IA + SAST: El verdadero punto de inflexión

Aquí es donde las cosas empiezan a pintar bien. ¡Nunca habíamos sido tan eficientes y razonablemente fiables a gran escala a la hora de estudiar, comprender el código y encontrar problemas en el código y la configuración!

Hemos implementado diversas versiones de soluciones SAST (Pruebas de Seguridad de Aplicaciones Estáticas) y DAST (Pruebas de Seguridad de Aplicaciones Dinámicas). Si bien estas soluciones mejoraron su escalabilidad, también lo hicieron los falsos positivos y los recursos humanos necesarios para revisar los resultados. CodeQL, Semgrep y herramientas similares han mejorado considerablemente y ahora forman parte de la mayoría de nuestros proyectos, ya que funcionan bien una vez optimizadas.

¿En qué se diferencia el SAST impulsado por IA de las pruebas de penetración automatizadas con IA? En el caso de las pruebas de penetración clásicas (automatizadas), contábamos con una solución parcialmente funcional que escalaba, pero no resolvía las causas raíz; simplemente señalaba los síntomas a gran escala.

En el caso del SAST impulsado por IA, gracias a la naturaleza de las pruebas de caja blanca y a la creciente precisión de los modelos para comprender el código, se puede profundizar en el análisis a un costo y tiempo muy razonables: encontrar la causa raíz de los problemas, identificar todas sus variantes, generar una prueba de concepto y, como colofón, ¡proporcionar una solución! Si bien aún requiere cierta intervención humana, el valor es inmenso.

En Google, OpenAI y otras organizaciones, existen sistemas que consumen tokens de forma excesiva. Muchos han experimentado con procesos similares internamente, obteniendo un retorno de la inversión de 10, 50 o 100 veces mayor en valor potencial de errores en comparación con el coste de los tokens utilizados.

Compárese esto con el enfoque de caja negra: "Tras varias horas de pruebas a ciegas, envié 100 solicitudes a este punto de conexión para confirmar una inyección SQL. Aquí tienen un enlace a OWASP y una prueba de concepto en Python. Para ahorrar tokens, les dejo a ustedes y a sus desarrolladores la tarea de encontrar las otras 100 variantes de este problema".

Resulta que con 200 dólares en tokens puedes o bien hacer funcionar tu agente de pruebas de caja negra hasta que encuentre algunos errores de forma remota, explotarlos y considerarlo una victoria, o bien gastar la misma cantidad de dinero y una fracción del tiempo para encontrar, clasificar, explotar, analizar variantes, parchear e informar sobre una docena de ellos consumiendo código.

Estos monstruos que consumen tokens crearán, y de hecho ya han creado, su propia cadena de cuellos de botella y problemas de ruido. Probablemente muchos de ustedes hayan oído hablar o participado en alguna discusión sobre FFMPEG vs. Google AI. Pero, por suerte, ya contamos con una solución (casi) funcional. Es menos arriesgado permitir que un LLM envíe una solicitud de extracción que dejar que gestione la infraestructura de red y borre una o dos bases de datos en el proceso.

Conclusión

Por favor, no se enfaden conmigo cuando diga que las pruebas de penetración, en su forma clásica tal como las conocemos, incluso con un cambio de motor de IA, están muertas.

No está del todo muerto. Deben seguir coexistiendo diferentes enfoques de pruebas, y las plataformas de recompensas por errores continuarán creciendo. Pero, al final, si medimos los resultados, especialmente con la trayectoria que están siguiendo las pruebas SAST y DAST impulsadas por IA, será muy difícil que el enfoque de caja negra logre alcanzarlo en términos de eficiencia e impacto a largo plazo.

En 2025, tras presenciar las increíbles hazañas de las APT, si aún te preguntas si tu red es vulnerable a ataques, necesitas un toque de atención. La respuesta es SIEMPRE sí. Estarás en mejor posición si te centras en el CÓMO, analizando cada caso individualmente, como suele ser el enfoque de las pruebas de caja negra. Pero si buscas una solución más eficaz y a largo plazo para identificar y resolver problemas, las pruebas de caja negra (automatizadas) probablemente sean uno de los métodos menos eficientes.

Saber que estamos condenados a sufrir una brecha de seguridad de una forma u otra no hace que esas pruebas sean irrelevantes. Simplemente significa que es mejor centrarse en lo que sucede después de una brecha y mejorar en ese aspecto. ¿SOC impulsado por LLM? ¿XDR que consumen tokens? ¿Despliegue impulsado por IA siguiendo las mejores prácticas de seguridad? Por ejemplo, ¡Google anunció su Agentic SOC! Eso debería significar algo, considerando la dirección que están tomando.

Sea lo que sea que esté por venir, me intriga. Simplemente no apostaría por agentes de LLM usando Nmap y lanzando payloads a ciegas hasta que uno funcione. Si identifican automáticamente el objetivo, obtienen una copia local para ingeniería inversa o auditoría, encuentran una vulnerabilidad y luego la explotan (¿Hola, XBow?), ¡por supuesto! Me apunto. Pero, pensándolo bien, ¿no se está adentrando eso en el terreno de SAST?

Como dato adicional, le pedí a ChatGPT que revisara todo el historial de OWASP TOP 10 desde sus inicios. Al parecer, las clases de errores simplemente cambian de posición. Ocasionalmente aparecen nuevos, ¡pero nunca desaparecen! ¿Cuántas pruebas de penetración y exploits más necesitamos para enseñar a la gente cómo manejar correctamente un ../../..?

Fuente: Hamid Kashfi

Seguir leyendo...

HydraPWK2: distro de Linux para pruebas de penetración en el sector industrial

HydraPWK, anteriormente conocido como BlackTrack (no Backtrack), es una distribución Linux de código abierto basada en Debian GNU/Linux.

Esta distribución ha sido diseñada para la investigación y las pruebas de penetración en el sector industrial. Incluye diversas herramientas para pruebas de penetración, como recopilación de información, escaneo, pruebas de estrés, explotación, cracking, ingeniería inversa, análisis forense y drones.

Este proyecto se centra en las pruebas de penetración en tiempo real, facilitando a los expertos de Red Team la realización de pruebas de penetración físicas. Por defecto, utiliza el kernel RT con PREEMPT_RT para garantizar que todo se ejecute a tiempo.

Ya que está diseñado para el hacking de hardware en tiempo real (pruebas de penetración de hardware físico) y con baja latencia para comunicarse con el objetivo.

Seguir leyendo...

Cybersecurity AI (CAI): framework para automatizar pruebas de seguridad

El panorama de la ciberseguridad está experimentando una transformación radical a medida que la IA se integra cada vez más en las operaciones de seguridad. Se prevee que para 2028, las herramientas de prueba de seguridad basadas en IA superarán en número a los pentesters humanos.

Este cambio representa una transformación fundamental en la forma en que se abordan los desafíos de la ciberseguridad. La IA no es solo una herramienta más: se está convirtiendo en esencial para abordar vulnerabilidades de seguridad complejas y anticiparse a las amenazas sofisticadas. A medida que las organizaciones se enfrentan a ciberataques más avanzados, las pruebas de seguridad mejoradas con IA serán cruciales para mantener defensas sólidas.

Cybersecurity AI (CAI) es un marco de trabajo ligero y de código abierto que permite a los profesionales de seguridad crear e implementar automatización ofensiva y defensiva basada en IA. CAI es el marco de trabajo estándar para la seguridad mediante IA, utilizado ya por miles de usuarios individuales y cientos de organizaciones. Tanto si eres investigador de seguridad, hacker ético, profesional de TI u organización que busca mejorar su postura de seguridad, CAI proporciona los componentes básicos para crear agentes de IA especializados que pueden ayudar con la mitigación, el descubrimiento y la explotación de vulnerabilidades, así como con la evaluación de la seguridad.

Este trabajo se basa en esfuerzos previos y se busca democratizar el acceso a herramientas avanzadas de IA para la ciberseguridad es vital para toda la comunidad de seguridad. El objetivo es capacitar a investigadores de seguridad, hackers éticos y organizaciones para que desarrollen e implementen potentes herramientas de seguridad basadas en IA. Al poner estas capacidades a disposición del público, busca igualar las condiciones y garantizar que la tecnología de IA de vanguardia para la seguridad no se limite a empresas privadas con gran financiación ni a actores estatales.

Los programas de recompensas por errores (Bug Bounty) se han convertido en un pilar fundamental de la ciberseguridad moderna, proporcionando un mecanismo crucial para que las organizaciones identifiquen y corrijan vulnerabilidades en sus sistemas antes de que puedan ser explotadas. Estos programas han demostrado ser altamente efectivos para proteger tanto la infraestructura pública como la privada, permitiendo a los investigadores descubrir vulnerabilidades críticas que de otro modo podrían haber pasado desapercibidas.

CAI está diseñado específicamente para potenciar estos esfuerzos, proporcionando un marco de trabajo ligero y ergonómico para la creación de agentes de IA especializados que pueden asistir en diversos aspectos de la búsqueda de recompensas por errores, desde el reconocimiento inicial hasta la validación y el reporte de vulnerabilidades. El marco de trabajo busca complementar la experiencia humana con capacidades de IA, ayudando a los investigadores a trabajar de manera más eficiente y exhaustiva en su misión de hacer que los sistemas digitales sean más seguros.

CAI se basa en los siguientes principios fundamentales:

• Marco de IA orientado a la ciberseguridad: CAI está diseñado específicamente para casos de uso de ciberseguridad, con el objetivo de automatizar parcial y totalmente las tareas de seguridad ofensivas y defensivas.
• Código abierto y gratuito para investigación: CAI es de código abierto y gratuito para fines de investigación. Nuestro objetivo es democratizar el acceso a la IA y la ciberseguridad. Para uso profesional o comercial, incluyendo implementaciones locales, soporte técnico especializado y extensiones personalizadas, contáctenos para obtener una licencia.
• Ligero: CAI está diseñado para ser rápido y fácil de usar.
• Diseño modular y centrado en agentes: CAI opera con agentes y patrones agentivos, lo que permite flexibilidad y escalabilidad. Puede agregar fácilmente los agentes y patrones más adecuados para su caso de ciberseguridad.
• Integración de herramientas: CAI integra herramientas ya incorporadas y permite al usuario integrar fácilmente sus propias herramientas con su propia lógica.
• Registro y rastreo integrados: utiliza Phoenix, la herramienta de registro y rastreo de código abierto para LLM. Esto proporciona al usuario una trazabilidad detallada de los agentes y su ejecución.
• Compatibilidad con múltiples modelos: LiteLLM admite y potencia más de 300 modelos. Los proveedores más populares son:
• Anthropic: Claude 3.7, Claude 3.5, Claude 3, Claude 3 Opus
• OpenAI: O1, O1 Mini, O3 Mini, GPT-4o, GPT-4.5 Preview
• DeepSeek: DeepSeek V3, DeepSeek R1
• Ollama: Qwen2.5 72B, Qwen2.5 14B, etc.

Alternativas de código cerrado

La IA para la ciberseguridad es un campo crítico; sin embargo, muchos grupos, erróneamente, la abordan mediante métodos de código cerrado con fines puramente económicos, aprovechando técnicas similares y basándose en modelos existentes de código cerrado (a menudo propiedad de terceros).

Este enfoque no solo desperdicia valiosos recursos de ingeniería, sino que también representa un derroche económico y genera esfuerzos redundantes, ya que suelen terminar reinventando la rueda. Aquí presentamos algunas de las iniciativas de código cerrado y en las que aprovechan la agentes de IA en la ciberseguridad:

• Autonomous Cyber
• CrackenAGI
• ETHIACK
• Horizon3
• Irregular
• Kindo
• Lakera
• Mindfort
• Mindgard
• NDAY Security
• Penligent
• Runsybil
• Selfhack
• Sola Security
• SQUR
• Staris
• Sxipher (seems discontinued)
• Terra Security
• Vibeproxy
• Xint
• XBOW
• ZeroPath
• Zynap
• 7ai

Fuente: CAI

Seguir leyendo...

Libro gratuito: "La Biblia Negra del Ethical Hacking"

Este libro gratuito "La Biblia Negra del Ethical Hacking", publicado Alejandro G. Vera, es un buen compendio de herramientas y técnicas que pueden servir a quienes se están comenzando a acercar al mundo de la seguridad ofensiva y el pentesting.

El libro se puede descargar de forma gratuita desde Github [PDF] o adquirir en Amazon.

Índice

• Prólogo
• Capítulo 1 – Entornos de Guerra Digital
• Capítulo 2 – Sistema de Herramientas Black-Hat
• Capítulo 3 – Anonimato y Clandestinidad Digital
• Capítulo 4 – Reconocimiento Agresivo y Subterráneo
• Capítulo 5 – Explotación de Vulnerabilidades de Cero Días (Zero-Day)
• Capítulo 6 – Ataques de Ingeniería Social de Alto Impacto
• Capítulo 7 – Pentesting Extremo
• Capítulo 8 – Escalada de Privilegios Creativa
• Capítulo 9 – Carding: Anatomía y Simulación en Laboratorio
• Capítulo 10 – Mercados Negros y Transacciones Anónimas
• Capítulo 11 – Hombre en el Medio (MitM) al Límite
• Capítulo 12 – DoS y DDoS de Nivel Militar
• Capítulo 13 – Web Hacking sin Piedad
• Capítulo 14 – Wireless Hacking Avanzado
• Capítulo 15 – Hacking con Dispositivos Móviles
• Capítulo 16 – Clonación de SIM y Ataques IMSI Catcher
• Capítulo 17 – Control Remoto de Dispositivos Móviles (Android e iOS)
• Capítulo 18 – Android como Plataforma de Ataque
• Capítulo 19 – Clonación de SIM: Escenarios Avanzados
• Capítulo 20 – Hombre en el Medio en Redes Móviles
• Capítulo 21 – Rootkits Invisibles
• Capítulo 22 – Malware Fileless
• Capítulo 23 – Keyloggers Indetectables
• Capítulo 24 – Ataques a Cadenas de Suministro (Supply Chain Attacks)
• Capítulo 25 – Exfiltración de Datos Encubierta
• Capítulo 26 – Hacking Físico y Seguridad de Acceso
• Capítulo 27 – Ingeniería Social Avanzada
• Capítulo 28 – OSINT Avanzado
• Capítulo 29 – Ataques a APIs y Microservicios
• Capítulo 30 – Red Teaming Avanzado
• Capítulo 31 – Hacking de Infraestructura Crítica
• Capítulo 32 – Hacking con Drones y Dispositivos Autónomos
• Capítulo 33 – Explotación de IoT Masivo
• Capítulo 34 – Ingeniería Social Avanzada
• Capítulo 35 – Hacking de Redes 5G y Comunicaciones Avanzadas
• Capítulo 36 – Deepfakes y Manipulación Multimedia para Operaciones de Ingeniería Social
• Capítulo 37 – Cierre, Despedida y Declaración Final

Seguir leyendo...

Predator-OS: distro de pentesting, privacidad y educación en ciberseguridad

Predator-OS integra más de 1.200 herramientas clasificadas en 40 categorías y 9 modos de seguridad, adaptándose a todo tipo de expertos y principiantes en ciberseguridad.

Predator-OS (puede dar alertas de seguridad) se está convirtiendo en una de las distribuciones Linux más comentadas entre los entusiastas de la seguridad informática, la privacidad y la educación en ciberseguridad. Destaca por sus configuraciones personalizadas de privacidad, optimización de hardware y arranque, y la incorporación de herramientas de múltiples distribuciones líderes en seguridad.

Ofrece varias ediciones según el perfil de usuario: desde la Home Edition más segura y privada, hasta la Security y Black Edition, diseñadas para pentesting y personalización extrema.

¿Qué es Predator-OS y cuál es su origen?

Predator-OS es una distribución Linux avanzada creada en 2021 por Hossein Seilani. Este desarrollador es conocido por otras distribuciones especializadas en seguridad como Emperor-OS, Hubuntu y Little-Psycho, por lo que su trayectoria avala la seriedad e innovación que encontramos en Predator-OS.

La principal filosofía de Predator-OS gira en torno a tres ejes: seguridad, privacidad y formación académica. No solo está orientada a la realización de pruebas de penetración (penetration testing) y al hacking ético, sino que también busca proporcionar un entorno protegido contra ataques, fácil de endurecer y especialmente diseñado para ser un laboratorio didáctico.

Esta distro está pensada para funcionar tanto en modo Live-CD y USB como instalada en disco, abriendo posibilidades para diferentes perfiles de uso.

Base tecnológica de Predator-OS y requisitos

Predator-OS está construida sobre Debian 12 Stable, garantizando una base sólida, estable y ampliamente compatible. Aprovecha el kernel 6.6.15 LTS (y en ediciones previas, núcleos 6.1 y 5.10 LTS), lo que ofrece soporte actualizado para hardware moderno y flexibilidad en configuraciones específicas, como veremos más adelante.

La arquitectura principal soportada es x86_64, asegurando la máxima compatibilidad con la mayor parte de los equipos actuales. En cuanto a la experiencia gráfica, Predator-OS llega con dos entornos de escritorio completamente personalizados y ligeros: Plasma y MATE. Cada uno está adaptado mediante menús especializados que mejoran la accesibilidad a las herramientas de seguridad y configuración.

Foco en la seguridad, privacidad y anonimato

Si hay algo que define a Predator-OS es su enfoque extremo en la seguridad. Desde su configuración por defecto, tanto a nivel de usuario como de kernel, todo está pensado para minimizar la superficie de ataque y proteger el sistema de accesos no autorizados. Muchos servicios y loggers innecesarios se desactivan durante el arranque, haciendo el sistema más eficiente y seguro.

Las opciones de anonimato y privacidad se han potenciado mediante herramientas especializadas, integración de funciones propias de distribuciones como Kodachi Linux e IprediaOS, y sistemas que permiten el endurecimiento personalizado del entorno. Todo ello convierte a Predator-OS en una elección idónea para quienes buscan proteger tanto su identidad como sus datos.

Gracias a sus políticas de firewall integradas, múltiples utilidades defensivas y modos específicos, los usuarios pueden controlar hasta el más mínimo detalle de su seguridad, además de aprovechar herramientas para el anonimato online y configuraciones de privacidad avanzadas.

Herramientas y modos de funcionamiento de Predator-OS

Predator-OS sobresale por su arsenal de más de 1.200 herramientas preinstaladas (en algunas ediciones, hasta 1.300), repartidas en 40 categorías distintas que cubren todo el espectro de la ciberseguridad:

• Pruebas de penetración (Red Team y Blue Team)
• Análisis forense digital
• Ingeniería inversa
• Recopilación de OSINT (inteligencia de código abierto)
• Seguridad en la nube (AWS, Web3)
• Laboratorio de ciberseguridad
• Pruebas en dispositivos móviles e IoT
• Pruebas de estrés en hardware y software
• Anonimato y privacidad online

Las herramientas provienen de los repositorios oficiales de Debian y Ubuntu y de proyectos alojados en GitHub, asegurando actualizaciones periódicas y acceso a las utilidades más recientes del sector.

Una de las ventajas más destacadas es la disponibilidad en 9 modos de seguridad totalmente personalizables, que permiten orientar el sistema a tareas defensivas, ofensivas, de endurecimiento, privacidad o testeo, según la situación o necesidad concreta. Cambiar entre estos modos es ágil, facilitando el acceso a las herramientas más adecuadas en cada momento.

Además, dispone de librerías y recursos integrados, como más de 2 TB de diccionarios de contraseñas (online y offline), cerca de 800 muestras de malware en 80 familias diferentes, más de 600 herramientas de análisis forense y miles de scripts educativos y recursos de aprendizaje en ciberseguridad.

Ediciones de Predator-OS: Home, Security y Black

Predator-OS presenta varias ediciones adaptadas a diferentes perfiles y necesidades:

• Home Edition: Diseñada para quienes desean un sistema de escritorio enfocado en la privacidad y protección, sin incluir herramientas de hacking o pentesting. Es perfecta para usuarios que buscan anonimato y seguridad básica.
• Security Edition: Orientada a profesionales y entusiastas que requieren un entorno completo con utilidades de pentesting, protección, anonimato y refuerzo del sistema, incluyendo todas las características mencionadas.
• Black Edition: Edición premium con Mammoth Panel, un panel gráfico con más de 2000 configuraciones y ajustes personalizables, facilitando una personalización extrema incluso para usuarios avanzados.

La descarga de las ISOs es sencilla, y la instalación rápida gracias a su instalador gráfico intuitivo.

Recursos educativos y comunidad

Predator-OS no solo es una herramienta potente para la seguridad, sino que también funciona como una plataforma educativa excepcional. Incluye cientos de scripts didácticos, hojas de ruta para aprender ciberseguridad, colecciones de libros prácticos y recursos tanto en línea como offline.

Su interfaz amigable y la documentación accesible facilitan el aprendizaje para principiantes, quienes pueden desarrollar habilidades en auditoría, defensa y análisis desde cero. Los profesionales también encuentran un entorno con utilidades especializadas y opciones para prácticas en entornos virtuales y laboratorios propios.

Comparativa con otras distribuciones de seguridad

Predator-OS destaca por integrar y superar funcionalidades de muchas distribuciones populares en seguridad:

• Incluye todas las herramientas de Bugtraq Linux y suma más utilidades de pentesting web que Samurai Linux.
• Dispone de una colección mayor de herramientas que BackBox, incluyendo todos los paquetes relevantes de Pentoo Linux, y añade funciones forenses de CAINE Linux y deft.
• Implementa características de privacidad y anonimato similares a Kodachi y Discreete Linux, además de opciones de testeo móvil con Santoku Linux y herramientas para IoT y stress testing superiores a Attifyos y stressLinux.
• Integra recursos de comunidades como insecure.org y herramientas OSINT y laboratorios en línea y offline.
• Una ventaja adicional es la posibilidad de ejecutar herramientas de Windows en Linux, lo que resulta especialmente útil en investigaciones o análisis forenses híbridos.

Instalación, arranque y configuraciones extra

La instalación de Predator-OS es sencilla gracias al instalador Calamares, que ofrece una experiencia gráfica intuitiva, permitiendo seleccionar opciones clave y facilitando la partición del disco y la detección de otros sistemas operativos.

El sistema puede arrancar en diversos modos: modo seguro, modo texto, Noacpi, IOMMU, modo forense y CLI puro para usuarios avanzados que prefieran prescindir de la interfaz gráfica. Esto amplía su utilidad en escenarios de recuperación, auditoría o análisis de malware.

El usuario y contraseña por defecto en todas las ISOs estándar es "user/user" o "root/user", facilitando la primera prueba o toma de contacto en máquinas virtuales.

Actualizaciones y soporte

El equipo de desarrollo mantiene un ritmo constante de actualizaciones y mejoras, incluyendo parches de seguridad y nuevas utilidades. La versión más reciente, Predator-OS 3.5, se basa en Debian Stable 12 "Bookworm", con soporte y fecha de lanzamiento claramente documentados.

Un entorno para laboratorio y aprendizaje

Uno de los aspectos más valorados de Predator-OS es su orientación tanto hacia profesionales como para la educación y autoformación. Incluye más de 300 scripts educativos, 100 recursos en línea para practicar, 11 categorías de formación offline, más de 70 sitios de autoaprendizaje y laboratorios virtuales.

Compartir libros, manuales y hojas de ruta en la comunidad convierte a Predator-OS en un entorno casi insustituible para profesores, estudiantes y formadores en ciberseguridad.

Fuentes: Linux-Adictos

Seguir leyendo...

Publicado Kali Linux v2024.2

Kali Linux lanzó la versión 2024.2, con nuevas herramientas y correcciones para el error Y2038.

Como es típico en la primera versión del año, Kali Team ha lanzado nuevos elementos visuales, incluidos fondos de pantalla y actualizaciones del menú de inicio y la pantalla de inicio de sesión.

Dieciocho nuevas herramientas en Kali Linux 2024.2

Kali 2024.2 agrega dieciocho nuevas herramientas:

• autorecon - Multi-threaded network reconnaissance tool
• coercer - Automatically coerce a Windows server to authenticate on an arbitrary machine
• dploot - Python rewrite of SharpDPAPI
• getsploit - Command line utility for searching and downloading exploits
• gowitness - Web screenshot utility using Chrome Headless
• horst - Highly Optimized Radio Scanning Tool
• ligolo-ng - Advanced, yet simple, tunneling/pivoting tool that uses a TUN interface
• mitm6 - pwning IPv4 via IPv6
• netexec - Network service exploitation tool that helps automate assessing the security of large networks.
• pspy - Monitor Linux processes without root permissions
• pyinstaller - Converts (packages) Python programs into stand-alone executables.
• pyinstxtractor - PyInstalller Extractor
• sharpshooter - Payload Generation Framework
• sickle - Payload development tool
• snort - Flexible Network Intrusion Detection System
• sploitscan - Search for CVE information
• vopono - Run applications through VPN tunnels with temporary network namespaces
• waybackpy - Access Wayback Machine's API using Python

Kali dice que no tuvieron tiempo de incluir el kernel de Linux 6.8, que se lanzó el 10 de marzo, pero que se incluirá en la versión 2024.3.

Corrección para el error del año 2038 Y2K28

Similar al error Y2K, el 'problema del año 2038' (también conocido como Y2038 e Y2K38) hará que la hora cambie a 1901-12-13 20:45:52 después de llegar a 2038-01-19 03:14:08 UTC en Linux sistemas cuando las marcas de tiempo UNIX se almacenan en una variable entera time_t de 32 bits.

Para solucionar este problema, los compiladores y bibliotecas cambiaron a enteros time_t de 64 bits más grandes que almacenan correctamente las marcas de tiempo cuando llegamos a 2038. Sin embargo, esto requiere que las aplicaciones y bibliotecas que utilizan las variables de 32 bits anteriores se vuelvan a compilar para no causar problemas.

Para comenzar a usar Kali Linux 2024.2, puede actualizar la instalación existente, seleccionar una plataforma o descargar directamente imágenes ISO para nuevas instalaciones y distribuciones en vivo.

Actualización rápida vía consola:

grep VERSION /etc/os-release
sudo apt update
sudo apt dist-upgrade

Fuente: BC

Seguir leyendo...

Browser In The Browser (BitB) sin Frames

Browser In The Browser (BITB) introducido originalmente por @mrd0x, es un concepto que crea la apariencia de una ventana de navegador creíble dentro de la cual el atacante controla el contenido (sirviendo el sitio web malicioso dentro de un iframe).

Sin embargo, la barra de URL de la ventana del navegador falso está configurada en el sitio legítimo que el usuario esperaría. Esto, combinado con una herramienta como Evilginx, se convierte en la receta perfecta para un ataque de phishing creíble.

El problema es que en los últimos meses/años, los principales sitios web como Microsoft implementaron varios pequeños trucos llamados "framebusters/framekillers" que principalmente intentan romper los iframes que podrían usarse para servir al sitio web proxy, como en el caso de Evilginx.

En resumen, Evilginx + BITB para sitios web como Microsoft ya no funciona. Al menos no con un BITB que se basa en iframes.

Aquí es donde viene la herramienta de Wael Al Masri: Frameless BibB y es simplemente eso, un BITB sin usar iframes, es decir, que podremos usar BitB con Evilginx en sitios web como Microsoft. Esto lo logra inyectando scripts y HTML además del contenido original mediante búsqueda y reemplazo (también conocido como sustituciones), y luego confiando completamente en trucos de HTML/CSS/JS para crear el efecto visual.

También utiliza un truco adicional llamado "Shadow DOM" en HTML para colocar el contenido de la página de destino (fondo) de tal manera que no interfiera con el contenido proxy, lo que nos permite usar de manera flexible cualquier landing page con pocos JS adicionales.

Instrucciones de instalación y más en la web del proyecto https://github.com/waelmas/frameless-bitb

Fuente: HackPlayers

Seguir leyendo...