APWG ghi nhận 971.181 cuộc tấn công phishing chỉ trong quý 1 năm 2026 — tăng 13,8% so với quý trước. Và vào tháng 1 năm 2026, Google đã triệt phá điều mà họ gọi là một trong những mạng proxy dân cư lớn nhất thế giới sau khi phát hiện hơn 550 nhóm đe doạ đang chuyển lưu lượng qua đó chỉ trong một tuần. Nói cách khác, proxy đang đứng ở cả hai chiến tuyến trong cuộc chiến chống phishing.
Đó chính là điểm căng mà phần lớn bài viết về “proxy và phishing” thường bỏ sót. Hoặc họ nói proxy là lá chắn (mua sản phẩm proxy của chúng tôi, bạn sẽ an toàn), hoặc họ cảnh báo proxy là công cụ của kẻ tấn công (hãy sợ đi). Thực tế phức tạp hơn nhiều — và cũng đáng quan tâm hơn.
Kẻ tấn công dùng hạ tầng proxy để che giấu nguồn gốc, xoay vòng qua các địa chỉ IP nhìn có vẻ đáng tin cậy, và đánh cắp phiên đăng nhập đã xác thực — kể cả sau MFA. Người phòng thủ dùng proxy để kiểm tra an toàn các liên kết đáng ngờ, xem trang phishing hiển thị ra sao ở các quốc gia khác nhau, và lọc lưu lượng độc hại trước khi nó chạm tới hệ thống nội bộ. Hướng dẫn này sẽ đi qua cả hai phía, rồi chỉ ra một quy trình cụ thể mà bạn có thể áp dụng thật sự. Không nói vòng vo, không có “viên đạn bạc”.
- Mức độ: Trung bình
- Thời gian cần thiết: Khoảng 25 phút để đọc và lên kế hoạch; phần triển khai sẽ tùy từng bước
- Bạn cần chuẩn bị: Hiểu cơ bản về hạ tầng web của tổ chức, quyền truy cập vào cấu hình DNS của tên miền, trình duyệt Chrome (để làm theo phần Thunderbit), và tùy chọn là tài khoản của nhà cung cấp proxy
Phishing là gì và vì sao doanh nghiệp của bạn phải quan tâm?
Phishing là một kiểu tấn công lừa đảo. Tội phạm dùng email, tin nhắn, trang đăng nhập giả, mã QR hoặc website giả mạo để dụ người dùng giao thông tin đăng nhập, xác nhận đăng nhập, cài mã độc hoặc chuyển tiền.
Nó không còn chỉ là chuyện “một email xấu” nữa. Phishing hiện đại bao gồm các trang được host trên cloud, luồng đăng nhập giả của Microsoft 365, mã QR và hành vi đánh cắp session token.
Với doanh nghiệp, mức độ rủi ro là rất cụ thể. Báo cáo Cost of a Data Breach 2025 của IBM cho biết chi phí rò rỉ dữ liệu trung bình toàn cầu là 4,4 triệu USD. Báo cáo Internet Crime Report 2025 của FBI cho thấy IC3 đã nhận khoảng 453.000 đơn khiếu nại gian lận có yếu tố mạng, với tổng thiệt hại vượt 17,7 tỷ USD, trong đó lừa đảo email doanh nghiệp (BEC) chiếm hơn 3 tỷ USD.
Đánh cắp thông tin đăng nhập, gian lận chuyển tiền, xâm nhập chuỗi cung ứng, phạt vi phạm quy định — phishing chạm tới tất cả.
Phần tiếp theo sẽ nói rõ proxy đóng vai trò gì ở cả mặt tấn công lẫn phòng thủ, và một chiến lược phòng vệ nhiều lớp, thực tế, sẽ trông như thế nào.
Bản chất kép của proxy: lá chắn của bạn và vũ khí của họ
Proxy là một lớp trung gian giữa thiết bị của bạn và internet. Thay vì website nhìn thấy địa chỉ IP thật của bạn, nó chỉ thấy IP của proxy. Hãy hình dung nó như dịch vụ chuyển tiếp thư: người nhận nhận thư từ địa chỉ chuyển tiếp chứ không phải từ nhà bạn.
Chính đặc tính đó tạo ra bài toán “dùng hai mục đích”. Các đội ngũ an ninh dùng proxy để điều tra mối đe doạ mà không lộ IP công ty hay máy trạm của chuyên viên phân tích. Kẻ tấn công lại dùng đúng công nghệ này để khiến lưu lượng độc hại trông như đến từ người dùng bình thường, từ quốc gia khác, hoặc từ các mạng dân cư đáng tin cậy. Phân tích của Barracuda tháng 4/2026 giải thích rất rõ: IP dân cư nhìn có vẻ thật vì chúng gắn với kết nối internet gia đình hoặc doanh nghiệp nhỏ thực sự, nên các hệ thống chống gian lận ít có xu hướng đánh dấu chúng.
Phần lớn bài viết khác chỉ nói một phía. Điều đó khiến người đọc có cái nhìn thiếu sót — và hệ thống phòng thủ cũng thiếu sót theo.
Kẻ tấn công dùng proxy để chống lại bạn như thế nào
Ba hướng tấn công quan trọng nhất đối với người phòng thủ doanh nghiệp là: ẩn danh và xoay IP, lạm dụng proxy dân cư, và né tránh trên nền tảng đáng tin cậy.
Giải thích phishing AiTM (Adversary-in-the-Middle)
AiTM là kiểu tấn công phá vỡ giả định “có MFA là đủ an toàn” (spoiler: MFA truyền thống không trụ nổi).
Trong một cuộc tấn công AiTM, kẻ tấn công đặt reverse proxy giữa nạn nhân và trang đăng nhập hợp pháp — chẳng hạn Microsoft 365. Người dùng sẽ thấy một luồng đăng nhập trông hoàn toàn thật. Họ nhập thông tin đăng nhập, hoàn tất MFA, và nhà cung cấp danh tính thật sự cấp một session cookie. Nhưng vì toàn bộ lưu lượng đi qua proxy của kẻ tấn công, hắn sẽ chặn được cookie phiên đó. Sau đó hắn có thể phát lại phiên để truy cập tài khoản — không cần mật khẩu hay yêu cầu MFA nữa.
Phân tích của Microsoft về Tycoon2FA, một trong những bộ công cụ phishing AiTM nổi bật, cho thấy kẻ vận hành có thể giả mạo trang đăng nhập của Microsoft 365, Outlook, SharePoint, OneDrive và Google. Bộ kit này tạo PDF và mã QR, quản lý chuỗi chuyển hướng, và theo dõi việc dùng MFA cùng việc thu thập session cookie. Hạ tầng của nó dùng các subdomain tồn tại ngắn và hạ tầng host trên Cloudflare để làm khó danh sách chặn.
Đây không phải lý thuyết. Các bộ công cụ AiTM đang bị khai thác trên diện rộng, và đó là lý do số 1 khiến câu “chúng tôi có MFA rồi” chưa bao giờ là câu trả lời đầy đủ cho phishing.
Lạm dụng proxy dân cư và xoay IP
Các mạng proxy dân cư chuyển lưu lượng của kẻ tấn công qua các địa chỉ IP nhà dân thật, khiến yêu cầu phishing trông hợp lệ và vượt qua các bộ lọc gian lận dựa trên IP. Nhiều nhà cung cấp không kiểm tra nghiêm ngặt cách IP của họ được sử dụng, tạo ra một thị trường xám.
Ví dụ cụ thể nhất: vào tháng 1 năm 2026, Google Threat Intelligence Group đã triệt phá mạng proxy dân cư IPIDEA, làm giảm hàng triệu thiết bị khả dụng trong mạng này. GTIG ghi nhận hơn 550 nhóm đe doạ khác nhau dùng các exit node của IPIDEA chỉ trong một giai đoạn bảy ngày. Điều tra cũng phát hiện sự chồng lấn với botnet, lạm dụng truy cập SaaS, tấn công password spray và các tác nhân gián điệp toàn cầu. Nhiều triển khai SDK proxy không hề có cơ chế xin phép người dùng rõ ràng.
Tư vấn của FBI năm 2026 về proxy dân cư liệt kê các mục đích tội phạm gồm phishing, đăng nhập bằng thông tin bị đánh cắp, tấn công brute force, chiếm đoạt tài khoản, spam và che giấu C2.
Host trên nền tảng đáng tin cậy và né tránh bộ kit phishing
Một chiêu né tránh khác là host trang phishing trên các nền tảng đáng tin cậy — SharePoint, Google Docs, Azure Blob Storage — để lợi dụng uy tín tên miền. Phân tích của Microsoft về mối đe doạ nhắm vào Azure Blob Storage cho thấy kẻ tấn công dùng nó để host các trang đăng nhập Microsoft giả, khiến nạn nhân khó nhận ra dấu hiệu độc hại chỉ dựa trên chứng chỉ.
Các bộ kit phishing cũng có logic né tránh riêng. Phân tích bộ kit phishing của Cofense ghi nhận cơ chế lọc theo vị trí địa lý, user-agent và ngôn ngữ, CAPTCHA, phát hiện developer tools, và chuyển hướng sang trang hợp lệ. Nếu người truy cập không khớp hồ sơ nạn nhân dự kiến — sai quốc gia, sai trình duyệt, hoặc trông giống công cụ quét bảo mật — trang sẽ hiển thị nội dung vô hại hoặc trang 404.
Quét từ một IP công ty duy nhất hoặc một trung tâm dữ liệu cloud sẽ bỏ sót những trang này. Bộ kit được thiết kế chính là để ẩn khỏi bạn.
Người phòng thủ dùng proxy để phản công như thế nào
Ở mặt phòng thủ, proxy đảm nhiệm bốn việc rất thực tế:
-
Quét URL và tên miền ẩn danh. Chuyển các liên kết đáng ngờ qua một proxy được kiểm soát để phía đích chỉ thấy IP proxy chứ không thấy laptop nhân viên hay mạng doanh nghiệp. Điều này giảm phơi nhiễm trực tiếp và tạo ra một quy trình điều tra có thể lặp lại.
-
Thu thập threat intelligence. Dùng proxy xoay vòng để crawl hạ tầng phishing, danh sách tên miền, nguồn threat feed công khai, hoặc các tên miền mới đăng ký mà không bị chặn sau vài request. (Luôn phải tuân thủ pháp luật và điều khoản dịch vụ.)
-
Phát hiện phishing theo từng khu vực địa lý. Dùng proxy ở nhiều vùng để xem một URL đáng ngờ có hành xử khác nhau giữa Mỹ, EU, APAC hay thị trường mục tiêu khác không. Cách này bắt được các bộ kit dùng geofencing hoặc lọc theo user-agent — cũng chính là các kỹ thuật né tránh đã nói ở trên.
-
Triển khai reverse proxy / WAF. Reverse proxy đứng trước các tên miền của chính bạn. Nó không ngăn nhân viên bấm vào liên kết phishing bên ngoài, nhưng nó bảo vệ tài sản web của bạn khỏi bot traffic, credential stuffing, mã độc và các kiểu lưu lượng lạm dụng.
Vì sao chỉ MFA thôi vẫn thua trước phishing dùng proxy
Tôi đã thấy cuộc tranh luận này lặp đi lặp lại trong rất nhiều diễn đàn IT: “Chúng tôi có MFA nên đã được bảo vệ.” Những quản trị viên hệ thống từng xử lý sự cố AiTM thực tế lại có góc nhìn rất khác.
Cơ chế rất đơn giản. Nạn nhân hoàn tất MFA trên một luồng đăng nhập trông như thật. Nhà cung cấp danh tính thật cấp token phiên. Kẻ tấn công chặn token đó qua reverse proxy của mình.
Xác thực đã thành công — nhưng giờ kẻ tấn công sở hữu phiên làm việc. Chỉ đổi mật khẩu thôi có thể vẫn chưa đủ nếu các phiên đang hoạt động và các thay đổi MFA do kẻ tấn công tạo ra vẫn còn. Microsoft khẳng định rõ rằng tổ chức bị ảnh hưởng cần thu hồi session cookie và hoàn nguyên các thay đổi MFA do kẻ tấn công tạo ra, chứ không chỉ dừng ở biện pháp khắc phục tiêu chuẩn.
Mã SMS, ứng dụng OTP, xác nhận push — tất cả đều có thể bị lừa nếu người dùng hoàn tất chúng trong một luồng do kẻ tấn công kiểm soát. MFA đã làm đúng phần việc của nó. Vấn đề là kẻ tấn công đã theo dõi toàn bộ quá trình.
Điều gì thực sự chặn được phishing AiTM?
FIDO2 / Passkey. FIDO Alliance giải thích rằng passkey được thiết kế chống phishing ngay từ đầu: không có mật khẩu để đánh cắp, không có dữ liệu đăng nhập có thể tái sử dụng. Cặp khóa mật mã được ràng buộc với origin của tên miền hợp lệ, nên proxy của kẻ tấn công không thể sao chép thử thách này. CISA xác nhận rằng FIDO và PKI là hai phương thức MFA phi độc quyền, phổ biến, có thể ngăn phishing thông tin xác thực.
Xác thực dựa trên chứng chỉ. Ở cấp doanh nghiệp, triển khai phức tạp hơn, nhưng cũng chống phishing rất tốt vì dựa vào chứng chỉ thiết bị thay vì mã do người dùng nhập.
Chính sách Conditional Access. Trong môi trường Microsoft, Conditional Access có thể yêu cầu thiết bị tuân thủ, vị trí đáng tin cậy, kiểm tra dựa trên rủi ro, hoặc mức xác thực chống phishing — qua đó làm giảm giá trị của token phiên bị đánh cắp, ngay cả khi kẻ tấn công có được nó.
Tất cả những thứ này là bổ sung cho proxy, không phải thay thế. Mục tiêu là nhiều lớp bảo vệ.
Phương án thực tế cho SMB có ngân sách hạn chế
Phản biện rất dễ đoán: “Intune, MDM, khóa phần cứng — đó là ngân sách cấp doanh nghiệp mà.” Đúng. Vậy đây là lộ trình tiết kiệm:
- Passkey trên trình duyệt. Phần lớn trình duyệt hiện đại đã hỗ trợ passkey sẵn. Không cần mua phần cứng. Hãy bắt đầu với tài khoản quản trị, tài chính và nhân sự.
- Triển khai DMARC miễn phí. Bản ghi SPF, DKIM và DMARC đều có thể công bố miễn phí. Google Workspace và Microsoft 365 đều có hướng dẫn thiết lập sẵn.
- Đăng ký phòng thủ cho tên miền. Đăng ký các biến thể gõ nhầm và tên miền giống thương hiệu của bạn. Hầu hết nhà đăng ký tính khoảng 10–15 USD/năm mỗi tên miền. Thiết lập chính sách DMARC reject cho từng tên miền đó.
- Đào tạo có trọng tâm. Tập trung nhận thức nhân viên vào các mồi nhử AiTM cụ thể: trang đăng nhập Microsoft 365 giả, trang chia sẻ tài liệu giả, mã QR, trò lừa xác minh thiết bị, và các quy trình “khẩn cấp” về lương/nhà cung cấp.
Hãy coi đây là cách “bắt đầu ở đây, nâng cấp sau”. Chỉ cần áp dụng một phần cũng đã giảm rủi ro đáng kể.
Loại proxy nào phù hợp nhất để tránh phishing?
Mỗi loại proxy phục vụ một mục đích chống phishing khác nhau, và chọn sai sẽ vừa tốn tiền vừa tạo điểm mù.
| Loại Proxy | Trường hợp chống phishing phù hợp nhất | Ưu điểm | Nhược điểm | Mức chi phí |
|---|---|---|---|---|
| Datacenter | Quét URL hàng loạt, giám sát tên miền | Nhanh, rẻ, xử lý khối lượng lớn | Dễ bị các bộ kit phishing tinh vi phát hiện | Thấp |
| Residential | Phát hiện phishing theo khu vực, kiểm tra theo góc nhìn người dùng | Trông giống traffic người dùng thật, vượt qua chặn địa lý | Chậm hơn, đắt hơn, có nhiều lo ngại nghiêm trọng về nguồn cung đạo đức | Cao |
| Rotating | Crawl threat intel, giám sát liên tục | Tránh bị chặn IP trong các phiên crawl dài | Thiết lập phức tạp hơn, độ trễ thay đổi | Trung bình |
| Reverse Proxy / WAF | Bảo vệ tài sản web của chính bạn | Lọc mối đe doạ đi vào, phát hiện bot, chống DDoS | Không giúp phát hiện phishing từ đường outbound | Trung bình |
Lưu ý về nguồn cung đạo đức. Trường hợp Google/IPIDEA và khuyến cáo của FBI đều cho thấy mạng proxy dân cư có thể được xây từ thiết bị bị xâm phạm, SDK lừa dối, điều khoản VPN ẩn hoặc mã độc. Trước khi mua lưu lượng proxy dân cư, hãy yêu cầu nhà cung cấp chứng minh rõ ràng sự đồng ý của người dùng, cơ chế từ chối tham gia, khả năng kiểm toán và xử lý lạm dụng. Những nhà cung cấp từng bị nêu tên trong nghiên cứu bảo mật (PacketStream, 911 Proxy hiện đã ngừng hoạt động) cần được xem xét với mức độ thận trọng cực cao.
Với đa số doanh nghiệp nhỏ và vừa, hãy bắt đầu bằng proxy datacenter để quét hàng loạt và reverse proxy/WAF cho các tên miền của chính bạn. Chỉ thêm residential proxy khi bạn thật sự cần kiểm thử theo khu vực địa lý và đã thẩm định nhà cung cấp thật kỹ.
Từng bước: Cách tránh phishing bằng proxy (quy trình thực tế)
Phần lớn bài viết chỉ dừng ở lý thuyết. Mỗi bước dưới đây đều có gợi ý công cụ và đủ chi tiết để bạn giao cho đội IT hoặc tự thực hiện.
Bước 1: Theo dõi các tên miền mới đăng ký có vẻ giống thương hiệu của bạn
Kẻ tấn công thường đăng ký những tên miền na ná thương hiệu của bạn trước khi triển khai chiến dịch: thunderb1t.com, thunderbit-login.com, thunderbit-support.net.
Phát hiện sớm những tên miền này là một trong những hành động phòng thủ có giá trị cao nhất.
Cách làm:
- Tạo danh sách theo dõi gồm các từ khóa thương hiệu, tên sản phẩm, tên lãnh đạo, và các từ liên quan đến đăng nhập (ví dụ: “login”, “portal”, “invoice”, “payment”).
- Truy vấn nhật ký Certificate Transparency (CT) hằng ngày bằng crt.sh, công cụ cho phép tìm bản ghi chứng chỉ theo tên miền hoặc tên tổ chức. Các log CT yêu cầu chứng chỉ được tin cậy công khai phải được ghi nhận, nên các chứng chỉ mới cấp cho tên miền giả mạo sẽ xuất hiện ở đây.
- Đánh dấu những tên miền có khoảng cách chỉnh sửa gần với thương hiệu của bạn, TLD đáng ngờ (.xyz, .top, .click), hoặc chứa từ khóa login/payment.
- Hiển thị các trang được đánh dấu thông qua proxy hoặc sandbox — tuyệt đối không dùng trình duyệt của nhân viên.
Liên hệ với Thunderbit: API batch extract của Thunderbit có thể xử lý tới 100 URL đáng ngờ mỗi job, dùng renderMode: "full" để render các bản sao phishing nặng JavaScript. Bạn định nghĩa một JSON Schema cho dữ liệu muốn lấy về — tiêu đề trang, có form đăng nhập hay không, domain hành động của form, issuer SSL, chuỗi chuyển hướng, URL cuối cùng. Phiên bản CLI cũng rất hợp với giám sát bằng cron:
thunderbit batch extract --file suspicious-urls.txt --schema phishing-signals.json --render-mode full
Với người không chuyên kỹ thuật, tiện ích mở rộng Thunderbit Chrome cũng có thể dùng để nhanh chóng scrape và xem lại các trang đáng ngờ chỉ trong vài cú nhấp — rất hữu ích khi bạn chỉ cần soi vài URL thay vì chạy một pipeline định kỳ.
Kết quả mong đợi: Báo cáo hằng ngày hoặc hằng tuần về các tên miền mới đăng ký có vẻ giống thương hiệu, kèm metadata có cấu trúc để sàng lọc.
Dùng thử Thunderbit để rà soát URL đáng ngờ
Bước 2: Chuyển các liên kết đáng ngờ qua proxy datacenter
Trước khi bất kỳ ai trong tổ chức của bạn bấm vào liên kết đáng ngờ, hãy phân tích nó qua một đường đi được kiểm soát. Lúc đó chỉ IP proxy bị lộ, không phải thiết bị nhân viên hay mạng công ty.
Cách làm:
- Với kiểm tra nhanh, dùng urlscan.io (sandbox web cho phép chọn quốc gia quét) hoặc VirusTotal (quét URL qua hàng chục sản phẩm antivirus và blocklist).
- Với script nội bộ hoặc phân tích khối lượng lớn hơn, chuyển request qua proxy datacenter:
curl -x http://proxy.example.com:8080 -I "https://suspicious.example"
- Với trang phishing trực tiếp, dùng VM dùng một lần hoặc sandbox trình duyệt. Tắt việc nhập thông tin đăng nhập. Ghi lại chuỗi chuyển hướng, tiêu đề trang, đích cuối, các POST của form, script và ảnh chụp màn hình.
- Tuyệt đối không nhập thông tin đăng nhập thật của công ty. Và hãy cẩn trọng với các lần quét công khai — một số dịch vụ sẽ hiển thị URL bạn gửi trừ khi được cấu hình ở chế độ riêng tư hoặc không liệt kê.
Kết quả mong đợi: Đánh giá an toàn về đích đến, hành vi và dấu hiệu của liên kết — mà không làm lộ hệ thống công ty.
Bước 3: Dùng proxy phân bố theo khu vực để phát hiện chiến dịch phishing nhắm mục tiêu
Một số bộ kit phishing chỉ hiển thị nội dung độc hại cho người truy cập từ quốc gia hoặc ngôn ngữ mục tiêu. Cofense ghi nhận rằng lọc theo vị trí địa lý được dùng rất phổ biến: người truy cập từ “vùng sai” sẽ thấy trang vô hại hoặc 404, còn nhóm mục tiêu thì thấy form thu thập thông tin đăng nhập.
Cách làm:
- Kiểm tra các liên kết đáng ngờ từ những khu vực nơi nhân viên, khách hàng và đội tài chính của bạn thực sự làm việc. Nếu công ty bạn ở Mỹ nhưng có văn phòng tại Anh, hãy test từ cả hai nơi.
- So sánh URL cuối, ảnh chụp màn hình, tiêu đề trang, form và mã phản hồi HTTP theo từng khu vực.
- Xoay user-agent và ngôn ngữ khi điều tra các mồi nhử nhắm vào QR code hoặc thiết bị di động — một số bộ kit cũng lọc theo các tiêu chí này.
- Escalate các URL hiển thị nội dung vô hại ở một nơi nhưng hiện form đăng nhập ở nơi khác. Đó là tín hiệu phishing rất mạnh.
Kết quả mong đợi: Phát hiện các chiến dịch nhắm theo địa lý mà cách quét ở một địa điểm duy nhất sẽ không nhìn thấy.
Bước 4: Triển khai reverse proxy hoặc WAF cho các tên miền của chính bạn
Đã đến lúc chuyển từ phát hiện outbound sang phòng thủ inbound. Reverse proxy và WAF đứng trước các tài sản web của bạn, kiểm tra lưu lượng đi vào trước khi nó chạm tới máy chủ.
Cách làm:
- Trỏ DNS của tên miền sang nhà cung cấp reverse proxy. Cloudflare là lựa chọn dễ tiếp cận nhất cho SMB — DNS, CDN, WAF và rules đều nằm trong một giao diện. Với ứng dụng host trên AWS, AWS WAF hoạt động tốt nếu bạn đang dùng CloudFront, ALB hoặc API Gateway.
- Bật các rule WAF được quản lý. Chúng chặn các IP độc hại đã biết, lọc bot traffic và phát hiện kiểu credential-stuffing.
- Bật giới hạn tần suất cho đăng nhập, đặt lại mật khẩu và form liên hệ.
- Thêm rule bot hoặc challenge cho các điểm cuối rủi ro cao.
- Kiểm tra sự kiện WAF hằng tuần — đừng chỉ cấu hình xong rồi để đó.
Kết quả mong đợi: Lưu lượng độc hại inbound bị lọc trước khi tới máy chủ. Các nỗ lực credential stuffing vào trang đăng nhập sẽ bị chặn hoặc buộc xác minh.
Bước 5: Tự động hóa và lên lịch giám sát liên tục
Phishing không phải là một cuộc kiểm tra một lần. Tên miền, bộ kit và hạ tầng mới xuất hiện mỗi ngày — vì vậy việc giám sát cần có nhịp độ:
- Hằng ngày: quét CT tìm tên miền tương tự và hàng đợi tên miền đáng ngờ.
- Hằng ngày hoặc mỗi giờ (với thương hiệu rủi ro cao): kiểm tra sandbox cho các tên miền mới phát hiện.
- Hằng tuần: xem báo cáo tổng hợp DMARC và các mẫu spoofing.
- Hằng tuần: xem sự kiện WAF liên quan đến credential stuffing và các đợt bot tăng đột biến.
- Hằng tháng: kiểm tra tiến độ triển khai MFA chống phishing.
- Hằng quý: kiểm thử quy trình của bộ phận tài chính và nhân sự bằng các kịch bản AiTM và BEC thực tế.
Liên hệ với Thunderbit: Các workflow crawl theo lịch và CLI/API của Thunderbit có thể hỗ trợ giám sát định kỳ cho các đội vận hành không chuyên kỹ thuật. Điểm mạnh nhất không phải là “Thunderbit tự ngăn phishing”, mà là “Thunderbit giúp đội vận hành thu thập tín hiệu có cấu trúc từ các trang đáng ngờ và nguồn giám sát tên miền mà không phải viết crawler riêng từ đầu”. Kết quả có thể đẩy vào Google Sheets hoặc Airtable để cả nhóm cùng theo dõi, hoặc vào Slack thông qua tích hợp đơn giản.
Kết quả mong đợi: Một vòng lặp giám sát liên tục, phát hiện mối đe doạ mới trong vài giờ thay vì vài tuần.
Proxy không bắt được mọi thứ: bảo vệ email bằng DMARC, SPF và DKIM
Các nhà cung cấp proxy sẽ không nói với bạn phần này: proxy chỉ là một lớp phòng vệ, còn phishing qua email mà không đi qua lớp proxy thì cần được bảo vệ riêng.
Nhiều cuộc tấn công phishing đi vào qua địa chỉ email giả mạo. Proxy sẽ không chặn những thứ đó.
Thiết lập SPF với hard fail
SPF (Sender Policy Framework) là một bản ghi DNS liệt kê những IP nào được phép gửi email thay mặt tên miền của bạn. Hãy cấu hình -all (hard fail) thay vì ~all (soft fail) để từ chối thẳng các sender không được phép.
Sai lầm thường gặp: quên đưa vào tất cả dịch vụ gửi thư hợp lệ — CRM, nền tảng marketing, nhà cung cấp email giao dịch, helpdesk. Hãy kiểm tra toàn bộ nguồn gửi trước khi công bố bản ghi.
Triển khai ký DKIM
DKIM (DomainKeys Identified Mail) thêm chữ ký mật mã vào email gửi đi. Bên nhận sẽ xác minh thư không bị sửa trên đường truyền. Cả Google Workspace và Microsoft 365 đều có hướng dẫn thiết lập DKIM sẵn. Chỉ mất khoảng 15 phút.
Ép DMARC ở chế độ reject
DMARC (Domain-based Message Authentication, Reporting & Conformance) cho máy chủ nhận biết phải làm gì khi SPF hoặc DKIM thất bại. Bước quan trọng mà nhiều tổ chức bỏ qua là nâng từ p=none (chỉ giám sát) lên p=reject (chặn thư lỗi) sau khi đã xác minh luồng email hợp lệ.
Nhiều tổ chức giữ DMARC ở p=none mãi mãi — có nhìn thấy nhưng không được bảo vệ. Giống như lắp camera an ninh nhưng không bao giờ khóa cửa.
Đăng ký phòng thủ các tên miền giống thương hiệu
Chủ động đăng ký các lỗi chính tả phổ biến và các tên miền tương tự thương hiệu của bạn. Đặt chính sách DMARC reject trên những tên miền phòng thủ này để chúng không thể bị dùng cho email giả mạo. Với giá 10–15 USD/năm mỗi tên miền, đây là một trong những biện pháp rẻ nhất nhưng có tác động lớn nhất — vậy mà phần lớn doanh nghiệp nhỏ lại bỏ qua hoàn toàn.
Ghép tất cả lại: phòng thủ nhiều lớp chống phishing
Không có công cụ đơn lẻ nào ngăn được phishing. Sức mạnh thực sự đến từ sự kết hợp. Checklist thực tế:
Outbound (điều tra mối đe doạ):
- Quét URL dựa trên proxy cho các liên kết đáng ngờ
- Theo dõi tên miền qua log CT và batch extraction
- Kiểm thử phân bố theo địa lý cho các chiến dịch nhắm mục tiêu theo vùng
Inbound (bảo vệ tài sản của bạn):
- Reverse proxy / WAF cho các tên miền web
- DMARC/SPF/DKIM cho xác thực email
- Đăng ký phòng thủ các tên miền giống thương hiệu
Xác thực (bảo vệ tài khoản):
- FIDO2 / passkey cho MFA chống phishing
- Chính sách Conditional Access (thiết bị tuân thủ, kiểm tra dựa trên rủi ro)
- Quy trình giám sát và thu hồi token phiên
Con người (lớp an toàn cuối cùng):
- Đào tạo tập trung riêng vào mồi nhử AiTM, mã QR và kịch bản BEC
- Văn hoá báo cáo rõ ràng — tạo điều kiện để báo cáo email đáng ngờ dễ dàng và không bị phạt
- Kiểm thử định kỳ quy trình của bộ phận tài chính và nhân sự bằng các tình huống phishing sát thực tế
Cách tiếp cận này phù hợp với nguyên tắc phòng thủ nhiều lớp trong NIST Cybersecurity Framework: nhiều lớp độc lập, để khi một lớp thất bại thì chưa đồng nghĩa với việc bị xâm nhập toàn diện.
Với các đội cần điều tra URL đáng ngờ, thu thập dữ liệu mối đe doạ hoặc giám sát tên miền ở quy mô lớn, AI web scraper của Thunderbit có thể tăng tốc quy trình — tiện ích Chrome cho người không chuyên kỹ thuật, API/CLI cho đội kỹ thuật. Nó không phải là sản phẩm bảo mật tự thân, nhưng rất đáng có trong bộ công cụ của nhà phân tích. Bạn có thể tìm hiểu thêm về web scraping không cần code hoặc khám phá các cách tiếp cận AI web scraping trên blog của chúng tôi.
Dùng AI web scraping để giám sát mối đe doạ Get Started Free
Câu hỏi thường gặp
Kẻ tấn công dùng proxy như thế nào trong các cuộc tấn công phishing?
Kẻ tấn công dùng proxy dân cư và proxy xoay vòng để che giấu IP thật, luân chuyển qua các địa chỉ đáng tin cậy, vượt qua phát hiện gian lận dựa trên IP, và triển khai reverse proxy AiTM để chặn phiên đã xác thực — ngay cả sau khi nạn nhân hoàn tất MFA. Vụ triệt phá IPIDEA vào tháng 1 năm 2026 cho thấy hơn 550 nhóm đe doạ đang dùng cùng một mạng proxy dân cư.
Reverse proxy ngăn phishing và xâm nhập website như thế nào?
Reverse proxy đứng trước máy chủ web của bạn và kiểm tra lưu lượng đi vào trước khi nó chạm tới hạ tầng. Nó chặn các IP độc hại đã biết, lọc bot traffic, giới hạn tốc độ đăng nhập, và phát hiện credential stuffing hoặc hoạt động liên quan đến phishing. Tuy nhiên, nó không bảo vệ nhân viên khỏi việc bấm vào liên kết phishing bên ngoài.
Proxy có thể ngăn hoàn toàn phishing không?
Không. Proxy là một lớp quan trọng, nhưng phishing qua email cần DMARC/SPF/DKIM, còn việc chiếm phiên qua tấn công AiTM cần MFA chống phishing như FIDO2/passkey. Phòng thủ nhiều lớp kết hợp proxy, xác thực email, thông tin đăng nhập chống phishing và đào tạo nhân viên là điều bắt buộc.
Phishing AiTM là gì và vì sao MFA không chặn được?
Phishing AiTM (Adversary-in-the-Middle) dùng reverse proxy đặt giữa nạn nhân và trang đăng nhập thật, thu được token phiên sau khi MFA hoàn tất. MFA truyền thống không chặn được vì kẻ tấn công đánh cắp phiên đã xác thực chứ không phải mật khẩu. FIDO2/passkey chống được kiểu tấn công này vì thử thách mật mã được ràng buộc với tên miền hợp lệ và không thể phát lại qua proxy của kẻ tấn công.
Loại proxy nào tốt nhất để phát hiện phishing?
Proxy datacenter là tốt nhất để quét URL hàng loạt (nhanh và rẻ). Proxy dân cư là tốt nhất cho kiểm thử theo khu vực địa lý (thực tế hơn nhưng đắt hơn — hãy thẩm định nhà cung cấp về nguồn cung đạo đức). Reverse proxy/WAF là tốt nhất để bảo vệ website của chính bạn. Cách tiếp cận mạnh nhất là kết hợp các loại proxy dựa trên mục tiêu phát hiện hoặc bảo vệ.
Dùng thử Thunderbit để giám sát mối đe doạ và AI scraping Get Started Free
Tìm hiểu thêm
