Nguy Cơ & Kịch Bản Tấn Công SMS Qua SS7

Phân Tích Case: “Không gửi tin nhắn nhưng mạng lưới ghi nhận số khác đã nhận SMS từ tôi”

0. Mô Tả Case & Khung Phân Tích

Hiện tượng quan sát được:

• Thuê bao không chủ động gửi SMS.
• Trên mạng lưới ghi nhận một số điện thoại khác đã nhận được tin nhắn đứng tên thuê bao.
• IMEI đúng (khớp thiết bị thật).
• IMSI đúng (khớp SIM thật).
• GT (Global Title) hợp lệ trong log báo hiệu.
• OCS ghi nhận đầy đủ và đúng trình tự luồng CAP (InitialDPSMS → ContinueSMS → EventReportSMS).

Vì sao đây là dấu hiệu bất thường nghiêm trọng: Đây không phải là lỗi hiển thị hay lỗi đồng bộ dữ liệu thông thường. Việc OCS ghi nhận đúng luồng CAP hợp lệ đồng nghĩa có một giao dịch CAMEL thực sự đã được một node nào đó khởi tạo với các tham số định danh (IMSI, MSISDN) trùng khớp thuê bao — hệ thống không có cách nào ở tầng CAP để phân biệt “đây là chính chủ” hay “đây là ai đó mạo danh nhưng đúng tham số”. Nói cách khác: mọi lớp kiểm tra nghiệp vụ (charging) đã pass, nên vấn đề nằm ở tầng thấp hơn — nơi hệ thống tin tưởng nguồn gửi mà không xác thực được danh tính thực sự.

Tài liệu này đi từ bản tin nào trong luồng SMS có thể bị lợi dụng → kịch bản tấn công cụ thể khớp với 4 dấu hiệu trên → cách phân biệt với các nguyên nhân khác → cách xác minh và xử lý.

1. Các Bản Tin Trong Luồng SMS Có Thể Bị Khai Thác

Đối chiếu với case: nếu tấn công xảy ra, nó phải đi qua ít nhất một trong các bản tin dưới đây — vì đây là toàn bộ “bề mặt tấn công” của luồng SMS ở tầng SS7.

1.1 Nhóm bản tin liên quan trực tiếp đến case (MO-SMS & Tính cước — CAP)

1.2 Nhóm bản tin hỗ trợ tấn công (không xuất hiện trực tiếp trong log OCS nhưng là điều kiện cần)

1.3 Tổng kết mức độ liên quan đến case của bạn

2. Giả Thuyết Chính: SS7 Spoofing / MAP Injection

Đây là giả thuyết khớp nhất với 4 dấu hiệu quan sát được trong case của bạn, vì nó là dạng tấn công duy nhất giải thích được đồng thời: IMEI đúng + IMSI đúng + GT hợp lệ + OCS ghi đúng luồng — mà không cần kẻ tấn công có SIM vật lý hay lây nhiễm được thiết bị của bạn.

2.1 Định nghĩa

SS7 Spoofing / MAP Injection là dạng tấn công trong đó kẻ tấn công — có được quyền truy cập vào mạng báo hiệu liên mạng (thông qua interconnect hợp pháp bị lạm dụng, GRX/IPX bị xâm nhập, node SS7 bị compromise, hoặc dịch vụ “SS7 access” mua trên thị trường ngầm) — tự soạn và gửi thẳng bản tin MAP/CAP hợp lệ về mặt cú pháp (đúng chuẩn TCAP/SCCP) nhưng giả mạo danh tính nguồn (Global Title, Point Code, hoặc tham số nghiệp vụ như IMSI/MSISDN) mà không cần đi qua access network thật (BTS/BSS/RNC) của thuê bao nạn nhân.

Điểm mấu chốt khiến dạng tấn công này nguy hiểm: các node lõi (HLR, VMSC, OCS) không có cơ chế xác thực nguồn gốc bản tin ở tầng SS7 truyền thống — SCCP GT về bản chất chỉ là một trường địa chỉ logic, hoàn toàn có thể bị đặt tùy ý bởi node gửi, tương tự như giả mạo IP source trong mạng IP truyền thống trước khi có các cơ chế lọc.

2.2 Đối chiếu từng dấu hiệu của case với cơ chế MAP Injection

2.3 Kịch bản tấn công điển hình khớp với case (từng bước)

Bước 1: Kẻ tấn công gửi MAP SendRoutingInfoForSM giả mạo GT
        --> HLR trả về IMSI thật + VMSC hiện tại của bạn
        (Thu thập thông tin định danh - có thể đã xảy ra
         trước đó mà không để lại dấu vết trong log OCS)

Bước 2 (tùy biến thể, không phải lúc nào cũng có):
        Kẻ tấn công gửi MAP UpdateLocation giả mạo
        --> HLR cập nhật nhầm "VLR hiện tại" sang node
            kẻ tấn công kiểm soát
        (Chiếm quyền định tuyến - session hijack)

Bước 3: Kẻ tấn công gửi CAP InitialDPSMS + MAP MO-ForwardSM
        giả mạo SM-RP-OA = IMSI của bạn
        --> OCS/SCP xử lý như giao dịch hợp lệ, ghi đúng luồng CAP
            (ĐÂY LÀ ĐIỂM KHỚP TRỰC TIẾP VỚI CASE CỦA BẠN)
        --> Số nhận (SĐT lạ) nhận được "tin nhắn" mà bạn
            không hề gửi

Bước 4: Nếu cần che giấu dấu vết, kẻ tấn công gửi kèm
        MAP MO-ForwardSM Ack giả để đồng bộ trạng thái các node

Nhận xét quan trọng: Nếu điều tra không tìm thấy UpdateLocation lạ trước sự cố, điều đó không loại trừ MAP Injection — ngược lại, nó còn củng cố giả thuyết này, vì kỹ thuật tinh vi thường bỏ qua bước UpdateLocation (không cần thiết lập phiên VLR thật) để giảm dấu vết và giảm độ trễ tấn công.

2.4 Vì sao “IMEI đúng” không phải bằng chứng loại trừ tấn công (IMEI Spoofing)

IMEI có thể bị giả mạo ở hai tầng khác nhau, cả hai đều liên quan đến case này:

Lý do gốc rễ: IMEI không được bảo vệ bằng cơ chế mật mã học gắn với phần cứng như IMSI/Ki trong SIM. Mạng lõi (VMSC/HLR/OCS) không có cách xác thực mật mã học để kiểm tra “IMEI này có thực sự đến từ modem vật lý đó hay không”, trừ khi chủ động đối chiếu real-time với EIR (Equipment Identity Register) và lịch sử ghép cặp IMEI-IMSI.

Hệ quả cho phân tích case: Việc IMEI đúng không giúp phân biệt giữa MAP Injection và SIM Cloning (kèm giả mạo IMEI) — cả hai đều có thể tạo ra dấu hiệu này. Điểm phân biệt thực sự nằm ở mục 3 bên dưới.

3. Các Giả Thuyết Khác Cần Loại Trừ

Dù MAP Injection là giả thuyết khớp nhất, cần đối chiếu có hệ thống để loại trừ các khả năng khác trước khi kết luận. Lưu ý quan trọng: như phân tích ở mục 2.4, “IMEI đúng” không còn là tiêu chí phân biệt đáng tin cậy giữa các giả thuyết — vì IMEI có thể bị spoof ở cả hai hướng tấn công. Điểm phân biệt thực sự đã chuyển sang việc có tồn tại phiên xác thực AuC (Authentication Center) hợp lệ hay không.

3.1 Điểm phân biệt quyết định: Phiên xác thực AuC

SIM Cloning và MAP Injection giờ đây không còn phân biệt được bằng IMEI, vì cả hai đều có thể tạo ra IMEI “đúng”. Sự khác biệt căn bản nằm ở một bước mà SIM Cloning buộc phải đi qua nhưng MAP Injection có thể bỏ qua hoàn toàn:

• SIM Cloning: SIM giả (dù cài trong thiết bị đã spoof IMEI) vẫn phải xác thực thành công với AuC bằng đúng Ki đã trích xuất được, thông qua quy trình chuẩn: Attach Request → Authentication Request/Response (thách thức RAND/SRES hoặc AKA) → UpdateLocation được HLR chấp nhận. Đây là “cửa chính” của mạng mà kẻ tấn công không thể bỏ qua, vì không có Ki đúng thì không authenticate được.
• MAP Injection: Kẻ tấn công tiêm thẳng bản tin MO-ForwardSM/InitialDPSMS vào lõi mạng qua interconnect, hoàn toàn không cần đi qua bước Attach/Authentication nào — vì các node lõi (VMSC/OCS) xử lý bản tin MAP/CAP như đến từ một VMSC hợp lệ khác, không yêu cầu xác thực lại access-layer.

→ Do đó, câu hỏi quyết định khi điều tra là: “Có bản ghi Authentication Request/Response và UpdateLocation THÀNH CÔNG với AuC ngay trước giao dịch MO không?”

• Có → nghiêng mạnh về SIM Cloning (kèm hoặc không kèm IMEI spoofing)
• Không có, hoặc bản tin MO xuất hiện “từ hư không” → nghiêng mạnh về MAP Injection

3.2 Bảng đối chiếu chẩn đoán nhanh (đã cập nhật)

Kết luận cập nhật: SIM Cloning vẫn là một nguy cơ hoàn toàn hiện hữu, không bị loại trừ bởi việc IMEI khớp đúng. Việc điều tra cần chuyển trọng tâm từ “đối chiếu IMEI” sang “tìm bằng chứng có/không có phiên Authentication+UpdateLocation hợp lệ với AuC ngay trước giao dịch MO” — đây mới là tiêu chí phân biệt đáng tin cậy giữa hai giả thuyết.

4. Cách Xác Minh Cụ Thể Cho Case Này

Thực hiện theo thứ tự ưu tiên — bắt đầu từ việc dễ kiểm tra nhất để loại trừ nhanh, sau đó tập trung vào tiêu chí phân biệt quyết định (mục 3.1):

1. Loại trừ malware trước tiên: Kiểm tra thiết bị (quét malware, xem lịch sử gửi SMS thực tế trên máy, kiểm tra ứng dụng lạ có quyền SMS). Nếu log gửi trên chính máy không có gì bất thường → loại trừ, chuyển sang điều tra mạng lõi.
2. Kiểm tra có phiên Authentication Request/Response thành công với AuC ngay trước giao dịch MO không — đây là bước quyết định (xem mục 3.1). Có → nghiêng về SIM Cloning. Không có/bản tin MO xuất hiện đột ngột → nghiêng về MAP Injection.
3. Kiểm tra có UpdateLocation hợp lệ ngay trước giao dịch MO không — đây là hệ quả tất yếu nếu bước 2 có kết quả “Có”.
4. So khớp VLR/VMSC ghi trong CDR của giao dịch MO-ForwardSM với vị trí thực tế bạn đang ở tại thời điểm đó. Nếu VMSC ghi nhận khác hoàn toàn khu vực bạn đang ở → dấu hiệu mạnh của MAP Injection (SIM Cloning thường khớp với một khu vực địa lý cụ thể, ổn định).
5. Đối chiếu GT nguồn của MO-ForwardSM/InitialDPSMS với danh sách GT hợp lệ của các VMSC/VLR thuộc mạng bạn — nếu GT thuộc một mạng roaming/đối tác không tương ứng với vị trí bạn đang ở, gần như chắc chắn là spoofing.
6. Kiểm tra Calling Party SCCP Address vs Point Code thực tế trong log STP — nhiều vụ MAP Injection dùng GT hợp lệ nhưng Point Code (địa chỉ vật lý thực) lại thuộc một node hoàn toàn khác trong chuỗi interconnect.
7. Đối chiếu lịch sử IMEI-IMSI pairing (EIR) — lưu ý: bước này không dùng để phân biệt SIM Cloning vs MAP Injection (vì cả hai đều có thể có IMEI đúng), chỉ hữu ích để loại trừ khả năng là một thiết bị hoàn toàn khác đang dùng chung IMEI một cách tình cờ/trùng lặp.
8. Nếu mạng có SS7 Firewall (GSMA FS.11): kiểm tra log Category 1 (bản tin không nên đến từ interconnect), Category 2 (bản tin không nhất quán với vị trí đã biết của thuê bao), Category 3 (bản tin không hợp logic nghiệp vụ) — case dạng này thường rơi vào Category 2.

5. Hướng Xử Lý Ngay

1. Chặn/reset thuê bao tạm thời (Barring hoặc AuC re-key nếu nghi SIM clone) để cắt đứt phiên đang bị lạm dụng, ngăn giao dịch tiếp theo xảy ra trong lúc điều tra.
2. Đối chiếu UpdateLocation history trong HLR/HSS như mục 4 — nếu thấy VLR khác vừa đăng ký thuê bao ngay trước sự cố, gần như chắc chắn là SIM clone hoặc MAP-based location spoofing.
3. Kiểm tra SS7 Firewall (nếu mạng có triển khai) xem có rule nào bị bỏ sót cho phép InitialDPSMS/MO-ForwardSM đến từ GT ngoài whitelist.
4. Nếu xác định là MAP Injection từ đối tác interconnect — đây là lỗ hổng ở tầng liên mạng, cần làm việc với GTT/STP để chặn GT nguồn cụ thể và báo cáo lên GSMA (IR.82 fraud reporting).

6. Biện Pháp Phòng Ngừa Dài Hạn Ở Cấp Mạng

Để tránh case tương tự tái diễn trong tương lai, không chỉ với thuê bao này mà toàn mạng.

Tham chiếu chéo: Tài liệu này nên đối chiếu cùng file tong-hop-bao-hieu-ss7-sms.md (chứa sơ đồ luồng SS7 đầy đủ, danh sách báo hiệu MAP/CAP, và các chuẩn 3GPP/ITU-T liên quan) để có bức tranh đầy đủ về cả kiến trúc luồng lẫn phân tích rủi ro của case này.