SplunkでSunburstバックドアを検出する

要約：このブログでは、Splunkのコア機能とSplunk Enterprise Securityを使用して、SolarWinds社のOrionソフトウェアを悪用して拡散するSunburstバックドアマルウェアからネットワークを保護する(そしてそのアクティビティを検出する)ためのすぐに使えるガイダンスをご紹介します。Splunkの脅威調査チームは、来週、追加のガイダンスを公開する予定です。以下の方法で悪質なネットワークアクティビティが検出されることがありますが、実際にネットワークが危険にさらされているとは限らないことに注意してください。通常どおり、注意深く確認してください。 

Sunburstバックドアの概要

日曜日の午後、FireEye社は「Sunburstバックドア」と名付けたマルウェアに関するレポートを公開しました。詳細な分析が報告されたこのすばらしいホワイトペーパーを直接お読みになることを強くお勧めしますが、概要は次のとおりです。攻撃者は、巧妙な手段でSolarWinds社のOrionソフトウェアに含まれる正規のDLLをトロイの木馬化し、同社の顧客向けアップデートサイクルにこのDLLを埋め込みました。そして、このトロイの木馬化されたバックドアを通じて、感染者のネットワーク内で横展開し、重要なデータを盗み出します。

FireEye社は現時点で、少なくとも2020年の春には幅広い業種をターゲットに世界各地でこの攻撃が行われていたことを突き止めました。米国CISAが最近発行した緊急指令21-01と併せて、Splunkは、お客様がこの攻撃を検出してネットワークを保護できるように、概要レベルであっても早急にガイダンスを提供することが必要だと考えました。Splunkの調査チームは、今後数日のうちにラボでシナリオを検証しながら、この攻撃に合わせてより細かく調整された検出方法を公開する予定です。(こちらについては、後日公開された「脅威の指標をSplunk Enterprise Securityにスムーズに取り込む(英語)」も参照ください)

注意事項

FireEye社のレポートによると、この攻撃者は、ターゲットを慎重に選び、トラフィックをより巧妙に偽装するため、地域に合わせて攻撃元のインフラを変え、さらには被害者に合わせて攻撃元のホスト名も変えるという高度な手口を使用しています。SolarWinds Orionのような信頼されているソフトウェアを踏み台にすることで、ネットワークにおけるSolarWinds社製品の地位を利用し、オンプレミスとクラウドの両方のインフラで横展開して、データを捕捉し盗み出します。

Sunburstバックドアはattack vectorとして非常に巧妙ですが、それでもネットワーク上を横展開するトロイの木馬にすぎません。そのため、一般的なネットワーク防御策とインシデント対応策の多くをすぐに活用できます。ネットワーク上でSolarWinds Orionを実行しているホストがわかっている場合は、そこが攻撃の踏み台となるため、それらのホストで追跡を開始します。Sunburstバックドア自体は、Orionを実行しているホストにのみ仕掛けられます。しかし、攻撃者は一般的な手法やOrionから収集された資格情報を使用してOrionホストから横展開するため、その脅威にも対応が必要です。

Splunk Enterprise Securityでの検出

Sunburstのような出来事は、Splunkのブログ「インターネットから収集したCOVID (または他の)脅威インテリジェンスをSplunk Enterprise Securityに追加する方法(英語)」を読み返して、Splunk Enterprise Security (ES)に脅威インテリジェンスをすばやく追加する方法を再確認する良い機会です。要するに、この中の「COVID」脅威リストを「SUNBURST」脅威リストに置き換えて考えればよいのです。このブログでは、FireEye社が現在公開しているIOC (侵害の痕跡)に基づいてSplunkのSIEMをアップデートする方法と、ホストが感染した場合の検出結果について説明しています。 

同僚のShannon Davisがすでに、上記の方法でSplunk ESに取り込めるローカルの脅威インテリジェンスファイルをいくつか作成しています。 

IOC：DNS、ハッシュ、IP

まずは、FireEye社がGitHubリポジトリで公開しているIOCを確認しましょう。たくさんの「OR」ステートメントをつなげてDNSを調べることもできますが、IOCが増えて冗長になるのを避けるため、簡潔なルックアップファイルをいくつか作成しました。ルックアップファイルの使い方について詳しくは、以前のブログ記事「Lookup Before You Go-Go...Hunting (ハンティングに乗り出す前の下調べ)(英語)」と「Hunting COVID Themed Attacks with IOCS (IOCでCOVID関連攻撃を追跡する)(英語)」を参照してください。必要なルックアップファイルはGitHubリポジトリで随時公開しているので、それぞれ入手してください。これはFireEye社やその他のベンダーが公開している情報を基にしたもので、作業はここから始める必要があります。

たとえば、上記のブログまたはGitHubリポジトリの指示に従ってルックアップテーブルを作成します。その後、次のようなサーチを実行すると、これまでに特定されている悪質なドメインと通信しているホストを見付けることができます。

index=main sourcetype=stream:*
| lookup sunburstDOMAIN_lookup Domain AS query
| search isBad=TRUE
| stats VALUES(query) AS "Sunburst" by src_ip

調べたいIOCのタイプ(ドメイン、IP、またはハッシュ)に合わせて、サーチクエリーとルックアップファイルを変更するだけです。

これらのIPやドメインへのトラフィックが検出された場合は、FireEye社が公開しているSnortアラートをよく調べてください。ファイアウォールまたはプロキシのトラフィックログを収集している場合は、URLに次の文字列を含むトラフィックを探すことで、侵害されたホストを絞り込める可能性があります。

/swip/upd/SolarWinds.CortexPlugin.Components.xml
swip/Upload.ashx
/swip/upd/

ラテラルムーブメント(横展開)

トロイの木馬化されたDLLを介してネットワークへのアクセスを獲得した攻撃者は、重要な情報を探して盗み出すために、横展開を開始します。次は、この動きを検出しましょう。ログではまだ確認されていませんが、攻撃者はネットワークトラフィックの法則に従って動くと考えてよいでしょう。私は、非常に便利なSplunk Security Essentials (SSE)ツールを使用して、いくつかのサーチをPDFにエクスポートしました(下図)。これらのサーチをそのまま使用することも、これを基に必要に応じて変更することもできます。まずは、ネットワーク内でSolarWinds Orionを実行しているホストと通信する不審なトラフィックを確認することを強くお勧めします。

Sysmonと名前付きパイプ

FireEye社のレポートで興味深い情報として、名前付きパイプの存在も挙げられます。SysmonとSplunkを使用している場合は、イベントコード17と18で名前付きパイプ「583da945-62af-10e8-4902-a8f205c72b2e」を探してみてください。以下にサーチ例を示します。

index=windows sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" 
(EventCode=17 OR EventCode=18) PipeName=583da945-62af-10e8-4902-a8f205c72b2e

また、SysmonとSplunkのクエリーについてコミュニティが興味深い実験を行っていますが、現時点ではそれらのクエリーを検証できていません。検索してみると面白い情報が見つかるかもしれません。

Azure Active Directory

Microsoft社も、Sunburstバックドアを使用する攻撃者が横展開の中でAzure ADを標的にしていることを突き止めました。Azure ADへの攻撃は、盗んだ管理者パスワードまたは偽造したSAMLトークンを使って行われます。幸い、SplunkではRyan Laitのすばやい対応のおかげでこれらを検出できます。AzureのデータをSplunkに取り込んでいる場合は、攻撃者による活動について優れた洞察が得られます。

Microsoft Azure Add on for Splunkによって収集されるAzure Active Directory監査データは、攻撃者の手口の一部を追跡するために役立ちます。この監査ログには、Azure内でのユーザーとリソース間のやり取りがすべて記録されます。検出のためのサーチ例をいくつか示します。

アプリケーション登録とサービスプリンシパルへの変更の監視
サービスプリンシパルの新規作成：

sourcetype="azure:aad:audit" activityDisplayName="Add service principal" 
| stats values(activityDisplayName) AS Action, values(initiatedBy.user.userPrincipalName) 
AS UPN, values(targetResources{}.displayName) AS Target,
values(targetResources{}.modifiedProperties{}.displayName) AS "Modified Resources",
values(targetResources{}.modifiedProperties{}.oldValue) AS "Old Values",
values(targetResources{}.modifiedProperties{}.newValue) AS "New Values" by correlationId 
| fields - correlationId

アプリケーションまたはサービスプリンシパルへの資格情報と証明書の追加：

sourcetype="azure:aad:audit" activityDisplayName="Add service principal credentials"

アプリケーションまたはサービスプリンシパルへの権限とロールの割り当ての追加：

sourcetype="azure:aad:audit" activityDisplayName="Add app role assignment to service principal" OR 
activityDisplayName="Add delegated permission grant" OR activityDisplayName="Add application" 
| stats  values(initiatedBy.user.userPrincipalName) AS UPN, values(targetResources{}.displayName) 
AS Target, values(targetResources{}.modifiedProperties{}.displayName) AS "Modified Resources", 
values(targetResources{}.modifiedProperties{}.oldValue) AS "Old Values", 
values(targetResources{}.modifiedProperties{}.newValue) 
AS "New Values" by correlationId activityDisplayName
| fields - correlationId

このサーチを使用して、アプリケーション登録に不適切に高い権限を追加しているユーザーを調査します。 #ReadMailInAllMailboxes

マルチテナントアクセスを許可するように変更されたアプリケーション：

sourcetype="azure:aad:audit" activityDisplayName="Update application" operationType=Update 
result=success targetResources{}.modifiedProperties{}.displayName=AvailableToOtherTenants 
| table activityDateTime initiatedBy.user.userPrincipalName, 
targetResources{}.displayName additionalDetails{}.value

Azure ADカスタムドメインへの変更：

sourcetype="azure:aad:audit"  activityDisplayName="Add unverified domain" OR 
activityDisplayName=*domain* | stats values(activityDisplayName) AS 
Action, values(initiatedBy.user.userPrincipalName) AS UPN, values(targetResources{}.displayName) 
AS Target, values(targetResources{}.modifiedProperties{}.displayName) 
AS "Modified Resources", values(targetResources{}.modifiedProperties{}.oldValue) 
AS "Old Values", values(targetResources{}.modifiedProperties{}.newValue) 
AS "New Values" by correlationId 
| fields - correlationId

Microsoft Azure App for Splunkで、その他のサーチやAzureデータ向けの事前構築済みセキュリティコンテンツも確認してください。

VPSホスト

現時点では、攻撃者は地理的に関連のある(つまりIPアドレスが被害者の国のローカルである)仮想プライベートサーバー(VPS)ホストを利用して被害者のネットワークにアクセスしていると考えられます。これらのIPの決定的なリストはありませんが、2020年春以降の外部から内部へのネットワークトラフィックを調査して、不明なIPアドレスがシステム(特にSolarWindsホスト)にアクセスしていないかどうかを確認することをお勧めします。

MITRE ATT&CK

FireEye社の調査チームは、調査結果をMITRE ATT&CKに反映しています。前述のラテラルムーブメント(横展開)での調査と同様に、私はSplunk Security Essentialsで、確認された戦術と技法に関係する可能性のあるすべてのコンテンツを抜き出しました。その結果をまとめたPDFはかなり大きなサイズになりましたが、お役に立てば幸いです。自社のSSEインスタンスのみを重点的に調査したい場合は、以下の確認すべき項目を1つずつサーチしてください(PDFには有用だと思われるサーチをすべて含めたので、お時間があれば目を通してみてください)。

• Malicious Powershell Process - Encoded Command (悪質なPowershellプロセス - エンコードされたコマンド)
• Anomalous Audit Trail Activity Detected (異常な監査証跡アクティビティの検出)
• Tor Traffic (Torトラフィック)
• Concentration of Attacker Tools by Filename (ファイル名ごとの攻撃者ツールの集中的な実行)
• Concentration of Attacker Tools by SHA1 Hash (SHA1ハッシュごとの攻撃者ツールの集中的な実行)
• Sc Exe Manipulating Windows Services (Windowsサービスを操作するSc.Exe)
• Prohibited Service Detected (禁止されているサービスの検出)
• Prohibited Process Detected (禁止されているプロセスの検出)
• Anomalous New Service (異常な新規サービス)
• Abnormally High Number of Endpoint Changes By User (ユーザーによる異常な回数のエンドポイント変更)
• First Time Seen Running Windows Service (Windowsサービスの初回実行)
• Processes with Lookalike (typo) Filenames (ファイル名が類似する(少しだけ違う)プロセス)
• SMB Traffic Allowed (許可されたSMBトラフィック)
• Anomalous New Process (異常な新規プロセス)
• High Process Count (プロセス数の増加)
• Prohibited Service Detected (禁止されているサービスの検出)
   

まとめ

私たちはこのブログを短く、わかりやすく、簡潔に保つように努めました。上記の情報は、SSEやESCUなどの既存の製品、過去の調査、さらに一部はShannon DavisやRyan Laitなどの優秀なSplunk社員が即席で作成したSPLからの抜粋です。また、分析とIOCの多く(すべてではありませんが)は、FireEye社とMicrosoft社のブログを参考にしました。すでに述べたとおり、Splunkの脅威調査チームは引き続き、詳細(およびデータ)を入手し次第、最新情報と追加の検出方法を公開する予定です。

このブログはこちらの英語ブログの翻訳です。