ブルートフォースのユーザー名列挙/失敗したユーザー名の試行を追跡する最良の方法
アプリケーションが存在するWindowsサーバーがあり、アプリケーションへのログイン時にドメイン資格情報を使用します。最近のペンテスト中に、テスターはアプリケーションの応答に基づいて有効なドメインユーザー名を列挙するためにアプリケーションを使用できました（無効なユーザー名と無効なパスワードでは異なる応答が返されました）。
アプリケーションは修正されているため、この情報は表示されませんが、短期間に2000,000を超える無効なユーザー名の試行があったため、この攻撃を検出する必要があったようにも思います。管理者がActive Directoryを注意深く監視していたとしても、それはわかりませんでした。どうやら障害は、アプリケーションがインストールされているサーバーのローカルイベントログにのみ表示されたようです。
私の質問：1）Active Directoryがこれらの失敗したユーザー名リクエストを中央の場所に記録して、スパイクに気付く方法はありますか？
2）そうでない場合、将来このタイプの攻撃を監視して積極的に検出するための最良の方法は何ですか（できれば、新しい機器をあまり購入する必要がないことを願います）。
ご協力いただきありがとうございます。
すばらしい質問です。
まず最初に-私は、ほとんどの「侵入テスト担当者」をスクリプトキディと見なしています。私の偏見は公平でも正確でもないかもしれませんが、私がこの免責事項を入れているのは、私の口調で皮肉を検出した場合、それがどこから来ているのかがわかるようにするためです。 no熟練したペンテスターがいるとは言っていませんが、これは私の抜本的な一般性です。
（人生のための青いチーム！）
私の質問：1）Active Directoryがこれらの失敗したユーザー名リクエストを中央の場所に記録して、スパイクに気付く方法はありますか？
誰もがこの質問に完全かつ自信を持って答えられるように、十分な情報を提供していませんでした。 あなたのアプリケーションは、攻撃者がユーザーアカウントを列挙することを可能にする欠陥を含んでいることが発見されたと言いました。 ADがyourアプリケーションのロギングを実行する必要があるとあなたがどのように感じているかを理解しようとしています。
どうやら障害は、アプリケーションがインストールされているサーバーのローカルイベントログにのみ表示されたようです。
どうやら障害はサーバーのイベントログに表示されましたか？または、障害didがサーバーのイベントログに表示されますか？もしそうなら、イベントは正確に何を言っていましたか？誰がそれらを記録しましたか？あなたの申請？またはウィンドウズ？調べに行くと、私は私の答えにさらに明確化を加えることができるかもしれません。
これらのイベントは何らかの方法でActive Directoryによってログに記録されているはずであるというあなたの推定に基づいて、ここから外に出ます...ペンテスターが実際にアプリケーションの欠陥をまったく利用しておらず、代わりにユーザー名を列挙するKerberos自体の非常によく知られた欠陥ですか？ Kerberos自体には、攻撃者が何千回もの「事前認証」の試行（つまり、ブルートフォース攻撃）を試みることができるという設計上の欠陥と考えられるものが含まれており、KDCはユーザーアカウントが存在するかどうかに応じて異なる応答をします。これはActive Directory固有の動作ではありませんが、MIT Kerberos、Heimdalなど）にも同様に適用されます。有効なユーザー名がプレフィックスなしで提示された場合、KDCはKDC_ERR_PREAUTH_REQUIREDで応答します-authデータ、実際の認証を試行しなくても。このようにして、KDCからユーザー名を列挙できます。ただし、攻撃者（またはKrbGuessなどの攻撃者が使用しているツール-ペンテスターは、使用しているときに最高の状態にあるため）他の人のツール、）は完全な認証試行を続ける必要はありません。実際の認証が試行されなかったため、何もログに記録されません！
さて、あなたの次の質問に：
2）そうでない場合、将来このタイプの攻撃を監視して積極的に検出するための最良の方法は何ですか（できれば、新しい機器をあまり購入する必要がないことを願います）。
いくつかのこと。
まず、これらの種類の攻撃を検出するように設計された有料のエンタープライズグレードの製品があります。多くのベンダーがそのような製品を提供しており、製品の推奨事項はServerfaultのトピックから外れていますが、それは発表済みです。そこ。これらの製品の多くは、ドメインコントローラーとこれらの「データコレクター」の間のポートミラーリングを構成して、ドメインコントローラーに出入りするすべてのパケットを文字どおりに表示および分析するように要求することで機能します。
（申し訳ありませんが、それはあなたの「あまりにも多くのものを買うことなく」という条項に該当します。）
あなたを助けるかもしれないもう一つは、レジストリエントリです：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
LogLevel = 1
文書化 ここ 。
このレジストリエントリを有効にすると、セキュリティイベントログのイベントでフラッディングが発生し、Kerberos事前認証が必要であることを示すKerberosエラーに関するイベントが発生します。そのようなイベントの例：
A Kerberos Error Message was received:
on logon session DOMAIN\serviceaccount
Client Time:
Server Time: 12:44:21.0000 10/9/2012 Z
Error Code: 0x19 KDC_ERR_PREAUTH_REQUIRED
Extended Error:
Client Realm:
Client Name:
Server Realm: DOMAIN
Server Name: krbtgt/DOMAIN
Target Name: krbtgt/DOMAIN@DOMAIN
Error Text:
File: e
Line: 9fe
Error Data is in record data.
しかし、Kerberos要求の津波がどこから来ているのか正確に特定されていない場合、これは役立つかもしれません。これにより、前述のエンタープライズ侵入検知製品に戻ります。
また、サーバーがイベントを一元管理された場所に転送して、自由に使用できるツールで分析できるようにするWindowsイベント転送を忘れないでください。
この回答全体はこれまでのところKerberosプロトコルに基づいていますが、投稿の詳細がほとんどないため、私はこれを当然のことと考えることもできません。それにもかかわらず、これが少なくとも少しは役立つことを願っています。
これは私が適切な答えを聞きたいと思う興味深い質問です。 Dougが役立つと思われるいくつかの情報に出くわしましたが、少し不十分かもしれません。他の誰かがおそらく拡張された答えを提供できます：
監査情報を保存するサーバーにログインします実行-> RSOP.MSC->コンピューターの構成-> Windows設定->セキュリティ設定->ローカルポリシー->監査ポリシー- >「監査アカウントログオンイベント」および「監査ログオンイベント」
「アカウントログオンイベント」の説明は次のとおりです。
アカウントログオンイベントの監査
このセキュリティ設定は、このコンピューターがアカウントの資格情報を検証するたびにOSが監査するかどうかを決定します。
コンピューターが権限のあるアカウントの資格情報を検証するたびに、アカウントログオンイベントが生成されます。ドメインメンバーおよびドメインに参加していないコンピューターは、ローカルアカウントに対して権限があります。ドメインコントローラーはすべて、ドメイン内のアカウントに対して権限があります。資格情報の検証はローカルログオンをサポートしているか、ドメインコントローラー上のActive Directoryドメインアカウントの場合は別のコンピューターへのログオンをサポートしている可能性があります。資格情報の検証はステートレスであるため、アカウントログオンイベントに対応するログオフイベントはありません。
このポリシー設定が定義されている場合、管理者は、成功のみ、失敗のみ、成功と失敗の両方を監査するか、これらのイベントをまったく監査しない（つまり、成功も失敗もしない）かを指定できます。
「ログオンイベント」の説明は次のとおりです。
ログオンイベントの監査
このセキュリティ設定は、OSがこのコンピューターへのログオンまたはログオフを試みるユーザーの各インスタンスを監査するかどうかを決定します。
ログオンしたユーザーアカウントのログオンセッションが終了するたびに、ログオフイベントが生成されます。このポリシー設定が定義されている場合、管理者は、成功のみ、失敗のみ、成功と失敗の両方を監査するか、これらのイベントをまったく監査しない（つまり、成功も失敗もしない）かを指定できます。
失敗した試行のみを監視したい場合は、基本的にそれらのポリシーを有効にし、ポリシー設定を定義し、「失敗」を選択する必要があります。必要に応じて、成功を監視することもできますが、この種の攻撃を探すことだけを心配している場合は、解析が少し難しくなる可能性があります。
システムが脆弱である可能性のある同様の構成が心配な場合は、STIG設定（ link ）を確認することをお勧めします。SCAPスキャナーと組み合わせて使用すると、いくつかの強調表示に役立ちます組織が直面しているリスク。 STIGビューアはいくつかの誤検知を発生させる傾向がありますが、各問題の詳細を読んだ場合、それは初心者ではないかもしれません。