C2サーバとDGA（Domain Generation Algorithm）

Pipeline Co. Ltd.
2021年5月1日
読了時間: 7分

C2サーバとは

C2とはCommand and Controlのことを意味し、インターネットに接続したC2サーバは感染PCで動作するマルウェアと通信を確立することにより、サイバー攻撃者がC2サーバを介して感染PCにリモート操作可能な状態となる。

詳細には、以下のようなプロセスを経る。

攻撃者はマルウェアを作成後、ダウンロードサイトにマルウェアを配置する。このサイトのURLは例えば　Windows Updateといった正式なサイトを偽装している。

さらに、C2サーバも用意しておく。

攻撃者は攻撃対象のユーザに正式な通知を偽装して偽装URLを含むメールを送る。

ユーザは意図せず偽装URLのリンクをクリックする。

偽装URLの名前解決がDNSにより実施され、マルウェアがユーザPC上でインストール＆実行される。

マルウェアはC2サーバと接続を確立し、ビーコンを定期的に通信する。この際、マルウェアに設定されたC2サーバ先が名前で指定されている場合は、名前解決がDNSにより実施される。

攻撃者はC2サーバに対して悪意ある操作を行うコマンドを実行するよう指示する。

C2サーバは指示されたコマンドをマルウェアに対して指示し、マルウェアはユーザPC上でそれを実行する。

（図１）

図１　攻撃者がC2サーバを介して標的PCを攻撃するプロセス

DGA（Domain Generation Algorithm）とは

これをみると、④においてマルウェアは攻撃者のC2サーバにDNSへ名前解決のための問い合わせ通信を繰り返し送信していることがわかる。そしてその通信の中身をみると、宛先の名前は一見例えばWindows Updateサイトのような正規サイトのような感じで、よくみると部分的にスペルが違う・後に意味のない文字の羅列が続くなど奇妙な見た目の文字列が確認できる。

しかもこの奇妙な文字列は全く同じものだけを繰り返し送信しているというよりは、動的に生成した文字列を数百・数万個も送信しており、しかもDNSへの問い合わせは成功しているものもあれば、多くは失敗している。

これは動的に生成したドメイン名の中からDNSによって名前解決できるものがC2サーバの名前に合致するというロジックであることがわかる。

もしマルウェアのバイナリ内や設定ファイル内にC2サーバ情報が直接書き込まれていた場合は従来からのルールベースの防御手段で対応できるが、実際には動的に大量に生成された情報が存在するので、人力で分析することは困難な作業となる。

これを解決する手段として、機械学習が用いられる。

まずいくつかの既知の悪意あるドメインと無害なドメインで構成される分類済みの学習用データセットを用意する。このデータセットを使って機械学習によりコンピュータに学習させる。その後、このコンピュータにとって未知のドメインを悪意あるもの、または悪意あるものに近いもの、そして、安全なものに分類させるというのが大まかな方針だ。

一方、マルウェアは動的にドメインを生成するために特定のアルゴリズムを使っている。いわゆるDGAと呼ばれるものだ。DGAには多種多様なバリエーションがある。ランダムに見えるドメインを生成するものもあれば、単語リストを使用するものもある。

それに対して検知する側としては、できるだけマルウェアのDGAの特徴を捉えられるような情報を機械学習に入力させるかが検知の精度を決めることになる。

ただし、もしマルウェアのDGA自体を入手できれば完全に防御可能となる。生成されるC2サーバドメインを列挙することができるからだ。

さらに捜査機関によってアクティブなドメインの所在が明らかにされ、C2サーバを停止させることができる。このようにしてマルウェアとC2サーバを利用した攻撃自体を無効化できるようになるケースもある。

名前解決とDNS

マルウェアの活動を検知するにはDNSによる名前解決の情報を分析することが重要であることがわかった。

では、そもそもDNSを使った名前解決とはどういうものなのだろうか。

ここでは、DNSの仕組みを大枠で理解することを目標に解説する。これは、DNS通信の分析において、特に説明を受ける側に関わる時に必要となる知識を得ることを目的とする。

さらに、大枠での理解のため、詳細な説明は省き、厳密性はある程度犠牲にしていることに留意してほしい。

端末からDNSによる名前解決のフローを図２に示す。

ここでは端末上でインターネットブラウザを使ってインターネットサイトに接続する場合を例に示す。

DNS通信では、通信方式としてUDPと呼ばれるプロトコル（通信手順）を用いる。さらに、この通信にポート番号として53番を使用する。これはDNS通信をする際はこの番号を付加する取り決めになっているからである。さらに、外部DNSを参照するため、ファイアウォールにはUDP/53の許可設定がある。

端末でブラウザにドメイン名を含む宛先（URL）を入力して実行すると、端末のブラウザがOSの機能と連携してDNSへ接続先IPアドレス情報をOSのネットワーク設定にあるDNS（自組織ネットワークで稼働しているDNS、インターネットプロバイダが管理するDNSなど）に問い合わせる。

もしそのDNSに情報がない場合は、そのDNSに設定してある外部DNSへ問い合わせる。

外部DNSにてIPアドレス情報がある場合、外部DNSは要求してきたDNSに対してIPアドレス情報を応答する。

IPアドレス情報を受けたDNSは端末へIPアドレスを応答する。ここで、次回以降同じドメイン名の問い合わせがあったときのために、この情報をキャッシュとして一定期間保管しておく。これにより、毎回外部DNSに要求することを避ける。これはDNS間の通信による輻輳を避けることを目的としている。

端末はIPアドレス情報の応答を受け、そのIPアドレスでサイトに接続する。

さらに端末のOSは、この情報をキャッシュとして一時保管し、直近のドメイン情報を毎回DNSへ問い合わせすることを避けるようになっている機能がある。

まれにこのキャッシュの更新がうまく行かず、キャッシュ内情報と実在する情報に齟齬が発生して通信に失敗する場合がある。この場合にキャッシュクリアをすることにより問題を回避することがある。具体的には、Windowsでは“ipconfig /flushdns”というコマンドである。また、現在のキャッシュ情報を参照するのは“ipconfig /displaydns”というコマンドである。

図２　DNSによる名前解決（ドメイン名からIPアドレス情報を得る）フロー

このように、DNSは現在誰もが利用してありふれたものになっているインターネット利用のスタイルにおいて、重要な役割を持っている。インターネットの一般への普及が可能となった要因の一つとしてDNSの存在があったのだ。

では、DNSが無い頃はどうだったのだろうか。

日本において通信ネットワークがインターネットにつながり始めたのは１９８０年代の終わり頃になる。それ以前またその直後、まだDNSは普及していなかったが、やはりその当時でもIPアドレスを直接入力したり表示したりするのは、そのサイトがどういうものなのかを識別するのに不便であるという認識だった。

そこで、自組織内の各PC内にhostsファイルというファイルを準備し、そこにドメイン名とIPアドレスの対応表を直接書いておくという方法がよく使われていた。そしてブラウザにhostsファイルに書かれているドメイン名を入力して接続実行すると、OSはhostsファイルに書かれた情報を参照して、そこで得たIPアドレスを用いてサイトに接続するという手順となっていた。

しかし、全ての端末にhostsファイルを準備することは管理が煩雑になる。端末管理の一環として管理担当者が端末にhostsファイルをコピーしたり、ネットワーク利用者へhosts変更手順を通知して、それを利用者が見ながら手動で入力したり、というような方法が取られていた。

しかも、インターネットが大学・研究所・一部企業のみならず、一般利用が進めば、接続先サイトが膨大になることから、hostsファイルを使った手動での管理はすぐに限界を迎えることは目に見えていた。

そのような中、DNSのあり方について国内でも検討が進められた。例えば、ドメイン名の登録業務、階層構造で構成されるドメインのルートドメインの管理などがある。

そして1995年、インターネット関連機能が標準搭載されたWindows95が発売され、インターネットの一般利用が大きく進んだ。Windows95においてもhostsファイルの利用は少なからずあったが、多くはDNSを利用するようになった。

今や多くの人がインターネットに接続するデバイスを常に持ち歩き、画面を見る・見ないに関わらずインターネットに常時接続する時代となった。さらに近い将来に向けて、インターネット接続デバイスとして自動車・家電が加わりつつある。

このような中、全世界規模の分散ネットワークシステムであるDNSは、既に利用者が意識する機会はほとんどないが、重要なインフラの一つとして世界に存在し続けている。