- raw data - #cleanVPN, or not?

Encouraging best practices in the VPN industry via independent, community-certified verification of clean installers and clean basic service operations. Let's reward the good, and make the bad a little bit less tempting 〰 github repo#cleanVPN
User avatar
Posts: 612
Joined: Sun Dec 16, 2012 6:34 am
Contact: - raw data - #cleanVPN, or not?

Post by Pattern_Juggled » Fri Feb 27, 2015 12:17 am

{direct link:}
github repository: #skRATched

Those who follow such things may have noticed that a good chunk of the cryptostorm team has been, not to put too fine a point on it, a little bit distracted in recent days. That's not to say that we've not been covering our duties, nor making steady progress on network improvements and new capabilities for cryptostorm members. Rather, it's that we've been ever less good (read: bad) at marketing lately. We've deployed really interesting and useful new features and barely mentioned them. We put our new website into production in a final push of production-code fine-tuning that culminated in us playing a bit of a prank on the internet. And also deepDNS.

It's not that we're dismissive of the value of such things - not at all. It's been something else entirely: #superfish. For those who stay a healthy distance from the front lines of security tech, this was a situation in which the world suddenly realised that Lenovo has been pre-installing some really noxious adware on their laptops, adware from venture-funded superfish that bundles into its installer (or "installed," in the case of pre-loaded laptops) a self-sighed, low-rent root ssl certificate enabling for comprehensive man-in-the-middle (MiTM) plaintext visibility of all "secure" web browsing people with infected machines might do via https sessions.

There's been oceans (sorry) written about superfish since then, as well as the provider of the creepy TLS-hijacking network kit behind its most frightening characteristics, #komodia. We did our part to help dig through the initial waves of public relations chaff and focus attention on the horrific side-effects such MiTM attacks have on the reliability of https as a secure transit medium, in general. This is important work, and we were happy to help out as we could. By the time Filippo released the first in a series of iteratively-improving vuln-testing tools, we'd been pulled deep into the superfishy waters.

But why?

For that it helps to step back and remember the part cryptostorm plays in good security practice. We're essentially generalised transit layer security, what we sometimes call "encrypted packet routing" (not a very sexy tagline, admittedly). The idea is that we wrap all data traffic to and from our network members in an encrypted, encapsulated wrapper as it goes to and from the plaintext internet. We work hard to ensure stuff doesn't "leak" out of that wrapper, and our model involves constant vigilance on such matters. We know that terrain, we know what we do well and where we're still pinning down loose bits. It's our home turf.

But then there's web browsers.

Browsers are, in a word, a security nightmare. They want to their own little webservers nowadays, announcing their innermost feelings (and IP addresses) via webRTC replies to arbitrary stun servers. They let javascript do horrible things inside their paper-thin "sandbox" architectures, and they have this whole layer of https "encryption" that... well, it's broken. Not the crypto - not really (yes, heartbleed was bad but it's patched). It's the whole Certificate Authority model of identifying endpoints within https that's broken. Horribly broken. Tragically broken. Go watch Moxie's excellent summary of the broken-ness, and I'll not bore you with a poor repetition of it here.

Ideally this wouldn't matter to cryptostorm: after all, we wrap https inside our own layer of in-transit crypto, so if https is broken then it's just a good thing we're there as fallback. Only with MiTM attack models, not so simple; sure, from the member to the cryptostorm exitnode, we can cover that channel securely (and we do)... but those https sessions exit cryptostorm and (unless they're .onion or .i2p traffic heading into those subnetworks via our deepDNS service). When they do, they're vulnerable to interception.

They're also vulnerable right at the member computer - the "endpoint" - and superfish showed just how easy it is for that vulnerability to become real. After all, if ssl kneecappers like komodia's interceptor jack data traffic right on the member PC, having cryptostorm secure the already hijacked data doesn't help our members at all.

In one sense, this isn't our problem: we route packets. Only... no. That's not how things are evolving. Our real role, we understand, is to help ensure our members are secure online. Real secure, not fake "secure" (see below... trust me). So when browser vulns get critical and members are leaking data right through the middle of our secure tunnel, we don't just ignore it and "not our problem" look the other way. That said, we're not browser specialists and we don't run client-side kernels... but somewhere in the middle, there's important work for us in keeping our members secure.

Superfish - and the tragic insecurities of the CA model - falls right in that terrain. That terrain is also where we've enabled support for Namecoin-blochchain-based DNSchain... to help members avoid the need for reliance on centralised DNS lookups, for example. Thus superfishing wasn't just a distraction from our real work: it's part of our job. Ok also it's fascinating, and working with smart colleagues to untangle the ball of sad this whole thing represents is exhilarating and entirely self-fulfilling (if you're a geek, right?). Many an hour was not slept in the past week, as our team has cycled in and out of superfishy forensics.

But a funny thing happened on the way to the superfishing: we started getting tips from friends and colleagues, out in the etherverse, that they'd seen similar cert-baed, ssl-hijacking, proxied weirdness well beyond superfish. Some of that's simply komodia's kneecapper-ware getting spread out like some nasty infection... but not all. Soon enough we were chasing down injection-based subversions of ssl security in a range of platforms, thanks to data provided by the community. (we owe apologies to some who have waited patiently all week while we gut pulled into... well, you'll see below). The rot runs deep - we've only scratched the surface, and my own pastime of collecting "fishycerts" in the wild will likely carry me through many a year of my peaceful retirement.

But here's where things get weird.

We got our first tip on a "VPN service" that might be superfishy late last week. Our reply perhaps speaks for itself...
That project is still a work in process (again, see below for an explanation of the delay in publishing); ongoing data are available publicly for other researchers to review and expand on via our github repository. Are we just being, well assholes in our interest specifically in VPN services that might be superfishing their customers? Actually, no - we hope not.

Rather, we're strong proponents of operational and technical transparency when it comes to customer-focussed security tech. The most obvious part of that is opensource code, of course. And yet, the "VPN industry" is filled with closed-source "mystery binaries" (as Graze calls them)... blobs of who-knows-what downloaded and installed by people trusting they will "stay secure" and "have total privacy" if they just pony up their creditcard every month.

It's very time-consuming to analyse binaries, as compared to source code: possible, but something of a fine art... and it's not our fine art. We run a great network security service; we don't pretend to be world-class .exe reversers deobfuscation specialists in our spare time. In a pinch, we've got team resources with strong skills to cross into that space - but it's not our core zone and we're slower and less competent at it than are the many folks who do it full-time and do it very well indeed.

But that shouldn't be necessary for privacy tech, ffs!

There's just no legitimate excuse to have close-source code getting pushed around in this space. Stick a humble little repository on github (like our quite-humble widget repo), and dump pre-compile code into it. Sure, it'd be great to do full reproducible build recipes & the other high-powered stuff (we're working on that as a medium-term goal), but even a simple repo and some independently-available hashes go a long way to ensuring totally arbitrary, dodgy code isn't being superfished all up in customers' grills, you know? This is not so much to ask.

So that's our axe to grind, our idée fixe as it were. With open code, iterative improvement is just so much more structurally inevitable. Someone sees something derpy in the code, they raise a fuss, derp is lessened, code recompiled... the world is a better place. It's a collaborative process, and the entire "industry" improves over time. That's the idea, anyway.

In the "VPN industry," unfortunately, it doesn't work like that at all, just yet. There's some exceptions - we've gone back and forth with Mullvad, to be blunt, on some issues publicly... and despite the friction such can entail, it's been a net benefit for everyone. We (genuinely) appreciate the eyes on our code they provide, and we hope our chivvying (and occasional trollolol-y good-natured tomfoolery) might just be of benefit to them. Anyway, that's how it's supposed to work: it's not perfect, and it's not always pretty... but it delivers better tech over time, mostly. So that's good.

In the "VPN industry," it's all snake-oil all the time: every me-too "VPN service" is the "world's fastest" and blah blah blah. No metrics, no public view into the code. We've found instances of companies faking their 'server stats' pages with php scripts, we've watched as server certs showed up across different VPN companies (happens when the "DO NOT USE THESE TEST CERTS IN PRODUCTION" certs included in the openvpn installers get, yep, used in production)... there's more Alot more. We write up perhaps 5% of what we find, time being limited. Graze refers to it as a "backlog of weirdness" we have in our files and that's an apt phrase indeed.

So when PIA claims to be safe against 'advanced alien technology,' it's not an aberration. And when we point out how silly that is, we're accustomed to being quite well savaged in reply. Trolls, smears, (very poor quality) SQLi pokes at our machines... it's temper-tantrum-level stuff, and it's how the "VPN industry" responds to public discussion & debate of security tech.

That has to change.

Hence we do try to put a bit of a light on less-than-optimal issues in this little corner of the world - as we encourage others to do with us, as well - so that we can come in line with every other part of security tech in recognising that open code is the foundation of the vast majority of solid security tech.

It does make us seem a little bit growl-y and suspicious, there's no doubt. That's a shame, and I hope over time we come to more of an equilibrium with the "VPN industry" in such matters. But that'll happen when things move into the best-practice model of open, public code... not by us compromising on our position on the question. Just to be clear. We do think it'll happen, and if we get tarred a bit as the bête noir of the "VPN industry" meanwhole, so be it. We'll live - and our members are no less secure for it, that's for certain.

As we were unpacking and undertaking forensic analytics on the VPN software installer that bundles not only the fiddler testing package (which does ssl kneecapping very well, indeed) but also trusted cert-key pairs that remain in the Windows trust store even after uninstall, something came our way. It came from... a friend with some very precise information. And as such tends to be, it was short and to the point: cyberghost is far from the worst; take a look at this binary (loaded from this page... you'll see if you look hard enough.

Oh. Ok then.

Here's the installer pulled from that URL. It has a SHA256 hash value of: ef2af4837195f85335d5434d198e75b07246d3e79b942b2a542e96c90a5aac59.
(5.92 MiB) Downloaded 3592 times
Here is the report.
(reports also from virustotal and, and

For whatever value such things add, here's the chain of trust underling the code signing certificate on the binaries:
HMA installer codesign.jpg

edited to add: it's been pointed out to me that, per data provided via the scanner, the HMA installer doesn't pass the "PE check," or code signing cryptographic verification. I've not done these calculations directly, so I can't say whether this PE-fail is spurious or not - but here's the report as it is presented:
Those red flags raised by some of the scanners are, as we've been reminded by friends in the malware analysis world as well as knowing firsthand, likely false-positives and aren't some big red flag. And at that level, nothing to see here folks - move right along. It's closed-source code, so we can't see alot of what's going on... but what we can see isn't overtly evil. Fair enough.

Dig a little deeper, and you see that the installer makes an http call to this URL:

Code: Select all
Raw content:

Code: Select all

GET /download/0/6/1/061F001C-8752-4600-A198-53214C69B51F/dotnetfx35setup.exe HTTP/1.1
User-Agent: NSIS_Inetc (Mozilla)
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: MC1=V=4&GUID=ff8156e0b7c7464e9c5ca694a076d81e&HASH=&LV=&LU=1412024236610; optimizelySegments=%7B%22223040836%22%3A%22direct%22%2C%22244338170%22%3A%22none%22%2C%22223033821%22%3A%22false%22%2C%22223082014%22%3A%22ie%22%7D; optimizelyEndUserId=oeu1411991834643r0.7160220457384006; optimizelyBuckets=%7B%7D; MUID=121AAB31755E6EFF1B43ADF5715E6C85; A=I&I=AxUFAAAAAADvBgAAYeNKI3hJ0WqAQsafK8vAFw!!&V=4
This download actually routes through akamai, via this trajectory at present:
[root@fenrir ~]# wget ... 5setup.exe
--2015-02-26 16:42:29-- ... 5setup.exe
Resolving,, 2a02:26f0:71::5c7b:4826, ...
Connecting to||:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2959376 (2.8M) [application/octet-stream]
Saving to: `dotnetfx35setup.exe'

100%[===================================================================================================================================>] 2,959,376 651K/s in 4.5s

2015-02-26 16:42:34 (642 KB/s) - `dotnetfx35setup.exe' saved [2959376/2959376]
Here is the file that results:
(2.82 MiB) Downloaded 2022 times
As the wget results show as well, it's exactly 2,959,376 byes long. The file hashes as follows:

MD5: c626670633ddcc2a66b0d935195cf2a1
SHA1: ec9f0c31b9949ca1cf14e9a43bca065fa5bc0e71
SHA256: 6ba7399eda49212524560c767045c18301cd4360b521be2363dd77e23da3cf36

Full-payload pcaps of the HMA installer making the calls to this file, via IP address, are here:

This file that has been pulled from that address, via those packets, at the request of the HMA installer, purports to be an incremental update to Microsoft's .net framework. Specifically (from
Microsoft .NET Framework 3.5 contains many new features building incrementally upon .NET Framework 2.0 and 3.0, and includes .NET Framework 2.0 service pack 1 and .NET Framework 3.0 service pack 1.
File details, from the microsoft site:
Version: 3.5
File Name: dotNetFx35setup.exe
Date Published: 11/20/2007
File Size: 2.7 MB
Hmmm... 2.7 megabtyes? Let's download that one, directly from microsoft (by clicking the "download" button on that page, and navigating around their effort to trick the unwary into allowing some Bing search crap to come along for the ride - stay classy, M$!), and see what we get. I've added "_microsoft" to this filename - "dotNetFx35setup_microsoft.exe" - in order to keep the two apart; I did not change the capitalisation, that's how the file has arrived, which also matches the spelling of the text title given by the Microsoft page, above):
(2.74 MiB) Downloaded 1912 times
Here's the trajectory the download request took:
[root@fenrir ~]# wget ... 5setup.exe
--2015-02-26 17:21:06-- ... 5setup.exe
Resolving,, 2a02:26f0:71::5c7b:4896, ...
Connecting to||:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2869264 (2.7M) [application/octet-stream]
Saving to: `dotNetFx35setup.exe'

100%[===================================================================================================================================>] 2,869,264 645K/s in 4.4s

2015-02-26 17:21:11 (641 KB/s) - `dotNetFx35setup.exe' saved [2869264/2869264]
How does this file hash out?

MD5: 269f314b87e6222a20e5f745b6b89783
SHA1: b0ca05c12ebb9a3610206bad7f219e02b7873cbd
SHA256: c05a019ce69c2e6973e464f381c2b0b618ad9b135ca5275b052febf64c9f9257

So, ok, the files aren't bit-identical. Indeed we can see that the file from is smaller by exactly 90,112 bytes. Not alot, but not zero either.

Let's scan the two files....

Here's virustotal's summary stats and metadata on dotnetfx35setup.exe (the one from the HMA installer), and here's the same virustotal metadata summary on dotNetFx35setup_microsoft.exe, the link directly from Side by side, the two pages look like this:
side to side.jpg

edited to add: reading back over this, one can see that this "side by side" graphic I did is pretty much useless. Not my strong suit, sadly. I'm leaving it as-is, but adding in these two additional side-by-side comparisons in the hopes they're a bit more helpful.

Here' are the microsoft ("legit") and HMA ("corrupted") virustotal detail screenshots, the former atop the latter:



And from the scanner, here's the microsoft ("legit") as compared to the corrupt ("HMA") versions' respective static sections analysis, the former atop the latter:



Only a few divergences, actually. Of course the hashes differ - no way to fudge that, as it's driven by bit-level metrics.

The microsoft file shows version "3.5.21022.08" and the HMA one "3.5.30729.01" which makes sense because the microsoft binary was code-signed on 4:43 AM 11/8/2007 whereas the HMA one wasn't code-signed until 8:24 AM 7/30/2008... nearly a year later. So maybe the HMA file is some later build, right?

Except the compilation timestamp for both files is identical: 2005-06-01 16:46:51
As is the EXIF timestamp: 2005:06:01 17:46:51+01:00

Review the PE Sections data, some interesting things stand out (this is beyond my personal level of Windows expertise, so I'm making note solely in hopes others will see and offer explanation). Virtual addresses are identical, as is virtual size. Raw size lists identical for text and data... but not for .rsrc; microsoft's version lists as 2827264, whereas the HMA version is 2917376. A size difference of exactly 90,112 btyes. Naturally, the hashes for the .rsrc values diverge... but it's interesting to note that the hashes of the data values also diverge. That suggests that some of the payload is actually in .data, although the metadata weren't updated to reflect that?

When we flip over to the comparative data offered by a similar small but nonzero divergence is once again apparent. The microsoft version shows a reasonably mundane dynamic analysis snapshot (again, the specifics of this are past my expertise level; I'm sharing the data as they appear):
The HMA/mystery version, in contrast, is quite a bit different in that regard:
A similar pattern shows in most all other areas: much more activity in the HMA version, as compared to the legitimate one.

Perhaps most striking is the network behaviour divergence. Here's the pcaps pulled from the microsoft version's installation process:
Here's the mystery/HMA pcaps:

9902433cc3ad6e00ecc3e321e9d68c83e12fcd2991327a405d4b8ad22525fbb2.pcap 55.6 MB

(that's a link because the HMA version generated 55 megabytes of traffic during that short time-window on the VM testbed; in contrast, the microsoft version's clock in at... 8kB)

There's a great deal more data to look through in the sandboxed VM runs of the initial HMA installer and then of the dotnetfx version it downloads. Some of it, after looking closely and research carefully and asking around, we're still not quite clear on. For those in this field, its likely obvious how it all fits together.

We did run some local test installs of the HMA application itself, and there's network data gathered from that. We don't have those data analytics complete, and it felt inappropriate to stall publication of what we've worked on thus far whilst waiting on that. Most of all, we wanted to put our raw data into view of others who do this sort of thing in a dedicated manner. We've brought our best work to it, but at this point review is the most productive next step and it is for that reason we've brought these data forward.

What's in the payload of this modified binary? We haven't looked inside and let it run on a local machine long enough to answer that question. But, really... there shouldn't be a question.

As an aside, I believe what's happened here - and this will be obvious to many in the field, I'm sure - is that the legitimate microsoft SP1 upgrader has about 100kB of stuff stuffed into it by whoever did these mods. What's in that payload? The strings give some hints, as do the registry edits... but that's something others can dig into with the data published here. Pains were taken to make the tweaked version look very similiar... it took me a few days to finally see through that. Once you see it, of course, it's obvious.

Did the developers who made this HMA VPN application intend to bring in this apparently malicious payload, or was it some sort of serious security error? This I cannot say... it's an open question.

- - -

Is there a short-form, tl;dr summary of this work as it has developed so far? For us, we're confident in saying that sending out closed-source, mystery binaries as applications - with no validation mechanism possible, and no ability for outside researchers to effectively review code integrity, is a really bad idea. These are VPN software clients - this isn't heavily complex, super-secret technology... there's no reason it's not publishable, and it makes no impact on competitiveness to be honest.

Absent that open code standard, we're left with a situation such as we've uncovered with the HMA binaries. There they are. They are installing things that are not very friendly-looking, and all the signs are that it's a bad state of affairs. Or is it? Maybe there's a totally legit, obvious-in-hindsight explanation for why this flows the way it does... we're not saying that's impossible, and indeed if the developers of this application would step through the design, code, compile process it would be instructive and valuable for everyone involved.

As to what exactly these mystery binaries are doing - and, in terms of providing network security, not doing - we leave up to professional malware investigators to determine. From our end, we'd not distribute these binaries to our members. Nope, never. Perhaps we're just too cautious, or too old-fashioned... or have seen too much to be so carefree.

And superfish, the thing that got this going in the first place? One very tangible lesson we're all learning from that debacle is the ease with which the current CA system can be subverted is not a theoretical matter, or even one specific to nation-state level actors in the field. Rather, it's being exploited widely, for all sorts of shady or outright nefarious reasons. It's particularly pernicious in that these injected trust creds tend to stick for the long-term, and thus open new attack surfaces almost impossible to fully imagine. It's really a mess, and it's going to take some real work to get past this.

I know I now look at browsers as a horrific security risk, and there's not many good answers I can give when asked what my advice is. Given the things I've seen in (as-yet-unpublished) work we've done on malicious javascript being served by "leak test" websites of various flavours, and I can see that we at cryptostorm will be pulled up the OSI stack, as it were, in order to ensure that the work we do down at our level isn't entirely undone by the tragic disaster of the browserverse.

Now, having at the least scoped the extent of the problem, I feel we're in a much better place to map what we can do about it. And for that, I'd like to thank the cryptostorm team, who have patiently covered for me in so many ways in the last couple weeks as I had my "gone fishin'" sign posted out front of my office. I knew this stuff mattered, and I knew this stuff was chunky enough to take some sustained work. I didn't know it'd be weeks of fugue-state intensity... but such is life. So it goes.

Finally, a note of thanks to Filippo and the rest of the crew that has pitched in on this - publicly and privately - both in loose coordination with cryptostorm and via independent tracks. Many have helped enormously from behind the curtains, and some have offered amazingly valuable public expertise only through cloaked channels. Filippo, by stepping forward to be a face and a personality raising the alarm about these issues, has paved the way for so many of the rest of us to contribute most effectively. This is a newly-evolving model of emergent threat-analysis responsiveness, I believe, and it's been an honour to take part in it... despite the need to juggle other tasks in order to clear calendar time for superfishing.

We've so many more interesting things to pursue in this line of research; Graze's "backlog of weirdness" is now a growing deluge-in-waiting. The team here is hoping we can create syncretic working relationships with proper, card-carrying security researchers so that these items don't go stale under the weight of our myriad production obligations within cryptostorm.

Meanwhile, there you go. This is my idea of a short research note, although I apologise for the verbosity. A risk in this line of work, unfortunately.


~ pj

ps: the one man who knows the true path forward, lest we forget, is Mike Espresso! Here's to #test2, w00d!
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

[list]✨ ✨ ✨[/list]
pj@ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github

User avatar
Posts: 241
Joined: Tue Jan 28, 2014 12:38 am

Re: #superfishing in a sea of bad

Post by Tealc » Fri Feb 27, 2015 2:44 am

I can only say....


I'm actually reading this after watching CitizenFour so my conspiracy theories are INSANE :-D

User avatar
Posts: 434
Joined: Mon Aug 05, 2013 11:39 am

Re: #superfishing in a sea of bad

Post by marzametal » Fri Feb 27, 2015 6:29 am

Been blocking stuff for ages now, especially the Microsoft Installer, plus Windows Explorer from sending stuff outbound... noticed nearly all executable installers try to dry-reach for net access... not on my watch lol

User avatar
Posts: 612
Joined: Sun Dec 16, 2012 6:34 am

validating project pcaps

Post by Pattern_Juggled » Fri Feb 27, 2015 7:29 pm

ntldr wrote: ... f613e1ac8/

this url gives me 403 Forbidden :?
Ah, yes pcaps are provided by malwr only for registered users (it's free to register). Here's the file; anyone who wants to validate it has not been modified from the one posted at malwr just needs to create an account there so they can download a comparator version directly.
This file hashes as:

MD5: 54a0508fed4cce0d0af3dfde40a58bf9
SHA1: ee8fb6a51cdf46c8cad5d2fc99dcc1e38f752cf7
SHA256: 99f63a60671f270a3efba88d209f03dee137f77ec10bb04394bc9b6f613e1ac8


~ pj
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

[list]✨ ✨ ✨[/list]
pj@ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github

User avatar
Posts: 612
Joined: Sun Dec 16, 2012 6:34 am

full pcaps: HideMyAss Windows installation & VPN connection

Post by Pattern_Juggled » Mon Mar 02, 2015 11:34 am

As noted earlier, here are some installation & VPN connection pcaps from the above-analysed HMA binaries. I have not done much beyond surface-level analytics yet... although I believe a deeper look will be quite informative.
(996.19 KiB) Downloaded 1833 times
Those running analyses, please do share results!


~ pj
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

[list]✨ ✨ ✨[/list]
pj@ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github

User avatar
Posts: 612
Joined: Sun Dec 16, 2012 6:34 am

spies, bunk certs, & VPN malware

Post by Pattern_Juggled » Mon Mar 02, 2015 11:38 am

Tealc wrote:I'm actually reading this after watching CitizenFour so my conspiracy theories are INSANE :-D
If you were unfortunate enough to end up on the receiving end of my admittedly rant-y twitter thread after another long session hunting fake root certs, you'll already know that there's obvious - inescapable - connections between these bunk certs and spy agency doings. Those certs show up in the analyses posted above.

What does that mean? I've not a clue, to be blunt about it. I'm gathering data - making sense of the circumstances that caused those data is still a bit too far out for me to tackle.


~ pj
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

[list]✨ ✨ ✨[/list]
pj@ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github

User avatar
Posts: 612
Joined: Sun Dec 16, 2012 6:34 am

data set: malicious javascript served via HMA join page

Post by Pattern_Juggled » Tue Mar 03, 2015 12:01 am

This email push to recruit friends and family...

Takes one (via redirect) to a page hosting the following html and other script-y complications:

With this one sort of standing out right away...

Code: Select all

  if( == '' || == '')
    _kms('//' + _kmk + '.1.js');
    window._isKissMetricsEnabled = true;

A scan through the scripts pulled when a visitor arrives shows quite an active scene...

You wouldn't know that from the screenshot taken by the scanner service... since it's been blocked by HMA, for some reason...

But if one steps back in time (21 February 2015) to see other scans of the same HMA IP address, perhaps the reason becomes clear:

Code: Select all

GET /i/? HTTP/1.1 

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; ar; rv: Gecko/20110614 Firefox/3.6.18
Accept: */*
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
United States
AS36351 SoftLayer Technologies Inc.
HTTP/1.0 200 OK 
Content-Type: application/x-javascript 
Date: Sat, 21 Feb 2015 01:59:02 GMT
Set-Cookie: d=%5B%5D; expires=Thu, 20-Feb-2020 01:59:02 GMT; Max-Age=157680000; path=/; l=RQTnHVTn5mYdDQoXTOMYAg==; expires=Thu, 31-Dec-37 23:55:55 GMT;; path=/
Expires: Sat, 21 Feb 2015 01:59:01 GMT
Cache-Control: no-cache
Connection: close
That's the join page. Anyone have a bit of time to look around the rest?


~ pj
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

[list]✨ ✨ ✨[/list]
pj@ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github

User avatar
Posts: 612
Joined: Sun Dec 16, 2012 6:34 am

post-install pcaps

Post by Pattern_Juggled » Tue Mar 03, 2015 6:40 pm

Test run of post-installation application, not yet analysed:!4Rhh3ZhR!Ai1ak6Rfo ... 0i4L-y7l_o
Summary created by Wireshark (v1.10.6 from master-1.10)

Name: /EC2_pcaps/hma_installer.pcap
Length: 1019958 bytes
Format: Wireshark/... - pcapng
Encapsulation: Ethernet

First packet: First packet:
Last packet: Last packet:
Elapsed: Elapsed: et: Last packet: ast

OS: 64-bit Windows Server 2008 R2 Service Pack 1, build 7601
Capture application: Dumpcap 1.12.3 (v1.12.3-0-gbb3e9a0 from master-1.12)

Dropped packets: 0 (0.000%)
Capture filter: none
Link type: Ethernet
Packet size limit 262144 bytes

Packets: 1256
Between first and last packet:125.527 sec
Avg. packets/sec: 10.006
Avg packet size: 778.195 bytes
Bytes: 977413
Avg bytes/sec: 7786.485
Avg Mbit/sec: 0.062
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

[list]✨ ✨ ✨[/list]
pj@ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github


HMA: Don't miss 50% off in our Summer Special!

Post by cryptostorm_ops » Tue Jul 14, 2015 1:11 pm

Return-path: <>
Delivery-date: Mon, 13 Jul 2015 20:15:25 +0300
Received: from ([]:29148)
by with esmtps (TLSv1.2:DHE-RSA-AES128-GCM-SHA256:128)
(Exim 4.85)
(envelope-from <>)
id 1ZEhK9-0000sX-3V
for; Mon, 13 Jul 2015 20:15:25 +0300
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;;
s=smtpapi; bh=tS0V6j5UMrJmUp7CqjwlcUYSiVI=; b=Pp74I8/3N51aJN5Dx5
Received: by with SMTP id filter-337.8036.55A3F207B
2015-07-13 17:14:47.370377484 +0000 UTC
Received: from OTE0MzE2 (unknown [])
by ismtpd-078 (SG) with HTTP id 14e88696d89.7ab.977dd
for <>; Mon, 13 Jul 2015 17:14:47 +0000 (UTC)
Content-Type: multipart/alternative;
MIME-Version: 1.0
From: HMA! Team <>
Subject: Don't miss 50% off in our Summer Special!
Message-ID: <14e88696d89.7ab.977dd@ismtpd-078>
Date: Mon, 13 Jul 2015 17:14:47 +0000 (UTC)
List-Unsubscribe: < ... dBfuBAb3pl>, < ... dBfuBAb3pl>
X-SG-EID: aXMS4AcJQ8qkYz963H8i6AT5igliZEUkQCK+Q9Ftz9vXweEF8mzE5NYcIjW8eYYTQ5oGqrAESX11v0
X-SG-ID: VPWZYjw6GOzHdwkwPeoX9QiEbzQXX/gF9P8njHP5+LBmJ5dz+kbEZqGLY+HjsjSwVSI4yUI+iELeem

Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

Email not displaying correctly? View it ( ) in your browser

Hi twinklet0es,


The HideMyAss! Midsummer Night=E2=80=99s Special is bringing Dream Savings =
to thousands of VPN users =E2=80=93 but you=E2=80=99ve still not got your 5=
0% saving on HMA! Pro VPN!

These prices are for a limited time only, so take advantage of this great o=
ffer and order today! (
tm_campaign=3Dsumspe )



( ... 6BOM2A?ut=
n=3Dsumspe )


Have a magical summer!

The HMA! Team


To unsubscribe please click here (
akSKS1R3zn0rbTnD6Syw-2Fcv6zlV0uhuvMoA )

HMA! Team
7 Moor Street, London, W1=

Content-Type: text/html; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

<style type=3D"text/css">.ReadMsgBody{width:100%;}.ExternalClass{width:100%=
rgin-left:0;}*{-webkit-text-size-adjust:none;}</style><table cellpadding=3D=
"0" cellspacing=3D"0" width=3D"100%" style=3D"border-collapse:collapse;back=
ground:#f2f5f7;min-width:620px;table-layout:fixed;"><tbody><tr><td align=3D=
"center" style=3D"padding-right:10px;padding-top:10px;padding-bottom:10px;p=
adding-left:10px;"><div style=3D"width:auto;margin-right:auto;margin-left:a=
x;line-height:150%;"><table style=3D"width:100%;border-collapse:separate;ta=
ble-layout:fixed;" cellspacing=3D"0" cellpadding=3D"0"><tbody><tr><td align=
=3D"center"><table width=3D"600" cellspacing=3D"0" cellpadding=3D"0" style=
0px;background:#ffffff;"><tbody><tr><td><table cellpadding=3D"0" cellspacin=
g=3D"0" style=3D"width:600px;border-collapse:collapse;table-layout:fixed;">=
<tbody><tr><td width=3D"100%" style=3D"vertical-align:top;"><div><table sty=
le=3D"width:100%;border-collapse:separate;table-layout:fixed;" cellspacing=
=3D"0" cellpadding=3D"0"><tbody><tr><td style=3D"background:#ffffcf;"><tabl=
e width=3D"100%" cellspacing=3D"0" cellpadding=3D"0" style=3D"border-collap=
se:separate;border-spacing:0px;table-layout:fixed;"><tbody><tr><td style=3D=
padding-right:0;"><div style=3D"word-wrap:break-word;line-height:140%;text-=
align:left;"><p style=3D"text-align:center;font-size:11px;margin:0;">Email =
not displaying correctly? <a href=3D"
6U7Iz2F4noA" style=3D"text-decoration:none;"><span style=3D"text-decoration=
:underline;color:#002AFF;">View it</span></a> in your browser</p></div></td=
></tr></tbody></table></td></tr></tbody></table></div><div><table style=3D"=
border-collapse:separate;border-spacing:0px;table-layout:fixed;" cellpaddin=
g=3D"5" cellspacing=3D"5"><tbody><tr><td></td></tr></tbody></table><table s=
ffffff;" cellspacing=3D"15" cellpadding=3D"0"><tbody><tr><td style=3D"backg=
round:#ffffff;"><table width=3D"100%" cellspacing=3D"0" cellpadding=3D"0" s=
body><tr><td style=3D"vertical-align: top;" align=3D"center"><div><a href=
=3D" ... jWrK1bB6M=
gD-2FJyLd6lpXkPeaKkDaL8yA" style=3D"width:auto;" target=3D"_blank"><img sty=
le=3D"border:medium none;width:570px;height:285px;resize:none;position:rela=
tive;display:block;top:0px;left:0px;" width=3D"570" height=3D"285" src=3D"h=
9e5b0e760e1f7/b78be676e70ff18295c9d5ecbee9c565" /></a></div></td></tr></tbo=
dy></table></td></tr></tbody></table></div><div><table style=3D"border-coll=
apse:separate;border-spacing:0px;table-layout:fixed;" cellpadding=3D"5" cel=
lspacing=3D"5"><tbody><tr><td></td></tr></tbody></table><table style=3D"wid=
th:100%;border-collapse:separate;table-layout:fixed;background:#ffffff;" ce=
llspacing=3D"15" cellpadding=3D"0"><tbody><tr><td style=3D"background:#ffff=
ff;"><table width=3D"100%" cellspacing=3D"0" cellpadding=3D"0" style=3D"bor=
d style=3D"vertical-align:top;"><div style=3D"word-wrap:break-word;line-hei=
<span style=3D"font-size:16px;"><span style=3D"font-family:arial,helvetica=
,sans-serif;">Hi twinklet0es,</span></span></div>
<span style=3D"font-size:16px;"><span style=3D"font-family:arial,helveti=
ca,sans-serif;">The HideMyAss! Midsummer Night&rsquo;s Special is bringing =
Dream Savings to thousands of VPN users &ndash; but you&rsquo;ve still not =
got your <strong>50% saving on HMA! Pro VPN!</strong></span></span><br />
<span style=3D"font-size:16px;"><span style=3D"font-family:arial,helveti=
ca,sans-serif;">These prices are for a limited time only, so take advantage=
of this great offer and <a href=3D"
zER7E8synMmb5BxK-2F144VuG6jNQMnCN4oqhuaQ5gRtBc">order today!</a></span></sp=
<br />
</div><div><p style=3D"margin-left:0;margin-top:0;margin-right:0;margin-bot=
tom:0;text-align:center;"><a style=3D"display:inline-block;text-align:cente=
g-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;" href=3D"h=
hXs-2FcNAtg"><img src=3D"
122912_c8148d92d8288fc53439e5b0e760e1f7/40400c245b4b704f24c5de7563043254" /=
iv><table style=3D"border-collapse:separate;border-spacing:0px;table-layout=
:fixed;" cellpadding=3D"5" cellspacing=3D"5"><tbody><tr><td></td></tr></tbo=
dy></table><table style=3D"width:100%;border-collapse:separate;table-layout=
:fixed;background:#ffffff;" cellspacing=3D"15" cellpadding=3D"0"><tbody><tr=
><td style=3D"background:#ffffff;"><table width=3D"100%" cellspacing=3D"0" =
cellpadding=3D"0" style=3D"border-collapse:separate;border-spacing:0px;tabl=
e-layout:fixed;"><tbody><tr><td style=3D"vertical-align:top;"><div style=3D=
<span style=3D"font-size:16px;">Have a magical summer!</span><br />
<span style=3D"font-size:16px;">The HMA! Team</span></div>
style=3D"border-collapse:separate;border-spacing:0px;table-layout:fixed;" =
cellpadding=3D"5" cellspacing=3D"5"><tbody><tr><td></td></tr></tbody></tabl=
e><table style=3D"width:100%;border-collapse:separate;table-layout:fixed;ba=
ckground:#ffffff;" cellspacing=3D"15" cellpadding=3D"0"><tbody><tr><td styl=
e=3D"background:#ffffff;"><table width=3D"100%" cellspacing=3D"0" cellpaddi=
ng=3D"0" style=3D"border-collapse:separate;border-spacing:0px;table-layout:=
fixed;"><tbody><tr><td style=3D"vertical-align: top;" align=3D"center"><div=
><img style=3D"border:medium none;width:570px;height:95px;resize:none;posit=
ion:relative;display:block;top:0px;left:0px;" width=3D"570" height=3D"95" s=
rc=3D" ... 48d92d828=
8fc53439e5b0e760e1f7/c9e33e00b74cefefb508036cd8f0ed4d" /></div></td></tr></=
tbody></table></td></tr></tbody></table></div><div><table style=3D"border-c=
ollapse:separate;border-spacing:0px;table-layout:fixed;" cellpadding=3D"5" =
cellspacing=3D"5"><tbody><tr><td></td></tr></tbody></table><table style=3D"=
cellspacing=3D"15" cellpadding=3D"0"><tbody><tr><td style=3D"background:#f=
1f1f1;"><table width=3D"100%" cellspacing=3D"0" cellpadding=3D"0" style=3D"=
><td style=3D"vertical-align:middle;font-size:11px;padding-top:10px;padding=
-right:10px;padding-bottom:10px;padding-left:10px;"><div style=3D"word-wrap=
:break-word;line-height:140%;text-align:left;"><p style=3D"font-size:11px;m=
To unsubscribe please click <a href=3D"
WsaATUw6YDuHb2w9EVwZ6Ty6Jx1SojFP6u5vpd" style=3D"text-decoration:none;"><sp=
an style=3D"color:#0000FF;text-decoration:underline;">here</span></a></p>
</div></td><td style=3D"vertical-align:middle;font-size:11px;padding-top:10=
px;padding-right:10px;padding-bottom:10px;padding-left:10px;"><div style=3D=
"word-wrap:break-word;line-height:140%;text-align:left;"><p style=3D"font-s=
HMA! Team<br />
7 Moor Street, London, W1</p>
td></tr></tbody></table><img src=3D"
-2BVc7jUbO6UR1aQLl3SABAXZmk6De5NwmlyR6hcYyRFO41DxM9x57ykIW0Q-3D-3D" alt=3D"=
" width=3D"1" height=3D"1" border=3D"0" style=3D"height:1px !important;widt=
h:1px !important;border-width:0 !important;margin-top:0 !important;margin-b=
ottom:0 !important;margin-right:0 !important;margin-left:0 !important;paddi=
ng-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;=
padding-left:0 !important;"/>


Posts: 8
Joined: Sat Aug 08, 2015 10:45 pm

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

Post by Iddertew » Sat Aug 08, 2015 11:14 pm

Thank you for good communication.