Vụ lừa đảo 130.000 USD bằng cuộc gọi và email mạo danh Google, đồng bộ mã xác thực bị lợi dụng để phishing

• Một người dùng chia sẻ trải nghiệm bị phishing do cuộc gọi mạo danh đội hỗ trợ Google và email giả mạo [e-mail]
• Do tính năng đồng bộ đám mây của Google Authenticator, kẻ tấn công đã lấy được cả mã xác thực hai bước, xâm nhập tài khoản Coinbase và đánh cắp tiền mã hóa
• Chỉ trong khoảng 40 phút, nạn nhân bị lấy mất số tiền mã hóa trị giá khoảng 80.000 USD (giá trị hiện tại khoảng 130.000 USD)
• Lỗ hổng bảo mật của Gmail và thiết lập đồng bộ mặc định của Authenticator được chỉ ra là nguyên nhân khiến thiệt hại nghiêm trọng hơn
• Khuyến nghị tuân thủ các nguyên tắc bảo mật cơ bản như thay đổi mật khẩu định kỳ, không chia sẻ mã xác thực và cân nhắc kỹ khi bật đồng bộ đám mây

---

Vụ lừa đảo bắt đầu chỉ từ một cuộc gọi

• Ngày 19/6, nạn nhân nhận cuộc gọi từ đầu số (650) khu vực 'Pacifica, CA'
• Đối phương tự nhận là thuộc đội hỗ trợ Google, nhắc tới một yêu cầu chuyển giao tài khoản đã bị báo cáo (thậm chí còn nói có kèm giấy chứng tử và ID)
• Chúng gửi email từ địa chỉ [e-mail] trông như thật (người gửi hiển thị là Norman Zhu), khiến nạn nhân tin rằng đó là email chính thức
• Trên ứng dụng Gmail cho iOS, email được hiển thị là người gửi @google.com cùng branding, mã vụ việc và các chi tiết ngụy trang tinh vi
• Lấy cớ xác minh tình trạng còn sống hay đã chết, kẻ tấn công yêu cầu kiểm tra một mã xác thực tạm thời, và trong khoảnh khắc hoảng loạn nạn nhân đã cung cấp mã

Kẻ tấn công truy cập tài khoản Coinbase

• Cuối cuộc gọi, đối phương còn hướng dẫn như thể đang hỗ trợ đăng ký Google Advanced Security để khiến nạn nhân yên tâm
• Nạn nhân tưởng rằng mình đã tăng cường bảo mật, nhưng thực tế kẻ tấn công đã có quyền truy cập Gmail, Drive, Photos và các mã Authenticator đã đồng bộ
• Yếu tố mang tính quyết định là đồng bộ đám mây của Google Authenticator đã khiến cả mã 2FA cũng bị lộ
• Ngay sau đó, kẻ tấn công đăng nhập vào tài khoản Coinbase và bắt đầu rút tiền mã hóa

Chi tiết vụ đánh cắp tiền mã hóa

• Trong khoảng 40 phút, kẻ tấn công thực hiện nhiều giao dịch để chuyển phân tán ETH và các token khác rồi rút sạch toàn bộ
• Thiệt hại tại thời điểm đó khoảng 80.000 USD, theo giá hiện tại tương đương khoảng 130.000 USD
• Hai giờ sau khi kiểm tra số dư Coinbase, nạn nhân bàng hoàng thấy tài khoản gần như về 0
• Nạn nhân còn phát hiện lịch sử đăng nhập từ thiết bị mới trong tài khoản Google và việc số điện thoại khôi phục đã bị thay đổi

Vì sao ngay cả chuyên gia bảo mật cũng có thể mắc bẫy

• Nạn nhân cho biết mình làm việc trong ngành IT và bản thân cũng là người thiết kế trải nghiệm xác thực
• Dù có nhận thức bảo mật cao, nạn nhân vẫn thất bại trước phishing do email giả mạo quá tinh vi và tình huống khẩn cấp được dàn dựng khéo léo

Hai sai lầm bảo mật cốt lõi của Google

1. Không chặn được email giả mạo người gửi ‘@google.com’
   • Trường From của email có thể bị spoof để trông như email chính thức, trong khi ứng dụng Gmail trên iOS không cho xem đầy đủ header nên rất khó xác minh ngay lập tức
2. Google Authenticator bật đồng bộ đám mây theo mặc định
   • Kẻ tấn công lấy được các mã 2FA đã đồng bộ, khiến hiệu lực thực tế của xác thực hai bước bị vô hiệu hóa
   • Hệ quả là toàn bộ tài sản số như email, 2FA, tài liệu và ảnh đều có thể bị lộ cùng lúc

• Lưu ý: có cảnh báo rằng đối với người dùng vừa dùng Gmail vừa dùng Google Authenticator, 2FA có thể về bản chất không còn thực sự an toàn

Nguyên tắc và lời khuyên bảo mật

• Hãy đổi mật khẩu ngay hôm nay và cập nhật định kỳ (các vụ rò rỉ hơn 1,6 tỷ mật khẩu vẫn tiếp diễn)

• Tuyệt đối không chia sẻ mã xác thực (kẻ tấn công thao túng tâm lý bằng cảm giác “khẩn cấp” và “lo sợ”)

• Cân nhắc kỹ khi dùng đồng bộ đám mây của Google Authenticator

  • Dù tăng sự tiện lợi khi khôi phục, nó cũng đi kèm rủi ro trong quản lý

• Luôn cảnh giác với các cuộc gọi đáng ngờ

  • Nếu thấy bất an, nên ngắt cuộc gọi ngay và kết nối lại qua kênh chính thức

• Nạn nhân hy vọng vụ việc này sẽ giúp nâng cao cảnh giác và ngăn chặn các thiệt hại tương tự

Giải thích thêm và các tình tiết liên quan

• Có khả năng kẻ tấn công đã nắm sẵn mật khẩu từ danh sách rò rỉ gần đây gồm 1,6 tỷ mật khẩu
• Nạn nhân cho biết mình không dùng lại cùng một mật khẩu và đã giữ bí mật mật khẩu, nhưng đã không thay đổi mật khẩu trong thời gian dài
• Nhiều khả năng kẻ tấn công đã nhận được mã khôi phục rồi dùng nó để vượt qua 2FA

Liên quan đến email phishing

• Nạn nhân nhận nhiều email mang danh nghĩa [e-mail], nhưng kẻ tấn công đã xóa sạch mọi dấu vết email, cả thùng rác lẫn lịch sử khôi phục
• Tuy vậy, sau khi chuyển tiếp một số email đến [e-mail], nạn nhân đã giữ lại được bản gốc thông qua các thư bị trả lại trong quá trình lấy lại quyền truy cập tài khoản
• Địa chỉ email [e-mail] dường như không thực sự tồn tại hoặc không thể truy cập từ bên ngoài
• Email gốc có tiêu đề ‘Google Recent Case Status’, dùng định dạng và cách đặt tên chính thức, kèm hướng dẫn về việc xem xét nội bộ và lưu mật khẩu tạm thời
• Email còn bao gồm tên nhân viên hỗ trợ là ‘Norman Zhu’, số vụ việc và thông tin bộ phận

Tóm tắt toàn bộ

• Đây là một vụ chiếm đoạt tài khoản quy mô lớn và trộm tiền mã hóa do cuộc tấn công mạo danh cực kỳ tinh vi kết hợp với lỗi cấu trúc ở cấp nền tảng
• Vụ việc nhắc lại rằng ngay cả xác thực hai lớp cũng không phải vùng an toàn tuyệt đối
• Ngoài các nguyên tắc bảo mật truyền thống, cần xem xét lại chính sách ở cấp nền tảng và thiết lập bảo mật khác nhau cho từng dịch vụ

[GN⁺]

Ý kiến trên Hacker News

• Thứ Sáu tuần trước tôi cũng nhận được một cuộc gọi tương tự, nghe rất hợp pháp. Mẹo tôi hay dùng là yêu cầu mã số ticket và số gọi lại chính thức để kiểm tra xem đó có đúng là số của công ty thật không. Nếu đúng thì có thể tiếp tục nói chuyện, còn không thì có thể yên tâm bỏ qua. Người gọi nói rằng họ có thể gửi một email để “chứng minh đây là chính thức”, nhưng lại không cung cấp số gọi lại, nên tôi biết ngay đó là lừa đảo. Địa chỉ email hay số điện thoại đều có thể bị giả mạo. Dù số hiển thị có vẻ bình thường cũng tuyệt đối đừng tin; luôn phải gọi lại vào số chính thức để xác minh.

  • Tôi thậm chí còn không nhận trực tiếp cả số điện thoại, mà luôn hỏi tên công ty và chi nhánh trước, rồi tự vào trang web chính thức của công ty (ví dụ: https://amazon.com) để tìm số và gọi lại. Hơi bất tiện nhưng an toàn hơn nhiều.

  • Khi tra “số chính thức” cũng phải cẩn thận. Số giả có thể lẫn trong kết quả tìm kiếm trên những trang web trông như thật. Đúng là chiến trường không tiếng súng.

  • Về chuyện “dù là số thật thì caller ID cũng vô nghĩa”, tôi cũng đã từng nói điều này vài năm trước khi ngân hàng gọi và yêu cầu tôi cung cấp thông tin cá nhân để xác minh danh tính.

  • “Số điện thoại chính thức” là một ý tưởng hay, nhưng nếu kẻ tấn công có quyền truy cập SS7 thì cách đó cũng vô dụng.

• Những điều cần phải ghi nhớ lặp đi lặp lại:

  • Bộ phận hỗ trợ khách hàng của các công ty lớn tuyệt đối không tự gọi điện trước.

  • Nếu ai đó gọi điện hoặc gửi email xin mã, tuyệt đối đừng đọc mã xác thực nhận qua SMS; trong tin nhắn thường cũng có ghi như vậy.

  • Đừng bảo vệ thông tin cá nhân quan trọng chỉ bằng một mật khẩu. Đừng dùng Google Authenticator gắn với tài khoản Google làm nơi quản lý mật khẩu; nên dùng bên thứ ba như 1Password.

  • Phải tách riêng email dùng cho ngân hàng/đầu tư và email đã lộ ra ngoài. Hồ sơ Chrome cũng nên tách theo từng email và chỉ giữ lại extension quản lý mật khẩu.

  • Nhưng vài tuần trước tôi từng nhận được cuộc gọi xưng là bộ phận hỗ trợ ngân hàng từ một số không ra trên tìm kiếm. Họ yêu cầu tôi đọc mã xác thực được gửi qua tin nhắn, tôi từ chối thì online banking bị khóa, rồi thư giấy thật được gửi đến với nội dung rất cứng rắn rằng “không thể tự động nâng cấp tài khoản vì anh/chị không liên lạc với nhân viên hỗ trợ”. Cuối cùng tôi tạo tài khoản mới trong app và gọi lại cho họ, rồi đọc lại mã SMS cho họ (!), và đó thực sự là bước xác minh duy nhất cho tài khoản mới. Một ngân hàng thuộc top 100 toàn cầu lại vận hành như vậy. Cảm giác như chính doanh nghiệp đang huấn luyện khách hàng để bị lừa. Đó là một ngân hàng gốc Đức, nhưng Chase cũng có thói quen yêu cầu mã OTP qua điện thoại y như vậy.

  • Tôi từng bị bộ phận hỗ trợ khách hàng yêu cầu mã xác thực khi xin tắt thiết lập tiết kiệm năng lượng của Google Nest Thermostat (đây là tính năng cho phép công ty điện lực điều khiển nhiệt độ để tiết kiệm điện). Tôi từ chối vì “trong tin nhắn có ghi là không được tiết lộ”, và bộ phận hỗ trợ chỉ chuyển sang cách khác. Bản thân yêu cầu đó vốn đã kỳ quặc.

  • Cho đến gần đây Chase vẫn còn yêu cầu kiểu mã này khi gọi liên quan đến cảnh báo gian lận. Điều đó thực sự rất khó chịu.

  • Tôi để điện thoại ở chế độ “Không làm phiền” theo mặc định. Chỉ 5 người thân ruột thịt mới làm máy đổ chuông. Số lạ thì tôi tuyệt đối không nghe, và nếu thật sự khẩn cấp thì họ phải để lại voicemail. Có cảm giác khi bắt máy thì mình khó giữ được sự tỉnh táo để phán đoán ngay lập tức. Nó giống kiểu hỏi đường rồi móc túi đồng hồ. Ban đầu mục đích không hẳn là bảo mật, nhưng ở góc độ tránh tip từ ngân hàng và không lộ diện với hacker thì rất hữu ích.

  • Đáng tiếc là một số call center thật sự đang dùng cách gọi điện để xác minh danh tính, gửi mã qua SMS/email rồi bắt khách hàng đọc lại.

• Vụ tấn công này có vẻ chỉ là social engineering đơn thuần, và có lẽ không hề có email spoofing. Rất có thể email đó thực sự do Google gửi chính thức. Tôi đoán kẻ tấn công đã kích hoạt quy trình khôi phục tài khoản chính thức của Google, và trong quá trình đó Google gửi email có chứa mã. Nhờ nạn nhân đọc mã đó lên, kẻ tấn công dường như đã giành được toàn quyền truy cập tài khoản Google (và cả Gmail, Google Drive cùng ứng dụng xác thực đã sao lưu trên đó). Tôi rất muốn xem header gốc của email.

  • Email gửi từ [e-mail] trông không giống thật. Ngay ở câu mở đầu của đoạn một và câu đầu đoạn hai đã có lỗi ngữ pháp. Một email từ bộ phận pháp lý mà mắc lỗi chính tả và dấu câu cơ bản như vậy là điều không thể chấp nhận được. Nếu là email chính thức thật thì chắc chắn đã được biên tập; vậy nên đó là giả.

  • Nếu email là do kẻ tấn công gửi thì tôi không hiểu vì sao nạn nhân còn phải cung cấp mã.

  • “Đặt lại mật khẩu Coinbase” à? Dùng Gmail gắn với các dịch vụ quan trọng như ngân hàng, crypto, domain... thực sự rất nguy hiểm. Tôi cũng đang ở trong tình trạng biết mật khẩu Google của mình nhưng vẫn không vào được vì bị chặn bởi xác thực hai lớp.

• Luôn phải nghi ngờ số lạ. Tôi đồng ý với lời khuyên rằng nếu thấy có gì bất thường thì nên cúp máy và tự liên hệ lại với công ty để bắt đầu lại cuộc trao đổi. Nghĩ lại thì hầu như tôi không bắt máy nếu không hề chờ trước một cuộc gọi nào, và có lẽ nhờ vậy mà tránh được rất nhiều trò lừa. Việc Google đồng bộ mã Authenticator lên đám mây để rồi kẻ tấn công cuối cùng truy cập được cả Gmail, Drive, Photos và app xác thực là điều rất đáng thất vọng.

  • Bình thường tôi không nghe số lạ, nhưng mấy hôm trước có cuộc gọi giả danh “nhân viên Amazon” nói rằng tài khoản của tôi vừa thanh toán một chiếc iPhone giá 600.000 won. Để xác minh danh tính của họ, tôi hỏi “món hàng gần đây nhất tôi đặt là gì”, nhưng họ cứ lúng túng mãi. Chúng tôi nói chuyện tới 20 phút rồi cuối cùng phía bên kia chửi thề và cúp máy. Đồng thời tôi còn nghe thấy tiếng ồn rất lớn xung quanh, như thể họ đang thực hiện cùng lúc các cuộc gọi lừa đảo khác. Tôi thật sự không hiểu sao mình lại kéo dài cuộc gọi lâu đến vậy.

  • Dấu hiệu đỏ rõ ràng nhất trong các vụ này là “bộ phận hỗ trợ chủ động liên hệ trước”. Khi thực sự có việc gấp và muốn liên hệ hỗ trợ thật thì lại chẳng thể kết nối được.

  • Quy tắc của tôi dạo này là mọi số lạ đều chuyển thẳng sang voicemail. Nếu quan trọng thì hãy để lại tin nhắn và số điện thoại. Nếu thực sự cần, tôi sẽ gọi lại. Chỉ ngoại lệ cho bệnh viện, giao hàng và những trường hợp buộc phải nghe. Tôi đang lọc kiểu như vậy.

  • Tôi dùng quy tắc 1–2 giây. Bắt máy, nói hello, nếu trong vòng 1–2 giây không có ai trả lời thì tôi cúp. Bọn lừa đảo thường được nối từ hàng đợi cuộc gọi nên sẽ có một khoảng trễ, lại còn phải vào kịch bản nên phản ứng chậm. Không giống hội thoại bình thường, chúng cần thời gian chuẩn bị. Những cuộc gọi không phản hồi ngay có khả năng rất cao là spam.

  • Không chỉ điện thoại tôi mà điện thoại của bố mẹ tôi cũng được cài chặn hoàn toàn số lạ. Tôi thường xuyên dặn họ đừng tin email lừa đảo, vậy mà mỗi năm vẫn có một hai lần mẹ tôi hoảng hốt gọi tới vì một “email lừa đảo mà bà tưởng là thật”.

• Không nghe điện thoại là nguyên tắc mặc định của tôi. Thực tế tôi bật “Không làm phiền” và chỉ cho phép số trong danh bạ yêu thích đổ chuông. Người thực sự có việc gấp (dù là hợp pháp hay lừa đảo) thì cứ để lại voicemail. Nếu họ tự xưng là từ một công ty nào đó thì chính tôi sẽ tự xác minh. Những trường hợp như thế này cho thấy với các cuộc gọi mình không yêu cầu trước, dù nghe có thuyết phục đến đâu thì cũng không nên bắt đầu câu chuyện. Và tôi tuyệt đối không để thông tin nhạy cảm trong tài khoản Google. Nếu từng làm trong ngành công nghệ thì ai cũng biết việc đó nguy hiểm đến mức nào.

  • Tôi hiểu rất rõ rủi ro của spam call, không cần giải thích thêm. Nhưng có vẻ mọi người đang quá dễ dàng loại bỏ tiền đề rằng đôi khi “bộ phận an ninh của ngân hàng” thật sự có thể gọi để cảnh báo gian lận. Có thể tôi không nhận ra số của ngân hàng, và cũng không chắc đó có phải đáp án đúng hay không.

  • Tôi từng nhận các cuộc gọi thật sự quan trọng từ chính phủ hoặc ngân hàng (ví dụ sai sót trong khai thuế), nên tôi không nghĩ câu trả lời đúng là tuyệt đối không nghe máy. Nhân tiện, ở châu Âu hầu như không ai dùng voicemail; đó có vẻ là văn hóa của riêng Mỹ.

• Ngay cả khi không có giả mạo địa chỉ email thì việc đánh cắp crypto vẫn hoàn toàn khả thi. Tội phạm có thể dí súng và bắt nạn nhân giao seed phrase; những trường hợp như vậy thực tế khá nhiều. Vì thế ngân hàng truyền thống an toàn hơn crypto rất nhiều. Tác giả đã làm tốt khi chia sẻ trải nghiệm này, nhưng mong rằng bài học thật sự phải là crypto không phải phương tiện lưu trữ tài sản an toàn.

  • Dù sao thì gọi điện hàng loạt vẫn dễ mở rộng quy mô hơn nhiều so với việc cầm súng tìm đến tận nhà.

  • Nhưng đúng chất Hacker News, có người cho rằng việc dùng súng đe dọa ngay từ đầu đã không phải vấn đề trọng tâm.

  • Với bảo mật crypto, multisig rất hữu ích. Ví dụ trong mô hình 2-of-2, nếu chia quyền ký với một tổ chức đáng tin như ngân hàng thì thường còn an toàn hơn ngân hàng thông thường. Nếu dùng nhiều khóa như 3-of-5, bạn còn có thể chuẩn bị cho cả tình huống bị ép buộc, chẳng hạn khóa trên hardware token sẽ tự xóa khi nhập sai PIN.

  • Ví multisig mới là lời giải. Ngoài ra, cấu trúc buộc nhiều người đồng ý để rút tiền cũng tạo hiệu ứng “phanh” đối với chi tiêu, dù trong trường hợp nhiều người cùng liên quan thì lại có thể tăng rủi ro. Nếu dùng cold wallet ngoại tuyến thì việc hack sẽ mất hàng giờ, giúp có thêm thời gian xoay xở.

  • Cũng đáng xem tranh https://xkcd.com/538/.

• Câu hỏi then chốt nhất là tại sao kẻ tấn công không vét luôn cả ngân hàng/quỹ hưu trí/thẻ tín dụng. Trên thực tế, ngân hàng nhạy cảm với việc tài khoản khách hàng bị hack hơn rất nhiều.

  • Cái gọi là “ngân hàng có quan tâm” thực chất có nghĩa là, ví dụ nếu bạn đã thực hiện các biện pháp hợp lý thì khi tài khoản bị rút sạch ngân hàng sẽ có chính sách bồi hoàn. Vì vậy từ góc nhìn của ngân hàng, các vụ lừa đảo số tiền lớn được chú ý hơn nhiều. Tham khảo thêm: mới 10 tháng trước còn có một thread Reddit nói tổ hợp Coinbase + Google Authenticator là bảo mật tốt nhất Thread Reddit về vụ hack Coinbase.

  • Mặt khác, cũng vì lý do này mà việc ngân hàng v.v. ép người dùng chỉ được giao dịch qua app điện thoại bị khóa đủ kiểu cũng là một vấn đề. Gần như không có điểm cân bằng giữa thái độ “không tin nổi chính khách hàng” và việc bắt họ tự gánh trách nhiệm.

  • Việc chuyển tiền từ tài khoản ngân hàng hay chứng khoán cần có thời gian. Trong khoảng thời gian đó, nếu phát hiện ra lừa đảo và báo cáo thì tài khoản có thể bị đóng băng, nên dễ ngăn tổn thất tức thì hơn.

  • Cũng có ý kiến cho rằng thật ra ngân hàng chẳng quan tâm đến mức đó.

• Diễn biến vụ việc khá mơ hồ nên tôi không hiểu lắm. Nếu chỉ với một mã 2FA mà quét sạch được mọi thứ thì đó là vấn đề cực kỳ nghiêm trọng. Cũng có thể là do mật khẩu đã bị lộ từ trước, do tái sử dụng mật khẩu, hoặc đơn giản là tài khoản Google đã bị xâm phạm sẵn. Nếu chỉ với mã 2FA mà đi từ tài khoản Google → app xác thực → trình quản lý mật khẩu thì xác thực hai lớp ở các dịch vụ khác cũng có thể sụp đổ dây chuyền. Điều tôi tò mò nhất là có chuyện tái sử dụng mật khẩu hay không. Lưu ý: tôi làm ở Google nhưng không thuộc đội bảo mật.

  • Tôi nghĩ kẻ tấn công đã có sẵn mật khẩu của tôi rồi, và thứ cuối cùng chúng cần chỉ là mã khôi phục mà tôi đã đọc qua điện thoại. Tôi không chia sẻ mật khẩu và cũng không tái sử dụng, nhưng quả thật đã không thay đổi nó trong thời gian dài.

  • Chỉ cần kiểm soát được email và mã 2FA thì ngay cả khi có mật khẩu hay không, kẻ xấu cũng có thể dùng đặt lại mật khẩu để chiếm mọi tài khoản.

• Bài viết thiếu giải thích kỹ thuật cụ thể, nên việc đến năm 2025 mà Google vẫn không chặn nổi những email @google.com “trông giống thật” là điều đáng lo. Không rõ nguyên nhân là Unicode spoofing, hay là không có xác thực như DKIM, hoặc bản thân tài khoản gửi đã bị xâm nhập. Tổng thể câu chuyện có nhiều chỗ không khớp.

  • Bản thân ý tưởng domain name Unicode dường như chưa bao giờ thật sự ổn. Trên thực tế, những kẻ dùng tính năng đó phần lớn là lừa đảo và tội phạm. Xin “cảm ơn” ICANN theo kiểu mỉa mai.

  • Tôi thấy lạ là bài gốc không giải thích cụ thể làm sao email trông như được gửi từ domain google. Bản thân người viết nói mình làm trong ngành bảo mật mà lại không đưa chi tiết thì cũng đáng nghi.

• Có người chỉ ra rằng chẳng thấy ai đưa ra lời khuyên “đừng để hàng trăm nghìn đô trong tài khoản Coinbase”.

  • Tôi thì từng chia crypto của mình ra làm hai nơi: Coinbase và một ổ cứng bị hỏng, mà giờ ổ cứng đó không khôi phục được.

  • Tôi khuyên là đừng đầu tư vào crypto ngay từ đầu. Ngoài đầu cơ và rửa tiền thì khó thấy giá trị thực tế rõ ràng, trong khi rủi ro lại rất lớn.