Over the past several years the world of password cracking has exploded with new tools and techniques. These new techniques have made it easier than ever to reverse captured password hashes. Based on our experience, within the past few years passwords have often become the first step into compromising the entire network. New techniques such as LLMNR/NetBIOS response have reduced the efficacy of pass the hash techniques, again increasing the necessity of actually cracking the hashes. With the addition of powerful techniques, from GPGPU cracking to rainbow tables, it is easier than ever to access the plaintext for fun and profit.
Heavy utilization of GPUs has increased the power of these tools exponentially. Many organizations and individuals have built massive GPU password cracking rigs and cloud based services, such as AWS GPU instances, have also placed high performance cracking into the realm of affordability. Although the current tools do an amazing job providing heavy utilization for individual hardware, they have not kept pace with the need for distributed cracking services. Additionally, these tools can often make the sharing of expensive hardware difficult, requiring manual job tracking, GNU screen, or scripts put together to queue cracking jobs.CrackLord attempts to change this by providing a scalable, pluggable, and distributed password cracking system. Better said, CrackLord is a way to load balance the resources, such as GPUs and CPUs, from multiple hardware systems into a single queuing service. CrackLord uses two primary services: the Resource and Queue. The Resource is a service that runs on individual systems, providing access to their underlying hardware. Resources utilize various tools, such as Hashcat, John the Ripper, rcrack, or others, to run jobs and use the local CPU or GPU to crack hashes. The Queue is a service that runs on a single system, providing an interface for users to submit cracking jobs. These jobs are then processed and sent to available Resources to perform the actual crack. Users are able to create, pause, resume, and delete jobs in the Queue which will communicate with the Resource to handle the results. Finally, the system is designed to be extensible providing standard interfaces and libraries allowing new tools, resource types, and management interfaces to be written and added as necessary.