ハッカーがMicrosoft 365(M365)内の見落とされがちなマシンアカウントを悪用し、チリの組織から企業データを窃取していることが分かりました。
どの組織のM365環境にも、人間に紐づくアカウントはもちろん存在しますが、それだけでなく共有の機能アカウントや、アプリケーション・自動化プロセスに属するアカウントも存在します。個人アカウントについては本人がその管理責任を負いますが、こうした非人間アカウントを誰が把握し、維持し、保護しているのでしょうか。十分な注意が払われなければ、こうしたアカウントは管理の目が行き届かなくなり、デフォルトの認証情報や過剰な権限を持ったまま忘れ去られた遺物と化してしまいます。
米カリフォルニア州サンディエゴで開催されたProofpoint Protect 2026において、Proofpointの研究者らは、チリの組織のM365環境への侵入を試みる、これまで知られていなかった脅威アクターの存在を明らかにしました。このアクターはオープンソース(OSS)ツールキットと基本的なパスワードスプレー攻撃を用いましたが、標的組織のいずれにおいても従業員アカウントへの侵入には一件も成功しませんでした。その代わりに侵入の鍵となったのが非人間アカウントであり、これによって窃取する価値のある多様な機密データへのアクセスを獲得していたのです。
チリで確認されたM365侵害
「TeamFiltration」と呼ばれる手法は、組織のM365環境をハッキングする最も手軽で安易な方法の一つです。5年前に開発され、「Taking a Dump in the Cloud」という奇抜なタイトルのDEF CON 30講演で一般公開されたTeamFiltrationは、オールインワン型のオープンソース(OSS)M365ハッキングキットです。倫理的なハッカーであれ悪意あるハッカーであれ、これをM365テナントに向ければ、含まれるアカウントを列挙し、IPブロックを回避するためインフラをローテーションさせながら総当たり攻撃を仕掛けることができます。さらにこのツールは、接続されたMicrosoftアプリケーション全体にわたる大規模なデータ窃取やバックドア設置も可能にします。
Proofpointが現在UNK_CondorFiltrationとして追跡している脅威アクターは、7月21日からTeamFiltrationキャンペーンを開始しました。当初はチリの大手銀行2行に関連する数百件のM365アカウントを探りました。その1週間後には、同国の3番目の金融機関を標的に数千件のアカウントを調査しています。しかし、これらの試みはいずれも大きな成果には至らなかったようです。
数週間の静穏期間を経て8月半ば、この脅威アクターは第3波となるTeamFiltration攻撃を再開しました。今回は全砲門をチリの大手小売企業という単一の標的に向け、7件の企業アカウントの侵害に成功しています。
突破口となったのは、新しいツールや手口ではありませんでした。28の異なるM365テナントにまたがる5,700件を超えるアカウントを対象としたキャンペーンにもかかわらず、UNK_CondorFiltrationは依然として従業員アカウントを一件も突破できていませんでした。しかし今回は、この小売企業がおそらく存在を忘れていた、あるいはそもそも把握していなかったと思われる7件の機能アカウント・サービスアカウントを特定していたのです。
これらのアカウントには、アクティブな利用履歴が一切ありませんでした。誰もログインしたことがなく、何らかの操作を行うために使われたこともありません。チケット管理や取引先への支払い承認といった業務機能のために作成されながら、そのまま忘れ去られていたようです。おそらくデフォルトの、あるいは共有された認証情報を使用しており、多要素認証(MFA)による保護もなかったとみられます。実際、脅威アクターはわずか7分間で6件のアカウントを侵害しています。
初期アクセスを確保した攻撃者は、TeamFiltrationの自動窃取機能を用いてOutlook、Teams、OneDriveからメール、チャット履歴、ファイルを吸い出しました。少なくとも1件のケースでは、それにとどまらず、標的企業の仮想プライベートネットワーク(VPN)を探索し、M365管理ポータルとクラウドサービスを管理するAzureポータルの両方にアクセスし、SharePointファイルも閲覧していました。
非人間アカウントがリスクと化す理由
Proofpointの脅威リサーチ担当ディレクター、Yaniv Miron氏によれば、UNK_CondorFiltrationの被害者は決して特殊な例ではないといいます。同氏の説明によれば、どの組織でも「さまざまな目的のために数多くのサービスアカウントが作成されている」ものの、「その目的が不要になった際に、当該ユーザーをロックアウトまたは無効化する対応が徹底されていないケースが多い」とのことです。さらに悪いことに、「アカウントが正式な手続きを経ずに作成され、公式に文書化すらされていない場合もある」と同氏は付け加えます。その結果、本来であればこうした野放しのアカウントを保護できたはずの従業員自身が、その存在すら知らないという事態が生じているのです。
同氏は、こうした事態を防ぐ最善の方法として、たとえ自動処理のみを行うアカウントであっても、すべてのクラウドアカウントを必ず人間の従業員に紐づけることを挙げています。そうすれば少なくとも、そのアカウントに対して責任を負う個人が明確になります。それに加えて、組織はアカウントに有効期限を設定することで、管理が行き届かないアカウントが少なくとも長期間放置されないようにできます。
とはいえ、組織が将来作成するアカウントを保護する前に、まずは既に社内に存在している可能性のある安全性の低いアカウントを棚卸しする必要があります。Miron氏は、既に脅威となっているアカウントを洗い出すために、管理者は組織の通常の命名規則に合致しないユーザー名を探し出すべきだとアドバイスしています。
「IT担当者やSOCチームのメンバーが、365内の全ユーザーを走査し、特定の命名規則に沿っていないアカウント名を洗い出すスクリプトを書けばよいのです」と同氏は述べます。「ランダムな名前を持つユーザーのほとんどは、その目的を確認する価値があるでしょう」
翻訳元: https://www.darkreading.com/cyberattacks-data-breaches/ghost-service-accounts-m365-data-theft-chile
