El soporte no está disponible en todos los Android. Además, para que el iPhone sea detectable es necesario cambiar la configuración de AirDrop y en algunos Galaxy activar un interruptor adicional. Si un modelo no admite el intercambio directo, Quick Share ofrece otra opción: la transferencia mediante un código QR.

Analizaremos qué smartphones son compatibles con AirDrop a 11 de septiembre de 2026, qué ajustes comprobar y por qué el iPhone puede no aparecer en Quick Share.

Qué Android son compatibles con Quick Share y AirDrop

La lista actual de Google incluye smartphones de Google, Samsung, Xiaomi, OnePlus, OPPO, HONOR y vivo.

Google también marca como pendientes de soporte al Motorola razr fold 2026, la serie OPPO Find X8, HONOR Magic8 Pro, vivo X300 y X300 Pro. Mientras la función no se lance para ellos, no conviene contar con la transferencia directa vía AirDrop.

Hay una limitación específica para Pixel. Según la ayuda de Google, se pueden enviar archivos a iPhone, iPad y Mac a partir del Pixel 8a. Para la transferencia inversa, desde un dispositivo Apple a un Pixel, Google indica Pixel 9 y modelos posteriores, excepto el Pixel 9a. Por ello, Pixel 8a y Pixel 9a pueden enviar archivos a un iPhone, pero no figuran en la lista oficial de Pixel para recibir mediante AirDrop.

Con Samsung la situación también depende de la región. La página global de Android enumera modelos hasta Galaxy Z Fold6 y Z Flip6, pero la guía de Samsung en el momento de la comprobación menciona Galaxy S24, S25, S26, Galaxy Z Fold7 y Z Flip7 con Android 16 y One UI 8.5. Samsung advierte explícitamente que la disponibilidad de la función depende de la versión del software y de la región. Por eso, en un Galaxy concreto es mejor comprobar no solo el nombre del modelo sino también la presencia de la opción «Intercambio con dispositivos Apple» en los ajustes.

Cómo enviar un archivo de Android a iPhone

La condición principal desde el iPhone: AirDrop debe estar abierto para todos los dispositivos cercanos. El modo «Solo para contactos» no sirve para el intercambio con Android.

1. En el iPhone abra «Ajustes» → «General» → «AirDrop».
2. Elija «Para todos durante 10 minutos».
3. Asegúrese de que en el iPhone estén activados Wi‑Fi y Bluetooth.
4. En el Android, abra la foto, el vídeo u otro archivo.
5. Pulse «Compartir» → «Quick Share».
6. Seleccione el iPhone en la lista de dispositivos cercanos.
7. En el iPhone acepte el archivo entrante desde la notificación de AirDrop.

Apple permite activar ese modo también desde el Centro de control. Ábralo, pulse y mantenga presionado el grupo de controles de conexión en la esquina superior izquierda, seleccione AirDrop y luego «Para todos durante 10 minutos». Ese procedimiento aparece en la instrucción oficial de Apple.

Tras diez minutos el modo abierto se desactivará automáticamente. Si en el iPhone hay sesión iniciada en la cuenta de Apple, AirDrop volverá a la opción «Solo para contactos». Si no hay sesión, se restaurará la opción «Recepción desactivada».

En un Galaxy compatible, antes de la primera transferencia hay que comprobar también este ajuste: «Ajustes» → «Dispositivos conectados» → «Quick Share» → «Intercambio con dispositivos Apple». El interruptor debe estar activado. Si no aparece esa opción, Samsung recomienda comprobar las actualizaciones del sistema y de los «Servicios de Google Play».

Cómo enviar un archivo de iPhone a Android

La transferencia directa funciona también a la inversa, pero solo en Android que admiten la recepción desde dispositivos Apple.

En Android abra Quick Share y póngalo en modo «Recibir». En la interfaz estándar de Google también puede abrir «Ajustes», buscar «Quick Share», elegir «Quién puede compartir contigo» → «Todos durante 10 minutos».

1. Desbloquee el Android y abra Quick Share.
2. Active el modo «Recibir» o la opción «Todos durante 10 minutos».
3. En el iPhone abra la foto o el archivo.
4. Pulse «Compartir» → AirDrop.
5. Seleccione el Android en la lista de dispositivos detectados.
6. En Android pulse «Aceptar».

En Samsung los nombres difieren. Abra los ajustes de Quick Share, pulse «Quién puede abrirte acceso» y seleccione «Todos (solo 10 minutos)». La opción «Intercambio con dispositivos Apple» también debe estar activada.

Para Pixel, Google indica una limitación aparte: pueden recibir archivos desde iPhone, iPad y Mac los Pixel 9 y modelos posteriores, pero excluye al Pixel 9a. Si Pixel 8a o Pixel 9a no aparecen en AirDrop en el iPhone, puede deberse a la falta de soporte oficial para ese sentido de la transferencia.

Por qué Quick Share no detecta el iPhone

Si el iPhone no aparece entre los dispositivos de Quick Share, primero compruebe las condiciones sin las cuales la transferencia directa no funciona.

• Modelo de Android no compatible. Consulte la lista actual de Google. Para smartphones no compatibles está prevista la transferencia mediante código QR.
• En el iPhone está seleccionado el modo «Solo para contactos». Para Android hay que establecer temporalmente «Para todos durante 10 minutos».
• Han pasado más de diez minutos desde la activación. Abra AirDrop y vuelva a seleccionar «Para todos durante 10 minutos».
• Wi‑Fi o Bluetooth están desactivados. Para el intercambio directo ambos interfaces deben estar activados.
• Los teléfonos están lejos entre sí. Google aconseja colocar los dispositivos juntos, a una distancia no mayor de 30 cm.
• En Samsung está desactivado «Intercambio con dispositivos Apple». Compruebe ese ajuste en Quick Share.
• La función aún no está disponible en el dispositivo concreto. Google advierte que el conjunto de funciones puede variar según el modelo, la región y el operador.
• El teléfono está ocupado con otra transferencia. Espere a que termine y vuelva a intentarlo.

Si se cumplen todas las condiciones pero no se establece la conexión, Google recomienda activar y desactivar el modo avión y, si es necesario, reiniciar los dispositivos. En Android 12 y versiones anteriores también conviene comprobar si la detección de ubicación está activada.

En Galaxy hay restricciones adicionales. Según Samsung, la detección de un dispositivo Apple puede verse afectada por la función de punto de acceso móvil y por funciones que usan Wi‑Fi Direct o Wi‑Fi Aware, como Smart View, DeX, Multi Control, Music Share, Camera Share y Storage Share. Si alguna está activada, desactívela temporalmente y vuelva a buscar.

¿Se necesita Internet y en qué difiere la transferencia directa del código QR?

Para la transferencia directa entre un Android compatible y un iPhone no se necesita Internet. Google indica expresamente que Quick Share con AirDrop funciona sin conexión a Internet. Los dispositivos se detectan por Bluetooth y los archivos se transmiten por una conexión Wi‑Fi local. No es necesario estar conectados a la misma red Wi‑Fi.

Google también confirma que la conexión Quick Share con AirDrop se establece directamente entre los dispositivos. En esa transferencia el archivo no pasa por servidores de Google.

El código QR funciona de forma distinta y está pensado también para Android sin soporte de AirDrop. En ese caso el archivo se sube a los servidores de Google y el iPhone recibe un enlace para descargarlo. Por eso ambos dispositivos necesitan Internet.

Para enviar un archivo mediante código QR:

1. En Android abra el archivo y elija «Compartir» → «Quick Share».
2. Pulse «Usar código QR».
3. Escanee el código con la cámara del iPhone.
4. Pulse el enlace que aparezca.
5. En el navegador se abrirá la página de Quick Share y comenzará la transferencia.

Google indica para este método un límite de hasta 10 GB en 24 horas y hasta 1000 archivos por sesión. Es posible enviar archivos simultáneamente a no más de 20 dispositivos Apple. Los datos se almacenan en los servidores de Google hasta 24 horas, están protegidos con cifrado de extremo a extremo y no ocupan espacio en el Google Drive personal.

La diferencia es por tanto fundamental. Si el iPhone aparece directamente en la lista de Quick Share, el archivo puede transferirse sin Internet. Si Android muestra un código QR, se usa Internet y una carga intermedia a los servidores de Google.

¿Funciona Quick Share con Mac y qué hacer con un Android no compatible?

Quick Share con AirDrop no funciona solo con iPhone. Google admite el envío a iPad y Mac, si el Android es compatible con la función.

En el Mac hay que abrir «Preferencias del Sistema» → «General» → «AirDrop y Handoff», y en la configuración de AirDrop elegir «Todos». Ese procedimiento figura en la documentación de Apple. Tras ello, un Android compatible podrá detectar el Mac mediante Quick Share.

Para Galaxy, Samsung indica iPhone 8 y posteriores, iPad de quinta generación y posteriores, así como MacBook de 2020 en adelante. Para otros Android conviene seguir los requisitos del fabricante y la ayuda actual de Google.

Si el smartphone no figura en la lista de modelos compatibles, instalar una aplicación en el iPhone no resolverá el problema. No hace falta una versión de Quick Share para iOS para esa transferencia. La opción integrada más sencilla en ese caso es abrir Quick Share en el Android, elegir «Usar código QR» y escanearlo con la cámara del iPhone.

Por eso al atacante a veces no le hace falta romper la 2FA. Si un info‑stealer robó un token válido, el delincuente puede presentarlo al servidor como confirmación de una sesión ya creada. El servidor ve la continuación de una sesión previamente autorizada, no un nuevo inicio de sesión. Comprobaciones por dirección de red, dispositivo y otros indicios pueden frenar el ataque, por lo que una sola copia del token no basta en todos los servicios.

La dimensión del problema la mostró la investigación de Okta del 9 de septiembre de 2026. La empresa analizó 7 GB de datos de info‑stealers de 5 871 equipos infectados en 162 países. El volcado apareció en Telegram el 2 de agosto. Los investigadores encontraron 44 791 JWT únicos, de los cuales 555 probablemente estaban relacionados con la autenticación en servicios de inteligencia artificial.

Cómo el robo de sesión permite eludir la 2FA

La cadena habitual es: contraseña → segundo factor o clave de acceso → el servidor confirma la identidad → crea una sesión → el navegador recibe un identificador de sesión → las siguientes solicitudes se realizan con ese identificador.

El segundo factor actúa al inicio de la cadena. Tras el inicio de sesión, el sitio necesita una forma de recordar al usuario ya verificado. Muchos datos de sesión funcionan mediante la presentación de un secreto válido. Si el atacante obtiene ese secreto, el servidor debe recurrir a otros métodos para determinar si la solicitud procede realmente del usuario anterior.

El robo de sesión no rompe la autenticación de dos factores. El atacante utiliza el resultado de una comprobación que ya se pasó con éxito.

Una clave de acceso protege bien contra el phishing y el robo de contraseña, pero por sí sola no protege cada token de sesión que el servicio entregue tras el inicio. Por eso bancos, servicios de correo y otros sistemas pueden volver a solicitar la confirmación de identidad antes de cambiar la contraseña, añadir un nuevo método de acceso o realizar otra operación sensible.

Qué son cookie, token de acceso, token de actualización y JWT

La cookie de sesión guarda el identificador o el token de la sesión actual. Un token de acceso otorga ciertos permisos por un tiempo limitado, y un token de actualización permite obtener nuevos tokens de acceso. El robo del último es especialmente peligroso, porque el atacante puede renovar el acceso hasta que el secreto sea revocado o expire.

JWT, o JSON Web Token, es un formato de token. Una firma criptográfica protege el contenido frente a modificaciones inadvertidas, pero no impide copiar un JWT válido en su totalidad. Un JWT firmado tampoco tiene por qué estar cifrado.

Okta encontró 44 791 JWT únicos. En el 17,7 % de los tokens había datos personales abiertos, por ejemplo nombre, dirección de correo electrónico o número de teléfono. Esa información sigue siendo útil para phishing incluso después del vencimiento del token.

Los investigadores también hallaron 2 937 JWE relacionados con autenticación. Según Okta, una parte importante de esos tokens la emitía OpenAI usando NextAuth.js. Al 2 de agosto, 1 843 de los JWT y JWE encontrados aún no habían expirado. El cifrado oculta el contenido de un JWE, pero no impide por sí solo volver a presentar un token válido al servidor.

En una tabla aparte Okta indicó 9 829 tokens únicos de autenticación de Google, de los cuales 9 213 seguían vigentes. Para Microsoft los valores fueron 2 491 y 1 763, y para Anthropic 561 y 164. Las cifras de Google y Microsoft no deben interpretarse como número de cuentas robadas en servicios de IA, porque los sistemas de autenticación compartida cubren distintos productos.

El coste de una filtración puede ser alto. Unit 42 describe un caso con gastos de casi 1 millón de dólares. En otro incidente público citado por Okta, el arquitecto de software Jesse Davies informó del uso no autorizado de Gemini por aproximadamente 25 673 AUD. El atacante llamó a un servicio público de Cloud Run, no robó la sesión del navegador.

Otro caso independiente ocurrió en METR. Por un error fail‑open, una instancia pública de EC2 quedó prácticamente sin comprobación de acceso, tras lo cual el atacante logró la exposición de una clave de API y durante casi tres semanas consumió créditos por un valor aproximado de 600 000 dólares. Allí no se usó un info‑stealer ni el robo de cookies. El caso muestra el riesgo general: obtenido un secreto válido, el atacante a menudo puede usar el acceso sin un nuevo inicio de sesión.

Qué hacer si roban la sesión o la cookie

Los info‑stealers buscan contraseñas guardadas, cookies, datos de perfiles del navegador, tokens de aplicaciones y claves de API. El atributo HttpOnly dificulta que una página web ordinaria lea las cookies, pero no protege frente a un programa malicioso que ya esté en el equipo.

Si sospecha de un info‑stealer, no cambie la contraseña ni inicie sesión en cuentas importantes desde el dispositivo infectado. El malware puede robar al instante las nuevas cookies y tokens.

1. Desconecte el dispositivo sospechoso de la red.
2. Desde un dispositivo limpio, abra la configuración de seguridad de la cuenta.
3. Cierre todas las sesiones activas.
4. Revoque aplicaciones desconocidas, claves y tokens.
5. Cambie la contraseña.
6. Reemita los códigos de respaldo de la 2FA.
7. Revise el historial de accesos y los cambios de configuración.
8. Limpie el sistema infectado y, si la compromisión es grave, reinstálelo.

El botón «Cerrar sesión» a menudo termina solo la sesión actual. Cambiar la contraseña tampoco siempre revoca todos los tokens emitidos con anterioridad.

Primero revoque las sesiones antiguas desde un dispositivo limpio. Cambiar la contraseña en un equipo infectado puede simplemente entregar al info‑stealer la nueva contraseña y una nueva sesión.

Cómo los navegadores protegen la sesión frente a la copia

En 2024 Google añadió en Chrome 127 para Windows App‑Bound Encryption. El mecanismo vinculó el descifrado de datos protegidos del navegador a Chrome y dificultó la extracción directa de cookies. La protección elevó el coste del ataque, pero no resolvió el problema por completo. Especialistas de Red Canary hallaron saltos en Stealc, Vidar, LummaC2 y otros info‑stealers. El malware, por ejemplo, extraía cookies de la memoria del navegador o usaba depuración remota.

Device Bound Session Credentials, o DBSC, va más allá y vincula la continuación de la sesión a una clave criptográfica del dispositivo. El navegador crea un par de claves, y la clave privada no debería abandonar el dispositivo. Para emitir una nueva cookie de corta duración, el servidor pide al navegador que demuestre la posesión de la clave. Así, una copia robada de la cookie en otro equipo pierde rápidamente valor.

Google empezó a desplegar DBSC en Chrome 145 para Windows, donde las claves las protege el módulo TPM. En abril de 2026 la empresa anunció la disponibilidad pública de DBSC para Windows en Chrome 146. En el mismo comunicado Google mencionó solo la intención de soportar macOS en una de las versiones siguientes de Chrome y no dio una versión concreta. Por eso no puede afirmarse que DBSC para macOS apareció precisamente en Chrome 147 sin una confirmación oficial aparte.

DBSC no se puede activar simplemente en cualquier sitio y considerar el problema resuelto. El servidor del servicio debe soportar el protocolo, y el malware en el equipo de origen aún puede actuar en nombre del usuario directamente en el dispositivo infectado.

Conclusión

La 2FA y las claves de acceso aumentan mucho la seguridad de una cuenta, pero no eliminan la amenaza del robo de una sesión ya creada. Tras una infección, hay que revocar las sesiones y tokens activos desde un dispositivo limpio y luego eliminar el malware. Los tokens de corta duración, la verificación adicional antes de acciones críticas y la vinculación de la sesión al dispositivo reducen la posibilidad de reutilizar un secreto robado.

El material está destinado a proteger cuentas y sistemas propios. El robo, la interceptación y el uso de tokens o sesiones ajenos sin el permiso del titular pueden infringir la legislación rusa. Verifique esos mecanismos solo en sus propios sistemas o con permiso expreso.

No hay un ganador universal aquí. Google Play no obtiene prioridad absoluta, y RuStore no bloquea la aplicación para sí de forma permanente después de la primera instalación. El resultado depende del identificador de la aplicación, de la firma digital, del número interno de versión y, en las versiones nuevas de Android, del mecanismo de propiedad de las actualizaciones.

Cómo decide Android si se puede instalar una actualización

La tienda solo descarga la compilación nueva. La decisión final sobre la instalación la toma Android. En la documentación oficial de Android están indicadas las condiciones principales para la actualización:

• Coincide el identificador de la aplicación. Android usa el application ID, por ejemplo ====code====

  com.example.app

  ============= .
• Coincide la firma digital. También se admite una transición correctamente realizada a una clave de firma nueva.
• El número interno de versión no es inferior al instalado. El sistema se guía por el ====code====

  versionCode

  ============= , y no solo por el número visible como 5.4.1.
• Si es necesario, el usuario confirma la instalación. Esto depende de la versión de Android y del instalador.

Por eso, una aplicación instalada desde RuStore a veces sí puede recibir una actualización desde Google Play. Para ello las compilaciones deben ser compatibles, y Play debe considerar la aplicación disponible para actualización en ese dispositivo. Por lo general, esto también significa que la aplicación ya está en la biblioteca del usuario o fue preinstalada por el fabricante.

La situación inversa también es posible. Si el desarrollador usa una misma firma en distintas tiendas, Android en principio admite la transición entre ellas sin desinstalar. A los desarrolladores que quieren mantener actualizaciones compatibles desde varias tiendas se les suele recomendar usar una única clave de firma.

Por qué surge un conflicto de firma

La firma digital confirma quién tiene derecho a publicar una continuación de la aplicación instalada. Al actualizar, Android verifica el certificado de la nueva compilación. Si no coincide con el certificado de la versión actual y no existe una rotación de clave permitida, el sistema no autoriza el reemplazo.

Esto puede ocurrir si las versiones para RuStore y Google Play están firmadas con claves distintas. Para el usuario normalmente se ve igual: la tienda descarga la actualización, pero la instalación termina con un error.

Por eso RuStore recomienda actualizar la aplicación por el mismo método con el que se instaló. Es mejor actualizar la versión de RuStore desde RuStore, y la compilación de otra tienda desde esa misma tienda. Si el usuario quiere pasarse a RuStore, el servicio aconseja eliminar la versión actual e instalarla de nuevo.

Si RuStore informa directamente de un conflicto de firmas, pulsar «Actualizar» de nuevo no resolverá el problema. En la instrucción oficial de RuStore para ese caso se indica la reinstalación completa de la aplicación.

Quién actualizará la aplicación si la actualización automática está activada en ambas tiendas

No se puede determinar esto por el nombre de la tienda. Si ambos servicios han recibido una compilación adecuada y pueden iniciar la instalación, la aplicación la actualizará la que descargó el archivo antes y completó la instalación con éxito, no la que sea «más importante».

Además, Android protege la aplicación contra reversión normal. Si una tienda ya ha instalado una compilación con un ====code====

versionCode

Desde Android 14 existe el mecanismo de propiedad de las actualizaciones. El instalador puede solicitar el derecho a gestionar las actualizaciones del paquete, y entonces otro instalador puede necesitar el consentimiento del usuario. Pero la existencia de la función no significa que en cada smartphone y para cada aplicación se asigne automáticamente una tienda permanente.

Por eso es más seguro no confiar en una prioridad del sistema y eliminar usted mismo la competencia entre las tiendas: no existe en Android un interruptor único que haga eso automáticamente para todas las aplicaciones.

Cómo elegir una tienda para las actualizaciones

Si no hay errores de instalación, no es necesario desinstalar la aplicación. Basta con desactivar su actualización automática en la otra tienda.

Si quiere actualizar la aplicación mediante RuStore:

1. Abra Google Play.
2. Pulse la foto de perfil y seleccione «Gestionar apps y dispositivo».
3. Abra «Gestionar» y seleccione la aplicación deseada.
4. En la página de la aplicación, pulse el icono «Más».
5. Desactive la opción «Actualización automática».
6. En RuStore abra el perfil → «Ajustes de autoactualizaciones» y asegúrese de que la aplicación no esté en «Excepciones».

Los nombres de las opciones en Google Play corresponden a la ayuda oficial de Google actual. En RuStore la sección «Excepciones» se usa para las aplicaciones que no deben actualizarse automáticamente.

Si quiere actualizar la aplicación mediante Google Play: active «Actualización automática» para ella en Google Play, y en RuStore abra el perfil → «Ajustes de autoactualizaciones» → «Excepciones» y añada esta aplicación.

Si necesita desactivar por completo las actualizaciones automáticas de Google Play, abra «Ajustes» → «Ajustes de conexión» → «Actualización automática de aplicaciones» y seleccione «Nunca». Google advierte además que las actualizaciones que corrigen vulnerabilidades graves pueden, en algunos casos, instalarse independientemente de esta configuración.

En RuStore el modo general se configura desde el perfil → «Ajustes de autoactualizaciones». En la página oficial de RuStore también se describen la selección de red para las descargas y la lista de excepciones para aplicaciones individuales.

Por qué RuStore sugiere actualizar una aplicación ya actualizada

Primero conviene comprobar si ambas compilaciones son realmente iguales. Android tiene dos números de versión. El ====code====

versionName

versionCode

Además, las versiones en las tiendas se publican de forma independiente. Google Play puede estar distribuyendo una compilación más reciente mientras en RuStore hay otra, o viceversa. Si tras iniciarse la propia aplicación lleva al usuario a Google Play, eso tampoco significa que Android haya asignado a Google la condición de tienda principal. El enlace a la actualización puede ser mostrado por la propia aplicación según la lógica del desarrollador.

RuStore también reconoce la situación en que la tienda ofrece actualizar una aplicación que ya está actualizada. En su ayuda el servicio aconseja en ese caso limpiar la caché de RuStore o reinstalar la propia tienda. No es necesario eliminar la aplicación problemática como primer paso.

Cuándo es necesaria la reinstalación y qué comprobar antes de eliminar

Conviene desinstalar la aplicación cuando la compilación nueva no pasa la verificación de firma o la tienda elegida informa directamente de la incompatibilidad con la versión instalada. Antes de ello debe comprobar los datos que solo pueden almacenarse en el teléfono. Las aplicaciones admiten la copia de seguridad y la restauración de formas distintas.

• Banco. Asegúrese de que la aplicación esté disponible para reinstalación desde la fuente oficial elegida, y de tener los datos de acceso y acceso al número vinculado. Tras la reinstalación puede ser necesaria una nueva autorización y volver a configurar la biometría.
• Juego. Vincule el progreso a una cuenta o a un guardado en la nube compatible. Las partidas guardadas locales pueden desaparecer al desinstalar.
• Aplicación con archivos locales. Exporte documentos, proyectos, grabaciones y otros datos si la aplicación ofrece esa opción.
• Funciones de pago. Revise las políticas del desarrollador. Una compra o suscripción realizada a través de una tienda puede depender de la cuenta de esa tienda y de su sistema de pago.
• Códigos y claves. Para autenticadores, certificados y otras aplicaciones con secretos locales primero utilice la exportación o la copia de seguridad integrada.

Tras comprobar, desinstale la aplicación desde «Ajustes» → «Aplicaciones» → la aplicación correspondiente → «Desinstalar», o bien desde el menú del icono si esa opción existe en la capa del teléfono. Luego instale la aplicación de nuevo desde la tienda elegida.

No descargue un APK aleatorio para evitar el error. Si tiene otra firma, Android de nuevo rechazará la actualización, y la fuente desconocida aumentará el riesgo de obtener una compilación falsa.

Tras la reinstalación deje para la aplicación solo una fuente de actualizaciones automáticas. Para la versión de RuStore desactive la actualización automática en Google Play. Para la versión de Google Play añada la aplicación a «Excepciones» en RuStore. Esta es la forma más clara de evitar un conflicto repetido.

Después de que se publica la corrección, a veces resulta más fácil para un atacante encontrar el error. En lugar de revisar millones de líneas de código fuente, se puede comparar la versión antigua y la nueva, localizar la sección modificada y entender qué situación peligrosa corregía el desarrollador. Para Chromium el problema es especialmente visible, ya que el código fuente es abierto, y Chrome, Edge y otros navegadores reciben compilaciones finales según sus propios calendarios.

Qué es el patch gap y cómo se encuentra una vulnerabilidad a partir de una corrección

Google define el patch gap como el intervalo entre el momento en que se añade una corrección de seguridad a Chromium y el momento en que esa misma corrección se entrega a los usuarios de la versión estable de Chrome.

El parche en sí no contiene una descripción lista de la posible explotación. Sin embargo, la naturaleza del cambio a menudo ofrece una pista clara. Una nueva comprobación de límites de un array, una verificación adicional de tipos o un cambio en el manejo de memoria hacen que el investigador examine la implementación previa en ese punto concreto.

La cadena es esta: el desarrollador corrige el error → el cambio aparece en Chromium → el investigador compara versiones → reconstruye la causa del parche → examina la compilación antigua → crea un exploit → la actualización estable llega más tarde a los usuarios.

Google considera este escenario como una explotación de una vulnerabilidad ya conocida, es decir, un n-day. Si se intenta ocultar el objetivo del parche, por lo general eso ayuda poco. El riesgo disminuye mucho más cuando el código fuente se corrige con rapidez y pronto se publica una versión estable protegida.

El patch gap no crea la vulnerabilidad. El error ya existía anteriormente, pero la publicación pública de la corrección puede reducir drásticamente el tiempo necesario para encontrarla y analizarla.

BlueMoon mostró el patch gap en ataques reales

La historia de BlueMoon ilustra bien cómo se manifiesta el patch gap en la práctica. La secuencia fue simple: 

7 de agosto la corrección de CVE-2026-85046 apareció en Chromium →
28 de agosto comenzaron ataques confirmados →
3 de septiembre Google lanzó Chrome 152.0.7977.82/.83 corregido →
la actividad de BlueMoon continuó al menos hasta el 8 de septiembre →
9 de septiembre Proofpoint divulgó las campañas.

Al principio BlueMoon empleó al actor vinculado con China TA412, también conocido como APT31 y Violet Typhoon. Después, el mismo conjunto apareció en UNK_LateNight, UNK_DoubleCheck y UNK_QuietRacket. En pocos días una cadena fue utilizada por cuatro clústeres de espionaje.

La limitación de la tercera etapa a versiones antiguas de Windows y el notable uso del comando curl indicaban prisa. Proofpoint supone que los operadores intentaron usar la última cadena de navegador antes de la instalación masiva de actualizaciones, de modo que la velocidad fue más importante que el sigilo.

Tras un ataque exitoso, TA412 instalaba la extensión GemStone, disfrazada como Google Gemini. Esta robaba datos del navegador, registraba entradas y aceptaba órdenes. El instalador comprobaba Chrome, Edge, Brave y Vivaldi.

BlueMoon muestra el riesgo principal del patch gap: la corrección puede existir ya en el código fuente, pero los ataques reales continúan hasta que los usuarios reciben e instalan la versión protegida.

En qué se diferencia un zero-day de un n-day y qué relación tiene CVE-2026-87491

Zero-day suele denominarse la vulnerabilidad que los atacantes explotan mientras no existe una corrección disponible para los usuarios. N-day suele referirse a la explotación de un error ya divulgado o corregido, cuando parte de los dispositivos siguen ejecutando la versión antigua. No hay un límite universal estricto entre los términos, por eso distintos investigadores pueden describir el mismo caso de forma algo diferente.

CVE-2026-87491 es un ejemplo aparte y no está vinculada a BlueMoon. El fallo de escritura fuera de límites se encontraba en V8. El investigador Jihyeon Jeong del laboratorio Compsec de la Universidad Nacional de Seúl informó a Google sobre él el 6 de agosto a través del programa de recompensas por errores. La corrección entró en Chrome 153, publicado el 8 de septiembre. Google también confirmó la existencia de un exploit para CVE-2026-87491 en ataques reales.

En una semana de septiembre hubo dos ejemplos independientes de un mismo problema. CVE-2026-85046 se usó en BlueMoon antes de la entrega masiva de la corrección en Chrome 152, y la CVE-2026-87491, divulgada por separado, requirió ya Chrome 153. No deben mezclarse las dos historias, aunque ambas muestran lo corto que puede ser el intervalo entre la disponibilidad de información sobre un error y su explotación.

La agencia CISA incluyó ambas vulnerabilidades en el catálogo KEV. Para CVE-2026-85046 las agencias civiles federales de EE. UU. deben mitigar el riesgo antes del 18 de septiembre de 2026; para CVE-2026-87491, antes del 23 de septiembre. Esos plazos ilustran la diferencia entre la aparición de la corrección y la actualización efectiva de todo el parque de dispositivos.

Un parche público ayuda a buscar errores relacionados. Este enfoque se llama búsqueda de variantes. El investigador analiza la causa de una vulnerabilidad y luego revisa otras funciones y componentes en busca de patrones peligrosos similares. El método lo aplican tanto desarrolladores para proteger el producto como atacantes en busca de nuevos puntos de entrada.

Por qué Chromium es especialmente sensible a los retrasos en las actualizaciones

Chromium sirve como base común para varios navegadores. Cuando los desarrolladores corrigen el código fuente de Chromium, el fabricante del producto final aún tiene que incorporar el cambio en su rama, probar la compilación y entregar la actualización a los usuarios.

Durante los primeros ataques de BlueMoon, las versiones estables más recientes de los navegadores afectados aún no incluían las correcciones necesarias. Los cambios publicados en Chromium ya se podían analizar, mientras que las compilaciones de usuario seguían siendo vulnerables. La salida de un Chrome protegido tampoco implica automáticamente que Edge, Brave, Opera, Vivaldi o una aplicación basada en Electron ya hayan recibido una actualización equivalente.

La actualización automática de Chrome tampoco garantiza protección instantánea. La nueva versión puede descargarse en segundo plano, pero el navegador seguirá ejecutando el código antiguo hasta que se reinicie. Además, Google distribuye algunas versiones de forma gradual durante varios días o semanas.

En el equipo, la comprobación se ve así: Menú → Ayuda → Acerca de Google Chrome → esperar a que compruebe las actualizaciones → Reiniciar. Para otro navegador basado en Chromium hay que comprobar la actualización de ese producto concreto.

La frase «el desarrollador lanzó un parche» y la frase «mi navegador está protegido» son eventos diferentes. La protección aparece después de instalar la versión corregida y, cuando el programa lo exige, al reiniciarlo.

Conclusión

El patch gap surge entre la corrección del código fuente y la entrega de la versión protegida al usuario. En un proyecto abierto como Chromium ese intervalo es especialmente peligroso: un parche publicado permite localizar más rápido la sección modificada y reconstruir el principio de funcionamiento del error.

BlueMoon mostró esa carrera en la práctica. La corrección de CVE-2026-85046 estuvo en el código fuente desde el 7 de agosto; Chrome 152.0.7977.82/.83 recibió la protección el 3 de septiembre, pero se observaron ataques varios días más. Los operadores utilizaron una cadena que incluía un escape no numerado del sandbox de V8 y CVE-2026-85880 para versiones antiguas de Windows, sacrificando el sigilo en favor de la velocidad.

Al notificarse una vulnerabilidad en explotación activa conviene comprobar manualmente la versión del navegador, instalar la actualización disponible y reiniciar completamente el programa. Los usuarios de Edge, Brave, Opera, Vivaldi y otros productos basados en Chromium deben guiarse por la publicación de su fabricante, no solo por noticias sobre parches de Chrome.

El material describe vulnerabilidades y métodos de análisis solo con fines educativos. No se debe crear ni emplear exploits contra sistemas ajenos sin el permiso del propietario. Al investigar software, respete la legislación de la Federación de Rusia y pruebe únicamente sus propios sistemas o recursos para los que tenga permiso explícito.

El 12 de mayo de 2026 Google anunció una comprobación adicional de APK en Chrome para Android. Con Safe Browsing activado, el navegador evalúa el paquete descargado en busca de malware conocido y puede detener la descarga antes de la instalación. Google no indicó la versión exacta de Chrome ni el calendario de despliegue completo de la función, por lo que la apariencia de la advertencia puede variar según la versión del navegador.

Explicamos por qué Chrome bloquea los APK, en qué se diferencian las advertencias entre sí, dónde entra Play Protect y cómo descargar de forma segura un APK de un banco, RuStore u otro servicio. El artículo está orientado a usuarios en Rusia.

Por qué Chrome bloquea los APK ya en la etapa de descarga

Las descargas de APK ahora tienen varios niveles de comprobación independientes. El primero es el propio Chrome: al descargar, el navegador consulta la Navegación segura y evalúa el sitio, la conexión y el archivo según el nivel de protección.

En Chrome para Android, por defecto se usa la Protección estándar. En los ajustes también están disponibles la Protección mejorada y la Protección desactivada. Ruta en la versión en español de Chrome: Más → Configuración → Privacidad y seguridad → Navegación segura. La nueva comprobación de APK funciona con Safe Browsing activado, independientemente del nivel de protección, y el botón «Comprobar si hay malware» para archivos sospechosos está disponible en el modo de Protección mejorada.

Google describe el nuevo mecanismo como una comprobación del paquete en busca de malware conocido ya durante la descarga —es una barrera separada antes de que se ejecute el instalador de Android. Por eso, permitir instalar aplicaciones desde Chrome no afecta la decisión del navegador de detener la descarga.

Qué significan las advertencias de Chrome al descargar APK

En la ayuda de Chrome Google clasifica los bloqueos de descarga en varios tipos, y no conviene reaccionar igual ante todos.

Un APK sospechoso puede ser simplemente nuevo o poco descargado, y la etiqueta Archivo peligroso es una señal más seria, por lo que no conviene tratar todas las advertencias por igual. En el modo de Protección mejorada, Chrome puede ofrecer una comprobación adicional: la acción Comprobar si hay malware, tras la cual informará si se ha encontrado contenido malicioso.

Chrome, Play Protect y el permiso para instalar APK: etapas distintas

Estos tres mecanismos se confunden con frecuencia, aunque resuelven tareas diferentes.

• Chrome y Navegación segura analizan el sitio y la descarga. La nueva protección de 2026 puede detener un APK antes de que se guarde el archivo.
• Google Play Protect comprueba las aplicaciones en la instalación, analiza el dispositivo posteriormente y puede advertir, bloquear o eliminar una aplicación potencialmente peligrosa.
• El permiso para instalar desde fuentes externas determina si una aplicación (por ejemplo, Chrome o un gestor de archivos) tiene derecho a pasar el APK al instalador del sistema.

Por eso, no se soluciona el mensaje de Chrome con el permiso para instalar desde fuentes desconocidas: ese permiso se necesitará más tarde, cuando el APK ya esté descargado y el usuario lo abra. La ruta a esa opción del menú varía según las capas de personalización de Android, por lo que no la considere universal para todos los fabricantes.

Play Protect también está activado por defecto: en Google Play sus ajustes están en la ruta icono de perfil → Play Protect → Ajustes. Para las aplicaciones que se obtienen fuera de Google Play, el servicio puede ofrecer un escaneo adicional.

Qué hacer si Chrome bloquea un APK oficial de un banco, RuStore u otro servicio

Algunos bancos y tiendas de aplicaciones distribuyen APK en sus propios sitios. La procedencia es más importante que el nombre del archivo: un APK falsificado puede llamarse igual que el oficial.

1. Busque el sitio oficial por su cuenta si llegó a la página desde un anuncio o un enlace accidental. Compruebe la dirección del banco con sus canales oficiales, y descargue RuStore solo desde el dominio rustore.ru.
2. Verifique la dirección antes de descargar. Un error en una letra, un guion adicional, un subdominio desconocido o una redirección mediante un acortador de enlaces son motivos para no continuar.
3. Evalúe la advertencia de Chrome. Un archivo sospechoso o poco frecuente no es lo mismo que una infección. Si Chrome identifica el archivo como peligroso, es mejor cancelar la descarga.
4. No desactive la Navegación segura (ruta descrita arriba): desactivarla por una sola descarga reduce la protección de todos los sitios y archivos posteriores.
5. Use la comprobación adicional si Chrome la ofrece —la acción Comprobar si hay malware para archivos sospechosos.
6. Tras la descarga, no desactive Play Protect. Deje que Android analice el paquete; para un APK poco conocido, el sistema puede solicitar un escaneo adicional.
7. Permita la instalación solo a la aplicación desde la que abre el APK, y solo después de verificar la fuente.

RuStore ofrece una instrucción oficial: la tienda propone descargar RuStore.apk desde su propio sitio y muestra los pasos para permitir la descarga y la instalación. Si la página que ofrece RuStore está en otro dominio, es más seguro volver a rustore.ru y comenzar de nuevo.

Para un banco, utilice únicamente el enlace desde su sitio oficial. La instalación desde una tienda oficial de aplicaciones suele ser más fiable que la descarga manual de un APK.

Cómo comprobar un APK y cuándo cancelar la descarga

Es útil comprobar tres cosas: la fuente, la integridad y la firma del APK.

Fuente. El APK debe provenir del dominio oficial del desarrollador o de una tienda a la que el propio desarrollador remita. El icono de la aplicación, un nombre de archivo conocido o un diseño de página similar no garantizan nada.

Checksum. Si el desarrollador publica el SHA-256 del APK, compárelo con el valor del archivo descargado. La coincidencia confirma que el archivo no se ha modificado, pero no demuestra que el programa sea seguro —compare el hash solo con el valor del origen oficial.

Firma digital. Android compara la firma de la nueva versión con la firma de la aplicación ya instalada. Un APK con un certificado distinto no se instalará sobre la aplicación existente como una actualización normal.

Usuarios avanzados pueden comprobar el APK con la herramienta del SDK de Android apksigner: el comando ====code====

apksigner verify --print-certs app.apk

Es mejor cancelar la descarga sin intentar sortearla si coincide al menos uno de los siguientes signos:

• Chrome informa del descubrimiento de malware o bloquea el archivo como peligroso;
• el APK se descarga desde un dominio que no es el oficial, como espejo, foro, disco en la nube o un enlace dentro de un mensaje;
• el sitio exige desactivar la Navegación segura o Play Protect como condición obligatoria;
• la página se hace pasar por un banco o servicio, pero la dirección difiere de la oficial;
• el desarrollador no confirma ese método de distribución;
• el archivo debería ser una actualización, pero Android no lo acepta por problemas con la firma.

Incluso una advertencia para un APK oficial no debe considerarse automáticamente un error: consulte el soporte del desarrollador y la disponibilidad de una versión nueva del archivo.

apksigner verify --print-certs app.apk

Pero la frontera entre el navegador y el sistema operativo no es absoluta. Chromium admite un mecanismo estándar de intercambio con programas locales llamado Native Messaging. Si en el equipo está instalado un componente local compatible, la extensión puede enviarle comandos y el programa ya funciona fuera del entorno del navegador con los privilegios del usuario actual.

El permiso "leer y modificar datos en todos los sitios" no significa control total sobre Windows o Linux. Para trabajar arbitrariamente con archivos y comandos del sistema operativo, la extensión por lo general necesita un componente local separado o el equipo ya debe estar comprometido de otra manera.

Qué puede una extensión típica de Chrome dentro del navegador

Las capacidades las definen los permisos que el desarrollador indicó en el archivo de la extensión. La documentación de Chrome divide los permisos entre acceso a las interfaces del navegador y acceso a sitios.

Una extensión con amplio acceso a sitios puede leer el contenido de las páginas y modificarlo. Google indica expresamente que los scripts de las extensiones pueden operar con la estructura de la página web. El complemento puede, por ejemplo, ver datos de formularios, modificar la página o añadir sus propios elementos.

Un riesgo aparte está relacionado con las cookies. La interfaz chrome.cookies permite leer y modificar las cookies de los sitios a los que la extensión tiene acceso. Una cookie de sesión válida robada a veces permite a un atacante aprovechar una sesión activa sin conocer la contraseña.

La situación con los datos guardados en el gestor de contraseñas de Chrome es distinta. No existe una interfaz estándar para que las extensiones lean toda la base de contraseñas guardadas. Pero un complemento malicioso con acceso a una página puede intentar interceptar la contraseña que el usuario introduce en un formulario, suplantar la página de inicio de sesión o robar información de una sesión activa.

El acceso a direcciones locales del tipo file:// tampoco equivale al acceso a todo el disco. Chrome requiere permitir por separado a la extensión trabajar con esas direcciones. El usuario puede cambiar el permiso en la página de administración de la extensión, lo que se describe en la documentación.

Cómo Native Messaging saca a la extensión más allá del navegador

Native Messaging no fue creado como una forma de eludir las protecciones, sino como un mecanismo estándar para enlazar el navegador con un programa instalado en el equipo. Ese mecanismo es necesario, por ejemplo, para algunos gestores de contraseñas, herramientas corporativas de seguridad, programas criptográficos y aplicaciones a las que las capacidades del navegador no les bastan.

El esquema es así: extensión de Chrome → servicio de la extensión → Native Messaging → programa local → sistema operativo.

Según la documentación de Chrome, una extensión con el permiso nativeMessaging puede conectarse a un programa local previamente registrado. Chrome inicia dicho programa como un proceso separado y transmite mensajes a través de las entradas y salidas estándar. En la configuración del componente local también se indican los identificadores de las extensiones a las que se les permite la conexión.

Chrome no crea el programa local por sí mismo. El componente debe haber llegado al sistema con anterioridad, por ejemplo junto con una aplicación instalada. Por ello una extensión aleatoria de la tienda no puede simplemente declarar nativeMessaging y obtener automáticamente acceso a la línea de comandos del sistema.

En Windows Chrome busca componentes Native Messaging registrados, en particular en las ramas ====code====

HKEY_CURRENT_USERSOFTWAREGoogleChromeNativeMessagingHosts

HKEY_LOCAL_MACHINESOFTWAREGoogleChromeNativeMessagingHosts

SOFTWAREMicrosoftEdgeNativeMessagingHosts

En Linux Chrome busca configuraciones de usuario, por ejemplo en ====code====

~/.config/google-chrome/NativeMessagingHosts

/etc/opt/chrome/native-messaging-hosts

Por qué PEEP puede ejecutar comandos de Windows

Un buen ejemplo de esta arquitectura apareció en septiembre de 2026. Se detectó el conjunto PEEP, que se hace pasar por la extensión "Smart Bookmarks" para Chrome y Edge.

PEEP muestra la diferencia entre una extensión maliciosa y una toma completa del equipo. En el navegador el componente recopila historial, información sobre pestañas y cookies, puede operar con el contenido de las páginas y realizar otras acciones disponibles para el navegador. Cuando el operador necesita acceder a archivos, obtener la lista de procesos o ejecutar un comando del sistema, la extensión transfiere la tarea a un programa independiente ====code====

nm_host.exe

Los especialistas encontraron comandos para leer y escribir archivos, buscar archivos, ver procesos y servicios, así como iniciar una consola de comandos. El programa local realiza esas acciones con los privilegios de la cuenta del usuario. El propio mecanismo no eleva los privilegios.

PEEP no debe considerarse un ejemplo de que un usuario instaló una extensión ordinaria y con ello entregó de inmediato todo el equipo al atacante. El conjunto está pensado para una fase posterior al compromiso inicial. Antes de la instalación, el atacante ya necesita la posibilidad de ejecutar código en el equipo, y algunos métodos de persistencia requieren privilegios más elevados.

PEEP también modifica la configuración de Chromium, incluidas las Secure Preferences, y aplica mecanismos de instalación forzada de extensiones. Por eso eliminar simplemente el icono de "Smart Bookmarks" no garantiza limpiar un sistema infectado.

Una extensión de la tienda oficial y una que el atacante instaló tras comprometer el equipo se encuentran en condiciones totalmente distintas. En el segundo caso el atacante ya puede modificar archivos del navegador, la configuración del sistema y registrar componentes locales.

Cómo comprobar extensiones peligrosas en Chrome y Edge

Empiece por la lista habitual de complementos. En Chrome abra ====code====

chrome://extensions

edge://extensions

Para cada complemento abra los detalles y compruebe el acceso a sitios. Si el programa no necesita trabajar constantemente en todas las páginas, limite el acceso a sitios concretos o a la activación mediante clic.

A continuación revise las políticas del navegador. Chrome → ====code====

chrome://policy

ExtensionSettings

edge://policy

Las organizaciones pueden permitir solo extensiones y componentes locales aprobados. Chrome admite las políticas ExtensionInstallAllowlist, NativeMessagingBlocklist y NativeMessagingAllowlist. Microsoft proporciona herramientas similares para Edge.

Si una extensión desconocida vuelve después de eliminarla, el navegador muestra instalación forzada, en NativeMessagingHosts apareció una entrada desconocida o el software de seguridad detectó un programa ajeno, no se limite a reinstalar la extensión. Desactive el complemento sospechoso, ejecute un análisis completo del sistema con el software de seguridad y compruebe los programas que pudieron registrar el componente local. Tras confirmar una infección cambie las contraseñas desde un dispositivo limpio y cierre las sesiones activas en servicios importantes, porque la extensión maliciosa pudo obtener cookies o datos introducidos en páginas.

Conclusión

Los permisos de una extensión de Chrome pueden ser muy amplios dentro del navegador. Un complemento puede leer páginas, historial, cookies y modificar el contenido de sitios si el usuario concedió los permisos necesarios. Pero trabajar arbitrariamente con archivos y comandos del sistema requiere un puente adicional hacia el sistema operativo. PEEP utiliza precisamente esa arquitectura y, además, se instala tras un compromiso inicial del equipo. Por eso al revisar una extensión sospechosa hay que mirar no solo la lista de complementos, sino también las políticas del navegador, los programas locales y los componentes Native Messaging registrados.

Compruebe la configuración del sistema, archivos y el registro solo en sus propios dispositivos o con permiso del propietario. No utilice los mecanismos descritos para acceder a datos o equipos ajenos. Esas acciones pueden violar la legislación de la Federación Rusa.

Esquemas similares están bastante extendidos. Según los datos del Banco de Rusia, en 2025 se abrían mensualmente decenas de miles de cuentas de droppers, y en los periodos pico la cifra alcanzó las 100 000. Al mismo tiempo, el volumen total de operaciones sospechosas en esas cuentas se redujo varias veces. Por ello, la cifra de 100 000 indica más bien la magnitud del problema que un nuevo aumento en el número de droppers.

Cómo funciona el fraude P2P y la transferencia por un tercero

El «triángulo» y los cálculos a través de un exchange cripto en la sombra son esquemas distintos. En el primero, el estafador engaña a una víctima concreta y usa al vendedor de la criptomoneda como receptor de su dinero. En el segundo, un intermediario ilegal empareja sistemáticamente los pagos de distintos clientes.

El Banco de Rusia alertó específicamente sobre los exchanges cripto ilegales que pueden conectar a compradores con vendedores vinculados al financiamiento del terrorismo u otra actividad delictiva. Ese esquema se diferencia del «triángulo» clásico, aunque en ambos casos la transferencia bancaria vincula a personas que no se conocen.

Si el dinero proviene de una persona que no participa en la operación P2P, o si una suma llegó desde varias tarjetas, conviene no transmitir la criptomoneda hasta verificar y resolver la situación a través de la plataforma.

Cómo vender criptomonedas de forma segura a través de P2P

Antes de la operación, verifique el perfil de la contraparte, el número de operaciones completadas, la antigüedad de la cuenta y los datos disponibles sobre la identidad. Una calificación alta reduce el riesgo, pero no excluye la posibilidad de que el perfil haya sido hackeado o que su propietario realice operaciones dudosas.

Antes de entregar la criptomoneda, compare los datos disponibles del comprador con el nombre del emisor en la aplicación bancaria. Una discrepancia evidente, frases como «la esposa pagará» o «un amigo enviará parte del importe», varios pagadores o la fragmentación del pago son motivos para detener la operación.

Procedimiento de verificación: abrir la operación → comprobar a la contraparte → esperar la transferencia → abrir la aplicación bancaria → verificar el abono real, el importe y el emisor → solo después de esto entregar la criptomoneda.

No confíe en capturas de pantalla, SMS o recibos del comprador. Verifique únicamente su propia cuenta. Si llegó solo parte del importe, el dinero proviene de un tercero o el comprador intenta llevar la conversación a un mensajero, abra una disputa dentro de la plataforma.

Guarde el número y la hora de la operación, el perfil de la contraparte, la conversación, el extracto bancario y los datos del emisor. Si la criptomoneda ya fue transferida, conserve la dirección del receptor y el identificador de la operación en la cadena de bloques.

Qué hacer si ya ha llegado una transferencia sospechosa

Si el dinero provino de otra persona o surgieron sospechas de fraude, no gaste la suma en disputa ni intente enviarla por su cuenta a nuevos datos.

• no libere la criptomoneda si la plataforma aún la retiene;
• abra una disputa en la plataforma P2P;
• guarde la conversación, el extracto y los datos de la operación;
• póngase en contacto con el banco a través de la aplicación o del número oficial;
• indique la fecha, el importe y la razón de sus sospechas;
• consulte con el banco el procedimiento para la devolución del dinero, si fuera necesario.

No envíe la devolución a la tarjeta que el comprador dejó en el chat. Incluso devolver al pagador original conviene acordarlo con el banco para no complicar la investigación.

Si la criptomoneda ya fue entregada, la posibilidad de impugnar la operación depende de las reglas de la plataforma. Por ejemplo, Bybit prohíbe pagos de terceros y en su ayuda indica la posibilidad de presentar una apelación sobre una operación completada dentro de cinco días naturales. Esta es una regla concreta de esa plataforma; puede cambiar y no se aplica automáticamente a otros servicios. La apelación tampoco garantiza la devolución de la criptomoneda ya entregada.

El banco puede verificar esos ingresos según las normas contra el blanqueo de capitales. Ante operaciones sospechosas, tiene derecho a solicitar una explicación del sentido económico de las transferencias y documentos sobre la fuente de los fondos.

De forma separada opera un mecanismo antifraude basado en la Ley Federal n.º 161-FZ. No debe mezclarse con el control financiero de las operaciones de droppers. La base del Banco de Rusia sobre operaciones fraudulentas se forma, entre otras fuentes, con información de bancos y del Ministerio del Interior sobre transferencias sin el consentimiento voluntario del cliente.

La plataforma «Antidrop» no forma parte, por ahora, de los mecanismos en vigor. El Banco de Rusia solo está creando un sistema único a través del cual los bancos podrán intercambiar información sobre droppers. La arquitectura de la plataforma ya está definida, pero el sistema aún no se ha lanzado. Según el pronóstico del Banco de Rusia, la plataforma debería entrar en funcionamiento hacia mediados de 2027. Por tanto, las transferencias P2P sospechosas se verifican hoy con los mecanismos bancarios y antifraude existentes, y no mediante «Antidrop».

Si el banco detecta indicios de una transferencia fraudulenta, puede suspender esa operación durante dos días. El Banco de Rusia denomina ese plazo periodo de enfriamiento. La suspensión de dos días de una transferencia concreta y las limitaciones por la presencia de datos del cliente en la base del Banco de Rusia son medidas distintas.

Si los datos sobre una persona o sus medios de pago ya figuran en la base del Banco de Rusia sobre operaciones fraudulentas, el banco puede suspender el uso de la tarjeta y la banca online; al recibir información del Ministerio del Interior está obligado a hacerlo. Las limitaciones se mantienen mientras la información permanezca en la base.

Si el banco no bloqueó la tarjeta, desde el 15 de mayo de 2025 existe otra medida: ese cliente no puede transferir a sí mismo ni a otras personas físicas a través de medios de pago electrónicos más de 100 000 rublos al mes. Para transferir una suma mayor será necesario acudir a la sucursal del banco con un documento de identidad. La restricción no se aplica al pago de bienes y servicios a personas jurídicas.

La inclusión errónea de datos se puede impugnar a través de su banco o directamente ante el Banco de Rusia. El regulador examina la solicitud de exclusión de datos de la base en un plazo de hasta 15 días hábiles. Ese plazo no está relacionado con la suspensión de dos días de una transferencia sospechosa concreta.

¿Se puede convertir uno en dropper tras una operación P2P habitual?

Recibir dinero de la víctima de una estafa no significa automáticamente que el vendedor sea reconocido como dropper o delincuente. Para una calificación penal importan las acciones de la persona, su papel, el ánimo de lucro y la naturaleza de las operaciones.

Desde el 5 de julio de 2025 entraron en vigor nuevas partes del artículo 187 del Código Penal de la Federación Rusa, introducidas por la Ley Federal n.º 176-FZ. Para el titular de la cuenta, la entrega de su tarjeta o el acceso a ella con ánimo de lucro para operaciones ilícitas, así como la realización de tales operaciones por indicación de otra persona, pueden conllevar hasta tres años de privación de libertad y una multa de hasta 300 000 rublos. Para delitos más graves, la pena máxima alcanza los seis años de prisión y una multa de 1 000 000 de rublos o la privación de ingresos por un periodo de hasta tres años.

Las nuevas disposiciones no se aplican a actos realizados antes del 5 de julio de 2025 si eso empeora la situación de la persona. Ese principio está consagrado en el artículo 10 del Código Penal de la Federación Rusa. La posible responsabilidad por hechos anteriores se determina según las normas vigentes en el momento del hecho.

El riesgo aumenta cuando una persona recibe regularmente transferencias de muchos desconocidos, cobra dinero en varias partes, lo reenvía según instrucciones ajenas, recibe una remuneración por las operaciones realizadas o facilita a otros el acceso a la tarjeta y la banca online. La fragmentación del pago por sí sola no demuestra que una persona sea un dropper, pero esa técnica se usa para transitar y encubrir dinero ajeno.

Conclusión

Una plataforma P2P puede controlar la entrega de la criptomoneda, pero no garantiza el origen legal de los rublos. Es más seguro aceptar un único pago de la propia contraparte, contrastar los datos del emisor y no liberar la criptomoneda ante discrepancias.

Si ya ha llegado una transferencia sospechosa, mantenga el dinero en la cuenta, registre las pruebas, abra una disputa y contacte con el banco. Ante restricciones, aclare la base concreta: la suspensión de dos días de la transferencia, las medidas derivadas de la base de operaciones fraudulentas y las comprobaciones de control financiero funcionan según reglas distintas.

El material tiene carácter informativo y no sustituye a una consulta jurídica. En operaciones con criptomonedas cumpla la legislación de la Federación Rusa, los requisitos del banco y las reglas de la plataforma. Si la transferencia está relacionada con un proceso penal, hay una solicitud de la policía o se discute una suma importante, es mejor consultar a un abogado y conservar todos los documentos de la operación.

Por eso, el acceso a las opciones de accesibilidad es especialmente valorado por los troyanos bancarios. El usuario abre voluntariamente al programa malicioso un mecanismo del sistema que Android creó para los lectores de pantalla, el control sin contacto y otras ayudas de accesibilidad. Un único acceso de este tipo no siempre basta para tomar el control total del teléfono, pero la aplicación obtiene capacidades que no tiene un programa con el conjunto habitual de permisos.

Si un reproductor de vídeo, una linterna, una app para ver documentos, un juego u otra aplicación pide activar «Accesibilidad» sin una razón clara, la solicitud debe considerarse un indicio serio de riesgo.

Qué obtiene la aplicación tras conceder Accessibility en Android

El nombre técnico del mecanismo en la API de Android es AccessibilityService. Google lo creó ante todo para aplicaciones que ayudan a personas con discapacidades a usar el dispositivo. El servicio funciona en segundo plano y recibe eventos cuando cambia la interfaz, por ejemplo cuando aparece una nueva ventana, cambia el foco o se pulsa un botón.

Decir que «Accessibility lee la pantalla» simplifica un poco lo que ocurre. En muchos casos el servicio recibe no una fotografía de la pantalla, sino un árbol estructurado de elementos de la interfaz. En él pueden aparecer textos, botones, campos de entrada, interruptores y otros objetos que la aplicación haya hecho accesibles al sistema. La clase AccessibilityNodeInfo permite no solo localizar esos elementos, sino también interactuar con ellos.

Tras conceder el acceso, el servicio de accesibilidad potencialmente puede:

• observar los cambios de la interfaz y determinar qué ventana o aplicación abrió el usuario;
• leer el texto disponible para el sistema, por ejemplo etiquetas de botones, nombres de campos, importes y mensajes en pantalla;
• encontrar elementos de la interfaz, incluidos botones como «Transferir», «Continuar» o campos de entrada;
• pulsar botones y realizar otras acciones sobre los elementos accesibles;
• introducir texto en campos, si la aplicación permite interactuar con ellos a través de Accessibility;
• desplazar páginas y listas sin intervención del usuario;
• enviar gestos táctiles a puntos específicos de la pantalla, si el servicio declaró esa capacidad;
• ejecutar acciones globales de Android, por ejemplo retroceder, abrir la pantalla principal o la lista de aplicaciones recientes;
• navegar entre ventanas y aplicaciones, organizando una secuencia de acciones casi como lo haría el propio usuario.

Por eso al malware no le hace falta conocer la estructura interna de la aplicación bancaria. A veces basta con detectar el lanzamiento del banco, encontrar los elementos necesarios de la interfaz y pulsarlos en secuencia.

Algunos servicios pueden además obtener una imagen de la pantalla. La interfaz correspondiente apareció en AccessibilityService a partir de Android 11. Sin embargo, no hay que entender «control total» de forma literal. Accessibility no otorga automáticamente acceso a todos los archivos, a la cámara, al micrófono, a SMS o a los datos de cada aplicación, y las ventanas protegidas pueden limitar las capturas y el trabajo con elementos sensibles.

Una protección adicional ofrece la propiedad accessibilityDataSensitive. El desarrollador puede marcar un elemento de la interfaz como sensible, tras lo cual Android limitará el acceso a ese elemento para los servicios que no sean herramientas de accesibilidad.

Para distinguir los servicios, Android usa, entre otras cosas, la propiedad ====code====

isAccessibilityTool

true

Por qué los troyanos bancarios usan la accesibilidad

Un programa Android normal no puede simplemente abrir la aplicación de un banco ajeno y empezar a pulsar botones dentro. Accessibility resuelve otra tarea y permite legítimamente que un servicio interactúe con la interfaz de otras aplicaciones. Los troyanos bancarios emplean este mecanismo para usos indebidos.

Un ataque típico comienza con ingeniería social. Se persuade a la persona para que descargue un APK desde un sitio de terceros, permita la instalación desde orígenes desconocidos y active «Accesibilidad». Después el troyano puede esperar a que se inicie la aplicación del banco → localizar el botón necesario → abrir el formulario de transferencia → rellenar los campos accesibles → pulsar «Continuar». Accessibility por sí solo no anula la biometría ni otros métodos independientes de confirmación, pero amplía notablemente las capacidades del malware.

El troyano también puede leer la interfaz accesible, interceptar códigos si Android los muestra en un elemento accesible, cerrar advertencias y mostrar ventanas falsas. El acceso separado a notificaciones, SMS y el permiso para mostrar ventanas sobre otras aplicaciones hace que ese esquema sea aún más peligroso.

Un buen ejemplo es StreamRat, que ThreatFabric describió en septiembre de 2026. El troyano se difundía haciéndose pasar por un servicio gratuito de televisión en streaming. La campaña publicitaria, entre el 11 de junio y el 3 de julio, alcanzó alrededor de 570 000 usuarios, sobre todo en España. El sitio explicaba paso a paso cómo instalar el APK y activar Accessibility, tras lo cual el operador podía vigilar la interfaz, mostrar formularios falsos y controlar remotamente el teléfono.

StreamRat empleó también una técnica inusual contra los sistemas de protección. El dropper creaba una conexión VPN ficticia, por la que se dirigía casi todo el tráfico del teléfono, excepto el del propio malware. Según la estimación de ThreatFabric, esa técnica podía impedir que las aplicaciones de seguridad se comunicaran con sistemas de verificación en la nube, reduciendo entre otras cosas la eficacia del análisis en la nube de Google Play Protect.

Un ejemplo en Rusia está relacionado con el troyano RedWing. El 12 de agosto de 2026 los especialistas de F6 informaron que el malware se difundía haciéndose pasar por la aplicación RadarTrevog para alertas sobre ataques de drones y peligro de misiles. Los autores del señuelo explotaron temores reales y convencieron a los usuarios de conceder todos los permisos solicitados.

F6 señaló que el acceso clave era Android Accessibility. RedWing también solicitaba SMS, notificaciones y permiso para mostrar ventanas sobre otras aplicaciones. El troyano podía interceptar códigos bancarios, recopilar datos, ayudar a secuestrar cuentas de mensajería y usar el teléfono infectado para ataques DDoS.

Android va cerrando gradualmente estos escenarios. Advanced Protection Mode apareció en Android 16, y en Android 17 la protección recibió una nueva restricción para Accessibility. El mecanismo apareció por primera vez en Android 17 Beta 2 en febrero de 2026 y luego se incluyó en la versión estable de Android 17, que se lanzó el 16 de junio.

Con Advanced Protection activado, el sistema no permite que aplicaciones comunes obtengan Accessibility Service y revoca el acceso ya concedido a servicios no adecuados. La separación está relacionada, entre otras cosas, con la propiedad ====code====

isAccessibilityTool

No se puede considerar la protección como infranqueable. Advanced Protection se activa de forma voluntaria, y el usuario puede desactivar Device protection y devolver las capacidades limitadas. Por eso los atacantes aún pueden intentar convencer a la víctima de que desactive la protección por sí misma.

Android 17 no prohibió el abuso de Accessibility de una vez por todas. El sistema añadió una barrera adicional para los usuarios con Advanced Protection activado, pero la ingeniería social sigue siendo el principal método para lograr que una persona abra voluntariamente un acceso peligroso al malware.

En qué se diferencia Accessibility de otros permisos de Android

Las opciones de accesibilidad pueden confundirse con permisos habituales de Android, el acceso a notificaciones, la visualización de ventanas sobre otras aplicaciones o los derechos de administrador del dispositivo. Las capacidades de estos mecanismos son distintas.

Device Admin pertenece al modelo antiguo de gestión de Android. Google empezó a retirar parte de esas funciones en Android 9, y con Android 10 limitó adicionalmente las políticas antiguas para las aplicaciones modernas. La gestión empresarial de Android ahora se apoya sobre todo en Android Enterprise, dispositivos completamente gestionados y perfiles de trabajo.

El permiso «Mostrar sobre otras aplicaciones» tampoco concede directamente a una app el derecho de pulsar botones dentro de la aplicación del banco. Permite colocar una ventana propia sobre la de otra aplicación. Accessibility, en cambio, puede interactuar con los elementos accesibles de la interfaz ajena. El malware suele solicitar ambos accesos, porque juntos ofrecen más posibilidades para controlar el dispositivo y engañar al usuario.

Un único interruptor sospechoso no prueba por sí mismo una infección. Mucho más preocupante es la combinación de señales. Por ejemplo, un APK desconocido que pide permitir la instalación desde fuentes externas, activar Accessibility, dar acceso a notificaciones, permitir ventanas sobre otras aplicaciones y designar el programa como administrador del dispositivo.

Cómo comprobar Accessibility en Android y desactivar una aplicación sospechosa

Los nombres de los apartados dependen del fabricante del teléfono y de la versión de Android. En dispositivos con una interfaz cercana a la estándar, la ruta habitual suele ser la siguiente.

Ajustes → Accesibilidad → Aplicaciones descargadas o Aplicaciones instaladas → servicio deseado → desactivar.

En Samsung, Xiaomi, Honor y dispositivos de otros fabricantes el menú puede llamarse de otra manera. Si el apartado no aparece en el lugar habitual, abra la búsqueda dentro de Ajustes y escriba «accesibilidad».

Revise todas las aplicaciones de terceros con acceso activo. La mera presencia de un programa en la lista no significa infección. Lectores de pantalla, herramientas de control para personas con limitaciones, algunas aplicaciones de automatización y otras apps legítimas usan efectivamente Accessibility.

Compruebe la finalidad de cada aplicación. La pregunta debe ser simple: ¿por qué necesita esta aplicación ver la interfaz de otras apps y actuar en mi nombre? Para un lector de pantalla la respuesta es evidente. Para un reproductor de vídeo, una linterna, un visor de documentos recibido por mensajería o una app enviada por un desconocido, normalmente no hay una razón clara.

Tras revisar Accessibility, compruebe otros accesos sensibles.

Ajustes → Aplicaciones → Acceso especial → Acceso a notificaciones → comprobar la lista.

Ajustes → Aplicaciones → Acceso especial → Mostrar sobre otras aplicaciones → comprobar la lista.

Ajustes → Aplicaciones → Acceso especial → Instalar aplicaciones desconocidas → desactivar las fuentes innecesarias.

Búsqueda en Ajustes → Administradores del dispositivo → comprobar las aplicaciones activas.

Si el dispositivo admite Advanced Protection, puede comprobar el modo desde los ajustes de seguridad.

Ajustes → Seguridad y privacidad → Otras opciones → Advanced Protection → Device protection.

Si sospecha de un troyano bancario, desconecte Wi‑Fi y la red móvil, luego intente revocar a la aplicación sospechosa los permisos de accesibilidad y los demás permisos sensibles. Después, elimine la propia aplicación. La red desconectada no cura la infección, pero dificulta que el malware reciba nuevas órdenes y transmita datos durante la limpieza.

A continuación, ejecute Google Play Protect e instale las actualizaciones de Android disponibles. Si la aplicación sospechosa pudo ver la app bancaria, las notificaciones, los SMS o las credenciales introducidas, cambie las contraseñas importantes desde otro dispositivo que se sepa limpio. Revise las operaciones en sus cuentas y, si procede, contacte inmediatamente con el banco.

Si el malware impide abrir los ajustes, coloca su propia ventana sobre la interfaz del sistema o no permite eliminarse, pruebe el modo seguro. El método de inicio depende del fabricante. Cuando no es posible determinar con seguridad qué cambios realizó el malware, es más seguro guardar los archivos personales necesarios y restablecer el teléfono a los valores de fábrica. No vuelva a instalar el APK sospechoso tras el restablecimiento.

isAccessibilityTool

Conclusión

El servicio de accesibilidad de Android no es una función peligrosa en sí misma. Sin un acceso amplio a la interfaz no podrían funcionar los lectores de pantalla y otras ayudas de accesibilidad necesarias. El riesgo surge cuando esas capacidades las obtiene una aplicación que no necesita controlar ventanas ajenas.

Android también cambia. Advanced Protection apareció en Android 16, y en Android 17 el sistema empezó a revocar automáticamente Accessibility a los servicios no adecuados cuando el modo de protección mejorada está activado. Sin embargo, ni un nuevo indicador, ni la verificación de Google Play, ni Advanced Protection anulan el principio fundamental: una aplicación sin una razón clara no debe recibir el derecho a ver la interfaz de otras aplicaciones y pulsar botones en lugar del propietario del teléfono.

El material está destinado a la protección de los propios dispositivos y al análisis de riesgos. Revise las aplicaciones y los dispositivos sobre los que tiene derecho a actuar, cumpla la legislación de la Federación de Rusia y no utilice los mecanismos descritos para el acceso no autorizado a datos o dispositivos ajenos.

El proyecto fue desarrollado por HotStart Labs. El código fuente está publicado en el repositorio bajo la licencia MIT y la verificación ya preparada se puede ejecutar en el sitio de GlassBox. El servicio resulta útil para usuarios que quieren entender por qué bloquear las cookies o cambiar la dirección IP no garantiza el anonimato en internet.

Qué es la huella digital del navegador y cómo funciona GlassBox

Un sitio web no necesita saber el nombre de la persona, la dirección de correo electrónico o el número de teléfono para distinguir a un visitante de otro. El navegador transmite multitud de características técnicas, entre ellas la versión del navegador, el tamaño de la pantalla, el idioma del sistema, la zona horaria, las capacidades de la tarjeta gráfica, las interfaces de programación disponibles, las fuentes y las particularidades del procesamiento de gráficos o sonido.

Cada parámetro individual suele darse en un gran número de personas. La combinación de decenas de rasgos se encuentra mucho menos a menudo. Un sitio puede guardar ese conjunto como huella digital y tratar de reconocer el mismo navegador en la siguiente visita, incluso si el usuario ha borrado algunos identificadores habituales.

GlassBox reproduce comprobaciones similares directamente en el navegador del usuario y muestra los valores obtenidos. En la descripción del proyecto el desarrollador indica aproximadamente unas 31 familias de métodos. La versión web actual divide los resultados en un mayor número de paneles individuales, por lo que la cantidad de pruebas visibles puede diferir del número de familias de comprobaciones en la documentación.

Las señales recogidas por GlassBox se agrupan en varios conjuntos. Unas están más relacionadas con el hardware, otras con la combinación del motor del navegador y el dispositivo, y otras caracterizan la versión del navegador o la sesión actual.

El porcentaje de unicidad en GlassBox no debe interpretarse como la probabilidad exacta de que un sitio identifique a una persona concreta. El desarrollador aclara expresamente que el indicador es una estimación modelada y no el resultado de una comparación con una base real de visitantes.

Qué datos del navegador comprueba GlassBox

GlassBox comprueba propiedades habituales del navegador y métodos más complejos para construir una huella digital. En particular, el servicio obtiene información sobre el motor del navegador, la pantalla, el idioma, la zona horaria y las preferencias regionales.

Algunas pruebas trabajan con Canvas. El navegador recibe la instrucción de dibujar una imagen y la herramienta analiza el resultado. En el resultado pueden influir la tarjeta gráfica, el controlador, el sistema operativo, el navegador y las particularidades del procesamiento gráfico. De forma similar funcionan las comprobaciones de WebGL, WebGL2 y WebGPU.

GlassBox también analiza el procesamiento de audio. El navegador crea o procesa una señal sonora, y pequeñas diferencias en los cálculos ayudan a obtener una señal adicional sobre el dispositivo. Precisamente el interés por estos métodos, según el desarrollador David Dale, fue una de las razones para crear el proyecto.

Entre los resultados se incluyen las fuentes disponibles, los formatos multimedia compatibles, las voces de síntesis, el conjunto de interfaces de programación del navegador y algunos cálculos matemáticos. GlassBox también analiza el almacenamiento del navegador, las resoluciones, la información de dispositivos multimedia, el soporte de distintas funciones CSS y otros parámetros del entorno.

Una comprobación independiente está relacionada con WebRTC. La tecnología se utiliza, por ejemplo, para videollamadas y la transmisión directa de multimedia entre navegadores. En algunas configuraciones WebRTC puede revelar información de red, por lo que esa prueba se usa a menudo para verificar la protección contra la fuga de direcciones IP.

GlassBox puede comparar los resultados guardados de distintas ejecuciones. El usuario puede copiar el informe de un navegador, abrir otro navegador y comprobar hasta qué punto coinciden las características del dispositivo. Ese experimento muestra de forma evidente por qué algunos rasgos pueden vincular sesiones incluso después de cambiar de navegador.

Cómo comprobar el navegador con GlassBox

Para una verificación habitual no es necesario instalar ningún programa ni extensión.

Abra GlassBox → espere a que terminen las pruebas → observe el indicador general de identificabilidad → expanda los paneles que le interesen → compruebe Canvas, WebGL, audio, WebRTC, fuentes, parámetros de red y otros rasgos.

El número atractivo en la parte superior de la página no debe convertirse en el resultado principal de la comprobación. Es más útil ver qué parámetros concretos el navegador revela sin permiso adicional y qué características se conservan tras reiniciar el navegador o cambiar de red.

Para el experimento se pueden realizar varias ejecuciones. Primero pruebe un navegador habitual, luego una ventana privada, otro navegador o Tor Browser. Después de cada ejecución puede comparar los resultados y ver qué características cambiaron y cuáles permanecieron igual.

Hay un matiz relacionado con la privacidad de la propia prueba. La mayoría de las comprobaciones se ejecuta localmente. Sin embargo, la versión actual de GlassBox, con la función de geolocalización activada, consulta servicios externos para obtener información sobre la dirección IP pública, la red y el uso supuesto de VPN. En la página del servicio ahora se enumeran ipwho.is, ipapi.is y geojs.io. El usuario que necesite una comprobación completamente local puede desactivar la función «Geo».

El desarrollador también advierte que la versión integrada en otra página puede obtener menos datos. El navegador puede bloquear WebRTC, sensores, dispositivos multimedia o permisos dentro de un elemento embebido. Para una comprobación completa es mejor abrir GlassBox como sitio independiente.

Cómo reducir la huella digital del navegador

Intentar cambiar manualmente cada parámetro no siempre aumenta la privacidad. Una configuración demasiado inusual puede producir el efecto contrario. Si la mayoría de usuarios comparten un conjunto de características y el navegador de una persona muestra una combinación rara de parámetros suplantados, distinguir ese navegador resulta más sencillo.

Por ello el desarrollador de GlassBox aconseja no buscar la configuración de protección más extraña posible, sino agruparse con un gran número de usuarios con la misma configuración. Recomendaciones detalladas están publicadas en la guía oficial.

Para casos que requieran un anonimato reforzado, uno de los enfoques más coherentes lo ofrece Tor Browser. Los desarrolladores de Tor procuran homogeneizar las características de los usuarios, limitan algunas vías de obtención de huellas digitales y aplican otros mecanismos de protección. Instalar muchos complementos por cuenta propia o cambiar los parámetros estándar de Tor Browser puede, por el contrario, hacer la configuración más rara.

Algunos medios de protección contra las huellas digitales existen también en otros navegadores. No obstante, bloquear Canvas, WebGL o interfaces individuales puede afectar al correcto funcionamiento de sitios. No existe un interruptor universal que oculte completamente el navegador y al mismo tiempo nunca rompa las páginas web.

Una VPN resuelve otra tarea. El servicio oculta la dirección IP pública del usuario frente al sitio visitado, pero no necesariamente cambia características como la pantalla, la tarjeta gráfica, Canvas, WebGL, fuentes o el motor del navegador. Por ello no puede considerarse una protección completa frente a las huellas digitales.

Una limitación similar se aplica a borrar las cookies. Limpiar las cookies elimina una forma de almacenar identificadores, pero las características técnicas del dispositivo pueden permanecer igual después de la limpieza.

Para comprobar el resultado de forma adicional puede usar proyectos independientes como EFF y AmIUnique. A diferencia del modelo completamente local de GlassBox, esos servicios pueden comparar la huella con datos de otros visitantes. Por eso los resultados de distintas herramientas no son directamente comparables como medidas idénticas.

Conclusión. GlassBox muestra claramente el principal problema de las huellas digitales del navegador. Un sitio no necesita un identificador único secreto si la combinación de decenas de características comunes ya permite distinguir navegadores entre sí. Es más útil considerar el servicio no como una medida exacta del porcentaje de anonimato, sino como una forma ilustrativa de ver los datos disponibles para un sitio y comprobar qué configuraciones realmente cambian la huella digital.

Use GlassBox y herramientas similares para comprobar sus propios dispositivos, navegadores y sistemas sobre los que tenga permiso para hacer pruebas. Al recopilar o procesar datos de otros usuarios cumpla la legislación de la Federación de Rusia, incluidas las exigencias aplicables sobre datos personales y el secreto de las comunicaciones.

La fecha de registro del dominio no equivale a la fecha de creación del sitio. La dirección pudo haberse registrado hace diez años y empezar a usarse solo ayer. También es posible otro escenario: el dominio antiguo fue eliminado del registro y luego lo registró un nuevo propietario. Por eso, si se necesita una verificación profunda, conviene comparar el registro de inscripción actual, el archivo web, el historial del dominio, los registros de certificados y los datos técnicos.

Si solo se necesita la antigüedad actual del dominio, empiece por RDAP o el WHOIS oficial. Si quiere saber desde cuándo realmente funcionó un sitio en esa dirección, una sola fecha de registro no es suficiente.

Qué se considera la antigüedad de un dominio

Por antigüedad de un dominio suele entenderse el tiempo transcurrido desde la fecha de inicio de su registración actual. En los datos de registro el valor relevante puede denominarse «Creation Date», «created» o aparecer como evento «registration» en RDAP.

Un mismo nombre de dominio puede tener, además, varias «antigüedades» diferentes:

• antigüedad de la registración actual;
• tiempo desde la registración más antigua conocida;
• tiempo desde la aparición del sitio en el dominio;
• tiempo desde el primer certificado SSL conocido;
• tiempo desde las primeras entradas DNS, enlaces o páginas encontradas.

Si las fechas difieren, el origen no está necesariamente equivocado. Cada fuente registra su propio evento.

Verificar la fecha de registro mediante RDAP o el WHOIS oficial

Para responder a la pregunta «cuándo se registró un dominio», acuda primero a los datos de registro actuales. Esa fuente está más cerca del registro y es más fiable que un sitio cualquiera que se presente como «comprobador de antigüedad de dominio».

Cómo comprobar un dominio internacional mediante RDAP

Para las zonas de dominio generales, como .COM, .ORG, .NET y muchas zonas nuevas, el protocolo principal ahora es RDAP. ICANN denomina a RDAP como reemplazo de WHOIS. Desde el 28 de enero de 2025 los registradores y los registros de zonas genéricas ya no están obligados a mantener el antiguo WHOIS, salvo excepciones concretas. La descripción actual del proceso de transición está publicada en el sitio de ICANN.

Al usuario común le resulta más fácil abrir ICANN Lookup → introducir el dominio sin «https://» ni la ruta de la página → abrir los datos de registro → buscar «Creation Date» o el evento «registration».

En la respuesta técnica RDAP la fecha de registro se guarda como un evento de tipo «registration». Otras fechas pueden describir la última modificación, la expiración de la registración u otros sucesos, por lo que no se debe tomar la primera fecha que aparezca.

Por qué en RDAP y WHOIS se oculta el nombre del propietario pero se ve la fecha de registro

Tras el endurecimiento de los requisitos de protección de datos personales, entre ellos la entrada en vigor del RGPD en 2018, muchos servicios de registro empezaron a ocultar el nombre, la dirección, el teléfono y el correo electrónico de las personas físicas. En las respuestas pueden aparecer «REDACTED», «Redacted for Privacy» o un formulario de contacto en lugar de una dirección directa.

Si los datos de contacto están ocultos, aun así se puede conocer la antigüedad del dominio. La vigente política de ICANN para las zonas genéricas exige publicar la «Creation Date». Por eso la fecha de registro suele seguir siendo accesible incluso cuando se ocultan los datos del propietario.

Cómo comprobar la antigüedad de un dominio .RU o .xn--p1ai

Para los dominios nacionales rusos utilice el WHOIS del Centro de Coordinación o el WHOIS del Centro Técnico de Internet.

Puede comprobar un dominio así: WHOIS → nombre de dominio → campo «created».

El Centro de Coordinación administra .RU y .xn--p1ai, y el Centro Técnico de Internet realiza las funciones técnicas del operador. El Centro de Coordinación indica explícitamente que los datos de su WHOIS para .RU y .xn--p1ai proceden del registro a través del CTI. La estructura del registro se describe en el sitio del Centro de Coordinación.

En la respuesta puede aparecer varios campos. «created» contiene la fecha de registro, «paid-till» muestra el plazo pagado, «free-date» se refiere a la posible liberación del dominio. Para determinar la antigüedad hace falta el campo «created».

REG.RU y RU-CENTER no son una verificación independiente del registro .RU

Los registradores rusos REG.RU y RU-CENTER también permiten comprobar rápidamente la fecha de registro. Sus interfaces resultan más cómodas que la respuesta técnica WHOIS, pero para .RU y .xn--p1ai no debe suponerse que REG.RU, RU-CENTER, el Centro de Coordinación y el CTI sean cuatro fuentes independientes de la misma fecha.

REG.RU, por ejemplo, muestra explícitamente el bloque «Información en el registro» y señala la fuente «TCI». Se trata precisamente de los datos de registro actuales que REG.RU presenta en su interfaz WHOIS. Por consiguiente, la coincidencia de la fecha de registración actual entre REG.RU y el Centro de Coordinación no confirma la información de forma independiente. Ambos interfaces pueden mostrar información procedente del mismo registro.

Para .RU y .xn--p1ai la fuente de la fecha de registración actual es una sola. El Centro de Coordinación, el CTI y los registradores pueden ofrecer distintas interfaces a los datos del registro. Si las interfaces muestran valores distintos, sospeche primero una demora en la actualización, caché o un error de visualización, y no dos versiones diferentes de la historia del dominio.

¿Pueden los servicios WHOIS de terceros mostrar datos antiguos?

Sí. Algunos agregadores guardan respuestas y no las actualizan en cada consulta. El servicio Who.is, por ejemplo, indica en su ayuda que cachea WHOIS y ofrece un botón «Refresh Data» para solicitar datos de nuevo.

Si un servicio externo muestra una fecha inesperada, compruebe la hora de la última actualización y repita la consulta mediante RDAP oficial, el registro o el registrador. Una diferencia de varios días en un agregador con caché suele indicar una copia almacenada y no un cambio en la fecha de registro.

Comprobar la historia del sitio mediante Wayback Machine

La fecha de registración responde a la pregunta sobre el nombre de dominio. Para evaluar la antigüedad del propio sitio es más útil usar la Wayback Machine del Internet Archive.

Procedimiento: Wayback Machine → nombre de dominio → el año más antiguo en el calendario → primera página guardada disponible.

Supongamos que WHOIS muestra 2012 y la captura más antigua del sitio aparece en 2018. La conclusión fiable queda limitada por dos hechos: el dominio se registró, en el marco de la registración actual, no más tarde de 2012, y Internet Archive guardó una página en 2018. No se puede afirmar que el sitio se lanzó precisamente en 2018.

Por qué la primera copia en Wayback Machine no equivale a la fecha de lanzamiento

El archivo no visita cada página inmediatamente tras su publicación. El sitio pudo haber funcionado meses o años antes de la primera captura. Parte de las páginas pudo ser inaccesible para el robot, requerir autenticación o simplemente no haber sido recorrida.

La situación con robots.txt es más compleja de lo que dicen a veces las instrucciones antiguas. Internet Archive ya declaró en 2017 que el archivo web dependería menos de robots.txt, porque una nueva versión del archivo podría cerrar por atrás la historia antigua de un sitio que ya no está vinculado al propietario actual. Más detalles están en el blog del Internet Archive.

Si una página no aparece en Wayback Machine no se puede explicar automáticamente por robots.txt. Los propietarios o titulares de derechos pueden solicitar restricciones a Internet Archive, algunos sitios bloquean técnicamente el archivado, y otras páginas nunca se guardaron. En 2026 Internet Archive describió por separado los casos en que los editores limitan el acceso a Wayback Machine en su centro de ayuda.

Wayback Machine muestra la huella más antigua encontrada de un sitio web, no la fecha oficial de su creación.

Consultar la historia del WHOIS y registros anteriores del dominio

El RDAP o WHOIS actual puede no contar lo que sucedió con un dominio antes. Si el dominio fue eliminado y luego registrado de nuevo, el registro actual puede referirse solo a la nueva registración.

Un ejemplo claro: la registración actual comenzó en 2024, Wayback Machine muestra un sitio de 2013 y la base histórica contiene WHOIS de 2012. La combinación de indicios sugiere que el dominio se utilizó antes y luego se registró de nuevo.

DomainTools

DomainTools Whois History guarda instantáneas históricas de WHOIS para un gran número de dominios. El servicio existe desde hace tiempo y ayuda a averiguar cómo cambiaron el registrador, los datos de contacto, los servidores de nombres y las fechas de registro. El acceso completo suele ser de pago.

Whoxy

Una alternativa más accesible ofrece Whoxy. El servicio mantiene su propia base de registros WHOIS antiguos y proporciona búsqueda web e interfaz programática. Whoxy advierte que devuelve historia desde su base local, no consultando al registrador en tiempo real.

Historial de WHOIS para .RU y .xn--p1ai

Aquí hay una limitación importante. El WHOIS público del CTI muestra el registro público actual, pero no proporciona un archivo oficial abierto con todos los estados pasados de un .RU o .xn--p1ai concreto. Por eso los datos históricos de dominios rusos suelen ser necesarios buscarlos en bases de empresas externas.

REG.RU, por ejemplo, coloca un enlace a un servicio separado «Historia Whois» junto al resultado actual, y en algunas secciones de la tienda de dominios muestra por separado la «Fecha de la primera registración» y la «Fecha de registración» actual. Es preciso distinguir dos productos. El WHOIS actual de REG.RU para .RU y .xn--p1ai puede mostrar datos del registro del CTI, mientras que «Historia Whois» es una base histórica independiente y no un archivo oficial del CTI. La información histórica resulta útil como fuente adicional, pero la base puede no cubrir todos los períodos.

Si no hay un registro antiguo en DomainTools, Whoxy u otro archivo, eso no demuestra que el dominio no existiera antes. El archivo pudo no conservar el período necesario.

Comprobar certificados SSL antiguos mediante Certificate Transparency

Otra fuente útil que a menudo se pasa por alto en artículos sobre la antigüedad de dominios son los registros públicos de Certificate Transparency, que registran la emisión de certificados TLS públicos. Los registros se actualizan constantemente y sus entradas se pueden consultar públicamente. El principio de funcionamiento está descrito en materiales de Google y en el sitio del proyecto Certificate Transparency.

Para la comprobación práctica suele utilizarse crt.sh. Introduzca el dominio y busque los certificados más antiguos en los que el nombre de dominio figura entre los nombres del certificado. crt.sh es una interfaz pública de búsqueda a los datos de Certificate Transparency, por lo que no conviene depender de su disponibilidad garantizada. El servicio puede responder despacio o no abrirse temporalmente. Si la consulta falla, inténtelo más tarde o use otra interfaz a los registros de Certificate Transparency.

Ejemplo: WHOIS muestra registración en 2010, Wayback Machine no guarda nada hasta 2017, y el registro de certificados contiene un certificado para el dominio de 2015. Se puede afirmar con seguridad que el dominio empleó TLS no más tarde de 2015.

Por qué un certificado no muestra la fecha exacta del sitio

Los sitios antiguos pudieron funcionar largos periodos solo por HTTP y no tener un certificado TLS público. El certificado también pudo emitirse antes del lanzamiento completo del sitio. Además, un certificado puede cubrir varios nombres a la vez o usar nombres comodín.

Por eso Certificate Transparency confirma actividad técnica del dominio en una fecha concreta, pero no sustituye la registración.

Para un dominio sin capturas antiguas en Wayback Machine, los registros de certificados a veces ofrecen la mejor huella independiente del uso real de la dirección.

Comprobar el historial de DNS, enlaces y datos de servicios de búsqueda

Cuando WHOIS, el archivo web y los certificados no dan una imagen completa, ayudan huellas técnicas indirectas. Entre ellas están registros DNS antiguos, las fechas en que los servicios detectaron enlaces por primera vez y los datos de rastreadores de buscadores.

Historial DNS y servidores de nombres

El WHOIS actual puede contener servidores de nombres y el estado «DELEGATED». Ese estado indica que el dominio está delegado ahora, pero no muestra la fecha del primer delegado.

Un dominio pudo registrarse en 2015 y no configurar servidores de nombres durante varios años. Por eso «created: 2015» no prueba que desde 2015 haya funcionado un sitio en esa dirección.

Para estudiar A, AAAA, MX, NS, SOA y TXT antiguos se usan bases de DNS históricas. Por ejemplo, SecurityTrails ofrece historial DNS por nombre de host y tipo de registro. Esas bases se usan sobre todo en análisis profundos; algunas funciones son de pago.

Si la primera NS o A encontrada aparece varios años después del registro, se puede suponer que el dominio empezó a usarse más tarde. Aun así, no conviene basar la fecha de lanzamiento únicamente en DNS.

Semrush y otros servicios de analítica de búsqueda

Los servicios de analítica de búsqueda no sustituyen a WHOIS, pero pueden mostrar su propia historia del sitio. En el informe de enlaces entrantes de Semrush, por ejemplo, existe el campo «First Seen». Ese campo indica la fecha en que el rastreador de Semrush detectó por primera vez un enlace concreto.

Si un servicio detectó enlaces al dominio hace diez años, el sitio o al menos la dirección ya se empleaban entonces. Sin embargo, «First Seen» es la fecha en que ese servicio concreto descubrió el enlace, no la fecha de registración o publicación.

Ahrefs aplica un principio similar a la historia de páginas. En la documentación de Content Explorer la compañía indica que al estimar la fecha de publicación tiene en cuenta cuándo su rastreador vio por primera vez la dirección, el marcado de la página y datos de Archive.org. Esa métrica resulta útil para investigar la historia de contenido, pero no debe llamarse antigüedad del dominio.

¿Se puede conocer la primera indexación mediante Google Search Console?

Para un sitio propio Google Search Console ofrece información adicional. La herramienta de inspección de URLs muestra si Google conoce una página concreta, su estado en el índice y datos de rastreo.

Search Console no debe usarse como un «contador universal» de la antigüedad del dominio. El acceso a información detallada requiere derechos verificados sobre el recurso, y las fechas mostradas se refieren al trabajo de Google con páginas concretas y no constituyen la fecha oficial de registración del dominio. Para un sitio ajeno el método resulta prácticamente inútil.

Qué método elegir para comprobar la antigüedad del dominio

Por qué los servicios muestran antigüedades distintas

Con frecuencia las fechas difieren porque un mismo nombre tuvo varios periodos de vida. Un sitio antiguo pudo existir en 2010, luego la registración dejó de existir, el dominio quedó libre y un nuevo propietario registró la dirección en 2024.

Entonces los datos de registración actuales muestran 2024, Wayback Machine conserva páginas de 2010 y una base histórica puede contener ambas épocas. No hay contradicción: las fuentes describen distintos periodos.

El servicio muestra la fecha de modificación

«Updated Date» y el evento «last changed» se refieren a cambios en el registro de registración. Esos campos no muestran la antigüedad del dominio. La misma regla aplica a la fecha de transferencia entre registradores.

Confunden registración con el fin del periodo pagado

«Expiration Date», «paid-till» y valores similares se refieren al periodo futuro de registración. Para determinar la antigüedad de la registración actual hacen falta «Creation Date», «created» o el evento RDAP «registration».

El servicio externo muestra caché

El agregador puede mantener una respuesta local varios días o más. Compruebe la etiqueta «Last fetched», «Updated» o marca similar. Si hay un botón de actualización, solicite un registro nuevo y compare el resultado con la fuente autorizada.

Las fuentes registran eventos distintos

Registración, delegación DNS, emisión de certificado, publicación del sitio, archivado web y detección de un enlace por un rastreador pueden ocurrir en años distintos. Por eso buscar una única «fecha correcta» para todas las tareas es equivocado.

Fecha de registración del dominio y fecha de creación del sitio: cuál es la diferencia

El registrador registra el nombre de dominio, no el sitio web. Tras la registración el propietario puede no publicar nada. Un dominio puede mostrar durante años una página de estacionamiento, redirigir visitantes o directamente no estar delegado.

Ejemplo: el dominio se registró el 1 de marzo de 2018, las primeras entradas DNS aparecieron en 2021, el certificado se emitió en 2022 y la primera captura en Wayback Machine data de 2023. Con los datos disponibles no se puede afirmar que el sitio funcione desde 2018. Es más correcto decir que el dominio está registrado desde 2018 y que las huellas técnicas confirmadas aparecieron más tarde.

Cómo comprobar un sitio sospechoso mediante la antigüedad del dominio

La antigüedad del dominio es útil al evaluar un enlace desconocido, pero no constituye en sí una prueba de fraude. Un dominio antiguo puede ser pirateado o comprado tras cambio de propietario, y un dominio nuevo puede pertenecer a una empresa legítima.

La comprobación práctica es así: copie el dominio sin la ruta → compruebe la fecha de registración mediante RDAP oficial o WHOIS → compare la dirección con el dominio indicado en el sitio oficial de la organización → revise la historia en Wayback Machine → si es necesario, verifique certificados en crt.sh → no introduzca contraseñas, datos bancarios ni códigos si el sitio se hace pasar por una organización conocida pero el dominio es reciente y su historia no coincide con la versión oficial.

Para un banco, un mercado o una entidad pública conviene buscar la dirección oficial no vía un anuncio ni un enlace en un mensaje. Abra la aplicación oficial instalada previamente, una marca guardada o el directorio oficial de la organización y compare el nombre de dominio carácter por carácter.

La registración reciente aumenta la sospecha si el sitio copia una marca conocida, exige un pago urgente o pide contraseñas. Un dominio joven por sí solo no demuestra fraude.

¿Se puede determinar la fecha exacta de creación del sitio?

Para un sitio ajeno, por lo general no. No existe un registro público único de lanzamientos de sitios web.

La evaluación más fiable procede de varias huellas independientes. Primero localice la fecha de registración. Luego compruebe la primera copia en Wayback Machine, certificados antiguos, registros WHOIS históricos y DNS. Si hay historia de enlaces o páginas en servicios de analítica de búsqueda, utilícela como confirmación adicional.

La frase «el dominio se registró en 2014» es más precisa que «el sitio funciona desde 2014» si la única fuente disponible es WHOIS.

Algoritmo rápido de comprobación

Para .COM, .ORG, .NET y otras zonas genéricas: ICANN Lookup → «Creation Date» → Wayback Machine → ante discrepancias historia WHOIS → crt.sh.

Para .RU y .xn--p1ai: WHOIS del Centro de Coordinación o del CTI → «created» → Wayback Machine → si hace falta, historia WHOIS externa → crt.sh y historial DNS.

REG.RU o RU-CENTER pueden usarse en lugar de la interfaz técnica si resultan más cómodos para leer los datos, pero no convierten un registro único en varias fuentes independientes.

Conclusión

Para comprobar con precisión la antigüedad de la registración actual, empiece por los datos de registro oficiales. Los dominios genéricos revise mediante RDAP e ICANN Lookup; .RU y .xn--p1ai mediante el WHOIS del Centro de Coordinación o del CTI. REG.RU y RU-CENTER resultan cómodos para leer la misma información, pero no convierten un registro único en varias fuentes independientes.

Si necesita entender la historia real del sitio, añada Wayback Machine, archivos WHOIS, registros de Certificate Transparency y el historial DNS. Las fechas de primera detección de enlaces en Semrush, de páginas en Ahrefs y los datos de Search Console también pueden ayudar, pero siguen siendo indicios indirectos.

Las fechas suelen diferir porque las fuentes registran eventos distintos. La registración del dominio, la delegación DNS, la emisión del certificado, el lanzamiento del sitio y el primer archivado pueden ocurrir en años diferentes.

Utilice solo información de acceso público, cumpla la legislación de la Federación de Rusia y las normas de los servicios elegidos. No intente obtener datos personales cerrados del administrador del dominio ni eludir restricciones de acceso. Al evaluar un sitio sospechoso tenga en cuenta el conjunto de indicios, no solo la antigüedad del dominio.