Cómo me robaron la cuenta de Telegram con un enlace falso de reunión

Me robaron la cuenta de Telegram con un enlace falso de videollamada: en la dirección habían cambiado dos letras, en lugar de microsoft teams decía miclosoft teams. Un proceso se instaló en el sistema en una fracción de segundo, estuvo allí unos diez días y esperó a que yo introdujera un código de verificación en dos pasos. Ningún antivirus lo detectó. Recuperé la cuenta, desmonté el esquema y aquí está completo.

Cómo funciona el esquema

La llamada la agendé yo mismo, con un socio al que, como se supo después, le habían robado la cuenta exactamente igual. Los atacantes clonan su página de reservas, tú entras por la dirección habitual y no compruebas nada, porque la iniciativa fue tuya.

Ya en la reunión, a la otra parte “no le funciona la cámara”. Te piden que arregles un controlador: abre una página, descarga un archivo, pega un comando en la terminal. Ahí es donde ocurre todo.

Por qué funcionó conmigo

Tres detalles construyen la confianza, y los tres están falsificados.

Primero, la reunión la convoqué yo. El cerebro no revisa un enlace que has abierto tú mismo. La desconfianza se activa con los enlaces que llegan de fuera, no con los propios.

Segundo, en la llamada había vídeo de una persona conocida. Lo habían grabado cuando lo estaban hackeando a él. Ves la cara de tu socio y dejas de dudar.

Tercero, la petición suena técnica y pequeña. No es “manda dinero”, es “ayúdame, se me ha caído la cámara”. Es una petición de ayuda, y negarse resulta incómodo.

Lo que el antivirus no vio

La aplicación de phishing la detectó el segundo antivirus al instante. El proceso implantado, en cambio, fue invisible para todos los programas. Lo encontró la herramienta con agente que uso en la terminal para trabajar: recorrió el sistema, listó tres procesos, resolvió las direcciones a las que llamaban, los aisló y los eliminó. Con esos mismos datos preparé la denuncia a la policía en español.

No afirmo que a todo el mundo le vaya a pasar así, es un caso, el mío. Pero la conclusión es simple: ante una sospecha, el escáner no sustituye la revisión del sistema, se ejecuta junto a ella.

Señales de alarma durante una llamada

La reacción correcta es idéntica en los cuatro casos: salir y reprogramar. Un interlocutor legítimo no se ofende por eso.

Qué hacer antes de la reunión

Manda tú el enlace, desde tu propia página de reservas. Así no hay nada que verificar.

Si el enlace te lo mandan a ti, pégalo en un chat con un modelo de lenguaje y pregunta si es seguro. El ojo no detecta dos letras cambiadas en un dominio, el modelo compara la cadena carácter por carácter.

Activa la verificación en dos pasos en todas partes, y siempre que puedas por canales independientes: una aplicación generadora de códigos más la huella o la cara, y no un mismo buzón de correo protegiéndolo todo.

El prompt con el que reviso mi equipo

Esta revisión la paso una vez por semana. El prompt está en inglés a propósito: los modelos trabajan con más precisión así, y no tiene sentido traducirlo en cada sesión. Está escrito para macOS; para Windows, pide al modelo que lo reescriba para tu sistema.

Copia el texto entero y dáselo a un agente con acceso a la terminal (Claude Code, Codex).

You are a security auditor doing a threat hunt on this macOS machine. Assume nothing:
this machine MAY BE COMPLETELY CLEAN, and "no threat found" is a valid, expected result.
Do not invent a problem to justify action. Your job is to (1) surface anything suspicious
or anomalous, (2) explain each finding so I understand it, and (3) be ready to neutralise
ONLY if something real is confirmed and ONLY after I approve.

GROUND RULES
- The whole hunt is READ-ONLY. Do not delete, kill, move, or modify anything.
- Distinguish clearly between "normal", "needs a human glance", and "actually malicious".
  Most machines have lots of the first two. Do not raise alarms on legitimate software.
- Hunt by behaviour and anomaly, not a fixed list. Treat as worth checking:
  code running from user-writable paths (~/Library, /tmp, /var/folders, /Users/Shared),
  unsigned / adhoc / non-notarized binaries that have persistence or network access,
  LaunchAgents whose label impersonates a trusted brand (com.apple.* over a third-party
  name like 1Password/Google/CleanMyMac), persistence that launches an interpreter
  (bash/python/osascript) with -c / base64 / curl / eval, established connections to raw
  public IPs with no reverse DNS on odd ports by non-browser processes, several artifacts
  created in the same minute, and recently cleared shell history.

PHASE 1 - COLLECT (read-only). Report what you see at each step, good or empty.
1. Shell history (~/.zsh_history, ~/.bash_history): curl|wget piped to a shell, chmod +x
   in temp, nohup, tput reset, base64 -d | sh, osascript -e, suspicious TLDs
   (.online/.xyz/.top/.shop), any download-and-run one-liners.
2. Persistence: ~/Library/LaunchAgents, /Library/LaunchAgents, /Library/LaunchDaemons.
   Print Label + ProgramArguments + RunAtLoad/KeepAlive + mtime. Flag brand-impersonating
   labels, interpreter launches, and binaries living in user-writable paths.
3. ~/Library/Application Support: flag any com.apple.* folder that contains a Mach-O binary.
4. Processes running from /tmp, /var/folders, /Users/Shared, or fake Application Support
   paths (ps + executable path). Note that AppTranslocation is often a legit quarantined app.
5. Live network: lsof -nP -iTCP -sTCP:ESTABLISHED. Flag established connections to raw public
   IPs (no rDNS) on unusual ports by non-browser processes. Ignore LAN/private/loopback IPs.
6. Other vectors: login/logout hooks (com.apple.loginwindow), cron / at / periodic / emond,
   configuration profiles (profiles list), system/kernel extensions, DYLD_INSERT_LIBRARIES
   in shell env files and launchd EnvironmentVariables, /etc/hosts redirects of sensitive
   domains, proxy (scutil --proxy), DNS overrides, ~/.ssh/authorized_keys, new admin users
   (dscl . -read /Groups/admin), sudoers / sudoers.d, injected lines in shell rc files, GUI
   login items, browser extensions (especially crypto wallets and broad-permission ones).

PHASE 2 - VERIFY each non-obvious item.
- codesign -dv --verbose=4 <path> and spctl --assess --type execute -v <path>.
- shasum -a 256 <path> for any suspect binary (record the hash).
- Trace the parent process and what the binary connects to.
- Give each item a verdict: legitimate / needs-review / malicious, with your reasoning.
- One known campaign to also check for (an EXAMPLE, do not limit to it; absence means nothing):
  domain webcamsdk-update.online ; C2 172.86.126.215 ; files teamsSDK.sh / teamsSDK.bin ;
  fake LaunchAgents com.apple.1Password / com.apple.CleanMyMac / com.apple.Google.

PHASE 3 - REPORT (always). Give a clear overall verdict:
  CLEAN          - nothing malicious found (list the few review items as a sanity check),
  NEEDS REVIEW   - ambiguous items I should confirm, none clearly malicious yet,
  COMPROMISED    - confirmed malicious persistence/process/connection (list evidence).
Be honest. If it is clean, say so plainly and stop. Do not proceed to Phase 4.

PHASE 4 - PREPARE CONTAINMENT (only if Phase 3 = COMPROMISED, and only after I approve
each item). Do not act unprompted.

- First write all evidence to a file: plist contents, hashes, paths, C2 IPs, process list.
- Then propose exact, reversible steps: quarantine (move, NOT delete) to
  ~/quarantine_malware_<date>/, unload the LaunchAgents/Daemons (launchctl bootout), kill
  the live process. Show me the commands and wait for my go-ahead before running them.
- After I approve and you run them, re-check: confirm no malware process and no C2 connection.

PHASE 5 - ADVISE (always, scaled to what you found).
- If COMPROMISED: list every credential/secret to rotate from a CLEAN device (password
  manager, browser passwords, crypto wallets/seeds, .env API keys, SSH keys, email,
  exchanges), tell me to check the mailbox for attacker forwarding rules, and state plainly
  that after an interactive backdoor the only certain cleanup is a full macOS reinstall.
- If CLEAN or NEEDS REVIEW: give short hardening tips (hardware/app 2FA not SMS, do not run
  commands sent during calls, keep seeds off the work machine) and what to glance at manually
  (System Settings > Privacy > Accessibility / Input Monitoring / Screen Recording, which a
  keylogger would need and which this hunt cannot fully read without Full Disk Access).

Start with Phase 1 now and report findings as you go. Remember: finding nothing is a good
and valid outcome. Do not delete or change anything without my explicit approval.

Tres cosas de este prompt importan más que el resto.

Toda la revisión es de solo lectura. Un agente que borra lo que encuentra se lleva con ello las pruebas, y a veces partes del sistema que funcionaban. Solo propone contención después de tu aprobación, y pone en cuarentena en lugar de borrar.

“No he encontrado nada” es un resultado válido. Se dice en el primer párrafo y se repite al final. Sin eso, el modelo casi siempre “encuentra” algo con tal de no devolver una respuesta vacía.

Caza por comportamiento, no por una lista fija. La campaña concreta con el dominio webcamsdk-update.online y los agentes de arranque que suplantan marcas aparece como ejemplo, no como lista completa: su ausencia no demuestra nada.

Qué hacer si ya ha pasado

El orden es este. Primero, lanzar un análisis del sistema. En paralelo, revisar los procesos en ejecución y las conexiones de red, porque ahí se esconde justo lo que el escáner no ve. Después, cambiar todas las contraseñas, no solo la de la cuenta robada. Con una intrusión confirmada, lo más seguro es reinstalar el sistema entero: no hay garantía de haberlo limpiado todo.

Y aparte. Tras el robo, lo que reciben tus amigos desde tu cuenta no es una extorsión. Reciben conversaciones de trabajo normales, entrenadas con tu propio historial de mensajes, y después una propuesta de llamada. El objetivo no es tu dinero, son las siguientes cuentas. El esquema se reproduce como un virus, y por eso hay que avisar a tu círculo en la primera hora.

Qué salvó el perímetro de trabajo

A la infraestructura corporativa no llegaron, y el motivo es aburrido: verificación en dos y tres pasos desde dispositivos distintos, todo el perímetro detrás de una VPN, accesos separados por rol. En la mayoría de la gente el perímetro personal es más débil que el de trabajo, y es justo el personal el que atacan, porque es el camino fácil hacia todo lo demás.

Si solo te quedas con una cosa

Que te pidan pegar algo en una terminal o descargar algo durante una videollamada no es un fallo técnico. Es el ataque. En ese momento la reunión se termina, no continúa.