Fases del PTES desde mi experiencia (parte II)

Continuando la serie que comencé la semana pasada sobre las fases del PTES, hoy os traigo la segunda parte. En este caso, la famosa Intelligence Gathering.

Intelligence Gathering (Recopilación de Inteligencia)

Esta fase es la base de todo pentest. Su objetivo es recopilar la máxima cantidad de información posible sobre el objetivo para identificar todos los vectores de ataque potenciales: físicos, electrónicos y humanos. La profundidad de esta recolección varía en función del tiempo y los objetivos del test, definiéndose comúnmente en tres niveles:

• Nivel 1 (referente al cumplimiento): Se basa principalmente en herramientas automatizadas. Es el mínimo indispensable para afirmar que se ha realizado una recolección de inteligencia.
• Nivel 2 (mejores prácticas): Combina herramientas automatizadas con análisis manual. Incluye una comprensión sólida del negocio, sus ubicaciones físicas, relaciones comerciales y organigrama.
• Nivel 3 (pruebas más avanzadas o Red Team): Incluye los niveles anteriores más un análisis manual intensivo. Puede implicar, por ejemplo, la creación de perfiles falsos en redes sociales para analizar conexiones, un profundo entendimiento de las relaciones comerciales y un gran número de horas de trabajo.

La recolección se divide en dos categorías principales:

OSINT (Open Source Intelligence)

Se trata de obtener información de fuentes públicamente disponibles, sin interactuar directamente con los sistemas del objetivo. Se subdivide en:

• Pasiva: No se envía tráfico alguno al objetivo. Se utiliza información archivada o almacenada por terceros (como resultados de motores de búsqueda en caché), por lo que la información puede estar desactualizada.
• Semi-pasiva: Se interactúa con el objetivo, pero con un comportamiento que se asemeja al de un usuario normal de Internet (consultando servidores DNS públicos, sin escaneos de puertos). El objetivo podría detectar la actividad posteriormente, pero no atribuirla fácilmente a un atacante.
• Activa: Implica un contacto directo y detectable con el objetivo, como escaneos de puertos completos y enumeración de servicios. Esta actividad es claramente identificable como “maliciosa”.

Las áreas de investigación en OSINT son muy amplias:

• Inteligencia corporativa: Ubicaciones físicas, relaciones comerciales (socios, proveedores, competidores…), ofertas de empleo (que revelan tecnologías usadas), informes financieros (como los EDGAR de la SEC), licitaciones públicas (RFP/RFQ), perfiles en redes sociales corporativas y fechas significativas para la empresa.
• Inteligencia electrónica: Metadatos de documentos públicos (que pueden revelar nombres de usuario, rutas internas o versiones de software, entre otras), bloques de red propiedad de la empresa, direcciones de correo electrónico (para listas de usuarios válidos), tecnologías utilizadas, métodos de acceso remoto y huella de infraestructura externa.
• Inteligencia sobre personas: Perfiles de empleados clave en redes sociales (frecuencia de publicación, tono, metadatos en fotos que filtran ubicación), direcciones de correo personal, números de teléfono, nombres de dominio personales y registros públicos, donaciones políticas, licencias profesionales, antecedentes penales.
• Información de pago: Servicios como LEXIS/NEXIS o funciones premium de LinkedIn que ofrecen datos más detallados.

Footprinting

Esta etapa implica una interacción más directa con el objetivo para obtener información técnica.

Footprinting Externo:

• Reconocimiento pasivo: Consultas WHOIS para identificar el propietario de dominios y rangos de IP, y búsquedas BGP para encontrar el Número de Sistema Autónomo (ASN) de la red.
• Reconocimiento activo: Escaneos de puertos (con herramientas como Nmap), captura de banners de servicios, transferencias de zona DNS (AXFR), barridos SNMP y descubrimiento de aplicaciones web y hosts virtuales. El objetivo es establecer una lista priorizada de objetivos externos.

Footprinting interno (si se tiene acceso a la red):

• Aquí las técnicas son similares, pero se amplían para incluir servicios internos como Directorio Activo, sitios de intranet, aplicaciones empresariales (ERP, CRM) y segmentos de red sensibles.

Identificación de mecanismos de protección

Es crucial identificar las defensas del objetivo para planificar evasiones futuras. Esto incluye:

• Protecciones a nivel de red: Firewalls, sistemas de prevención de intrusiones (IPS), sistemas de prevención de pérdida de datos (DLP).
• Protecciones a nivel de host: Antivirus, sistemas de detección de intrusiones basados en host (HIDS), listas blancas de aplicaciones (Whitelisting), protección de ejecución de datos (DEP).
• Protecciones a nivel de aplicación: Web Applications Firewalls (WAF) y opciones de codificación.

El resultado de esta fase debe ser un mapa detallado del objetivo, que incluya activos tecnológicos, relaciones humanas y comerciales, y un inventario de sus defensas, permitiendo así un enfoque de ataque preciso y realista en las fases siguientes. 

Fases del PTES desde mi experiencia

 Hoy voy a intentar "sintetizar" las fases de la guía PTES (Penetration Testing Execution Standar) desde lo que llevo vivido en estos 10 años que ya llevo en ciberseguridad.

Pre-engagement Interactions (la reunión antes de empezar)

Esta es, sin duda, la parte más crítica de todo el pentest y la que más se olvida. No es glamurosa, no hay exploits brillantes, pero es la que evita que te metas en un jaleo legal o que el cliente espere milagros por no dejar las cosas claras.

Imagina que es la planificación de un asalto, pero en lugar de un banco, es una red corporativa. Aquí es donde defines QUÉ se va a atacar y, casi más importante, QUÉ NO.

El Arte de Definir el Alcance (Scoping)

Aquí es donde te sientas con el cliente (a veces, incluso antes de firmar el contrato, pero con un NDA por delante) y descubres qué necesita realmente. Muchas veces el cliente no tiene ni idea de lo que quiere. He llegado a oír: "Quiero que me hackees estas 100 IPs". Y tú, como buen profesional, le tienes que explicar que atacar una aplicación web crítica es un trabajo totalmente distinto a hacer un escaneo superficial de 100 IPs. El precio no puede ser lineal. Es como cobrar lo mismo por dar un paseo en bici que por el Tour de Francia.

Hay que ser su guía y preguntar (entre muchas otras) cosas como: ¿es un test de caja negra (black-box, sin información), gris (grey-box, con algo de info) o blanca (white-box, con acceso total)? Ya que esto cambia totalmente el tipo de auditoría.

La Guía de Preguntas (Cuestionarios)

Este estándar te sugiere una batería de preguntas amplia para hacerle al cliente, organizadas por tipo de test:

• Test de Red: ¿Por qué lo hacen? ¿Es por cumplimiento normativo? ¿Cuántas IPs? ¿Hay firewalls o IDS? Si consigues acceso, ¿hasta dónde quieren que llegues? ¿A por los datos? ¿A por el control total?
• Aplicación Web: ¿Cuántas apps? ¿Cuántos logins? ¿Tendrás acceso al código fuente? ¿Quieren que hagas fuzzing?
• Wireless: ¿Cuántas redes? ¿Cifrado? ¿Hay que buscar dispositivos "trampa" (rogues)?
• Test Físico: ¿Cuántas ubicaciones? ¿Guardias de seguridad? ¿Están armados? ¿Se pueden usar ganzúas? (Ojo con la legalidad).
• Ingeniería Social: ¿Listas de emails o teléfonos para atacar? ¿Está aprobado el acceso físico no autorizado?

La Bestia del "Scope Creep"

Es lo más difícil de organizar en las consultorías. El cliente, contento con tu trabajo, te dice: "Oye, ya que estás, mira también este servidor que no era parte del contrato". Y si no lo controlas, acabas trabajando gratis. La clave es ser firme: cualquier trabajo extra requiere un nuevo acuerdo, un nuevo presupuesto y un nuevo documento firmado. La buena relación con el cliente no significa regalar horas de trabajo.

Temas Peligrosos y Legales (los campos de minas)

• Terceros y la Nube: ¿El cliente usa AWS, Azure o un hosting? Cuidado, porque atacar un servicio en la nube sin el permiso explícito del proveedor es una forma rápida de que te demanden. Amazon, por ejemplo, tiene un formulario específico para esto. Revisa e infórmate de todo antes de liarla.
• Leyes Locales: Si los servidores están en otro país, tienes que conocer sus leyes. Lo que en España es un test, en Alemania puede ser un delito.
• Denegación de Servicio (DoS): ¿Está aprobado? La mayoría de las empresas le tienen pánico porque puede tumbar sistemas de producción. Normalmente, solo se hace en entornos de pruebas. Es importarte reflejarlo.
• Ingeniería Social: Los pretextos (las excusas que usas) deben ser aprobados por escrito. Nada de pretextos de pornografía o drogas a menos que el cliente lo autorice explícitamente (y sea relevante).
• Información Sensible: Durante el test, puedes encontrarte con datos de tarjetas de crédito, historiales médicos (PHI) o información personal identificable (PII). El estándar es claro: evita visualizar o descargar estas cosas si no quieres tener problemas. Demuestra el acceso con una captura de pantalla que no muestre los datos reales. Es un riesgo legal enorme para ti.

Reglas de Compromiso (Rules of Engagement)

Si el Alcance es el QUÉ, las Reglas de Compromiso son el CÓMO. Aquí defines la línea de salida y la de meta, los horarios de ataque (¿en horario de “oficina” o por la noche?), cómo manejar la información sensible, y el documento más importante de todos: el "Permission to Test". Este documento, firmado por el cliente, es tu escudo legal. Dice que ellos son conscientes de que les vas a atacar y que no te van a demandar si se cae un servidor (aunque harás todo lo posible para evitarlo).

Comunicación y Objetivos

Establecer líneas de comunicación claras es vital. ¿A quién llamas si tiras un servidor de producción a las 3 de la mañana? Hay que tener una lista de contactos de emergencia 24/7. Y, por último, definir los objetivos. Un test no es solo parchear sistemas. Es entender el riesgo para el negocio. El objetivo principal no debería ser "cumplir con PCI-DSS", sino "evitar que un atacante robe la base de datos de clientes y nos lleve a la quiebra".

En resumen, la fase de Pre-engagement es donde dejas de ser un técnico y te conviertes en consultor. Es donde ganas o pierdes al cliente, y donde te proteges a ti y a tu empresa de un mundo de dolor.

Si veo que tiene suficiente apoyo, iré subiendo el resto de fases.

"Consumo" de APIS

 Con este título pareciese que os voy a hablar de una riquísima merienda de los 80 y 90, pero no, en este caso, Una API (Interfaz de Programación de Aplicaciones) es un conjunto de reglas y protocolos que permite a las aplicaciones de software comunicarse entre sí, compartir datos y funcionalidades.

Para intentar explicar esto, para la gente a la que le suena más a la merienda, precisamente voy a usar una analogía de un restaurante.

Imagina que entras en un restaurante.

1. Tú (El Cliente): Eres la aplicación que quiere algo (por ejemplo, un programa de Python, una app móvil, o incluso una página web con JavaScript).
2. La Cocina (El Servidor): Es donde está todo lo bueno: los datos, la lógica de negocio, la base de datos. Es el "cerebro" que tiene la información que tú quieres. No puedes entrar directamente a la cocina a coger cosas.
3. El Menú (La Documentación de la API): Es una carta donde se explica qué platos (datos o servicios) puedes pedir. Te dice el nombre de cada plato, los ingredientes (los parámetros que necesitas especificar) y cómo viene presentado (el formato de la respuesta).
4. El Camarero (La API REST): Este es el personaje clave. El camarero es la API. Es el intermediario que toma tu pedido, se lo lleva a la cocina, y te trae la respuesta.

Vale, y ahora, ¿qué es lo de REST?

REST (Representational State Transfer) es simplemente un conjunto de reglas de etiqueta o un protocolo de buenas maneras que sigue el camarero para que la comunicación sea eficiente y todo el mundo se entienda. Define cómo debes hacer el pedido para que la cocina te entienda perfectamente.

Resumen de la analogía: Tú (el cliente) le haces un pedido (una solicitud HTTP) al camarero (API REST) según lo que pone en el menú (documentación), el camarero se lo lleva a la cocina (servidor), que prepara tu plato (los datos), y el camarero te lo sirve en la mesa (la respuesta).

La Solicitud HTTP (Los Ingredientes de un Pedido)

Para que tu pedido al camarero (la solicitud a la API) sea perfecto, debe estar bien formada. Se componen de lo que llamamos un verbo HTTP y un Endpoint.

1. El Endpoint (la dirección del restaurante y la mesa): Es la dirección única a la que tienes que enviar tu solicitud. Normalmente, es una URL como las siguientes:

• https://api.mitienda.com/v1/productos
• https://api.twitter.com/2/tweets/search/recent

2. El Verbo HTTP (la acción que quieres hacer): Esto le dice al camarero qué quieres hacer exactamente. Los verbos son como las palabras mágicas.

• GET (Coger/Obtener): El más común. Es como decir "Tráeme...". Se usa para solicitar y recuperar datos, sin modificar nada en el servidor.

Ejemplo: GET https://api.mitienda.com/v1/productos -> "Tráeme la lista de productos."

• POST (Enviar/Crear): Es como decir "Toma, guarda esto". Se usa para crear un nuevo recurso. Lleva un "cuerpo" (body) con la información del nuevo elemento.

Ejemplo: POST https://api.mitienda.com/v1/productos -> "Aquí tienes los datos de un producto nuevo, guárdalo en la cocina (base de datos)." (El cuerpo llevaría el nombre, precio, etc.).

• PUT/PATCH (Actualizar): Es como decir "Quiero modificar este plato que ya pedí". Se usa para actualizar un recurso existente. PUT suele ser para reemplazarlo completamente y PATCH para modificar solo una parte.

Ejemplo: PATCH https://api.mitienda.com/v1/productos/123 -> Con esto le decimos: "Cambia el precio del producto con ID 123 a 29.99€"

• DELETE (Borrar): Muy claro. "Borra este plato de la cuenta". Se usa para eliminar un recurso.

Ejemplo: DELETE https://api.mitienda.com/v1/productos/123 -> En este caso le pedimos que borre algo: "Elimina el producto con ID 123."

3. Los Headers (son las instrucciones especiales para el camarero): Son metadatos o información adicional sobre tu solicitud. Van "por detrás", no son el pedido en sí, sino instrucciones sobre cómo hacerlo.

• Authorization: La más importante. Es como mostrar tu carnet de socio o tu reserva. Lleva una credencial (normalmente un "API Key" o un token) que le dice al servidor "Oye, soy yo, tengo permiso para estar aquí".

Ejemplo: Authorization: Bearer TU_TOKEN_SECRETO_AQUI.

• Content-Type: Le dice al camarero en qué formato le estás entregando la información si estás haciendo un POST o PUT. Lo más común es application/json (hablaremos de JSON luego).

4. El Body (este es el cuerpo, el pedido en sí mismo): Solo se usa con POST, PUT y PATCH. Es donde metemos los datos que quieres enviar para crear o actualizar. Si en GET le dices "tráeme una pizza", en POST le dices "quiero crear una pizza con estos ingredientes: masa fina, extra de queso, jamón...".

La Respuesta HTTP (La Respuesta del Camarero)

El camarero siempre vuelve con una respuesta. Esta respuesta tiene dos partes fundamentales:

1. El Código de Estado HTTP (es el estado de tu pedido): Un número de 3 dígitos que te indica claramente si todo fue bien o si hubo un problema. Es crucial saber leerlos.

• Todo bien (2xx): 200 OK: Tu pedido llegó y tienes lo que querías. 201 Created: ¡Creado! Se ha creado un nuevo recurso con tu petición POST.
• Errores del Cliente (4xx): 400 Bad Request: Has hecho un pedido mal formado (falta un parámetro, el body está mal, etc.). 401 Unauthorized: No tienes permiso. Tu API Key o token es inválido. 403 Forbidden: Tienes credenciales, pero no suficientes permisos para hacer esa acción concreta. 404 Not Found: El recurso que pides (el endpoint o el ID del producto) no existe.
• Errores del Servidor (5xx): 500 Internal Server Error: El problema está en la cocina (el servidor). No es culpa tuya.

2. El Body de la Respuesta (Los Datos - El Plato): Aquí es donde vienen los datos que pediste. El formato más común (con diferencia), es JSON (JavaScript Object Notation). Es un formato muy fácil de leer tanto para humanos como para máquinas. Se parece a los objetos en JavaScript o los diccionarios en Python.

Ejemplo de respuesta a una petición GET a: https://api.mitienda.com/v1/productos/123:

json
{
  "id": 123,
  "nombre": "Zapatillas Running Ultra",
  "precio": 89.99,
  "enStock": true,
  "categorias": ["deporte", "running"]
}

¿CÓMO se Hace Este Consumo? (Programas y Código)

Aquí viene la parte práctica. "Consumir una API" significa, a nivel técnico, escribir código que envíe estas solicitudes HTTP y procese las respuestas.

1. Herramientas para Probar y Jugar (Fundamentales):

• Postman: Es el rey. Es una aplicación de escritorio que te permite construir solicitudes HTTP (GET, POST, etc.) de forma muy visual. Puedes poner los endpoints, los headers, el body, etc., y ver la respuesta. Es IMPRESCINDIBLE para probar APIs antes de escribir código.
• Thunder Client (una extensión de VSCode) es una alternativa similar.
• cURL: Es un comando que viene en la terminal (Linux y Mac) o en el Prompt de Windows. Es la forma más "pura" y universal de hacer una petición HTTP.

Ejemplo en bash:

curl -X GET "https://api.mitienda.com/v1/productos" -H "Authorization: Bearer TU_TOKEN"

2. Lenguajes de Programación para Automatizar (donde se usa de verdad):

En un trabajo real, no vas a estar haciendo peticiones a mano con Postman todo el día. Integrarás el consumo de la API en tu aplicación. Casi cualquier lenguaje moderno puede hacerlo.

• Python (El Más Amigable): Con la librería requests es absurdamente fácil.

python
import requests

url = "https://api.mitienda.com/v1/productos"
headers = {"Authorization": "Bearer TU_TOKEN"}

respuesta = requests.get(url, headers=headers) # Hace la solicitud GET

datos = respuesta.json() # Convierte la respuesta JSON en un diccionario de Python

for producto in datos['productos']:

    print(producto['nombre'], producto['precio'])

• JavaScript (para web y Node.js): Se usa la función fetch() (nativa) o librerías como axios.

javascript

// Con fetch (en un navegador o Node.js moderno)
fetch('https://api.mitienda.com/v1/productos', {
  headers: { 'Authorization': 'Bearer TU_TOKEN' }
})
.then(response => response.json())
.then(data => console.log(data));

Java, C#, PHP, Go, etc.: Todos tienen sus librerías (como HttpClient en Java, RestSharp en C#...) para hacer exactamente lo mismo.

Recapitulando, necesitamos que sepas:

1. Leer y entender una documentación técnica (el menú del restaurante).
2. Obtener datos de un servicio externo (usando GET).
3. Enviar datos para crear nuevos registros (usando POST).
4. Actualizar y borrar información existente (usando PUT/PATCH y DELETE).
5. Manejar la autenticación (usando API Keys o Tokens en los Headers).
6. Interpretar los códigos de respuesta para manejar errores correctamente.
7. Procesar los datos que vienen en formato JSON.
8. Usar herramientas como Postman para pruebas y un lenguaje de programación (como Python con requests) para integrar todo esto en una aplicación real.

Y hasta aquí el símil de hoy de las APIs con un restaurante. Espero que haya sido fácil de seguir.