Real pentesting doesn’t always look like the tutorials. Sometimes you’re mid-engagement, digging through an exposed directory, and you find something that makes you stop and think: that really shouldn’t be here.
That’s exactly what happened here.
The scenario
During a client engagement, an undisclosed directory was discovered on an HTTP server — the kind of thing that only shows up if you’re thorough with your enumeration. Inside it: the client’s SSL private key.
Finding an exposed SSL private key is already a significant finding on its own. A private key lets an attacker decrypt HTTPS traffic captured between the server and its users — past and future — depending on the cipher suite in use. In the wrong hands, it’s a serious compromise of confidentiality.
There was one problem: the key was password-encrypted. Without the passphrase, it couldn’t be used directly. The certificate file was there, but locked.
So a tool was written to unlock it.
What the tool does
It’s a shell script that runs a dictionary attack against a password-protected SSL private key using openssl. The logic is straightforward: take a wordlist, attempt to decrypt the key with each passphrase in turn, and stop when one works. Simple, focused, and built to solve a specific problem encountered in the real world.
No frills. Does the job.
The script is available here:
https://raw.githubusercontent.com/nullsecuritynet/tools/master/cracker/ssl-crack/release/ssl-crack.sh
Two findings, not one
It’s worth pausing on what this scenario actually represents from a reporting perspective, because there are two separate issues at play here.
The first is the exposed directory itself — an access control failure that allowed an unauthenticated or unauthorised user to browse to files that should never be publicly accessible. That’s the root cause.
The second is the weak passphrase protecting the key. An SSL private key should be protected with a strong, randomly generated passphrase. If a dictionary attack cracks it in any reasonable timeframe, the passphrase isn’t doing its job.
Both get reported. Neither excuses the other. The exposed directory is the entry point; the weak passphrase is what turns a bad situation into a worse one.
For the lab
If you want to practice this in a controlled environment — which you should before you need it on a real engagement — generate your own password-protected key with openssl, set a passphrase you know is in a common wordlist like rockyou.txt, and run the script against it. Watch it work. Then understand what would have stopped it: a strong passphrase, a properly restricted directory, or ideally both.
The tool is the easy part. Understanding the conditions that made it necessary is what you take into your next engagement.