# Reconocimiento externo & OSINT

## <mark style="color:red;">Whois</mark>

WhoisXMLAPI

<https://whois.whoisxmlapi.com/>

Se puede obtener el whois de un dominio realizando la siguiente consulta a la API:

```bash
curl --location 'https://www.whoisxmlapi.com/whoisserver/WhoisService' \
    --header 'Content-Type: application/json' \
    --data '{
        "domainName": "dominio.com",
        "apiKey": "<TUAPIKEY>",
        "outputFormat": "JSON"
    }'
```

Con el siguiente mini-script de bash se puede automatizar la obtención de los registros Whois de una lista de dominios objetivos.

Para ello, hay que sustituir en la variable `data` el valor de la APIKey por la de una cuenta de WhoisXMLAPI.

{% code overflow="wrap" %}

```bash
for i in $(cat domains.txt); do ts=$(date +%Y%m%d); data="{\"domainName\": \"$i\", \"apiKey\": \"<TUAPIKEY>\", \"outputFormat\": \"JSON\"}"; curl -s --location 'https://www.whoisxmlapi.com/whoisserver/WhoisService' --header 'Content-Type: application/json' --data "$data" -o "${ts}_${i}whoisxmlapi.json"; echo "Guardado: ${ts}${i}_whoisxmlapi.json"; done
```

{% endcode %}

En el siguiente enlace, tras haber iniciado sesión, se puede obtener el valor de nuestra APIKey:

<https://whois.whoisxmlapi.com/documentation/making-requests>

## <mark style="color:red;">Enumeración de dominios</mark>

### WhoIsXMLApi

Si por ejemplo, conociendo el nombre de la organización y usando, además, el nombre que usa la organización para registrar dominios que sepamos que les pertenecen, se pueden buscar otros dominios asociados a la misma organización.

<https://tools.whoisxmlapi.com/reverse-whois-search>

### Obtención de IPs

{% code overflow="wrap" %}

```bash
echo "domain,ip" > domain_ips.csv && for d in $(cat domains.txt); do ips=$(dig +short "$d" | tr '\n' ' ' | sed 's/ *$//'); [[ -z "$ips" ]] && ips="NA"; echo "$d,\"$ips\"" >> domain_ips.csv; done
```

{% endcode %}

## <mark style="color:red;">Enumeración de subdominios</mark>

### WhoIsXMLApi

<https://tools.whoisxmlapi.com/domains-subdomains-discovery>

<figure><img src="https://940481291-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FFPk1C70Fp5SRurFLmfzj%2Fuploads%2FpAY5d5alKvLB9xR0jQQz%2Fimage.png?alt=media&#x26;token=14bf92f8-8f0c-4e4b-b0e3-1b15fc1800ee" alt=""><figcaption></figcaption></figure>

O usando la API:

<https://domains-subdomains-discovery.whoisxmlapi.com/api/documentation/making-requests>

{% code overflow="wrap" %}

```bash
curl -s -X POST "https://domains-subdomains-discovery.whoisxmlapi.com/api/v1" \
  -H "Content-Type: application/json" \
  -d '{ "apiKey": "<TUAPIKEY>", "domains": { "include": [ "dominio.com" ] }, "subdomains": { "include": [ "*" ] } }'
```

{% endcode %}

### ProjectDiscovery Cloud Platform

```
https://cloud.projectdiscovery.io/assets/domain/<dominio>
https://cloud.projectdiscovery.io/assets/domain/hubspot.com
```

### Bevigil

<https://bevigil.com/osint-api>

### crt.sh

```
https://crt.sh/?q=%25.<dominio>
https://crt.sh/?q=%25.xtormin.com
```

### Subfinder

<https://github.com/projectdiscovery/subfinder>

```bash
subfinder -d xtormin.com -silent
```

### Subfinder + httpx

<https://github.com/projectdiscovery/httpx>

```bash
subfinder -silent -d xtormin.com | httpx -silent
subfinder -silent -d xtormin.com | httpx -silent > discover/urls-xtormin.com.txt
```

{% code overflow="wrap" %}

```bash
subfinder -silent -d xtormin.com | httpx -silent | nuclei -t technologies/tech-detect.yaml
```

{% endcode %}

### gau

<https://github.com/lc/gau>

Obtener URL conocidas de Open Threat Exchange de AlienVault, Wayback Machine y Common Crawl.

```bash
gau ejemplo.com > urls.txt
```

Se ejecuta el comando anterior y luego se filtran esas URLs (por ejemplo, quedarse con aquellas con parámetros `?=`) y pasarlas a Nuclei.&#x20;

¿Por qué? Porque en esas rutas a veces hay endpoints antiguos. Un caso práctico: extraer todas las URLs de `ejemplo.com` con `gau`, luego ejecutar plantillas de **exposures** sobre ellas (buscando si algún endpoint `/dev/` o parámetros de debug están accesibles). Esto puede revelar API ocultas o páginas de administración a las que ya no se enlaza, pero siguen activas.

### katana

<https://github.com/projectdiscovery/katana>

Es un **web crawler** rápido de ProjectDiscovery. Tras identificar un host interesante, se puede ejecutar el comando anterior para descubrir rutas internas (por ejemplo, enlaces o endpoints en el código JavaScript) y luego alimentar esos resultados a Nuclei.&#x20;

```bash
katana -u https://ejemplo.com
```

Katana encuentra cosas que gau (pasivo) no ve, ya que explora la aplicación en tiempo real. Integrando Katana con Nuclei, se logra un **fuzzing dirigido**: primero se rastrea la superficie del sitio, luego se escanean esos descubrimientos con plantillas. Por ejemplo, si Katana descubre un `/api/v2/internal/test`, se puede inmediatamente correr plantillas de API genéricas sobre ese endpoint para ver si hay configuraciones inseguras o métodos HTTP habilitados inesperadamente.

### qsreplace

Esta herramienta reemplaza valores de parámetros en una lista de URLs con un payload deseado. Es útil para pruebas de inyección.&#x20;

Un ejemplo: supongamos que con gau/katana se obtuvo una lista de URLs con parámetros (`urls_con_params.txt`). Un hunter podría usar `qsreplace` para inyectar un payload XSS en todos esos parámetros de golpe:&#x20;

{% code overflow="wrap" %}

```bash
cat urls_con_params.txt | qsreplace '"><img src=x onerror=alert(1)>' > xss_test_urls.txt
```

{% endcode %}

Luego ese archivo `xss_test_urls.txt` se pasa a Nuclei con una plantilla de detección de XSS reflejado. La plantilla comprobaría si la cadena `"><img src=x onerror=alert(1)>` aparece en la respuesta sin escapar, indicando vulnerabilidad. De esta manera, **Nuclei se convierte en el motor de verificación**, mientras que herramientas como qsreplace generan variaciones de los inputs. Similarmente, qsreplace se puede usar para SSRF (reemplazando parámetros `url=` con un dominio *collaborator* y usando Nuclei/Interactsh para detectar salida), o para LFI (reemplazando parámetros `file=` con `../../../../etc/passwd` y buscando la respuesta).

### Concatenación de herramientas

*Dnsx* puede resolver masivamente subdominios (por si subfinder entrega resultados sin IP); *Naabu* para detectar puertos abiertos no estándar (por ejemplo aplicaciones corriendo en 8080, 8443, etc., que Httpx luego convierte a URLs para Nuclei); *Katana headless* para escenarios con heavy JavaScript; *ParamSpider/GF* para encontrar parámetros candidatos a inyección, etc. En general, Nuclei se coloca al final de estas cadenas: **consume los datos que otras herramientas producen** (URLs, parámetros, hosts) y realiza los chequeos de vulnerabilidades en base a sus plantillas.

### Parseado de información

Extraer subdominios de una lista de URLs:

{% code overflow="wrap" %}

```bash
cat subfinder_output.txt | awk -F/ '{print $3}' | sort -u > subdomains.txt
```

{% endcode %}

## Enumeración de redes (PTR)

```bash
echo "173.0.84.0/24" | dnsx -silent -resp-only -ptr
```

## Enumeración de organizaciones y ASN

<https://github.com/j3ssie/metabigor>

```bash
echo "organización" | metabigor net --org -o org-data.txt
```

```bash
echo AS17012 | dnsx -silent -resp-only -ptr
```

## Subdomain Takeover

### Condiciones de explotación

Condiciones:

1. El subdominio existe y apunta a un servicio externo.
2. El recurso en el proveedor externo no está activo o no ha sido creado.
3. El proveedor permite reclamar ese nombre sin verificación adicional.
4. El DNS sigue apuntando al servicio (registro activo).

{% hint style="warning" %}
Si se apunta un wildcard a un servicio (ej: `*.example.com` → `myapp.herokuapp.com`) y **no se reclaman explícitamente** los subdominios, el atacante puede crear uno arbitrario.
{% endhint %}

**Condición 1**

El subdominio (`sub.example.com`) tiene un registro DNS que apunta a un proveedor externo mediante un **registro CNAME o A**.

Algunos ejemplos:

| Subdominio           | Registro DNS                    | Servicio externo     |
| -------------------- | ------------------------------- | -------------------- |
| `blog.example.com`   | CNAME → `example.github.io`     | GitHub Pages         |
| `app.example.com`    | CNAME → `app.herokuapp.com`     | Heroku               |
| `shop.example.com`   | CNAME → `shops.myshopify.com`   | Shopify              |
| `status.example.com` | CNAME → `example.statuspage.io` | Atlassian Statuspage |

**Condición 2**

La cuenta, repositorio, app o recurso **ya no existe** en el proveedor (o nunca fue creado), pero el subdominio **sigue apuntando allí**.

Ejemplo:

```bash
dig blog.example.com CNAME +short
# example.github.io.
```

Y si visitas `blog.example.com`, obtienes algo como:

```
There isn't a GitHub Pages site here.
```

**Condición 3**

El servicio **no requiere validación de propiedad del dominio** para aceptar el subdominio apuntado por DNS.\
Esto permite a un atacante **registrar un nuevo recurso con ese nombre** y automáticamente tomar control del subdominio.

🔧 *Ejemplo real:*

* El atacante crea `example.github.io` → GitHub lo acepta sin verificación.
* El CNAME ya existe → `blog.example.com` carga el sitio del atacante.

**Condición 4**

Aunque el recurso externo fue eliminado, el **registro DNS sigue presente**, por lo tanto el atacante no necesita acceso a la cuenta original, solo al servicio.

### Identificación de recursos vulnerables

{% code overflow="wrap" %}

```bash
subjack -w subdomains.txt -t 50 -timeout 10 -o subdomains_takeovers_vuln_subjack.txt -ssl

nuclei -l subdomains.txt -t takeovers -silent -o subdomains_takeovers_vuln_nuclei.txt
```

{% endcode %}