OSINT

Conceptos básicos de OSINT

Internet cuenta con mas de 2500 millones de usuarios a nivel mundial, cualquiera de ellos puede publicar algo en internet, la proliferación de las redes sociales en estos últimos años ha hecho que el número de información se haya visto incrementado exponencialmente.

• Google almacena información de 30 billones de páginas web, lo que supone más de 1.000 terabytes de información.
• Facebook tiene 2.100 millones de usuarios, 80 millones de páginas y 440.000 millones de fotos subidas a su página.
• Twitter tiene más de 1300 millones de usuarios activos que escriben diariamente más de 500 millones de tweets.

Sin embargo, no hay que olvidarse de la cantidad de datos disponibles también en la Deep Web aunque no se cuenta con cifras exactas y puede ser mas relevante la información que encontremos que con métodos convencionales

OSINT son las siglas en inglés de Open Source Intelligence y se refiere a un conjunto de técnicas y herramientas utilizadas para recopilar información pública, analizar datos y relacionarlos para convertirlos en conocimiento útil.

Usamos OSINT para tomar toda la información disponible de cualquier fuente pública sobre una empresa, individuo o cualquier otra cosa que queramos investigar y convertir toda esa acumulación de datos en inteligencia que nos ayude a lograr resultados oportunos de manera más eficiente.

OSINT se utiliza en muchos campos: finanzas, tecnología, policía, militar (donde se originó), marketing, etc. Si nos centramos en el ámbito técnico y más concretamente en la ciberseguridad, encontramos varios usos de este:

• Se utiliza en la etapa de reconocimiento de un pentesting: Descubrir hosts en una organización, información de Whois, encontrar subdominios, información de DNS, encontrar ficheros de configuración, passwords, etc…
• Se utiliza para tests de ingeniería social: Buscar toda la información sobre un usuario (en redes sociales, documentos, etc) y ser consciente de la información que hay disponible.
• Prevención de ciberataques: Obtener información que nos alerte de posibles amenazas a nuestra organización o posibles ciberataques.
• Marketing: es muy útil para obtener más información sobre el público potencial de un producto y personalizar las comunicaciones

Habilidades OSINT

Las habilidades OSINT son las capacidades y los conocimientos necesarios para recopilar, analizar y utilizar información de fuente abierta para una variedad de propósitos.

• Obtenga información sobre los diferentes tipos de código abierto, incluidos los sitios web públicos, las redes sociales y otros recursos en línea.
• Saber cómo acceder y utilizar varias herramientas y técnicas OSINT, como motores de búsqueda, analisis de redes sociales y de metadatos.
• Desarrollar la capacidad de analizar e interpretar datos de fuentes abiertas, incluida la identificación de patrones, tendencias y correlaciones.
• Crear una red de contactos y recursos que puedan proporcionar información y conocimientos valiosos.
• Capacidad para presentar hallazgos y conclusiones de manera clara, concisa y convincente.

Fases del Proceso OSINT

El proceso OSINT consta de las siguientes fases:

• Requisitos: es la fase en la que se establecen todos los requerimientos que se deben cumplir, es decir, aquellas condiciones que deben satisfacerse para conseguir el objetivo o resolver el problema que ha originado el desarrollo del sistema OSINT.
• Identificar fuentes de información relevante: consiste en especificar, a partir de los requisitos establecidos, las fuentes de interés que serán recopiladas. Hay que tener presente que el volumen de información disponible en Internet es prácticamente inabordable por lo que se deben identificar y concretar las fuentes de información relevante con el fin de optimizar el proceso de adquisición.
• Adquisición: etapa en la que se obtiene la información a partir de los orígenes indicados.
• Procesamiento: consiste en dar formato a toda la información recopilada de manera que posteriormente pueda ser analizada.
• Análisis: es la fase en la que se genera inteligencia a partir de los datos recopilados y procesados. El objetivo es relacionar la información de distintos orígenes buscando patrones que permitan llegar a alguna conclusión significativa.
• Presentación de inteligencia: consiste en presentar la información obtenida de una manera eficaz, potencialmente útil y comprensible, de manera que pueda ser correctamente explotada

Tipos de recopilaciones

1. Recopilación pasiva

La recopilación pasiva a menudo implica el uso de plataformas de inteligencia de amenazas (TIP) para combinar una variedad de fuentes de amenazas en una única ubicación de fácil acceso.

1. Recopilación activa

La recopilación activa es el uso de una variedad de técnicas para buscar información o conocimientos específicos. Para los profesionales de seguridad, este tipo de trabajo de recolección generalmente se realiza por una de dos razones:

• Una alerta recopilada pasivamente ha puesto de manifiesto una amenaza potencial y se requiere una mayor comprensión.
• El enfoque de un ejercicio de recopilación de inteligencia es muy específico, como un ejercicio de prueba de penetración.

Herramientas

Hay multitud de herramientas y servicios útiles a la hora de implementar un sistema OSINT. A continuación se mencionan algunos de ellos:

• Buscadores habituales: Google, Bing, Yahoo, Ask. Permiten consultar toda la información que indexan. Así mismo, permiten especificar parámetros concretos (Hacking con buscadores: por ejemplo «Google Hacking» o «Bing Hacking») de manera que se pueden realizar búsquedas con mucha mayor precisión que la que utilizan los usuarios habitualmente.

Algunos ejemplos son los siguientes:

Operador	Ejemplo de búsqueda en Google	Propósito
site	site:wikipedia.org	Buscar resultados dentro de un sitio específico
related	related:wikipedia.org	Buscar sitios relacionados
cache	cache:wikipedia.org	Buscar la versión del sitio en caché
intitle	intitle:wikipedia	Buscar en el título de la página
inurl	inurl:wikipedia	Buscar una palabra contenida en una URL
filetype:env	filetype:pdf	Buscar por tipos de archivo específicos
intext	intext:wiki	Buscar en el texto del sitio web solamente
“”	“Wikipedia”	Buscar palabra por coincidencia exacta
+	jaguar + car	Buscar más de una palabra clave
–	jaguar speed -car	Excluir palabras de la búsqueda
OR	jaguar OR car	Combinar dos palabras
	how to Wikipedia	Operador de comodín
imagesize	imagesize:320×320	Búsqueda de imágenes por tamaño
@	@wikipedia	Buscar en redes sociales
#	#wiki	Buscar hashtags
$	camera $400	Buscar un precio
..	camera $50..$100	Buscar dentro un rango de precios

• Buscadores especializados:
  • Shodan: Permite entre otras cosas localizar ordenadores, webcams, impresoras, etc. basándose en el software, la dirección IP, la ubicación geográfica, etc. Mediante este servicio es posible localizar información de interés
  • Knowem: es una herramienta que permite comprobar si un nombre de usuario está disponible en más de 550 servicios online. De este modo, se puede saber los servicios que utiliza un usuario en concreto, ya que habitualmente la gente mantiene dicho nombre para todos los servicios que utiliza. Además, disponen de una API que permite automatizar las consultas.
  • Tineye: es un servicio que, partiendo de una imagen, indica en qué sitios web aparece. Es similar a la búsqueda por imagen que incorpora Google Imágenes.
  • Buscadores de información de personas: permiten realizar búsquedas a través de diferentes parámetros como nombres, direcciones de correo o teléfonos. A partir de datos concretos localizan a usuarios en servicios como redes sociales, e incluyen posibles datos relacionados con ellos como números de teléfono o fotos. Algunos de los portales que incorporan este servicio son: Spokeo, Pipl, 123people o Wink.

• Herramientas de recolección de metadatos:
  • Metagoofil: permite la extracción de metadatos de documentos públicos (pdf, doc, xls, ppt, docx, pptx, xlsx). A partir de la información extraída se pueden obtener direcciones de correo electrónico del personal de una empresa, el software utilizado para la creación de los documentos y por tanto poder buscar vulnerabilidades para dicho software, nombres de empleados, etc.
  • FOCA: es un software de código abierto que permite a los usuarios analizar metadatos para determinar si una pagina web contiene documentos corruptos, soporta archivos tipo DOC,ODT,ODS,SVG y PPT
• Servicios para obtener información a partir de un dominio:
  • Spiderfoot es una herramienta de reconocimiento que consulta automáticamente más de 100 fuentes de datos públicas. Las usa para recopilar información sobre direcciones IP, nombres de dominio, direcciones de correo electrónico, nombres y más.
• Otras herramientas de interés:
  • GoBuster: Es una herramienta que por fuerza bruta es capaz de encontrar los subdominios de una web proporcionada por el usuario.
  • Theharvester : esta herramienta obtiene emails, subdominios, host, nombres de empleados, puertos abiertos, etc. a través de diferentes servicios como Google, Bing, LinkedIn y Shodan.
  • SiteDigger: al igual que GooScan permite automatizar búsquedas. Busca en la caché de Google para identificar vulnerabilidades, errores, problemas de configuración, etc.
  • Palantir: es una empresa que tiene como cliente a diferentes servicios del Gobierno de Estados Unidos (CIA, NSA y FBI) y que se centra en el desarrollo de software contra el terrorismo y el fraude, mediante la gestión y explotación de grandes volúmenes de información. ­
  • Maltego: permite visualizar de manera gráfica las relaciones entre personas, empresas, páginas web, documentos, etc. a partir de información pública.Para usar Maltego, se requiere el registro del usuario, el registro es gratuito. Una vez que los usuarios se registran pueden usar esta herramienta para crear la huella digital del objetivo en Internet.

Conclusión

Saber cómo extraer inteligencia de código abierto es una habilidad importante para cualquier persona involucrada en la ciberseguridad.

El factor más importante para el éxito de cualquier iniciativa de inteligencia de código abierto es la presencia de una estrategia clara: una vez que sepas lo que estás tratando de lograr y hayas establecido los objetivos en consecuencia, identificar las herramientas y técnicas más útiles será mucho más realizable.

Ya sea que esté protegiendo su red corporativa o investigando vulnerabilidades, cuanto más sepa sobre su huella digital, mejor podrá verla desde la perspectiva de un atacante.

Armado con este conocimiento, puede continuar desarrollando mejores estrategias de defensa y ataque.­

Kill Chain

Riesgos Cibernéticos y el Ciclo de vida del ataque

Prepararse para manejar incidentes requiere una planificación cuidadosa, una planificación más allá de la creación de un plan de respuesta a incidentes, manuales de estrategias y pruebas anuales o semestrales. Con tiempo y recursos limitados, tiene sentido centrar la atención en áreas en las que es probable que ocurran eventos de ciberseguridad. Saber dónde enfocarse se obtiene respondiendo las siguientes preguntas:

• ¿Qué riesgos invitan a los atacantes a la red?
• ¿Qué vectores de ataque es probable que se utilicen?

Dos herramientas importantes diseñadas para responder a estas preguntas son la evaluación del riesgo y el ciclo de vida del ataque de ciberseguridad desarrollado por Mandiant.

• La evaluación de riesgos establece los riesgos presentes en el entorno en el que es probable que ocurran eventos ciberseguridad.
• El ciclo de vida de un ataque de ciberseguridad describe el proceso que siguen los atacantes cuando buscan violar entidades y robar, modificar o destruir activos.

La evaluación y el análisis del riesgo de ciberseguridad implica varios elementos clave. Analizando adecuadamente riesgos para los activos digitales de la entidad requiere evaluar las amenazas y vulnerabilidades que es probable que estas amenazas exploten y analizar cada una en términos de la probabilidad de un ataque exitoso y el impacto para la entidad.

Ver estos riesgos en términos del ciclo de vida del ataque, anteriormente conocido como Kill Chain, genera un contexto en términos de las amenazas de un vector de ataque. Piense en ello como colocar el ciclo de vida del ataque encima de la evaluación de riesgos. Un actor de amenazas explota una vulnerabilidad para obtener un punto de apoyo inicial dentro de la entidad. Luego busca formas de explotar otros sistemas, aumentando sus privilegios, hasta alcanzar el objetivo. Priorizar el plan de respuesta a incidentes y los libros de jugadas asociados en torno a estos escenarios mejora la planificación y la preparación para posibles incidentes.

Documentación de riesgos cibernéticos

Evaluar los riesgos de ciberseguridad requiere seis actividades clave. Los primeros cuatro son la identificación de activos, la identificación de amenazas, la identificación de vulnerabilidades y la evaluación del riesgo inicial para los activos digitales en la entidad. El quinto paso es identificar los controles de seguridad, a veces denominados medidas, destinados a reducir los riesgos cibernéticos. El sexto paso mide el riesgo residual, el riesgo que permanece una vez que se identifica un control de seguridad cibernética y se mide la efectividad en la reducción del riesgo.

A continuación, dejamos un esquema de cómo se podría medir el riesgo:

Análisis de amenazas

Las amenazas, tanto los actores de amenazas como los escenarios de amenazas, son personas, grupos y eventos que aprovechan las debilidades de los sistemas de información de una organización para llevar a cabo actos dañinos. Estos actos apuntan a la confidencialidad, integridad y disponibilidad de los activos digitales.

Los ataques de ciberseguridad están dirigidos contra uno o más de los pilares que se muestran en imagen anterior. Ataques como la violación de un Ayuntamiento tienen como objetivo la confidencialidad de los datos. Los datos son accesibles por personas no autorizadas, ya sea que solo accedan o se eliminen.

Los ataques contra la integridad de los datos se producen cuando un actor de amenazas cambia los datos sin que los propietarios de los datos detecten estos cambios. Incluso cuando se detecta una brecha, estos ataques siguen siendo problemáticos, porque a veces es imposible saber qué datos cambiaron no siempre es una tarea fácil. Las operaciones del día a día requieren los datos precisos, por lo que cuando la integridad se ve comprometida, el rendimiento de los servicios se ve afectado.

Los ataques de disponibilidad incluyen ataques de denegación de servicio diseñados para bloquear servidores y otros dispositivos de red. Cuando las redes dejan de estar disponibles, los ingresos y las obligaciones contractuales pueden estar en riesgo. El ransomware es otro tipo de ataque de disponibilidad. Estos son comunes como se puede ver leyendo las noticias a diario. Siempre hay una gran empresa u organización víctima de este tipo de ataque.

Muchas veces, estos intentos tienen éxito cuando los atacantes explotan con éxito a los usuarios finales que, sin darse cuenta, lanzan malware diseñado para cifrar bases de datos y otros repositorios importantes.

Los atacantes esperan que las entidades víctimas paguen un rescate para desbloquear los datos. Si no se paga el rescate, los atacantes amenazan con destruir los datos. Es importante saber que existen copias de seguridad con integridad y que están listas para fines de restauración; de lo contrario, las organizaciones objetivo tienen opciones limitadas.

El último ejemplo de amenazas a la disponibilidad se incluye en los planes de continuidad del negocio y recuperación ante desastres. Eventos como inundaciones, terremotos y ataques terroristas provocan interrupciones en las operaciones comerciales y fuerzan la recuperación de las operaciones de IT en otros sitios geográficos de respaldo. Afortunadamente estas situaciones no suelen darse en España.

Los actores y escenarios de amenazas provocan incidentes que varían en clasificación desde molestos hasta perjudiciales. En casos severos, las amenazas provocan la pérdida de ingresos significativos durante varios años. 

Medición de la gravedad del riesgo

El riesgo se mide utilizando dos parámetros: probabilidad de que el riesgo sea explotado e impacto para la entidad si es explotado. Cada uno tiene sus propias consideraciones para la medición.

Probabilidad

La probabilidad establece las probabilidades de que una amenaza explote una vulnerabilidad. Esto se basa en varios factores:

• ¿Qué tan conocida es la vulnerabilidad públicamente?
• ¿Cuáles son las probabilidades de que los actores de amenazas conozcan y puedan encontrar la vulnerabilidad en el entorno de las organizaciones?
• ¿Qué habilidades o recursos especiales se requieren para administrar con éxito el exploit?
• ¿Vale la pena el esfuerzo por la vulnerabilidad?

Estas preguntas se utilizan para comprender y medir las vulnerabilidades en términos de probabilidad. Sin datos estadísticos significativos y herramientas actuariales, la probabilidad puede ser subjetiva. Estos tipos de evaluación de riesgos se conocen como cualitativos. El análisis utilizado para desarrollar la medición del riesgo no utiliza mediciones estadísticas. El uso de dichas herramientas permite que la evaluación de riesgos sea cuantitativa. Siempre que sea posible, una combinación de los dos tipos produce resultados en los que los beneficios superan los costos. Tanto las evaluaciones de riesgo cualitativas como cuantitativas utilizan una escala de uno a cinco, indicando cinco que la vulnerabilidad tiene una alta probabilidad de ser explotada.

Impacto

El impacto mide el daño causado a la entidad si se explota con éxito una vulnerabilidad.

Un exploit que otorga a un atacante acceso root a un sistema GNU/Linux o un administrador del sistema (SA) acceso a una base de datos SQL son exploits de alto impacto. Este acceso le da a un actor de amenazas la capacidad de hacer cualquier cosa que elija con el sistema y sus datos. Comprender el impacto es una función de varios factores:

• Los datos que procesa el sistema.
• Los privilegios expuestos a través del exploit.
• Capacidad para detectar el exploit o los movimientos del atacante después.
• Proximidad a datos de misión crítica.

Los tres primeros se explican por sí mismos. Si el exploit en cuestión existe en un sistema de salud (imagina un hospital por ejemplo o centro de salud). Los sistemas que procesan la información del paciente son entornos de alto impacto. Las cuentas de administrador tienen un alto impacto si los atacantes obtienen acceso a ellas. Otra consideración relacionada con el impacto es la detección. Si un atacante obtiene acceso, lo que le permite ejecutar comandos de PowerShell, por ejemplo, y las herramientas de detección no están presentes para detectar su uso, podría existir una situación de alto impacto. El último elemento, la proximidad a los datos de misión crítica, considera en qué parte del ciclo de vida del ataque el exploit introducidor por el atacante.

¿El atacante solo necesita encontrar una debilidad más para violar los datos de destino? Estas características se consideran al evaluar el impacto. El impacto también se mide muchas veces usando una escala de uno a cinco, donde cinco indica el mayor impacto.

La siguiente imagen muestra un mapa de calor, un ejemplo que usa la escala de uno a cinco para las calificaciones de probabilidad e impacto gestionado por Pilar utilizando metodología Magerit:

Usando el mapa de calor, un riesgo con un impacto muy alto y una probabilidad muy alta se considera muy alto. Los riesgos con calificaciones muy bajas en ambas categorías se Consideran muy bajos. Cualquier otra combinación de probabilidad e impacto se encuentra en algún punto intermedio.

Revisar la evaluación de riesgos

Una vez que se completa la evaluación de riesgos, se muestra visualmente el plan para planificar y anticipar cómo podría ocurrir una infracción. En la siguiente imagen, se muestra un ejemplo abreviado de un registro de riesgo producido durante la evaluación con la herramienta Pilar, vemos como muestra un riesgo alto, medio y bajo:

El alto riesgo documentado durante la evaluación indica que los empleados son susceptibles a los ataques de phishing. Una forma de reducir el nivel de riesgo es identificar un control de ciberseguridad. Para combatir a los usuarios finales vulnerables que son el objetivo de los ataques de phishing, un control de capacitación y concienciación identificado en el ENS se alinearía con este riesgo. La cantidad de reducción de riesgo, si la hay, depende de la madurez del proceso de control. Los controles inmaduros tienden a operar de manera ineficaz y, por lo tanto, no logran reducir la cantidad de riesgo. Durante la planificación de la respuesta a incidentes, el equipo se concentraría en prepararse para los ataques lanzados a través de correos electrónicos dirigidos a los empleados. Los libros de jugadas que describen las acciones necesarias para combatir las campañas de phishing, el malware y los ataques de ransomware son áreas de enfoque clave para las sesiones de práctica.

El riesgo medio ilustra las vulnerabilidades que los ataques de por ejemplo otros gobiernos y los ciberdelincuentes pueden explotar en aplicaciones web. Éste permite el acceso al entorno de una entidad. El equipo de respuesta a incidentes debe planificar ataques exitosos contra servidores web y comprender los libros de jugadas relevantes para contener un ataque de este tipo.

El bajo riesgo muestra que la entidad hace un trabajo efectivo manteniendo un inventario de activos de hardware y software. El equipo de respuesta a incidentes no tiene que dedicar tanto tiempo a planificar las respuestas debido a la pérdida de activos.

Estos tres ejemplos ilustran cómo el equipo de respuesta a incidentes puede analizar Escenarios en los que se inician eventos, incidentes y violaciones: riesgos críticos y altos primero, luego moderados según sea necesario y, finalmente, riesgos bajos. Es probable que los riesgos bajos no formen parte de la planificación de escenarios y que solo ciertos riesgos moderados/medios, dependiendo de la superposición con los riesgos críticos y altos, sean, por ejemplo, el riesgo medio debido a la explotación de aplicaciones web mal configuradas. Si existiera un alto riesgo debido a que se estaban usando bibliotecas de código desactualizadas, el riesgo de configuración podría ser redundante y no necesario para la planificación de incidentes. Los elementos del registro de riesgos deben evaluarse individualmente, pero deben tenerse en cuenta cuando estén presentes vectores de ataque comunes.

El ciclo de vida del ciberataque Mandiant

Un aspecto importante de la preparación de respuesta a incidentes es la planificación del juego. Los equipos deportivos profesionales y aficionados se preparan para los oponentes antes de las competencias. El propósito es comprender qué hace bien el adversario y qué debilidades se pueden explotar son piezas clave del rompecabezas. El ciclo de vida de un ciberataque creado por Mandiant, ilustra los pasos que realizan los atacantes contra las entidades, organizaciones, empresas, etc.

Romper el ciclo de vida

Se puede pensar que el ciclo de vida del ataque tiene tres fases:

1. El primero comienza con el reconocimiento inicial y termina una vez que se establece un punto de apoyo dentro de la red objetivo.
2. El segundo es un proceso iterativo de aumento de privilegios, realización de reconocimiento interno, movimiento lateral y mantenimiento de la persistencia.
3. La última fase es terminar el trabajo.

Fase uno

Los ataques que experimentan las entidades en el entorno actual no son golpes rápidos, en muchos casos.

Este conjunto inicial de actividades está diseñado para recopilar la mayor cantidad de información posible sobre el objetivo. Los atacantes a menudo saben más sobre la red de la que planean aprovecharse que las personas que trabajan diariamente en el sitio de la red objetivo.

Reconocimiento

Existen muchos métodos para llevar a cabo el reconocimiento. Existen herramientas de código abierto para que las utilicen los piratas informáticos, pero gran parte de la información recopilada está disponible públicamente. A continuación se enumeran las formas comunes en que los atacantes recopilan datos para usarlos contra sus objetivos y los beneficios de esta información:

• Shodan: Los atacantes pueden ver los puertos y servicios expuestos de nuestros servidores.
• DNS: Se puede realizar un reconocimiento sobre los dominios y subdominios de nuestra entidad u organización.
• Osint: Los atacantes pueden comprender la entidad, el personal, la tecnología utilizada y los problemas de personal.
• Recolección de correos: Una lista de objetivos en la entidad puede dar lugar a campañas masivas de Phishing que intentan explotar a un usuario final y obtener acceso

Dos formas comunes en las que las entidades se ven comprometidas son a través de ataques de phishing y la explotación de dispositivos mal configurados (más sobre esto en la siguiente sección). Los ataques exitosos son el resultado de una amplia inteligencia recopilada antes de que se lance cualquier método de ataque activo.

Compromiso inicial

Si un atacante puede engañar a los usuarios finales para que los dejen entrar en el entorno, se pueden eludir todos los controles de seguridad en el perímetro e internamente. Aprovechar configuraciones defectuosas en dispositivos expuestos a Internet es otra forma en que los atacantes intentan infiltrarse en las redes. Los actores de amenazas de hoy tienen la ventaja de contar con vastos recursos para aprovechar la inteligencia recopilada durante la etapa de reconocimiento. Si el método elegido es un ataque de phishing, los atacantes sabrán todo lo posible sobre el objetivo, tanto personal como profesional, para aumentar las posibilidades de éxito.

Establecer un punto de apoyo

Una vez dentro, se utiliza software malicioso para establecer un punto de apoyo en el entorno.

Los ataques de phishing exitosos conducen al control sobre un dispositivo de usuario final o credenciales robadas.

La explotación de aplicaciones web, por ejemplo, le da al adversario un nivel de acceso privilegiado que es útil. El objetivo requiere colocar una puerta trasera en el sistema, para que los atacantes puedan entrar y salir.

Fase dos

Esta fase es iterativa. En primer lugar, se cumplen los requisitos de escalada de privilegios. Estos privilegios se utilizan para realizar un reconocimiento del entorno interno y moverse lateralmente hacia el objetivo, manteniendo la persistencia. Cuando se presentan oportunidades para escalar aún más los privilegios, o se presentan privilegios a otros entornos, estas credenciales se utilizan para ejecutar nuevamente el reconocimiento interno, seguir moviéndose a través de la red y mantener la persistencia. Este ciclo continúa hasta que se logra la misión.

Elevación de privilegios

Una vez dentro, los atacantes quieren escalar los privilegios, primero investigando la máquina comprometida, para ver si existe alguna forma de escalar. La higiene ciberseguridad juega un papel en la limitación de la capacidad de los atacantes para aumentar los privilegios. Si las cuentas administrativas o de servicio predeterminadas son omnipresentes en el entorno, no es difícil para los grupos maliciosos comprometer una de estas cuentas para obtener privilegios elevados.

Reconocimiento interno

El reconocimiento interno consiste en investigar las conexiones a la máquina comprometida inicialmente y/o la máquina que actualmente controla a los atacantes. Es posible usar Nmap para descubrir conexiones. Depende de si el atacante piensa que existen capacidades de detección para alertar a la entidad del escaneo.

Mover lateralmente

Una vez que un atacante ingresa y mapea una disposición del terreno, es hora de moverse. La intención es encontrar credenciales con la capacidad de ingresar a los sistemas que albergan los datos a los que se dirige el atacante. Esto incluye acceder a máquinas que son literalmente movimientos laterales, lo que significa que no se produce una elevación de credenciales, y encontrar máquinas en las que existan credenciales elevadas.

Mantener la presencia

Los ataques se llevan a cabo durante varios meses o años. Algunas estadísticas informan un retraso de siete meses o más antes de la detección de intrusiones. Esto significa que los actores de amenazas van y vienen. Lo hacen mediante la implementación de una puerta trasera, lo que permite el acceso cuando existe el tiempo para continuar el ataque.

Una forma sencilla es mediante conexiones inversas. Los atacantes también usan rootkits, otras formas por ejemplo es dejando puertas traseras en los sistemas como otra forma de mantener la persistencia. Si las capacidades de monitoreo son inmaduras, habilitar este servicio facilita la reconexión y no son detectadas por la organización.

Fase tres: completa la misión

Esta es una fase de un solo paso. Una vez que el atacante ha encontrado lo que está buscando, lo siguiente es eliminar, cambiar o destruir los datos. Si el atacante quiere robar datos, los mueve por medios irregulares y en incrementos lo suficientemente pequeños como para no causar alarma.

Cómo ayuda esto

Usando lo anterior, el equipo de respuesta a incidentes desarrolla escenarios de amenazas. Lograr esto requiere pensar en varios puntos clave.

• Los atacantes apuntando a la entidad.
• Los métodos utilizados para realizar el ataque y completar la misión.
• Debilidades que explota.
• Debilidades similares dentro de la entidad.
• Acciones disponibles para reducir la probabilidad de éxito.
• Vincule la evaluación de riesgos y la cadena letal.

Dos formas comunes en las que se lanzaron ataques en los últimos años fueron a través de la explotación de los usuarios finales a través de ataques de phishing y la explotación de las debilidades de configuración en las aplicaciones web. Estos vectores de ataque representan las formas en que los atacantes ingresan inicialmente y establecen un punto de apoyo en las entidades. Estos riesgos, si son altos o medios, requieren un seguimiento y una evaluación constantes. La medición del nivel de riesgo de la vulnerabilidad del usuario final y la protección de las aplicaciones web para los cambios mantienen a la entidad alerta y enfocada en las formas comunes en que comienzan los eventos, incidentes e infracciones.

Formación y concienciación a los usuarios finales

Los ataques de phishing se utilizan para ingresar y establecer un punto de apoyo para el atacante o para liberar ransomware. A partir del ataque a Anthem, 2015 se convirtió en un año de grandes filtraciones, debido a ataques de phishing. Estos ataques se dirigieron a entidades sanitarias y capturó muchos titulares. El ataque de Anthem comenzó con un ataque de phishing selectivo bien diseñado dirigido a una persona con credenciales elevadas. El correo electrónico que inició la cadena de eventos llevó al objetivo a un dominio malicioso.

En España, llevamos años recibiendo ciberataques en varios sectores, si bien los titulares los ocupan las estafas del CEO o algún ransomware que ha cifrado algún Ayuntamiento, este tipo de ciberataque más sofisticado y dirigido no suele ocupar los titulares, pero no significa que no se esté dando. Lamentablemente la implantación del ENS va muy lenta y cuenta con el poco interés político, falta de medios y recursos, que de alguna forma convierten las entidades públicas españolas en blancos fáciles de todo tipo de organizaciones que podemos englobar como “atacantes”.

---

Conclusión

La planificación de respuestas a eventos de ciberseguridad es muy similar a la planificación de juegos en deportes o la planificación de batallas militares. Teniendo en cuenta cómo atacan los adversarios en función de sus métodos preferidos y qué debilidades existen en los sistemas de información, el equipo se centra en acciones específicas para aumentar la eficacia del programa de respuesta a incidentes.

Comprender qué riesgos existen para los activos es imprescindible. Discutir estos riesgos en términos de cómo los atacantes sofisticados se acercan a los objetivos ayuda al equipo a construir un programa integral destinado a prepararse para manejar eventos con el potencial de ocurrir.

Evidentemente, hace falta un equipo que esté al día, entrenado y con tiempo para investigar, aprender y estar siempre al día en este tipo de cosas. Eventos como el evento sevillano SecAdmin que se realiza una vez al año en el mes de noviembre en Sevilla son sitios clave para mantener a los equipos de respuesta de incidentes al día e informado de las últimas tendencias en ciberataques.

Disponer de bajos recursos, un equipo que no esté actualizado y sobre todo sin tiempo para probar, testear, hace que no funcione bien. En España, muchas veces se tiene la idea que un equipo de respuesta a incidentes es un equipo dormido, que no hace nada hasta que suenan las alarmas. Si esto fuera así, entonces ese equipo ha fracasado antes de empezar. No tendrá ensayado los procedimientos, no tendrá definido los roles y responsabilidades, y ante un incidente correrán de un sitio a otro sin mitigar ni solucionar nada.

Plan de respuesta a incidentes

Ya hemos hablando un poco y definido en qué consiste ese plan, quién lo debe llevar a cabo. Ahora vamos a centrarnos en los requisitos necesarios.

¿Toda organización puede tener su plan de respuesta a incidentes?

Requisitos previos

Antes de construir el programa de respuesta a incidentes, deben existir capacidades específicas. Como mínimo, estos deben incluir la adopción de un marco elegido; una comprensión de los activos que la entidad debe enfocarse en proteger; documentación de los riesgos a la confidencialidad, integridad y disponibilidad de los activos; y seguridad de que existen todas las capacidades de protección fundamentales.

Ejemplos de estas capacidades incluyen:

• Procesos de control de acceso y restricción de privilegios elevados 
• Protección contra el uso indebido de datos en movimiento, en uso y en reposo 
• Endurecimiento de herrajes, en base a estándares establecidos 
• Comprensión y gestión de vulnerabilidades 
• Existencia de protecciones de redes de comunicación y control (cortafuegos, etc)

Estableciendo las funciones de identificación y protección

La ciberseguridad es una función que siempre supone un coste, es decir, no se ve como un motor de ingresos para una organización. Rara vez se nota el programa de seguridad de la información cuando las cosas van bien. Los líderes de seguridad informática deben justificar continuamente los gastos de un programa y la necesidad de empleados a tiempo completo, etc. Es posible que una empresa nunca vea valor en la ciberseguridad hasta que se evite o mitigue con éxito una crisis. Lo más probable es que se culpe a la seguridad cuando se produce un incidente.

A pesar de estos desafíos, la seguridad informática debe superar estos desafíos para proteger los activos de una entidad. El primer paso es definir el programa de ciberseguridad a través del Esquema Nacional de Seguridad (ENS).

Programa de ciberseguridad definido

Para lograr el objetivo de la respuesta a incidentes, que es mitigar el impacto de eventos, incidentes y quiebres de seguridad, todo el programa de ciberseguridad debe operar de manera efectiva, no solo los programas de respuesta y recuperación. El programa debe estar impulsado por un propósito y una misión, comunicados a todos los miembros del equipo de ciberseguridad, que, a su vez, deben estar alineados y trabajar hacia los mismos objetivos.

La ciberseguridad protegerá incansablemente la información de nuestros usuarios mediante el establecimiento de capacidades efectivas y fundamentales de identificación de amenazas y la protección con capacidades de detección, respuesta y recuperación en caso de incidente.

Después de establecer el propósito y la misión, el programa se evalúa y mide para determinar la madurez y eficacia del estado actual. Medir el estado actual impulsa la hoja de ruta para cumplir con la misión. Usando un horizonte temporal de tres años, los objetivos anuales impulsan el programa. Crear responsabilidad sobre quién, qué, dónde, cuándo y cómo lograr los objetivos del programa; formación de subprogramas; y lograr la alineación con la misión de la organización. 

Un enfoque programático

La construcción de programas de ciberseguridad conduce a acciones de medición y mejora que continúan año tras año. El pensamiento de dominio podría conducir a centrarse en competencias y enfoques únicos para ciertas capacidades. La implementación de firewalls administrados por un ingeniero de seguridad podría hacer que algunos sientan que el perímetro de la red está suficientemente protegido. No se requiere ningún esfuerzo adicional para esta subcategoría. Los programas son continuos. Las iteraciones, ciclos o sprints (los términos no importan) ocurren con hitos definidos. Una vez que se cumplen esos hitos, se crean otros nuevos.

En términos de un programa de ciberseguridad, la esperanza es que los hitos se vuelvan más incrementales a medida que el programa madura.

 Identificación de programas

La subcategoría Tecnología de protección encaja lógicamente en un programa de protección de red. El líder del programa y el equipo deben concentrarse en garantizar que se implemente la tecnología fundamental. Las personas y los componentes del proceso mantienen los dispositivos configurados de acuerdo con las prácticas líderes seguras.

Los programas muy maduros rastrean métricas específicas y analizan cada una de acuerdo con criterios establecidos por la entidad, como los siguientes: ¿Se bloqueó el tráfico de manera incorrecta? ¿Se perdió el tráfico malicioso? ¿Se realizaron cambios de configuración sin aprobación o se encontraron configuraciones inseguras?

Estos datos se utilizan durante los ejercicios anuales de planificación y presupuesto para identificar mejoras en las personas, los procesos y la tecnología, para que el programa sea más efectivo. En un ambiente centrado en el programa, este ritual ocurre anualmente, para asegurar que el programa se mantenga encaminado para satisfacer las necesidades de la organización.

La siguiente imagen ilustra ejemplos de programas que las entidades pueden crear propuestas por el NIST.

Aquí en España, podemos encontrar el marco de referencia del ENS. Si se comparan los ítems, veremos que coinciden en su mayoría. Hay que recordar entonces que un programa de respuesta a incidentes es un componente esencial de un programa de ciberseguridad. Cada componente de framework sirve para hacer que los demás sean mejores y capaces de cumplir con los objetivos de la organización de ciberseguridad. Como se describió anteriormente un programa de respuesta a incidentes no cumplirá sus objetivos si los programas como la gestión de acceso, la protección de datos, la protección de la información y todos los demás no siguen una gestión de programa eficaz.

¿Cómo apoya cada programa la respuesta a incidentes?

La respuesta a incidentes, como programa, es vital para una entidad para que el daño de los ataques sea limitado. La respuesta a incidentes no es un programa independiente. Sin programas efectivos que lo respalden, existen capacidades limitadas para detectar, contener, erradicar y recuperarse rápidamente de las infracciones.

La siguiente imagen muestra ejemplos de cómo cada programa contribuye a la respuesta a incidentes.

Conclusiones

Antes de actuar según el deseo de crear el mejor programa de respuesta a incidentes de su clase, es necesario establecer las capacidades descritas en las funciones de identificación y protección del framework elegido, posiblemente el ENS. Estas funciones por ejemplo del ENS, como parte de los programas de ciberseguridad que respaldan el programa de respuesta a incidentes, deben ser fundamentalmente efectivas. Sin gobernanza, gestión de riesgos, gestión de activos, protección de red, gestión de amenazas, gestión de acceso, control de cambios, capacitación y concienciación, y continuidad del negocio/recuperación ante desastres, es casi imposible que el programa de respuesta a incidentes sea efectivo.

Cada uno de los programas descritos ejecuta actividades clave requeridas para que la respuesta a incidentes sea efectiva. Sin estos, el potencial de respuesta a incidentes para satisfacer las necesidades de la entidad es muy limitado.

Estrategia vs tácticas

Cuando la respuesta a incidentes está dirigida por personas técnicas, el programa corre el riesgo de atascarse en detalles tácticos y pierde la necesidad de una estrategia clara. El plan de respuesta a incidentes se basa en una estrategia de detección, contención y erradicación de intrusiones e infecciones antes del impacto en datos confidenciales y/u operaciones comerciales.

En la imagen anterior, se muestran dos formas de expresar este concepto. Las estrategias se construyen en torno a los activos de interés, pensando en los riesgos y escenarios de ataque que probablemente ocurran. En el análisis se incluyen capacidades fundamentales de protección y prevención, no solo medidas de detección y respuesta. Estas medidas se basan en casos de uso y se derivan de los escenarios de ataque identificados, para desplegar recursos y construir los objetivos estratégicos del plan de respuesta a incidentes.

El análisis y la revisión continuos se llevan a cabo a través de ejercicios de práctica y revisión de los eventos actuales. Las nuevas amenazas o inteligencia sobre los procesos, tácticas y técnicas (PPT) e indicadores de compromiso (IOC) de un atacante empujan al equipo a analizar estos datos en términos de activos afectados. El equipo debe comprender si las capacidades de protección, detección y respuesta son adecuadas. De lo contrario, los procesos alternativos o de compensación deben llenar el vacío.

Las tácticas, que vienen en forma de libros de jugadas (pensar en el ajedrez y sus diferentes estrategias de apertura), libros de ejecución o listas de verificación, describen las acciones específicas esperadas para un tipo de evento o incidente. Los libros de jugadas para ransomware, malware, acceso no autorizado, robo de datos y varios otros escenarios designan acciones específicas requeridas para cumplir con los objetivos del programa.

Cambiando la cultura

Para lograr el objetivo de crear un programa eficaz de respuesta a incidentes, pueden ser necesarios cambios en la forma en que la dirección, la tecnología de la información y el personal de ciberseguridad de la forma de cómo piensan sobre la respuesta a incidentes. Las pruebas anuales y la remediación como enfoque para la preparación de la respuesta se consideran suficientes. Este enfoque es utilizado por la mayoría de las entidades hoy en día.

Los auditores y reguladores también aceptan este enfoque al evaluar entidades. Los auditores de ciberseguridad consideran que esto es suficiente y rara vez cuestionan a los auditados sobre esta noción.

La dirección debe adoptar la respuesta a incidentes como un programa vital para los objetivos de la organización y apoyarlo con los recursos y el compromiso necesarios.

Con demasiada frecuencia, el CEO no considera la ciberseguridad como algo más que una función de costo o un mal necesario. A pesar de una mayor responsabilidad y escrutinio frente a las infracciones y la respuesta a las infracciones, poco parece cambiar.

Para combatir estos desafíos, la gestión eficaz del cambio organizacional es necesario. 

Conclusiones

La respuesta efectiva a incidentes define cómo las personas externas, los medios, los reguladores, los clientes y el público ven la competencia del equipo de seguridad cibernética y la entidad. Cuando los programas de respuesta a incidentes fallan, es por varias razones, principalmente por falta de:

• Liderazgo
• Preparación
• Ejecución

El liderazgo es la necesidad número uno y el impulsor de una respuesta exitosa a incidentes.

Los líderes deben asegurarse de que las personas adecuadas formen parte del equipo de respuesta, crear una cultura centrada en los comportamientos necesarios que conducen al éxito y mantener la calma frente a una tormenta. Los líderes no pueden perder el control de las emociones, permitir que los miembros del equipo actúen fuera de su rol en el equipo y desviarse del plan de respuesta a incidentes.

Debe haber una práctica constante, que va desde ejercicios de mesa completos hasta escenarios más pequeños utilizando libros de jugadas específicos. El objetivo es desarrollar la memoria muscular, ayudar a los miembros del equipo a sentirse cómodos con sus roles e infundir confianza en su capacidad para responder adecuadamente.

La migración de los enfoques tradicionales a la respuesta a incidentes, que se centra en ejercicios de simulación anuales, requiere un cambio en la forma en que la organización piensa sobre la preparación y respuesta a incidentes. Cambiar de manera efectiva los comportamientos hacia la respuesta a incidentes en todos los miembros de la entidad es el factor de éxito más importante para la respuesta a incidentes. respuesta.

La gestión de incidentes de seguridad

La gestión de ciberincidentes consta de varias fases. La fase inicial contempla la creación y formación de un Equipo de Respuesta a Ciberincidentes (ERC), y la utilización de las herramientas y recursos necesarios.

Durante esta fase de PREPARACIÓN, el organismo público, atendiendo a lo dispuesto en los Anexos I y II del ENS, y previo el correspondiente análisis de riesgos, habrá identificado y desplegado un determinado conjunto de medidas de seguridad.

La adecuada implantación de las antedichas medidas ayudará a detectar las posibles brechas de seguridad de los Sistemas de Información de la organización y su análisis, en la fase de DETECCIÓN, ANÁLISIS E IDENTIFICACIÓN, desencadenando los procesos de notificación a los que hubiere lugar.

La DETECCIÓN de la amenaza, una vez que ha penetrado en el organismo, puede ser realizada por el propio organismo y/o por las sondas desplegadas por el CCN-CERT, que generarán el correspondiente aviso.

La organización, en la fase de CONTENCIÓN, MITIGACIÓN Y RECUPERACIÓN del ciberincidente –y atendiendo a su peligrosidad- deberá intentar, en primera instancia, mitigar su impacto, procediendo después a su eliminación de los sistemas afectados y tratando finalmente de recuperar el sistema al modo de funcionamiento normal. Durante esta fase será necesario, cíclicamente, persistir en el análisis de la amenaza, de cuyos resultados se desprenderán, paulatinamente, nuevos mecanismos de contención y erradicación.

Tras el incidente, en la fase de ACTIVIDAD POST-CIBERINCIDENTE, los responsables del organismo emitirán un Informe del Ciberincidente que detallará su causa originaria y su coste (especialmente, en términos de compromiso de información o de impacto en los servicios prestados) y las medidas que la organización debe tomar para prevenir futuros ciberincidentes de naturaleza similar.

Puesto que no todos los ciberincidentes poseen las mismas características ni la misma peligrosidad, es necesario disponer de una taxonomía de los ciberincidentes, lo que ayudará posteriormente a su análisis, contención y erradicación.

Los factores que podemos considerar a la hora de establecer criterios de clasificación son, entre otros:

• Tipo de amenaza: código dañino, intrusiones, fraude, etc.
• Origen de la amenaza: Interna o externa.
• La categoría de seguridad de los sistemas afectados.
• El perfil de los usuarios afectados, su posición en la estructura organizativa de la entidad y, en su consecuencia, sus privilegios de acceso a información sensible o confidencial.
• El número y tipología de los sistemas afectados.
• El impacto que el incidente puede tener en la organización, desde los puntos de vista de la protección de la información, la prestación de los servicios, la conformidad legal y/o la imagen pública.
• Los requerimientos legales y regulatorios.

La combinación de uno o varios de estos factores es determinante a la hora de tomar la decisión de crear un ciberincidente o determinar su peligrosidad y prioridad de actuación.

La tabla siguiente muestra una clasificación de los ciberincidentes:

LA DETECCIÓN DE LOS CIBERINCIDENTES

No es fácil en todos los casos determinar con precisión si se ha producido o no un ciberincidente y, si es así, identificar su tipo y evaluar a priori su peligrosidad.

Básicamente, los indicios de que nos encontramos ante un ciberincidente pueden provenir de dos tipos de fuentes: los precursores y los indicadores. Un precursor es un indicio de que puede ocurrir un incidente en el futuro. Un indicador es un indicio de que un incidente puede haber ocurrido o puede estar ocurriendo ahora.

Algunos ejemplos de precursores son:

• Las entradas de log del servidor Web, con los resultados de un escáner de vulnerabilidades.
• El anuncio de un nuevo exploit, dirigido a una atacar una vulnerabilidad que podría estar presente en los sistemas de la organización.
• Amenazas explícitas provenientes de grupos o entidades concretos, anunciado ataques a organizaciones objetivo.

Los indicadores son muy comunes, tales como:

• El sensor de intrusión de una red emitiendo una alerta cuando ha habido un intento de desbordamiento de búfer contra de un servidor de base de datos.
• Las alertas generadas por software antivirus.
• La presencia de un nombre de archivo con caracteres inusuales.
• Un registro de log sobre un cambio no previsto en la configuración de un host.
• Los logs de una aplicación, advirtiendo de reiterados intentos fallidos de login desde un sistema externo desconocido la detección de un número importante de correos electrónicos rebotados con contenido sospechoso desviación inusual del tráfico de la red interna.

PELIGROSIDAD DE LOS CIBERINCIDENTES

Además de tipificar los ciberincidentes dentro de un determinado grupo o tipo, la gestión de los mismos (asignación de prioridades y recursos, etc.) exige determinar la peligrosidad potencial que el ciberincidente posee. Para ello, es necesario fijar ciertos “criterios” de Determinación de la Peligrosidad con los que comparar las evidencias que se disponen del ciberincidente, en sus estadios iniciales.

El cuadro siguiente muestra el Nivel de Peligrosidad de los Ciberincidentes, atendiendo a la repercusión que la materialización de la amenaza de que se trate podría tener en los sistemas de información de las entidades del ámbito de aplicación del ENS:

NIVEL DE IMPACTO DEL CIBERINCIDENTE EN LA ORGANIZACIÓN

El ENS señala que el impacto de un ciberincidente en un organismo público se determina evaluando las consecuencias que tal ciberincidente ha tenido en las funciones de la organización, en sus activos o en los individuos afectados.

El cuadro siguiente muestra cómo debe determinar el organismo afectado el Nivel de Impacto Potencial de los Ciberincidentes en la organización:

Los programas de respuesta a incidentes requieren priorización dentro de la seguridad ciberseguridad general el programa y la dirección deben ver la respuesta a incidentes como una función fundamental de la organización. Esto significa hacer más que escribir un plan de respuesta a incidentes y realizar un ejercicio de simulación una vez al año. Operar como una parte de un sistema, lo cual significa que la respuesta a incidentes se somete a revisiones y mejoras continuas de manera regular. El plan debe ser fluido, y cada evento, incidente e incumplimiento al que se responde es una oportunidad para analizar qué salió bien y qué oportunidades de mejora existen. Las pruebas frecuentes del programa y sus procesos producen una retroalimentación beneficiosa. Una hoja de ruta que describe la trayectoria del programa de respuesta a incidentes, desde el desarrollo inicial hasta el programa más maduro respaldado por procesos efectivos, impulsa los proyectos y acciones anuales.

La revisión de su análisis de riesgos, la documentación de otras infracciones y la referencia a recursos como el ciclo de vida de ataques de Mandiant facilitan la generación de escenarios de práctica. No se habla de práctica de alta tecnología. El equipo elige un escenario y luego recorre el proceso de análisis, clasificación y respuesta. Al final de cada recorrido, el equipo identifica lo que funciona y lo que no, y agrega las piezas que faltan en los libros de estrategias de respuesta.

En el peor de los casos, un liderazgo deficiente hace que eventos menos significativos creen más daño de lo esperado.

Sin dinero, un programa de respuesta a incidentes no puede funcionar. El programa requiere las mejores capacidades posibles de detección y respuesta que el presupuesto pueda sostener. Las capacidades incluyen componentes técnicos y personas para establecer y mantener procesos clave. La prevención de pérdida de datos (DLP), la detección y respuesta de punto final (EDR) y la capacidad de capturar paquetes completos, encabezados de flujo, encabezados y tráfico de flujo neto son ejemplos de capacidades tecnológicas.

Entidades de todos los tamaños utilizan a terceros para realizar investigaciones forenses. Estas entidades aportan sus propias herramientas al entorno. Cuanta más evidencia esté disponible para que la analice el equipo forense, mejor. El último elemento de financiación es el tiempo. Los participantes del programa necesitan tiempo para practicar lo siguiente:

• Los técnicos deben ensayar las respuestas a los distintos tipos de incidentes y realizar mejoras en los libros de jugadas.
• Los líderes deben ensayar escenarios y evaluar la toma de decisiones.
• El equipo ejecutivo debe ensayar cómo recibe información, evalúa el escenario y toma decisiones.

La práctica lleva tiempo. Lograr los resultados deseados requiere un compromiso de tiempo significativo. Se necesitan muchas sesiones de práctica para inculcar la capacidad de responder adecuadamente sin pensar demasiado. Un ejercicio teórico anual o semestral no es suficiente. El objetivo es garantizar que las tácticas del plan de respuesta estén arraigadas en el equipo, de modo que ciertas acciones se vuelvan automáticas. Sin práctica enfocada a la respuesta de incidentes el programa no crece ni se perfecciona.

Respuesta de incidentes

Introducción a la respuesta de incidentes

La respuesta a incidentes es la práctica de investigar y corregir campañas de ataque activas en una organización.

Cuando ocurre un ataque cibernético, pueden tener lugar múltiples actividades simultáneamente, y esto puede ser agitado cuando no hay coordinación o procedimientos adecuados de manejo de incidentes. Incluso hasta peligroso.

Sin embargo, prepararse con anticipación y establecer un plan y políticas de respuesta a incidentes claros y fáciles de entender permite que los equipos de seguridad trabajen en armonía. Esto les permite concentrarse en las tareas críticas que limitan el daño potencial a sus sistemas de TI, datos y reputación, además de evitar interrupciones comerciales innecesarias.

Y, sobre todo, lo más importante, cada equipo sabe qué tiene que hacer y cómo hacerlo.

Por tal motivo, tampoco está demás planificar simulacros, donde poner a prueba los protocolos frente a un incidente de seguridad.

Lo primero: Preparar un plan de respuesta a incidentes

Un plan de respuesta a incidentes documenta los pasos a seguir en caso de un ataque o cualquier otro problema de seguridad. Digamos que es el mapa, que debe seguir los responsables de los equipos de seguridad, cuando todo es un caos y la organización está en shock.

Digamos que el peor escenario que podría darse, se dio.  Si bien los pasos reales pueden variar según el entorno, un proceso típico, basándonos en un marco de referencia como el de SANS (SysAdmin, Auditoría, Red y Seguridad), incluirá los siguientes pasos: preparación, identificación, contención, eliminación, recuperación, notificación del incidente y revisión de incidentes.

Flujo del proceso de respuesta a incidentes (basado en la plantilla NIST) Imagen NIST

La preparación incluye el desarrollo de un plan con información relevante y los procedimientos reales que seguirá el equipo de respuesta a incidentes informáticos (CIRT) para abordar el incidente.

Éstos incluyen:

• Definir los equipos e individuos específicos que son responsables de cada paso del proceso de respuesta a incidentes.
• Definir lo que constituye un incidente, incluido lo que justifica qué tipo de respuesta.
• Datos y sistemas críticos que requieren más protección y resguardo.
• Una forma de preservar los estados afectados de los sistemas afectados con fines forenses.
• Procedimientos para determinar cuándo y a quién notificar sobre un problema de seguridad. Cuando ocurre un incidente, puede ser necesario informar a los usuarios afectados, clientes, personal policial, etc. pero esto diferirá de una industria y un caso a otro.

Un plan de respuesta a incidentes debe ser fácil de entender e implementar, así como alinearse con otros planes y políticas de la organización. Sin embargo, la estrategia y el enfoque pueden diferir entre diferentes industrias, equipos, amenazas y daños potenciales. Las pruebas y actualizaciones periódicas garantizan que el plan sea válido y eficaz.

Pasos a seguir un equipo de respuesta a incidentes

Una vez que hay un incidente de seguridad, los equipos deben actuar de manera rápida y eficiente para contenerlo y evitar que se propague a los sistemas limpios. Las siguientes son las mejores prácticas para abordar problemas de seguridad. Sin embargo, estos pueden diferir según el entorno y la estructura de una organización.

El equipo de respuesta a incidentes informáticos

Dentro del caos, es importante asegurarse de que el equipo “multidisciplinario de CIRT”, interno o externo, cuente con las personas adecuadas con las habilidades y la experiencia adecuadas. Y la única forma de cumplir con esto es definiendo las competencias y equipos antes del incidente.

Otra cosa no menos importante es seleccionar un líder de equipo que será la persona focal para dar dirección y asegurarse de que la respuesta vaya de acuerdo con el plan y los plazos. El líder también trabajará de la mano con la dirección y especialmente cuando haya decisiones importantes que tomar en cuanto a las operaciones. Por lo que las características del líder deberán de ser muy concretas con la habilidad de hablar hacia la dirección con un lenguaje menos técnico pero que represente la situación actual. Una persona segura, que trasmita confianza y seguridad.

Identificación del incidente y establecer el tipo y origen del ataque.

Por lo general, todas las empresas tienen previamente identificado y clasificado una serie de incidentes, con sus respectivas respuestas. Por lo que los incidentes menores, serán identificados, que no van a requerir la actuación del CSIRT.

Aquí hay una muestra de cómo podría ser una tabla con una clasificación de los ciberincidentes. En algunas empresas, añaden una columna más para indicar los equipos y tipo de respuesta que requiere cada clasificación.

Una vez tenemos nuestra tabla realizada, estaremos preparados para ante cualquier signo de amenaza, el equipo de RI sabrá como actuar con rapidez para verificar si realmente se trata de un problema de seguridad, ya sea interno o externo, al mismo tiempo que se asegura de contenerlo lo más rápido posible. Las formas típicas de determinar cuándo hay un problema incluyen, entre otras:

• Alertas de herramientas de monitoreo de seguridad, mal funcionamiento dentro de los sistemas, comportamientos inusuales, modificaciones de archivos inesperadas o inusuales, copias o descargas, etc.
• Informes de usuarios, administradores de sistemas o redes, personal de seguridad o socios o clientes externos externos.
• Registros de auditoría con signos de comportamiento inusual del usuario o del sistema, como múltiples intentos fallidos de inicio de sesión, descargas de archivos grandes, uso elevado de memoria y otras anomalías.

Evaluar y analizar el impacto del ataque

El daño que causa un ataque varía según su tipo, la eficacia de la solución de seguridad y la velocidad a la que responde el equipo. La mayoría de las veces, no es posible ver el alcance del daño hasta después de resolver por completo el problema. El análisis debe averiguar el tipo de ataque, su impacto y los servicios que podría haber afectado.

Se considera una buena práctica buscar cualquier rastro que pueda haber dejado el atacante y recopilar la información que ayudará a determinar la línea de tiempo de las actividades. En esta línea es bueno que, durante la planificación del equipo de respuesta a incidente, se verifique que la organización cuenta con sistemas de monitorización que en caso de incidente, puedan dar información que ayude a esclareces el suceso. Por ejemplo un recolector de logs siempre es bienvenido ante un incidente. Tener logs de toda la red implica analizar todos los componentes de los sistemas afectados, captando información relevantes para un análisis forense y determinar qué pudo haber sucedido en cada etapa.

Según la extensión del ataque y los hallazgos, puede ser necesario escalar la incidencia al equipo forense.

Contención, eliminación de amenazas y recuperación

La fase de contención incluye bloquear la propagación del ataque y restaurar los sistemas al estado de operación inicial. Idealmente, el equipo CIRT debería identificar la amenaza y la causa raíz, eliminar todas las amenazas bloqueando o desconectando los sistemas comprometidos, limpiando el malware o virus, bloqueando a los usuarios maliciosos y restaurando los servicios.

También deben establecer y abordar las vulnerabilidades que los atacantes explotaron para evitar futuras ocurrencias de las mismas. Una contención típica implica medidas a corto y largo plazo, así como una copia de seguridad del estado actual.

Antes de restaurar una copia de seguridad limpia o limpiar los sistemas, es importante mantener una copia del estado de los sistemas afectados. Esto es necesario para preservar el estado actual, que puede ser útil cuando se trata de análisis forense. Una vez respaldada, el siguiente paso es la restauración de los servicios interrumpidos. Los equipos pueden lograr esto en dos fases:

• Verificar los sistemas y los componentes de la red para comprobar que todos funcionen correctamente
• Volver a verificar todos los componentes que estaban infectados o comprometidos y luego limpiados o restaurados para asegurarse de que ahora estén seguros, limpios y operativos.

Notificación y denuncia

El equipo de respuesta a incidencias realiza el análisis, responde e informa. Necesitan explorar la causa raíz del incidente, documentar sus hallazgos sobre el impacto, cómo resolvieron el problema, la estrategia de recuperación mientras pasan la información relevante a la administración, otros equipos, usuarios y proveedores externos.

Comunicaciones con agencias y proveedores externos  

Si el incidente afecta a datos sensibles o de carácter personal, recordar que notificar a las autoridades (AEPD) o la que corresponda en un plazo inferior a las 72 horas una vez detectado el incidente, además de otras autoridades legales. Por lo que  el equipo debe iniciar este proceso, además de contar con un equipo de comunicación, para atender los medios de prensa, clientes, para comunicar de forma coordinada y responsable los detalles del incidente. Por este motivo es necesario seguir los procedimientos establecidos en su política de TI.

Por lo general, un ataque da como resultado el robo, el uso indebido, la corrupción u otra actividad no autorizada de datos sensibles como información confidencial, personal, privada y comercial. Por este motivo, es fundamental informar a los afectados para que puedan tomar precauciones y proteger sus datos críticos, como información financiera, personal y otra información confidencial.

Por ejemplo, si un atacante logra acceder a las cuentas de los usuarios, los equipos de seguridad deben notificarles y pedirles que cambien sus contraseñas. Y abrir una investigación para determinar la gravedad del incidente.

Realizar una revisión posterior al incidente

La resolución de un incidente también ofrece lecciones aprendidas, y los equipos pueden analizar su solución de seguridad y abordar los vínculos débiles para prevenir un incidente similar en el futuro. Algunas de las mejoras incluyen la implementación de mejores soluciones de seguridad y monitoreo para amenazas internas y externas, informando al personal y a los usuarios sobre amenazas de seguridad como phishing, spam, malware y otras que deben evitar.

Otras medidas de protección son ejecutar las herramientas de seguridad más recientes y efectivas, parchear los servidores, abordar todas las vulnerabilidades en las computadoras cliente y servidor, etc.

Estudio de caso de respuesta a incidentes del NIC Asia Bank de Nepal

Una capacidad de detección o una respuesta inadecuadas pueden provocar daños y pérdidas excesivos. Un ejemplo es el caso del NIC Asia Bank de Nepal, que perdió y recuperó algo de dinero después de un compromiso del proceso comercial en 2017.Los atacantes pusieron en peligro el SWIFT y transfirieron fondos fraudulentamente del banco a varias cuentas en el Reino Unido, Japón, Singapur y los EE. UU. .

Afortunadamente, las autoridades detectaron las transacciones ilegales pero solo lograron recuperar una fracción del dinero robado. Si hubiera habido un mejor sistema de alerta, los equipos de seguridad habrían detectado el incidente en una etapa anterior, tal vez antes de que los atacantes tuvieran éxito en el compromiso del proceso comercial.

Dado que se trataba de un problema de seguridad complejo que involucraba a otros países, el banco tuvo que informar a las autoridades policiales y de investigación. Además, el alcance estaba más allá del equipo interno de respuesta a incidentes del banco y, por lo tanto, la presencia de equipos externos, el banco central y otros.

Una investigación forense realizada por equipos externos de su banco central estableció que el incidente pudo haber sido por negligencia interna que expuso sistemas críticos.

Según un informe, los entonces seis operadores habían utilizado la computadora del sistema SWIFT dedicada para otras tareas no relacionadas. Esto puede haber expuesto el sistema SWIFT, lo que permitió a los atacantes ponerlo en peligro. Después del incidente, el banco transfirió a los seis empleados a otros departamentos menos sensibles.

Lecciones aprendidas: El banco debería haber implementado un sistema de vigilancia y alerta además de crear una conciencia de seguridad adecuada entre los empleados y hacer cumplir políticas estrictas.

Conclusión

---

Una respuesta a incidentes bien planificada, un buen equipo y las herramientas y prácticas de seguridad relevantes brindan a su organización la capacidad de actuar con rapidez y abordar una amplia gama de problemas de seguridad. Esto reduce los daños, las interrupciones del servicio, robo de datos, pérdida de reputación y posibles responsabilidades.

Reversing

Citando wikipedia: “La ingeniería inversa es el proceso llevado a cabo con el objetivo de obtener información o un diseño a partir de un producto, con el fin de determinar cuáles son sus componentes y de qué manera interactúan entre sí y cuál fue el proceso de fabricación.”

¿Qué utilidades tiene el reversing?

Si bien uno de los usos más conocidos es la detección de vulnerabilidades y el análisis de malware en el ámbito de la seguridad informática, también existen otros motivos del uso del reversing.

• Las más comunes son las siguientes:
• Descifrar algoritmos criptográficos
• Agregar funcionalidades
• Análisis de malware
• Testing del software
• Detección de vulnerabilidades

¿Por dónde empezar?

Es importante conocer los fundamentos y para ello hay que remontarse a la base. Si bien podemos empezar por técnicas de forma directa y aplicar ciertas “metodologías” a la hora de realizar reversing, es necesario tener una buena base, ya que sin la misma nos costará mucho avanzar y pensar de forma creativa a la hora de intentar resolver las problemáticas que nos puedan aparecer cuando aplicamos ingeniería inversa.

Existe mucha información al respecto relativa al reversing, por lo que aquí nos enfocaremos en explicar toda esta información de forma resumida y comprensible para todo el mundo. Se hablará desde compiladores, estructuras de los propios ejecutables, programación a bajo nivel (ASM, C, etc), arquitecturas de hardware entre otras.

En 1954 se empezó a desarrollar un lenguaje que permitía escribir fórmulas matemáticas de manera traducible por un ordenador; lo llamaron FORTRAN (FORmulae TRANslator). Fue el primer lenguaje de alto nivel y se introdujo en 1957 para el uso de la computadora IBM modelo 704.

Surgió así por primera vez el concepto de un traductor como un programa que traducía un lenguaje a otro lenguaje. En el caso particular de que el lenguaje que se ha de traducir es de alto nivel y el lenguaje traducido, de bajo nivel, se emplea el término compilador. La tarea de hacer un compilador no fue fácil. El primer compilador de FORTRAN tardó 18 años en desarrollarse. Esto deja de manifiesto la cantidad de investigación que se necesitó realizar para poder llegar a un producto final, un compilador completo, por sencillo que fuera su lenguaje. Toda esta investigación aportó la gran parte de teoría, técnicas y herramientas utilizadas hoy en día en los campos de lenguajes y autómatas. Los compiladores permiten escribir código fuente en lenguajes de alto nivel, es decir, en lenguajes no dependientes de la arquitectura del ordenador en el que se ejecute, así como que el lenguaje sea fácilmente interpretable por un ser humano, lejos de ser una lista de comandos secuenciales, como venía siendo el lenguaje ensamblador u otros lenguajes de bajo nivel.

Los lenguajes de alto nivel han permitido un desarrollo exponencial de software que se adapta a las necesidades de los usuarios y funcionan sin prácticamente cambios en diferentes arquitecturas y tipos de ordenadores. Esta ventaja, junto con otras, como la reutilización de código y disciplinas como la ingeniería de software, nos han llevado a los complejos programas informáticos con entornos visuales de escritorio, así como efectos gráficos y videojuegos en 3D en tiempo real, el desarrollo de complejos sistemas de comunicaciones que llevaron a la creación y utilización en masa de Internet o la capacidad de llevar a cabo software con finalidades matemáticas, médicas o de otros sectores y que nos permiten realizar grandes obras de ingeniería, bioingeniería, química o análisis y diagnósticos médicos, así como muchas otras utilidades del software.

Programa fuente

Este código escrito en un lenguaje de alto nivel, en concreto, C++, calcula el área de un triángulo de forma muy sencilla, solicita una serie de argumentos introducido por el usuario por línea de comandos y luego muestra un mensaje con el resultado, o salir con un mensaje de error si no hubiera argumento.

Como se puede observar en la figura, este código de alto nivel permite no solo la utilización de variables con nombre a la libre elección del programador, sino el empleo de comentarios sobre el código, así como la indentación del texto. Estas características facilitan la lectura a las personas, aunque no tenga ninguna trascendencia respecto al código máquina que se ha de generar.

También se puede observar la utilización de estructuras de código, como pueden ser las funciones, que ayudan a la reutilización de código y a su abstracción, pudiendo construir código centrándose en lo particular, para ir resolviendo problemas más generales, además de poder realizar invocaciones recursivas sin necesidad de llevar el control de manera explícita.

Estas facilidades y la proximidad del código fuente al lenguaje natural permiten al desarrollador centrarse en “el qué” debe hacer el software en lugar de en “el cómo” debe implementarlo para que funcione en una máquina con una arquitectura u ordenador en concreto.

Programa objeto / Código ensamblador

Una vez que el compilador ha desarrollado todas las etapas y conseguido generar un código objeto correcto y operativo, se convierte en un código objeto, por lo general, código ensamblador. El lenguaje ensamblador es la representación más cercana al código máquina. La siguiente captura muestra el código ensamblador, que compone el programa objeto, de un programa similar al visto anteriormente del cálculo de un área.

Mnemónico

En informática, un mnemónico o nemónico es una palabra que sustituye a un código de operación (lenguaje de máquina), con lo cual resulta más fácil la programación, es de aquí de donde se aplica el concepto de lenguaje ensamblador.

Un ejemplo común de mnemónico es la instrucción MOV (mover), que le indica al microprocesador que debe asignar datos de un lugar a otro. El microprocesador no entiende palabras, sino números binarios, por lo que es necesaria la traducción del término mnemónico a código objeto.

En muchas ocasiones se puede tomar a nivel de usuario como las teclas de acceso rápido que vemos en las ventanas, por ejemplo en un navegador encontramos el menú típico que dice Archivo, Editar, Ver, entre otras opciones, el mnemónico sería el valor de la letra que esta subrayada, así si presionamos la tecla alt y luego por ejemplo la A, se nos abrirá el menú de archivo, es por esta razón que se puede decir que la A en el menú resulta la tecla mnemónica de Archivo, o la tecla de acceso rápido a la opción Archivo.

El lenguaje Mnemónico también es utilizado en la programación de controladores lógicos programables (PLC), haciendo más rápida y eficiente la construcción de programas de alta complejidad.

Instrucción

Como se puede apreciar, existen varias diferencias en cuanto a los mnemónicos y operandos, tal y como se puede ver en la siguiente instrucción expresada en ambas sintaxis:

Hay varios tipos de instrucciones, en este caso dejamos la tabla de esamblador de Intel para procesadores 80186 o superiores. Pero también lo hay para procesadores AT&T, entre otros.

Etiquetas

Además de las instrucciones, se puede observar cómo hay etiquetas dentro del código a modo de localizaciones, que se utilizan para las bifurcaciones de código necesario:

Estas etiquetas son traducidas por direcciones de memoria relativas en la fase de construcción del binario final.

Como se puede apreciar en esta captura, podemos ver claramente no solo las etiquetas sino la estructura de un lenguaje ensamblador.

Un programa consta de varias partes diferenciadas. La palabra .data es una directiva y comunica al ensamblador que a continuación se define un conjunto de datos. El programa tan sólo tiene un único dato que se representa como una secuencia de caracteres. La línea .asciz, también una directiva, seguida del string entre comillas es la que instruye al ensamblador para crear una zona de memoria con datos, y almacenar en ella el string que se muestra terminado por un byte con valor cero. Nótese que el efecto de la directiva .asciz no se traduce en código sino que son órdenes para que el ensamblador haga una tarea, en este caso almacenar un string en memoria.

Antes de la directiva .asciz se incluye la palabra dato seguida por dos puntos. Esta es la forma de definir una etiqueta que luego se utilizará en el código para acceder a estos datos.

La línea siguiente contiene la directiva .text que denota el comienzo de la sección de código. Nótese que todas las directivas tienen como primer carácter un punto. La línea con la directiva .globl main comunica al ensamblador que la etiqueta con nombre main será globalmente accesible desde otro programa.

A continuación, se encuentran las instrucciones en ensamblador propiamente dichas. Se pueden ver las instrucciones push parar almacenar un operando en una zona específica de memoria que se denomina la pila.

Al comienzo del código se define la etiqueta main. Esta etiqueta identifica la posición en por la que el procesador va a empezar a ejecutar. Hacia el final del código se puede ver una segunda etiqueta con nombre done.

Una vez creado el fichero de texto con el editor y guardado con el contenido de la figura superior y con nombre miprograma.s, se ejecuta el compilador. Para ello primero es preciso arrancar una ventana con el intérprete de comandos y estando situados en el mismo directorio en el que se encuentra el fichero miprograma.s ejecutar el comando:

gcc -o miprograma miprograma.s

También tienes un emulador en javascript en esta web assembler-simulator donde poder probar código.

Una vez que el código objeto ha sido generado, entran en juego otras herramientas fuera del alcance del compilador, como son el ensamblador y el enlazador de códigos objeto. El ensamblador genera código binario partiendo del programa en lenguaje ensamblador. Es decir, traduce los mnemónicos en los códigos binarios correspondientes. Por otro lado, el enlazador de códigos objeto se encarga de obtener los códigos objeto requeridos por el código objeto en cuestión de las librerías disponibles. Una vez que tiene todas las piezas necesarias, genera un fichero final ejecutable o en forma de librería del sistema.

Conceptos básicos sobre reconstrucción de código

En el tema anterior profundizamos en el proceso de compilación, que convierte el código fuente, escrito en un lenguaje estructurado de alto nivel y fácilmente comprensible por una persona, en código objeto escrito en lenguaje máquina, para la arquitectura escogida y directamente ejecutable.

Ahora conocemos los conceptos básicos sobre diseño, análisis e implementación de lenguajes, así como los detalles sobre las fases por las que pasa un compilador, las técnicas utilizadas para generar y optimizar el código objeto y, en definitiva, todo lo relacionado con el proceso de compilación que genera código objeto partiendo de código fuente.

Ya sabemos cómo el compilador convierte el código fuente a código intermedio, utilizando este finalmente para traducirlo a código máquina de manera directa, tal como se puede apreciar en la siguiente imagen.

Proceso inverso

Tal como hemos visto antes, si podemos realizarlo en un sentido, también podríamos de alguna forma hacer el proceso inverso, pudiendo generar código fuente a partir del código objeto en lenguaje máquina.

Esta labor sí es posible en gran medida, aunque se deben tener en cuenta algunas las limitaciones. En este tema, vamos a referirnos como “Reconstrucción de código” al proceso inverso al que hemos estado estudiando en el tema anterior. Es decir, al proceso de obtener el código fuente a partir del código objeto. Debido a las limitaciones mencionadas, no será posible obtener comentarios, ni nombre de variables, tal y como las describió el desarrollador, puede que ni tan siquiera con el tipo ni el tamaño exacto con el que este lo hizo.

No obstante, sí se va a poder obtener una estructura de código que cumple con bastante exactitud con el comportamiento del programa fuente. Para ello, es necesario conocer las estructuras que el compilador maneja, y con las que traduce el código fuente a código objeto. De esta forma, podremos identificar estas estructuras en el código objeto y ser traducidas a código fuente. Esta traducción depende de:

• Arquitectura (INTEL, ARM, x86,etc)
• Optimizaciones que pueda sufrir el código

Resumiendo

Si bien ya hemos visto lo fundamental para comprender el mundo de los compiladores, lo que nos resultaba útil para comprender como se construyen los binarios que queremos analizar; ahora es el momento de empezar a comprender las estructuras de datos que nos podemos encontrar a la hora de reconstruir el código fuente partiendo del desemsamblado.

Haciendo un poco de memoria respecto a las fases de compilación, podemos observar en las últimas fases de “Generación de código intermedio”, “Optimización” y “Generación de código” que la idea de reconstrucción del código sería volver al proceso del “código intermedio”.

Debemos tener claro que existen limitaciones cuando volvemos del código final al código intermedio, como la perdida de comentarios del programador, nombres reales de las variables, tipo de variables, el tamaño, etc.

Para poder identificar todas estas estructuras de datos y comprender el código, trataremos aquí como identificarlas manualmente, dependiendo de la arquitectura del código (x86, x86_64, arm, …) y las optimizaciones aplicadas por el compilador.

Cuando tengamos identificadas las estructuras de datos, podremos darles nombres a las mismas mediante nuestro software de ingeniería inversa (radare2, IDA, papel y lápiz? ) para así poder reversear sin volvernos locos y dejar invertir más esfuerzo mental en algo que no merece la pena por no apuntarlo o nombrar las cosas, pudiendo dejar ese esfuerzo en pensar las estructuras mentalmente y al vuelo, en tratar otras cosas más relevantes del reversing, como la lógica de programación del propio código a analizar.

Las estructuras de datos que vamos a analizar serán las típicas del lenguaje de programación C.

versing?

Citando wikipedia: “La ingeniería inversa es el proceso llevado a cabo con el objetivo de obtener información o un diseño a partir de un producto, con el fin de determinar cuáles son sus componentes y de qué manera interactúan entre sí y cuál fue el proceso de fabricación.”

¿Qué utilidades tiene el reversing?

Si bien uno de los usos más conocidos es la detección de vulnerabilidades y el análisis de malware en el ámbito de la seguridad informática, también existen otros motivos del uso del reversing.

• Las más comunes son las siguientes:
• Descifrar algoritmos criptográficos
• Agregar funcionalidades
• Análisis de malware
• Testing del software
• Detección de vulnerabilidades

¿Por dónde empezar?

Es importante conocer los fundamentos y para ello hay remontarse a la base. Si bien podemos empezar por técnicas de forma directa y aplicar ciertas “metodologías” a la hora de realizar reversing, es necesario tener una buena base, ya que sin la misma nos costará mucho avanzar y pensar de forma creativa a la hora de intentar resolver las problemáticas que nos puedan aparecer cuando aplicamos ingeniería inversa.

Existe mucha información al respecto relativa al reversing, por lo que aquí nos enfocaremos en explicar toda esta información de forma resumida y comprensible para todo el mundo. Se hablará desde compiladores, estructuras de los propios ejecutables, programación a bajo nivel (ASM, C, etc), arquitecturas de hardware entre otras.

En 1954 se empezó a desarrollar un lenguaje que permitía escribir fórmulas matemáticas de manera traducible por un ordenador; lo llamaron FORTRAN (FORmulae TRANslator). Fue el primer lenguaje de alto nivel y se introdujo en 1957 para el uso de la computadora IBM modelo 704.

Surgió así por primera vez el concepto de un traductor como un programa que traducía un lenguaje a otro lenguaje. En el caso particular de que el lenguaje que se ha de traducir es de alto nivel y el lenguaje traducido, de bajo nivel, se emplea el término compilador. La tarea de hacer un compilador no fue fácil. El primer compilador de FORTRAN tardó 18 años en desarrollarse. Esto deja de manifiesto la cantidad de investigación que se necesitó realizar para poder llegar a un producto final, un compilador completo, por sencillo que fuera su lenguaje. Toda esta investigación aportó la gran parte de teoría, técnicas y herramientas utilizadas hoy en día en los campos de lenguajes y autómatas. Los compiladores permiten escribir código fuente en lenguajes de alto nivel, es decir, en lenguajes no dependientes de la arquitectura del ordenador en el que se ejecute, así como que el lenguaje sea fácilmente interpretable por un ser humano, lejos de ser una lista de comandos secuenciales, como venía siendo el lenguaje ensamblador u otros lenguajes de bajo nivel.

Los lenguajes de alto nivel han permitido un desarrollo exponencial de software que se adapta a las necesidades de los usuarios y funcionan sin prácticamente cambios en diferentes arquitecturas y tipos de ordenadores. Esta ventaja, junto con otras, como la reutilización de código y disciplinas como la ingeniería de software, nos han llevado a los complejos programas informáticos con entornos visuales de escritorio, así como efectos gráficos y videojuegos en 3D en tiempo real, el desarrollo de complejos sistemas de comunicaciones que llevaron a la creación y utilización en masa de Internet o la capacidad de llevar a cabo software con finalidades matemáticas, médicas o de otros sectores y que nos permiten realizar grandes obras de ingeniería, bioingeniería, química o análisis y diagnósticos médicos, así como muchas otras utilidades del software.

Programa fuente

Este código escrito en un lenguaje de alto nivel, en concreto, C++, calcula el área de un triángulo de forma muy sencilla, solicita una serie de argumentos introducido por el usuario por línea de comandos y luego muestra un mensaje con el resultado, o salir con un mensaje de error si no hubiera argumento.

Como se puede observar en la figura, este código de alto nivel permite no solo la utilización de variables con nombre a la libre elección del programador, sino el empleo de comentarios sobre el código, así como la indentación del texto. Estas características facilitan la lectura a las personas, aunque no tenga ninguna trascendencia respecto al código máquina que se ha de generar.

También se puede observar la utilización de estructuras de código, como pueden ser las funciones, que ayudan a la reutilización de código y a su abstracción, pudiendo construir código centrándose en lo particular, para ir resolviendo problemas más generales, además de poder realizar invocaciones recursivas sin necesidad de llevar el control de manera explícita.

Estas facilidades y la proximidad del código fuente al lenguaje natural permiten al desarrollador centrarse en “el qué” debe hacer el software en lugar de en “el cómo” debe implementarlo para que funcione en una máquina con una arquitectura u ordenador en concreto.

Programa objeto / Código ensamblador

Una vez que el compilador ha desarrollado todas las etapas y conseguido generar un código objeto correcto y operativo, se convierte en un código objeto, por lo general, código ensamblador. El lenguaje ensamblador es la representación más cercana al código máquina. La siguiente captura muestra el código ensamblador, que compone el programa objeto, de un programa similar al visto anteriormente del cálculo de un área.

Mnemónico

En informática, un mnemónico o nemónico es una palabra que sustituye a un código de operación (lenguaje de máquina), con lo cual resulta más fácil la programación, es de aquí de donde se aplica el concepto de lenguaje ensamblador.

Un ejemplo común de mnemónico es la instrucción MOV (mover), que le indica al microprocesador que debe asignar datos de un lugar a otro. El microprocesador no entiende palabras, sino números binarios, por lo que es necesaria la traducción del término mnemónico a código objeto.

En muchas ocasiones se puede tomar a nivel de usuario como las teclas de acceso rápido que vemos en las ventanas, por ejemplo en un navegador encontramos el menú típico que dice Archivo, Editar, Ver, entre otras opciones, el mnemónico sería el valor de la letra que esta subrayada, así si presionamos la tecla alt y luego por ejemplo la A, se nos abrirá el menú de archivo, es por esta razón que se puede decir que la A en el menú resulta la tecla mnemónica de Archivo, o la tecla de acceso rápido a la opción Archivo.

El lenguaje Mnemónico también es utilizado en la programación de controladores lógicos programables (PLC), haciendo más rápida y eficiente la construcción de programas de alta complejidad.

Instrucción

Como se puede apreciar, existen varias diferencias en cuanto a los mnemónicos y operandos, tal y como se puede ver en la siguiente instrucción expresada en ambas sintaxis:

Hay varios tipos de instrucciones, en este caso dejamos la tabla de esamblador de Intel para procesadores 80186 o superiores. Pero también lo hay para procesadores AT&T, entre otros.

Etiquetas

Además de las instrucciones, se puede observar cómo hay etiquetas dentro del código a modo de localizaciones, que se utilizan para las bifurcaciones de código necesario:

Estas etiquetas son traducidas por direcciones de memoria relativas en la fase de construcción del binario final.

Como se puede apreciar en esta captura, podemos ver claramente no solo las etiquetas sino la estructura de un lenguaje ensamblador.

Un programa consta de varias partes diferenciadas. La palabra .data es una directiva y comunica al ensamblador que a continuación se define un conjunto de datos. El programa tan sólo tiene un único dato que se representa como una secuencia de caracteres. La línea .asciz, también una directiva, seguida del string entre comillas es la que instruye al ensamblador para crear una zona de memoria con datos, y almacenar en ella el string que se muestra terminado por un byte con valor cero. Nótese que el efecto de la directiva .asciz no se traduce en código sino que son órdenes para que el ensamblador haga una tarea, en este caso almacenar un string en memoria.

Antes de la directiva .asciz se incluye la palabra dato seguida por dos puntos. Esta es la forma de definir una etiqueta que luego se utilizará en el código para acceder a estos datos.

La línea siguiente contiene la directiva .text que denota el comienzo de la sección de código. Nótese que todas las directivas tienen como primer carácter un punto. La línea con la directiva .globl main comunica al ensamblador que la etiqueta con nombre main será globalmente accesible desde otro programa.

A continuación, se encuentran las instrucciones en ensamblador propiamente dichas. Se pueden ver las instrucciones push parar almacenar un operando en una zona específica de memoria que se denomina la pila.

Al comienzo del código se define la etiqueta main. Esta etiqueta identifica la posición en por la que el procesador va a empezar a ejecutar. Hacia el final del código se puede ver una segunda etiqueta con nombre done.

Una vez creado el fichero de texto con el editor y guardado con el contenido de la figura superior y con nombre miprograma.s, se ejecuta el compilador. Para ello primero es preciso arrancar una ventana con el intérprete de comandos y estando situados en el mismo directorio en el que se encuentra el fichero miprograma.s ejecutar el comando:

gcc -o miprograma miprograma.s

También tienes un emulador en javascript en esta web assembler-simulator donde poder probar código.

Programa binario ejecutable

Una vez que el código objeto ha sido generado, entran en juego otras herramientas fuera del alcance del compilador, como son el ensamblador y el enlazador de códigos objeto. El ensamblador genera código binario partiendo del programa en lenguaje ensamblador. Es decir, traduce los mnemónicos en los códigos binarios correspondientes. Por otro lado, el enlazador de códigos objeto se encarga de obtener los códigos objeto requeridos por el código objeto en cuestión de las librerías disponibles. Una vez que tiene todas las piezas necesarias, genera un fichero final ejecutable o en forma de librería del sistema.

Conceptos básicos sobre reconstrucción de código En el tema anterior profundizamos en el proceso de compilación, que convierte el código fuente, escrito en un lenguaje estructurado de alto nivel y fácilmente comprensible por una persona, en código objeto escrito en lenguaje máquina, para la arquitectura escogida y directamente ejecutable.

Ahora conocemos los conceptos básicos sobre diseño, análisis e implementación de lenguajes, así como los detalles sobre las fases por las que pasa un compilador, las técnicas utilizadas para generar y optimizar el código objeto y, en definitiva, todo lo relacionado con el proceso de compilación que genera código objeto partiendo de código fuente.

Ya sabemos cómo el compilador convierte el código fuente a código intermedio, utilizando este finalmente para traducirlo a código máquina de manera directa, tal como se puede apreciar en la siguiente imagen.

Proceso inverso

Tal como hemos visto antes, si podemos realizarlo en un sentido, también podríamos de alguna forma hacer el proceso inverso, pudiendo generar código fuente a partir del código objeto en lenguaje máquina.

Esta labor sí es posible en gran medida, aunque se deben tener en cuenta algunas las limitaciones. En este tema, vamos a referirnos como “Reconstrucción de código” al proceso inverso al que hemos estado estudiando en el tema anterior. Es decir, al proceso de obtener el código fuente a partir del código objeto. Debido a las limitaciones mencionadas, no será posible obtener comentarios, ni nombre de variables, tal y como las describió el desarrollador, puede que ni tan siquiera con el tipo ni el tamaño exacto con el que este lo hizo.

No obstante, sí se va a poder obtener una estructura de código que cumple con bastante exactitud con el comportamiento del programa fuente. Para ello, es necesario conocer las estructuras que el compilador maneja, y con las que traduce el código fuente a código objeto. De esta forma, podremos identificar estas estructuras en el código objeto y ser traducidas a código fuente. Esta traducción depende de:

• Arquitectura (INTEL, ARM, x86,etc)
• Optimizciones que pueda sufrir el código

Resumiendo

Si bien ya hemos visto lo fundamental para comprender el mundo de los compiladores, lo que nos resultaba útil para comprender como se construyen los binarios que queremos analizar; ahora es el momento de empezar a comprender las estructuras de datos que nos podemos encontrar a la hora de reconstruir el código fuente partiendo del desemsamblado.

Haciendo un poco de memoria respecto a las fases de compilación, podemos observar en las últimas fases de “Generación de código intermedio”, “Optimización” y “Generación de código” que la idea de reconstrucción del código sería volver al proceso del “código intermedio”.

Debemos tener claro que existen limitaciones cuando volvemos del código final al código intermedio, como la perdida de comentarios del programador, nombres reales de las variables, tipo de variables, el tamaño, etc.

Para poder identificar todas estas estructuras de datos y comprender el código, trataremos aquí como identificarlas manualmente, dependiendo de la arquitectura del código (x86, x86_64, arm, …) y las optimizaciones aplicadas por el compilador.

Cuando tengamos identificadas las estructuras de datos, podremos darles nombres a las mismas mediante nuestro software de ingeniería inversa (radare2, IDA, papel y lápiz? ) para así poder reversear sin volvermos locos y dejar invertir más esfuerzo mental en algo que no merece la pena por no apuntarlo o nombrar las cosas, pudiendo dejar ese esfuerzo en pensar las estructuras mentalmente y al vuelo, en tratar otras cosas más relevantes del reversing, como la lógica de programación del propio código a analizar.

Las estructuras de datos que vamos a analizar serán las típicas del lenguaje de programación C.

Variables

Como seguro que sabemos, las variables sirgen para almacenar valores de nuestra aplicación y existen varios tipos. Los tipos son clasificados en base a un tamaño (ancho de bits) y unos valores mínimos y máximos (en base al signo) ayudan a definir con más exactitud el valor numérico hasta donde abarcan.

Vamos a tratar los tipos de variables en C en arquitecturas de 32bits, excluyendo floats y double.

Si construimos una aplicación realizada en código c donde sólo realizamos la definición de variables globales y locales, podemos ver un ejemplo de cómo se sitúan en el binario.

Código aplicación “test”

Si compilamos el fichero en 64 bits y analizamos el desemsamblado del mismo en sintaxis Intel nos encontraremos con lo siguiente:

Si analizamos el binario de 64 bits con gdb en la función main se nos mostrará lo siguiente:

Si lo recompilamos en 32bits (si usas ubuntu/debian probablemente necesites el paquete “libc6-dev-i386”) y tiramos de gdb desde la función main se mostrará lo siguiente:

(gdb) disassemble main

Dump of assembler code for function main:

Ahora, si observamos detenidamente sólo hemos mostrado las variables de tipo local, las cuales hemos tenido que encontrar la entrada main mediante la instrucción de gdb “disassemble main”, ¿pero qué hay de las variables de tipo global?

Para ello vamos a decirle a gdb que nos muestre o “examine” el contenido de la memoria en una dirección dada usando el formato especificado. Esa dirección dada será la dirección de memoria de la variable gvar1 mediante el uso del carácter “&” (AND) y que muestre en contenido en hexadecimal agrupado en una longitud de byte, mostrando un total de 32 bytes.

(gdb) set disassembly-flavor intel

Ahora mostraremos estas variables en hexadecimal con una longitud por defecto, normalmente “word” (palabra) y hasta un total de 8, ya que con esto cubriremos el poder mostrar todas las variables globales.

(gdb) x/8wx &gvar1

0x804a018 <gvar1>: 0x00332211 0x00000044 0x00000055 0x00000066
0x804a028 <gvar7>: 0x00000077 0x00000088 0x00000099 0x00000000

Otra forma curiosa de ver y confirmar el tamaño de las variables globales, sería compilando la aplicación sin ensamblado/linkado, donde podemos ver en el apartado “size” el tamaño de las variables.

gcc -m32 -S test.c -o test

Conclusiones

Esta lección habla sobre el tema de la ingeniería inversa o reversing, que consiste en el proceso de obtener información o un diseño a partir de un producto para determinar cuáles son sus componentes y cómo interactúan entre sí. Se menciona que uno de los usos más conocidos del reversing es la detección de vulnerabilidades y el análisis de malware en el ámbito de la seguridad informática, pero también se mencionan otros usos como descifrar algoritmos criptográficos y agregar funcionalidades. Se recomienda empezar el estudio del reversing conociendo los fundamentos y remontándose a la base. También se menciona que en un curso de reversing se hablará de compiladores, estructuras de ejecutables, programación de bajo nivel, arquitecturas de hardware, sistemas operativos y kernel e incluso técnicas de explotación y metodologías.

La Ciberseguridad Ante la Furia de la Naturaleza:

Lecciones del Terremoto de Kamchatka
El reciente terremoto de magnitud 8.8 frente a las costas de Kamchatka, que desató alertas de tsunami a lo largo y ancho del Pacífico, no es solo un recordatorio de la inmensa fuerza de la naturaleza, sino también un prisma a través del cual podemos analizar la resiliencia y vulnerabilidad de nuestros sistemas de ciberseguridad. Aunque un sismo y un tsunami son fenómenos físicos, sus repercusiones en el ámbito digital son profundas y multifacéticas.

La Fragilidad de la Infraestructura Crítica
Un evento de la magnitud de este terremoto puede causar daños devastadores a la infraestructura física que soporta nuestra vida digital. Cables submarinos, centros de datos, torres de telecomunicaciones y subestaciones eléctricas son puntos vulnerables que, si se ven afectados, pueden provocar cortes masivos en el servicio de internet, telefonía y otros servicios esenciales. En el contexto de ciberseguridad, esto se traduce en una interrupción de las comunicaciones críticas, la imposibilidad de acceder a sistemas de emergencia o de respuesta, y una parálisis en la capacidad de monitorear y mitigar ciberataques. La dependencia global de la infraestructura interconectada significa que un daño localizado en Kamchatka podría reverberar en la conectividad de otros países de la cuenca del Pacífico, afectando desde transacciones financieras hasta la operación de servicios públicos.

La Exacerbación de las Amenazas Cibernéticas
Los desastres naturales crean un ambiente propicio para el aumento de la actividad maliciosa. En momentos de caos y necesidad de información, los actores de amenazas cibernéticas aprovechan la confusión y el miedo. Podemos esperar un incremento de ataques de phishing con enlaces a supuestas donaciones, mapas de evacuación o actualizaciones de noticias falsas, buscando robar credenciales o instalar malware. Las campañas de desinformación también florecerán, difundiendo rumores y noticias falsas para sembrar pánico o polarizar a la población, lo que puede obstaculizar los esfuerzos de respuesta y rescate. Además, la atención de los equipos de ciberseguridad puede desviarse hacia la restauración de servicios, dejando flancos abiertos que los atacantes más oportunistas no dudarán en explotar.

La Necesidad Imperante de la Resiliencia Cibernética
Este tipo de eventos subraya la urgencia de construir una resiliencia cibernética robusta. Esto implica no solo proteger los sistemas contra ataques, sino también garantizar su continuidad operativa y recuperación rápida frente a interrupciones. Las lecciones aprendidas de Kamchatka incluyen:

Redundancia y Diversificación: Asegurar que las rutas de datos y los centros de datos críticos tengan redundancia geográfica y tecnológica, evitando puntos únicos de fallo que puedan ser arrasados por un desastre natural.

Planes de Recuperación de Desastres (DRP) y Continuidad del Negocio (BCP): Las organizaciones deben tener planes bien definidos para la recuperación de sus sistemas informáticos y la continuidad de sus operaciones ante una catástrofe, incluyendo respaldos de datos fuera de sitio y procedimientos claros de comunicación.

Concienciación y Educación: Educar al público y al personal sobre las tácticas de ingeniería social y desinformación que proliferan durante las crisis es crucial para evitar que caigan en trampas cibernéticas.

Colaboración Multisectorial: La coordinación entre gobiernos, empresas de telecomunicaciones, proveedores de servicios en la nube y agencias de ciberseguridad es vital para una respuesta rápida y efectiva a la hora de restaurar la conectividad y proteger los sistemas.

En conclusión, un terremoto como el de Kamchatka es un crudo recordatorio de que la ciberseguridad no opera en el vacío. Está intrínsecamente ligada a la infraestructura física y a la psicología humana, ambas vulnerables ante la imprevisibilidad de la naturaleza. Fortalecer nuestra ciberseguridad en este contexto significa no solo defendernos de amenazas digitales, sino también prepararnos para un mundo donde los desastres físicos pueden ser tan destructivos para nuestros sistemas de información como el ataque de un sofisticado grupo de hackers. ¿Estamos realmente preparados para que nuestros sistemas digitales soporten la próxima gran calamidad natural?

Recursos Base de datos

Un recurso en la web que es muy importante tener en cuenta a la hora de modelar una base de datos básica. A continuación se describen las bondades de esta plataforma.

Cuando comienzas a aprender el mundo acerca de las Bases de Datos. Un recurso Online que no se puede escapar es a través de la pagina web https://dbdiffo.com/.

Es un entorno que facilita los modelos entidad relación muy amigable que facilita el trabajo a la hora de optar por un motor de base de datos (SQL, Oracle, entre otros).

Altamente recomendado en la academia de Ingeniería de Software para interactuar con docentes y estudiantes a la hora de crear tablas y relaciones. En pocas palabras un entorno intuitivo que vale la pena tener en cuenta a la hora de modelar cualquier tipo de dato. Puedes generar leyendas y los atributos de manera profesional.

Toda vez que se crea una tabla de manera recursiva e intuitiva podrás crear rápidamente un modelo de base de datos con unos cuantos clicks.

Otras herramientas de las que podrás sacar el mayor partido que pueden servir en este tópico te las comparto a continuación:

diagrameditor

app diagram

Caída de Facebook e Instagram a nivel mundial