クラウドアカウント乗っ取りの検出：脅威調査リリース(2022年10月)

Splunk脅威調査チーム(STRT)は先日、3つの新しい分析ストーリー(Azure Active Directory Account Takeover、AWS Identity and Access Management Account Takeover、GCP Account Takeover)をリリースしました。セキュリティアナリストはこの分析ストーリーを使用して、一部の大規模なパブリッククラウドサービスプロバイダーを標的としたクラウドアカウント乗っ取り攻撃を検出できます。このブログ記事では、各クラウドプロバイダーで利用できるテレメトリと、そのデータをSplunkに取り込む際のオプションについて説明します。最後に、これらの分析ストーリーで利用できる検出方法をいくつかご紹介します。

クラウドのラボ環境を対象に行った攻撃のシミュレーションと、セキュリティチームがSplunkを使用してそれを検出する方法の詳細については、以下のビデオ(英語)をご覧ください。

はじめに

アカウント乗っ取り(ATO)はIDを標的とした攻撃であり、サイバー犯罪者はそれを足がかりに、パスワードスプレー攻撃、ソーシャルエンジニアリング、マルウェア感染、クレデンシャルスタッフィングなどさまざまな手法を使ってオンラインアカウントに不正アクセスを行います。この不正アクセスでは、実際のユーザーを装ってアカウントの詳細情報を変更したり、機密情報を盗み出したりといった悪質な攻撃が実行されます。場合によっては、1人の従業員のオンラインアカウントが侵害されただけで、標的となった組織内で攻撃者がアクセス権を拡大し、機密性の高い内部システムやアプリケーションを乗っ取ってしまうこともありす。

2022年にLapsus$グループによって実行されたいくつかのセキュリティ侵害では、このような攻撃が実際に行われたことが確認されています。これらの攻撃では、マルウェアを配布したり、コマンドアンドコントロールチャネルを使用して攻撃対象のネットワークを侵害したりといった従来の手法ではなく、ソーシャルエンジニアリングと認証情報の盗難を組み合わせて、機密情報や大企業への特権アクセスを手に入れることに成功していました。

クラウドアカウント乗っ取りの監視

クラウドアカウントの乗っ取りを効果的に監視するには、認証とアカウントアクティビティのテレメトリを取り込んでインデックスする必要があります。このテレメトリは通常、特定のクラウドプロバイダーが利用しているアイデンティティプロバイダーから取得できます。アイデンティティプロバイダーは、プリンシパルのID情報の作成と維持管理を行うほか、依存しているアプリケーションへの認証サービスも提供するシステムエンティティです。

このセクションでは、アマゾン ウェブ サービス(AWS)、Microsoft Azure、Google Cloud Platformで利用されているネイティブのアイデンティティプロバイダーについて概説します。また、これらのアイデンティティプロバイダーで利用可能なテレメトリと、そのデータをSplunkに取り込む際にセキュリティチームが使用しなければならないオプションについても説明します。

Azure Active Directory

Azure Active Directory (Azure AD)は、Microsoft社が提供するクラウドベースの企業向けIDおよびアクセス管理(IAM)サービスです。Azure ADは、Microsoft 365 (旧Office 365)やAzure Portalのようなサービスをはじめ、OAuthプロトコルを使用する多くのクラウドベースアプリケーションの認証の基盤となっています。Azure ADは、オンプレミスのActive Directory環境と同期させることも可能で、企業イントラネット内のアプリケーションのような内部リソースに対する認証機能も提供します。Microsoft社によると、Azure ADは12億以上のIDを管理し、1日に80億回を超える認証を行っています。

テレメトリとログ収集

Azure ADでは、3つのアクティビティログカテゴリが用意されています。アカウント乗っ取りで主に利用されるのはサインインと監査ログのカテゴリです。

Azure ADログをSplunkに取り込むには、Splunkbaseから入手できるSplunk Add-on for Microsoft Cloud Servicesを使用します。Splunk脅威調査チームが公式ドキュメントに従ってAttack Range環境とのインテグレーションの設定を行ったところ、その作業はわずか数ステップで完了しました。Splunk CloudのユーザーであればData Managerも利用できます。Data Managerに関しては、先頃Microsoft Azureデータソースのオンボーディングのサポートが発表されました。

AWS Identity and Access Management

Amazon Web Services (AWS) Identity and Access Management (IAM)は、ユーザー、AWSリソース、AWSサービス間のID認証および認可を可能にするサービスです。例えば、AWSのユーザーがAmazon Simple Storage Service (S3)上のファイルにアクセス、更新、または削除しようとした場合、そのユーザーリクエストはデフォルトのIAMによって確認されます。これによってそのリクエストを送信したユーザーが特定され、アタッチされたIAMポリシーでユーザーに付与されている権限に従ってリクエストを許可するか拒否するかが決定されます。これらのポリシーはIAMに不可欠で、すべてのユーザーとユーザーグループにアタッチされ、それぞれがどのリソースにアクセスできるかが明確に定義されています。

テレメトリとログ収集

AWS IAMのログを監視する主な方法は以下の3つです。

アカウント乗っ取りのユースケースでは、AWS CloudTrailログに注目します。AWS CloudTrailログは非常に情報量の多いデータソースであり、ログ形式も極めて詳細です。CloudTrailサービスは、セキュリティチームが脅威を調査する際に必要なログをすべて収集します。これらのログは、AWSアカウントのリスク監査、ガバナンス、コンプライアンスにも役立ちます。

CloudTrailは基本的にすべてのAPIアクティビティとAWSコンソールとのやり取りを記録します。これによって攻撃者を追跡したりAWSアカウントの不適切な設定を検出したりすることができ、AWS環境の保護に役立ちます。

AWSのログをSplunkに取り込むには、Splunkbaseから入手できるSplunk Add-on for Amazon Web Servicesを使用します。Splunk脅威調査チームが公式ドキュメントに従ってAttack Range環境でAWSアカウントからSplunkサーバーにCloudTrailログを収集する設定を行ったところ、その作業はわずか数ステップで完了しました。Splunk CloudのユーザーであればData Managerも利用できます。Data Managerに関しては、先頃AWSログのオンボーディングのサポートが発表されました。

Google Workspace

Google Cloudは、コンピューティング、ストレージ、ネットワーク、機械学習、アプリケーション開発のための各種クラウドサービスを提供しています。Google Cloudのリソースとやり取りを行うIDを管理するにはいくつかの方法があります。それにはGoogle Cloud Identity、Google Workspace、シングルサインオンをサポートするサードパーティ製インテグレーションなどがあります。

Google Workspace (GWS、旧GSuite)は、Gmail、カレンダー、Meetなどのコラボレーションツールや生産性向上ツールで有名です。一方、GWSはアイデンティティプロバイダーでもあり、管理者はこれを使用してユーザーやアクセスポリシーを管理できます。Splunkの調査によれば、GWSはGoogle Cloudのユーザーに最も使用されているアイデンティティプロバイダーです。

テレメトリとログ収集

Google Workspaceは、監査ログの包括的なリストを提供しています。アカウント乗っ取りのユースケースでは、Splunk Add-on for Google Workspaceを使用してAPIから取り込んだユーザーと管理者の監査ログを使用します。セキュリティチームは、GWSに影響を与える「データの保持期間とタイムラグ」について理解しておく必要があります。イベントによっては、Google管理コンソールでデータが使用可能になり、Splunkでインデックスが完了するまでに数時間かかる場合もあります。

Splunk脅威調査チームが公式ドキュメントに従ってAttack Range環境でGoogle Workspaceのテスト環境からSplunkサーバーにGoogle Workspaceアクティビティレポートデータのログを収集する設定を行ったところ、その作業はわずか数ステップで完了しました。Splunk CloudのユーザーであればData Managerも利用できます。Data Managerに関しては、先頃Google Cloud Platform監査ログのオンボーディングのサポートが発表されました。

これらのユーザー認証ログをSplunkに取り込むには、2通りの方法があります。

• Splunk Add-on for Google Workspace：このアドオンを使用すると、Google WorkspaceのAPIを使用してGoogle Workspaceのイベントデータを収集できます。これらのログは、Google監査レポートからの認証、パスワードの変更、2FAの登録などのユーザーのログイベントに基づいています。
• Splunk Add-on for Google Cloud Platform：管理者は、Google Cloud Platformとログを共有するようにGoogle Workspaceを設定し、Appの定義済みの入力を使用するか、Google Pub/Subを介してイベントを収集するようにSplunkでHECを設定することで、これらのログをSplunkに取り込むことができます。

Splunkの脅威調査チームが作成したアカウント乗っ取りの3つの分析ストーリー(クラウドプロバイダーごとに1つ)には、合計で27の検出方法が含まれ、MITRE ATT&CKの7つの技法と6つのサブ技法に対応しています。セキュリティチームはこれらの分析ストーリーを活用して、クラウドテナントに対する不審な挙動をリアルタイム監視や脅威ハンティングによって捕捉できます。

複数のクラウドプロバイダーで使用できる検出ルールの概要を以下の表に示します。詳細については、research.splunk.comで以下の分析ストーリーをご確認ください。

• Azure Active Directory Account Takeover
• AWS Identity and Access Management Account Takeover
• GCP Account Takeover

まとめ

Lapsus$によって実行されたセキュリティ侵害は、アカウント乗っ取りとID攻撃のリスク、それにともなう被害の可能性を浮き彫りにしました。Lapsus$の成功に触発されて、今後その他の攻撃者たちが同様のアプローチで企業を狙う恐れもあります。Splunk脅威調査チーム(STRT)では、パスワードポリシーや多要素認証といった一般的な防御対策と併せて、検出ルールによるアプローチも取り入れることを推奨しています。脅威を防御する上では、このような攻撃との関連を示す不審なアクティビティをすばやく検出して対応できる、効果的な監視機能を策定して導入する必要があります。

その他のリソース

セキュリティ関連の最新コンテンツは、SplunkbaseとGitHubからダウンロードできます。ご紹介した検出ルールは既に利用可能であり、Splunk Enterprise Securityの場合は製品に組み込まれたESCUアプリケーションアップデートプロセスで、Splunk Security Essentials (SSE)の場合は、APIアップデートで入手できます。

すべてのセキュリティコンテンツの一覧は、Splunkマニュアルのリリースノートに掲載されています。

フィードバック

ご意見やご要望がございましたら、GitHubから遠慮なくお寄せください。Slackチャネル「#security-research」にご参加いただくこともできます。SlackのSplunkユーザーグループへの招待が必要な場合は、こちらの手順に従ってください。

寄稿者

このブログ記事を執筆したMauricio VelazcoとBhavin Patel、このリリースに協力してくださったSplunk脅威調査チームのJose Hernandez、Teoderick Contreras、Rod Soto、Michael Haag、Lou Stella、Eric McGinnis、Patrick Bareiss(以上敬称略)に感謝申し上げます。

また、攻撃シミュレーション用のオープンソースツールを提供してくださったAtomic Red Team、Stratus Red Team、Beau Bullock氏にも感謝申し上げます。