Cómo detecta LinkedIn la automatización: hallazgos en el código de 16 extensiones, pruebas en la nube y el motor de detección de LinkedIn

Analizamos 16 extensiones de automatización de LinkedIn para ver qué hacen con las sesiones, las cookies, las llamadas del navegador y los servidores de los proveedores.

También nos registramos en 7 servicios en la nube con dos cuentas en cada uno y contrastamos las direcciones IP de salida que se les asignaron con una base de datos independiente de reputación frente al fraude.

La tercera parte de la investigación examinó el código de las propias páginas de LinkedIn. Ese código incluye un escáner de extensiones con 6 167 objetivos, el sistema Spectroscopy, que analiza el modelo de objetos del documento (DOM), y una huella digital del dispositivo basada en 48 parámetros que puede acompañar a las solicitudes de sesión.

Esta guía muestra qué señales pueden aumentar el riesgo para la cuenta, qué arquitecturas de automatización exponen más señales y cómo puede auditar cualquier extensión en unos cinco minutos.

En resumen: 9 aspectos que debe conocer antes de instalar cualquier herramienta

1. LinkedIn puede analizar los navegadores basados en Chromium en busca de extensiones conocidas. Esto se denomina detección activa de extensiones (AED). A mediados de junio de 2026, el código de LinkedIn sondeaba 4 934 identificadores de extensiones de Chrome y la lista crecía en torno a 12 al día.
2. Las herramientas puente de cookies crean una de las configuraciones de mayor riesgo. Estas extensiones leen la cookie de sesión li_at de LinkedIn y la suben a la nube del proveedor, que después puede actuar desde su cuenta mediante la IP de un centro de datos. Encontramos este patrón en el código de 9 herramientas de uso generalizado.
3. Leer cookies no es lo mismo que exportar su sesión. Algunas herramientas leen las cookies, pero mantienen la sesión localmente. La verdadera pregunta es adónde va el valor de la cookie, por lo que rastreamos esa ruta en todas las herramientas de esta guía.
4. Bloquear la telemetría de LinkedIn puede revelar la herramienta en lugar de ocultarla. Algunas extensiones bloquean los endpoints de seguimiento de LinkedIn. Si uno de ellos sigue enviando información, LinkedIn podría detectar que se están bloqueando otras rutas de telemetría.
5. La huella digital de su dispositivo puede acompañar a las solicitudes de sesión. LinkedIn recopila 48 señales del dispositivo, entre ellas gráficos, audio, fuentes, la IP local mediante comunicación web en tiempo real (WebRTC) e indicadores de automatización. Esa huella se cifra y se adjunta a las solicitudes de la API durante la sesión.
6. La detección se entiende mejor como un modelo de puntuación. La presencia de extensiones, los rastros de código, las anomalías de red y el comportamiento de la cuenta pueden aportar señales de riesgo. Unos límites diarios prudentes ayudan, pero no corrigen una arquitectura arriesgada.
7. La prospección manual no está exenta de restricciones. Un volumen elevado, la apertura masiva de perfiles y demasiados avisos de «I don’t know this person» también pueden afectar a los usuarios que trabajan manualmente.
8. Las herramientas en la nube pueden dejar un rastro de IP visible. En nuestra prueba de 7 herramientas en la nube, cinco de las seis herramientas que operaban en el servidor situaron las cuentas detrás de direcciones IP pertenecientes a centros de datos o servicios proxy calificados como de alto riesgo por una base de datos independiente sobre fraude. Un proveedor asignó la misma IP a ambas cuentas de prueba y tres herramientas no relacionadas dirigieron el tráfico a través del mismo proveedor de infraestructura subyacente.
9. La seguridad de la cuenta no es una preocupación minoritaria. En nueve mercados anglófonos, aproximadamente 12 050 búsquedas mensuales están relacionadas con restricciones de LinkedIn, limitaciones de cuentas, verificación de identidad o bloqueos.

Por qué puede confiar en este informe

Esta guía se basa en tres fuentes de información y pruebas: el historial del producto, el código de las extensiones y pruebas reales de servicios en la nube.

La primera fuente es Alexander Erin, fundador de Linked Helper, quien ocupa ese cargo desde octubre de 2016.

Él escribió la primera versión de Linked Helper, que era una extensión de Chrome. En su momento de mayor popularidad, ocupó el primer puesto para la consulta de búsqueda «LinkedIn» en Chrome Web Store y contaba con unos 80 000 usuarios. También vio cómo los primeros sistemas de detección de LinkedIn afectaban a extensiones de la competencia. En agosto de 2019, dispuso de tres días para adaptar Linked Helper frente a una segunda oleada de detección.

Después de aquello, el equipo decidió abandonar Chrome Web Store y reconstruir Linked Helper como una aplicación de escritorio independiente.

La segunda fuente es el código.

Para este informe, descargamos las extensiones publicadas de 16 herramientas de la competencia, desminificamos el código y rastreamos lo que hacen con su sesión de LinkedIn. Revisamos el código archivo por archivo y conservamos las referencias de líneas cuando el comportamiento podía verificarse.

También utilizamos la investigación de BrowserGate, que analizó el JavaScript de producción de LinkedIn entre diciembre de 2025 y marzo de 2026. Ese trabajo documentó sistemas de detección que nuestro experto ya describía desde 2019 desde la perspectiva de quienes diseñan o estudian los sistemas de defensa.

La tercera fuente es una prueba práctica.

El código puede mostrar lo que una extensión es capaz de hacer, pero no qué dirección IP asigna un servicio en la nube después de que la sesión llegue a sus servidores. Para comprobarlo, nos registramos en 7 herramientas en la nube con dos cuentas por herramienta desde el mismo país, Francia.

Para cada cuenta, registramos la IP de salida, la reputación de la IP en IPQualityScore (IPQS), el tipo de dispositivo, el sistema operativo (SO) mostrado por la nube y si la extensión complementaria figuraba en la lista de detección de LinkedIn. IPQS es una base de datos independiente de inteligencia contra el fraude e incluye a LinkedIn entre sus clientes en su sitio web.

Al terminar esta guía, dispondrá de tres resultados prácticos:

1. Un mapa de riesgos de las principales arquitecturas de automatización
2. Una lista de comprobación a nivel de código para auditar cualquier extensión
3. Benchmarks operativos más seguros para los casos en los que todavía sean aplicables

Por qué la seguridad de la cuenta es el problema principal

Las restricciones de cuentas de LinkedIn siguen siendo una preocupación importante para los equipos de ventas y crecimiento, los profesionales de selección de personal, los fundadores y las agencias. Cada mes, las personas buscan respuestas sobre restricciones, comprobaciones de identidad, límites de solicitudes de conexión y medidas repentinas contra sus cuentas.

La mayoría de los consejos se limita a los topes de actividad diaria y al volumen de mensajes. Son importantes, pero solo representan una parte del riesgo. LinkedIn también puede observar señales técnicas, como extensiones del navegador, huellas digitales de dispositivos, entornos donde se ejecutan las sesiones en la nube y reputación de IP.

Este informe se centra en esa capa técnica. En lugar de especular sobre lo que LinkedIn podría detectar, examinamos cómo están construidas las herramientas de automatización, qué señales exponen y cómo puede afectar cada arquitectura al riesgo de la cuenta.

1. Las arquitecturas que determinan el riesgo de la automatización en LinkedIn

Etiquetas comerciales como «nube», «AI», «extensión de Chrome» y «seguro» no explican por sí solas el riesgo para la cuenta.

Las verdaderas preguntas son:

1. ¿Cómo accede la herramienta a su cuenta?
2. ¿Dónde se ejecuta el trabajo?
3. ¿Adónde van sus datos?
4. ¿Qué rastros deja la configuración?

La mayoría de las herramientas de automatización de LinkedIn pueden encuadrarse en los componentes que aparecen a continuación. Algunas utilizan un solo modelo, mientras que otras combinan varios dentro del mismo producto.

Flujo de datos de la extensión de Chrome Dux-Soup. Los nodos rojos muestran que su sesión o sus datos de LinkedIn salen hacia la nube de un proveedor. Los nodos grises muestran los datos que permanecen en su navegador.

1.1 Extensiones que se ejecutan dentro de su navegador

Una extensión del navegador puede combinar varios patrones de automatización. La diferencia entre ellos es importante, porque algunos mantienen la sesión localmente y otros trasladan sus datos de sesión a la nube de un proveedor.

a) Extracción local mediante su propia sesión

En este modelo, su sesión de LinkedIn permanece en su equipo. La extensión llama directamente desde su navegador a la API interna de LinkedIn, conocida como Voyager, utilizando su inicio de sesión de LinkedIn existente.

Desde el punto de vista técnico, puede ser algo como fetch(..., {credentials: "same-origin"}) con un encabezado CSRF token derivado de su cookie JSESSIONID. Los tokens de protección contra la falsificación de solicitudes entre sitios (CSRF) ayudan a demostrar que una solicitud pertenece a la sesión actual iniciada en el navegador.

Solo se suben al proveedor los datos recopilados, como perfiles o correos electrónicos. El propio token de sesión no se exporta.

Entre los ejemplos verificados en nuestra auditoría se encuentran Octopus CRM, GetProspect, Findymail, Apollo y Dux-Soup en sus planes Turbo, Pro y Free. Octopus CRM tenía la implementación más limpia de este grupo, porque no solicitaba el permiso cookies de Chrome y utilizaba llamadas locales a Voyager como fetch(voyager, {credentials:"same-origin", "CSRF-token": U()}).

La ventaja es que su IP, la sesión del navegador y la huella digital del dispositivo permanecen coherentes. Su token de sesión no sale del navegador.

• Una solicitud aislada a Voyager sin el tráfico circundante de la página puede crear un patrón de solicitudes poco natural, que tratamos en §2.7.
• La extensión también puede seguir siendo visible para los escáneres de extensiones de LinkedIn, que tratamos en §2.1 y §2.2.

También existe un riesgo de mantenimiento.

Muchas extensiones dependen de supuestos fijados directamente en el código sobre la estructura de la API interna de LinkedIn, los formatos de las solicitudes, los encabezados y los parámetros. Si LinkedIn cambia esos requisitos, una extensión desactualizada puede empezar a enviar solicitudes mal formadas o inusuales hasta que el proveedor detecte el cambio, publique una corrección y los usuarios instalen la actualización.

b) Extensiones puente de cookies o de envío de datos de sesión

En este modelo, su sesión de LinkedIn sale de su equipo. La extensión lee el almacén de cookies de LinkedIn mediante llamadas como chrome.cookies.getAll(...), selecciona valores como li_at, JSESSIONID o li_a y los envía al servidor del proveedor.

A partir de ese momento, la nube del proveedor puede actuar desde su cuenta mediante su propia dirección IP. Como explicó nuestro experto sobre una herramienta de este tipo: «La extensión funciona como un puente para extraer la cookie y no tiene ningún otro propósito».

La tabla siguiente muestra lo que encontramos en el código. También distingue entre las herramientas que exportan datos de sesión y aquellas que mantienen la sesión de LinkedIn localmente y solo envían resultados.

Expandi: el caso más interesante del conjunto de datos

Expandi (mediante la extensión del conector de Expandi) merece un examen más detallado porque muestra varias técnicas utilizadas en el mercado de la automatización de LinkedIn. Esas técnicas pueden reducir algunos riesgos, pero también pueden dejar señales que los sistemas de detección pueden observar.

Comprender cómo funcionan estas técnicas y dónde siguen dejando señales proporciona un marco útil para evaluar cualquier otra herramienta de automatización.

Flujo de datos de la extensión de Chrome Expandi Connector, reconstruido mediante una auditoría del código. Los nodos rojos muestran que su sesión o sus datos de LinkedIn salen hacia la nube de un proveedor. Los nodos grises muestran los datos que permanecen en su navegador.

Técnica 1: inyectar un script en el contexto de la página de LinkedIn

Normalmente, un script de contenido se ejecuta en un entorno aislado y no puede modificar el XMLHttpRequest de la página.

Para eludir esa limitación, Expandi inyecta un nodo <script src="chrome-extension://ohcplcf…/linkedin/injected.js"> real en el DOM activo (linkedin/content.js:2-7).

Ese nodo contiene una URL chrome-extension:// literal dentro de la página. El sistema Spectroscopy de LinkedIn (§2.2) puede recorrer pasivamente el DOM, buscar esa subcadena, extraer el identificador de 32 caracteres de la extensión y comunicarlo.

Esta vía de detección no requiere una lista de objetivos. Una afirmación como «No estamos en la lista de AED» no resuelve la cuestión si la extensión inyecta un recurso chrome-extension:// visible. En ese caso, el método de entrega se convierte en la huella.

Grado de certeza: comprobado en el código. La inyección es explícita y el mecanismo Spectroscopy está documentado en el análisis del código de producción de BrowserGate.

Técnica 2: sobrescribir dinámicamente XMLHttpRequest.prototype.send

El archivo injected.js:3-27 de Expandi sobrescribe el método nativo send de la página, de forma que todas las respuestas de la API Voyager que obtiene el navegador puedan copiarse a la extensión. La modificación se ejecuta en el mismo contexto global que el JavaScript de LinkedIn, que es precisamente el objetivo de inyectar el script en la página.

Un método send modificado deja de ser nativo y cualquier script de la página puede comprobarlo. Por ejemplo, Function.prototype.toString.call(XMLHttpRequest.prototype.send) devuelve el código fuente del contenedor en lugar de "function send() { [native code] }", y Expandi no intenta enmascarar toString.

Una referencia limpia obtenida de un <iframe> nuevo del mismo origen tampoco coincidiría con el método send modificado de la página. Esto crea una diferencia detectable entre la API original del navegador y el estado actual de la página.

LinkedIn ya implementa comprobaciones de esta clase. El grupo del motor interno de huellas digitales APFC/DNA tratado en §2.6 incluye comprobaciones antibot directas y una función signals para detectar afirmaciones incoherentes del navegador. LinkedIn también carga el script externo HUMAN/PerimeterX desde li.protechts.net (§2.8a), diseñado para detectar manipulaciones como prototipos modificados y cambios en el comportamiento de toString.

Grado de certeza: la modificación está comprobada en el código. La vía de detección se desprende del funcionamiento de esa modificación.

No encontramos ningún bloqueo de telemetría en esta ruta, por lo que cualquier veredicto de esas comprobaciones puede seguir enviándose. No afirmamos haber observado cómo LinkedIn marcaba a un usuario concreto de Expandi. La afirmación más precisa es que la capacidad de detección existe y la modificación es suficientemente visible como para que esos sistemas puedan detectarla.

Técnica 3: enviar una llamada independiente a Voyager GraphQL para obtener el correo electrónico

El archivo injected.js:34-44 de Expandi realiza una solicitud programática GET /voyager/api/graphql con withCredentials:true. Crea un CSRF-token a partir de su JSESSIONID (injected.js:30-31) para obtener información de contacto o datos de correo electrónico que una visualización normal del perfil no descarga de forma predeterminada.

LinkedIn puede identificarlo como una anomalía del mapa de solicitudes (§2.7). Se trata de una llamada a la API sin una acción correspondiente del usuario, que se activa después de cargar perfiles en los que el usuario no abrió «Contact info».

A gran escala, el patrón «Cada perfil visualizado también obtiene su correo electrónico» se vuelve reconocible como característico de una herramienta que extrae datos para enriquecer perfiles. Resulta visible en los registros del servidor sin ninguna ayuda del navegador. La llamada utiliza su sesión real e incluye el encabezado cifrado de la huella digital, pero el patrón de comportamiento es lo que la delata.

Grado de certeza: comprobado en el código. La llamada es explícita y la anomalía es observable desde el servidor por diseño.

El hallazgo más grave: algunas extensiones recopilan más que datos de LinkedIn

La variante más grave es la recopilación del almacén completo de cookies de todos los sitios en los que ha iniciado sesión, no solo LinkedIn. La extensión expandi.ai de Konnector, un proveedor distinto de Expandi.io, devuelve chrome.cookies.getAll({}) a su aplicación web para todos los dominios.

Incluso el intercambio aparentemente rutinario isInstalled puede exponer el almacén completo de cookies (KonnectorContent.js:10-28, background.js:19). Esto amplía el riesgo más allá de la automatización de LinkedIn y afecta a la seguridad general de las cuentas.

Ejemplo de PhantomBuster

PhantomBuster pertenece a otra categoría. Rellena automáticamente su cookie li_at en su página de configuración en la nube con un solo clic (contentscript.js:5265-5266). No se trata de un POST silencioso, pero permite transferir la sesión con solo pulsar un botón.

PhantomBuster también puede recopilar cookies de sesión de 15 plataformas (background.js:5140-5230). Por eso §1.2a considera que la reutilización de cookies es la peor categoría.

c) Automatización del DOM dentro de la página de LinkedIn

Algunas extensiones automatizan LinkedIn haciendo clic en botones por usted e inyectando sus propios paneles, botones o controles en la página de LinkedIn.

Esto crea dos superficies de detección. Cada elemento inyectado puede tener un selector único que un escáner puede buscar (§2.2), y cada clic programático lleva isTrusted:false. Con la API normal de las extensiones, como explicó nuestro experto, «No se puede falsificar: siempre es false» (§2.5).

En la práctica, pocas herramientas realizan inyecciones intensivas en la página. Sin embargo, las que sí lo hacen generan señales que LinkedIn puede examinar sin necesidad de una lista de objetivos, porque el escáner puede observar directamente qué ha cambiado dentro de la página (§2.2).

1.2 Servicios en la nube que se ejecutan en los servidores del proveedor

Un servicio en la nube necesita una vía de acceso a su cuenta de LinkedIn antes de poder automatizar cualquier tarea. En la práctica, existen dos puntos de entrada principales.

a) Reutilización de cookies mediante una sesión sincronizada

Esta es la parte del modelo puente de cookies de §1.1b que se ejecuta en el servidor. Es una de las configuraciones de mayor riesgo porque su sesión puede reutilizarse fuera de su propio navegador.

El riesgo proviene de varias señales simultáneas:

• Una sesión puede aparecer en dos IP en paralelo. La suya mientras continúa navegando por LinkedIn y la IP del centro de datos del proveedor mientras la nube ejecuta la automatización. Nuestro experto lo denominó «un indicio inequívoco».
• Reutilizar una cookie no equivale a un inicio de sesión normal. No crea una entrada visible en la página «active sessions» de LinkedIn, por lo que no puede verlo desde la configuración de su cuenta.
• El plan Cloud de Dux-Soup toma las cookies sin advertir al usuario cuando se conecta.
• Si la nube reutiliza la cookie dentro de su propio navegador, es posible que la huella digital del dispositivo no coincida con la utilizada siempre por su sesión (§2.6).
• Si la nube omite el navegador y llama directamente a la API, puede crear un mapa de solicitudes poco natural (§2.7).

Una vez trasladada la sesión a la nube del proveedor, usted deja de poder observar el entorno desde el que se utiliza su cuenta de LinkedIn.

b) Nuevo inicio de sesión en el entorno del proveedor

La segunda vía es un nuevo inicio de sesión desde el entorno del proveedor. El servicio inicia un servidor privado virtual (VPS) o un emulador de navegador e inicia sesión con su nombre de usuario, contraseña, código de correo electrónico y código de autenticación de dos factores (2FA).

Algunos proveedores describen este enfoque en privado. Una herramienta de publicaciones sociales nos indicó que inicia sesión mediante un VPS con un navegador similar a Multilogin y que después realiza todas las demás tareas mediante la API. Otra conocida suite de prospección describió «un navegador real para las acciones poco frecuentes y la API para el resto».

(No vamos a identificarlas, pero… a su favor, PhantomBuster documenta públicamente su arquitectura de navegador en la nube).

Nuestro experto considera que esta vía es menos arriesgada que reutilizar cookies. Un nuevo inicio de sesión desde una máquina y una ubicación nuevas puede, al menos, parecer algo que haría una persona real. Aun así, vincula a su cuenta la IP, la ubicación geográfica, la zona horaria y la huella digital de la nube, cuestiones que tratamos en §2.9 y §2.10.

Qué hace después la nube: solo API frente a navegador emulado

Tras iniciar sesión, la nube aún tiene que realizar el trabajo. Puede utilizar un navegador emulado, llamar directamente a las API de LinkedIn o combinar ambos métodos.

Nuestro experto califica la ejecución en el entorno de la nube como una estimación, no como un hecho probado directamente. Su valoración es clara: «Creo que todos saturan la API con llamadas directas. Todos ellos. Con un 95 % de probabilidad».

Ofrece tres razones para esta estimación:

1. Las llamadas a la API son mucho más sencillas que analizar páginas de LinkedIn que cambian constantemente.
2. LinkedIn todavía no ha reforzado la API lo suficiente como para detener a los servicios que han reconocido públicamente su uso.
3. Las funciones de bandeja de entrada en tiempo real de los paneles de estas herramientas suelen requerir acceso directo a la API. Recuperar bajo demanda una conversación reciente con una persona concreta no es algo que un navegador que extrae datos en segundo plano pueda hacer con la rapidez y regularidad necesarias.

El riesgo a nivel de sistema es que las nubes que solo utilizan la API dependen de solicitudes con parámetros fijados directamente en el código. LinkedIn solo tiene que cambiar la API mediante un encabezado especial, nombres de endpoints específicos para cada usuario o una modificación similar para que todos esos clientes dejen de funcionar o empiecen a parecer inusuales.

El análisis de BrowserGate reveló que una parte de esta infraestructura ya existe. Se inyecta un bloque cifrado con la huella digital en los encabezados HTTP de cada solicitud a la API realizada por una sesión real del navegador (§2.6 y §2.7). La infraestructura para distinguir el tráfico de navegadores reales de los clientes que solo utilizan la API parece estar desplegada. Que LinkedIn pase de recopilar esas señales a utilizarlas para imponer restricciones es decisión suya.

Esta salvedad es importante en todo el informe: desde fuera, no se puede demostrar qué método utiliza una nube; un cliente de API también puede imitar un inicio de sesión. Informamos de lo que vemos en el código y calificamos el comportamiento en el entorno de la nube como «muy probable».

Qué medimos al registrarnos (7 herramientas, 2 cuentas en cada una)

El análisis del código termina en el límite de la extensión. La propia nube es una caja negra para el usuario, aunque LinkedIn podría ver más.

Hay algo que la caja negra no puede ocultar por completo: la dirección IP de salida que asigna a su cuenta y la huella digital del dispositivo que muestra. Para comprobarlo, nos registramos en siete herramientas en la nube con dos cuentas por herramienta, todas desde el mismo país, Francia.

Después comprobamos cada IP asignada en IPQualityScore (IPQS). Probar dos cuentas por herramienta es importante porque permite ver si un proveedor reutiliza la infraestructura entre clientes.

¿Qué es IPQualityScore (IPQS)?

IPQS es un servicio independiente de prevención del fraude con más de 10 años en el mercado. Evalúa las direcciones IP mediante señales procedentes de su propia red de honeypots, trampas, rastreadores y fuentes de datos sobre abusos.

Para cada IP, IPQS devuelve varios campos útiles:

• fraud_score, de 0 a 100.
• Indicadores de proxy, red privada virtual (VPN) y Tor.
• Tipo de conexión, como centro de datos, residencial o móvil.
• Datos de geolocalización.
• Historial reciente de abusos.

No existe un umbral oficial que convierta la puntuación de una IP en un veredicto de seguridad. Aun así, los propios ejemplos de IPQS consideran de alto riesgo las puntuaciones superiores a 75 y la empresa afirma alcanzar aproximadamente un 99,95 % de precisión en la detección de proxies y VPN.

Utilizamos IPQS como punto de referencia independiente de lo que podría detectar un sistema antifraude moderno. Una IP muy utilizada para abusos, un endpoint de proxy conocido o una dirección de centro de datos compartida por muchas cuentas no relacionadas pueden convertirse en señales que los sistemas de riesgo suelen evaluar.

Las IP de centros de datos no son maliciosas por definición. A menudo inspiran menos confianza que las conexiones residenciales o móviles porque proceden de proveedores de alojamiento, no de redes de consumidores. En el contexto de LinkedIn, pueden resultar más reveladoras cuando muchas cuentas aparecen desde la misma infraestructura en la nube.

IPQS también fue útil porque sus datos de geolocalización coincidían a menudo con lo que LinkedIn mostraba en las sesiones de seguridad de las cuentas durante nuestras pruebas. Algunos proveedores de proxies anunciaban ubicaciones que no coincidían con el país identificado por IPQS o LinkedIn, lo que crea otro factor de riesgo: una discrepancia geográfica entre la ubicación de conexión declarada y la observada.

IPQS no es el motor privado de riesgos de LinkedIn. Su puntuación no constituye un veredicto sobre la seguridad de una cuenta ni una resolución jurídica. Es un benchmark independiente para comparar la calidad y la reputación de las IP que las herramientas de automatización asignan a las cuentas de los usuarios.

Resultados de la prueba de registro en la nube

Qué muestra la tabla

1. Skylead es el caso que mejor ilustra el riesgo.

Ambas cuentas de prueba salieron a través de la misma IP exacta de un centro de datos, 58.97.254.1, con una puntuación de fraude de IPQS de 100. Dos perfiles en una misma IP de centro de datos coinciden con el tipo de patrón de agrupación de cuentas que puede evaluar la lógica de acceso paralelo de LinkedIn (§2.9).

2. La infraestructura señalada como de riesgo era compartida, y no solo dentro de una marca.

Dripify, Skylead y We Connect dirigen su tráfico a través del mismo proveedor de infraestructura subyacente, HostRoyale Technologies (ASN 203020). Si un bloque del proveedor pierde reputación ante los sistemas de LinkedIn, varias herramientas pueden verse afectadas al mismo tiempo.

3. HeyReach añadió un problema adicional de control.

Sus IP tenían puntuaciones de fraude de 100 y su extensión bloqueaba el cierre de sesión de dos maneras: mediante una interceptación de webNavigation (background.js:1-17) y una regla de declarativeNetRequest (rules.json:1-14). Esto puede impedir que el usuario invalide la sesión después de entregar toda la lista de cookies mediante api.heyreach.io/.../CreateLinkedInAccountFromCookies.

4. Meet Alfred fue el claro contraste en esta prueba.

Fue la única herramienta que asignó a ambas cuentas IP limpias con puntuaciones de fraude de 0 y falsificó un agente de usuario móvil. Sin embargo, una IP limpia solo resuelve una señal. La herramienta sigue almacenando las credenciales en su nube y actuando como el usuario desde una máquina distinta.

5. Ninguna herramienta comprueba la IP que asigna.

Ninguna de las 7 herramientas incluía un comprobador de calidad del proxy. Una herramienta puede asignar una dirección señalada como de riesgo, o un usuario puede añadir un proxy deficiente, sin recibir una advertencia clara. El «control de ubicación» también suele significar control a nivel de país, no de estado o ciudad (§2.9).

No podemos ver qué hacen internamente estos servidores y calificamos el modo de ejecución como «muy probable». Sin embargo, la IP, la infraestructura compartida, la huella digital y la presencia en la lista de detección no son inferencias: los medimos (consulte el recuadro sobre IPQS anterior).

1.3 Herramientas basadas en navegador que controlan un navegador completo

La automatización basada en navegador utiliza un entorno de navegador completo en lugar de limitarse a una extensión ligera o a un cliente de API básico. Esta categoría se divide en dos modelos muy diferentes.

Herramientas basadas en un navegador en la nube

Una herramienta basada en un navegador en la nube ejecuta un navegador como Chrome sin interfaz o Puppeteer en el servidor del proveedor. PhantomBuster es el único proveedor de este grupo que reconoce públicamente esta arquitectura.

Este modelo sigue teniendo puntos débiles.

Puppeteer se puede detectar y existe todo un sector antibot dedicado a identificar la automatización del navegador.

El alojamiento de varias cuentas también crea un riesgo de correlación cuando muchos «usuarios» comparten la unidad de procesamiento gráfico (GPU), la pila de audio y otros rasgos de la huella digital de un mismo servidor.

Herramientas de escritorio independientes

Una herramienta de escritorio independiente ejecuta un navegador separado basado en Chromium en el equipo del usuario. Linked Helper utiliza este modelo.

Esto crea una superficie de detección menor que una extensión de Chrome o una granja de cuentas en la nube. No hay un identificador de Chrome Web Store que pueda sondear el escáner de detección activa de extensiones de LinkedIn (§2.1), no se inyecta código de una extensión en la página de LinkedIn (§2.2 y §2.3) y la cuenta conserva la IP local y la huella digital del equipo del usuario.

También existe una ventaja estructural. LinkedIn puede analizar con calma cualquier extensión pública de Chrome Web Store y crear un detector antes de desplegar nada. Frente a una aplicación de escritorio independiente, las pruebas de detección deben desplegarse en producción, donde pueden observarse.

Que una herramienta esté basada en un navegador no significa automáticamente que sea segura. Solo reduce parte de la exposición técnica. Las decisiones del desarrollador sobre la huella digital, la navegación, los tiempos y la simulación de clics siguen afectando al riesgo.

Ejemplo práctico: Dux-Soup utiliza varios patrones en un mismo paquete

La mayoría de las herramientas encajan en una fila del mapa de arquitecturas. Dux-Soup es diferente porque config.getEdition() ofrece una arquitectura distinta según el plan.

Esto convierte a Dux-Soup en un ejemplo útil para esta guía. Un solo producto muestra extracción local, envío de datos de sesión, exposición a AED, bloqueo de telemetría y límites de gran volumen en distintas partes de su configuración.

Flujo de datos de la extensión de Chrome Dux-Soup. Los nodos rojos muestran que su sesión o sus datos de LinkedIn salen hacia la nube de un proveedor. Los nodos grises muestran los datos que permanecen en su navegador.

• Free, Pro y Turbo utilizan extracción local (§1.1a). Se llama a Voyager en el navegador del usuario con un CSRF-token derivado de JSESSIONID, por lo que la sesión permanece en el equipo del usuario. Nivel de riesgo: medio.
• Cloud utiliza el envío de datos de sesión (§1.1b y §1.2a). El service worker ejecuta chrome.cookies.getAll({domain:"linkedin"}) y después envía todo el almacén de cookies, localStorage y datos de navigator a app.dux-soup.com mediante PUT /api/{user}/sessions/{domain}. A continuación, controla la cuenta a través de un canal Socket.IO (sw.js:1, libs/socket-io/socket.io.js:1562). Fue el conjunto de datos de sesión más amplio que encontramos en todas las herramientas.
• Está confirmado que la extensión figura en la lista AED de LinkedIn (§2.1). El identificador de la extensión ppdakpfeaodfophjplfdedpcodkdkbal y el archivo de sondeo fetchforwarder.js aparecen en detection_db.json. En cada visita, LinkedIn puede solicitar chrome-extension://…/fetchforwarder.js, y una respuesta correcta puede indicar que la extensión está instalada antes de que el usuario haga clic en nada.
• La configuración antidetección puede acabar delatando la herramienta (§2.8). Las reglas de declarativeNetRequest bloquean li/track, sensorcollect, protechts y merchantpool (rules.json; interruptor de la interfaz killtracking). Esas reglas están en un JSON estático que cualquiera puede leer, y el silencio resultante de la telemetría puede convertirse en una anomalía.
• Los límites combinan ajustes prudentes y agresivos (§6). El valor predeterminado de maxinvites es un razonable 20 al día. La misma interfaz aumenta maxvisits a 500 al día y ofrece un análisis «Turbo» de aproximadamente 10 páginas por minuto, muy por encima del comportamiento normal de navegación de una persona.

2. La superficie de detección: qué puede ver, recopilar y comparar LinkedIn

Este es el núcleo técnico de la guía. Durante años, gran parte de la lógica de detección de LinkedIn solo podía describirse a partir de la experiencia de quienes diseñaban o estudiaban sistemas de defensa. La investigación de BrowserGate cambió esta situación al descomponer el JavaScript de producción de LinkedIn, incluido un módulo de unos 2,7 MB.

Ese análisis encontró tres sistemas que trabajan conjuntamente dentro de las páginas de LinkedIn:

1. La detección activa de extensiones (AED) sondea activamente su navegador en busca de extensiones instaladas (§2.1).
2. Spectroscopy analiza pasivamente el DOM en busca de rastros dejados por las extensiones (§2.2).
3. APFC/DNA recopila una huella digital del dispositivo con 48 características (§2.6).

Estas señales alimentan el flujo de telemetría de LinkedIn, incluido el endpoint li/track (§2.4). El análisis de extensiones se ejecuta en navegadores basados en Chromium, como Chrome, Edge, Brave, Opera y Arc. BrowserGate encontró una comprobación literal userAgent.indexOf("Chrome") en el código.

La lista de objetivos también sigue creciendo. Pasó de 38 extensiones en 2017 a unas 461 en 2024 y después a 4 934 en junio de 2026. Esto representa un crecimiento de aproximadamente 12 entradas nuevas al día y demuestra que la lista se mantiene, no está abandonada.

4 934 se refiere a identificadores únicos de extensiones de Chrome, mientras que 6 167 corresponde a la lista más amplia de objetivos de sondeo formados por identificador y archivo.

A continuación se presenta cada vector de detección: mecanismo → qué llega a los servidores de LinkedIn → a quién detecta → cómo puede comprobarlo usted mismo.

2.1 El escáner de extensiones (AED): estar instalada puede significar ser visible

El código de las páginas de LinkedIn incluye una lista de pares {extension id, file} definida directamente en el código. Puede incluir archivos como logotipos, popup.html, manifest.json o cualquier recurso que la extensión exponga mediante web_accessible_resources.

La página ejecuta silenciosamente llamadas fetch() contra rutas como chrome-extension://<id>/<file>. Si la solicitud se completa correctamente, LinkedIn puede saber que la extensión está instalada.

Los detalles de producción son importantes porque el análisis está diseñado para pasar desapercibido:

• Puede lanzar en paralelo unas 6200 solicitudes mediante Promise.allSettled.
• También puede analizar una por una con un retraso configurable staggerDetectionMs, lo que hace que resulte menos evidente en la pestaña «Network».
• Puede esperar a que el navegador esté inactivo mediante requestIdleCallback, para que usted no perciba lentitud.
• Los errores se descartan mediante bloques catch vacíos, por lo que la consola permanece limpia.
• Los resultados se envían como un AedEvent {browserExtensionIds: [...]}.

Si la extensión figura en la lista de LinkedIn, el hecho de que esté instalada puede registrarse en cada visita antes de que el usuario haga clic en nada.

Puede comprobarlo en unos tres minutos.

Abra linkedin.com, vaya a «DevTools», abra «Sources» y busque el identificador de su extensión en todos los archivos cargados. Puede encontrar el identificador en chrome://extensions.

Después, abra «Network», filtre por li/track y vuelva a cargar LinkedIn. Podrá observar cómo salen de la página los POST de telemetría agrupados. Para una comprobación más profunda, busque AedEvent o chrome-extension:// en los paquetes JavaScript de LinkedIn.

2.2 El sistema Spectroscopy del DOM: el escáner que no necesita una lista

Un segundo sistema analiza la propia página activa. Recorre recursivamente todo el DOM, incluidos los nodos de texto y los valores de los atributos, en busca de la subcadena chrome-extension://.

Cuando encuentra esa cadena, extrae el identificador de 32 caracteres de la extensión y comunica un SpectroscopyEvent.

Esto difiere de AED porque no necesita una lista de objetivos. Una extensión nueva puede seguir siendo detectada si inyecta un elemento, estilo, iframe o script que remita a sus propios recursos chrome-extension://.

En conjunto, AED y Spectroscopy abarcan dos estados habituales de las extensiones.

• AED puede detectar una extensión instalada pero inactiva.
• Spectroscopy puede detectar una extensión que modifica activamente la página de LinkedIn.

Este es el escáner aplicable al modelo de automatización del DOM de §1.1c.

2.3 Instantáneas de la página desde un Web Worker

En momentos aleatorios, un proceso en segundo plano puede recopilar una instantánea estructural de la página. La instantánea incluye etiquetas sin su contenido de texto, además de elementos script/style con contenido.

La instantánea se cifra y se envía para buscar rastros en el servidor. No puede ver qué busca LinkedIn porque esa búsqueda no se realiza en su navegador.

Conocemos este mecanismo por experiencia directa. Es el algoritmo que detectó la primera versión de la extensión de Chrome de Linked Helper en agosto de 2019. La solución a corto plazo consistió en hacer que la copia de la extensión de cada usuario fuera estructuralmente única, lo que permitió ganar tiempo. Esa experiencia es una de las razones por las que Linked Helper abandonó Chrome Web Store y se reconstruyó como aplicación de escritorio independiente.

Lo relatamos como un hecho histórico. LinkedIn ya disponía de este tipo de detección basada en la estructura de la página desde 2019, mucho antes de los hallazgos actuales de BrowserGate.

2.4 El flujo de telemetría: li/track

Los sistemas anteriores convergen en https://www.linkedin.com/li/track. El nombre del método en el código es fireTrackingPayload.

Este endpoint recibe eventos de comportamiento, como movimientos del ratón, clics y escritura, junto con los veredictos de los escáneres, como AedEvent y SpectroscopyEvent.

El transporte está diseñado para ser fiable:

• Los eventos se agrupan hasta un máximo de 29 por solicitud.
• Las solicitudes fallidas se reintentan hasta 4 veces.
• Las cargas se comprimen mediante compresión Lempel-Ziv (LZ) a través de compressToBase64.

Otros endpoints relacionados gestionan los datos de huellas digitales, entre ellos /platform-telemetry/li/apfcDf y /apfc/collect.

Recuerde estos nombres porque vuelven a aparecer en §2.8. Las extensiones que intentan bloquear la telemetría de LinkedIn deben bloquear todo el conjunto. Omitir un endpoint puede revelar el propio bloqueo.

2.5 isTrusted: el indicador de clic que un script de contenido normalmente no puede cambiar

Todos los eventos del DOM incluyen un indicador de solo lectura isTrusted. Un clic humano real devuelve true.

Un evento creado por el script de contenido de una extensión devuelve false. Esto incluye dispatchEvent, new MouseEvent y las llamadas programáticas a .click(). Mediante la API normal de las extensiones, nuestro experto lo explica claramente: «No se puede falsificar. Siempre es false».

Una salvedad precisa para que la afirmación resista el escrutinio: los eventos generados mediante la API chrome.debugger pueden devolver isTrusted:true. Sin embargo, Chrome muestra entonces un aviso amarillo permanente que indica que una extensión está depurando el navegador. La vía alternativa existe, pero no pasa desapercibida.

Hasta donde llega el conocimiento directo más reciente de nuestro experto, LinkedIn todavía no aplicaba medidas de forma masiva basándose en este indicador. Su comentario fue: «Es cuestión de tiempo». A LinkedIn le cuesta una sola instrucción if.

2.6 La huella digital de 48 puntos (APFC): el pasaporte técnico de su equipo

¿Qué es una huella digital del navegador?

Una huella digital del navegador es una instantánea técnica de su equipo. Puede incluir qué GPU renderiza una imagen de prueba, cómo procesa una señal la pila de audio, qué fuentes tiene instaladas, la pantalla, los núcleos de la CPU, la memoria de acceso aleatorio (RAM), la zona horaria y otros rasgos.

Cada señal puede parecer inofensiva por sí sola. En conjunto, pueden ser prácticamente únicas. También son difíciles de falsificar correctamente, porque una imitación convincente exige reproducir las peculiaridades de otra máquina, no solo cambiar una cadena del navegador.

El motor de huellas digitales de producción de LinkedIn, denominado internamente APFC/DNA, recopila 48 características. Los grupos principales son:

• Hardware y sistema operativo (SO): núcleos de la CPU, RAM, 6 métricas de pantalla, función táctil, batería y plataforma.
• Gráficos, audio y fuentes: hash del canvas, proveedor y renderizador de WebGL, otros 65 parámetros de WebGL, respuesta del oscilador y del compresor de AudioContext y fuentes instaladas.
• Red: IP local mediante WebRTC, tipo de conexión, velocidad de descarga y tiempo de ida y vuelta (RTT).
• Entorno: zona horaria medida de dos maneras, idioma, complementos, tipos MIME, cámaras, micrófonos y altavoces mediante enumerateDevices, y peculiaridades del almacenamiento.
• Señales antibot directas: webdriver, detección de frameworks de automatización, modo incógnito y una función llamada signals que puede marcar combinaciones falsificadas de SO, navegador, resolución o idioma.

Conviene destacar un detalle. «Do Not Track» se recopila, pero se excluye del hash. En otras palabras, LinkedIn registra la preferencia, pero esta no detiene el flujo más amplio de creación de huellas digitales que aquí se describe.

La instantánea se cifra mediante cifrado de clave pública RSA a través de apfcDfPK, se almacena en globalThis.apfcDf y después se adjunta como encabezado HTTP a solicitudes posteriores de la API durante la sesión. BrowserGate hace referencia a SyncCollectionHandler y al indicador de función sync.apfc.headers para este comportamiento.

Esto significa que la huella digital no se envía una sola vez y se olvida. Puede acompañar a las acciones que realiza su sesión.

Esto crea dos problemas importantes para la automatización en la nube:

1. Un servicio en la nube que nunca haya recopilado su huella digital real no puede reproducirla. Como explicó nuestro experto: «Para falsificarla, primero tendría que recopilarla».
2. Recopilar algunos datos de la huella digital no es suficiente. Tendría que recopilarlos exactamente de la misma forma que LinkedIn («Si dibujan un triángulo distinto, el hash será distinto»). Y el detector de mentiras signals existe precisamente porque la falsificación rudimentaria ya es lo bastante habitual como para detectarla.

2.7 El mapa de solicitudes: una acción crea muchas solicitudes

Abra cualquier perfil de LinkedIn con «DevTools» en ejecución y verá que se activa un grupo de solicitudes. Una visita normal a una página puede incluir marcado, llamadas a Voyager, telemetría, precargas y otras solicitudes auxiliares.

Una herramienta que solo utiliza la API puede crear un patrón diferente. Se accede a los datos del perfil, pero no se produce la visita circundante a la página del perfil. Como lo describió nuestro experto: «Se accede al perfil, pero nunca se visita la página del perfil y las solicitudes asociadas nunca se envían».

Se trata de una anomalía del mapa de solicitudes. Puede detectarse únicamente mediante los registros del servidor.

LinkedIn también dispone de varias opciones activas: cambiar los nombres de los endpoints para cada usuario, utilizar encabezados especiales y servir solicitudes señuelo a cuentas de prueba nuevas. Como se indicó en §2.6, el encabezado especial de la huella digital ya existe en producción.

Una nube que solo utiliza la API tiene dos opciones difíciles. Puede intentar falsificar ese encabezado sin recopilar de forma legítima la huella digital subyacente o puede enviar solicitudes sin el mismo contexto respaldado por el navegador. Ambas opciones pueden dejar un patrón.

2.8 Bloqueo de telemetría: la configuración antidetección que puede acabar delatando la herramienta

Algunas extensiones intentan ocultarse bloqueando los endpoints de detección y telemetría de LinkedIn mediante la API webRequest. El punto débil es que la lista de bloqueo debe estar completa.

Si la extensión omite un endpoint, el que sobreviva puede informar de que se están bloqueando otras rutas de telemetría. Nuestro experto lo denominó «una señal que podría contribuir directamente al bloqueo de la cuenta».

Según el código de producción, la lista identificada que debería cubrir un bloqueador incluye:

• li/track
• /platform-telemetry/li/apfcDf
• /apfc/collect
• /sensorCollect
• el iframe li.protechts.net
• el script merchantpool1.linkedin.com

Cuanto más crece esta lista, más fácil resulta para LinkedIn añadir un endpoint nuevo antes de la próxima versión de la extensión.

Manifest V3 añade un detalle importante. Los controladores de bloqueo de webRequest han desaparecido para las extensiones públicas, pero el bloqueo declarativo mediante declarativeNetRequest sigue funcionando.

Para los auditores, esto facilita la inspección porque la lista de bloqueo se encuentra ahora en un archivo JSON estático dentro del paquete de la extensión.

2.8a El conjunto de sistemas antibot externos de LinkedIn

LinkedIn no depende únicamente de su propio JavaScript. También carga sistemas externos antibot y de puntuación.

El análisis de BrowserGate identificó tres componentes importantes:

• HUMAN Security, anteriormente PerimeterX: un iframe oculto de 0×0 procedente de li.protechts.net, situado en left: -9999px con aria-hidden y cargado con uc=scraping en la URL. Entre las cookies relacionadas se encuentran _px3 y _pxvid.
• Merchant Pool: un segundo script de creación de huellas digitales procedente de merchantpool1.linkedin.com, vinculado a la cookie de sesión del usuario.
• Google reCAPTCHA v3 Enterprise: puntuación invisible al cargar la página.

Estos sistemas se activan mediante indicadores de funciones internas como pemberly.tracking.*. Esto significa que LinkedIn puede probar la detección en segmentos de usuarios y ampliar la cobertura sin modificar el flujo del producto que ven los usuarios.

Esta es la confirmación a nivel de código de la antigua advertencia del experto: «Nada les impide implementarlo en cualquier momento».

2.9 IP, geolocalización y sesiones paralelas

Una cookie activa en dos IP al mismo tiempo (§1.2a) es una de las señales más claras a nivel de red.

La geolocalización de IP es suficientemente fiable para crear señales de riesgo. Tiene una precisión aproximada del 80 % a nivel estatal y acierta la ciudad en torno a dos tercios de las ocasiones. Por tanto, un usuario que aparece en dos estados al mismo tiempo puede crear una señal relativamente clara.

Los controles de proxy en la nube no suelen resolver el problema por completo. Muchas herramientas permiten elegir un país, no un estado o una ciudad. Trabajar en paralelo —por ejemplo, que el usuario navegue localmente mientras la nube actúa desde la misma cuenta en otra región— añade el mismo tipo de señal.

Nuestro informe de registro de §1.2 mostró el problema práctico. La IP asignada por la nube solía ser una dirección de centro de datos que una base de datos independiente sobre fraude ya había calificado como de alto riesgo. Las puntuaciones de fraude de IPQS fueron de 94 o más en cinco de las seis herramientas que operaban en el servidor.

La infraestructura también era compartida. Dripify, Skylead y We Connect dirigen su tráfico a través de HostRoyale Technologies, ASN 203020, y Skylead asignó a ambas cuentas de prueba la misma IP en el mismo /24.

Por tanto, «una IP dedicada en su país» puede parecer más segura de lo que realmente es. En nuestra prueba, medimos con frecuencia una IP de centro de datos señalada como de riesgo en una infraestructura compartida, y ninguna de las herramientas probadas comprobó la reputación de la IP antes de asignarla.

2.10 Zona horaria y configuración regional

La zona horaria y la configuración regional son señales menores, pero aportan contexto. Como explicó nuestro experto: «Una zona horaria incorrecta suma un punto más».

La huella digital recopila dos veces la zona horaria mediante dos métodos. Por tanto, una falsificación parcial puede quedar expuesta si los valores no coinciden. También recopila los idiomas del sistema.

Una sesión «basada en EE. UU.» que se ejecuta desde una máquina configurada en UTC+5 y con una configuración regional incoherente es el tipo de discrepancia que la función signals está diseñada para marcar.

2.11 La capa de comportamiento: los usuarios manuales también pueden activarla

Las secciones anteriores se centran en la detección de herramientas. Esta capa se centra en el comportamiento, por lo que los usuarios manuales de LinkedIn también pueden sufrir restricciones.

Los principales riesgos de comportamiento son fáciles de entender:

• Volumen: las observaciones históricas de la carga de soporte de nuestro experto mostraron que unas 500 solicitudes de conexión al día podían provocar una restricción en aproximadamente dos semanas. Enviar una solicitud de conexión cada 5 segundos podía cerrar la sesión. Hoy el límite es más bajo porque LinkedIn aplica un límite móvil de unas 100 solicitudes de conexión por semana para la mayoría de las cuentas, de hasta unas 200 para perfiles con cierta antigüedad y un Social Selling Index (SSI) elevado y de unas 250 con Sales Navigator.
• Cómo se abren los perfiles: pegar URL de perfiles en bloque puede parecer un patrón de extracción. Llegar mediante la búsqueda por nombre se asemeja más al flujo normal de un usuario. La apertura masiva de URL es un desencadenante documentado de restricciones, incluso cuando la realiza manualmente una persona.
• Reacciones de los destinatarios: la tasa de aceptación es importante, al igual que los avisos de «I don’t know this person». Incluso con una tasa de aceptación del 80 %, 400 solicitudes de conexión al día dejan a 80 personas diarias decidiendo si deben ignorar, rechazar o informar sobre la solicitud.
• Acceso paralelo desde distintos países: esto enlaza con §2.9. Utilizar la cuenta localmente mientras un servicio en la nube actúa desde otro país puede añadir señales de riesgo a nivel de red.

La arquitectura y el comportamiento son capas independientes. Una configuración de menor riesgo puede seguir generando riesgo si la cuenta se comporta de forma poco realista, y el trabajo manual también puede provocar restricciones cuando el volumen o los patrones parecen automatizados.

3. Es un modelo de puntuación: cómo aumentan las sanciones de LinkedIn

Ninguna de las señales de detección de §2 debe considerarse un simple interruptor binario. El marco propuesto por el experto coincide con lo que encontramos en el código, las pruebas en la nube y los patrones de comportamiento: «Todo funciona como un modelo de puntuación; cada elemento suma puntos y acerca la cuenta al bloqueo».

Esto significa que LinkedIn no necesita una única señal perfecta. Puede comparar muchas señales pequeñas procedentes de su navegador, el comportamiento de la extensión, la dirección IP, el historial de la sesión y los patrones de prospección.

Los usuarios cuyas cuentas han sido objeto de restricciones conocen bien la escala de sanciones:

1. Advertencia: LinkedIn puede mostrar un mensaje que indique «Puede que esté utilizando herramientas de automatización».
2. Restricción temporal: la cuenta puede quedar limitada hasta que complete la verificación de identidad, como una comprobación por SMS o la carga de un documento de identidad.
3. Bloqueo permanente: cuando LinkedIn muestra «LinkedIn Member» en lugar de un nombre, suele significar que la cuenta ya no existe.

El riesgo se acumula entre capas. Una extensión instalada puede añadir una señal (§2.1), los rastros de código pueden añadir más (§2.2–§2.8), las anomalías de red pueden aportar otro grupo (§2.9–§2.10) y el comportamiento de la cuenta puede aumentar aún más la puntuación (§2.11).

Una arquitectura de menor riesgo no protege frente a un comportamiento imprudente. Si envía demasiadas solicitudes de conexión, abre perfiles en bloque mediante URL o provoca demasiados avisos de «I don’t know this person», el comportamiento por sí solo puede crear un riesgo de restricción.

El caso contrario es aún más importante al elegir una herramienta. Un comportamiento prudente no corrige una arquitectura arriesgada. Enviar 15 solicitudes de conexión al día no elimina las señales técnicas creadas cuando su cookie de sesión se reutiliza desde un centro de datos de otro país.

4. Lista de comprobación para una auditoría del código en 5 minutos

No necesita ser investigador de seguridad para realizar una primera auditoría de una extensión de Chrome. Puede desempaquetar la extensión con un visor de paquetes de extensiones de Chrome (CRX), o instalarla e inspeccionar los archivos locales de la extensión.

En macOS, las extensiones instaladas de Chrome suelen guardarse en ~/Library/Application Support/Google/Chrome/Default/Extensions/. Cuando tenga los archivos, busque los patrones siguientes.

Esta es la misma lógica de auditoría en la que se basan las afirmaciones sobre el código de este informe. No juzgue un permiso de forma aislada. Rastree qué ocurre con el valor y adónde va.

Cuando redacte el veredicto de una auditoría, vincule la afirmación a las pruebas. Si el código muestra que una cookie se envía al dominio de un proveedor, dígalo directamente. Si el comportamiento del servidor no puede observarse desde fuera, califíquelo como «muy probable» y explique la vía de riesgo.

Una plantilla útil para redactar veredictos, tomada del experto, sería: «La extensión funciona como un puente para extraer cookies y no tiene ningún otro propósito» o, en el caso de las nubes: «Es muy probable que el servicio funcione mediante llamadas directas a la API; los riesgos son A, B y C».

Una acusación exige una prueba concreta en el código. Todo lo demás debe calificarse como «muy probable».

5. Tabla maestra de riesgos

Esta tabla expresa los hallazgos en un lenguaje sencillo. Muestra el problema, qué pone en riesgo y dónde lo encontramos o medimos.

En cuanto al comportamiento en el entorno del servidor, calificamos la afirmación como «muy probable» porque no se puede demostrar por completo desde fuera cómo se ejecuta internamente un servidor en la nube. Solo presentamos como hechos lo que encontramos en el código o medimos directamente durante el registro.

6. Cómo automatizar de forma más segura

Estos benchmarks solo tienen sentido cuando la arquitectura ya presenta un riesgo técnico bajo. Si su herramienta utiliza el envío de datos de sesión, infraestructura compartida en la nube o configuraciones de proxy sin control, los límites diarios por sí solos no eliminarán el riesgo técnico descrito anteriormente.

Realice estas comprobaciones antes de ejecutar cualquier automatización de LinkedIn:

• Envíe unas 15-20 solicitudes de conexión al día. Esto coincide con lo que permite el límite móvil de LinkedIn de unas 100 solicitudes de conexión por semana. El antiguo consejo de «50-70 al día» es anterior al límite semanal.
• Retire las solicitudes de conexión pendientes cada 3 semanas aproximadamente. Una gran acumulación de solicitudes de conexión ignoradas puede convertirse en una señal negativa por sí misma.
• Vigile su tasa de aceptación. Si disminuye, el problema suele estar en la segmentación o en la adecuación del mensaje, no solo en el límite diario.
• Prepare los perfiles antes de automatizarlos. Realice aproximadamente un mes de actividad manual normal y utilice una foto real y un empleador real antes de automatizar una cuenta nueva o inactiva.
• Abra los perfiles mediante la búsqueda por nombre, no pegando URL en bloque. Como se indicó en §2.11, la apertura masiva de URL también puede restringir a los usuarios manuales.
• Utilice una IP por cuenta con una ubicación geográfica coherente. Mantenga la misma ciudad o estado cuando sea posible, y ajuste la zona horaria y la configuración regional a la ubicación habitual de la cuenta (§2.9–§2.10).
• No ejecute sesiones paralelas. Evite utilizar la cuenta localmente mientras una herramienta actúa desde ella en la nube. Evite también utilizar al mismo tiempo dos dispositivos, dos regiones o actividad local y en la nube.

Un enfoque de menor riesgo combina una arquitectura más segura, un origen estable de la sesión, un ritmo realista y un comportamiento similar al de un miembro normal de LinkedIn que utiliza su cuenta.

7. Por qué Linked Helper utiliza una arquitectura de escritorio

Declaración de transparencia

Este informe lo publica Linked Helper, por lo que debemos explicar claramente nuestra propia posición. Nuestra arquitectura surge de las lecciones que aprendimos cuando la primera versión de Linked Helper todavía era una extensión de Chrome.

Esa experiencia nos mostró algo importante: todas las extensiones exponen superficies de detección que no existen necesariamente en el software de escritorio independiente. Decidimos no seguir adaptando continuamente una extensión para sortear esas señales.

A continuación explicamos cómo se corresponde esa decisión con los riesgos tratados en este informe.

Sin huella de extensión

Linked Helper no es una extensión del navegador. No existe ningún identificador de Chrome Web Store, ningún paquete de extensión instalado en Chrome ni ningún recurso de extensión que pueda sondear el escáner AED de LinkedIn (§2.1).

Tampoco se inyecta código en las páginas de LinkedIn. Las interfaces de las extensiones, los scripts de contenido, los botones y los paneles inyectados pueden ser visibles para Spectroscopy y el análisis de instantáneas de la página (§2.2–§2.3).

Linked Helper mantiene los controles de las campañas, las colas y los paneles dentro de la aplicación de escritorio. La página de LinkedIn no se modifica con paneles ni scripts de extensión de Linked Helper.

Sin transferencia de la sesión a la nube

Su sesión de LinkedIn permanece en su equipo. Linked Helper no sube li_at, li_a, almacenes de cookies, almacenamiento del navegador ni conjuntos de sesiones a la nube de un proveedor.

Esto elimina varios patrones de riesgo tratados anteriormente en el informe:

• Ningún navegador remoto actúa en su nombre
• Ninguna granja de cuentas en la nube ejecuta su sesión
• No se asigna a su cuenta ninguna infraestructura compartida de salida del proveedor
• No es necesaria la reutilización oculta de su sesión de LinkedIn en la nube

Linked Helper tampoco ejecuta la automatización de LinkedIn mediante una capa independiente de reutilización de la API. Muchos productos en la nube dependen de reproducir el tráfico de la API de LinkedIn, lo que puede crear un patrón de solicitudes diferente al de una sesión normal del navegador.

Linked Helper utiliza en su lugar su propio motor de navegador local. Las acciones se producen en un entorno de navegador de su equipo mediante su sesión autenticada de LinkedIn y su dirección IP, o el proxy que usted asigne.

Identidad independiente para cada cuenta

Linked Helper separa la identidad del navegador para cada cuenta. Ejecutar varias cuentas de LinkedIn mediante un solo perfil del navegador puede crear señales de correlación, por lo que cada instancia de Linked Helper utiliza cookies, almacenamiento y cachés independientes.

Cada instancia también puede generar sus propias características de huella digital del navegador. Esto reduce la probabilidad de que parezca que varias cuentas proceden exactamente de la misma configuración de dispositivo.

También existe protección contra el uso de la cuenta equivocada. Si intenta iniciar sesión con otra cuenta de LinkedIn en una instancia existente, Linked Helper cierra la sesión de la cuenta actual en lugar de mezclar las sesiones sin advertir al usuario.

El control de proxies también es importante para los equipos o usuarios que gestionan varias cuentas. Linked Helper le permite asignar un proxy a cada instancia, de modo que usted controla la dirección de red utilizada por cada cuenta.

Esto difiere de muchas herramientas en la nube, donde el proveedor elige la IP de salida por usted. Linked Helper también incluye un comprobador integrado de reputación de IP basado en datos de IPQualityScore (IPQS), para que pueda evaluar la calidad del proxy antes de ejecutar campañas.

Los controles de comportamiento siguen siendo importantes

La arquitectura solo reduce algunas señales técnicas de riesgo. LinkedIn también puede evaluar cómo se comporta la cuenta, por lo que dicho comportamiento sigue siendo importante.

Linked Helper incluye controles que le ayudan a evitar patrones evidentemente mecánicos:

• Navegación dentro de la página: Linked Helper puede buscar y hacer clic mediante la propia interfaz de LinkedIn en lugar de acceder directamente a través de las URL de los perfiles.
• Límites diarios de acciones: unos valores predeterminados prudentes ayudan a reducir picos de actividad poco realistas.
• Límites móviles de 24 horas: los límites se miden en ventanas móviles, no solo por días naturales.
• Retrasos aleatorios: el tiempo entre acciones varía en lugar de repetir siempre el mismo intervalo.
• Volúmenes diarios y horarios aleatorios: la actividad de las campañas puede cambiar de un día a otro en lugar de repetir cifras idénticas.
• Variaciones de mensajes: puede alternar varias versiones del mensaje para que la prospección no parezca una única plantilla repetida.

Estos controles no eliminan el riesgo de la automatización, pero ayudan a que la actividad de la cuenta se parezca más al comportamiento normal en LinkedIn.

La salvedad honesta

Ningún proveedor —tampoco Linked Helper— puede garantizar una seguridad total. La capa de comportamiento descrita en este informe evalúa tanto a personas como a sistemas de automatización.

Una prospección deficiente, un volumen excesivo, unas tasas de aceptación bajas, una actividad inusual en la cuenta y una segmentación deficiente pueden crear riesgo, independientemente del software que utilice. Una arquitectura de menor riesgo reduce algunas señales técnicas, pero no hace seguro un comportamiento imprudente de la cuenta.

La pregunta útil no es «¿Es seguro o no?». La pregunta útil es cuántas señales detectables expone la arquitectura antes incluso de tener en cuenta su comportamiento.

Linked Helper está diseñado para mantener la sesión en el equipo del usuario, evitar las señales de las extensiones y de la transferencia de sesiones a la nube, aislar las identidades de las cuentas, permitirle controlar la configuración de IP y favorecer un ritmo más realista.

Nota metodológica

El análisis estático se realizó sobre paquetes de extensiones distribuidos públicamente en mayo-junio de 2026. En la auditoría de registro en la nube se probaron 7 herramientas con 2 cuentas cada una durante junio de 2026.

Las versiones cambian y los proveedores publican actualizaciones. Las clasificaciones de este informe reflejan el código que leímos y las IP que se nos asignaron durante las pruebas. Cuando se midieron, están disponibles las referencias de archivos y líneas, las IP de salida, la reputación de las IP y la presencia de las extensiones complementarias en la lista de detección.

En todo el informe, el comportamiento interno de los servidores se califica como «muy probable» porque no podemos demostrar desde fuera todos los métodos de ejecución en el entorno del servidor. Solo presentamos como hechos aquello que podemos mostrar en el código o medir directamente.

Esta guía es el mapa. Cada análisis detallado por marca aporta pruebas más profundas, y el ejemplo de Dux-Soup de §1 muestra cómo un producto puede combinar varios patrones arquitectónicos en diferentes planes. Linked Helper no está afiliado a LinkedIn, no cuenta con su respaldo ni es socio oficial de LinkedIn.