Un skimmer de WooCommerce es código malicioso inyectado en archivos JavaScript legítimos de una tienda que captura datos de tarjetas de crédito en tiempo real mientras el checkout funciona con normalidad. Según el análisis técnico publicado el 15 de mayo de 2026, el ataque modifica un archivo JS existente en disco, inyecta el malware al inicio del archivo, y deja el código original intacto para no levantar sospechas.
En 30 segundos
- Los atacantes modifican archivos JavaScript legítimos en disco, probablemente a través de un plugin vulnerable, e inyectan el skimmer al inicio del archivo sin tocar el código original.
- El malware captura número de tarjeta, email, teléfono y dirección usando selectores CSS específicos de WooCommerce, con validación Luhn y polling cada 500ms para atrapar autocompletado.
- Técnicas de evasión incluyen cifrado RC4, Base64 invertida, auto-eliminación post-exfiltración y deduplicación en localStorage para no enviar el mismo dato dos veces.
- El ataque es invisible en auditorías superficiales porque el sitio funciona normal, el HTTPS sigue vigente y el JS comprometido es un archivo conocido y confiable.
- Detectarlo requiere monitoreo de integridad de archivos, análisis de conexiones salientes a dominios C2, y revisión de plugins con acceso a archivos del servidor.
WooCommerce es un plugin de código abierto para WordPress desarrollado por Automattic, diseñado para transformar un sitio WordPress en una tienda de comercio electrónico. Permite gestionar productos, carritos de compra, pagos y pedidos directamente desde WordPress.
¿Qué es un skimmer de WooCommerce y por qué es tan peligroso?
Un skimmer digital es malware que se ejecuta en el navegador del comprador, captura los datos de pago en el momento exacto en que se escriben, y los envía a un servidor controlado por el atacante. El sitio sigue funcionando. El pago se procesa. El cliente no ve nada raro. Y mientras tanto, los datos de su tarjeta viajan a otra parte.
Eso ya es serio. Lo que lo hace especialmente grave es el perfil de riesgo que genera para el dueño del sitio: exposición a PCI DSS (con multas que pueden llegar a USD 100.000 por incidente), responsabilidad regulatoria, y daño reputacional que se activa cuando los clientes empiezan a reportar cargos no reconocidos, no cuando vos descubrís el ataque.
Lo peligroso de los skimmers de WooCommerce es que la brecha puede pasar meses sin detectarse. No hay alertas automáticas, no hay transacciones fallidas, no hay nada que indique que algo salió mal. El sitio «funciona bien».
Anatomía del ataque: cómo los atacantes inyectan el malware
Acá viene lo que no es obvio: si alguien tiene acceso suficiente al servidor para modificar archivos en disco, ¿por qué no hace algo más agresivo? ¿Por qué limitarse a inyectar JavaScript?
La respuesta es técnicamente elegante. Los datos de las tarjetas no existen en el servidor. El número de tarjeta, el CVV, la fecha de vencimiento, todo eso vive exclusivamente en el navegador del usuario mientras completa el formulario. Nunca llega al servidor de WordPress en texto plano (si el sitio está bien configurado). Entonces, para robarlo, el atacante necesita estar donde están los datos: en el browser.
El vector de entrada más probable, según el análisis del caso real, es un plugin de WordPress vulnerable que permitió algún nivel de acceso remoto al servidor. Una vez adentro, el atacante no agrega un archivo nuevo (eso levanta alertas en algunos monitores), sino que modifica un archivo JavaScript existente y legítimo. El malware se inyecta al inicio del archivo, y el código original queda intacto más abajo. Para cualquiera que revise el archivo sin leer el principio, parece normal. Cubrimos ese tema en detalle en cómo proteger integraciones con terceros.
Cómo captura los datos de pago: los detalles técnicos
Ponele que sos el malware. Estás corriendo en el browser del cliente que está por pagar. ¿Cómo sabés qué campo es el número de tarjeta?
Usás selectores CSS específicos de WooCommerce. El checkout de WooCommerce tiene una estructura predecible: IDs de campo conocidos, clases CSS estándar, estructura de formulario documentada. El skimmer los conoce de memoria. Apunta a los campos correctos desde el primer momento.
El detalle técnico más interesante es el polling. El malware verifica los campos cada 500 milisegundos. ¿Por qué? Para capturar datos que el usuario no tipea sino que el navegador completa automáticamente. Si el browser autocompleta el número de tarjeta, el skimmer lo captura igual, porque está chequeando el valor del campo cada medio segundo sin esperar a que el usuario lo toque.
Antes de exfiltrar el número de tarjeta, el malware corre el algoritmo de Luhn para validar que sea un número de tarjeta real. Si no pasa la validación, no lo envía. Eso reduce el ruido en el servidor C2 y evita datos basura que podrían complicar la operación del atacante. Los datos capturados incluyen email, teléfono, dirección completa, número de tarjeta, fecha y CVV.
Técnicas anti-detección: por qué no los ven ni en auditorías
El cifrado es RC4 combinado con Base64 invertida. El código que ve un analista que abre el archivo no se parece a nada reconocible. No hay strings en texto plano como «credit_card» o dominios C2 visibles.
Después de exfiltrar los datos, el malware registra en localStorage que ya envió esa sesión. No vuelve a enviar. Eso tiene dos efectos: el servidor C2 no recibe datos duplicados, y el tráfico malicioso es mínimo, lo que hace casi imposible detectarlo por volumen de conexiones salientes. Esto se conecta con lo que analizamos en soluciones de parches de seguridad disponibles.
La auto-eliminación es el toque final. Una vez que terminó su trabajo, el código se borra a sí mismo del DOM. Si alguien inspecciona el browser después del checkout, no encuentra rastros. (Sí, en serio. El código se limpia solo.)
Combinar todo eso explica por qué estos ataques pasan desapercibidos. El archivo comprometido es conocido, el sitio funciona, el HTTPS está activo, y no hay ninguna señal obvia de que algo esté mal.
Indicadores técnicos de compromiso (IOCs)
El análisis técnico del caso real identificó dominios C2 específicos, direcciones IP, puertos WebSocket y campaign IDs embebidos en el malware. Estos IOCs son los datos concretos que podés usar para auditar tu servidor.
| Tipo de IOC | Qué buscar | Dónde buscarlo |
|---|---|---|
| Dominios C2 | Dominios no reconocidos en conexiones WebSocket salientes del checkout | Logs de servidor, Content Security Policy violations |
| Puertos WebSocket | Conexiones WS a puertos no estándar (no 80/443) desde páginas de pago | Network tab del browser DevTools, WAF logs |
| Campaign IDs | Strings alfanuméricos hardcodeados en el JS, usados para tracking de campañas del atacante | Búsqueda en archivos JS modificados |
| Modificaciones de archivos | Timestamps de modificación recientes en JS que no coinciden con actualizaciones del plugin | Monitoreo de integridad (AIDE, Wordfence) |
| LocalStorage keys | Keys no reconocidas relacionadas con sesiones de pago | Application tab en DevTools después del checkout |
¿Cómo usás estos IOCs para auditar tu servidor? La forma más directa es buscar en todos los archivos JS del sitio strings codificados en Base64 que decodifican a dominios o IPs externas. También podés revisar los timestamps de modificación de archivos JS en los directorios de plugins activos contra el historial de actualizaciones.
Métodos para detectar un skimmer en tu tienda
Ningún método solo es suficiente. Los skimmers modernos están diseñados para evadir detecciones individuales.
Monitoreo de integridad de archivos
Wordfence tiene módulo de integridad de archivos que alerta cuando algo cambia en el directorio de WordPress. El problema es que solo funciona para archivos del core, no para archivos de plugins de terceros, que es exactamente donde se inyectan estos skimmers. AIDE (Advanced Intrusion Detection Environment) a nivel de servidor es más completo pero requiere configuración manual. Tema relacionado: herramientas de detección de malware.
Content Security Policy (CSP) con reporting
Una CSP correctamente configurada puede bloquear la exfiltración de datos a dominios no autorizados. Más útil aún: configurada en modo report-only primero, te muestra exactamente qué conexiones salientes está haciendo tu página sin bloquear nada. Ahí pueden aparecer los dominios C2. El análisis técnico del caso destaca esto como una de las defensas más efectivas.
Análisis manual de JS en producción
Herramientas como las documentadas en investigaciones de Magecart permiten comparar el hash de archivos JS en producción contra versiones conocidas del plugin. Si el hash no coincide y no hubo una actualización reciente, hay un problema. Es tedioso, pero es uno de los pocos métodos que detecta modificaciones que no generan alertas automáticas.
Medidas de protección técnica contra skimmers WooCommerce
La protección real requiere capas. Una sola medida no alcanza.
| Medida | Efectividad contra skimmers | Complejidad de implementación | Costo aproximado |
|---|---|---|---|
| CSP estricta con whitelist de dominios | Alta (bloquea exfiltración) | Media | Gratis |
| Monitoreo de integridad de archivos (AIDE) | Alta (detecta modificaciones) | Alta | Gratis / tiempo de config |
| WAF con reglas específicas de skimming | Media (depende de las reglas) | Baja | USD 10-50/mes según proveedor |
| Subresource Integrity (SRI) en JS externos | Alta para scripts externos | Baja | Gratis |
| Auditoría periódica de plugins | Media (prevención de acceso inicial) | Baja | Gratis o USD 99/año Patchstack |
| Wordfence (monitoreo de archivos) | Media (limitada a core) | Muy baja | Gratis / USD 119/año premium |
Lo más importante para el acceso inicial es mantener todos los plugins actualizados y eliminar los que no usás. Un plugin sin actualizar y sin uso activo es superficie de ataque gratuita. Si usás hosting en donweb.com, revisá que el servidor tenga restricciones de escritura en directorios de plugins desde el panel de control, lo que limita lo que un plugin comprometido puede modificar.
Subresource Integrity (SRI) es subestimada. Cuando cargás un script externo, SRI permite especificar el hash esperado del archivo. Si el archivo cambia (porque el CDN fue comprometido o porque se modificó en el servidor), el browser rechaza la ejecución. Para scripts propios servidos desde el mismo servidor, necesitás una solución diferente, pero para scripts de terceros es una defensa sólida y gratis.
Qué está confirmado / Qué todavía no está claro
Confirmado
- El ataque modifica un archivo JavaScript legítimo existente en disco, no agrega archivos nuevos
- El vector de acceso más probable es un plugin de WordPress con vulnerabilidad de acceso remoto
- El malware usa selectores CSS específicos de WooCommerce para identificar campos de pago
- El cifrado es RC4 + Base64 invertida para ofuscar el código y los dominios C2
- El polling a 500ms captura datos de autocompletado que no generan eventos de input
- El malware implementa deduplicación en localStorage para no exfiltrar datos repetidos
Todavía no está claro
- El plugin específico que fue el vector de acceso inicial en el caso analizado no fue revelado públicamente
- La escala del ataque (cuántas tiendas afectadas, cuántos datos robados) no fue divulgada
- Si los dominios C2 identificados siguen activos o fueron dados de baja al momento de la publicación
Errores comunes al protegerse de skimmers
Error 1: Confiar en que HTTPS protege contra skimmers. El candado en la barra del browser indica que la conexión entre el browser y el servidor está cifrada. No dice nada sobre qué código está corriendo en esa página. El skimmer opera dentro del contexto seguro, captura los datos antes de que lleguen al formulario, y los exfiltra por su propia conexión. HTTPS no hace nada contra esto.
Error 2: Revisar solo los plugins «nuevos» o «desconocidos». El malware se inyecta en archivos de plugins existentes y confiables. Si solo auditás lo que parece sospechoso por su nombre o fecha de instalación, pasás por alto exactamente el vector que usa este ataque.
Error 3: Asumir que el scanner de malware lo va a detectar. Los scanners buscan firmas conocidas. Un skimmer bien ofuscado con RC4 y Base64 invertida no tiene firmas reconocibles hasta que alguien lo analiza y publica los IOCs. Para el momento en que tu scanner lo detecta, probablemente ya pasaron semanas de exfiltración.
Preguntas Frecuentes
¿Cómo funcionan los skimmers de tarjetas en WooCommerce?
El atacante inyecta código JavaScript malicioso en un archivo legítimo del sitio, típicamente a través de un plugin vulnerable. Ese código se ejecuta en el browser del comprador durante el checkout, captura los datos de tarjeta usando selectores CSS específicos de WooCommerce, y los envía a un servidor externo controlado por el atacante. Todo ocurre mientras la transacción se procesa normalmente, sin errores visibles.
¿Cómo detectar si mi tienda tiene un skimmer?
Las señales más confiables son: timestamps de modificación recientes en archivos JavaScript de plugins sin una actualización correspondiente, conexiones salientes a dominios no reconocidos en los logs del servidor o en las CSP violation reports, y keys no esperadas en localStorage después de completar un checkout de prueba. Herramientas como Wordfence ayudan pero no cubren archivos de plugins de terceros, donde suelen estar estas inyecciones. Relacionado: protección avanzada contra compromisos.
¿Qué diferencia hay entre un skimmer y otros tipos de malware en WordPress?
La diferencia principal es el objetivo y el nivel de sigilo. Un backdoor busca persistencia en el servidor. Un ransomware cifra archivos. Un skimmer solo quiere datos de tarjeta, no deja rastros visibles, no afecta el funcionamiento del sitio, y se auto-elimina del DOM después de exfiltrar. Eso lo hace significativamente más difícil de detectar que otros tipos de malware que generan señales observables.
¿Cómo se inyecta código malicioso en la página de pago?
El vector más común es un plugin de WordPress con vulnerabilidad de ejecución remota de código o de escritura de archivos. Una vez que el atacante tiene acceso al sistema de archivos, modifica un archivo JavaScript existente y legítimo (no agrega uno nuevo, que sería más fácil de detectar). El malware se inserta al inicio del archivo, el código original queda intacto al final, y el archivo sigue siendo reconocido como válido por los sistemas de auditoría que no verifican integridad de contenido.
¿Cuánto daño económico puede causar un skimmer sin detectar?
Depende del volumen de ventas y el tiempo de exposición, pero el daño tiene tres dimensiones: las multas PCI DSS que pueden llegar a USD 100.000 por incidente según el tier del comerciante, el costo de notificación obligatoria a clientes afectados (legal, comunicación, monitoreo de crédito), y el daño reputacional cuando los clientes asocian cargos fraudulentos con tu tienda. Un skimmer activo durante tres meses en una tienda con 200 transacciones mensuales puede comprometer miles de tarjetas antes de que nadie note el patrón.
Conclusión
El análisis técnico publicado el 15 de mayo de 2026 confirma algo que la industria sabía en teoría pero que acá queda documentado con detalle real: los skimmers de WooCommerce son ataques sofisticados, silenciosos, y con un retorno muy alto para los atacantes a costa de un costo muy alto para los dueños de tiendas.
Lo que cambió con este análisis es el nivel de detalle disponible sobre las técnicas de evasión específicas: RC4, Base64 invertida, polling de 500ms, auto-eliminación del DOM, deduplicación en localStorage. Cada una de esas técnicas tiene una contramedida, y ahora están documentadas.
El paso más concreto que podés tomar hoy es configurar una Content Security Policy en modo report-only en tu página de checkout y revisar qué dominios aparecen en los violation reports durante 48 horas. Si aparece algo que no reconocés, tenés un problema que investigar. Es gratis, no rompe nada, y puede revelar exactamente el tipo de exfiltración que describe este caso.