ConnectWiseは、攻撃者が侵害されたアプリケーション認証情報を使ってMicrosoft 365テナントにアクセスしたことを受け、Cloud Backup環境にひも付く7つのアプリケーションIDを無効化した。
Huntressは10月16日までに、162のテナントで不正なサインインを確認した。その中には、別のConnectWiseアプリケーションがグローバル管理者の権限を取得し、他のアプリに新たな認証情報を追加したケースも1件含まれている。
ベンダー側からのアクセスは封じ込められたが、Microsoft 365管理者にとってインシデントは終わっていない。影響を受けたアプリケーションを無効化しても、攻撃者がテナント内にすでに作成した可能性のあるロール変更、認証情報、メールボックスルール、同意付与、その他の永続化手段が元に戻るわけではない。
最新のCloud Backupのセキュリティガイダンスで、ConnectWiseはパートナーに対し、自社の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。
Microsoft独自の侵害されたアプリケーションへの対応プレイブックでは、アプリケーションIDが侵害された可能性がある場合、サービスプリンシパルのサインイン、予期しない認証情報、特権付きアプリケーションロール、通常とは異なる権限変更を確認するよう推奨している。
この幅広い調査が重要なのは、元のConnectWise認証情報を削除しても、攻撃者が侵入後に作成した別の認証情報、ロール割り当て、アクセス経路までは削除されないからだ。
CoreViewでセキュリティ戦略担当バイスプレジデントを務めるKasper Lindgaard氏は、サインインの成功が確認された場合、影響を受けたConnectWiseアプリケーションが無効化されているかどうかを確認するだけでなく、対応範囲を広げるべきだと述べた。
「脅威アクターによるサインインの成功を示す兆候が少しでもあるなら、インシデントは設定変更インシデントとして扱うべきです。つまり、10月1日から10月17日07:00 UTCまでの間に行われ、正当性を確認できない変更をすべて明確に洗い出し、元に戻す必要があります。
Lindgaard氏は次のように付け加えた。
「ConnectWiseは攻撃を阻止しました。しかし残念ながら、脅威アクターがMicrosoft 365の設定を変更していないか、あるいはテナント内に永続化を確立していないかを確認する責任と困難な作業は、企業側にあります。ITリーダーの3分の1超が、Microsoftが設定を自動的にバックアップしていると誤って考えており、そのため、このような攻撃からの復旧は一段と難しくなります」
つまり管理者には、公開されたIPアドレスを検索するだけでなく、テナントの変更前と変更後を比較できる状態が必要だ。アプリケーションへのサインイン成功に続いて、新しいシークレット、特権ロール、メールボックスルール、同意付与、ポリシー変更のいずれかが行われていれば、元のアプリケーションを停止した後もアクセス経路が残る可能性がある。
まだアプリケーションを再接続しないこと
ConnectWiseは、正式な復旧および再認証の手順を公開するまで、影響を受けた接続を無効のままにしておくよう求めている。
管理者は、不要な削除を行う前に、利用可能なログも保存すべきだ。ConnectWiseは、初期調査の間はエンタープライズアプリケーションをそのまま残し、設定と識別子を証拠として利用できる状態にしておくよう具体的に助言している。
このインシデントは、長期間維持されるアプリケーションアクセスのより広範な弱点も浮き彫りにした。組織はますます、非人間ID、つまりサービスプリンシパル、アプリケーションID、API認証情報、自動化エージェントなどを、人間のアカウントと同じように管理しなければならなくなっている。
こうしたIDには、明確な所有者、最小権限のアクセス許可、認証情報のローテーション、実用的なログ、定期的なレビューが必要だ。同じ管理策を、機密性の高いクラウド環境への恒常的なアクセスを保持するSaaSベンダーに対する通常のサードパーティーリスク管理にも組み込むべきである。
ConnectWiseの顧客が直ちに行うべき作業は、より限定的だ。証拠を保存し、関連するサービスプリンシパルのサインインをすべて特定し、アクセスが行われた期間中の変更を調査し、永続化を排除する。そしてConnectWiseが再接続して安全だと判断するまで、影響を受けたアプリケーションを無効のままにしておく。
関連記事：TeamFiltrationのハッカー、放置されたMicrosoft 365サービスアカウントを悪用は、非人間IDがクラウド環境への見落とされがちな経路を生み出した別の事例。