PureVPN Doesn’t Need to Keep Logs Given How Many Google Keeps

There’s a cyber-stalking case in MA that has a lot of people questioning whether or not VPNs keep serial cyber-stalkers safe from the FBI. In it, Ryan Lin is accused of stalking a former roommate, referred to by the pseudonym Jennifer Smith in the affidavit, as well as conducting some bomb hoaxes and other incidences of stalking (if these accusations are true he’s a total shithole with severe control problems).

Because the affidavit in the case refers to tying Lin’s usage to several VPNs, it has been read to confirm that PureVPN, especially, has been keeping historic logs of users, contrary to their public claims. To be clear: you can never know whether a VPN is honest about keeping logs or not, and simply having a VPN on your computer might provide means of compromise (sort of like an anti-virus), that makes you more vulnerable. But I don’t think the affidavit, by itself (particularly with a great deal of the evidence in the case still hidden), confirms PureVPN is keeping logs. Rather, I think the account matching described in the affidavit says the FBI could have identified which VPNs Lin used via orders to Google, Facebook, and other tech companies, and using that, obtained a pen register on PureVPN collecting prospective traffic. I don’t think what is shown proves that FBI obtained historic logs (though it doesn’t disprove it either).

One thing to understand about this case is that Lin would have been the suspect right from the start, because his stalking started while he still lived with Smith, and intensified right after his roommates got him evicted. Plus, some of his stalking of Smith and others involved his real social media accounts. That means that, at a very early stage in this investigation, FBI would have been able to get all this information from Google and Facebook, which his victims knew he used.

A. The following information about the customers or subscribers of the Account:
1. Names (including subscriber names, user names, and screen names);
2. Addresses (including mailing addresses, residential addresses, business addresses, and e-mail addresses);
3. Local and long distance telephone connection records;
4. Records of session times and durations, and the temporarily assigned network addresses (such as Internet Protocol (“IP”) addresses) associated with those sessions;
5. Length of service (including start date) and types of service utilized;
6. Telephone or instrument numbers (including MAC addresses);
7. Other subscriber numbers or identities (including temporarily assigned network addresses and registration Internet Protocol (“IP”) addresses (including carrier grade natting addresses or ports)); and
8. Means and source of payment for such service (including any credit card or bank account number) and billing records.

B. All records and other information (not including the contents of communications) relating to the Account, including:
1. Records of user activity for each connection made to or from the Account, including log files; messaging logs; the date, time, length, and method of connections; data transfer volume; user names; and source and destination Internet Protocol addresses;
2. Information about each communication sent or received by the Account, including the date and time of the communication, the method of communication, and the source and destination of the communication (such as source and destination email addresses, IP addresses, and telephone numbers);
3. Records of any accounts registered with the same email address, phone number(s), method(s) of payment, or IP address as [] the accounts listed in Part 1; and Records of any accounts that are linked to either of the accounts listed in Part 1 by machine cookies (meaning all Google user IDs that logged into any Google account by the same machine as [] the accounts in Part 1). [my emphasis]

So very early in the investigation (almost certainly 2016), the FBI would have started obtaining every IP address that Lin was using to access Google and Facebook, and any accounts tied to the IP addresses used to log into his known accounts.

Instragram IDs WAN usage

Now consider the different references to VPNs in the affidavit. First, in February 2017, Lin registered a new Instagram account via WAN Security, one of the three VPNs listed.

February 2017: Lin registers Instagram account via WAN Security, also uses it to send email from [email protected] to local police department

That would mean that from the time FBI learned he used WAN to register with Instagram, the FBI would have known he used that service, and probably would have a very good idea which WAN server he default logged into.

Gmail ties WAN usage to other pseudonymous accounts

Then, FBI tracked April 2017 activity to connect Lin to an anonymous account at a service called Rover that he used to stalk people.

  • April 14, 2017, 14:55:52: Lin’s Gmail address accessed from IP address tied to WANSecurity server
  • April 14, 2017, 15:06:27: “Ashley Plano,” using [email protected], accessed Rover via same WANSecurity server
  • April 17, 2017, 21:54:25: “Ashley Plano” accesses Rover via Secure Internet server
  • April 17, 2017, 23:19:12: Lin’s Gmail address accessed via same Secure Internet server
  • April 18, 2017, 23:48:28: Lin’s Gmail address accessed via same Secure Internet server
  • April 19, 2017, 00:30:11: Ashley Plano account accessed via same Secure Internet server
  • April 24, 2017 (unspecified times): Lin’s Gmail and [email protected] email account accessed via same Secure Internet server

The WAN Security usage would have been accessible from Lin’s Gmail account (and would have been known since at least February). A subpoena to Rover after reports it was used for stalking would have likewise shown the WAN Security usage and times (assuming their logs are that detailed).

The Secure Internet use would have likewise shown up in his Gmail usage. Matching that to the Rover logs would have been the same process as with the WAN Security usage. And matching Lin’s known Gmail to his (alleged) pseudonymous teleportx email would have been done by Google itself, matching other accounts accessed by the IP Lin used (though they would have had to weed out other multiple Secure Internet server users).

In other words, this stuff could have come — and almost certainly did — from 2703(d) order returns available with a relevance standard, probably starting months before this activity.

Work computer confirms PureVPN usage, may provide account number

Then there’s this information, tying Lin’s work computer to PureVPN.

July 24, 2017: Lin fired by his unnamed software company employer — he asks, but is denied, to access his work computer to sign out of accounts

August 29, 2017: FBI agents find “Artifacts indicat[ing] that PureVPN, a VPN service that was used repeatedly in the cyberstalking scheme, was installed on the computer.”

What is not mentioned here is whether the “artifact” that showed Lin, like a fucking moron, loaded PureVPN onto his work computer also included him loading his PureVPN account number onto the computer. I think the vagueness here is intentional — both to keep the information from us and from Lin (at least until he signs a protection order). I also think this discussion, while useful for establishing probable cause to search his house, is also a feint. I suspect they already had Lin tied to PureVPN, and probably to a specific account there.

FBI’s not telling when and how they IDed Lin’s PureVPN usage, but Google would have had it

Which leads us to this language, which is the stuff that has everyone wigged out about PureVPN keeping logs.

Further, records from PureVPN show that the same email accounts–Lin’s gmail account and the teleportfx gmail account–were accessed from the same WANSecurity IP address. Significantly, PureVPN was able to determine that their service was accessed by the same customer from two originating IP addresses: the RCN IP address from the home Lin was living in at the time, and the software company where Lin was employed at the time.

[snip]

PureVPN also features prominently in the cyberstalking campaign, and the search of Lin’s workplace computer showed access of PureVPN.

Unlike almost every reference in this affidavit, there’s no date attached to this knowledge. It appears after the work computer language, leaving the impression that the knowledge came after the work computer access. But particularly since FBI alleges Lin used PureVPN for a lot of his stalking, they probably were looking at PureVPN much earlier.

One thing is certain: FBI could have easily IDed a known PureVPN server accessing Lin’s Gmail account and the teleportfx one FBI identified at least as early as April, months before finding PureVPN loaded onto his work computer.

The FBI doesn’t say which victims Lin accessed via PureVPN or when, only that it figured prominently. It does say, however, that PureVPN identified use from both Lin’s home and work addresses.

Most importantly, FBI doesn’t say when they asked PureVPN about all this. Nothing in this affidavit rules out the FBI serving PureVPN with a PRTT to track ongoing usage tied to Lin’s known accounts (rather than historical usage tied to them). Mind you, there’s nothing to rule out historical logs either (as the affidavit also notes, Lin at one point tweeted something indicating knowledge that VPNs will at least keep access information tied to users).

Here’s the thing, though: if you’re using the same Gmail account tied to the same home IP to access three different VPN providers, often on the same day, your VPN usage is going to be identified from Google’s extensive log keeping. It is an open question what the FBI can do with that knowledge once they have it — whether they can only collect prospective information or whether a provider is going to have some useful historical knowledge to share. But the FBI didn’t need historic logs from PureVPN to get to Lin.

image_print
13 replies
  1. SpaceLifeForm says:

    Note that all of this correlation can occur even if using a VPN that does not log anything and is free money wise. Call it an anonymous VPN. Now, there is no such thing, because they will go broke at some point. They can say that they do not log but they have to be making some money somewhere to pay for server and bandwidth costs.

    But, assume that a truely free (no PII needed) and no logging VPN actually exists.

    Let’s call it PipeDream VPN.

    Now, PipeDream VPN will have one or more servers and some DNS infrastructure in place, and TLS certificates. So even if they want to provide PipeDream VPN totally free to end users, and not log anything, the servers ip addresses have to be usuable.

    And because they have ip addresses, DNS, and TLS certs, the operators are not truely invisible. It may very well be the case that one can not really figure out who is really providing the PipeDream VPN, at least not easily. But LE/IC can if they want to. They may not want to because it is one of them! And they may not want to because they do not need too!

    Let’s assume that PipeDream VPN is really stealthy, and LE/IC knows or does not care who the operators are.

    LE/IC has the ip addresses, and in conjunction with UPSTREAM, all they have to do is log TCP 3-way handshakes (with timestamps) which show connection establishment. And log the 4-way handshake (with timestamps) for connection teardown. And maybe log timestamp of last payload packet (normal packet, not 3-way or 4-way) and idle times (may also be known as ‘think-time’).

    Now they know when and for how long the connection was *up*. They know the two ip addresses involved. The source ip address will be tied to the user end and the destination ip address would be one of the PipeDream VPN servers.

    Note that no content need be collected during the entire session. But they may count the bytes.

    Now, one may be wondering: How does this prove anything?

    The trick is the same thing happens on the other side of the PipeDream VPN.

    The VPN is just a tunnel, and by correlating connection timestamps on the user to PipeDream VPN side (and byte counts) with the connection timestamps (and byte counts) of the connection between the PipeDream VPN server and the actual end server that the user visits, one can tie the user to the actual end server.

    So if they have a suspect and get the suspect ip address(es) from suspect ISP,, then they can search on the collected UPSTREAM data for suspects ip address(es), find traffic to PipeDream VPN, then use the PipeDream VPN ip address(es) to search again for target end sites using correlated timestamps (and bytecounts). Magic. Now LE/IC has a list of sites that suspect probably visited. LE/IC then goes to target site for more info (logs).

    No logs or cooperation needed from PipeDream VPN at all!

    Note the same kind of traffic analysis applies to Tor.

    • bmaz says:

      Hey Genius SLF, would you like to translate your acronym and tech speak gibberish to actual English for the readers here?

      Because, if not, then you are not worth squat. That is what we have always done here. If you can’t do that, then you are in the wrong place.  Frankly, I think you are just blowing shit, and don’t have anything better.

      Do you? Otherwise, this is not your little jabberwocky playground, and you need to find a new place to troll with your navel gazing.

      • SpaceLifeForm says:

        Sorry. I tried to keep the entire scenario as simple as possible without being overly technical. But, alas, when technology is involved, one must use some tech terms.

        YPN – Virtual Private Network
        PII – Personally Identifying Information
        DNS – Domain Name System
        TLS – Transport Level Security

    • OldFart says:

      “LE/IC has the IP addresses, and in conjunction with UPSTREAM, all they have to do is log TCP 3-way handshakes (with timestamps) which show connection establishment. And log the 4-way handshake (with timestamps) for connection teardown. And maybe log timestamp of last payload packet (normal packet, not 3-way or 4-way) and idle times (may also be known as ‘think-time’).”

      If LE/IC both have the IP of the VPN server the user is connecting to (which would show in the logs of the sites that were used, which they would easily get) and the IP of the suspect, then it’s extremely easy to correlate between them.
      But the problem arises when they don’t have the suspects IP.  They would need to have access to every ISPs logs in the country to do this (unlikely), and even then it may yield incomplete results if the suspect is smart and tunnels like Home -> Some 3rd world country -> His VPN -> Website
      Then there would never be a connection between his home IP address and the IP address of the VPN they suspect he’s using.

      They could do the packet size/timing correlation attack but I doubt that the packet size will be always the same. (My theory: What if the 3rd world country VPN fragments packets and reassembles them on their server?)

      “The VPN is just a tunnel, and by correlating connection timestamps on the user to PipeDream VPN side (and byte counts) with the connection timestamps (and byte counts) of the connection between the PipeDream VPN server and the actual end server that the user visits, one can tie the user to the actual end server.”

      This could only happen if the PipeDream VPN keeps logs, otherwise, they’d have to tap the datacenter of the server that he’s using and then run a Deep Packet Inspection machine, which is highly unlikely (as one costs 500,000 Euros and higher), or hack it (the cheaper way) but I doubt that this would be admissible in court, or they issue a gag order on the VPN owners and install a blackbox if both VPN servers are in the USA (could be also FVEY?; which is pretty dumb to do in the first place).

      btw. What do you mean by UPSTREAM? Some kind of a 3-letter agency program or you mean the data sent outbound?

      • SpaceLifeForm says:

        “But the problem arises when they don’t have the suspects IP.”

        Not applicable in this case. The roommate called the police at some point. If the roommate was technical at all, she could have told the police or FBI the WAN ip of their residence herself! Even if she did not, it would be trivial for police/FBI to contact the ISP and get the WAN ip from ISP logs via residence street address.

        That is all they need. The WAN (Wide Area Network) ip addresses given to the residence from the ISP.

        It matters not if the suspect is connecting to a nearby website, or a nearby VPN, or a website in foreign country, or VPN in foreign country. It makes no difference at all. The connections will be findable with enough traffic analysis. Some will be trivial to correlate, some will take more effort (VPN), and some will take a lot of effort (Tor). But with enough effort, the suspect will leave the tracks that will be found.

        It may take weeks or more.

        Just google:

        G(parallel construction)
        G(upstream collection)

  2. Fish out of water says:

    It is my understanding that VPNs are encrypted tunnels designed, in part, to prevent man-in-the-middle attacks on the content of the message, document, video, whatever. If you want to obscure destinations of the encrypted content you would need to use something like the TOR/Onion infrastructure.

    OldFart, thank you for the civil response to SLF but if you think “they” don’t have access to every ISP’s logs in the country then you haven’t been paying attention – see: NSA / Snowden, Edward.

    Regards

    • SpaceLifeForm says:

      “It is my understanding that VPNs are encrypted tunnels designed, in part, to prevent man-in-the-middle attacks on the content of the message, document, video, whatever.”

      Correct. Especially the ‘last mile’. Example, you are on travel for your corporation, but need to use untrustable hotel wifi.

      The primary and really only the best use of VPN technology is if you are remote and need to reach your corporate Intranet to do work.

      But one should not then go back out to the internet at large via work VPN and do bad stuff. Just like one should not go out to internet at large and do bad stuff even if you are at corp hq.

      If you are up to nefarious things, you do not want to go thru your work VPN.

      But if you are up to no good, even if you use a non-work VPN (or use Tor), you can eventually be caught via traffic analysis.

      That was the entire point of my original post.

      The VPN provider (PipeDream in my example) (or Tor), does not have to provide any logs whatsoever!

  3. greengiant says:

    Yes, per EW the FBI had both ends on the VPN,  the IP the suspect used to send,  and the VPN outlet IP addresses on all the stalking.  Don’t we all assume Google/ISP(Internet service provider)s  are keeping track of metadata of every web link request versus IP (Internet protocol address assigned to you by your ISP and which every adbot and cookie tracks to identify you)  address because I read that Google provides a blacklist function to the ISPs.   And add in all those DNS lookups loggers and so forth as revealed by the “trump tower server”  supposedly later found to be in Philadelphia.

    Back in the day before spam filters got upgraded and I was checking firewall logs,  I found that a number of adbots and other email phishers were using dynamic IP addresses from the cloud computer providers such as Amazon and Google? and so forth.  Now those cloud computer services rent time on their machines via dynamic pricing depending on the demand.  While the teen hackers that go about providing denial of service attacks using their network of bots on captured computers and internet of things,  a more sophisticated attack might use a cut-out or stolen credit cards to purchase cloud computer just like they use to purchase malware domain names on the internet registry.  So I am thinking the sophisticates can roll their own VPNs or use VPNs that only use cloud computers that make the NSA’s and the likes of Cambridge Analytics’ work a tad more difficult.  I mean good luck trying to get Amazon to tell you who was assigned that IP address at that microsecond especially after your firewall clock is hacked.   As for TOR,  getting a hit from the Maldives or Indonesia or some place triggers hey this is a  TOR exit node or some captured computer.

    Maybe some more obvious tracking vectors than these that defeat VPNs.

    • SpaceLifeForm says:

      As to firewall logs, one must look at outbound, and probably most do not.

      Well over a decade ago, I caught javascript doing SSL (pre TLS) back to somewhere.

      I know the attack came in via an ad server.

    • SpaceLifeForm says:

      One more point on timestamps.

      They do not have to be microsecond accurate.

      Within a minute or so is good enough when combined with byte counts for correlation purposes.

      In fact, remains me of the Y2K rollover.
      A group of people using different cellcos.
      I told them none of their phones would roll over at the same time. That they would not even be within seconds of each other.

      Over one minute from first phone to last phone.

      Almost 1.5 minutes.

      Proved to me two things:

      Telcos/Cellcos not using NTP properly.
      Telcos/Cellcos timestamped logs therefore not that accurate.

      But close enough for government work.

Comments are closed.