💻 Tecnología 🔒 Ciberseguridad 🎓 Educación 🧑‍💻 Programación 💼 Negocios

Tu aplicación está siendo atacada aunque no lo sepas: convierte cada 404 en inteligencia de seguridad.

Las empresas invierten en firewalls, WAF y múltiples capas de protección, pero proteger no es suficiente si no sabemos qué están buscando los atacantes. Solicitudes aparentemente simples hacia .env, .git, /graphql o archivos de configuración pueden revelar patrones de reconocimiento automatizado. En este artículo vere

Gregorio Bolivar2 min · 23 visitas · 9 lecturas · 1 impresiones/PDF

#ciberseguridad #honeypot #ethicalhacking #websecurity #devsecops #applicationsecurity #threatintelligence #inteligenciaartificial #cybersecurity #infosec

https://diloya.app/articles/@gbolivar/tu-aplicacion-esta-siendo-atacada-aunque-no-lo-sepas-convierte-cada-404-en-inteligencia-de-seguridad-cfc8efee

VozVelocidadLeer

Listo para escuchar.

La calidad y disponibilidad de la reproducción depende de las voces instaladas en tu dispositivo y navegador.

Proteger no es suficiente

Aquí pondría el inicio del artículo:

“Las empresas crean cada vez más capas de protección, pero ¿realmente saben qué está pasando en sus sistemas?”

Hablas de WAF, firewall, IDS/IPS, rate limiting, Cloudflare, etc., y planteas tu tesis:

Bloquear es importante. Observar es fundamental.

El objetivo es despertar la curiosidad antes de entrar en la parte técnica.

¿Qué están buscando los atacantes?

Esta sería probablemente la pestaña más impactante.

Mostrarías casos como:

GET /.env
GET /.env.production
GET /.env.backup
GET /.git/config
GET /.git/HEAD
GET /aws-exports.js
GET /public/js/app.js.map
POST /graphql
GET /wp-admin/install.php?step=1

Y explicarías qué podría estar intentando descubrir cada solicitud:

.env → secretos y credenciales

.git → repositorios expuestos

.js.map → código fuente y estructura frontend

aws-exports.js → configuraciones cloud

/graphql → identificación de APIs

/wp-admin → detección automatizada de WordPress

Aquí introduciría una frase fuerte:

Para tu aplicación fueron varios 404. Para seguridad, fue una secuencia de reconocimiento.

Honeypot para aplicaciones web

Aquí presentas tu idea.

No necesitas comenzar hablando de un honeypot extremadamente sofisticado. Puedes explicar que una aplicación puede registrar:

IP
↓
Método HTTP
↓
Ruta solicitada
↓
User-Agent
↓
Headers
↓
Timestamp
↓
Código HTTP
↓
Frecuencia
↓
Secuencia de solicitudes

Y luego correlacionar:

45.x.x.x
    │
    ├── /.git/config
    ├── /.git/HEAD
    ├── /.env
    ├── /.env.local
    ├── /.env.production
    ├── /.env.backup
    ├── /aws-exports.js
    └── /graphql
              ↓
      PATRÓN DETECTADO
              ↓
     Reconocimiento web

Aquí es donde explicas algo muy importante: el honeypot debe estar aislado y no debe tener acceso a secretos, bases de datos ni infraestructura productiva sensible.

De un 404 a inteligencia de seguridad

En lugar de:

404 /.env
404 /.git/config
404 /graphql

Tu sistema podría terminar diciendo:

┌─────────────────────────────────┐
│ NIVEL DE RECONOCIMIENTO: ALTO   │
├─────────────────────────────────┤
│ ✓ Búsqueda de secretos          │
│ ✓ Exploración de repositorios   │
│ ✓ Fingerprinting tecnológico    │
│ ✓ Exploración de APIs           │
│ ✓ Comportamiento automatizado   │
└─────────────────────────────────┘

Y ahí introduces correlación, reglas, reputación de IP, ASN, geolocalización aproximada, alertas y eventualmente IA para explicar el comportamiento, no simplemente decidir arbitrariamente si algo es un ataque.

Un 404 no siempre es simplemente un error. Puede ser una señal.

La diferencia está en si tu infraestructura solamente lo descarta o si tiene la capacidad de observarlo, correlacionarlo y convertirlo en inteligencia.