Google bị giả mạo qua tấn công phát lại DKIM: phân tích kỹ thuật

 (easydmarc.com)
1 điểm bởi GN⁺ 2025-07-27 | 1 bình luận | Chia sẻ qua WhatsApp
  • Đây là một trường hợp kẻ tấn công đã gửi thành công email lừa đảo giả mạo Google bằng tấn công phát lại DKIM
  • Địa chỉ người gửi và kết quả xác thực của email trông như thư chính thức thật từ Google, khiến người dùng rất dễ bị lừa
  • Kẻ tấn công tận dụng Google Sites để dựng một trang trông giống trang hỗ trợ chính thức, qua đó tăng độ tin cậy
  • Dù SPF, DMARC và DKIM đều vượt qua xác thực, cốt lõi của cuộc tấn công là chuyển tiếp lại email mà không sửa nội dung thư hay header chữ ký
  • Biện pháp ứng phó thực tế được khuyến nghị là xoay vòng khóa DKIM định kỳ và nâng cao nhận thức người dùng

Mở đầu: email lừa đảo trông hoàn toàn bình thường

  • Vào buổi sáng, một người quen đã nhận được email nói rằng có yêu cầu tài liệu pháp lý liên quan đến tài khoản Google của họ
  • Người gửi được hiển thị là địa chỉ no-reply chính thức của Google, không có lỗi chính tả, không có liên kết đáng ngờ hay tên miền bất thường, và được soạn rất tinh vi
  • Người nhận khó có thể tự xác định thật giả nên đã nhờ chuyên gia kiểm tra

Phân tích chi tiết email

  • Header email và phần xem trước liên kết được kiểm tra trong môi trường sandbox
  • Địa chỉ người gửi, nhận diện thương hiệu, chất lượng ngôn ngữ, sự hiện diện của tệp đính kèm đều trông bình thường
  • Tuy nhiên, khi kiểm tra kết quả xác thực SPF, DKIM, DMARC thì phát hiện dấu hiệu bất thường

Lưu ý về email lừa đảo

  • Nhấn mạnh không nhấp vào liên kết hoặc làm theo chỉ dẫn trong email đáng ngờ
  • Nếu trả lời email đó hoặc mở tệp đính kèm ngoài môi trường sandbox, có nguy cơ rò rỉ thông tin, xâm phạm email doanh nghiệp, chiếm đoạt tài khoản, xâm nhập mạng
  • Nếu thấy đáng ngờ, cần lập tức yêu cầu phân tích chuyên sâu và báo cho đội ngũ bảo mật

Luồng tấn công: lợi dụng Google Sites

  • Liên kết trong email tấn công sẽ dẫn thẳng tới Google Sites nếu người dùng đang đăng nhập
  • Google Sites là subdomain chính thức của google.com mà bất kỳ ai cũng có thể tạo miễn phí, nhưng nội dung bên trong không phải là trang hỗ trợ chính thức
  • Dịch vụ này được dùng cho nhiều mục đích như wiki nội bộ, dashboard dự án, tài liệu hóa, website sự kiện, và cũng có thể bị lạm dụng như trong vụ tấn công này

Khi hạ tầng đáng tin trở thành mối đe dọa

  • Google Sites (ra mắt năm 2008) tích hợp với Google Workspace, cho phép tạo và phát hành dễ dàng, có SSL và mang lại độ tin cậy thương hiệu
  • Kẻ tấn công có thể dựng một website lừa đảo trông chính thức một cách dễ dàng, chi phí thấp mà không cần domain hay hosting riêng

Chi tiết quá trình tấn công phát lại DKIM

Bước 1: lấy được email Google thật

  • Kẻ tấn công nhận một email hợp lệ từ tài khoản no-reply@accounts.google.com, sau đó lưu lại nội dung gốc và header

Bước 2: chuẩn bị phát lại thông điệp đã ký

  • DKIM gắn chữ ký số cho một phần nội dung email và một số header nhất định
  • Nếu giữ nguyên thông điệp gốc và header chữ ký, xác thực vẫn được duy trì ngay cả khi phát lại

Bước 3: phát lại qua Outlook

  • Kẻ tấn công gửi email tấn công từ tài khoản Outlook
  • Dù thông tin nguồn gửi và một phần đường đi thay đổi, chữ ký DKIM vẫn còn hiệu lực

Bước 4: dùng máy chủ chuyển tiếp SMTP Jellyfish

  • Email được định tuyến qua hệ thống Jellyfish của Microsoft (tạo khoảng cách với máy chủ phát đi)

Bước 5: gửi qua Namecheap PrivateEmail

  • Dịch vụ PrivateEmail của Namecheap nhận email rồi tiếp tục đóng vai trò chuyển tiếp
  • Trong quá trình này, một chữ ký DKIM mới được thêm vào, nhưng không phù hợp với tiêu chí DMARC
  • Tuy nhiên, chữ ký DKIM gốc của Google vẫn khớp và hợp lệ, nên quá trình kiểm tra DMARC vẫn vượt qua

Bước 6: phát tới Gmail đích

  • Cuối cùng, người nhận nhận được một email trông như thư chính thức từ Google
  • Kết quả là SPF, DKIM và DMARC đều vượt qua xác thực

Vì sao email “trát triệu tập” giả lại nguy hiểm

  • Email mang nội dung ‘trát triệu tập’ tạo ra nỗi sợ, cảm giác khẩn cấp và sự hoang mang cho người nhận
  • Cách phát hành/chuyển giao trát triệu tập thực tế khác với email kiểu này; nếu hợp lệ thì thường sẽ được chuyển bằng hình thức vật lý hoặc qua kênh chính thức
  • Loại lừa đảo này rất thuyết phục, đến mức ngay cả người dùng có kỹ năng kỹ thuật cũng dễ mắc bẫy

Kết luận và ứng phó

  • Với mọi email khẩn cấp ngoài dự kiến, luôn cần xác minh tính xác thực và nhờ chuyên gia xử lý
  • Tuyệt đối không nhấp liên kết, không trả lời, không thực thi bất kỳ nội dung nào
  • Khuyến nghị yêu cầu đội bảo mật hoặc nhân sự điều tra chuyên trách phân tích

Bổ sung: quy trình tái hiện cuộc tấn công

  • Kẻ tấn công đăng ký domain tại Namecheap để nhận dịch vụ PrivateEmail miễn phí
  • Sau khi đăng ký Google Workspace (bản dùng thử miễn phí) và xác thực domain, chúng tạo một ứng dụng Google OAuth độc hại
  • Trường App Name có thể được đặt thành tên mong muốn (ví dụ: Google Support)
  • Thông báo tài khoản do Google gửi được chuyển tới PrivateEmail, và địa chỉ người gửi cùng địa chỉ trả lời có thể bị thao túng
  • Cuối cùng, email tấn công được chuyển tới mục tiêu mà kẻ tấn công mong muốn

Câu hỏi thường gặp

  • Tấn công phát lại DKIM: kẻ tấn công chặn một email hợp lệ có chữ ký DKIM còn hiệu lực, rồi phát lại với cùng nội dung và header
  • Giới hạn chặn của SPF, DMARC: SPF chỉ xác minh máy chủ/IP gửi; trong tấn công phát lại, DMARC cũng có thể bị vượt qua nếu DKIM vẫn khớp
  • Vì sao khó phát hiện: không sửa nội dung hay header nên rất khó nhận diện chỉ bằng xác minh chữ ký
  • Cách cuộc tấn công lách Google OAuth: kẻ tấn công tạo ứng dụng OAuth độc hại rồi phát lại thông báo chính thức do Google gửi để tăng độ tin cậy
  • Biện pháp ứng phó: xoay vòng khóa DKIM định kỳ (chu kỳ dưới 30 ngày) và đào tạo người dùng (cảnh giác với liên kết đáng ngờ, kiểm tra URL, thúc đẩy văn hóa báo cáo) là rất quan trọng

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-07-27
Ý kiến trên Hacker News

  • Tôi đang xây dựng giải pháp cho vấn đề này (cùng các đồng tác giả từng làm ở Google và Yahoo, đây là một dự án đáng tin cậy)
    Hãy tham khảo tài liệu Draft: DKIM2 Motivation
    Cách này không ngăn được việc văn bản do người dùng nhập vào thực sự được gửi ra từ Google, nhưng ít nhất sẽ ngăn việc thông điệp đó bị phát lại mà không có chủ ý thực sự từ Google
    Vì các trường SMTP FROM/TO được bảo vệ
    Bản dự thảo về động cơ không chứa chi tiết kỹ thuật; có thể xem bản nháp trong các tài liệu liên quan
    Hãy tham khảo liên kết DKIM Working Group Documents

    • Do trang Datatracker không hiển thị tốt các tài liệu ứng viên nên tôi đính kèm liên kết trực tiếp
      Draft: dkim2-dns
      Draft: dkim2-header
      Draft: dkim2-modification-algebra
      Draft: dkim2-bounce-processing
      Draft: dkim2-message-examples

    • Tôi tò mò cách này sẽ hoạt động thế nào với mailing list hoặc group
      Ví dụ, rất nhiều nơi tự động chuyển tiếp email từ bên ngoài gửi đến accounts-payable@example.com cho các thành viên trong nhóm
      Tôi muốn biết liệu ở hệ thống của người nhận cuối có cần cấu hình tin cậy trình chuyển tiếp mailing list hay phải có logic nội bộ để theo dõi nó thuộc danh sách nào không
      Cần phải có cách xác minh rằng accounts-payable, người nhận ban đầu, là một người nhận hợp lệ

  • Tôi thực sự đã từng bị FBI tịch thu toàn bộ dữ liệu tài khoản Google của mình sau khi bị kết án vì tội hack máy tính
    Họ lấy dữ liệu một lần vào năm 2016 và một lần nữa vào năm 2018
    Thực tế họ không làm theo cách như trong bài viết này
    Theo trải nghiệm của tôi, họ gửi email đến một bộ phận cụ thể của Google để tiến hành liên lạc chính thức
    Cơ quan điều tra hành động rất thận trọng để đối tượng điều tra không phát hiện ra càng lâu càng tốt

    • Nói rõ hơn cho những ai tò mò
      Bạn sẽ nhận được một email từ usernotice@google.com với nội dung như sau:
Dear Google user,

Google received and responded to legal process issued by the United States Department of Justice (<FEDERAL DISTRICT>) compelling the release of information related to your Google account. A court order previously prohibited Google from notifying you of the legal process. We are now permitted to disclose the receipt of the legal process to you. The agency reference number or case number on the legal process is <DISTRICT COURT CASE NUMBER>.

For more information about how Google handles legal process, view our transparency report at http://google.com/transparencyreport/userdatarequests/….

Google is not in a position to provide you with legal advice or discuss the substance of the legal process. If you have other questions regarding this matter, you may wish to contact an attorney.

Please reply to this email and/or include the case identification number located in the subject line in any further communications regarding this matter.

Regards, 
Legal Investigations Support
Google LLC

Trong trát triệu tập của đại bồi thẩm đoàn liên bang (Federal Grand Jury subpoena), thường sẽ có yêu cầu trì hoãn thông báo 1–2 năm để nhà cung cấp dịch vụ (như Google) không được báo cho bạn biết
Trát triệu tập chỉ cung cấp các hồ sơ mang tính tổng quát (thông tin thanh toán, lịch sử đăng nhập, v.v.), chứ không cung cấp nội dung thực tế như email
Muốn lấy dữ liệu thực như email thì phải có lệnh khám xét riêng, và Google thường không thông báo riêng về việc lệnh khám xét đó đã được thực thi

  • Hôm nay là thứ Sáu mà bình luận này làm tôi tỉnh ra thêm 10%
    Muốn nghe câu chuyện chi tiết phía sau quá

  • Thú vị thật
    Tôi tự hỏi liệu yêu cầu này có được ghi lại hoặc gắn thẻ trong toàn bộ tệp dữ liệu tài khoản của tôi khi tôi gửi các yêu cầu kiểu GDPR như “hãy cho tôi toàn bộ dữ liệu liên quan đến tài khoản của tôi” hay không

  • Tôi đoán lệnh khám xét có lẽ được ban hành vì vi phạm CFAA, wire fraud hoặc conspiracy gì đó
    Hy vọng bạn đã thuê luật sư giỏi và xử lý ổn thỏa

  • Gần đây tôi cũng nhận được một đợt tấn công tương tự
    Kẻ tấn công gửi mail từ yourgoogleaccount@google.com (không phải chính xác là gmail.com), sau đó chuyển tiếp thông báo lỗi gửi thư (bounce) nhận được từ máy chủ mail của Google đến yourgoogleaccount@gmail.com rồi chèn thêm tin nhắn spam ở cuối
    Mọi bước kiểm tra bảo mật đều được vượt qua
    Điều thật kỳ lạ là nó kết hợp lỗi postmaster với chiến dịch phishing
    Nếu không rành kỹ thuật thì rất dễ mắc bẫy
    Trường hợp của tôi thì nội dung phishing là thông báo trúng thưởng dụng cụ xây dựng

    • Tôi cũng đã nhận những email kiểu này suốt vài tuần nay
      Giờ tôi có cảm giác Google đã bỏ cuộc với email rồi

  • Tôi đã rất bối rối khi đọc bài này
    Bài mô tả rất chi tiết như thể kẻ tấn công đã chỉnh sửa phần thân email để chèn liên kết phishing, nhưng thực tế không có bằng chứng hay sự chỉnh sửa nào như vậy
    Chữ ký DKIM có bao gồm hash của phần thân
    Về mặt kỹ thuật có thể dùng trường I= để giới hạn phạm vi hash, nhưng tôi đã kiểm tra và Google dường như không dùng tùy chọn đó cho email ngắn (xác nhận bằng cách xem trực tiếp mail từ no-reply@accounts.google.com)
    Tức là để vượt qua kiểm tra DKIM và DMARC thì phần thân không được thay đổi, nên liên kết phishing cũng là nội dung gốc do Google gửi đi ngay từ đầu (chỉ là có thể dành cho người nhận dự kiến khác)
    Vì vậy, trọng tâm thực sự giống như “một email đáng sợ bị chuyển tiếp nhầm” hơn, còn tiêu đề ‘DKIM replay attack’ có thể nghe nghiêm trọng hơn nhiều đối với những người không quen lĩnh vực này
    Chỉnh sửa: Tôi tưởng bài đã kết thúc ở phần “The Takeaway?”, nhưng bản cập nhật bên dưới giải thích rằng liên kết thực ra được chèn vào tên ứng dụng Google OAuth rồi xuất hiện trong mẫu email của Google
    Đây mới là điểm quan trọng nhất của cuộc tấn công, nhưng cách tổ chức bài quá tệ nên bị chôn vùi và khiến người đọc hiểu nhầm như thể có thể phân phối nội dung tùy ý
    Bổ sung: Một bình luận khác cũng chỉ ra rằng ảnh chụp màn hình email đã bị cắt ở giữa để phần cố định của mẫu email Google không hiện ra
    Bản thân cuộc tấn công cẩu thả hơn nhiều so với tưởng tượng

    • Bài này có vẻ được viết theo cách cố tình gây hiểu nhầm
      Nó làm như phần xuất hiện trong ảnh chụp là toàn bộ email, trong khi thực tế hẳn là còn phần văn bản tiếp theo đủ để gây nghi ngờ

    • Theo cách tôi hiểu thì DKIM được xác minh vì kẻ tấn công đang chuyển tiếp nguyên xi email mà họ thực sự nhận được từ Google
      Vector tấn công thực sự là ở chỗ Google bị khiến phải gửi một email chứa đoạn văn bản do kẻ tấn công kiểm soát

  • Cá nhân tôi thấy lỗ hổng thực sự ở đây là có thể đặt URL trong tên ứng dụng Google OAuth, và nó được render vào email no-reply từ tên miền gốc của Google đến một địa chỉ tùy ý mà gần như không có kiểm soát
    Dù liên kết không bấm được, nếu phần văn bản xung quanh đủ đáng sợ thì nạn nhân vẫn rất có thể tự gõ địa chỉ đó vào
    Việc các dịch vụ chuyển tiếp vẫn giữ nguyên tính toàn vẹn DKIM có thể xếp chồng nhiều lớp chỉ là một khía cạnh mang tính giáo dục thêm
    Cần chặn hoàn toàn việc đưa URL vào tên ứng dụng OAuth, đặc biệt là các URL có chứa google.com

  • Cuối cùng cũng thấy!
    Vài tháng trước tôi đã nhận một email gần như y hệt như thế này (nhắm đến quản trị viên Google Domains)
    Tôi chắc chắn đã nổi da gà khi thấy email đó
    Tôi cũng không vội nhấp vào liên kết mà chờ xem, đồng thời cố tìm thêm tài liệu tham khảo khác về trò lừa này
    Điểm lạ là tất cả địa chỉ email đều bị che đi, và kiểu che đó không khớp với các email tôi quản lý
    Bản thân email là thật, và khi tìm trên Google thì nội dung phần thân cũng khớp
    Trường hợp của tôi là email liên quan đến tài khoản của người đã qua đời, hoàn toàn không đúng với thực tế
    Nhưng tôi đã gần như 100% nghi ngờ rằng có ai đó đang cố thuyết phục Google rằng tôi đã chết để cướp toàn bộ tài khoản Google của mình
    Đó là một trải nghiệm cực kỳ đáng sợ

  • Bước 3: Kẻ tấn công gửi email từ Outlook
    Theo tôi biết thì không thể giả mạo đường đi trong header Received:
    Mỗi máy chủ đều tiếp tục tự thêm thông tin đường đi của chính mình
    Vì thế tôi luôn kiểm tra thông tin đó khi xác minh nguồn gốc email
    Email đến từ Google thì không thể nào lại đi qua máy chủ của Microsoft

    • Header của máy chủ ‘đáng tin cậy’ cuối cùng thì không thể giả mạo, còn các phần đường đi khác thì có thể

    • Tôi tò mò không biết bạn có kiểm tra thủ công header của mọi email như vậy không
      Hay bạn đang dùng công cụ nào để hiển thị hoặc trực quan hóa chúng

  • Tình huống này thực sự đáng sợ
    Hãy thử tưởng tượng phải giải thích bài học rút ra từ bài này cho người thân của mình
    Thật nặng nề khi phải nói rằng ngay cả khi email đến từ một tên miền đáng tin, và dkim/dmarc/spf đều lần lượt vượt qua, vẫn luôn phải nghi ngờ
    Nhưng phạm vi mà cuộc tấn công này làm được thực ra khá hạn chế
    Ví dụ, nó không thể giả mạo rồi gửi tin nhắn từ tài khoản Gmail của người khác
    “Khi một thông điệp được chuyển tiếp, chữ ký DKIM vẫn được giữ nguyên miễn là phần thân và các header nằm trong phạm vi ký không bị thay đổi”
    Điều bất ngờ là header To: lại không nằm trong phạm vi ký DKIM
    Tôi nghĩ cần thay đổi cấu hình chữ ký, hoặc thêm tính năng ở trình email để cảnh báo khi To bị thay đổi dù thư vẫn hợp lệ

    • Hãy thử tưởng tượng giải thích bài học của bài này cho người thân – rằng luôn phải nghi ngờ
      Đã khó xử ngay từ việc còn phải giải thích dkim/dmarc/spf là gì
      Thực ra các công nghệ này là hạ tầng phía sau mà người dùng không cần phải biết
      Cuộc tấn công này không đáng sợ đến mức đó
      Bài viết có phần cường điệu vì muốn bán sản phẩm
      Việc header To: không nằm trong chữ ký thực ra cũng không quan trọng lắm
      Trong thực tế, To trong email không nhất thiết phải là người nhận cuối cùng

    • Trong email, việc luôn giữ thái độ nghi ngờ đã là trạng thái mặc định từ rất lâu rồi
      Tốt nhất là đừng bao giờ tin tuyệt đối vào trường From

    • Bạn nói ngạc nhiên vì To: không nằm trong chữ ký DKIM, nhưng thực tế là có
      Vì vậy giá trị To: gốc lẽ ra phải được giữ nguyên
      Ảnh chụp màn hình trong phần tái hiện có hiển thị địa chỉ To: gốc đó
      Điều này không có nghĩa là thư được phát đến địa chỉ đó
      Về bản chất, email có thể được chuyển đến bất kỳ địa chỉ nào, với bất kỳ giá trị To: nào

    • Lời khuyên mặc định của tôi là, nếu một email nào đó thúc giục bạn phải thực hiện hành động, hãy tự truy cập trực tiếp vào website tương ứng
      Đừng nhấp vào bất kỳ liên kết nào
      Bất tiện thật, nhưng về lâu dài nó giải quyết được vấn đề
      Đặc biệt với ngân hàng hay các hệ thống quan trọng thì sự bất tiện này hoàn toàn xứng đáng

    • Ở nơi làm việc của tôi, kiểu tình huống đe dọa này đã thành chính sách rồi
      Trên internet, nghi ngờ mọi thứ là thông lệ tốt
      Rất nhiều doanh nghiệp nhỏ và freelancer vẫn chưa dùng MFA, hoặc dù có dùng thì vẫn dễ bị đánh cắp token
      Khi các tài khoản đó bị xâm nhập, những email độc hại trông như từ người dùng nội bộ thực sự sẽ xuất hiện
      Từ góc nhìn người dùng, chúng trông hoàn toàn hợp lệ
      Vì vậy email luôn phải được xử lý với sự hoài nghi

  • Tác giả viết
    “Here is the URL from that email [...] https://sites.google.com[...]”
    Chính liên kết này mới là dấu hiệu đỏ đầu tiên
    Tôi nghĩ tác giả đáng lẽ phải nêu điểm đó ngay từ đầu, thay vì ba đoạn sau mới nhắc tới

    • Không phải ai cũng biết hết mọi subdomain của google.com
      Vấn đề thực sự là, ngoài lỗi liên quan đến trường hợp lệ của SSO, Google còn phục vụ nội dung do người dùng tạo ra ngay trên các subdomain của tên miền chính
      Các dịch vụ khác như Drive cũng có thể vậy

    • Có thể đó là dấu hiệu đỏ với bạn, nhưng chưa chắc với bố mẹ chúng ta

  • Nhìn chung tôi nghĩ đây là một ví dụ cho thấy bảo mật email là một hệ thống mong manh đến mức nào
    Diễn đàn này có rất nhiều người thông minh, tôi tin có thể nghĩ ra một giải pháp thay thế xử lý dứt điểm những vấn đề như thế này
    Tôi cũng nghĩ Google nên phục vụ các site như vậy trên một tên miền tách biệt như hostedbygoogle.com thay vì tên miền chính
    Không hiểu sao đến giờ họ vẫn chưa tách ra

    • Thực tế thì mọi phương án thay thế khả thi cuối cùng đều dẫn tới một hệ thống giao toàn bộ quyền kiểm soát cho một công ty duy nhất
      Điều đó làm mất đi giá trị lớn còn lại của email: một hệ thống không bị ai kiểm soát hoàn toàn
      Vấn đề kỹ thuật thì có thể giải được, nhưng vấn đề con người và lợi ích mới khó hơn nhiều
      Những bên có đủ nguồn lực để giải quyết vấn đề này phần lớn không có động lực tạo ra một nền tảng hoàn toàn mở
      Trừ khi họ nắm toàn bộ tiền bạc và quyền kiểm soát, còn không thì họ sẽ không bỏ công làm
      Ngược lại, cũng không phải ai cũng muốn giao hết quyền kiểm soát cho một công ty
      Đó chính là lý do đây không phải vấn đề kỹ thuật mà là vấn đề kinh doanh
      (Lý do mọi dịch vụ trong metaverse gần như không thể chia sẻ avatar và vật phẩm với nhau cũng y hệt như vậy
      Không hẳn là vì kỹ thuật không làm được, mà là vì chủ sở hữu quyền sẽ không bao giờ cho phép)

    • Công bố startup mới Shadowfax do Thiel đầu tư!
      Dịch vụ độc quyền tập trung, an toàn của chúng tôi được tích hợp lớp AI và blockchain, sẵn sàng thay thế hệ thống email lỗi thời
      Chúng tôi đã giành được hợp đồng với Bộ Quốc phòng Mỹ, và dự kiến sẽ trở thành tiêu chuẩn cho toàn bộ liên lạc nội bộ và đối ngoại của chính phủ liên bang vào năm 2027