Common Crawl Quét Toàn Bộ Web Tìm Site WordPress Lỗi Chỉ Với 0,4 USD: Sự Thật Và Cách Phòng Thủ

Một bài viết trên HackerNoon đầu tháng 9/2026 vừa cho thấy thực tế đáng suy ngẫm: với khoảng 0,4 USD chi phí AWS và vài giờ setup, bất kỳ ai cũng có thể quét toàn bộ web, lọc ra hàng triệu site WordPress và đánh dấu những site đang chạy plugin có lỗ hổng đã biết. Tác giả dùng Common Crawl — kho dữ liệu khoảng 50 TB crawl công khai của cả web — kết hợp Amazon Athena và EMR để làm việc này hoàn toàn tự động. Trong bài này mình sẽ mổ xẻ quy trình đó, giải thích vì sao site của bạn bị “soi” ngay khi plugin lỗi chưa kịp vá, và quan trọng hơn: bạn nên phòng thủ thế nào khi đối thủ không crawl web bằng tay nữa mà chạy Big Data.

Common Crawl là gì và tại sao kẻ tấn công thích nó?

Common Crawl là tổ chức phi lợi nhuận crawl toàn bộ web công khai và lưu archive khổng lồ — khoảng 50 TB cho mỗi lần crawl — lên Amazon S3, ai cũng truy cập được miễn phí. Với kẻ tấn công, đây là món quà: họ không cần tự crawl hàng chục triệu website, tốn băng thông và dễ bị chặn, mà chỉ cần truy vấn danh sách URL có sẵn. Site của bạn với đường dẫn /wp-content/, /wp-login.php hay /xmlrpc.php lộ ngay trong index. Đây là lý do mình luôn nói với khách hàng: ẩn dấu vết WordPress trên trang chủ không ngăn được scanner hiện đại, vì chỉ một asset leaked là đủ để hệ thống nhận diện bạn.

Quy trình quét hàng triệu site WordPress hoạt động ra sao?

Bài viết gốc mô tả pipeline gồm ba giai đoạn, tất cả chạy trên AWS với chi phí gần như không đáng kể. Mình tóm tắt lại để bạn hiểu thợ săn của mình đang vũ trang đến răng thế nào.

Giai đoạn 1 — Tìm mọi domain WordPress bằng Athena. Dữ liệu index của Common Crawl lưu dạng Parquet trên S3, Athena truy vấn trực tiếp không cần tải về. Một query SQL lọc ra tất cả domain có URL khớp các dấu hiệu WordPress:

WITH wp_domains AS (
    SELECT DISTINCT
        REGEXP_EXTRACT(url, 'https?://([^/]+)', 1) AS domain
    FROM "cc_index"."cc_main"
    WHERE crawl = 'CC-MAIN-2026-25'
      AND fetch_status IN (200,301,302)
      AND (
          url LIKE '%/wp-content/%'
          OR url LIKE '%/wp-includes/%'
          OR url LIKE '%/wp-json/%'
          OR url LIKE '%/wp-login.php%'
          OR url LIKE '%/xmlrpc.php%'
      )
)
SELECT c.url, c.warc_filename, c.warc_record_offset, c.warc_record_length
FROM "cc_index"."cc_main" c
JOIN wp_domains d
  ON REGEXP_EXTRACT(c.url, 'https?://([^/]+)', 1) = d.domain
WHERE c.crawl = 'CC-MAIN-2026-25'
  AND c.fetch_status = 200
  AND c.content_mime_detected = 'text/html';

Kết quả trả về kèm warc_filename, offset và length — tức tọa độ chính xác của bản HTML trang chủ từng site nằm trong kho WARC. Tác giả ước tính mỗi lần truy vấn kiểu này tốn khoảng 0,4 USD.

Giai đoạn 2 — Cào HTML và dò pattern plugin lỗi bằng EMR. Danh sách CSV được đưa vào cụm EMR Spark. Script Python trên từng worker đọc đúng đoạn WARC theo offset, lấy HTML trang chủ và tìm các chuỗi pattern đặc trưng của plugin đang có CVE — trong ví dụ là ova-event-manager với CVE-2025-6553. Vì hầu hết theme và plugin để lại dấu vết trong HTML (comment generator, đường dẫn asset, handle CSS/JS), việc dò version plugin về bản chất chỉ là khớp chuỗi trên hàng triệu trang cùng lúc.

Giai đoạn 3 — Xuất danh sách nạn nhân tiềm năng. Kết quả ghi ra file domains.txt trên S3: một danh sách sạch sẽ các site đang chạy chính xác plugin dễ bị khai thác. Từ đây, khai thác từng site chỉ còn là việc tự động hóa. Toàn bộ chuỗi từ “cả world wide web” đến “danh sách nạn nhân” diễn ra trong vài giờ với chi phí dưới 1 USD.

Vì sao điều này đáng lo cho site WordPress của bạn?

Ba hệ quả thực tế mà mình rút ra. Thứ nhất, cửa sổ vá lỗi của bạn đang bị đo bằng giờ, không phải tuần. Ngay khi một CVE plugin được công bố, pattern HTML của plugin đó lập tức thành “chìa khóa vạn năng” cho phép quét ngược toàn bộ Common Crawl. Thứ hai, site nhỏ không còn là nơi an toàn — attacker không cần tìm đến bạn thủ công, danh sách tự động sinh ra bao gồm mọi site khớp pattern, kể cả blog 10 lượt xem mỗi ngày. Thứ ba, nguy cơ nằm ở phiên bản cũ tích lũy: archive Common Crawl lưu theo thời gian, nên thậm chí cả những dấu vết từ crawl cũ cũng có thể được đối chiếu chéo.

Nhìn chuỗi CVE nghiêm trọng dày đặc trong năm 2026 như Super Forms hay All-in-One WP Migration mà mình đã phân tích ở bài về CVE-2026-19949 ở All-in-One WP Migration, bạn sẽ thấy quy trình trên không còn là thí nghiệm học thuật mà là dây chuyền sản xuất nạn nhân.

Bảo vệ site WordPress khỏi mass scanner như thế nào?

Bạn không thể xóa dấu vết WordPress khỏi các archive công khai, nhưng có thể khiến danh sách domains.txt trở nên vô dụng với site mình. Checklist mình áp dụng, sắp theo thứ tự ưu tiên:

1. Vá plugin nhanh nhất có thể: bật auto-update cho plugin phổ biến. Câu thần chú quen thuộc: wp plugin update --all nên chạy trong cron kiểm tra hằng ngày.
2. Xóa plugin không dùng thay vì chỉ deactivate: file vẫn nằm trên đĩa và vẫn match pattern. Dọn bằng WP-CLI: wp plugin delete <slug>.
3. Chặn truy cập trực tiếp vào các file mồi: khóa xmlrpc.php, giới hạn wp-login.php theo IP ở tầng Nginx/CDN. Đây là những URL mà chính query ở trên dùng để nhận diện.
4. Đặt WAF hoặc filtering ở tiền cảnh: Cloudflare WAF hoặc các dịch vụ chặn bot chuyên dụng sẽ chặn bước khai thác tự động sau khi scanner có danh sách — bước cuối cùng và đắt nhất để chặn.
5. Giám sát file bất thường: quét thư mục wp-content/uploads tìm file .php — nơi webshell thường được thả. Lệnh nhanh: find /var/www/*/public_html/wp-content/uploads -name "*.php" đưa vào cron cảnh báo.

Bài học lớn nhất từ cuộc trình diễn này là gì?

Đó là sự bất đối xứng đã hoàn toàn nghiêng về kẻ tấn công: chi phí tìm ra bạn gần bằng 0, trong khi chi phí để bạn bị tìm thấy rồi bị khai thác có thể là cả website. Cách duy nhất để cân lại trò chơi là rút ngắn khoảng cách giữa thời điểm CVE công bố và thời điểm bạn vá — tự động hóa cập nhật, giám sát và phòng thủ nhiều lớp như mình chia sẻ ở trên. Đừng chờ đến khi site mình xuất hiện trong một file domains.txt nào đó mới bắt đầu.