Análisis de la capacidad de detección de Snort sobre ataques de red en ICS bajo la matriz MITRE ATT&CK

Equation Chapter 1 Section 1 Trabajo Fin de Grado Ingeniería de Telecomunicación Análisis de la capacidad de detección de Snort sobre ataques de red en ICS bajo la matriz MITRE ATT&CK Dpto. Telemática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Autor: Pablo Benítez Sánchez Tutor: Francisco Javier Muñoz Calle Sevilla, 2022 iii Proyecto Fin de Grado Ingeniería de Telecomunicación Análisis de la capacidad de detección de Snort sobre ataques de red en ICS bajo la matriz MITRE ATT&CK Autor: Pablo Benítez Sánchez Tutor: Francisco Javier Muñoz Calle Profesor colaborador Dpto. de Telemática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2022 v Proyecto Fin de Grado: Análisis de la capacidad de detección de Snort sobre ataques de red en ICS bajo la matriz MITRE ATT&CK Autor: Pablo Benítez Sánchez Tutor: Francisco Javier Muñoz Calle El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros: Presidente: Vocales: Secretario: Acuerdan otorgarle la calificación de: Sevilla, 2022 El Secretario del Tribunal vii A mi familia A mis profesores ix Agradecimientos Agradezco a mi tutor D. Francisco Javier Muñoz Callle su implicación en la elaboración de este trabajo y la ayuda inestimable en la resolución de dudas, todo ello siempre de la forma más rápida y atenta. ÍNDICE DE FIGURAS Figura 2-1. Diagrama de un ICS [1] 4 Figura 2-2. Modbus TCP ADU [2] 5 Figura 2-3. Esquema de comunicación DNP3 [4] 7 Figura 2-4. Trama de nivel de enlace DNP3 [4] 7 Figura 2-5. Cabecera de nivel de pseudo-transporte DNP3 [4] 8 Figura 2-6. Cabecera de nivel de transporte DNP3 [4] 8 Figura 2-7. Fragmentos de nivel de aplicación DNP3 [4] 9 Figura 2-8- Cabeceras de nivel de aplicación DNP3 [4] 9 Figura 2-9. Campo de control de aplicación DNP3 [4] 9 Figura 2-10. Cabecera de Objeto DNP3 [4] 11 Figura 2-11. Mensaje completo DNP3 [4] 11 Figura 2-12. Encapsulación S7comm [7] 12 Figura 2-13. Cabecera de S7PDU [7] 12 Figura 2-14. Estructura del mensaje Setup Communications de S7comm [8] 13 Figura 2-15. Campo Parameters – Item del mensaje de tipo Read/Write de S7comm [9] 13 Figura 2-16. Cabecera de datos de peticiones de escritura DNP3 [9] 14 Figura 2-17. Diagrama de paso de mensajes CIP sin conexión [10] 15 Figura 2-18. Diagrama de paso de mensajes CIP con conexión [10] 16 Figura 2-19. Torre de protocolos PCCC/CIP 17 Figura 2-20. Estructura del mensaje PCCC 17 Figura 3-1. Diagrama de paso de mensajes – Rogue Master 21 Figura 3-2. Creación Esclavo DNP3 – Rogue Master 22 Figura 3-3. Parámetros configurables del Esclavo DNP3 – Rogue Master 23 Figura 3-4. Parámetros configurables (cont.) del Esclavo DNP3 – Rogue Master 23 Figura 3-5. Creación de variables en el Esclavo DNP3 – Rogue Master 24 Figura 3-6. Variables Esclavo DNP3 – Rogue Master 24 Figura 3-7. Pestaña Data_Objects_1 Esclavo – Rogue Master 25 Figura 3-8. Creación Maestro DNP3 – Rogue Master 25 Figura 3-9. Parámetros configurados del Maestro DNP3 – Rogue Master 26 Figura 3-10. Data Objects Maestro DNP3 – Rogue Master 26 Figura 3-11. Menu Station Commands > Freeze and Clear – Rogue Master 27 Figura 3-12. Menu Station Commands > Freeze and Clear > Counter-Immediate-Freeze-and-Clear-No- Ack – Rogue Master 27 xvii Figura 3-13. Resultado Freeze and Clear no ACK – Rogue Master 28 Figura 3-14. Menu Station Commands > Freeze and Clear > Counter-Immediate-Freeze-and-Clear- No-Ack – Rogue Master 28 Figura 3-15. Resultado Immediate Freeze – Rogue Master 29 Figura 3-16. Menu Station Commands > Spontaneous Command – Rogue Master 29 Figura 3-17. Menu Station Commands > Spontaneous Command > Enable Unsolicited Messages – Rogue Master 29 Figura 3-18. Menu Station Commands > Special DNP3 Command – Rogue Master 30 Figura 3-19. Menu Station Commands > Special DNP3 Command > Cold Restart – Rogue Master 30 Figura 3-20. Menu Station Commands > Special DNP3 Command > Warm Restart – Rogue Master 31 Figura 3-21. Diagrama de paso de mensajes – Escaneo de direcciones IP que usen S7comm 32 Figura 3-22. Configuración de dirección IP para el PLC – Escaneo de equipos que usen S7comm 33 Figura 3-23. Configuración de nivel de acceso para el PLC – Escaneo de direcciones equipos que usen S7comm 33 Figura 3-24. Compilación del PLC – Escaneo de equipos que usen S7comm 34 Figura 3-25. Resultado de la compilación del PLC – Escaneo de equipos que usen S7comm 34 Figura 3-26. Botón cargar configuración – Escaneo de equipos que suen S7comm 34 Figura 3-27. Pantalla de carga de configuración – Escaneo de equipos que usen S7comm 35 Figura 3-28. Detección de PLCSIM para la carga de configuración – Escaneo de equipos que usen S7comm 35 Figura 3-29. PLCSIM – Escaneo de equipos que usen S7comm 36 Figura 3-30. NetToPlcSim – Escaneo de equipos que usen S7comm 36 Figura 3-31. Configuración de NetToPlcSim – Escaneo de equipos que usen S7comm 37 Figura 3-32. Resultado del ataque – Escaneo de equipos que usen S7comm 37 Figura 3-33. Diagrama de paso de mensajes Nmap - Escaneo de equipos que usen Modbus 38 Figura 3-34. Diagrama de paso de mensajes Metasplot modbus_findunitid - Escaneo de equipos que usen Modbus 39 Figura 3-35. ModbusPal – Escaneo de equipos que usen Modbus 40 Figura 3-36. Definición de un esclavo Modbus – Escaneo de equipos que usen Modbus 41 Figura 3-37. Configuración del esclavo Modbus – Escaneo de equipos que usen Modbus 41 Figura 3-38. Creación de los registros de almacenamiento del esclavo Modbus – Escaneo de equipos que usen Modbus 42 Figura 3-39. Resultado del ataque Nmap – Escaneo de equipos que usen Modbus 43 Figura 3-40. Opciones modbus_findunitid – Escaneo de equipos que usen Modbus 43 Figura 3-41. Resultado del ataque Metasploit – Escaneo de equipos que usen Modbus 43 Figura 3-42. Diagrama paso de mensajes – Remote System Information Discovery 45 Figura 3-43. Menu Station Commands > Read Device Attributes – Remote System Information Discovery 46 Figura 3-44. Menu Station Commands > Read Device Attributes > Device Manufacturer Name – Remote System Information Discovery 46 Figura 3-45. Menu Station Commands > Read Device Attributes > Device Name and Model – Remote System Information Discovery 47 Figura 3-46. Menu Station Commands > Read Device Attributes > Device Serial Number – Remote System Information Discovery 47 Figura 3-47. Menu Station Commands > Read Device Attributes > Non-Specific all Attributes – Remote System Information Discovery 48 Figura 3-48. Diagrama paso de mensajes – Lateral Movement 49 Figura 3-49. Estado inicial del esclavo Modbus – Lateral Movement 50 Figura 3-50. Ejecución de PLCInjector – Lateral Movement 50 Figura 3-51. Resultado del ataque – Lateral Movement 51 Figura 3-52. Diagrama de paso de mensajes – Automated Collection 52 Figura 3-53. PLCSIM Advanced – Automated Collection 53 Figura 3-54. Configuración de interfaces de red de PLCSIM Advanced – Automated Collection 53 Figura 3-55. Conexión entre interfaces de red – Automated Collection 54 Figura 3-56. Direccionamiento de las interfaces de red – Automated Collection 55 Figura 3-57. Resultado echo-request PLC virtual – Automated Collection 55 Figura 3-58. Opciones del módulo snmp_enum de Metasploit – Automated Collection 56 Figura 3-59. Información obtenida sobre el sistema y los parámetros de red – Automated Collection 56 Figura 3-60. Información obtenida sobre las interfaces de red del equipo – Automated Collection 57 Figura 3-61. Información obtenida sobre la red, encaminamiento y puertos TCP y UDP – Automated Collection 58 Figura 3-62. Diagrama de paso de mensajes RealWin Server – Command and Control 60 Figura 3-63. Diagrama de paso de mensajes Ignition SCADA – Command and Control 61 Figura 3-64. Servidor RealWin y puertos a la escucha – Commonly Used Port 62 Figura 3-65. Opciones del módulo realwin_scpc_initialize de Metasploit – Commonly Used Port 62 Figura 3-66. Terminal Meterpreter RealWin– 1 – Commonly Used Port 63 Figura 3-67. Terminal Meterpreter RealWin – 2 – Commonly Used Port 63 Figura 3-68. Terminal Meterpreter RealWin – 3 – Commonly Used Port 64 Figura 3-69. Terminal de Meterpreter Ignition SCADA - Commonly Used Port 65 Figura 3-70. Diagrama de paso de mensajes – Inhabit Response Function 66 Figura 3-71. Selección de procesador RSLogix Micro – Denial of Service 67 Figura 3-72. Selección de driver de comunicación RSLinx – Denial of Service 67 Figura 3-73. Selección de driver de comunicación RSLinkx (cont.) – Denial of Service 68 Figura 3-74. Menú RSLinx – 1 – Denial of Service 68 Figura 3-75. Iniciar controlador virtual en RSLogix Emulate 500 – Denial of Service 69 Figura 3-76. Menú RSLinx – 2 – Denial of Service 69 xix Figura 3-77. Sincronización RSLogix Micro/TEST – Denial of Service 70 Figura 3-78. RSLogix Micro modo REMOTE RUN – Denial of Service 70 Figura 3-79. Puertos abiertos equipo víctima – Denial of Service 71 Figura 3-80. Opciones módulo allen_bradley_pccc Metasploit – Denial of Service 71 Figura 3-81. Diagrama de paso de mensajes – Device Restart/Shutdown 72 Figura 3-82. Opciones del módulo multi_cip_command – Device Restart/Shutdown 73 Figura 3-83. Resultado del ataque – Device Restart/Shutdown 73 Figura 3-84. Diagrama de paso de mensajes – Modify Parameter 74 Figura 3-85. Estado inicial de los registros de almacenamiento – Modify Parameter 75 Figura 3-86. Opciones modbusclient Metasploit Write Single Register – Modify Parameters 75 Figura 3-87. Ejecución modbusclient Write Single Register – Modify Parameters 76 Figura 3-88. Resultado de la función Write Single Register – Modify 76 Figura 3-89. Opciones modbusclient Metasploit Write Multiple Registers – Modify Parameters 77 Figura 3-90. Ejecución modbusclient Write Multiple Registers – Modify Parameters 77 Figura 3-91. Resultado de la función Write Multiple Registers – Modify Parameter 78 Figura 3-92. Diagrama de paso de mensajes – Damage to Property 79 Figura 3-93. Creación bloque de datos S7-1200 – Damage to Property 80 Figura 3-94. Variables S7-1200 – Damage to Property 80 Figura 3-95. Estado inicial DB2 S7-1200 – Damage to Property 81 Figura 3-96. Inicialización de Node-RED – Damage to Property 81 Figura 3-97. Conexión de los nodos Node-RED – Damage to Property 82 Figura 3-98. Configuración nodo s7comm output Node-Red – Damage to Property 83 Figura 3-99. Configuración nodo inject Node-Red – Damage to Property 84 Figura 3-100. Ejecución de Node-Red – Damage to Property 85 Figura 3-101. Resultado del ataque TIA Portal – Damage to Property 85 Figura 3-102. Valores petición S7comm – Damage to Property 86 Figura 3-103. Diagrama de paso de mensajes – Loss of Productivity and Revenue 87 Figura 3-104. Estado inicial equipo víctima – Loss of Productivity and Revenue 88 Figura 3-105. Opciones modbusclient Metasploit Write Multiple Coils – Loss of Productivity and Revenue 89 Figura 3-106. Ejecución modbusclient Write Single Register – Modify Parameters 89 Figura 3-107. Resultado de la función Write Single Register – Modify Parameter 89 Figura 3-108. Diagrama de paso de mensajes – Manipulation of Control 90 Figura 3-109. Estado inicial equipo víctima – Manipulation of Control 91 Figura 3-110. Menu Point Command – Manipulation of Control 91 Figura 3-111. Point Command BINARY_OUTPUT – Manipulation of Control 92 Figura 3-112. Point Command ANALOG_OUTPUTS – Manipulation of Control 92 Figura 3-113. Resultado del ataque – Manipulation of Control 93 Figura 3-114. Diagrama de paso de mensajes – Lectura de registros mediante mensajes Modbus 94 Figura 3-115. Estado inicial registros de almacenamiento – Lectura de registros mediante mensajes Modbus 95 Figura 3-116. Estado inicial registros coils – Lectura de registros mediante mensajes Modbus 95 Figura 3-117. Resultado de la función Read Coils – Lectura de registros mediante mensajes Modbus 96 Figura 3-118. Resultado de la función Read Holding Registers – Lectura de registros mediante mensajes Modbus 96 Figura 3-119. Diagrama de red – Lectura de registros mediante mensajes S7comm 97 Figura 3-120. Conexión de los nodos Node-RED – Lectura de registros mediante mensajes S7comm 98 Figura 3-121. Resultado del ataque VariableInt1 – Lectura de registros mediante mensajes S7comm 98 Figura 3-122. Resultado del ataque Start – Lectura de registros mediante mensajes S7comm 99 Figura 3-123. Diagrama de paso de mensajes – Descubrimiento del sistema de directorios mediante DNP3 100 Figura 3-124. Resultado Direcory Read – 1 – Descubrimiento del sistema de directorios mediante DNP3 101 Figura 3-125. Resultado Direcory Read – 2 – Descubrimiento del sistema de directorios mediante DNP3 102 Figura 3-126. File Transfer – Read – Obtención de ficheros mediante DNP3 103 Figura 4-1. Diagrama de un IDS [42] 105 Figura 5-1. Distribución de las detecciones por protocolo (TALOS) 115 Figura 5-2. Porcentaje de ataques detectados en cada táctica de la matriz de MITRE (TALOS) 115 Figura 5-3. Distribucion de los ataques detectados por táctica de la matriz de MITRE (TALOS) 116 Figura 5-4. Distribución de las detecciones por protocolo (ETopen) 119 Figura 5-5. Porcentaje de ataques detectados en cada táctica de la matriz de MITRE (ETopen) 119 Figura 5-6. Distribucion de los ataques detectados por táctica de la matriz de MITRE (ETopen) 120 Figura 5-7. Distribución de las detecciones por protocolo (QuickDraw) 122 Figura 5-8. Porcentaje de ataques detectados en cada táctica de la matriz de MITRE (QuickDraw) 122 Figura 5-9. Distribucion de los ataques detectados por táctica de la matriz de MITRE (QuickDraw) 123 Figura 6-1. Comparativa de las detecciones por cada conjunto de reglas. 127 Figura 6-2. Distribucion de las detecciones por protocolo 128 Figura 6-3. Porcentaje de ataques detectados en cada táctica de la matriz de MITRE 128 xxi Objetivos y Alcance 2 1 OBJETIVOS Y ALCANCE nort es uno de los IDS (Intrusion Detection System) libres y gratuitos más utilizados del mercado, que se actualiza constantemente con nuevas formas de detectar ataques de red y con una comunidad muy activa que fomenta el desarrollo de reglas en paralelo con el equipo de desarrollo. Este trabajo forma parte de una línea de investigación que pretende probar las capacidades del IDS específicamente en entornos industrializados, ICS, utilizando protocolos usados en este tipo de sistemas. Entre los principales objetivos del trabajo, por tanto, se encuentran: • Realizar distintos ataques aplicables a ICS los cuales generen tráfico de red. Para ello se utilizarán herramientas que simulen dispositivos y protocolos utilizados en ICS, tanto para Windows como para Linux. • Análisis de dichos ataques usando el IDS Snort y los paquetes de reglas de TALOS, ETopen y QuickDraw. • Discusión de resultados de los ataques detectados por cada paquete de reglas, comprobando la cantidad de ataques detectados por cada paquete y comparándola con el resto de los paquetes, además de analizar por qué o por qué no se han detectado los ataques. En cuanto al alcance del trabajo, se limitará a estudiar ataques que presenten tráfico de red de ataque, puesto que es solo de esa forma podrán ser detectados Snort. Además, la categorización de estos estará definida por la matriz de MITRE ATT&CK. También se buscarán ataques que puedan ser reproducidos utilizando herramientas preferiblemente de código abierto y gratuitas, o también propietarias pero que cuenten con licencias de prueba. S 3 Análisis de la capacidad de detección de Snort sobre ataques de red en ICS bajo la matriz MITRE ATT&CK 2 BASE TEÓRICA n esta sección se introducirán las bases de los sistemas industrializados, además de describir los protocolos específicos de estos entornos más relevantes para los ataques de este trabajo. Además, de comentarán los principales aspectos de la seguridad de los sistemas industriales 2.1. Introducción a los Sistemas de Control Industriales El término ICS, o Industrial Control System, se refiere al conjunto de infraestructura, sistemas, dispositivos y protocolos cuya función es administrar, operar y automatizar procesos industriales. Los ICS se utilizan en todo tipo de industria, por ejemplo, la eléctrica, alimenticia, química, farmacéutica y un largo etcétera. Existen dos tipos principales de ICS: - Supervisory Control and Data Acquisition (SCADA): estos sistemas tienen como función el control centralizado de un ICS el cual tiene sus distintos componentes en localizaciones geográficas diferentes. En este tipo de sistemas es tan importante el control de procesos como la adquisición de los datos para su procesamiento centralizado. - Distributed Control System (DCS): en este tipo de sistemas se tiene como función principal el control de un ICS donde todos sus componentes están en la misma localicación geográfica. Debido a la naturaleza distribuida de los SCADA/ICS, este tipo de sistemas son más propensos a utilizar redes basadas en TCP/IP, mientras que los DCS pueden basarse en redes con conexiones serie. Esto significa que los SCADA/ICS son más propensos a ataques de red, y es el tipo de ICS en el que se centrará este trabajo. Dentro del conglomerado que constituye los ICS, tanto SCADA como DCS, podemos diferenciar ciertos componentes esenciales: - Programmable Logic Controller (PLC): equipo hardware usado para administrar el control sobre entornos ICS. Es capaz de dar y recibir ordenes para interactuar con otros elementos de una red de ICS. Normalmente se encuentran a cargo de el control de dispositivos como actuadores, sensores o maquinaria industrial. En el caso de sistemas SCADA pueden tener la misma funcionalidad que las RTU. - Remote Terminal Unit (RTU): es un dispositivo pensado para recopilar información del ICS para luego reportarla, además recibir órdenes de un equipo maestro (MTU). - Human Machine Interface (HMI): interfaz usada por los operarios de un entorno ICS para interactuar y configurar con los sistemas de control. - SCADA Server or Master Terminal Unit (MTU): equipo encargado de manejar los distintos niveles de control dentro de un ICS. - Data Historian: equipo cuya función es almacenar y recopilar información acerca de todos los procesos dentro de un ICS para su posterior análisis. En la Figura 2-1 se puede ver un diagrama de un ICS donde se ven reflejados los componentes descritos: E Base Teórica 4 Figura 2-1. Diagrama de un ICS [1] La mayor diferencia entre las redes de entornos empresariales y las redes de ICS es la importancia que se le da a la protección de los datos frente a la protección de los procesos. Por un lado, una de las máximas prioridades de las redes convencionales es la integridad y confidencialidad de los datos que viajan a través de ella. Sin embargo, en las redes de ICS la máxima prioridad es proteger la continuidad de los procesos industriales, puesto que su interrupción provoca una enorme pérdida de beneficios para cualquier ICS. Evidentemente, en las redes convencionales también es muy importante que los datos se transmitan correctamente y de forma fiable, al igual que en una red ICS los datos que se transmiten contienen información operacional confidencial para el ICS. No obstante, prioridades críticas para ambos tipos de redes son las expuestas en el párrafo anterior, ya que, en una red tradicional, los datos de una transacción bancaria se pueden 5 Análisis de la capacidad de detección de Snort sobre ataques de red en ICS bajo la matriz MITRE ATT&CK volver a transmitir, pero su contenido es de alto valor, mientras que en una red ICS, aunque los datos pueden tener información valiosa para un atacante, el hecho de que los distintos componentes de la red funcionen correctamente de forma continuada es mucho más critico. 2.1 Protocolos Utilizados En las redes de ICS se utilizan protocolos específicos que se adaptan a las necesidades que tienen las comunicaciones industriales. En este apartado se verán algunos de los protocolos más usados en ICS y relevantes para este trabajo. 2.2.1 Modbus TCP Modbus es un protocolo libre de capa de aplicación del modelo OSI muy utilizado en ICS debido a su gran simplicidad y ligereza. Este protocolo se basa en la arquitectura Maestro/Esclavo, donde el Maestro será el encargado de mandar distintas órdenes a uno o varios Esclavos, mientras que estos se dedicarán a responder las distintas peticiones del Maestro. Inicialmente se desarrollo en 1979 por Modicom, más tarde convirtiéndose en Schneider Electric, para comunicaciones serie en redes industrializadas, aunque actualmente se usa en redes TCP/IP, por defecto, en el puerto 502. Encapsuladas sobre los paquetes TCP encontramos ADUs, las cuales incluyen una cabecera MBAP y una PDU, siguiendo el formato: Figura 2-2. Modbus TCP ADU [2] En la Figura 2-2 se pueden diferenciar los siguientes campos: - Transaction ID: identifica cada petición entre el Maestro y el Esclavo. - Protocol ID: identifica el protocolo, para Modbus TCP siempre será “00 00”. - Longitud: número de bytes del mensaje Modbus. - Unit ID: identifica la instancia de Modbus en el equipo destino. - Function Code: código que identifica la función Modbus. Aunque el campo es de 1 byte existen códigos de función de el 0 al 127, ya que el bit más significativo de este campo siempre se mantiene a 0 en las peticiones Modbus. Si se produce una excepción Modbus en la respuesta, el bit más significativo del campo Function Code pasará a ser 1 indicando así que se ha producido la excepción. - Datos: el contenido de este campo depende de la función empleada. Las PDUs de Modbus tienen, históricamente, un tamaño máximo de 253 bytes, ya que el tamaño máximo de las tramas de la versión de Modbus para comunicación serie eran 253 bytes, añadiendo los 7 bytes de la cabecera MBAP contamos con ADUs de 260 bytes como máximo. Las PDUs pueden ser de tres tipos: petición, respuesta o excepción. En el modelo de datos que sigue Modbus podemos encontrar objetos de 1 bit como los Coils o Discrete Imputs, o de 16 bits como los Holding Registers o Input Registers. Los objetos de tipo Coil o Holding Register son leídos y modificados por aplicaciones que utilicen Modbus, mientras que los Discrete Imputs y Input Registers son objetos que sólo permiten lectura por sistemas I/O. Base Teórica 12 Figura 2-12. Encapsulación S7comm [7] La cabecera de la S7PDU tiene el siguiente formato: Figura 2-13. Cabecera de S7PDU [7] En la Figura 2-13, se pueden diferenciar: - Protocol ID (1 byte): identifica al protocolo, en el caso de S7comm siempre será 0x32. - MSG Type (1 bye): indica el tipo de mensaje que se está enviando. Podemos diferenciar los siguientes tipos: o Job Request: petición del maestro. o Ack: confirmación por parte del esclavo. o Ack-Data: confirmación por parte del esclavo a una petición de Job Request. o Userdata: - Reserved (2 bytes): siempre se mantienen a 0. - PDU Ref (2 bytes): se usa para identificar a una petición/respuesta como parte de la misma transacción. - Param Length (2 bytes): número de bytes del campo Parámetros. - Data Length (2 bytes): número de bytes del campo Datos. - Error Class (1 byte): información sobre errores en la respuesta. - Error Code (1 byte): información sobre errores en la respuesta. En el campo de Parameters tiene una estructura específica por cada tipo de mensaje de S7comm. A continuación, se describe la estructura para los tipos de mensajes utilizados en el trabajo. • SetUp Communication: al principio de cada sesión S7comm, el maestro enviará un mensaje de Setup Communication y el esclavo mandará un mensaje de respuesta. En este intercambio de mensajes, se negocian parámetros de la sesión como la longitud máxima de la S7PDU o el número máximo de peticiones sin ACK que se permiten. Para este tipo de mensaje, la estructura es la siguiente: 13 Análisis de la capacidad de detección de Snort sobre ataques de red en ICS bajo la matriz MITRE ATT&CK Figura 2-14. Estructura del mensaje Setup Communications de S7comm [8] Dentro del campo Parameters podemos ver: o Function Code (1 byte): código de la función S7comm, en este caso siempre será 0xf0 (Setup Communication). o Reserved: se mantiene a 0 o Max AMQ Caller (2 bytes): nº de peticiones sin ACK. o Max AMQ Callee (2 bytes): nº de peticiones sin ACK. o PDU Length (2 bytes): indica la longitud máxima que tendrá la S7PDU, entre 112 y 960 bytes. • Read/Write: Los mensajes de lectura/escritura de variables tienen una estructura diferente, ya que se debe especificar sobre qué variable se quiere actuar y, en el caso de escritura, indicar qué valor queremos que tome dicha variable. Para estos mensajes, el campo Parameters también incluirá como primer campo (1 byte) el código de función, el cuál será 0x04 (Lectura) o 0x05 (Escritura), luego el siguiente byte indicará el número de elementos sobre los que se quiere realizar la acción, y por último se indican los detalles de cada elemento siguiendo el siguiente formato (solo en los mensajes de petición): Figura 2-15. Campo Parameters – Item del mensaje de tipo Read/Write de S7comm [9] o Var Type (1 byte): indica el tipo de estructura que sigue el item. Para acceso de variables siempre se usa el valor 0x12. o Var Length (1 byte): longitud del resto del item. o Syntax ID (1 byte): indica el formato y modo de direccionamiento. Se usa el valor 0x10 para indicar “cualquier tipo”. o Transport Size (1 byte): determina el tipo y longitud de la variable, por ejemplo, BIT, BYTE o WORD. o Length (2 bytes): número de variables (del mismo tipo y consecutivas) sobre las que queremos actuar. o DB Number (2 bytes): número identificativo de la base de datos a la que queremos acceder. Base Teórica 14 o Area (1 byte): zona de memoria donde se encuentra la variable a sobre la que queremos actuar. o Address (3 bytes): offset que tiene la variable a la que queremos acceder dentro de la zona de memoria elegida. En el caso de los mensajes de escritura (petición y respuesta) y los mensajes de respuesta de lectura, a continuación del campo Parameters, se incluirá un campo adicional donde se indicará el valor que se quiere escribir, como se puede ver en la Figura 2-16. Este campo tendrá una cabecera con la siguiente estructura: Figura 2-16. Cabecera de datos de peticiones de escritura DNP3 [9] o Return Code (1 byte): código que indica, en el mensaje de respuesta, si se ha producido algún error al realizar la escritura (en los mensajes de petición tendrá valor 0). o Transport Size (1 byte): determina el tipo y longitud de la variable, por ejemplo, BIT, BYTE o WORD. o Data Length (2 bytes): longitud de la variable sobre la que queremos escribir. En los mensajes de respuesta de lectura y petición de escritura el campo de datos incluirá el dato que hemos leído o queremos escribir, respectivamente, mientras que en los mensajes de respuesta de escritura solo se mandará la cabecera de datos puesto que solo nos importará el valor del campo Return Code. 2.2.4 CIP CIP es un protocolo multipropósito de capa de aplicación en el modelo OSI propietario de ODVA usado en ICS y que, de nuevo, sigue el esquema Maestro/Esclavo. Para su uso en redes TCP/IP tradicionales, CIP está encapsulado sobre ENIP (EtherNet/IP Industrual Protocol) [10], otro protocolo propietario del grupo ODVA usado en redes ICS con necesidades de comunicación en tiempo real, que, a su vez, esta encapsulado sobre TCP. Por defecto, CIP utiliza el puerto TCP 44818. CIP utiliza dos modos de transmisión de mensajes: - Mensajes implícitos: el maestro manda mensajes multicast y son los diferentes esclavos los que determinan si procesan o no el mensaje. - Mensajes explícitos: el maestro manda un mensaje dirigido a un esclavo en concreto. En la siguiente tabla se pueden observar las principales diferencias entre los dos modos: Tabla 2-3. Diferencias entre modo implícito y explícito de CIP [10] De forma similar a los protocolos anteriormente descritos, CIP utiliza servicios para identificar las distintas 15 Análisis de la capacidad de detección de Snort sobre ataques de red en ICS bajo la matriz MITRE ATT&CK acciones que pueden realizarse sobre los dispositivos. En este trabajo sólo se va a ver el servicio Stop (0x07), de forma que se pueda causar un apagado no autorizado de un dispositivo. En CIP es importante diferenciar entre los conceptos de sesión y conexión. Cada vez que queramos establecer una comunicación Maestro/Esclavo se creará una sesión, la cuál indentificará al flujo de datos para esa interacción, las sesiones se establecen mediante ENIP. Por otra parte, existen mensajes sin conexión y con conexión. Una conexión CIP es una relación que comparten dos o más aplicaciones de nodos diferentes, en la que se establece un circuito virtual entre ellas para el traspaso de datos, para establecer una conexión se hace uso del servicio Forward Open Request. Sin embargo, también se pueden mandar mensajes sin haber establecido una conexión, cada mensaje deberá contener más información y no se le garantiza la disposición de recursos en el nodo destino. Normalmente se usan mensajes sin conexión para envíos de mensajes excepcionales. A continuación, se puede ver el flujo de mensajes que se intercambian en los mensajes sin conexión y con conexión: Figura 2-17. Diagrama de paso de mensajes CIP sin conexión [10] Base Teórica 16 Figura 2-18. Diagrama de paso de mensajes CIP con conexión [10] 17 Análisis de la capacidad de detección de Snort sobre ataques de red en ICS bajo la matriz MITRE ATT&CK 2.2.4 PCCC PCCC es otro protocolo de capa de aplicación del modelo OSI que permite la comunicación de PLCs en ICS. Al igual que los anteriores, es un protocolo basado en la estructura Maestro/Esclavo y que funciona mediante peticiones y respuestas. PCCC tiene la particulariad de que puede viajar encapsulado como un servicio del protocolo CIP (0x04b), de forma que se tiene el siguiente esquema: Figura 2-19. Torre de protocolos PCCC/CIP En este trabajo se utilizará PCCC sobre CIP y mediante mensajes con conexión, por lo que se seguirá el esquema de conexión planteado en la Figura 2-19. El formato del mensaje PCCC es el siguiente: Figura 2-20. Estructura del mensaje PCCC Se pueden diferenciar los siguientes campos: - Requestor ID - Vendor ID - Serial Number Los tres campos anteriores proporcionan toda la información necesaria relevante a PCCC sobre el emisor del mensaje. - CMD (Command Code): - STS (Status): indica el estado del resultado en el mensaje de respuesta. - TNSW (Transaction ID): identifica a un par de mensajes petición/respuesta. - FNC (Function Code): identifica a la función que se quiere realizar sobre el destinatario de forma similar a otros protocolos como Modbus. Base Teórica 18 - PCCC Data: datos relativos a la función que se utilice en el mensaje, es un campo opcional y de longitud variable. 2.2 Seguridad en los ICS Originalmente los sistemas ICS no se establecían con fuertes sistemas de seguridad, ya que solían estar aislados del resto de redes y sistemas de una empresay se usaban conexiones serie y protocolos propietarios. Sin embargo, con el paso de los años las redes ICS se han ido conectando cada vez más a Internet y a redes IT, adoptando la estructura TCP/IP. Debido a esto las redes ICS, en muchos casos, tienen un nivel muy bajo de seguridad, ya que históricamente se han protegido simplemente por su aislamiento y el desconocimiento de su existencia y funcionamiento. Por este motivo, actualmente, la seguridad es una de las mayores preocupaciones en el sector de ICS. Aunque la seguridad en ICS comparte varios aspectos básicos con las redes IT, para estos entornos se deben tener especialmente en cuenta: - Tiempo de respuesta: en vista de la naturaleza de los procesos industriales, las comunicaciones en tiempo real son críticas para su infraestructura, ya que muchos de los procesos industriales dependen en gran medida del tiempo de respuesta. - Disponibilidad: como se ha comentado en el apartado 2.1, la continua disponibilidad es un aspecto crítico de este tipo de los ICS, por lo que una gran parte de la seguridad de este tipo de sistemas debe ir orientada a protegerlos de ataques que puedan interrumpir el servicio que prestan. - Efectos físicos: las redes industriales tienen muchos componentes, como maquinaria industrial, con posibles impactos físicos severos en el personal y las instalaciones. - Tiempo de vida de los componentes: el periodo de vida útil de muchos dispositivos usados en ICS es mucho mayor que en redes IT, por lo que la seguridad de los ICS debe ser lo suficientemente flexible para adaptarse a equipos que tengan prestaciones anticuadas. Además de los anteriores, un componente fundamental para la seguridad de los ICS es la seguridad en sus comunicaciones. En este trabajo se expondrán vulnerabildiades relativas a los protocolos usados en ICS descritos en el apartado 2.2. Entre los problemas de seguridad más importantes comunes a la mayoría de los protocolos de ICS se encuentran: - Falta de cifrado en las comunicaciones: aunque la confidencialidad de los datos no es tan importante como en las redes IT, la información que se transmite por las redes ICS sigue siendo de alto valor para la empresa, puesto que el filtrado de esta información podría dar un gran conocimiento a atacantes del funcionamiento de una red ICS. - Falta de autenticación: no se implementan mecanismos de autenticación de los dispositivos (como por ejemplo certificados), esto permite que cualquier atacante que suplante la dirección IP de un dispositivo, o como mucho el identificador de equipo (en caso, por ejemplo, de DNP3) puede hacerse pasar por un equipo de la red ICS e interactuar con el resto de los dispositivos. Los parámetros como direcciones IP, identificadores o funciones utilizadas son fácilmente extraíbles del tráfico habitual que se cursa por una red ICS. Una gran cantidad de los ataques realizados en este trabajo son posibles debido a la falta de autenticación de estos protocolos. - Falta de algoritmos de checksum: protoclos como Modbus o S7comm son vulnerables a ataques de Man in the Middle ya que no implementan ninguna forma de CRC - Falta de modernización de los protocolos: la mayoría de los protocolos descritos en el apartado 2.2 se crearon cuando la seguridad no era un problema importante en las redes ICS, y debido a la lenta actualización de los dispositivos e infraestructura de estos entornos muchos ICS siguen utilizando protocolos muy desactualizados para las necesidades actuales de seguridad. Existe versiones más seguras de algunos protocolos como DNPSec v5 (versión más segura de DNP3), pero aún falta mucho para que se normalice su utilización. 19 3 ATAQUES DE RED REALIZADOS n esta sección se describirán todos los ataques de red realizados para probar las capacidades del IDS Snort, categorizándolos según la matriz de MITRE ATT&CK [11]. En esta matriz ha sido desarrollada por MITRE para llevar un seguimiento, recopilar y analizar las amenazas de ciberseguridad, en este caso, para los entornos industrializados. La matriz proporciona una gran fuente de información que permite a equipos de investigación mejorar las defensas de los ICS. 3.1 Selección de los ataques Como se indica en la introducción del apartado, todos los ataques descritos han sido clasificados en tácticas y técnicas de la matriz de MITRE ATT&CK que cuentan con el elemento Data Source: Network Traffic, denotando así que es una técnica que involucra tráfico de red. El proceso de selección de ataques ha sido el siguiente: 1. Análisis de las técnicas de la matriz de MITRE ATT&CK que contasen con ataques de red. 2. Recopilación inicial de posibles ataques siguiendo los ejemplos de procedimiento que se pueden encontrar para las técnicas seleccionadas en la matriz de MITRE. 3. Expansión de la lista de posibles ataques con ataques encontrados en otras fuentes, pero clasificándolos según las categorías de la matriz de MITRE. 4. Primer filtrado de ataques viables: como la mayoría de los ataques extraídos de los ejemplos de procedimiento de la referencia [11] han sido ejecutados mediante software o malware no disponible, se ha hecho un primer filtrado de ataques para los que existen medios accesibles para su realización. 5. Selección de ataques definitivos: se ha intentado ejecutar todos los ataques de la lista de ataques viables y finalmente se han seleccionado los que han tenido éxito, que se describirán en los siguientes subapartados. Todo el proceso de selección de ataques se ha registrado en un libro de Excel que se puede encontrar en el repositorio de Github en la referencia [41] (descrito brevemente en el Anexo B). Este libro cuenta con las siguientes hojas: • Lista Completa de Ataques: en esta lista se encuentra la recopilación de todos los ataques extraídos de los ejemplos de procedimiento de la matriz de MITRE además de los encontrados en otras fuentes. Cuenta con columnas para indicar: o Ataque para realizar o Software de simulación de la víctima y el atacante o Disponibilidad del software o Protocolos utilizados o Procedimiento para ejecutar el ataque (si se hubiera encontrado) • Ataques Viables: en esta lista se recogen los ataques de la lista anterior que cuentan con software de simulación de la víctima y el atacante accesibles para su utilización. • Ataques Seleccionados: segundo filtrado tras intentar ejecutar todos los ataques, donde se recogen los ataques exitosos. E Ataques de red Realizados 20 3.2 Initial Access La primera táctica que encontramos en la matríz de MITRE es Initial Access. Esta categoría engloba los ataques cuyo objetivo es conseguir un primer acceso a una red ICS. Las técnicas que forman parte de esta táctica suelen estar enfocadas a ganar acceso o suplantar equipos con accesos o funciones privilegiadas. Para esta táctica se ha usado un ataque siguiendo la técnica de Rogue Master, la cual consiste en establecer un equipo no legítimo que se pueda comunicar con otros que actúen con el rol de esclavos en un entorno ICS. Esto trae una serie de beneficios para un atacante: - Mandar mensajes de control haciéndose pasar por el verdadero maestro de forma que se interrumpa la funcionalidad normal o se gane control de la red. - Recolectar información dirigida al Maestro original. - Evitar ser detectado al suplantar al Maestro original. Para el ataque realizado se ha empleado el protocolo DNP3, donde, mediante la herramienta FreyrSCADA DNP3 Client (Master) [12] se simula el establecimiento de un equipo con rol de maestro en una red ICS, el cuál enviará ordenes de control a un esclavo, simulado por la misma herramienta en su version de Oustation (Esclavo) [13]. El objetivo del ataque es suplantar la identidad de el maestro original de forma que se le manden las siguientes órdenes al equipo esclavo (descritas en la Tabla 2-2): - Freeze and Clear no ACK - Immediate Freeze no ACK - Enable Spontaneous Messages - Cold Restart - Warm Restart En la Figura 3-1 se muestra un diagrama de paso de mensajes que muestra la comunicación que se va a establecer en este ataque. Cabe destacar que, el mensaje Read Class 1,2,3 se repite periódicamente, pero por simplicidad solo se ha incluido una vez en el diagrama. Esta periodicidad se debe que el equipo maestro manda cada segundo (por defecto), una orden de lectura a todas las variables del equipo esclavo, de forma que pueda tener los valores actualizados. Aunque esta acción no se realice explícitamente, también constituye una forma de obtención de información dirigida al verdadero maestro por parte del maestro implantado por los atacantes. 21 Análisis de la capacidad de detección de Snort sobre ataques de red en ICS bajo la matriz MITRE ATT&CK Figura 3-1. Diagrama de paso de mensajes – Rogue Master Ataques de red Realizados 28 Figura 3-13. Resultado Freeze and Clear no ACK – Rogue Master Para mandar una orden de Inmmediate_Freeze se debe acceder al mismo menú que en la Figura 3-11 y seleccionar “Counter_Immediate_Freeze” en el menú desplegable “Type”: Figura 3-14. Menu Station Commands > Freeze and Clear > Counter-Immediate-Freeze-and-Clear-No-Ack – Rogue Master Como se puede ver en la Figura 3-15, el valor de el registro FRCOUNTER_INPUT se ha actualizado con el valor, que tiene la variable COUNTER_INPUT. 29 Análisis de la capacidad de detección de Snort sobre ataques de red en ICS bajo la matriz MITRE ATT&CK Figura 3-15. Resultado Immediate Freeze – Rogue Master A continuación, se mandará la orden Enable Sponteneous Commands, de esta forma el esclavo puede mandar Respuestas no Solicitadas al equipo maestro, lo que podría permitir recolectar información dirigida a un maestro legítimo. Figura 3-16. Menu Station Commands > Spontaneous Command – Rogue Master Figura 3-17. Menu Station Commands > Spontaneous Command > Enable Unsolicited Messages – Rogue Master Ataques de red Realizados 30 Por útimo se utilizarán las órdenes de Cold Restart y Warm Restart las cuales, como se describe en la Tabla X, producirán que se reinicie el hardware y software completos del equipo esclavo completa y de forma parcial respectivamente. Figura 3-18. Menu Station Commands > Special DNP3 Command – Rogue Master Figura 3-19. Menu Station Commands > Special DNP3 Command > Cold Restart – Rogue Master 31 Análisis de la capacidad de detección de Snort sobre ataques de red en ICS bajo la matriz MITRE ATT&CK Figura 3-20. Menu Station Commands > Special DNP3 Command > Warm Restart – Rogue Master Desafortunadamente la herramienta utilizada no muestra ningún resultado ante las acciones de Enable Unsolicited Messages, Cold Restart y Warm Restart. Sin embargo, se ha generado correctamente el tráfico correspondiente el cuál se utilizará en el Apartado 4 para la detección de Snort. 3.3 Discovery Mediante la táctica de Discovery los atacantes intentarán obtener información acerca de la infraestructura, los equipos que componen un entorno ICS y cómo interaccionan entre ellos, con el objetivo de usar esa información para planear sus siguientes movimientos dentro de la red. 3.3.1 Remote System Discovery La técnica de Remote System Discovery se centra en identificar equipos dentro de un entorno ICS. Los ataques que se han ejecutado para esta técnica tienen como objetivo averiguar qué dispositivos conectados a una red ICS utilizan los protocolos S7comm y Modbus, de forma que se puedan planear otros ataques basándose en estos protocolos. 3.3.1.1 Escaneo de equipos que usen S7comm Para este ataque se utilizará la herramienta Nmap para realizar un escaneo de la red en busca de equipos que utilicen el protocolo S7comm, usando el script ns7-info.se [14]. Para ello, Nmap intentará establecer conexiones S7comm con los equipos de la red ICS, y si lo consigue, además, extraerá información sobre el hardware del equipo, de forma que se pueda recopilar más información sobre los tipos de equipos que hay en la red. Para el equipo víctima simularemos un PLC S7-1200, el cual tendrá habilitadas las comunicaciones S7comm, mediante las siguientes herramientas: - PLCSIM: Simulador de Siemens para el PLC S7-1200 [15]. - TIA Portal V16: Project Manager de Siemens a través del que configuraremos el PLC [15]. - NetToPlcSim: herramienta externa que permitirá conectar PLCSIM a la red para realizar el ataque [16]. En la Figura 3-21 se puede ver un diagrama de paso de mensajes del tráfico que se va a cursar para este ataque. Ataques de red Realizados 32 Figura 3-21. Diagrama de paso de mensajes – Escaneo de direcciones IP que usen S7comm 3.3.1.1.1 Configuracio n del equipo ví ctima Una vez se tengan instaladas todas las herramientas necesarias para la simulación en el equipo víctima se debe comenzar la configuración de el PLC simulado mediante un proyecto en el software TIA Portal. Una vez creado el proyecto como se indica en el Anexo A, el primer paso será configurar una dirección IP para el PLC, esto se puede hacer desde: PLC_1 > Configuración de dispositivos > General > Interfaz PROFINET > Direcciones Ethernet como se puede er en la Figura 3-22: 33 Análisis de la capacidad de detección de Snort sobre ataques de red en ICS bajo la matriz MITRE ATT&CK Figura 3-22. Configuración de dirección IP para el PLC – Escaneo de equipos que usen S7comm Dentro de PLC_1 > Configuración de dispositivos > General > Protección & Seguridad > Nivel de acceso se deberá seleccionar el modo “Acceso completo (sin protección)” para facilitar la ejecución del ataque. Figura 3-23. Configuración de nivel de acceso para el PLC – Escaneo de direcciones equipos que usen S7comm El siguiente paso será compilar el PLC usando el botón de la Figura 3-24: Ataques de red Realizados 34 Figura 3-24. Compilación del PLC – Escaneo de equipos que usen S7comm Tras compilar, si no se han obtenido errores deberá aparecer una pantalla como la mostrada en la Figura 3-25: Figura 3-25. Resultado de la compilación del PLC – Escaneo de equipos que usen S7comm El siguiente paso será cargar la configuración en el PLC simulado pulsando el botón señalado en la Figura 3-26. Figura 3-26. Botón cargar configuración – Escaneo de equipos que suen S7comm Una vez se pulse aparecerá la pantalla mostrada en la Figura 3-27 y tras pulsar el botón Iniciar Búsqueda, TIA Portal detectará la herramienta PLCSIM como se puede ver en la Figura 3-28. 35 Análisis de la capacidad de detección de Snort sobre ataques de red en ICS bajo la matriz MITRE ATT&CK Figura 3-27. Pantalla de carga de configuración – Escaneo de equipos que usen S7comm Figura 3-28. Detección de PLCSIM para la carga de configuración – Escaneo de equipos que usen S7comm Finalmente, para terminar de cargar la configuración se deberá pulsar el botón Cargar > Cargar > Finalizar en las pantallas siguientes. Tras haberse cargado la configuración la pestaña de PLCSIM debería mostrar lo siguiente: Ataques de red Realizados 36 Figura 3-29. PLCSIM – Escaneo de equipos que usen S7comm Donde podemos ver que ha adoptado el modelo de CPU elegido, se le ha asignado la dirección IP que hemos configurado y el marcador RUN/STOP está de color verde. Sin embargo, aún hay que hacer uso de la herramienta NetToPlcSim para vincular la tarjeta de red virtual que crea PLCSIM con la tarjeta de red que se vaya a utilizar para realizar el ataque, para una descripción más detallada de el funcionamiento de las tarjetas virtuales de PLCSIM consultar el Anexo A. Para ello se debe agregar una nueva conexión pulsando el botón Add: Figura 3-30. NetToPlcSim – Escaneo de equipos que usen S7comm A continuación, indicamos la dirección que tiene asignada el PLC virtual y la dirección que queremos usar de cara a la red y pulsaremos Ok como se puede ver en la Figura 3-31. Como PLCSIM no permite cursar tráfico por la interfaz virtual NetToPlcSim abre el puerto 102 (S7comm) en la dirección IP que le indiquemos y reenvía todo el tráfico S7comm a PLCSIM de forma que actúa de puente entre el simulador y el resto de la red. Con esto concluye la configuración del PLC víctima que se requiere para realizar este ataque. 37 Análisis de la capacidad de detección de Snort sobre ataques de red en ICS bajo la matriz MITRE ATT&CK Figura 3-31. Configuración de NetToPlcSim – Escaneo de equipos que usen S7comm 3.3.1.1.2 Configuracio n del equipo atacante Para el ataque se va a utilizar una máquina Kali Linux v21.4a y la herramienta Nmap, como se mencionó anteriormente, junto al script ns7-info.se. Ambos vienen instaldos por defecto en Kali Linux, por lo que no se necesitará ninguna configuración adicional. 3.3.1.1.3 Ejecucio n del ataque La ejecución de este ataque es muy sencilla, simplemente tendremos que ejecutar siguiente comando en la máquina de Kali Linux para ejecutar Nmap e indicarle que use el script ns7-info.se. nmap -script s7-info.nse -p 102 192.168.0.64 -Pn Con -p indicamos el puerto al que queremos hacer el escáner, y con la opción -Pn se indica que no se haga ping antes de hacer las peticiones S7comm. En la Figura 3-32 podemos ver como, efectivamente, se ha detectado el PLC virtual y se ha obtenido información acerca de la CPU que hemos elegido: Figura 3-32. Resultado del ataque – Escaneo de equipos que usen S7comm Ataques de red Realizados 44 3.3.2 Remote System Information Discovery Los ataques pertenecientes a la técnica de Remote System Information Discovery tienen como objetivo obtener información detallada de los equipos de una red ICS. En este apartado se utilizará el protocolo DNP3 para obtener atributos sobre esclavos DNP3. Para ello se volverá a usar la herramienta FreyrSCADA DNP3 Client/Outstation para la simulación de los equipos maestro y esclavo respectivamente. Se hará uso de la función DNP3 Read Device Attribute, con la que se obtendrá información acerca de, entre otros: - Vendedor del equipo - Nombre y modelo del equipo - Número de serie - Localización En la Figura 3-42 se puede ver un diagrama de paso de mensajes del tráfico que se va a cursar debido a este ataque. Hay que comentar que para no tener que hacer tantas peticiones separadas se usa la variación 254 de la función que hace una petición para que el equipo esclavo devuelva todos sus atributos. 45 Análisis de la capacidad de detección de Snort sobre ataques de red en ICS bajo la matriz MITRE ATT&CK Figura 3-42. Diagrama paso de mensajes – Remote System Information Discovery 3.3.2.1 Configuración del equipo Esclavo La configuración del equipo esclavo es la misma que la descrita en el Apartado 3.1.1 3.3.2.2 Configuración del equipo Maestro La configuración del equipo maestro es la misma que la descrita en el Apartado 3.1.2 Ataques de red Realizados 46 3.3.2.3 Ejecución del Ataque Se procederá de forma análoga al apartado 3.1.3 para mandar las órdenes DNP3 del maestro al eslcavo, primero se seleccionará en el menú desplegable de acciones Station Commands > Read Device Attributes, como se muestra en la Figura 3-43. Figura 3-43. Menu Station Commands > Read Device Attributes – Remote System Information Discovery Se va a comenzar obteniendo el nombre del vendedor del equipo, para ello se usará la variación 252 de la función Device Attribute. Tras realizar la petición obtenemos, ya que estmaos usando una herramienta de simulación, FreyrSCADA Embedded Solutions, como se puede observar en la Figura 3-44. Figura 3-44. Menu Station Commands > Read Device Attributes > Device Manufacturer Name – Remote System Information Discovery Si se usa la variación 250 (Nombre y modelo del dispositivo) obtendremos FreyrSCADA DNP3 Library, ya que es un equipo simulado. 47 Análisis de la capacidad de detección de Snort sobre ataques de red en ICS bajo la matriz MITRE ATT&CK Figura 3-45. Menu Station Commands > Read Device Attributes > Device Name and Model – Remote System Information Discovery Mediante la variación 248 se obtendrá el número de serie, en este caso 21.05.008 (como se verá más adelante al ser un equipo simulado el nº de serie es la versión), de nuevo, no es un nº de serie real ya que estamos simulando el esclavo. Figura 3-46. Menu Station Commands > Read Device Attributes > Device Serial Number – Remote System Information Discovery Finalmente, se usará la variación 254 para obtener en una sola petición todos los atributos como se puede ver en la Figura 3-47: Ataques de red Realizados 48 Figura 3-47. Menu Station Commands > Read Device Attributes > Non-Specific all Attributes – Remote System Information Discovery Entre los atributos obtenidos se pueden observar: - Localización (variación 245): India - Hardware version (variación 243): DNP3 Outstation - Software version (variación 242): 21.05.008 La lista completa de variaciones de la función Read Device Attributes se puede consultar en la referencia [19]. 3.4 Lateral Movement Mediante esta táctica los atacantes intentarán moverse a través de una red ICS, tomando el control de distintos equipos de forma remota para acabar llegando al punto deseado de la red. En este apartado se realizará un ataque de la técnica Program Download, donde el objetivo será descargar en un equipo remoto un fichero malicioso que permita al adversario ganar el control de dicho dispositivo. Para ello se utilizará el protocolo Modbus y la herramienta PLCInjector [20], la cual es capaz de cargar cualquier fichero en los registros de memoria de un PLC. Algunos dispositivos como el PLC S7-1500 tienen zonas de memoria que se ejecutan de forma periódica, por tanto, si se consiguera cargar un fichero malicioso en esas zonas de memoria se podría ejecutar un fichero malicioso de forma remota con sólo cargarlo en el dispositivo de forma adecuada. Una descripción más detallada del funcionamiento del PLC S7-1500 en estas situaciones se puede consultar en la referencia [21]. Ya que la parte interesante de cara al análisis de este trabajo es exclusivamente el tráfico de red, por simplicidad para realizar el ataque y por limitaciones en el software de simulación se transmitirá un fichero de texto y se usará como software de emulación de la víctima la herramienta ModbusPal. En la siguiente figura se puede apreciar un diagrama de paso de mensajes relativo a este ataque: 49 Análisis de la capacidad de detección de Snort sobre ataques de red en ICS bajo la matriz MITRE ATT&CK Figura 3-48. Diagrama paso de mensajes – Lateral Movement Primero, PLC Injector comprueba que en el equipo víctima haya suficiente espacio en memoria para guardar el fichero, por lo que lanza una petición de la función Modbus 0x03, Read Holding Registers. Si determina que puede guardar el archivo comenzará a mandar mensajes con la función 0x10, Write Multiple Registers, para guardar en la zona seleccionada de memoria los datos del fichero. 3.4.1 Configuración del equipo víctima La configuración del equipo víctima es exactamente igual que la configuración mostrada en el apartado 3.2.1.2.1. Ataques de red Realizados 50 3.4.2 Configuración del equipo atacante Al ser PLCInjector un script de Python no tenemos que realizar ninguna configuración en el equipo del atacante, solo tener descargado el código de la herramienta. 3.4.3 Ejecución del ataque Inicialmente, todos los registros de almacenamiento están a 0 como se puede ver en la Figura 3-49: Figura 3-49. Estado inicial del esclavo Modbus – Lateral Movement Para ejecutar el script de Python hay que usar el siguiente comando desde la terminal de, en este caso, Kali Linux: python2 plcInjectPayload.py -upload fichero-malicioso -ip 192.168.100.3 Donde con el parámetro -upload se indica que se quiere subir un archivo y “fichero-malicioso” es el fichero que vamos a cargar al esclavo Modbus, en este caso simplemente es un fichero de texto con el contenido “esto es una prueba”. Aunque podría ser cualquier tipo de fichero. Como se puede observar, con -ip indicaremos la dirección IP del equipo víctima. Figura 3-50. Ejecución de PLCInjector – Lateral Movement 51 Análisis de la capacidad de detección de Snort sobre ataques de red en ICS bajo la matriz MITRE ATT&CK A continuación, si se comprueba de nuevo la pestaña de los registros de almacenamiento de el esclavo Modbus se puede ver que tienen el contenido del fichero (en decimal). Figura 3-51. Resultado del ataque – Lateral Movement Como no se ha indicado ninguna posición de memoria al ejecutar el script de Pyhton, el contenido del fichero se ha cargado en las primeras direcciones de memoria. En caso de querer cargar un fichero a un PLC de verdad, habría que indicar el inicio de la zona de memoria donde se quiera guardar dicho fichero mediante el parámetro -addr (por defecto 0). PLCInjector también permite descargar cualquier contenido de memoria que haya en el equipo víctima al equipo de atacante con la opción -download. De esta forma se podría extraer información sobre el contenido de la memoria de un equipo. Esto lo hace mediante la función Read Holding Registers. 3.5 Collection La táctica de Collection se centra en la obtención de información sobre los equipos y la infraestructura de un ICS. Suele usarse junto a la táctica de Discovery para recopilar toda la información posible acerca de los objetivos de futuras operaciones maliciosas en entornos ICS. En este apartado se va a describir la técnica de Automated Collection, cuyo objetivo es la obtención de información de manera automática mediante el uso de herramientas o scripts. Para ello se utilizará el módulo snmp_enum de la herramienta Metasploit, el cual lanzará peticiones SNMP hacia un equipo y recopilará automáticamente información sobre el mismo y sus interfaces de red. Para el equipo víctima, se simulará un PLC S7-1500 de Siemens mediante PLCSIM Advanced [25], ya que estos PLCs tienen habilitado el protoclo SNMP. En la Figura 3-52 se puede ver un diagrama de mensajes que representa el tráfico de este ataque: Ataques de red Realizados 52 Figura 3-52. Diagrama de paso de mensajes – Automated Collection Aunque SNMP no sea un protoclo específico de ICS, sí es uno muy utilizado en estos entornos para labores de monitorización y configuración de los distintos equipos que realizan procesos industriales, por lo que muchos equipos de este tipo soportan dicho protocolo. 3.5.1 Configuración del equipo víctima En el equipo vícitima tendremos que configurar PLCSIM Advanced para simular un PLC S7-1500. Al iniciar PLCSIM Advanced se abre la siguiente pantalla: 53 Análisis de la capacidad de detección de Snort sobre ataques de red en ICS bajo la matriz MITRE ATT&CK Figura 3-53. PLCSIM Advanced – Automated Collection Lo primero que hay que configurar es el el apartado de Online Access, para que el PLC virtual se pueda comunicar con otros equipos de la red. Para ello se debe seleccionar el interruptor para establecer el modo PLCSIM Virtual Eth. Adapter, esto creará una interfaz virtual en el equipo la cual habrá que vincular a la interfaz de red que queramos utilizar para establecer la comunicación. En la Figura 3-54 se puede observar como se ha seleccionado la interfaz Ethernet 3 en la pestaña desplegable de “TCP/IP communication with” y en la venta de interfaces de red del Panel de Control del equipo están tanto Ethernet 3 como la interfaz virtual de PLCSIM Advanced. Figura 3-54. Configuración de interfaces de red de PLCSIM Advanced – Automated Collection Ataques de red Realizados 60 Figura 3-62. Diagrama de paso de mensajes RealWin Server – Command and Control 61 Análisis de la capacidad de detección de Snort sobre ataques de red en ICS bajo la matriz MITRE ATT&CK Figura 3-63. Diagrama de paso de mensajes Ignition SCADA – Command and Control Ataques de red Realizados 62 3.6.1 Configuración del equipo víctima RealWin Server Una vez se tenga instalado el servidor RealWin en una máquina Windows XP (consultar Anexo A), simplemente habrá que configurar la direccion IP que se vaya a utilizar, en este caso 192.168.2.92 y ejecutar el servidor. En la Figura 3-64 se puede ver la pantalla de inicio del servidor RealWin y mediante el comando netstat que el puerto TCP 912 está a la escucha de peticiones. Figura 3-64. Servidor RealWin y puertos a la escucha – Commonly Used Port 3.6.2 Configuración del equipo atacante RealWin Server Como se utilizará la herramienta Metasploit, no se requerirá ninguna configuración en el equipo del atacante además de configurar una dirección IP dentro de la misma subred que el servidor RealWin. Para este ataque el equipo adversario tendrá la dirección IP 192.168.2.87. 3.6.3 Ejecución del ataque RealWin Server Primero habrá que iniciar la consola de Metasploit y buscar el módulo realwin_scpc_initialize. Este módulo tiene las siguientes opciones de configuración: Figura 3-65. Opciones del módulo realwin_scpc_initialize de Metasploit – Commonly Used Port El payload que se utiliza por defecto para este módulo de Metasploit es reverse_tcp. Se deberá establecer RHOST como 192.168.2.92 y en este caso LPORT como 502 para que el tráfico de C&C vaya sobre el puerto por defecto del protocolo Modbus. 63 Análisis de la capacidad de detección de Snort sobre ataques de red en ICS bajo la matriz MITRE ATT&CK Cuando se ejecuta el módulo de Metasploit se iniciará una terminal de Meterpreter, donde podremos ejecutar comandos remótamente en el equipo víctima, como se puede observar en las siguientes figuras: Figura 3-66. Terminal Meterpreter RealWin– 1 – Commonly Used Port Figura 3-67. Terminal Meterpreter RealWin – 2 – Commonly Used Port Ataques de red Realizados 64 Figura 3-68. Terminal Meterpreter RealWin – 3 – Commonly Used Port Se han usado los commandos sysinfo, ipconfig y netstat como ejemplo, pero se puede ejecutar cualquier comando que permita la terminal de Meterpreter. También se ha realizado el ataque de forma totalmente análoga para el puerto TCP 20000, puerto por defecto del protocolo DNP3. Las diferencias entre los resultados de Snort para ambos ataques se discutirán en el apartado 4. 3.6.4 Configuración del equipo víctima Ignition SCADA Tras la instalación del software de Ignition SCADA, en el equipo víctima sólo habrá que iniciar el servidor web de este. 3.6.5 Configuración del equipo atacante Ignition SCADA De nuevo, al utilizar un módulo de Metasploit, no se requerirá ninguna configuración en el equipo del atacante además de configurar una dirección IP dentro de la misma subred que el equipo con Ignition SCADA. Para este ataque el equipo adversario tendrá la dirección IP 192.168.2.87. 3.6.6 Ejecución del ataque Ignition SCADA Tras iniciar la consola de Metasploit, se deberá seleccionar el módulo inductive_ignition_rce. De nuevo, se utilizará el payload de reverse_tcp. Las opciones del módulo son análogas a las mostradas en la Figura 3-65, se establecerá RHOST como 192.168.2.92 y, al igual que para RealWin Server, LHOST como 192.168.2.87 y LPORT como 502 para que el tráfico de C&C vaya sobre el puerto por defecto del protocolo Modbus. Una vez se ejecuta el módulo se puede ver que se ha tenido éxito y se ha obtenido una terminal de Meterpreter: 65 Análisis de la capacidad de detección de Snort sobre ataques de red en ICS bajo la matriz MITRE ATT&CK Figura 3-69. Terminal de Meterpreter Ignition SCADA - Commonly Used Port Para generar tráfico de C&C se han ejecutado los mismos comandos que en el apartado 3.5.3. Además, al igual que para RealWin, se ha realizado el ataque también para el puerto 102 (S7comm), cuyo análisis se mostrará en el apartado 4. 3.7 Inhabit Response Function Mediante esta táctica, se intenta evitar que el personal de administración de un ICS pueda actuar ante eventos que se produzcan en el entorno, impidiendo el correcto control de las distintas incidencias que puedan surgir en un proceso industrial y que puedan provocar daños físicos, personales y productivos. Dentro de esta táctica se encuentran las técnicas de Denial of Service y Device Restart/Shutdown, las cuales se cubrirán en este apartado. 3.7.1 Denial of Service Esta técnica se centra en provocar que equipos de ICS entren en estado de denegación de servicio, de forma que el personal encargado no pueda manejarlos de forma adecuada y se interrumpa la funcionalidad que están prestando los equipos. En este apartado se provocará que un equipo entre en estado de denegación de servicio mediante una vulnerabilidad explotable por el protocolo PCCC [28], usando el módulo allen_bradley_pccc de Metasploit. Los controladores 1100 de MicroLogix en sus versiones 1763-L16BWA, 1763-L16AWA, 1763-L16BBB y 1763- L16DWD están afectados. Para simular estos equipos se utilizará la herramienta RSLogix Emulate 500 [29] junto a RSLinx Classic y RSLogix Micro. A continuación, se puede ver un diagrama de paso de mensajes para este ataque: Ataques de red Realizados 66 Figura 3-70. Diagrama de paso de mensajes – Inhabit Response Function Para este ataque se usa PCCC encapsulado en CIP, como se comentó en el Apartado 2.2.4, usando el servicio Execute PCCC (0x4b) del mismo. Además, como se usa un mensaje con conexión, se utiliza el servicio de Forward Open de CIP siguiendo el modelo de la Figura 2-18, aunque como se puede observar, no se usa Forward Close ya que se entra en estado de denegación de servicio. 67 Análisis de la capacidad de detección de Snort sobre ataques de red en ICS bajo la matriz MITRE ATT&CK 3.7.1.1 Configuración del equipo víctima Una vez se tengan instaladas las 3 herramientas necesarias para simular el controlador para comenzar la configuración se deberá iniciar RSLogix Micro, y seleccionar File > New para crear un archivo de configuración, tras lo que se abrirá una pestaña en la que habrá que seleccionar el tipo de procesador que queremos simular. En este caso se elegirá MicroLogix 1100 Build 1763 Series B como se puede ver en la Figura 3-71: Figura 3-71. Selección de procesador RSLogix Micro – Denial of Service Una vez se elija el tipo de procesador se abrirá el entorno de programación del PLC, sin embargo, para este ataque no será necesario realizar ninguna acción en RSLogix además de generar el fichero de configuración con el tipo de procesador necesario. A continuación, se debe iniciar RSLinx Classic y seleccionar Communications > Configure Drivers. Se abrirá una pestaña en la que habrá que seleccionar SLC500 Emulator Driver, ya que se está simulando el dispositivo, como se muestra en la Figura 3-72: Figura 3-72. Selección de driver de comunicación RSLinx – Denial of Service Ataques de red Realizados 68 Habrá que establecer un nombre y número de estación, se pueden dejar los valores por defecto obteniendo el siguiente resultado: Figura 3-73. Selección de driver de comunicación RSLinkx (cont.) – Denial of Service Si ahora se pulsa el botón señalado en la Figura 3-74, se abrirá una pestaña donde aparece nuestro equipo y donde se puede ver el driver que se acaba de iniciar: Figura 3-74. Menú RSLinx – 1 – Denial of Service El siguiente paso será abrir la herramienta de RSLogix Emulate 500, tras lo que se deberá cargar el archivo que se creó en RSLogix Micro, en este caso llamado TEST.RSS. Para ello se deberá seleccionar en el meú File > Open. Una vez se tenga abierto el archivo donde especificamos el modelo del procesador hay que ejecutar el controlador pulsando el botón Run señalado en la Figura 3-75: 69 Análisis de la capacidad de detección de Snort sobre ataques de red en ICS bajo la matriz MITRE ATT&CK Figura 3-75. Iniciar controlador virtual en RSLogix Emulate 500 – Denial of Service Si ahora se vuelve a RSLinx y desplegamos la pestaña del driver que se ha configurado antes podremos ver que tenemos el equipo que se está usando además del controlador virtualizado (TEST). Figura 3-76. Menú RSLinx – 2 – Denial of Service Por ultimo se debe volver a RSLogix Micro y en el menú Comms > System Comms, tras lo que se abrirá una pestaña para sincronizar RSLogix Micro con el controlador virtualizado TEST pulsando el botón Upload como se puede ver en la Figura 3-77: Ataques de red Realizados 76 - ID del esclavo Modbus: 1 - Función a ejecutar: WRITE_REGISTER (equivale a Write Single Register) Al ejecutar el módulo se puede ver que no se ha obtenido ninguna excepción: Figura 3-87. Ejecución modbusclient Write Single Register – Modify Parameters Una vez ejecutado el módulo podemos observar que se ha modificado correctamente el registro de almacenamiento del esclavo Modbus en el equipo víctima en la Figura 3-88. Como comentario hay que destacar que, en la siguiente Figura aparece el dato que se ha modificado en la dirección 11 (en vez de la 10), esto se debe a un fallo en la herramienta ModbusPal donde siempre se realiza la acción en la siguiente dirección a la que se indica en los mensajes Modbus. Figura 3-88. Resultado de la función Write Single Register – Modify El módulo modbusclient también implementa otras funciones de Modbus como Write Multiple Registers. Para modificar varios registros de almacenamiento al mismo tiempo estableceremos las siguientes opciones: 77 Análisis de la capacidad de detección de Snort sobre ataques de red en ICS bajo la matriz MITRE ATT&CK Figura 3-89. Opciones modbusclient Metasploit Write Multiple Registers – Modify Parameters Esta vez se ha establecido: - Direccion del primer registro a modificar: 10 - Datos a escribir: 2000, 3000, 4000, 5000, 6000 - Numero de registros que modificar: 5 - Direción IP del equipo víctima: 192.168.100.3 - ID del esclavo Modbus: 1 - Función a ejecutar: WRITE_REGISTERS (equivale a Write Multiple Registers) A continuación, se ejecuta el módulo de la misma forma que antes y se vuelve a obtener que no se han recibido excepciones: Figura 3-90. Ejecución modbusclient Write Multiple Registers – Modify Parameters En ModbusPal se tiene que se han modificado los registros 11, 12, 13, 14 y 15: Ataques de red Realizados 78 Figura 3-91. Resultado de la función Write Multiple Registers – Modify Parameter Si un atacante consiguiera modificar de esta forma los registros de almacenamiento de un PLC, podría alterar en gran medida los procesos industriales. Siguiendo el ejemplo de la Figura 3-91, el equipo víctima podría estar controlando la temperatura de una serie de máquinas o las revoluciones por minuto de varios motores. Si se modificaran los valores de estos parámetros introduciendo datos tan altos como los que se han mostrado en este apartado se podrían producir graves daños en la infraestructura del ICS. 3.9 Impact La última táctica en la matriz de MITRE para ICS es Impact, cuyos ataques están centrados en manipular, interrumpir el funcionamiento o destruir un ICS. Las técnicas de esta táctica engloban las distintas acciones que un adversario puede realizar para perjudicar un ICS. Debido a la generalidad de esta táctica, los ataques de este apartado podrían encajar en otras tácticas y técnicas también. 3.9.1 Damage to Property Esta técnica se basa en dañar físicamente o destruir infraestructura de un ICS, por tanto, de forma similar al apartado 3.7 se va a realizar un ataque cuyo objetivo es modificar parámetros de un PLC de forma que pueda desembocar en daños físicos a equipos de un ICS. En el equipo víctima vamos a utilizar, en este caso, un PLC S7-1200 virtual para lo que se necesitarán las herramientas PLCSIM, TIA Portal y NetToPlcsim. Por otra parte, en el equipo atacante utilizaremos la herramienta Node-Red, la cual proporcionará la posibilidad de comunicarse con el PLC virtual usando el protocolo S7comm. El tráfico de este ataque está representado en el siguiente diagrama de paso de mensajes: 79 Análisis de la capacidad de detección de Snort sobre ataques de red en ICS bajo la matriz MITRE ATT&CK Figura 3-92. Diagrama de paso de mensajes – Damage to Property 3.9.1.1 Configuración del equipo víctima La configuración del S7-1200 virtualizado se realizará en TIA Portal, de forma análoga a la descrita en el Apartado 3.2.1.1.1, aunque además se deberá configurar una nueva zona de memoria donde se crearán las variables que se van a modificar en este apartado. Para ello en el menú Bloques de programa > Agregar nuevo bloque se establecerá un nuevo bloque de memoria de tipo Bloque de datos (DB global) y se indicará un nombre: Ataques de red Realizados 80 Figura 3-93. Creación bloque de datos S7-1200 – Damage to Property Una vez se haya creado el bloque crearemos distintas variables que se usarán para hacer el ataque. Se han definido las siguientes variables: Figura 3-94. Variables S7-1200 – Damage to Property La compilación del proyecto y conexión con PLCSIM son también análogas a las mostradas en el apartado 3.2.1.1.1. Al conectarse correctamente podemos ver que la zona de memoria que hemos creado muestra el valor actual de cada variable: 81 Análisis de la capacidad de detección de Snort sobre ataques de red en ICS bajo la matriz MITRE ATT&CK Figura 3-95. Estado inicial DB2 S7-1200 – Damage to Property 3.9.1.2 Configuración del equipo atacante Una vez esté instalado Node-Red en el ordenador del adversario se arrancará la aplicación con el comando nodered desde la terminal de, en este caso, Kali Linux. Como se puede ver en la Figura 3-96 nos podremos conectar a la herramienta desde el navegador al puerto 1880: Figura 3-96. Inicialización de Node-RED – Damage to Property Una vez se haya abierto la herramienta en el navegador tendremos que seleccionar los nodos que se van a utilizar para mandar los mensajes S7comm. Se necesitarán: - Nodo inject: indicará el valor que queremos escribir - Nodo s7comm (output): creará los paquetes S7comm - Nodo msg.payload: mandará los mensajes Estos nodos se pueden seleccionar en el menú de la derecha, y deberán quedar conectados como se muestra en la Figura 3-97: Ataques de red Realizados 82 Figura 3-97. Conexión de los nodos Node-RED – Damage to Property Para configurar las peticiones que realizará el nodo s7comm se abirá el siguiente menú pulsando doble clic sobre el nodo en cuestión: 83 Análisis de la capacidad de detección de Snort sobre ataques de red en ICS bajo la matriz MITRE ATT&CK Figura 3-98. Configuración nodo s7comm output Node-Red – Damage to Property Como se puede apreciar en la Figura 3-98, se deben configurar: - Dirección IP del equipo víctima: 192.168.0.64 (dirección en la que escucha peticiones NetToPlcsim) - Puerto TCP: puerto estándar S7comm, el 102 - Posibles variables a escribir: para cada variable tendremos que indicar: o Tipo de zona de memoria en la que se encuentra: para este caso Datablock o Número de la zona de memoria: en este caso el 2 o Offset dentro de la zona de memoria: el offset para cada variable se puede ver en TIA portal, para las variables de tipo booleano 0.1 por cada variable y para las de tipo entero 2. o Nombre identificativo para Node-Red Luego, en el nodo timestamp habrá que configurar el valor que queremos escribir, en formato JSON, en este caso se modificará el valor de una variable entera a 100: Ataques de red Realizados 84 Figura 3-99. Configuración nodo inject Node-Red – Damage to Property 3.9.1.3 Ejecución del ataque Para realizar el ataque simplemente habrá que indicar a los nodos de Node-RED que empiece a lanzar peticiones al PLC virtual, para ello habrá que seleccionar el botón Deploy señalado en la Figura 3-100: 85 Análisis de la capacidad de detección de Snort sobre ataques de red en ICS bajo la matriz MITRE ATT&CK Figura 3-100. Ejecución de Node-Red – Damage to Property Si ahora se comprueba el valor de la variable VariableInt en TIA Portal, se puede comprobar como ha cambiado a 100. Figura 3-101. Resultado del ataque TIA Portal – Damage to Property De forma análoga que la comentada en el apartado 3.7.3, la modificación de parámetros en equipos como PLCs puede resultar en comportamientos adversos de los propios PLCs y los equipos que controlan. Esto puede resultar en daños físicos a equipos e infraestructuras de ICS ya que se está tratando con equipamiento industrial y potencialmente peligroso como motores, válvulas o actuadores. También se puede ver en la pestaña de debug de Node-Red la variable, dirección y valor que se ha enviado en la petición de Write Var de S7comm. Ataques de red Realizados 92 Figura 3-111. Point Command BINARY_OUTPUT – Manipulation of Control A continuación, para la variable de tipo ANALOG_OUTPUTS se abrirá también la ventana de Point Command, se seleccionará la acción DIRECT_OPERATE y se introducirá el valor 2000 como se puede ver en la Figura 3- 112: Figura 3-112. Point Command ANALOG_OUTPUTS – Manipulation of Control Finalmente, en el equípo esclavo se puede comprobar que se han modificado el valor de ambos parámetros: 93 Análisis de la capacidad de detección de Snort sobre ataques de red en ICS bajo la matriz MITRE ATT&CK Figura 3-113. Resultado del ataque – Manipulation of Control La modificación de estos parámetros puede resultar permite al atacante ganar el control del proceso industrial en un ICS. En el caso de la variable binaria, conmuar su valor puede encender o apagar un dispositivo en un momento inadecuado. Por otro lado, la modificación de la variable de tipo análogo puede alterar el comportamiento de un dispositivo de forma que provoque daños al proceso industrial y a la infraestructura del ICS. 3.9.4 Theft of Operational Information En esta técnica los adversarios intentarán obtener información operacional acerca de equipos, procesos e infraestructura de un ICS con el objetivo ganar conocimiento acerca de el funcionamiento y estructura de un ICS para futuros ataques o para beneficio personal. En este apartado se mostrarán cuatro ataques que resultan en la obtención de este tipo de información. 3.9.4.1 Lectura de registros mediante mensajes Modbus En este ataque se utilizará el protocolo Modbus para obtener información acerca de un equipo del ICS. Para realizar el ataque se utilizará la herramienta Metasploit, concretamente el módulo modbusclient, y para simular un esclavo Modbus se volverá a utilizar ModbusPal. El esquema que seguirá el tráfico del ataque es el siguiente: Ataques de red Realizados 94 Figura 3-114. Diagrama de paso de mensajes – Lectura de registros mediante mensajes Modbus Como se puede ver en el diagrama, se han utilizado las funciones Modbus Read Coils y Read Holding Registers. 3.9.4.1.1 Configuracio n del equipo ví ctima La configuración del equipo víctima es igual que la mostrada en el apartado 3.2.1.2.1. Sin embargo, para este caso se han inicializado los registros de almacenamiento de la misma forma que en el apartado 3.7.1, que se recuerda, tenían los siguientes valores: 95 Análisis de la capacidad de detección de Snort sobre ataques de red en ICS bajo la matriz MITRE ATT&CK Figura 3-115. Estado inicial registros de almacenamiento – Lectura de registros mediante mensajes Modbus Y para los registros de tipo Coil se ha incializado de la siguiente forma: Figura 3-116. Estado inicial registros coils – Lectura de registros mediante mensajes Modbus Ataques de red Realizados 96 3.9.4.1.2 Configuracio n del equipo atacante Como se utilizará la herramienta Metasploit, no se requerirá ninguna configuración en el equipo del atacante además de configurar una dirección IP dentro de la misma subred que el equipo víctima. Para este ataque el equipo adversario tendrá la dirección IP 192.168.100.2. 3.9.4.1.3 Ejecucio n del ataque Como se ha hecho anteriormente, se inicia la consola de Metasploit y en este caso se busca el módulo modbusclient, para este ataque tendremos que establecer las opciones: - Direccion del primer registro del que leer: 10 - Numero de registros que leer: 5 - Direción IP del equipo víctima: 192.168.100.3 - ID del esclavo Modbus: 1 - Función a ejecutar: READ_COILS (equivale a Read Coils) Una vez que se ejecuta el módulo obtenemos que no se ha recibido ninguna excepción y se han leído correctamente los valores indicados, que como podemos ver en la Figura 3-117 corresponden con los valores que se muestran en la Figura 3-116: Figura 3-117. Resultado de la función Read Coils – Lectura de registros mediante mensajes Modbus Este resultado puede dar a un adversario, por ejemplo, información sobre el estado de dispositivos que estén siendo controlados por un PLC, obteniendo una lista de equipos apagados/encendidos. A continuación, se usará la acción de modbusclient READ_REGISTERS para leer los valores de los registros de almacenamiento del 11 al 20: Figura 3-118. Resultado de la función Read Holding Registers – Lectura de registros mediante mensajes Modbus En este caso, el resultado del ataque puede dar al adversario información sobre los valores de las distintas variables de un PLC, de forma que se pueda planear en base a eso futuros ataques. 97 Análisis de la capacidad de detección de Snort sobre ataques de red en ICS bajo la matriz MITRE ATT&CK 3.9.4.2 Lectura de registros mediante mensajes S7comm En este ataque se utilizará el protocolo S7comm para obtener información acerca de un PLC S7-1200. Para realizar el ataque se utilizará la herramienta Node-RED, y para simular el PLC se volverá a utilizar PLCSIM, acompañada de TIA Portal y NetToPlcsim. El esquema que seguirá el tráfico del ataque es el siguiente, donde se utilizará la función S7comm Read Var: Figura 3-119. Diagrama de red – Lectura de registros mediante mensajes S7comm 3.9.4.2.1 Configuracio n del equipo ví ctima Para este ataque se va a usar la misma configuración del equipo víctima que la mostrada en el apartado 3.8.1.1. 3.9.4.2.2 Configuracio n del equipo atacante En este caso, se establecerán de nuevo los nodos de inject y msg.payload, pero se sustituirá el nodo s7comm: write por su análogo para lectura, s7comm: read, de forma que los nodos que se van a utilizar para este ataque son: Ataques de red Realizados 98 Figura 3-120. Conexión de los nodos Node-RED – Lectura de registros mediante mensajes S7comm El resto de la configuración será igual que la mostrada en el apartado 3.8.1.2, salvo que el nodo inject no necesita ninguna configuración. 3.9.4.2.3 Ejecucio n del ataque Para realizar el ataque simplemente habrá que poner en marcha Node-RED de la misma forma que en el apartado 3.8.1.3. Luego, si se comprueban los valores obtenidos en la ventana de debug podemos ver que se han obtenido los mismos valores que se pueden ver en la Figura 3-121 para las variables Start y VariableInt1: Figura 3-121. Resultado del ataque VariableInt1 – Lectura de registros mediante mensajes S7comm 99 Análisis de la capacidad de detección de Snort sobre ataques de red en ICS bajo la matriz MITRE ATT&CK Figura 3-122. Resultado del ataque Start – Lectura de registros mediante mensajes S7comm Al igual que en el apartado anterior, un adversario que realice este ataque podría ganar informacion sobre el estado del PLC y su funcionamiento. 3.9.4.3 Descubrimiento del sistema de directorios mediane DNP3 En este ataque se describirá como meante órdenes DNP3 un adversario podría descubrir la estructura de directorios que presenta el equipo víctima. Para ello se hará uso de las herramientas FreyrSCADA DNP3 Client (Master) Y Server (Outstation) para el equipo atacante y víctima respectivamente. Para desarrollar el ataque se harán uso de las funciones DNP3 Open File y Read, descritas en la Tabla 2-2, mediante la orden Open File se abre un directorio del equipo víctima y con la orden Read se lee su contenido. En la Figura 3-123 se puede apreciar el diagrama de paso de mensajes de este ataque: Ataques de red Realizados 100 Figura 3-123. Diagrama de paso de mensajes – Descubrimiento del sistema de directorios mediante DNP3 101 Análisis de la capacidad de detección de Snort sobre ataques de red en ICS bajo la matriz MITRE ATT&CK 3.9.4.3.1 Configuracio n del equipo ví ctima La configuración del equipo esclavo es la misma que la descrita en el Apartado 3.1.1. 3.9.4.3.2 Configuracio n del equipo atacante La configuración del equipo maestro es la misma que la descrita en el Apartado 3.1.2. 3.9.4.3.3 Ejecucio n del ataque Una vez se tengan configurados y conectados los equipos atacante y víctima se debe seleccionar en el equipo atacante en el menú desplegable Station Commands > Directory Read, tras lo que se abrirá una ventana donde habrá que introducir la ruta del directorio del que se quiere ver su contenido. Para este caso se ha elegido C:\Program Files (x86)\FreyrSCADA Embedded Solution\ Tras ejecutar la orden se mostrará el contenido de dicho directorio como se puede ver en la siguiente Figura: Figura 3-124. Resultado Direcory Read – 1 – Descubrimiento del sistema de directorios mediante DNP3 Se puede ver que dentro del directorio seleccionado hay 2 nuevos directorios, si ahora añadimos uno de ellos, por ejemplo, DNP Outstation - Server Simulator\, a la ruta que se tenía y hacemos una nueva petición podremos ver el contenido de ese nuevo directorio: Detección de Snort 108 108 4.3 Reglas TALOS TALOS es un equipo de inteligencia de amenazas comerciales que forma parte de Cisco, y que a su vez forma parte de la comunidad que desarrolla día a día mejoras para sistemas de ciberseguridad como Snort, para los que se encargan de mantener y actualizar el conjunto de reglas utilizado en este apartado. En la Tabla 4-1 se pueden ver los resultados obtenidos del análisis de Snort de los ataques realizados utilizando el paquete de reglas TALOS [36]. Táctica Técnica Ataque Reglas detectadas Initial Access Rogue Master Envío de ordenes a outstation desde un master no legitimo - Discovery Remote System Discovery Escaneo de direcciones IP que usen S7comm conectadas a la red - Discovery Remote System Discovery Escaneo de direcciones IP que usen Modbus conectadas a la red 15071, 17798, 17799 Discovery Remote System Discovery Escaneo de direcciones IP que usen Modbus conectadas a la red 17789, 15071 Discovery Remote System Information Discovery Descubrimiento de información del outstation medinate DNP3 - Lateral Movement Program Download Subida y descarga de ficheros a un PLC 17782, 17790 Collection Automated Collection Obtención de información de un equipo a través de SNMP 1411. 1417 Command and Control Commonly Used Port Camuflaje de tráfico C&C al usar puertos estándar 502 (RealWin Server) 15071 Command and Control Commonly Used Port Camuflaje de tráfico C&C al usar puertos estándar 502 (Ignition SCADA) 15071, 50447 Command and Control Commonly Used Port Camuflaje de tráfico C&C al usar puertos estándar 20000 (RealWin Server) - Command and Control Commonly Used Port Camuflaje de tráfico C&C al usar puertos estándar 102 (Ignition SCADA) Inhabit Response Function Denial of Service DoS mediante protocolo PCCC - 109 Análisis de la capacidad de detección de Snort sobre ataques de red en ICS bajo la matriz MITRE ATT&CK Inhabit Response Function Device Restart/Shutdown Apagado de PLC mediante orden CIP 40518 Impair Process Control Modify Parameter Modificación de parámetros medinate ordenes Modbus 17783, 17782 Impact Damage to Property Modificación de parámetros mediante ordenes S7comm - Impact Loss of Productivity and Revenue Apagado de dispositivos conectados a un PLC mediante la modificación de variables que controlen dichos equipos 17785 Impact Manipulation of Control Modificación de parámetros mediante ordenes DNP3 - Impact Theft of Operational Information Lectura de registros mediante mensajes Modubs 17788, 17790 Impact Theft of Operational Information Lectura de registros mediante mensajes S7comm - Impact Theft of Operational Information Descubrimiento del sistema de directorios de outstation mediane DNP3 - Impact Theft of Operational Information Subida y descarga de ficheros a un PLC - Tabla 4-1. Resultados del conjunto de reglas TALOS 4.4 Reglas ETopen Emerging Threats (ET) es un grupo dedicado a la investigación en ciberseguridad en el campo Open Source que contribuyen con varios sistemas IDS como Snort. En su repositorio Open cuentan con las reglas de detección de Snort que se han usado para obtener los resultados de este apartado. La Tabla 4-2 muestra los resultados obtenidos del análisis de Snort de los ataques realizados utilizando el paquete de reglas ETopen [37]. Táctica Técnica Ataque Reglas detectadas Initial Access Rogue Master Envío de ordenes a outstation desde un master no legitimo - Discovery Remote System Discovery Escaneo de direcciones IP que usen S7comm conectadas a la red - Detección de Snort 110 110 Discovery Remote System Discovery Escaneo de direcciones IP que usen Modbus conectadas a la red - Discovery Remote System Discovery Escaneo de direcciones IP que usen Modbus conectadas a la red - Discovery Remote System Information Discovery Descubrimiento de información del outstation medinate DNP3 - Lateral Movement Program Download Subida y descarga de ficheros a un PLC - Collection Automated Collection Obtención de información de un equipo a través de SNMP 2101411, 1417, 1411 Command and Control Commonly Used Port Camuflaje de tráfico C&C al usar puertos estándar 502 (RealWin Server) 2011976, 2035480, 2025644 Command and Control Commonly Used Port Camuflaje de tráfico C&C al usar puertos estándar 502 (Ignition SCADA) 2018358, 2035480, 2025644 Command and Control Commonly Used Port Camuflaje de tráfico C&C al usar puertos estándar 20000 (RealWin) 2011976, 2035480, 2025644 Command and Control Commonly Used Port Camuflaje de tráfico C&C al usar puertos estándar 102 (Ignition SCADA) 2018358, 2035480, 2025644 Inhabit Response Function Denial of Service DoS mediante protocolo PCCC 2026917 Inhabit Response Function Device Restart/Shutdown Apagado de PLC mediante orden CIP - Impair Process Control Modify Parameter Modificación de parámetros medinate ordenes Modbus - Impact Damage to Property Modificación de parámetros mediante ordenes S7comm - Impact Loss of Productivity and Revenue Apagado de dispositivos conectados a un PLC mediante la modificación de variables que controlen dichos equipos - 111 Análisis de la capacidad de detección de Snort sobre ataques de red en ICS bajo la matriz MITRE ATT&CK Impact Manipulation of Control Modificación de parámetros mediante ordenes DNP3 - Impact Theft of Operational Information Lectura de registros mediante mensajes Modubs - Impact Theft of Operational Information Lectura de registros mediante mensajes S7comm - Impact Theft of Operational Information Descubrimiento del sistema de directorios de outstation mediane DNP3 - Impact Theft of Operational Information Subida y descarga de ficheros a un PLC - Tabla 4-2. Resultados del conjunto de reglas ETopen 4.5 Reglas QuickDraw El paquete de reglas QuickDraw ha sido desarrollado por la empresa Digital Bond, la cual tiene ramas de investigación en el campo de la ciberseguridad para ICS y trabaja con varios gobiernos en este tema. El conjunto de reglas, además de tráfico de ataque de ejemplo, es público en Github. Este repositorio se puede consultar en la referencia [30]. La Tabla 4-3 muestra los resultados obtenidos del análisis de Snort de los ataques realizados utilizando el paquete de reglas QuickDraw. Táctica Técnica Ataque Reglas detectadas Initial Access Rogue Master Envío de ordenes a outstation desde un master no legitimo 1111204, 1111210 Discovery Remote System Discovery Escaneo de direcciones IP que usen S7comm conectadas a la red - Discovery Remote System Discovery Escaneo de direcciones IP que usen Modbus conectadas a la red 1111004, 1111005 Discovery Remote System Discovery Escaneo de direcciones IP que usen Modbus conectadas a la red 1111006 Discovery Remote System Information Discovery Descubrimiento de información del outstation medinate DNP3 1111206, 1111207 Lateral Movement Program Download Subida y descarga de ficheros a un PLC 1111006, 1111007 Detección de Snort 112 112 Collection Automated Collection Obtención de información de un equipo a través de SNMP Command and Control Commonly Used Port Camuflaje de tráfico C&C al usar puertos estándar 502 (RealWin Server) 1111008, 1111009, 1111012 Command and Control Commonly Used Port Camuflaje de tráfico C&C al usar puertos estándar 502 (Ignition SCADA) 1111008, 1111009, 1111012 Command and Control Commonly Used Port Camuflaje de tráfico C&C al usar puertos estándar 20000 (RealWin Server) 1111202 Command and Control Commonly Used Port Camuflaje de tráfico C&C al usar puertos estándar 102 (Ignition SCADA) - Inhabit Response Function Denial of Service DoS mediante protocolo PCCC - Inhabit Response Function Device Restart/Shutdown Apagado de PLC mediante orden CIP - Impair Process Control Modify Parameter Modificación de parámetros medinate ordenes Modbus 1111007 Impact Damage to Property Modificación de parámetros mediante ordenes S7comm - Impact Loss of Productivity and Revenue Apagado de dispositivos conectados a un PLC mediante la modificación de variables que controlen dichos equipos 1111007 Impact Manipulation of Control Modificación de parámetros mediante ordenes DNP3 1111206, 1111207 Impact Theft of Operational Information Lectura de registros mediante mensajes Modubs 1111006 Impact Theft of Operational Information Lectura de registros mediante mensajes S7comm - Impact Theft of Operational Information Descubrimiento del sistema de directorios de outstation mediane DNP3 1111206, 1111208 113 Análisis de la capacidad de detección de Snort sobre ataques de red en ICS bajo la matriz MITRE ATT&CK Impact Theft of Operational Information Subida y descarga de ficheros a un PLC 1111201, 1111204, 1111206, 1111208, 1111210 Tabla 4-3. Resultados del conjunto de reglas QuickDraw 4.6 Resultados tráfico QuickDraw para todos los conjuntos de reglas En este apartado se exponen los resultados obtenidos tras analizar el tráfico de ataque proporcionado por el repositorio de QuickDraw por los conjuntos de reglas de TALOS, ETopen y el propio QuickDraw: Protocolo Resutlado Snort Reglas detectadas Bacnet No detectado - DNP3 Detectado 15718, 15717, 15713 ENIP No detectado - FOX No detectado - Modbus Detectado 15071, 15074, 15075, 17782, 17783, 17784, 17785, 17787, 17788, 17789, 17790, 17791, 17792, 17794, 17795, 17796, 17797, 17798, 17799, 17800, 29319, 30816, 30819 Modicon No detectado - OMRON No detectado - S7comm No detectado - Tabla 4-4. Resultados para el tráfico de ataque QuickDraw para las reglas TALOS Protocolo Resutlado Snort Reglas detectadas Bacnet No detectado - DNP3 No detectado - ENIP No detectado - FOX No detectado - Detección de Snort 114 114 Modbus No detectado - Modicon No detectado - OMRON No detectado - S7comm No detectado - Tabla 4-5. Resultados para el tráfico de ataque QuickDraw para las reglas ETopen Protocolo Resutlado Snort Reglas detectadas Bacnet Detectado 1111701, 1111702, 1111703, 1111704, 1111705, 1111707, 1111708, 1111709 DNP3 Detectado 1111201, 1111202, 1111205, 1111206, 1111207, 1111208, 1111209, 1111210, 1111212, 1111213 ENIP Detectado 1111517 FOX Detectado 1111101 Modbus Detectado 1111001, 1111002, 1111003, 1111004, 1111005, 1111006, 1111007, 1111008, 1111009, 1111010, 1111011, 1111012, 1111013, 1111014 Modicon Detectado 1111015 OMRON Detectado 1111401, 1111402, 1111403, 1111404 S7comm No detectado - Tabla 4-6. Resultados para el tráfico de ataque QuickDraw para las reglas QuickDraw 115 Análisis de la capacidad de detección de Snort sobre ataques de red en ICS bajo la matriz MITRE ATT&CK 5 DISCUSIÓN DE RESULTADOS n esta sección se discutirán los resultados del análisis del IDS Snort del tráfico de ataque generado en el apartado 3. Se verá detalladamente qué ataques han hecho saltar alertas y cuales no. Todos los resultados de los análisis de Snort se pueden encontrar también en el libro de Excel que se encuentra en el repositorio de Github [41] y cuyo contenido se describe brevemente en el Anexo B. 5.1 Reglas TALOS El conjunto de reglas TALOS ha obtenido un resultado aceptable, detectando 10 de los 21 ataques realizados, considerando un ataque como detectado cuando salta, al menos, una regla relacionada con el ataque que se ha llevado acabo. A continuación, se muestran varias gráficas acerca de las detecciones logradas por este conjunto de reglas: Figura 5-1. Distribución de las detecciones por protocolo (TALOS) Figura 5-2. Porcentaje de ataques detectados en cada táctica de la matriz de MITRE (TALOS) 0 1 2 3 4 5 6 7 8 9 Modbus TCP DNP3 S7comm CIP PCCC SNMP Número de detecciones Protocolos Ataques detectados por protocolo (TALOS) 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% Initial Access Discovery Lateral Movement Collection Command and Control Inhabit Response Function Impair Process Control Impact Porcentaje de ataques detectados por táctica (TALOS) Ataques detectados Ataques no detectados E Discusión de Resultados 116 116 Como se puede ver en la Figura 5-1, las reglas TALOS han sido capaces de detectar ataques de 3 protocolos distintos, Modbus TCP, CIP y SNMP. Por otra parte, en la Figura 5-2 se puede observar que, excepto para la táctica de Initial Access, se han detectado como mínimo el 28.6% de los ataques de cada táctica. Aunque también hay que tener en cuenta que no todas las tácticas tienen el mismo nº de ataques, en la Figura 5-3 se puede ver un gráfico que muestra la división de ataques detectados por categoría: Figura 5-3. Distribucion de los ataques detectados por táctica de la matriz de MITRE (TALOS) En los siguientes sub-apartados se examinarán las reglas que han detectado los ataques para los 3 protocolos mencionados y se describirá por qué no han sido detectados los ataques de los demás protocolos. 5.1.1 Detecciones del protocolo Modbus De los 7 ataques de se han realizado usando el protcolo Modbus, el paquete de reglas TALOS ha sido capaz de detectar todos. Las reglas que han detectado ataques de este protocolo han sido las siguientes: - 15071: se ha devuelto una excepción. - 17782: se ha escrito en múltiples registros de almacenamiento. - 17783: se ha escrito en un registro de almacenamiento. - 17785: se ha escrito en múltilpes registros binarios. - 17789: se ha leído el contenido de un registro de almacenamiento. - 17790: se ha leído el contenido de múltiples registros de almacenamiento. - 17798: se ha usado la función Report Slave ID (17). - 17799: se ha usado la función Read Device Identification (43). Como se puede ver, el conjunto de reglas TALOS está preparado para detectar actividad maliciosa que se centre en la lectura/escritura de registros de esclavos Modbus. Esto explica su muy buen resultado en la detección de los ataques que se han realizado con este protocolo, ya que muchos de los ataques realizados para Modbus están basados en las funciones de lectura/escritura aprovechando la falta de autenticación de este. Initial Access 0% Discovery 23% Lateral Movement 11% Collection 11% Command and Control 11% Inhabit Response Function 11% Impair Process Control 11% Impact 22% Ataques detectados Initial Access Discovery Lateral Movement Collection Command and Control Inhabit Response Function Impair Process Control Impact 117 Análisis de la capacidad de detección de Snort sobre ataques de red en ICS bajo la matriz MITRE ATT&CK Las reglas 17782-99 se basan en el campo donde se indica el código de función en la ADU de Modbus, visto en la Figura 2-2, de esta forma, permite detectar posibles ataques que usen el protocolo según los códigos de funcion que se manden en las distintas peticiones. Esto se hace mediante la sintaxis: modbus_func:<nombre_funcion> Cabe destacar que los ataques de la táctica Command and Control han sido detectado por la regla 15071, a pesar de que no se ha recibido ninguna excepción Modbus, ya que, de hecho, no se cursa si quiera tráfico Modbus, sino que sólo se usa el puerto TCP 502. Esto se debe a que esta regla comprueba que se ha producido una excepción Modbus mediante la siguiente sintaxis: byte_test:1,&,128,7 Donde cada elemento significa: - 7: indica que se va a comenzar a analizar el 8º byte de la cabecera Modbus, se indica el número 7 porque el primero se cuenta como el 0. - 1: se analiza 1 byte a partir del 8º byte. - &: se realiza la operación AND. - 128: valor con el que se realiza la operación, en decimal. Por tanto, se está comprobando que el bit más significativo del campo Function Code (ver en Figura 2-2) es 1, ya que cuando se devuelve una excepción Modbus, el campo Function Code de la respuesta se mantiene igual que el de la petición, pero cambiando el bit más significativo a 1, como se comentó en el apartado 2.2.1. Sin embargo, en este caso al no estar usándose Modbus, en todos los paquetes del tráfico de meterpreter ha coincidido que el primer bit del 8º byte después de la cabecera TCP es 1, de forma que la regla 15071 lo detecta como si fuera una excepción Modbus. Por consiguiente, la detección de este ataque podría considerarse un falso positivo, aunque la generación de estas alertas podría alertar de que se está produciendo actividad sospechosa lo cual podría llevar a descubrir el ataque. 5.1.2 Detecciones del ataque de Command and Control para Ignition También, para el ataque de Command and Control realizado con la herramienta Ignition SCADA (para el puerto 502 y 102) se ha lanzado una alarma correspondiente a la regla 50447. Esta alerta realmente corresponde con el protocolo HTTP, que usa el módulo de Metasploit para aprovechar la vulnerabilidad de la herramienta Ignition, y detecta cuando se usa una dirección IP en el campo host de la cabecera HTTP. Esta alerta, aunque puede levantar sospechas de que se está cursando algún tráfico extraño, por si misma no tiene por qué alertar de un ataque contra ICS, por lo tanto se podría considerar un falso positivo. 5.1.3 Detecciones del protocolo CIP En el caso del protocolo CIP, la regla que ha detectado el ataque ha sido la 40518. Esta alerta detecta que se ha realizado un intento de parado de la CPU de el equipo víctima comprobando, principalmente, los siguientes campos del paquete CIP: - Comando ENIP: se comprueba si es el comando ENIP se corresponde con Send RR Data (0x6f), el cuál indica que se está mandado un mensaje de tipo sin conexión, mediate la sintaxis content:"|6F 00|",depth 2;, donde el campo content indica los bytes a detectar y depth el número de bytes a detectar. - Servicio CIP: se comprueba si el campo que indica el servicio CIP corresponde al servicio CIP Stop CPU (0x07), gracias a content:"|07 02 20 64 24 01|", donde 07 es la parte del servicio CIP. 5.1.4 Detecciones del protocolo SNMP El conjunto TALOS cuenta con varias reglas para la detección de mensajes SNMP. En este caso, el ataque ha sido detectado por las alertas: Discusión de Resultados 124 124 código de función Modbus utilizado es alguna de las funciones de lectura que implementa el protocolo ( consultar Tabla 2-1 y [2]). - 1111007: se ha realizado una petición de escritura no autorizada a un PLC. De forma análoga a la regla 1111006, se comprueba el campo Protocol ID y, en este caso, que el código de función sea alguna de las funciones de escritura de Modbus mediante pcre:"/[\S\s]{3}(\x05|\x06|\x0F|\x10|\x15|\x16)/iAR"; - 1111008: se ha detectado un paquete de tamaño ilegal. Esta regla detecta cualquier paquete que tenga más de 300 bytes de datos. - 1111009: se ha establecido comunicación en el puerto TCP 502 que no utiliza el protocolo Modbus. Esta regla también comprueba que el campo de Protocol ID sea 00 00, ya que siempre en Modbus TCP este campo tendrá ese valor. En este caso se usa sintaxis de pcre:"/[\S\s]{2}(?!\x00\x00)/iAR" para detectar el valor del campo mediante expresiones regulares. - 1111012: se ha detectado un paquete con longitud incorrecta. Las reglas 1111006 y 1111007 requieren una leve modificación a la configuración de las variables MODBUS_SERVER y MODBUS_CLIENT del archivo snort.conf. Puesto que lo que están detectando es una petición no autorizada, la sintaxis de estas reglas muestra lo siguiente: alert tcp !$MODBUS_CLIENT any -> $MODBUS_SERVER 502 Por tanto, para los ataques realizados se tendría que establecer MODBUS_CLIENT como una dirección o rango que no incluya 192.168.100.2 y MODBUS_SERVER como 192.168.100.2, ya que se está comprobando que se realice una petición desde una dirección que no sea la que representa un cliente Modbus legítimo. Esto quiere decir que las reglas de QuickDraw, aunque son capaces de detectar las funciones de lectura y escritura de Modbus, no serían capaces de hacerlo si el atacante obtuviese el control de un equipo con dirección IP dentro del rango establecido en la variable MODBUS_CLIENT. En este caso los ataques de Commonly Used Port que utilizan el puerto TCP 502, han sido detectados por las alertas 1111008, 1111009 y 1111012. Aunque en las reglas QuickDraw no se incluya ninguna que detecte el exploit contra el servidor de RealWin o Ignition, sí que es capaz de identificar correctamente que se está usando un puerto estándar para tráfico que no corresponde con el protocolo que suele usarlo, lo cuál es un indicio claro de un ataque de la técnica mencionada. 5.3.2 Deteccion del protocolo DNP3 Las siguientes reglas han detectado el tráfico de DNP3 de los ataques realizados: - 1111202: se ha establecido comunicación en el puerto 20000 que no utiliza el protocolo DNP3. De forma análoga a con el protocolo Modbus, esta regla comprueba el campo Start de la cabecera de nivel de enlace del protocolo DNP3, mediante la siguiente sintaxis usando una expresión regular: pcre:"/(?!\x05\x64)/iAR";. En mensajes del protocolo DNP3 ese campo siempre es 0x05 0x64. - 1111204: se ha detectado un Cold Restart. Esta regla detecta mediante content:"|0D|"; offset:12; depth:1 que el byte número 13 de la cabecera DNP3 es 0x0D, es decir, que el campo del código de función DNP3 de la cabecera de pseudotransporte (Figura X) es el de Cold Restart. - 1111206: se ha detectado una petición de lectura no autorizada. Se detecta, de nuevo, que el campo de Function Code sea 0x01, lo que equivale a la función Read, mediante content:"|01|"; offset:12; depth:1; - 1111207: se ha detectado una petición de escritura no autorizada. De forma completamente análoga a las reglas de Modbus para lectura/escritura, en este caso se utiliza la sintaxis: pcre:"/[\S\s]{10} (\x02|\x04|\x05|\x06|\x09|\x0A|\x0F|\x12). Así se detectan todas las funciones DNP3 que sean de tipo escritura mediante, de nuevo, el valor del campo Function Code de DNP3. - 1111208: se ha detectado una petición no categorizada no autorizada. Se detectan otro tipo de funciones de la misma forma que la regla anterior mediante la sintaxis: pcre:"/[\S\s]{10}(\x03|\x07|\x08| \x0B|\x0C|\x10|\x11|\x13|\x14|\x15|\x16|\x17|\x18|\x19|\x1A|\x1B|\x1C|\x1D|\x1E). 125 Análisis de la capacidad de detección de Snort sobre ataques de red en ICS bajo la matriz MITRE ATT&CK - 1111210: se ha detectado un Warm Restart. De forma análoga a la anterior, mediante content:"|0E|"; offset:12; depth:1; detecta que el campo del código de función es 0x0E que equivale a la función Warm Restart. - 1111201: se ha usado la función Disable Unsolicited Responses (0x15). Al igual que las reglas 1111202 y 1111204 se comprueba si el código de función DNP3 es 0x15. Cabe destacar que la regla 1111208 salta en los ataques de descubrimiento del sistema de ficheros y descarga de un fichero mediante DNP3 debido a las funciones de Open File (19) y Close File (1A) que se utilizan, ya que forman parte del conjunto de “funciones misceláneas” que detecta la regla 1111208. 5.3.3 Detecciones del tráfico del repositorio QuickDraw Como es de esperar las reglas QuickDraw han obtenido un muy buen resultado con sus propios ficheros de tráfico, sin embargo, no se han detectado todos los protocolos como cabría esperar. De los 8 protocolos para los que hay reglas configuradas se han detectado 5: • Bacnet: se han detectado todas las reglas relativas a este protocolo menos la 1111106 y 1111107 porque no se incluía el tráifco necesario en los ficheros proporcionados. • DNP3: se han detectado todas las reglas relativas a este protocolo. • ENIP: se ha detectado la regla relativa a este protocolo. • FOX: la regla 1111101 detecta un intento de descubrimiento de equipos que usen el protocolo FOX, encapsulado en TCP, realizado con el script fox-info.nse desarrollado por Digital Bond [35]. • Modbus: además de las reglas comentadas en el apartado 5.3.1, otras reglas interesantes detectadas son: o 1111001: se ha detectado la función Force Listen Mode Only (0x08 - 04) o 1111002: se ha detectado la función Restart Communications Options (0x08 - 01) o 1111003: se ha detectado la función Restart Communications Options (0x08 – 0A) o 1111013: se ha detectado un escaneo de “Point List”. o 1111014: se ha detectado un escaneo de funciones Modbus. De la misma forma que las demás, se detectan los códigos de funciones y subfunciones con el campo Func. Code de la cabecera Modbus. • Modicon: se ha detectado la regla relativa a este protocolo. • OMRON: Se han obtenido alertas procedentes de las 4 reglas relativas a este protocolo. 5.3.4 Ataques no detectados Las razones por las que no se han detectado más ataques son: • No se incluye ninguna regla para los protocolos CIP ni PCCC. • Para el protoclo S7comm se incluyen reglas que detectan un intento de enumerar los equipos que usen S7comm mediante un script desarrollado por Digital Bond, el cual utiliza la misma función Request CPU Functions que el ataque realizado en el apartado 3.2.1.1. La regla tiene la siguiente sintaxis: content: "|32 07 00 00 00 00 00 08 00 08|"; offset: 0; depth: 10; content: "|00 01 12 04 11 44 01 00|"; offset: 11; depth: 8; Esas 2 sentencias detectan la cabecera y los campos de Parameters de la S7PDU respectivamente (consultar en Figura X), donde 0x44 representa que se está realizando una petición de CPU Functions. Sin embargo, en este caso no se detecta porque la regla especifica que empieza a buscar la primera cadena de bytes en los 10 primeros bytes tras la cabecera TCP, cuando antes de llegar a la cabecera Discusión de Resultados 126 126 S7comm están las cabeceras de los protocolos TKP e ISO-COPT, como también se puede ver en la Figura X. Para que se detectara el ataque realizado se debería modificar los campos de offset de la primera y segunda sentencia para que se empezase a buscar tras las cabeceras de los protocolos antes mencionados, o eliminar las sentencias de depth para que se analizara todo el contenido del paquete. 127 Análisis de la capacidad de detección de Snort sobre ataques de red en ICS bajo la matriz MITRE ATT&CK 6 CONCLUSIONES Y LINEAS DE CONTINUACIÓN ras analizar los resultados en los apartados anteriores, se puede concluir que los tres conjuntos de reglas utilizados han sido capaces de detectar varios de los ataques realizados en el apartado 3, aunque con distinto nivel de eficacia. 6.1 Conclusiones En la siguiente figura se puede ver un gráfico comparativo de los resultados obtenidos para los ataques realizados en el apartado 3 con cada paquete de reglas: Figura 6-1. Comparativa de las detecciones por cada conjunto de reglas. Como se puede ver en la figura anterior, el paquete de reglas que ha obtenido un mejor resultado ha sido el de QuickDraw con el 69% de los ataques detectados. El conjunto que ha obtenido el segundo mejor resultado es el de TALOS con el 48% y por último ETopen con sólo un 29%. El hecho de que QuickDraw haya sido el conjunto más eficaz no es sorprendente ya que, principalmente, es el único conjunto que incorpora reglas del protocolo DNP3, que ha sido usado en varios de los ataques del trabajo. A pesar de esto, tanto TALOS como ETopen han aportado más variedad en los protocolos detectados puesto que QuickDraw solo ha detectado ataques de Modbus y DNP3 (de los ataques realizados en el apartado 3). En cuanto al protocolo Modbus, tanto TALOS como QuickDraw han detectado los 7 ataques realizados, sin embargo, el resultado del conjunto TALOS ofrece más información que el de QuickDraw puesto que, como se puede ver en los apartados 5.1 y 5.3, TALOS incluye una regla diferente para cada función de lectura/escritura, mientras que QuickDraw agrupa todos los códigos de función de lectura en la regla 1111006 y los de escritura en la 1111007. Esto hace que sea más difícil identificar qué tráfico Modbus es el que está haciendo saltar la alarma si se utiliza el conjunto QuickDraw en lugar de el TALOS. Además, tal y como están escritas las reglas QuickDraw, para que se provoquen las alertas relativas a las reglas 1111006 y 1111007 la dirección IP del atacante debe estar fuera el rango que se defina en la variable MODBUS_CLIENT, ya que se pretende sólo detectar las peticiones de lectura/escrituras no autorizadas. En las reglas TALOS si se establece el valor de la variable EXTERNAL_NET como “any” se puede capturar el tráfico de atacantes dentro y fuera de la red industrial. Aún así, la ventaja que presenta QuickDraw ante TALOS respecto a las detecciones del protocolo Modbus es que, las reglas de QuickDraw han sido capaces de detectar más tipos de eventos, ya que, además de las funciones 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% TALOS ETopen QuickDraw Ataques detectados en cada conjunto de reglas Nº de ataques detectados Nº de ataques no detectados T Conclusiones y Lineas de Continuación 128 128 de lectura/escritura, se ha detectado el uso del puerto 502 por un protocolo que no es Modbus y el uso de tamaños de paquetes erróneos. También es importante destacar que, aunque el conjunto de ETopen no ha detectado ningún protocolo específicico de ICS, cuenta con detecciones muy precisas para los ataques de Command and Control e Inhabit Response Función. De esta forma, permite para estos ataques identificar concretamente la vulnerabilidad que se está explotando, en el caso de RealWin y RSLogix, y en la totalidad de los ataques de Command and Control el uso de payloads por parte de Metasploit Por tanto, aunque todos los conjuntos probados han conseguido detectar ataques, lo más eficaz sería utilizar los 3 paquetes de reglas simultáneamente. De esta forma se conseguirían detectar 18 de los 21 ataques realizados en el apartado 3. A continuación se muestran gráficos de los resultados que obtendrían los tres paquetes de forma conjunta: Figura 6-2. Distribucion de las detecciones por protocolo Figura 6-3. Porcentaje de ataques detectados en cada táctica de la matriz de MITRE Como se puede ver en la Figura 6-3, combinando los tres conjuntos de reglas se detectan todos los ataques de todas las tácticas menos de Discovery, de la que se detecta el 75%, e Impact con un 71% de ataques detectados. Esto demuestra la robustez que presenta la combinación de los 3 conjuntos de reglas elegidos. 0 1 2 3 4 5 6 7 8 9 Modbus TCP DNP3 S7comm CIP PCCC SNMP HTTP APEX Número de detecciones por protocolo 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% Initial Access Discovery Lateral Movement Collection Command and Control Inhabit Response Function Impair Process Control Impact Porcentaje de detecciones para cada táctica Ataques detectados Ataques no detectados 129 Análisis de la capacidad de detección de Snort sobre ataques de red en ICS bajo la matriz MITRE ATT&CK Por otra parte, como se puede ver en la Figura 6-2, el único protocolo no detectado es S7comm, el cuál supone también el 25% y el 29% de ataques no detectados de las tácticas de Discovery e Impact respectivamente. Se puede considerar que la mayor carencia que tienen los conjuntos de reglas seleccionados respecto a los ataques realizados en el trabajo es la falta de reglas que detecten tráfico S7comm. (Aunque QuickDraw incluye una regla que detectaría el ataque de Discovery si se modificara como se explicó en el apartado 5.3.4). Sin embargo, para el resto de los protocolos probados se complementan muy bien, ya que, por ejemplo, para los ataques de Modbus combinando las detecciones de TALOS y QuickDraw se identificarían qué funciones se están usando, además de detecciones sobre tamaños ilegales de paquetes y excepciones Modbus. Por otra parte, para los ataques de Command and Control, combinando los paquetes de QuickDraw y ETopen, se detectaría que, por un lado, se está cursando tráfico por puertos estándar que no corresponde a los protocolos Modbus y DNP3, y por otro el uso de payloads por parte de Metasploit y explotación de vulnerabilidades en el caso de RealWin Server. 6.2 Líneas de continuación Como líneas de continuación del trabajo se pueden realizar los siguientes puntos: • Explorar ataques de más protocolos ICS: el conjunto de TALOS, por ejemplo, tiene reglas para otros protocolos de ICS como OMRON y Modicon. En la referencia [39] se puede encontrar una descripción de los protocolos más utilizados en ICS. También sería interesante probar ataques del protocolo OPC. En este trabajo no se han cubierto estos protocolos por falta de tiempo y herramientas de simulación. • Configurar reglas propias para Snort: un aspecto a tener en cuenta podría ser el desarrollo de reglas propias de Snort, ya que una vez conocidos los protocolos ICS y como funcionan, se pueden desarrollar reglas que detecten actividad maliciosa de los mismos. Por ejemplo, para S7comm, ya que ningún conjunto incorpora reglas para este protocolo. • Alternativas a las herramientas de simulación: como se ha comentado antes, la falta de herramientas de simulación de elementos ICS ha sido un gran problema a la hora de encontrar ataques para realizar en el trabajo. Si bien se ha intentado encontrar herramientas de simulación de equipos como PLCs que utilicen protocolos ICS, otra opción podría ser utilizar herramientas que generen tráfico de forma genérica, aunque no se podría comprobar la reacción del equipo víctima. • Explorar ataques recogidos en el libro de Excel que por falta de tiempo o herramientas no se han podido realizar. En este se incluyen una gran cantidad de ataques posibles para ICS, por lo que se podría investigar formas de realizarlos apoyándose en los puntos comentados anteriormente. Referencias 130 130 REFERENCIAS [1] Industrial Control System, https://www.trendmicro.com/vinfo/us/security/definition/industrial-control- system, 13/04/2022 [2] MODBUS APPLICATION PROTOCOL SPECIFICATION, https://modbus.org/docs/Modbus_Application_Protocol_V1_1b.pdf, 16/06/2022 [3] MODBUS Application Protocol, https://datatracker.ietf.org/doc/html/draft-dube-modbus-applproto- 00#section-2.1, 16/06/2022 [4] "IEEE Standard for Electric Power Systems Communications-Distributed Network Protocol (DNP3)," in IEEE Std 1815-2012 (Revision of IEEE Std 1815-2010) , vol., no., pp.1-821, 10 Oct. 2012, doi: 10.1109/IEEESTD.2012.6327578, https://ieeexplore.ieee.org/document/6327578, 17/06/2022 [5] RFC 1006, https://datatracker.ietf.org/doc/html/rfc1006, 17/06/2022 [6] RFC 905, https://datatracker.ietf.org/doc/html/rfc905, 17/06/2022 [7] The Siemens S7 Communication - Part 1 General Structure, http://gmiru.com/article/s7comm/, 17/06/2022 [8] The Siemens S7 Communication - Part 2 Job Requests and Ack Data, http://gmiru.com/article/s7comm- part2/ 17/06/2022 [9] Accurate Modeling of the Siemens S7 SCADA Protocol for Intrusion Detection and Digital Forensics, Amit Kleinmann, Avishai Wool, 2014. https://commons.erau.edu/cgi/viewcontent.cgi?article=1169&context=jdfsl, 17/06/2022 [10] EtherNet/IP Quick Start for Vendors Handbook, https://www.odva.org/wpcontent/uploads/2020/05/PUB00213R0_EtherNetIP_Developers_Guide.pdf, 18/06/2022 [11] Matriz de MITRE ATT&CK, https://collaborate.mitre.org/attackics/index.php/Main_Page, 03/07/2022 [12] FreyrSCADA DNP3 Client, https://www.freyrscada.com/dnp3-ieee-1815-Client-Simulator.php, 20/06/2022 [13] FreyrSCADA DNP3 Server, https://www.freyrscada.com/dnp3-ieee-1815-Server-Simulator.php, 20/06/2022 [14] Script s7-info, https://nmap.org/nsedoc/scripts/s7-info.html, 21/06/2022 131 Análisis de la capacidad de detección de Snort sobre ataques de red en ICS bajo la matriz MITRE ATT&CK [15] Descarga del SIMATIC STEP 7, incluyendo Safety, y WinCC V16 de prueba, https://support.industry.siemens.com/cs/document/109772803/descarga-del-simatic-step-7-incluyendo-safety- y-wincc-v16-de-prueba-(trial)?dti=0&lc=es-ES, 21/06/2022 [16] NetToPlcsim, http://nettoplcsim.sourceforge.net/, 21/06/2022 [17] Script modbus-discover, https://nmap.org/nsedoc/scripts/modbus-discover.html, 21/06/2022 [18] ModbusPal - a Java MODBUS simulator, https://sourceforge.net/projects/modbuspal/, 22/06/2022 [19] Numeric List of DNP3 Outstation Device Attributes, http://gtg.ddns.net:8080/file/help_en- US/Content/DNP3DriverGuide/NumericListofDNP3OutstationDeviceAttributes.htm?tocpath=Driver%20Ref erence%7CDNP3%20Driver%7CDNP3%20Specific%20Status%20Display%20Attributes%7CNumeric%20 List%20of%20DNP3%20Outstation%20Device%20Attributes%7C_____0, 23/06/2022 [20], PlcInjector Github, https://github.com/BorjaMerino/PlcInjector, BorjaMerino, 23/06/2022 [21] A New Injection Threat on S7-1500 PLCs - Disrupting the Physical Process Offline. IEEE Open Journal of the Industrial Electronics Society. 3. 1-1. 10.1109/OJIES.2022.3151528. Alsabbagh, Wael & Langendoerfer, Peter. (2022), https://www.researchgate.net/publication/358617664_A_New_Injection_Threat_on_S7- 1500_PLCs_-_Disrupting_the_Physical_Process_Offline, 18/06/2022 [22] CVE-2010-4142, https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4142, 24/06/2022 [23] SCADA Hacking: Attacking SCADA/ICS Systems through the Human Machine Interface (HMI), https://www.hackers-arise.com/post/scada-hacking-attacking-scada-ics-systems-through-the-human-machine- interface-hmi, 23/06/2022 [24] RFC 3080, https://datatracker.ietf.org/doc/html/rfc3080, 19/06/2022 [25] Portal de descarga Ignition SCADA, https://inductiveautomation.com/downloads/archive/8.0.0, 05/07/2022 [26] Vulnerabilidad Ignition SCADA, https://github.com/rdomanski/Exploits_and_Advisories/blob/master/advisories/Pwn2Own/Miami2020/rce_me _v2.md, rdomanski, 05/07/2022 [27] Descarga del SIMATIC S7-PLCSIM Advanced, https://support.industry.siemens.com/cs/document/109772889/descarga-del-simatic-s7-plcsim-advanced-v3-0- de-prueba-(trial)?dti=0&lc=es-WW, 29/06/2022 [28] CVE-2017-7924, https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7924, 27/06/2022 Referencias 132 132 [29] Rockwell Download Center Webpage, https://compatibility.rockwellautomation.com/Pages/MultiProductFindDownloads.aspx?crumb=112&mode=3 &refSoft=1&versions=3943,50808, 28/06/2022 [30] Quickdraw-Snort, https://github.com/digitalbond/Quickdraw-Snort, 29/06/2022 [31] Official Website of ASHRAE SSPC 135, http://www.bacnet.org/index.html, 22/06/2022 [32] Niagara AX Networking and IT Guide, https://www.lynxspring.com/documents/AX_Networking_IT_Guide.pdf, 22/06/2022 [33] FINS Commands Reference Manual, https://www.myomron.com/downloads/1.Manuals/Networks/W227E12_FINS_Commands_Reference_Manu al.pdf, 22/06/2022 [34] FINS Communications, https://paginas.fe.up.pt/~pfs/recursos/plcs/omron/cs1/eth_manual/sec5.pdf, 30/06/2022 [35] Digital Bond's ICS Enumeration Tools Redpoint, https://github.com/digitalbond/Redpoint, 30/06/2022 [36] Snort Descargas, https://www.snort.org/downloads, 04/07/2022 [37] Proofpoint Emerging Threats Rules, https://rules.emergingthreats.net/open/snort-2.9.0/, 04/07/2022 [38] ModScan, https://code.google.com/archive/p/modscan/, 01/07/2022 [39] An Internet-wide view of ICS devices, Mirian, Ariana, Zane Ma, David Adrian, Matthew Tischer, Thasphon Chuenchujit, Timothy M. Yardley, Robin Berthier, Joshua Mason, Zakir Durumeric, J. Alex Halderman and Michael Bailey, 2016, http://mdbailey.ece.illinois.edu/publications/pst2016_ics.pdf, 03/07/2022 [40] Portal de descargas Metasploit, https://www.metasploit.com/download, 05/07/2022 [41] Repositorio de Github del trabajo, https://github.com/pablobs2000/TFG-Snort-IDS, Pablo Benítez Sánchez, 12/07/2022 [42] Descripción IDS, https://www.incibe.es/protege-tu-empresa/blog/son-y-sirven-los-siem-ids-e-ips, 06/07/2022 133 Análisis de la capacidad de detección de Snort sobre ataques de red en ICS bajo la matriz MITRE ATT&CK