31 jul 2019

Protegiendo nuestro trabajo en pentests hostiles


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!

30 jul 2019

RootedCON #Valencia: RootedLab de Red Team & Ethical Hacking

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!


Rootkits en Linux: jugando al escondite (parte II)

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!

29 jul 2019

Rootkits en Linux: jugando al escondite (Parte I)

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!

26 jul 2019

Nueva versión de Burp Suite

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!

25 jul 2019

Buscando activos con onyphe.io

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!

24 jul 2019

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


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!

23 jul 2019

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:

22 jul 2019

Advanced Persistent Threat (II) - Atribución


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!

19 jul 2019

Advanced Persistent Threat - Inicio de la serie


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!

18 jul 2019

BoomER - Local Exploiting

En esta ocasión os vengo a hablar de BoomER, mi proyecto fin de máster junto a Antonio Marcos y que dirigió Pablo González. No es la primera vez que hablo del proyecto, pero si es la primera vez que aparece BoomER en Flu-project.

Figura 1 - Banner de BoomER


¿Y qué es eso de BoomER? 

Se trata de un framework de Post-Explotación desarrollado con Python. Nos va a permitir recolectar información, detectar y explotar determinadas vulnerabilidades, pero al ser un proyecto modular, en muy pocos pasos cualquiera puede agregar sus módulos para comprobar lo que quiera. Se puede ver la funcionalidad y características de BoomER en la figura 2.

Figura 2 - Características de BoomER

En BoomER tenemos módulos destinados para MacOS, Windows y Linux.

Proyecto BoomER Independiente 

Para empezar, os facilito el repositorio del proyecto, y que está en el siguiente enlace: https://github.com/Josue87/BoomER.

BoomER aporta muchas opciones, existen módulos ‘sin carga’ y módulos que permiten la carga de Payloads, dentro de la herramienta existen unos ejemplos que permiten la apertura de shell reversas en Metasploit, cómo se puede ver en la figura 3.

Figura 3 - Lanzando un exploit con un Payload de Metasploit

Y en la figura 4 se puede apreciar como se recibe esta Shell, en esta ocasión, para las pruebas se ha usado un mismo equipo, como se puede comprobar en la dirección IP.

Figura 4 - Recibiendo la Shell en Metasploit

Y en la figura 5 se puede ver un ejemplo de uso en un MacOS para aprovecharnos de la vulnerabilidad de Rootpipe y elevar privilegios:

Figura 5 - Lanzando Rootpipe desde BoomER

Para terminar este apartado, se adjunta un vídeo de cómo funciona BoomER en Windows, donde conseguimos ser System:


Y saqué tiempo para crear nuestro propio meterpreter, basado en Metasploit, y que se puede ver en la figura 6:

Figura 6 - Nuestro Boomerpreter

Proyecto BoomER en el meterpreter de Metasploit 

Para no variar, el repositorio de esta parte del proyecto se encuentra en: https://github.com/Josue87/BoomER-MSF-Meterpreter

Este aspecto fue muy sugerido por Pablo, y al final pudimos tener una versión 'lite' de BoomER en la versión del meterpreter de Python, y que nos permitía tener una mini terminal de nuestra herramienta para ejecutar distintos módulos, y que mejor que ver un vídeo con un ejemplo de exploit:


El objetivo era llegar a tener una versión para cada 'tipo' de meterpreter, pero al final por falta de tiempo nos tuvimos que conformar con Python. Un placer compartir este proyecto en Flu-project.

¡Nos vemos en la próxima entrada!

17 jul 2019

Extrayendo direcciones de email con hunter.io

Durante los procesos de recolección de información (footprint) para la realización de un test de intrusión, un red team, o un proceso OSINT, necesitamos reunir datos de muchas fuentes de información diferentes. En una de estas fases, solemos recopilar direcciones de email de la organización, con el objetivo de tener varios "puntos de contacto" para las pruebas de ingeniería social a los que poder remitir un spear phishing, entre otras posibilidades, o incluso, averiguar a través de los emails, algunos usuarios válidos del Active Directory. Para esta labor, el sitio web https://hunter.io/ nos puede ser de gran ayuda:



Hunter.io realiza de forma activa escaneos en la red, al estilo de Shodan, pero para almacenar direcciones de email asociadas a un dominio.

Para probar su funcionamiento, buscaremos las cuentas de email asociadas a "eitb.eus":


Y vemos cómo nos devuelve 74 direcciones diferentes:


Además, podremos ver la fuente de donde fue obtenida la dirección de email, con el fin de poder contrastar su veracidad (incluso si el sitio web fue eliminado):



De forma gratuita, podréis realizar hasta 50 consultas al mes. Únicamente debéis registraros con una dirección de email.

Espero que os sea de utilidad.

Saludos!

16 jul 2019

Teleco in a nutshell v4.0: Ruido

¿Recordáis los televisores CRT, cuando emitían esas chiribitas blancas y negras al no tener un canal sintonizado, que siempre nos hacía recordar la película Poltergeist (“Ya están aquíii…”)? Lo que ocurre es que aunque no estemos recibiendo la señal deseada, estamos recibiendo ruido. Definimos ruido como toda aquella señal que no deseamos, y que se mezcla con la señal que queremos transmitir/recibir debido a la propiedad de interferencia entre ondas, concepto que ya introdujimos en un post anterior.

El ruido siempre existe, ya no sólo por otras señales similares que “colisionan” con la nuestra (lo cual comúnmente conocemos como interferencia, en relación con la propiedad física que os acabamos de comentar), sino que existen otras señales generadas de forma natural, que podemos clasificar en dos grupos:
  • Ruido interno: es un ruido que se genera dentro de los equipos que utilizamos para generar y recibir las señales electromagnéticas, y que afectará en mayor medida en las comunicaciones por cable. Es la suma de una serie de ruidos generados por distintos procesos físicos, principalmente por el movimiento de las partículas energéticas (electrones y fotones) y por el efecto de la temperatura.
  • Ruido externo: es aquel ruido que se encuentra en la naturaleza, fuera de los dispositivos de comunicaciones, y el cual afectará en mayor medida en las comunicaciones inalámbricas. A su vez es la suma de diferentes ruidos, donde destacan el ruido industrial (motores, generadores, etc), el ruido atmosférico (generado por las reacciones químicas en la atmósfera y fenómenos meteorológicos como rayos, por ejemplo) y el ruido cósmico (aquel producido por los cuerpos celestes o del espacio profundo).
Como ya hemos mencionado en anteriores posts, el ruido es una señal aleatoria en frecuencia y amplitud (aunque acotada). En el receptor se obtendrán las dos señales mezcladas, y será clave la proporción de potencia entre ambas: la relación señal/ruido (SNR). Si esta proporción es alta, el receptor podrá diferenciar la señal original del ruido. El problema viene cuando la señal emitida va perdiendo potencia por el efecto de la atenuación del canal, ya que mientras esta es cada vez más tenue, el ruido se va sumando de manera constante, haciendo que la SNR vaya siendo peor.
Señal original, ruido e interferencia entre ambas señales [Fuente: Mathworks]
Antes de enseñaros un ejemplo, tenemos que tener en cuenta que las atenuaciones y las diferencias entre señal y ruido generalmente son muy grandes. Una señal puede recibirse miles o millones de veces más tenue de lo que se emitió, y por otro lado es evidente que en el momento de su emisión, la señal será mucho más potente que aquel ruido que pudiéramos recibir del espacio profundo. Por tanto, normalmente no se trabaja con vatios, sino con decibelios (dB), que es una medida que nos indica la relación entre dos valores (de potencia en este caso) en una escala logarítmica. Esto permite que dos señales muy distantes en potencia sean más manejables al trabajar en una escala decibélica. Por ejemplo, cuando decimos que una señal ha perdido 90dB en su transmisión, realmente estamos diciendo que se ha recibido una potencia mil millones de veces menor. 
Fórmula para pasar de vatios a decibelios (logaritmo en base 10)
Estamos acostumbrados a escuchar hablar de decibelios cuando estamos hablando (qué ironía) del ruido que generan ciertas cosas. No obstante, como hemos dicho, los decibelios hablan de la relación entre dos valores, y es que en este caso se está hablando realmente de dB(SPL), que es la diferencia de potencia respecto a una referencia sonora. En transmisiones ocurre lo mismo, cuando hablamos de un valor concreto (por ejemplo, una antena que emite una señal con una potencia de 1W) podemos pasarlo a decibelios tomando como referencia la milésima de vatio, a lo que llamamos dBm (en la fórmula anterior consideramos P2 como 1mW y P1 como 1000mW, obteniendo 30dBm).

Además, por las propiedades matemáticas de los logaritmos, donde antes dividíamos para calcular las pérdidas, ahora restamos decibelios. Por ejemplo, en los casos anteriores hemos hablado de una antena que emite 30 dBm y la señal pierde 90dB en su transmisión. Por tanto, el receptor obtendría -60dBm de potencia de señal. Esto es un nanovatio de potencia recibida, lo cual podemos ver que es extremadamente poco, pero ¿cuánta potencia de ruido se recibe? Pues dependerá de infinitas cosas… Mejor veamos un ejemplo real:
Espectro de una señal en la banda de 554MHz (DBV-T) [Fuente: Flickr-csete]
En la figura anterior podemos ver el espectro recibido de un canal de televisión, donde se aprecia una potencia de señal media recibida de unos -70dBm, junto con un ruido de unos -86dBm. Esto quiere decir que el ruido está unas 40 veces por debajo, o lo que es lo mismo, que la SNR es de 16dB. ¿Este valor es bueno? Pues no se puede saber a priori, ya que dependerá completamente de la calidad del receptor y de la información que estemos enviando.

Para terminar, ¿cómo combatimos el ruido? Por un lado evitándolo, con equipos electrónicos de alta calidad; por otro lado (y mucho más práctico), aumentando la potencia de la señal con amplificadores y reduciéndosela al ruido mediante filtros. Adivinad de qué os vamos a hablar en el próximo post… :)

Muchas gracias por leernos y ¡nos vemos en el siguiente post!


Si os habéis quedado con ganas de más:

15 jul 2019

Herramientas online de cracking de contraseñas. Parte 2

Buenas a todos, hoy damos continuidad a la cadena de artículos sobre herramientas online para el cracking de contraseñas, analizando un nuevo servicio, en esta ocasión, el ofrecido por gpuhash.me:


Este servicio es uno de los más completos que hemos analizado, ya que permite crackear una gran cantidad de hashes muy diferentes (wireless, windows, wallets, office, compresión, etc.)


Su funcionamiento es bastante básico, y de forma sencilla podremos cargar nuestro hash, o lista de hashes, para crackear, indicando el tipo de algoritmo utilizado para su generación:


A continuación, seleccionaremos la técnica que queremos que utilicen para proceder al crackeo. Atentos a esta opción, porque de ella dependerá el precio del servicio. Soportan muchas opciones, desde la fuerza bruta clásica, al uso de diccionarios o de combinaciones de ellos y un sistema experimental llamado "Neural hash search", entre otros:






La petición será encolada, y en función de la prioridad, acelerarán más o menos nuestra petición. Una vez haya concluido, podremos acceder a la contraseña crackeada, mediante el pago del importe indicado.

En todo momento podremos verificar el estado de nuestra petición, mediante la opción "Get result":


Mientras que el servicio que analizamos el otro día, hashkiller.co.uk, es una opción rápida para tratar de extraer contraseñas sencillas, esta herramienta es interesante tenerla en cuenta para aquellos hashes que se resisten.

Saludos!