** 本記事は、Rapid Response: The Squirrelwaffle Incident Guide の翻訳です。最新の情報は英語記事をご覧ください。**
本記事は、インシデント対応担当者やセキュリティ運用チームが、広範囲で見られる脅威のツール、テクニック、行動を特定し、修復できるように、ソフォスの Rapid Response チームが作成した段階的なインシデントガイドのシリーズの一部です。
Squirrelwaffle とその攻撃手法
Squirrelwaffle は、悪意のある Office 文書として、スパムキャンペーンで配布されるマルウェアローダーです。Squirrelwaffle は、被害者の環境における最初の攻撃拠点と、他のマルウェアを配信してシステムに感染させるための経路を攻撃者に提供します。受信者が Squirrelwaffle に感染した文書を開きマクロを有効にすると、一般的に Visual Basic スクリプトが悪意のあるファイルやスクリプトをダウンロードして実行し、攻撃者にコンピュータのさらなるコントロールを与えてしまいます。
また、Squirrelwaffle のオペレーターは、DocuSign を使用してユーザーを騙し、Office 文書でマクロを有効にさせようとします。
Squirrelwaffle 攻撃では通常、標的となった組織に属する従業員の社内外の連絡先にスパムメールが送信され、マルウェアがさらに拡散されます。多くの場合、Qakbot (Qbot) や Cobalt Strike のクラック版など他のマルウェアもインストールされ、ランサムウェアのような深刻な攻撃につながる可能性があります。
Squirrelwaffle 攻撃は基本的に、ProxyShell 脆弱性の悪用によって Microsoft Exchange サーバーが侵害された結果として実行されます。
Microsoft Exchange のバックエンドへのアクセスが設定されているため、これまで Squirrelwaffle のキャンペーンで見られた手口では、クライアントのユーザーやロールに対する検出可能な変更が保証されないようです。しかしこのアクセスによって、外部からの脅威は、Exchange Web Services (EWS) に対する不正な SOAP (Simple Object Access Protocol) リクエストを使用して、電子メールメッセージを抽出したり、返信したりすることが可能になります。
いくつかのケースでは、悪意を持って作成されたメールボックスに「ApplicationImpersonation」のロールが追加されていることが確認されており、サーバーサイドリクエストフォージェリ (SSRF) 攻撃によって EWS のみを介して動作しているように見えるものもあります。
インシデントガイドの背景
本ガイドでは、ネットワークで検出された Squirrelwaffle を含むインシデントの調査および緩和策のみを取り上げます。未対応の Web シェル、または ProxyLogon や ProxyShell 脆弱性などが悪用された結果として、さらなる内部的なラテラルムーブメントが検出された場合は、徹底したインシデント対応を行うことを推奨します。
さらに、本ガイドでは、Sophos XDR の「Live Discover」や「Live Response」などの機能を用いて、防御側が取るべき手順を説明しています。Sophos XDR を使用していない場合でも、OSQuery などの他のツールを利用できるセキュリティ専門家であれば、それぞれのニーズに合わせて情報を応用することができます。
本ガイドで言及されているクエリやコマンドは、インシデント対応時に Sophos Rapid Response チームが使用した手法の一部です。これらはあくまで推奨事項であり、各タスクを遂行する方法は他にもあります。
アイテムの削除を指示する PowerShell やコマンドラインは、正規のクライアント設定が誤って削除されないように、ダブルチェックする必要があります。
調査
本セクションの目標は、ProxyShell または Squirrelwaffle に関連する IoC (セキュリティ侵害の痕跡) があるかどうかを確認することです。
Exchange のバージョンを確認する
まず、現在ネットワークに悪用可能な Microsoft Exchange サーバーが存在するかどうかを確認する必要があります。そのためには、すべてのExchange サーバーのバージョンとパッチレベルを確認する必要があります。
Sophos XDR のユーザーは、新しい Live Discover クエリを作成して実行できます。Live Discover に不慣れで方法が分からない場合は、まずヘルプガイドを参照することを推奨します。Live Discover のヘルプガイド
- まず、 Sophos Central にログインし、Threat Analysis Center から Live Discover に進む
- [Designer Mode (デザイナーモード)] を有効にする
- [Create new query (新規クエリ作成)] を選択する
- クエリの名前と詳細を設定し、保存するカテゴリとして [Live Endpoint] を選択する
- Rapid Response の Github ページから SQL の詳細をコピーする
- クエリを保存する
このクエリをネットワーク全体に対して実行するか、Exchange サーバーに対してのみ実行するかを選択できます。その結果、オンラインの Exchange サーバーのバージョン番号が表示されます。これらのサーバーがどのくらい古いかは、こちらのリンクから確認できます。
どのバージョンに脆弱性があるかについての詳細は、
「Microsoft Exchange における ProxyShell の脆弱性と対策」を参照してください。
過去の悪用事例を探す
Exchange にパッチを適用することで、ProxyShell のさらなる悪用から保護することができます。しかし、すでに悪用されている場合は、サーバーにマルウェアが存在し、攻撃者がリモートアクセスできる可能性があります。次のステップでは、過去に ProxyShell を悪用された形跡がないかどうかを確認します。
方法 1 – マルウェアイベント
最近検出されたマルウェアを確認します。
Sophos XDR をご利用のお客様は、以下の手順で確認できます。
- Sophos Central にログインした状態で、[Logs & Reports (ログとレポート)] から [Events (イベント)] ページにアクセスする
- 検索ボックスに任意の Exchange サーバー名を入力する
- ドロップダウンリストから過去 90 日間を選択する
- [Malware (マルウェア)] 以外のチェック項目をすべて外す
- [Update (更新)] をクリックする
- 検出された項目の名前と場所を確認する
Web シェルやその他の脅威の検出リストは常に変化しています。検出された脅威について疑問がある場合は、コミュニティフォーラムからお問い合わせください。
緊急のサポートが必要な場合は、Rapid Response Service をご覧ください。
Web シェルの検出例:
- マルウェア検出: ‘CXmal/WebAgnt-A’(C:\inetpub\wwwroot\aspnet_client\qgifbeskzqoybayx.aspx ファイル)
- マルウェア検出: ‘Troj/ASPDoor-Y’ (C:\inetpub\wwwroot\aspnet_client\qjocyhdfmrmmlycf.aspx ファイル)
- マルウェア検出: ‘Mal/Chopper-A’ (C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root\e22c2559\92c7e946\App_Web_web5oiz2.dll ファイル)
Web シェルが存在する可能性のある、Exchange サーバーの悪用に関連する最も一般的な場所は、これらのフォルダとそのサブディレクトリです。
- C:\inetpub\wwwroot\aspnet_client\
- C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\
- C:\ProgramData\
- C:\Windows\Microsoft.NET\Framework64\
方法 2 – Exchange ログを確認する
もう 1 つの方法は、「MSExchange 管理」の Windows イベントログを見ることです。
以下のリンクにあるクエリを、上記と同じ方法で作成します。
Exchange サーバーでこのクエリを実行し、結果を調査します。最初に探すべきイベントの 1 つは「New-MailboxExportRequest」です。疑わしいケースは、ランダムな件名で「.aspx」ファイルを指していることが多いです。これらの .aspx ファイルは、Web シェルです。
これらのイベントやファイルが存在する理由は他にもあるかもしれないので、さらなる対処を施す前に必ず調査と検証を行ってください。上記と同様の結果が出た場合、Exchange サーバーが悪用された可能性が高いです。
同じデータを使って「New-ExchangeCertificate」の結果も見てみましょう。アプリケーションのなりすましのための管理ロールと新しいメールボックスの作成は、Squirrelwaffle 攻撃チェーンの一環です。おそらく「.aspx」へのリファレンスと、変更されるアカウントのユーザー名が表示されます。
別のイベントとして、次のようなものが見られるかもしれません。
これは、そのユーザーのメールボックス全体 (.pst ファイル) がエクスポートされたことを示しています。この例では、管理者のメールボックスですが、どのユーザーでも起こり得ます。このアクティビティは完全に正規のもので、管理者やバックアップソフトウェアによって行われる可能性があります。もし、攻撃者が背後にいる場合、ユーザーのメールに読み取り専用でアクセスすることができるようになります。これにより攻撃者は、後のフィッシングメールに悪用できる、被害者の組織に関する貴重な情報を手にできてしまいます。
また、下記のように表示されることもあります。
これは、アカウントに割り当てられている「インポート・エクスポート」のロールです。
方法 3 – 悪意のある HealthMailbox
HealthMailbox アカウントは、Microsoft Exchange の正規の仕組みであり、Active Directory で普通に見られるものです。しかし、ProxyShell の脆弱性の一部では、新しい HealthMailbox が作成されます。そのため、アカウントを手動で削除しなければ攻撃者がネットワークアクセスを維持するリスクもあるため、HealthMailbox の識別は重要です。
HealthMailbox を検出する最も良い方法は、Active Directory (AD) を利用することです。正規の HealthMailbox は、CN=Monitoring Mailboxes、CN=Microsoft Exchange System Objects に配置されます。他の OU または Active Directory グループに Healthmailbox が存在する場合は、疑わしいため確認する必要があります。
ドメインコントローラーから PowerShell を使用して、以下のコマンドを実行します。
- get-aduser -Filter “Name -like ‘*HealthMailbox*’” -Properties created | where {$_.DistinguishedName -notlike ‘*Monitoring*’} | fl
このコマンドは、HealthMailbox に似ていて DistinguishedName に「Monitoring」が含まれていないユーザーを AD に問い合わせます。もし、何らかのアカウントが返ってきた場合、それらは疑わしいものであり、悪意のあるものである可能性が高いです。
Active Directory にアクセスできない場合、完全な方法とは言えませんが、これらのアカウントを探す方法はいくつかあります。
1 つ目は、アカウントを作成したコマンドを必要とします。これは、MSExchange 管理イベントログに「New-Mailbox」コマンドレットが発行された形で記録されているはずです。正規の HealthMailbox はシステムによって自動的に作成され、これらのログでコマンドが発行されたり追跡されたりすることはありません。時間が経過している場合、ログがイベントを上書きしている可能性があることに注意してください。この情報は、直接 PowerShell や Live Discover で取得することができます。
PowerShell の例:
Get-WinEvent -LogName ‘MSExchange Management’ | where {$_.Message -like ‘*New-Mailbox,*’ -and $_.Message -like ‘*HealthMailbox*’} | fl
Live Discover:
2 番目の方法は、信頼性が低く、HealthMailbox の名前と OSQuery の Logon_Session テーブルを使用することに依存しています。Windows と Active Directory がアカウントを処理する方法によって、アカウントにはそれぞれ名前を定義できる複数の側面があります。ここで使用するものは、Active Directory とローカルアカウント情報に分かれています。
Active Directory のアカウントは DistinguishedName (DN) 、SAMAccountName (SAM)、UserPrincipleName (UPN) を使用することができます。正確性は、DN、UPN、SAM の順に高くなっています。先に述べたように、DN はフルネームと、そのアカウントが AD でどのように構成されているかを示します。UPN は、グループ化されていないフルネームを表示し、OSQuery の Logon_Session テーブルと組み合わせて、疑わしい HealthMailbox を見つけることができます。
注意すべき点は、ソフォスのエージェントが存在していた時間の長さによって、悪意のある HealthMailbox と正規の HealthMailbox の両方が、このテーブルにログが記録されたりされなかったりするログインアクションを実行する可能性があることです。
イベントが記録されている場合、正規の HealthMailbox は名前の末尾に 32 文字の文字列を含んでいます。悪意のある HealthMailbox は 7 文字の文字列しか確認されていません。UPN フィールド (ユーザー名ではない) が短いバージョンであることを示すログオンイベントは、さらに調査されるべきです。この情報は Live Discover で収集することができます。
分析
本セクションでは、Exchange に関連する IoC が悪用されているのを確認した場合に、Web シェルがまだ存在するかどうかを特定し、攻撃者の行動をさらに調査するためのいくつかの方法を説明します。
潜在的な Web シェルを特定する
この時点で、過去に Exchange サーバーに作成された Web シェルの名前と、フォルダーパスは確認済みであると考えます。
下記のクエリを作成して実行します。
このクエリは、悪用された Exchange サーバーで最も一般的に見られる場所にある .aspx ファイルを検索します。
.aspx ファイルが見つかっても、それが Web シェルであると限らないことに注意してください。検証する場合は、そのファイルのコピーを samples@Sophos.com にメールすることをおすすめします。Exchange サーバーには正規の .aspx ファイルが存在する可能性があります。
また、攻撃者が以前にサーバーにアクセスしたことがある場合、元の Web シェルが検出されたりサーバーにパッチが適用されたりした場合に、他の Web シェルやサーバーへのさらなるアクセス手段を作成している可能性がある、と理解しておくことも重要です。
不正なエクスポート要求、管理ロール、アプリケーションのなりすましを特定する
この攻撃の一部には、アカウントのパーミッションの変更が含まれます。このアクティビティを特定して修正する必要があります。そうしないと、以前に削除した Web シェルが再作成されてしまいます。
Exchange サーバーで PowerShell セッションを開始し、以下のコマンドを実行します。
- Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn
次に、メールボックスのエクスポートリクエストのキューを表示します。
- Get-MailboxExportRequest | Select-Object -Property FilePath,Mailbox,Name,RequestQueue,WhenCreatedUTC,WhenChangedUTC,Status
次に、「ApplicationImpersonation」を用いて、管理ロールを表示します。
- Get-ManagementRoleAssignment -Role “ApplicationImpersonation” | Select-Object -Property Name,Role,RoleAssigneeName,WhenCreated
そして最後は、「メールボックスのインポート・エクスポート」を使った管理ロールです。
- Get-ManagementRoleAssignment -Role “Mailbox Import Export” | Select-Object -Property Name,Role,RoleAssigneeName,WhenCreated
この結果、キューに残っているメールボックスのエクスポート要求と、未承認のインポート・エクスポートロールが表示され、ProxyShell および ProxyLogon エクスプロイトから以前に削除した Web シェルを再作成することができます。
未承認のアプリケーション偽装権限は、新しいアカウントが別のユーザーの代わりに行動することを可能にする Squirrelwaffle アクティビティに起因するものです。
疑わしいコマンドを探す
IIS ログ
攻撃者がサーバーにて、リモートでコマンドを実行する能力を得た場合、それらが最初に表示される場所の 1 つは、IIS (Internet Information Services) のログです。下記のクエリを使用すると、これらのログの場所と名前を特定することができます。
このクエリは 3 つのパス変数をサポートしていますが、おそらく「path1」を使用して、下記の値を入力するかと思います。
- C:\inetpub\logs\LogFiles\%\%%
使用しない変数については、下記のような、結果を返さない値を入力すれば問題ありません。以下は参考例です。
次のような結果が得られると思います。
以下のクエリで、これらのログファイルの内容を Grep することができます。Grep は、ログファイルの文字列をリモートで検索し、一致する行をログに戻す機能です。
ここでの最善の方法は、調査の初期に確認した .aspx ファイル名のいずれかを検索することです。
例:
もし結果が得られなかったら、他のログファイルや他の .aspx ファイル名を確認するようにしてください。もし結果が得られた場合、以下のように表示され、人間でも読むことはできますが、初見では難しいかもしれません。
このデータを CSV にエクスポートして「行」の列をコピーすると、CyberChef などのサイトを利用して、これを見やすくすることができます。
この CyberChef の recipe をご活用ください。 https://gchq.github.io/CyberChef/#recipe=URL_Decode()Find_/_Replace(%7B’option’:’Regex’,’string’:’%5E’%7D,’%5C%5Cn’,true,false,true,false)Syntax_highlighter(‘auto%20detect’)
この例では、下記のコマンドを見ます。
- Whoami
- Quser
- Tasklist
これらは、攻撃者がアクセスについてより多くの情報を収集するために使用する可能性がある、一般的な検出コマンドです。
PowerShell ログ
ProxyShell 攻撃や Squirrelwaffle 攻撃に共通するもう 1 つの特徴は、Microsoft PowerShell を使用してコマンドを実行することです。Exchange サーバーで正規の目的のために実行される PowerShell の量が多いため、これらのログを確認するのは簡単な作業ではありません。
このクエリは、PowerShell ログから情報を取得し、潜在的に疑わしいコマンドを識別することを試みます。
注: 発見された PowerShell コマンドのほとんどは、疑わしい (sus) とマークされたものを含め、正規のものである可能性が高いです。これらは手動で確認する必要があり、PowerShell の予備知識が必要になります。
以下の例では、Windows Defender のリアルタイム保護を無効にするために PowerShell が使用されていることがわかります。
対応策
パッチ
まず最初に行うべきことは、Exchange サーバーに最新のパッチがインストールされているかを確認することです。バージョンと Microsoft がリリースした日付の一覧は、こちらで確認できます。
悪意のある HealthMailbox を削除する
次のステップは、ハント段階で決定された通り、インシデント中に作成された不正な HealthMailbox やその他の疑わしいメールボックスを削除することです。
被害を受けた組織がメールボックスを自ら削除し、完全な可視性を確保することが最善です。未承認のメールボックスは、管理者ドメインアカウントも削除する必要があります。 メールボックスを無効にするだけでは、AD アカウントは保持されます。
上記の実行は簡単です。Exchange サーバーで、PowerShell を開き次のコマンドを実行します。
- Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn
これにより、現在の PowerShell セッションに Exchange コマンドレットが追加されます。次に以下のコマンドを実行します。
- Remove-Mailbox -Identity “<Name of malicious Healthmailbox>” -Permanent $true
これにより、メールボックスと AD ユーザーアカウントが完全に削除されます。
「-Permanent $true」は任意ですが、これを付けずに実行すると、メールボックスは切断されるだけで、メールボックスのデータベースに 30 日間 (保存期間が設定されている場合はその期間）残ってしまいます。
Exchange GUI からもこの操作を行うことができますが、メールボックスに対して単に [Disable (無効化)] ではなく [Delete (削除)] を選択する必要があります。
MailboxExportRequest を削除する
その後、キューに残っている MailboxExportRequest のうち、調査の段階で特定された正規でないものを削除する必要があります。可能であれば、履歴に残っている古い「Completed (完了)」と「Failed (失敗)」のリクエストも削除してください。
サードパーティのインシデント対応者は、被害者にこれらのリクエストを削除するよう依頼し、完全に可視化できるようにするのが理想的です。必要であれば、PowerShell からリクエストを削除することができます。
「完了」ステータスのすべてのリクエストを削除します。
- Get-MailboxExportRequest -Status Completed | Remove-MailboxExportRequest
「失敗」ステータスのすべてのリクエストを削除します。
- Get-MailboxExportRequest -Status Failed | Remove-MailboxExportRequest
単一の ID に対するリクエストを削除します。
- Remove-MailboxExportRequest -Identity “<Request Identity>”
注: 各コマンドの最後に 「-Confirm:$false”」を付けると、削除の確認を省略できます。このコマンドを使用する前に、意図した通りに削除されていることを確認してください。
未承認の管理ロールを削除
調査中に特定された未承認の管理ロールを削除する必要があります。
(Exchange には、これらのロールを使用するロールの割り当てが組み込まれています。削除を提案する前に、作成されたロールを確認する必要があります。)
サードパーティのインシデント対応者は、被害者にこれらのロールを削除するよう依頼し、完全に可視化できるようにするのが理想的です。必要であれば、PowerShell からロールを削除することができます。
単一の管理者ロールを削除します。
- Remove-ManagmentRoleAssignment “<ROLE NAME>”
注: 各コマンドの最後に 「-Confirm:$false”」を付けると、削除の確認を省略できます。 このコマンドを使用する前に、意図した通りに削除されていることを確認してください。
この時点で、予防策としてすべてのユーザーのパスワードをリセットすることをおすすめします (攻撃チェーンは、追加のイベントが発見されない限り、アカウントの侵害の兆候を示しません) 。これは、Squirrelwaffle メールの受信者が、将来的に EWS を通じて抽出されたコンテンツに基づく、スピアフィッシング攻撃の標的にされる可能性があるからでもあります。
Squirrelwaffle や Exchange の脆弱性、Web シェルに関連するアクティビティがさらに見られる場合は調査を行い、必要であればサードパーティのインシデント対応のサポートを受けることをおすすめします。
ソフォスは、本レポートへの貢献に対して、Sophos Rapid Response チームの Matthew Everts、Stephen McNally、Vikas Si の各位に謝意を表します。
コメントを残す