Anatomía de un ataque a WooCommerce: 5 etapas y dónde se contiene cada una | Drokio Blog | Drokio
DefensaWooCommerceataquekill chain
🎯Anatomía de un ataque a WooCommerce: 5 etapas y dónde se contiene cada una
Los ataques exitosos a WooCommerce siguen un patrón conocido: recon, acceso inicial, escalada, persistencia, exfiltración. Cada etapa tiene defensas específicas que la cortan. Si entendés las 5 etapas, sabés exactamente dónde está fallando tu protección.
Drokio··13 min de lectura
Anatomía de un ataque a WooCommerce: 5 etapas y dónde se contiene cada una
Si tu defensa contra ataques a WooCommerce es "tengo plugin de seguridad",
estás peleando una guerra que no entendés. Los ataques exitosos contra Woo
medianas — las que tienen $50K-$500K MRR — no son intentos aleatorios. Son
operaciones con plan, paciencia y método.
El patrón es público desde Lockheed Martin Cyber Kill Chain (2011) y desde
MITRE ATT&CK (2013). Adaptado a Woo, las 5 etapas son:
Reconocimiento — saber qué tenés
Acceso inicial — entrar
Escalada / movimiento lateral — moverse
Persistencia — quedarse
Exfiltración / impacto — cobrar
Cada etapa tiene defensas específicas que la cortan. Si entendés cuál
falla en tu setup, sabés exactamente qué falta. Vamos una por una.
Etapa 1 — Reconocimiento
Qué hace el atacante: identifica que tu sitio existe, qué versión de
WP/Woo corre, qué plugins tenés instalados, qué tema, qué hosting.
Drako cubre: hardening de defaults seguros + bloqueo de enumeración
estándar. Drako_Hardening cierra los vectores más obvios el día 1.
Lo que NO se puede contener: la existencia de tu sitio en internet.
Si tu Woo es público, recon es inevitable. Lo que sí se puede es subir
el costo del recon lo suficiente para que el atacante elija targets
más fáciles.
Etapa 2 — Acceso inicial
Qué hace el atacante: obtener primer foothold dentro del sistema.
Vectores comunes en Woo 2026:
| Vector | Frecuencia | Ejemplo concreto |
|---|---|---|
| Brute force / credential stuffing contra /wp-login.php | 90% de ataques masivos | Wordlist 100K passwords contra usuarios enumerados |
| CVE en plugin no actualizado | 60% de ataques exitosos | LiteSpeed Cache CVE-2024-28000 (RCE) |
| Plugin nulled con backdoor | 10% (alto riesgo) | Theme premium descargado de site pirata |
| Phishing del admin → captura credenciales | 30% de ataques dirigidos | Email "actualice su factura WooCommerce" |
| API key comprometida (Stripe/PayPal) | 5% (alto valor) | Token leakeado en commit público de GitHub |
Cómo se contiene:
2FA en wp-admin: rompe brute force + credential stuffing en 99%
de los casos.
Login throttle: 5 intentos fallidos = IP bloqueada 24h.
Patch management: plugins actualizados en menos de 7 días post-disclosure.
WAF rule virtual patching: bloquear el payload del CVE antes que
el plugin se actualice (Drako_Parche).
Vigía-Dark OSINT: detectar si una credencial de tus usuarios
apareció en un breach público (HIBP API).
Code review de plugins de tercer-party antes de instalar.
Drako cubre:
Drako_Login_Throttle (brute force).
Drako_Integrity (modificación de archivos detectada).
Drako_Brain analyze (pattern match en código nuevo).
Donde se pierden las tiendas: 2FA NO obligatorio en wp-admin +
plugin con CVE no actualizado. Combinación letal.
Etapa 3 — Escalada / movimiento lateral
Qué hace el atacante: tiene acceso al admin con credenciales válidas
(o session token via XSS). Ahora explora qué más puede hacer:
Instalar plugin malicioso que se ve legítimo ("WP Optimizer Pro v2.3").
Modificar functions.php del theme para cargar webshell.
Plantar .php en wp-content/uploads/ para ejecución remota.
Cambiar URL del sitio (siteurl/home en wp_options) para redirect
malicioso a un dominio del atacante.
Crear usuario admin nuevo con email controlado por el atacante.
Instalar plugin que envía pagos a stripe key del atacante en el
checkout de Woo.
Tiempo del atacante: días o semanas. El atacante NO encripta el sitio
inmediatamente — quiere quedarse silencioso para extraer valor.
Cómo se contiene:
Integrity scanning: hash SHA-256 de archivos críticos cada 6h.
Cualquier modificación de functions.php o aparición de .php nuevo
en uploads = alarm.
Brain analysis del código nuevo: si aparece un archivo PHP que
contiene eval(), base64_decode(), system() en patrón de webshell,
el verdict del Brain es malicious con confianza > 80% → cuarentena
automática.
Audit log de wp_options changes: si siteurl o home cambian,
alarm crítico inmediato.
Plugin install monitoring: cualquier plugin instalado fuera de
ventana de mantenimiento conocida = alarm.
Honeypots / canaries: campos cebo en la DB que nunca deberían
ser leídos por código legítimo. Si se leen, hay intrusion.
Drako cubre todo lo anterior vía Drako_Integrity + Drako_Brain +
Drako_Espejismo + Drako_Trampa.
Donde se pierden las tiendas: NO tienen integrity scanning, o lo
tienen pero los logs no se revisan. El atacante opera invisible durante
30-60 días.
Etapa 4 — Persistencia
Qué hace el atacante: garantizar que aunque limpien el sitio, él
puede volver.
Mecanismos:
Múltiples webshells en distintos paths (no solo uploads).
Credenciales nuevas creadas en wp_users con role admin.
Tareas programadas wp-cron maliciosas que reintroducen el malware.
Backdoor en el código del theme (functions.php) — sobrevive a
desinstalación de plugins.
Modificación de plugins legítimos (drop-in replacements de archivos
específicos).
Cómo se contiene:
Integrity baseline: el hash de cada archivo PHP del core, theme y
plugin se compara contra baseline conocido. Cualquier diff = alarm.
Audit trail completo: logs de quién creó qué usuario, cuándo, desde
qué IP. Auditable post-incidente.
Reinstall fresh post-incidente: si hay sospecha de breach, el
protocolo correcto es nuked-from-orbit (reinstalar WP + theme + plugins
desde fuentes oficiales) y restaurar solo data, NO archivos.
Drako cubre: Drako_Integrity para detección de modificaciones, audit
trail de cambios admin. La parte "reinstall fresh" es procedimiento
operacional, no código.
Etapa 5 — Exfiltración / impacto
Qué hace el atacante: cobra el ataque. Tres modelos comunes:
Modelo A — Robo de datos
Exfiltra wp_users (emails + hashes para ataques posteriores).
Exfiltra wp_woocommerce_orders (datos de clientes + PII).
Exfiltra wp_postmeta con metadata de pagos (no la card en sí, pero
patrones).
Vende la data en mercados underground.
Modelo B — Skimming en tiempo real
Modifica el checkout de Woo para enviar datos de tarjeta a un endpoint
controlado por el atacante.
Mientras la tienda opera normal, cada compra duplicates: una al
procesador real, otra al atacante.
Persiste meses hasta que algún cardholder reporta fraude.
Modelo C — Ransomware
Encripta DB + archivos del sitio.
Demanda rescate en crypto.
Si el cliente pagó, da la key. Si no, vende los datos exfiltrados antes.
Cómo se contiene:
Para Modelo A (exfiltración silenciosa):
Egress monitoring: alarmar si el sitio hace requests outbound a
destinos no whitelist.
Rate limiting de requests sospechosos.
Canary data: filas en wp_users / wp_woocommerce_orders que no
corresponden a usuarios reales. Si se detecta intento de leer a esas
filas en bulk, alarm. Si esas filas aparecen en algún breach público,
sabés que tu DB se exfiltró.
Para Modelo B (skimming):
Code review periódico del checkout: hash de los archivos
involucrados en pago.
Subresource Integrity (SRI) en scripts de tercer-party.
Content Security Policy estricta que bloquea exfiltration via
fetch/xhr a dominios no whitelist.
Para cada una de las 5 etapas, hacete tres preguntas:
¿Tengo un control que la detecta?
¿El control está corriendo activamente, no solo configurado?
¿Cuándo fue la última vez que verifiqué que funciona?
Si en cualquier etapa la respuesta a 1 es "no", o a 2 es "no estoy
seguro", o a 3 es "nunca", ahí está tu próximo gap.
Una tienda Woo bien protegida cubre las 5 etapas con redundancia. Una
tienda que solo tiene firewall + scanner cubre etapa 1-2 y queda expuesta
en 3-5 — exactamente donde los atacantes serios viven.
Lo que TrustOS publica
Drokio TrustOS hace cada etapa verificable públicamente:
Hardening (etapa 1) → score hardening live en verify page.
Si tu cliente, auditor o inversor pregunta "cómo sé que mi tienda está
protegida en las 5 etapas", el link drokio.com/verify/<tu-sitio> es la
respuesta. No marketing, no fe — score live verificable.
¿Querés ver una demo de las 5 etapas en vivo? Drokio Attack Lab
corre los escenarios contra un stage WP aislado. 3 escenarios grabables:
brute force (etapa 2), webshell upload (etapa 3), restore drill (etapa 5).
¿La mayoría de los ataques siguen las 5 etapas o saltan directo?
Los ataques masivos automatizados (bots) saltan directo de recon a acceso inicial, esperando que tu sitio sea de los descuidados. Si tu hardening está OK, esos rebotan. Los ataques dirigidos contra Woo medianas/grandes ($50K-$500K MRR) sí siguen el patrón completo — operadores entrenados con dwell time de semanas o meses. La diferencia es que los masivos los para Drako_Login_Throttle + integrity scan; los dirigidos requieren capas adicionales (Brain analysis + canaries + restore drill probado).
¿Cuál etapa es donde se 'pierde' una tienda Woo típica?
Etapa 3 (escalada de privilegios) es donde se pierde la mayoría. Los atacantes ya tienen acceso al wp-admin y empiezan a moverse: instalar plugins maliciosos, modificar functions.php, plantar webshells en uploads. Si Drako_Integrity escanea cada 6h y Drako_Brain analiza patrones, la etapa 3 se contiene. Sin esas capas, el atacante avanza a etapa 4 (persistencia) y ya es muy tarde.
¿Las 5 etapas las identifica un humano o un sistema?
Idealmente ambos. Un humano experto las identifica post-incidente analizando logs (forense). Un sistema bien configurado las detecta en runtime via señales correlacionadas. Drokio Brain combina ambas: el chain analiza eventos individuales con contexto, y el meta-agente Maestro (en tier Conan) correlaciona eventos entre módulos para detectar patrones de kill chain en progreso. La detección en runtime cuesta orden de magnitud menos que la respuesta post-breach.
¿Esto aplica solo a WooCommerce o también a WordPress sin Woo?
El patrón general aplica a cualquier WordPress. Las diferencias en Woo son: (1) los datos a exfiltrar tienen valor monetario inmediato (tarjetas, pedidos, datos de clientes), por eso atacantes invierten más tiempo; (2) downtime es directamente revenue perdido; (3) compliance applica más fuerte (PCI-DSS si procesa pagos, habeas data si tiene PII de clientes). Los plugins de WooCommerce (gateways de pago, integraciones de envío) son la superficie de ataque más interesante para atacantes.
Producto mencionado
🐕
Drako
El cachorro guardián
4 módulos base del ecosistema Drokio: Hardening, Integrity, Alerts y Admin. Un solo plugin, 1 sitio WordPress, $9/mes.
Qué hacer si tu WordPress fue hackeado: guía de emergencia paso a paso
Si acabás de descubrir que tu WordPress está hackeado, parás. Respirás. Y seguís esta guía. Orden exacto de acciones en las primeras 24 horas para contener el daño y restaurar sin reinfectar.
