Ochenta y seis días de señuelo · V — Lo que la web pregunta

GET /.env           21.211 peticiones · 257 IPs
GET /.git/config     2.608 peticiones · 220 IPs
GET /.aws/credentials  1.159 peticiones · 54 IPs

De las ciento cuatro mil peticiones que recibió mi sensor web en ochenta y seis días, la más repetida —después de la portada— no fue un exploit. Fue pedir el archivo .env: veintiún mil veces, contando todas sus variantes (.env.local, .env.production, .env.bak, app/.env, backend/.env…), desde doscientas cincuenta y siete direcciones distintas. La web, vista desde un servidor que lo registra todo, casi no fuerza puertas. Pregunta. Pregunta por el archivo de configuración con las contraseñas dentro, por el .git que alguien subió sin querer, por las credenciales de AWS en el directorio del usuario. La mayor parte del ruido de fondo de internet no es gente rompiendo cosas: es gente tocando el picaporte de millones de puertas a ver cuál quedó sin llave.

Las cuatro entregas anteriores siguieron a actores que entraron: por SSH, por la API de Docker, con un minero en la mano. Esta es sobre la capa de antes, la que pega contra el puerto 80 y el 443 sin credenciales y sin sesión, y sobre lo que esa capa revela cuando uno la lee entera. Al final están las 268 IPs de Oracle Cloud que me atacaron desde adentro de la misma nube, que es el hilo que arrastro desde la entrega I.

1. Las CVEs que llegaron con payload#

Es fácil mirar un log de nginx, ver /vendor/phpunit/.../eval-stdin.php y escribir “nos atacó la CVE-2017-9841”. Pero una ruta en un log no es una CVE: es una ruta. Para afirmar que algo fue un intento de explotación quiero ver el payload, no solo el nombre del archivo. Crucé cada candidata contra el store exigiendo eso: método, cuerpo y fecha. Estas son las que pasaron la prueba.

── peticiones web por familia de explotación (eventos · IPs · primera vista) ──
CVE-2017-9841  phpunit eval-stdin.php        7.184   147   2026-08-10
CVE-2024-4577  PHP-CGI allow_url_include       941   145   2026-08-10
CVE-2021-36260 Hikvision /SDK/webLanguage      721    11   2026-08-10
CVE-2025-31324 SAP NetWeaver metadatauploader  134   132   2026-08-10
—              ThinkPHP invokefunction          382   138   2026-08-10
—              Spring Boot /actuator/env        442    95   2026-08-10
—              GeoServer /geoserver/web         222    67   2026-08-10
—              Tomcat /manager/html              25    25   2026-08-10

Vale la pena mirar cómo llega cada una, porque la forma del payload dice más que el conteo.

CVE-2017-9841 (phpunit eval-stdin.php) es la más repetida y la más vieja: un fallo de 2017 en una dependencia de pruebas de PHP que permite ejecutar código mandándolo en el cuerpo de la petición. Llegó siete mil veces desde 147 IPs, casi siempre por GET —lo que ya es una señal de automatismo ciego, porque el exploit real necesita un POST con el PHP en el cuerpo; solo dos IPs lo mandaron bien—. El resto son escáneres que prueban 139 variantes de la ruta (/vendor/phpunit/..., /lib/phpunit/..., /laravel/vendor/...) por si la aplicación la escondió en algún subdirectorio. Nueve años después, sigue siendo la ruta más buscada de mi corpus.

CVE-2024-4577 (PHP-CGI) es la contraria: reciente, de 2024, y todas sus 941 llegadas fueron POST, bien formadas, con el payload de manual —%ADd+allow_url_include%3d1+%ADd+auto_prepend_file%3dphp://input— que engaña a php-cgi en Windows para que incluya y ejecute el cuerpo de la petición. Una de las 145 IPs, 103.46.186.148, la tengo confirmada por una fuente independiente: un comentario en VirusTotal del 28 de octubre la describe atacando otro honeypot “con CVE-2024-4577”. Cuando el payload en mi store y el reporte de un tercero coinciden en la técnica y la fecha, la atribución del método (no del operador) deja de ser una conjetura.

CVE-2021-36260 (Hikvision) es la rara del grupo: solo 11 IPs, pero una de ellas, 195.182.16.23 (Amarutu, geolocalizada en Frankfurt), pidió /SDK/webLanguage 395 veces a lo largo de casi tres meses. Es la inyección de comandos en cámaras Hikvision, y lo interesante es que siete de esas peticiones fueron PUT, no GET: el PUT es el que lleva el XML con el comando a ejecutar. El resto sondea. Un actor fijo, especializado en un CCTV, machacando el mismo endpoint durante toda la ventana.

CVE-2025-31324 (SAP NetWeaver) es la más nueva y la más democrática: 134 peticiones a /developmentserver/metadatauploader repartidas entre 132 IPs, casi una por IP, creciendo mes a mes (18 en agosto, 46 en septiembre, 64 en octubre). Es el patrón de una CVE que entró hace poco al repertorio de los escáneres masivos: todavía la prueba mucha gente una vez, no pocos muchas veces.

Las otras tres son clásicos que nunca se van: ThinkPHP (invokefunction para RCE), Spring Boot Actuator (/actuator/env para volcar variables de entorno con secretos), GeoServer (incluida una IP que intentó la ejecución vía valueReference=exec(...) de WFS). Ninguna explotó nada, porque mi nginx no es ninguna de esas aplicaciones. Pero todas quedaron registradas con su payload, y eso es lo que las hace citables.

2. La caza de secretos (y una vuelta de tuerca nueva)#

Debajo de las CVEs hay una capa más grande y más silenciosa: la búsqueda de archivos que no deberían ser públicos. Las 21.211 peticiones de .env son la punta. Debajo están el .git/config (que deja clonar el repositorio entero y leer su historia), las /.aws/credentials, los docker-compose.yml, los terraform.tfvars, los .bash_history. Un barrido típico pide doscientas o trescientas rutas en pocos segundos, todas candidatas a contener una llave.

Lo que no esperaba encontrar —y es, creo, lo más nuevo de todo el corpus— es que una parte de esos barridos ya no busca solo secretos de nube. Busca secretos de agentes de IA.

── peticiones a archivos de configuración de asistentes de IA (eventos · IPs · 1ª vista) ──
GET /.cursor/mcp.json                                 34   22   2026-08-28
GET /.claude/.credentials.json                        17   13   2026-09-07
GET /.claude/settings.json                            41   25   2026-08-11
GET /.config/anthropic/credentials/default.json       21   12   2026-08-11
GET /.local/share/opencode/auth.json                  16    8   2026-08-29
GET /.codex/config.toml                               28   17   2026-08-28
GET /.gemini/settings.json                             7    4   2026-09-13
GET /anthropic.json · /openai.json                    55   —    2026-08-11
GET /mcp.json · /.mcp.json · /api/mcp                304   —    2026-08-11
GET /CLAUDE.md                                         24    2   2026-08-29

Desde mediados de agosto, varios escáneres agregaron a su lista de botín los archivos donde los asistentes de código guardan sus llaves de API y la configuración de sus servidores MCP: ~/.cursor/mcp.json, ~/.claude/.credentials.json, ~/.config/anthropic/credentials/default.json, el auth.json de opencode, el config.toml de Codex. Hay quien pide hasta el CLAUDE.md, por si el archivo de instrucciones del repositorio menciona rutas o tokens. El 18 de octubre, dos IPs del mismo bloque de TC Datacenter (45.138.12.27 y 45.138.12.22) hicieron un barrido quirúrgico de cuarenta rutas en el que convivían, codo con codo, el .aws/credentials de siempre y el .cursor/mcp.json de ahora.

La lógica es la misma de 2017, actualizada: donde antes el descuido estaba en subir el .env al servidor, hoy también está en que una máquina de desarrollo tenga una llave de API de un modelo con saldo, o un servidor MCP con acceso a cosas. El valor de esas llaves es real y el método para cazarlas es viejo. Es la primera vez que lo veo sistematizado en el ruido de fondo, y sospecho que no va a ser la última.

3. Preguntarle a los metadatos de la instancia#

La SSRF —pedirle al servidor que haga una petición por uno— tiene en la nube un objetivo de oro: el servicio de metadatos de la instancia, en la dirección mágica 169.254.169.254, que entrega las credenciales temporales del rol de la máquina a cualquiera que corra dentro de ella. En mi sensor web vi 1.306 intentos de llegar ahí, de 20 IPs, y lo revelador es la forma: no buscan un parámetro vulnerable concreto, lo prueban todos.

GET /fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/
GET /fetch?uri=http://169.254.169.254/latest/meta-data/iam/info
GET /fetch?target=http://169.254.169.254/latest/meta-data/
GET /proxy?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/
GET /redirect?url=http://169.254.169.254/latest/meta-data/
GET /api/webhook?url=http://169.254.169.254/latest/meta-data/...
GET /screenshot?url=http://169.254.169.254/latest/meta-data/...
GET /proxy?url=http://169.254.169.254/metadata/identity/oauth2/token?...   (Azure)
GET /fetch?url=http://metadata.google.internal/computeMetadata/v1/.../token  (GCP)
GET /?url=http://169.254.169.254/opc/v2/identity/cert.pem                    (OCI)

Cada IP recorre una matriz: una docena de nombres de parámetro que suelen implementar SSRF (url, uri, target, dest, path, src, file, redirect, webhook, screenshot, preview, image), por una docena de rutas-prefijo (/fetch, /proxy, /api/fetch, /image…), por las cuatro nubes grandes: AWS (/latest/meta-data/iam/security-credentials/), Azure (/metadata/identity/oauth2/token), Google (metadata.google.internal/computeMetadata/v1/.../token) y Oracle (/opc/v2/identity/cert.pem y la clave, lo mismo que buscaba el visitante de la entrega I). No saben qué aplicación corre detrás; disparan contra todas las combinaciones por si una contesta. Una de las primeras IPs en hacerlo, el 11 de agosto, fue 34.168.251.237, una máquina de Google Cloud que, entre otras cosas, le pedía a mi servidor las credenciales de su propio proveedor. Una SSRF a ciegas no distingue en qué nube está.

Ninguno lo consiguió: mi nginx no reenvía nada a 169.254.169.254. Pero el abanico es la prueba de que esto ya está empaquetado en herramientas de barrido, no reservado a un pentest dirigido. La diferencia con el visitante de Jerusalén es instructiva: él ajustó la cabecera Authorization: Bearer Oracle que exige la versión 2 de la API de OCI; el abanico automático no, y por eso ni siquiera habría pasado el 401. La herramienta prueba mil puertas; la persona abre la correcta.

4. Los servicios golosos: qué sirvió de carnada y qué se delató#

El segundo sensor, el de servicios (Beelzebub), ofrecía Redis, Elasticsearch, Postgres, MySQL, Docker y VNC falsos. La pregunta interesante no es cuánto los golpearon —mucho—, sino cuáles sostuvieron el engaño y cuáles se delataron solos.

── golpes por servicio emulado (10-ago → 3-nov) ──
postgres   19.304 eventos · 1.403 IPs
redis      17.977 eventos · 1.931 IPs
mysql      11.221 eventos · 1.654 IPs
elastic     7.977 eventos · 1.488 IPs

Elasticsearch fue la mejor carnada, y a la vez la que peor aguanta un segundo vistazo. El emulador anuncia, en /_cat/indices, dos índices irresistibles: users y payments, con tamaños inventados. Doscientas cinco IPs leyeron esa lista. Y la trampa funcionó: siete de ellas volvieron a consultar GET /users/_search y GET /payments/_search con paginación (scroll=10m), creyendo que había una base de usuarios y pagos para vaciar. El problema es que el emulador solo sabe responder la portada, el listado de índices y la salud del clúster; cualquier consulta real cae en el catch-all y devuelve index_not_found_exception. Es decir: anuncia índices que no puede buscar. Para un bot que se contenta con el listado, es un cebo perfecto; para el que de verdad intenta leer, se delata en la segunda petición.

Postgres fue el mejor recolector. El emulador responde a cualquier conexión con una petición de contraseña en claro, y los atacantes se la dan: 1.574 veces le entregaron su contraseña al señuelo antes de que este les fallara. Entre el botín hay diccionarios enteros (postgres, 123456, root), pero también credenciales con olor a objetivo concreto —pgg_superadmins, killallwogs123132, bombisrael4124512, y el memorable 1your-super-secret-and-long-postgres-password, que es, literalmente, el valor de ejemplo de un docker-compose.yml famoso que mucha gente copió sin cambiar—. El emulador no completa el login, pero ya cosechó lo que el atacante estaba dispuesto a probar.

Redis aguanta el saludo y poco más. Responde PONG al PING y un INFO con versión 7.0.12 y un tiempo de actividad fijo de nueve días —el mismo para todos, siempre, que es su delator—. Tres IPs intentaron la jugada clásica de Redis abierto: CONFIG SET dir /root/.ssh, /var/lib/redis/.ssh y /var/spool/cron/crontabs, el paso previo a escribir una llave SSH o un cron a través de la base de datos. El emulador no les sigue el juego, así que ahí se cortan. Hubo también sondas con EVAL return 'REDIS_OK_<hex>', que son canarios de ejecución: el atacante comprueba si el Redis de verdad corre Lua.

MySQL fue el más flojo. Solo entrega un banner (8.0.29) y corta a los diez segundos; no implementa el protocolo, así que la mayoría de las sondas reciben “Not a command” y se van. Sirvió para contar quién toca el 3306, no para engañar a nadie.

Un detalle que explica buena parte del ruido en todos estos puertos: hay un escáner genérico, con User-Agent de Go o de visionheight.com/scan, que le tira HTTP a todo —manda GET /solr/admin/info/system, GET /v2/_catalog, GET /cgi-bin/authLogin.cgi— sin importarle que del otro lado haya un Redis o un MySQL. No busca el servicio que hay; busca por si acaso hubiera otro. En un honeypot multiservicio, ese ruido se ve clarísimo: peticiones HTTP llegando al puerto de Postgres.

5. 268 direcciones de Oracle, atacando desde Oracle#

Y acá cierro el hilo que vengo arrastrando desde la primera entrega. El señuelo vivía en Oracle Cloud. Entre los dieciséis mil atacantes, 268 venían de la propia Oracle Cloud (AS31898), con 95.131 eventos. No es un detalle anecdótico: es atacar la casa desde adentro de la casa.

── IPs atacantes alojadas en Oracle Cloud (AS31898) ──
total            268 IPs · 95.131 eventos · 2026-08 → 2026-11

por conducta:
   142  intrusión SSH (login + comandos)
    86  barrido web
    31  servicios (sobre todo el bucle de VNC)
     8  fuerza bruta SSH
     1  abuso de la API de Docker

por región OCI (de las que caen en rangos publicados):
    61  ap-singapore-1      8  ap-tokyo-1       3  us-phoenix-1
    23  us-chicago-1        7  us-ashburn-1     + 20 regiones más
    11  sa-saopaulo-1       6  ap-mumbai-1

Dos lecturas, y las dos importan. La primera: en volumen, el grueso de esas IPs es el bucle de VNC —veinte direcciones de OCI repartidas por São Paulo, Singapur y Tokio que, entre todas, generaron 83.095 de los 95.131 eventos golpeando un handshake de VNC roto, el fenómeno que conté en la entrega cero—. Quitado ese ruido, quedan 12.036 eventos de trabajo real: 142 IPs que entraron por SSH y corrieron comandos, 86 que barrieron la web.

La segunda lectura es la que me interesa. Entre esas 142 intrusiones SSH están las siete máquinas de OCI que vi en la entrega IV instalando el agente de monitoreo komari apuntado a sexy.pp.ua —ahora sé que estaban en Phoenix, Sídney, San José, Chuncheon, Singapur y Osaka, seis regiones distintas de Oracle, haciendo exactamente lo mismo—. Y están las 124 IPs de OCI que empujaron la llave mdrfckr, el land-grab de SSH de aquella entrega. Oracle fue, de lejos, el ASN que más veces plantó esa llave.

¿Qué significa? Con pinzas: una IP de nube dice dónde corría la máquina, no quién la manejaba. La explicación más barata, y la que sostienen las reputaciones (varias de estas IPs tienen puntaje casi nulo en las listas públicas, como señalé para las de komari), es que son instancias de la capa gratuita de OCI —levantadas con una tarjeta robada o comprometidas después— usadas como plataforma de salto. El atacante no eligió atacar Oracle desde Oracle por ironía: eligió máquinas baratas y desechables, y muchas de las máquinas baratas y desechables de hoy están en la misma nube que mi señuelo. La vecindad es estructural. Cuando uno pone un servidor en una nube grande, una parte no trivial de sus atacantes son vecinos de rack.

6. El ruido que no es ataque: los escáneres de investigación#

No todo lo que golpea el puerto 80 quiere entrar. Una parte —medible y separable— son proyectos de medición de internet que escanean todo el espacio de direcciones y se identifican, con mayor o menor honestidad, en el User-Agent o en una ruta de contacto.

── tráfico de medición (se autodeclara; no es intento de intrusión) ──
internet-measurement.com   74 IPs    (Driftnet)
infrawat.ch                40 IPs
docs.getodin.com           20 IPs    (Odin)
flowiq-labs.com             6 IPs
about.censys.io             3 IPs
— por etiqueta del store: stretchoid 446 · censys 367 · onyphe 268 · binaryedge · shodan

Estos piden la portada, a veces un /favicon.ico, y siguen. Dejan una ruta de contacto o un dominio con su política de escaneo (infrawat.ch, flowiq-labs.com/scanning-info) para que uno pueda pedir la exclusión. Los separo del resto por disciplina: contarlos como atacantes infla las cifras y ensucia las listas de bloqueo. Dicho esto, la frontera no siempre es nítida —algunos “proyectos de investigación” venden después los datos a quien sea—, pero un escáner que se nombra y respeta un robots no es lo mismo que una IP que manda el payload de PHP-CGI. En mi contabilidad, lo declarado va a una cubeta aparte.

7. Indicadores#

8. MITRE ATT&CK#

9. Detección#

Para las CVEs verificadas, lo que distingue un intento real de una sonda ciega es el método y el cuerpo, no la ruta. Estas firmas Suricata apuntan a los dos que llegaron bien formados en mi corpus —el POST de PHP-CGI y el PUT de Hikvision— y a la ruta de SAP, que por ahora llega sola:

alert http any any -> $HOME_NET any (msg:"CVE-2024-4577 PHP-CGI allow_url_include"; flow:to_server,established; http.method; content:"POST"; http.uri; content:"auto_prepend_file"; nocase; content:"allow_url_include"; nocase; classtype:web-application-attack; sid:9115050; rev:1;)
alert http any any -> $HOME_NET any (msg:"CVE-2021-36260 Hikvision webLanguage (PUT = RCE)"; flow:to_server,established; http.method; content:"PUT"; http.uri; content:"/SDK/webLanguage"; classtype:web-application-attack; sid:9115051; rev:1;)
alert http any any -> $HOME_NET any (msg:"CVE-2025-31324 SAP NetWeaver metadatauploader"; flow:to_server,established; http.uri; content:"/developmentserver/metadatauploader"; nocase; classtype:web-application-attack; sid:9115052; rev:1;)

El GET de phpunit lo dejo fuera a propósito: con 147 IPs mandándolo a ciegas, una firma por la ruta es todo ruido. Si acaso, alertar sobre el POST con cuerpo, que son los dos únicos intentos serios.

La SSRF a los metadatos es más fácil de cazar en la salida que en la entrada, porque el marcador es constante: la dirección 169.254.169.254 (o metadata.google.internal) apareciendo en un parámetro de una petición web es casi siempre un intento. Esta regla Sigma mira el valor de los parámetros de la URL, no la ruta:

title: SSRF hacia los metadatos de la instancia (cualquier nube)
id: 6b1e0a7c-2d94-4f3a-8c15-9e7b2a4d6f08
status: experimental
logsource:
  category: webserver
detection:
  imds:
    cs-uri-query|contains:
      - '169.254.169.254'
      - 'metadata.google.internal'
      - '/opc/v2/identity'
      - '/metadata/identity/oauth2/token'
  condition: imds
level: high
tags:
  - attack.credential_access
  - attack.t1552.005

Y en el equipo mismo, lo más barato: el servicio de metadatos solo debería consultarlo el agente de la nube. Cualquier otro proceso pidiendo 169.254.169.254 es sospechoso, y forzar la versión 2 de la API (IMDSv2 en AWS, el Bearer Oracle obligatorio en OCI) convierte una SSRF ciega —la del abanico de la sección 3— en un 401. El visitante de la entrega I sabía ajustar esa cabecera; el ruido de fondo, no.

Lo que me deja esta capa es un cambio de proporción. Durante años, el consejo fue “parchea tus CVEs”. Sigue valiendo —CVE-2017-9841 llegó siete mil veces—, pero la mayor parte de lo que vi no buscaba un fallo de software: buscaba un archivo que alguien dejó donde no iba. El .env, el .git, la credencial de AWS, y ahora la llave del asistente de IA. No hay parche para eso, porque no es un bug: es una llave real, bien copiada, puesta en un lugar público por descuido. La web no se pasa el día rompiendo puertas. Se lo pasa probando picaportes, y gana cada vez que alguien, en algún lado, olvidó echar la llave.

La entrega siguiente cierra la serie: el método, los límites, lo que falló del propio honeypot, y todo lo que aprendí teniéndolo ochenta y seis días encendido: Ochenta y seis días de señuelo · VI — Lo que aprendió el señuelo.