Tấn công Magecart: Nguy hiểm đánh cắp dữ liệu thẻ

Một chiến dịch tấn công Magecart tinh vi và kéo dài đã hoạt động âm thầm trong hơn 24 tháng, lây nhiễm vào các trang web thương mại điện tử trên ít nhất 12 quốc gia.
Chiến dịch này sử dụng hơn 100 tên miền độc hại để đánh cắp dữ liệu thẻ thanh toán theo thời gian thực, gây thiệt hại tài chính nặng nề nhất cho các ngân hàng chứ không phải nhà bán lẻ.
Tổng quan chiến dịch Magecart và mục tiêu tấn công
Các nhà nghiên cứu bảo mật tại ANY.RUN đã phát hiện một hoạt động Magecart quy mô lớn, liên tục hoạt động từ đầu năm 2024.
Chiến dịch này đã lây nhiễm vào 17 trang web WooCommerce được xác nhận trong khoảng thời gian từ tháng 2 năm 2024 đến tháng 4 năm 2025.
Cơ sở hạ tầng của chiến dịch trải rộng trên hơn 100 tên miền, cho thấy mức độ đầu tư và lập kế hoạch nhất quán với tội phạm mạng có tổ chức, chứ không phải các vụ skim ngẫu nhiên.
Các nạn nhân được xác định ở Vương quốc Anh, Đan Mạch, Pháp, Tây Ban Nha và Hoa Kỳ. Đặc biệt, có một sự tập trung đáng kể ở Tây Ban Nha liên quan trực tiếp đến việc chiến dịch lạm dụng hệ sinh thái thanh toán Redsys.
Mặc dù các nhà bán lẻ thương mại điện tử là mục tiêu xâm nhập ban đầu, thiệt hại tài chính chính lại đổ lên các ngân hàng và chủ thẻ.
Dữ liệu thẻ bị đánh cắp thúc đẩy các hoạt động gian lận sau đó và làm xói mòn lòng tin của người tiêu dùng vào các hệ thống thanh toán kỹ thuật số. Những áp lực này do các tổ chức tài chính phải gánh chịu rất lâu sau khi skimmer bị gỡ bỏ.
Cơ chế tấn công và chuỗi lây nhiễm phức tạp
Hoạt động này sử dụng một chuỗi lây nhiễm nhiều lớp, nhiều giai đoạn, được thiết kế để gây khó khăn cho việc phát hiện và gỡ bỏ.
Giai đoạn 1: Chèn JavaScript Loader
Sau khi xâm nhập một trang WooCommerce, kẻ tấn công chèn một JavaScript loader nhỏ, bị xáo trộn vào một trong các tệp script hiện có của trang web.
Loader này không chứa logic đánh cắp thẻ riêng biệt. Thay vào đó, nó âm thầm kết nối với cơ sở hạ tầng bên ngoài, truy xuất một payload cấu hình JSON (được mã hóa dưới dạng mảng ký tự số) và tìm nạp giai đoạn độc hại tiếp theo một cách linh hoạt.
Loader còn có cơ chế dự phòng: nếu một tên miền staging không thể truy cập được hoặc bị chặn, nó sẽ tự động lặp qua một danh sách các tên miền dự phòng cho đến khi nhận được phản hồi hợp lệ.
Thiết kế này đảm bảo chiến dịch tiếp tục hoạt động ngay cả khi các thành phần riêng lẻ bị gỡ bỏ, đây là lý do chính khiến hoạt động không bị phát hiện trong hơn hai năm.
Giai đoạn 2: Giả mạo giao diện thanh toán
Payload giai đoạn hai được gửi từ các tên miền được tạo ra để giống các dịch vụ web hợp pháp, bao gồm các thư viện jQuery giả mạo, tài nguyên CDN và nền tảng phân tích.
Các ví dụ về tên miền giả mạo bao gồm: jquerybootstrap[.]com, newassetspro[.]com, và assetsbundle[.]com. Để hiểu rõ hơn về cách các thư viện giả mạo hoạt động, bạn có thể tham khảo thêm về các gói Packagist độc hại chứa jQuery trojanized.
Sau khi được tải, script độc hại sẽ chờ trang thanh toán xuất hiện, sau đó chiếm quyền điều khiển giao diện thanh toán, thay thế hoàn toàn hoặc phủ lên biểu mẫu thanh toán hợp pháp bằng một biểu mẫu giả mạo rất thuyết phục.
Kỹ thuật hiệu quả nhất của chiến dịch tấn công Magecart này là khả năng mạo danh chân thực các nhà cung cấp dịch vụ thanh toán đáng tin cậy.
Biến thể được ghi nhận nhiều nhất bắt chước Redsys, một bộ xử lý thanh toán được sử dụng rộng rãi ở Tây Ban Nha, bằng cách kết hợp tên miền Redsys hợp pháp sis.redsys.es vào luồng tấn công để tăng độ tin cậy.
Các giao diện của PayPlug SAS cũng đã được sao chép. Giao diện người dùng thanh toán giả mạo hỗ trợ nhiều ngôn ngữ (tiếng Anh, tiếng Tây Ban Nha, tiếng Ả Rập và tiếng Pháp), cho thấy một chiến lược nhắm mục tiêu toàn cầu có chủ ý chứ không phải cơ hội.
Một khi nạn nhân nhập thông tin thẻ của họ vào biểu mẫu giả mạo, payload sẽ truyền dữ liệu bao gồm BIN, số thẻ đầy đủ, ngày hết hạn và CVV.
Dữ liệu này không được gửi qua yêu cầu HTTP POST tiêu chuẩn mà qua một kênh WebSocket được mã hóa. Chi tiết phân tích có sẵn tại ANY.RUN Task Analysis.
Trong một trường hợp được ghi nhận, máy chủ điều khiển và chỉ huy (C2) được ngụy trang dưới dạng tên miền Redsys (redsysgate[.]com).
Phương pháp đánh cắp dữ liệu này được lựa chọn một cách có chủ đích: lưu lượng WebSocket thường bị bỏ qua bởi các công cụ giám sát an ninh mạng dựa trên HTTP thông thường, làm giảm khả năng phát hiện theo thời gian thực.
Trong một phần mở rộng đáng chú ý của bề mặt tấn công, cùng một payload độc hại cũng đóng vai trò là cơ chế phân phối tệp APK Android.
Khi người dùng truy cập các cửa hàng bị nhiễm trên thiết bị di động, script hiển thị một lời nhắc cung cấp giảm giá hoặc tiền thưởng để đổi lấy việc tải xuống một ứng dụng, kèm theo hướng dẫn bật cài đặt từ “Nguồn không xác định”.
Vector di động này được bản địa hóa ít nhất bốn ngôn ngữ, củng cố rằng cơ sở hạ tầng của chiến dịch được xây dựng có mục đích, không phải ngẫu hứng.
Các chỉ số thỏa hiệp (IOCs)
Các tên miền độc hại được liên kết với chiến dịch tấn công Magecart này bao gồm:
jquerybootstrap[.]comnewassetspro[.]comassetsbundle[.]comredsysgate[.]com(Máy chủ C2)
Biện pháp phòng ngừa và phát hiện
Chiến dịch này cho thấy sự trưởng thành của các cuộc tấn công Magecart, chuyển từ các vụ chèn mã cơ hội nhanh chóng sang các hoạt động dai dẳng, dựa trên cơ sở hạ tầng với khả năng điều khiển và chỉ huy theo thời gian thực.
Đối với các đội ngũ bảo mật, các ưu tiên phòng thủ chính bao gồm:
- Giám sát các kết nối WebSocket gửi đi từ các trang thanh toán.
- Thực thi Chính sách bảo mật nội dung (CSP) nghiêm ngặt.
- Triển khai giám sát tính toàn vẹn tệp JavaScript.
- Thực hiện kiểm tra định kỳ các script của bên thứ ba.
Đối với các tổ chức tài chính, việc chia sẻ thông tin tình báo về mối đe dọa chủ động và tăng cường phát hiện gian lận đối với các giao dịch không có thẻ vẫn là những biện pháp đối phó quan trọng chống lại loại mối đe dọa thanh toán dai dẳng và thích ứng này.







