Case Study: Cuộc tấn công DDoS vào GRANIX (Tháng 7/2025)

1. Executive Summary

• What happened: Trong khoảng thời gian từ ngày 09 đến 13/07/2025, nền tảng giao dịch OTC Crypto GRANIX đã liên tục hứng chịu các đợt tấn công từ chối dịch vụ phân tán (DDoS) với tần suất trung bình 30 triệu request/giờ. Đối tượng tấn công yêu cầu khoản tiền chuộc trị giá 1.000 USD để dừng tấn công.
• How it was discovered: Vào lúc 17h00 ngày 09/07, hệ thống bắt đầu có dấu hiệu giật lag. Sau quá trình điều tra, xác nhận đây là một cuộc tấn công DDoS quy mô lớn.
• Impact scope: Khoảng 20–25% người dùng bị ảnh hưởng, phần lớn là do phải vượt CAPTCHA mới vào được hệ thống hoặc truy cập bị từ chối hoàn toàn. Website bị sập hoàn toàn trong 30 phút đầu tiên.
• Current remediation status: Hệ thống đã được ổn định thông qua các biện pháp bảo vệ nâng cao từ Cloudflare và AWS. Tuy nhiên, sau sự cố, không có kế hoạch phòng ngừa hay quy trình ứng phó nào được ban lãnh đạo triển khai.

2. Incident Timeline

• 09/07 – 17:00: Hiệu suất hệ thống suy giảm đột ngột.
• 09/07 – 17:05: Phát hiện lưu lượng truy cập bất thường vào NGINX ingress của cụm Kubernetes.
• 09/07 – 17:10: Hệ thống AWS WAF và phân tích của Cloudflare phát cảnh báo.
• 09/07 – 17:15: Triển khai xử lý ban đầu, cô lập hệ thống gốc khỏi Internet.
• 09/07 – 17:30: Website sập hoàn toàn (~30 phút).
• 09/07 – 18:00: Bật CAPTCHA và rule chặn ngắn hạn trên Cloudflare, khôi phục truy cập.
• 09/07 – 20:00: Đợt tấn công thứ hai khởi phát, kéo dài liên tục đến 13/07.
• 10/07 - 13/07: Các đợt tấn công liên tiếp được chống trả bằng cách kết hợp rate-limit, WAF custom rule, challenge JS và phân tích hành vi.
• 14/07: Lưu lượng truy cập trở lại bình thường. Tiến hành tổng kết hậu sự cố.

30 phút đầu tiên của đợt tấn công

3. Systems Affected

• Hostname/IP: k8s-granix-ingress / 10.0.2.11
• Role: Cổng Ingress công khai (NGINX trên Kubernetes)
• Affected Components/Services: Web frontend, API Gateway
• Affected User Accounts: Không phát hiện bị chiếm quyền / xâm phạm
• Hostname/IP: cloudflare edge
• Role: CDN & lớp phòng thủ DDoS
• Affected Components/Services: Firewall, challenge

4. Root Cause Analysis

Sự thật phũ phàng đã được phơi bày: GRANIX là một pháo đài với những bức tường giấy, và sự thiếu nhận thức của lãnh đạo đã để lộ những cánh cửa chính.

• Technical Weakness
• Thiếu giới hạn request chi tiết theo IP.
• Không có hệ thống giám sát lưu lượng nền để phát hiện bất thường.
• Không có kịch bản phản ứng sự cố sẵn sàng.
• Bằng chứng: Log ghi nhận hơn 15-30 triệu request/giờ đổ dồn vào các endpoint /api/*, từ nhiều IP có hành vi tương tự bot.
• Procedural Weakness
• Không có tài liệu hoặc kịch bản phòng chống DDoS.
• Nhân sự và ban lãnh đạo không có nhận thức đúng về rủi ro từ các cuộc tấn công có đòi tiền chuộc.
• Không có kiểm thử khả năng chịu tải từ trước.

5. Indicators of Compromise (IoCs)

IP độc hại tiêu biểu

• 154.203.39.9 (Nhật)
• 46.114.15.16 (Đức)
• 31.59.11.231 (Nhật)
• 46.203.52.126 (Nhật)

Hành vi đáng ngờ

• Flood các endpoint /, /api/..., /api/airdrop/...
• Giả lập User-Agent là trình duyệt di động để qua mặt filter

6. Threat Intelligence Integration

MITRE ATT&CK Mapping

• Tác động: Network Denial of Service (T1498.001)
• Quan sát: Flood dữ liệu vào gateway nhằm đánh sập ingress và làm tê liệt cluster.
• Chiến dịch tương tự đã biết: Các cuộc tấn công có chủ đích nhằm vào nền tảng crypto tại Đông Nam Á trong năm 2023 với yêu cầu tống tiền tương tự.

7. Containment Actions

1. Bật full bảo vệ DDoS trên Cloudflare: rate-limit, challenge JS, OWASP Managed Rules
2. Tuỳ chỉnh AWS WAF để lọc theo header bất thường và IP dính blacklist
3. Tạm thời chặn theo vùng địa lý từ các ASN độc hại. Cấu hình các quy tắc Cloudflare WAF, bao gồm các quy tắc Managed Rulesets (như Cloudflare OWASP Core Ruleset) và các quy tắc tùy chỉnh để chặn các mẫu lưu lượng tấn công đã biết.
4. Tối ưu lại cấu hình ingress NGINX: giới hạn kết nối, bộ đệm, timeout. Tăng cường khả năng mở rộng tự động (autoscaling) của các pod NGINX Ingress Controller và các dịch vụ ứng dụng trên Kubernetes để hấp thụ một phần lưu lượng tấn công.
5. Giới hạn tốc độ yêu cầu (rate limiting) trên NGINX Ingress Controller cho các địa chỉ IP hoặc mẫu yêu cầu đáng ngờ.
6. Phân tích nhật ký truy cập (access logs) để xác định các địa chỉ IP nguồn độc hại và các mẫu tấn công, sau đó chặn chúng thủ công hoặc tự động.

Những ngày cuối cùng của trận chiến

8. Remediation Steps

1. Triển khai blocklist động cập nhật bằng Lambda@Edge
2. Thêm CAPTCHA / challenge JS riêng cho các API trọng yếu
3. Bật autoscale cho pod ingress và rule WAF bằng Terraform
4. Kết nối Prometheus + Grafana để giám sát lưu lượng theo thời gian thực
5. Tập hợp log và gửi về hệ thống ELK để phân tích và điều tra chuyên sâu
6. Tối ưu hóa cấu hình NGINX Ingress Controller để xử lý hiệu quả hơn các yêu cầu hợp pháp và giảm thiểu tác động của lưu lượng tấn công còn sót lại.
7. Rà soát lại và tinh chỉnh các quy tắc Cloudflare WAF và AWS WAF dựa trên các mẫu tấn công quan sát được để tối đa hóa hiệu quả chặn và giảm thiểu cảnh báo sai.
8. Thực hiện kiểm tra khả năng phục hồi DDoS định kỳ (DDoS resiliency tests) để đảm bảo hệ thống có thể chịu được các cuộc tấn công trong tương lai.
9. Đảm bảo rằng tất cả các thành phần hệ thống, đặc biệt là NGINX Ingress Controller và các dịch vụ Kubernetes, được cập nhật các bản vá bảo mật mới nhất.
10. Khôi phục hiệu suất đầy đủ của trang web sau khi cuộc tấn công kết thúc, theo dõi các chỉ số về độ trễ và khả năng đáp ứng.

9. Lessons Learned

• Lỗ hổng kỹ thuật
• Chưa có autoscale cho ingress và cấu hình rate-limit phù hợp
• Cloudflare đang ở cấu hình mặc định, chưa tối ưu cho ngành crypto
• Thiếu chiến lược phòng thủ DDoS chủ động. Dựa vào các giải pháp tức thời thay vì một kiến trúc bảo mật toàn diện.
• Lỗ hổng quy trình
• Không có playbook hoặc kịch bản xử lý sự cố nào
• Không có kế hoạch liên lạc/ứng phó khẩn cấp khi xảy ra sự cố
• Yếu tố con người
• Không có bất kỳ hỗ trợ nào từ team hoặc quản lý cấp trên
• Sau khi qua sự cố, ban lãnh đạo vẫn không hành động gì thêm để cải thiện / phòng chống trong tương lai
• Điểm cần cải thiện
• Xây dựng ma trận phản ứng sự cố theo mức độ nghiêm trọng
• Tổ chức tabletop drill định kỳ để diễn tập và chuẩn hoá hành vi phản ứng
• Cần một chiến lược phòng thủ DDoS chủ động, không chỉ là phản ứng.
• Cần một sự thay đổi văn hóa từ cấp lãnh đạo về tầm quan trọng của an ninh mạng và đầu tư vào nó.

10. Recommendations

• Tactical (ngắn hạn):
• Giới hạn truy cập vào ingress theo burst rate/IP
• CAPTCHA cố định trên trang login và giao dịch
• Thực hiện các bài kiểm tra khả năng phục hồi DDoS (DDoS resiliency tests) hàng quý để xác định và khắc phục các điểm yếu tiềm ẩn.
• Tối ưu hóa liên tục các quy tắc Cloudflare WAF và AWS WAF dựa trên các mối đe dọa mới nổi và lịch sử tấn công.
• Triển khai các giải pháp giám sát lưu lượng mạng nâng cao để phát hiện sớm các dấu hiệu của tấn công DDoS.
• Strategic (dài hạn):
• Xây dựng và duy trì một sổ tay ứng phó DDoS chi tiết và thường xuyên cập nhật.
• Đưa tư duy threat modeling vào quy trình phát triển sản phẩm
• Chuyển mindset bảo mật từ “phản ứng” sang “phòng thủ chủ động”
• Phát triển và thực hiện một chương trình đào tạo nhận thức về an ninh mạng toàn diện cho tất cả nhân viên, nhấn mạnh tầm quan trọng của các mối đe dọa như DDoS và phishing.
• Thiết lập một quy trình quản lý rủi ro an ninh mạng chính thức, bao gồm đánh giá lỗ hổng định kỳ và kiểm tra thâm nhập.
• Đầu tư vào một hệ thống Quản lý Sự kiện và Thông tin An ninh (SIEM) tập trung để cải thiện khả năng tương quan nhật ký và phát hiện mối đe dọa.
• Thành lập một nhóm ứng phó sự cố (IR team) chuyên trách hoặc thuê ngoài dịch vụ IR để đảm bảo có đủ nguồn lực và chuyên môn khi có sự cố.
• Cam kết rõ ràng từ cấp lãnh đạo về việc ưu tiên và đầu tư vào an ninh mạng như một phần cốt lõi của chiến lược kinh doanh.

11. Appendices

• Log minh hoạ: 1 vài IP request liên tùng tục
• Ảnh chụp màn hình: Ghi nhận log từ Cloudflare, spike CAPTCHA
• So sánh cấu hình Cloudflare:
• Trước: bật OWASP mặc định, chưa có rate limit
• Sau: giới hạn 200 RPS/IP, challenge toàn bộ /api/*, yêu cầu trình duyệt hợp lệ
• Sơ đồ kiến trúc: Cloudflare → AWS → K8s Ingress → App Backend

Lưu ý: Do điều khoản NDA, GRANIX là 1 cái tên bí danh được đặt ra, không phải tên công ty / trang web / dịch vụ thật.

🛡️ Tác giả: Nguyễn An Hưng - Người phòng thủ duy nhất trong trận chiến không đồng đội

📝 Lưu ý cá nhân: Cuộc chiến này đã được chống đỡ và giành thắng lợi chỉ với một người. Nhưng nếu không có sự thay đổi từ tổ chức, thì chiến thắng này chỉ là sống sót – không phải là thành công. full-width