2019/07/31

Protegiendo nuestro trabajo en pentests hostiles

Por el 2019/07/31 con 1 comentario

Buenas a todos, ya estamos a último día de mes, y comienzan para muchos las deseadas vacaciones de verano :) Por nuestra parte, mañana daremos comienzo a unas semanas de descanso para retomar con fuerzas renovadas la nueva temporada de Flu Project a partir del próximo 2 de septiembre. ¡Así que vamos a por el último artículo!

En muchas ocasiones nos encontramos en nuestro día a día con algunos administradores de sistemas y seguridad, CISOs, etc. que, permitidme la expresión, han toreado en muchas plazas, y pueden ser algo hostiles. También nos encontraremos casos como el del típico administrador que, bajo cualquier ralentización de la red, o caída no controlada (por su incompetencia, generalmente), enseguida está pidiendo a su director que finalicemos los trabajos de pentesting, acusándonos del problema, cuando la realidad es que simplemente no quiere ser auditado para que no salgan a la luz las vergüenzas de su mal hacer. ¿Os suena, verdad? }:)

En este tipo de situaciones, nosotros solemos adoptar ciertos mecanismos de protección, que nos han venido bien para resolver disputas sobre, quién ha tirado qué, de una forma rápida e indolora, sin tener que recurrir al análisis de los logs que pudiesen tener (porque... todo el mundo tiene logs de todo, ¿verdad? :P)

Lo primero que recomendamos es indicarle al cliente una de nuestras IPs fijas, y canalizar todos los ataques que realicemos por ella. Aunque trabajemos en remoto desde casa, vía VPN saldremos siempre por esa dirección IP. De esta manera garantizamos que ante cualquier ataque "real", estaremos 100% cubiertos y no podrán acusarnos de un ataque "inapropiado".

También podéis aprovechar esta situación para pedirles que añadan la dirección IP a las listas blancas, para así avanzar más rápidamente en las pruebas, en función del tipo de revisión que sea realizada.

Otra recomendación que os haría es capturar todo el tráfico de red, y guardarlo en un disco externo hasta, al menos, que el informe sea entregado. 

Un simple tcdump como el siguiente, sería más que suficiente para registrar todos nuestros ataques:

tcpdump -i eth0 -w pentest1.log

Finalmente, recomendamos grabar la salida de la consola, o al menos, custodiar el "history" sin machacarlo. Para grabar la salida podéis hacer uso del comando "ttyrec".
Instalación: apt-get install ttyrec
Grabación: ttyrec -a pentest2.tty
Reproducción: ttyplay pentest2.tty
Con estos tres pasos sencillos, estaremos más que protegidos en aquellos pentests, que por su hostilidad, puedan dar problemas. Lo más importante, más que capturar todas las evidencias posibles de nuestro trabajo, es que el administrador "sepa" que los estamos capturando, ya que de esta manera, se cohibirá más a la hora de acusarnos, y verificará con más ahínco, que los problemas no se hayan visto producidos por una mala configuración, un mal dimensionamiento de su red, etc.

¿Y vosotros qué medidas soléis tomar para protegeros en los pentests hostiles?

¡Nos vemos en septiembre, un abrazo!
Leer más
    email this       edit

2019/07/30

RootedCON #Valencia: RootedLab de Red Team & Ethical Hacking

Por el 2019/07/30 con 0 comentarios
El próximo 13 y 14 de Septiembre se celebrará la sexta edición de Rooted CON Valencia. Tengo el honor por sexto año consecutivo de asistir con una formación o RootedLab. Además, daré una charla el sábado 14 de septiembre sobre uac-a-mola^2. Sexto año dónde los chicos de Rooted se situarán en Valencia para llevar a todos los asistentes el mundo de la seguridad informática. Si necesitas más información sobre el taller puedes ponerte en contacto con la gente de rooted en info@rootedcon.com.

Mi taller sobre Ethical Hacing & Red Team será el viernes 13 de septiembre, en el cual participaré de nuevo. En este training, orientado a la práctica del hacking. Tienes la agenda del Lab en este enlace.

Podrás introducirte y sentar bases en los tipos de auditorias, en la forma de trabajo, en cómo llevar a cabo auditorías y cómo se debe presentar los resultados de éstas. El alumno obtendrá una visión global del hacking ético, profundizando en ciertas partes prácticas de auditorias y se repasarán conceptos de Red Team. ¿A quién va dirigido?


  • Profesionales del sector de la seguridad informática. 
  • Estudiantes.
  • Administradores de sistemas y redes.
  • Desarrolladores que quieren mejorar su perfil.
  • Cuerpos y fuerzas de seguridad del estado.
  • Docentes.
¿Qué veremos?


  1. Introducción
    1. Metodologías
    2. Tipos auditoría
    3. Ejercicios RT
    4. Diferencias entre auditoría y RT
    5. Equipos involucrados
  2. Vectores
    1. Acceso digital
    2. Acceso físico
    3. Ingeniería Social
  3. Recopilación de información
    1. Enumeración
    2. Fingerprint
  4. Explotación: Comprometiendo el sistema
    1. Análisis
    2. Técnicas de explotación
    3. Elevación de privilegios
    4. Movimiento lateral
    5. Técnicas de pivoting
    6. Despliegue de persistencia
  5. Emulación de adversarios

Precio estándar: 100€
Fecha de inicio: 13 de Septiembre de 2017
Fecha de finalización: 13 de Septiembre de 2017
Duración: 8 horas
Idioma del curso: Español
Plazas limitadas



¡No lo dudes y guarda tu plaza!


Leer más
    email this       edit

Rootkits en Linux: jugando al escondite (parte II)

Por el 2019/07/30 con 0 comentarios
Buenos días, hoy continuaremos con la segunda parte del artículo "Jugando al escondite". En el primer post, vimos la teoría acerca de cómo detectar un rootkit. En este post lo veremos de forma práctica, jugando con un sencillo script que iremos desgranando :)

Lo primero que haremos es abrir el fichero /proc/sys/kernel/pid_max en modo lectura, leemos el PID máximo y lo almacenaremos en la variable máximo. Después, cerraremos el fichero e imprimiremos un mensaje por pantalla.


Reservamos memoria para almacenar todos los posibles PIDs y los inicializamos a cero. Ahora viene lo divertido. Dentro del segundo bucle for, creamos los procesos con la función fork. Esta función duplica el proceso actual, por tanto, ahora mismo tenemos varios procesos ejecutando nuestro código. La función fork devuelve un 0 para el caso del proceso hijo y devuelve el PID del proceso hijo para el caso del padre. Ya sé que suena un poco lioso, quienes no conozcáis esta función os recomiendo mirar la documentación de Linux ejecutando “man fork”. El proceso hijo ejecutará la parte que está en rojo y el proceso padre la parte en azul. Como podéis ver, el proceso hijo no realiza nada, simplemente finaliza su ejecución. El proceso padre guarda el PID del hijo (también os recomiendo echarle un ojo a la función wait).


Si ejecutamos el código que llevamos hasta ahora, tenemos lo siguiente:


Se irán generando procesos hasta el PID máximo, en mi caso 32768. Después probará con los PIDs del 1 al 2906.


La primera imagen de abajo es nuestro programa, y la segunda es el resultado de ejecutar en Linux “ps -e”. Como podéis ver, como el PID 1037 está siendo ocupado por otro proceso llamado “gsd-clipboard”, nuestro programa no puede generar otro proceso con el mismo PID. Por este motivo, genera el proceso con PID 1036 y después salta al 1038. Si os fijáis, ocurre lo mismo con el 1040 y 1042.



Por tanto, para terminar este programa y que sea totalmente funcional, solo quedaría programar estas comparaciones, comentadas en el párrafo de arriba. Esto ya os lo dejamos a vosotros :)

Espero que os haya gustado, ¡hasta la próxima!
Leer más
    email this       edit

2019/07/29

Rootkits en Linux: jugando al escondite (Parte I)

Por el 2019/07/29 con 0 comentarios
Buenas a todos, hoy hablaremos sobre los Rootkits en Linux. Para empezar, ¿qué es un Rootkit? Muy sencillo, es un malware para infectar y controlar los ordenadores de forma remota, y sobre todo, mantenerse ocultos durante la mayor parte del tiempo. Podemos explicarlo de otra forma, imaginemos que somos un atacante y queremos infectar un sistema. Lo primero que haremos es descubrir una vulnerabilidad que nos permita entrar en el sistema, después escalaremos privilegios hasta ser administradores y es ahora cuando llega la función de nuestro Rootkit, instalar una puerta trasera que nos dé acceso al sistema y sobre todo que nos permita mantenerla “escondida” a los ojos de los sysadmins.

Seguro que muchos de vosotros os preguntaréis cómo es posible que estos “programillas” se mantengan ocultos y que cuando ejecutemos, en Linux, el comando “ps -a” no seamos capaces de encontrar este proceso malicioso. Muchos de estos Rootkits modifican la información disponible en “/proc” afectando, por tanto, a los comandos como “ps”. De esta forma, cuando lo ejecutamos solo veremos lo que el atacante quiera que veamos. Otros Rootkits lo que hacen es modificar el kernel y por tanto, se arriesgan a corromper el sistema y dejarlo inutilizado.

A muchos de vosotros seguro que se os ocurren ideas acerca de cómo detectar estos Rootkits. Yo os voy a explicar uno de los métodos más efectivos, que consiste en hacer fuerza bruta en el espacio de IDs de los procesos. En este post os explicaré la teoría y en el siguiente un caso práctico.

Vamos a ir creando procesos y anotando sus PIDs (Process IDentifier). Para averiguar el PID máximo ,podemos consultar el fichero “/proc/sys/kernel/pid_max”. En nuestro caso es 32768, aunque ejecutando el comando “echo 32768 > /proc/sys/kernel/pid_max” podremos modificarlo.


Una vez que hayamos creado y anotado los PIDs, debemos analizar los resultados. Los PIDs que NO hemos anotado, son aquellos que están siendo usados por otros procesos. Pongamos un ejemplo, imaginemos que el número máximo de PID es 10 y que los PIDs anotados son los siguientes:


Con esto sabemos que los PIDs 1, 2, 3, 5, 9 y 10 están siendo utilizados por otros procesos. Por tanto, si ejecutamos “ps -e” deberíamos tener un resultado similar a este:


Sin embargo, si el resultado fuese este otro, estaríamos ante un posible rootkit cuyo PID es 9.


¿La idea es sencilla verdad? Pues en el próximo artículo pondremos en práctica esta teoría.

¡Saludos!
Leer más
    email this       edit

2019/07/26

Nueva versión de Burp Suite

Por el 2019/07/26 con 1 comentario
Buenos días, hoy hablaremos sobre la conocida herramienta Burp Suite, más concretamente, de la versión 2.1 (Community y Professional Edition), que incorpora una gran cantidad de características. Os dejo por aquí el link de descarga de la página oficial.

Ahora es posible cambiar la interfaz a modo noche. Para ello pulsamos en “Burp”, seguimos la siguiente ruta “User Options > Display > User Interface > Look and Feel” y seleccionamos “Darcula”.

Al iniciar Burp Suite, nos encontramos con el nuevo Dashboard. Como podéis ver en la imagen de abajo, tenemos una sección de tareas donde encontraremos el progreso de cada tarea realizada (por ejemplo, al lanzar un escáner de vulnerabilidades), un log que nos va informando de diferentes eventos y un panel que muestra información de las vulnerabilidades encontradas en una web.


Arriba a la izquierda, haciendo clic en “New live task”, podemos planificar nuevos escáneres (crawlers o auditorías en busca de vulnerabilidades)



El crawler trae nuevas características, como capacidad para manejar sesiones automáticamente, detectar cambios en la aplicación, configurar múltiples logins para diferentes roles de usuarios, etc. Probadlo y contadnos qué os parece! :)

Un saludo!
Leer más
    email this       edit

2019/07/25

Buscando activos con onyphe.io

Por el 2019/07/25 con 1 comentario
Buenas a todos, en el post de hoy quería compartiros un servicio online lanzado hace un par de años, similar a Shodan, llamado onyphe.io. Se trata de un portal muy simple, que nos dará acceso bien a través de la web, o bien a través de su API, a una gran cantidad de información de activos de Internet almacenada en sus bases de datos.

De una forma similar al popular buscador Shodan, podremos lanzar queries utilizando diferentes parámetros para localizar, por ejemplo, servicios FTP expuestos en Internet. A continuación podréis ver un ejemplo con una búsqueda para los servidores "Pure-FTPd":




Una vez seleccionado un activo, podremos abrir una nueva ventana con mayor detalle sobre el servidor:



Y acceder a todo el detalle sobre los puertos abiertos, los servicios a la escucha, banners, etc:




Así como información sobre si el activo puede suponer una amenaza:


El portal dispone de una licencia gratuita limitada, de una licencia perpetua por un coste bastante bajo (59$), y de algunas licencias para uso profesional por importes mayores.

En Github podréis encontrar un interesante script desarrollado por MS-LUF, para hacer consultas a través del API de Onyphe, utilizando Powershell:



A continuación, os dejo un ejemplo de la salida en formato CSV que genera:


Sin duda, una interesante utilidad para incorporar a nuestros procesos de OSINT.

Saludos!
Leer más
    email this       edit

2019/07/24

El intrusismo laboral (empresarial) en España en el sector de la ciberseguridad

Por el 2019/07/24 con 3 comentarios

Buenas a todos, hoy os voy a contar una historia (breve, no os preocupéis), sobre una realidad que llevamos algunos años observando en nuestro sector, el de la ciberseguridad, dentro de España. Lo que os voy a contar es una situación muy concreta, pero que se ha repetido en varias ocasiones en estos últimos 3-4 años, y que por desgracia comienza a ser habitual. Me estoy refiriendo al intrusismo laboral en nuestro sector. Pero no al intrusismo de químicos, industriales y otros expertos que trabajan en informática. Para mí, al menos, esto no es un problema, mientras sus capacidades técnicas sean las adecuadas para desempeñar las funciones que requieran sus respectivos puestos de trabajo. De hecho alabo a todos estos profesionales, ya que su esfuerzo tiene que ser aún mayor que el de muchos informáticos, al menos, durante el inicio de su actividad. A lo que me refiero, es a aquellas compañías que ofertan servicios de ciberseguridad, sin dedicarse ni haberse dedicado nunca a una materia similar, y sin tener ningún conocimiento, ni técnico, ni en la venta de los mismos, lo cual si cabe es aún más grave.

Hace cosa de 6 meses, una compañía de unos 250 empleados, que nada tiene que ver con la ciberseguridad, ni la seguridad, ni tan siquiera, la informática, nos llamó para subcontratarnos un servicio de ciberseguridad para uno de sus clientes. Esta empresa que pongamos que se dedica al ámbito textil (no es así, pero la verdad que da igual el sector real al que se dedica), contaba con 8 personas dentro de su CAU. No eran grandes expertos, pero se defendían lo suficiente como para sobrellevar su día a día, gestionar una red Windows pequeña, un pequeño grupo de impresoras, un par de servidores, el wordpress de la web corporativa... lo típico. Ese servicio nunca nos lo llegaron a subcontratar, porque, como nos enteramos más adelante, lo acabaron ejecutando con dos de los técnicos de su CAU. Sin ánimo de entrar en aspectos legales, CNAEs, etc., ni en temas de seguros de responsabilidad profesional, lo que hicieron fue una barbaridad. Se trataba de un pentest muy complejo, interno y externo, a un parque muy grande de servidores y puestos de trabajo (varios miles) a uno de sus clientes estrella. Su cliente no era una Ibex 35, pero sí una empresa que todos conoceréis de sobra y que mueve varios millones de euros, la cual además, había sufrido recientemente algunas estafas del CEO y varios casos de ransomware, y que por tanto, era un potencial objetivo para seguir siendo atacada.

Un importante cargo de esta empresa que realizó el pentest (no daré más detalles para evitar alusiones), se informó por Internet de qué iba esto de la ciberseguridad, y asesorado, más o menos, por uno de los informáticos de su CAU, se aventuraron a realizar ellos mismos el servicio, porque era "muy rentable". Sí, lamentable, lo sé. No entraré en porqué era tan rentable para ellos este trabajo, aunque las razones son obvias. Solo diré que tras aprovecharse de nuestro esfuerzo en la estimación y cotización del servicio, les fue fácil "ganar este contrato", ya que tenían una oferta top (la nuestra), que competía con otras ofertas que su cliente había solicitado a otras empresas que sí eran del ámbito de la ciberseguridad. El resultado del proyecto lo desconocemos, porque no nos brindaron más detalles diferentes a que el proyecto ya lo habían comenzado con dos personas de su CAU, y que estaban a mitad del mismo. 

Aunque no es una historia de muchas moralejas, podemos aprender de ella que siempre hay comerciales encantadores de serpientes, que lo mismo te venden un palet de toallas, que un pentest :), que nunca hay que fiarse de los trileros, y lo más importante, que ante la explosión de la ciberseguridad que llevamos viviendo varios años, el número de vende humos está aumentando considerablemente, y es algo con lo que tenemos que convivir. Es difícil convencer a muchas empresas, sin cultura de ciberseguridad, de lo difícil que es hacer un proyecto de seguridad, y la importancia de que lo realicen profesionales experimentados, pero es un esfuerzo que es importante que hagamos entre todos. Muchos me diréis que el tiempo pone las cosas en su lugar, y aunque no siempre pasa, ya hemos tenido casos de clientes que en un caso similar, han vuelto a confiar en nosotros para que resolviésemos algún problema, en varias ocasiones, grave.

Antes de despedirme, y como remate a la historieta, esta empresa nos volvió a contactar meses más tarde para que formásemos a su CAU "en esto del hacking". Quizás, las cosas no iban tan bien cómo esperaban en un inicio...

Saludos!
Leer más
    email this       edit

2019/07/23

Teleco in a nutshell v5.0: Amplificadores y filtros

¡Muy buenas!

En el último post estuvimos hablando sobre el ruido y la importancia de la relación entre la potencia de la señal y el ruido recogidos por un receptor. Pues bien, en este post hablaremos sobre las dos grandes armas que tenemos para combatir al ruido: los amplificadores y los filtros.

Los amplificadores son equipos electrónicos que aumentan la potencia (recordemos, el cuadrado de la amplitud) de una señal. Debemos tener en cuenta que un amplificador no entiende de frecuencias: toda aquella señal que entre al amplificador (sea deseada o ruido) sale amplificada, sea cual sea su forma de onda o frecuencia. Únicamente hay que tener en cuenta una limitación llamada tensión de saturación de salida, que es la máxima amplitud de salida que puede ofrecer el amplificador (algo menos que la tensión de alimentación que tenga).

Amplificador con saturación en 15V. Función de amplificación (izqda.) y ejemplo de entrada y salida del amplificador (dcha.) [Quora]

En la imagen anterior podemos ver un amplificador con una saturación de 15V. Si nos fijamos en la parte de la izquierda, podemos ver la función de amplificación, que indica la tensión de salida (eje vertical) en función de la señal de entrada (eje horizontal). Vemos que el amplificador funciona de forma lineal, es decir, que la señal de salida es la misma que la de entrada con una cierta ganancia; pero hasta cierto punto, el de saturación. Con señales de entrada mayores, su salida (que debería ser mayor a 15V) no aumenta más, provocando un corte de la forma de la señal tal y como podemos ver en la parte derecha de la figura.

Como ya hemos dicho, los amplificadores afectan a toda la señal indiscriminadamente, por tanto, es imprescindible usar también filtros, que son exactamente lo contrario a los amplificadores: elementos electrónicos que disminuyen la potencia de la señal únicamente en algunas frecuencias.

Existen diversos tipos de filtros en función de su diseño electrónico. pero los más importantes son tres: 
  • Filtro paso bajo: Disminuyen la potencia de la señal a partir de una cierta frecuencia. Las frecuencias inferiores no son afectadas.
  • Filtro paso alto: Disminuyen la potencia de la señal hasta una cierta frecuencia. Las frecuencias superiores no son afectadas.
  • Filtro paso banda: Disminuyen la potencia de la señal hasta una cierta frecuencia y a partir de otra. Las frecuencias intermedias no son afectadas.
Filtros paso bajo, paso alto y paso banda [Wikipedia]
Pues bien, con estos dos componentes electrónicos podremos conseguir (mediante un correcto diseño de los equipos) una buena señal con el mínimo ruido posible. Sin embargo, hay un tercer elemento de gran ayuda a la hora de obtener un buen SNR, exclusivo para señales digitales: los regeneradores.

En el caso de las señales digitales se juega con la ventaja de que tiene unos valores de amplitud finitos (al ser una señal cuadrada). Por tanto, si esta señal se mezcla con ruido, es relativamente sencillo regenerarla, ya que únicamente hay que intentar discernir cuál de los posibles valores de esa señal cuadrada original está teniendo esa señal ruidosa. 
Funcionamiento del regenerador para recuperar una señal digital de baja calidad [Wikipedia]
¡Pues hasta aquí por hoy! En el siguiente post nos alejaremos un poco de tan bajo nivel, hablando de ondas y componentes electrónicos; y pasaremos a hablar del espectro radioeléctrico (¿y por qué me toca resintonizar la tele por enésima vez?)

¡Muchas gracias por leernos! ¡Hasta el próximo post! 

Y si os habéis quedado con ganas de más:
Leer más
    email this       edit

2019/07/22

Advanced Persistent Threat (II) - Atribución

Por el 2019/07/22 con 0 comentarios

Como ya adelantábamos en el primer artículo, los APT son grupos avanzados capaces de provocar el mayor impacto imaginable, incluyendo daños a la propia Seguridad Nacional de un país. Sin embargo, no hay mes en el que no escuchemos noticias sobre nuevas víctimas de alguno de estos grupos, incluyendo algunas de las empresas o estados más preparados del mundo. ¿Cómo puede ser que una amenaza tan extremadamente grave se materialice una y otra vez de forma indefinida en el tiempo sin una respuesta efectiva?

Como todo en esta vida, la respuesta a esta pregunta no es sencilla. Sin embargo, sí que existe un factor determinante que nos puede arrojar algo de luz en este sentido, y es el concepto de atribución. La atribución es la capacidad de rastrear e identificar al responsable de un ciberataque, generalmente, con el objetivo de poder acusarlo por los cauces pertinentes.

Como cualquier otro crimen, un ciberataque pueden tener consecuencias gravísimas, no sólo reputacionales, sino de tipo económicas o asociadas al cumplimiento normativo. Por este mismo motivo, después de cada incidente puede ser necesario iniciar una importante investigación con el objetivo de dilucidar qué ha sucedido, cómo ha sucedido, y quién es el responsable último del ataque.

Sin embargo, al contrario de lo que suele suceder en otro tipo de delitos, la propia naturaleza del espacio Cyber hace muy difícil perseguir al autor material de determinados hechos. La arquitectura pública y distribuida de Internet hace que los atacantes tengan innumerables mecanismos para ocultar sus actividades. Por ejemplo, un atacante de China interesado en una víctima de EEUU podría utilizar, sin mayor complicación, direccionamiento IP de EEUU que impida identificar el origen chino de la amenaza. Para ello podría redirigir las comunicaciones a través de proxies, usar la red Tor, utilizar ordenadores y servidores previamente comprometidos, o incluso contratar de forma anónima servidores alojados en EEUU. Además, redirigir las comunicaciones a través de servidores alojados en diferentes países es trivial, creando escenarios donde cualquier investigación va a requerir de un compromiso internacional en el que numerosas jurisdicciones entran en juego, generalmente impidiendo la recogida rápida de evidencias que puedan ser utilizadas en el caso.

Pero no sólo eso, y es que cuando el crimen proviene de un APT las situaciones pueden ser aún más difíciles.

Supongamos por un momento que Cyberistán ataca a Ambrosía, y que sin mucha preocupación utiliza la infraestructura de la empresa privada Bad Corp, afincada en Cyberistán, y con la que los servicios secretos de Cyberistán están asociados.

Aunque no traten de ocultar el origen de las comunicaciones, sin una investigación más detallada, en un principio desde Ambrosía como mucho podrán saber eso, que el origen de las comunicaciones está en Bad Corp, una empresa privada de Cyberistán.

Para empezar, que un ataque salga de Bad Corp. no quiere decir que detrás del ataque esté Cyberistán, ni que estos hayan promovido dicha actuación, aunque todas las sospechas estén detrás de ese estado enemigo. Por ejemplo, puede que un tercer estado, Borostyria, haya hackeado a Bad Corp. para lanzar el ataque desde esa infraestructura.

Pero no sólo eso, porque como además Cyberistán y Ambrosía son naciones no alineadas, y uno de los principales objetivos de Cyberistán es, digámoslo claro, tocarle las narices a Ambrosía, podrá hacer todo tipo de perrerías en una posible investigación si es que esta se llega a iniciar. Así a bote pronto podrá:

  • Avisar a Bad Corp. para que limpie todas las evidencias (por error, claro).
  • Como comentábamos, sea verdad o no, sugerir que Bad Corp. ha sido víctima de un ataque y que por tanto los malos son otros. 
Al final, puede que incluso los servicios secretos de Ambrosía tengan información conseguida de forma paralela que permita, casi con un 100% de probabilidad, atribuir el ataque a Cyberistán. Pero a efectos prácticos, no se acusará formalmente a nadie. ¿Por qué? Puede que se considere que es mejor no revelar la información que se ha obtenido a través de otros medios, quizás para ocultar exáctamente los medios o fuentes usadas, o incluso puede que se entienda que las consecuencias de esta acusación puedan ser, en realidad, peores para sus propios intereses.

Un ejemplo de esto último lo hemos podido ver reciéntemente, cuando algunos medios se hacían eco de una dura realidad: numerosas empresas de EEUU sabían que estaban siendo atacadas por China, pero aun así decidieron silenciarlo. Un secreto a voces ocultado, al parecer, durante décadas. ¿El motivo? Pues parece ser que para algunos directivos era mejor mirar para otro lado y así garantizar los números del trimestre, que proteger de forma efectiva a su propia compañía. Años mirando a otro lado, aunque esto suponga permitir que toda ventaja tecnológica y competitiva se desvanezca día a día debido al robo constante de información. Un claro ejemplo de pan para hoy, y hambre para mañana.

En resumen, tenemos pues que la atribución es difícil ya que:
  1. La arquitectura distribuida de Internet y los mecanismos de intercambio de información dificultan conocer el origen de un ataque.
  2. Los atacantes, además, pueden utilizar diversas técnicas para dificultar todavía más sus actividades.
  3. Aun suponiendo que llegas a conocer el origen de un ataque, normalmente es difícil asociar ese origen a un actor concreto.
  4. Y finalmente, aun identificando a un actor concreto, queda en el aire saber si el estado debe ser responsable de las acciones de ese grupo de personas.
Sin embargo, cada vez existen más técnicas y herramientas utilizadas por expertos en ciberseguridad con el objetivo de intentar atribuir una campaña maliciosa a un actor o grupo determinado. Grandes campañas, como las de los APT, suelen involucrar una infraestructura grande y compleja, con numerosas personas trabajando en ella y diferentes objetivos. Por este motivo, la posibilidad de cometer errores o de dejar suficientes trazas que permitan apuntar a un origen concreto van creciendo a lo largo del tiempo.

En próximos artículos seguiremos a vueltas con la atribución, y con algunos de los datos utilizados por los analistas para poder analizar una campaña de APT.

¡Saludos!
Leer más
    email this       edit

2019/07/19

Advanced Persistent Threat - Inicio de la serie

Por el 2019/07/19 con 0 comentarios

Ya hace mucho tiempo que escuchamos por primera vez el término Advanced Persistent Threat, o sus siglas APT, también conocido como Amenaza Persistente Avanzada en nuestro idioma. Todo aquel que se haya dedicado a la seguridad en los últimos años ha escuchado alguna vez este concepto, y si no, es que anda un poco perdido.

Los APT son grupos de actores maliciosos que están relacionados con las capacidades más avanzadas de ataque en el ciberespacio. Aunque generalmente están asociados con grupos dirigidos y apoyados por algún estado, en realidad, reciéntemente se han descubierto grupos muy avanzados que actuán de forma independiente.

La peligrosidad de estos grupos es muy alta, entre otras cosas, porque gracias al apoyo del estado que los ampara son capaces de mantener campañas sostenidas en el tiempo contra sus objetivos, incluso durante años. Si son detectados y eliminados de la organización objetivo, no tendrán problema en adaptar sus tácticas y volver a atacar indefinidamente mientras su misión esté activa.

Generalmente, el objetivo de estos grupos suele ser el robo de información, pero también se han producido ataques con éxito que tenían como objetivo impedir la operación, o directamente destruir infraestructuras críticas de un país enemigo. Por tanto, es necesario tener claro que caer víctima de un APT puede suponer un riesgo, ya no sólo a la propia operativa de la organización, sino que puede estar en riesgo incluso la Seguridad Nacional.

Desgraciadamente, hoy en día el concepto de APT no es sólo un término conocido, sino un término que escuchamos de forma muy frecuente. Si quieres conocer más sobre este fascinante mundo, presta atención a esta serie de artículos en la que analizaremos el funcionamiento y comportamiento de algunos de los grupos más avanzados de la historia, y en la que intentaremos dar respuesta al por qué de su presencia masiva en el ciberespacio.

¡Nos vemos!

Leer más
    email this       edit