丸太の指輪は嘘をつかない：一目瞭然の歴史的列挙

丸太はディフェンダーの親友としてよく知られています。これらはフォレンジックゴールド、異常検知シグナル、アカウンタビリティの宝庫です。セキュリティチームは、インシデントの再構築、アクティビティの監視、アラートのトリガーを頼りにしています。しかし、視点を変えたらどうなるでしょうか。攻撃者がログを脅威ではなく機会と見なしたらどうなるでしょうか。

見過ごされがちだったクラウドインフラストラクチャのログの不正利用の可能性を探ってみましょう。すべてのログエントリには、単なるイベントではありません。ソース IP アドレス、ID、リソース名、リクエストパラメータ、レスポンスコード、ユーザーエージェントなどが含まれます。防御側にとって、これらのフィールドはパンくずです。しかし、攻撃者にとっては、インテリジェンス、ピボットポイント、さらには秘密の通信チャネルにもなり得ます。

攻撃者がログを使用して列挙を行う方法について詳しく説明し、ログデータを分析することで ID、サービス、エンドポイント、リソース階層について学習します。このプレゼンテーションでは、実際のシナリオ、ライブデモ、またはシミュレーション (該当する場合) を順を追って説明し、ログを防御ツールから攻撃ベクトルに変えたときに、うさぎの穴がどれほど深くなるかを示します。最後に、防御側がこの種の悪用を検出する方法、避けるべき構成、ゼロトラストの観点からログへのアクセスと可視性を再考する方法など、実際的な緩和策を見ていきます。

ログは私たちのシステムのストーリーを伝えます。しかし、どんな良い話でもそうですが、味方であれ敵であれ、誰でも読むことができます。今こそ、デジタルツリーの輪が私たちの歴史だけでなく、私たちの秘密を語っているかもしれないということを考え始める時です。

クラウド環境へのログイン

クラウドプロバイダーが提供するサービスの量が膨大で、そのリソースを監視する必要があるため、クラウドプロバイダーで運用しているセキュリティエンジニアは、膨大な量のさまざまなログタイプとグループに直面することになります。すべてのサービスのほとんどすべてのリソースが、実行したアクティビティに基づいてログを生成します。クラウドプロバイダーの監査ログツールによって生成および管理されるもの、特に ID とアクセス管理を扱うものと、リソースによって特定の形式で生成され、クラウドストレージまたは特定のストレージおよびクエリサービスに保持されるものもあります。

以下の表は、AWS、Azure、および GCP のいくつかのログソースを示しています。繰り返しますが、これらは唯一のログタイプではなく、すべてのサービスとそのログのほんの一部にすぎません。

この調査に関しては、最も使用されているクラウドプロバイダーとして、AWS、Azure、GCPベースのインフラストラクチャのみを検討しますが、他のクラウドプロバイダーにも同じロジックを適用できます。

AWS

AWS 組織またはアカウント内のイベントを管理する 2 つの主なサービスは、AWS CloudTrail と AWS CloudWatch です。AWS CloudTrail は監査ログを保存および管理しますが、AWS CloudWatch は必要に応じてさまざまなログソースをマージ、クエリ、ダッシュボード化できるサービスです。

AWS の監査ログも管理するメインのログサービスは AWS CloudTrail です。AWS CloudTrail は AWS API に関連するイベントをログに記録し、AWS 組織またはアカウント内のすべての管理アクティビティを監視します。VPC フローログ、サーバーレス実行ログ、EC2 インスタンスメトリックス、Route53 関連ログなど、CloudTrail では保存も管理もされない他の種類のイベントも生成され、S3 バケットや CloudWatch に保存するように設定できます。CloudWatch にイベントを保存するとコストがかかりますが、イベントのクエリは簡単になります。

AWS クラウドトレイル

AWS CloudTrail は、AWS API を使用して実行されたイベントによってトリガーされたログを管理し、特定のエンドポイントから特定の ID によってアクセスされる ID、サービス、およびリソースに関する情報を含みます。CloudTrail ログはセキュリティ監査ログとして使用されます。これにより、セキュリティエンジニアは、アカウントまたは組織全体のリソースやサービスに対する ID のアクセスに関するアクティビティをモニタリングできます。以下のイベントは、IAM ユーザーを作成するための AWS CloudTrail イベントの例です。

AWS クラウドウォッチ

AWS CloudWatch は、AWS リソースまたは AWS に統合された他の関係者からログを収集して管理するサービスです。要するに、クラウドでホストおよび管理されるサービスは、オンプレミスで再利用されたサービスにすぎません。そこで、「クラウドは他人のコンピュータ」という引用が出てきます。以前のオンプレミスサービスと同様に、各サービスには独自のログ形式があり、必ずしも AWS ログ形式と互換性があるとは限りません。CloudWatch ログは、AWS がこれらのログに対して行うレスポンスです。あらゆるリソースからあらゆるログを収集して管理し、それらのイベントを特定のフィールドにフォーマットまたはカプセル化することで、管理者が管理しやすくアクセスしやすくなります。

以下のスクリーンショットは、Lambda 関数の実行開始から出力の取得までのログフローを示しています。

CloudWatch で管理できるすべてのログが CloudWatch によって管理されるわけではありません。リソースが作成されると、作成者はログを CloudWatch に送信するか S3 バケットに送信するかを選択できます。後者の方が安価ですが、ユーザーは CloudWatch が提供するダッシュボードなど他の機能を使用できなくなります。Lambda 関数などの他のリソースでは、作成時にデフォルトで CloudWatch ロググループが作成されます。

アズール

Azure では、3 つの主要ライセンスに分かれた複数のサービスを提供しています。

• Azure サブスクリプションこれには、IaaSおよびPaaSソリューションによるクラウドインフラストラクチャの導入と管理を可能にするすべてのサービスが含まれます
• M365 サービス、メールサーバー、ファイルストレージ、エンドポイントとクラウドセキュリティ、DLPなどのユーザー関連タスクの管理に使用されるSaaSソリューションを提供します。
• エントラ IDは、ユーザー、グループ、アプリ、サービスプリンシパル、それらのロール、ID プロバイダー関連のタスクを含む、クラウド内の IAM を管理します。

Azure では、いくつかのタイプのロググループを有効にして管理する必要があります。

Azure (ブロードプラットフォーム/Azure モニター)

• アクティビティログ (プラットフォーム/コントロールプレーンイベント) サブスクリプション/管理グループ/テナントレベルのイベント (リソースの作成、ロールの変更、デプロイの失敗、サービスの状態)。コントロールプレーンの操作の監査に使用されます。
• リソースログ (以前は「診断ログ」) Azure サービス (ストレージ、NSG フロー、アプリケーションゲートウェイアクセス/ファイアウォールなど) によって発行されるリソースごとの操作ログ。各サービスは独自のリソースログカテゴリ/スキーマを公開しています。
• 指標 リソースから出力される数値時系列測定値 (CPU、1 秒あたりのリクエスト数、レイテンシー)。ログとは異なりますが、ログと一緒に取り込まれることがよくあります。

マイクロソフトエントラ ID (Azure AD) ID プラットフォームログ

EntraID イベントは診断設定で管理され、管理者は保存するログタイプと保存方法を選択できます。イベントは次の場所に保存できます。

• ログ分析
• ストレージアカウント
• イベントハブにストリーミング配信
• 任意のパートナーソリューションに送信 (通常は Azure を通じてサービスとして提供されます)

ログタイプには、監査ログ、サインインログ、プロビジョニングログ、ネットワークおよびリスク関連のイベントが含まれます。

• 監査ログ -ユーザーの作成、グループの変更、ポリシーの更新など、Entra IDテナントに対して行われた管理アクションと変更を記録します。
• サインインログ -ログインの成功、失敗、場所やデバイスなどの認証の詳細を含む、インタラクティブなユーザーログイン試行をキャプチャします。
• 非対話型ユーザーログインログ -トークンの更新など、ユーザーによる直接の操作なしに、ユーザーに代わってアプリケーションが実行した自動サインインを追跡します。
• サービスプリンシパルのログインログ -Azure リソースにアクセスするサービスプリンシパル (アプリケーションおよび管理対象 ID) の認証アクティビティを記録します。
• 管理対象 ID サインインログ -サービスへの認証を行うAzureマネージドIDのサインインイベントを具体的にログに記録します。
• プロビジョニングログ -アカウントの自動作成や同期など、Entra IDと接続アプリケーション間のユーザーおよびグループのプロビジョニングアクティビティを文書化します。
• ADFS サインインログ -Entra IDとの連携時に、Active Directoryフェデレーションサービス（ADFS）からのサインインイベントをキャプチャします。
• リスクの高いユーザー -Identity Protection によって検出された異常な行動や侵害された認証情報に基づいて、危険と判定されたユーザーを一覧表示します。
• ユーザーリスクイベント -認証情報の漏洩、匿名IPの使用、旅行が不可能なシナリオなど、ユーザーに対する特定のリスク検出について詳しく説明します。
• ネットワークアクセストラフィックログ -マイクロソフトのグローバルセキュアアクセス（旧Entra Private/Internet Access）を流れるネットワークトラフィックを記録します。
• リスキー・サービス・プリンシパル -侵害の可能性があるとフラグが立てられた、または疑わしい行動を示しているサービスプリンシパルを特定します。
• サービスプリンシパルリスクイベント -異常なログインパターンや認証情報の漏洩など、サービスプリンシパルの特定のリスク検出を文書化します。
• エンリッチドオフィス365監査ログ -追加のEntra IDコンテキストとエンリッチメントデータにより、Office 365監査イベントが強化されました。
• マイクロソフトグラフアクティビティログ -Microsoft Graph API を介して行われた API 呼び出しと操作を追跡して、モニタリングとセキュリティ分析を行います。
• リモートネットワークヘルスログ -グローバル・セキュア・アクセス環境におけるリモート・ネットワーク接続の状態と接続状態を監視します。
• ネットワークアクセスアラート -マイクロソフトのグローバルセキュアアクセスサービスによって生成された脅威検出用のセキュリティアラートが含まれています。
• ネットワークアクセス接続イベント -グローバル・セキュア・アクセス・ネットワーク・トンネルを介して個々の接続イベントとセッションを記録します。
• Microsoft サービスプリンシパルサインインログ -マイクロソフトのファーストパーティサービスプリンシパルと内部アプリケーション専用のサインインアクティビティを記録します。
• Azure AD グラフアクティビティログ -従来の Azure AD Graph API (非推奨、マイクロソフトグラフの前身) に対して行われた API 呼び出しを追跡します。
• ネットワークアクセスジェネレーティブAIインサイト -グローバル・セキュア・アクセスにおけるネットワーク・アクセス・パターンとセキュリティ体制について、AIが生成した洞察と分析を提供します。

マイクロソフト 365/Office 365 (監査ログとサービスログ)

Microsoft 365/Office 365には、プラットフォーム全体のユーザーアクティビティ、管理アクション、サービスレベルのイベントをキャプチャするさまざまなログが用意されています。これらのログを理解することは、コンプライアンス、セキュリティ調査、および運用監視にとって重要です。以下に、主なログタイプの概要と、Microsoft 365 エコシステムにおける各ログの適用範囲を示します。

• 統合監査ログ (マイクロソフトパービュー監査) Exchange、SharePoint/OneDrive、Teams、Azure AD/Entra、Power BI、Defenderなどのアクティビティを集約する中央監査ストア。Microsoft 365全体のユーザー/管理者のアクションを検索するために使用されます。リテンション/機能はライセンス (E5 と他の SKU) によって異なります。
• オンラインログの交換/交換
  
  • メールボックス監査ログ メールボックスの所有者/代理人/管理者のメールボックスのアクティビティ (メッセージの読み取り、送信先、フォルダへのアクセス)
  • エクスチェンジ管理者監査ログ 管理者による変更は Exchange 管理センターまたはコマンドレットで実行されました。
  • メッセージトレース/トランスポートログ メッセージ配信とルーティング用のメールフローレコード。
• SharePoint/OneDrive 監査イベント ファイル/フォルダへのアクセス、共有、同期、管理上の変更 (Unified Auditに表示)
• チーム監査イベント チャネル/ファイル/チャット/チームメンバーの変更、ミーティング、ポリシーの変更（Purview Auditで確認可能）。
• セキュリティ製品ログ Defender for Office 365/Defender for Endpoint /Microsoft 365 Defenderは、独自のアラート、検出、テレメトリを作成します（多くの場合、コンプライアンス/セキュリティセンターと統合監査/アラートストリームに統合されています）。

GCP

Azure と同様に、Google はクラウドデプロイメントのインフラストラクチャ側を含む Google Cloud Platform (GCP) と、メール、DLP、Google ドキュメント、ドライブなどのユーザー関連サービスを含む Google Workspace を提供しています。そのため、実行されるアクティビティの種類に応じて、それぞれに異なる種類のログが生成されます。

GCP 監査ログ (コントロールプレーンイベントとデータプレーンイベント)

グーグルクラウドプラットフォーム (GCP) すべてのサービスのアクティビティ、システム、データ、セキュリティイベントをキャプチャする Cloud Logging による統合ロギングを提供します。主なカテゴリは次のとおりです。 監査ログ管理アクションとデータアクセスアクションを記録します。

• 管理アクティビティログ: コントロールプレーン操作 (リソースの作成/更新/削除)。常に有効。
• システムイベントログ: ユーザーに代わる Google システムによるアクション（自動スケーリング、メンテナンスなど）。常に有効。
• データアクセスログ: データプレーンの読み取り/書き込み（クラウドストレージからのオブジェクトの読み取り、BigQuery へのクエリなど）。ボリュームの都合上、明示的に有効にする必要があります。
• ポリシー拒否ログ: 組織のポリシー制約により拒否されたアクセスリクエストを記録します。

それぞれが GCP プロジェクト、組織、請求先アカウント、プロジェクトフォルダで生成および管理されるように設定されています。

   projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Factivity
   projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fdata_access
   projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fsystem_event
   projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fpolicy

   folders/FOLDER_ID/logs/cloudaudit.googleapis.com%2Factivity
   folders/FOLDER_ID/logs/cloudaudit.googleapis.com%2Fdata_access
   folders/FOLDER_ID/logs/cloudaudit.googleapis.com%2Fsystem_event
   folders/FOLDER_ID/logs/cloudaudit.googleapis.com%2Fpolicy

   billingAccounts/BILLING_ACCOUNT_ID/logs/cloudaudit.googleapis.com%2Factivity
   billingAccounts/BILLING_ACCOUNT_ID/logs/cloudaudit.googleapis.com%2Fdata_access
   billingAccounts/BILLING_ACCOUNT_ID/logs/cloudaudit.googleapis.com%2Fsystem_event
   billingAccounts/BILLING_ACCOUNT_ID/logs/cloudaudit.googleapis.com%2Fpolicy

   organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity
   organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access
   organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fsystem_event
   organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fpolicy

GCP プラットフォームログ

プラットフォームログ Google Cloud Platform では、ユーザーワークロードを実行するインフラストラクチャとサービスによって生成された運用データとパフォーマンスデータをキャプチャします。管理アクションやアクセスアクションに焦点を当てた監査ログとは異なり、プラットフォームログでは以下を可視化できます。 どうやって ネットワークトラフィック、コンピューティングアクティビティ、アプリケーションパフォーマンスなど、システムが動作します。例には以下が含まれます。 VPC フローログ ネットワークフローの場合、 ファイアウォールログ ルール施行のため、 ロードバランサーログ リクエストとレイテンシーの詳細、および クラウド NAT ログ 接続追跡用。これらのログは、パフォーマンスチューニング、トラブルシューティング、異常なトラフィックの急増や接続障害などの異常の検出に非常に役立ちます。プラットフォームログを Cloud Logging、BigQuery、SIEM にエクスポートすることで、組織は運用データをセキュリティやアプリケーションの洞察と関連付けて、フルスタックのオブザーバビリティを実現できます。

ログを使用してクラウド権限を列挙する

実行されたイベント、イベントを実行したID、ターゲットとなるリソースに関する情報を含むフィールドは多数あります。

• API コールを実行する ID のタイプ、ID、名前
• API コールを実行するクライアントのソース IP とユーザーエージェント
• この実行の対象となるリソース
• 入力パラメータと出力値
• イベントが許可されるか拒否されるか

監査ログを使用してリソースを列挙する

各クラウドプロバイダーの監査ログサービスには、保存期間とそれらのイベントを取得する方法があります。ログの種類とクラウドプロバイダーに応じて、最大 10 年間まで設定可能な GCP イベントの 30 日から、AWS と Azure の 90 日間 (後でクラウドストレージ (S3 バケットと Azure Storage) やログ分析サービス (CloudWatch または Log Analytics) などの他の場所に保存できます。

ログを一覧表示するには、特定の権限が必要です。

• 法律: クラウドトレイル:ルックアップイベント、保存されているイベントを一覧表示します
• Azure クラウド監査ログ:
  
  • マイクロソフト. オペレーショナル・インサイト/ワークスペース/検索/アクション: を実行します 検索クエリ Log Analytics ワークスペースに対してログデータを取得します。
  • マイクロソフト. インサイト/イベントタイプ/値/読み取り: 読み取り アクティビティログイベント サブスクリプションの場合（管理業務の監査証跡）。
  • Microsoft.Resources/サブスクリプション/プロバイダー/READ: リストまたは取得 リソースプロバイダー サブスクリプションで登録されています。
• ID 監査ログを入力: 監査ログ。すべて読む
• GCP: ロギング、ログ、エントリ、リスト: 特定のスコープの GCP 監査ログを一覧表示します

各監査ログには、イベントから取得できる情報がいくつかあります。

• イベントを実行した ID に関する情報: 各イベントには、API 呼び出しを実行する ID に関する情報が含まれます。
  
  • AWS CloudTrail ログでは、ID (IAM ユーザーまたはロール) (フィールド) のタイプと ID です。 クラウドトレイルイベント. ユーザ ID. プリンシパル ID)、および権限を実行するアイデンティティの ARN (フィールド CloudTrail Event.userIdentity.arn)
  • Azure アクティビティログでは、各イベントには 呼び出し元 フィールドには、コールを実行している ID の名前が含まれます。次に、内部に 主張 フィールドでは、フルネームが表示されます（クレームズ・ネーム) およびソース IP (.ipaddr）アイデンティティの。上の別のフィールド 主張、は http://schemas.microsoft.com/claims/authnmethodsreferencesには、コールを実行している ID の認証方法が一覧表示されます。
  • GCP 監査ログでは、 認証情報 には、通話をリクエストしたIDに関する情報が含まれます。
• 実行の対象となるリソース: リソースに影響する各イベント（作成、更新、リスト、取得）には、それらのリソースのリストが含まれます リソース フィールド。リソースが影響を受けない場合、フィールドは表示されますが空です。
  
  • AWS では、このフィールドは Resource と呼ばれ、影響を受ける各リソースのリソース名とタイプが含まれます。

[
      {
          "ResourceType": "AWS::IAM::User",
          "ResourceName": "bleonUser"
      },
      {
          "ResourceType": "AWS::IAM::User",
          "ResourceName": "AIDA***************"
      },
      {
          "ResourceType": "AWS::IAM::User",
          "ResourceName": "arn:aws:iam::012345678901:user/bleonUser"
      }
  ]

• Azure では、イベントにはリソースグループフィールド (リソースグループ名)、リソースタイプ (リソースタイプ) とリソース ID (リソース ID)

"resourceGroupName": "test-resource-group-name",
"resourceProviderName": {
    "value": "Microsoft.Resources",
    "localizedValue": "Microsoft Resources"
},
"resourceType": {
    "value": "Microsoft.Resources/subscriptions/resourceGroups",
    "localizedValue": "Microsoft.Resources/subscriptions/resourceGroups"
},
"resourceId": "/subscriptions/abcd1234-1234-4567-90ab-abcdef123456/resourceGroups/test-resource-group-name",

• GCP には resource というフィールドもあり、影響を受けるリソースに関する情報が格納されます。

"resource": {
  "labels": {
    "email_id": "bsidesnyc-test-account@my-project-12345-123456.iam.gserviceaccount.com",
    "project_id": "my-project-12345-123456",
    "unique_id": "108093650973646504873"
  },
  "type": "service_account"
},

• リソースを探すもう 1 つの場所は、API 呼び出しに必要な入力パラメーターと、正常に実行されたときに取得される出力情報です。これらのフィールドには、リソースだけでなく、ポリシードキュメントやタグなどの他のカスタム情報も含まれています。
  
  • AWS にはこの情報が保存されています リクエストパラメーター そして レスポンス要素:

"requestParameters": {
  "userName": "bleonUser"
},
"responseElements": {
  "user": {
    "path": "/",
    "userName": "bleonUser",
    "userId": "AIDA***************",
    "arn": "arn:aws:iam::012345678901:user/bleonUser",
    "createDate": "Aug 5, 2025, 8:02:49 PM"
  }
},

• Azure では、実行内容に応じて、イベントにはリクエスト本文があります (リクエストボディ)、リクエストパラメータを内部に含むレスポンスボディ (レスポンスボディ)、出力値とともに、両方またはどちらでもない。

"requestBody": "{\"id\":\"/subscriptions/abcd1234-1234-4567-90ab-abcdef123456/resourceGroups/test-resource-group-name\",\"name\":\"test-resource-group-name\",\"type\":\"Microsoft.Resources/resourceGroups\",\"location\":\"centralus\",\"tags\":{\"SomeKey\":\"SomeValue\"}",

"responseBody": "{\"id\":\"/subscriptions/abcd1234-1234-4567-90ab-abcdef123456/resourceGroups/test-resource-group-name\",\"name\":\"test-resource-group-name\",\"type\":\"Microsoft.Resources/resourceGroups\",\"location\":\"centralus\",\"tags\":{\"SomeKey\":\"SomeValue\"},\"properties\":{\"provisioningState\":\"Succeeded\"}}",

• GCP では、この情報は次の場所に保存されます。 要求 そして 応答 畑

"request": {
  "@type": "type.googleapis.com/google.iam.admin.v1.CreateServiceAccountRequest",
  "account_id": "bsidesnyc-test-account",
  "name": "projects/my-project-12345-123456",
  "service_account": {}
},

"response": {
  "@type": "type.googleapis.com/google.iam.admin.v1.ServiceAccount",
  "email": "bsidesnyc-test-account@my-project-12345-123456.iam.gserviceaccount.com",
  "etag": "MDEwMjE5MjA=",
  "name": "projects/my-project-12345-123456/serviceAccounts/bsidesnyc-test-account@my-project-12345-123456.iam.gserviceaccount.com",
  "oauth2_client_id": "108093650973646504873",
  "project_id": "my-project-12345-123456",
  "unique_id": "108093650973646504873"
},

• ソース IP フィールドによる API コールを実行する ID のソース IP アドレスと拡張によるジオロケーション: 「送信元IPアドレス」:「1.2.3.4"
• ユーザーエージェントを通じて特定のタスクを実行するために使用されているオペレーティングシステム、コンテキスト、またはツール: 「UserAgent」:「Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv: 141.0) Gecko/20100101 Firefox/141.0

権限の追加を確認して ID 権限を列挙する

各クラウドプロバイダーには、API を使用してアクセスできます。ID がタスクを実行できるようにするには、そのタスクにアクセスできる必要があります。サービス、リソース、または単純な API 呼び出しへのアクセスは、ロール (Azure と GCP の場合) とポリシー (AWS の場合) を通じて付与されます。

ID に権限が追加されると、イベントがトリガーされます。これらのイベントは通常、優先度の高い管理イベントと見なされるため、すべてのクラウドプロバイダーがログに記録します。

API 権限の追加とは別に、一部のリソースにはアクセスポリシーも含まれます。これらのポリシーは、サービスの他のリソースでタスクを実行するためのアクセス権を持っている場合でも、ID からサービスのリソースへのアクセスを許可または拒否します。

セキュリティログを繰り返し処理して ID 権限を列挙する

ID が API コールで持つ権限。各 API 呼び出しには、次の 2 つのフィールドがあります。 エラーコード そして エラーメッセージ。 エラーコード 実行が失敗した理由を示しますが、 エラーメッセージ エラーの説明が表示されます。API 呼び出しの実行が許可されない場合、フィールド エラーコード の値は アクセス拒否。

"errorCode": "AccessDenied",
"errorMessage": "User: arn:aws:iam::012345678912:user/attacker is not authorized to perform: iam:CreateUser on resource: arn:aws:iam::012345678912:user/someuser with an explicit deny in a service control policy"

もし エラーコード 値はそうではありません アクセス拒否、許可される可能性が高いです。また、CloudTrail のログは、イベント履歴と S3 バケットの両方から取得されると、最新のものから古いものの降順で並べられるため、ログを反復処理して各イベントの最新のエラーを確認できます。

• もし エラーコード 値は アクセス拒否、そのイベントが以前に許可されていなかった場合は、そのイベントが拒否されたことを意味します。
• もし エラーコード 値は アクセス拒否イベントが以前に許可されていた場合は、その許可が許可されていることを意味します。
• もし エラーコード 値はそうではありません アクセス拒否、そのイベントが以前に拒否されたことがなければ、許可が許可されているということになります。

この原則を知っていれば、1 回の API 呼び出しだけで、アカウント上の任意の ID を列挙できます。 クラウドトレイル:ルックアップイベント。

AWS CloudTrail ログを使用してアクセス権限を列挙することの欠点

この列挙手法を使用する場合の欠点は、権限が許可または拒否されてから実行に時間がかかることです。この問題は、イベントの生成後に権限が追加されたり取り消されたりした場合に発生します。これは頻繁に発生します。特に一時的な権限では、ID が特定の権限に特定の期間だけアクセスできるようになっています。攻撃者は、ターゲットの ID にはタスクを実行するためのアクセス権があると考えてイベントを取得しますが、実際にはアクセス権がありません。

ログインログを使用して ID を列挙する

ユーザーがクラウド環境にログインするたびに、サインインイベントがトリガーされます。ログには、ログインしたユーザーに関する情報が含まれます。

• ID ログイン
• ソース IP
• 認証メカニズム (SSO、フェデレーション、MFA を使用している場合)
• 一部にはユーザーエージェントが含まれている可能性があります

クラウドプロバイダーのサインインログを読み取る権限を持つ攻撃者は、以下を取得する可能性があります。

• 使用している ID 名と認証メカニズム (MFA を含む) のリスト
• 有効または無効な ID のリスト
• サインインが失敗した理由のリスト
• アイデンティティの発信元となる可能性のある場所のリスト
• ID が使用する IP のリスト。

AWS サインインイベント

AWS では、マネジメントコンソールにアクセスするためのさまざまな方法を提供しています。

• AWS ユーザーログインプロファイル。ログインプロファイルを持つユーザーはマネジメントコンソールにログインし、それを通じてアカウントの GUI アクセスを取得できます。
• サインイン URL を作成する IAM ユーザーフェデレーション認証情報 (ここで説明したように)
• AWS Identity Center からログインすると、ユーザーは認証情報または IDP を使用してログインし、ロールがユーザーに関連付けられます。これにより、管理コンソールでの管理アクセスが可能になります。

ユーザーが AWS マネジメントコンソールにログインすると、イベントがトリガーされるのは サインイン:コンソールログイン。イベントには ID ログイン、ソース IP、ユーザーエージェント、AWS アカウントに関する情報が含まれます。

• 呼び出しを実行する ID であるログインプロファイルから IAM ユーザーとしてログインすると、IAM ユーザーの ARN が含まれます (ユーザーアイデンティティー.arn フィールドの形式は arn: aws: iam:: 012345678912: ユーザー/ログインユーザー)。
• ユーザーエージェントはブラウザになります (Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv: 143.0) Gecko/20100101 Firefox/143.0)、ログインは1つを介して行われるため
• で その他のイベントデータ フィールドには、ログインに使用されたコンソールのログイン URL と、MFA の使用状況に関する情報も表示されます。

"additionalEventData": {
  "LoginTo": "https://console.aws.amazon.com/console/home?hashArgs=%23&isauthcode=true&state=hashArgsFromTB_us-east-2_addce6de859630d0",
  "MobileVersion": "No",
  "MFAUsed": "No"
},

ユーザーがフェデレーション認証情報を使用してログインした場合、ユーザーの ARN には次の形式が含まれます。 arn: aws: sts: 012345678912: フェデレーテッドユーザー/ログインユーザーセッション名。認証情報は STS から取得されるため、イベントのソースは STS になります。 STS: フェデレーショントークンの取得。

また、 その他のイベントデータ 何も含まれません ログインする フィールド。ID が管理コンソールにアクセスするために必ずしもログインプロファイルを持っている必要はないためです。

"additionalEventData": {
  "MobileVersion": "No",
  "MFAUsed": "No"
},

最後に、ID が Identity Center を介してログインすると、ログインを実行する ID は、ログインしているユーザーのメール名と同じセッション名のロールになります (arn: aws: sts:: 0123456789012: Assumed-role/awsReservedsso_AdministratorAccess_abcdef1234567890/someuser)。Identity Center では、各ユーザーは 1 つのロールにのみアクセスでき (別に設定されている場合を除く)、セッション名はログインしているユーザーのセッション名になります。ロール名の最も一般的な形式は次のとおりです。 AWS Reservedsso_AdministratorAccess _abcdef1234567890ただし、Identity Center の作成時に任意に設定できます。

ID ログインログを入力

Azure の場合、認証はエントラ ID を使用して行われます。ログインしようとすると、各イベントにステータスが表示され、ログインログにステータスフィールドが表示されます。このフィールドにはエラーコード (ステータス. エラーコード) および成功または失敗の理由 (ステータス。その他の詳細) が保存されます。ステータスの理由には、サインインが承認された理由と拒否された理由の説明が含まれます。理由には次のようなものが考えられます。

• 予想-認証コード、更新トークン、およびセッションは、時間の経過とともに期限切れになるか、ユーザーまたは管理者によって取り消されます。アプリはユーザーに新しいログインを要求します。
• ユーザーにサインインを再試行してもらい、アプリに同意してもらいます。
• ユーザーをテナントに招待するか、ユーザーがテナントのメンバーではないはずの場合はこのエラーを無視してください。これは、メンバーではないユーザーがテナントのログイン URL に誘導されたり、間違ったユーザーアカウントを選択したりする場合です。
• Azure AD で多要素認証が完了しました
• トークンのクレームによって MFA 要件が満たされました
• アクションは不要です。これは、アプリケーションまたは条件付きアクセス要件によるデバイスIDの判断の一環として行われるものと想定されます。
• ユーザーが MFA プロンプトを完了しませんでした。認証しないことにしたのか、他の作業中にタイムアウトになったのか、認証設定に問題があるのかもしれません。
• ユーザーは正しい認証情報を入力しませんでした。ユーザーのミスが原因で、ログにこれらのエラーがいくらか表示されることが予想されます。
• ユーザーには、MFAを実行できるように連絡先オプションを提供するオプションが提示されました。
• これはログインフローで想定される部分です。ログインを容易にするために、このブラウザにサインインしたままにするかどうかをユーザーに尋ねます。
• パスワードリセット情報を提供する必要があるため、ユーザー認証はブロックされました。
• ユーザーが次にインタラクティブサインインを行うと、これの入力が求められ、アプリが次にトリガーするはずです。
• ユーザーは多要素認証を実行する必要があります。条件付きアクセスポリシー、ユーザーごとの適用、クライアントからの要求など、多要素を必要とするものが複数ある可能性があります。

イベントに保存されるもう 1 つの情報は、位置情報です。Azure はリクエストの送信元の IP と ASN に基づいて場所を計算し、その情報を提供します。

"location": {
  "city": "Some City",
  "countryOrRegion": "US",
  "geoCoordinates": {
    "altitude": null,
    "latitude": 12.3456,
    "longitude": 65.4321
  },
  "state": "State"
},

グーグルログインログ

Google は、ユーザーのログインイベントを組織のデータアクセスログに記録します (「ログ名」:「Organizations/123456789012/logs/cloudaudit.googleapis.com%2FData_Access」) タイプが「監査ログ」(「プロトペイロード。@type」:「type.googleapis.com/google.cloud.audit.auditlog」) と 「サービス名」:「ログイン.googleapis.com」。

Googleでは、以下を使用して成功または失敗別にログをフィルタリングできます ProtoPayload.メソッド名 フィールド

• google.ログイン.ログインサービス.ログイン成功
• Google.ログイン.ログインサービス.ログイン失敗

障害の理由:

"event": [
  {
    "eventName": "login_failure",
    "eventType": "login",
    "eventId": "3484ada0",
    "parameter": [
      {
        "label": "LABEL_OPTIONAL",
        "value": "reauth",
        "type": "TYPE_STRING",
        "name": "login_type"
      },
      {
        "multiStrValue": [
          "none"
        ],
        "type": "TYPE_STRING",
        "label": "LABEL_REPEATED",
        "name": "login_challenge_method"
      },
      {
        "name": "dusi",
        "value": "INjZurSThIbFLg",
        "type": "TYPE_STRING",
        "label": "LABEL_OPTIONAL"
      }
    ]
  }
]

視界の向こう側

ログは引き続きセキュリティ運用にとって不可欠です。検出、対応、フォレンジック調査におけるその価値については議論の余地がありません。しかし、この調査を通じて調査してきたように、ログを防御者にとって強力にするあらゆる機能は、攻撃者にとってもログの価値を高めています。インシデントの正確な再構築を可能にするのと同じ細分性により、偵察も可能になります。迅速な脅威ハンティングをサポートするのと同じアクセシビリティが、秘密の列挙にも対応しています。厄介な事実は、ログは 敵対空間の共有資源。攻撃者は、ログを読み取るのに十分な権限を持って最初のアクセス権を取得すると、組織自身が構築および管理している既製のインテリジェンスプラットフォームを継承します。CloudTrail、Azure Monitor、Cloud Logging は、読者が敵対的である可能性があることを想定して設計されていませんが、侵害シナリオでは、その前提は壊滅的に失敗します。

ログは私たちのシステムのストーリーを伝えます。しかし、ストーリーはアクセスできる人なら誰にでも読まれたり、誤読されたり、悪用されたりする可能性があります。ここで紹介する手法は、単なる理論上の好奇心を示すものではなく、むしろ実用的で効果的であり、巧妙な脅威アクターにますます理解されるようになっています。可視性は両刃の剣であり、ログアクセスに相応しい重力をもって扱わない限り、防御側の親友が攻撃者のサイレントパートナーになってしまう可能性があります。

では、解決策は何でしょうか？防御側も盲目にするのと引き換えに、攻撃側を盲目にするために、まったくログに記録すべきではないのでしょうか？もちろんそうではありません。ただし、いくつかの制限を設定する必要があります。この種の攻撃に対する最善のアドバイスは、言うは易し行うは難しですが、最低限の権限を適用することです。ログの取得は、プログラムによるかどうかにかかわらず、多くの ID によって実行されるタスクであるため、制限が難しくなります。ログにはデータが含まれます。データログには ID 情報、ユーザーエージェント、IP 関連、入出力パラメーターなどが含まれており、このデータは防御側や脅威ハンターにとっては貴重ですが、攻撃者にとっても重要です。

つまり、ログアクセスには最低権限を厳密に適用し、読み取り権限を書き込み権限と同様に重要視する必要があります。つまり、ログストレージをセグメント化して、ある環境が侵害されても、他の環境からのテレメトリが公開されないようにするということです。つまり、ログクエリ自体を監視し、異常なアクセスパターンに対する検出ルールを作成し、ログを読み取れるユーザーとその理由を定期的に監査することになります。ロギング権限を持つすべてのサービスアカウント、CloudTrail アクセス権限を持つすべての ID、logging.viewer を持つすべてのロールは、デフォルトで付与されるのではなく、正当化およびレビューされるべきです。