Chiến dịch chiếm phiên Google: Lời mời lịch và proxy trực tiếp
Từ giữa tháng 8/2026, một chiến dịch lừa đảo đã đánh cắp phiên đăng nhập Google đang hoạt động của người dùng doanh nghiệp. Mọi dấu hiệu kiểm tra thông thường đều cho kết quả sạch, và kẻ tấn công đã thiết kế như vậy một cách có chủ đích. Nhóm nghiên cứu mối đe dọa tại Material Security phát hiện chiến dịch này và đã gỡ bỏ hàng trăm tên miền của kẻ tấn công trong chiến dịch mang tên Operation CloudFire.
Mồi nhử: lời mời Google Calendar
Các thông điệp xuất hiện dưới dạng lời mời Google Calendar. Một số đến qua BCC, nhiều thư đến từ tổ chức mà người nhận đã từng trao đổi email. Lý do được đưa ra rất nhàm chán: thông báo tin nhắn thoại, yêu cầu RFP và RFI, giấy triệu tập tòa án, thông báo trễ thanh toán. Không có gì nổi bật trong một hộp thư bận rộn.
Hầu hết các liên kết trỏ đến chính Google. Mô thức thường gặp là đi qua trình chuyển hướng /url của Google, với đích thực nằm trong tham số truy vấn. Các đợt khác dùng share.google và liên kết tệp Drive theo cách tương tự, một biến thể dựa vào liên kết thông báo giao dịch của Intuit. Khi thư được chấm điểm, tên miền, chứng chỉ và uy tín hiển thị đều hợp lệ.
Cách đánh cắp: proxy ngược trước trang đăng nhập Google
Khi nạn nhân nhấp vào, kẻ tấn công chạy một proxy ngược trực tiếp trước trang đăng nhập Google thật. Nạn nhân nhập mật khẩu, nhận lời nhắc thật và phê duyệt trong khi kẻ vận hành theo dõi theo thời gian thực. Máy chủ chuyển từng yếu tố xác thực thứ hai đến Google ngay khi nhận được, dù là mã SMS, mã authenticator, xác nhận số Tap-Yes của Google hay khôi phục tài khoản qua điện thoại. Không kiểm soát nào trong số đó ngăn được việc chiếm phiên.
Khung tấn công có tên Nyasher đã được công bố từ tháng 2, sau khi các nhà nghiên cứu tìm thấy một khóa cứng trong JavaScript của nó.
Vì sao các kiểm soát thông thường im lặng
Hệ thống uy tín trả lời câu hỏi về quyền sở hữu: ai đăng ký tên miền, nó từng lưu trữ gì, có ai từng phàn nàn không. Chiến dịch này được xây dựng để mọi câu trả lời đó đều vô hại.
Nó hoạt động theo ba lớp. Thứ nhất là trình chuyển hướng của Google, tạo cho bước nhảy đầu tiên một URL Google đáng tin. Thứ hai là thử thách Cloudflare Turnstile, có bản dùng tiện ích thật phục vụ từ hạ tầng của Cloudflare. Thứ ba là trang thu mật khẩu, nơi mọi thứ trở nên khó khăn cho phòng thủ: không có trang tĩnh để quét, JavaScript dựng trang trong trình duyệt sau khi vượt thử thách, nên trình thu thập không có gì để tải và nhật ký proxy không có gì để ghi.
Hạ tầng cũng được thiết kế để vứt bỏ. Các đợt đầu dùng nhiều tên miền mồi trải trên nhiều nhà đăng ký, hầu hết đăng ký chỉ vài ngày trước khi dùng. Điểm nhận kích hoạt trước đợt tấn công từ 1 đến 20 ngày. Một chứng chỉ wildcard được cấp 46 phút trước khi tên miền nó bao phủ được đăng ký. Chặn một mắt xích chỉ tốn của kẻ tấn công vài đô la và một buổi chiều.
Điều gì đã ngăn chặn
Các nhà nghiên cứu theo dõi chiến dịch từ đầu, bám theo từng biến thể khi mồi nhử, cổng và điểm cuối luân chuyển. Khi có biện pháp phát hiện, họ bắt được hơn 99% thư độc hại, tỷ lệ phân loại lại là 0,01%. Công việc diễn ra đều đặn vì kẻ tấn công liên tục đổi chiến thuật, chủ đề và nội dung mồi để lọt qua phát hiện tĩnh, học máy và tác tử.
Điều hiệu quả là không để bất kỳ tín hiệu đơn lẻ nào quyết định. Chỉ dựa vào uy tín sẽ không bắt được; phân tích liên kết cũng vậy, vì bước nhảy đầu là URL Google và trang cuối không tồn tại cho đến khi trình duyệt dựng nó. Thay vào đó, cách phát hiện cân nhắc chỉ báo kỹ thuật cùng ý định biểu kiến của thư, nơi liên kết thực sự kết thúc và quan hệ gửi phía sau.
Nơi phân tích cũng quan trọng. Cổng được xây để kiểm tra thư khi truyền không phù hợp với lời mời lịch, mà phần lớn chiến dịch này đến dưới dạng lời mời lịch. Lời mời lịch cần được coi là bề mặt đe dọa riêng, dùng toàn bộ lịch sử tài khoản làm ngữ cảnh bên cạnh tín hiệu kỹ thuật.
Thiệt hại nằm ở đâu
Một phiên bị chiếm để lại dấu vết trong nhật ký kiểm tra Google Workspace. Phiên trực tiếp chạm tới mail, Drive và khả năng cấp quyền OAuth dưới danh nghĩa nạn nhân, nên phạm vi ảnh hưởng vượt xa hộp thư.
Điều này đặt ra câu hỏi khó cho đội bảo mật: ai thực sự xem nhật ký kiểm tra, và hành động nhanh đến đâu? Đội có thể thu hồi phiên, khoanh vùng quyền OAuth và đặt lại tài khoản bị ảnh hưởng trong một giờ không? Nhiều chương trình không làm được, và kẻ tấn công giữ phiên trực tiếp có thể làm rất nhiều trong một giờ.
Operation CloudFire: nhắm vào hạ tầng
Đến cuối tháng 9, các nhà nghiên cứu quyết định rằng tinh chỉnh quy tắc, huấn luyện lại mô hình và cập nhật tác tử sẽ không giải quyết một mình. Phát hiện bảo vệ khách hàng nhưng không làm gì với kẻ vận hành đang chuẩn bị đợt tiếp theo. Vì vậy nhóm nhắm vào hạ tầng.
Các nhà phân tích lấy URL cổng và backend khi thư đang được gửi và báo cáo qua hệ thống báo cáo lạm dụng của Cloudflare. Đội ngũ của Cloudflare xác nhận trang xen giữa giả và trang đăng nhập Google qua proxy phía sau, rồi đặt cảnh báo lừa đảo của mình trước các đích đó.
Điều này có hai tác dụng. Thứ nhất, hạ tầng của kẻ tấn công bị đốt: mọi cổng và điểm cuối bị báo cáo phải đăng ký lại, trỏ lại và cấp chứng chỉ lại trước khi gửi tiếp. Thứ hai, nó bảo vệ nhiều người ngoài khách hàng của một công ty: ai nhấp vào liên kết bị báo cáo sẽ thấy trang cảnh báo thay vì biểu mẫu thông tin đăng nhập.
Một tháng qua các con số
Các số liệu chỉ bao gồm tổ chức đồng ý chia sẻ dữ liệu, nên tổng thực tế cao hơn. Trong một tháng của Operation CloudFire, các nhà nghiên cứu ghi nhận:
- 68.676 thư chiến dịch bị chặn
- 2.112 URL độc hại duy nhất được phân tích
- 897 tên miền duy nhất bị gỡ bỏ
- 8.570 địa chỉ người gửi bị xâm phạm duy nhất trên 6.354 tên miền gốc
Các thư cũng theo nhịp rõ ràng, gửi theo giờ làm việc của doanh nghiệp Mỹ.
Số lượng người gửi giải thích cách chiến dịch tạo được lòng tin. Kẻ tấn công kiểm soát từng tài khoản bị xâm phạm trước khi lời mời đầu tiên được gửi, và mỗi tài khoản gửi lời mời đến danh bạ đã lưu của chủ tài khoản. Người nhận thấy tên hoặc tên miền quen thuộc, trên tên miền có lịch sử sạch, vào thời điểm hợp lý trong ngày. Các nguồn uy tín không có lý do để gắn cờ.
Tình hình hiện tại
Chủ đề lừa đảo đã chuyển từ lời mời lịch sang lời mời chia sẻ tệp và tài liệu Google Drive. Các nhà nghiên cứu chưa thấy sự gia tăng tương ứng ở mồi nhử hay chiến thuật khác, và hoạt động của nhóm này dường như đã phân tán. Hiện tại chiến dịch có vẻ đã kết thúc.
Đó là một ảnh chụp nhanh và có thể thay đổi nhanh chóng. Xây lại hạ tầng rất rẻ, và khung tấn công đã công khai từ tháng 2. Kẻ vận hành cũng đã phát hành một nhánh Microsoft 365 chưa hoàn thiện song song với mã Google đang hoạt động. Nó gồm đường dẫn stylesheet, một bộ khung thứ hai và chuỗi tiêu đề giải mã thành lời nhắc đăng nhập Microsoft. Không đường dẫn nào hoạt động hôm nay, và thêm thương hiệu mới chỉ cần thả vào một tệp, không cần đổi mã. Đòn tiếp theo đã được xây sẵn và đang chờ.
Các nhà nghiên cứu coi việc luân chuyển chủ đề là quá trình lặp đi lặp lại và dự đoán lần chuyển hướng tiếp theo sẽ giống lần này, chỉ khác thương hiệu.
Nguồn: The Hacker News
Trích nguồn từ: The Hacker News
Tags:
Bài viết liên quan
Lỗ hổng MongoDB nghiêm trọng CVE-2026-118383: hai request từ kẻ chưa xác thực có thể làm sập server khi chuyển vai primary
MongoDB đã phát hành bản vá cho lỗ hổng use-after-free nghiêm trọng CVE-2026-118383, cho phép kẻ tấn công chưa xác thực gửi hai request khiến thành viên replica set bị sập khi đảm nhận vai primary.
Đọc thêm
Lỗ hổng nghiêm trọng trong Red Hat Quay cho phép đọc và ghi đè mọi container image riêng tư
Red Hat Quay dính hai lỗ hổng nghiêm trọng: kẻ tấn công có thể đọc, ghi đè image riêng tư trong mọi repository và đánh cắp token robot account của tenant khác. Bản vá đã phát hành cho tám nhánh Quay 3.
Đọc thêm
Hàng nghìn tài khoản GitHub bị chiếm đoạt để cài mã độc đánh cắp bí mật CI
Kẻ tấn công dùng thông tin đăng nhập của 4.837 tài khoản GitHub để cấy mã độc đánh cắp bí mật vào các quy trình CI, ảnh hưởng ít nhất 1.806 kho mã và hàng nghìn kho khác nhận commit độc hại.
Đọc thêm
Google Cloud cảnh báo ba lỗ hổng CPU AMD Turin có thể rò rỉ dữ liệu giữa các tiến trình trong VM
Google Cloud yêu cầu khách hàng dùng máy ảo trên chip AMD Turin cài bản vá hệ điều hành khách và khởi động lại máy để chống ba lỗ hổng kênh kề có thể làm lộ dữ liệu giữa các tiến trình.
Đọc thêm
SignDrop: Lỗ hổng zero-day biến tính năng bảo mật CLFS của Windows thành công cụ chiếm quyền SYSTEM
Mã khai thác công khai SignDrop lợi dụng cách driver CLFS tạo tệp đồng hành để nâng quyền từ người dùng thường lên SYSTEM; Microsoft chưa xác nhận, chưa cấp CVE hay phát hành bản vá.
Đọc thêm
Lỗ hổng nghiêm trọng trong Apache HTTP/2 có thể cho phép kẻ tấn công chưa xác thực thực thi mã từ xa
Lỗ hổng CVE-2026-119618 trong module mod_http2 của Apache HTTP Server ảnh hưởng các phiên bản 2.4.55 đến 2.4.70, được vá trong 2.4.71, cho phép kẻ tấn công chưa xác thực chiếm quyền điều khiển tiến trình máy chủ.
Đọc thêm
Node.js vá 16 lỗ hổng, gồm lỗi HTTP/2 làm sập máy chủ và rò rỉ dữ liệu kết nối khác
Node.js phát hành bản vá cho 16 lỗ hổng, trong đó có các lỗi HTTP/2 và HTTPS nghiêm trọng có thể khiến máy chủ bị sập hoặc làm lộ bộ nhớ, bao gồm cả khóa riêng TLS.
Đọc thêm
Railway bị đánh cắp khóa AI của khách hàng, thiệt hại ước tính 740.000 USD
Railway cho biết khóa API của các nhà cung cấp AI do khách hàng lưu trên nền tảng bị đánh cắp trong vụ xâm nhập tháng 10, gây ra khoản chi phí trái phép ước tính 740.000 USD, và công ty cam kết tự trả các khoản này khi nhà cung cấp AI không hoàn tiền
Đọc thêm
Xây một AI agent phá vỡ mọi quy tắc bảo mật: bài học về định danh và phân quyền
Token tạo ra agent Rehearsal chạy trong phiên đăng nhập của người dùng và phát hiện ba lỗ hổng cốt lõi về định danh, phạm vi truy cập và khả năng truy vết của AI agent.
Đọc thêm
Tin tặc nhắm vào máy chủ Qlik Sense bằng reverse shell, chuẩn bị khai thác ActiveMQ và Veeam
Nhóm tấn công đã thử triển khai lệnh reverse shell PowerShell nhắm vào máy chủ Qlik Sense trong tháng 10/2026, đồng thời chuẩn bị sẵn công cụ khai thác lỗ hổng ActiveMQ và Veeam.
Đọc thêm