Un hackeo puede afectar mucho más que una página web: puede exponer información, interrumpir la atención a clientes y obligar a detener procesos mientras se investiga. Para una empresa que vende, opera o presta servicios mediante plataformas digitales, la pregunta es concreta: ¿qué pasaría si mañana perdemos el control de una de ellas?

Tanner: una reivindicación pública requiere verificación

En septiembre apareció una reivindicación atribuida a Qilin que menciona a Tanner y el dominio tanner.cl. El rastreador Ransomware.live registra su detección el 4 de septiembre de 2026. Esa fecha corresponde al registro público; no establece cuándo habría ocurrido una intrusión. La lista de reivindicaciones de Ransomware.live debe leerse con esa distinción.

Al cierre de esta revisión, el 23 de septiembre, no encontramos en las fuentes públicas consultadas una confirmación de Tanner o de una autoridad que permita establecer el alcance, los sistemas afectados o la causa. Por ello, no afirmamos que se hayan robado datos, perdido fondos o interrumpido sus servicios. Tampoco atribuimos el caso a una vulnerabilidad específica.

Para una empresa que recibe una alerta similar, la acción útil es verificarla con sus responsables y proveedores, contrastarla con sus registros y coordinar la respuesta. Una acusación merece investigación; convertirla inmediatamente en una conclusión puede llevar a decisiones equivocadas.

Canvas: la seguridad también depende de lo que permite hacer cada cuenta

Instructure informó que detectó actividad no autorizada en Canvas el 29 de abril de 2026. El 7 de mayo, el mismo atacante volvió a acceder mediante otra vulnerabilidad y modificó páginas visibles para algunos usuarios. La empresa puso temporalmente Canvas en mantenimiento. Según su reporte oficial, ese segundo acceso no produjo extracción adicional de datos.

La compañía identificó una vulnerabilidad vinculada a tickets de soporte en Free-for-Teacher y confirmó el uso de cuentas de esa modalidad en ambos episodios. También informó la corrección de vulnerabilidades y de caminos que permitían obtener permisos superiores. Es información sobre debilidades de la aplicación; no autoriza a reconstruir un método de ataque completo que no está publicado.

Para quienes administran una plataforma, este caso invita a revisar qué puede hacer realmente una cuenta común, incluida su interacción con soporte y otras funciones secundarias.

Diater: contener el ataque y determinar los datos afectados son tareas diferentes

Diater confirmó que detectó un incidente de ransomware el 3 de julio de 2026, que incluyó acceso no autorizado y extracción de información. Señaló que lo contuvo el 5 de julio. Su comunicado fechado el 4 de septiembre describe afectación a ciertos datos de pacientes, empleados y exempleados. La página muestra además una fecha de publicación del 7 de septiembre.

El comunicado no identifica el punto de entrada inicial ni una vulnerabilidad concreta. Saber que hubo ransomware describe parte del incidente, pero no explica por sí solo cómo comenzaron los accesos.

La lección para un negocio digital es mantener un mapa de los datos que guarda y de quién puede consultarlos. Ese mapa permite investigar y comunicar con precisión, aunque el servicio ya haya vuelto a funcionar.

Ecopetrol: mantener la operación no descarta una exposición de información

En su comunicado del 27 de julio de 2026, Ecopetrol confirmó que un actor externo publicó información copiada ilegalmente de 15 empresas de su grupo. La compañía señaló que no había identificado afectación de sus soluciones tecnológicas transaccionales y que el alcance total, el impacto y los costos seguían siendo inciertos.

El documento no permite fijar la fecha inicial de acceso ni establecer una causa técnica específica. Tampoco sería correcto convertir la filtración confirmada en una afirmación de paralización general de la compañía.

Para tu empresa, esto plantea dos comprobaciones distintas: que la plataforma siga disponible y que sus datos permanezcan protegidos. Una revisión que solo mide si el sitio está funcionando puede dejar fuera un riesgo importante.

¿Qué los generó? La respuesta depende de la evidencia de cada caso

Conviene separar tres preguntas: cómo entró alguien, qué pudo hacer después y qué consecuencias tuvo. Una noticia puede responder una de ellas y dejar las otras abiertas. En estos antecedentes hay información concreta sobre vulnerabilidades de Canvas; en Diater y Ecopetrol, los comunicados citados confirman consecuencias sin detallar el acceso inicial. Para Tanner, la propia existencia y alcance del incidente siguen sin confirmación en las fuentes consultadas.

Las medidas siguientes son recomendaciones preventivas de BlackDoor. No son conclusiones forenses sobre las empresas mencionadas ni una promesa de que un control aislado habría evitado sus incidentes.

Cinco decisiones para proteger tus plataformas

1. Definir qué proceso no puede detenerse

Elige un proceso concreto: vender, recibir solicitudes, despachar o atender a clientes. Identifica el sitio, la aplicación, la base de datos y los proveedores que lo sostienen. Acuerda quién decide una suspensión y cómo seguir operando temporalmente. Ese ejercicio permite priorizar una revisión sin partir por una lista interminable de herramientas.

2. Comprobar permisos con cuentas reales de prueba

Solicita pruebas autorizadas con los distintos perfiles de tu plataforma. Deben comprobar, por ejemplo, que un cliente no vea información de otro y que una cuenta de soporte no obtenga facultades de administración. La guía de autorización de OWASP recomienda limitar privilegios y validar permisos en cada solicitud. Esto aplica también a plataformas desarrolladas con IA.

3. Incluir la nube y los servicios conectados

Revisa quién administra el alojamiento, dónde se guardan archivos y qué accesos conservan agencias, desarrolladores e integraciones. Cada permiso necesita un propósito y un responsable. Cuando finaliza un contrato o cambia una integración, incorpora la revisión de accesos al cierre del trabajo. Documenta además cómo contactar al proveedor si el canal habitual queda indisponible.

4. Pedir una prueba de recuperación

Tener una copia no demuestra que puedas volver a operar. La guía de CISA sobre ransomware recomienda respaldos protegidos y pruebas periódicas de restauración. Define qué recuperar, comprueba que la copia sea utilizable y mide el tiempo. Verifica también las funciones esenciales de la aplicación, no solo que el servidor encienda.

5. Acordar qué ocurre después de una alerta

Define quién recibe avisos, quién los investiga y quién decide las medidas de contención. Un tablero con alertas no reemplaza esas responsabilidades. Pide que el servicio contratado especifique plataformas incluidas, horarios, canales y alcance de respuesta. CISA también recomienda practicar el plan de incidentes y su comunicación: una persona responsable debe poder explicar qué se sabe y cuál es el siguiente paso.

Una revisión que termine en decisiones

Reúne a quien dirige el negocio, a la persona responsable de tecnología y al proveedor de tu plataforma. Trabajen sobre una sola aplicación importante y pidan tres resultados: riesgos priorizados, medidas con responsables y una fecha para comprobar las correcciones. Si ya existe una señal de intrusión, activen el procedimiento de respuesta y preserven la información que permita investigarla.

En BlackDoor podemos evaluar tus sitios web, aplicaciones y plataformas, acompañar la corrección de vulnerabilidades y definir su protección continua. Cotiza la revisión de tu plataforma y cuéntanos qué proceso necesitas proteger.