Recursos cloud

Última actualizaciónhace 1 minuto

Los recursos cloud aparecen en DNS, HTML, JavaScript, documentación, buscadores y nombres de archivos. Un endpoint encontrado puede pertenecer a almacenamiento, una CDN, una aplicación gestionada o un tenant compartido. La enumeración debe identificar proveedor, recurso, operación expuesta y relación con la organización.

Reconocer endpoints

Los nombres varían por producto y región, pero algunos patrones frecuentes son:

Proveedor	Ejemplos de endpoint
AWS	`BUCKET.s3.amazonaws.com`, `s3-website-REGION.amazonaws.com`
Azure	`ACCOUNT.blob.core.windows.net`, `ACCOUNT.file.core.windows.net`
GCP	`storage.googleapis.com/BUCKET`, `BUCKET.storage.googleapis.com`

Un CNAME o una URL de estos dominios demuestra una dependencia técnica. No demuestra que el recurso sea público, escribible ni administrado por el mismo equipo que el dominio principal.

Buscar referencias en el sitio

Primero guarda el HTML para poder revisar exactamente la misma respuesta. En curl, -sS oculta el progreso pero conserva los errores y -o homepage.html escribe el body en un archivo:

curl -sS https://DOMAIN/ -o homepage.html

rg -n busca patrones y muestra el número de línea. El siguiente comando localiza referencias a endpoints comunes dentro del archivo guardado:

rg -n 'amazonaws\.com|blob\.core\.windows\.net|storage\.googleapis\.com' homepage.html

Repite la búsqueda sobre JavaScript, source maps, manifiestos y archivos de configuración descargados por la aplicación. DevTools permite relacionar cada URL con la petición que la utiliza, su response y sus cabeceras.

Los buscadores pueden localizar documentos ya indexados con consultas como:

site:amazonaws.com "COMPANY_NAME"
site:blob.core.windows.net "COMPANY_NAME"
site:storage.googleapis.com "COMPANY_NAME"

Los resultados son históricos y dependen del índice. Un enlace puede seguir indexado después de retirar el objeto.

Validar el recurso exacto

Antes de descargar un archivo, una petición HEAD permite observar status, tamaño, tipo y metadatos sin solicitar el body. curl -I envía HEAD cuando el servidor lo admite:

curl -I CLOUD_OBJECT_URL

No todos los servicios implementan HEAD del mismo modo. Un 403 puede significar que el recurso existe pero exige autenticación, que la operación está bloqueada o que el proveedor oculta la existencia. Un 404 tampoco es uniforme entre plataformas. Compara respuestas con un nombre aleatorio y con un objeto conocido cuando necesites entender el comportamiento.

Si el archivo debe analizarse, -o evita imprimir datos binarios en la terminal. file identifica el formato por su contenido y sha256sum genera un hash para conservar la copia exacta:

curl -sS CLOUD_OBJECT_URL -o artifact
file artifact
sha256sum artifact

Separar operaciones y alcance

El acceso cloud no es binario. Comprueba por separado:

resolución y existencia del endpoint
lectura de un objeto cuyo nombre ya se conoce
listing del bucket o container
acceso a versiones o metadatos
escritura de objetos nuevos
modificación o borrado de objetos existentes
acceso autenticado mediante credenciales o una URL firmada

Un objeto público puede ser intencional y no implica listing. Un listing abierto no implica escritura. Una URL firmada puede conceder acceso temporal a un solo objeto sin hacer público el container. Registra la operación exacta, el status y la respuesta que sostienen la conclusión.

Nombres e inferencias

Los recursos suelen reutilizar abreviaturas, nombres de producto, entornos y regiones:

company-assets
company-dev-backups
product-staging-eu
teamname-logs

Estas convenciones permiten generar candidatos, pero el nombre no atribuye el recurso. Busca relaciones independientes: DNS, referencias desde una aplicación oficial, certificados, account identifiers, documentos o contenido que coincida con el contexto técnico.

Archivos como .env, backups, exportaciones, source maps o claves SSH pueden cambiar inmediatamente el mapa de infraestructura. Conserva la URL, las cabeceras, el hash y el contexto del hallazgo. Después analiza qué sistema consume ese dato y si sigue vigente. La presencia de un archivo llamado id_rsa no demuestra que contenga una clave válida ni que se utilice en un host actual.

Qué debe quedar en el inventario

Campo	Pregunta
Proveedor	¿AWS, Azure, GCP u otra plataforma?
Recurso	¿Bucket, container, object, file share, CDN o aplicación?
Identificador	¿Qué nombre, account, región y endpoint se observan?
Procedencia	¿DNS, HTML, repositorio, buscador o documento?
Operación	¿Qué lectura, listing, escritura o metadata se comprobó?
Respuesta	¿Qué status, cabeceras y body se recibieron?
Relación	¿Qué evidencia lo conecta con la organización?
Fecha	¿Cuándo se observó y cuándo parecía haberse creado el artefacto?