Tin tức Hướng dẫn kỹ thuật CÔNG TY CỔ PHẦN DỊCH VỤ CÔNG NGHỆ DATECH
Số 23E4 KĐT Cầu Diễn, Tổ 7, Phú Diễn, Bắc Từ Liêm, Hà Nội
Email: sales@datech.vn
Danh mục sản phẩm
CÔNG TY CỔ PHẦN DỊCH VỤ CÔNG NGHỆ DATECH
Số 23E4 KĐT Cầu Diễn, Tổ 7, Phú Diễn, Bắc Từ Liêm, Hà Nội
Danh mục sản phẩm
Router 
Firewall 
Switch 
Wifi - Access Point 
Máy chủ ( Server ) 
Thiết bị lưu trữ NAS 
Networking Accessories 
Video Conference 
Vật tư mạng 
Tổng đài & điện thoại 
Bộ lưu điện UPS 
13/12/2021
13/12/2021
Danh sách nội dung [Ẩn]
DNS Tunneling: Con đường bí mật thoát ra khỏi mạng của bạn
Hãy tưởng tượng thế này: đó là một buổi chiều thứ Năm yên tĩnh. Bạn đang lặng lẽ phân tích những mối đe dọa mới nhất từ các hệ thống EDR và bảng điều khiển tường lửa, kiểm tra tất cả các cảnh báo về các kết nối outbound đến những địa chỉ lạ. Tất cả chúng đều đã bị chặn.
Thế nhưng, ngay cả khi bạn đang nhâm nhi ly cà phê, một loại mã độc nguy hiểm đang lan rộng khắp toàn bộ mạng doanh nghiệp, báo hiệu một cuộc tấn công ransomware tàn phá và tốn kém sắp xảy ra. Loại mã độc này không hoạt động trong bóng tối: nó có một “đường dây liên lạc” mở về phía kẻ điều khiển. Nhưng đường dây này không phải là một kết nối TCP mà bạn có thể nhìn thấy trên tường lửa. Nó đang âm thầm truyền đi, ẩn sâu bên trong dòng chảy dày đặc của các truy vấn DNS, hòa lẫn vào dòng sông cuồn cuộn của hàng ngàn, hàng vạn truy vấn DNS hoàn toàn vô hại, được chuyển tiếp bởi DNS resolver nội bộ đáng tin cậy của bạn. Khi bạn nhận ra sự bất thường này, thì đã quá muộn.
Cốt lõi của Internet chính là Hệ thống Tên miền (Domain Name System – DNS): một dịch vụ nền tảng mà kể từ khi được giới thiệu vào đầu những năm 1980, đã trở thành tiêu chuẩn thực tế (de facto) cho việc phân giải tên trên toàn bộ Internet. Nhiệm vụ của nó, về bản chất, là chuyển đổi các tên miền thân thiện với con người, như www.hpe.com, thành các dạng địa chỉ gốc của Internet, tức là địa chỉ IPv4 và IPv6.
Tuy nhiên, việc sử dụng DNS ngày nay đã vượt xa khỏi một cơ chế ánh xạ tĩnh, đơn giản giữa hostname và địa chỉ IP. Phần mềm hiện đại sử dụng DNS để triển khai nhiều chức năng, từ cân bằng tải (load balancing) đến khám phá dịch vụ (service discovery), thông qua nhiều cách sử dụng – và lạm dụng – giao thức này nhằm thực hiện vô số tác vụ điện toán hiện đại. Tính không thể thiếu cùng với sự phức tạp ngấm ngầm của nó khiến DNS thường được xem như một “con quái vật đang ngủ” — tốt nhất là không nên đánh thức. Trong bối cảnh an ninh mạng, điều này đồng nghĩa với việc DNS thường được mặc định là đáng tin cậy.
Mỗi email được gửi đi, mỗi trang web được truy cập, mỗi lần đăng nhập Active Directory – tất cả đều bắt đầu bằng một truy vấn DNS. Sự phổ biến rộng khắp và mức độ tin cậy ngầm định này chính là điều khiến DNS trở thành một mục tiêu hấp dẫn và dễ bị khai thác, và cũng là lý do tại sao DNS thường xuyên bị các tác nhân đe dọa hiện đại sử dụng, bao gồm các chiến dịch ransomware quy mô lớn và các nhóm APT được hậu thuẫn bởi chính phủ. Nhiều trong số đó tận dụng mạnh mẽ chức năng C2 (Command and Control – TA0011) của Cobalt Strike, đặc biệt là tính năng DNS Beacon, vốn sử dụng DNS cho việc liên lạc điều khiển (T1071.004). Cobalt Strike, một bộ phần mềm thương mại tự quảng bá là “phần mềm cho mô phỏng đối thủ và hoạt động red team”, là một công cụ tấn công mạnh mẽ đã được các tổ chức tội phạm và các nhóm APT trên toàn thế giới sử dụng rộng rãi.
Điều này cực kỳ hiệu quả bởi vì, như các tác nhân đe dọa từ lâu đã biết, nhận ra và khai thác, các kỹ sư mạng và thậm chí cả kỹ sư bảo mật thường xem DNS như một thứ gì đó nằm giữa một “con quái vật” và một “đường ống ngu ngốc”. Nó phải tồn tại, và nó phải hoạt động. Ngay cả khi giao thức DNS bị chặn tại tường lửa biên, nếu muốn truy cập Internet hoạt động bình thường, vẫn phải có một DNS resolver nội bộ, và nó phải được phép giao tiếp tự do với các DNS resolver bên ngoài. Bản chất của DNS khiến việc hạn chế lưu lượng DNS trở nên đầy rủi ro kỹ thuật, và tính chất đệ quy (recursive) của DNS resolver khiến việc kiểm soát điểm đến của lưu lượng DNS gần như là không thể.
Do đó, DNS trở thành một “đường cao tốc thông tin” ẩn giấu, một điểm mù mà kẻ tấn công có thể lợi dụng để tuồn dữ liệu ra vào ngay cả trong những mạng được bảo vệ nghiêm ngặt nhất. Kỹ thuật này, được gọi là DNS tunneling, cho phép các tác nhân đe dọa đóng gói lệnh độc hại và dữ liệu bị đánh cắp vào bên trong các truy vấn DNS tưởng chừng vô hại và các phản hồi của chúng, tạo ra một kênh liên lạc bí mật có thể vượt qua hàng tỷ đô la đầu tư bảo mật tích lũy.
Trong bài viết này, chúng ta sẽ đi sâu khám phá mối đe dọa phổ biến này. Trước tiên, chúng ta sẽ bắt đầu với cái nhìn tổng quan về chính DNS, phân tích cơ chế hoạt động của các truy vấn “đệ quy” đã đề cập, cũng như chuỗi tin cậy (chain of trust) giúp nó vận hành. Sau đó, chúng ta sẽ đào sâu vào thế giới của việc “tuồn dữ liệu” qua DNS, xem xét cách kẻ tấn công có thể tạo ra một đường hầm TCP/IP hoàn chỉnh bên trong lưu lượng DNS tới một điểm cuối trên Internet, qua mặt các cơ chế kiểm soát mạng được thiết kế để ngăn chặn kiểu truy cập này. Chúng ta cũng sẽ phân tích các ví dụ thực tế về các kỹ thuật tunneling khác nhau, cùng với loại lưu lượng và log mà chúng tạo ra. Cuối cùng, chúng ta sẽ thảo luận về một framework để phát hiện các kênh liên lạc bí mật này, với chiến lược giảm thiểu nhiều lớp nhằm khiến DNS tunneling trở nên khó khăn và dễ bị phát hiện nhất có thể, khiến nó trở nên vô dụng đối với hầu hết các tác nhân đe dọa, ngoại trừ những kẻ kiên trì nhất.
Mục tiêu không chỉ là hiểu rõ mối đe dọa, mà còn là trang bị và chuẩn bị cho các chuyên gia mạng những kiến thức và chiến lược cần thiết để “soi sáng” điểm mù này, và đóng lại “đường cao tốc ẩn” đó một cách triệt để.
Trước khi đi vào cách DNS có thể bị lạm dụng, chúng ta cần bắt đầu từ cách sử dụng cơ bản và đúng đắn nhất của nó: thiết kế và chức năng. Về bản chất, DNS là một cơ sở dữ liệu phân tán toàn cầu, có cấu trúc phân cấp, dùng để ánh xạ tên miền tới các “bản ghi tài nguyên” (resource records). Ví dụ phổ biến nhất của một bản ghi tài nguyên (RR) chính là địa chỉ IP.
Trước khi có DNS, các mạng như ARPANET và DECNET dựa vào các biến thể của file hosts để lưu trữ các bản ghi tĩnh giữa tên và địa chỉ tương ứng. Những cơ sở dữ liệu này vẫn còn tồn tại cho đến ngày nay, dưới dạng /etc/hosts trên các hệ điều hành kiểu UNIX, và C:\Windows\System32\drivers\etc\hosts trên Windows. Tuy nhiên, khi các mạng máy tính mở rộng quy mô, người ta nhanh chóng nhận ra rằng việc tạo và sao chép thủ công các file này là không khả thi.
Trong thế giới của giao thức Internet, “Domain Name System” được đặc tả trong RFC 882 vào năm 1983, trong khi bản triển khai đầu tiên là named(8), tự mô tả là “máy chủ tên miền Internet”, được phát hành cùng với 4.3BSD, và cũng được bao gồm trong “Network Distribution”. Phần này của BSD, chỉ chứa mã mạng có thể phân phối tự do, sau đó đã được tích hợp vào nhiều hệ điều hành, và các đoạn mã như named cũng được ngành công nghiệp áp dụng rộng rãi.
Chức năng cốt lõi của DNS hầu như không thay đổi kể từ đầu những năm 80. Nó bao gồm một không gian tên duy nhất (namespace), được tổ chức như một cây đảo ngược; “root” nằm ở đỉnh của cây, và bên dưới root là một tập hợp các “Top-Level Domains” (TLD). Các TLD này bao gồm những cái quen thuộc như .com, .org, .net, nhưng trong những thập kỷ gần đây đã mở rộng đáng kể, bao gồm nhiều “country-code TLD” (ccTLD), cũng như các “generic TLD”, với hơn một nghìn TLD khác nhau, từ .men đến .broadway hay .pizza.
Bên dưới các TLD là các domain cấp hai (second-level domain). Ví dụ, đó là phần hpe trong hpe.com. Và bên dưới nữa là cấp ba, như arubanetworking trong arubanetworking.hpe.com. Số lượng cấp của domain chỉ bị giới hạn bởi độ dài tối đa của tên miền, vốn được quy định bởi giao thức DNS.
Khi một máy khách (client) cần phân giải một tên miền, ví dụ để truy cập một website, nó sẽ khởi tạo một quy trình liên quan đến hai loại máy chủ DNS riêng biệt:
Cần lưu ý rằng DNS có độ phức tạp “ngấm ngầm”, và hai vai trò này hoàn toàn có thể được đảm nhiệm bởi cùng một máy chủ DNS. Nghĩa là, một máy chủ vừa có thể là authoritative cho một domain nhất định, vừa đồng thời hoạt động như một recursive resolver.
Hãy cùng đi qua một ví dụ đơn giản với www.hpe.com:
Mô hình này, dù cực kỳ hiệu quả, lại được xây dựng dựa trên một đặc điểm mà kẻ tấn công rất thích khai thác: bất kỳ client nào có quyền truy cập layer 3 tới một recursive DNS resolver đều có thể khiến server đó gửi truy vấn đến bất kỳ authoritative name server nào trên Internet. Recursive resolver đóng vai trò như một proxy, chuyển tiếp yêu cầu của client ra bên ngoài.
Đây chính là nguyên lý cho phép DNS tunneling hoạt động. Kẻ tấn công chỉ cần thiết lập một “authoritative name server” độc hại cho domain mà chúng kiểm soát. Sau đó, mã độc chạy trên máy đã bị xâm nhập có thể gửi các truy vấn DNS được chế tạo đặc biệt, với dữ liệu được nhúng bên trong tên miền, tới recursive resolver nội bộ của công ty.
Resolver, khi thực hiện nhiệm vụ của mình, sẽ thấy một yêu cầu cho domain mà nó không có thẩm quyền quản lý và cũng không có trong cache. Nó sẽ tuân theo giao thức và chuyển tiếp truy vấn chứa dữ liệu này lên chuỗi phân giải, đến authoritative server của kẻ tấn công. Khi đó, kẻ tấn công đã thành công trong việc tuồn dữ liệu ra khỏi mạng, thực hiện kỹ thuật Exfiltration Over C2 Channel (T1041), tất cả đều thông qua DNS server nội bộ của công ty như một “đồng phạm bất đắc dĩ”! Tường lửa chỉ nhìn thấy một truy vấn DNS bình thường đến từ DNS server nội bộ đáng tin cậy, hoàn toàn không thể phân biệt với hàng ngàn truy vấn DNS khác đang lưu thông. “Con đường cao tốc ẩn” đã được hình thành.
Cũng cần lưu ý rằng tồn tại một tập hợp các phần mở rộng của DNS gọi là DNSSEC (DNS Security Extensions). DNSSEC được thiết kế để chống lại các cuộc tấn công man-in-the-middle và poisoning bằng cách sử dụng chữ ký mật mã để xác minh tính xác thực và toàn vẹn của phản hồi DNS. Tuy nhiên, DNSSEC không phải là công cụ đặc biệt hiệu quả để ngăn chặn DNS tunneling hoặc các hình thức rò rỉ dữ liệu khác. Một máy chủ DNS độc hại hoàn toàn có thể sử dụng DNSSEC để ký các phản hồi của nó và vẫn được xác thực bởi resolver hỗ trợ DNSSEC. Ngoài ra, việc triển khai DNSSEC trong các cấu hình DNS nội bộ hoặc “split-horizon” (như trong mạng doanh nghiệp) cũng gặp nhiều thách thức đáng kể, càng hạn chế tính hữu dụng của nó trong trường hợp này. Tuy vậy, ở những nơi có thể triển khai, DNSSEC vẫn là một công cụ hữu ích.
DNS tunneling, vì vậy, là kỹ thuật đóng gói dữ liệu của các giao thức hoặc chương trình khác vào bên trong các truy vấn và phản hồi DNS — một phương pháp được MITRE ATT&CK phân loại là Application Layer Protocol: DNS (T1071.004). Mục tiêu của nó là tạo ra một kênh liên lạc bí mật, hai chiều giữa một client đã bị xâm nhập và máy chủ C2 (Command and Control) của kẻ tấn công, tất cả đều trông giống như lưu lượng DNS hợp lệ.
Thoạt nhìn, điều này có vẻ đơn giản. Nhưng “ác quỷ nằm trong chi tiết”, và các triển khai DNS có rất nhiều chi tiết như vậy.
Cơ chế cốt lõi của DNS tunneling liên quan đến việc mã hóa dữ liệu vào trong các subdomain và hostname của các truy vấn DNS. Theo tiêu chuẩn DNS, các ký tự hợp lệ trong tên miền chỉ bao gồm chữ cái in hoa, chữ số và dấu gạch ngang (-). Do đó, thông thường kẻ tấn công sẽ sử dụng mã hóa Base32 để gửi dữ liệu theo chiều “upstream”.
Tuy nhiên, phần lớn các DNS server thực tế lại “dễ dãi” hơn và không thực thi nghiêm ngặt quy tắc này. Nhiều DNS server thực tế phân biệt chữ hoa và chữ thường — tức là chúng không chuẩn hóa (normalize) kiểu chữ của tên miền. Điều này làm tăng số lượng ký tự có thể sử dụng từ 37 lên 63. Ngoài ra, nhiều DNS server cũng chấp nhận các ký tự như + hoặc _ là hợp lệ, nâng tổng số ký tự phân biệt lên 64, cho phép sử dụng mã hóa Base64 — một sự gia tăng đáng kể về mật độ dữ liệu.
Giả sử chúng ta có thể sử dụng mã hóa Base64. Chúng ta muốn gửi tên đăng nhập và mật khẩu của một tài khoản quản trị đến máy chủ C2. Ta sẽ mã hóa dữ liệu này dưới dạng username:password — ví dụ: admin:rockyou.
admin:rockyou sẽ trở thành YWRtaW46cm9ja3lvdQ. (Để so sánh, phiên bản Base32 sẽ là MFSG22LOHJZG6Y3LPFXXK)evilapt.pizza, ta sẽ có truy vấn: YWRtaW46cm9ja3lvdQ.evilapt.pizzaevilapt.pizza. “Name server” này thực chất là một phần mềm chuyên biệt, có khả năng nhận diện payload và giải mã lại thành admin:rockyou.Đó là cách để đưa dữ liệu ra ngoài. Để tạo thành kênh hai chiều, kẻ tấn công cần có khả năng gửi dữ liệu vào trong. Điều này được thực hiện bằng cách mã hóa dữ liệu vào chính phản hồi DNS, thông qua các Resource Record đã đề cập trước đó.
“Name server” độc hại có thể phản hồi bằng nhiều loại Resource Record khác nhau. Không có một loại nào là tối ưu tuyệt đối — mỗi loại đều có những đánh đổi riêng giữa băng thông, độ ẩn mình (stealth), và tính khả dụng. Hai loại phổ biến nhất là A/AAAA record và TXT record:
Các loại bản ghi khác như CNAME, SRV, MX, và NULL/PRIVATE cũng được sử dụng. Đặc biệt, NULL record có thể chứa một lượng dữ liệu cực lớn — lên đến 64 kilobyte trong một phản hồi! Tuy nhiên, nó không có mục đích sử dụng hợp pháp, được IETF đánh dấu là thử nghiệm, và có thể (và thường xuyên) bị vô hiệu hóa trên resolver hoặc bị chặn bởi các tường lửa có DPI.
DNS tunneling hiện đã trở nên “được thương mại hóa” (commoditized), với nhiều công cụ hỗ trợ triển khai:
Mặc dù DNS tunneling cho C2 và rò rỉ dữ liệu (data exfiltration) là trường hợp sử dụng kinh điển, các tác nhân đe dọa hiện đại đang dần dịch chuyển việc sử dụng kỹ thuật này “sang trái” trong chuỗi “kill chain” an ninh mạng. Chúng đang tận dụng tính ẩn mình của DNS cho những hoạt động tinh vi hơn, ở giai đoạn rất sớm — từ trước khi một cuộc xâm nhập hoàn chỉnh được thiết lập.
OAST (Out-of-Band Application Security Testing) là kỹ thuật trong đó mã khai thác sẽ cố gắng phân giải một hostname cụ thể, đã biết trước và mang tính duy nhất, đồng thời theo dõi các truy vấn tới hostname đó trên name server, nhằm xác định liệu exploit có “thành công” hay không. Phương pháp này đã phổ biến trong giới kiểm thử bảo mật từ lâu, đặc biệt nhờ module “Collaborator” của Burp Suite. Hiện nay có nhiều dịch vụ cung cấp các “endpoint” OAST cho developer/pentester sử dụng, chẳng hạn như oast.fun
Tuy nhiên, hiện nay các tác nhân đe dọa bắt đầu sử dụng kỹ thuật này theo hướng “tấn công”, coi nó như một chỉ dấu xâm nhập (indicator of compromise) cực kỳ kín đáo. Ví dụ, vào đầu năm nay (2025, tại thời điểm bài viết), kho gói Python PyPI đã ghi nhận một tác nhân đe dọa tải lên một package giả mạo tên monoliht, cố tình viết sai chính tả của monolith với hy vọng người dùng vô tình gõ pip install monoliht (đảo vị trí chữ t và h).
Gói này sẽ âm thầm tạo ra các yêu cầu tới dịch vụ OAST oast.fun, mã hóa các thông tin như hostname, username và thư mục làm việc hiện tại vào trong truy vấn DNS.
Tương tự, tên miền cũng có thể được sử dụng để theo dõi người dùng, chẳng hạn trong các chiến dịch phishing. Bằng cách sử dụng Javascript để khởi tạo các yêu cầu tới những domain duy nhất (ví dụ: chứa các giá trị hash riêng biệt trong subdomain), kẻ tấn công có thể tránh việc kích hoạt các kết nối tới những địa chỉ IP đáng ngờ, và thay vào đó chỉ tạo ra các truy vấn DNS “im lặng” gửi tới resolver nội bộ.
Sự “dịch chuyển sang trái” này là một diễn biến rất quan trọng. Nó có nghĩa là các hệ thống phòng thủ không còn có thể xem các dấu hiệu DNS tunneling chỉ đơn thuần là biểu hiện của một C2 beacon đang hoạt động ở giai đoạn hậu khai thác. Một truy vấn DNS duy nhất với entropy cao, tới một domain không xác định, giờ đây có thể chính là dấu hiệu đầu tiên — và cũng có thể là duy nhất — của một cuộc tấn công phishing thành công hoặc một lỗ hổng vừa bị khai thác.
Với mức độ tinh vi và đa dạng của các kỹ thuật DNS tunneling, một chiến lược phát hiện nhiều lớp là điều bắt buộc. Chiến lược này tiến triển từ phân tích thống kê cơ bản đến mô hình hành vi nâng cao và học máy.
Lớp đầu tiên tập trung vào việc xác định các bất thường có thể định lượng trong lưu lượng DNS — những dấu hiệu đặc trưng của hoạt động tunneling.
Các tác nhân tấn công hiện đại có thể né tránh phân tích thống kê đơn giản bằng cách sử dụng kỹ thuật “low-and-slow”. Để đối phó, các giải pháp Network Detection and Response (NDR) xây dựng một baseline hành vi cho hoạt động DNS “bình thường” của toàn bộ mạng cũng như từng host riêng lẻ.
Bằng cách học các mẫu hành vi điển hình của một thiết bị — như nó thường truy vấn những domain nào, với tần suất ra sao, vào thời điểm nào trong ngày, cũng như kích thước truy vấn và phản hồi — hệ thống NDR có thể phát hiện các sai lệch tinh vi mà các rule tĩnh không thể nhận ra.
Ví dụ, một máy trạm của developer đột nhiên bắt đầu gửi các truy vấn A record định kỳ, tần suất thấp, tới một domain chưa từng thấy ở Đông Âu mỗi 30 phút sẽ bị đánh dấu là bất thường có độ tin cậy cao, ngay cả khi các truy vấn riêng lẻ không có entropy cao. Đây chính là “nhịp tim” đặc trưng của một C2 beacon đang ở trạng thái ngủ.
Các phương pháp phát hiện tiên tiến nhất sử dụng machine learning (ML) để nhận diện các mẫu phức tạp, phi tuyến tính mang dấu hiệu độc hại.
Phát hiện là yếu tố quan trọng, nhưng chỉ là một nửa của cuộc chiến. Một hệ thống phòng thủ hiệu quả trước DNS tunneling đòi hỏi một chiến lược defense-in-depth mạnh mẽ, kết hợp giữa kiểm soát kiến trúc, thực thi chính sách chặt chẽ và kiểm tra chủ động. Mục tiêu là khiến việc tunneling trở nên khó khăn, chậm chạp và dễ bị phát hiện đến mức kẻ tấn công buộc phải chuyển sang các phương pháp khác dễ bị phát hiện hơn.
Việc áp dụng giới hạn tốc độ (rate limiting) trên các resolver nội bộ có thể giới hạn số lượng truy vấn mà một client có thể gửi trong một khoảng thời gian nhất định. Dù không thể ngăn chặn hoàn toàn một kẻ tấn công kiên nhẫn, biện pháp này rất hiệu quả trong việc phá vỡ các hoạt động exfiltration dữ liệu khối lượng lớn, khiến chúng trở nên không thực tế và dễ kích hoạt các cảnh báo khác, từ đó giúp đội ngũ bảo mật có thêm thời gian phản ứng. Ngoài ra, có thể áp dụng các chính sách giới hạn độ dài tối đa của truy vấn DNS và chặn các loại record không có mục đích sử dụng hợp pháp (ví dụ: NULL record), thông qua các nền tảng như HPE Aruba Networking SSE. Dù việc chặn hoàn toàn TXT record thường là không khả thi, vẫn có thể thiết lập các chính sách để đánh dấu hoặc giám sát chặt chẽ hơn các phản hồi TXT có kích thước lớn bất thường từ các domain không đáng tin cậy.
Chủ động săn tìm dấu hiệu của DNS tunneling trong log DNS của bạn, tận dụng các công cụ như Aruba Central Client Insights. Đừng chờ đến khi có cảnh báo. Hãy bắt đầu với các truy vấn dựa trên các TTP đã biết. Ví dụ: “Một tác nhân đe dọa đang sử dụng DNS Beacon của Cobalt Strike. Hãy tìm các truy vấn A record mang tính định kỳ tới một domain duy nhất, luôn nhận về phản hồi 0.0.0.0.”
Cách duy nhất để biết hệ thống phòng thủ của bạn có hoạt động hay không là kiểm thử. Hãy thực hiện các bài diễn tập red team có kiểm soát một cách định kỳ, sử dụng các công cụ như dnscat2/blind và Cobalt Strike. Những bài kiểm thử này mang lại phản hồi thực tế vô giá về việc liệu các rule phát hiện trên HPE Aruba Networking EdgeConnect SD-WAN có hoạt động hay không, các giới hạn tốc độ có hiệu quả hay không, và các kiểm soát kiến trúc được cấu hình trong ClearPass có thực sự ngăn chặn được lưu lượng DNS đi trực tiếp ra ngoài hay không.
DNS-over-HTTPS (DoH) và DNS-over-TLS (DoT) mã hóa lưu lượng DNS và đặt ra một thách thức rất lớn đối với bảo mật doanh nghiệp. Đặc biệt, DoH là một vấn đề nghiêm trọng, được mô tả như “công cụ Shadow IT tối thượng” vì nó đóng gói các truy vấn DNS bên trong lưu lượng HTTPS tiêu chuẩn trên cổng 443 (một dạng Protocol Tunneling – T1572), khiến nó không thể phân biệt với các yêu cầu web thông thường. Khi các trình duyệt bật DoH mặc định, chúng sẽ vượt qua các cơ chế kiểm soát DNS của doanh nghiệp và tạo ra một kênh liên lạc mã hóa, không được quản lý, che giấu cả hoạt động tunneling độc hại lẫn việc sử dụng ứng dụng trái phép.
Một lần nữa, cách phòng thủ tốt nhất vẫn là defense-in-depth:
| Tactic | Technique ID | Tên | Mức độ liên quan |
|---|---|---|---|
| Command and Control | T1071.004 | Application Layer Protocol: DNS | Kỹ thuật chính được sử dụng cho DNS tunneling. |
| Exfiltration | T1041 | Exfiltration Over C2 Channel | Sau khi thiết lập kênh C2 bằng DNS (T1071.004), kẻ tấn công sử dụng chính kênh này để tuồn dữ liệu bị đánh cắp ra ngoài mạng. |
| Defense Evasion | T1572 | Protocol Tunneling | Kẻ tấn công sử dụng các giao thức như DNS-over-HTTPS (DoH) để đóng gói truy vấn DNS độc hại bên trong lưu lượng HTTPS hợp lệ đã được mã hóa, nhằm né tránh các công cụ chỉ kiểm tra DNS thông thường. |
| Defense Evasion | T1568.002 | Dynamic Resolution: Domain Generation Algorithms (DGAs) | Malware sử dụng DGA để định kỳ tạo ra số lượng lớn tên miền nhằm kết nối tới C2. Kỹ thuật này thường được phát hiện thông qua tỷ lệ phản hồi NXDOMAIN cao. |
| Initial Access | T1566 | Phishing | Kẻ tấn công sử dụng email lừa đảo để dụ người dùng truy cập các trang độc hại. DNS đóng vai trò nền tảng trong quá trình này, vì máy người dùng cần phân giải domain của liên kết độc hại, và một số chiến dịch phishing còn tạo thêm truy vấn DNS để theo dõi. |
| Resource Development | T1583.001 | Acquire Infrastructure: Domains | Các tác nhân đe dọa thu thập domain để phục vụ hoạt động của mình, bao gồm đăng ký domain mới cho C2 hoặc tái sử dụng các domain hết hạn từng thuộc Shadow IT. |
DNS là và sẽ tiếp tục là một giao thức nền tảng của Internet. Mức độ tin cậy ngầm định và sự phổ biến rộng khắp của nó đảm bảo rằng các tác nhân đe dọa sẽ tiếp tục khai thác DNS theo những cách ngày càng sáng tạo và tinh vi hơn. Cuộc chiến bảo mật DNS không phải là một dự án làm một lần rồi xong, mà là một quá trình thích nghi liên tục, đòi hỏi một chiến lược defense-in-depth kết hợp giữa kiến trúc vững chắc, chính sách thông minh và sự giám sát chủ động.
Việc thay đổi góc nhìn — từ xem DNS như một “con quái vật” không nên động vào, hay một “đường ống ngu ngốc”, sang coi nó là một “đường cao tốc thông tin bí mật” tiềm ẩn nguy cơ — sẽ giúp chúng ta bắt đầu xây dựng một thế trận phòng thủ vững chắc hơn. Bằng cách buộc toàn bộ lưu lượng đi qua các điểm kiểm soát được giám sát, áp dụng phân tích hành vi và thống kê để phát hiện tín hiệu độc hại trong “nhiễu” DNS, và liên tục kiểm thử hệ thống bằng pentest/red team thực tế, chúng ta có thể loại bỏ “điểm mù DNS” và đóng lại “con đường ẩn” này, tước đi một trong những công cụ mạnh nhất của kẻ tấn công và buộc chúng phải chuyển sang các phương thức dễ bị phát hiện hơn.
Địa chỉ: Số 23E4 KĐT Cầu Diễn, Tổ 7, Phú Diễn, Bắc Từ Liêm, Hà Nội
Điện thoại: 0243 201 2368
Hotline: 098 115 6699
Email: info@datech.vn
Website: https://datech.vn
