Skip to main content

Chiến dịch Magecart 15 tháng và 953 nạn nhân: Bài học đắt giá về "vòng lặp tái nhiễm" trong bảo mật bán lẻ

Updated 22 min readMarkdown
Chiến dịch Magecart 15 tháng và 953 nạn nhân: Bài học đắt giá về "vòng lặp tái nhiễm" trong bảo mật bán lẻ

Tóm Tắt Chiến Dịch

Ít nhất 953 cửa hàng trực tuyến trên toàn cầu - phần lớn vận hành trên nền tảng Magento và Adobe Commerce đã bị xâm nhập trong một chiến dịch gián điệp thương mại điện tử (e-skimming/Magecart) quy mô lớn hoạt động liên tục từ tháng 7/2025 đến nay. Báo cáo phân tích mới nhất do hãng bảo mật Sansec công bố vào ngày 24/10/2026 chỉ ra rằng nhóm tin tặc đã luân chuyển hạ tầng qua 5 tên miền độc hại trong 15 tháng, liên tục cập nhật mã độc nhằm né tránh các công cụ phân tích tự động.

Thay vì sửa đổi file mã nguồn hay can thiệp vào các tệp cấu hình truyền thống (core_config_data), kẻ tấn công bí mật chèn mã tải JavaScript (loader) trực tiếp vào bảng cms_block của cơ sở dữ liệu MySQL. Khi trang web kết xuất nội dung tĩnh (banner, header, footer), loader sẽ âm thầm thu thập dấu vân tay trình duyệt (browser fingerprinting) bao gồm WebGL GPU renderer, thông số phần cứng, thuộc tính ChromeDriver/Selenium để phân biệt người mua hàng thật với bot quét an ninh. Nếu phát hiện công cụ rà quét, máy chủ điều khiển (C2) sẽ trả về phản hồi rỗng hoặc vô hại.

Đôi Nét Về Hệ Sinh Thái Magento & Adobe Commerce

Lịch sử phát triển và phân nhánh sản phẩm

  • Giai đoạn khởi nguyên (2008 – 2011): Magento ra đời năm 2008 bởi công ty Varien (Mỹ), nhanh chóng tạo nên cơn sốt nhờ mã nguồn mở linh hoạt và kiến trúc mô-đun vượt trội so với osCommerce lúc bấy giờ.
  • Giai đoạn eBay (2011 – 2015): eBay thâu tóm Magento nhằm phục vụ chiến lược thanh toán PayPal và khởi động dự án đại tu kiến trúc toàn diện Magento 2.
  • Thương vụ lịch sử của Adobe (2018): Tháng 5/2018, Adobe chính thức mua lại Magento với giá 1,68 tỷ USD, đổi tên dòng sản phẩm thương mại thành Adobe Commerce, biến nền tảng này thành hạt nhân xử lý giao dịch trong bộ giải pháp Adobe Experience Cloud.

Kiến trúc kỹ thuật và Lý do Magento luôn là "miếng mồi kim cương" của Magecart

Về mặt công nghệ, Magento là một kiến trúc phức tạp vận hành trên:

  • Ngôn ngữ: PHP (PHP 8.1 - 8.3).
  • Cơ sở dữ liệu: MySQL / MariaDB.
  • Tối ưu hiệu năng: Redis (lưu session và cache), Varnish Cache (HTTP reverse proxy tăng tốc trang), Elasticsearch / OpenSearch (công cụ tìm kiếm và lọc danh mục).

Quy Mô & Hạ Tầng Luân Chuyển 5 Tên Miền Trong 15 Tháng

Hạ tầng C2 của chiến dịch được thiết kế theo mô hình xoay vòng định kỳ (domain cycling). Cứ sau 3 đến 5 tháng khi tên miền cũ bị các hệ sinh thái bảo mật hoặc báo cáo CSP (Content Security Policy) gắn cờ độc hại thì lập tức kẻ tấn công lại kích hoạt một tên miền mới và thực hiện cập nhật hàng loạt cơ sở dữ liệu của các nạn nhân đã chiếm quyền kiểm soát từ trước.

Chi tiết 5 tên miền trọng tâm được Sansec theo dõi từ tháng 07/2025 đến tháng 10/2026:

Tên miền Thời điểm đăng ký Phát hiện đầu tiên trên store Số lượng store ghi nhận Trạng thái hiện tại
manulfie.click Trước 07/2025 (Re-reg: 23/05/2026) 09/07/2025 863 Hết hạn, bị bên thứ ba mua lại (Parked trên abovedomains.com)
neswnsssn.click Trước 12/2025 (Re-reg: 22/05/2026) 12/12/2025 494 Hết hạn, bị bên thứ ba mua lại (Parked trên abovedomains.com)
lanhd6549tdhse.top 25/03/2026 30/03/2026 355 Bùng phát trong làn sóng tấn công PolyShell (471 store/giờ)
additionalver.com 07/06/2026 08/06/2026 246 Sử dụng nền tảng Keitaro TDS, ghi nhận ~52.000 báo cáo CSP
deepveindrilling.com 06/10/2026 07/10/2026 83 Đang hoạt động, ẩn sau Cloudflare, tự tích hợp fingerprinting

Ngoài 5 tên miền chính, hệ thống giám sát còn ghi nhận 2 tên miền phụ hoạt động song song ở quy mô nhỏ hơn là hdfdsi84j3h.top (được đăng ký chỉ 3 phút sau tên miền lanhd6549tdhse.top) và c85grt98sd.com.

Một phát hiện đặc biệt nguy hiểm từ dữ liệu telemetry: Hai tên miền ban đầu (manulfie.click và neswnsssn.click) sau khi hết hạn đã được một dịch vụ lưu trữ tên miền (domain parking) thu mua lại vào tháng 5/2026 và chuyển nameserver về abovedomains.com. Tuy nhiên, tính đến tháng 10/2026, Sansec vẫn phát hiện 15 cửa hàng chưa hề dọn dẹp mã độc cũ (9 store chứa manulfie.click và 6 store chứa neswnsssn.click). Trình duyệt của khách hàng truy cập các website này tiếp tục gửi thông tin tiêu đề trang (page title) và địa chỉ giới thiệu (referrer) tới chủ sở hữu mới của domain, đồng thời thực thi bất kỳ script nào mà máy chủ bên thứ ba phản hồi — tạo ra lỗ hổng chuỗi cung ứng thứ cấp cực kỳ khó lường.

Phân Tích Kỹ Thuật Chi Tiết

Chiến dịch không phải là một đợt tấn công chớp nhoáng mà là một chuỗi hoạt động kéo dài, kết hợp nhuần nhuyễn giữa khai thác lỗ hổng máy chủ web để chiếm quyền điều khiển ban đầu, cắm chốt nhiều tầng cửa sau, và biến chính cơ sở dữ liệu CMS thành bệ phóng mã độc phía máy khách (Client-side Skimmer).

Phase 1: Initial Access — Vũ khí hóa lỗ hổng N-day PolyShell & SessionReaper

Phân tích pháp y trên các máy chủ bị nhiễm cho thấy chiến dịch này không cần dùng tới lỗ hổng zero-day trong đợt triển khai tháng 10/2026. Thay vào đó, kẻ tấn công tận dụng các lỗ hổng tải tệp tin và leo thang đặc quyền nghiêm trọng đã được công bố trước đó nhưng chưa được vá triệt để.

1. PolyShell (CVE-2026-48356 / Adobe Security Bulletin APSB26-73):
Đây là lỗ hổng upload file không hạn chế (Unrestricted File Upload) nằm trong cơ chế xử lý tệp tùy chọn tùy chỉnh (custom_options) của Magento. Kẻ tấn công gửi các yêu cầu HTTP giả mạo tải lên tệp ảnh hợp lệ nhưng thực chất là mã PHP độc hại được nhúng trong cấu trúc tệp ảnh (polyglot file). Mã độc được lưu tại đường dẫn:

pub/media/custom_options/quote/

pub/media/customer_address/

Tại đây, tệp webshell ngụy trang dưới đuôi .png hoặc .jpg nhưng có thể được gọi trực tiếp qua web để thực thi mã lệnh từ xa với quyền hạn của tiến trình web server (www-data hoặc nginx). Vào ngày 30/03/2026, nhóm tin tặc đã sử dụng kịch bản khai thác tự động PolyShell để tấn công đồng loạt và cắm loader vào 471 cửa hàng chỉ trong 60 phút.

2. SessionReaper (CVE-2025-54236 / Adobe Security Bulletin APSB25-88):
Lỗ hổng xử lý session cho phép vượt qua cơ chế xác thực và can thiệp trái phép vào phiên làm việc của quản trị viên.

Thống kê từ Sansec trên 169 máy chủ cài đặt Magento 2 bị phát hiện có loader và thiếu ít nhất một bản vá cốt lõi: 102 máy chủ (chiếm 60%) chứa các tệp mã độc được tải lên thông qua PolyShell hoặc SessionReaper. Trong khi đó, tỷ lệ này ở các máy chủ bị nhiễm mã độc skimmer khác chỉ là 32%, chứng minh PolyShell và SessionReaper là hai "vũ khí mở đường" đặc trưng của nhóm tấn công này.

Phase 2: Multi-layer Persistence - Chiến lược 'Chân vạc' 3 tầng cắm chốt

Để đảm bảo duy trì quyền truy cập lâu dài và chống lại các nỗ lực dọn dẹp sự cố thông thường của chủ website, nhóm tin tặc đã triển khai chiến lược cắm chốt "chân vạc" ở 3 tầng kiến trúc độc lập:

1. Tầng Hệ điều hành (OS-Level Reverse Shell):
Cài cắm công cụ GSocket backdoor. GSocket tạo ra một đường hầm mã hóa hai chiều từ máy chủ nạn nhân đi ra mạng proxy toàn cầu (Global Relay Network). Do kết nối xuất phát từ trong máy chủ đi ra (outbound traffic) qua cổng HTTPS tiêu chuẩn, hầu hết các tường lửa biên (Stateful Firewall) đều cho phép đi qua, cung cấp cho kẻ tấn công quyền truy cập shell tương tác bất cứ lúc nào mà không cần mở port lắng nghe.

2. Tầng Xác thực Ứng dụng (Application-Level Rogue Admin):
Kẻ tấn công thực thi truy vấn SQL chèn trực tiếp một tài khoản quản trị viên mới vào bảng admin_user. Tài khoản này được cấu hình quyền hạn cao nhất (role_id = 1), cho phép kẻ tấn công đăng nhập hợp lệ qua giao diện quản trị Magento Admin mà không cần thông qua bước khai thác lỗ hổng phần mềm.

3. Tầng Tệp tin Ẩn giấu (Filesystem Backdoors):
Ngoài webshell dạng ảnh polyglot trong pub/media/, kẻ tấn công còn để lại các tệp backdoor PHP độc lập như accesson.php nằm rải rác trong cây thư mục mã nguồn.

Phase 3: Database Staging - Biến bảng cms_block thành bệ phóng ngầm

Một trong những đặc điểm nổi bật nhất của chiến dịch này là vị trí cắm chốt của mã độc. Thông thường, các nhóm Magecart hay can thiệp vào:

  • File mã nguồn PHP hoặc file JavaScript của giao diện (app/design/frontend/...).
  • Bảng cấu hình hệ thống core_config_data (ví dụ: trường design/head/includes hoặc design/footer/absolute_footer).

Tuy nhiên, trong chiến dịch này, trên tất cả 148 ca can thiệp server do công cụ chuyên dụng eComscan giám sát, mã tải JavaScript chỉ xuất hiện duy nhất trong bảng cms_block, tuyệt đối không ghi nhận trong core_config_data hay các tệp theme trên ổ đĩa.

Lý do chiến thuật của kẻ tấn công:

  • Bảng cms_block chứa các khối nội dung tĩnh (Static Blocks) được người quản trị dùng để hiển thị thông báo khuyến mãi, header, footer, chính sách thanh toán hoặc giỏ hàng.
  • Khi người dùng truy cập bất kỳ trang nào có chứa khối tĩnh này, Magento sẽ truy vấn database và render trực tiếp nội dung HTML/JS ra frontend.
  • Rất nhiều công cụ quét tính toàn vẹn tệp tin (File Integrity Monitoring - FIM) hoặc git-check chỉ giám sát thư mục code trên disk mà không theo dõi các thay đổi bên trong database MySQL. Ngược lại, các công cụ quét database thông thường thường chỉ tập trung vào core_config_data, khiến cms_block trở thành "điểm mù hoàn hảo" để duy trì sự hiện diện bền bỉ.

Phase 4: Client-side Execution — Né kiểm soát eval() qua DOM Event Handler (fpCode)

Ở đợt phát tán đầu tiên của tên miền mới vào tối ngày 07/10/2026, đoạn mã được bơm vào cms_block có cấu trúc như sau:

Đoạn script ngắn này chứa đựng kỹ thuật lẩn tránh rất tinh quái:

  1. Thực thi không cần hàm eval():
    Các giải pháp bảo vệ trình duyệt, WAF hiện đại và chính sách CSP nghiêm ngặt thường cấm hoặc giám sát gắt gao hàm eval() hay new Function(). Kẻ tấn công vượt qua rào cản này bằng cách tạo ra một thẻ <div> ảo, gán chuỗi mã độc lấy từ localStorage vào thuộc tính onclick, đưa thẻ vào DOM, gọi lệnh e.click() kích hoạt sự kiện và ngay lập tức xóa thẻ khỏi DOM bằng e.remove(). Trình duyệt sẽ thực thi mã độc như một event handler nội tại mà không kích hoạt bất kỳ cảnh báo eval() nào.
  2. Duy trì mã độc Client-side bền vững (Persistent Stashing):
    Bản thân đoạn mã trong CMS block không hề ghi dữ liệu vào fpCode. Trách nhiệm ghi giá trị vào localStorage.setItem("fpCode", ...) thuộc về script thứ hai tải từ máy chủ deepveindrilling.com. Một khi người mua hàng đã tải payload độc hại thành công lần đầu tiên, mã skimmer sẽ nằm lại vĩnh viễn trong localStorage của trình duyệt. Kể cả khi tên miền deepveindrilling.com bị cơ quan chức năng triệt hạ hoặc bị nhà mạng chặn DNS, trình duyệt của nạn nhân vẫn sẽ tiếp tục kích hoạt và chạy mã độc từ fpCode ở mỗi phiên truy cập sau.

Phase 4 (Nâng cấp): Deep Browser Fingerprinting — Kỹ thuật 'Ru ngủ' Security Scanner

Vào ngày 23/10/2026, nhóm tin tặc thực hiện một đợt nâng cấp toàn diện: viết lại toàn bộ nội dung trong cms_block của các cửa hàng bị kiểm soát. Đoạn mã script tag trần bị thay thế bằng một inline loader phức tạp, có nhiệm vụ thu thập dấu vân tay trình duyệt chi tiết và gửi về máy chủ C2 qua tham số URL:

https://deepveindrilling.com/?s=49b7ca5f&fp=<dữ_liệu_fingerprint_mã_hóa>

Dữ liệu fp (fingerprint) được thu thập từ máy khách bao gồm các chỉ số nhận diện môi trường ảo hóa và tự động hóa:

  • Dấu hiệu Automation: Kiểm tra cờ navigator.webdriver, các biến môi trường toàn cục của Selenium (window.document.__selenium_unwrapped, window._webdriver_evaluate), và các thuộc tính tự động của ChromeDriver (đặc biệt là tiền tố biến cdc_asdjflasutopfhvcZLmcfl).
  • Phần cứng đồ họa (WebGL): Truy vấn extension WEBGL_debug_renderer_info để lấy chính xác thông tin card màn hình (UNMASKED_RENDERER_WEBGL). Nếu trả về các driver ảo hóa như SwiftShader, llvmpipe, VirtualBox, VMware hoặc Google Cloud GPU, hệ thống sẽ bị nhận diện ngay là sandbox.
  • Thông số phần cứng & môi trường: Đếm số nhân CPU (navigator.hardwareConcurrency), dung lượng RAM (navigator.deviceMemory), độ phân giải và độ sâu màu màn hình (screen.width, screen.height, screen.colorDepth), múi giờ hệ thống (Intl.DateTimeFormat().resolvedOptions().timeZone), danh sách ngôn ngữ (navigator.languages), và User-Agent Client Hints.

Kết quả đánh giá từ C2: Khi dịch vụ phân tích website tự động urlscan.io quét qua một cửa hàng bị nhiễm sử dụng trình duyệt Chrome headless/automated, máy chủ C2 tại deepveindrilling.com nhận diện được dấu vân tay của crawler và ngay lập tức phản hồi mã trạng thái HTTP 200 nhưng không kèm bất kỳ nội dung mã độc nào. Nhờ đó, cửa hàng hoàn toàn vượt qua các bài kiểm tra bảo mật định kỳ của chủ shop. Payload độc hại thực sự chỉ được phát tán khi dấu vân tay xác nhận đó là một người dùng thật đang thực hiện thao tác duyệt web tự nhiên.

Phase 5: Exfiltration & Trục lợi kép — Keitaro TDS, Web Skimmer và Crypto Phishin

Trước tháng 10/2026, nhóm tấn công không tự xử lý logic lọc bot trên loader mà sử dụng nền tảng thương mại Keitaro — một hệ thống theo dõi quảng cáo (Ad Tracker) thường bị lạm dụng làm Hệ thống Phân phối Lưu lượng (Traffic Distribution System - TDS).

  • Loader chèn trong Magento sẽ thu thập thông tin se_referrer, tiêu đề trang, query string và gửi về URL mã hóa Base64: https://additionalver.com/Mb2z8J?&se_referrer=
  • Chuỗi Base64 giải mã: aHR0cHM6Ly9hZGRpdGlvbmFsdmVyLmNvbS9NYjJ6OEo/JnNlX3JlZmVycmVyPQ==
  • Keitaro TDS phân tích referrer và IP. Nếu là bot hoặc truy cập trực tiếp từ máy trạm Windows không thỏa mãn điều kiện shopping, server trả về câu lệnh decoy hoàn toàn vô hại: QWE=123;

Đồng thời thiết lập một cookie đánh dấu trình duyệt này trong vòng 24 giờ để không phục vụ mã độc nữa nhằm tránh gây nghi ngờ.

Payload thu thập được: Dữ liệu từ Sansec Watch (hệ thống giám sát CSP) cho thấy hành vi phân phối payload thực tế cho người dùng:

  • Ngày 12/12/2025: Một khách hàng đăng nhập vào cửa hàng bị nhiễm nạp script từ manulfie.click. Script này ngay lập tức kích hoạt tải trang lừa đảo từ https://crypto-insider.top/ssl/, và 5 phút sau chuyển tiếp sang https://leqdger.click/ssl/.
  • Tên miền leqdger.click là chiêu thức typosquatting nhắm vào thương hiệu ví lạnh tiền mã hóa Ledger (được đăng ký ngày 12/09/2025). Nhóm tấn công lợi dụng phiên duyệt web của khách hàng để hiển thị các pop-up giả mạo yêu cầu nhập cụm từ khôi phục (seed phrase) ví tiền điện tử, song song với việc đánh cắp thông tin thẻ tín dụng nhập tại bước checkout.

Phân Tích Nghịch Lý 'Cửa Hàng Đã Vá Đầy Đủ Vẫn Bị Xâm Nhập'

Một phát hiện quan trọng trong báo cáo đã đập tan quan niệm sai lầm phổ biến: "Chỉ cần cập nhật bản vá Magento mới nhất là an toàn".

Sansec đã phân tích trường hợp một cửa hàng thương mại điện tử vận hành phiên bản Magento 2.4.7-p10 — phiên bản mới nhất tại thời điểm kiểm tra, không hề thiếu bất kỳ bản vá lỗi cốt lõi (core patch) nào. Lúc 15:46 UTC ngày 23/10/2026, cửa hàng này được quét và xác nhận hoàn toàn sạch sẽ. Tuy nhiên, đúng 1 giờ sau (16:46 UTC), mã loader

deepveindrilling.com đã xuất hiện trong bảng cms_block.

Nguyên nhân:
Kẻ tấn công không cần khai thác lỗ hổng phần mềm mới. Dữ liệu điều tra ngược dòng cho thấy:

  • Ngày 16/09/2026: Một tài khoản quản trị viên giả mạo (rogue admin) đã được tạo âm thầm trong bảng admin_user.
  • Ngày 24/09/2026: Kẻ tấn công cài cắm thành công GSocket backdoor (công cụ reverse shell mã hóa qua mạng proxy/Relay) trên máy chủ.
  • Khi muốn triển khai loader mới, kẻ tấn công chỉ việc đăng nhập qua tài khoản admin ngầm hoặc sử dụng backdoor GSocket để cập nhật trực tiếp nội dung cơ sở dữ liệu.

Điều này chứng minh: Nếu quá trình xử lý sự cố (Incident Response) chỉ dừng lại ở việc cập nhật mã nguồn Magento mà bỏ qua việc rà soát tài khoản quản trị và backdoor cấp hệ thống, kẻ tấn công có thể quay lại bất cứ lúc nào.

Ma Trận Kỹ Thuật MITRE ATT&CK Mapping

Giai đoạn (Tactic) Mã kỹ thuật Tên kỹ thuật Mô tả áp dụng trong chiến dịch
Initial Access T1190 Exploit Public-Facing Application Khai thác PolyShell (CVE-2026-48356) và SessionReaper (CVE-2025-54236) trên Magento 2 / Adobe Commerce.
Execution T1059.007 JavaScript Thực thi loader JavaScript trên trình duyệt của khách hàng truy cập storefront.
Execution T1203 Exploitation for Client Execution Sử dụng DOM Event Handler (<div onclick=...>) để ép trình duyệt thực thi payload từ localStorage mà không gọi eval().
Persistence T1505.003 Web Shell Đẩy webshell PHP ngụy trang tệp ảnh PNG vào pub/media/custom_options/quote/ và tệp backdoor accesson.php.
Persistence T1078.003 Local Accounts Tạo tài khoản quản trị viên bất hợp pháp trực tiếp trong bảng cơ sở dữ liệu admin_user.
Persistence T1565.001 Stored Data Manipulation Thao túng dữ liệu bảng cms_block và cms_page để duy trì mã nạp độc hại trên giao diện cửa hàng.
Defense Evasion T1027 Obfuscated Files or Information Mã hóa Base64 các URL máy chủ C2, ẩn giấu webshell trong tệp ảnh đa định dạng (polyglot PNG).
Defense Evasion T1497.001 Virtualization/Sandbox Evasion Thu thập WebGL GPU, số nhân CPU, RAM, phát hiện navigator.webdriver và ChromeDriver cdc_ để né scanner/sandbox.
Defense Evasion T1564.004 NTFS File Attributes / Disguise Ẩn mã độc sau dịch vụ Cloudflare và ngụy trang dưới các khối HTML/CMS tĩnh thông thường.
Credential Access T1056.003 Web Inject (Magecart) Nhúng mã skimmer vào luồng thanh toán để đánh cắp số thẻ tín dụng, CVV, ngày hết hạn và thông tin cá nhân.
Credential Access T1566.002 Spearphishing Link / Phishing Phân luồng người dùng qua Keitaro TDS sang các trang phishing đánh cắp seed phrase ví Ledger (leqdger.click).
Command & Control T1071.001 Web Protocols (HTTP/HTTPS) Giao tiếp C2 thông qua giao thức HTTPS bảo mật ẩn sau CDN Cloudflare.
Command & Control T1090.003 Multi-hop Proxy (GSocket) Sử dụng GSocket backdoor thiết lập kết nối điều khiển từ xa mã hóa qua mạng relay toàn cầu.

IOCs

Loader URLs

Keitaro TDS URLs

Phishing / Malicious Payload URLs

Base 64

  • aHR0cHM6Ly9hZGRpdGlvbmFsdmVyLmNvbS9NYjJ6OEo/JnNlX3JlZmVycmVyPQ==

Nhận Định Chuyên Gia FPT IS SOC

Sự dịch chuyển sang Database-Level Skimming & Tự động né quét:
Bằng việc chọn bảng cms_block thay vì tệp mã nguồn PHP/JS, kẻ tấn công đã vô hiệu hóa hoàn toàn các giải pháp giám sát tính toàn vẹn tệp tin (FIM) và Git rollback. Đáng chú ý, việc tự phát triển engine browser fingerprinting (WebGL, Selenium, ChromeDriver) thay thế Keitaro TDS thương mại cho thấy năng lực R&D cao, biến các công cụ quét tự động thành "kẻ mù" khi chỉ nhận được phản hồi HTTP 200 rỗng.

Cái bẫy 'Dọn dẹp bề mặt' và Vòng lặp tái nhiễm (72%):
Con số 72% cửa hàng nhiễm tên miền mới từng là nạn nhân cũ chứng minh sai lầm phổ biến: quản trị viên chỉ xóa đoạn script hiển thị mà không truy tìm root-cause. Xóa script trong database chỉ cắt đứt ngọn; chừng nào các webshell PNG polyglot trong pub/media/, tài khoản rogue admin trong admin_user và backdoor GSocket chưa bị triệt phá, website sẽ bị tái nhiễm chỉ sau vài giờ.

Rủi ro hiện hữu tại thị trường eCommerce Việt Nam:
Khảo sát thực tế của FPT IS SOC cho thấy nhiều chuỗi bán lẻ trực tuyến tại Việt Nam vận hành Magento 2 theo mô hình bàn giao từ outsource agency, thường thiếu quy trình bảo trì bảo mật định kỳ do tâm lý sợ xung đột module gây gián đoạn kinh doanh. Hai lỗ hổng PolyShell (APSB26-73) và SessionReaper (APSB25-88) hiện vẫn tồn tại trên diện rộng, kết hợp với việc máy chủ web (Nginx/Apache) không chặn thực thi PHP trong thư mục upload pub/media/, biến các hệ thống trong nước thành mục tiêu lý tưởng cho các đợt càn quét tự động.

Khuyến Nghị Chi Tiết

Đối với người dùng

  • Kiểm tra tính xác thực của website: Chỉ mua sắm trên các website đáng tin cậy; kiểm tra kỹ tên miền, đặc biệt khi được chuyển hướng sang trang đăng nhập hoặc thanh toán khác thường.
  • Bảo vệ thông tin thanh toán: Không nhập thông tin thẻ ngân hàng, mật khẩu hoặc mã OTP khi xuất hiện yêu cầu bất thường. Ưu tiên sử dụng thẻ ảo, giới hạn giao dịch hoặc phương thức thanh toán có cơ chế bảo vệ người mua.
  • Cảnh giác với các yêu cầu cài đặt và xác thực: Không tải phần mềm, tiện ích trình duyệt hoặc thực hiện các thao tác xác minh không rõ nguồn gốc theo hướng dẫn xuất hiện trên website.
  • Theo dõi giao dịch tài chính: Kiểm tra lịch sử giao dịch ngân hàng và thông báo thanh toán; liên hệ ngân hàng ngay khi phát hiện giao dịch không được thực hiện hoặc phê duyệt bởi mình.
  • Xử lý khi nghi ngờ bị lộ thông tin: Sử dụng thiết bị đáng tin cậy để đổi mật khẩu, thu hồi các phiên đăng nhập đáng ngờ và liên hệ ngân hàng hoặc nhà cung cấp dịch vụ liên quan khi cần thiết.

Đối với đơn vị vận hành website

  • Cập nhật và vá lỗ hổng: Duy trì phiên bản Magento và các extension ở trạng thái được hỗ trợ, cài đặt bản vá bảo mật từ nguồn chính thức và loại bỏ thành phần không còn được sử dụng.
  • Kiểm soát tài khoản quản trị: Bật xác thực đa yếu tố (MFA) khi được hỗ trợ, áp dụng nguyên tắc quyền tối thiểu và rà soát định kỳ các tài khoản, API token cũng như quyền truy cập bất thường.
  • Giám sát nội dung CMS: Kiểm tra các thay đổi trái phép trong cms_block, cms_page và các thành phần có khả năng tải hoặc thực thi JavaScript; đối chiếu với bản sao lưu sạch và lịch sử chỉnh sửa.
  • Phát hiện kết nối bất thường: Giám sát yêu cầu DNS, HTTP/HTTPS và các script tải từ tên miền bên ngoài; đối chiếu với IOC đã xác minh và danh sách tài nguyên bên thứ ba được phê duyệt.
  • Tăng cường bảo vệ phía trình duyệt: Xem xét triển khai Content Security Policy (CSP), kiểm soát nguồn JavaScript và cơ chế phát hiện thay đổi nội dung thanh toán. Cần kiểm thử kỹ để tránh ảnh hưởng đến hoạt động hợp pháp của website.
  • Chủ động ứng phó sự cố: Khi phát hiện dấu hiệu xâm nhập, lưu giữ bằng chứng, cô lập thành phần bị ảnh hưởng, điều tra tài khoản và backdoor, xác định nguyên nhân gốc và chỉ khôi phục hoạt động sau khi xác minh hệ thống an toàn.

Đối với đội ngũ an ninh mạng

  • Tích hợp IOC đã xác minh vào hệ thống SIEM, EDR, DNS và proxy để hỗ trợ phát hiện, cảnh báo và điều tra.
  • Kết hợp phân tích mã nguồn, cơ sở dữ liệu, log ứng dụng và lưu lượng mạng; không dựa hoàn toàn vào kết quả quét tự động hoặc mã phản hồi HTTP.
  • Theo dõi các thay đổi về tên miền, hành vi loader và cơ chế né tránh phát hiện để cập nhật quy tắc giám sát.
  • Thực hiện đánh giá sau sự cố nhằm xác định phạm vi ảnh hưởng, nguy cơ tái xâm nhập và các biện pháp cần bổ sung.

Tài Liệu Tham Khảo

Hackers Infect 953 Online Stores With Scanner-Evading JavaScript, Mostly on Magento

Magento Campaign Infects 953 Online Stores Across Five Domains

deepveindrilling.com: Magento CMS block loader hits 953 stores | Sansec

No comments yet. Be the first to comment.

More from this blog