ユーザーは、機密情報へのアクセス権と機密性の高いアクションの実行権限を持つ、システム内の信頼されたエンティティです。悪意のある攻撃者はユーザーを、Web サイトを標的にして貴重なデータやリソースを盗むための機会と見なしています。

Datadog App and API Protection (AAP) は、この脅威の管理に役立つ組み込みの検出機能と保護機能を提供します。

このガイドでは、アカウント乗っ取り (ATO) キャンペーンへの備えと対応に AAP を活用する方法について説明します。このガイドは 3 つのフェーズに分かれています。

1. ログイン情報の収集:
   • 自動または手動のインスツルメンテーション方法を使用して、Datadog AAP でログインアクティビティの収集を有効にし、検証します。
   • サービスのコードを変更できない場合はリモート構成オプションを使用します。
   • データが欠落している場合や不正確な場合のトラブルシューティングを行います。
2. アカウント乗っ取りキャンペーンへの備え:
   • AAP によって検出される ATO キャンペーンに備えます。
   • 攻撃アラートの通知を構成します。
   • 攻撃者を正確に特定するために、適切なデータ伝播を検証します。
   • 即時の緩和策として自動 IP ブロックを設定します。
   • 攻撃者の IP は動的であるため一時的なブロックが重要になることを学びます。
3. アカウント乗っ取りキャンペーンへの対応:
   • 攻撃者の戦略、トリアージ、対応、調査、監視、クリーンアップなど、ATO キャンペーンへの対応方法を学びます。

フェーズ1: ログイン情報の収集

悪意のあるパターンを検出するために、AAP はユーザーのログインアクティビティを可視化する必要があります。このフェーズでは、この可視化を有効にして検証する方法を説明します。

ステップ 1.1: ID サービスで AAP が有効になっていることを確認する

このステップでは、AAP を使用するようにサービスをセットアップする方法を説明します。

1. [Catalog] (カタログ) に移動し、[Security] (セキュリティ) レンズをクリックして、ログインサービス名を検索します。

2. サービスをクリックして、その詳細を開きます。[Threat management] ピルが緑色の場合、AAP は有効になっています。ステップ 1.3: ログイン情報が自動的に収集されていることを検証するに進んでください。

   AAP が有効になっていない場合、パネルに [Discover AAP] (AAP を検出) ボタンが表示されます。

   AAP をセットアップするには、ステップ 1.2: ログインサービスで AAP を有効にするに進みます。

ステップ 1.2: ログインサービスで AAP を有効にする

ログインサービスで AAP を有効にするには、以下の要件を満たしていることを確認してください。

• Datadog APM と同様に、AAP にはサービス内でのライブラリ統合と実行中の Datadog Agent が必要です。
• AAP は基本的に、可能な限り新しいライブラリを使用することでメリットが得られますが、サポートされている最小バージョンは互換性要件に記載されています。
• 最低限、[Threat Detection] を有効にする必要があります。理想的には、[Automatic user activity event tracking] (ユーザーアクティビティイベントの自動追跡) も有効にする必要があります。

新しいデプロイメントを使用して AAP を有効にするには、APPSEC_ENABLED 環境変数/ライブラリ構成または Remote Configuration を使用してください。どちらの方法も使用できますが、Remote Configuration は Datadog UI を使用して設定できます。

Remote Configuration を使用して AAP を有効にし、サービスを再起動せずに済むようにするには、次の手順を実行します。

1. AAP オンボーディングに移動します。
2. [Enable App & API Protection] (App & API Protection を有効化) をクリックします。
3. [Activate on your APM services] (APM サービスでアクティブ化) で、[Select Services] (サービスを選択) をクリックします。
4. サービスを選択し、[Next] (次へ) をクリックしてセットアップ手順を続行します。

AAP Traces にサービスからのトレースが表示されたら、ステップ 1.3: ログイン情報が自動的に収集されていることを検証するに進みます。

新しいデプロイメントの使用に関する詳細な手順については、Datadog SDK を使用した AAP 脅威検出の有効化を参照してください。

ステップ 1.3: ログイン情報が自動的に収集されていることを検証する

AAP を有効にした後、ログイン情報が Datadog によって収集されていることを検証できます。

注: サービスで AAP を有効にした後、ユーザーがサービスにログインするまで数分待つか、ご自身でサービスにログインしてください。

ログイン情報が収集されていることを検証するには、次の手順を実行します。

1. AAP の [Traces] (トレース) に移動します。
2. ログインサービスからのログインアクティビティでタグ付けされたトレースを探します。たとえば、[Search for] (検索) に @appsec.security_activity:business_logic.users.login.* がある場合があります。
3. すべてのログインサービスがログインアクティビティを報告しているかチェックします。これは [Service] (サービス) ファセットで確認できます。

サービスからのログインアクティビティが表示されない場合、ステップ 1.5: サービスを手動でインスツルメントするに移動します。

ステップ 1.4: ログインメタデータが自動的に収集されていることを検証する

ログインメタデータが収集されていることを確認するには、次の手順を実行します。

1. AAP の [Traces] (トレース) に移動します。
2. ログインサービスからのログイン成功/失敗アクティビティでタグ付けされたトレースを探します。[Search for] の検索クエリを更新して、business_logic.users.login.success または business_logic.users.login.failure でフィルタリングできます。
3. トレースを開きます。
4. [Security] (セキュリティ) タブで、[Business Logic Event] (ビジネスロジックイベント) を確認します。
5. イベントが偽のユーザーに対するものであるかをチェックします。

ログイン成功とログイン失敗の両方のトレースをいくつか確認します。ログイン失敗については、usr.exists が true (既存ユーザーによるログイン試行の失敗) のトレースと false のトレースを探します。

これらのチェックは、ユーザーが存在するかどうかにかかわらず実行する必要があります。

偽のユーザー (usr.exists:false) の場合は、以下の問題を確認してください。

• 単一のイベント: トレースに複数のログインイベント (成功と失敗の両方など) が含まれている場合は、自動インスツルメンテーションが正しくないことが原因である可能性があります。自動インスツルメンテーションを変更するには、ステップ 1.5: サービスを手動でインスツルメントするに移動してください。
• イベントに必須メタデータが含まれているか:ログイン成功の場合は、ユーザー属性セクションとして表示されることがあります。必須メタデータは、ログイン失敗の場合は usr.login と usr.exists、ログイン成功の場合は usr.login と usr.id です。メタデータが不足している場合は、ステップ 1.5: サービスを手動でインスツルメントするに移動してください。

インスツルメンテーションが正しい場合は、フェーズ 2: アカウント乗っ取りキャンペーンへの備えに進んでください。

ステップ 1.5: サービスを手動でインスツルメントする

AAP は、Datadog ライブラリに組み込まれた SDK を使用して、ログイン情報とメタデータを収集します。インスツルメンテーションは、ユーザーのログインが成功/失敗したときに SDK を呼び出して、ログインのメタデータを SDK に提供することによって行われます。SDK は、ログインとメタデータをトレースに添付して Datadog に送信します。そのデータは Datadog で保持されます。

サービスを手動でインスツルメントするには、次の手順を実行します。

1. 自動インスツルメンテーションで不正確なデータ (単一トレース内の複数のイベント) が提供されている場合は、自動インスツルメンテーションを無効にするを参照してください。
2. 各言語の詳細なインスツルメンテーション手順については、ビジネスロジック情報 (ログイン成功、ログイン失敗、任意のビジネスロジック) のトレースへの追加に進んでください。必ず以下のメタデータを追加してください。
   • usr.login: ログイン成功時と失敗時に必須。このフィールドには、アカウントへのログインに使用された名前が含まれます。名前は、メールアドレス、電話番号、ユーザー名、その他である可能性があります。このフィールドの目的は、標的となったアカウントを、システムに存在しない場合でも特定することです (ユーザーがアカウントを変更できる可能性があるため)。また、このフィールドは、攻撃者が使用したデータベースの場所に関する情報を提供します。この値を usr.id と混同しないでください。
   • usr.exists: ログイン失敗時に必須。このフィールドは、一部のデフォルト検出で必要になります。システムに存在しないアカウントを標的とした試行の優先度を下げるのに役立ちます。

コードをデプロイしたら、インスツルメンテーションが正しいことを検証します。ステップ 1.4: ログインメタデータが自動的に収集されていることを検証するの手順に従ってください。

ステップ 1.6: サービスのリモートインスツルメンテーション

AAP では、カスタムアプリ内 WAF ルールを使用してログイン試行にフラグを立て、検出ルールに必要なメタデータをリクエストから抽出できます。

このアプローチでは、Remote Configuration が有効化されて機能している必要があります。Remote Configuration で、このサービスに対して Remote Configuration が実行されていることを確認してください。

カスタムアプリ内 WAF ルールを使用するには、次の手順を実行します。

1. アプリ内 WAF カスタムルール作成フォームを開きます。

2. ルールに名前を付け、[Business Logic] (ビジネスロジック) カテゴリを選択します。

3. ルールタイプを、ログイン失敗の場合は users.login.failure に、ログイン成功の場合は users.login.success に設定します。

4. サービスを選択し、ログイン試行を照合するルールを作成します。通常は、メソッド (POST)、正規表現を使用したURI (^/login)、およびステータスコード (失敗の場合は 403、成功の場合は 302 または 200) を照合します。

5. 検出ルールに必要なタグを収集します。最も重要なタグは usr.login です。ログインがリクエストで提供されていると仮定して、条件を追加し、演算子として store value as tag を設定します。

6. 本文またはクエリのいずれかで、特定のユーザーパラメーターを入力として選択します。

7. [Tag] (タグ) フィールドを、usr.login を使用してキャプチャされた値を保存するタグの名前に設定します。

8. [Save] (保存) をクリックします。ルールがサービスのすべてのインスタンスに自動的に送信され、ログイン失敗のキャプチャが開始されます。

インスツルメンテーションが正しいことを検証するには、ステップ 1.4: ログインメタデータが自動的に収集されていることを検証するを参照してください。

詳細については、コードを変更せずにビジネスロジック情報を追跡するを参照してください。

フェーズ 2: ATO キャンペーンへの備え

サービスのインスツルメンテーションのセットアップが完了すると、AAP は攻撃キャンペーンを監視します。[Attacks overview] (攻撃の概要) の [Business logic] (ビジネスロジック) セクションでトラフィックを確認できます。

AAP は、攻撃者のさまざまな戦略を検出します。高い信頼度で攻撃を検出すると、組み込みの検出ルールがシグナルを生成します。

シグナルの重大度は、脅威の緊急度に基づいて設定されます。たとえば、攻撃が失敗した場合は [Low] (低)、アカウントの侵害が成功した場合は [Critical] (重大) になります。

以降のセクションで説明するアクションは、検出をより迅速に特定して活用するのに役立ちます。

ステップ 2.1: 通知を構成する

通知は、シグナルがトリガーされたときに、希望するチャンネルで警告を提供します。通知ルールを作成するには、次の手順を実行します。

1. [Create a new rule] (新しいルールを作成) を開きます。
2. ルールの名前を入力します。
3. [Signal] (シグナル) を選択し、[App & API Protection] 以外のすべてのエントリを削除します。
4. ルールを category:account_takeover に制限し、重大度を展開して Medium を含めます。
5. 通知の受信者 (Slack、Teams、PagerDuty) を追加します。 詳細については、通知チャンネルを参照してください。
6. ルールをテストして保存します。
   通知は、次にシグナルが生成されたときに送信されます。

ステップ 2.2: 適切なデータ伝播を検証する

マイクロサービス環境では、サービスは通常、他のサービスを実行している内部ホストからアクセスされます。この内部環境では、IP、ユーザーエージェント、フィンガープリントなど、元の攻撃者のリクエストに固有の特性を特定することが困難になります。

AAP Traces を使用すると、ログインイベントにソース IP やユーザーエージェントなどが適切にタグ付けされていることを検証できます。検証するには、[Traces] でログイントレースを確認し、以下をチェックします。

• ソース IP (@http.client_ip) が多様であり、パブリック IP であること。
  • 問題: ログイン試行が少数の IP からのみ行われている場合、可用性を損なうことなくブロックできないプロキシである可能性があります。
  • 解決策: 初期リクエストのクライアント IP を、X-Forwarded-For などの HTTP ヘッダーを使用して転送します。より優れたセキュリティのためにカスタムヘッダーを使用し、DD_TRACE_CLIENT_IP_HEADER 環境変数を使用してそれを読み取るように SDK を構成できます。
• ユーザーエージェント (@http.user_agent) が予期されるトラフィック (Web ブラウザ、モバイルアプリなど) と一致していること。
  • 問題: ユーザーエージェントが、呼び出し元のマイクロサービスネットワークライブラリのユーザーエージェントに置き換えられる可能性があります。
  • 解決策: 後続のサービスを呼び出す際に、クライアントのユーザーエージェントを使用します。
• 複数のヘッダーが設定されていること。これは、トレースの [See more details] (詳細を確認) の [Request] (リクエスト) ブロックで確認できます。
  • 問題: 通常のリクエストヘッダー (例: accept-encoding) が、インスツルメントされたサービスに転送されていません。これにより、フィンガープリント (@appsec.fingerprint.*) の生成が損なわれ、攻撃者のアクティビティを分離するシグナルの能力が低下します。
  • 解決策: 後続のマイクロサービスを呼び出す際に、それらのヘッダーを転送します。

ステップ 2.3: 自動ブロックを構成する

AAP の自動ブロック機能を使用すると、時間帯を問わず攻撃をブロックできます。これにより、チームメンバーがオンラインになる前に攻撃をブロックできるため、営業時間外にセキュリティを確保できます。ATO では、ログイン試行の失敗の増加によって引き起こされる負荷の問題を軽減したり、侵害されたアカウントが攻撃者に使用されるのを防いだりするのに役立ちます。

攻撃の一部として識別された IP をブロックするように自動ブロックを構成できます。攻撃者は IP を変更できるため、これは部分的な修復にすぎませんが、包括的な修復を実装するための時間を稼ぐことはできます。

自動ブロックを構成するには、次の手順を実行します。

1. [AAP] > [Policies] (ポリシー) > [Detection Rules] (検出ルール) に移動します。
2. [Search] (検索) に、tag:"category:account_takeover" を入力します。
3. ブロックを有効にするルールを開きます。Datadog では、[High] (高) または [Critical] (重大) の重大度に対して IP ブロックを有効にすることを推奨しています。
4. ルールの [Define Conditions] (条件を定義) の [Security Responses] (セキュリティ対応) で、[IP automated blocking] (IP の自動ブロック) を有効にします。[User automated blocking] (ユーザーの自動ブロック) を有効にすることもできます。 条件ごとにブロック動作を制御できます。各ルールには、信頼度と攻撃の成功に基づいて複数の条件を設定できます。

Datadog は、IP アドレスの永続的なブロックを推奨していません。攻撃者が同じ IP を再利用する可能性は低く、永続的なブロックによりユーザーがブロックされる可能性もあります。さらに、AAP でブロックできる IP の数には制限があるため (~10000)、このリストが不要な IP でいっぱいになる可能性もあります。

フェーズ 3: ATO キャンペーンへの対応

このセクションでは、アカウント乗っ取りを試みるハッカーの一般的な行動と、検出のトリアージ、調査、監視の方法について説明します。

攻撃者がキャンペーンを実行する方法

最終的には、システムが攻撃を受けることになります。悪意のあるログイン試行が波のように押し寄せて、サービスで想定されている通常のログインアクティビティの量を上回ることもよくあります。負荷が増大して可用性の問題が発生したり、攻撃者がいつでもアカウントにログインできるようになったりする可能性があります。

攻撃者がとる行動は、各自の戦略と、対象システムの構成に依存します。侵害したアカウントが凍結される前にアクセス権を悪用してすぐに価値を引き出そうとする攻撃者もいれば、そのアカウントを後で利用するために休眠状態にしておく攻撃者もいます。

多くの戦略が存在しますが、攻撃のバリューチェーンはしばしば慎重に分割されていることを理解しておくことが重要です。

1. 攻撃を開始する実行者は、多くの場合、ベンダーから資格情報のデータベース (別のサービスの侵害によって取得された可能性が高い) を購入します。
2. 実行者は、検出を回避しながら自動的にログインを試行するように設計された (ヘッダーをランダム化して通常のトラフィックに可能な限り似せようとする) スクリプトを調達します。
3. 実行者はボットネットへのアクセスを購入し、多くの異なる IP を活用して攻撃を実行します。極端なケースでは、50 万回以上の試行を伴う大規模なキャンペーンが極度に分散された結果、Datadog で観測された IP あたりのリクエスト数は平均 1.01、アカウントあたりの試行回数は 1 回のみだった例もあります。
4. 有効な資格情報が発見されると、下流の別の攻撃者に販売されて、金銭窃取、スパム、悪用などの目的に利用される可能性があります。

システムに対する攻撃が始まると、攻撃者の戦略に応じて、[Credential Stuffing] (クレデンシャルスタッフィング)、[Distributed Credential Stuffing] (分散クレデンシャルスタッフィング)、または [Bruteforce] (ブルートフォース) のラベルが付いたシグナルが生成されます。

ステップ 3.1: トリアージ

最初のステップでは、検出が正しいことを確認します。ログインエンドポイントに対するセキュリティスキャンや、大量のトークンローテーションなど、検知システムには攻撃のように見える動作もあります。分析はシグナルに依存します。以下の例は一般的なガイダンスであり、個々の状況に合わせてカスタマイズする必要があります。

このシグナルは、あるアカウントに対して多くの異なるパスワードを試すことで、ユーザーアカウントを盗もうとする試みを監視しています。一般的に、これらのキャンペーンでは少数のアカウントが標的となります。

侵害されたとフラグが立てられたアカウントを確認します。ユーザーをクリックすると、最近のアクティビティの概要が開きます。

トリアージのための質問:

• アクティビティの急激な増加はありましたか?
• それらの IP アドレスからのログイン試行は初めてですか?
• 脅威インテリジェンスによってフラグが立てられていますか?

これらの質問への回答が“はい”である場合、そのシグナルは正当なものである可能性が高いです。

アカウントの機密性に基づいて対応を調整できます。たとえば、アクセスが制限された無料アカウントと管理者アカウントでは対応が異なります。

このシグナルは、少数の IP アドレスからのログインの失敗が多数のアカウントで発生している状況を検出します。これは多くの場合、未熟な攻撃者によって引き起こされます。

標的としてフラグが立てられたアカウントを確認し、類似点を見つけて、それらのユーザーの機密性を判断します。

それらのユーザーが同じ機関に所属しているなど、属性を共有している場合は、その IP が当該機関のプロキシである可能性があるかどうかをチェックするために、カーソルを合わせてサイドパネルを開き、過去のアクティビティを確認します。

トリアージのための質問:

• アクティビティの急激な増加はありましたか?
• アカウント間に関連性はありませんか?
• IP は脅威インテリジェンスによってフラグが立てられていますか?
• ログインの成功よりも失敗の方がはるかに多いですか?

これらの質問への回答が“はい”である場合、そのシグナルは正当なものである可能性が高いです。 攻撃の規模や、アカウントが侵害されているかどうかに基づいて、対応を調整できます。

このシグナルは、サービスにおけるログイン失敗の総数が大幅に増加しているかを監視します。これは、ボットネットを活用する高度な攻撃者によって引き起こされます。

Datadog は、サービス内のログイン失敗間で共通の属性を特定しようとします。これにより、悪意のあるアクティビティを分離するために使用できる、攻撃者のスクリプト内の欠陥が明らかになります。見つかった場合、[Attacker Attributes] (攻撃者の属性) というセクションが表示されます。表示された場合は、クラスターを選択して [Explore clusters] (クラスターを探索) をクリックし、正当なアクティビティであるかどうかを確認します。

正確であれば、クラスターのアクティビティはログイン失敗の増加と密接に一致し、それ以前は低かったか、存在しなかったはずです。 クラスターが利用できない場合は [Investigate in full screen] (全画面で調査) をクリックし、対象となったユーザー/IP に外れ値がないか確認します。

リストが切り捨てられている場合は [View in AAP Traces Explorer] (AAP Traces エクスプローラーで表示) をクリックして、Traces エクスプローラーで調査を実行します。その他のツールについては、ステップ 3.3: 調査を参照してください。

トリアージの結果、シグナルが誤検知であると判断された場合は、誤検知としてフラグを立ててクローズできます。

誤検知がサービス内の固有の設定によって引き起こされた場合は、抑制フィルターを追加して誤検知を抑制できます。

シグナルが正当なものである場合は、ステップ 3.2: 予備対応に進んでください。

ステップ 3.2: 予備対応として攻撃者を妨害する

攻撃が進行中の場合は、調査を進めながら攻撃者を妨害することを検討するとよいでしょう。攻撃者を妨害することで、攻撃の速度を低下させ、侵害されるアカウントの数を減らすことができます。

この予備対応を実施するには、サービスで Remote Configuration が有効になっている必要があります。

部分的な対応を開始するには、次の手順を実行します。

攻撃者は少数の IP アドレスを使用している可能性が高いです。それらをブロックするには、シグナルを開き、[Next Steps] (次のステップ) を使用します。ブロックの期間を設定できます。

Datadog では 12 時間を推奨しています。これは、攻撃を停止させるのに十分な時間です。また、攻撃終了後にそれらの IP アドレスが正当なユーザーに再割り当てされた際に、正当なユーザーがブロックされるのを回避することもできます。Datadog では、永続的なブロックは推奨していません。 侵害されたユーザーをブロックすることもできますが、よりよいアプローチは、それらを抽出してお使いのシステムで資格情報をリセットすることです。

最後に、[Next Steps] セクションで自動 IP ブロックを有効にして、調査中に新しい IP が自動的にブロックされるようにすることもできます。

これらの攻撃では、多くの場合、大量の使い捨て IP が使用されます。Datadog のレイテンシーにより、攻撃者が IP をプールから削除する前に IP をブロックしてログイン試行を阻止するのは現実的ではありません。

代わりに、悪意のある試行に固有の、リクエストの特性 (ユーザーエージェント、特定のヘッダー、フィンガープリントなど) をブロックします。

[Distributed Credential Stuffing campaign] (分散クレデンシャルスタッフィングキャンペーン) シグナルでは、明確な特性が自動的に特定されて、[Attacker Attributes] (攻撃者の属性) として提示されます。

ブロックする前にクラスターのアクティビティを調べて、実際に悪意のあるアクティビティであることを確認することをお勧めします。

以下の質問に対する回答を試みます。

• 悪意のあるトラフィックですか?そのトラフィックは攻撃が始まる前から存在していましたか?
• 有意な量の正当なトラフィックを捕捉できますか?
• このクラスターに基づくブロックは効果的ですか?

そのためには、クラスターを選択して [Explore clusters] (クラスターを探索) をクリックします。

[Investigate] (調査) エクスプローラーが表示され、クラスタートラフィックの指標 (攻撃によるトラフィックが多くを占めていること、および脅威インテリジェンスによってフラグが立てられた IP の割合が高いこと) が提供されます。

これらは 2 つの重要な指標です。

• Threat Intel % (脅威インテリジェンス %)

• Traffic Distribution (トラフィック分布)

指標をクリックすると、クラスタートラフィックに関する詳細情報が表示されます。

[Cluster Activity] (クラスター アクティビティ) では、このクラスターに一致する APM トラフィック全体のボリュームが可視化されます。AAP データと比較する際にはスケールに注意してください。APM データはサンプリングされている可能性がありますが、AAP データはサンプリングされていません。

次の例では、攻撃前からのトラフィックが多くなっています。これは、通常のトラフィックの正当なアクティビティがこのクラスターと一致していることを意味します。そのため、アクションを実行するとそれらがブロックされてしまいます。したがって、エスカレーションしたり、シグナル内の [Block All Attacking IPs] (すべての攻撃 IP をブロック) をクリックしたりする必要はありません。

別の例では、クラスターのアクティビティが攻撃とともに開始されています。これは、付随的被害が生じる可能性は低いため、ブロックに進んでもよいことを意味します。

特性が攻撃者と一致することを確認したら、アプリ内 WAF ルールをプッシュして、それらの特性と一致するリクエストをブロックできます。これは、ユーザーエージェントベースの特性に対してのみサポートされています。

ルールを作成するには、次の手順を実行します。

1. [AAP] > [Policies] > [In-App WAF] (アプリ内 WAF) > [[Custom Rules] (カスタムルール)][33] に移動します。

2. [Create New Rule] (新しいルールを作成) をクリックし、構成を完了します。

3. [Define your custom rule] (カスタムルールを定義) の手順に従います。

4. [Select the services you want this rule to apply to] (このルールを適用するサービスを選択) で、お使いのログインサービスか、リクエストをブロックするサービスを選択します。ブロックの対象をログインルートに絞ることもできます。

5. [If incoming requests match these conditions] (受信リクエストがこれらの条件に一致した場合) で、ルールの条件を構成します。

   1. 特定のユーザーエージェントをブロックする場合は、それを [Values] (値) に貼り付けます。[Operator] (演算子) では、[matches value in list] (リストの値に一致) を使用できます。より柔軟な設定が必要な場合は、[Matches RegEx] (正規表現に一致) を使用することもできます。

6. [Preview matching traces] (一致するトレースをプレビュー) セクションを使用して、ルールの影響を最終確認します。予期しないトレースが表示されなければ、ブロックモードを選択してルールを保存します。

複数のブロックアクションが利用可能です。攻撃者の巧妙さによっては、ブロックされたことにすぐに気づかれないよう、より目立たない対応が必要になります。

ステップ 3.3: 調査

予備対応として攻撃者を妨害したら、以下を特定できます。

• 攻撃者によって侵害されたアカウント。これにより資格情報をリセットできます。
• 標的となったアカウントのソースに関するヒント。プロアクティブなパスワードリセットや監視の厳重化に活用できます。
• 攻撃者のインフラストラクチャーに関するデータ。将来の試行やその他の悪意のあるアクティビティ (クレジットカードスタッフィング、不正利用など) の検知に活用できます。

最初のステップは、アプリケーションの全体的なトラフィックから攻撃者のアクティビティを分離することです。

攻撃者のアクティビティを分離する

攻撃者のアクティビティを分離する間、現在のフィルターが網羅的であることを以下の 2 つのテストで確認してください。

1. [Traces] に移動し、特定したフィルターに基づいてトレースを除外します。目標は、残りのトラフィック量を通常のトラフィック量と同程度にすることです。攻撃中にまだログインの急増が見られる場合は、攻撃を包括的に分離するためにはさらなるフィルターが必要であることを意味します。
2. フィルターに一致するトラフィックを、期間を広げて (たとえば、攻撃が 1 時間続いた場合は 1 日) 確認します。攻撃の前後に一致したトラフィックは、誤検知である可能性が高いです。

次に、攻撃のアクティビティを分離することから始めます。

[Signals] に移動して、標的となったユーザーのリストを抽出します。

[Security Traces] (セキュリティトレース) 内の [login attempts] (ログイン試行) リンクをクリックすることで、標的となったユーザーのトレースをクエリできます。

標的となったユーザーに直接アクセスしたい場合は、シグナルサイドパネルからリストを抽出できます。

このユーザーリストからトレースクエリを作成して、標的となったユーザーによるすべてのアクティビティを確認できます。以下のテンプレートに従ってください。

@appsec.security_activity:business_logic.users.login.* @appsec.events_data.usr.login:(<users>)

ログインの成功は、疑わしいものと見なすべきです。

このシグナルは、少数の IP から発生する多くのアクティビティを検知したもので、その分散型バリアントと密接に関連しています。攻撃の一部がシグナルで検知されなかった場合、状況によっては分散クレデンシャルスタッフィングの手法を使用する必要があります。

[Security Traces] 内の [login attempts] リンクをクリックすることで、攻撃元の IP と一致するトレースをクエリできます。

攻撃元の IP に直接アクセスしたい場合は、シグナルサイドパネルからリストを抽出できます。

この IP リストからトレースクエリを作成して、疑わしい IP からのすべてのアクティビティを確認できます。以下のテンプレートに従ってください。

@appsec.security_activity:business_logic.users.login.* @http.client_ip:(<IPs>)

ログインの成功は、疑わしいものと見なすべきです。

このシグナルは、1 つのサービスにおけるログイン失敗の急増を検知したものです。攻撃の規模が大きい場合は、ブルートフォースまたはクレデンシャルスタッフィングのシグナルをトリガーすることもあります。このシグナルは、分散型攻撃をより包括的に検出することも可能です。

分散型攻撃の場合、攻撃者の属性をシグナルで確認できます。

1. サイドパネルでシグナルを開いた後、[Investigate in full screen] をクリックします。
2. [Attacker Attributes] でクラスターを選択し、[Filter this signal by selection] (このシグナルを選択内容でフィルター) をクリックします。次に、[Traces] で [View in AAP Traces Explorer] をクリックします。

これにより、フラグが立てられた属性にフィルターが設定されたトレースエクスプローラーに移動します。現在のクエリで調査を開始することもできますが、ログインの失敗だけでなく成功も一致するようにクエリを拡張することをお勧めします。そのためには、@appsec.security_activity:business_logic.users.login.failure を @appsec.security_activity:business_logic.users.login.* に置き換えます。上記で説明した手法を使用して、フィルターの網羅性と正確性を確認してください。

それらの属性が不正確または不完全な場合は、攻撃者のアクティビティを分離するために、さらなる特性の特定を試みることもできます。全画面のシグナルに戻り、[Traces] セクションまでスクロールダウンすると、[Analysis] (分析) ボタンがあります。これにより、攻撃からのトラフィックがさまざまな属性によってスライスされる画面が表示されます。

最も一般的な属性はテーブルの先頭に表示されますが、下にスクロールするとその影響を視覚化できます。各行には、その属性に一致するトラフィックの割合と、そのトラフィックがトラフィック増加の「形状」にどの程度一致しているかが示されます。目標は、増加したアクティビティを分離しつつ、通常の安定したトラフィックを除外する、一連の属性を特定することです。グラフのスケールに注意してください。すべてのトレースにすべての属性がタグ付けされているわけではありません (例: Threat Intelligence)。さらに、一部のフィールドはブロックに使用できないことに留意してください (Threat Intelligence、ASNs、IP geo)。

属性を特定したら、リストからそれらを選択し、[Filtering enabled] (フィルター有効) ボタンのオン/オフを切り替えて網羅性を再確認します。満足できたら、影響を受けたユーザーをさらに詳しく確認するために [View Traces] (トレースを表示) をクリックします。

ログインの成功と失敗を確認する

ログインの成功と失敗を確認すると、以下を特定するのに役立ちます。

• 攻撃者が何を狙っているか。それに基づいてブロック対策を講じることができます。
• 攻撃者が何を行っているか。スクリプトが変更されても捕捉できるようになります。
• 攻撃者がどの程度成功しているか。アカウントの制御を取り戻したり、対応にかけられる時間を評価したりできます。

攻撃者のアクティビティが分離されたら、ログインの成功を確認して、以下の質問を検討します。

• 侵害されたアカウントはありますか?
• 侵害されたアカウントは何らかの活動に利用されていますか、それとも休眠状態に置かれていますか?
• それらのアカウントはその後に別のインフラストラクチャーからアクセスされていますか?
• このインフラストラクチャーに関連する過去のアクティビティはありますか?

ログインの失敗については、以下の質問を検討します。

• 攻撃者は特定のユーザー群を狙っていますか?
• 攻撃はどれくらい成功していますか?攻撃の精度は 1/100 〜 1/1000 の範囲である必要があります。
• CAPTCHA や多要素認証が突破されていますか?

調査が進み、調査結果に基づく対応を適用できるようになったら、このステップと次のステップの間を行き来することができます。

ステップ 3.4: 対応

Datadog の調査機能は、バックエンドからのデータによって強化されていますが、このデータは、対応を実行するライブラリでは利用できません。そのため、すべてのフィールドを対応の適用に利用できるわけではありません。

執拗な攻撃者は、対応に気づくとすぐにそれを回避しようとします。これを想定して、以下のことを行ってください。

1. 攻撃の可視性を失わないようにする。
2. 攻撃者によるブロックの特定を可能な限り困難にする。たとえば、ブロックの応答をログイン失敗時の応答と同じにします。これにより、攻撃者を混乱させ、攻撃がまだ成功していると信じ込ませることができます。
3. 攻撃者によるブロックの回避を可能な限り困難にする。IP の代わりに、特定のヘッダー値などの微妙な特性を使用します。

Datadog の組み込みのブロック機能を使用して、特定の基準に一致するリクエストを拒否することも、データをいずれかのシステムに自動的にエクスポートして、資格情報のリセット、ブロック時のログイン失敗の模倣などの対応を実施することもできます。

Datadog のブロック機能

Datadog によってブロックされたトラフィックの一部であるユーザーには、“You’re blocked” (ブロックされています) というページが表示されるか、リダイレクトなどのカスタムステータスコードが返されます。ブロックは、パフォーマンス特性が異なる 2 つのメカニズムを通じて適用できます。Denylist とカスタム WAF ルールの 2 つです。

Denylist

Denylist は、多数のエントリをブロックする効率的な方法ですが、IP とユーザーに限定されます。調査の結果、攻撃の原因となっている少数の IP セット (<1000) が判明した場合は、それらの IP をブロックするのが最善の対策です。

Denylist は、シグナル内の [Automate Attacker Blocking] (攻撃者のブロックを自動化) をクリックすることで、Datadog プラットフォームを使用して管理および自動化できます。

[Automate Attacker Blocking] または [Block All Attacking IPs] のシグナルオプションを使用して、すべての攻撃 IP を数時間、1 週間、または永続的にブロックします。同様に、侵害されたユーザーをブロックすることもできます。繰り返しになりますが、Datadog では、IP を永続的にブロックすることは推奨していません。IP がパブリックプールに再利用された後に、正当なトラフィックがブロックされるリスクがあるからです。

ブロックは、Denylist から解除または延長できます。

シグナルが正確でなかった場合は、ユーザーまたは IP のリストを抽出して、手動で Denylist に追加できます。

アプリ内 WAF ルール

Denylist で不十分な場合は、WAF ルールを作成できます。WAF ルールは、評価速度は Denylist よりも遅くなりますが、より柔軟です。

新しいルールを作成するには、次の手順を実行します。

1. [AAP] > [Policies] > [In-App WAF] (アプリ内 WAF) > [Custom Rules] (カスタムルール) に移動します。
2. [Create New Rule] (新しいルールを作成) をクリックし、構成を完了します。
3. [Define your custom rule] (カスタムルールを定義) の手順に従います。
4. [Select the services you want this rule to apply to] で、お使いのログインサービスか、リクエストをブロックするサービスを選択します。ブロックの対象をログインルートに絞ることもできます。

5. [If incoming requests match these conditions] (受信リクエストがこれらの条件に一致した場合) で、ルールの条件を構成します。
   1. 特定のユーザーエージェントをブロックする場合は、それを [Values] に貼り付けます。[Operator] では、[matches value in list] を使用できます。より柔軟な設定が必要な場合は、[Matches RegEx] を使用することもできます。

6. [Preview matching traces] (一致するトレースをプレビュー) セクションを使用して、ルールの影響を最終確認します。予期しないトレースが表示されなければ、ブロックモードを選択してルールを保存します。

対応は自動的にトレーサーにプッシュされ、ブロックされたトレースが Traces エクスプローラーに表示されます。

複数のブロックアクションが利用可能です。攻撃者の巧妙さによっては、ブロックされたことにすぐに気づかれないよう、より目立たない対応が必要になります。

詳細については、アプリ内 WAF ルールを参照してください。

自動データエクスポート

Webhook を使用して任意のユーザー ID をプッシュするようにシグナルを構成できます。この方法を使用すると、侵害されたユーザーをお使いのシステムにプッシュして、資格情報をリセットしたり、制限をかけたりすることができます。その目的は、それらのアカウントを攻撃者にとって無用なものにすることです。

Webhook を使用してユーザー ID をプッシュするようにシグナルを構成するには、次の手順を実行します。

1. 標準 Webhook ターゲットを構成します。これが Cloud SIEM でどのように機能するかを確認するには、Webhooks で検出された脅威の修復を自動化するに移動してください。
2. [Detection Rules] で、構成するルールを開きます。

3. 検出ルールの条件にある通知設定に移動します。
4. 受信者を追加し、[Notify for every new @usr.id detected] (新しい @usr.id が検出されるたびに通知する) をオンにします。これにより、更新が発生したときにリストをエクスポートできるようになります。

検出ルールの条件で設定された通知ターゲットは、新しいユーザー ID が検出されるとメッセージを受信します。これらのシグナルを監視する通知プロファイルは、新しいユーザー ID に関するアラートを受信しません。

標的にされたユーザー ID と侵害されたユーザー ID を Webhook で受信するには、Datadog Webhook インテグレーションを使用して Webhook を設定します。Webhook のペイロードに $SECURITY_SIGNAL_ATTRIBUTES 変数を含めます。ユーザー ID は、JSON ペイロードの @usr.id パスに格納されます。

ペイロードをパースすることにより、お使いのシステムで ID に基づくアクションを実行できます。

重要: このリストに含まれるのは、前回の通知以降に検出された ID のみです。ID が再度ログインしても重複排除は行われません。

ステップ 3.5: 監視

攻撃者が対応を察知した後に、攻撃が一時停止されたり、改変されたりする可能性があります。対応を導入した後も、ログイン試行の割合、特に失敗の割合を監視し続けてください。攻撃は一旦収束しても、数分、数時間、あるいは数日後に再開される可能性があります。

大規模な攻撃が再開された場合は、分散クレデンシャルスタッフィングのシグナルを再実行する必要があります。この場合、以下の考慮事項を確認してください。

• 執拗な攻撃者を諦めさせるには、多くの場合、防御措置を何度も繰り返す必要があります。
• 理想的な防御とは、攻撃者が回避できない堅牢なブロック戦略です。
• 攻撃者は、IP やユーザーエージェントを変更することによって検出を回避しようとすることがよくあります。ログイン試行を送信するために調達したスクリプトを大幅に変更する可能性は低いため、ヘッダーの方がより耐性のあるターゲットとなります。
• 効果的な戦略には、珍しいヘッダーの組み合わせを特定するフィンガープリントベースの手法や相関手法が含まれます。
• 以前の防御対応の結果としてブロックされたトラフィックを監視します。
• 攻撃者のトラフィックをブロックすると、正当なトラフィックまで意図せずブロックしてしまう可能性があります。正当なトラフィックのブロックを解除するメカニズムを実装してください。Datadog の対応を調整するか、攻撃終了後にブロックが解除されるようにします。

ステップ 3.6: クリーンアップ

攻撃者による目立った活動がないまま数日が経過したら、攻撃が終了したと判断し、クリーンアップフェーズに移行することを検討してもよいでしょう。

クリーンアップフェーズの目的は以下のとおりです。

• 追加した緩和策をすべて無効にする。
• 正当なトラフィックがブロックされていないことを確認する。
• 将来の攻撃に備えてサービスを強化する機会を特定する。
• 攻撃者がユーザーに対して使用したデータのソースを特定する。

緩和策を無効にする

ユーザーのブロックは、シグナルで [Block All Attacking IPs] を選択した際に設定したタイマーに基づいている必要があります。ユーザーのブロックがそのように構成されれている場合は、さらなる操作は必要ありません。

永続的なブロックを設定した場合は、以下の手順を実行して、Denylist からユーザーと IP のブロックを解除してください。

1. Denylist を開きます。
2. [Blocked IPs] (ブロックされた IP) または [Blocked users] (ブロックされたユーザー) をクリックします。
3. エンティティリストで IP またはユーザーを見つけて、[Unblock] (ブロックを解除) をクリックします。

カスタムアプリ内 WAF ルールを無効化または削除する

アプリ内 WAF ルールを無効化または削除するには、カスタムアプリ内 WAF ルールのページに移動し、[Monitoring] (監視) または [Blocking] (ブロック) をクリックして [Disable Rule] (ルールを無効化) を選択し、ルールを無効にします。

ルールが不要になった場合は、その他のオプション (…) をクリックして [Delete] (削除) を選択することで削除できます。

正当なトラフィックがブロックされていないことを確認する

正当なトラフィックがブロックされていないことを確認するには、トラフィックの量が攻撃の量とほぼ一致している必要があり、主要な攻撃波以外でブロックされたトレースがほとんど存在しない状態である必要があります。

正当なトラフィックがブロックされていないことを確認するには、以下の手順を実行します。

1. [Traces] に移動し、ブロックされたトレースを検索 @appsec.blocked:true で検索します。
2. 大量のトラフィックが継続的にブロックされている場合、そのトラフィックは正規のユーザーである可能性が高いです。
   1. 誤ったブロックルールを無効にして、ユーザーがそれ以上ブロックされないようにします。
   2. Denylist からそのトラフィックのブロックを解除することを優先します。

サービスを強化する

大規模な ATO キャンペーンが単発で発生することは稀です。攻撃の合間を利用してサービスを強化し、その後の攻撃で活用できる構成を確立することをお勧めします。

一般的な強化の例をいくつか挙げます。

• IP/ユーザー/ネットワーク範囲/ユーザーエージェントごとのログイン試行のレート制限: このソフトブロック機能を使用すると、攻撃者が通常のユーザーと特性を共有している場合でも、通常のユーザーへの影響を最小限に抑えつつ、状況によっては攻撃の規模を大幅に縮小できます。
• ログイン時の摩擦の追加: ユーザーに大きな影響を与えずに攻撃者の自動化を阻止するには、CAPTCHA を使用するか、攻撃中にログインフローを変更します (例: 新しいエンドポイントからトークンを取得することを要求する)。
• 多要素認証 (MFA) の強制: Datadog は、アカウントの侵害を阻止する上で MFA が非常に効果的であることを確認しています。攻撃を受けている間は特に、最も権限の高いユーザーに MFA の使用を義務付けることができます。
• ユーザーに対する機密性の高いアクションの制限: サービスでユーザーに機密性の高いアクション (金銭の支払い、機密情報へのアクセス、連絡先情報の変更など) の実行を許可している場合、不審なログインを行ったリスクの高いユーザーは、手動または多要素認証による確認が行われるまで禁止することをお勧めします。不審なログインは、Webhook を通じて Datadog からお使いのシステムにプログラムでフィードできます。
• シグナルの検出結果をプログラムで消費する機能: Datadog の Webhook を消費するエンドポイントを作成して、疑わしいユーザー/IP/特性に対して自動的にアクションを実行します。

攻撃者のデータソースを特定する

攻撃者は、侵害されたアカウントのリストを大量に入手します。データベースのソースを特定することで、リスクのあるユーザーを事前に特定できます。

データベースのソースを特定するには、次のいずれかのオプションを使用して、攻撃の影響を受けたユーザーをエクスポートします。

• シグナルの詳細の [Targeted users] (標的となったユーザー) で、[Export to CSV] (CSV にエクスポート) をクリックします。このオプションでは、最大 10,000 人のユーザーをエクスポートできます。
• 10,000 人以上のユーザーをエクスポートする必要がある場合は、手動で API 呼び出しを実行してクエリをページ分割します。Traces エクスプローラーも同様の呼び出しを実行するため、@appsec.events_data.usr.login でグループ化することにより、そこで実行されている呼び出しに基づいてリクエストを作成できます。バックエンドの上限を回避するために、制限を 10000 に設定し、より短い時間範囲を使用してください。

リストを入手したら、共通の属性がないか確認します。

• すべてのユーザーが特定の地域または特定の顧客から来ている場合。
• ユーザーの大部分が既知の侵害を共有している場合 (Have I Been Pwned API を使用)。

データベースのソースが特定されたら、それらの顧客に対して、あらかじめパスワードリセットを強制するか、高リスクのフラグを立てます。これにより、将来の不審なログインが実際に侵害されたものであるという確信が高まります。

攻撃者のその他のアクティビティを確認する

攻撃者のシグニチャを活用してフィルターを拡張し、攻撃者が実行したログイン以外のアクティビティを調査します。

このフィルターは、精度が低くなる可能性があります。たとえば、攻撃者が攻撃のために複製した正規のトラフィックを持つモバイルアプリケーションのシグニチャと一致するフィルターなどが挙げられます。このフィルターにより、攻撃者が事前に調査した内容や、攻撃者が次に何をしようとしているのかについてのヒントを得られる可能性があります。

攻撃者が使用したインフラストラクチャーを起点に調査することも可能です。それらの悪意のある IP アドレスはログイン以外の操作を行ったか、他の機密性の高い API にアクセスしているか、などを調べます。

結論

アカウントの盗難は一般的な脅威ですが、従来のインジェクション攻撃よりもはるかに複雑です。これらを検知するにはお使いのシステムとの緊密な統合が必要であり、高度な攻撃に対しては自動対応が不可能なほどの不確実性が伴います。

このガイドでは、以下のことを行いました。

• アカウント乗っ取りキャンペーンの様相、そのトリアージ方法、および対策方法を学習しました。
• Datadog AAP が必要とするすべてのコンテキストを提供できるように、ログインサービスをインスツルメントしました。
• 攻撃時にあらゆる機能を提供できるように、ログインサービスを構成しました。

これは一般的なガイダンスです。アプリケーションや環境によっては、追加の対応戦略が必要になる場合があります。