INTRODUCCIÓN
Un ciberataque se define como un "intento de destruir, exponer, alterar, inhabilitar, robar u obtener acceso no autorizado o hacer un uso no autorizado de un activo" 1 . Con el aumento de los ataques, el estudio de los ciberataques ha adquirido gran relevancia a nivel social. Los ataques de red son inherentemente multietapa o multipaso (MSNA) 2 , lo que significa que constan de al menos dos ataques distintos relacionados. Estos ataques pueden durar horas, días o meses hasta alcanzar su objetivo. Las organizaciones más complejas que son víctimas de un MSNA suelen contar con Centros de Operación de Seguridad (SOCs). Estos SOCs están dedicados a detectar y mitigar los daños causados por estos ataques en una compleja topología de red vigilada. Los SOC utilizan modelos o marcos de trabajo para analizar y categorizar las tácticas, técnicas y procedimientos utilizados en los ciberataques. El Cyber Kill Chain (CKC) desarrollado por Hutchins, Cloppert y Amín 3 , ilustrado en la Figura 1 , está basado en la táctica Kill Chain del F2T2EA utilizado por el ejército de los Estados Unidos. Es un marco de trabajo ampliamente utilizado para este tipo de ataques. El CKC está orientado a desactivar amenazas del tipo "Amenaza Avanzada Persistente" (APT) y recopila inteligencia sobre las amenazas y su uso futuro, permitiendo que el atacante continúe sus actividades después de ser detectado.
Existen variaciones del CKC, como el modelo Unified Kill Chain (UKC) propuesto por Pols 4 , que propone la evolución de un ataque usando 18 etapas. También, Singh, Callupe y Govindarasu 5 propusieron un modelo simplificado del CKC compuesto por cuatro etapas: reconocimiento, acceso, ejecución y persistencia, de acuerdo con la Figura 2 .
La definición de cada uno de los pasos del CKC simplificado de Singh y sus coautores 6 es la siguiente:
Reconocimiento: el atacante trata de recopilar información relevante sobre la red y sus servicios para identificar posibles víctimas y objetivos de ataque. Para ello, puede usar herramientas de red como ping, arp, traceroute, nmap, entre otras.
Acceso: el atacante intenta conectarse a los objetivos seleccionados para descubrir sus posibles vulnerabilidades. Esta información se usará más adelante para lograr acceso y/o escalada de privilegios. En esta etapa, pueden utilizarse herramientas como OpenVAS, Metasploit, Nessus, entre otras.
Lanzamiento/ejecución del ataque: en esta etapa, el atacante intenta explotar las vulnerabilidades encontradas en la red o sus componentes para obtener control sobre ellos. Las actividades pueden incluir virus, gusanos, caballos de Troya, ataques de denegación de servicio (DoS), ataques de Man-in-the-Middle (MITM), violaciones a la integridad y violaciones a la privacidad.
Persistencia: en esta etapa, el atacante crea una puerta trasera para mantener su acceso persistente y poder ingresar en el futuro para repetir el ataque o lanzar múltiples ataques en diferentes plataformas de manera coordinada. La persistencia requiere que el lanzamiento/ejecución se haya realizado con éxito.
Los ejercicios de ciberseguridad tipo Capture the Flag (CTF) han tomado gran relevancia en la demostración de capacidades de detección y respuesta por parte de los SOCs. Según ŠVÁBENSKÝ, ČELEDA, VYKOPAL y BRIŠÁKOVÁ 7 , los participantes pueden aprender habilidades técnicas como criptografía y seguridad de redes, así como aspectos humanos como la ingeniería social y la conciencia de seguridad cibernética. Dado esto, han sido utilizados exitosamente para entrenar profesionales en seguridad de una manera lúdica, tanto por instituciones educacionales 8 como por gobiernos y compañías privadas. Un ejemplo de esto último son los organizados por compañías como Google en 2020 ((?P)) y Facebook en 2019 ((?P)). Existen diferentes tipos de CTFs 9 . Los más conocidos son los del tipo jeopardy (donde es un entorno controlado del equipo contra la máquina) y los de tipo ataque/defensa, en los que nos concentramos en este trabajo. En CTFs ataque/defensa, cada equipo compuesto de hasta 5 miembros tiene una máquina y/o subred, la cual posee tanto programas con vulnerabilidades que deben explotarse para obtener las banderas ocultas. Cada equipo tiene un tiempo corto para parchar sus servicios y desarrollar exploits para luego conectarse con los otros equipos participantes intentando capturar sus banderas. No está permitido bloquear programas vulnerables lo cual es monitoreado durante la competencia. Esta competencia tiene puntos. Cada equipo anota un punto cada vez que logra defender su máquina o atacar la máquina de otros equipos. La defensa otorga puntos, cada equipo tiene la posibilidad de defender su sistema, cuando el equipo está buscando un exploit o vulnerabilidad se puede incluir un parche en el servicio para proteger cualquier fuga de información que pueda ocurrir. Un CTF tiene rondas (por ejemplo de 5 minutos), por lo que en cada una es posible seguir obteniendo puntos si las vulnerabilidades no han sido parchadas en anteriores. El ganador de la competencia es el equipo con la mayor cantidad de puntos.
El DEF CON CTF es conocido por ser uno de los CTF más largos y desafiantes en la comunidad de seguridad informática. En general, participan los 20 mejores equipos del mundo compuesto de 5 miembros. Este CTF es del tipo Ataque-Defensa, es altamente competitivo y riguroso. El primer CTF se realizó en el DEF CON 4 (1996). Su formato actual comenzó en DEF CON 10 (2002). A partir de entonces, se refinó aún más en DEF CON 13 (2005) cuando se enfatizó en la explotación binaria y su corrección. Finalmente, desde DEF CON 25 (2017), se utiliza el emulador cLEMENCy (LEgitbs Middle ENdian Computer) desde el cual se ejecutan los servicios vulnerables para que los participantes estén obligados a prescindir de herramientas avanzadas de corrección de software que podrían favorecer a algún equipo en particular. Dado que en este CTF para que los equipos logren obtener las banderas deben realizar ataques por naturaleza MSNA, la estrategia de este trabajo es caracterizar los MSNAs que se dan en estos eventos. Para ello, hemos primero analizado la literatura respecto de la reconstrucción de ataques multietapa, segundo hemos estudiado cómo obtener de la data de estos CTFs datos en un formato procesable y como tercer paso nos hemos centrado en la caracterización de un evento específico.
Respecto de la literatura destacamos un enfoque basado en meta-alertas correlacionadas, así como alertas únicas no agrupadas para construir grafos de escenarios de APT 10 . Esto se logra construyendo una Máquina de Estados de Kill Chain (KCSM) que opera con datos de alerta agrupados para identificar estados y transiciones de ataques de múltiples etapas. Los grafos de escenarios de APT resultantes de este proceso visualizan posibles campañas de APT en la red y proporcionan un contexto procesable durante las investigaciones. Otro enfoque ha sido utilizar reconocimiento de escenarios de ataque basados en pasos de ataque, lo que permite ofrecer un enfoque flexible para reconocer ataques 11 . El sistema que proponen puede aportar un valor añadido en investigaciones forenses y en honeypots de investigación. Su arquitectura usa seis componentes principales: receptor de alertas, normalización de alertas, preprocesamiento de alertas, agrupación de alertas, reducción de alertas y reconocimiento de escenarios de ataque. Una estrategia recurrente ha sido utilizar un sistema de detección de intrusos (IDS) a partir del registro de tráfico de red de estos eventos para la generación de alertas como paso inicial para la reconstrucción y caracterización 12 .
Este trabajo se divide en las siguientes secciones. Sección II: "Método propuesto para la caracterización de un CTF" donde utilizamos como base el IDS, Snort, para generar un conjunto de alertas a partir de archivos pcaps liberados por la conferencia, luego utilizamos un modelo CKC para clasificar cada alerta y luego una componente visual para presentar los MSNAs; Sección III: "Resultados", donde se muestran los resultados aplicando este método al CTF 22 de la DEF CON; y Sección IV, donde se establecen las conclusiones y el potencial trabajo futuro.
II. MÉTODO PROPUESTO PARA LA CARACTERIZACIÓN DE UN CTF
En esta investigación se propone utilizar el modelo Kill Chain Simplificado en Máquinas de Estado (KCS2ME), es decir, emplear máquinas de estado para representar los pasos del modelo de CKC simplificado visto anteriormente.
Fuente: elaboración propia.
La Figura 3 muestra la propuesta de método para caracterizar ataques multietapa en ejercicios CTF utilizando un enfoque forense basado en alertas en vez de las tramas directas de la red. Esta propuesta consta de dos bloques principales, el primero es la operación de Snort de manera normal sobre las capturas de red y el segundo es la clasificación de las alertas obtenidas según el modelo CKC. La primera parte, que implica la operación normal de Snort, requiere simplemente la selección del CTF a analizar y genera alertas a partir de las capturas de las tramas de red registradas durante el CTF. La segunda requiere el apoyo del software ((?P)) y la clasificación previa de las reglas de Snort a utilizar mediante el modelo CKC, que se encuentran disponibles con el software . Luego, se ejecuta la clasificación de las alertas y la caracterización visual de los CTF.
Por lo tanto, en el bloque de la izquierda se muestra el primer componente del método: Snort, el cual es de fuente abierta, no requiere un pago por licencia y viene integrado con Linux Ubuntu. La entrada al componente Snort incluye las reglas Snort actualizadas previamente en su sitio web y los archivos que contienen las capturas de las tramas de red de CTF, que generalmente están disponibles en formato PCAP (por ejemplo: (?P)). Para procesar el dataset , se ejecuta el siguiente comando: snort -c /etc/snort/snort.conf -r archivo.pcap
Por otro lado, en el bloque derecho de la Figura 3 se pueden observar dos componentes adicionales: Base de Conocimiento y Software MSNA (repositorio de clasificación de alertas y conjunto de scripts que se encuentran disponibles en (?P)). Para el componente Base de Conocimiento, dado que las reglas de Snort son generales, una parte del método consiste en clasificar las reglas en las etapas del modelo CKC, tal como se muestra en la Figura 4 y se describe en el Algoritmo 1. Para ello, primero se genera una plantilla vacía utilizando un script que toma las reglas instaladas dentro de Snort, a partir del cual se extrae el SID de cada regla y se generan los campos necesarios para el siguiente paso.
Algoritmo 1.
Fuente: elaboración propia.
Fuente: elaboración propia.
El componente Base de Conocimiento se refiere al repositorio que almacena tuplas de regla-etapa. Las técnicas utilizadas para realizar la clasificación de las reglas Snort, dentro de una etapa del CKC, son las siguientes:
Basado en el código de la vulnerabilidad: muchas reglas incluyen en su descripción un código de bases de datos de vulnerabilidades como CVE, bugtraq, msb, arachNIDS, osvdb, McAfee, Nessus o una URL que permite obtener información acerca de lo que la regla busca detectar y así clasificarla en el CKC. Un ejemplo de esto se puede ver en la regla 100000223, cuya descripción es reference:bugtraq,16213 , lo que permite encontrar información en (?P)
Basado en la definición de la regla: la regla Snort contiene las condiciones en las que debe alertar algún tipo de ataque, y al interpretar estas condiciones se puede hacer la correspondiente clasificación en el modelo CKC, por ejemplo:
alert tcp $EXTERNAL_NET any - $HTTP_SERVERS $HTTP_PORTS (msg:“WEBATTACKS nmap command attempt”, flow: to_server, established, content: “nmap%20”, nocase, classtype: web application attack, sid:1361, rev:5,)
Allí se indica que se debe generar una alerta cuando un cliente se identifica a sí mismo como "nmap" al conectarse desde el exterior hacia el servidor web, lo que puede interpretarse como un intento de escanear servicios web para obtener información sobre la versión del servidor. Esto se considera como una etapa 2 del modelo CKC.
Basado en la descripción: en la descripción de la regla puede haber un texto que indica de manera certera su naturaleza. Los más importantes son: XSS, Overflow, SQL injection, exploit.
Basado en el uso de herramientas: esto corresponde al uso de herramientas que se sabe qué tipo de resultados generan. Por ejemplo, haciendo reconocimiento de red, usando ping o traceroute, generará alertas que se pueden clasificar como de descubrimiento de red, es decir, de etapa 1 del CKC usado.
Basado en el nombre del archivo: las reglas de Snort se agrupan en archivos por temática, lo que es útil en algunos casos, mientras que en otros no. Entre los nombres de archivo que pueden ayudar a clasificar se encuentran los siguientes: Virus, Backdoor y Shellcode. Estos implican compromiso del host , es decir, etapa 4 del CKC. En cambio, otros nombres como Web o Misc no permiten hacer una adecuada clasificación.
Una vez que el software MSNA procesa las tramas de red de un CTF, se generará un conjunto de alertas clasificadas en el modelo CKC. La salida incluirá un archivo con los Snort ID (SID) de las reglas que no estaban clasificadas en el CKC, además de la cantidad de veces que se encontraron en el archivo de alertas.
Para ello, se realiza el supuesto de que el destino del ataque es un servidor o un grupo de servidores en producción y, por tanto, no tienen usuarios haciendo uso de este en su consola, como en el caso de un equipo de escritorio. Esto implica lo siguiente: 1) Las conexiones salientes son automatizadas, por lo que normalmente una conexión saliente será exitosa y las credenciales de usuario y contraseña serán correctas. Otros comportamientos, como un barrido al exterior, se consideran bajo el control de un atacante; 2) No hay sistemas de chat en uso. Por esta razón, una conexión de chat de salida se considerará una acción de comando y control; 3) Una conexión saliente de un virus implica que el servidor está comprometido; y 4) Una conexión desde el exterior a un servicio del servidor que debería entregarse solo a equipos de la misma LAN se considerará un ataque. Ejemplos de estos servicios son compartir carpetas e impresoras usando protocolo SMB, así como el servicio de proxy. En este último caso, al estar el cliente fuera de la LAN, se considera que esta conexión es una búsqueda de proxy reverso para aprovecharlos de alguna manera (por ejemplo, un ataque de falsa bandera o un salto hacia el interior de la organización).
III. RESULTADOS
DEF CON 22 CTF
En esta investigación hemos decidido caracterizar la DEF CON 22 CTF (2014) porque es la última versión del evento en la que los ataques se detectaron a través de las reglas de Snort. DEF CON 22 CTF se llevó a cabo del 8 al 10 de agosto de 2014. El CTF se realizó por tres días, entre las 9:00 y las 20:00 horas, iniciando la conexión entre distintas subredes a las 10:00 horas en horario de verano del Pacífico en USA (PDT), UTC -7. A cada uno de los 20 equipos participantes se le asignó una red clase C y un host para defender, y los miembros de cada equipo se repartieron las tareas de ataque y defensa durante la competencia. Cada host tenía cuatro servicios vulnerables 13 : eliza , un simulador económico espacial basado en texto, wdub , un servicio web, justify , un solucionador de restricciones e IMAP , un servidor de correo electrónico. Además de defender su propio host y atacar a otros equipos con la misma configuración, también hubo un desafío de hardware. Las banderas se obtenían al explotar vulnerabilidades en los servidores. Los equipos debían defender sus propias banderas y obtener las de sus oponentes, desarrollando parches binarios y llevando a cabo ataques. Según Yam 14 las estrategias utilizadas en los CTF son: Reutilización de exploits, Detección de exploits, Detección de banderas salientes, Hazañas ofuscadas, Ofuscación del tráfico de exfiltración, Destrozar banderas (modificarlas), Colusión y Apalancamiento en recursos externos.
Preparación de Ambiente
Para poder lograr el objetivo de este trabajo, se levantó un laboratorio con Ubuntu 20.04.2.0 LTS, que correspondía a la última versión disponible del sistema operativo a la fecha. Debido a que los ataques aprovechaban vulnerabilidades presentes en bases de datos públicas, se crearon reglas en Snort para detectar dichos ataques. Por tanto, esta versión incluye Snort 2.9.7.0 y se utilizaron las reglas snortrules-snapshot-29171.tar.gz, las cuales se descargaron posterior al registro en la web de Snort ((?P)). En la Figura 5 se muestra un resumen de la clasificación por etapa CKC de las reglas que utiliza Snort para detectar ataques.
Fuente: elaboración propia.
Las capturas de red de los CTFs pueden descargarse en formato CAP desde https://media.defcon.org/DEF%20CON%2022/DEF%20CON%2022%20ctf/. Sin pérdida de generalidad, solo se utilizaron las capturas de la subred del equipo ganador del evento, Plaid Parliament of Pwning (PPP), las cuales tienen un tamaño comprimido de 4.47 GB. Se descargó esta información utilizando el archivo torrent proporcionado por el sitio web, puesto que admite la recuperación de descargas interrumpidas. El dataset incluyen las conexiones con origen o destino desde 10.5.1.0/24. Algunas de las conexiones registradas en la subred corresponden a ataques al servidor 10.5.1.2, mientras que otras corresponden a ataques desde algún equipo de la subred hacia los otros servidores objetivos. También hay conexiones al servidor que mantiene el conteo del puntaje y verifica las banderas, llamado Scorebot, y navegación normal desde los equipos de la subred. Al momento de procesar las alertas, el servidor donde está Snort tenía configurado horario de invierno de Chile continental (UTC-4), por lo que las alertas se generaron con una diferencia de 3 horas. En la Figura 6 se observa la frecuencia de los ataques agrupada en bloques de 15 minutos, en donde los ataques en el bloque de las 17:30 horas sobresalen del resto.
Fuente: elaboración propia. Generado utilizando las alertas obtenidas por SNORT.
Por otra parte, en la Figura 7 se puede apreciar un alza en los ataques poco antes del fin del evento.
Fuente: elaboración propia. Generado utilizando las alertas obtenidas por Snort.
Utilizando Wireshark para analizar el archivo de captura de red "ppp_00100_201408 09181755.cap" y empleando el filtro "(ip.addreq 10.5.1.110 and ip.addreq 10.5.19.2) and (tcp.port eq 143) ", se pueden ver cuatro acciones que conducen a un ataque exitoso, las cuales se muestran en la Figura 8 : 1. Inicio de sesión, 2. Creación de un mailbox, 3. Seleccionar en mailbox creado con desbordamiento de buffer y 4. Obtención de la bandera.
Fuente: elaboración propia. Captura de imagen de Wireshark.
En la Figura 9 se puede observar la obtención de la bandera mediante un ataque de " directory traversal " (también conocido como "salto de directorio", "cruce de directorio" o " path traversal "), que consiste en escapar del directorio web en que el servicio debería estar confinado. En este caso, la bandera se encuentra dentro del archivo /home/wdub/flag.
Fuente: elaboración propia. Captura de imagen de Wireshark.
Debido a la componente de defensa del CTF, los ataques que son exitosos al principio pueden dejar de serlo posteriormente, dependiendo principalmente de la calidad de los parches binarios creados por los defensores. Además, existen otros ataques, algunos de los cuales son exploratorios, mientras que otros no están claros si fueron o no exitosos. También se registran ataques entre estaciones de trabajo, los cuales no otorgan puntos en el CTF, pero pueden ayudar a entorpecer el trabajo de un equipo contrincante
Aplicación del método a la DEF CON 22 CTF
Tras el procesamiento de las capturas de red del CTF mediante Snort, se obtuvo un archivo consolidado de alertas que se filtró según el atacante, el objetivo, o por ambos. Posteriormente, estas alertas filtradas se sometieron al algoritmo de clasificación según la CKC. A continuación, se presentan dos casos representativos para caracterizar un CTF:
- Todos los equipos contra el equipo PPP (10.5.1.2).
ii) El equipo HITCON (10.5.9.2) atacando al equipo PPP (10.5.1.2).
- Escenario de ataque usando 10.5.1.2 como objetivo
En la Figura 10 se pueden apreciar los ataques dirigidos al servidor 10.5.1.2, el cual es defendido por el equipo PPP. Estos ataques son realizados por los 19 equipos restantes. Los anchos de cada una de las líneas son similares entre sí para el caso de las que ingresan a la misma barra, que representa cada etapa del CKC, por lo que a primera vista parecen similares entre sí.
Fuente: elaboración propia. Generado automáticamente con el software MSNA.
ii) Escenario de ataque usando 10.5.1.2 como objetivo y 10.5.9.2 como atacante
Durante el CTF se registraron 995 ataques desde 10.5.9.2 a 10.5.1.2, representados en la Figura 11 . Estos se inician con siete ataques de etapa 1, seguidos de 15 de etapa 3. Desde la tercera línea, se puede apreciar que esta es roja, lo que indica que es un ataque de etapa 4. Luego de esto, se mantiene una intermitencia principalmente compuesta por varios ataques de etapa 3 y unos pocos de etapa 4. Solo ocasionalmente aparecerán otras etapas. La línea más larga corresponde a 32 ataques tipo etapa 3 del CKC.
Fuente: elaboración propia. Generado automáticamente con el software MSNA.
En la Figura 12 , los ataques de una etapa particular del CKC corresponden al mismo número de etapa. Se puede apreciar que la mayoría de los estados son 3, cuyo estado previo era 3, y que luego, por orden de cantidad, están los estados 3 cuyo estado previo era 4, y los de estado 4 donde el estado previo era 3. Los estados relacionados con 1 y 2 son menores que los otros estados, por lo que parece que hubo poca actividad relacionada con estas etapas.
Fuente: elaboración propia. Generado automáticamente con el software MSNA.
Discusión de los resultados DEF CON 22 CTF
- Escenario de ataque usando 10.5.1.2 como objetivo
En la Figura 10 , la similitud en los anchos de cada una de las líneas que ingresan a la misma etapa CKC implica similitud en la cantidad, proporción y clasificación de los ataques entre los diferentes atacantes. Considerando que los atacantes pueden hacer ingeniería inversa con los ataques recibidos, es esperable que los equipos se retroalimenten entre sí en la medida en que son atacados. Esta similitud permite utilizar un solo ataque como referencia para describir al resto.
ii) Escenario de ataque usando 10.5.1.2 como objetivo y 10.5.9.2 como atacante
En cuanto al gráfico de máquina de estado, en la Figura 12 se puede apreciar que el estado que tiene más alertas es el de etapa 3, con un total de 652, de los cuales 489 tienen como etapa previa la misma etapa 3 y los restantes de otras etapas. El mayor número de ataques de etapa 3 puede deberse a que hay que hacer múltiples ataques de esta etapa antes de lograr un ataque exitoso. Luego de lograr el éxito, se realizan las exfiltraciones de información o, en este contexto, la obtención de la bandera mediante un ataque de etapa 4. Después de esto, se inicia nuevamente el ciclo del MSNA. El motivo para iniciar un nuevo MSNA es que el valor de la bandera cambia en cada round, generando nuevos puntos cuando se tiene la bandera actualizada, también podrían haberse parchado servicios de un round a otro, por lo que se necesita buscar, detectar y explotar nuevas vulnerabilidades. El evento DEF CON 22 CTF se dividió en 272 rondas de cinco minutos cada una. Al comienzo a cada equipo se le asignaron 2502 banderas, las que se distribuyeron igualmente entre los seis servicios 15 .
En cuanto a la información obtenida al inicio, debería ser suficiente para toda la operación, dado que no se producen cambios en la infraestructura de red entre un MSNA y otro. Por lo tanto, no es necesario volver a obtenerla.
Al revisar las figuras 11 y 12 se puede observar que, una vez finalizado un ciclo de CKC o de un ataque MSNA, estos ciclos se reinician. Se pueden identificar ciclos cortos que solo regresan a ataques de etapa 3 y otros ciclos un poco más largos que regresan hasta la etapa 2. La falta de pasos de etapa 1 puede deberse a que no se necesita un nuevo descubrimiento de la red. En total, se completaron 148 ataques MSNA, de los cuales 26 provienen de la etapa 2 y 122 provienen de la etapa 3.
CONCLUSIONES Y TRABAJO FUTURO
En este trabajo se caracterizaron los ataques MSNA en un ejercicio CTF mediante el enfoque forense. El método usado para esto fue un KCS2ME, el cual se apoyó en una herramienta de amplio uso y de muchos años de desarrollo como Snort. De esa manera, se aplicó un conjunto de reglas para determinar las cualidades o rasgos característicos de los ataques del DEF CON 22 CTF. Si bien un enfoque basado en reglas es considerado rígido, la clasificación de los ataques individuales en etapas CKC lo hace más general, pudiendo con ello haber hecho una comparación entre ataques MSNA.
Claramente, existen diferencias entre un CTF de ataque-defensa y un MSNA en ambiente real. Por ejemplo, 1) el sistema a defender es prácticamente idéntico al sistema que se debe atacar, y en un ataque real solo se podría acceder al software base, como servicios y sistema operativo, pero no a configuraciones ni software hecho a medida, como páginas web. 2) Es posible descubrir vulnerabilidades y ataques explotables al hacer ingeniería inversa de los ataques recibidos. 3) En el mundo real, un atacante externo necesita obtener información de la red mediante la realización de ataques que se encuentran clasificados en la etapa 1 del CKC, mientras que, en un CTF, las redes y los blancos de los ataques están predefinidos. 4) Una vez que se realiza un ataque exitoso, no pasa mucho tiempo para que el equipo de defensa pueda crear una contramedida en forma de parche binario, lo que obliga al atacante a crear un nuevo ataque o una nueva variante del anterior.
Futuros investigadores podrían abordar las limitaciones de este estudio de varias maneras. Por ejemplo, podrían ampliar la cantidad de reglas clasificadas, las cuales hoy son 7750; usar otros CKC para buscar patrones de ataque generales diferentes, como ATP, a fin de complementar el actual módulo. También podrían buscar formas de encontrar patrones de CKC en distintas combinaciones de orígenes y destinos de las alertas, así como también su extensión a casos reales. También se podrían considerar la colusión entre equipos, en donde los ataques a estudiar no son solo uno a uno, o bien un estudio que se enfoque dentro de cada round.