search

openwall / john

John the Ripper jumbo - advanced offline password cracker, which supports hundreds of hash and cipher types, and runs on many operating systems, CPUs, GPUs, and even some FPGAs
https://www.openwall.com/john/
Other
10.39k stars 2.11k forks source link

pcap2john.py: Add support for extracting NTLMv2 hashes #4212

Open AlbertVeli opened 4 years ago

AlbertVeli commented 4 years ago

Description

Feature request. Add support for NTLMv2 in the pcap2john.py script.

Steps to reproduce

It is possible to open the pcap in wireshark and extract it manually using the method described here:

https://research.801labs.org/cracking-an-ntlmv2-hash/

But it would be nice if pcap2john could do it too.

System configuration

Tried with python2.7 and dpkt/scapy installed through pip.

Also, a separate issue but it might be fixed at the same time. The pcap2john.py script only works with python2. It should be fixed so it works with python3 and python2. New distributions have python3 as default.

solardiz commented 4 years ago

@exploide Maybe you could help with one or both of these issues: Python 3 compatibility and NTLMv2 support in pcap2john.py? Thanks!

exploide commented 4 years ago

That's a large script. Luckily there is a repo with test data: https://github.com/kholia/my-pcaps/ It contains a lot of captures (which is good and bad at the same time :laughing: ).

I can take a look at Python 3 compatibility. I don't know in advance how much work it is and cannot promise anything.

exploide commented 4 years ago

I had a first look and need to say it would be quite a substantial amount of work to do. The code is long and complex because it supports to many different types of protocols. To be honest it looks hard to maintain this script. For example, the packet parsing libraries scapy and dpkg are intermixed there. I think I understand why, since the script is basically a merge of multiple former stand-alone scripts, and that's what happens over time.

Then, when running on non-trivial capture files, the script is really slow. This is because each pcap file with all of the contained network packets is parsed again by each of the extraction functions. A great speed up could be achieved by applying scapy filters early and passing the packet only to the relevant extraction function.

This however, would be similar to a rewrite of the script. I don't think I currently have the necessary amount of time for that. And even don't know if it is worth it. There are already pcap credential extraction tools, like for example PCredz and hcxtools.

solardiz commented 4 years ago

Thanks @exploide! So the functionality requested here by @AlbertVeli - dumping of NTLMv2 network hashes - is already supported by PCredz (NTLMv2 is specifically mentioned) and probably also by hcxtools ("netntlm" is mentioned). Since our pcap2john.py is less consistently written, it feels weird to be adding functionality that already exists in those tools to there.

We could maybe bundle PCredz in JtR jumbo (and then keep it updated), since it's just a reasonably sized Python script rather than a larger multi-file project. Or/and at least we should refer to these tools from some expected place in JtR documentation (where would that be?)

If we include PCredz, would it cover 100% of functionality of current pcap2john.py (and more)? Should we drop pcap2john.py if so?

AlbertVeli commented 4 years ago

PCredz also seems to be out of date. It is written in python2 and the prerequisite pylibpcap can't be installed through pip and also seems to support only python2. To get it going you have to:

pip2 install --user http://downloads.sourceforge.net/project/pylibpcap/pylibpcap/0.6.4/pylibpcap-0.6.4.tar.gz

When I tried it just now I provided a pcap that works when I extract the NTLMv2 information manually, but when provided to PCredz it didn't find anything.

exploide commented 4 years ago

True.. And then there is net-creds, another tool for the same purpose. Also Python2 only and boroughs some code from PCredz.

They do not cover all the functionality of pcap2john.py. The latter supports some of the more exotic protocols.

It all is a mess. I love the open source community, but I hate it that the wheel gets reinvented so often. I'm close before writing a new tool and... reinvent the wheel :roll_eyes: No...

But when, maybe it would be good to rely for parsing on scapy, which is most actively maintained, or pyshark, which can use the existing Wireshark dissectors.