パスワードスプレー攻撃がまた流行っている様です。オーストラリアの国立セキュリティセンター（ACSC)が警戒記事を出していました。
www.security-next.com
公式発表 Advisory - 2019-130: Password spray attacks – detection and mitigation strategies
パスワードスプレー攻撃は、一般的に用いられることが多い安易なパスワードを使用しつつも、特定のIDに対する連続攻撃を避け、アカウントのロックを避けつつ、ログインを試行する攻撃手法。「low-and-slow攻撃」や「リバースブルートフォース攻撃」などと呼ばれることもある。
同じIDに対してログインの試行を連続して行わず、大量に用意したリストに対して単一のパスワードを試行していくことで特定のIDに対する攻撃間隔を広げてシステムにおける異常検知などを回避。同一組織内で大量のエラーが集中しないよう、組織横断的なリストが用いられるケースもある。
同センターによると、オーストラリア国内の組織に対する大規模なパスワードスプレー攻撃が展開されているという。外部へ公開されている「ウェブメール」や「リモートデスクトップアクセス」「Active Directoryフェデレーションサービス（ADFS）」などが標的となっていた。
（Security Next記事より引用）
◆キタきつねの所感
パスワードスプレー攻撃は従来の攻撃パターンと少し違うので、防衛側が検知しずらい傾向がある攻撃と言えます。例えば
ID=abc@fox.com, パスワード＝password （ログイン失敗）
ID=bcd@fox.com, パスワード=password （ログイン失敗）
ID=cde@fox.com, パスワード=password （ログイン成功）
・
・
・
といった試行をする様な攻撃なのですが、abc@fox.comやbcd@fox.comは、ログイン試行失敗が1回なので、正規のアクセスとの区別がつきずらくなります。長く時間をかけて、ログイン試行をしてくる事も多いので、短時間にログイン失敗のログを検知する、といった良くある検知がしずらいのが特徴です。
今年前半にもシトリックスなどへの攻撃、あるいはスプレー攻撃への注意喚起記事が出ていたかと思います。
foxsecurity.hatenablog.com
対策部分についてどう書いてあるのかな・・・と興味があったので、Security Next記事では概要しか書かれてなかったので、元ソース（オーストラリア国立セキュリティセンター）の注意喚起を見てみました。
※比較的Google翻訳が読みやすく訳してくれたので、参考まで貼っておきます。
推奨事項
検出
パスワードスプレー攻撃を検出する可能性を高めるため、ACSCは、以下の状況において、組織がセキュリティ情報およびイベント管理（SIEM）ソリューションなどでアラートルールを作成することを推奨しています。
定義された期間内の多数の認証試行
通常、パスワードスプレー攻撃中、一定期間（1時間など）の試行失敗回数は、通常のログイン失敗イベントよりも大幅に多くなります。悪意のあるサイバー攻撃者は、システムまたはサービスのデフォルトのロックアウトしきい値または予想されるロックアウトしきい値に基づいて、設定された数のログインを試みる可能性があります。クラウドベースのサービスのログを確認している場合、組織のIPアドレス範囲を除外すると、検索を絞り込むのに役立ちます。ACSCは、場合によっては、ユーザーアカウントのログインに対するパスワードスプレーがアルファベット順に試行されていることにも気付きました。
多数の不正なユーザー名
パスワードスプレー攻撃の中には、一般的なユーザー名リストまたはユーザー名ジェネレーターを使用して試行されるものがあります。このような手法の脅威は、システムで使用されるユーザー名の命名ポリシーに依存しています。組織が利用するほとんどのシステムは標準の命名規則を使用するため、この手法を検出し、それによってもたらされる脅威を容易に評価できます。
定義された期間にわたる多数のアカウントロックアウト
スプレーの方法によっては、一部のアクターはロックアウトポリシーを考慮または認識せずにアカウントごとに複数のパスワードを試行し、企業アカウントがロックアウトされる可能性があります。ADFSを使用した組織でのサービス拒否を防ぐには、Windows Server 2016でスマートロック機能を実装することを検討する必要があります（Microsoftガイダンス「Windows Server 2016のエクストラネットスマートロックアウト機能の説明」を参照）。
I nは、マイクロソフトのクラウドインフラストラクチャを使用する場合は、Active DirectoryのPowerShellのアズールで認証標準ユーザーレビュー
のOffice 365での標準コントロールは、すべてのユーザーがあなたのMicrosoftのAzureサービスでの認証にPowerShellを使用することを可能にします。これにより、アクターはクラウドでホストされているアクティブディレクトリを自動的に列挙し、追加のアカウントに攻撃を仕掛けたり、その情報を使用してより洗練されたスピアフィッシングメールを作成したりできます。Azure Active Directory PowerShellを使用してサービスとやり取りする正当な目的はありますが、標準の非管理者ユーザーにとってこのような使用法は予想外です。Azure Active Directoryのログの場合、ユーザーが「appDisplayName：Azure Active Directory PowerShell」で認証している場合、これを特定できます。
IPアドレスごとのログイン成功とログイン失敗の比率を見ると、
多くの場合、スプレー攻撃は成功よりも多くの失敗をもたらします。検出を回避しようとしてパスワードスプレー攻撃が長期間にわたって発生している場合、IPアドレスごとに失敗と成功の比率を調べ、IPのログイン失敗率が非常に高いかどうかを判断できます。
（ACSC注意喚起より引用）※機械翻訳
個人的に効果があると思うのが、多要素認証などを導入する根本策を別にして、
①一定時間内のログイン試行失敗（ログ）の監視
②パスワード試行がアルファベット順のパターン検知
③IPアドレス毎のログイン失敗の検知
④海外IPからのログイン試行数の増加監視
辺りが有効だと思います。特に海外に直接シッピングをしてない、日本の会員向けのサービスしている企業は、海外IPからのアクセス数が急増する事は稀かと思いますので、そこの監視を強めるだけでも大分、攻撃検知が早くなるのではないかと思います。
海外IPからは、場合によって追加認証を要求できれば（その次は日本のIPを偽装してくるとは思いますが・・）手ごわいとみて、違うサイトに移動する攻撃者が多いのではないでしょうか。
オーストラリアで攻撃傾向が強まったという事は、恐らく同じ攻撃が日本へもされると考えて対策をしておいた方が無難かと思います。
■日本人のためのパスワード2.0 ※JPAC様 ホームページ
7/8に日本プライバシー認証機構（JPAC)様からホワイトレポートをリリースしました。キタきつねとしての初執筆文章となります。「パスワードリスト攻撃」対策の参考として、ご一読頂ければ幸いです。
更新履歴