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:

1. Reconocimiento — saber qué tenés
2. Acceso inicial — entrar
3. Escalada / movimiento lateral — moverse
4. Persistencia — quedarse
5. 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.

Cómo lo hace:

• Crawl de tu sitio + lectura del HTML público (meta tags, scripts).
• /?p=1 para enumerar usuarios.
• Wappalyzer-style fingerprinting (CSS classes, JS comments).
• Lectura del readme.html que algunos plugins dejan público.
• Shodan / Censys: catálogo de cualquier IP pública con WordPress.

Costo para el atacante: cero. Cualquier sitio Woo está en estos catálogos en minutos de su deploy.

Cómo se contiene:

• Hardening WordPress: bloquear /?p= enumeración, bloquear lectura de /wp-json/wp/v2/users, header X-Pingback removido.
• Headers minimalistas: NO exponer versión WP en <meta name="generator">.
• Plugin headers: bloquear readme.txt lectura pública.

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).
• Vigía-Dark feeds (CVE awareness + HIBP credential leaks).

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.
• wp_cron monitoring: tareas programadas nuevas requieren validación.
• 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 Modelo C (ransomware):

• Backup off-host con Object Lock (ver artículo separado sobre backup off-host).
• Restore drill mensual probado.
• Plan de DR documentado y ensayado.

Drokio cubre:

• Drako_Trampa (canary DB) para Modelo A.
• Drako_Integrity para Modelo B.
• Backup off-host + restore drill (RESTORE_DRILL_2026-05) para Modelo C.

La pregunta clave para tu Woo

Para cada una de las 5 etapas, hacete tres preguntas:

1. ¿Tengo un control que la detecta?
2. ¿El control está corriendo activamente, no solo configurado?
3. ¿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.
• Login + 2FA (etapa 2) → score identity_2fa live.
• Integrity + Brain (etapa 3-4) → score threat_detection live.
• Backup + restore (etapa 5) → score backup_health live.

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).

→ Ver Trust Center