PacketWhisper - DNSクエリとテキストベースのステガノグラフィを使用してデータを密かに転送し、属性特定を回避します。攻撃者が制御するネームサーバーやドメインは不要。DLP/MLSデバイスを回避し、データおよびDNSネームサーバーのホワイトリスト制御を突破。任意のファイルタイプ（実行ファイル、Office、Zip、画像など）をFQDN（完全修飾ドメイン名）のリストに変換し、DNSクエリを使用してデータを転送します。シンプルながら非常に効果的。
(更新: 2020/05/27: はい、2020年の夏の間にGithubプロジェクトをすべてPython3に移行する予定です。)
Joe Gervais (TryCatchHCF)
従来のDNSデータ持ち出し手法は、次のいずれかに依存しています。DNSトンネリング、DNSクエリフィールドへのデータ隠蔽、またはエンコード/暗号化されたペイロードを分割してDNSクエリのサブドメインとして使用する方法。これらの方法はすべて、攻撃者がデータを受信するためのドメインや関連付けられたDNSネームサーバーを制御する必要があるため、属性特定につながります。また、これらの手法はDNSネームサーバーのブラックリスト登録（一般的）やホワイトリスト登録（増加傾向）に対して脆弱です。さらに、DFIRアナリストはこれらの手法に精通しており、SIEMシステムはしばしばそれらを検出して警告を発します。
PacketWhisperはこれらの制限を克服します。
通信システムが互いに直接接続したり、共通のエンドポイントに接続したりすることなく、ターゲットがホワイトリストに登録したDNSサーバーを使用してデータを転送できたらどうでしょうか？ネットワーク境界がデータ持ち出しをブロックするためにデータホワイトリストを採用していたとしても？
これを実現するために、PacketWhisperはDNSクエリとテキストベースのステガノグラフィを組み合わせています。Cloakify Toolsetを活用し、ペイロードをFQDN文字列のリストに変換します。PacketWhisperはそのFQDNリストを使用して連続したDNSクエリを生成し、ペイロードをネットワーク境界を越えて（または内部で）転送します。データは目に見える形で隠され、2つのシステムは互いに直接接続したり、共通のエンドポイントに接続したりすることはありません。PacketWhisperが使用する暗号は、警告を回避し、分析の試みを誤誘導するための複数の欺瞞レベルを提供します。
データを受信するには、最も便利な方法でDNSクエリを含むネットワークトラフィックをキャプチャします。（キャプチャポイントの例については、以下の「PCAPファイルのキャプチャ」を参照してください。）その後、キャプチャしたPCAPファイルをPacketWhisper（任意のシステムで実行可能）に読み込ませると、ファイルからペイロードを抽出し、元の形式にデクローク化します。
DNSは魅力的なプロトコルです。データ転送速度は比較的遅いものの、最も機密性の高いネットワークでも、DNSはほとんどの場合ネットワーク境界を越えて許可されるからです。
重要な注意: DNSクエリを使用してデータを転送していますが、DNSルックアップの成功は必要ありません。実際、PacketWhisperはDNS応答を見ることさえありません。これによりユースケースが拡大し、クエリ対象のドメインを制御する必要も、DNSリクエストを処理するDNSネームサーバーを制御する必要もないという事実が強調されます。
したがって、PacketWhisperを使用すると、次のようなペイロードを変換できます：
以下のようなFQDNのリストに変換し：
PacketWhisperがこれらをDNSクエリに変換し、ネットワークトラフィックに次のように表示されます：
DNS解決パスの任意の場所でPCAPファイルとしてキャプチャし、そのPCAPをローカルのPacketWhisperに読み込ませてペイロードを復元します：
プロジェクトに含まれているDEF CON 26のスライド（Packet Hacking Villageのプレゼンテーション）をご覧ください。スライドでは、DNSデータ持ち出し、テキストベースのステガノグラフィ/Cloakify Toolsetの背景、そしてPacketWhisperがそれらを組み合わせてデータ転送方法にする方法を説明しています。スライドは単独でも役立つように意図的に作成されており、背景情報と説明は完全なものになっています。ただし、DC26 Packet Hacking Villageのプレゼンテーションのビデオもご覧いただければ、より多くのコンテキストが得られます。
プロジェクトにはサンプルPCAPファイル（巧妙に「sample.pcap」と命名）が含まれており、各暗号に対応した個別のペイロードが含まれています。もちろん、どのファイルタイプでも可能ですが、ここではテキストファイルをPCAPに転送しています。 PacketWhisperに読み込ませて試してみてください！
お使いの環境での簡単なテストとして、VMからPacketWhisperを実行し、ホストシステムを介してVMのネットワークインターフェースでパケットキャプチャを行いながらファイルを送信します。その後、PCAPファイルを任意の便利なPacketWhisperインスタンスに読み込ませてファイルをデコードできます。ただし、転送速度は速くないことを覚えておいてください。小さなファイルと忍耐が鍵です。
質問: 「なぜScapyやdnspythonツールセットを使わなかったのですか？」
回答: 運用ツールにおけるプロジェクト依存関係が嫌いだからです。プロジェクトは可能な限りアトミックで自己完結型に保ち、特にクライアント側で環境を制御できない、または最小限の権限しか持っていない場合でも最大限の信頼性を確保しています。PacketWhisperの構造上、プロジェクトをtarでまとめてターゲットホストに展開するだけで、制限されたシェルホストでも実行できます。
質問: 「なぜPacketWhisperはCloakify Toolsetのフォークプロジェクトではないのですか？」
回答: 上記と同じ回答です。Cloakifyの機能のうち非常に特定のサブセットしか必要とせず、それ以外のすべてをPacketWhisperに追加すると、ディレクトリが乱雑になり、PacketWhisperで使用できないツールや暗号が含まれてしまいます。両方のプロジェクトを所有しているため、変更があれば両者間で同期することを約束します。
$ python packetWhisper.py
FQDNベースの暗号は3つのカテゴリに分類されます：
ランダムサブドメインFQDN（一意）
ほとんどのユースケースに推奨される暗号モード
サブドメインにランダム化された要素が組み込まれたFQDNです。これによりDNSキャッシュを防ぎ、DNSクエリパス上にあるNATされたネットワークデバイスを越えてデータを転送することも可能になります。送信システムのIPアドレスはNATデバイスを越えて見えないため、暗号で生成されたサブドメインには一意のタグ要素が含まれており、パケットキャプチャ内でPacketWhisperのペイロードを識別するのに役立ちます。
これらの暗号は、セッション、ユーザー、キャッシュコンテンツなどを識別するために複雑なサブドメインに依存するさまざまなサービスの形式を模倣しています。このアプローチにより、PacketWhisperのDNSクエリがネットワークの他のトラフィックに溶け込みやすくなります。
サブドメイン名の最初の部分は暗号リストからの文字列です。残りのサブドメイン名はランダム化されて各FQDNを一意にし、DNSキャッシュが早期にDNSクエリパスを遮断するのを防ぎます。その後、ドメイン名を追加します。このようにFQDNを構築することで、選択したドメインに関連する通常のFQDNのように見せかけ、ネットワーク上で見られる通常のWebトラフィックによりよく溶け込ませます。
繰り返しFQDN（一意）
ネットワーク上の他のすべてのDNSクエリから目立つように作成されていますが、ランダム化は含まれていません。つまり、DNSキャッシュが干渉する可能性がありますが、その副作用として、DNSクエリは最大のマルチクライアントPCAPコレクションでも見つけやすくなります。これは、FQDNが、映画「バカルー・バンザイの8次元を越えて」に登場する架空のYoyodyne Propulsion Systemsの「Johns」（Red Lectroidエイリアン）のリストのような奇妙なエンドポイントであるためです。
一般的なWebサイトFQDN
一般的なWebサイトURLから構成されたFQDNです。
注: ほとんどの環境は境界でNATされているため（クライアントのIPアドレスが見えなくなる）、このモードは通常、同じローカル/24ネットワークに接続されたシステム間でのデータ転送にのみ有用です（例：お気に入りのコーヒーショップのゲストWiFi）。
一般的なWebサイト暗号では、ソースIPアドレスのみがネットワーク上の他の類似DNSクエリと区別する手段となるため、PacketWhisperはペイロードの最初と最後に一意の「ノックシーケンス」DNSクエリを送信し、後でPCAPファイルから送信ホストを識別するのに役立ちます。
FQDNの例: www.github.com
暗号を選択すると、PacketWhisperはペイロードを目的の暗号に従ってFQDN文字列のリストにエンコード（Cloakify）します。次に、順次DNSリクエストを生成してデータをDNS解決パスに沿って送信します。PacketWhisperは各DNSクエリの間に小さな遅延を追加し、DNSリクエストの順序が狂うのを防ぎます。
ここで重要な要素は、もちろんPacketWhisperが生成したDNSクエリを含むネットワークトラフィックをキャプチャできることです。DNSクエリパスへの可視性があれば、どこでもキャプチャできるため、多くのオプションがあります。
キャプチャポイントの例：
想像力を働かせてください。壁のディスプレイも含め、DNS解決パス上の任意のデバイスがオプションです。「待って、何？」
注: VPN接続はホストとVPN出口ノード間の可視性をブロックします。転送元のクライアントがアクティブなVPN接続を使用している場合、VPN出口ノードより上流でキャプチャできない限り、DNSクエリは見えません。同じシステム上でのキャプチャでも失敗します。多くの方がおそらくVPNを使用しているでしょうから、PacketWhisperをテストしたい場合は、ホストされた仮想マシン（VM）から送信し、ホストシステム上のVMのネットワークインターフェースでトラフィックをキャプチャしてみてください。
PCAPファイルをキャプチャしたら、tcpdump（LinuxおよびMacOSに含まれている）またはWinDump（Windows）がインストールされたシステムでPacketWhisperを実行し、ペイロードを復元します。PacketWhisperは使用された暗号を尋ね、PCAPからペイロードを抽出し、最後に一致する暗号で抽出されたペイロードをデコードします。
重要な注意: 同じPCAP内では、使用する暗号ごとに1つのペイロードを送信できます。同じ暗号を使用した複数のペイロードが含まれるPCAPは問題を引き起こします。例えば、提供した「example.pcap」ファイルには、現在利用可能な運用暗号ごとに1つずつ、合計5つのペイロードが含まれています。もしペイロードの1つが別のペイロードと同じ暗号を使用していた場合、PacketWhisperはいずれも抽出できません。簡単な修正方法はPCAPファイルを分割することです（これが、PacketWhisperの送信コードが送信の開始時刻と終了時刻にUTC日時を出力する理由です）。同じ暗号を使用した複数のペイロードを許可するよう取り組んでおり、解決策はすでにありますが、まだ実装に至っていません。
PCAPファイルが実際にPCAP形式であることを確認してください。tcpdumpやWinDumpを使用してキャプチャした場合は問題ありません。ただし、WiresharkはWiresharkトラフィックを保存するためのさまざまな「名前を付けて保存...」オプションを提供しており、そのうちの1つだけが実際にtcpdump/PCAP互換です。間違いを早期に発見するためのエラーレポートの改善に取り組んでいます。
安全な暗号化スキームではありません。PacketWhisperは安全な暗号化スキームではありません。頻度分析攻撃に対して脆弱です。「ランダムサブドメインFQDN（一意）」カテゴリの暗号を使用してエントロピーを追加し、頻度分析攻撃の効果を弱めてください。ペイロードの機密性が必要な場合は、PacketWhisperで処理する前にペイロードを暗号化してください。
高帯域幅の転送方法ではありません。PacketWhisperはDNSクエリに依存しており、UDPベースであるため、リクエストの配信順序（または配信の成功）は保証されません。デフォルトでは、PacketWhisperは各DNSクエリの間に小さな（0.5秒）遅延を追加します。元のペイロードサイズ（Cloakify出力ファイルではなく）に基づいて、1時間あたり約7.2K（毎分120バイト）の速度でペイロードを安全に転送できます。クエリ間の遅延をなくすこともでき、転送速度は劇的に向上しますが、ネットワークノイズの増加やペイロードの破損のリスクがあります。
そして正直なところ、DNS以外のデータ転送モードが利用可能であれば、メインのCloakify Toolsetプロジェクトを使用してファイルを平然と隠し（ペイロードをPokemonGoモンスターのリスト＋緯度経度座標に変換するなど）、FTP/HTTPなどを介して利用可能な高帯域幅をすべて活用できます。DNSは他のプロトコルがブロックされている場合に非常に有用ですが、常に選択肢を認識しておいてください。
DNSはDNSです。OSごとにDNSキャッシュポリシーなどが異なります。ネットワークがダウンしている、隔離されているなどの可能性もあります。PacketWhisperには、一般的なFQDNを解決できるかどうかを確認する簡単な手動チェックが含まれていますが、DNSはしばしば厄介なものです。昔ながらのITトラブルシューティングの格言を覚えておいてください：「いつもDNSが原因だ。」
プロジェクトに含まれているDEF CON 26のスライド（Packet Hacking Villageのプレゼンテーション）をご覧ください。緩和戦略はプレゼンテーションの後半でカバーされています。すべてのことにおいて、「多層防御」が味方です。特に、DNS解決パスは組織の制御が及ばない広大な領域にわたるためです。
MDNSおよびLLMNRローカルネットワークDNSブロードキャストモードを追加する予定です。これらは同じローカルネットワークに接続されたシステムで使用することを目的としており、WiFiパケットキャプチャ時にキャプチャデバイスがプロミスキャスモードにアクセスする必要がなくなります（これらのプロトコルはホストネットワークのx.y.z.255にトラフィックを送信し、同じローカルネットワーク上の他のすべてのシステムにブロードキャストします）。
また、さらに暗号を追加する予定ですが、日常的なニーズには現在の暗号コレクションで十分であり、十分に活用できるでしょう。
また、単一のPCAPファイル内で同じ暗号を使用した複数のペイロードを許可するための作業も行っています。解決策はすでにプロトタイプ化されていますが、PCAP抽出ワークフローがユーザーにとってより煩雑になります。運用上は、その価値があるよりも問題が多いかもしれません。私は常に、スイスアーミーナイフのような複雑さよりも、よりクリーンな運用機能を好みます。
