Supernovaマルウェアを検出: SolarWindsの続き

TL;DR: Supernova は、SolarWinds Orion をインメモリWeb shell経由の攻撃に晒しています。これはパッチを当てる必要があり、以下の検出は敵の行動を特定するのに役立ちます。

組織が一息ついて休暇を終えた頃、SolarWinds Orionの "Sunburst "侵入に趣向を凝らしたものが現れ始めました。

Supernovaのタイムライン

12 月 15 日、GuidePoint Securityは、当初 FireEye の調査で公開された「Supernova」と呼ばれる .NET ウェブシェルの分析結果を掲載しました。その2日後には、パロアルトネットワークスが「Supernova」の分析をフォローアップしました。Microsoftは12月18日、FireEyeが最初に報告したSunburstの侵入に含まれていたサプライチェーンのDLLを侵害した 「Solorigate」に関する包括的な報告書を発表しました。マイクロソフトは「発見された追加のマルウェア」の項で、調査中に発見された「Supernova」というマルウェアを呼び、このマルウェアがSunburst攻撃の他の側面に適合していないため、Supernovaは別のAPTグループから発信された可能性があるという仮説を示しています。

12月24日、SolarWindsはSunburstとSupernovaの両方を含む初のセキュリティアドバイザリを発表しました。このアドバイザリはその後、新しい情報が入手可能になったため、何度も更新されています。SolarWindsは、SupernovaはSunburstの攻撃とは別物であることを明らかにしており、マルウェアはOrionプラットフォームに見られる脆弱性を利用していました。この新たな脆弱性と関連するマルウェアは、攻撃者が別の方法でアクセスすることを可能にします。DHS CISAは、当初のガイダンスを更新し、この新しい方法を含むようにしました。

この新たに発表された調査（そしてこれは本当にリーダーズダイジェスト版です）に基づいて、Supernova とは何か、そしてそれがどのように活用されているかを見ていきます。また、データモデルとSPLを使って、この攻撃方法を利用している敵を識別することができる様々な検出方法についても見ていきます。

Supernovaとは？

Supernovaは当初、SolarWindsオリオンの侵入であるSunburstの解析中に特定されました。この初期分析の間に、SupernovaのYaraルールがSunburstの他の要素と一緒に作成されたのは、当初、Supernovaが同じ侵入の一部であると仮定されていたからです。SupernovaはSunburstとは異なるという新しい仮説に基づいて、FireEyeはGitHubのレポからYaraルールを削除しましたが、オリジナルのルールにはまだアクセス可能です。

Supernova はゼロデイ脆弱性 を利用して、トロイの木馬化された .NET DLL をインストールしています。このDLLはSunburst DLLのようにデジタル署名されていないことに注意することが重要で、これが複数の研究者が脆弱性を利用して悪意のあるコードを脆弱なシステムにロードするために使用している別の脅威行為者であると考える理由の一つです。

ロードされるマルウェアはWeb shellです。このMITRE ATT&CKの技術、T1505は、ウェブサーバをバックドア化し、システムへの永続的なアクセスを確立するために攻撃者によって使用されています。より深く掘り下げるには、AcunetixによるWeb shellの素晴らしい入門書がここにあります。興味のある方は是非先に読んでみてください。このWeb shellをさらに厄介なものにしているのは、インメモリで実行するように作られていることで、検出やフォレンジックアナリストが侵入後に追加の分析を行うのをより困難にしています。しかし、困難ではありますが、不可能ではありません。

できる対策とは？

SSolarWinds社は、SunburstとSupernovaの両方の問題と、どのバージョンのソフトウェアが影響を受けるかを説明したセキュリティアドバイザリの更新を続けています。両方の問題にはパッチが適用されています。実際、適用されるパッチによっては、SunburstとSupernovaの両方を同時に緩和することができます。

自社の環境でSupernovaをどう検出するか？

ここまで読んでいただいた方は、SupernovaとSunburstが別の問題であることを基礎的に理解し、何らかの対策を講じたいと考えていることでしょう。ここでは、あなたの環境で役立つかもしれないいくつかの検出方法を紹介します。

このブログの読者の方は、Splunk EnterpriseやSplunk Enterprise Securityを使っているかもしれません。データモデルは誰でも使えますが、誰でも使いこなせるわけではないと認識しています。その点を考慮して、以下の検出はデータモデルとtstatsコマンドを使用した場合と同様にSplunkで提供されています。tstatsコマンドを使用すると、全体的な検索パフォーマンスが向上します。データモデルを使用していない場合、SPLの検索は、検索基準がまだ適用されるので、役に立つはずです。しかし、以下の例と比較して、環境のソースタイプによってフィールド名が異なる場合があります。

これらは、現状のままでは大まかな検索ですが、IPアドレスや他の属性に基づいてさらに絞り込むことができます。優れた資産管理は、検索対象となるシステムを分離するのに役立ちます。検索にtstatsやデータモデルを使用せず、SPLだけを使用したい場合は、該当するイベントを含むインデックスのみに検索を絞り込むために、index=<インデックス名を挿入> を使用することを忘れないでください。

CERT/CCは12月26日に新しいSolarWinds Orion APIの脆弱性アラートを発行しました。この最新アラートが追加された最近の脆弱性スキャンで、Splunkに脆弱性スキャンデータをインジェストして脆弱性データモデルを生成していると仮定すると、この検索により脆弱性のあるシステムが発見される可能性があります。

| tstats count from datamodel=Vulnerabilities.Vulnerabilities where 
Vulnerabilities.cert=VU#843464 OR Vulnerabilities.cert=843464 OR 
Vulnerabilities.cve=CVE-2020-10148 groupby Vulnerabilities.dest 
Vulnerabilities.dvc Vulnerabilities.signature Vulnerabilities.vendor_product _time span=1s

SPLの検索は、Nessus、Qualys、その他のイベントソースに依存しますが、脆弱性ベンダーがCERT/CCやCVEを利用していれば、このように簡単に検索することができます。

index=<index where vulnerability data is stored> 
sourcetype=<vulnerability scanner> (VU#843464 OR 843464 OR CVE-2020-10148)

ディスク上にWeb shellが存在しないため、この侵入の痕跡は限られていますが、ファイルハッシュはトロイの木馬化された.NET DLL用に存在しています。VirusTotal は現在59のエンジンで検出しています。シグネチャ名は、同様に検索することができますが、アンチウイルスベンダーによって異なります。

ファイルシステムのイベントをどのように識別しているかにもよりますが、以下の検索により、トロイの木馬化されたDLLに関連付けられたファイルハッシュがディスクに書き込まれているかどうかを識別できるかもしれません。これは、収集したイベントがエンドポイントデータモデルに書き込まれているかどうかに依存することに注意してください。

| tstats count from datamodel=Endpoint.Filesystem where 
Filesystem.file_name=*logoimagehandler.ashx* OR 
Filesystem.file_hash=C15abaf51e78ca56c0376522d699c978217bf041a3bd3c71d09193efa5717c71 
OR Filesystem.file_hash=75af292f34789a1c782ea36c7127bf6106f595e8 OR 
Filesystem.file_hash=56ceb6d0011d87b6e4d7023d7ef85676 groupby 
Filesystem.file_name Filesystem.file_path Filesystem.dest 
Filesystem.file_hash Filesystem.vendor_product Filesystem.user _time span=1s

Sysmonを実行している人は、EventCode 11 (FileCreate)を検索することで、DLLがディスクに書き込まれたかどうか、いつ書き込まれたかを判断するのにも役立ちます。

index=<index where endpoint data is stored> 
sourcetype=xmlwineventlog:microsoft-windows-sysmon/operational EventCode=11 
file_name=*logoimagehandler.ashx* 
| table _time host Image Computer TargetFilename

少なくとも、これら3つのハッシュ（SHA256、SHA1、MD5）を検索することで、お使いのSolarwinds Orionシステムにマルウェアが存在するかどうかを判断できるようになります。

SHA256: C15abaf51e78ca56c0376522d699c978217bf041a3bd3c71d09193efa5717c71
SHA1: 75af292f34789a1c782ea36c7127bf6106f595e8
MD5: 56ceb6d0011d87b6e4d7023d7ef85676

特定のプロセスで読み込まれているDLLを探している場合は、Sysmon Event Code 7 (Image loaded)を使用して、起動されているトロイの木馬化された.NET DLLを探すこともできます。

index=<index where endpoint data is stored>
sourcetype=xmlwineventlog:microsoft-windows-sysmon/operational EventCode=7 
(file_name=*logoimagehandler.ashx* OR 
SHA256=C15abaf51e78ca56c0376522d699c978217bf041a3bd3c71d09193efa5717c71 OR 
SHA1=75af292f34789a1c782ea36c7127bf6106f595e8 OR 
MD5=56ceb6d0011d87b6e4d7023d7ef85676)
| table _time Image ImageLoaded Computer

SentinelOne はまた、Supernova が .NET のインメモリコンパイルに使用しているのと同じ技術を使用した概念実証を開発したブログを公開しました。彼らは、CSC.exe と CVTRES.exe が実行中に子プロセスとして作成されることを確認しました。これは、SIEMでシグネチャとしてデプロイするための戦術ではなく、ハンティングをするための戦術であることを覚えておいてください。多くの .NET アプリがこれを行うことができるので、これは危険性の指標ではないことに注意したいのですが、.NET アセンブリがコンパイルされているかどうかを判断し、脆弱性のあるシステムでこの動作の直後に発生した追加のアクションを探すために、このような検索を実行する価値はあるかもしれません。

| tstats count from datamodel=Endpoint.Processes where
Processes.process_exec=cvtres.exe Processes.parent_process_exec=csc.exe 
groupby Processes.process_exec Processes.process_id Processes.process 
Processes.parent_process_exec Processes.parent_process 
Processes.parent_process_id Processes.dest Processes.user 
Processes.vendor_product _time span=1s

index=<index where endpoint data is stored>
sourcetype=xmlwineventlog:microsoft-windows-sysmon/operational EventCode=1 
CommandLine=*cvtres.exe* ParentCommandLine=*csc.exe*
| table _time CommandLine ParentCommandLine User host ProcessId ParentProcessId

Web shellはメモリ上に存在するため、Webやネットワークのトラフィックイベントのようなイベントでこれを見る機会が最も多いでしょう。Guidepointのブログ には、Stream for SplunkやBro/Zeekなど、httpやURIのファイル名やパラメータに関連する情報を含むデータセットで使用するための擬似的なクエリがいくつか掲載されています。エンドポイントデータがなくても、Webやネットワークのトラフィックデータがあれば、このような検索を出発点として利用することができます。前述したように、Splunk for Stream を使用していない場合、SPL は特定のデータソースに適合させることができます。

| tstats count from datamodel=Web.Web where
web.url=*logoimagehandler.ashx*codes* OR
Web.url=*logoimagehandler.ashx*clazz* OR
Web.url=*logoimagehandler.ashx*method* OR
Web.url=*logoimagehandler.ashx*args* groupby Web.src Web.dest Web.url
Web.vendor_product Web.user Web.http_user_agent _time span=1s

index=<index where network/web data is stored> sourcetype=stream:http 
(url=*logoimagehandler.ashx*codes* OR Web.url=*logoimagehandler.ashx*clazz*
OR Web.url=*logoimagehandler.ashx*method* OR
Web.url=*logoimagehandler.ashx*args*)
| table _time src_ip src_port dest_ip dest_port url transport status

| tstats count from datamodel=Web.Web where Web.http_content_type=text/plain
Web.dest=(insert your SolarWinds IP here, we are looking for inbound traffic)
Web.url=*logoimagehandler.ashx* groupby Web.src Web.dest Web.url
Web.vendor_product Web.user Web.http_user_agent _time span=1s

index=<index where network/web data is stored> sourcetype=stream:http
dest_ip=(insert your SolarWinds IP here, we are looking for inbound traffic) 
url=*logoimagehandler.ashx*
| table _time src_ip src_port dest_ip dest_port url transport status

Sunburstの後すぐに別の脆弱性とそれに関連した悪意のあるコードに対処することは、望ましい新年の始まりではないと思いますが、検出方法を提供させていただきます。

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