Mostrando entradas con la etiqueta OSINT. Mostrar todas las entradas
Mostrando entradas con la etiqueta OSINT. Mostrar todas las entradas

jueves, julio 30, 2026

MyThreatIntel: Plataforma de Threat Intelligence desde la experiencia en DFIR y Respuesta a Incidentes

La inteligencia sobre amenazas se ha convertido en una pieza fundamental dentro de la ciberseguridad moderna. Sin embargo, el principal problema al que se enfrentan hoy los analistas no es la falta de información. Ocurre, de hecho, todo lo contrario: existen demasiadas fuentes, demasiados datos y demasiados contextos dispersos.

Figura 1: MyThreatIntel - Plataforma de Threat Intelligence desde
la experiencia en DFIR y Respuesta a Incidentes

Durante una investigación real, ya sea en un entorno SOC, en un servicio de DFIR, en tareas de Threat Hunting o en un proceso de Cyber Threat Intelligence, el analista necesita responder con rapidez a preguntas muy concretas: qué actor está detrás de una campaña, qué infraestructura mantiene activa, si una organización ya ha sido publicada en un portal de ransomware, si la extorsión sigue en negociación, si ya ha habido filtración, qué vulnerabilidades se están publicando, qué indicadores se conocen o qué artefactos de malware estánrelacionados.

El problema es que esa información rara vez se encuentra en un único lugar. Normalmente está repartida entre Data Leak Sites, bases de datos de vulnerabilidades, repositorios de IoCs, servicios Onion, mercados de la Darknet, fuentes OSINT, catálogos de malware y repositorios de filtraciones. El resultado es un coste operativo claro: una parte muy importante del tiempo no se dedica a analizar, sino a buscar, ordenar y contextualizar. De esa necesidad nace MyThreatIntel, una plataforma pensada para reducir esa fricción y ayudar a que la inteligencia llegue al analista de una manera más estructurada, más rápida y más útil.

Una plataforma orientada al contexto

MyThreatIntel no se diseñó como un simple agregador de datos ni como un panel más de ciberseguridad. La idea era más ambiciosa: construir una plataforma capaz de obtener información desde fuentes heterogéneas, normalizarla, enriquecerla y ponerla en contexto. Fue precisamente esa necesidad operativa la que nos llevó a Javier Martí Sanz y a mí - Manuel Martínez Casasola -  a desarrollar MyThreatIntel. Tras trabajar en investigaciones forenses, respuesta a incidentes y servicios de inteligencia, la conclusión era clara: los datos existían, pero el esfuerzo necesario para convertirlos en conocimiento útil seguía siendo demasiado alto.


Actualmente, MyThreatIntel es una herramienta de Secure&IT, desarrollada para reforzar sus capacidades de Cyber Threat Intelligence y servir de apoyo en tareas de monitorización, análisis, investigación y respuesta ante incidentes. La plataforma permite centralizar y relacionar información que, de otro modo, tendría que localizarse y analizarse de forma independiente en múltiples fuentes.

Por eso, el valor de MyThreatIntel no reside únicamente en centralizar información, sino en relacionarla. Una víctima publicada por un grupo de ransomware puede vincularse con el actor responsable, su infraestructura Onion, el estado de la negociación, las filtraciones asociadas, posibles IoCs relacionados y, en determinados escenarios, incluso con las vulnerabilidades o artefactos de malware observados en una campaña.

Ese enfoque convierte la plataforma en algo más que una colección de secciones independientes: la convierte en un entorno de trabajo orientado a la investigación y al contexto.

Ransomware: visibilidad directa del ecosistema de extorsión

Uno de los pilares de la plataforma es la monitorización continua del ecosistema ransomware. MyThreatIntel sigue de forma directa los portales utilizados por los actores para publicar nuevas víctimas, manteniendo un histórico de actividad que permite observar tendencias, distribución geográfica, sectores afectados y volumen por actor.

Figura 4: Dashboard de ransomware con víctimas registradas,
distribución geográfica y actividad por actor.

Esto no solo facilita saber quién está publicando más víctimas en un momento dado, sino también analizar la evolución de los grupos y entender mejor el comportamiento del ecosistema criminal. Tener esa visión agregada, pero también aterrizada en cada incidente, aporta un enorme valor para analistas CTI, equipos CSIRT y servicios de respuesta a incidentes.

Figura 5: Registro de incidentes en crudo, con filtrado
por fechas, países, actores y sectores.

Además, la plataforma permite consultar el “registro en crudo” de incidentes, filtrando por fechas, países, actores o sectores. Ese enfoque combina visualización ejecutiva y detalle técnico, algo especialmente útil cuando se necesita pasar rápidamente de una visión global a un caso concreto.

Negociaciones: seguir la extorsión más allá de la publicación

Si hay una capacidad especialmente diferencial dentro de MyThreatIntel, esa es la monitorización de negociaciones. La mayoría de soluciones se detienen en la publicación de la víctima dentro del Data Leak Site. Sin embargo, desde el punto de vista de la investigación, ese suele ser solo el comienzo de la historia. A partir de ahí empieza una fase crítica: el proceso de extorsión.

MyThreatIntel monitoriza directamente, desde los portales de los propios actores, el estado de esas negociaciones: si siguen activas, si ha habido filtración parcial o completa, si la víctima ha desaparecido del portal o si existen indicios públicos de que el rescate ha sido abonado. Esta capacidad aporta una visibilidad muy poco habitual y permite entender mejor el ciclo completo de una operación de ransomware.

Figura 6: Sección de Negociaciones (Beta), con distribución
por actor, eventos monitorizados y pagos detectados.

Más allá del interés analítico, este seguimiento tiene un valor operativo evidente. Permite estudiar el comportamiento real de los actores, comparar patrones entre grupos y observar cómo evolucionan las extorsiones en el tiempo.

Vulnerabilidades: monitorización continua desde fuentes oficiales

La inteligencia sobre amenazas no se limita a seguir actores o incidentes activos. También requiere una vigilancia constante sobre la exposición técnica del ecosistema. Por ello, MyThreatIntel incorpora una sección de vulnerabilidades alimentada a partir de fuentes oficiales como NIST y CVE.org

Figura 7: Dashboard de vulnerabilidades, con severidad, fabricantes y frecuencia de detección.

La plataforma permite consultar CVEs descubiertas, severidad, fabricantes, vectores de ataque y metadatos asociados, facilitando tanto la revisión rápida de nuevas publicaciones como la exportación de resultados para otros flujos de trabajo.

Figura 8: Vista detallada de CVEs individuales con descripción, vector y puntuación CVSS.
 
La utilidad aquí no está solo en mostrar una lista de CVEs, sino en integrarlas dentro de un entorno de investigación más amplio. La vulnerabilidad deja de ser un identificador aislado y pasa a formar parte del contexto que rodea una amenaza o una investigación concreta.

Indicadores de Compromiso: del dato técnico a la utilidad operativa

Los IoCs siguen siendo una pieza esencial en investigación, detección y respuesta. MyThreatIntel incorpora un repositorio de indicadores con clasificación por tipo, criticidad y telemetría, permitiendo realizar búsquedas, filtros y exportación de resultados.

Figura 9: Dashboard de IoCs con volumen total, criticidad y distribución por tipo.

Aquí el objetivo no es solo acumular artefactos, sino facilitar su consumo real por parte del analista. Hashes, dominios, archivos y otros indicadores aparecen organizados de forma que puedan emplearse con rapidez durante una investigación o integrarse en tareas de detección.

Figura 10: Telemetría de indicadores, con fichas detalladas por artefacto.

Este enfoque resulta especialmente útil cuando el volumen de datos es alto y el analista necesita reducir ruido para centrarse en aquello que tiene mayor relevancia operativa.

Darknet & Markets: seguir la infraestructura donde operan los actores

MyThreatIntel también incorpora una capa específica para la vigilancia de servicios Onion y mercados de la Darknet. Este componente permite observar qué servicios continúan activos, cuáles han caído, qué mercados siguen operando y cómo evoluciona su infraestructura con el tiempo.

Figura 11: Vista global de Darknet & Markets, con servicios Onion,
mercados activos y distribución por grupos.

No se trata únicamente de listar URLs. El valor real está en mantener un histórico de disponibilidad, relaciones con actores y capturas o notas asociadas. En entornos donde la infraestructura cambia rápidamente, esa trazabilidad resulta especialmente valiosa.

Figura 12: Detalle de mercados Darknet, mostrando estado operativo y URLs monitorizadas.

De esta forma, la plataforma aporta una visión mucho más estable sobre un ecosistema que, por naturaleza, es altamente volátil.

Figura 13: Detalle de servicios Onion asociados a actores, con enlaces activos y caídos.

Filtraciones y grupos: conocimiento estructurado sobre el adversario

El repositorio de filtraciones añade una perspectiva distinta: la exposición histórica de organizaciones. Los registros pueden buscarse por nombre, fecha o tamaño, lo que ayuda a comprobar si una entidad, dominio o conjunto de datos ya apareció en una filtración conocida. Este componente puede utilizarse tanto en investigaciones de terceros como en análisis de exposición, procesos de ciberinteligencia y respuesta a incidentes. La información deja de estar distribuida entre referencias aisladas y pasa a formar parte de un catálogo consultable desde el mismo entorno.

Figura 14: Repositorio de filtraciones y catálogo histórico.

La sección Grupos funciona como una base de conocimiento sobre actores de amenazas. Incluye descripciones, aliases, infraestructura Onion, capturas y notas, permitiendo contextualizar rápidamente a un grupo sin depender de búsquedas dispersas.

Figura 15 Inteligencia de amenazas: fichas de grupos,
enlaces Onion y documentación asociada.

La relación entre actores, víctimas, portales, notas de rescate e infraestructura es uno de los puntos donde MyThreatIntel deja de comportarse como un agregador y empieza a funcionar como una herramienta de investigación. Al analizar una víctima, el investigador puede acceder al contexto del actor, revisar sus canales e infraestructura y observar su actividad documentada desde una única interfaz.

Malware y artefactos técnicos

El repositorio de malware reúne muestras con sus hashes, nombre, firma, tamaño, tipo y etiquetas técnicas. Esta clasificación permite localizar artefactos por familia o característica y relacionarlos con los indicadores utilizados durante una investigación.

Figura 16: Repositorio de muestras de malware, hashes, firmas y etiquetas.

El apoyo de MITRE ATT&CK aporta contexto sobre técnicas, tácticas y comportamientos, especialmente cuando una muestra forma parte de una cadena de intrusión más amplia. De este modo, el repositorio no actúa únicamente como almacén de archivos, sino como fuente de apoyo para análisis de malware, Threat Hunting y construcción de hipótesis durante una investigación.

Permutaciones DNS para investigar suplantaciones

La consulta DNS amplía la plataforma hacia la detección de typosquatting, phishing e infraestructura sospechosa. A partir de un dominio, el motor genera permutaciones y comprueba su registro utilizando diferentes TLD y palabras clave asociadas a accesos corporativos, identidad, Microsoft 365, VPN, correo, servicios cloud o soporte técnico.

Figura 17: Consulta de permutaciones DNS, TLD, palabras clave y dominios registrados.

El resultado permite distinguir entre dominios generados y registrados, revisar fechas de creación, aplicar filtros y exportar el análisis. Integrar esta capacidad dentro de MyThreatIntel facilita conectar una posible suplantación con el resto del contexto disponible, en lugar de tratarla como una consulta independiente.

Consumo mediante Web y API

La interfaz web está orientada a la investigación manual, pero la inteligencia también debe poder salir de la plataforma. MyThreatIntel dispone de una API con autenticación mediante Bearer Token, respuestas JSON estandarizadas, búsqueda de texto y filtrado por fuentes y categorías. Esto permite consumir vulnerabilidades, IoCs, muestras de malware, víctimas de ransomware, infraestructura Tor, mercados, grupos, negociaciones y filtraciones desde plataformas SIEM, herramientas SOAR, scripts o automatizaciones desarrolladas en PowerShell, Python, JavaScript y otros lenguajes.

MyThreatIntel puede utilizarse directamente desde https://mythreatintel.secureit.es/, donde centraliza toda esta información en una única interfaz. Además, como la plataforma dispone de API, lo que permite integrarla en flujos de trabajo, herramientas SIEM y SOAR, scripts de investigación o procesos de automatización propios. Este punto es importante porque la inteligencia no siempre termina en el panel. En muchos casos, su verdadero valor aparece cuando puede integrarse en otros procesos de seguridad y respuesta.

Conclusión

MyThreatIntel no nace para sustituir fuentes, sino para darles sentido conjunto. En un escenario donde la información está cada vez más fragmentada, el verdadero reto no consiste en recopilar más datos, sino en reducir el tiempo necesario para convertirlos en contexto útil. Ransomware, negociaciones, vulnerabilidades, IoCs, Darknet, filtraciones, grupos, malware y DNS no son piezas aisladas. En una investigación real suelen formar parte de una misma historia. La utilidad de MyThreatIntel está precisamente en ayudar a contar esa historia con menos fricción, más contexto y una mejor capacidad de respuesta.

Saludos,

jueves, abril 16, 2026

¿Qué se necesita para tener seguras las identidades digitales en la empresa?

La semana pasada un amiguete y compañero de profesión me hizo esta pregunta: "¿Que necesitaría para tener seguras las identidades digitales en mi empresa?" ¿Necesitaríamos invertir más en Soluciones de Gobierno de la Identidad, de Gestión de Cuentas Privilegias, Control de Acceso, CIAM, Multifactor Authentication? ¿O sería conveniente que empezáramos a mirar soluciones de ISPM (Identity Security Posture Management) o ITDR (Identity Threat Detection and Response)?

Figura 1: ¿Qué se necesita para tener seguras
las identidades digitales en la empresa? 

Una pregunta de muñeca rusa, donde una pregunta lleva a otra y a otro. Para responderle fácilmente, y comenzar la conversación con un poco más de contexto, la respondí cariñosamente que eso dependerá de los resultados de la Evaluación de Riesgos. Así que si ya tenía una duda, yo le acababa de meter un nivel más de complejidad, que hizo que se le quedara cara de sorprendida.
Hay que tener en cuenta que no en todas las organizaciones, los departamentos que gestionan la Seguridad de las Identidades Digitales, están integrados en el área de seguridad, y en muy pocos se realiza una evaluación de riesgos más o menos formal para concluir los controles a implementar en base a los riesgos identificados.

Riesgos de Seguridad de la Gestión de Identidades

Seguidamente la invite a reflexionar de manera una poco más profunda, y estuvimos comentando los escenarios riesgos principales que afectan a la Gestión de Identidades Digitales y que controles mitigantes en formato de soluciones de seguridad de la identidad sería conveniente implementar en base a los mismos:
  • Leavers: Casos frecuentes de personas que abandonan la compañía y cuyas cuentas de acceso a la organización no se desactivan a tiempo - o nunca- o usuarios que cambian de departamento y arrastran sus permisos de acceso a sistemas. En este caso deberíamos priorizar una herramienta de Gobierno de Identidades Digitales.
  • Cuentas Privilegiadas Sin Control: Administradores de sistemas o aplicaciones que mantienen el acceso privilegiado asignado de manera permanente y no se monitoriza / controla cómo usan sus privilegios. En este caso deberíamos priorizar la implementación de una solución que nos permita movernos a un escenario de Zero Standing Privileges (ZSP) y que asigne los permisos de administrador durante el tiempo que se necesiten para realizar la tarea administrativa y siguiendo el flujo de aprobación necesario.
También dependiendo del escenario podría ser conveniente implementar una solución que haga grabación e indexación de sesiones como las que aportar los Privileged Access Manager (PAM) tradicionales, aunque de manera generalista no es algo que, a mí personalmente, me guste del todo, ya que la telemetría que ofrecen hoy en día los End-Point Detection & Response (EDR) es suficiente en la mayoría de los casos para tener un tracking que nos permita identificar cómo los administradores utilizan sus permisos administrativos.
  • Acceso con una autenticación débil: Tanto a aplicativos como a servicios expuestos en Internet - e incluso que no están expuestos en Internet hoy en día 😊 -. En este caso los  Identity Providers (IDP) que la mayoría de las empresas tienen, como pueden ser Azure AD o Google IDP, ya tiene capacidades más que suficiente para proveer una autenticación robusta, pero claro hay que configurarlos bien. Sin embargo, hoy en día una autenticación con usuario y contraseña + un Multi-Factor Authentication (MFA) compartido por SMS es algo que se nos queda un poquito cortito en cuanto a seguridad.
Por lo tanto deberías abogar por implementar Passkeys en la medida de los posible, y ya de paso, quitamos a los usuarios el dolor de las passwords añadiendo unas políticas de acceso condicional que tengan una inteligencia mínima que haga que el sistema sea capaz de reaccionar frente amenazas del sistema de autenticación como puede ser cambios de ubicación imposibles o un usuario que se autentica con una parámetros que difieren bastante de sus comportamientos, tales como horarios y localizaciones de login.
  • Riesgos asociados con las identidades de Business Partners: Ya sean clientes, proveedores, o fabricantes, que consumen servicios digitales que provee la empresa. En este caso sería conveniente contar con un Customer Identity & Access Management (CIAM) que nos permita unificar la experiencia de usuario en su proceso de autenticación, aportando seguridad y reducción fricción, así como asegurar el cumplimiento a normativas que puedan ser aplicables como el Reglamento General de Protección de Datos (RGPD) y tunear la experiencia del usuario
  • Riesgo de Fraude debido a Conflictos de Segregación de Funciones: o dicho de otra de manera  más sencilla con un par de ejemplos, que el mismo usuario tenga permisos para hacer las nóminas y liberar los pagos, o que el mismo usuario tenga permisos para crear solicitudes de pedidos de compras y aprobar la mismas. 
En este caso necesitaremos una solución de estilo  Government Risk & Compliance (GRC) que nos permita controlar conflictos de segregación de funciones, idealmente de manera proactiva, y que sea multi aplicación, es decir, que no se limite a los permisos de una sola aplicación, como el ERP. Esto es algo que algunas herramientas de Gobierno de Identidades proveen, y también, obviamente, existen soluciones dedicadas a mitigar este tipo de riesgos

 

No creo que sea necesario seguir con más ejemplos, entiendo que con estos cinco casos se ve bastante bien que los riesgos que se busquen proteger en la gestión de identidades deben priorizar la decisión sobre que tecnologías debes implantar. Como habéis visto, además, no he querido tirarme al barro del riesgo relacionado las Non-Human Identities - y las tecnologías de seguridad para las Non-Human Identities -o las Identidades de Agentes IA, ya que estos actúan en nombre del usuario, o con su propia identidad, por lo que se debe tener en cuenta que los mismos van a trabajar en base objetivos y no de manera determinista, por lo tanto sus permisos es fácil que necesiten cambiar mientras estás realizando una tarea.

Esto seguro que nos da para otro artículo dedicado, aunque si me gustaría mencionar que esto a día de hoy es un riesgo relevante real, principalmente para organizaciones mas avanzadas tecnológicamente hablando (por supuesto que llegará al resto). Esta es una categoría que aún está siendo construida - no olvidéis que el primer Agentic AI lo vimos en diciembre de 2024, con lo que llevamos menos de un año y medio con los agentes, y empresas como Cloudflare están construyendo arquitecturas de referencia para la gestión de la seguridad de estas identidades.


Como conclusión, me gustaría resaltar la importancia de definir un roadmap de trabajo dentro del Plan Director de Seguridad con todas las iniciativas relacionadas con la Seguridad de Identidades en base a los riesgos que necesitemos mitigar. Y por supuesto, que seamos conscientes de que la seguridad de la identidad digital en muchas ocasiones (cada más) es la única capa de defensa, por lo tanto debemos tomarnos muy en serio esta labor, e implementar las medidas de protección pertinentes hasta llevar el nivel de riesgo a ratios aceptables para nuestra organización. O atente a las consecuencias.

Saludos,

Autor: Samuel López Trenado, especialista en Gestión de Identidades Digitales

jueves, abril 02, 2026

Cómo lograr el Check de Verified en LinkedIn con una Identidad Pública que no coincide con la Identidad Legal

Durante los últimos años, las redes sociales han ido incorporando sistemas de verificación con el objetivo de reforzar la confianza entre los usuarios. Estos sistemas consisten en un mecanismo mediante el cual la plataforma confirma que la persona o entidad que gestiona una cuenta es realmente quien dice ser. La recompensa visible para el usuario es una insignia, un pequeño icono —el conocido check— que, para muchos, simboliza autenticidad y fiabilidad.

Figura 1: Cómo lograr el Check de Verified en LinkedIn con una
Identidad Pública que no coincide con la Identidad Legal

En el caso de LinkedIn, esta insignia de verificación pretende indicar que un perfil pertenece a una persona real y que la información presentada coincide con su identidad profesional, pero hay que entender que no tiene por qué ser la información legal. A través de estos distintivos, la plataforma busca generar un entorno más seguro, donde los usuarios puedan interactuar con confianza, evitando suplantaciones y facilitando la creación de redes profesionales legítimas. Además, el sistema permite verificar no solo la identidad, sino también documentación, garantizando que determinada información que aparece en el currículo de la persona es correcto.

Sin embargo, esta lógica presenta un matiz a conocer. La verificación no siempre vincula de manera técnica y directa la identidad visible del perfil con la identidad que se ha validado internamente. Algo que hay que entender si te dedicas a la investigación de identidades en Internet. Es decir, un usuario podría mostrarse como verificado gracias al check, pero no existir una correspondencia completa entre los datos de la persona que aparece en el perfil y aquella que ha pasado el proceso de validación. 

La insignia ofrece cierta seguridad y confianza, pero no asegura la correspondencia absoluta entre la identidad verificada y la visible, por lo que debes conocer su funcionamiento correctamente para entender sus límites. En LinkedIn, un perfil verificado transmite una idea muy concreta, detrás de ese nombre hay una identidad confirmada, pero podría darse el caso que no fuera exactamente la visible, que es lo que la mayoría de usuarios interpreta sin pensarlo demasiado. 

 o que vas a ver a continuación no muestra una intrusión, ni una toma de cuenta, ni una vulnerabilidad técnica clásica. Muestra algo distinto, un flujo de verificación para reforzar la autenticidad del perfil, pero que deja que la identidad visible de una cuenta sea distinta de la identidad legal acreditada. Esto, si lo conoces, no tiene por qué ser malo. Muchas personas tienen nombres públicos que no son los que están en sus identidades legales, como Moxie Marlinkspike o Chema Alonso, pero aún así se puede verificar que son ellos. Moxie Marlinsspike protagonizo en un evento una anécdota que se hizo famosa cuando le pedían un ID con su nombre en un evento, y el dijo simplemente: "Google me", para que la persona que le registraba supiera que él era Moxie Marlinspike, - una identidad creada por él mismo - incluso si su identidad legal era otra.

Dicho de otra forma, el sistema comprueba que hay una persona real detrás - que ha hecho el proceso de Know Your Custormer -, pero el usuario final puede seguir sin saber quién es realmente esa persona . Cuando una insignia de verificación deja de responder a la pregunta “quién está detrás” y pasa a responder sólo a “hay alguien detrás”, el modelo de confianza debe ser otro. Es cierto que, si hay algún problema, la plataforma que ha verificado a esa cuenta, sabe quién está detrás de ella. Es decir, la identidad legal del que controla esa cuenta.

Lo curioso es que, de acuerdo con el flujo operativo descrito, ante una discrepancia, LinkedIn propone una salvaguarda consistente en mostrar el nombre oficial como complemento público en el perfil. Incluso llega a mostrar una vista previa en la que el alias, la insignia de verificación y el nombre legal aparecen conjuntamente, reforzando la transparencia y autenticidad del perfil. 

Sin embargo, esto no parece la mejor idea para perfiles que tienen una identidad pública bien reconocida que prefieren conservar la privacidad de su identidad legal. Como vamos a ver en esta demostración, aunque la intención declarada por LinkedIn en la ayuda es mostrar la identidad legal, el resultado operativo final, y el resultado finalmente visible demuestra que se puede ocultar la identidad legal, divergente con la identidad pública.


La prueba de concepto que sigue documenta precisamente eso. Cómo un perfil con un nombre divergente puede atravesar el proceso de verificación documental y biométrica, llegar hasta la fase en la que LinkedIn reconoce la discrepancia - y aunque promete transparencia -, terminar finalmente con la insignia añadida sin que se muestre tu identidad legal. Aunque hay discrepancia, la identidad legal no queda visible como complemento en el perfil. No se trata de una hipótesis. Se trata de una secuencia reproducida, documentada y observable. Vamos al grano.

1. Preparación de la cuenta y estado inicial

Qué se quiere demostrar con esta prueba de concepto:
  • Se parte de una cuenta con un nombre de perfil divergente respecto del nombre del documento.
  • El proceso de verificación documental y biométrica se completa correctamente.
  • LinkedIn detecta la discrepancia y ofrece una salvaguarda de transparencia.
  • La vista previa muestra que el nombre oficial aparecería entre paréntesis.
  • El resultado final observado es un perfil verificado con alias y sin nombre complementario visible.
La cuenta utilizada en la prueba muestra un nombre de perfil divergente, "El lado del mal", y en ese momento todavía no dispone de ninguna verificación añadida. 

Figura 4: Estado inicial de la cuenta: nombre de perfil divergente
y ausencia de verificación previa. 

Este punto es importante porque fija el estado previo. El alias visible, cuenta operativa y cero insignias activas.

2. Verificación documental y biométrica

El flujo de Persona valida la identidad de la persona real detrás de la cuenta. El material gráfico permite ver que el proceso pasa por el escaneo físico del documento, la comprobación biométrica y la validación final de identidad. 

Figura 5: Secuencia resumida del proceso de "Know Your Customer".
Escaneo del documento, verificación biométrica y validación positiva de identidad.

Para evitar exponer datos innecesarios, en esta versión se han omitido capturas donde aparecen campos documentales completos.

3. LinkedIn detecta la discrepancia y propone una salvaguarda

Una vez verificada la identidad real, LinkedIn no añade todavía la insignia. En ese punto aparece un mensaje explícito: el nombre del ID no coincide con el nombre del perfil y, como alternativa para poder verificar la identidad, se ofrece mostrar el nombre del documento oficial como complementario en el perfil.

Figura 6: Aviso de discrepancia de nombre y activación
de la salvaguarda propuesta por LinkedIn.

4. La propia plataforma enseña el resultado esperado

La siguiente pantalla es decisiva porque ya no es una interpretación del investigador. Es la propia plataforma la que muestra una vista previa de cómo debería quedar el perfil si se acepta la opción propuesta: alias visible, insignia de verificación y nombre oficial entre paréntesis como complemento público.

Figura 7: Vista previa del comportamiento esperado. El nombre oficial
aparece como complemento visible junto al alias.

5. Resultado final observado

Tras completar el flujo, la verificación queda añadida al perfil. No obstante, el resultado visible no coincide con la vista previa anterior, el perfil termina mostrando la insignia de verificación sobre el alias, pero sin el nombre oficial complementario que LinkedIn había presentado como mecanismo de transparencia.

Figura 8: Comparativa directa entre el resultado que LinkedIn
promete y el resultado finalmente observado en el perfil.

6. Interpretación técnica de la evidencia mostrada

La imagen documenta el estado final de la prueba de concepto y concentra, en una sola vista, el núcleo del fallo de lógica observado en el flujo de verificación de LinkedInDesde el punto de vista técnico, lo que se aprecia es la coexistencia de tres elementos que no deberían convivir de esta forma si la salvaguarda de transparencia se aplicara correctamente, según la ayuda de la plataforma.
  • Un nombre de perfil arbitrario o alias visible
  • Una insignia de verificación de identidad activa
  • La ausencia del nombre legal complementario que el propio flujo promete mostrar cuando detecta discrepancia entre identidad acreditada e identidad mostrada.
Figura 9: Resultado obtenido BYPASS Business Logic Error
 / Broken Identity Binding

Esto permite inferir que el proceso de validación documental y biométrica ha finalizado con éxito - se ha hecho el KYC,  el backend ha marcado la cuenta como verificada y tiene la documentación almacenada, pero que la capa de representación pública del perfil no está materializando de forma efectiva el mecanismo de unión entre identidad legal e identidad pública, que es algo que debes tener en cuenta.

Dicho de manera más precisa, la plataforma resuelve correctamente la pregunta “existe una persona real detrás de esta cuenta y sabemos quién es”, pero “la identidad pública que se muestra al resto de usuarios no tiene por qué ser la identidad legal que ha sido acreditada”.

Lo que se muestra no es una simple anomalía visual o un problema cosmético. Lo que refleja es una posible desincronización entre el estado de verificación concedido y la política de exposición del atributo de identidad complementaria descrito en la ayuda de Linkedin. En otras palabras, el sistema concede el distintivo sin hacer cumplir de manera consistente la condición de transparencia que él mismo presenta como alternativa cuando existe un desajuste de nombres, pero que por otro lado permite a las identidades públicas mantener la privacidad de sus identidades legales.

A nivel de lógica de negocio, esto encaja con un escenario de Broken Identity Binding, la identidad  legal validada existe, pero no queda correctamente enlazada con la identidad pública consumida por terceros. El resultado práctico es que el usuario que observa el perfil recibe una señal de autenticidad fuerte, pero que si carece del contexto mínimo necesario para interpretar correctamente qué ha sido verificado y bajo qué identidad, podría llevarle a confusión o error. 

7. Implicación de seguridad y abuso potencial de esta evidencia

En un sistema de verificación bien ligado, la insignia debería actuar como un atributo de confianza contextualizado. Es decir, no solo debería indicar que el proceso de validación ha sido superado, también debería permitir interpretar correctamente qué identidad ha quedado acreditada frente al resto de usuarios. Cuando esa unión falla, el distintivo conserva su fuerza visual, pero pierde precisión semántica. Es decir, podría parecer que la identidad legal es la que se ve públicamente es la misma - porque no aparece entre paréntesis otro nombre), sin ser así.

Eso abre la puerta a varios escenarios a tener en cuenta. Lógicamente, hay que pensar en la suplantación creíble con validación, ya que un actor podría construir un perfil con un alias, una identidad visual cuidada o incluso una identidad coincidente con la de un tercero, completar la verificación con su propia documentación legítima y terminar mostrando públicamente una cuenta que transmite autenticidad sin revelar el contexto real de la verificación. Para el observador externo, la insignia refuerza la apariencia, para el atacante, reduce el riesgo de ser detectado y aumenta credibilidad. Para limitar la suplantación de personas conocidas, por supuesto, Linkedin tiene los mecanismos de denuncia de suplantaciones, y por eso las empresas monitorizan las identidades de sus ejecutivos en la red para detectar estos posibles casos.

Hay que añadir que, además, en caso de que esta identidad fuera parte de un delito que se investigara, la plataforma podría entregar la documentación que usó la persona en el proceso de KYC, pero para engaños individuales a personas a través de redes sociales, podría dar a la identidad un halo de ser lo que se ve, cuando realmente es otra persona.

En este caso, el objetivo ya no es parecer una persona concreta, sino parecer una entidad fiable. Nombres como “Security Team”, “Compliance Department” o cualquier otra formulación institucional adquieren más potencia cuando van acompañados de una verificación activa. El problema no es solo el alias, también que el distintivo puede ser interpretado por la víctima como una validación indirecta del rol, del contexto o de la autoridad del emisor. Para ello hay que entender que las verificaciones pueden verificar también la documentación, pero puede ser que alguien verifique su identidad con este proceso, pero no verifique sus aptitudes, por lo que podría ser mintiendo en sus títulos y acreditaciones.

Cuando una plataforma proyecta una señal fuerte de autenticidad, terceros pueden usarla como referencia adicional en procesos de evaluación, contacto profesional, validación de antecedentes o interpretación pericial informal. Hay que entender bien los límites de la verificación, y si la identidad visible no queda unida con transparencia a la identidad legal acreditada - lo que podría ser una opción de privacidad - ,  y los que consumen estos límites no lo conocen, la plataforma introduce sin quererlo ruido precisamente en el punto donde debería reducirlo.

En otras palabras, el problema no está en que LinkedIn permita usar identidades públicas o alias. El problema aparece cuando el distintivo de verificación sigue actuando como una señal fuerte de identidad legal - tal y como dice en su ayuda - sin que el usuario pueda interpretarlo correctamente. Es decir, si la Verificación permite el uso de Identidades Públicas con privacidad de Identidades Legales, no debería decir que si hay discrepancia entre ellas mostrará las dos en la Verificación y luego que se pueda evitar eso.

Saludos,


jueves, marzo 05, 2026

Cloudforce ONE: Cloudflare Threat Report 2026

Cloudflare tiene una visibilidad de lo que está sucediendo en Internet muy especial. El 20% del tráfico mundial HTTP pasa por el Edge de Cloudflare, lo que permite que la compañía puede ver desde una posición privilegiada las amenazas, los ataques, y las evoluciones de tendencias que se están produciendo en tiempo real en la red.
Estos datos, además de mostrarse muchos abiertos a todos en Radar, se procesan, se generan insights de ciberseguridad, y están dentro del servicio de Cloudforce One, que se puede configurar para unidades de ciberinteligencia, CERTs, CSIRTs, etcétera.

Figura 2: Cloudforce ONE

Aprovechando esos datos, el equipo ha publicado el Cloudflare Threat Report 2026 que puedes descargar desde la siguiente URL2026 Cloudflare Threat Report, y que tiene la siguiente tabla de contenidos, donde como podéis ver, se analiza el mundo del Cibercrimen y los ataques Nation State.
En el se analizan los principales insights de ciberseguridad que son de interés en este año 2026, donde como se puede ver, la automatización de los ataques usando Inteligencia Artificial, es decir, el Hacking con IA, sigue siguiendo el primero de los temas a tener presentes. Por supuesto, los ataques Nation State, que hace años parecían "de película" y hoy en día, con el ecosistema geopolítico que se ha creado es el día a día en Internet.
También los ataques a servicios SaaS y cadena de suministro son una de las grandes preocupaciones a tener en cuenta este año, por ser uno de los grandes riesgos de ciberseguridad para las empresas, así que hay que reforzar seriamente ese apartado.
Además, hay que tener en cuenta los insiders en forma de empleados remotos que utilizan sistemas de DeepFakes, los ataques DDoS Volumétricos, así como ataques explotados por algunos grupos de cibercrimen robando tokens 2FA, y fallos en el relay de correo electrónico. Estos ataques DDoS han continuado batiendo records en tamaño, por lo que infraestructuras como la de Cloudflare son las únicas con capacidad global para detener dichos ataques.
En el informe también se dedica un amplio espacio - el informe tiene 52 páginas - a los grupos de cibercrimen y Nation State que están activamente operando en Internet, por si tienes curiosidad. Aquí tenéis un resumen de algunas operaciones en EMEA.
Como recomendaciones, el informe hace especial énfasis en aquellos puntos que deben ser prioridad para los equipos de seguridad de las empresas, donde el despliegue seguro de Inteligencia Artificial es una de las primeras prioridades a tener en cuenta.
Además, reforzar la gestión de la identidad pasando de MFAs a Identity First, para tener una monitorización constante de las identidades - incluidas las Non Human Identities -, y, por supuesto, toda al gestión de seguridad de los SaaS utilizados.
En el punto 4, la verificación humana de los empleados como recomendación de seguridad debido a la cantidad de ataques con DeepFakes en empleados remotos. Por supuesto, tener un sistema en Internet preparado para detener ataques DDoS Volumétricos, además de reducir drásticamente la superficie de exposición debido a los SaaS, y reforzar la seguridad de los sistemas de correo electrónico.

Y por supuesto, además de aprender cuáles son los riesgos de los sistemas, tener información actualizada en tiempo real de amenazas y protecciones a tener en cuenta. Insights e información de Ciberintelgiencia.

Figura 11: Cloudforce ONE

Si estás en un CERT o un CSIRT, te recomiendo que le eches una mirada a Cloudforce ONE que tiene información única aprovechando la escala de la infraestructura de Cloudflare.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  


domingo, marzo 01, 2026

Cómo identificar perfiles anónimos de una plataforma online en Internet usando LLMs y Agentes IA

Descubrir quién se oculta detrás de una cuenta de Twitter/X anónima, o de quién es en realidad un usuario de un foro de la DeepWeb, o de cualquier red social, es un trabajo de investigación con mucho de ciencia, donde la Inteligencia Artificial juega desde hace años un rol importante, con los algoritmos de clasificación basados en Machine Learning, por ejemplo.

Como era de esperar, estos técnicas de Open Source INTelligence (OSINT) para investigar personas e identidades en Internet, también sacan beneficio del uso de las capacidades de los LLMs para analizar textos de gran tamaño, como por ejemplo la biografía de un sospechoso o candidato, y grandes cantidades de pequeños textos - como comentarios o posts en redes sociales - para extraer la más mínima información de ellos y encontrar el Match entre ellos.
De eso va el trabajo que se ha publicado esta misma semana, que lleva por título: "Large-scale online deanonymization with LLMs" donde los investigadores han estado utilizando modelos LLMs para hacer el análisis de los CVs de los candidatos, y el análisis de los comentarios en foros online, en el estudio Hacker News y Reddit para comprobar la eficacia del Match
Para poder hacer la media, han contado con un base de pruebas de perfiles de Linkedin que apuntan a sus perfiles de Hacker News, para poder saber después si el Match que hace el modelo es correcto o no, así que todas las mediciones que presenta el estudio se basan en eso.
En el ejemplo de la figura anterior está el proceso lógico del sistema. En ese caso se trata de tener una entrevista, comentarios, mensajes donde el perfil anónimo ofrezca piezas de información, con las que se hace un perfilado de búsqueda, y un Agente IA se dedica a buscar el o los candidatos con más probabilidades. 
Al final, es como jugar al famoso juego de "¿Quién es Quién?" donde se van sacando datos de las preguntas y se genera un perfil que en cada nueva fuente de información descarta a otros. Sacar información de estos textos con un LLM es algo bastante sencillo. 

Figura 6: El modelo razona los matches

Esto se puede hacer no solo con textos, sino también con fotografías, como os expliqué en el artículo de "Investigando fotografías y personas con Multi-Modal Large Language Models", lo que deja claro que las capacidades de los nuevos modelos de IA son especialmente poderosas en la deanonimización.


La gracia es que lo puede hacer con fotografías públicas o privadas, y saca información "jugosa"de fotografías que se tienen que analizar masivamente en un análisis forense, por ejemplo, o en un investigación OSINT.

Todas estas técnicas de análisis de datos con LLMs para hacer Hacking, Pentesting o Forensics, las hemos tratado en el libro de "Hacking & Pentesting con Inteligencia Artificial" donde la utilización de las capacidades analíticas de los LLMs para extraer información de fuentes de datos diversas como fotos, vídeos, audios - o textos es fundamental.


Por supuesto, el artículo, en los datos experimentales da unos resultados fabulosos, comparándolos con algoritmos anteriores. Eso sí, como os podéis imaginar, a medida que aumenta el número de "candidatos sospechosos", el porcentaje de identificación de perfiles anónimos con éxito se degrada, obligando al tener más piezas de datos.
Pero, y aquí viene la pregunta interesante. Al trabajar en modo Agentic AI, el sistema puede estar vigilando cada pieza de información nueva que aparezca en forma de un nuevo comentario, lo que haría que cada vez el sistema pudiera tener nuevos datos para identificar a los perfiles anónimos. Es decir, cuanto más grande es la base de sospechosos, más difícil, pero cuanto más datos hay - y a lo largo del tiempo estos crecen - más fácil es identificarlos. Así que estos sistemas podrían estar monitorizando los foros e ir descubriendo gente cada día. Brutal.

Figura 11: Libro de Machine Learning aplicado a Ciberseguridad de
Carmen TorranoFran Ramírez, Paloma Recuero, José Torres y Santiago Hernández

Si te interesa la IA y la Ciberseguridad, tienes en este enlace todos los postspapers y charlas que se han  escrito, citado o publicado en este blog sobre este tema: +300 referencias a papers, posts y talks de Hacking & Security con Inteligencia Artificial.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  


Entrada destacada

Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment. Nuestro nuevo libro en 0xWord

Pocas veces me ha hecho tanta ilusión que saliera un nuevo libro en 0xWord como con este libro de " Hacking IA: Jailbreak, Prompt Inje...

Entradas populares