Windows10が、2016年7月（Windows 10 v1607）のアップデートで、それまでのハッシュの暗号化方法が、RC4からAESに変更されました。
これに伴い、VolatilityやMetasploitの hashdump で得られる解析結果にどのような影響がでるか確認してみました。
Windowsフォレンジックの基礎としては知っているものの、このハッシュ値を使って何かをする用事もなかったので、実際に使うことはほとんどありませんでした。
（クレデンシャル情報を抜いてやらなきゃいけない調査ってないし・・・）
ただ、7payの事件で認証関係の問題が大きく取り上げられたことや、今週のデジタルフォレンジックの講習会（なんか私が話すらしい？）でデモをするにあたり、認証関係をちょっと使うので、Windowsの認証関係も復習してみた、というわけです。
すると、以前できていたことが上手くいかなかったこともあったので、その検証結果をメモしておきます。
新しいWindows10のhashdumpの解析
以前書いた「SANS SIFTのVolatilityの更新」で、Windows10（v1607以降）からハッシュを出力しました。
このハッシュはNTLMハッシュの「はず」なのですが、どうもこれが正しくない、という可能性がありました。
以下の図は、「hashtest」のユーザとそのハッシュ値を、 Volatility の hashdump で出力した結果です。
パスワードは「X2ugd7」という脆弱なものを使用しています。
これが正しいならば、パスワード解析ツールで解読できるはずだと考えました。
そこで、Kali Linux にインストールされている hashcat で解析してみました。
すると、解析失敗してしまいました。
Windows7のhashdumpの解析
解析方法が間違っているのか？ということで、Windows7マシンにテスト用ユーザを作り、そのユーザに同じパスワード「X2ugd7」を設定し、メモリダンプを取得しました。
以下の図は、このWindows7のメモリダンプから「test」のユーザとそのハッシュ値を、 Volatility の hashdump で出力した結果です。
ソルトのないNTLMのハッシュ値は同じ値になるのではないか、と予想していたのですが、結果は異なりました。
これが正しいかどうか、 hashcat で同様に解析してみました。
なお、コマンドラインで --force オプションを使っているのは、Kali Linux がVMでGPUがなく、かつ OpenCL もインストールしていないので、OpenCL Device Typesが指定できなかったためです。また、-a 3 は Brute-force モード、-m 1000 はNTLM形式を指定しています。
（詳しくはヘルプページ参照。 https://hashcat.net/wiki/doku.php?id=hashcat ）
hashcat --force -a 3 -m 1000 16467c20eda2bb5a7059c33b7e74f216
結果は、上の図の赤線のとおり、解析が成功しパスワードが判明しました。
逆に言えば、パスワード「X2ugd7」のNTLMハッシュは「16467c20eda2bb5a7059c33b7e74f216」が正しいとも言えると思います。
本当は、Windows10の hashdump の結果で同じ結果を得られると思っていたのですが。
これらから、Windows10（v1607以降）のメモリダンプから Volatility の hashdump で得られるハッシュ値は NTLM ハッシュではないか、正しく取得できてないものと思われます。
この理由は色々調べてみましたが、出力されているハッシュが別の形式なのか、旧形式で解析してしまいおかしい値になっているかは分かりませんでした。
これについては、理由が分かったら追記したいと思います。
これらのハッシュ値を使って pass-the-hash ができるかを検証した結果は、次回書きたいと思います。
（すいません、ちょっと長くなってきたので、度々やらかすブッタ切りです・・・）