Purple Team: ¿pero esto qué es? (III). Vectr.io

Como ya podéis suponer por anteriores spoilers, en esta tercera parte de la serie (ver primera parte y segunda parte), tras haber dejado claro el papel que juega la Inteligencia de Amenazas en la metodología Purple Team, entraremos un poco más en detalle sobre las fases de preparación, ejecución y lecciones aprendidas en un ejercicio.

Disclaimer: Como ya comenté en el primer episodio, no pretendo sentar cátedra con este artículo sino más bien, aportar mi punto de vista y aportar una visión de conjunto sobre el un tema del que no se encuentra gran cantidad de documentación (sobre todo en español), y la que se encuentra, está dispersada en múltiples fuentes.

Tras haber desarrollado un plan de ejecución tomando como referencia el mapeado de las amenazas sobre la MITRE ATT&CK MATRIX, es hora de llevar a la práctica todos los casos de uso. Para ello usaremos Vectr.io, una plataforma web de código abierto desarrollada por Security Risk Advisors.

Esta herramienta se encarga de centralizar todas las tareas de coordinación de los equipos Red y Blue. Pero lejos de ser una herramienta solo para coordinar los ejercicios, también está preparada para ser utilizada como una suerte de bitácora de todas las operaciones ejecutadas en diversos ejercicios a lo largo del tiempo, de forma que se pueda realizar un seguimiento de la evolución de la postura de seguridad de la organización a lo largo del tiempo.

Con una descripción abstracta como la anterior, puede ser difícil imaginar cómo se consigue todo esto. Por ello, el objetivo de este post es optar por un enfoque más práctico.

En aras de la brevedad, no vamos a entrar en detalle de todas las funcionalidades de esta herramienta sino que mostraremos las posibilidades que ofrece y como estas nos pueden ayudar con nuestro objetivo. Será de ahí en adelante tarea de cada uno explorar las funciones más avanzadas y evaluar si le son útiles para su caso particular.

[Read more…]

Evadiendo el antivirus mediante Early Bird y Syscalls

Uno de los problemas que se intentan evitar durante el desarrollo de un proyecto Red Team es generar alertas que puedan hacer sospechar al Blue Team que un activo ha sido comprometido. En este tipo de proyectos la discreción es fundamental.

Es probable que, si se levantan suficientes sospechas, el Blue Team actúe y se pierda un punto de entrada ya conseguido. Puede que sea incluso necesario reconstruir toda la infraestructura de ataque (probablemente el Blue Team obtendrá IOCs y marcará como maliciosos las IPs, dominios, artefactos, etc. que se estén utilizando). Incluso tras reconstruir la infraestructura de ataque, puede que resulte muy difícil encontrar otro punto de entrada.

Por este motivo, uno de los aspectos que es necesario tener en cuenta en el desarrollo de los artefactos que se preparen para el ejercicio es la evasión del antivirus. Las técnicas de detección utilizadas por los servicios de antivirus instalados en los equipos de usuario van mejorando mucho con el tiempo, principalmente con la incorporación del análisis en la nube.

No obstante, las técnicas utilizadas por los profesionales que trabajan en la parte ofensiva y, cómo no, también por los atacantes reales, también han mejorado notablemente, obligando a mejorar continuamente las protecciones y formas de detección.

En este artículo se comentan un par de técnicas que se explican en profundidad en los cursos RED TEAM Operator: Malware Development Essentials y Intermediate Course del Sektor7 Institute, cursos muy recomendables ya que tienen un temario variado y son muy prácticos.

El código utilizado en los ejemplos de este artículo está basado en el que se presenta en estos dos cursos.

Early Bird es una técnica de inyección de código que hace uso del mecanismo implementado en Windows para las llamadas asíncronas a procedimientos, también conocido como APC o Asynchronous Procedure Calls. Esta funcionalidad permite la ejecución asíncrona de código en el contexto de un determinado proceso y resulta interesante porque puede ser utilizada para la ejecución de código malicioso antes de que llegue a ejecutarse el punto de entrada del hilo principal del proceso original.

[Read more…]

Steal ’em all! Token impersonation

Durante un proceso de intrusión, el robo de Tokens y la impersonación de usuarios nos puede ser de gran ayuda, ahorrándonos mucho tiempo y favoreciendo el permanecer lo más sigilosos posibles utilizando tan solo las capacidades y herramientas que el propio sistema operativo Microsoft Windows nos ofrece.

Antes de comenzar y a modo de recordatorio, un Token dentro del sistema operativo Microsoft Windows es un elemento de seguridad que dota de identificación a procesos e hilos cuando estos quieren realizar acciones sobre objetos securizables del sistema (ficheros, registros, servicios…).

En las siguientes líneas vamos a ver cómo es posible robar el Token de casi cualquier proceso en ejecución en el equipo utilizando tan solo dos técnicas diferentes, siempre y cuando tengamos los privilegios y permisos necesarios para poder llevarlo a cabo.

Como todo en este mundo parte de un trabajo previo, el reto y la inspiración de la investigación partió de este magnífico post de Justin Bui (@slyd0g) de SpecterOps, del que rebatiremos algunas de sus conclusiones, así como el de Chintan Shah de MacAfee  “Technical Analysis of Access TokenTheft and Manipulation”, el cual referencia al primero.

Pero ¿por qué nos puede interesar robar un token de un proceso o hilo concreto del sistema?

La respuesta rápida y corta es para elevar privilegios y realizar acciones que con el token actual no podemos llevar a cabo o para movernos lateralmente hacia otro equipo de la red. Un ejemplo de lo primero lo tenéis en el anterior post “TrustedInstaller, parando Windows Defender”, aunque ahora veremos alguno más.

[Read more…]

Mythic

NOTA: El contenido de este artículo es educativo e informativo. El objetivo es aprender cómo funciona la aplicación Mythic y cómo identificar sus capacidades. El autor no se hace responsable de una mala utilización de la información aquí expuesta ni las consecuencias legales que se pudieran derivar de ella.

¿Qué es Mythic?

Mythic es una plataforma de código abierto que busca proporcionar un entorno para las fases de post explotación de C2 (Comando y control).

Entre sus características destaca que es altamente personalizable, rápidamente desplegable, modular y pensado para el trabajo de múltiples operadores al mismo tiempo.

Mirando con lupa

Mythic se compone de diferentes servicios que conforman el conjunto de funcionalidades que es la plataforma.

[Read more…]

Purple Team: ¿pero esto qué es? (II). Threat Intelligence

Tras haber hecho una introducción y exposición somera de la metodología Purple Team y enumerado las fases que la componen en la primera parte de esta serie, en esta segunda voy a entrar en más detalles sobre cómo se integra la inteligencia de amenazas (Cyber Threat Intelligence o CTI) en todo el proceso de emulación adversarial, y por ende, en los ejercicios o programas Purple Team.

Lo primero: entender la organización objetivo

Tanto si se está realizando CTI como consultor externo como si se forma parte de la organización, es importante contar con la mayor información posible sobre la organización.

Para ello, el equipo de CTI debe llevar a cabo un intenso y extenso ejercicio de obtención de información, de la misma forma que la obtendría un agente de amenazas enemigo. Además de esto, la información debe enriquecerse con la obtenida mediante entrevistas y consultas al personal de la organización.

El objetivo es identificar la superficie de ataque de las personas, procesos, tecnologías y sistemas que forman parte de la huella digital de la organización para crear una visión preliminar de la exposición desde la perspectiva del atacante, y contribuir así al descubrimiento de posibles escenarios de ataque que se incluirán en el informe de CTI.

Identificar el adversario a emular

[Read more…]

Deconstruyendo la gestión de riesgos (I): el riesgo inherente

Los seres vivos somos expertos en gestionar riesgos. Es algo que hemos hecho a lo largo de millones de años. Se llama, entre otras cosas, instinto de supervivencia. No estaríamos aquí si se nos diera mal.

Los evitamos, los mitigamos, los externalizamos, los asumimos.

Por ejemplo, ¿va a llover hoy? Si llueve, ¿cuánto va a llover? ¿Me llevo el paraguas? ¿Me quedo en casa? ¿Me encontraré con un atasco de camino al trabajo? ¿Llegaré tarde a la reunión? ¿Llamo para avisar? ¿Intento posponer la reunión? ¿Pincharé una rueda de camino a casa? ¿Cuándo fue la última vez que revisé la rueda de repuesto? ¿He pagado la prima del seguro? ¿Cuál es la cobertura de asistencia en carretera?

Todos esos procesos cotidianos de identificación y valoración de riesgos los realizamos de manera inconsciente a diario, y aplicamos medidas de gestión del riesgo sin apenas darnos cuenta. Cogemos un paraguas, llamamos a la oficina para avisar del retraso, asistimos a la reunión por teléfono, salimos antes de casa o decidimos coger el transporte público. Evidentemente, no siempre es tan sencillo.

Sin embargo, cuando nos trasladamos al entorno corporativo, empezamos con la tolerancia al riesgo, los criterios de probabilidad, impacto y vulnerabilidad, los catálogos de amenazas (estándar), las estrategias, los registros de riesgo, el riesgo inherente, residual y proyectado, los ratios de mitigación. Y nos perdemos durante meses en conceptos, documentos y metodologías, alejándonos cada vez más de la realidad que tenemos que analizar y proteger.

La ortodoxia en la gestión de riesgos (de ciberseguridad)

A raíz de esto, hace ya unos meses, en plena pandemia, fui a topar con un interesante artículo que contraponía dos visiones muy diferentes de la gestión de riesgos, que venía a llamar RM1 vs RM2.

Básicamente, y citando directamente del artículo, RM1 estaría enfocado a la “gestión de riesgos para las partes interesadas externas (Consejo, auditores, reguladores, gobierno, agencias de calificación crediticia, compañías de seguros y bancos)“, mientras que RM2 sería la “gestión de riesgos para los responsables de la toma de decisiones dentro de la empresa“.

Algunas semanas o meses después, Román Ramírez publicaba una entrada en una línea similar, criticando la ortodoxia reinante en la gestión de riesgos de ciberseguridad y los problemas que esta generaba.

[Read more…]

Purple Team: ¿pero esto qué es? (I)

A menudo leemos o escuchamos términos como Red, Blue, Purple, Adversarial Emulation y muchas otras de forma casi intercambiable, lo que produce confusión en la gente que se aproxima a este mundo.

Todas estas disciplinas, a menudo solapadas parcialmente entre ellas en su ámbito de aplicación, tienen su lugar en el plan de seguridad de una organización, pero conviene tener claros sus puntos fuertes y débiles para aprovechar los primeros y minimizar los segundos.

A lo largo de este artículo, o serie de ellos (a ver hasta donde me lleva la madriguera del conejo), intentaré aportar mi granito de arena en este tema haciendo una introducción al tema y detallando después con algo más de profundidad la metodología Purple Team.

Es conveniente aclarar que este artículo no pretende sentar cátedra sobre el asunto y solo tiene como objetivo hacer una exposición didáctica y lo menos árida posible.

Algunos antecedentes

Según las organizaciones han ido madurando y la ciberseguridad va cobrando importancia, se han ido implementando diferentes metodologías y enfoques.

Hace bastantes años (y desgraciadamente también en algunas organizaciones actualmente) la ciberseguridad se reducía a medidas de hardening (bastionado), y gradualmente se empezaron a desarrollar tecnologías de detección y respuesta.

[Read more…]

Nueva vulnerabilidad 0-day en los servidores apache

En esta entrada vamos a comentar la nueva vulnerabilidad descubierta hace tan solo unos días, que afecta a los servidores Apache que se encuentren en la versión 2.4.49.

Esta vulnerabilidad, del tipo Path traversal, o salto de directorio en castellano, se basa en un fallo a la hora de la normalización de rutas en el servidor, permitiendo a un atacante externo leer cualquier archivo incluso fuera del Document Root, aunque para esto, se tiene que dar la situación en la que los archivos fuera del Document Root no estén protegidos por la directiva ‘require all denied‘. Este fallo puede ser utilizado para filtrar el código fuente de archivos interpretados como scripts CGI.

Esta vulnerabilidad ha sido registrada con el CVE-2021-41773.

La explotación de esta vulnerabilidad es relativamente sencilla, tal y como puede verse en la siguiente prueba de concepto:

[Read more…]

Omnium contra Omnes (II): Hacia el realismo político

En el anterior artículo comentábamos el impacto que ha tenido la posibilidad de anonimato en el ciberespacio. En este post vamos a indagar en esta cuestión y exponer los detalles que explican la existencia del anonimato, así como las consecuencias en el contexto geopolítico.

Anonimato

Los cinco factores imposibilitan la atribución directa de una acción de ciberguerra a una nación son los siguientes:

1. Que el medio virtual esté conformado por información permite a todo tipo de usuarios disponer de la posibilidad de la creación y modificación de artefactos, únicamente limitado por los permisos. Esto conduce a que no exista una traslación completa del elemento físico al virtual y, por tanto, no se dispone del control total del mismo. En consecuencia, no es posible garantizar la inmutabilidad de los elementos del entorno, es decir, qué acciones se han realizado o quién las realiza.

2. Existe la imposibilidad fáctica de la asignación de un perfil virtual de una nación. Los problemas vinculados a la atribución, fundamentados en el punto anterior, imposibilitan la relación de dos campañas separadas en el tiempo solo a partir de sus tácticas, técnicas y procedimientos. Incluso a pesar de contar con un indicador como el hash, no existe garantía al 100% de que se trata exactamente del mismo actor, pues el código podría haber sido robado o manipulado con anterioridad.

[Read more…]

10 consejos para asegurar los datos alojados en Amazon S3

El uso de Amazon Simple Storage Service S3 está cada vez más extendido, utilizándose en multitud de casos de uso: repositorios de datos sensibles, almacenamiento de logs de seguridad, integración con herramientas de backups…, por lo que debemos tener especial atención en la forma en la que configuramos nuestros buckets y como los exponemos a internet.

En este post hablaremos sobre 10 buenas prácticas de seguridad que nos permitirán gestionar de una forma correcta nuestros buckets S3.

Empecemos.

1 – Bloquea el acceso público a los buckets de S3 en toda la organización

Por defecto los buckets son privados y únicamente pueden ser utilizados por los propios usuarios de nuestra cuenta, siempre que tengan establecido correctamente los permisos para ello.

Adicionalmente, los buckets tienen una opción “S3 Block Public Access” que impide que los buckets puedan ser considerados públicos. Esta opción se puede activar o desactivar en cada bucket de la AWS Account. Para prevenir que un usuario pueda desactivar dicha opción, podemos crear una política SCP en nuestra organización para que ninguna AWS Account miembro de la organización pueda hacerlo.

[Read more…]