help identify algo from kerio connect
trying to decrypt mail user passwords generated by kerio connect.
I'm new to this stuff and dont know how to identify which algo is used.

I've created 3 users with same password(123456) and hashed outputs I get are salted:

If they store the passwords locally they seem to use "the strongly secure SHA format" 

[Image: add_user.png]

They don't specify how they mangle/salt/alter the hash. They can do this in an infinte amount of ways, so it will be difficult to guess how they do it based only on 3 users with the same password.

They also seems to offer database wide encryption:

It is unclear how they make this encryption. But your string start with D3S, this might refer to Triple DES or just DES.

I tried to download the application and look if decompilation is an option (if it was a .net or Java application), but I get the error "Error 28103" when installing. But I think you need more information than 3 accounts with the same passwords.
Looks weird. Maybe it's coincidence that they all start with "3" but I'm not sure. Also the last part is fixed. Actual data is 32 characters, fixed part is 16 characters. That doesn't match any normal SHA checksum length. Either it's truncated SHA (whatever version) or it's not SHA at all.
I just ran mdxfind for any supported hash, using '123456' as the only input - up to 2M rounds, with extended truncation search - against those hashes both with and without the static component. In theory, this would cover many different types and subtypes of hash. No hits.

I'd be curious in what kinds of hashes are generated if that "Store password" box is checked or unchecked.

According to :

Quote:Version 8.4.0 October 14, 2014
* Passwords are now always stored in MS-CHAP v2 compatible format for Local users

Given the apparent normal integration of Kerio w/LDAP, I thought it could be LDAP SHA:

$ echo "123456" | passthrough 101
$ echo "123456" | passthrough 111
$ echo fEqNCco3Yq9h5ZUglD3CZJT4lBs= | base64 -d | xxd -p
$ echo 3sFdypnBr3JA0ujT1xeTpffgSEA0NDY3MzU0Mg==  | base64 -d | xxd -p

... but then again, since it changes each time, it must be salted, so that's probably not it.

At this point, unless we're missing something, I think we've established that it's probably not a hash type supported by hashcat.
These D3S values are certainly encrypted, obfuscated or both. Why?
[Image: sLZj.png]

The authentication mechanisms APOP, CRAM-MD5 and DIGEST-MD5 all have something in common: The server has to know the password.
Still not convinced? As soon as you use the "strongly secure SHA format" (more on this later) the flag isPasswordReversible is set to false.

[Image: sLZp.png]

This means by default that is true and therefore the password is reversible.
I do not know the details but here are some interesting observations.
1. When I set the same password (123456) I get the same static suffix:

2. It changes when using another password but across multiple accounts it stays the same. For example with password set to 1234567

3. The output size depends on the password length. Password: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA (32x A)
Notice that the pattern adfa4447eff8dc repeats three times. This points in the direction of a block cipher with a block size of 8 bytes. So like DanielG mentioned DES or 3DES is highly likely.

Now coming back to the SHA hashes.
They have the "SHA:" prefix e.g.

The algorithm used is PKBDF2-HMAC-SHA1 with 10000 iterations. And that is already supported by hashcat.
The first 16 hex chars are the salt and the rest the hash. Here are some lines of python to format the hashes for hashcat.
#!/usr/bin/env python2

import sys

for line in sys.stdin:
  line = line.rstrip()
  salt = line[:16].decode('hex').encode('base64').strip()
  hash = line[16:].decode('hex').encode('base64').strip()
  print "sha1:10000:%s:%s" % (salt, hash)
See it in action
$ echo 9deb9254021335cf21e6aa91b568657b8e3b30ee92acab5aa44f0ac3 | ./
$ echo 123456 | ./hashcat --quiet -m 12000 sha1:10000:neuSVAITNc8=:IeaqkbVoZXuOOzDukqyrWqRPCsM=

Now the interesting part is for every user there's a password history saved in users.cfg which is using this algorithm.
And when you create a new user the first entry in the password history is also the current password.
what's a little confusing is the random data at the beginning of the hash/encrypted data. Since the last bytes (probably encrypted or hashed ciphertext) are static this does not seem to be an encryption password/IV/salt.

Also interesting to note is that misha's and hops' static part for a known password are identical. This suggests the software is using a hardcoded encryption key.
See also:
Awesome debugging powers to get that info! Seems to be 3DES indeed with key "61d0e54954733b8080808080808080808080808080808080".

Decoding D3S:8742ddf7db1906c5d54ec948c500e587adfa4447eff8dc42adfa4447eff8dc42adfa4447eff8dc4298558bad76110b35 (3. Password: 32x A) reveals 4173a95780AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA, maybe the beginning ("4173a95780") is some sort of user ID?
That is indeed some awesome reverse engineering!

There's something interesting going on with the Key. 3DES has three keys and performs DES on the plaintext with encryption, decryption and encryption. Each operation using one of the keys.
To be exact it is enc(key3, dec(key2, enc(key1, pt))). Since key2 and key3 are the same (80808080808080) it cancels itself out.
Or in other words: we are left with DES and the key1 (61d0e54954733b80).
Oh wow, why would they make that choice, using just DES and key "61d0e54954733b80" decodes it indeed.