Es sábado por la mañana y la oficina de la auditoría está casi vacía. En la mesa tienes el encargo firmado de la Gestoría Prado, la del susto de aquella noche: quieren saber qué se ve de ellos desde Internet antes de que lo vea otro. Hoy no defiendes un servidor: lo miras desde fuera, con permiso, apuntas lo que encuentras y se lo cuentas para que lo arreglen.
Esto es un Red Team, y lo que lo separa de un delito no es la habilidad: es el papel que tienes
encima de la mesa. En este tema aprendes a leerlo, a barrer un bloque de direcciones con nmap, a
distinguir los tres estados de un puerto, a ver qué cuesta cada forma de preguntar y a leer una
versión a mano. Y lo primero es lo del papel.
Antes de tocar nada, el contrato
Una auditoría empieza con un encargo: alguien que es dueño de unos equipos (o responde por ellos) pide por escrito que se los revisen. Ese escrito es el contrato, y las cuatro cosas que siempre dice son:
- Quién autoriza. Con nombre, puesto y firma. Quien te lo pide tiene que poder darlo: el dueño del negocio o quien lleve sus sistemas, no un empleado con curiosidad.
- El alcance: qué equipos y qué direcciones entran. Normalmente un bloque de IP, una lista de nombres o unas máquinas concretas. Lo que no está en esa lista, no es tuyo.
- Lo excluido: lo que, aunque caiga dentro del alcance, no se toca. Casi siempre hay algo: el router que gestiona el proveedor, la impresora de la planta, el servidor de un tercero que comparte la red.
- La ventana: el día y las horas. Un barrido a las nueve de la mañana de un martes puede dejar sin citas a media gestoría; a las nueve de un sábado, no molesta a nadie.
Y una cosa que el contrato dice en negativo: qué no se hace. En una auditoría de este tipo no se modifica nada del cliente, no se tiran servicios para ver si se caen y no se sacan datos de verdad. Se demuestra el agujero con el gesto mínimo y se para ahí.
Eso tiene una consecuencia práctica el primer minuto del encargo: el alcance que te dan no es el
que escribes en la orden. Si pides 192.0.2.16/29, nmap le pregunta a las ocho direcciones del
bloque, y una de ellas es la que el contrato te acaba de prohibir. No vale decir que «solo era un
ping»: un ping es tocar, sale en el registro del otro lado y lleva tu dirección.
La forma de escribirlo sin salirse es un rango del último octeto: 192.0.2.18-22 son las cinco
direcciones que van de la .18 a la .22, y el router del proveedor —el .17— se queda fuera sin
nombrarlo. Las maneras de decirle a nmap a quién mirar son cuatro: una dirección (192.0.2.20),
un bloque en CIDR (192.0.2.16/29, las ocho), un rango del último octeto (192.0.2.18-22) y una
lista separada por espacios, si lo que quieres son dos sueltas. Traducir el contrato a una de esas
cuatro formas, y comprobar que lo excluido no cabe en lo que has escrito, es parte del trabajo.
Ejercicio
Lo primero, el contrato: alcance, excluido y ventana
Estás en el puesto de la auditoría, sábado por la mañana. El encargo firmado está en ~/encargo/contrato.txt. Antes de mirar un solo puerto, léelo y quédate con qué entra y qué no.
Preparando la máquina…
Lo que no estaba en el contrato
Pasa casi siempre: barres el bloque que te han dado y contesta alguien que no estaba en la lista. Un equipo que nadie recuerda haber puesto, una máquina de un proveedor, un trasto que un día se enchufó «un momento». Mira este barrido de descubrimiento, que solo pregunta quién está vivo:
auditor@pc-auditoria:~$ nmap -sn 203.0.113.0/24 Starting Nmap 7.80 ( https://nmap.org ) at 2026-10-15 16:43 UTC Nmap scan report for runnervmwvtoz (203.0.113.1) Host is up (0.000029s latency). MAC Address: FE:C2:31:FE:D3:C6 (Unknown) Nmap scan report for srv-objetivo.auditoria (203.0.113.10) Host is up (0.000017s latency). MAC Address: BE:2D:1F:29:09:72 (Unknown) Nmap scan report for 9e70a51b4bc9 (203.0.113.5) Host is up. Nmap done: 256 IP addresses (3 hosts up) scanned in 2.09 seconds
Tres equipos vivos de 256 direcciones miradas. -sn (ping scan) es lo primero que se hace: dice
quién contesta sin hacer un barrido de puertos. Que no es lo mismo que no tocar ninguno, y
conviene saberlo: para enterarse de si alguien está vivo hay que mandarle algo. En la misma red lo
que manda es una pregunta ARP; de lejos, un paquete al 443 y otro al 80 (y un eco de ICMP). Su
propia cuenta de puertos barridos dice cero —Ports scanned: TCP(0;)—, y aun así a esos dos
puertos les ha llegado algo. Si una dirección no contesta a nada de eso, nmap la da por caída y no
sigue:
auditor@pc-auditoria:~$ nmap -p 22 203.0.113.250 Starting Nmap 7.80 ( https://nmap.org ) at 2026-10-15 16:43 UTC Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn Nmap done: 1 IP address (0 hosts up) scanned in 0.44 seconds
«Parece caído» no es «no existe»: puede estar vivo y con el ping cerrado. -Pn se salta el
descubrimiento y pregunta por los puertos de todas formas.
Ahora lo importante. Cuando aparece un equipo que no está en el contrato, lo que toca es lo que menos apetece:
- No lo tocas. Ni un puerto, ni una versión, ni una cabecera. Está fuera.
- Lo documentas: la dirección, cuándo apareció y cómo (la línea del barrido vale como evidencia).
- Llamas al contacto del contrato y preguntas de quién es. O lo meten en el alcance por escrito, o se queda fuera.
Y eso ya es un hallazgo por sí mismo, de los que de verdad sirven: el cliente tiene un equipo vivo en su bloque público y no sabe cuál es. No hace falta mirarle ni un puerto para que eso valga más que la mitad de los puertos abiertos del servidor.
Ejercicio
Quién está vivo, y lo que no estaba en el contrato
El alcance es 192.0.2.16/29, pero el 192.0.2.17 está excluido, y lo excluido manda sobre el alcance. Mira quién contesta en el resto del bloque, sin barrerle los puertos a nadie todavía; va a aparecer alguien de más. Apúntalo en el cuaderno (~/encargo/hallazgos.txt) y no lo toques.
Preparando la máquina…
El barrido y los tres estados de un puerto
Un barrido de puertos es preguntar, puerto por puerto, si hay algún programa escuchando. Un
servidor tiene 65.535 puertos TCP posibles; por defecto nmap mira los mil más usados. Lo que
contesta cada uno cae en uno de tres estados, y los tres se ven en la captura.
open: hay alguien escuchando y contesta que sí.
auditor@pc-auditoria:~$ sudo nmap -sS -T2 -p 22,80,443 203.0.113.10 Starting Nmap 7.80 ( https://nmap.org ) at 2026-10-15 16:43 UTC Nmap scan report for srv-objetivo.auditoria (203.0.113.10) Host is up (0.000062s latency). PORT STATE SERVICE 22/tcp open ssh 80/tcp open http 443/tcp open https MAC Address: BE:2D:1F:29:09:72 (Unknown) Nmap done: 1 IP address (1 host up) scanned in 1.65 seconds
La columna SERVICE no es una respuesta del servidor: es lo que suele haber en ese puerto, sacado
de la tabla de nmap. Que diga ssh no prueba que sea SSH.
closed: la pregunta llega al servidor, pero ahí no escucha nadie. El servidor contesta «no».
auditor@pc-auditoria:~$ nmap -p 9999 203.0.113.10 Starting Nmap 7.80 ( https://nmap.org ) at 2026-10-15 16:43 UTC Nmap scan report for srv-objetivo.auditoria (203.0.113.10) Host is up (0.000032s latency). PORT STATE SERVICE 9999/tcp closed abyss MAC Address: BE:2D:1F:29:09:72 (Unknown) Nmap done: 1 IP address (1 host up) scanned in 0.06 seconds
filtered: no llega ninguna respuesta. Algo en el camino —un cortafuegos— se come la pregunta y
no dice nada.
auditor@pc-auditoria:~$ nmap -p 8080 203.0.113.10 Starting Nmap 7.80 ( https://nmap.org ) at 2026-10-15 16:43 UTC Nmap scan report for srv-objetivo.auditoria (203.0.113.10) Host is up (0.000033s latency). PORT STATE SERVICE 8080/tcp filtered http-proxy MAC Address: BE:2D:1F:29:09:72 (Unknown) Nmap done: 1 IP address (1 host up) scanned in 0.26 seconds
La diferencia entre closed y filtered es la lección fina del tema, y se ve del todo con
--reason, que escribe por qué nmap ha decidido cada estado:
auditor@pc-auditoria:~$ nmap --reason -p 22,9999 203.0.113.10 Starting Nmap 7.80 ( https://nmap.org ) at 2026-10-15 16:43 UTC Nmap scan report for srv-objetivo.auditoria (203.0.113.10) Host is up, received arp-response (0.000031s latency). PORT STATE SERVICE REASON 22/tcp open ssh syn-ack ttl 64 9999/tcp closed abyss reset ttl 64 MAC Address: BE:2D:1F:29:09:72 (Unknown) Nmap done: 1 IP address (1 host up) scanned in 0.06 seconds
opense sabe porque llega un syn-ack: «sí, estoy aquí».closedse sabe porque llega un reset: «aquí no hay nadie». Hay respuesta, y eso ya dice mucho: el equipo está vivo, el paquete llegó y no hay nada en medio que estorbe.filteredes la ausencia de respuesta.nmappregunta, vuelve a preguntar y se rinde.
Para quien audita, los tres significan cosas distintas. Un closed dice «ese servicio no está
puesto». Un filtered dice «puede que esté y que haya un cortafuegos delante»: el servicio podría
seguir vivo para quien venga de la red buena. Y 996 puertos closed con uno filtered dice algo
más: que el cortafuegos del servidor solo filtra ese puerto, porque si filtrase por defecto el
resto saldría filtered también.
Y ojo con la palabra «silencio»: el paquete de un puerto filtered no se pierde, lo descarta una
regla que lo cuenta. En este mismo barrido, la del 8080 apuntó ocho paquetes, y eso se ve desde
el otro lado — está en La prisa y el ruido.
Ejercicio
Los tres estados de un puerto, y por qué
El servidor del cliente es 192.0.2.20. Consigue ver los tres estados que enseña el tema (open, closed y filtered) y después pídele a nmap que te diga por qué ha decidido cada uno.
Preparando la máquina…
Tres formas de preguntar por un puerto
nmap tiene varias maneras de hacer la misma pregunta, y no cuestan lo mismo. Las tres del tema:
-sT, la conexión completa. Abre la conexión TCP de verdad, como la abriría un navegador, y la
cierra. No necesita permisos especiales, porque la hace el sistema operativo. Y precisamente por
eso es la que más se nota: el servicio del otro lado ve una conexión entera y la apunta.
auditor@pc-auditoria:~$ nmap -sT -p 22,80,443 203.0.113.10 Starting Nmap 7.80 ( https://nmap.org ) at 2026-10-15 16:43 UTC Nmap scan report for srv-objetivo.auditoria (203.0.113.10) Host is up (0.00014s latency). PORT STATE SERVICE 22/tcp open ssh 80/tcp open http 443/tcp open https MAC Address: BE:2D:1F:29:09:72 (Unknown) Nmap done: 1 IP address (1 host up) scanned in 0.06 seconds
-sS, media conexión. Manda el primer paquete, escucha la respuesta y no termina de abrir la
conexión. Es la que nmap usa por defecto cuando se lanza con privilegios, porque necesita
escribir paquetes a mano. Da la misma tabla de puertos que -sT (compárala con la de la sección
anterior, que es un -sS -T2) y deja menos rastro en los registros del servicio, aunque el
cortafuegos la ve igual.
-sV, la versión. Para los puertos que salieron abiertos, habla con el servicio y le saca qué
programa es y qué versión. El número de la columna VERSION no se lo inventa: sale de lo que
contestó el servicio. Lo que sí hace es conjeturar a partir de esa respuesta —la compara con su
base de huellas—, y por eso la última línea de un -sV pide que le avises si se ha equivocado
(«Please report any incorrect results»). En un informe, la versión se apunta con la orden que la
sacó al lado; si de ella depende algo gordo, se confirma por otro camino.
auditor@pc-auditoria:~$ nmap -sV -p 22,80,443 203.0.113.10 Starting Nmap 7.80 ( https://nmap.org ) at 2026-10-15 16:43 UTC Nmap scan report for srv-objetivo.auditoria (203.0.113.10) Host is up (0.000031s latency). PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 8.9p1 Ubuntu 3ubuntu0.18 (Ubuntu Linux; protocol 2.0) 80/tcp open http nginx 1.18.0 (Ubuntu) 443/tcp open ssl/http nginx 1.18.0 (Ubuntu) MAC Address: BE:2D:1F:29:09:72 (Unknown) Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 12.37 seconds
Mira el 443: con -sT decía https (la tabla de nombres) y con -sV dice ssl/http y nginx 1.18.0 (Ubuntu). Eso ya es un hallazgo de verdad: el servidor está cantando el programa, su versión
exacta y hasta la distribución. Con eso, cualquiera busca los fallos conocidos de esa versión sin
tocar el servidor.
Lo que cuesta cada una. La misma pregunta sobre los mismos tres puertos:
| Cómo se preguntó | Puertos | Lo que tardó |
|---|---|---|
-sT |
3 | 0,06 s |
-sS -T2 |
3 | 1,65 s |
-sV |
3 | 12,37 s |
-A -T4 |
3 | 16,16 s |
-sV tarda doscientas veces más que -sT porque habla con cada servicio y espera su respuesta.
Y -A (versión, guiones, conjetura del sistema operativo y traza) es el más caro de todos, el que
más información da y el que más se nota.
Ejercicio
De un barrido con cuidado a las versiones
Los puertos que importan son el 22, el 80 y el 443. Míralos primero despacio, sin prisa, y después pregúntale a cada servicio qué versión es: ahí está el hallazgo.
Preparando la máquina…
La prisa y el ruido
nmap tiene seis plantillas de temporización, de -T0 a -T5. Lanzado sin objetivo, escribe
su ayuda entera; este es el trozo que habla del tiempo:
auditor@pc-auditoria:~$ nmap TIMING AND PERFORMANCE: Options which take <time> are in seconds, or append 'ms' (milliseconds), 's' (seconds), 'm' (minutes), or 'h' (hours) to the value (e.g. 30m). -T<0-5>: Set timing template (higher is faster) --min-hostgroup/max-hostgroup <size>: Parallel host scan group sizes --min-parallelism/max-parallelism <numprobes>: Probe parallelization --min-rtt-timeout/max-rtt-timeout/initial-rtt-timeout <time>: Specifies probe round trip time. --max-retries <tries>: Caps number of port scan probe retransmissions. --host-timeout <time>: Give up on target after this long
-T3 es lo normal si no dices nada. -T0 y -T1 mandan un paquete cada mucho rato (minutos, en el
caso de -T0); -T4 y -T5 aprietan. Por qué importa: lo que se gana en tiempo se paga en
ruido.
Y aquí está lo que casi nadie cuenta la primera vez: un barrido no es invisible… pero no deja rastro donde casi todo el mundo lo busca. Para saberlo de verdad se hizo una captura aparte, con los registros del servidor mirados antes y después de cada orden, para poder decir qué dejó cada una. Esto es lo que apareció:
| Lo que se lanzó | Líneas en access.log (web) |
Líneas en auth.log (sesiones) |
|---|---|---|
nmap -sn al bloque |
0 | 0 |
nmap -sS -p 22,80,443 |
0 | 0 |
nmap -sT -p 22,80,443 |
0 | 0 |
nmap -sV -p 22,80,443 |
15 | 2 |
nmap -sC -p 80 (guiones) |
29 | 0 |
nmap -A -T4 -p 22,80,443 |
69 | 14 |
nc -nv 203.0.113.10 22 |
0 | 2 |
curl http://203.0.113.10/ |
1 | 0 |
Lee la tabla despacio, porque dice algo que no es lo que se cuenta por ahí. Un barrido de puertos
no deja ni una línea: ni el -sS, que deja el saludo a medias, ni el -sT, que lo completa.
Tampoco en la web, aunque el puerto 80 esté abierto y la conexión se abra de verdad. Lo que deja
rastro es hablar con el servicio: pedirle la versión, soltarle los guiones o leerle el banner a
mano.
El motivo es el mismo en los dos registros. nginx no apunta conexiones: apunta peticiones, y
un barrido de puertos no pide ninguna página —abre, mira que haya alguien y cierra—. Y sshd no
apunta conexiones tampoco: apunta lo que pasa desde el saludo del protocolo, y a ese saludo solo
llega quien se queda a escucharlo. De ahí que el nc del banner sí deje su par de líneas:
root@srv-objetivo:~# tail -2 /var/log/auth.log Oct 16 12:09:40 srv-objetivo sshd[4789]: error: kex_exchange_identification: Connection closed by remote host Oct 16 12:09:40 srv-objetivo sshd[4789]: Connection closed by 203.0.113.5 port 54064
Eso no es «alguien se ha conectado»: es un saludo cortado a medias, que es exactamente lo que
hace quien solo quería leer la versión. Y es lo que apunta también el -sV, por la misma razón. El
-A deja catorce líneas porque prueba de todo —versiones viejas del protocolo, claves de tipos que
ya no se aceptan— y cada intento falla con su propio mensaje.
En el registro de la web, lo que escribe línea son las peticiones de la sonda de versiones, los
guiones del motor de scripts y el curl a mano. De las 114 que dejó la captura entera, estas cinco
cuentan la historia:
root@srv-objetivo:~# cat /var/log/nginx/access.log 203.0.113.5 - - [16/Oct/2026:12:09:06 +0000] "GET / HTTP/1.0" 200 612 "-" "-" 203.0.113.5 - - [16/Oct/2026:12:09:15 +0000] "PROPFIND / HTTP/1.1" 405 166 "-" "Mozilla/5.0 (compatible; Nmap Scripting Engine; https://nmap.org/book/nse.html)" 203.0.113.5 - - [16/Oct/2026:12:09:15 +0000] "GET /robots.txt HTTP/1.1" 404 162 "-" "Mozilla/5.0 (compatible; Nmap Scripting Engine; https://nmap.org/book/nse.html)" 203.0.113.5 - - [16/Oct/2026:12:09:33 +0000] "GET /.git/HEAD HTTP/1.1" 404 162 "-" "Mozilla/5.0 (compatible; Nmap Scripting Engine; https://nmap.org/book/nse.html)" 203.0.113.5 - - [16/Oct/2026:12:09:42 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.81.0"
La misma dirección en las 114 líneas, siempre 203.0.113.5: quien barre, por definición, tiene
que poder recibir la respuesta, así que su dirección está ahí. Casi todas con error, 404 y 405
en vez de 200. Y el último campo, el agente de usuario, dice quién es: Nmap Scripting Engine,
con el enlace a su documentación. La primera línea es la sonda de la versión, que pide la portada y
calla ("-" de agente); /robots.txt y /.git/HEAD son dos de las cosas que los guiones miran
siempre, por si el servidor sirve el repositorio de código sin querer; y la última es el curl a
mano de la sección siguiente, con su curl/7.81.0.
En el cortafuegos. El puerto 8080 salía filtered porque una regla descarta sus paquetes. Esa
regla los cuenta:
root@srv-objetivo:~# iptables -L INPUT -v -n Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 4 176 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8080 31 2003 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53
Eso es el filtered visto desde dentro: los paquetes llegaron, nadie los contestó y la regla los
apuntó uno a uno. Desde fuera parecía silencio; desde dentro es una cifra que sube de golpe, y en un
panel de vigilancia eso es una alerta. Fíjate en la segunda fila, la del 53 de UDP: 31 paquetes
para un solo puerto. Es lo que cuesta un barrido de UDP, y de eso habla el tema siguiente.
Por eso en una auditoría de verdad el ruido se elige, no se sufre: se mira primero quién está vivo,
después los puertos que importan con cuidado, y solo se saca la artillería donde haga falta y con el
cliente avisado. Un -T4 con -A sobre un bloque entero deja las 85 líneas de arriba multiplicadas
por cada equipo; un -T2 sobre tres puertos concretos, con suerte, pasa por el ruido de fondo de
Internet. En la sala de este tema eso es un número en la pared.
Los banners, a mano
nmap -sV es cómodo, pero no hace magia: lee lo que el servicio suelta al abrir la conexión, el
banner. Eso se puede hacer con las manos, y conviene saberlo, porque es la forma de confirmar
una versión sin fiarte de la herramienta (y la de leer un servicio que nmap no reconoce).
sshd es el más hablador de todos: antes de que nadie le pregunte nada, dice qué es.
auditor@pc-auditoria:~$ nc -nv -w 5 203.0.113.10 22 </dev/null Connection to 203.0.113.10 22 port [tcp/*] succeeded! SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.18
Una conexión, sin escribir nada (</dev/null), y el servidor cuenta la versión exacta de OpenSSH y
el número de paquete de Ubuntu. De ahí se saca qué Ubuntu es y qué parches tiene puestos. -n es
para que nc no resuelva nombres y -w 5 para que se rinda a los cinco segundos.
Un servidor web no habla primero: espera una petición. Las cabeceras de su respuesta son su banner:
auditor@pc-auditoria:~$ curl -sS -D - -o /dev/null http://203.0.113.10/ HTTP/1.1 200 OK Server: nginx/1.18.0 (Ubuntu) Date: Thu, 15 Oct 2026 16:43:46 GMT Content-Type: text/html Content-Length: 612 Last-Modified: Thu, 15 Oct 2026 16:42:42 GMT Connection: keep-alive ETag: "6ad10282-264" Accept-Ranges: bytes
-D - manda las cabeceras a la pantalla y -o /dev/null tira el cuerpo de la página, que aquí no
interesa. La cabecera Server: dice el programa, la versión y la distribución; es lo mismo que
contestó a -sV, visto en crudo.
Ejercicio
Leer una versión a mano: nc y curl
nmap -sV no hace magia: lee lo que el servicio suelta. Confírmalo tú, sin nmap: el banner del SSH y las cabeceras de la web.
Preparando la máquina…
Las herramientas que este tema no usa
En cualquier lista de herramientas de auditoría salen unos cuantos nombres que aquí no se usan, y conviene saber qué son, para qué sirven y con qué permiso se tocan. En SudoQuest, cuando un tema las necesita, se eligen por su nombre en el puesto de trabajo (gastan tiempo y ruido y devuelven un hallazgo): no hay ninguna orden que funcione fuera del juego.
Los esquemas de abajo están a nivel de página de manual —con huecos, no con valores— para que reconozcas la herramienta cuando la veas escrita. Son una ilustración, no una receta.
- Hydra. Prueba muchas parejas de usuario y contraseña contra un servicio que pide
credenciales, para encontrar las que son flojas o las de fábrica. Se usa cuando el contrato
autoriza expresamente probar credenciales, y aun así con una lista corta y acordada: una lista
larga tira servicios, bloquea cuentas de verdad y deja a gente sin trabajar. Esquema:
hydra -l <usuario> -P <lista-de-contraseñas> <servicio>://<equipo>. - whatweb. Mira una web por fuera y dice con qué está hecha: el servidor, el gestor de
contenidos, sus módulos y sus versiones. Es de las más suaves (pide páginas, como un navegador)
y entra en casi cualquier alcance que incluya la web. Esquema:
whatweb <url>. - sqlmap. Comprueba si un parámetro de una web llega hasta la base de datos sin filtrar y, si
llega, hasta dónde se puede leer por ahí. Es de las más intrusivas que existen: puede escribir
en la base y tumbar la aplicación, así que va con una cláusula específica en el contrato, en
ventana de mantenimiento y solo de lectura. Esquema:
sqlmap -u <url-con-parámetro> --batch. - La enumeración de privilegios. En una máquina en la que ya tienes acceso autorizado, recorre
todo lo que podría dejar subir a administrador: reglas de
sudomal puestas, programas con el bit SUID, tareas programadas que escriben donde no deben, versiones del núcleo con fallos conocidos. Solo tiene sentido con acceso ya concedido por el contrato, y lo que encuentra se demuestra con el gesto más inerte posible (leer un fichero marcado) y se para ahí. Esquema:<script-de-enumeración> | tee <informe>. - Metasploit. Un marco con miles de módulos que automatizan la explotación de fallos conocidos: eliges el objetivo, el módulo y qué quieres que pase. Se nombra porque lo vas a ver en todas partes y porque conviene saber qué hay dentro de esa caja. En SudoQuest se queda en la teoría: no hay sala que lo use ni acción que lo represente.
En la sala del tema
En la sala estás en la oficina de la auditoría un sábado por la mañana, con la ventana del contrato abierta de 09:00 a 13:00. En tu mesa, al lado del portátil, tienes el encargo, y conviene leerlo entero antes de escribir nada: el alcance es un solo equipo, el servidor de la gestoría, y del bloque público solo se puede barrer para ver qué hay vivo, sin tocarle los puertos a nadie. Fuera quedan el router del proveedor —que está dentro de ese mismo bloque y aun así no se toca— y la red interna de la oficina. En la pared, el marcador del encargo, que se lee desde cualquier sitio de la oficina: el ruido que llevas, la hora, los minutos de ventana que quedan, los hallazgos que ya has confirmado, las faltas y los tickets abiertos. El ruido es el que manda: cada orden que escribes suma, y si llegas al umbral el SOC del cliente te corta el acceso. Y en la mesita, el teléfono: llamar al contacto es lo que se hace cuando aparece algo que no estaba en el papel, y también la salida si te quedas atascado.
Lo que encuentras va al tablero de hallazgos, cada uno con su evidencia (la salida que lo prueba), su gravedad —crítica, alta, media o baja— y su recomendación. Al final entregas el informe de pentest y te llevas una nota en estrellas: cuánto encontraste, cuánto ruido hiciste y si respetaste el alcance. Salirse del contrato no es un detalle que se mire al final: el cliente llama en cuanto pasa.