Ξ welcome to cryptostorm's member forums ~ you don't have to be a cryptostorm member to post here Ξ
Ξ any OpenVPN configs found on the forum are likely outdated. For the latest, visit here or GitHub Ξ
Ξ If you're looking for tutorials/guides, check out the new https://cryptostorm.is/#section6 Ξ

Kebrum - raw data - cleanVPN, or not?

Post a reply

This question is a means of preventing automated form submissions by spambots.
:D :) ;) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :!: :?: :idea: :arrow: :| :mrgreen: :geek: :ugeek: :angel: :clap: :crazy: :eh: :lolno: :problem: :shh: :shifty: :sick: :silent: :think: :thumbdown: :thumbup: :wave: :wtf: :yawn:

BBCode is ON
[img] is ON
[flash] is OFF
[url] is ON
Smilies are ON

Topic review

If you wish to attach one or more files enter the details below.

Expand view Topic review: Kebrum - raw data - cleanVPN, or not?

topic split

by Pattern_Juggled » Sun Mar 08, 2015 5:28 am

I've taken the liberty of splitting off the "funky CRL subdomains" topic into its own dedicated thread, as it had basically taken over this one. I may go back and pull some of the findings still in posts above, relating to the CRLs, and move to the new thread, but that seems a spot of work so I'll avoid doing so for now :-P

Do keep in mind, however, that it's the Kebrum installers calling these mysterious subdomains during their setup process - so this is directly relevant to the Kebrum analysis itself. At the same time, we've noted it's not only the Kebrum installers that make such calls; thus, having a standalone thread for that work makes sense as it can be managed and maintained independently, and referenced as needed.


~ pj

Re: Kebrum - raw data - cleanVPN, or not?

by Pattern_Juggled » Mon Mar 02, 2015 11:38 pm

marzametal wrote:I was not suprised to see Akamai pop up. I HATE CONTENT DELIVERY NETWORKS!
You only think you hate them now... if you get a bit deeper into this, you'll see the central role they play in the entire process. I've noted elsewhere how counter-intuitive it is to be using CDNs - legitimately or not - to distribute such things as certificate revocation lists. That just doesn't make much sense, and leaves open the door for all sorts of clever exploits that make use of the fluidity of CDN-based data delivery.


~ pj

Re: Kebrum - raw data - cleanVPN, or not?

by marzametal » Mon Mar 02, 2015 4:01 pm

We need Maxwell Smart!

This has peaked my interest. I was looking for a reason to install VirtualBox and I still perve in WireShark from time to time. OMG, I never knew the VT website could look up IP address history. That is friggin' handy! I will have a look at the other sites too (malwr, archive).

I was not suprised to see Akamai pop up. I HATE CONTENT DELIVERY NETWORKS!


by Pattern_Juggled » Mon Mar 02, 2015 9:34 am

marzametal wrote:version 3? Wow, that smells like hmmmm, W7 is v6, so Vista is 5, XP is 4... no way, Windows 98?
Yep, it dates back a long, long time.

It's obviously not being used for any legitimate Windows purpose any longer... which begs the question: what use is it serving?

Because someone's still using it. For something.

A great next step is to visit all the archive.org snapshots of the page it links to and collect the text it's been serving over all those years. The way in which those characters change will likely help sketch out a pattern.

Remember those old spy agency "code broadcasts" on shortwave radio? Can't help but be reminded of them....


~ pj

Re: Kebrum - raw data - cleanVPN, or not?

by marzametal » Mon Mar 02, 2015 5:41 am

version 3? Wow, that smells like hmmmm, W7 is v6, so Vista is 5, XP is 4... no way, Windows 98?

Kebrum - raw data - cleanVPN, or not?

by Pattern_Juggled » Sun Mar 01, 2015 7:48 am

{direct link: cleanvpn.org/kebrum}

I've got alot of raw data here, and currently this one for me rates as:

unable to verify clean status with current analysis

Here's a list of links I've been using:
https://www.virustotal.com/en/file/0a24 ... /analysis/

Note these binaries are code-signed by a cert with a trust chain that goes back to one of the seriously dodgy "USERtrust" certificates that are tangled up in the NSA/DigiNotar root CA compromise of 2011:

Here's the root cert that one of the kebrum installers has been reported to drop during installation; it's categorised as a full CA, so if it's injected into the Windows trust store, it can be used to sign other certs, enable full 'ssl kneecapping' MiTM capture of plaintext https, etc
https://github.com/cryptostorm/review/b ... umroot.crt

Here's the openvpn.conf that unpacks from one of the installers...it's certainly a minimalist approach to openvpn parameters

https://github.com/cryptostorm/review/b ... lient.ovpn

This is a CRL that comes down from a "microsoft" URL, and when it is unpacked it's... not a CRL?

https://github.com/cryptostorm/review/b ... 2009-2.crl

That CRL-maybe is flagged by Sonicwall as malware:

http://software.sonicwall.com/applicati ... v_id=56997

We sent out a tweet recently seeking advice in untangling this particular mystery. Edited: see follow-on posts in this thread for additional data on this question that has since come to light.

Here's some analytic files on that www<dot>download<dot>microsoft<dot>com URL mystery:

https://www.virustotal.com/en/url/eecf4 ... /analysis/

https://web.archive.org/web/20140615000 ... ootseq.txt
https://www.virustotal.com/en/domain/ww ... formation/

...I felt I was close to untangling that mystery, but in the end it remains a nagging open question to me. Currently, the page loaded from this wget...

Code: Select all



Code: Select all


...legit? If it is, it's not mentioned anywhere in any MS or Tech Net or other resources I could find. And I looked. Alot. Like... alot. Maybe it's legit. It's not confidence-inspiring that, if you go to the HTTPS version of that strange microsoft URL, you get the somewhat dodgy "akamai" cert. It's dodgy in that it's not actually listed as issued to Akamai - but rather "Cybertrust Inc." - and that it's CRL distribution point is listed as "http://crl.omniroot.com/PublicSureServerSV.crl" with no other URLs for root CA confirmations, and the omniroot.com domain itself resolves to exactly nothing when visited (although crl.omniroot.com does resolve to a directory of CRL stuff, seemingly currently-maintained... and you can make of that what you will - yet another side-channel mystery to untangle for those curious about such oddball situations):

Code: Select all

Version: 3 (0x2)
Serial Number:
Signature Algorithm: sha1WithRSAEncryption
Issuer: O=Cybertrust Inc, CN=Cybertrust Public SureServer SV CA
Not Before: Jun 12 20:35:45 2014 GMT
Not After : Jun 12 20:35:45 2015 GMT
Subject: C=US, ST=MA, L=Cambridge, O=Akamai Technologies, Inc., CN=a248.e.akamai.net
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Authority Key Identifier:

X509v3 CRL Distribution Points:

Full Name:

X509v3 Subject Key Identifier:
X509v3 Basic Constraints:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
Netscape Cert Type:
SSL Client, SSL Server
X509v3 Subject Alternative Name:
DNS:*.akamaihd.net, DNS:*.akamaihd-staging.net, DNS:a248.e.akamai.net, DNS:*.akamaized.net, DNS:*.akamaized-staging.net
Signature Algorithm: sha1WithRSAEncryption


If you do load it via https despite the fake cert, you get this:

Code: Select all

<TITLE>Service Unavailable - Fail to connect</TITLE>
<H1>Service Unavailable</H1>
The server is temporarily unable to service your request.  Please try again

But yeah, there's something fishy here. This is the ssl-labs test:

Code: Select all


Maybe Microsoft just has some old server sitting around that is handling these requests, and it's got a bad cert, and it's... umm. Something something something. And it's all standup. Except it gets pulled by alot of verified malware during their installs, or C&C, or... something.

But why, then, does the SSL certificate one is served when one visits the https version of the page have organization name that's not even Akamai, let alone Microsoft? These questions become fractal in nature, branching off into more and more sub-sub-questions that each has its own nest of strange occurrences. Some of those strange occurrences are, most certainly, legitimate once researched a bit: there's many strange things in the world of CAs that are legitimate even if pretty odd.

But, for every one of those I've chased down to an explanation that was credible and well-documented if not terribly elegant, there's one that just keeps forking into more and more strange side-channels. It becomes a question of time constraints, in terms of chasing them all to ground - something I don't claim to have done personally. However, of the ones I have chased to ground, there's been a roughly equal mix of legit albeit needlessly complex explanations, and complete mystery answers that themselves are confirmation of something untoward going on.

Note that follow-on posts in this thread now explore in much more detail this www.download.windowsupdate.com mystery and track fractal fronds deep into several well-documented families of malware in the process. Rather than making this post longer by pulling those data up into it, I've let the extra data accrue in subsequent posts.

But that's not the only odd certificate-related hostname that appears in the Kebrum installers activities once it's run and packets are logged. Here's the other mysterious hostname called during one of the install actions.

Code: Select all


This was tweeted recently, as well, in terms of one of the reply elements from WHOIS...
Currrently that weirdly-formed subdomain resolves to

Code: Select all


And there's a bit of weird in those results, if you look closely. But look one back in time, to what it used to resolve to:

Code: Select all


So, yeah, someone's doing something clever here. Don't ask me how, I've not untangled it thus far. But it's not legit, despite being clever! :-P

Here's an old marketing brochure from now-AWOL AddTrust - complete with striding, purposeful businessmen! - bragging how "AddTrust ensures that its root keys are embedded in ubiquitous software packages and Internet browsers," and that the "AddTrust business concept is entirely geared towards minimizing your time to market, so that in literally a month you can start providing services and generate income."

That service was selling root CA signing authority to anyone who could pay for it. The bunk root certs that resulted from that orgy of cert-signing are still very much alive and kicking today, as evidenced by their appearance in the Kebrum installers, as root certifying authority for the code signing process itself. Yay.

Code: Select all


Here's a still-legit AddTrust root cert...

...and here's a notably non-confidence-inspiring AddTrust root cert...

Code: Select all


See the difference? All but identical... but divergent MD5s and other cryptographic materials. Took me a few hours to figure that one out... more than I care to admit. There are three legitimate (Swedish) Addtrust entities in the official root CA records. Here they are, with their respective root signing certificate fingerprints (SHA1):

edit: this is somehow related to the USER trust CA compromise, but to be honest I am not going to burn more time figuring out exactly how.

edited to add: here is the official CA information on the legit "AddTrust Class 1­ CA Root" entity, which is - inexplicably - Swedish)...

Code: Select all


Are those code-signing trust chains legit, or are there compromised Comodo/DigiNotar root authorities involved? I have not done enough validation of this step in the process, as of yet, to say definitively either way. For now, let us say that the code signatures on these binaries are not proved to be illegitimate, but at the same time aren't 100% confidence inspiring either.

Here's the code blobs I've found, which include both an earlier version (sometimes called "version 1") and the later version. This later one is almost 20 megs; the earlier one is closer to 16. Those are the only two I've been able to find thus far. The naming gets mixed up alot, tbh, but the hashes tell the distinction:
(19.12 MiB) Downloaded 730 times

malwr.com analysis:

Code: Select all


pcap from the install process as captured by the cuckoo sandbox VM used by malwr.com (SHA256 hash of the file: 211691d624089f7e9e7c9d05805a5c49d45c68f8782c895a2b9d1160e3c3f782):

Note that the pcaps confirm direct contact to and download of files from the two mysterious hostnames explored in more detail above.

Next, here's a different version of the Kebrum installer this one approximately 16 mb:
(15.83 MiB) Downloaded 699 times

And the virustotal run on it:

Code: Select all


Feel free to run all the scanners on each of the files, and the stuff that unpacks when you execute them in a VM. I have - if you do it, you'll see the results already precomputed in all the major scanner engines. Been there, done that. ;-)

So... clean?


~ pj