Un actor identificado como «skra» afirma que obtuvo más de 18 TB de la red y la infraestructura en la nube de Kensium, y que publicó casi 170 GB de código fuente y copias de seguridad. La denuncia también menciona información personal, pero ni el volumen ni el contenido de los archivos han sido verificados de forma independiente.
***

• La publicación atribuye a «skra» la extracción de más de 18 TB y la divulgación inicial de casi 170 GB.
• El actor dice que el material incluye código fuente, información personal y respaldos de bases de datos vinculados con AWS S3 y EC2.
• La evidencia disponible no permite confirmar la brecha, los archivos ni los datos presuntamente expuestos.

Kensium aparece en una denuncia de filtración de 18 TB que sigue sin verificarse

Una publicación atribuye la extracción a un actor llamado «skra»

Un actor que se identifica con el alias «skra» afirma haber sustraído más de 18 TB de información de la red y la infraestructura en la nube de Kensium, una empresa estadounidense de servicios digitales y tecnología. La misma denuncia asegura que casi 170 GB del supuesto conjunto de datos ya fueron publicados, mientras que otros materiales podrían difundirse más adelante. Por ahora, se trata de afirmaciones del actor y no de un incidente confirmado de manera independiente.

La información difundida describe a Kensium como una agencia digital con sede en Chicago, Illinois, especializada en comercio electrónico conectado con sistemas de planificación de recursos empresariales, conocidos como ERP. También menciona entornos relacionados con sistemas de gestión de almacenes, o WMS, y puntos de venta, o POS. Esas referencias describen el tipo de operación empresarial que el actor atribuye a Kensium, pero no demuestran por sí mismas que esos sistemas hayan sido vulnerados.

Según la publicación reseñada por Dark Web Informer, el lote inicial incluiría código fuente y copias recientes de bases de datos, además de información de identificación personal. El actor relaciona parte del material con servicios de Amazon Web Services, específicamente almacenamiento S3 y máquinas virtuales EC2. Sin acceso verificable al contenido, no es posible determinar qué repositorios, respaldos o categorías de información aparecen realmente en los archivos.

La ficha de la denuncia muestra como fecha de publicación el 6 de noviembre de 2026 a las 8:16 p. m. Ese dato corresponde a la fecha que aparece en el material proporcionado y no constituye, por sí solo, una confirmación externa sobre cuándo se produjo una intrusión o cuándo se publicó efectivamente el conjunto de datos. La misma ficha anticipa que habría más entregas, pero tampoco aporta pruebas independientes de que existan o vayan a difundirse.

El contenido anunciado no puede comprobarse con la evidencia disponible

La captura descrita en el reporte deja visible la afirmación sobre el volumen total y la lista general de categorías, pero oculta el árbol de archivos y el contenido de los documentos. Esa limitación impide identificar los nombres de las bases de datos, los proyectos de código, las rutas de almacenamiento o las personas que podrían estar afectadas. Por tanto, los casi 170 GB deben entenderse como el tamaño que el actor atribuye al lote, no como una medición corroborada.

El material enumera tres clases de información presuntamente comprometida: código fuente, datos personales y respaldos de bases de datos. Sin una muestra verificable, no se puede precisar si la información personal correspondería a clientes, empleados u otros grupos, ni qué campos incluiría. Tampoco es posible concluir que cada una de esas categorías esté efectivamente presente en la publicación.

El alias «skra» y el dominio de Kensium son los identificadores que el reporte dice observar directamente en la captura. El dominio identifica a la organización nombrada en la denuncia, no a una infraestructura maliciosa, y la evidencia suministrada no muestra direcciones IP controladas por el atacante ni hashes de malware. La presencia de un alias en una publicación tampoco permite atribuirle, por sí sola, una identidad o una operación comprobada.

El análisis del reporte vincula de manera inferida las copias de seguridad en la nube con la técnica de recolección T1530 de MITRE ATT&CK, y el código fuente con T1213.003, asociada a repositorios de código. Esas etiquetas sirven para ordenar comportamientos descritos o sospechados; no certifican que la extracción haya ocurrido ni revelan cómo se habría conseguido el acceso. En este caso, la propia información disponible no muestra una ruta de adquisición comprobada.

Los riesgos potenciales dependen de que la denuncia sea auténtica

Si las afirmaciones fueran auténticas, la exposición de código y respaldos podría generar riesgos distintos y relacionados: desde la pérdida de propiedad intelectual hasta la divulgación de información de clientes o empleados. El acceso a código fuente también puede ayudar a terceros a estudiar la arquitectura de una aplicación, mientras que una copia de base de datos podría contener información útil para fraudes o ataques posteriores. La denuncia, sin embargo, no permite establecer que esos escenarios ya se hayan materializado.

La referencia a AWS S3 y EC2 tampoco prueba que las cuentas de nube de Kensium hayan sido comprometidas, ni aclara si los archivos habrían salido directamente de esos servicios o si el actor los obtuvo por otra vía. La publicación habla de datos asociados con esa infraestructura y no presenta registros técnicos que permitan reconstruir el acceso. Distinguir entre una afirmación sobre el origen de los archivos y una evidencia de intrusión resulta esencial para no convertir una acusación en un hecho establecido.

La escala anunciada eleva el interés del caso, pero el volumen por sí solo no verifica la autenticidad ni la relevancia de los datos. Una colección grande puede incluir información duplicada, archivos irrelevantes o contenido cuya procedencia no se pueda demostrar, mientras que un conjunto menor también podría contener material sensible. Sin examinar muestras de forma segura y comprobar su origen, no corresponde afirmar qué personas, clientes o sistemas quedarían expuestos.

Dark Web Informer señala expresamente que no verificó de manera independiente la brecha, los más de 18 TB atribuidos a la extracción, el lote de casi 170 GB ni la presencia de datos personales, código o respaldos. La captura documenta que existe una publicación con esas afirmaciones, pero no demuestra que el material sea auténtico o que Kensium haya sufrido un acceso no autorizado. Hasta que haya corroboración, la denuncia debe tratarse como una alegación pendiente de confirmación.

Qué se puede afirmar y qué permanece abierto

Con la información disponible, el hecho comprobable se limita a la existencia de una ficha que atribuye a «skra» una supuesta filtración y enumera datos que dice haber obtenido. No se proporcionan pruebas visibles que permitan confirmar el contenido de los archivos ni medir el impacto sobre la empresa o terceros. La diferencia entre documentar una denuncia y confirmar una brecha es especialmente importante cuando el material incluye categorías sensibles como información personal.

También queda sin respuesta si Kensium identificó actividad irregular, si notificó a personas potencialmente afectadas o si inició una investigación sobre la supuesta exposición. La información entregada no incluye declaraciones de la compañía ni detalles de una respuesta técnica, por lo que no permite atribuirle acciones o decisiones. Tampoco permite concluir que los sistemas de comercio electrónico, ERP, WMS o POS mencionados hayan sufrido interrupciones.

La promesa de publicar datos adicionales podría aportar elementos para evaluar la denuncia, aunque una nueva entrega no bastaría automáticamente para autenticar su origen. Sería necesario verificar los archivos con cautela, evitar la circulación de datos personales y establecer si existe una relación demostrable con la infraestructura de la compañía. Mientras ese proceso no aporte evidencia sólida, las cifras y el alcance anunciados deben conservarse bajo atribución al actor.

El caso reúne una cifra llamativa, referencias a servicios de nube y la posible exposición de código y respaldos, pero ninguna de esas afirmaciones cuenta con confirmación independiente en el material reseñado. Por ahora, no se puede dar por probado que Kensium haya sufrido una brecha de 18 TB ni que los casi 170 GB anunciados contengan información auténtica. Esa cautela no elimina los riesgos potenciales, pero evita presentarlos como daños ya comprobados.

ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín