** 本記事は、Windows services lay the groundwork for a Midas ransomware attack の翻訳です。最新の情報は英語記事をご覧ください。**
更新(2022-01-28): ZTNA 設定を通じてネットワーク上のデバイスの管理を強化する仕組みを説明するため、本文を一部修正しました。
2021 年 12 月に発生した、ある IT ベンダーに対する攻撃において、少なくとも 2 種類の商用リモートアクセスツールとオープンソースの Windows ユーティリティが悪用されました。この攻撃は「Midas」と呼ばれるランサムウェアを利用したものでした。
ソフォスの Rapid Response チームの分析により、ネットワーク上のドメインコントローラーや他のコンピューターに初めてこのランサムウェアが出現した時点より少なくとも 2 か月前から攻撃者がネットワーク上で活動していた痕跡が発見されました。
被害を受けた組織は Citrix を使用して全従業員の端末を仮想化していましたが、組織のネットワークは階層化されていませんでした。組織のネットワーク全体には VPN を通じてのアクセスが可能であり、仮想マシンのハイパーバイザーとして動作する Windows Server 搭載機が、物理デバイスの大部分を占めていました。分割されていない単純なネットワークは、ランサムウェア攻撃のリスクを高めます。ゼロトラストネットワークアクセス (ZTNA) 設定をしていれば、たとえ組織のマシンに攻撃の下地が作られた後でも、攻撃者がラテラルムーブメントを行ったり、リソースにアクセスしたりするのを阻止できたかもしれません。
この攻撃では、侵入先のサーバーに配置した PowerShell スクリプトを一台ずつ実行するように設計された Windows サービスが繰り返し作成されました。作成されたサービスは、他のマシン (VM またはサーバー) から、SMB を介して確認できます。ZTNA を導入し、アクセスコントロールを適切に設定しておけば、侵害されたサーバーが攻撃者により別のサーバーへの侵害に利用されることや、ハイパーバイザー同士が相互に作用、あるいはお互いをリソースとして利用することは防げていた可能性があります。
被害を受けた組織は、他社製のエンドポイント保護製品を利用してサーバーを保護していましたが、ネットワークへの侵入を示す警告は表示されませんでした。攻撃者は、コマンドの実行、内部 RDP 接続、すでにインストールされている市販のリモートアクセスソフトウェアの利用、クラウドへのデータのアップロード、組織のドメインコントローラーとのファイルのやり取りなどを 2 か月にわたって行いました。2021 年 12 月に実行されたランサムウェアの展開は、その最終段階でした。
ログデータが不足しているため、攻撃者が最初にどのようにドメインコントローラーにアクセスしたのか、およびどのようにそのマシンの Administrator アカウントを侵害し、権限を得たのかは不明なままです。しかし、一旦アクセスに成功すると、攻撃者はアカウントの権限 (およびネットワークの開放構造) を利用して、ネットワーク上のマシンにバックドアおよびランサムウェアを続けて拡散しました。
外部ツールの利用
Midas は通常、最近流行している他のランサムウェアほど大きな脅威ではありません。しかし、攻撃者は今回のインシデントにおいて、よくあるランサムウェア攻撃の手法を踏襲したようです。今回の攻撃では標準の Windows 管理ツールやプロセス (PowerShell や Deployment Image Servicing and Management ツールなど)、およびマルウェアとして検知されにくい商用リモートアクセスツール (AnyDesk や TeamViewer) が活用されました。これらのツールを使ってネットワーク内を水平移動し、組織のネットワークからファイルを流出させたと見られています。
今回の事例では、被害を受けた組織の IT スタッフは以前に AnyDesk や TeamViewer などのリモートアクセスツールをテストした後、使わずに放置していたそうです。残念ながら、攻撃発生時にはこれらのツールがまだ一部のサーバーにインストールされたままでした。攻撃者はこの状況を利用したようです。
また、攻撃者がオープンソースツール「Process Hacker」を導入および使用し、被害を受けた組織がシステム保護のために使用していたエンドポイント保護製品を特定して終了させたことも報告されています。
最も早い日付のセキュリティ侵害の痕跡 (IoC) は 10 月 13 日のものでした。侵害されたドメインコントローラーのうちの 1 台のログに、被害を受けた組織の内部ネットワーク上のマシンとドメインコントローラーとの間でリモートデスクトッププロトコル (RDP) 接続が行われたことが記録されています。この RDP 接続へのログインは、2 台の異なるマシンから Administrator アカウントを利用して行われました。攻撃者がドメインコントローラーへの RDP 接続に使用した 2 台の内部マシンへのアクセス権をどのように取得したかは不明です。
攻撃の初期段階は 10 月 13 日から 11 月 2 日にかけて行われ、その後、3 週間後の 11 月 22 日までは活動が見られませんでした。最近のランサムウェア攻撃で、攻撃者がこれほど長くネットワーク上に留まる事例はまれです。しかし、このような事例がまったくないわけではありませんし、今回の事例では実際にそうなっています。
攻撃者による Process Hacker の使用が成功したのは一部だけです。11 月 25 日、サンクスギビングデーには一部のマシンが組織のサーバー上での Mimikatz 認証情報収集ツールの使用を検知し、ブロックしたからです。しかし、攻撃者はブロックされる前日に別のサーバーで Mimikatz の実行に成功していたことが調査の結果判明しました。侵害されたサーバーをフォレンジック調査したところ、収集された認証情報の一部を含んだ Password.txt というファイルが発見されました。
PowerShell による攻撃の制御
今回の攻撃は細工された PowerShell スクリプトに大きく依存しています。いくつかの例ではこのスクリプトは Windows サービスとしてインストールされ、実行されていました。また、攻撃は DISM.exe を通じて Visual Basic Script と Batch ファイルを実行することで制御されていました。DISM.exe は本来破損または故障した Windows の機能を修復するために利用されるユーティリティです。
攻撃者はネットワークに接続していた最初の 1 週間の間に、被害を受けた組織内の多くのマシンへのアクセス権を獲得しました。彼らは侵入した複数のマシンの TEMP ディレクトリにさまざまな PowerShell スクリプトをアップロードし、アクセス可能な他のマシン上に Windows サービスを作成しました。その後、ネットワーク経由でスクリプトを呼び出し、他のマシン上でホストされているスクリプトを実行していました。
PowerShell スクリプトの多くはランダムなファイル名を使用していましたが、いくつかのファイル名には、その動作を示す部分が含まれています。たとえば、DISM ツールを使用してバックドアをインストールしたサーバー上で実行されるスクリプトには「dism_els.ps1」という名前がついていました。このスクリプトは最初の実行から 20 分後に2 台目のサーバーで再度実行されました。また、「adtest.ps1」という名前のスクリプトはサーバーのドメイン管理者権限を得ているかどうかの確認に使用されたと考えられます。
攻撃者は、1 件のタスクを構成するために、不自然なほど複雑にスクリプトを組み合わせていました。たとえば、ある PowerShell スクリプトがバッチファイルを実行し、そのバッチファイルが PowerShell スクリプトを起動し、その PowerShell スクリプトが DLL サイドロードツールを起動するコマンドを実行して、悪意のある DismCore.dll ペイロードをシステムプロセスに挿入する、という構造を取っているものがありました。Visual Basic Script が PowerShell を起動し、その PowerShell が DISM を呼び出して DismCore.dll をロードするバッチスクリプトを起動する、という例も複数確認されています。使われるファイルは 4 文字、8 文字、または 12 文字のランダムな英数字で構成されています。PowerShell スクリプトの中には、デフォルトの .ps1 ではなく、.log というファイル拡張子が使用されているものがあります。
いくつかのスクリプトでは、ファイル拡張子がまったく使用されていませんでした。
攻撃者は几帳面にも、10 月 13 日から 19 日にかけて異なるマシンでまったく同じ処理を繰り返し、被害を受けた組織のネットワーク上の多くのサーバーにバックドアを仕掛けました。しかし、19 日に突然接続と活動を停止すると、11 月 2 日に再開するまで潜伏していました。
11 月 2 日に、攻撃者はさらに 2 台のデスクトップ機にログオンし、サービスの作成と PowerShell の実行を繰り返しました。この際に、攻撃の初期段階において侵入されたあるサーバーにおいて AnyDesk が 13 回使用された痕跡が残っています。この挙動が確認されたあと、さらに 3 週間の間、活動は停止しました。
サンクスギビングデーの「お祝い」
攻撃者は 11 月 22 日に作業を再開し、新たにサービスをインストールしました。さらに、インストールしたサービスを利用して、以前に侵入したネットワーク内の他のマシン上の Powershell スクリプトを実行しました。
22 日には特定の PowerShell スクリプトが 1 回実行されただけでしたが、その翌日には他の 3 台のマシンにさらにサービスがインストールされ、それらのサービスを使用して PowerShell スクリプトが実行されました。
11 月 25 日に、侵害されたドメインコントローラーのうち 1 台が、ローカルストレージの C:\Compaq\!logs\ というパスに Password.txt というファイルを書き出したことがログに記録されています。しかし、被害を受けた組織のアンチウイルスソフトが別のサーバー上で動作している Mimikatz を検出したのは、その日の夜中過ぎでした。25 日から 29 日にかけて他にも多くの内部 RDP 接続が行われましたが、その後攻撃者は身を隠したため、追跡は困難です。
攻撃の最終段階
それから 1 週間以上後の 12 月 7 日 (被害を受けた組織の現地時間)、攻撃者は組織のネットワーク上のマシンにランサムウェアのバイナリを展開し始めました。バイナリファイルは C:\hp\ というパスにドロップされ、そのファイル名には被害を受けた組織の名前が含まれていました。このディレクトリには、攻撃者により Process Hacker のコピーも保存されていました。
その後、攻撃者は作成したサービスの下で、KProcessHacker3 という名前で Process Hacker を実行しました。Process Hacker は、数週間前に Mimikatz の実行を妨げたアンチウイルスソフトを終了させるために実行されたと見られています。
また、攻撃者が計 46 プロセス、216 サービスの名前を検知して停止させるのに使用した PowerShell スクリプトコマンドの復元に成功しました。停止されるサービスには、MSSQL、各種バックアップツール、業務用アプリケーション、および McAfee、Kaspersky、Trend Micro、ソフォスなどのセキュリティソフトウェアに関連するサービスなどが含まれています。サービスやプロセスを停止させるスクリプトには複数の冗長なリストが含まれていました。このことは、攻撃者がリストの項目を手作業で追加していること、および項目の重複をチェックしていないことを示しています。
プロセスを停止させた後、攻撃者は local.exe、および share.exe ( の部分には被害を受けた組織の名前が入っていました) のコピーを組織内サーバーに移動し、実行しました。
この作業は、ネットワーク上の他の複数のサーバーで繰り返し行われました。作業とはすなわち、Process Hacker の実行に使用される Windows サービスをインストールし、その数分後に 2 件のランサムウェアのバイナリをコピーして実行することです。攻撃者は、この作業をゆっくり、1 時間に 1 度ほどのペースで行いました。
その後、同日 (12 月 8 日) 中に、被害を受けた組織の従業員がランサムノート (およびサーバーが正常に機能していないこと) を発見し、Rapid Response チームに連絡を取りました。
被害を受けた組織にとっては幸いなことに、被害は少数のサーバーに留まりました。Rapid Response チームの協力の元、組織全体のマシンにソフォスのエンドポイント保護ツールがインストールされました。保護ツールは攻撃者がさらに DISM と Process Hacker を使用し、ネットワーク上の他のマシンに追加でランサムウェア実行ファイルを展開しようとしたのを検出し、ブロックしました。
事件の教訓
今回の Midas ランサムウェア攻撃は、PowerShell スクリプトを実行するために新しい Windows サービスをインストールする段階に大きく依存しています。インストールされたサービスは、ランダムな文字と数字の組み合わせで命名されており、一見して不審なものでした。しかし、被害を受けた組織はサービスの作成や、サーバー間のラテラルムーブメントについて、ネットワーク上のコンピューターを監視していませんでした。
また、今回の攻撃は、被害を受けた組織が通常業務で使用していない RDP とサードパーティのリモートアクセスツールの両方に大きく依存していました。今回の事例では、侵入されたマシンには少なくとも 14 種類のオープンソースまたは商用のリモートアクセスツールが一旦インストールされた後放置されていたことが確認されています。言うまでもなく、このことは悪用の危険性を高めます。放置されていたツールのうちの 1 つは、攻撃者が最初に社内のコンピューターにアクセスするために利用された可能性があります。したがって、一旦インストールしたリモートコントロールツールであっても、あまり頻繁に利用していない場合は、マシンから完全にアンインストールすることが推奨されます。
正規のツールが正当に使われているか、あるいは不正に使われているかをエンドポイント保護製品が判断するのは困難です。そのため、本来悪意のないプログラムや Windows 管理ツールによる異常な活動の監視を、IT セキュリティチームが行うことが必要です。アプリケーションの許可リストを作成することで、攻撃者が悪用できるツールをさらに制限することができます。
私たちの従来のアドバイスは、ここでも当てはまります。被害を受けた組織が組織内のサービスやマシンに多要素認証を使用し、ネットワークを複数のエリアに分割してアクセスを制限していれば、攻撃はより困難だったでしょう。たとえ完全に攻撃を防げなくても、攻撃者の士気を削ぐことができれば、その努力と計画は有意義です。
検出とガイダンス
ソフォス製品は、悪意のある DISM の使用を DynamicShellcode エクスプロイトとして検出しますが、悪意のないファイルに対する誤検出は行いません。Process Hacker ユーティリティは、潜在的に不要なアプリ (PUA) として検出され、Midas ランサムウェアのバイナリは Troj/Ransom-GLY として検出されます。攻撃に利用される他のコンポーネントは、それぞれ Troj/PSInj-BI (PowerShell スクリプト)、Troj/MSIL-SDB (悪意のある dismcore.dll)、Harmony Loader (PUA)、および ATK/sRDI-A (sRDI DLL サイドローディングツール) として検出される可能性があります。
SophosLabs は、この攻撃に関連するセキュリティ侵害の痕跡 (IoC) の一部を SophosLabs の Github に公開しています。なお、被害を受けた組織の特定を防ぐため、本記事とスクリーンショットでは組織名を示す部分が編集されています。
SophosLabs は、攻撃の分析への貢献について、Rapid Response チームの Jason Jenkins に謝意を表します。
コメントを残す