web-dev-qa-db-ja.com

LM（Lan Manager）ハッシュ-ブルートフォースの失敗

Hashcatで解読しようとしているLMハッシュがいくつかあります。私の理解では、LMはパスワードをハッシュする前に2つの7文字の文字列に分割しました。また、大文字、数字、特殊文字のみを使用していると思います。

Hashcatで次のコマンドを実行しようとしました：hashcat64.exe -m 3000 -a 3 lm-out.txt -1 ?u?d?s --increment ?1?1?1?1?1?1?1

これにより、1〜7文字のLMの許容文字とのあらゆる組み合わせがブルートフォースになるはずですが、これを実行して完了した後、すべてのパスワードの0.20％しか回復していません。

誰かが私にこれに光を当てることができるかどうか疑問に思っていましたか？ hashcatの特殊文字マスクにポンド記号が含まれていないことは知っていますが、なぜパスワードの99％以上がこのようにブルートフォースされないのか理解できません。一部が単純な単語として復元されたという事実は、ハッシュされる前にそれらが何らかの方法で変更されることはできないと私に信じさせます。

（また、私はサイバーセキュリティで働いているので、これは決して「ブラックハット」リクエストではありません！）

Hashcat.net/wiki/doku.php?id=example_hashesのサンプルハッシュを試して、Roryが示唆するように、ハッシュが破損する問題を除外しましたが、ハッシュから約20個のパスワードを抽出できました。ハッシュが破損していないか、何らかの方法でセキュリティの追加レイヤーが存在しないと思います。これは、ほとんどのハッシュだけでなく、すべてのハッシュに影響するのでしょうか。

すべてのハッシュは、同じスクリプトによってNTDS.ditファイルから一度に抽出されたので、すべて正常であるか、またはすべて破損していますか？その提案を誤解していない限り？

ロイスの答えに関連して（包括的な応答をありがとう）：

  • ポンドと言うと、私は実際には英語なので、文字通り「＃」ではなく「£」記号を意味します。 hashcat wikiで特殊文字の文字セットを確認したところ、「£」記号がそのリストに表示されませんでしたか？英語のハッシュダンプでもあるので、それが問題なのだろうか？混乱をお詫びします！

  • クラックされたハッシュについて-最初の部分はすべて7、2番目の部分は空白、または最初の部分は7、2番目の部分は1-6です。それらは！付きの英数字です。唯一の特殊文字として。それらは実際の単語、または文字ではなく数字でマングルされた単語です。

  • もうターゲットシステムにアクセスできませんが、確かに一部のハッシュがクラックされているという事実は、問題がアプローチにあり得ないことを意味しますか？機能したものは同じ方法で抽出されたという意味ですか？

  • システムのデフォルトのコードページ/文字セットを見つける方法がわからないので、システムにアクセスできなくなったので、それに答えられるかわかりません。 Hashcatが米国を想定している場合に問題を引き起こす可能性のある英国英語と米国英語の間に違いはありますか？

  • パスワードをNTLMとして保存することを強制するALT文字が使用された場合、これらのパスワードのすべてのLMハッシュが1つの標準的な「空白」ハッシュに置き換えられないのですか？クラックされていないすべてのハッシュが異なるため、これは私を混乱させてきたものです。つまり、それらは異なる値のハッシュであると想定しました。また、ユーザーの99％以上がパスワードに標準的ではない文字を使用しているとは考えにくいと思っていました。 （特に解読されたパスワードが与えられた！）

  • ハッシュを抽出するために、ボリュームシャドウコピーを作成し、NTDS.ditとSYSTEMを取得しました。次に、esedbexportを使用してテーブルを抽出し、ntdsxtract（具体的にはdsusers.py）を使用してハッシュを抽出しました。これはかなり標準的なルートだと思いますが、ツールへのリンクを投稿したり、明確にしたい場合は、そこでの私のプロセスに関するより正確な情報を投稿したりできます。

繰り返しますが、私を投げ続けているのは、ハッシュのsomeが割れているため、このプロセスでエラーが発生した場合、またはシステムの文字セットを使用した場合でも、シングルハッシュ意味不明？

ご協力ありがとうございます。ロイス、ありがとうございました。

（また、LMの下位互換性についてアドバイスすることは、すでに私たちがすでに行っていることです！）

hashhashcat
4
Chris

まず、あなたのメタ質問に対するいくつかの答え：

  • hashcatは確かに7文字の分割を理解し、それに応じて最適化します。

  • hashcatは、LMが大文字と小文字を区別しないことも知っているため、攻撃の速度を変更せずにカスタム文字セットを削除できます。

  • Hashcatの？の文字セットに '＃'が含まれていないという考えがどこにあるのかわかりません。それは間違いなく：

    $ hashcat --help | egrep ' s .*#'
  s |  !"#$%&'()*+,-./:;<=>?@[\]^_`{|}~

私はこのアプローチがすべての有効な7ビットASCIIハッシュを取得することを期待します：

$ hashcat -m 3000 -a 3 -i lm.hashlist ?a?a?a?a?a?a?a

次に、答えのいくつかのアイデア：

  • 実際にクラックされたハッシュのリストに、文字セット、長さ、パターンなどの共通点はありますか？これは何が欠けているかについての手掛かりを与えるかもしれません。

  • ターゲットシステムに既知のパスワードを設定する機能はありますか？その場合、既知の平文に対して直接アプローチを検証できます。

  • ターゲットシステムのデフォルトのコードページ/文字セットは何ですか？英語/ Windows-1252 でない場合、 物事は複雑になります -ハッシュへの変換中に、システムは文字列をOEMに変換します コードページ 。

  • ALT文字 がパスワードに使用されている場合、 一部はLMパスワードで機能し、その他は機能しません 。次のALT文字はLM互換ではありません。これらのALT文字を使用すると、LMがシステムのデフォルトであっても、パスワードはNTLMとしてのみ保存されます。

0128-0159 0306-0307 0312 0319-0320 0329-0331 0383 0385-0406 0408-​​0409 0411-0414 0418-0424 0426 0428-0429 0433-0437 0439-0447 0449-0450 0452-0460 0477 0480-0483 0494-0495 0497 -0608 0610-0631 0633-0696 0699 0701-0707 0709 0711 0716 0718-0729 0731 0733-0767 0773-0775 0777 0779-0781 0783-0806 0808-0816 0819-0893 0895-0912 0914 0918-0919 0921-0927 0929- 0930 0933 0935-0936 0938-0944 0947 0950-0955 0957-0959 0961-0962 0965 0967-1024

たとえば、これはhashcaによってクラックされた「cañon」のLMハッシュです（免責事項：Windows VMを使用してALTキーエントリメソッドを使用して文字列を生成し、次に John the Ripperのpass_gen.pl ハッシュする）：

272a43bc1fe85832:$HEX[4341a54f4e]

これをutf-8対応システムで複製しようとすると、代わりにこの結果が得られますが、これはWindowsがデータ入力を処理する方法ではありません。

de3fa2be44e8af61:CAñON (which is 41 43 b1c3 4e 4f)

私はこのアプローチがそれらのいくつかを拾うことを期待します：

$ hashcat -m 3000 -a 3 -i lm.hashlist ?b?b?b?b?b?b?b

ただし、ALT文字の使用は比較的まれです。パスワードハッシュの実際のエンタープライズリストを監査している場合は、次にハッシュ抽出スクリプトの有効性を調べます。あなたがそれについてもっと投稿したなら、私はもっと助けようとすることができます。

（また、LMの下位互換性は現代の企業では不要であり、監査人として 無効にすることをお勧めします。 ）

5
Royce Williams