En cloud, “aguantar el tráfico” no siempre significa “estar a salvo”. La elasticidad que permite absorber picos también permite que un atacante convierta tu cuenta en una máquina de quemar presupuesto. A esto se le suele llamar Denegación de Billetera (Denial of Wallet, DoW): el objetivo es el coste, no la disponibilidad.
En empresa se ve con patrones repetidos: criptominería desplegada con credenciales filtradas, autoescalado inducido por tráfico artificial, uso abusivo de servicios gestionados (egress, logs, colas, funciones) y DDoS que, aunque no “tire” el sistema, fuerza un incremento de recursos y consumo. La disciplina FinOps ayuda, pero si no se integra con seguridad (FinOps Security), llegas tarde: el gasto ya ocurrió.
Qué salió mal en incidentes de Denegación de Billetera: la elasticidad como arma
El error típico no es “no tener WAF” o “no tener autoscaling”; es tenerlos sin límites y sin una lectura económica de riesgo. En casos reales de criptominería, el atacante no necesita tocar tu aplicación: le basta con conseguir una clave de acceso (por ejemplo, en un repositorio o en un endpoint comprometido) y lanzar recursos caros y persistentes. Si además hay permisos amplios, puede abrir instancias GPU, clusters administrados o granjas de contenedores con facturación por minuto.
En otros escenarios el abuso llega por la capa de servicio: tráfico artificial contra endpoints que disparan funciones serverless, colas, bases de datos o registros. La plataforma escala “correctamente” desde un punto de vista SRE, pero el coste marginal por solicitud hace que el ataque sea rentable para el adversario. A veces el atacante ni siquiera busca persistencia: solo generar el máximo gasto en pocas horas antes de que alguien reaccione.
La consecuencia empresarial es concreta: saturación de presupuesto mensual, bloqueos internos por sobrepasar límites de gasto, interrupción de proyectos (porque el área financiera congela la cuenta) y semanas de trabajo investigando consumo para justificarlo. Esto no es una “incidencia técnica” aislada; es un incidente de riesgo financiero con trazabilidad técnica.
Señales tempranas que distinguen un pico legítimo de un ataque orientado a coste
Las primeras señales rara vez aparecen en el monitor de latencia; aparecen en la curva de gasto y en métricas “aburridas”: egress, logs, invocaciones, mensajes, métricas de cómputo por AZ o región. Un patrón frecuente es el gasto que se desplaza a un servicio no central (por ejemplo, logs, NAT/egress o funciones) mientras la métrica de negocio (ventas, usuarios, conversiones) no acompaña.
Otra señal útil es el cambio de distribución: de repente, un entorno no productivo consume como producción, o una región que no se usa empieza a tener actividad. En criptominería, el consumo de CPU/GPU se dispara con tráfico externo bajo, y aparecen imágenes/artefactos nuevos en repositorios o clusters. En ataques de escalado masivo inducido, ves picos de requests que no se traducen en sesiones reales (ratios extraños entre requests y autenticaciones, o entre requests y eventos de aplicación).
- Gasto por servicio desalineado con el negocio: por ejemplo, suben NAT Gateway/egress o CloudWatch Logs sin incremento de usuarios. Esto suele delatar tráfico artificial o exceso de logging inducido.
- Recursos nuevos fuera del patrón operativo: instancias con tipos inusuales, nuevas regiones habilitadas, cambios en escalado mínimo/máximo. En empresas maduras, el “inventario” cambia lentamente; cambios bruscos suelen ser sospechosos.
- Actividad de API inusual: picos de llamadas a APIs de provisión (crear instancias, nodos, funciones, reglas) desde identidades o rangos IP no habituales.
Cada uno de estos puntos se valida cruzando señales: coste + inventario + eventos de auditoría. Si solo miras una dimensión, te engaña: un pico puede ser una campaña legítima; tres dimensiones alineadas suelen indicar abuso.
Cómo hacerlo en la práctica: alertas de anomalías, presupuestos y cuotas que frenan el daño
La respuesta operativa efectiva combina alertas tempranas con frenos. Las alertas por “umbral fijo” fallan porque el negocio cambia; funcionan mejor las alertas por anomalía por servicio, cuenta/proyecto y región. En paralelo, necesitas límites técnicos: cuotas de servicio, límites de autoscaling y controles para impedir que alguien (o algo) despliegue recursos fuera de tu guardrail.
En AWS, una base práctica suele incluir: AWS Budgets (alertas por coste/forecast), Cost Anomaly Detection (anomalías por servicio o tag), y alarmas en CloudWatch para métricas que correlacionan con coste (egress, invocaciones, errores que disparan reintentos). Lo importante no es “recibir un email”; es que el aviso llegue al canal de guardia y tenga contexto (servicio, región, tags, recurso probable) para actuar en minutos.
- Configurar alertas por anomalía por servicio y por tag: crear monitores de anomalía para servicios de alto riesgo económico (egress/NAT, funciones, logs, cómputo). Acompañarlo con una política de tagging mínima; sin tags, el triage se vuelve lento y caro.
- Aplicar cuotas y límites de escalado: solicitar/service quotas razonables y fijar máximos de Auto Scaling (y mínimos que no se disparen). El objetivo no es impedir crecer, sino evitar crecimiento ilimitado sin aprobación.
- Automatizar “kill switches” controlados: preparar runbooks para pausar escalado, deshabilitar endpoints no críticos o limitar egress temporalmente. Esto requiere acordarlo antes con producto y operaciones para no improvisar bajo presión.
Para validar que esto está bien implementado, revisa dos cosas: que la alerta dispara con datos “simulados” (por ejemplo, variación de coste en un sandbox o revisando el comportamiento histórico) y que el on-call puede identificar el recurso sospechoso sin abrir diez consolas. Si el triage tarda más de 20–30 minutos, el daño económico ya está escalando.
Contención durante el incidente: cortar el gasto sin destruir la evidencia
Cuando el gasto está subiendo, la tentación es “apagar todo”. En corporativo eso suele empeorar: cortas evidencias, rompes servicios críticos y generas un incidente mayor. La contención en DoW debe ser selectiva: detener la fuente de coste y preservar trazabilidad para entender el vector (credencial, endpoint, abuso de escalado, mala configuración).
En criptominería, una contención efectiva es aislar: detener instancias sospechosas, bloquear rutas de salida si aplica (sin tumbar integraciones críticas), y revocar credenciales comprometidas. En ataques que fuerzan escalado, suele ser más efectivo imponer límites temporales (max desired capacity), habilitar reglas de WAF/rate limiting o cerrar endpoints secundarios que se están explotando.
Hay un anti-patrón muy común: reaccionar solo con medidas de capa 7 (WAF) cuando el coste viene de egress, logs o reintentos internos. Si la aplicación entra en bucle de reintentos por timeouts inducidos, puedes estar pagando el doble: por cómputo y por servicios asociados. Por eso, durante la contención conviene revisar si hay tormenta de retries, errores 5xx y colas creciendo sin consumir.
Prevención realista: IAM mínimo viable, regiones controladas y “capacidad finita” por diseño
La prevención en DoW no es un checklist; es diseñar para que el coste tenga techo. Eso se logra combinando IAM restrictivo, controles de despliegue y límites de capacidad. Si una identidad puede “crear cualquier cosa en cualquier región”, el atacante solo necesita una filtración para monetizar tu cuenta.
Un control práctico es reducir superficie: bloquear regiones no usadas, exigir MFA donde aplique, y limitar acciones de provisión (run instances, create cluster, create function) a roles de CI/CD o a identidades con aprobación. A nivel de organización, separar cuentas por entorno/proyecto limita el blast radius financiero: una cuenta de desarrollo comprometida no debería poder consumir el presupuesto de producción.
Ejemplo de control técnico (AWS IAM) para evitar que un rol cree instancias grandes o fuera de regiones permitidas. No es “la” política definitiva, pero ilustra el tipo de guardrail que reduce DoW por provisión maliciosa:
- Restringir regiones: denegar acciones si
aws:RequestedRegionno está en la lista permitida. Esto frena despliegues en regiones “olvidadas” donde nadie mira costes. - Limitar tipos de instancia: permitir solo familias/tamaños aprobados (por ejemplo, negar GPU si no es imprescindible). En incidentes de criptominería, este control reduce impacto drásticamente.
- Separar roles de operación y provisión: un rol que opera no debería crear infraestructura base. Si el atacante roba un token operativo, le cuesta más convertirlo en gasto.
La validación no debe ser teórica: revisa en CloudTrail (o tu sistema de auditoría) que las acciones denegadas efectivamente quedan registradas, y realiza pruebas controladas intentando desplegar fuera de región o con un tipo no permitido. Si no lo pruebas, el día del incidente descubrirás “excepciones” que anulan el guardrail.
Recomendaciones para entornos corporativos
La Denegación de Billetera funciona porque mezcla dos realidades: seguridad (abuso) y FinOps (consumo). En empresa, la defensa efectiva aparece cuando el gasto se trata como un síntoma de incidente, con detección, triage y contención definidos, no como un reporte a fin de mes.
Prioriza alertas por anomalía con contexto (por servicio, región y tags), y acompáñalas con frenos: cuotas, máximos de escalado y controles IAM que pongan techo al coste. Operativamente, prepara runbooks para cortar gasto de forma selectiva sin perder evidencias, y valida periódicamente que esos guardrails funcionan con pruebas controladas.
¿Te interesa la seguridad en Cloud?
Comparto análisis técnicos, laboratorios prácticos y experiencias reales sobre Cloud Security.