Cómo los Agentes IA de Red Team hacen ataques de Ingeniería Social con Fake Accounts

Esta semana, el AI Security Institute de UK, ha publicado un informe sobre un par de incidentes con Red Teaming Agentic AI, donde estos hacen alarde de su capacidad de realizar ataques complejos, con múltiples fases, y donde buscan engañar a humanos para conseguir sus ataques, como haría cualquier adversario que necesita vulnerar una debilidad en las personas que administran los sistemas, para conseguir su objetivo.

Figura 1: Cómo los Agentes IA de Red Team hacen ataques

de Ingeniería Social con Fake Accounts

El informe, marcado como "Security Incident INC-2026-07-28-01" fue publicado el pasado 4 de Agosto, y donde se centra en las acciones que los Red Team Agentic AI decidieron salirse a Internet y atacar proyectos y personas fuera del ámbito de la evaluación. Según cuentan en el informe, probando el comportamiento de los diferentes modelos frente a un reto concreto, el resultado fue el siguiente:

"Ejecutamos este desafío 122 veces en varios modelos. Nuestra investigación reveló que, en 10 de esas ejecuciones, un agente de IA tomó medidas autónomas y no autorizadas en el entorno real de internet, dirigiéndose a personas u organizaciones reales. En total, catalogamos 19 acciones de este tipo. 

 

Casi todo este comportamiento (17 acciones) provino de un solo modelo, Mythos 5 de Anthropic, mientras que 2 acciones involucraron a GPT-5.6-Sol de OpenAI con los clasificadores cibernéticos (mecanismos para prevenir el uso indebido) desactivados. 

 

En el caso más grave, un agente intentó insertar código malicioso en un proyecto de código abierto. En un intento por lograr que el código fuera aprobado, el agente recurrió a la ingeniería social: creó identidades falsas en línea y las utilizó para presionar al mantenedor del proyecto para que aprobara el código. Un mantenedor humano lo detectó y se negó a aprobar el código malicioso."

Las Técnicas de Ingeniería Social son bien conocidas en el mundo del Red Team, y son fundamentales en muchos de los incidentes de seguridad que sufren las organizaciones hoy en día. Correos de Spear-Phishing, Spam-Phishing, llamadas telefónicas, SMSs, e incluso representaciones con actores en los centros de trabajo.

Figura 2: "Social Hunters: Hacking con Ingeniería Social en el Red Team" 

de 0xWord. Escrito por Marta Barrio y Carolina Gómez de Securiters

Uno de los Agentes IA, en este caso, intentó hacer un Supply Chain Attack, es decir, intentar atacar a un proyecto OpenSource que había identificado como parte de las piezas tecnológicas del reto que tenía que resolver.

Figura 3: Time-Line del Supply Chain Attack

Para atacar a este proyecto, hizo una Pull-Request (PR) con un código malicioso, que fue detectado por uno de los humanos mantenedores del proyecto y rechazado por contener malware. Para conseguir que este código fuera aprobado, decidió conseguir la aprobación usando diferentes técnicas. 

Figura 4: Prompt Injection para los Coding Agents

La primera de ellas, insertando un ataque de Prompt Injection para que cualquier Coding Agent que lo leyera ejecutar sus comandos. 

Figura 5:"Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment"

escrito por Chema Alonso con la colaboración de Pablo González, Fran Ramírez, Amador Aparicio, Manuel S. Lemos y José Palanco en 0xWord

Pero además, hizo dos cosas más. La primera, realizar un ataque de Spear-Phishing contra todos los usuarios mantenedores del código.

Figura 6: Orden cronológico de las acciones en los ataques de Ingeniería Social.

La segunda, con una nueva cuenta falsa poner un comentario haciendo creer que era una persona que había revisado el código y que estaba perfecto para ser mergeado en el proyecto. Como si fuera un revisor humano colaborando con el proyecto.

Figura 7: Conversación en GitHub y presión a los humanos

En la conversación completa se puede ver varios hechos interesantes. El primero de ellos es cómo hace el ataque y cómo se crea una nueva persona para apoyarse a sí mismo. Pero cuando el humano lo detecta, intenta presionarle para que hable con él, midiendo el tiempo que tarda el humano en contestar: "han pasado muchas horas desde que dejaste el warning".  

Figura 8: "The Art of Pentesting" El nuevo libro de

0xWord para formarse como pentester

Por último, cuando, se da cuenta de que ha sido detectado, lo que hace es simular que ha sido un error genuino  normal y corriente en lugar de un ataque, e intenta cubrir sus acciones con nuevos mensajes.

Figura 9: Cubriendo sus acciones

Dentro del informe, donde se analiza en detalle este incidente, también tenemos información de las trazas de razonamiento, donde podemos ver qué está pensando el Agente IA en todo momento a la hora de realizar sus acciones, y es tremendo.

Figura 10: Time-Line de razonamiento y acciones

En la image anterior podemos ver cómo va encadenando las acciones y el razonamiento que va haciendo en cada momento, evaluando si realmente está en Internet o no, si el proyecto es real o es una simulación, y si debe interactuar con las personas o no.

Figura 11: Consideraciones para los razonamientos.

En la siguiente imagen, podemos ver cómo decide preparar un ataque de Prompt Injection para otro posible Coding Agent que pudiera leer la pull request con una secuencia de comandos maliciosos.

Figura 12: Eligiendo un ataque de Prompt Injection en un comentario.

Está clara la potencia de los modelos de IA para hacer Agentic AI en el mundo del Hacking y el Pentesting con IA, por lo que no podemos obviarlos y hay que utilizarlos masivamente. El problema, ya no es que consigan su objetivo sino cómo les decimos qué pueden hacer y qué no pueden hacer para conseguirlo.

Figura 13: Hacking & Pentesting con Inteligencia Artificial.

En 0xWord, escrito por Pablo González, Fran Ramírez,

Rafael Troncoso, Javier del Pino y Chema Alonso

Esta PsicopatIA de acciones, donde no importa lo que es legitimo o no, lo que está bien o no, lo tienen que seguir haciendo las personas. De todo esto, ya os había hablado en el experimento de "Problem Solving con IA: Ético o No Ético" donde os contaba las conversaciones que tengo con mis hijas sobre la resolució de problemas....pues bien, en el mundo del Problem Solving con Agentes IA, va a ser más necesario que nunca. 

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Figura 14: Contactar con Chema Alonso

¿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.

Figura 2: Open Source INTelligence (OSINT): Investigar personas e Identidades en Internet 2ª Edición de 0xWord, escrito por Vicente Aguilera y Carlos Seisdedos

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.

Figura 3: Demostración de Robot de Tokens OAuth de identidades

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.

Figura 4: Las Yubikeys para gestión de Passkeys

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.

Figura 5: Identidades NO Humanas (NHI "Non-Human Identities").

La Gestión de un Riesgo de Seguridad Emergente

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.

Figura 6: Arquitectura de MCP Security en Cloudflare

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

Contactar con Samuel López Trenado

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. 

Figura 2: Open Source INTelligence (OSINT): Investigar personas e Identidades en Internet 2ª Edición de 0xWord, escrito por Vicente Aguilera y Carlos Seisdedos

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.

Figura 3: Según la ayuda de Linkedin, el nombre legal entre paréntisis,

y el nombre público destacado.

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 LinkedIn. Desde 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,

Autor: Catalin Barsan Apostolescu

Contactar con Catalin Barsan Apostolescu

Fear of the Dark: Detección de Suplantación de Identidad y DeepFakes usando Verificación de Identidad en MyPubicInbox

Continuando la serie de Fear of the Dark, como parte de la presentación de RootedCON, sincronizamos la publicación de un servicio para Perfiles Públicos que llevaba tiempo con ganas de tener. Como os he contado muchas veces, me he topado con la experiencia de la suplantación de mi identidad muchas veces, y por eso quería tener una forma de solucionar esto, mediante una Verificación de Identidad explícita, en este caso, usando MyPublicInbox.

Figura 1: Fear of the Dark: Detección de Suplantación de Identidad

y DeepFakes usando Verificación de Identidad en MyPubicInbox

La idea es muy sencilla. Supongamos que tú estás por ahí en las redes, y supuestamente te has topado conmigo, con Chema Alonso en un foro, en un canal de chat, o alguien que has encontrado te ha dicho que yo es mi amigo y que yo hago trabajos de hacking, que invierto en nosequé, o que yo estoy detrás de algo, y entonces un día tienes un chat o una vídeo conferencia "conmigo"... 

Figura 2: Verificación de Identidad en MyPublicInbox

Ya te digo yo que seguramente sea un Suplantación de Identidad y puede que estén usando una DeepFake, así que, sencillo. te vas a mi perfil en MyPublicInbox, y solicitas una Verificación de Identidad, que de momento es un servicio gratuito para todos los usuarios de MyPublicInbox.

Figura 3: Verificación de Identidad en MyPublicInbox

Desde ahí puedes enviar una evidencia, mediante una captura de pantalla, junto con una descripción de dónde supuestamente estás teniendo una reunión virtual conmigo, un chat, o una conversación. Si estás teniendo esa supuesta reunión conmigo, puedes "decirme" que quieres Verificar Mi Identidad sin ningún problema, que yo pasaré este proceso contigo.

Figura 4: Te llevará a tu cuenta de MyPublicInbox

para solicitar la Verificación de un Perfil Público

Esto generará una Petición de Verificación de Identidad que me entrará en Mi buzón de MyPublicInbox para que pueda revisarla, con toda la información que me has enviado. Solo tengo que ir a la sección de Verificación de Identidad y tendré en la zona de Verificar Identidad la petición.

Figura 5: Petición de Verificación de Identidad

Y ahora, pues con pulsar en Revisar tendré acceso a los detalles que me hayas proporcionado, con la captura de la imagen por delante, así que puedo ver si es una conversación mía de verdad o no. En este caso, para la demostración he subido una fotografía mía, pero lo suyo es subir la captura de una vídeo conferencia o del chat, o de lo que sea que se supone que soy yo.

Figura 6: Revisión de los datos de la petición de Verificación de Identidad

Y como yo soy yo, y sé si yo estoy haciendo ese chat, esa vídeo conferencia, esa reunión virtual o tengo esa cuenta en ese supuesto foro, pues daré a Rechazar o Verificar, con lo que generará un PDF con los datos del proceso de la Verificación o la No Verificación.

Figura 7: Informe de Verificación

El documento son unas páginas donde se detallan los datos de la petición, los datos de las fechas, y que ha pasado por los servidores de MyPublicInbox, que el usuario concreto que recibió la petición la revisó y dijo que sí, que era él, o que no, que no era él.

Figura 8: Informe completo firmado digitalmente

La única Verificación de Identidad que utilizamos ahora mismo es la del dueño de la cuenta, que sabe si él está o no está teniendo esa reunión o no. Es como si me llamara un amigo y me dijera: 

"Oye Chema, ¿eres tú el que está ahora en el foto de XXXX diciendo esas cosas?" 

Y yo le confirmará que sí o que no. Lo que me ayudará a mí a saber dónde me están suplantando la identidad y a él a protegerse contra una estafa.

Figura 9: Configuración de Verificación de Identidad en MyPublicInbox

Para configurar esto este servicio en MyPublicInbox, si eres un Perfil Público, puedes activarlo en el menú de tu cuenta de MyPublicInbox en la sección de Verificación de Identidad - Configurar Verificación. En el siguiente vídeo tienes una demostración de proceso completo.

Figura 10: Verificación de Identidad en MyPublicInbox

Al final, a pesar de que sea un servicio dependiente de una identidad en Internet - la de MyPublicInbox - ya obliga a los ciberestafadores a primero tener que robar la cuenta de MyPublicInbox, y luego a hacer la DeepFake o la suplantación, por lo que es una protección más antes de enviar dinero, o hacer cualquier tontería. 

Figura 11: "Ciberestafas: La historia de nunca acabar" (2ª Edición).por Juan Carlos Galindo en 0xWord.

Y por supuesto, desde MyPublicInbox monitorizamos el uso de este servicio para detectar situaciones de fraude, que además de mucha víctima, también hay mucha ciberestafa, por lo que la monitorización constante es clave siempre.

• Fear of the Dark: Fear, Data & Fake News
• Fear of the Dark: DeepFakes, Sappo & Sentiment Analysis
• Fear of the Dark: Detección de Suplantación de Identidad y DeepFakes usando Verificación de Identidad en MyPubicInbox
• Fear of the Dark: Primal Fears & Retórica IA
• Fear of the Dark: Deep Fakes, Fake News & Primal Fears
• Fear of the Dark: Un pequeño estudio de medios y miedos

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

La "shittización" en contra de hacer las cosas simples

Hace años, más de una docena, usaba a mis queridos héroes de "The Big Bang Theory" para explicar cómo de difícil lo habíamos hecho los que trabajamos en ciberseguridad para que las personas normales se pudieran conectar de forma segura a una red WiFi y a Internet. En el artículo de "Mea Culpa, Penny" explicaba todas las cosas que un usuario debía saber para configurar una VPN que se tunelizara a través de proxys, firewalls de redes,... ¿La quiere L2TP, SSTP o PPTP? 

Figura 1: La "shittización" en contra de hacer las cosas simples

Si eso se lo tengo que decir a mi madre, mejor la tengo que decir que no se conecte. Pero esta complejidad constante de la tecnología se ha ido extendiendo a la guerra comercial por el usuario, lo que hace que cada vez el número de opciones, los diseños de los interfaces, y el salto conceptual intelectual que el diseñador de un UX espera de un usuario, es cada vez mayor. 

En los foros tecnológicos se dice que un UX se ha "shitted" o "enmierdado" cuando la cantidad de opciones para el usuario, la anarquía de la distribución, la diversidad de los controles que debe tocar, y la cantidad de cosas que el usuario "debe suponer" para poder manejarlo, es enorme, y genera frustración en los usuarios. Esto, que parece evidente, es muy complicado de hacer. Hacer las cosas simples require de mucho trabajo, y para ello hay que primar al usuario o consumidor, por encima de las necesidades de negocio.

Cambiar de terminal iPhone

Os cuento esto por dos casos que he sufrido esta semana, que han sido bastante significativos. El primero de ellos con la migración de mi iPhone. Este es un proceso que he realizado ene veces ya, porque todos los años voy migrando mi iPhone. Esto implica migrar las apps, las fotos, los datos, etcétera... Todo esto bien, pero pero cuando llegamos a las partes de seguridad, la cosa se complica un poco. En mi caso, el iPhone era americano, además, como tengo en el mismo la conexión personal y la profesional, tenía una SIM y una eSIM, de dos países diferentes, además de que tenía que pasar de SIM a eSIM obligatoriamente.

El proceso, por supuesto, no funcionó correctamente, y acabé teniendo que ir a tienda, borrando las eSIM creadas virtualmente a partir de la SIM, y teniendo que comprar nuevas eSIM para el terminal americano. Eso hizo que perdiera los contactos de la SIM, y los contactos de la SIM perdidos generaron que se borraran también de la agenda, y por ende de WhatsApp y por ende usuarios dejaron de ver mi foto y me escribieron "¿Me has bloqueado?" No, estoy migrando un iPhone, no worries. Algunos se habrán enfadado y me habrán borrado a mí, así que me ha hecho perder amigos.

Como tengo Multi-SIM para dos países distintos, voy cambiando qué SIM activo o desactivo, pero claro, en la nueva versión de iPhone asocia a cada contacto una SIM por defecto, y cuando no está conectada esa SIM te sale una alerta que dice: "¿Quieres cambiar la asociación por defecto de la SIM a este contacto para poder llamar?" Y un sinfín de lindezas más, como por ejemplo que los contactos de iOS ahora tienen el botón de contactos, donde sale la lista y solo se puede hacer scroll y pulsar a la derecha en unas letras muy, muy, muy chiquititas... que no sé quién ha diseñado.

Figura 2: Esta me ha encantado. El número que el banco ha pasado a Apple es erróneo y después de llamar al Contact Center de ese número y esperar 20 minutos me dicen: "El número que te da iPhone no es de tu banco, somos otro banco". Genial.

Con la SIM ha sido una fiesta, pero luego hubo que migrar las Wallets, las apps bancarias, los 2FA, las autenticaciones de las herramientas de mensajería, etcétera, etcétera, y para cada una el proceso con la entidad es distinto. Instala app, inicia sesión con las credenciales, por el 2FA, te falta la passkey, recupera password, envía SMS, es de otro país y no llega, desactiva SIM, activa la otra, etcétera. Muy divertido y entretenida la gincana de migrar un terminal iPhone.

La autenticación doble con la identidad simple

La más divertida ha sido una app de un servicio - permitidme que no diga la empresa porque tengo amigos en ella y quiero arreglarlo antes -, donde al ir a hacer Login me ha dado la opción de usuario y contraseña, y en paralelo la opción de "Login con Google". Como no recordaba la contraseña - llevaba la app instalada mucho tiempo con autenticación automática con FaceID - le he dicho que autentique con Google. Y... surprise, me he encontrado con que usé la cuenta de Google sí, pero no con autenticación delegada, sino que lo hice con una contraseña, así que estamos en el caso de misma dirección de e-mail con doble autenticación, con usuario y contraseña o con IdP delegado usando OAuth.

Esto es un problema de arquitectura que los responsables de identidad y seguridad deben resolver, y si no lo hacen bien, genera escenarios de ataque como os comenté en el artículo del año 2022 : "Pre-Hijacked Accounts: o cómo robar una cuenta a un usuario antes de que se la cree". Dependiendo de cómo lo resuelvan, se pueden dar unos casos u otros. En mi caso, ha sido un DoS en toda regla que aún no he podido resolver y que voy a resolver llamando a mis colegas en esa empresa. 

El proceso ha sido muy divertido. Me enfrento al login y doy a "Login with Google". Comienza el proceso de autenticación delegada, y el sistema descubre que mi cuenta ya está creada pero con autenticación con contraseña. Salta el sistema de protección y unión de los dos procesos de autenticación para la misma identidad y me pide la contraseña que tiene la cuenta. Correcto. No la recuerdo, así que voy al proceso de recuperación de contraseña. Me manda el enlace de recuperación al correo de la cuenta de Google. Ojo que me lo envía a la dirección de correo con la que acabo de hacer login con Google, luego... ¿para qué? Si acabo de hacer login con Google, tengo acceso al Gmail del login de la cuenta, así que es un paso innecesario que no añade ninguna seguridad, pero para el sistema serán dos procesos independientes, y es el usuario el que se tiene que adaptar a la arquitectura y no al revés.

Da igual, sonrío, hago clic para cambiar la contraseña de la cuenta, pongo una y me dice... "No se puede cambiar la contraseña a esta cuenta". ¿Por qué? Pues porque en vez de mantener los dos autenticadores - con Google y por Usuario/Password, ha fusionado a un sólo autenticador, pero hasta que no introduzca la contraseña anterior - que no me deja cambiar - no puedo iniciar sesión. Conclusión "Deadlock" de libro por un mal diseño de seguridad. 

Después de dos días migrando cosas, aún me quedan un par de tarjetas bancarias que por motivos "corner case" aún no he conseguido migrar, y una cuenta de servicios de la empresa que por geo-location tampoco me permite procesar, pero más o menos lo tengo todo. Pero mientras pasaba por este proceso, me imaginaba a mi madre, y a muchas, muchas, muchas personas que tienen que pasar por aquí recordando que yo entiendo qué me están pidiendo, qué me está pasando, cuál es la situación en la que estoy en todo momento, pero que para ellas puede ser un dolor increíble.

La nueva "Simple" Televisión

Esta parte, que ha sido una de ellas, no ha sido la única experiencia que he tenido estas últimas 72 horas con esto, ya que además he querido cambiarle una televisión a mi madre para quitarle el descodificador y que solo tuviera un mando - de la SmartTV - y que no se confundiera. Al final, su problema consiste en que enciende la Televisión y el Descodificador y que si todo va bien, no hay problema, coge el mando del desco y cambia los canales y ve la tele - que es lo único que ella quiere -. Pero... si usa el mando de la SmartTV para subir o bajar canal, la SmartTV cambia el Source y se va a modo TV quitando el HDMI 1 de su fuente, y adios televisión. Y mi mamá, de 74 años, piensa que "ya se me ha ido la televisión".

Pues bien, le dije, ¨te voy a cambiar la televisión que está vieja, y te voy a poner la tele en una app y quitamos un mando del medio". Precioso decir, imposible para ella. Al final, encender la televisión y me pide una cuenta de la empresa de SmartTV que tengo que crear con un QRCode - imaginaos a una persona de 74 años ante eso -, después me pide que instale una app en el terminal, así que hay que usar las cuentas de Apple para ponerla en el iPhone, la instalas, te autenticas en la app con un correo y una password, te manda un SMS como 2FA, luego sigues un Wizzard de permisos para la app, y si quieres las noticias de la compañía de la televisión, las ofertas, los datos que le quieres dar de la app, y luego te pide el código que ves en la pantalla de la televisión de 14 dígitos, para darla de alta en tu app.

Y todo eso, en la primera pantalla de configuración de la SmartTV. 

Después de más de 20 pasos y una hora de configuración, con las ofertas de Amazon Prime gratis un mes, la de Apple TV, de quitar las apps de SmartThings para IoT, las autenticaciones en las diferentes apps, el inferfaz usa controles de usuario de tabs arriba, con líneas de vídeos y apps en un scroll infinito para abajo, y paneles que se expanden en los laterales. Así que me pongo con mi madre a enseñarle, y después de decirle 

"no, esa película no la puedes ver porque es de una promoción de un mes gratis de Apple TV y te lleva a esa app. Dale para atrás. Vaya, no sale. Pues dale al inicio. Ahora vete a la sección apps. Sí, tienes que bajar. Con las flechas. Ahora. Dale al ok. ¿El ok? Ah, espera, en este mando es distinto, el ok, es ese cuadrado con una flecha que sale de él. Sí, ahí. Ahora dale a la app. Sí, no te sale el canal que tenías antes, porque se personaliza con tus datos de navegación, así que hasta que no lo veas varias veces no te lo va a poner en su sitio, así que tienes que entrar en la guía. Es ese icono con unas rayas arriba a la izquierda. Sube con las flechas. Ahora entra, y sale la guía, ahora baja hasta que encuentres el canal. Sí, sigue bajando que hay cientos de canales. Ahora dale al ok. Sí esa es la ficha del canal. Dale al ok. No, que le has dado a la flecha y te has movido. Vuelve atrás. No, te has ido a la guía otra vez, era que movieras la flecha a la izquierda. No pasa nada vuelve a bajar. Sí, sé que son muchos... "

Pues bueno, le he quitado al nueva SmartTV, y le hemos puesto el sistema del desco (con una sola televisión) y al mando de la televisión anterior, para que no lo toque, Mi Survivor ha decidido ponerle celo a todos los botones menos al de encender y apagar, para que sepa que ese mando solo es para encender la televisión y nunca lo cambie de Source. Y no son pocos los que hacen eso.

Figura 3: Mandos "simples"

El MacBook Pro no arranca

Ya la última de las aventuras con la "shittización" de la tecnología, ha sido con mi MacBook Pro, que ha decidido no arrancar esta mañana - por eso estoy escribiendo el post tan tarde -. No tiene botón de hard-reset, la batería está cargando, pero no arranca. La última vez que me pasó eso, tuve que esperar dos días a que descargara toda la batería, y empezar de nuevo a cargarlo, y entonces funcionó, pero no tengo ni idea de qué le ha pasado. Tengo copia de seguridad de todo, así que no hay problema, pero tengo la seguridad de que si lo llevo a la tienda Apple me van a decir:

"Está roto, no se puede recuperar nada, compre otro". 

UPDATED: 20 horas después, se ha descargado y ha arrancado el MacBook Pro... otra vez como nuevo. Sin comprar ningún otro.

En resumen, menos mal que estoy al día de la tecnología y entiendo cómo funciona, entiendo qué está mal hecho en los sistemas, y al menos sé qué debo hacer para avanzar desde una situación a otra para conseguir arreglar el segundo paso, pero hablando de esto hace unos meses con un viejo colega de armas, sentados cómodamente, enumerábamos la cantidad de productos que eran fáciles, guays, sencillos y que se han "Shitted".

Unos meses después, os estoy escribiendo este artículo, porque cada vez vamos más rápido sacando tecnología, cada vez tiene menos QA, cada vez los UX son más "shitted" por permisos, seguridad, necesidades de negocio, etc... y hacen que las funciones core (como en el ejemplo de "ver la tele") estén cada vez más lejos de los usuarios. Recordad que os conté el lío que tuve con el bug de UX en WhatsApp solo por el tamaño de letra...

¿Tienes alguna experiencia similar? Déjamela en comentarios que me encantará leerla...

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)