Caso de phishing por $130 mil: llamadas y correos que se hicieron pasar por Google, con sincronización de códigos de autenticación

• Un usuario compartió su experiencia tras ser víctima de phishing mediante una llamada que se hizo pasar por el equipo de soporte de Google y un correo que aparentaba venir de [e-mail]
• Debido a la función de sincronización en la nube de Google Authenticator, el atacante también robó los códigos de autenticación de dos factores, hackeó la cuenta de Coinbase y robó criptomonedas
• En apenas 40 minutos, sufrió el robo de criptomonedas por un valor aproximado de 80 mil dólares (hoy, cerca de 130 mil dólares)
• Se señala que una debilidad de seguridad en Gmail y la configuración predeterminada de sincronización en Authenticator agravaron el daño
• Se aconseja seguir prácticas básicas de seguridad, como cambiar las contraseñas periódicamente y no compartir nunca los códigos de verificación, además de configurar con cautela la sincronización en la nube

---

Una estafa que empezó con una sola llamada

• El 19 de junio, recibió una llamada desde el código de área (650) de 'Pacifica, CA'
• La otra parte afirmó pertenecer al equipo de soporte de Google y mencionó una supuesta solicitud reportada de transferencia de cuenta (incluso con acta de defunción e identificación adjuntas)
• También enviaron un correo desde una dirección aparentemente real, [e-mail] (a nombre de Norman Zhu), lo que hizo que pareciera un correo oficial y generó confianza
• En la app de Gmail para iOS, aparecía como enviado desde @google.com, con branding y número de caso, disfrazado de forma muy convincente
• Con el pretexto de verificar si la persona estaba viva, solicitaron confirmar un código temporal de autenticación, y en un momento de ansiedad la víctima lo entregó

Acceso del atacante a la cuenta de Coinbase

• Al final de la llamada, dieron indicaciones como registrarse en Google Advanced Security para tranquilizar a la víctima
• La víctima pensó que había reforzado su seguridad, pero el atacante ya había obtenido acceso a Gmail, Drive, Photos y los códigos sincronizados de Authenticator
• Lo decisivo fue que, mediante la sincronización en la nube de Google Authenticator, también pudieron robar los códigos 2FA
• Poco después, el atacante inició sesión en Coinbase y comenzó el robo de criptomonedas

Detalles del robo de criptomonedas y del daño

• Durante unos 40 minutos, el atacante realizó varias transacciones para dispersar ETH y otros tokens y luego robar el total
• La pérdida fue de aproximadamente 80 mil dólares en ese momento, y cerca de 130 mil dólares a valor actual
• Dos horas después, al revisar el saldo de Coinbase, la víctima quedó impactada al ver que el balance estaba casi en cero
• También confirmó en la cuenta de Google inicios de sesión desde un nuevo dispositivo y cambios en el número de teléfono de recuperación

Por qué incluso un experto en seguridad pudo caer

• La víctima explicó que trabaja en la industria de TI y que incluso ha diseñado experiencias de autenticación
• Aunque tenía una alta conciencia sobre seguridad, falló al responder al phishing debido al correo falsificado y a la escenificación de una situación urgente

Los 2 errores clave de seguridad de Google

1. Fallo al filtrar correos con remitente falsificado ‘@google.com’
   • Fue posible falsificar el campo From del correo para que pareciera oficial, y en la app de Gmail para iOS no era posible revisar el encabezado completo, lo que dificultó verificarlo de inmediato
2. Activación predeterminada de la sincronización en la nube en Google Authenticator
   • El atacante obtuvo los códigos 2FA sincronizados, anulando en la práctica la efectividad de la autenticación en dos pasos
   • El resultado fue la exposición total de activos digitales como correo, 2FA, documentos y fotos, todo de una vez

• Referencia: advertencia de que para quienes usan Gmail y Google Authenticator juntos, el 2FA podría no ser intrínsecamente seguro

Reglas y consejos de seguridad

• Cambiar la contraseña hoy mismo y renovarla periódicamente (siguen ocurriendo filtraciones de más de 1.6 mil millones de contraseñas)

• Nunca compartir códigos de verificación (los atacantes manipulan psicológicamente con ‘urgencia’ y ‘miedo’)

• Usar con cautela la sincronización en la nube de Google Authenticator

  • Aumenta la facilidad de recuperación, pero también implica riesgos de gestión

• Mantener siempre la guardia ante llamadas sospechosas

  • Si hay inquietud, se recomienda colgar de inmediato y volver a contactar por canales oficiales

• Se espera que este caso sirva para generar conciencia y prevenir daños similares

Explicación adicional y contexto

• Existe la posibilidad de que el atacante ya tuviera la contraseña a partir de una lista reciente de 1.6 mil millones de contraseñas filtradas
• La propia víctima afirmó que no reutilizaba la misma contraseña y la mantenía en secreto, pero llevaba mucho tiempo sin cambiarla
• Se estima que el atacante logró saltarse la verificación 2FA al recibir el código de recuperación

Sobre el correo de phishing

• Se recibieron varios correos a nombre de [e-mail], pero el atacante eliminó por completo todos los rastros, incluida la papelera y el historial de recuperación
• Aun así, al reenviar algunos correos a [e-mail], se logró conservar el original mediante un correo rebotado durante el proceso de recuperación del control de la cuenta
• La dirección [e-mail] en realidad no existe o no es accesible desde el exterior
• El correo original tenía el asunto ‘Google Recent Case Status’ y estaba compuesto con formato y naming oficiales, instrucciones sobre revisión interna y almacenamiento temporal de contraseña
• Incluía el nombre del supuesto equipo de soporte, ‘Norman Zhu’, así como número de caso e información del departamento

Resumen general

• Se trata de un caso de robo masivo de cuenta y de criptomonedas provocado por la combinación de un ataque de suplantación altamente elaborado y fallas estructurales de la plataforma
• Es un caso que recuerda que ni siquiera la autenticación de dos factores es una zona segura absoluta
• Más allá de las nociones tradicionales de seguridad, subraya la necesidad de revisar políticas a nivel de plataforma y aplicar configuraciones de seguridad diferenciadas por servicio

[GN⁺]

Opiniones de Hacker News

• El viernes pasado también recibí una llamada parecida; sonaba legítima. Mi truco útil es pedir un número de ticket y un número oficial para devolver la llamada, y verificar que realmente sea el de la empresa. Si lo es, se puede seguir con la conversación; si no, uno se queda tranquilo. La persona que llamó dijo que podía enviar un correo “para demostrar que era oficial”, pero como no quiso darme un número para devolver la llamada, supe de inmediato que era una estafa. Tanto las direcciones de correo como los números de teléfono se pueden falsificar fácilmente. Aunque el número entrante parezca normal, nunca hay que confiar en él; siempre hay que volver a llamar al número oficial para comprobarlo.

  • Yo ni siquiera acepto un número de teléfono directamente. Siempre le pregunto a la persona el nombre de la empresa y la sucursal, y luego busco yo mismo el número en el sitio web oficial de la empresa (por ejemplo, https://amazon.com) y llamo. Es un poco más incómodo, pero es una seguridad mucho más fuerte.

  • También hay que tener cuidado al verificar el “número oficial” buscando en internet. Puede haber números falsos mezclados en los resultados, en sitios que parecen legítimos. De verdad, esto es una guerra sin armas.

  • Sobre eso de que “aunque sea un número legítimo, el caller ID no sirve de nada”, yo mismo se lo dije a mi banco hace unos años cuando me llamaron y me pidieron información personal para verificar mi identidad.

  • El “número oficial” suena como buena idea, pero si el atacante tiene acceso a SS7, ese método no sirve de mucho.

• Son cosas que hay que recordar una y otra vez:

  • Los equipos de soporte al cliente de las grandes empresas nunca llaman directamente.

  • Si alguien te pide un código por teléfono o por correo, jamás le digas un código de verificación que te llegó por SMS; el propio mensaje normalmente lo dice.

  • No protejas información personal importante con una sola contraseña. No uses Google Authenticator vinculado a tu cuenta de Google como gestor de contraseñas; mejor usar un tercero como 1Password.

  • Separa sí o sí el correo que usas para banco e inversiones del correo que ya conoce todo el mundo. También separa los perfiles de Chrome por correo y deja solo el gestor de contraseñas como extensión.

  • Pero hace unas semanas me llamó alguien diciendo que era del soporte de mi banco desde un número que no aparecía en búsquedas. Me pidieron que leyera un código de verificación que llegó por SMS, me negué, y entonces bloquearon mi banca en línea. Después me llegó por correo postal una carta bastante fuerte diciendo que, como no me había comunicado con el agente de soporte, no podían actualizar automáticamente la cuenta. Al final creé una cuenta nueva en la app y los llamé; les volví a leer el código del SMS (!), y ese fue literalmente el único paso de verificación para activar la nueva cuenta. Es uno de los 100 bancos más grandes del mundo. Las empresas prácticamente te entrenan para caer en estafas. Era un banco alemán, pero Chase tiene exactamente la misma costumbre de pedir códigos OTP por teléfono.

  • Una vez, al pedir que desactivaran una configuración de ahorro de energía del Google Nest Thermostat, soporte me pidió un código de verificación (esa función permite que la compañía eléctrica controle la temperatura para ahorrar energía). Me negué diciendo “el mensaje dice que no debo compartirlo”, y soporte simplemente me dio otra opción. La petición era rarísima.

  • Hasta hace poco Chase también pedía esos códigos cuando te llamaban por una alerta de fraude. Es una parte realmente desesperante.

  • Yo dejo mi celular siempre en “No molestar”. Solo permito que suenen 5 familiares directos. Nunca contesto números desconocidos y, si de verdad es urgente, que dejen un buzón de voz. Creo que cuando uno contesta una llamada no siempre puede pensar con la cabeza fría en el momento. Es parecido al truco de preguntarte una dirección en la calle y robarte el reloj. No era por seguridad principalmente, pero me gusta porque me evita las propinas del banco y la exposición a hackers.

  • Por desgracia, algunos call centers sí tienen la práctica de mandarte un código por SMS/correo cuando tú llamas para verificarte, y luego hacen que se los leas.

• Este ataque parece haber sido simple ingeniería social, y no parece que hubiera spoofing de correo. Lo más probable es que Google sí haya enviado oficialmente ese correo. Mi suposición es que el atacante inició el proceso oficial de recuperación de cuenta de Google, lo que hizo que Google enviara un correo con un código. Como la víctima leyó ese código en voz alta, el atacante terminó obteniendo acceso completo a la cuenta de Google (y también a Gmail y a la app de autenticación respaldada en Google Drive). Me gustaría mucho ver los encabezados originales del correo.

  • El correo enviado desde [e-mail] no parece real. Tiene errores gramaticales en la primera oración y al inicio del segundo párrafo. Es imposible que un correo del equipo legal tenga errores tan básicos de ortografía y puntuación. Si fuera oficial de verdad, seguro habría pasado por corrección. Es falso.

  • Si el correo lo hubiera enviado el atacante, entonces no entiendo por qué la víctima habría tenido que decir el código en voz alta.

  • Eso de “restablecimiento de contraseña de Coinbase”... usar Gmail vinculado a servicios críticos como banca, cripto o dominios es realmente peligroso. Yo mismo conozco mi contraseña de Google pero no puedo entrar porque la autenticación secundaria me lo impide.

• Siempre hay que desconfiar de los números desconocidos. Estoy de acuerdo con el consejo de que, si algo se siente raro, hay que colgar y volver a iniciar la conversación contactando directamente a la empresa. Pensándolo bien, casi nunca contesto llamadas si no esperaba recibirlas, y creo que gracias a eso he evitado muchas estafas. Me decepciona que Google sincronice los códigos de Authenticator en la nube y que al final eso le diera al atacante acceso a Gmail, Drive, Photos y la app de autenticación.

  • Normalmente no contesto números desconocidos, pero hace unos días me llamó alguien haciéndose pasar por “empleado de Amazon” diciendo que habían cargado un iPhone de 600 mil wones a mi cuenta. Para verificar quién era, le pregunté cuál había sido mi pedido más reciente, y siguió totalmente perdido. Después de hablar 20 minutos, terminó insultándome y colgó. Al mismo tiempo, se oía un ruido fuerte de fondo, como si estuvieran haciendo la misma estafa alrededor. No entiendo por qué duré tanto en esa llamada.

  • La señal de alerta más clara en este tipo de estafas es que “soporte te contacta primero”. Cuando de verdad quieres hablar con soporte por algo urgente, ni siquiera te contestan.

  • Mi regla ahora es mandar cualquier número desconocido directo al buzón de voz. Si es importante, que dejen mensaje y número. Si hace falta, yo regreso la llamada. Solo hago excepciones con casos como servicios médicos o entregas.

  • Yo uso la regla de 1 a 2 segundos. Contesto, digo hola, y si no responden en 1 o 2 segundos, cuelgo. Los estafadores suelen conectarse desde una cola de llamadas, así que hay una pequeña espera, y además necesitan acomodarse al guion. A diferencia de una conversación normal, requieren un tiempo de preparación. Si no responden de inmediato, es muy probable que sea spam.

  • No solo en mi teléfono: también en el de mis papás tengo configurado bloquear números desconocidos por completo. Les repito constantemente que no crean en estafas por correo, pero aun así una o dos veces al año mi mamá termina contactándome asustada por algún “correo de estafa que pensó que era real”.

• Mi regla básica es no contestar llamadas. De hecho, dejo activado “No molestar” y solo permito tonos para los números favoritos. Si alguien de verdad tiene urgencia —sea legítimo o estafa— que deje un buzón de voz. Si dice representar a una empresa, yo lo verifico por mi cuenta. Este caso demuestra que, si no pediste la llamada, por más convincente que suene, lo correcto es ni siquiera empezar la conversación. Y jamás guardo información sensible en una cuenta de Google. Cualquiera con experiencia en la industria tecnológica sabe lo peligroso que puede ser eso.

  • Yo también entiendo perfectamente el riesgo de las llamadas spam; no hace falta explicármelo. Pero siento que se descarta demasiado rápido la posibilidad de que lugares como “el equipo de seguridad del banco” sí puedan llamarte de verdad por una alerta de fraude. Puede que yo no reconociera el número del banco, y tampoco estoy seguro de que esa sea la respuesta correcta.

  • He recibido llamadas reales del gobierno o del banco por cosas importantes (como errores en la declaración de impuestos), así que no creo que la respuesta correcta sea simplemente no contestar nunca. Además, en Europa casi nadie usa el buzón de voz; eso parece más una costumbre de EE. UU.

• No hace falta falsificar una dirección de correo para robar cripto. Los criminales incluso podrían amenazarte con un arma para que entregues la semilla, y de hecho hay bastantes casos así. Por eso la banca tradicional es mucho más segura que las criptomonedas. El autor hizo bien en compartir su experiencia, pero ojalá la verdadera lección sea que la cripto no es una forma segura de guardar valor.

  • Aun así, llamar por teléfono escala mucho mejor que ir casa por casa con un arma.

  • Aunque bueno, muy al estilo de Hacker News, hay quien opina que las amenazas con armas ni siquiera son el tema aquí.

  • Para la seguridad en cripto, el multisig sirve bastante. Por ejemplo, en un esquema 2-of-2, si compartes la firma con una institución confiable como un banco, normalmente quedas mejor protegido que con un banco tradicional. Si usas varias llaves, como 3-of-5, también puedes prepararte contra coerción física, por ejemplo haciendo que una llave se borre al meter mal el PIN en un token de hardware.

  • La solución es una wallet multisig. Además, requerir que varias personas aprueben un retiro también funciona como freno para gastar de más, aunque cuando hay varias personas involucradas eso puede introducir otros riesgos. Y si usas una cold wallet offline, un hackeo puede tomar horas, lo que al menos te da tiempo.

  • También vale la pena ver esta viñeta: https://xkcd.com/538/

• La pregunta más importante es por qué el atacante no vació también el banco, la pensión o las tarjetas de crédito. En la práctica, los bancos son mucho más sensibles a las intrusiones en cuentas de clientes.

  • Lo que realmente significa “al banco le importa” es, por ejemplo, que si actuaste de forma razonable y aun así te vaciaron la cuenta, existe una política de reembolso. Por eso los bancos también ponen mucha más atención a los fraudes de montos altos. Como referencia, hace apenas 10 meses había un hilo en Reddit que decía que la combinación Coinbase + Google Authenticator era la mejor seguridad posible: hilo de Reddit sobre el hackeo de Coinbase

  • Dicho eso, también es un problema que por este motivo bancos y similares te obliguen a hacer banca solo desde apps de smartphone llenas de mecanismos de bloqueo. Casi no hay punto medio entre desconfiar totalmente del cliente y cargarle toda la responsabilidad.

  • En cuentas bancarias o de corretaje, las transferencias tardan. Durante ese tiempo puedes darte cuenta del fraude, reportarlo y lograr que congelen la cuenta, así que es más fácil evitar una pérdida inmediata.

  • Aunque también hay quien opina que a los bancos en realidad no les importa tanto.

• La secuencia del incidente es tan ambigua que cuesta entenderla. Si de verdad lograron vaciar todo solo con un código 2FA, sería gravísimo. También me pregunto si había una contraseña ya filtrada, reutilización de contraseña, o si simplemente la cuenta de Google ya estaba expuesta. Si con solo un código 2FA pudieron pasar de la cuenta de Google a la app de autenticación y luego al gestor de contraseñas, eso podría derribar en cadena la autenticación secundaria de muchos otros servicios. Lo que más me intriga es si hubo o no reutilización de contraseña. Nota: trabajo en Google, pero no en el equipo de seguridad.

  • Mi impresión es que el atacante ya tenía mi contraseña y al final solo necesitaba el código de recuperación que le di por teléfono. No compartí mi contraseña ni la reutilicé, pero sí llevaba mucho tiempo sin cambiarla.

  • Incluso si tienes la contraseña, si controlas el correo y los códigos 2FA puedes tomar todas las cuentas mediante restablecimientos de contraseña.

• Al texto le faltan detalles técnicos concretos, pero preocupa que incluso en 2025 Google no pueda bloquear correctamente correos “parecidos” a @google.com. No queda claro si fue spoofing con Unicode, si faltaba autenticación como DKIM, o si la propia cuenta estaba comprometida. En general, hay cosas que no cuadran.

  • La idea de los nombres de dominio Unicode nunca me ha parecido algo que realmente haya funcionado bien. En la práctica, quienes más los aprovechan suelen ser estafadores y criminales. Gracias, ICANN, dicho con toda la ironía.

  • También llama la atención que en esa publicación no expliquen cómo hizo para que pareciera que el correo venía de un dominio de Google. Dice trabajar en seguridad, pero aun así no da detalles, lo cual se siente raro.

• Alguien señaló que faltó el consejo de “no dejes cientos de miles de dólares en una cuenta de Coinbase”.

  • Yo tenía mi cripto repartida entre Coinbase y un disco duro dañado, y ahora no puedo recuperar el disco.

  • Yo recomendaría directamente no invertir en criptomonedas. Fuera de la especulación y el lavado de dinero, cuesta encontrarles valor práctico y los riesgos son altos.