Según el Centro de Recursos para el Robo de Identidad (ITRC), la primera mitad de 2026 vio el envío de más de 471 millones de notificaciones a víctimas, pero solo el 24% de ellas incluyeron información sobre el vector de ataque, la cifra más baja registrada. Esta falta de información plantea serios problemas para los consumidores, las empresas afectadas y los responsables políticos, ya que impide a las víctimas comprender su verdadera exposición al riesgo y tomar medidas significativas para mitigar las consecuencias.

Las organizaciones pueden mostrarse reticentes a revelar todos los detalles de un incidente por varias razones, desde preservar su reputación hasta evitar que la información pueda ser utilizada por otros atacantes. Este comportamiento no solo afecta la comunicación con los afectados, que a menudo se quedan sin información básica sobre qué datos fueron comprometidos y cómo deben proceder.

El contenido de estas notificaciones puede ser confuso. Por ejemplo, si una empresa indica que sus datos fueron «accedidos», no significa necesariamente que fueran robados. Además, la afirmación de que no hay «evidencia de mal uso» puede ser engañosa, ya que lo que percibe la empresa puede diferir de lo que está ocurriendo en el mercado del cibercrimen.

Es vital que los afectados evalúen la legitimidad de las notificaciones que reciben. Los estafadores han aprendido a capitalizar la preocupación generada por estas alertas, y a menudo lanzan mensajes falsos que pueden parecer legítimos. Se recomienda no hacer clic en enlaces de correos electrónicos no solicitados y contactar a la organización afectada a través de fuentes independientes para verificar la información.

Una vez confirmada la legitimidad de la notificación, los usuarios deben seguir ciertos pasos dependiendo del tipo de datos que pueden haber sido comprometidos. Para datos personales, como correos electrónicos o números de teléfono, se deben estar atentos a intentos de phishing. Si se comprometen credenciales de acceso, es crucial cambiarlas inmediatamente y activar la autenticación de dos factores.

Las organizaciones a menudo ofrecen servicios de monitoreo de crédito después de un incidente. Es importante entender que el monitoreo detecta cambios en el archivo de crédito, mientras que una congelación de crédito bloquea el acceso a la información crediticia. Combinarlos puede ser una estrategia eficaz para protegerse contra futuros fraudes.

A medida que la interacción con múltiples organizaciones se vuelve más común y los atacantes mejoran sus tácticas, las probabilidades de recibir una notificación de violación de datos seguirán aumentando. Sin embargo, mantenerse alertas e informados puede ser la clave para minimizar los riesgos de un robo de identidad posterior.
Fuente: WeLiveSecurity by eSet.

Los datos del Balance de Ciberseguridad 2025 del Instituto Nacional de Ciberseguridad (INCIBE) reflejan el alcance de esta problemática. Durante el pasado año, el organismo gestionó 122.223 incidentes de ciberseguridad, un 26% más que en 2024, y detectó más de 237.000 sistemas vulnerables. Entre los datos más relevantes para el ámbito doméstico destaca que el 85% de los sistemas infectados bajo el control de ciberdelincuentes estaban vinculados a dispositivos del Internet de las Cosas (IoT) presentes en las viviendas, como televisores inteligentes, decodificadores y reproductores multimedia.

Esta situación también afecta al resto de Europa. El informe ENISA Threat Landscape 2025, elaborado por la Agencia de la Unión Europea para la Ciberseguridad, señala que los dispositivos IoT se encuentran entre los objetivos prioritarios de los ciberdelincuentes. El documento identifica la falta de actualizaciones y la ausencia de configuraciones seguras como algunos de los principales factores que aumentan la vulnerabilidad de estos equipos en los hogares.

Estas deficiencias pueden facilitar que los atacantes accedan de forma clandestina a las redes domésticas y las utilicen para desarrollar actividades maliciosas. Además, una vez dentro, podrían llegar a acceder a información personal, lo que pone de manifiesto la importancia de reforzar la protección digital de los dispositivos conectados en el hogar.

Los expertos de ADT señalan que este escenario obliga a repensar qué significa proteger una vivienda. Y es que un sistema de seguridad que no contemple tanto la dimensión física como la virtual ofrece, en la práctica, una cobertura incompleta frente a las amenazas actuales.

En esa línea, advierten de que las soluciones de protección modernas deben responder también a las amenazas digitales mediante una arquitectura diseñada desde el origen para ser segura en todas sus dimensiones. Para ello, subrayan la importancia de integrar como capacidades base:

• La detección de inhibición. Esto supone contar con tecnología capaz de identificar el bloqueo de señal generado por un inhibidor entre los dispositivos y el panel de alarma. Ante esta situación, el sistema emite automáticamente una señal de alerta que se transmite a la Central Receptora de Alarmas (CRA), de modo que el intento de sabotaje queda detectado y notificado antes de que el intruso pueda actuar.
• La seguridad multivía. Esta funcionalidad garantiza la continuidad de las comunicaciones con la CRA incluso cuando el atacante intenta neutralizar uno de los canales de transmisión. Para ello, combina en redundancia el canal de comunicación móvil y la conexión cableada. Si uno de ellos se ve comprometido por una intrusión, un sabotaje o una inhibición de señal, el sistema mantiene el contacto con la central a través del otro.
• La supervisión de líneas. Mediante una comunicación permanente entre la CRA y el sistema de alarma, esta tecnología detecta si las líneas de comunicación, tanto la telefónica como la móvil, han sido saboteadas o cortadas. Si un intruso interrumpe las comunicaciones, la ausencia de respuesta en la supervisión de líneas genera un aviso inmediato a las autoridades. El silencio del sistema, se convierte en una señal de alerta.
• La tecnología Crash Signal. Diseñada para garantizar la efectividad del sistema, esta tecnología permite que la CRA reciba la señal de alarma aun cuando el panel de control haya sido destruido por el intruso. Al producirse una entrada en la casa, el sistema transmite una señal de retraso de entrada, tras la cual debería llegar una señal de desactivación. Si esa señal no llega, porque el intruso ha encontrado y dañado el panel, la CRA recibe la alerta de forma automática y contacta con las autoridades. El sistema actúa, en la práctica, como un mecanismo de seguridad del propio sistema de seguridad.

Plataformas como ADT Smart Security están concebidas bajo estos principios, garantizando que el usuario disponga en todo momento de visibilidad completa sobre el estado de su sistema y reciba alertas inmediatas ante cualquier intento de interferencia, manipulación o acceso no autorizado.

Oliver de la Rica, director general de ADT, explica que “el hogar conectado ha ampliado los frentes desde los que puede ser atacado. Los datos de INCIBE son muy claros, ya que la mayor parte de los dispositivos que acaban siendo utilizados en ataques masivos son equipos del hogar, equipos que sus propietarios nunca imaginarían que estuvieran involucrados en un incidente de seguridad. Los expertos de ADT trabajan para que los hogares españoles puedan disfrutar de las ventajas del hogar inteligente con la certeza de que están protegidos en todas sus dimensiones, tanto física como digital”.

Las claves de la IA de Kaspersky en 20 segundos

• La actualización incorpora resúmenes automáticos de informes y datos técnicos sobre amenazas.
• Las nuevas funciones también se aplican a las búsquedas basadas en inteligencia de fuentes abiertas (OSINT).
• La compatibilidad con MCP permite conectar aplicaciones de IA propias o de terceros al portal.
• Kaspersky afirma que su inteligencia se apoya en más de 25 petabytes de contexto sobre amenazas.
• Las funciones están disponibles con la licencia habitual de Kaspersky Threat Lookup, sujeta a una cuota de consultas.

Las novedades están dirigidas especialmente a los centros de operaciones de seguridad (SOC) y a los analistas de ciberamenazas. Estos equipos trabajan con grandes cantidades de alertas, registros técnicos, indicadores de compromiso (IoC) e informes sobre campañas maliciosas. La empresa plantea que la IA puede ayudar a localizar antes la información relevante y reducir el trabajo manual necesario para interpretarla.

La actualización se centra en dos cambios: resumir información técnica para acelerar su revisión y permitir que otras aplicaciones de inteligencia artificial consulten los datos de Kaspersky mediante una conexión estandarizada. A estas capacidades se suman mejoras en las búsquedas de información procedente de fuentes abiertas.

Resúmenes automáticos para revisar las amenazas con menos trabajo manual

La primera novedad permite generar resúmenes de información sobre amenazas con un solo clic. Durante una investigación, los analistas pueden necesitar revisar cientos de indicadores de compromiso o informes extensos relacionados con actores maliciosos, campañas y actividades sospechosas. La nueva función condensa esa información en textos más breves para facilitar una primera evaluación.

El objetivo es ayudar a los equipos a distinguir qué elementos requieren una investigación más profunda y cuáles pueden revisarse con menor prioridad. En lugar de leer cada documento completo desde el principio, el analista puede utilizar el resumen como punto de partida y consultar los datos originales cuando necesite más contexto.

Kaspersky también señala que ha seleccionado los conjuntos de datos utilizados para generar cada bloque de resumen. Según la compañía, esta decisión busca reducir el tiempo de revisión sin perder el contexto necesario para valorar la información. La nota de lanzamiento no detalla, sin embargo, métricas independientes que permitan cuantificar el ahorro de tiempo ni comparar la precisión de los resúmenes con una revisión manual.

La función también se extiende a los indicadores y entidades que aparecen en búsquedas de inteligencia de fuentes abiertas, conocidas como OSINT por sus siglas en inglés. En estos casos, la plataforma puede resumir los datos disponibles sobre una entidad para ofrecer una visión inicial de la información recopilada.

Este enfoque puede resultar útil cuando un equipo necesita examinar múltiples dominios, direcciones IP, archivos u otros elementos asociados a una posible actividad maliciosa. El resumen facilita la clasificación inicial, aunque la información generada por IA debe interpretarse junto con las evidencias originales y los procedimientos de validación del equipo de seguridad.

La compañía sostiene que estas herramientas pueden beneficiar tanto a analistas con menos experiencia como a especialistas que gestionan investigaciones complejas. Para los primeros, una síntesis puede ayudar a entender mejor los datos técnicos; para los segundos, puede reducir el tiempo dedicado a tareas repetitivas de lectura y clasificación.

MCP conecta el portal con aplicaciones de inteligencia artificial

La segunda novedad es la integración mediante Model Context Protocol (MCP), un protocolo que permite conectar aplicaciones de inteligencia artificial con fuentes de datos y herramientas externas. Kaspersky lo incorpora para que las organizaciones puedan vincular sus propias aplicaciones de IA o soluciones de terceros con Threat Intelligence Portal.

La compañía presenta esta conexión como una alternativa más flexible a las integraciones basadas exclusivamente en interfaces de programación de aplicaciones (API) tradicionales. Con MCP, los modelos de IA pueden realizar consultas dinámicas y acceder a datos externos en función de las necesidades de cada tarea, siempre dentro de las capacidades y permisos de la integración.

En la práctica, esta conexión puede permitir que una aplicación corporativa de IA consulte información de inteligencia sobre amenazas durante un flujo de trabajo de análisis. Así, una organización podría combinar sus herramientas internas con los datos disponibles en el portal, sin limitarse a consultar la plataforma de forma aislada.

Kaspersky afirma que la integración proporciona acceso en tiempo real a su inteligencia global para las aplicaciones conectadas. La empresa no especifica en el anuncio qué aplicaciones de terceros se han integrado ya, qué operaciones concretas están disponibles a través de MCP ni cuáles son los límites técnicos de las consultas. Por tanto, el anuncio describe una capacidad de integración, pero no confirma que todos los flujos de trabajo puedan automatizarse sin configuración adicional.

El valor práctico dependerá de cómo cada organización incorpore estas consultas a sus procesos. Por ejemplo, una herramienta interna podría solicitar información sobre un indicador detectado durante una investigación y utilizarla para ampliar el análisis. El alcance real de estas automatizaciones estará condicionado por la configuración, los permisos, la calidad de los datos y los controles aplicados a los resultados.

La incorporación de MCP también plantea cuestiones operativas que los equipos deben valorar antes de conectar servicios: qué datos pueden consultar las aplicaciones, cómo se gestionan las credenciales, qué registros quedan disponibles para auditoría y qué controles evitan que una respuesta automática se tome como una conclusión definitiva.

Licencias, consultas y alcance de las nuevas funciones

Kaspersky indica que los clientes pueden utilizar las nuevas funciones de IA con su licencia habitual de Kaspersky Threat Lookup, que incluye una cuota estándar de consultas. Las organizaciones que necesiten un volumen superior pueden adquirir solicitudes adicionales bajo demanda.

El anuncio no detalla el número de consultas incluidas, los precios de las ampliaciones ni posibles diferencias entre planes. Las empresas interesadas tendrán que consultar las condiciones de su licencia para determinar el coste de incorporar estas capacidades a un uso intensivo.

La actualización se apoya en la base de inteligencia de amenazas que Kaspersky ha construido a lo largo de los años. La compañía cifra en más de 25 petabytes el contexto propio de amenazas que respalda su oferta. Se trata de una cifra comunicada por el fabricante, no de una medición independiente de la cantidad de información útil que recibirá cada cliente.

Alexander Mazikin, responsable de la línea de productos de Threat Intelligence de Kaspersky, explica que el objetivo es acortar el tiempo entre recibir información y comprender cómo actuar. La empresa presenta las nuevas funciones como una forma de aprovechar mejor sus datos de inteligencia, pero el comunicado no incluye pruebas comparativas que permitan establecer cuánto mejoran la precisión de los análisis o el rendimiento global de los equipos.

Para los responsables de seguridad, la diferencia estará en la integración con los procesos existentes. Los resúmenes pueden acelerar la primera lectura de los datos, mientras que MCP abre la posibilidad de consultar la inteligencia desde otras herramientas. En ambos casos, el resultado dependerá de la calidad de la información, de la configuración de las aplicaciones y de la revisión humana cuando la investigación lo requiera.

Preguntas frecuentes

¿Qué nuevas funciones de IA ha incorporado Kaspersky Threat Intelligence Portal?

La actualización permite resumir información técnica sobre amenazas, incluidos datos relacionados con búsquedas OSINT, y añade conectividad mediante MCP para aplicaciones de IA propias o de terceros.

¿Para qué sirve MCP en la plataforma de Kaspersky?

MCP permite que aplicaciones de inteligencia artificial conectadas consulten datos del portal de forma dinámica. Su uso puede integrar la inteligencia de amenazas en otros flujos de análisis, según la configuración y los permisos disponibles.

¿Las nuevas funciones tienen un coste adicional?

Kaspersky indica que pueden utilizarse con la licencia habitual de Kaspersky Threat Lookup, que incluye una cuota estándar de consultas. Para volúmenes superiores, las organizaciones pueden comprar solicitudes adicionales bajo demanda.

¿Qué cantidad de datos de inteligencia utiliza Kaspersky?

La compañía afirma que su inteligencia de amenazas se basa en más de 25 petabytes de contexto propio. El comunicado no aporta una validación independiente de esa cifra ni detalla cómo se distribuye entre los distintos servicios.

Magellan, líder internacional en servicios de Consultoría y Tecnología, participará en la Expo Relación Cliente 2026, donde presentará las capacidades de su innovadora solución CX Suite. Esta plataforma de Contact Center as a Service (CCaaS) está diseñada para transformar las relaciones con los clientes a través del uso de inteligencia artificial, automatización, capacidades omnicanal y una gestión inteligente de datos.

En el evento, que reúne a importantes actores del sector, Magellan se posiciona como co-patrocinador y destaca la inteligencia artificial como eje central en la discusión sobre la evolución de la experiencia del cliente y la operativa de los centros de contacto. Durante la exposición, la compañía mostrará cómo la CX Suite integra canales, agentes, datos y procesos para ofrecer un servicio más ágil, eficiente y adaptado a las necesidades del cliente.

La participación en Expo Relación Cliente 2026 también marca un hito significativo para Magellan, ya que es su primer evento desde la adquisición, a comienzos de este año, de la división de Movilidad y Servicios Electrónicos de Worldline. Esta incorporación fortalece las capacidades de Magellan en el ámbito de Consultoría y Tecnología, permitiéndole ofrecer soluciones más integrales.

Un aspecto crítico que aborda la empresa es el delicado equilibrio necesario al implementar la inteligencia artificial en la atención al cliente. Magellan sostiene que, en lugar de ser una barrera, la tecnología debe convertirse en una aliada que simplifique la experiencia del usuario. Para lograrlo, CX Suite combina cinco capacidades clave: orquestación omnicanal, agentes IA avanzados, automatización del recorrido del cliente, herramientas de asistencia para agentes impulsadas por IA y gestión avanzada de datos.

Otro tema relevante en el evento es la adaptación a la nueva Ley SAC. Esta regulación emerge como un catalizador que impulsa a las empresas a revisar sus procesos, integrar canales previamente dispares y mejorar la trazabilidad de las quejas. La Ley establece un modelo en el que la automatización, la inteligencia artificial y la interacción humana deben operar en armonía, asegurando que los clientes puedan acceder a un agente humano cuando lo requieran.

La Ley SAC tiene como objetivo primordial garantizar un servicio personalizado y eficiente, estableciendo que al menos el 95% de las llamadas y solicitudes sean atendidas en menos de tres minutos. Andrea Aguiar, consultora de soluciones CX en Magellan, opina que esta normativa debe ser vista como una oportunidad para que las empresas evalúen y mejoren su comunicación con los clientes, destacando que la plataforma CX Suite es una herramienta clave para cumplir con estos nuevos requisitos. «La inteligencia artificial y la automatización pueden transformar y agilizar la experiencia del cliente, haciéndola más efectiva y satisfactoria», concluye Aguiar.

Legálitas ha reunido a destacados expertos en un evento enfocado en la diferenciación empresarial en el contexto de la inteligencia artificial, en el marco del Global Legaltech Day. Bajo el título «Si todos tienen IA, ¿quién destacará? La ventaja competitiva de los datos propios y la experiencia acumulada», esta sesión moderada por Juanjo Vázquez, CTO de Legálitas, ha contado con la participación de Josep Miret, CEO de Álex; William Beaven, de HappyRobot; y Víctor Fontecha, de NVIDIA.

Durante la discusión, los ponentes coincidieron en que, a medida que el acceso a la inteligencia artificial se vuelve más generalizado, las organizaciones deben centrarse en maximizar el uso de sus propios datos y la experiencia acumulada por sus profesionales. Josep Miret enfatizó que el verdadero valor de los datos radica en su capacidad para generar respuestas que un sistema de IA generalista no podría proporcionar.

Por su parte, William Beaven destacó que aunque muchas empresas ya manejan grandes volúmenes de información, el reto radica en unir ese conocimiento disperso para crear soluciones efectivas. Desde NVIDIA, Víctor Fontecha subrayó que los datos deben tener características específicas para ser considerados activos diferenciales, como ser únicos, estar validados, y poder ser enriquecidos con el tiempo.

Un claro ejemplo de esta estrategia es Álex, el asistente legal de inteligencia artificial de Legálitas, que ya es utilizado por un millón y medio de españoles. Este sistema combina legislación actual con más de cinco millones de consultas jurídicas previas, integrando tanto el conocimiento legal como la experiencia práctica adquirida.

Los expertos también discutieron la importancia de la supervisión humana en el uso de la IA, destacando que, aunque modelos generalistas pueden manejar tareas simples, la interpretación de casos específicos requerirá siempre del criterio y experiencia humanos. Así, enfatizaron que la intervención de profesionales es fundamental cuando las decisiones tienen repercusiones económicas o legales significativas.

El panel también abordó el desafío de generar confianza en el uso de la inteligencia artificial, con los ponentes afirmando que el aprendizaje continuo y los procesos de supervisión son clave para mejorar la calidad de las recomendaciones generadas. De cara al futuro, se espera un avance en la colaboración entre sistemas de IA para resolver problemas complejos y una mayor integración de estos sistemas en diversos campos como la medicina y la ciencia.

La participación de Legálitas en este evento también incluyó otra mesa redonda dedicada a cómo la tecnología puede hacer que los servicios jurídicos sean más accesibles y centrados en los ciudadanos. En esta sesión, se resaltó el papel de herramientas como Álex en la democratización del acceso a la justicia, permitiendo a las personas realizar consultas legales de forma gratuita y en tiempo real.

En resumen, los expertos coincidieron en que el futuro de las empresas radica en la capacidad de combinar inteligencia artificial, datos propios, experiencia acumulada y criterio humano, lo que les permitirá destacar en un mercado cada vez más competitivo donde la tecnología se convierte en un recurso común.

Las claves de OpenSSL y el cifrado de archivos en 30 segundos

• openssl enc permite cifrar archivos desde la terminal con algoritmos como AES-256-CBC.
• La opción -pbkdf2 refuerza la derivación de la clave a partir de una contraseña.
• El archivo cifrado puede enviarse por distintos canales, pero la contraseña debe compartirse por separado.
• También es posible cifrar una carpeta combinando tar y OpenSSL mediante una tubería.
• AES-256-CBC cifra el contenido, pero no autentica por sí solo los datos. Para información sensible conviene valorar un formato que también permita detectar modificaciones.

La utilidad de este método está en que el cifrado se realiza antes de que el archivo abandone el equipo. Así, la protección no depende exclusivamente de las medidas de seguridad que aplique el servicio por el que se envía. Sin embargo, cifrar un documento no elimina todos los riesgos: una contraseña débil, una copia sin cifrar o un archivo manipulado pueden comprometer el resultado.

Cómo cifrar un archivo con OpenSSL

Para generar una copia cifrada de un documento PDF llamado secret-file.pdf, el artículo original propone el siguiente comando:

openssl enc -aes-256-cbc -salt -pbkdf2 \
  -in secret-file.pdf \
  -out secret-file.pdf.enc

La opción enc activa las funciones de cifrado simétrico de OpenSSL. -aes-256-cbc selecciona AES con una clave de 256 bits y el modo CBC. Por su parte, -salt añade un valor aleatorio al proceso de derivación de la clave, mientras que -pbkdf2 utiliza la función PBKDF2 para convertir la contraseña en material criptográfico.

Los parámetros -in y -out indican, respectivamente, el archivo original y el destino del resultado. En las versiones habituales de OpenSSL, el comando solicita una contraseña de cifrado. Esa contraseña será necesaria después para recuperar el contenido.

El documento original no se modifica: el comando crea un segundo archivo, con extensión .enc, que contiene los datos cifrados. Es recomendable comprobar que el destino no sobrescribe por accidente otro archivo y conservar una copia segura del original hasta verificar que el proceso ha terminado correctamente.

La elección de AES-256 no basta por sí sola para determinar la seguridad del procedimiento. También importan la calidad de la contraseña, los parámetros de derivación de claves y el modo de cifrado. AES-256-CBC puede proteger la confidencialidad del contenido, pero no incorpora autenticación criptográfica que permita comprobar si alguien ha alterado los datos cifrados.

Cómo recuperar el archivo y comprobar el resultado

La persona que recibe el documento necesita el archivo cifrado, una versión compatible de OpenSSL y la contraseña correcta. Para descifrarlo, se puede utilizar:

openssl enc -d -aes-256-cbc -pbkdf2 \
  -in secret-file.pdf.enc \
  -out secret-file.pdf

La opción -d indica que se debe descifrar en lugar de cifrar. Los parámetros de cifrado y derivación de claves deben coincidir con los utilizados al crear el archivo. Si la contraseña es incorrecta o el archivo está dañado, el resultado no será una copia válida del documento original.

Antes de enviar información importante, conviene realizar una prueba de descifrado y comprobar que el archivo recuperado se abre correctamente. Para una verificación más rigurosa, se puede comparar una suma de comprobación del original con la del archivo recuperado. Por ejemplo, en sistemas que dispongan de sha256sum:

sha256sum secret-file.pdf test-output.pdf

Los valores deben coincidir si ambos archivos son idénticos. Esta comprobación sirve para detectar diferencias entre el original y la copia recuperada, aunque no sustituye a un mecanismo de autenticación que proteja el archivo frente a modificaciones maliciosas.

También es importante recordar que cifrar un archivo no borra automáticamente el original ni las copias temporales. Si el documento contiene datos confidenciales, habrá que revisar dónde se guardan las copias, quién tiene acceso a ellas y cómo se eliminan cuando dejan de ser necesarias.

Cifrar una carpeta completa con tar y OpenSSL

OpenSSL trabaja con flujos de datos y archivos, no con directorios completos de forma directa. Para agrupar y comprimir una carpeta antes de cifrarla, se puede combinar con tar:

tar -czf - my-folder | openssl enc -aes-256-cbc -salt -pbkdf2 -out my-folder.tar.gz.enc

En este ejemplo, tar genera un archivo comprimido a partir de my-folder y envía el resultado por una tubería al proceso de cifrado. El contenido intermedio se transmite directamente entre los dos comandos, sin necesidad de crear previamente un archivo comprimido sin cifrar en disco.

Para descifrarlo y extraer su contenido, el artículo original propone:

openssl enc -d -aes-256-cbc -pbkdf2 \
  -in my-folder.tar.gz.enc | tar -xzf -

La salida del descifrado se dirige a tar, que extrae los archivos. Antes de ejecutar el comando conviene comprobar el contenido del archivo y el directorio de destino, especialmente si procede de otra persona. Extraer archivos sin revisar sus nombres y rutas puede sobrescribir contenido existente o colocar archivos en ubicaciones no deseadas.

Esta combinación resulta práctica para copias de seguridad o para transportar varios documentos en un solo archivo. Aun así, mantiene la misma limitación del ejemplo anterior: CBC no autentica los datos. Para intercambiar información de especial sensibilidad, es preferible emplear una herramienta o un formato que proporcione cifrado autenticado y permita detectar alteraciones.

La contraseña y el canal de envío también importan

El archivo cifrado y la contraseña no deberían viajar juntos por el mismo canal. Si ambos se adjuntan al mismo correo electrónico, por ejemplo, quien consiga acceder a ese mensaje tendrá también los elementos necesarios para descifrar el documento.

Una opción más prudente consiste en enviar el archivo por un canal y comunicar la contraseña mediante otro. También conviene utilizar una contraseña larga, única y difícil de adivinar, ya que la seguridad del cifrado puede debilitarse si la contraseña es fácil de descubrir.

El cifrado local aporta una capa adicional de protección cuando el documento pasa por servicios externos, pero no garantiza que toda la operación sea segura. El destinatario debe conservar el archivo de forma adecuada, proteger la contraseña y evitar que el contenido descifrado quede expuesto en dispositivos compartidos o directorios accesibles para otras personas.

Tampoco es correcto asumir que todos los servicios de correo o mensajería almacenan los archivos de la misma manera. Algunos ofrecen cifrado de extremo a extremo y otros protegen únicamente determinadas partes de la comunicación. El cifrado previo con una herramienta local reduce la dependencia de esas diferencias, siempre que la implementación y la gestión de las claves sean adecuadas.

Preguntas frecuentes

¿OpenSSL permite cifrar un PDF desde Linux?

Sí. El comando openssl enc puede cifrar un PDF y guardar el resultado en un archivo independiente. Para recuperarlo será necesaria la contraseña utilizada durante el cifrado.

¿Es seguro utilizar AES-256-CBC?

AES-256-CBC puede proteger la confidencialidad de los datos, pero no autentica por sí solo el contenido cifrado. Para archivos sensibles conviene utilizar una solución que también permita detectar modificaciones.

¿Se puede cifrar una carpeta completa con OpenSSL?

Sí, combinando tar y OpenSSL mediante una tubería. tar agrupa los archivos y OpenSSL cifra el flujo resultante.

¿Cómo debe compartirse la contraseña?

Es recomendable enviar el archivo cifrado y comunicar la contraseña por canales separados. También conviene elegir una contraseña larga y única, y comprobar que el archivo se puede recuperar antes de enviar el original.

Las claves del OWASP Top 10 para IA en 20 segundos

• OWASP identifica diez riesgos específicos para aplicaciones basadas en LLM.
• La inyección de prompts sigue entre las amenazas principales, también mediante contenido externo.
• Los modelos pueden exponer información sensible o recibir permisos excesivos.
• La cadena de suministro, el envenenamiento de datos y los ataques contra RAG añaden nuevas superficies.
• También preocupan el consumo sin límites, la desinformación y la ejecución insegura de respuestas.

La clasificación de OWASP no se limita al comportamiento del modelo. El documento analiza el sistema completo que rodea a una aplicación de inteligencia artificial generativa: datos, modelos, memoria, mecanismos de recuperación, herramientas externas, permisos, registros y componentes utilizados para procesar las respuestas.

Para los equipos de ciberseguridad, ese enfoque resulta relevante porque un LLM rara vez funciona de forma aislada. Una aplicación puede permitir que el modelo consulte una base de datos, lea documentos, llame a una API o genere una orden que posteriormente será procesada por otro sistema. Cada una de esas conexiones introduce controles de seguridad que deben evaluarse por separado.

La inyección de prompts ya no se limita a lo que escribe el usuario

La inyección de prompts encabeza la lista de riesgos de OWASP. El ataque puede producirse cuando una instrucción maliciosa intenta modificar el comportamiento previsto del modelo, pero también cuando el sistema procesa contenido externo que contiene instrucciones ocultas.

Esto afecta especialmente a las aplicaciones que utilizan recuperación aumentada por generación (RAG), correo electrónico, páginas web, documentos, imágenes, herramientas o memoria. Un contenido aparentemente legítimo puede terminar influyendo en las instrucciones que recibe el modelo.

El problema se amplía cuando el LLM tiene acceso a herramientas. Una instrucción maliciosa que consiga alterar su comportamiento podría intentar provocar una acción que el usuario no pretendía realizar.

OWASP también sitúa entre los riesgos principales la divulgación de información sensible. Los datos pueden aparecer directamente en las respuestas, pero también pueden quedar expuestos a través de argumentos enviados a herramientas, registros, telemetría, embeddings o determinados mecanismos internos de la aplicación.

Por eso, la protección no debería depender únicamente de pedir al modelo que no revele determinada información. Los controles de autorización y acceso a datos tienen que existir fuera del modelo y limitar qué información puede consultar o utilizar cada petición.

El exceso de permisos convierte al agente en un objetivo

El tercer riesgo es el exceso de agencia. El problema aparece cuando una aplicación concede al modelo demasiadas funciones, permisos o autonomía para realizar acciones.

Un asistente capaz de consultar información tiene un nivel de exposición distinto de otro que puede modificar registros, ejecutar comandos, enviar mensajes o realizar operaciones en sistemas externos. OWASP recomienda que la autorización no dependa de la decisión del propio modelo.

La cuestión adquiere todavía más importancia con los sistemas de agentes de IA, donde un modelo puede encadenar varias acciones y utilizar herramientas para completar una tarea.

El documento también incluye la cadena de suministro. Una aplicación de IA puede depender de modelos, conjuntos de datos, adaptadores, componentes de software, procesos de conversión o cuantización y otras dependencias. Cualquier elemento comprometido puede introducir riesgos antes incluso de que la aplicación llegue a producción.

Entre las amenazas aparece además el envenenamiento de datos y modelos. Puede producirse durante el entrenamiento, el ajuste fino, la generación de embeddings, la reutilización de modelos o mediante mecanismos que incorporan información de forma continua. Los sistemas RAG, la memoria y determinados ciclos de realimentación también forman parte de esta superficie.

RAG, embeddings y consumo sin límites amplían la superficie de ataque

Los sistemas RAG introducen otro conjunto de problemas. Los modelos recuperan información desde fuentes externas y utilizan esos contenidos para generar una respuesta. OWASP advierte de debilidades relacionadas con los vectores y embeddings, entre ellas posibles fugas entre usuarios o clientes, ataques de inversión, inferencias sobre pertenencia a conjuntos de datos, manipulación de la recuperación o envenenamiento de cachés.

Esto obliga a proteger no solo el modelo, sino también las bases de datos vectoriales y los mecanismos que determinan qué información llega al contexto de cada petición.

Otro riesgo destacado es el consumo sin límites. Las aplicaciones de IA pueden enfrentarse a peticiones diseñadas para consumir recursos de forma excesiva, aumentar el uso de contexto o generar costes inesperados. En entornos comerciales aparece además el denominado denial of wallet, un ataque orientado a provocar un gasto elevado en servicios de IA.

Los controles tradicionales de disponibilidad siguen siendo necesarios: límites de frecuencia, presupuestos, restricciones de recursos y mecanismos de aislamiento. En aplicaciones con modelos costosos, controlar cuánto puede consumir una petición forma parte de la seguridad.

OWASP también identifica la desinformación como un riesgo de seguridad. Un modelo puede producir información incorrecta y, si esa respuesta se utiliza posteriormente para tomar una decisión o ejecutar una acción, el problema deja de ser únicamente de calidad de contenido.

La recomendación pasa por separar la generación de la ejecución y verificar las llamadas a herramientas antes de permitir que produzcan efectos reales.

El prompt del sistema tampoco debe convertirse en una caja fuerte

Otro de los riesgos recogidos en la edición 2026 es la exposición del contexto del sistema. Las aplicaciones pueden incluir instrucciones del sistema, reglas del desarrollador, políticas, esquemas de herramientas o información asociada al perfil del usuario.

Estos elementos pueden acabar expuestos mediante técnicas diseñadas para conseguir que el modelo revele información de su contexto. OWASP señala que los secretos y los controles de autorización no deberían colocarse en estas instrucciones como mecanismo principal de protección.

El último riesgo de la lista es el tratamiento incorrecto de las salidas del modelo. Una respuesta generada por un LLM debe considerarse entrada no confiable cuando vaya a utilizarse en otro sistema.

El peligro aparece cuando una aplicación incorpora directamente esa salida en una consulta SQL, un comando de terminal, código HTML u otra operación sin validarla o sanitizarla. El modelo puede generar texto aparentemente válido, pero eso no significa que el resultado sea seguro para ejecutar.

Para los equipos de seguridad, la principal consecuencia de este Top 10 es que una aplicación con IA debe analizarse como un sistema distribuido, no únicamente como un modelo. El control de identidades, permisos, datos, herramientas, dependencias y salidas sigue estando fuera del LLM y debe mantener sus propias barreras de seguridad.

El documento de OWASP tampoco plantea que todos estos riesgos tengan la misma manifestación en cualquier aplicación. Su utilidad está precisamente en ofrecer un marco para revisar los distintos puntos donde una aplicación basada en LLM puede introducir nuevas amenazas, especialmente cuando el modelo deja de limitarse a responder y empieza a consultar información o ejecutar acciones.

Preguntas frecuentes

¿Qué es el OWASP Top 10 para aplicaciones LLM 2026?

Es una clasificación de diez riesgos de seguridad asociados a aplicaciones que utilizan grandes modelos de lenguaje. La edición de 2026 incluye amenazas relacionadas con prompts, datos, agentes, cadena de suministro, RAG, embeddings y ejecución de respuestas.

¿Cuál es uno de los principales riesgos de seguridad de los LLM?

La inyección de prompts figura entre los riesgos destacados por OWASP. Puede afectar tanto a instrucciones introducidas directamente por un usuario como a contenido externo procesado por la aplicación.

¿Por qué los agentes de IA aumentan el riesgo?

Porque pueden disponer de herramientas, permisos y capacidad para realizar acciones en sistemas externos. Cuanto mayor sea la autonomía concedida, más importante resulta mantener la autorización y los controles de seguridad fuera del modelo.

¿Es seguro ejecutar directamente una respuesta generada por un LLM?

No debería considerarse segura por defecto. OWASP recomienda tratar las salidas del modelo como entradas no confiables y validarlas antes de utilizarlas en consultas, comandos, código u otras operaciones.

Fuente: Revista Cloud

El próximo 27 de octubre, la Sala Truss del Movistar Arena se convertirá en el epicentro de la innovación financiera con la celebración de la VIII edición del Financial & Fintech Innovation Summit. Este evento, organizado por Urban Event Marketing Agency, promete ser una jornada intensa dedicada al conocimiento práctico y al networking en el ámbito de la banca y el ecosistema fintech.

Grandes entidades bancarias como Banco Santander, BBVA, Revolut Bank, CaixaBank, CBNK Banco y Singular Bank han confirmado su participación y se disponen a compartir estrategias clave que están redefiniendo el futuro del sector. Más de 300 profesionales del ecosistema financiero y asegurador se darán cita para aprender y debatir acerca de los principales desafíos y oportunidades del sector.

Entre los ponentes destacados se encuentran figuras como Gabriela Orille, Consejera Independiente de DENARIUS y CEO en FLINKET; María Tejeiro, Global Head of Savings & Investments Optimization I WM&I en Banco Santander; y Santiago Pérez Olano, General Manager España de Revolut Bank, entre otros. Estos líderes no solo discutirán sobre la transformación del sector, sino también explorarán cómo los CFO’s, CIO’s y CTO’s podrán colaborar para superar los retos en un entorno cada vez más interconectado.

La Inteligencia Artificial jugará un papel central en esta edición del summit, donde se abordará cómo la IA y el Machine Learning están revolucionando la experiencia del cliente mediante la personalización de servicios y la automatización de la gestión de riesgos. Las prácticas de detección avanzada de fraude también estarán en el centro de las discusiones, destacando cómo la innovación tecnológica está transformando el concepto de dinero y el sistema financiero tal como lo conocemos.

Con tres salas y más de 500 metros de exposición, el evento busca fomentar conexiones profesionales y potenciar un ambiente colaborativo que respalde el crecimiento económico. La VIII edición del Financial & Fintech Innovation Summit cuenta con el apoyo de numerosos sponsors, que incluyen ARSYS, AVIVA VOICE, CIVISLEND, entre otros, y será una oportunidad invaluable para aquellos interesados en las tendencias emergentes del sector.

Para más detalles sobre la agenda y los ponentes, se puede acceder a la web oficial del evento y registrarse para asistir. Sin duda, este evento se presenta como una cita ineludible para todos los involucrados en la transformación del universo financiero.

Los puntos clave del análisis revelan que MATCHBOIL es un descargador en C# usado por UAC-0099 para descargar, instalar y persistir otro payload. A lo largo del tiempo, se ha observado un cambio significativo en la ofuscación del código, que inicialmente empleaba la renombración de símbolos Unicode, y que actualmente utiliza el ofuscador .NET Reactor de Eziriz. Además, MATCHBOIL ha implementado diversas técnicas para detectar si se está ejecutando en un entorno sandbox, lo que refuerza su capacidad para evadir detección.

La investigación de los diferentes ejemplares de MATCHBOIL comenzó en febrero de 2026, al recibir dos muestras relacionadas con el malware en VirusTotal. Dado que ambas muestras establecían comunicación con un dominio previamente atribuido a UAC-0099, los investigadores decidieron examinarlas más de cerca, descubriendo otros ejemplos desde noviembre y diciembre de 2025, lo que sugiere que todos estos ejemplares podrían ser variantes de MATCHBOIL.

El análisis de ESET también identificó muestras más antiguas, compiladas en abril de 2024, las cuales indicaban que UAC-0099 probablemente ya había empezado a desarrollar MATCHBOIL a mediados de 2024. La evolución del malware ha demostrado mejoras constantes, ya que los ejemplares recopilados antes de noviembre de 2025 eran más simples de analizar en comparación con las versiones más nuevas.

Las víctimas de MATCHBOIL relacionadas con el análisis de ESET se encontraban todas en Ucrania, afectando a diversas industrias. Desde julio hasta agosto de 2025, el malware fue detectado en múltiples empresas de transporte, y más tarde, en una empresa del sector energético en junio de 2026.

UAC-0099 se define como un grupo de ciberespionaje que tiene como objetivo organizaciones gubernamentales, instituciones financieras y medios de comunicación, enfocándose en Ucrania. Se estima que este grupo se alinea con los intereses rusos y puede actuar como un corredor de acceso inicial para otros grupos notables.

MATCHBOIL se distribuye principalmente a través de correos electrónicos de spearphishing. Cajando el enlace, se descarga un archivo comprimido que contiene un payload VBScript, ejecutándose luego de que la víctima activa el script manualmente. Durante su ejecución, el malware recopila información básica del sistema, lo que permite su identificación durante la comunicación con el servidor C&C.

Un aspecto notable del desarrollo de MATCHBOIL son los cambios implementados a lo largo del tiempo, que han incluido mejoras en la lógica de ejecución y persistencia, así como incrementos en su complejidad mediante la adición de interfaces gráficas que engañan al usuario al ejecutar el malware. Esta serie de adaptaciones sugiere un interés claro por parte de los operadores de UAC-0099 en perfeccionar su herramienta para futuros ataques, reflejando la rápida evolución de las tácticas y técnicas utilizadas en el malware.
Fuente: WeLiveSecurity by eSet.

Las claves de los certificados TLS fraudulentos en 30 segundos

• Tres registros afectados: los atacantes comprometieron los dominios de nivel superior .gh, .sl y .as, lo que les permitió alterar la resolución de dominios seleccionados.
• Certificados no autorizados: la manipulación del DNS facilitó superar las comprobaciones de control de dominio exigidas para emitir certificados HTTPS.
• Google intervino en Chrome: la compañía bloqueó los certificados fraudulentos identificados y colaboró con las autoridades de certificación para revocarlos.
• El alcance sigue sin estar claro: Google no ha publicado la lista completa de dominios afectados ni una cifra total de certificados emitidos.
• Los administradores deben actuar: la empresa recomienda vigilar los registros públicos de transparencia de certificados y restringir qué entidades pueden emitir certificados para sus dominios.

El incidente vuelve a poner de manifiesto una debilidad de la infraestructura de confianza de Internet: un certificado puede superar correctamente las comprobaciones habituales de emisión y, aun así, acabar en manos de un atacante si este consigue controlar temporalmente la infraestructura utilizada para demostrar la propiedad de un dominio.

Cómo consiguieron los atacantes obtener certificados válidos

Los certificados TLS (Transport Layer Security) permiten autenticar servidores y establecer conexiones cifradas entre clientes y servicios. Cuando un navegador visita una web mediante HTTPS, comprueba que el certificado presentado corresponde al dominio solicitado y que está firmado por una autoridad de certificación de confianza.

El problema aparece cuando un atacante consigue controlar el dominio o la infraestructura que se utiliza para verificar esa titularidad. Según Google, los responsables de estos ataques comprometieron los registros de .gh, .sl y .as, y modificaron registros DNS autoritativos y delegaciones de servidores de nombres para dominios seleccionados.

Con ese control temporal pudieron redirigir el tráfico hacia sistemas bajo su control y superar las comprobaciones automatizadas que utilizan las autoridades de certificación para verificar que quien solicita un certificado controla el dominio.

Google señaló que los certificados no autorizados afectaban a varios de sus dominios y a otros servicios de organizaciones importantes. No publicó una relación completa de las entidades afectadas ni precisó cuántos certificados llegaron a emitirse.

La compañía también aclaró que no había indicios de que se hubiera comprometido la infraestructura propia de las organizaciones afectadas ni de que las autoridades de certificación que emitieron los certificados hubieran incumplido los requisitos establecidos. El incidente se originó en el control de los registros de dominios de nivel superior, no en una intrusión confirmada en los sistemas de Google.

Un certificado fraudulento puede permitir que un atacante suplante criptográficamente un servicio cuando también consigue situarse en una posición desde la que interceptar o redirigir las conexiones. Por sí solo, disponer del certificado no garantiza que pueda leer cualquier comunicación cifrada: también necesita una vía para interponerse entre la víctima y el servicio legítimo.

Chrome bloquea los certificados identificados, pero no desaparece todo el riesgo

Google explicó que Chrome bloqueó los certificados no autorizados que identificó mediante CRLSets, un mecanismo que permite al navegador rechazar determinados certificados sin depender exclusivamente del proceso tradicional de revocación.

La empresa también trabajó con las autoridades de certificación implicadas para revocar los certificados correspondientes a dominios de Google. Estas medidas reducen la posibilidad de que los certificados detectados sigan utilizándose en ataques, pero no garantizan que se hayan localizado todos los emitidos durante los incidentes.

La revocación tradicional puede tardar en reflejarse en todos los clientes y sistemas. Por eso, los navegadores mantienen mecanismos adicionales para bloquear certificados concretos cuando detectan un riesgo. La protección tampoco es idéntica en todos los navegadores, aplicaciones y dispositivos, lo que complica la respuesta cuando un certificado fraudulento ha sido emitido por una entidad reconocida por el ecosistema.

Google indicó que los usuarios de Chrome no necesitan realizar ninguna acción específica para beneficiarse de los bloqueos que ha aplicado. Para los administradores de dominios, sin embargo, la recomendación es más exigente: la compañía advierte de que las medidas del navegador no deben considerarse una defensa suficiente.

La empresa reconoce que la complejidad de los secuestros de DNS impide garantizar que se hayan identificado todos los dominios afectados. También advierte de que los bloqueos de Chrome no protegen de forma fiable a quienes utilizan otros navegadores o clientes.

Por tanto, la situación no debe interpretarse como una vulneración confirmada de todas las organizaciones cuyos dominios aparecen en los registros de certificados. Lo que se ha confirmado es la emisión de certificados no autorizados para varios dominios, mientras que el alcance completo del incidente continúa sin conocerse públicamente.

Qué deberían revisar los administradores de sistemas

Google recomienda vigilar de forma continua los registros de Certificate Transparency (CT), un sistema público que permite consultar los certificados emitidos por autoridades de certificación. Los certificados de confianza utilizados por Chrome deben aparecer en estos registros, lo que permite detectar nuevas emisiones inesperadas con rapidez.

La vigilancia debe cubrir toda la cartera de dominios de una organización, incluidos los dominios regionales, los que apenas se utilizan y los que permanecen aparcados. Un dominio secundario puede convertirse en una vía de ataque si su registro o su configuración DNS no recibe la misma atención que la infraestructura principal.

Google también aconseja publicar registros CAA (Certification Authority Authorization), que permiten especificar qué autoridades de certificación están autorizadas para emitir certificados para un dominio. La empresa recomienda configuraciones restrictivas que incluyan vinculaciones con las cuentas ACME autorizadas, cuando corresponda.

Los registros CAA no impiden por sí solos la emisión fraudulenta durante un secuestro activo del DNS. Sin embargo, pueden ayudar a impedir nuevas emisiones cuando se recupera el control del dominio, especialmente si se restringen las cuentas autorizadas y los métodos de validación. Google advierte de que algunas autoridades pueden reutilizar comprobaciones de control de dominio almacenadas previamente, por lo que restaurar una política CAA restrictiva resulta especialmente importante tras un incidente.

Para los equipos de operaciones, estas medidas deberían acompañarse de una revisión de los accesos a las cuentas de registro, la configuración de DNS autoritativo y los procedimientos de recuperación. También conviene disponer de alertas ante cambios inesperados de delegaciones, direcciones IP y servidores de nombres.

El caso recuerda que HTTPS depende de varias capas de confianza: la seguridad del servidor, la resolución DNS, el control del dominio, las autoridades de certificación y los mecanismos de verificación del navegador. Proteger solo la aplicación web no basta si otra parte de esa cadena puede ser manipulada.

Preguntas frecuentes

¿Qué dominios de nivel superior fueron comprometidos?

Google identificó los registros .gh, correspondiente a Ghana; .sl, de Sierra Leona; y .as, de Samoa Americana.

¿Se comprometieron los servidores de Google?

Google afirmó que los incidentes no implicaron un compromiso de su propia infraestructura. Los atacantes manipularon registros de dominios y DNS para obtener certificados no autorizados.

¿Qué deben hacer los administradores de sistemas?

Google recomienda monitorizar los registros de Certificate Transparency, revisar toda la cartera de dominios y publicar registros CAA restrictivos para limitar las autoridades y cuentas autorizadas a emitir certificados.

¿Están protegidos todos los usuarios de Chrome?

Google bloqueó los certificados fraudulentos que identificó y señaló que los usuarios de Chrome no necesitan realizar ninguna acción. Sin embargo, la compañía no puede garantizar que se hayan detectado todos los certificados afectados ni que los bloqueos protejan de igual manera a otros navegadores.

vía: arstechnica.com