Chiến Dịch Magecart Lợi Dụng Stripe Như Một Máy Chủ Lệnh Và Kho Dữ Liệu Hoàn Hảo

Một chiến dịch tấn công mạng tinh vi do Sansec và BleepingComputer công bố vào tháng 6 năm 2026 đã phơi bày cách các nhóm tin tặc Magecart biến chính cơ sở hạ tầng của Stripe thành một máy chủ điều khiển (C&C) dùng một lần và là điểm nhận dữ liệu đánh cắp . Điều đáng sợ là cuộc tấn công không bao giờ tải mã độc từ một tên miền lạ. Thay vào đó, bộ nạp, tải trọng skimmer và dữ liệu thanh toán bị đánh cắp đều di chuyển qua googletagmanager.com và api.stripe.com – hai tên miền thiết yếu đối với thương mại điện tử hiện đại đến mức hầu như không cửa hàng nào chặn hoặc kiểm tra kỹ lưỡng . Cùng thời điểm với chiến dịch này, một lỗ hổng bảo mật nghiêm trọng khác trong plugin WordPress Everest Forms Pro (định danh CVE-2026-3300) cũng đang bị khai thác tích cực, cho phép kẻ tấn công chưa được xác thực thực thi mã PHP tùy ý và chiếm quyền điều khiển các trang web dễ bị tấn công .

Cách thức hoạt động của cuộc tấn công Magecart qua Stripe

Chiến dịch kết nối ba giai đoạn, mỗi giai đoạn đều lạm dụng một dịch vụ hợp pháp để tránh bị phát hiện .

Giai đoạn 1: Tiêm bộ nạp qua Google Tag Manager

Trước tiên, kẻ tấn công xâm nhập một vùng chứa (container) của Google Tag Manager (GTM) trên trang web mục tiêu. Chúng chèn một thẻ (tag) độc hại, sẽ được tải trên mọi trang. Vì tập lệnh này xuất phát từ googletagmanager.com, một tên miền phân tích dữ liệu đáng tin cậy, nó dễ dàng vượt qua các Chính Sách Bảo Mật Nội Dung (Content Security Policy - CSP) và trình chặn quảng cáo mà không gây ra bất kỳ cảnh báo nào . GTM trở thành cơ chế phân phối không thể bị chặn.

Giai đoạn 2: Lấy mã skimmer từ API của Stripe

Thay vì gọi ra một máy chủ bên thứ ba đáng ngờ, thẻ GTM sẽ yêu cầu tải trọng skimmer từ api.stripe.com. Kẻ tấn công lưu trữ toàn bộ mã JavaScript đánh cắp dữ liệu bên trong một trường dữ liệu bổ sung (metadata) của Khách hàng trên chính tài khoản Stripe của chúng, sử dụng mã khóa bí mật (secret key) ở chế độ kiểm tra (sk_test_...) để ghi và truy xuất nó . Mã skimmer đến từ một tên miền mà các nhà vận hành cửa hàng mặc nhiên tin tưởng như một phần của hệ thống thanh toán, vì vậy các quy tắc giám sát mạng và CSP hiếm khi gắn cờ cuộc gọi API này.

Giai đoạn 3: Chuyển dữ liệu bị đánh cắp về lại tài khoản Stripe đó

Khi người mua hàng nhập chi tiết thẻ tín dụng, thông tin cá nhân và địa chỉ thanh toán lúc thanh toán, mã skimmer được tiêm vào sẽ thu thập dữ liệu và gửi trở lại tài khoản Stripe của kẻ tấn công. Nó ghi thông tin dưới dạng các bản ghi Khách hàng giả hoặc các mục dữ liệu bổ sung bằng cách sử dụng cùng một API của Stripe . Vì lưu lượng đánh cắp dữ liệu định tuyến thẳng trở lại api.stripe.com, nó hoàn toàn hòa lẫn vào các cuộc gọi API thanh toán hợp pháp, khiến hành vi trộm cắp về cơ bản là vô hình trước các nhật ký tường lửa và công cụ phát hiện bất thường .

Theo các chỉ báo mà các nhà nghiên cứu quan sát được, toàn bộ hoạt động này đã diễn ra ít nhất là từ ngày 24 tháng 12 năm 2025 .

Vì sao mã khóa bí mật ở chế độ kiểm tra lại nguy hiểm ở đây?

Mã khóa bí mật ở chế độ kiểm tra của Stripe (sk_test_...) cấp toàn quyền đọc và ghi trong môi trường sandbox và cho phép tạo không giới hạn các khách hàng giả cùng các trường dữ liệu bổ sung mà không tốn bất kỳ chi phí nào . Vì mã khóa kiểm tra không bao giờ kích hoạt các giao dịch thực, sự lạm dụng chúng rất dễ bị bỏ qua. Kẻ tấn công dựa vào thực tế là nhiều tổ chức coi mã khóa kiểm tra là có rủi ro thấp và không kiểm toán hoạt động trong sandbox với cùng mức độ nghiêm ngặt họ áp dụng cho lưu lượng thực tế.

Một mối đe dọa có liên quan nhưng riêng biệt là việc để lộ khóa bí mật trực tiếp (sk_live_...), điều này sẽ cho phép kẻ tấn công truy cập trực tiếp vào dữ liệu giao dịch thực và có khả năng phát hành hoàn tiền hoặc chuyển tiền . Mặc dù chiến dịch này sử dụng mã khóa chế độ kiểm tra vì tính ẩn mật, nguyên tắc cơ bản là giống nhau: mã khóa API Stripe, ở bất kỳ chế độ nào, đều là những thông tin xác thực mạnh mẽ và không bao giờ được xuất hiện trong mã phía máy khách (client-side) hoặc các vùng chứa của Google Tag Manager .

CVE-2026-3300: Lỗ hổng thực thi mã từ xa nghiêm trọng trong Everest Forms Pro

Trong khi chiến dịch Stripe nhắm mục tiêu vào các luồng thanh toán thương mại điện tử, các chủ sở hữu trang web WordPress phải đối mặt với một mối đe dọa cấp bách không kém từ lỗ hổng plugin đã bị khai thác tích cực kể từ ngày 13 tháng 4 năm 2026 .

CVE-2026-3300 là một lỗ hổng thực thi mã từ xa (Remote Code Execution - RCE) chưa được xác thực trong plugin Everest Forms Pro, có khoảng 4.000 lượt cài đặt đang hoạt động . Lỗ hổng này có điểm CVSS là 9,8 và ảnh hưởng đến tất cả các phiên bản từ 1.9.12 trở xuống .

Lỗi này nằm trong hàm process_filter() bên trong tiện ích bổ sung (add-on) Calculation. Khi tính năng "Complex Calculation" được bật, plugin này lấy các giá trị do người dùng cung cấp từ các trường biểu mẫu kiểu chuỗi, nối trực tiếp chúng vào một chuỗi mã PHP và truyền kết quả cho eval() mà không có biện pháp loại bỏ ký tự đặc biệt đúng cách . Hàm sanitize_text_field() được áp dụng cho đầu vào không thể trung hòa dấu nháy đơn hoặc các ký tự khác có ý nghĩa đặc biệt trong ngữ cảnh mã PHP, cho phép kẻ tấn công thoát ra khỏi chuỗi dự kiến và tiêm các lệnh tùy ý .

Wordfence đã chặn hơn 29.300 nỗ lực khai thác và báo cáo rằng những kẻ tấn công đang triển khai các tài khoản quản trị viên trái phép như một phần của quá trình hậu khai thác . Chủ sở hữu trang web nên tìm kiếm các dấu hiệu xâm nhập như người dùng quản trị mới với tên không mong muốn, các tệp tin lạ trên máy chủ hoặc các kết nối ra ngoài đáng ngờ .

Các biện pháp phòng thủ cho cả hai mối đe dọa

Ngăn chặn chuỗi tấn công Magecart qua Stripe

• Khóa chặt Google Tag Manager. Hạn chế các vùng chứa GTM chỉ ở những thẻ đã được phê duyệt và kiểm toán, đồng thời yêu cầu quy trình phê duyệt quản lý thay đổi nghiêm ngặt trước khi xuất bản .
• Thắt chặt Chính Sách Bảo Mật Nội Dung (CSP). Không liệt kê api.stripe.com như một script-src trừ khi thực sự cần thiết. Nếu bạn buộc phải đưa vào, hãy thực thi các hàm băm toàn vẹn tài nguyên con (Sub-Resource Integrity - SRI). Việc chặn các tập lệnh nội tuyến (inline script) cung cấp thêm một lớp phòng thủ .
• Kiểm toán hoạt động trong sandbox của Stripe. Theo dõi bảng điều khiển Stripe của bạn để phát hiện khối lượng bất thường của việc tạo đối tượng Khách hàng hoặc ghi dữ liệu bổ sung bằng mã khóa chế độ kiểm tra. Hãy coi trọng các điểm bất thường trong sandbox như các điểm bất thường ở chế độ trực tiếp.
• Xoay vòng và bảo vệ mã khóa API. Không bao giờ nhúng mã khóa bí mật của Stripe – dù là kiểm tra hay trực tiếp – vào JavaScript phía máy khách, các biến GTM hoặc kho lưu trữ công khai . Hãy xoay vòng bất kỳ mã khóa nào có thể đã bị lộ .
• Triển khai giám sát phía máy khách. Sử dụng các công cụ kiểm tra tính toàn vẹn phía trình duyệt để phát hiện sự thao túng DOM trên các trang thanh toán bởi các tập lệnh trái phép .

Vá lỗ hổng trong Everest Forms Pro

• Cập nhật ngay lập tức. Nâng cấp lên Everest Forms Pro phiên bản 1.9.13 hoặc mới hơn, phiên bản có chứa bản sửa lỗi .
• Vô hiệu hóa tính năng rủi ro nếu việc vá lỗi bị trì hoãn. Như một giải pháp tạm thời, hãy tắt tính năng "Complex Calculation" trong cài đặt plugin để ngăn chặn việc khai thác thông qua đầu vào eval() không được loại bỏ ký tự đặc biệt .
• Quét tìm dấu hiệu xâm nhập. Tìm kiếm các tài khoản quản trị không xác định, tệp tin lạ, các lệnh gọi eval() đáng ngờ và kết nối mạng ra ngoài đến các IP không quen thuộc. Việc kiểm tra tính toàn vẹn toàn bộ WordPress dựa trên tổng kiểm tra (checksum) của tệp lõi, giao diện và plugin sau khi khắc phục là rất cần thiết .