SUNBURSTのDNS悪用戦術の分類

このレポートでは、SUNBURST攻撃で検知の回避に使用される重要な技法、すなわち既知の脆弱性とエンタープライズ・ドメイン・ネーム・システム（DNS）を使用したコマンド&コントロール・トラフィックの隠蔽について詳しく説明します。DNSは、その遍在性とノイズの多さから、一般的な攻撃ベクトルとして使用されています。大量のDNSクエリが実行されると、監視や保護が極めて困難になります。SUNBURSTマルウェアは、特殊なドメイン生成アルゴリズム（DGA）を使用し、DNSを介して標的のインフラストラクチャの内外で通信を確立します。このトラフィックはログ記録などの従来のセキュリティ対策では発見できず、こうしたアクティビティの検知方法についての厄介な問題を将来に残すことになりました。DNSはDNSトラフィックの解決先を難読化できるDNSトンネリングなどの悪用手法に加えて、ハイジャック、キャッシュ・ポイズニング、リダイレクトといった攻撃の被害を受ける傾向があります。DNSの保護には課題があることから、DNSの機能と欠陥について理解することが非常に重要になります。そうすることで、セキュリティ・チームは、将来の攻撃にDNSが使用されるのを防ぐために必要なベスト・プラクティスとツールを確立できます。

SolarWinds SUNBURSTの攻撃を見れば、巧妙化され、十分な資金提供を受けたサイバー攻撃がどのようにサプライチェーンを通じて広がり、何か月にもわたって気づかれることなく潜んでいられるのかがわかります。国家が関与する攻撃者がSolarWindsに侵入し、兵器化したトロイの木馬をSolarWinds Orionのアップデート・ビルド・サーバに挿入しました。その後、アップデートをインストールした顧客のネットワークがこのマルウェアに感染しました。下流のサーバにロードされると、SUNBURSTはバックドアを開き、インテリジェンス・ベンダがSolarWindsにアラートで通知して2020年12月に侵害のニュースを発表するまでの8か月以上もの（あるいはもっと長い）間、隠れていました。「この攻撃は、非常に巧妙化されたサプライチェーン攻撃でした。つまり、一般的なプロセスを中断させ、システムを侵害して、後からソフトウェアを使用するユーザを攻撃できるようにするのです。このケースでは、コードは特定の目的にかなった方法での使用を意図したものだったようです。コードの悪用には手動による操作が必要だったからです」-SolarWindsセキュリティ・アドバイザリ、2021年1月29日 本稿執筆時点で、SolarWindsにおけるSUNBURSTの侵害による保険損失の推定額は、9000万米ドルに達するものと見られています。感染したアップデートを受け取った会社の数は、約18,000社に上ります。100社を超える米国企業が、下流でアップデートにより侵害されました。インストールされたSUNBURSTのトロイの木馬が、既知の脆弱性と企業のDNSを悪用することによって、そのコマンド&コントロール（C2）活動を隠蔽しました。攻撃者は、ある特定の日に数百万件のDNSリクエストとクエリがあり、DNSのトラフィックとクエリをログに記録することが難しく、ログの管理が追いつかない状態であることを知っています。そのため、攻撃者はDNSアクティビティをこのすべてのノイズの中に隠蔽し、レーダの監視の目を逃れるよう、クエリとトラフィックのタイミングを慎重に調節しました。また、SUNBURSTのトロイの木馬はDNSクエリを操作して、組織外にコピーする重要なシステムを特定し、DNS解決の課題とデータ・リンク・ライブラリ（DLL）を悪用し、感染したシステムからのアウトバンド・トラフィックを、一見信頼できそうなレジストラおよびドメイン経由で送信しました。このホワイトペーパーでは、検知可能なネットワーク・アクティビティであるべきものを難読化してC2の通信と機密データの転送を隠蔽するために使用される、SUNBURSTのDNS戦術を分類します。

SolarWindsが最初にどのようにして侵害されたかは不明です。初期のレポートには、2019年9月にSolarWindsの従業員が所有するOffice 365のアカウントで侵害が開始されたと記されています。しかし、2021年2月にMicrosoftは、侵害の試みが成功していないことから、自社の製品がSolarWindsのネットワークの侵害に使用されたという証拠は見つからないとし、その説が誤りであることを証明しました。SolarWindsアドバイザリによると、SUNBURSTは米国内の複数のサーバから発生しており、アンチウイルス・ツールやファイアウォール・サービスが検知できない正当なネットワーク・トラフィックを偽装していたとのことです。かつてSolarWindsでは、推測しやすい共有パスワードを通じて攻撃者がOrionのビルド・サーバに侵入していました。また、攻撃者は「SolarWindsなどの民間会社と連邦政府の両方で採用されている脅威検知の技法を回避することもできた」とのことです。つまり、セキュリティ・チームがSolarWindsのDevOps環境を保護する責任を怠ったわけです。そうした環境では、セキュアなIDとアクセスの管理（IAM）が最優先事項であるにもかかわらず。### こっそり、ゆっくり、あわてずに 侵害が2019年9月に始まったとすると、攻撃者は5か月かけてSolarWindsの内部で悪意のあるコードのテストとコンパイルを行い、Orionのビルドのアップデート（SolarWindsアドバイザリによると、具体的にはOrionプラットフォームのビルドのバージョン2019.4 HF 5、202.2、202.2 HF）に挿入したことになります。さらに、SolarWinds Orionクライアントでアップデートが利用可能になるまで、もう1か月待ちました。2020年の3月から6月まで、Orionのアップデートを通じてSolarWindsからマルウェアが配布されました。6月に、攻撃者とマルウェアはOrion VMのビルドから消え去りました。それまでに、環境内にアップデートを展開した顧客18,000人以上がSUNBURSTのトロイの木馬に感染しました。図1のタイムラインをご覧ください。攻撃タイムラインの概要 図1. SUNBURSTによるSolarWindsのサプライチェーン攻撃のタイムラインと詳細（出典：CHANNELe2e） ### 隠れる方法を知る 上のタイムライン図からわかるとおり、感染したアップデートがSolarWindsから配布され始めて8か月後に、SUNBURSTがダウンロードされていたことがSolarWindsに通知されました。感染した顧客向けのパッチが作成され、2020年12月17日に、US-CERTが通知を出しました。したがって、このサプライチェーンに沿ってネットワークに潜入した攻撃者は、ニュースが発表されるまで6～8か月間、被害者の組織内に潜伏していたことになります。この攻撃が気づかれることなくこれほど長く続いたのには、以下のようないくつかの理由があります。1. パッチおよび更新プロセスへの過度の信頼： ほとんどの組織は、パッチはソフトウェア・サプライヤから直接提供されたもので、マルウェアは存在しないものと信じています。2. デプロイ前のテストの回避： アップデートにエンコードされたバックドアは2週間以上活動を停止していたため、テストおよびデプロイ時に検知されることはありませんでした。3. セキュリティ・アウェアネスの欠如： FireEyeの初期の分析によると、SUNBURSTマルウェアは「フォレンジックおよびアンチウイルス・ツールに関連するプロセス、サービス、ドライバを特定するための複数の難読化ブロックリスト」を使用して、こうした検知ツールを回避したり、オフにしたりしているとのことです。4. C2経路を隠れて設定 攻撃者はDNSサービスおよび盲点を利用して足場を固め、内部のIPアドレスにマルウェアを拡散し、C2チャネルを通じて不正なサーバにデータを送出します。### DNSの破壊 DNSを使用してC2通信を有効化・隠蔽することは、SUNBURSTマルウェアのペイロードの最も興味深い点です。デバイスが感染するとすぐにSUNBURSTのDNS戦術が開始されました。最初は外部のC2サーバに慎重にアクセスしようとしました。SUNBURSTバックドアは、ほとんど用いられないような攻撃手法により、DGAを使用してC2トラフィックをDNS内に隠蔽します。Symantecの1月のブログによると、DGAのこのサブバージョンでは、攻撃者はXORキーを使用してDNSクエリの最初の14文字にシステムIDをエンコードすることによって、C2サーバに情報を送信している感染した各コンピュータを特定できるようになったとのことです。攻撃者はエンコードされたユーザIDを受け取ると、暗号を使用して復号し、文字を読み取って、どのシステムに対して2次攻撃を仕掛けるかを決めました。それらの2次攻撃のほとんどは、攻撃が長続きし、最も大きな損害を与えると考えられる重要なインフラストラクチャやセキュリティ・ソフトウェア・ベンダに対して行われました。 図2. SUNBURSTによるDNSルックアップの構造（出典：Symantec） 不正なSUNBURSTトラフィックを隠蔽するDGAが高度な方法で利用されていたにもかかわらず、2020年12月11日、FireEyeの脅威調査チームが侵害調査の一環として、SolarWinds Orionソフトウェア内にエクスプロイトを発見したと発表しました。12月13日には、国家の支援を受けた敵対者がこのエクスプロイトを使用して広範囲に及ぶ攻撃を展開していることが確認されました。調査チームは、この脅威に「SUNBURST」という名前を付けました。その後、SolarWindsはOrionソフトウェアが破壊され、兵器化されているのを確認しました。初期のエクスプロイトが公表された後、非常に多くのセキュリティ・ベンダとセキュリティ機関が、DNSログ解析や静的/動的解析のような技法を使用して侵入の痕跡（IOC）の特定に取りかかりました。数日のうちに、Microsoftおよびセキュリティ・ベンダの連合が、攻撃者のプライマリ・ドメインである avsvmcloud[.]com を突き止めました。GoDaddy、Microsoft、FireEyeが協力し、 avsmcloud[.]com に新しいAレコードを設定して、被害システム上でマルウェアを無効化するIPアドレスに解決されるようにしました。SUNBURSTで使用されるスマートDGAプログラムがSUNBURST自体に対して実行されるようにしたのです。具体的には、トロイの木馬が自動的に接続を切断するIPブロック（Microsoftに属するIPの大規模なブロックなど）を発見しました。また、MicrosoftのIPを挿入し、すべての接続要求をそのIPに解決することで、すべての接続を切るようにC2サーバのAレコードを再設定しました。また、MicrosoftとFireEyeはFBIおよびインフラストラクチャ・セキュリティ庁と協力して、IPがSUNBURSTのトロイの木馬に感染している被害者を特定し、その旨を知らせることができるようにしています。それによって、被害者はマルウェアを発見してシステムから排除することができます。### 期限の厳守 MicrosoftはSUNBURSTの avsvmcloud ドメインを押収した後、そのドメインをロック・ダウンして、新しいシステムへの感染と被害システムとの通信を阻止しました。プライマリ・ドメインが押収され、ロックされた後は、パッチ更新をスキャンしてトロイの木馬を検知し、被害システムにロードされないようブロックすることが可能になりました。これは、将来の攻撃で似たようなメカニズムが使用された場合に役立つ重要な教訓になります。その段階で攻撃が検知されない場合は、攻撃者がC2サーバを介して通信し、機密データを活動拠点に送信する前に、ITチームが攻撃を阻止する必要があります。図3に、初期の感染からC2通信およびデータの削除までのキル・チェーンの推移を示します。 図3. SUNBURSTのキル・チェーンの推移 SUNBURSTのトロイの木馬や、他の同様の攻撃が、いつ監視されているかをわかっていて、監視されているらしいと気づいたらすぐに活動を停止してしまうとすると、それらの攻撃によるC2通信の確立を阻止するのは容易なことではありません。DNSの偏差をパッシブDNSルックアップでの履歴トラフィックと手動で比較するのが効果的です。それによって、監視中のマルウェアに情報が漏れるということも通常はありません。ただし、組織は、正しく比較するためにどのような兆候に注意すべきなのかを把握しておく必要はあります。

DNSは、インターネットからの接続要求と会社のIPアドレスとの間のゲートウェイの役割を担う重要なエンタープライズ・サービスであり、要求を伝える間にIPアドレスをプライベートに保ちます。組込み型のインフラストラクチャであるDNSは、「設定したらそのままにしておける」テクノロジと見なされることがよくあります。残念ながら、そのために見落としが起きたり、保護が不十分になってしまったりする可能性があります。>「DNSは、ドメインなどのインターネット・リソースに対する階層型の命名システムです。DNSはインターネットの住所録と考えることができます。DNSの主要な機能はドメイン名をホストのIPアドレスにマッピングすることです。DNSは、クライアント/サーバ・モデルを採用する分散データベース・システムとして維持されます。リゾルバ（クライアント・プログラム）がデータベースに情報を問い合わせます。また、ネーム・サーバ（サーバ・プログラム）が、ローカルに保存されたリソース・レコードから取得した情報を返します」Google Domainsのヘルプ・サイト ### ソフト・ターゲット VeriSignによると、2020年にDNSルート・サーバが処理したクエリの数は1日あたり平均で840億件でした。企業の場合、この数字は一般に数百万に上り、DNSトラフィックをログに記録するのはほぼ不可能なので、SUNBURSTがずっと潜んでいるのも難しいことではありません。DNSは、DNSトラフィックの名前解決を悪用したDNSトンネリングなどの攻撃手法に加えて、ハイジャック、キャッシュ・ポイズニング、リダイレクト攻撃の被害を受けやすい傾向があります。DNSシステムは管理者にトラフィックの異常や逸脱を通知しません。そのため、悪意のあるアクターにとって、この攻撃は感染したIPと組織外のドメインとの間のトラフィックを隠しておくのに好都合です。DNS関連のインテリジェンスは、ほとんど役に立ちません。そうしたインテリジェンス・フィードで提供されるのは、既知のDNSの脅威アクティビティに対する洞察です。つまり、あるドメインが疑わしいドメインのリストの1つに追加されるときには、そのドメインはすでに不正行為にかかわっていた可能性が高くなるということになります。この問題はSUNBURSTによって明らかとなりました。疑わしいドメインは無害で、アクティブ化されるまで数か月間、活動を停止していました。そのドメインがDNSインテリジェンス・フィードに初めて出現したのは12月で、SolarWindsにエクスプロイトに対する注意が喚起された後のことです。ほとんどの被害は、インテリジェンス・フィードに追加されるまでに発生していたのです。### SUNBURSTによるDNSの把握 SUNBURST攻撃では、正当に見えるドメインから正当に見えるトラフィックにクエリとドメインが解決されました。こうしたドメインのほとんどが、正当だと思われる2次プロバイダでホストされていたものです。そのため、SUNBURSTマルウェアは気づかれることなく標的の組織を侵害し、そこに居座ることができました。以下では、DNSエクスプロイトSUNBURSTについて順を追って説明します。SUNBURSTは、C2の設定、感染デバイス間の通信、オフラインでの詳細な調査のためのIPの特定に使用されます。* Orionは知らないうちに標準のWindowsインストーラのパッチ・ファイルを配布していました。このファイルには、トロイの木馬のコンポーネントである SolarWinds.Orion.Core.BusinessLayer.dll が隠された、Orionのアップデート関連の圧縮リソースが含まれていました。* このファイルが標的のシステムにダウンロードされた後、悪意のあるドメイン avsvmcloud[.]com との通信の確立を開始するまでの10～14日間、トロイの木馬SUNBURSTは活動を停止しました （人間の目はAVSとAWSを間違えやすいものです） * マルウェアの一部には、正当な SolarWinds.BusinessLayerHost.exe または SolarWinds.BusinessLayerHostx64.exe （システム構成によって異なる）によってロードされた悪意のあるDLLが含まれていました。* ドメインに対する初期のpingが成功した場合、SOLARWINDSがクエリとプログラムをこっそり、ゆっくりと30分刻みで送信して、リダイレクトを設定し、気づかれずに通信を行いました。* 次に、DNSを利用して、複数のステップでドメインのリダイレクトが確立されました。* クエリが、 avsvmcloud[.]com のサブドメインへの解決を試みました。しかし、リカーシブDNSサーバには avsvmcloud[.]com を解決する権限がないため、要求は転送されました。* 次に、攻撃者の制御する権威DNSサーバが、ワイルドカードのAレコードを使用して要求を解決しました。* 攻撃者は被害者のドメイン名を確認し、そのドメイン名にCNAMEレコードを追加しました。* DNS応答が、C2ドメインを指すCNAMEレコードを返しました。* マルウェアSUNBURSTは、DGAを使用して、攻撃者が返す価値のあるシステムを選べるように、感染したシステムに対する固有のIDを作成しました。* 攻撃者は検知を回避するために、XORキーを使用し、そのシステムで使用されているセキュリティ製品のステータスとともに、それらのシステムIDをDNSクエリの最初の14文字にエンコードしました。* 攻撃者は、C2サーバでVOX暗号を使用してIDを復号し、2次攻撃を仕掛けるシステムの種類（主に、政府機関、インフラストラクチャ、ソフトウェア会社）を定めるためにスキャンしました。* 次に、攻撃者はプライマリC2サーバへの二次的なセキュアHTTPS通信チャネルを開きました。* 機密データと知的財産は暗号化され、攻撃者がさらに詳しく分析するために、無害に見える小規模なクラウド・プロバイダでホストされているサーバに送信されました。以下の図4をご覧ください。DNSのリダイレクトがどのように確立されるのかを図で示しています。 図4. SUNBURSTのDNSリダイレクト技法の流れ ### CNAMEの利点とは 管理者はDNSimpleレコード・エディタからCNAMEレコードを追加、削除、更新できます。Windows DNSサーバ内のCNAMEレコードは別のドメイン名（example.com）を指し示しており、IPアドレス番号を直接指し示すことはありません。CNAMEレコードは通常、メール・サーバなどのセカンダリ・ドメインとして使用されます。Aレコードは常にプライマリ・サーバのIPアドレスを指し示しています。### ドメインおよびプロキシに隠れる 攻撃のリスクにさらされないように、C2サーバがネットワーク内の侵害されたIPと通信する前に、悪意のあるDNS関連アクティビティを検知することが目標となります。しかし、ドメイン接続の意図を検知し、把握することは、最善の状況下であっても困難です。ITセキュリティの専門家やツールがこうした悪意のあるアドレスを確認できない理由はいくつかあります。以下に、例を示します。* ブラックリストにないクリーンなドメインを使用している。攻撃者は特に、トランザクションに関連する名前の付いた、脅威でないドメインを探します。* C2ドメインがIPを、無害に見えても実際は疑わしいドメイン・リセラや小規模なクラウド・サービス・プロバイダ（例： chunkhost.com 、 liquidtelecom.com 、 mivocloud.com ）、さらには外部のメール・プロバイダやプロキシ・サービスに解決している。* プロキシ・サービスが、感染したIPが解決されるドメイン（例： insorg[.]org 、 safe-inet[.]net 、 safe-inet[.]com ）のIDを非表示にしている。

サプライチェーン攻撃では、キル・チェーンがサプライヤから開始します。SolarWindsへの攻撃が早期に検知されていたら、SUNBURSTのオペレータやマルウェア・プログラムによるSolarWindsのビルド・サーバへのアクセス、信頼できるアップデートを通じたSolarWindsの顧客へのマルウェアのアップロードは成功しなかったでしょう。サプライチェーンのキル・チェーンであればそうした攻撃を阻止できますが、そうでなければ、Orionのパッチ更新のダウンロードが試みられたときに阻止できます。あるいは、マルウェアの疑いのあるものを模擬運用環境でテストすることのできるサンドボックス・コンポーネントを含めておきます。さらに、サプライチェーンのキル・チェーンであれば、機密データの送出が確立・開始される前にC2アクティビティをブロックします。サプライチェーンのキル・チェーンについては、以下の図5をご覧ください。 図5. サプライチェーンのキル・チェーン 本稿執筆時点で、SolarWindsはOrionのアップデート・ビルド・サーバに攻撃が広がる前に、システム内でその攻撃がどのように発生したのかをまだ把握していません。攻撃者がSolarWindsの社内で横方向に移動しようとしていたのであれば、内部の機密情報を扱う開発サーバにアクセスされる前に攻撃を阻止しておく必要がありました。残念ながら、そうはできませんでした。攻撃者はSolarWindsのビルド環境に侵入し、正当なSolarWindsキーで署名されたOrionのアップデートにSUNBURSTのトロイの木馬が隠されました。サプライチェーン攻撃のキル・チェーンでは、こうした攻撃が（信頼できるパッチまたはアップデートを通じてネットワーク上の他のデバイスに）拡散したり、外部のC2サーバと通信したりできないようにすることが重要です。### DNSにもちょっとした「愛情」を DNSは長い間手動でキュレートされ、編集されていました（たとえば、適切なDNS解決とPTRレコードを保証するための「named.conf」ファイルおよびゾーン・ファイル）。この数年で、ポイント&クリックのDNSツールの使用により、この管理は容易になりましたが、DNSのハイジーン（衛生管理）が適切に行われなくなりました。そうした構成不備に対する可視性をログやWindowsのイベントで実現するのは、非常に困難です。前述のとおり、こうした監視の難しさや、それによる可視性の欠如が原因で、DNSがC2通信およびデータ流出の手段として頻繁に使用されるようになっています。SUNBURSTの場合は、返された値に基づいてプログラムによる判断がされていました。そのため、DNSにはプロアクティブな管理と保護が必要です。DNSサーバを強化しましょう。DNSSec（DNSリフレクション攻撃を防止）やDNS監視などのセキュリティ・テクノロジを使用して、DNSサーバを最新の状態に維持し、パッチを適用し、サポートしてください。厳格な制御を行うため、さまざまなベスト・プラクティスがある中でも、ゾーン転送を制限し、DNS再帰をオフにして（主要なLinuxディストリビューションのほとんどのBINDサーバでは、デフォルトでオンになっています）ポイズニング攻撃を防止することを特にお勧めします。別の方法として新たに知られるようになったのが、DNSトラフィックの暗号化（多くの場合、DNS over HTTPS（DoH）と呼ばれます）です。ただしこれは、攻撃者やホスト組織に対する可視性が失われてしまうため、もろ刃の剣です。ネットワークでの検知と対応（NDR）は、イベントやsyslogとは異なり、DNSハイジーンを損なう特定の条件を明らかにし、突き止めるのに役立ちます。たとえば、前述の未承認のDNSサーバ、DGAのような名前、疑わしいTLD、一致しないDNSの応答（ドメイン・ハイジャッキング）などです。### 変更内容の確認 典型的なDNSトラフィックを把握し、今後の調査および比較のために履歴ファイルを保存します。ITスタッフは、パッシブDNSを使用して、たとえば攻撃者にアラートを通知せずにドメインのAレコードに対する変更にフラグを設定できます。その変更が感染したシステムで今現在起こっているわけではないからです。巧妙なC2アクティビティを検知するために、DNSアクティビティ（トラフィック、クエリ、ドメイン、IP）に変化や異常な行動がないか調べる必要があります。SUNBURST攻撃の手法に見られる、注意すべき異常には以下のようなものがあります。* Orionネットワーク管理サーバのように、外部のホストと初めて通信する機密サーバ * 営業時間外に発生する内部システムから外部ドメインへの接続 * 内部システム間の例外的な接続（例：DevOpsが会計システムにアクセスする必要はない）。* 外国への接続、ルーティンのDNSトラフィックおよびクエリとは異なる場所への接続 * 異常なファイルの読み取り * リモート実行コマンドを使用したSSHトラフィックの増加 ### DNSトラフィックのデコードと比較 上記のいずれかの理由（または、リストにない他の理由）からトラフィックおよびクエリが疑わしいと思われる場合は、そのデータを除いておき、過去のDNSデータと比較して詳しく調べる必要があります。キーワード、疑わしいドメイン、データ流出が見つかった場合は、メタデータにデコードする必要があります。C2チャネルが確立され、HTTPS経由でセカンダリ接続が行われると、どのパケットにDNS要求またはDNS応答が含まれ、どのドメインおよびIPアドレスが要求されたのかを判断するのは困難になります。つまり、ネットワークの可視性を実現するためのソリューションは、疑わしいトラフィックを解読して調べることができなければなりません。パッシブ・クエリを使用した変更の検索、メタデータの調査によるC2通信を示唆するキーワードの検索、および過去のある時点のスナップショットのメタデータの比較はすべて、検知と対応を向上させるために自動化すべきプロセスです。### ドメイン名の偽装の検知 これには、スペルミスや不正確なドメイン名の検索も含まれます。たとえば、SUNBURSTの攻撃者はタイポスクワッティングという一般的な技法を使用してドメインを正当なものと見せかけ、被害者をプライマリC2サーバに誘導しました。以下のようなものには警戒が必要です。* ドメインが通常表す地理的地域とは異なるドメイン拡張子（.auや.ioなど、拡張子が表す地域ではないもの）* 正当に見えても、1つまたは複数の文字が異なっているか、文字が追加されているドメイン（たとえば、SUNBURSTの場合、 awscloud.com ではなく avsvmcloud[.]com が使用されていました）* 無害なレジストラまたはプラットフォームに同期しているように見えても、詳しく調べると、詐欺のようで疑わしいもの * 一般的な同期インターフェイス（appsynch.apiなど）を指し示し、RESTベースのモバイル・アプリ・ドメインとして表示されるサブドメインネットワーク・トラフィック、履歴メタデータ、DNSの接続と行動の相関、および疑わしいトラフィックへのドリルダウン機能によって、調査者はブロックすべきものを把握して候補リストを作成し、詳細な調査に注力することができます。そこから、C2チャネルをブロックし、被害のあったデバイスをより容易に特定して修復することができます（ExtraHopが提供する補足情報を参照して、ExtraHopがどのようにしてメタデータなどの高度な監視技法を用い、SUNBURSTを追跡したのかをご確認ください）。

Reveal(x)がSUNBURSTを検知・対応した方法に関するExtraHopによる補足 12月13日に初めてSUNBURST攻撃が明らかになったとき、多くの組織が環境内で被害のあったSolarWindsバイナリを特定し、停止しようと急ぎました。アクセス・ポイントが停止された後、システムやデータが侵害されているかどうか、またその程度はどのくらいかをセキュリティ・チームが判断するため、調査が本格的に開始しました。多くの場合、攻撃が長期にわたったことで、それはほぼ不可能になりました。何か月間もログを保存しておくと膨大なコストがかかりますが、いずれにしてもDNSなどの、悪意のある行動がログによって明らかになるようなデバイスの多くは、そもそもログを有効にしていませんでした。ですが、SUNBURSTの証拠はネットワークのメタデータに明らかに存在していました。以下の図は、2020年1月1日から2020年12月19日の間に検出された脅威アクティビティを示しています（ExtraHopが保護する多くの環境からの匿名化されたデータの総計を使用）。3月後半から10月前半までの間に、検知率が約150%増加しました。ExtraHopではプライバシー保護の観点から、このデータで具体的な攻撃対象は示していませんが、増加したトラフィックの大部分は同じ場所に向かっていることが明らかになりました。このデータを見ると、DNSをはじめとする、ネットワークでの行動に大きな、疑わしい変化が生じていることがわかります。SUNBURSTの侵害後の活動が盛んになったときに、タイムラインでの検知数も増加しています。また、巧妙な攻撃者の行動がネットワーク上で確認できた（できる）ことも示されています。

SolarWindsから18,000以上のダウンストリームの顧客にまで広がるSUNBURST攻撃において、マルウェアをリバースエンジニアリングした結果、この攻撃に携わった開発者の数は1,000人を上回ることが明らかになりました。このマルウェアは現在出回っており、リバースエンジニアリングの途中であるため、新たな脅威アクタによってSUNBURSTの手法がパッケージ化され、さまざまな、より巧妙化された方法で使用されるのは避けられません。デジタル製品を大量に扱うベンダやメーカでのセキュリティのベスト・プラクティスと定期的なリスク・アセスメントは、重要な軽減策です。しかし、この攻撃が証明するように、サプライチェーンの下流の組織は、こうした攻撃の再発に備えておく必要があります。つまり、ソフトウェアのサプライチェーンに存在するリスク、そのリスクがソフトウェアの配布にもたらす影響に関する意識を高めたうえで、サプライチェーンのキル・チェーンのできるだけ早い段階で、こうした攻撃を検知するためのツールおよびベスト・プラクティスを確立します。執筆者について Deb Radcliff氏には、サイバーセキュリティ業界での25年を超える経験があります。FBI、DoD、シークレット・サービス、CIA、自治体および州の法執行機関が独自に構築したサイバー部門を取材し、サイバー犯罪でスクープをものにした最初の調査報道ジャーナリストとしてキャリアをスタートさせました。その執筆記事は、多くの論文や大学の教科書で引用されています。Radcliff氏は陸軍士官学校で講演し、ニール賞を2度受賞し、3度目の候補に挙がりました。2005年、Radcliff氏はSANS Instituteの新しいアナリスト・プログラムを立ち上げて、SANSの専門家が作成した専門的なホワイトペーパーとWeb放送のコンテンツを15年にわたって監督しました。サイバーセキュリティに関する記事やブログの執筆も続けており、2021年4月には、サイバー推理小説『Breaking Backbones』を上梓しました。