Forus informó oficialmente un incidente de ciberseguridad que afectó algunos de sus sistemas y que la compañía conoció el 15 de septiembre de 2026. Por separado, ransomware.live incorporó el dominio forus.cl bajo el nombre LockBit 5 el 18 de septiembre, a las 21:48 UTC. El primer antecedente confirma un incidente; el segundo registra una reivindicación, pero no demuestra por sí solo quién lo causó.
Qué confirmó Forus sobre el incidente
En un hecho esencial enviado a la Comisión para el Mercado Financiero el 16 de septiembre, Forus S.A. señaló que había activado sus planes de prevención, detección y respuesta junto con especialistas en ciberseguridad y análisis forense digital. A esa fecha declaró el incidente contenido, con sus tiendas funcionando normalmente y otros canales de venta en recuperación, aunque con algunas intermitencias.
La compañía también indicó que, según la información disponible al emitir el comunicado, no existían datos personales afectados de clientes, trabajadores ni terceros. Agregó que todavía no podía proyectar efectos financieros. Esas afirmaciones corresponden al estado informado el 16 de septiembre y no reemplazan una evaluación técnica posterior.
El vínculo con Chile es directo: Forus es una empresa chilena de calzado, vestuario y accesorios con tiendas, comercio electrónico y presencia regional. La continuidad de canales digitales, medios de pago, inventario y logística hace que un incidente en este sector resulte relevante para otras compañías que combinan operación física y venta en línea.
LockBit 5: qué afirma el registro y qué falta por probar
La ficha de ransomware.live atribuye la reivindicación a “Lockbit5” y usa el dominio forus.cl. No se encontró en el comunicado de Forus una atribución al grupo, una descripción del vector de entrada, evidencia de cifrado ni confirmación de exfiltración. Tampoco se verificó una fecha pública distinta para la publicación original de la reivindicación; por eso se informa la fecha de detección del rastreador y no se presenta el 18 de septiembre como fecha del ataque.
A la fecha de esta revisión, los catálogos oficiales de grupos y software de MITRE ATT&CK no ofrecen un perfil G o S verificable para LockBit 5. El nombre tampoco autoriza a asumir que una versión reciente, sus operadores, sus afiliados y el malware sean una misma entidad.
Como contexto histórico, el Departamento de Justicia de Estados Unidos describió a LockBit como un esquema de ransomware como servicio: administradores desarrollaban herramientas y mantenían infraestructura, mientras afiliados conseguían acceso y ejecutaban ataques. Una alerta conjunta de CISA sobre LockBit 3.0 documentó conductas de una versión previa. Estas fuentes ayudan a entender antecedentes del ecosistema, pero no prueban que LockBit 5 sea idéntico ni que esas conductas hayan ocurrido en Forus.
Comportamientos históricos mapeables a ATT&CK
Las técnicas siguientes son un mapeo preventivo basado en antecedentes históricos de LockBit. No son técnicas observadas públicamente en este incidente:
- T1190 — Exploit Public-Facing Application: explotación de aplicaciones expuestas para obtener acceso inicial.
- T1078 — Valid Accounts: utilización de credenciales válidas obtenidas o compradas para ingresar a un entorno.
- T1486 — Data Encrypted for Impact: cifrado destinado a interrumpir la disponibilidad de información y servicios.
Mitigaciones verificadas para empresas chilenas
MITRE relaciona cada técnica con mitigaciones concretas. Deben priorizarse según la exposición real de la empresa y validarse mediante pruebas, no solo declararse en una política.
- M1051 — Update Software, vinculada con T1190: mantener un inventario de servicios expuestos, aplicar correcciones con plazos según criticidad y retirar interfaces que no tengan un dueño operativo.
- M1032 — Multi-factor Authentication, vinculada con T1078: exigir MFA resistente al phishing en correo, VPN, administración remota y servicios en la nube; las excepciones deben tener responsable y vencimiento.
- M1053 — Data Backup, vinculada con T1486: conservar copias separadas del entorno de origen y comprobar la restauración de aplicaciones prioritarias. Los objetivos de recuperación deben quedar definidos mediante RTO y RPO medibles.
Para una operación omnicanal también conviene ensayar decisiones cuando una plataforma se vuelve intermitente: qué canal se mantiene, quién autoriza una desconexión y cómo se valida el retorno. Un simulacro de ciberseguridad permite probar esa coordinación sin esperar a una crisis real. La gestión de accesos privilegiados ayuda, además, a reducir permisos permanentes sobre servicios críticos.
La atribución técnica debe quedar abierta hasta que exista evidencia verificable. Esta noticia no reproduce datos presuntamente sustraídos y distingue el comunicado oficial, el registro de la reivindicación y el contexto histórico. Las imágenes de portada e interior son ilustraciones referenciales generadas con IA.
