DNSトンネリングを利用してデータを流出させるマルウェア検体が、ここ数年間で複数確認されています。2021年6月には「BazarCall（またはBazaLoader）」と呼ばれる、マルウェアを感染させた被害者に偽のコールセンターに電話をかけさせる詐欺について、Microsoft セキュリティ・インテリジェンス（グローバルなセキュリティ専門家のネットワーク）が警告を発しました。BazarCallは、DNSトンネリングを使用してC2サーバと通信するAnchorマルウェアにつながる可能性があります。またAPT攻撃グループは、中東の政府組織を標的としたマルウェア配布キャンペーンでDNSトンネリングを使用しています。ここでは、ネットワーク内のDNSトンネリングを検出するために使用できるいくつかのテクニックをご紹介します。
DNSトンネリングの概要
では、どのようにして攻撃者はDNSトンネリングをマルウェアに利用するのでしょうか。手順は以下のように簡単です。
- まず、C2サーバとして使用するドメインを登録します。
- 次に、マルウェアはDNSクエリをDNSリゾルバに送信します。
- すると、DNSサーバはC2サーバにクエリをルーティングします。
- こうして、C2サーバと感染したホストの間の接続が確立されます。
DNSによる通信は遮断されないことが多いため、DNSトンネリングは攻撃者にとってデータを盗み出し、ネットワークへアクセスする便利な方法です。同時にDNSトンネリングには、ネットワーク上のDNSトンネリングの検出のために使用できる、非常に明確なネットワーク・マーカーが存在します。
Eliminate Threat Intelligence False Positives with SASE | Download eBook任意のデバイスへのDNSトンネリング
ネットワーク・マーカーに関しては、テキスト型のクエリがDNSトンネリングで非常に一般的です。ただし、DNS トンネリングは、タイプ 10 (NULL) などの一般的ではないクエリ タイプでも使用できます。
ネットワーク上のDNSトンネリングを検出するには、長いDNSクエリと一般的でないDNSクエリタイプを調べ、アンチウイルスなど正規のセキュリティ・ソリューションと、悪意のあるトラフィックを区別し、人間が生成したDNSトラフィックとボットが生成したトラフィックを区別する必要があります。
次の例では、当社の顧客ネットワークで確認されたDNSトンネリングトラフィックの背後にあるアルゴリズムを分析します。DNSトンネリングはWindowsで使用されるケースが散見されますが、以下の例ではAndroidで使用されています。
DNSを生成するアルゴリズムの検証
AndroidのDNSトンネリング使用例では、DNSクエリの使用にいくつかの共通した特徴が見つかりました。 スクリーンショット（図1）では、複数のDNSクエリで同じアルゴリズムが使用されていることがわかります。このアルゴリズムは8つのパートに分割されます。
図1では、複数のDNSクエリで同じアルゴリズムが使用されていることがわかります。このアルゴリズムは5つのパートに分割されます。
- 最初のパートは4-11文字（赤）
- 2番目のパートの最初の6文字が異なるクエリ間で繰り返される（青）
- 次のパートは63文字（黄）
- 最後のセクションは10文字（黒）
- 2番目のパートの最初の文字を結合した文字列が繰り返される（緑）
アルゴリズムの検証の結果、これらのDNSクエリはアルゴリズムが同じであることから、同じボットから送信されていることがわかります。また、異なるDNSクエリで繰り返されるアルゴリズムが統一されていることから、ボットトラフィックであると推測することができます。ボットにより生成されたトラフィックは、一貫性を持ち、同型である傾向にあります。
送信先の検証
次に、DNSクエリの送信先を検証します。送信先を検証することで、複数の未知のサーバを特定することができます。これらのサーバが受信した他のDNSクエリを検証したところ、トンネリングクエリ以外のものは見つかりませんでした。 DNSサーバへの正当なトラフィックが見つからない場合、同サーバがマルウェアに利用されている可能性を示すもう一つの指標となります。
ポピュラリティの検証
十分な規模を持つネットワークの場合、ユーザー間でIPまたはドメインのポピュラリティを測定するアルゴリズムを開発することも、マルウェア検知の一助となります。そうしたポピュラリティ測定アルゴリズムを、Catoネットワーク上の数十万人のユーザーを対象に使用することで、DNSクエリにおけるサーバのポピュラリティが低いことが判明します。IPのポピュラリティが低い場合、そのサーバがマルウェアによってのみ使用されている可能性があるため、悪意のあるサーバの指標となることがよくあります。しかし、ポピュラリティの低さだけでは悪意のあるサイトと判断するのには不十分なため、上記のような他の指標と合わせて判断する必要があります。
結論
DNSトンネリングは攻撃者が多くのファイアウォールを介してC2サーバと通信し、データ流出を可能とする古くからある手法ですが、ネットワークの特徴に着目することで脅威を特定することができます。 今回のケースでは、アルゴリズムによって生成された複数のDNSクエリ、不明なサーバを持つ送信先、ポピュラリティの低いサーバが見つかりました。どの指標も単独では悪意のある通信を反映していないかもしれませんが、このセッションが悪意のあるものである可能性が非常に高いという事実が、手動調査により検証されました。ネットワークとセキュリティの情報を組み合わせることにより、脅威の検知の改善につながることを示す好例となりました。