When we plan for the future of Impact we have a simple goal in mind; we want to our allow our users to step into the shoes of their advisory; adopt the mindset of the attacker, and perform the attackers actions (all in a safe repeatable way, of course). These simple goals becomes quite complex when you understand that our customers are not all the same. Some are dedicated security professionals, facing people who are dedicating large amounts of resources to compromising their network. Others have plenty of non-security related concerns; and are only able to focus on security a few hours a week. With our wizards and modules, Impact is able to cater to both groups. To help ensure we are meeting these needs of both groups we spend a lot of time trying to understand our customers and non-customers alike. Whether it is through customer calls, customer visits; attending and presenting at tradeshows or through our own research we are always striving to gain as much knowledge as we can. We have internal resources as well that I can turn to. Not everyone knows but Core started as a consulting company (and Impact was built internally for us by our testing team). I am lucky to have our own Security Consulting Services (SCS) team to talk to about trends we are seeing and their experiences in perform world class penetration tests in new security areas. Core CloudCypher was born out of one of those conversations, and a lot of existing work already done by the SCS team. During the course of their engagements they often are able to get access to encrypted passwords and  know if they can convert them to clear text, they can either reuse those passwords or demonstrate to their client the weaknesses of the passwords used. However, if you have looked into password cracking you know that you need a lot of processing power and terabytes of dictionaries and tables to stand a good chance of cracking a password. Not exactly the type of things you can pack in your carry-on and take to a client site. So SCS did what they always do when a solution doesn’t exist for a problem they have; they built what they needed. Then then approached me with their solution and proposed that the value they are getting from their implementation would also be something that our customers would appreciate. It really was one of the simpler decisions I had to make. And with that we started working on phase 1, a windows password cracking solution hosted in Amazon’s infrastructure. It accepts hashes from copies of Impact that have subscribed to our service; attempts to crack the hash to determine the plaintext password and then returns the password to Impact. When you host a service of this nature people naturally want to be assured that the service is secure; this was our first concern as well. We have implemented a number of measures to protect this data, here is an overview and I am happy to provide more detail to anyone who contacts me:

  • There is mutual authentication between Impact and the CloudCypher services; to prevent MitM attacks
  • Only the password hash is sent to the service (no username or target machine information is transmitted)
  • Only the workspace that submitted the hashes can retrieve the results
  • When results are retrieved they are deleted
  • If results are not retrieved within four days they are deleted

CloudCypher is not a silver bullet; but initial usage indicates it will crack the vast majority of passwords used by most user populations. Each hash will be worked on for a few hours and go through a multi-stage process of:

  • 30 million+ dictionary list, compiled from publically disclosed password breaches.
  • Rainbow tables made up of a variety of letter, number and special character combinations
  • Statistical Brute force attack

Any clear text passwords returned are passed to the Identity Manager; and so can be immediately reused across all applicable machines in your test environment. Not only can the service be used to take your testing even further; but you can also use it to demonstrate that even though you have a complex password policy; not all of your users are implementing complex passwords (something I have found managers don’t always seem to be able to grasp). So as an organization you could have a password policy that says a password must:

  • Have at least one capital letter
  • At least one number
  • At least one special character
  • Be longer than 8 characters

If all your users implement passwords like P4ssword! – which meets the letter of the password policy; you haven’t really gained too much security. I look forward to hearing new war stories from our customers around their usage of CloudCypher next time I visit with you. Alex Horan, Senior Product Manager.