ConnectWiseは、攻撃者が侵害したアプリケーション認証情報を使ってMicrosoft 365テナントにアクセスした問題を受け、Cloud Backup環境に関連する7つのアプリケーションIDを無効化しました。
Huntressは、10月16日までに162のテナントで不正なサインインを確認したと発表しました。その中には、別のConnectWiseアプリケーションがグローバル管理者権限を取得し、他のアプリに新しい認証情報を追加した事例も含まれます。
ベンダー側のアクセスは封じ込められましたが、Microsoft 365管理者にとってインシデントは終わっていません。影響を受けたアプリケーションを無効化しても、ロールの変更、認証情報、メールボックスルール、同意の付与など、攻撃者がテナント内ですでに作成した永続化の仕掛けは元に戻らないからです。
ConnectWiseは最新のCloud Backupセキュリティガイダンスで、パートナーに対し、自社のMicrosoft 365環境に加え、管理するすべての顧客テナントを調査するよう求めています。古い、あるいは休止中のSkyKick接続があるテナントも対象です。
ConnectWiseがこれまでに確認した内容
ConnectWiseの10月19日付の状況更新によると、Cloud Backup、SaaS Security、Cloud Managementは、修復とセキュリティ検証が続くなか、引き続き停止されています。定期バックアップ、アーカイブへのアクセス、リストア、セキュリティ監視、一部の管理機能は利用できない状態で、復旧時期は確定していません。
ConnectWiseは、既存のバックアップアーカイブは暗号化され隔離された状態にあり、アクセスされた形跡はないとしています。ただし、これは顧客のMicrosoft 365テナントに影響がなかったという意味ではありません。
| 確認済み | 未解明 |
|---|---|
| 不正アクセスにConnectWiseのアプリケーションIDが使われた | ベンダーの元の認証情報が露出した経緯 |
| 影響を受けた7つのアプリケーションIDを10月17日に無効化 | 下流で影響を受けたテナントの総数 |
| Cloud Backup、SaaS Security、Cloud Managementを停止 | 個々の顧客テナントでデータにアクセスされたかどうか |
| ConnectWiseはバックアップアーカイブへのアクセスの形跡はないとしている | アクセスに成功したすべてのテナントで、攻撃者が永続化を確立したかどうか |
| HuntressがMicrosoft 365への不正サインインを確認 | 攻撃者の正体と動機 |
Huntressによると、攻撃者はエンドユーザーのパスワードを盗んだのではなく、Cloud Backupアプリケーション自体の認証情報を使って認証していました。Microsoftのサインインログには、この認証がクライアントアサーションとして記録されています。
このため、防御側が探すべきものも変わります。アプリ専用認証では、ユーザーが通常のサインインを行うわけではないため、ユーザーMFAは検証の対象になりません。アプリケーションは自身の認証情報で認証し、既存の権限が許す範囲のアクセスをそのまま得ます。
こうした権限は、OAuth認可モデルの一部です。組織はこの仕組みによって、利用者に繰り返しサインインを求めることなく、サードパーティのアプリケーションにクラウドリソースへのアクセスを許可しています。
Huntressはさらに、政策、国家安全保障、貿易、重要鉱物の各分野の16組織に対する第2波の試行も確認しました。その多くは影響を受けたConnectWise製品を利用しておらず、必要なサービスプリンシパルが存在しない環境では試行は失敗しています。
Microsoft 365管理者が今すぐ確認すべきこと
ConnectWiseは、10月13日以降のアクティビティを確認し、ログの保持期間が許せば10月1日までさかのぼって調査するよう推奨しています。
まず、ユーザーのサインインビューだけでなく、サービスプリンシパルのサインインを確認してください。Microsoftのサービスプリンシパルに関するドキュメントによると、これらのログには、証明書やクライアントシークレットなどの認証情報を使ったアプリケーション認証が記録されます。
確認すべきCloud BackupのアプリケーションIDは次のとおりです。
506e08f9-6e9a-4da4-942b-a099a03644ae
ConnectWiseは、不審なアクティビティに関連する3つのIPアドレスも公表しています。
144.172.64[.]128144.172.64[.]99144.172.64[.]60
一致が見つかった場合は調査を開始すべきですが、直ちにテナントが侵害されたと結論づけるべきではありません。
管理者は次の項目も確認する必要があります。
- 新規または変更されたアプリケーション認証情報
- ディレクトリロールおよび管理者ロールの割り当て
- アプリケーションの所有者と同意の付与
- フェデレーション信頼と認証設定の変更
- 条件付きアクセスなどのポリシーの最近の変更
- メールボックスの転送、受信トレイルール、トランスポートルール、委任アクセス
- 不審な期間中に変更されたその他のユーザーIDやアプリケーションID
Microsoft自身の侵害されたアプリケーション向けプレイブックも、アプリケーションIDが侵害された可能性がある場合、サービスプリンシパルのサインイン、想定外の認証情報、特権的なアプリケーションロール、通常とは異なる権限変更を確認するよう推奨しています。
こうした広範な確認が重要なのは、元のConnectWiseの認証情報を削除しても、攻撃者が侵入後に作成した別の認証情報、ロールの割り当て、アクセス経路は消えないためです。
CoreViewのセキュリティ戦略担当バイスプレジデント、カスパー・リンドガード氏は、サインインに成功した形跡があれば、影響を受けたConnectWiseアプリケーションが無効化されているかを確認するだけでなく、対応の範囲を広げるべきだと指摘します。
「攻撃者によるサインイン成功の兆候が一つでもあれば、このインシデントは構成変更インシデントとして扱うべきです。つまり、10月1日から10月17日午前7時（UTC）までの間に行われた、正当性を確認できない変更をすべて洗い出し、元に戻す必要があります。
リンドガード氏は次のように付け加えました。
「ConnectWiseは攻撃を止めました。しかし企業側には、攻撃者がMicrosoft 365の構成を変更したり、テナント内に永続化の仕掛けを残したりしていないことを確かめるという、困難な責務が残されています。IT部門のリーダーの3分の1以上が、Microsoftが構成を自動的にバックアップしていると誤解しており、こうした攻撃からの復旧はいっそう難しくなっています。」
つまり管理者には、公表されたIPアドレスを検索するだけでなく、テナントの変更前後を比較できる視点が必要です。アプリのサインインに成功した後で新しいシークレット、特権ロール、メールボックスルール、同意の付与、ポリシー変更が行われていれば、元のアプリケーションを停止した後もアクセス経路が残る恐れがあります。
アプリはまだ再接続しないでください
ConnectWiseは、正式な復旧および再認可の手順が公開されるまで、影響を受けた接続は無効のままにしておくよう求めています。
管理者は、不必要にログを削除する前に、利用可能なログを保全すべきです。ConnectWiseは特に、初期調査の間はエンタープライズアプリケーションを削除せずに残し、構成や識別子を証拠として利用できる状態にしておくよう助言しています。
今回のインシデントは、長期間有効なアプリケーションアクセスが抱える、より広範な弱点も浮き彫りにしました。組織は、サービスプリンシパル、アプリケーションID、APIの認証情報、自動化されたエージェントといった非人間IDを、人間のアカウントと並行して管理する必要性が高まっています。
こうしたIDには、明確な所有者、最小権限の設定、認証情報のローテーション、活用可能なログ、定期的な見直しが欠かせません。機密性の高いクラウド環境への常時アクセス権を持つSaaSベンダーについては、同じ統制を日常的なサードパーティリスク管理にも組み込むべきです。
ConnectWiseの顧客が当面すべき作業は、次のように絞られます。証拠を保全し、関連するサービスプリンシパルのサインインをすべて洗い出し、露出期間中の変更を調査し、永続化の仕掛けを除去します。そして、ConnectWiseが再接続は安全だと表明するまで、影響を受けたアプリケーションを無効のままにしておきます。
関連記事：TeamFiltrationのハッカーが、忘れられたMicrosoft 365サービスアカウントを悪用。非人間IDがクラウド環境への見過ごされた侵入経路になった、もう一つの事例です。
翻訳元: https://www.esecurityplanet.com/cloud-security/news-connectwise-cloud-backup-breach-microsoft-365/
