ラピッド サイバー攻撃の一種、Petya の概要

本記事は、Microsoft Secure ブログ “Overview of Petya, a rapid cyberattack” (2018 年 2 月 5 日 米国時間公開) を翻訳したものです。

3 回シリーズの 1 回目のブログ記事では、ラピッド サイバー攻撃がどのようなもので、実行と結果の観点から他の攻撃とどう異なるかについて紹介しました。今回は、Petya (別名 NotPetya) 攻撃の詳細に触れていきます。

Petya の仕組み

Petya の攻撃チェーンはよく知られていますが、まだいくつかの小さな謎が残っています。以下が、Petya のキル チェーンの 4 つのステップです。

図 1: Petya 攻撃の仕組み

1. 準備 – Petya 攻撃は MEDoc アプリケーションの侵害から始まりました。各企業がアプリケーションを更新すると、Petya コードが起動されました。

2. 侵入 – MEDoc の利用者がソフトウェア更新をインストールした際に、企業のホスト上で Petya コードが実行されて、企業内で増殖を始めました。

3. 横断 – Petya マルウェアは、2 つの方法を用いて横断活動を行いました。

• 悪用 – SMBv1 (MS17-010) の脆弱性を悪用。
• 資格情報の盗難 – 現在ログオン中のアカウント (サービス アカウントを含む) を偽装。
• Petya は、アクティブなセッションにログオンしているアカウント (例えば、LSASS メモリに読み込まれた資格情報) のみを対象としました。

4. 実行 - その後、Petya はマシンを再起動し、暗号化プロセスを開始しました。画面上のテキストにはランサムウェアと表示されていましたが、このマルウェアには個別のキーを生成して、それを中央サービスに登録する技術的な対応機能 (復旧を可能にする標準的なランサムウェアの手順) がなかったため、明らかにデータ消去を意図している攻撃であったといえます。

Petya の未知の要素と独自の特徴

Petya は結果的に広範囲に影響を及ぼしましたが、それが意図されていたかどうかは不明です。しかし、次の特徴から高度な攻撃者が作成した攻撃であると考えられます。

• Petya 攻撃ではシステムのイベント ログが消去されましたが、その後、ドライブ自体が消去されたため、この動作は “不要” なものでした。これが標準的なフォレンジック対策の動作 (高度な攻撃グループではよく見られる) なのか、Petya が他の攻撃活動や操作を隠ぺいしようとしていたのかは未だ不明です。
• Petya のようなサプライ チェーン経由のアプローチを取るためには、攻撃スキルや能力に対して高レベルの投資を行う、十分な資金を持つ攻撃者である必要があります。サプライ チェーン攻撃は増加傾向にありますが、攻撃者が企業環境に侵入する経路の割合としては少なく、実行にはさらに高度な知識が不可欠です。

Petya による横断と増殖活動

私たちの観測では、Petya は MS17-010 の脆弱性の悪用よりも、ID 偽装のテクニックによって感染が拡大したという結果が出ています。これは、各組織が WannaCrypt 攻撃とそれが世間で注目されたことに対応して MS17-010 を展開し、緊急の修正プログラム適用の取り組みを進めたためであると考えられます。

Petya による攻撃は、標的型データ盗難攻撃で頻繁に発生する横断的な活動の緩和に関するよくある誤解を再燃させました。脅威アクターが横断的な活動に必要な資格情報を入手した場合は、PowerShell や WMI などの実行手段を無効にしても攻撃を ブロックすることはできません 。正規のリモート管理には少なくとも 1 つのプロセス実行手法の有効化が必要なため、効果的なチョークポイントにはならないのです。

図 2: Petya 攻撃の感染拡大方法

上の図では、横断的な活動には 3 つの技術的なフェーズがあることを示しています。

第 1 フェーズ: 標的の設定 - 次に攻撃/感染するマシンを特定する。

Petya の標的設定メカニズムは、通常のワーム動作と一致していました。しかし、Petya には独自の “革新” があり、サーバーや DC から DHCP サブネット構成内で標的とする IP アドレスを取得し、感染の拡大を加速させました。

第 2 フェーズ: 特権の取得 - 標的のリモート マシンを侵害するために必要な特権を取得する。

Petya ならではの特徴として、脆弱性の悪用に加えて、資格情報の盗難を自動化して感染拡大のために再使用することが挙げられます。前述したように、私たちが調査した攻撃で用いられた増殖方法は、偽装のテクニックによるものがほとんどでした。これが、SYSTEM のコンテキスト (コンピューター アカウント) および標的のシステムにログインしていたその他のアカウント (サービス アカウント、管理者、および標準的なユーザーを含む) の偽装につながりました。

第 3 フェーズ: プロセスの実行 - 侵害したマシンでマルウェアを起動する手段を取得する。

このフェーズでは防御策に重点を置くことは推奨しません。以下にその理由を挙げます。

1. 正規の資格情報 (または偽装したセッション) を持つ攻撃者 (またはワーム) は、別のプロセス実行手段を簡単に利用することができる。
2. IT 運用部門によるリモート管理では、少なくとも 1 つのプロセス実行手段が利用可能となっている必要がある。

これらの理由により、組織における急速な破壊攻撃および標的型データ盗難攻撃の両方の対策として、 プロセス実行フェーズ (3) でのブロックに重点を置くのではなく 、 特権の取得フェーズ (2) の緩和に対して注力すること を強くお勧めします。

図 3: Petya の増殖方法はそのほとんどが偽装 (資格情報の盗難) によるもの

Petya が 2 つのチャネルによる増殖のアプローチをとっていたため、エンドポイントの 97% に対して MS17-010 の修正を適用した組織においても企業規模での感染が発生しました。つまり、1 つの経路に対する緩和策だけでは十分ではないのです。

朗報としては、Petya は一般に普及した攻撃手法を再利用しているだけであるため、資格情報の盗難に対する防御策 (修正の適用およびその他の防御策も同様) への投資が、標的型データ盗難攻撃を未然に防ぐ対策に直接的に良い影響を与えることです。

攻撃と復旧エクスペリエンス: Petya から学んだこと

影響を受けた組織の多くは、災害復旧計画でこのような種類の障害に対する準備をしていませんでした。現実世界におけるラピッド サイバー攻撃の事例から学んだ主要なポイントは、以下のとおりです。

図 4: ラピッド サイバー攻撃からの復旧で学んだこと

オフラインでの復旧が必要となった - Petya に影響を受けた組織の多くでは、バックアップ用のアプリケーションとオペレーティング システム (OS) の展開システムが攻撃によって破壊され、事業運営の復旧が大幅に遅れました。いくつかの例では、復旧プロセスの文書を保存しているサーバーも停止していたため、IT スタッフは印刷された文書に頼らざるを得ませんでした。

連絡手段が使用不可になった - 多くの企業で、電子メールなどの標準的な会社の連絡手段が使用できない状態になりました。ほとんどすべての企業において、従業員への連絡は WhatsApp、配信テキスト メッセージのコピー/貼り付け、携帯電話、個人のメール アドレス、および Twitter などの代替手段に依存していました。

いくつかの組織で、Office 365 のインスタンスは十分に機能していましたが (SaaS サービスはこの攻撃の影響を受けなかった)、ダウン中のオンプレミス Active Directory (AD) に認証がフェデレーションされていたため、ユーザーは Office 365 のサービスにアクセスできませんでした。

追加情報

ラピッド サイバー攻撃の詳細と対策については、オンデマンド ウェビナーを参照してください。 Protect Against Rapid Cyberattacks (Petya, WannaCrypt, and similar).

ラピッド サイバー攻撃を緩和するためにマイクロソフトが推奨していることを説明する次のブログ投稿 (3 回シリーズの最後の投稿) にご期待ください。