ブルートフォースのユーザー名の列挙/失敗したユーザー名の試行をADで追跡する最良の方法


9

アプリケーションが存在するWindowsサーバーがあり、アプリケーションへのログイン時にドメイン資格情報を使用します。最近のペンテスト中に、テスターはアプリケーションの応答に基づいて有効なドメインユーザー名を列挙するためにアプリケーションを使用できました(無効なユーザー名と無効なパスワードでは異なる応答が返されました)。

アプリケーションは修正されているため、この情報は表示されませんが、短期間に2000,000を超える無効なユーザー名の試行があったため、この攻撃を検出する必要があったようにも思います。管理者がActive Directoryを注意深く監視しているときでも、それはわかりませんでした。どうやら障害は、アプリケーションがインストールされたサーバーのローカルイベントログにのみ表示されたようです。

私の質問:1)Active Directoryがこれらの失敗したユーザー名要求を中央の場所に記録して、それらのスパイクに気付く方法はありますか?

2)そうでない場合、将来このタイプの攻撃を監視して積極的に検出するための最良の方法は何ですか(できれば、新しい機器をあまり購入する必要がないことを願います)。

ご協力いただきありがとうございます。

回答:


11

すばらしい質問です。

まず最初に-私は、ほとんどの「侵入テスター」をスクリプトキディと見なしています。私の偏見は公平でも正確でもないかもしれませんが、私がこの免責事項を入れているのは、私の口調で皮肉を検出した場合、それがどこから来ているのかがわかるようにするためです。熟練したペンテスターがないと言っているわけではありませんが、これは私の広範な一般性です。

(人生のための青いチーム!)

私の質問:1)Active Directoryがこれらの失敗したユーザー名要求を中央の場所に記録して、それらのスパイクに気付く方法はありますか?

誰もがこの質問に完全かつ自信を持って答えられるように、十分な情報を提供していませんでした。あなたのアプリケーションには、攻撃者がユーザーアカウントを列挙することを可能にする欠陥が含まれていることが判明したと述べました。ADがアプリケーションのロギングを実行する必要があるとあなたがどのように感じているかを理解しようとしています。

どうやら障害は、アプリケーションがインストールされたサーバーのローカルイベントログにのみ表示されたようです。

どうやら障害はサーバーのイベントログに表示されましたか?または、サーバーのイベントログにエラー表示されましたか?もしそうなら、イベントは正確に何を言っていましたか?誰がそれらを記録しましたか?あなたの申請?またはウィンドウズ?調べに行くと、私は私の答えにさらに明確化を加えることができるかもしれません。

これらのイベントは何らかの方法でActive Directoryによってログに記録されているはずであるというあなたの推定に基づいて、ここから外に出ます...ペンテスターが実際にアプリケーションの欠陥をまったく利用しておらず、代わりにユーザー名を列挙するKerberos自体の非常によく知られた欠陥ですか?Kerberos自体には、攻撃者が何千回もの「事前認証」の試行(つまり、ブルートフォース攻撃)を試みることができるという設計上の欠陥と考えられるものが含まれており、KDCはユーザーアカウントが存在するかどうかによって異なる応答をします。これはActive Directory固有の動作ではありませんが、MIT Kerberos、Heimdalなどにも同様に適用されます。KDCは次のように応答しますKDC_ERR_PREAUTH_REQUIRED実際の認証を試みなくても、有効なユーザー名が事前認証データなしで提示された場合。このようにして、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プロトコルに基づいていますが、投稿にはあまり詳細を記載していなかったので、私はこれを当然のことと考えることもできません。それでも、これが少なくとも少しは役に立てば幸いです。


お返事をありがとうございます。月曜日に再確認しますが、イベントログはローカルサーバーへのログインに失敗した場合の標準のWindowsイベントだと思います(例:無効なユーザー名でRDP経由でログインに失敗した場合と同じです)。そのアプリケーション固有のものは間違いありません。Kerberos認証の列挙では、ペンテスターがローカルイントラネット上にいる必要があると思います。彼らは、〜でなかった。アプリケーションは、OSを内部で呼び出す標準のフォームベースの認証を使用してインターネット上で公開されています。
Doug

0

これは私が適切な答えを聞きたいと思う興味深い質問です。Dougが役立つと思われるいくつかの情報を見つけましたが、少し不十分かもしれません。他の誰かがおそらく拡張された答えを提供できます:

監査情報を保存するサーバーにログインします。 実行-> RSOP.MSC->コンピュータの構成-> Windows設定->セキュリティ設定->ローカルポリシー->監査ポリシー->「アカウントログオンイベントの監査」&「ログオンイベントの監査」

「アカウントログオンイベント」の説明は次のとおりです。

アカウントログオンイベントの監査

このセキュリティ設定は、このコンピューターがアカウントの資格情報を検証するたびにOSが監査するかどうかを決定します。

コンピューターが権限のあるアカウントの資格情報を検証するたびに、アカウントログオンイベントが生成されます。ドメインメンバーおよびドメインに参加していないコンピューターは、ローカルアカウントに対して権限があります。ドメインコントローラーはすべて、ドメイン内のアカウントに対して権限があります。資格情報の検証はローカルログオンをサポートしている可能性があります。または、ドメインコントローラー上のActive Directoryドメインアカウントの場合は、別のコンピューターへのログオンをサポートしている可能性があります。資格情報の検証はステートレスであるため、アカウントログオンイベントに対応するログオフイベントはありません。

このポリシー設定が定義されている場合、管理者は、成功のみ、失敗のみ、成功と失敗の両方を監査するか、これらのイベントをまったく監査しない(成功も失敗もしない)かを指定できます。

「ログオンイベント」の説明は次のとおりです。

ログオンイベントの監査

このセキュリティ設定は、このコンピューターへのログオンまたはログオフを試みるユーザーの各インスタンスをOSが監査するかどうかを決定します。

ログオンしたユーザーアカウントのログオンセッションが終了するたびに、ログオフイベントが生成されます。このポリシー設定が定義されている場合、管理者は、成功のみ、失敗のみ、成功と失敗の両方を監査するか、これらのイベントをまったく監査しない(成功も失敗もしない)かを指定できます。

失敗した試行のみを監視する場合は、基本的にこれらのポリシーを有効にし、ポリシー設定を定義して、「失敗」を選択する必要があります。必要に応じて、成功を監視することもできますが、この種の攻撃を探すことだけを心配している場合は、解析が少し難しくなる可能性があります。

システムが脆弱になる可能性のある同様の構成について懸念がある場合は、STIG設定(リンク)を確認することをお勧めします。SCAP スキャナーと組み合わせて使用​​すると、組織が持つ可能性のあるリスクを強調するのに役立ちます。直面しています。STIGビューアはいくつかの誤検知を発生させる傾向がありますが、それぞれの問題の詳細を読むと、それが最初ではない場合があります。


1
MSFTまたはnistベースラインをお勧めします。DISAは、ホストをエンティティとして保護するのではなく、環境について想定します。はい、適切な監査が必要です。また、Active Directoryのセキュリティを保護するためのベストプラクティスのホワイトペーパーも読みます。
ジムB

すばらしい点、ジムB!私はその側面を考慮していませんでした。
Sawta 2016年
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.