Một ngón tay chỉ vào cửa sổ hiển thị người gửi với địa chỉ Reply-To khác với From trên một yêu cầu chuyển tiền khẩn cấp

read receipts

Email Header Này Gửi Reply của Bạn Trực Tiếp Đến Tay Kẻ Trộm

Thỏa hiệp email kinh doanh hiếm khi cố gắng giả mạo người gửi. Nó chỉ thay đổi một trường mà inbox của bạn lịch sự che giấu.

·3 phút đọc

Đây là một vụ lừa đảo tốn cho các doanh nghiệp Mỹ nhiều tiền hơn ransomware, malware và các vi phạm dữ liệu cộng lại, và nó thường không liên quan đến bất kỳ malware nào cả. Không có liên kết độc hại. Không có tệp đính kèm bị nhiễm. Không có gì để antivirus bắt được. Chỉ là một email trông giống như đến từ CFO của bạn, và một câu trả lời mà yên tĩnh đi đến một chỗ khác.

Chỗ khác đó chính là mẹo khoá. Và nó nằm trong một trường tiêu đề mà hầu như không có client email nào hiển thị cho bạn.

Trường đó gọi là Reply-To. Nó đã là một phần của tiêu chuẩn mail internet từ đầu — RFC 5322 định nghĩa nó là địa chỉ nơi các phản hồi "nên" đi, riêng biệt với địa chỉ From. Trong cách sử dụng hợp pháp nó tẻ nhạt và hữu ích. Một bản tin được gửi từ noreply@company.com nhưng đặt Reply-To thành support@company.com để các câu hỏi của bạn được tiếp nhận bởi một người thực. Đó là tất cả. Đó là công việc trung thực.

Thỏa hiệp email kinh doanh biến tiện lợi đó thành một vũ khí. Thay vì công việc khó và kỹ thuật của việc giả mạo một địa chỉ From — điều này kích hoạt báo động SPF, DKIM và DMARC và bị đánh dấu — kẻ tấn công chỉ đăng ký một miền giống như hoặc một Gmail vứt đi. Sau đó họ đặt tên hiển thị thành "Karen Vasquez, CFO" để inbox của bạn hiển thị một tên con người quen thuộc in đậm. Địa chỉ From thực tế có thể là karen.vasquez.finance@gmail.com, nhưng bạn không thấy cái đó; bạn thấy "Karen Vasquez." Và quan trọng nhất, họ đặt Reply-To thành một địa chỉ họ kiểm soát.

Vì vậy bạn đọc email. Nó ngắn, hợp lý, một chút khẩn cấp. "Bạn có ở bàn không? Tôi cần bạn xử lý một chuyển khoản trước khi ngân hàng đóng cửa." Bạn nhấn reply. Client của bạn, vì hữu ích, gửi phản hồi của bạn tới Reply-To — không phải From. Bây giờ bạn đang nói chuyện với kẻ tấn công, và mỗi tin nhắn bạn gửi xác nhận rằng bạn đã rơi vào bẫy.

Quy mô ở đây không phải là một sai số làm tròn. Trung tâm Khiếu nại Tội phạm Internet của FBI ghi nhận $2.9 billion tổn thất BEC được báo cáo chỉ trong năm 2023, trên 21,000 khiếu nại. Đó là con số được báo cáo, từ những người nhận thấy và nộp đơn. Con số thực tế lớn hơn, bởi vì một chuyển khoản được thanh toán trông giống như một thứ ba bình thường cho đến khi đối chiếu.

Điều làm cho vấn đề này khó chịu là cách phòng chống nằm đúng ở đó và bị ẩn. Mỗi mail client biết giá trị Reply-To. Hầu như không có cái nào hiển thị nó. Gmail thu gọn người gửi thành một tên hiển thị và một dấu mũi tên nhỏ mà bạn phải nhấp vào. Outlook che giấu các địa chỉ thực tế dưới "View source" hoặc một hộp thoại thuộc tính mà hầu hết mọi người chưa bao giờ mở. Trường duy nhất tiết lộ trò lừa là trường duy nhất mà giao diện coi là rác rưởi.

Vì vậy hãy tập thói quen. Trước khi bạn trả lời bất kỳ thứ gì liên quan đến tiền, thay đổi chi tiết ngân hàng hoặc khẩn cấp, mở rộng header. Trong Gmail, nhấp vào mũi tên xuống bên cạnh tên người gửi và đọc dòng "reply-to" thực tế. Nếu From nói một điều và Reply-To chỉ vào một hộp thư khác, dừng lại. Sự không khớp đó hiếm khi là vô tội trong một email tài chính.

Tốt hơn nữa, đừng trả lời cả. Bắt đầu một tin nhắn mới cho địa chỉ bạn đã lưu cho người đó, hoặc gọi điện thoại bằng một số mà bạn không nhận được từ email. Kẻ tấn công dựa vào việc bạn ở trong chuỗi họ xây dựng.

Sự thanh lịch u ám của vụ lừa đảo này là nó vượt qua mọi kiểm tra tự động bằng cách không vi phạm bất kỳ quy tắc nào. Địa chỉ From về mặt kỹ thuật là thực tế. Tên miền xác thực tốt. Không có gì bị giả mạo. Lời nói dối không nằm trong đường ống — nó nằm trong dòng duy nhất mà phần mềm của bạn quyết định rằng bạn không cần thấy.

Reported BEC losses in the U.S., 2023 (FBI IC3)

Nguồn

  1. FBI IC3 — 2023 Internet Crime Report, BEC loss figures
  2. IETF RFC 5322 — Internet Message Format spec defining the Reply-To header field
  3. CISA — Guidance on social engineering and verifying sender identity

← Tất cả bài viết