ブログ(脅威調査)

SUNBURSTに関する追加の技術的詳細

FireEyeは、2020年12月13日に初めて公開したSUNBURSTバックドアに関する追加情報を検出しました。このマルウェアの技術的な詳細に触れる前に、SolarWindsのサプライチェーン侵害についてのブログ投稿をよく理解していただくことをお勧めします。このブログで、現在UNC2452として追跡している高度な攻撃グループによる世界規模の侵入キャンペーンが明らかになりました。

SUNBURSTは、SolarWindsというデジタル署名されたSolarWinds Orionプラグインのトロジャイズ版です。SolarWinds.Orion.Core.BusinessLayer.dll. HTTP経由でサードパーティ・サーバーに通信するバックドアが含まれています。最初の休止期間(最大2週間) が経過すると、SUNBURSTはバックドアにファイルの転送、ファイルの実行、システムのプロファイル、システムの再起動、システムサービスの無効化を指示するコマンドを取得して実行できます。マルウェアのネットワーク・トラフィックは、Orion Improvement Program (OIP)プロトコルを模倣することによって正規のSolarWinds活動と融合しようとし、永続的なステート・データは正規のプラグイン設定ファイル内に保存されます。バックドアは、複数の難読化ブロックリストを使用して、フォレンジック・ツールおよびアンチウイルス・ツールに関連付けられたプロセス、サービス、およびドライバを識別します。

この投稿では、以下のトピックについて詳しく説明します。

  • Anti-Analysis環境チェックとブロックリスト
  • ドメイン生成アルゴリズムとばらつき
  • DNS AおよびCNAMEレコードの統制(C2)
  • マルウェアの動作モード

Anti-Analysis環境チェック

SUNBURSTは、C2サーバーに到達する前に、分析ツールが存在しないことを確認するために多数のチェックを実行します。続行する前に、プロセス名、ファイル書き込みタイムスタンプ、Active Directory (AD)ドメインがチェックされます。これらの確認により、SUNBURSTは、SolarWinds Orionサプライチェーンの導入後7か月間、アンチウイルス・ソフトウェアとフォレンジック調査担当者による検知を回避できたと考えています。

最初に、バックドアは現在のプロセスの小文字の名称がsolarwinds.businesslayerhostであることを確認します。UNC2452は、文字列のハッシュを計算し、その結果を64 bitの数値17291806236368054941と比較することによって、この文字列を直接ソースコードに含めることを避けます。ハッシュ値は、64bitの数値6605813339339102567による追加のXORを持つ標準的なFNV-1A の64bitハッシュとして計算されます。追加のXORオペレーションにより、マルウェア・アナリストはハッシュ・プリイメージを強制するためにカスタム・ツールを開発する必要があります。

次に、バックドアは、ファイルシステム.NET assembly SolarWinds.Orion.Core.BusinessLayer.dllの最終書き込み時刻が現在から最低でも12~14日前である場合のみ実行されます。正確なしきい値は、この間隔からランダムに選択されます。つまり、SUNBURSTは姿を現すまで約2週間潜伏していることになります。タイムスタンプ確認が失敗した場合、バックドアは、正規の繰り返しバックグラウンドタスクによって呼び出された後でランダムに再度実行されます。しきい値が満たされると、サンプルは、583da945-62af-10e8-4902-a8f205c72b2eという名称の パイプを作成し、バックドアの1つのインスタンスのみが実行されていることを確認します。名前付きパイプがすでに存在する場合、マルウェアは終了します。

SUNBURSTはその設定を正規のSolarWinds.Orion.Core.BusinessLayer.dll.configファイルに保存します。appSettingsセクションのReportWatcherRetryReportWatcherPostponeの2つの既存の設定を再利用します。初期化中、バックドアはReportWatcherRetry設定が値3であるかどうかを判断します。この値は、マルウェアが非アクティブ化され、ネットワークアクティビティを実行しなくなったことを示します。後で説明するように、UNC2452はバックドアに自身を無効化する命令ができます。この機能は、オペレーターが被害者は関心がないと判断した場合や、ミッションを完了したと判断した場合に使用できます。SUNBURSTによって侵害されたシステムを調査する場合は、この設定を確認して、バックドアが無効になっているかどうかを判断します。この値が存在しても、SUNBURSTを無効にする前に攻撃者が環境をさらに侵害していないことは証明されません。

バックドアは、システムがActive Directory(AD)ドメインに加わっているかどうかも判断し、その場合はドメイン名を取得します。システムがADドメインに加わっていない場合、実行は停止されます。SUNBURSTはADドメイン名をブロックリストと照合し、次のいずれかの値が含まれている場合は実行を中止します:

swdev.local

emea.sales

pci.local

apac.lab

swdev.dmz

cork.lab

saas.swi

dmz.local

lab.local

dev.local

lab.rio

lab.brno

lab.na

test

solarwinds

 

これらのハード・コードされたADドメインは、UNC2452が避けたいと考えたSolarWinds内部ドメインの可能性があります。

最後に、SUNBURSTは、DNS名api.solarwinds.comを解決できることを確認することで、システムがインターネットに接続されていることを確認します。それ以外の場合、実行は停止し、後でランダムに再試行します。

Anti-Analysis Blocklists

SUNBURSTの行動は、マルウェア解析やセキュリティ・ソフトの存在に影響されます。これらのセキュリティ・ツールを検知するために使用される文字列を偽装するために、UNC2452は各文字列に対してハッシュ値を計算し埋め込んでいます。バックドアがハッシュ化されたプロセス名の存在をチェックすることは簡単ですが、ハッシュ値がどの文字列に対応するか(プリイメージ)を決定するには計算コストがかかります。しかし、情報セキュリティ・コミュニティのメンバーによるいくつかの厳しい作業のおかげで、ハッシュへの総当たり攻撃が成功しています。ハッシュとそれに対応する文字列の一覧は、このFireEyeGitHubページで参照できます。

SUNBURSTは、前述のFNV-1A+XORアルゴリズムを使用して、システム上の各プロセス名、サービス名、およびドライバ・ファイル名のハッシュを計算します。

ブロックリストされたプロセスまたはドライバ名が見つかると、SUNBURSTは一時停止し、後で再試行します。バックドアは、ブロックリストに登録されているプロセスやドライバがない場合にのみ、このチェックを通過します。

ブロックリスト・サービスが見つかった場合、SUNBURSTはWINDOWS Registryのサービス構成を操作してブロックリスト・サービスを無効にしようとします。これにより、レジストリ値HKLM\SYSTEM\CurrentControlSet\services\<service_name>\StartSERVICE_DISABLEDに対応する値4に設定されます。その結果、ブロックリスト・サービスは、次の電源サイクルで無効になります。つまり、侵害されたホストにブロックリスト・サービスが存在しても、システムはSUNBURSTの影響を受けません。

レジストリの変更が行われた後、SUNBURSTはReportWatcherPostpone構成値を更新して、無効になっているサービスを反映します。その後、バックドアは一時停止し、後でブロックリストされたプロセスとサービスのチェックを再試行します。

後続のサービス・ブロックリスト確認では、ReportWatcherPostpone設定キーにすでに存在するサービスをスキップします。SUNBURSTは、無効にしたサービスをブロックリストのメンバーとして処理しなくなります。したがって、インシデントレスポンス中、フォレンジックチームは、この設定キーをリカバリしてデコードし、無効にしようとしたサービスを解析することを検討する必要があります。

ドメイン生成アルゴリズム

このセクションでは、SUNBURSTが中間コマンドと制御(C2)コーディネーターを使用して最終的なC2サーバーを取得する方法について説明します。C2コーディネーターは、バックドアにビーコンの続行または停止を指示します。また、DNS CNAMEレコードを介してSUNBURSTを最終的なC2サーバーにリダイレクトします。これにより、UNC2452は、被害者間で共有されるネットワーク・インフラを制限して、それらの操作の区分化が可能となります。

C2コーディネーターは、avsvmcloud[.]comドメインの正式なDNSサーバーとして実装されます。C2コーディネーターと通信するために、SUNBURSTはドメイン生成アルゴリズム (DGA)を使用してavsvmcloud[.]comのサブドメインを構築し、システムDNSクライアントを使用して完全修飾ドメイン名(FQDN)を解決します。バックドアは、C2コーディネーターから注文を受け取るという特殊な方法で、DNS対応を解釈します。

DGAは、次のDNSサフィックスを持つサブドメインを生成してFQDNを作成します:

  • .appsync-api.eu-west-1[.]avsvmcloud[.]com
  • .appsync-api.us-west-2[.]avsvmcloud[.]com
  • .appsync-api.us-east-1[.]avsvmcloud[.]com
  • .appsync-api.us-east-2[.]avsvmcloud[.]com

Updateと命名された手法は、これらのランダムに見えるC2サブドメインを生成するための暗号ヘルパーの初期化を担当します。サブドメインは、符号化されたユーザーIDシステムのドメイン名の符号化方式と連結することによって生成されます。C2コーディネーターは、エンコードされたデータから被害者のドメイン名を復旧でき、これを使用してSUNBURSTを最終的なC2サーバーにルーティングする可能性があります。

ユーザーIDは、3つの値に基づいて生成されます:

  • 最初に使用可能な非ループバック・ネットワーク・インターフェイスのMACアドレス
  • ドメイン名
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\MachineGuid

SUNBURSTは、これらの組み合わせ値のMD5ハッシュを取得し、カスタムXORスキームを使用してエンコードします。この値は、UNC2452によって固有の被害者を追跡するために使用されると考えています。

SUNBURSTは、バックドアの動作モードを示すために、4つの異なる形式のサブドメインを使用します。各フォームには、若干異なる情報が含まれます。そのうち2つの形式で、調査者は被害者組織のドメイン名を回復できます。SUNBURST C2コーディネーター・トラフィックに被害者のドメインが存在することを確認するために、DNSログをレビューすることをお勧めします。

SUNBURSTが初期モードの場合、DGAで生成されたドメイン・プレフィックスに被害者組織のドメインが埋め込まれます。マルウェアが「アクティブ」モードに移行すると、マルウェアは他の2つの形式のサブドメインを使用します。これらにはADドメインは含まれず、実行中および停止中のサービスのリストまたはタイムスタンプのいずれかのエンコードが含まれます。

オープンソース・コミュニティは、多くのサブドメイン形式の素晴らしいリバース・エンジニアリングを行ってきました。我々は、4つの可能性のある符号化をすべて逆転させるいかなるパブリック・デコーダ・スクリプトも認識していませんが、ほとんどのデコーダは、最も有用な情報、すなわち、サブドメインに埋め込まれたユーザーIDとドメイン名の回復にフォーカスしています。DNSログにアクセスできる被害者組織のインシデント対応者は、これらのツールを使用して、ADドメインがSUNBURSTによって生成されたDNSサブドメインに埋め込まれていないことを確認することをお勧めします。これは、フォローオン・アクティビティを示すものではないことに注意してください。

そのようなドメインを復号するために、以下のソースが参照される可能性があります:


図1:攻撃者の操作とSUNBURSTの利用方法の図

図1:攻撃者の操作とSUNBURSTの利用方法の図

SUNBURSTは、DNSとHTTPの両方を含む2つの部分からなるC2プロトコルを使用します。「パッシブ」モードでは、バックドアはDNSを介してC2コーディネーターと通信し、その状態に対する高レベルの更新を受信します。たとえば、C2コーディネーターはバックドアにスリープ状態またはスプリング状態になるように指示することがあります。バックドアが「アクティブ」モードの場合、バックドアはHTTPを介して最終的なC2サーバーに通信し、「プロセスのスポーン」や「ファイルの転送」などの詳細なコマンドを受信します。

DNS C2とC2コーディネーター・プロトコル

C2コーディネーターと通信する場合、バックドアはDGAを介してドメインを継続的に生成します。バックドアは、ドメインを生成する間のランダムな間隔の実行を遅らせます。場合によっては、この遅延が最大9時間になることもあります。

C2コーディネーターがDNS Aレコードで応答する場合、SUNBURSTは解決されたアドレスをIPアドレス・ブロックのハードコードされたリストと照合します。アドレスがブロック内にある場合、バックドアは関連するモードに遷移します。バックドアは、遷移が確認されるまで、ブロックリスト、スリープ、ビーコンをDNS経由で確認するだけの「パッシブ」モードで開始します。その他のモードは、マルウェアがHTTP経由で通信する「アクティブ」、マルウェアが永久に無効になる「無効」です。これらのモードと遷移は、「動作モード」セクションで定義されます。

C2コーディネーターは、DNS CNAMEレスポンスで応答する場合もあります。この場合、マルウェアはHTTPS C2コミュニケーションにCNAMEレスポンスから指定されたドメインを使用します。SUNBURSTは、コマンド実行とC2HTTP(S)コールアウトを処理するスレッドを開始します。調査担当者が、avsvmcloud[.]comのサブドメインのCNAME解決を確認できるようになったら、UNC2452が環境内でFollow-on C2を開始した可能性があります。

マルウェアは、DNS CNAMEレスポンスを受信する直前に、次のいずれかのサブネットを指すDNS Aレコード・レスポンスを受信しなければならないことに注意してください。それ以外の場合、CNAME解決は無視され、エラーとして扱われます。さらに、これらのサブネットについては、AレコードのIPアドレスからの重要度が最も低いバイトがパースされ、使用する代理法、使用するURIスキーム、およびHTTPスレッドで使用される遅延値などの設定データが取得されます。

18.130.0.0/16

99.79.0.0/16

184.72.0.0/15

後続のDNS Aレコードが次のサブネット範囲で対応すると、DGAビーコンが続行されます。

8.18.144.0/23

18.130.0.0/16

71.152.53.0/24

99.79.0.0/16

87.238.80.0/21

199.201.117.0/24

184.72.0.0/15

 

それ以外の場合、次のサブネット範囲で後続のDNS Aレコード・レスポンスが発生すると、SUNBURSTが終了し、設定キーReportWatcherRetryがそれ以上実行されない値に更新されます。これがkillswitchです。

10.0.0.0/8

fc00:: - fe00::

96.31.172.0/24

172.16.0.0/12

fec0:: - ffc0::

131.228.12.0/22

192.168.0.0/16

ff00:: - ff00::

144.86.226.0/24

224.0.0.0/3

20.140.0.0/15

 

「アクティブ」モードでは、DGAサブドメイン・エンコードにビクティム・マシンのドメイン名情報は含まれません。代わりに、DGAサブドメインはタイム・スタンプまたは停止/実行中のサービスのリストをエンコードします。「パッシブ」モードに戻るには、マルウェア事業者がDNSサーバーを設定して、次のIP範囲内のA記録を解決することができます:

41.84.159.0/24

74.114.24.0/21

154.118.140.0/24

217.163.7.0/24

マルウェアが「アクティブ」モードから「パッシブ」モードに戻された場合、オペレーターがサンプルを再度アクティブ化したい場合、C2コーディネーターはアクティブ化プロセスを繰り返す必要があります。

HTTP(S) C2

通信する新しいホストとのCNAME DNSレスポンスを受信すると、SUNBURSTは新しいスレッドを開始してHttpHelper.Initializeという手法を実行します。この手法は、C2のコミュニケーションとディスパッチを担当します。HTTPスレッドは、SetTimeコマンドで制御される設定可能な時間だけ遅延させることから始まります。HTTPスレッドは、コールアウト間に最低1分間遅延します。マルウェアはHTTP GETまたはPOSTリクエストを使用します。サンプルは証明書の検証を無効にするため、SSL man-in-the-middleが実行された場合にHTTPSトラフィックを復号化できます。

マルウェアは、部分文字列のランダムな選択からHTTP GETまたはPOSTリクエストURIを構築します。使用される方式は、CNAME DNSレスポンスの直前に受信したAレコードに依存します。GETリクエストを送信する際に、マルウェアは符号化ユーザIDを含む「If-None-Match」のHTTPファイルを追加します。これにより、C2サーバーは、どのSUNBURST導入によってリクエストが生成されたかを判断できるようになり、単一のサーバーでのC2ストリームの多重化がさらに有効になります。

観測されたトラフィックでは、C2サーバーはステガノグラフィを用いてHTTPレスポンス本文にデータを隠蔽し、.NETアセンブリに関連する無害なXMLとして出現することを試みました。コマンドデータは、多くのGUIDおよび16進数に分散されます。コマンドは、"\{[0-9a-f-]{36}\}"|"[0-9a-f]{32}"|"[0-9a-f]{16}"という正規表現を使用して16進数を検索することによって、HTTPレスポンス本文から抽出されます。レスポンス内の一致する部分文字列は、非16進数に対してフィルタリング、結合され、HEXデコードされます。動作方法によっては、マルウェアがステガノグラフィを省略し、エンコードされたレスポンスをHTTPレスポンス本文で送信する場合があります。


図2:C2レスポンスは、コマンドをXML GUIDに埋め込みます。

受信したC2レスポンスにおいて、最初のDWORD値は、そのメッセージの実際の大きさを示します。この値の直後に、オプションのジャンク・バイトが追加されたメッセージが続きます。抽出されたメッセージは、メッセージの最初のバイトを使用してシングルバイトXORデコードされます。その後、結果はDEFLATEで圧縮解除されます。圧縮解除されたデータの最初の文字は、コマンドIDにマップされるASCII整数で、オプションの追加コマンド引数はスペース文字で区切られます。サポートされているコマンドを以下の表に示します。

コマンド

ID

動作

Idle

操作なし

Exit

現在のスレッドを終了します。

SetTime

メインイベントループ実行間の遅延時間を秒単位で設定します。遅延は[.9*<delay>,1.1*<delay>]の間でランダムに変化します。

遅延が300未満の場合、ループの次の実行時に2倍になります。これは、約[5,10]分の間隔に収まる必要があることを意味します。

o無関係な2番目の遅延ルーチンがあり、[16hrs,83hrs] の間のランダムな間隔を遅延します。

CollectSystemDescription

ホスト名、ユーザー名、OSのバージョン、MACアドレス、IPアドレス、DHCP構成、ドメイン情報を含むローカルシステムのプロフィール。

UploadSystemDescription

指定したURLにHTTPリクエストを実行し、結果をパースし、対応をC2サーバーに送信します。

RunTask

指定したファイル・パスと引数を使用して新しいプロセスを開始します。

GetProcessByDescription

プロセスのリストを返します。引数が指定されていない場合は、PIDとプロセス名のみを返します。引数が指定されている場合は、プロセス所有者の親PIDとユーザー名およびドメインも返します。

KillTask

指定されたプロセスをPIDで終了します。

GetFileSystemEntries

パスと一致パターンを指定すると、ファイルとディレクトリが再帰的に一覧表示されます。

WriteFile

ファイル・パスとBase64でエンコードされた文字列を指定すると、Base64文字列の内容が指定されたファイル・パスに書き込まれます。追加モードを使用して書き込みます。書き込み後に[1s,2s]の遅延が発生します。

FileExists

10 

指定されたファイル・パスが存在するかどうかをテストします。

DeleteFile

11 

指定したファイル・パスを削除します。

GetFileHash

12 

指定されたパスでファイルのMD5を計算し、その結果を16進数として返します。引数が指定されている場合は、ファイルの予想されるMD5ハッシュであり、計算されたMD5が異なる場合はエラーを返します。

ReadRegistryValue

13 

サポートされているハイブのいずれかから読み込まれた任意のレジストリ。

SetRegistryValue

14 

任意のレジストリは、サポートされているハイブのいずれかから書き込みます。

DeleteRegistryValue

15 

サポートされているハイブのいずれかから任意のレジストリが削除されます。

GetRegistrySubKeyAndValueNames

16 

指定されたレジストリパスの下にあるサブキーと値の名称の一覧を返します。

Reboot

17 

システムの再起動をただちにトリガーしようとします。

SUNBURSTは、UTF-8ストリングと付属の4バイト・エラーDWORDと8バイト・ユーザーIDからなるプロトコルを使って、C2サーバーにメッセージを送り返します。これらは、DEFLATEで圧縮されており、メッセージに見せかけたXORキーがシングルバイトのXORにエンコードされています。長さ10,000以下のメッセージ・ペイロードは、SolarWindsによって正当に使用されるOrion Improvement Program (OIP)メッセージに似たJSON文書に変換されます。HTTPリクエスト本文では、10,000バイト以上のメッセージがそのまま送信されます。

偽のOIP文書化には、次のフィールドが含まれています:

  • userId – a unique identifier for the victim machine
  • sessionID – stores a new random GUID for each HTTP thread
  • steps – an array of objects that contain the following
  • keys: Timestamp, Index, EventType, EventName, DurationMs, Succeeded, Message

The JSON key EventTypeOrionの値にハードコーディングされ、EventNameEventManagerにハードコーディングされます。C2サーバーに送信するエンコード済みのメッセージはランダムな範囲に分割、Base64方式でエンコードされ、steps配列内のオブジェクトMessageに格納されます。steps配列内のすべてのオブジェクトがマルウェア・レスポンスに寄与するわけではありません。Timestampフィールドの整数には、Messageフィールドの内容がマルウェア・レスポンスで使用されていることを示す0x2ビットが設定されている必要があります。Timestampフィールドの0x2ビットがクリアされているstepsのオブジェクトにはランダム・データが含まれ、マルウェア・レスポンスのアセンブル時に破棄されます。これは、マルウェア・サンプルがない場合に分析を妨げる試みである可能性があります。


図3:OIPプロトコルとしてのHTTPコールアウト・マスカレード

動作モード

DGAセクションに詳細が記載されているように、マルウェアには、CNAMEレコードが存在するかどうかに応じて、Aレコードが解決するIPブロックによって設定された複数の動作モードがあります。これらの動作モードは内部列挙型に格納されます。これらのマッピングと値については、次に説明します。

内部モード

マルウェアの内部動作は、次のモードで制御されます:

モード名

説明

Truncate

3

無効化。マルウェアのkillswitchが有効化されており、XML構成をディスク上で変更しないと、サンプルが再度実行されることはありません。

New

4

パッシブモード。DGAサブドメインはシステムのドメイン名をエンコードします。

Append

5

アクティブモード。C2ビーコンは、次のCNAME解決時に発生するか、すでに積極的に発生しています。DGAドメインは、userIDまたはサービスのリストのいずれかをエンコードします。

モード値は、バックドア設定キーReportWatcherRetryに書き込まれます。調査担当者は、マルウェア構成を回復し、この構成値を検査して、マルウェアの最後の実行モードを判断することを検討できます。

次の遷移は、IPブロック範囲を実行モードに変換する方法を制御します:

トランジション名

説明

Atm

Truncateへの移行

Ipx

AppendからNewへの移行

ImpLink

Truncateへの移行

NetBIOS

Appendへの移行、C2ビーコンの開始または続行

Unknown

IPv4またはIPv6アドレスではない場合は、終了、後でDGAを再試行します。

次の図は、HTTPベースのC2ビーコンが開始される前に、SUNBURSTのDGA DNSレスポンスがマルウェアを制御するためのモード遷移としてどのように機能するかを示しています:

さらに、DNS解決の列がマルウェア・モードを移行する方法を示す注釈付きネットワーク・ログを次に示します:

モードと移行に関するこの説明の最後に、これらのIPブロックの選択に関して少し触れます。キルスイッチをアクティベートするImpLink IPブロックのような場合、セキュリティ研究者によって発見されるのを避けるために、この範囲が攻撃者によって特別に選択された可能性があります。そのほか、NetBIOSや「特別な」NetBIOS IPブロックなどが解決される企業は、無関係であるか、少なくとも推測せずに明言できる範囲を超えている可能性があります。

マルウェア・フロー図

次の図は、マルウェアの実行の全体像を示しています。内部的には、SUNBURSTは前述のように一連のモードと遷移を使用します。これらのモードとトランジションの名前は意味を持ちません。マルウェア作成者は意図的に難読化の一形態としてそれらを選択しました。マルウェアの実行を図にするとき、これらの名前は明確化のため再利用されました。


図4:マルウェア・ロジックと決定状態

Q&A

ブロックリストされたプロセス、サービス、またはドライバを実行しているシステムは侵害から守られていますか?

常に安全とはいえません。ブロックリストされたプロセスまたはドライバが見つかると、SUNBURSTは無条件に終了し、検出されなくなるまで実行されません。一方、サービスは、起動時の初期化を制御するレジストリ値を設定することで無効になり、明示的に停止されることはありません。その結果、マルウェアが後でサービス・チェックを実行するときに、ブロックリストされたサービスがまだ実行されている可能性があります。このため、ブロックリストに登録されたサービスの実行中に被害者システムが感染する可能性があります。また、SUNBURSTはサービスを一度無効にしようとし、そのサービスを無効にするように設定を更新します。設定が更新されると、サービスは後続の実行中にブロックリストされたエントリとして扱われません。

別のDGAエンコードを監視すると、インシデントレスポンス中に何らかの情報が得られますか?

簡単な答え:どこを探すかのヒントは得られますが、それだけではありません。ネットワーク・ログのDGAエンコードの変更に注意するということは、マルウェアがNewからAppendまたはAppend から Newに移動した可能性があるというヒントです。これにより、CNAMEレコードが検出されるとすぐに、HTTP C2が開始できるモードになります。インシデントレスポンスは、DGAエンコード全体にフォーカスするかわりに、正常に解決されているCNAMEレコードを識別しようとすることにフォーカスする必要があります。CNAMEレコードを識別するのは、ログとより強力なシグナルを通してマルウェア・モードを追跡するよりも容易です。

「killswitch」とは?

FireEyeは、特定のDNSレスポンスによってマルウェアが自身を無効にし、その後のネットワーク活動を中止することを検出しました。GoDaddyの悪用チームとMicrosoftThreat Intelligence Centerの支援を受けて、DGAドメインの解決に使用されるドメインは、Microsoftの制御下にあるシンクホールサーバーを指定するように再構成されました。このシンクホール・サーバーのIPは、マルウェアが現在のモード (NewまたはAppend) から、永続的に非アクティブになるTruncateモードに移行するために使用される範囲に入るように特別に選択されました。言い換えれば、SUNBURST感染は、killswitchのために予防接種すべきだということです。

C2コミュニケーションが発生した場合、CNAMEレコードは必要か?

CNAMEレコードは、HTTP C2ビーコンが発生するために必要であり、最終的なC2サーバーを指定するためにC2コーディネーターによって提供されます。C2アクティビティは、CNAMEレコードを介して提供されるドメイン名を介して行われる必要があります。Raw IPを介して直接実行することはできません。C2ビーコンを初期化するために、バックドアはまず特殊なNetBIOSサブネットの1つからAレコード・レスポンスを探し、その後CNAMEレコードを受信することを想定しています。

DGAドメインが企業のドメイン名にデコードされた場合、その企業は危険にさらされていますか?

バックドアが「パッシブ」モードの場合、被害者のADドメイン名を埋め込むDGAエンコードを使用します。これは、バックドアが存在するすべてのシステムで、攻撃者がバックドアをアクティブにしてアクティブなC2コミュニケーションを開始できるDNSサーバーに接続しようとし始めた可能性があることを意味します。ほとんどの場合、これは発生せず、非ターゲットのバックドアはオペレーターによって無効化されていました。したがって、ドメインがDNSログからデコードされている場合、組織がフォローオン・アクティビティを経験しているとは考えられません。具体的には、バックドア・コードが存在し、アクティベーションが可能であることを示す指標にすぎないということです。

公的貢献

私たちは、SUNBURST GitHubの公開リポジトリにコミュニティの実質的な貢献を見てきました。

このリポジトリへのすべての貢献者に感謝したいと思います。具体的には、SUNBURSTが総当たり攻撃をしてきたすべてのFNVハッシュが埋め込まれています。これは、コミュニティのメンバーが他者を支援するために無料で提供した膨大なコンピューティング能力です。ハッシュを投稿してくれた皆様に感謝し、特にハッシュキャット・コミュニティを呼びかけ、それぞれのハッシュを体系的に破るために組織されたことに感謝したいと思います。プリイメージがかなり長い最後の数少ないハッシャーを破るために不可欠なことでした。

謝辞

Matthew Williams、Michael Sikorski、Alex Berry、Robert Wallaceの協力に感謝します。
UNC2452の詳細については、Webセミナー「UNC2452: What We Know So Far / 現時点でわかっていること」をご覧ください。

 

本ブログは機械翻訳(MT)を使用して翻訳しています。原文と翻訳版の意味、文言が異なる場合は原文を有効とします。

原文:December 24, 2020 「SUNBURST Additional Technical Details