DNSトンネリングとはなんなのか

DNSトンネリングとは、DNS問い合わせやDNS応答の中に、本来DNSとは関係のないデータを埋め込み、DNS通信に見せかけて外部と通信する手法です。

DNSは、Webサイトやメール、各種アプリケーションを利用するうえで欠かせない基本的な仕組みです。

そのため、多くのネットワーク環境ではDNS通信が許可されています。

DNSトンネリングは、この「DNS通信は通りやすい」という性質を利用して、外部との通信を隠す目的で使われます。

攻撃に悪用される場合、DNSトンネリングは以下のような用途で使われることがあります。

• マルウェアのC2通信
• 認証情報や端末情報の持ち出し
• ネットワーク制限の回避
• セキュリティ監視の回避

ただし、DNSトンネリング自体は技術的な概念であり、すべてが攻撃というわけではありません。

セキュリティ検証や研究目的で使われる場合もあります。

しかし、実務上は情報漏えいやマルウェア通信の文脈で問題視されることが多い手法です。

DNSの基本的な仕組み

DNSは名前解決のための仕組み

DNSは、ドメイン名に紐づく情報を問い合わせるための仕組みです。

一般的には、以下のようにドメイン名をIPアドレスに変換する役割として説明されます。

example.com → 93.184.216.34

人間は example.com のようなドメイン名を使ってWebサイトにアクセスしますが、コンピューター同士はIPアドレスを使って通信します。

そのため、Webサイトにアクセスする前には、裏側でDNS問い合わせが行われています。

DNSはIPアドレス以外の情報も扱う

DNSは「ドメイン名をIPアドレスに変換する仕組み」と説明されることが多いですが、厳密にはIPアドレス以外の情報も扱います。

代表的なDNSレコードには、以下のようなものがあります。

レコード	役割
A	IPv4アドレスを返す
AAAA	IPv6アドレスを返す
CNAME	別名を返す
MX	メールサーバーを指定する
TXT	テキスト情報を返す
NS	権威DNSサーバーを指定する

このように、DNSはさまざまな情報を問い合わせるための仕組みです。

DNSトンネリングでは、このDNSの柔軟性が悪用されることがあります。

DNSトンネリングの仕組み

DNS通信の中にデータを埋め込む

DNSトンネリングでは、DNS問い合わせのドメイン名部分や、DNS応答の中にデータを埋め込みます。

たとえば、攻撃者が以下のようなドメインを管理しているとします。

attacker-example.com

感染端末は、次のようなDNS問い合わせを送信します。

encoded-data.attacker-example.com

この encoded-data の部分に、外部へ送信したい情報が含まれます。

実際には、データはそのまま入れられるわけではありません。

DNS名として使える文字に変換される必要があります。

そのため、Base32、Base64 URL-safe、16進数表現、独自エンコードなどが使われることがあります。

攻撃者の権威DNSサーバーに問い合わせが届く

DNS問い合わせは、端末から直接攻撃者のサーバーに届くとは限りません。

多くの場合、社内DNSリゾルバや再帰DNSリゾルバを経由して、最終的に攻撃者が管理するドメインの権威DNSサーバーへ到達します。

流れを簡単に表すと、以下のようになります。

感染端末
  ↓
社内DNSリゾルバ
  ↓
再帰DNSリゾルバ
  ↓
攻撃者が管理する権威DNSサーバー

攻撃者は、権威DNSサーバーに届いた問い合わせ名を確認することで、サブドメイン部分に埋め込まれたデータを取り出せます。

DNS応答を使って命令を返すこともある

DNSトンネリングでは、端末から外部へデータを送るだけでなく、外部から端末へデータを返すこともあります。

たとえば、攻撃者がDNS応答の中にコマンドや設定情報を含めることで、感染端末に次の動作を指示できます。

待機する
次の通信先へ接続する
指定された情報を送信する
追加のマルウェアを取得する

このように、DNSトンネリングは双方向の通信路として使われる場合があります。

DNSトンネリングで使われる主な用途

マルウェアのC2通信

DNSトンネリングは、マルウェアのC2通信に使われることがあります。

C2とは「Command and Control」の略で、攻撃者が感染端末に命令を出したり、感染端末から情報を受け取ったりするための通信を指します。

通常、C2通信にはHTTPやHTTPSが使われることもあります。

しかし、これらの通信がファイアウォールやプロキシ、EDRなどに検知・制限される可能性があります。

そこで、攻撃者はDNS通信を使い、通常の名前解決に見せかけてC2通信を行うことがあります。

情報の持ち出し

DNSトンネリングは、情報の持ち出しにも悪用されます。

たとえば、感染端末から以下のような情報を外部へ送るケースがあります。

端末名
ユーザー名
内部IPアドレス
認証情報
ファイルの断片
システム情報

DNSは一度に送れるデータ量が大きくありません。

そのため、攻撃者はデータを細かく分割し、複数回のDNS問い合わせに分けて送信します。

イメージとしては、以下のような形です。

chunk001.attacker-example.com
chunk002.attacker-example.com
chunk003.attacker-example.com

それぞれのサブドメイン部分に分割されたデータが含まれ、攻撃者側で再構成されます。

ネットワーク制限の回避

一部のネットワークでは、HTTP、HTTPS、SSH、VPNなどの通信が制限されていても、DNS通信だけは許可されている場合があります。

DNSトンネリングは、このような環境でネットワーク制限を回避するために使われることがあります。

ただし、許可されていないネットワークで通信制限を回避する行為は、不正アクセスや規約違反につながる可能性があります。

業務環境や公共ネットワークで試すべきではありません。

DNSトンネリングが危険な理由

DNS通信は多くの環境で許可されている

DNSは、Webサイト閲覧やメール送受信、クラウドサービス利用などに必要な通信です。

そのため、多くのネットワーク環境ではDNS通信が許可されています。

HTTPやSSHなどの通信が厳しく制御されていても、DNSだけは利用できる構成になっている場合があります。

この性質により、攻撃者にとってDNSは外部通信の抜け道になりやすい通信経路です。

通常の通信に紛れやすい

DNS問い合わせは、日常的に大量に発生します。

Webサイトを1ページ表示するだけでも、広告配信、アクセス解析、CDN、画像配信、外部スクリプトなどにより、多くのDNS問い合わせが行われます。

そのため、不審なDNS通信が発生していても、通常の通信に紛れて見逃される可能性があります。

少量のデータを継続的に送信できる

DNSは大容量データ転送には向いていません。

しかし、認証情報、端末情報、コマンド、設定値などの小さなデータを送るには十分な場合があります。

また、データを細かく分割して多数のDNS問い合わせに分ければ、ある程度まとまった情報を外部に送信することも可能です。

このように、一回あたりの通信量は小さくても、継続的に行われることで情報漏えいにつながる危険があります。

DNSトンネリングで使われやすいDNSレコード

Aレコード・AAAAレコード

AレコードはIPv4アドレスを返すためのレコードです。AAAAレコードはIPv6アドレスを返すためのレコードです。

DNSトンネリングでは、問い合わせ名のサブドメイン部分にデータを埋め込み、AレコードやAAAAレコードの問い合わせとして送信することがあります。

また、応答側でIPアドレスの形を利用して、少量の情報を返す場合もあります。

TXTレコード

TXTレコードは、テキスト情報を返すためのレコードです。

任意の文字列を扱いやすいため、DNSトンネリングで悪用されることがあります。

ただし、TXTレコードには正当な用途も多くあります。

たとえば、以下のような用途です。

SPF
DKIM
DMARC
Google Search Consoleの所有権確認
Microsoft 365やGoogle Workspaceのドメイン確認
各種SaaSの認証設定

そのため、TXTレコードの問い合わせがあるだけで悪性とは判断できません。

重要なのは、問い合わせの量、頻度、ドメインの不審さ、サブドメインの長さ、ランダム性、端末の挙動などを総合的に確認することです。

CNAMEレコード

CNAMEレコードは、あるドメイン名を別のドメイン名の別名として扱うためのレコードです。

DNSトンネリングで使われる場合、応答データの表現や通信の中継のような形で利用されることがあります。

NULLレコード

NULLレコードは任意のバイナリデータを扱えるレコードですが、現在の一般的なDNS運用ではあまり使われません。

そのため、NULLレコードが頻繁に使われている場合、それ自体が不審な兆候になる可能性があります。

実務上は、A、AAAA、TXT、CNAMEなどの方が調査対象として見る機会は多いです。

DNSトンネリングの典型的な攻撃の流れ

攻撃者がドメインを準備する

まず、攻撃者は自分が管理するドメインを用意します。

attacker-example.com

そして、そのドメインの権威DNSサーバーを攻撃者側で制御できるようにします。

これにより、対象端末から送られてきたDNS問い合わせを攻撃者が受け取れる状態になります。

端末がマルウェアに感染する

次に、標的となる端末がマルウェアに感染します。

感染経路としては、以下のようなものがあります。

フィッシングメール
悪意ある添付ファイル
不正なWebサイト
脆弱性の悪用
不正なスクリプト
改ざんされたソフトウェア

感染後、マルウェアは外部との通信経路としてDNSを利用する場合があります。

感染端末がDNS問い合わせを送る

感染端末は、端末情報や盗み出したデータ、通信確認用の識別子などをエンコードし、サブドメイン部分に埋め込みます。

encoded-client-data.attacker-example.com

この問い合わせは、通常のDNS問い合わせとしてネットワーク上を流れます。

攻撃者がデータを取得する

問い合わせが攻撃者の権威DNSサーバーに届くと、攻撃者は問い合わせ名に含まれるデータを取り出します。

複数の問い合わせに分割されたデータであれば、攻撃者側で順番に並べ直して復元します。

DNS応答で命令を返す

攻撃者は、DNS応答の中に次の命令や設定情報を含めることがあります。

次の通信間隔
追加の接続先
実行するコマンド
送信すべき情報
待機命令

感染端末はDNS応答を受け取り、その内容に従って次の動作を行います。

DNSトンネリングの検知ポイント

長いサブドメインが頻発している

DNSトンネリングでは、データをサブドメイン部分に埋め込むため、通常より長いドメイン名が使われることがあります。

たとえば、以下のような問い合わせです。

x7adk39sdf92kslq0zmxp01.attacker-example.com
x7adk39sdf92kslq0zmxp02.attacker-example.com
x7adk39sdf92kslq0zmxp03.attacker-example.com

正規サービスでも長いサブドメインが使われることはありますが、特定端末から特定親ドメインに対して長いサブドメインの問い合わせが大量発生している場合は注意が必要です。

ランダム性の高い文字列が使われている

DNSトンネリングでは、エンコードされたデータがドメイン名に含まれるため、人間が読む単語ではなく、ランダムな英数字のように見えることがあります。

通常のドメイン名は、以下のように意味のある単語を含むことが多いです。

login.example.com
api.example.com
cdn.example.com
mail.example.com

一方、DNSトンネリングでは、以下のような不自然な文字列が使われる場合があります。

a8s7d6f5g4h3j2k1.example.com

このような文字列のランダム性は、エントロピー分析によって検知対象にされることがあります。

特定の親ドメインへの問い合わせが多い

DNSトンネリングでは、サブドメイン部分だけが毎回変わり、親ドメインは同じになることがあります。

aaa111.attacker-example.com
bbb222.attacker-example.com
ccc333.attacker-example.com

この場合、FQDN単位で見ると別々の問い合わせに見えます。

しかし、親ドメイン単位で集計すると、attacker-example.com に大量の問い合わせが集中していることが分かります。

そのため、検知ではFQDN単位だけでなく、親ドメインや登録ドメイン単位で集計することが重要です。

TXTレコードの問い合わせが不自然に多い

TXTレコードは正当な用途も多い一方で、DNSトンネリングに悪用されることもあります。

特定の端末から、特定の不審なドメインに対して、長いサブドメインを伴うTXT問い合わせが大量に発生している場合は調査対象になります。

ただし、TXTレコードの利用だけで悪性と判断するのは危険です。

SPF、DKIM、DMARC、SaaS連携などの正当な利用もあるため、他の指標と組み合わせて判断する必要があります。

NXDOMAINが大量に発生している

NXDOMAINとは、「問い合わせたドメインが存在しない」という応答です。

DGA系マルウェアや一部のDNS悪用では、存在しないドメインへの問い合わせが大量に発生することがあります。

ただし、DNSトンネリングでは必ずNXDOMAINが発生するわけではありません。

攻撃者が管理する権威DNSサーバーが正常な応答を返す構成になっていれば、NXDOMAINは多発しない可能性があります。

そのため、NXDOMAINの大量発生は不審な兆候の一つですが、DNSトンネリングの必須条件ではありません。

通信頻度や時間帯が不自然

DNSトンネリングでは、短時間に大量の問い合わせが発生することがあります。

また、業務時間外や深夜に特定端末から継続的なDNS問い合わせが行われている場合も、不審な兆候になります。

確認すべきポイントは以下です。

観点	確認内容
頻度	短時間に大量発生していないか
継続性	長時間にわたって一定間隔で発生していないか
時間帯	業務外や深夜に発生していないか
送信元	特定端末に偏っていないか
問い合わせ先	特定ドメインに集中していないか

DNSトンネリングへの対策

社内DNSリゾルバの利用を強制する

まず重要なのは、端末が自由に外部DNSへ問い合わせできないようにすることです。

推奨される構成は、以下のような形です。

社内端末 → 社内DNSリゾルバ → 外部DNS

端末から直接、外部のDNSサーバーへ問い合わせできる状態だと、攻撃者が用意したDNSサーバーやパブリックDNSを使って監視を回避される可能性があります。

そのため、端末から外部へのUDP/TCP 53番通信は制限し、許可されたDNSリゾルバのみ利用させることが重要です。

DNSログを取得・保管する

DNSトンネリングを検知するには、DNSログの取得が欠かせません。

ログとして残すべき主な項目は以下です。

項目	確認内容
クライアントIP	どの端末が問い合わせたか
問い合わせ名	どのドメインを問い合わせたか
レコード種別	A、AAAA、TXT、CNAMEなど
応答コード	NOERROR、NXDOMAINなど
応答サイズ	不自然に大きくないか
問い合わせ時刻	いつ発生したか
問い合わせ回数	短時間に集中していないか

DNSログは、SIEMやNDR、EDRなどと連携して分析できる状態にしておくと効果的です。

不審なドメインをブロックする

DNSフィルタリングや脅威インテリジェンスを活用し、既知の悪性ドメインへの問い合わせをブロックすることも有効です。

ただし、攻撃者が新規取得したドメインや、まだ評価されていないドメインを使う場合、ブラックリストだけでは防ぎきれません。

そのため、既知の悪性ドメインをブロックする対策に加えて、未知のドメインに対する異常検知も必要です。

DNSクエリの異常検知を行う

DNSトンネリング対策では、DNS問い合わせの内容やパターンを分析することが重要です。

具体的には、以下のような指標を見ます。

サブドメインの長さ
文字列のランダム性
親ドメイン単位の問い合わせ回数
TXTレコードの頻度
問い合わせ間隔
NXDOMAIN率
応答サイズ
端末ごとのDNS通信量

単一の指標だけで判断すると誤検知が増えるため、複数の指標を組み合わせて判断することが重要です。

DoH・DoTの利用を制御する

DNS over HTTPSやDNS over TLSは、DNS通信を暗号化する正規の技術です。

プライバシー保護や改ざん防止の観点では有用ですが、企業ネットワークではDNSログ監視やDNSフィルタリングを回避される可能性があります。

そのため、組織では以下のような対策が必要です。

許可されたDNSリゾルバのみ利用させる
無許可のDoH/DoTを制限する
プロキシやEDRで不審なDNS関連通信を監視する
DNSポリシーを明確にする

DoHやDoTそのものが悪いわけではありませんが、管理されていない暗号化DNS通信はリスクになります。

EDRやSIEMと組み合わせて調査する

DNSログだけでは、正規通信と悪性通信の判別が難しいことがあります。

たとえば、以下の2つは大きく意味が異なります。

ブラウザがCDN系ドメインへ多数のDNS問い合わせをしている
不明な実行ファイルがランダムなサブドメインへ多数のDNS問い合わせをしている

そのため、DNSログに加えて、端末側のプロセス情報やネットワークログを組み合わせて調査することが重要です。

確認すべき情報は以下です。

観点	確認内容
プロセス	どのプログラムがDNS問い合わせを発生させたか
親プロセス	Office、PowerShell、不審なスクリプトなどから起動していないか
端末	どのPC・サーバーで発生しているか
ユーザー	どのユーザー権限で動作しているか
通信先	新規取得ドメインや未知のドメインではないか
時系列	感染兆候やメール開封後に発生していないか

DNSトンネリングと似た攻撃・技術

DGA

DGAは「Domain Generation Algorithm」の略です。

マルウェアが大量のドメイン名を自動生成し、その中のどれかを使ってC2サーバーに接続する手法です。

DNSトンネリングとは異なる技術ですが、どちらも不審なDNS問い合わせを発生させるため、検知観点が一部似ています。

特に、ランダムな文字列のドメインや、NXDOMAINの大量発生などは、DGAでも見られることがあります。

DNSキャッシュポイズニング

DNSキャッシュポイズニングは、DNSの応答を不正に改ざんし、ユーザーを偽サイトや攻撃者のサーバーへ誘導する攻撃です。

DNSトンネリングは、DNS通信を使って別のデータを送受信する手法です。

どちらもDNSを悪用する点では共通していますが、目的と仕組みは異なります。

DNS over HTTPS・DNS over TLS

DNS over HTTPSやDNS over TLSは、DNS通信を暗号化する正規の技術です。

これらはDNSトンネリングそのものではありません。

ただし、企業ネットワークにおいて無許可で使われると、DNS監視やDNSフィルタリングを回避する手段になる可能性があります。

Webサイト運用者が注意すべきポイント

DNSトンネリングはWeb担当者にも無関係ではない

DNSトンネリングは、セキュリティ担当者だけが知っていればよい話ではありません。

Webサイト運用者、Webマーケター、WordPress管理者、広告運用担当者にも関係します。

たとえば、企業サイトやWordPressサイトが改ざんされ、不審なJavaScriptや外部通信が仕込まれた場合、訪問者や管理者の環境で不審な通信が発生する可能性があります。

また、DNS管理が不十分だと、不要なサブドメインや古いCNAMEレコードが放置され、攻撃者に悪用されるリスクもあります。

不要なDNSレコードを放置しない

Webサイト運用では、過去に使っていたサブドメインや検証環境のDNSレコードが放置されることがあります。

たとえば、以下のようなものです。

旧キャンペーンサイトのサブドメイン
使わなくなったLP用ドメイン
テスト環境のCNAME
退職者や外部制作会社が作成したDNSレコード
一時的なSaaS認証用レコード

これらを放置すると、サブドメインテイクオーバーや不正利用のリスクが高まります。

定期的にDNSレコードを棚卸しし、不要なレコードは削除することが重要です。

DNS管理画面の権限を適切に管理する

DNS設定を変更できる権限は非常に重要です。

攻撃者がDNS管理画面にアクセスできると、Webサイトやメール、サブドメインの設定を不正に変更される可能性があります。

最低限、以下の対策を行うべきです。

DNS管理画面のMFAを有効化する
不要な管理者アカウントを削除する
外部制作会社の権限を定期的に見直す
退職者のアカウントを無効化する
変更履歴を確認できる状態にする
DNSレコードの棚卸しを定期的に行う

DNSトンネリングを理解するうえでの注意点

DNSトンネリングは単一の特徴だけでは断定できない

DNSトンネリングの検知では、長いサブドメイン、ランダムな文字列、TXTレコードの多用、問い合わせ頻度などが注目されます。

しかし、これらの特徴があるからといって、必ずDNSトンネリングとは限りません。

正規のクラウドサービス、CDN、広告配信、アクセス解析、セキュリティ製品などでも、複雑なDNS問い合わせが発生する場合があります。

そのため、実務では複数の要素を組み合わせて判断する必要があります。

DNSトンネリングは必ず大容量通信になるわけではない

DNSトンネリングは、動画や大容量ファイルを高速に送るような用途には向いていません。

DNSにはドメイン名の長さや応答サイズに制限があるため、基本的には小さなデータを分割して送る手法です。

そのため、通信量だけを見ても検知できない場合があります。

むしろ、問い合わせ名の不自然さ、問い合わせ頻度、送信元プロセス、親ドメイン単位の集計などが重要になります。

DNSトンネリング自体は技術概念である

DNSトンネリングは悪用されることが多い技術ですが、技術そのものが必ずしも違法・悪性というわけではありません。

研究、検証、セキュリティ教育、閉域環境でのテストなど、正当な目的で扱われる場合もあります。

ただし、他人のネットワークや組織の通信制限を回避する目的で使うと、不正アクセスや規約違反につながる可能性があります。

まとめ

DNSトンネリングとは、DNS問い合わせやDNS応答の中に本来DNSとは関係のないデータを埋め込み、DNS通信に見せかけて外部と通信する手法です。

攻撃に悪用される場合、マルウェアのC2通信、認証情報や端末情報の持ち出し、ネットワーク制限の回避などに使われます。

DNSは多くの環境で必要な通信であり、通常の通信に紛れやすいため、攻撃者にとって悪用しやすい経路になり得ます。

一方で、DNSトンネリングは単一の特徴だけで断定できるものではありません。

長いサブドメイン、ランダム性の高い文字列、特定親ドメインへの大量問い合わせ、TXTレコードの多用、NXDOMAINの発生、通信頻度、端末プロセス情報などを組み合わせて判断することが重要です。

対策としては、社内DNSリゾルバの利用強制、外部DNSへの直接通信の制限、DNSログの取得、DNSフィルタリング、DoH・DoTの制御、EDRやSIEMとの連携が有効です。

DNSトンネリングを一言で表すなら、DNSという通常の通信経路を使って、別のデータ通信を隠して通す手法です。

ネットワーク防御においては、DNSを「ただの名前解決」として見るのではなく、重要な監視対象として扱うことが求められます。

以上、DNSトンネリングとはなんなのかについてでした。

最後までお読みいただき、ありがとうございました。