このプレイブックを使用して、複数のログイン失敗 (同じユーザーの複数の IP アドレスからの認証失敗が多すぎる) によってトリガーされたパスワードスプレーアラートを調査します。以下に示すステップは、パスワードスプレーの可能性プレイブックで使用できるアクション、タスク、サブフローの段階的な説明です。
始める前に
必要なロール：
- sn_si.admin
- flow_designer
Security Operations スポーク (sn_sec_spoke) がインストールされていることを確認します。
手順
-
プレイブックがトリガーされて実行が開始されたら、アクション 1 で、アクティビティが顧客の IP アドレスから発信されているかどうかを確認する必要があります。
パスワードスプレー攻撃を実行している IP アドレスを特定します。たとえば、アラートの TXID (トランザクション ID) を使用して、F5 ログと照合します。
-
アクション 2 では、アクティビティが顧客の IP アドレスから発信された場合に、次のアクションを実行します。
-
アクション 3 では、パスワードスプレー攻撃の可能性に関するインシデント後のレビューを開始する必要があります。
-
アクション 4 で、フローは終了します。
-
アクション 5 では、アクティビティが顧客の IP アドレスから発信されていない場合に、アラートの詳細から攻撃者のソース IP を特定します。
-
アクション 6 では、オープンソースインテリジェンス (OSINT) ツールを使用して IP レピュテーションを検証し、さらに過去 7 日間のこれらの IP からのトラフィックパターンを検証する必要があります。
図 : 1. パスワードスプレーの可能性プレイブック
-
アクション 7 では、パスワードスプレー攻撃を使用して正常にログインしたユーザー名を特定する必要があります。
-
アクション 8 では、失敗したログイン数とパターンを特定する必要があります。
-
アクション 9 では、真陽性のインジケーターを特定する必要があります。
- 過去 60 日間のソース IP からのトラフィックを確認します。履歴トラフィックは、真陽性のインジケーターにはなりません。
- 認証失敗があるユーザー名パターンとカウントを確認します。カウントが大きいほど、真陽性である確率が高くなります。
- ユーザー名は辞書ベースのように表示され (A ～ Z 順の並び) 、admin、sysadmin、root などの一般的なアドミン名が示されている場合があります
- スプレー攻撃では同じユーザー名でもさまざまなパターンがあり、同じアラートも john.doe、johnd、jdoe、john_doe、jdoe7 などでは失敗する可能性があります。これは、攻撃者が一般的なユースケースに基づいてユーザー名パターンを推測していることを示しています。
- 上記のステップの F5 ログのユーザーエージェントと URI に注目し、IOC が Red Condor アラートに関連しているかどうかを確認します。それらが一致した場合、それは真陽性のイベントです。
-
アクション 10 では、これまでに行われた調査に基づいて、これがパスワードスプレー攻撃の可能性があるケースかどうかを確認する必要があります。
-
アクション 11 で、これが「パスワードスプレー攻撃の可能性」である場合は、次のアクションを実行します。
-
アクション 12 では、適切なチームと連携して、必要なアカウントをロックアウトし、悪意のあるアクティビティを調査する必要があります。
図 : 2. パスワードスプレーの可能性プレイブック
-
アクション 13 では、パスワードスプレー攻撃の可能性に関するインシデント後のレビューを開始する必要があります。
-
アクション 14 で、フローは終了します。
-
アクション 15 では、これがパスワードスプレー攻撃の可能性があるケースでないかどうかを確認する必要があります。
-
アクション 16 で、これが「パスワードスプレー攻撃の可能性」でない場合は、次のアクションを実行します。
-
アクション 17 で、これまでの検索結果を文書化する必要があります。
-
アクション 18 では、パスワードスプレー攻撃の可能性に関するインシデント後のレビューを開始する必要があります。
-
アクション 19 で、フローは終了します。
-
アクション 20 では、同僚および GIR マネージャーに問い合わせてガイダンスを求める必要があります。
-
アクション 21 では、タスクをクローズする前にインシデントの事後レビューを完了するための応答タスクが作成されます。