WEBVTT 00:00:01.090 --> 00:00:04.799 JACK: You ever get fascinated with the cyber-crime supply chain? 00:00:04.799 --> 00:00:09.540 It’s never a solo hacker doing the whole thing; there’s a lot of layers to this onion. 00:00:09.540 --> 00:00:14.210 So, let’s say a hacker breaks into a place and steals a bunch of information from some 00:00:14.210 --> 00:00:15.210 company. 00:00:15.210 --> 00:00:19.510 Well, next he’ll typically want to sell that data to make some money and do it again, 00:00:19.510 --> 00:00:21.810 so now you’ve got to find a buyer. 00:00:21.810 --> 00:00:25.810 But before we even get to the buyer of stolen data, there’s sometimes brokers involved, 00:00:25.810 --> 00:00:28.529 people who have negotiated deals between hackers and buyers. 00:00:28.529 --> 00:00:33.650 So you might go to one of these brokers, offer a percentage for selling the database to someone. 00:00:33.650 --> 00:00:35.630 Now it’s on them to find someone. 00:00:35.630 --> 00:00:39.771 But when the broker finds a buyer, sometimes one side doesn’t trust the other so they 00:00:39.771 --> 00:00:44.610 bring in a trusted third party, an underground escrow agent if you will, who will wait for 00:00:44.610 --> 00:00:48.961 both the cash and the database and then make the trade. 00:00:48.961 --> 00:00:51.640 Okay, but then what does the buyer do with this database dump? 00:00:51.640 --> 00:00:55.899 Well, if it’s full of e-mail addresses, they might use it to send spam to people. 00:00:55.899 --> 00:00:58.300 But of course, the spammer isn’t selling anything themselves. 00:00:58.300 --> 00:01:02.559 They’re typically promoting someone else’s business; a porn website or a pharmacy. 00:01:02.559 --> 00:01:05.379 It’s just fascinating for me to think about that sometimes. 00:01:05.379 --> 00:01:12.540 It’s never about the data breach itself but what happens to that data after its stolen. 00:01:12.540 --> 00:01:20.420 (INTRO): [INTRO MUSIC] These are true stories from the dark side of the internet. 00:01:20.420 --> 00:01:25.490 I’m Jack Rhysider. 00:01:25.490 --> 00:01:29.140 This is Darknet Diaries. 00:01:29.140 --> 00:01:36.820 [INTRO MUSIC ENDS] 00:01:36.820 --> 00:01:44.520 JACK: I’m sure you all know what LinkedIn is, right? 00:01:44.520 --> 00:01:47.270 It’s the social network for professionals. 00:01:47.270 --> 00:01:51.290 You pretty much start your account by posting your resume of where you worked and what you 00:01:51.290 --> 00:01:52.450 did there. 00:01:52.450 --> 00:01:56.120 You can use the site to look for jobs and connect with other professionals in your field. 00:01:56.120 --> 00:01:58.450 It’s pretty popular in the US. 00:01:58.450 --> 00:02:05.380 In 2012, a person wanted to hack into LinkedIn and get as much user data as they could, but 00:02:05.380 --> 00:02:08.250 how are you going to get into the network of LinkedIn? 00:02:08.250 --> 00:02:13.370 This is a major Silicon Valley company made by some really skilled engineers and administrators. 00:02:13.370 --> 00:02:17.819 They would certainly be following all the latest best practices for securing a network 00:02:17.819 --> 00:02:22.010 by doing things like securing the front door to the network by putting a big firewall up 00:02:22.010 --> 00:02:26.960 to block all non-critical traffic from coming in and inspecting it for malicious activity. 00:02:26.960 --> 00:02:30.360 Then they’ll conduct security audits on all the internet-facing systems to make sure 00:02:30.360 --> 00:02:32.300 there’s no security holes. 00:02:32.300 --> 00:02:36.180 Of course, they’ll be running state-of-the-art monitoring tools and antivirus tools to watch 00:02:36.180 --> 00:02:38.310 for any intrusions. 00:02:38.310 --> 00:02:42.070 They did all that; the front doors of LinkedIn’s network was airtight. 00:02:42.070 --> 00:02:45.220 So, the hacker would have to find another way in. 00:02:45.220 --> 00:02:50.620 [MUSIC] He knew that engineers at LinkedIn had access to the corporate network when they 00:02:50.620 --> 00:02:51.620 were remote. 00:02:51.620 --> 00:02:55.940 I mean, today it’s obvious that a lot of companies have remote employees but back in 00:02:55.940 --> 00:03:00.660 2012 there were LinkedIn employees who had remote access into the network. 00:03:00.660 --> 00:03:04.819 That is, they didn’t have to be physically in the office in order to access the database 00:03:04.819 --> 00:03:06.270 or other critical systems. 00:03:06.270 --> 00:03:11.370 So, the hacker set out to figure how exactly do some engineers get remote access into the 00:03:11.370 --> 00:03:12.370 network? 00:03:12.370 --> 00:03:15.290 He concluded they must be getting in through a VPN. 00:03:15.290 --> 00:03:18.709 A VPN is a way to securely connect into a remote network. 00:03:18.709 --> 00:03:22.750 The traffic is encrypted from the edge of the corporate network all the way to the user’s 00:03:22.750 --> 00:03:24.300 computer, wherever they are in the world. 00:03:24.300 --> 00:03:29.909 That’s just it; if there’s a backdoor entrance for employees only, it would also 00:03:29.909 --> 00:03:33.239 mean that the hacker could try to get in through that. 00:03:33.239 --> 00:03:37.989 So, the hacker starts looking on LinkedIn’s website for people who worked there; engineers, 00:03:37.989 --> 00:03:41.280 system administrators, anyone who might have access into that VPN. 00:03:41.280 --> 00:03:45.220 So, he looked around for a victim which by the way, this is the reason why I don’t 00:03:45.220 --> 00:03:49.500 like posting my information on LinkedIn, because you can easily search for all the people who 00:03:49.500 --> 00:03:53.600 work in a specific company and then figure out who the admins are there who are probably 00:03:53.600 --> 00:03:58.340 posting things like oh, I’m good at Cisco firewalls and Oracle databases, and they might 00:03:58.340 --> 00:04:03.060 even be posting what versions of Oracle they’re good at which is a clue to any hacker to know 00:04:03.060 --> 00:04:04.840 what to expect once they get in. 00:04:04.840 --> 00:04:10.360 But what this means is that it’s pretty easy to find a target and narrow your sights 00:04:10.360 --> 00:04:14.450 on them by just looking at who’s on LinkedIn. 00:04:14.450 --> 00:04:20.190 This hacker found a LinkedIn engineer who probably had remote VPN access as well as 00:04:20.190 --> 00:04:25.510 access to the database inside, and the hacker zeroed in on this guy. 00:04:25.510 --> 00:04:32.770 [MUSIC] The hacker saw this engineer’s LinkedIn profile and on his profile there was a URL 00:04:32.770 --> 00:04:35.800 to this engineer’s personal website. 00:04:35.800 --> 00:04:39.170 Basically, it was like this engineer’s name.com. 00:04:39.170 --> 00:04:41.139 The hacker went to the website to check it out. 00:04:41.139 --> 00:04:45.840 It was just a basic About Me-type blog; it said hello, I’m a site reliability engineer 00:04:45.840 --> 00:04:48.260 at LinkedIn and here are my hobbies and things. 00:04:48.260 --> 00:04:52.040 The hacker poked around here for a bit but couldn’t find anything to exploit. 00:04:52.040 --> 00:04:58.080 But he looked at where the site was hosted and it was hosted on a residential IP address. 00:04:58.080 --> 00:05:03.880 Hm, it seemed like this LinkedIn site reliability engineer was [00:05:00] running a web server 00:05:03.880 --> 00:05:05.509 out of his house. 00:05:05.509 --> 00:05:10.860 This means there are open ports from the internet into his computers. 00:05:10.860 --> 00:05:15.419 The hacker thought well, hm, if I can get into this engineer’s home computer, this 00:05:15.419 --> 00:05:17.510 might give me a way into LinkedIn. 00:05:17.510 --> 00:05:23.990 So, he looked to see if there are any other websites also hosted at this IP address, and 00:05:23.990 --> 00:05:27.250 he found one called cockeyed.com. 00:05:27.250 --> 00:05:31.330 He browsed around here and this is a much bigger blog-type website. 00:05:31.330 --> 00:05:34.210 Cockeyed.com was a site ran by this engineer’s friend. 00:05:34.210 --> 00:05:36.040 He just hosted it for him. 00:05:36.040 --> 00:05:39.870 There’s videos of pranks and pictures and it’s basically a blog. 00:05:39.870 --> 00:05:44.069 But this site was built using PHP as the back-end technology. 00:05:44.069 --> 00:05:47.220 The hacker started looking for ways to exploit this site. 00:05:47.220 --> 00:05:52.840 He found a way to upload files to the site and he uploaded a couple malicious PHP files. 00:05:52.840 --> 00:05:55.380 One was specifically called madnez.php. 00:05:55.380 --> 00:06:00.670 Now, if a hacker can upload their own PHP program to your website and get that program 00:06:00.670 --> 00:06:06.310 to execute, then the hacker can take over that computer that’s hosting the website, 00:06:06.310 --> 00:06:09.319 because when you go to view the file through a browser, it’s going to execute whatever 00:06:09.319 --> 00:06:15.050 code is in that PHP program, and you can configure it to give you remote access to that computer. 00:06:15.050 --> 00:06:17.479 That’s just what this file did. 00:06:17.479 --> 00:06:22.220 The hacker got shell access to the website cockeyed.com which was being hosted in the 00:06:22.220 --> 00:06:26.060 same place this LinkedIn engineer’s personal blog was hosted. 00:06:26.060 --> 00:06:29.370 Once he got into the web server, he started scanning for other IPs in the network and 00:06:29.370 --> 00:06:31.520 found one, an iMac computer. 00:06:31.520 --> 00:06:37.400 He found that this iMac had an open SSH port which allows people to connect to that iMac. 00:06:37.400 --> 00:06:41.290 So, he started trying to brute-force login to that iMac. 00:06:41.290 --> 00:06:45.281 For the username, he used a first initial and the last name of the LinkedIn engineer 00:06:45.281 --> 00:06:49.960 and he just started hammering away, trying thousands and thousands of passwords, looking 00:06:49.960 --> 00:06:51.599 for one that worked. 00:06:51.599 --> 00:06:54.509 This was all happening in February of 2012. 00:06:54.509 --> 00:07:00.379 For days, this web server was attacking the iMac, all within this engineer’s house without 00:07:00.379 --> 00:07:02.330 the engineer knowing it. 00:07:02.330 --> 00:07:06.349 After a few days of trying thousands of passwords, one worked. 00:07:06.349 --> 00:07:11.990 [MUSIC] He got a hit for a valid username and password, so the hacker logged into that 00:07:11.990 --> 00:07:14.930 iMac with this and looked around. 00:07:14.930 --> 00:07:17.419 First he realized this is a person’s personal iMac. 00:07:17.419 --> 00:07:21.490 It’s not a LinkedIn computer or even an official work computer. 00:07:21.490 --> 00:07:26.750 Then he discovered that this web server that he got into was running on this iMac. 00:07:26.750 --> 00:07:32.389 Yeah, it was actually running on a virtual machine in the iMac and I find this fascinating 00:07:32.389 --> 00:07:37.150 because in essence, the virtual machine was the only thing exposed to the internet, but 00:07:37.150 --> 00:07:41.819 the hacker got into the virtual machine and then got into the host computer from there. 00:07:41.819 --> 00:07:46.340 It’s fascinating to me because this shouldn’t happen, but the way he did it was through 00:07:46.340 --> 00:07:48.669 the virtual IP interface. 00:07:48.669 --> 00:07:52.440 Because I always wonder how it’s possible to escape out of a virtual machine and onto 00:07:52.440 --> 00:07:56.569 the host computer, and here’s an example of when a hacker did that. 00:07:56.569 --> 00:08:00.599 After looking around the iMac for a while, the hacker stumbled upon the keys to the kingdom. 00:08:00.599 --> 00:08:03.960 Literally; he found a private key to LinkedIn. 00:08:03.960 --> 00:08:07.350 This was the key that the engineer could use to log into LinkedIn with. 00:08:07.350 --> 00:08:11.370 See, when you log into certain systems, you could use a username and a password but another 00:08:11.370 --> 00:08:15.640 option is to use public and private keys, where the public key is put on the server 00:08:15.640 --> 00:08:19.560 you need to access and your private key is on your own computer so when you connect to 00:08:19.560 --> 00:08:22.199 the server, you authenticate using the keys. 00:08:22.199 --> 00:08:26.449 This is all done automatically and saves you from having to type passwords. 00:08:26.449 --> 00:08:30.520 But when the hacker saw the private key, he snagged it right away. 00:08:30.520 --> 00:08:32.890 But where does this private key connect to? 00:08:32.890 --> 00:08:36.380 Well, the hacker had to look around a little bit more to find out, and that’s when he 00:08:36.380 --> 00:08:43.430 found a set of VPN profiles that allowed this person’s iMac to connect to LinkedIn. 00:08:43.430 --> 00:08:48.060 The profile contained everything they needed to connect; the server name, the IP address, 00:08:48.060 --> 00:08:49.060 the username. 00:08:49.060 --> 00:08:52.959 The only thing missing was the private key which the hacker just got. 00:08:52.959 --> 00:08:58.310 [MUSIC] The hacker then took this VPN profile and credentials and connected directly into 00:08:58.310 --> 00:08:59.990 LinkedIn’s VPN server. 00:08:59.990 --> 00:09:04.040 Now, here’s where the hacker made a major mistake; [00:10:00] he made this connection 00:09:04.040 --> 00:09:09.420 into LinkedIn from his home which was in Moscow, Russia. 00:09:09.420 --> 00:09:11.040 LinkedIn is in California. 00:09:11.040 --> 00:09:15.740 Well, there was nothing to stop this connection coming in from Moscow though, so he just got 00:09:15.740 --> 00:09:17.000 right in. 00:09:17.000 --> 00:09:21.070 From here, he was able to find his way around the network, looking for the user database, 00:09:21.070 --> 00:09:22.070 and he found it. 00:09:22.070 --> 00:09:27.690 He was able to log into that and grab the username, password hash, and e-mail addresses 00:09:27.690 --> 00:09:31.190 of as many LinkedIn users as he could. 00:09:31.190 --> 00:09:35.880 After that, he logged out and disappeared. 00:09:35.880 --> 00:09:39.840 LinkedIn had just been breached but they didn’t know it yet and they wouldn’t find out for 00:09:39.840 --> 00:09:42.320 another three months. 00:09:42.320 --> 00:09:47.250 The first moment when LinkedIn learned about this was through a forum called insidepro.com. 00:09:47.250 --> 00:09:52.730 This was an underground criminal forum where you could buy and sell stolen data from hacks. 00:09:52.730 --> 00:09:55.550 Someone was offering LinkedIn user data for sale there. 00:09:55.550 --> 00:09:59.829 The team at LinkedIn saw this and immediately sprang into action. 00:09:59.829 --> 00:10:07.010 [MUSIC] First, they needed to verify that the data being sold online was real LinkedIn 00:10:07.010 --> 00:10:08.010 user data. 00:10:08.010 --> 00:10:13.830 They compared what was in that sample database with their own database and sure enough, the 00:10:13.830 --> 00:10:16.060 hashes matched. 00:10:16.060 --> 00:10:23.890 The horror and the fear you get when confirming that you’ve just been breached, it’s indescribable. 00:10:23.890 --> 00:10:29.170 Now, LinkedIn’s response for something like this is a four-step process. 00:10:29.170 --> 00:10:32.920 First you confirm, contain, remediate, and do post-mortem. 00:10:32.920 --> 00:10:36.070 They just confirmed that they were breached. 00:10:36.070 --> 00:10:38.490 Next is for them to contain the problem. 00:10:38.490 --> 00:10:40.670 Is the hacker still in the network? 00:10:40.670 --> 00:10:41.800 What did they steal? 00:10:41.800 --> 00:10:42.800 How did they get in? 00:10:42.800 --> 00:10:45.140 Can we block them from getting in again? 00:10:45.140 --> 00:10:49.190 All these questions needed immediate answers. 00:10:49.190 --> 00:10:52.950 LinkedIn engineers and security team took over a conference room and called it a War 00:10:52.950 --> 00:10:53.950 Room. 00:10:53.950 --> 00:10:58.149 Something like forty to sixty people from LinkedIn were all working on this incident. 00:10:58.149 --> 00:11:00.620 They were flying in from foreign countries to help. 00:11:00.620 --> 00:11:04.810 They had the security team involved hunting through events and logs, looking for evidence. 00:11:04.810 --> 00:11:09.230 They had SREs, or site reliability engineers, and they’re combing through their systems 00:11:09.230 --> 00:11:11.430 looking for traces of unauthorized activity. 00:11:11.430 --> 00:11:13.139 There were lawyers present. 00:11:13.139 --> 00:11:17.779 Their Chief Internet Security Officer was present and active, doing all kinds of triage. 00:11:17.779 --> 00:11:23.310 Other executives were in the room too because this was the most important thing going on 00:11:23.310 --> 00:11:25.279 at LinkedIn at the time. 00:11:25.279 --> 00:11:29.140 The atmosphere was heavy and intense. 00:11:29.140 --> 00:11:33.870 The first clue they got was from the VPN logs. 00:11:33.870 --> 00:11:38.540 The LinkedIn security team saw that one of their California-based engineers had logged 00:11:38.540 --> 00:11:41.730 into the VPN from Moscow numerous times. 00:11:41.730 --> 00:11:43.529 So, they called him in for an interview. 00:11:43.529 --> 00:11:46.279 Hey, have you been to Russia lately? 00:11:46.279 --> 00:11:47.279 No. 00:11:47.279 --> 00:11:49.230 Did you use any kind of Russian proxy lately? 00:11:49.230 --> 00:11:50.230 No. 00:11:50.230 --> 00:11:53.320 Did you give anyone in Russia your login details? 00:11:53.320 --> 00:11:54.320 No. 00:11:54.320 --> 00:11:56.760 The security team was on the trail. 00:11:56.760 --> 00:11:57.850 This was a major clue. 00:11:57.850 --> 00:12:01.410 They found out that this engineer had been connecting to the corporate network from his 00:12:01.410 --> 00:12:05.450 home iMac and I’m gonna guess that probably wasn’t allowed. 00:12:05.450 --> 00:12:10.470 But the security team asked him to bring that iMac in for an examination. 00:12:10.470 --> 00:12:14.550 So, let’s back up a month, actually. 00:12:14.550 --> 00:12:19.019 So, a month before LinkedIn even knows this happened, the hacker was looking through the 00:12:19.019 --> 00:12:20.220 database that he stole. 00:12:20.220 --> 00:12:24.160 It contained e-mail addresses, usernames, and password hashes. 00:12:24.160 --> 00:12:27.980 This isn’t the password itself; it’s a representation of the password after it goes 00:12:27.980 --> 00:12:28.990 through an algorithm. 00:12:28.990 --> 00:12:33.279 So, in other words, you couldn’t see anyone’s password in this dump. 00:12:33.279 --> 00:12:39.389 But the hacker wanted to find a way to crack these passwords, so he posted a few of the 00:12:39.389 --> 00:12:43.270 hashes to a forum asking for help on how to crack them. 00:12:43.270 --> 00:12:48.590 When LinkedIn was investigating this, they saw that old post which matched the hashes 00:12:48.590 --> 00:12:50.330 that were in their database. 00:12:50.330 --> 00:12:52.579 The situation was getting worse for LinkedIn. 00:12:52.579 --> 00:12:57.870 They’re now seeing that the hacker is actively trying to crack users’ hashes. 00:12:57.870 --> 00:13:03.630 Unfortunately for LinkedIn, they weren’t yet salting their password hashes. 00:13:03.630 --> 00:13:09.680 Salting password hashes is an extra step that you do to make cracking hashes even harder. 00:13:09.680 --> 00:13:13.709 They were in the process of doing this but when you have hundreds of millions of users, 00:13:13.709 --> 00:13:15.890 it’s not easy to get it done. 00:13:15.890 --> 00:13:20.709 [MUSIC] At LinkedIn, they have different designations for how serious an incident is. 00:13:20.709 --> 00:13:24.800 Code Yellow is something that is some kind of technical risk like a server running over 00:13:24.800 --> 00:13:29.199 capacity or they’re not sure how to scale it properly, or a degradation of service that 00:13:29.199 --> 00:13:32.850 isn’t causing a whole outage but could at any moment. 00:13:32.850 --> 00:13:37.339 Code Yellows happen every few months or so there but as the LinkedIn team investigated 00:13:37.339 --> 00:13:42.190 this, they determined this incident was a Code Red, meaning it was business-impacting 00:13:42.190 --> 00:13:46.620 and because they were already seeing user data leaked to the internet, it meant this 00:13:46.620 --> 00:13:50.700 threat was certain and it could be at any moment that the LinkedIn database dump was 00:13:50.700 --> 00:13:52.029 revealed to the world. 00:13:52.029 --> 00:13:56.320 I believe at the time it was only available to whoever would buy it and it wasn’t freely 00:13:56.320 --> 00:13:58.250 available for anyone to look at. 00:13:58.250 --> 00:14:02.579 This creates a tense and scary moment for any security team; not knowing [00:15:00] 00:14:02.579 --> 00:14:07.449 what or how much got stolen and not knowing what the thieves plan on doing with it. 00:14:07.449 --> 00:14:11.589 There’s a level of anxiety here especially because this was already hitting the news 00:14:11.589 --> 00:14:14.620 media who was announcing this hack to the world. 00:14:14.620 --> 00:14:18.520 Lots of different teams were pulling logs and saving them for incident responders to 00:14:18.520 --> 00:14:19.520 comb through. 00:14:19.520 --> 00:14:24.329 It’s best to have logging turned on so you can sort of go back in time and see what happened 00:14:24.329 --> 00:14:25.329 where. 00:14:25.329 --> 00:14:29.020 One problem though is that there’s now a lot of logs to go through and if you think 00:14:29.020 --> 00:14:33.930 about the millions of users who are on the site every day, trying to find a needle in 00:14:33.930 --> 00:14:36.380 a haystack is tricky. 00:14:36.380 --> 00:14:40.870 I think the day they discovered this or the day after is when LinkedIn called the FBI 00:14:40.870 --> 00:14:42.630 to inform them of this breach. 00:14:42.630 --> 00:14:44.400 The FBI was very responsive. 00:14:44.400 --> 00:14:48.000 They asked for logs and started interviewing people right away. 00:14:48.000 --> 00:14:52.899 [MUSIC] LinkedIn saw that IPs were connecting in from Moscow, and so they took that IP and 00:14:52.899 --> 00:14:54.339 started tracing it through the network. 00:14:54.339 --> 00:14:55.700 Where did it go? 00:14:55.700 --> 00:14:56.790 What did it access? 00:14:56.790 --> 00:15:01.620 They were looking through SSH logs, Wiki logs, server access logs, and they saw connections 00:15:01.620 --> 00:15:07.310 from that IP which told them what user agent the hacker’s computer had. 00:15:07.310 --> 00:15:11.740 The user agent can tell you things like operating system, browser type, and version. 00:15:11.740 --> 00:15:13.990 The hacker’s user agent was unique. 00:15:13.990 --> 00:15:17.940 It actually had the word Sputnik in the end which isn’t normal. 00:15:17.940 --> 00:15:21.649 Sputnik is the name of the first satellite to be put in orbit by the Russians and this 00:15:21.649 --> 00:15:26.560 user agent just wasn’t seen by anyone before that which makes me wonder if the hacker put 00:15:26.560 --> 00:15:29.329 it there as sort of a signature. 00:15:29.329 --> 00:15:33.709 With this extra information, engineers can now search logs for that particular user agent 00:15:33.709 --> 00:15:38.230 to see if that has any hits for it, because maybe the hacker wasn’t using the same IP 00:15:38.230 --> 00:15:39.230 every time. 00:15:39.230 --> 00:15:41.980 Maybe they had come in from different IPs and different channels and different VPNs 00:15:41.980 --> 00:15:45.990 or something, but if there was a matching user agent, then you could know that that’s 00:15:45.990 --> 00:15:47.430 probably the same person. 00:15:47.430 --> 00:15:51.639 Next, they looked at the public website to LinkedIn to see if anyone with a matching 00:15:51.639 --> 00:15:57.110 IP or a matching user agent was logged into any user’s account on linkedin.com. 00:15:57.110 --> 00:15:59.250 Sure enough, there was some activity. 00:15:59.250 --> 00:16:04.730 The same IP and user agent was seen logging into thirty different LinkedIn accounts through 00:16:04.730 --> 00:16:06.660 the public website. 00:16:06.660 --> 00:16:12.560 This meant that the hacker had cracked some passwords that was in the data and was logging 00:16:12.560 --> 00:16:14.490 into LinkedIn with those users. 00:16:14.490 --> 00:16:18.060 This certainly elevated the concern for LinkedIn. 00:16:18.060 --> 00:16:22.250 Back in Moscow, the hacker did in fact have a rather beefy GPU farm. 00:16:22.250 --> 00:16:25.100 See, cracking password hashes is process-intensive. 00:16:25.100 --> 00:16:30.320 You have to cycle through millions of passwords, hash them, and see if those hashes match the 00:16:30.320 --> 00:16:31.770 hash in the database. 00:16:31.770 --> 00:16:33.769 If so, you’ve found a password. 00:16:33.769 --> 00:16:38.699 Graphics cards, GPUs, are particularly good at doing a lot of these little calculations 00:16:38.699 --> 00:16:39.699 like this. 00:16:39.699 --> 00:16:41.610 They can do a lot of simultaneous things at once. 00:16:41.610 --> 00:16:46.170 So, the hacker was running the database dump through this password-cracking station he 00:16:46.170 --> 00:16:50.519 had, and when he’d get a match on someone that he found interesting, he’d try logging 00:16:50.519 --> 00:16:53.920 into LinkedIn to verify it, and it did in fact work. 00:16:53.920 --> 00:17:01.300 He was logging into linkedin.com as different users. 00:17:01.300 --> 00:17:04.539 Back at LinkedIn, engineers started checking the database servers. 00:17:04.539 --> 00:17:08.280 They took the information they discovered and searched the logs to see if anyone had 00:17:08.280 --> 00:17:13.120 logged into the database servers with these IPs, username, or user agent. 00:17:13.120 --> 00:17:17.220 The database LinkedIn used at the time was Oracle which was on a UNIX machine. 00:17:17.220 --> 00:17:22.731 So, they looked to see if anyone connected to it using SSH and sure enough, they did. 00:17:22.731 --> 00:17:27.390 There were logs of the hacker logging into the database server and then accessing the 00:17:27.390 --> 00:17:30.429 database and running queries in that database. 00:17:30.429 --> 00:17:33.940 To get this far into the investigation took LinkedIn six weeks. 00:17:33.940 --> 00:17:39.070 [MUSIC] I’m talking an active War Room, Code Red situation for six weeks solid with 00:17:39.070 --> 00:17:43.270 multiple teams, dozens of people looking through thousands of servers, combing through millions 00:17:43.270 --> 00:17:44.270 of logs. 00:17:44.270 --> 00:17:45.830 It just takes a lot of time. 00:17:45.830 --> 00:17:48.929 During this time, they forced LinkedIn employees to change their passwords. 00:17:48.929 --> 00:17:53.840 They created a whole new account for the engineer who initially got hacked with that iMac computer, 00:17:53.840 --> 00:17:57.490 and they rebuilt servers to make sure there were no traces left on the system. 00:17:57.490 --> 00:18:02.309 Also, it appears that LinkedIn announced this breach as soon as they could to the public 00:18:02.309 --> 00:18:06.050 to inform their users that something bad has happened. 00:18:06.050 --> 00:18:12.160 HOST1: LinkedIn users beware; the business social network says some of its users’ passwords 00:18:12.160 --> 00:18:15.490 have been stolen and leaked onto the internet. 00:18:15.490 --> 00:18:21.210 HOST2: A hacking group rocked online network LinkedIn this week by publishing almost six 00:18:21.210 --> 00:18:25.659 and a half million user passwords to the site. 00:18:25.659 --> 00:18:32.090 JACK: 6.5 million LinkedIn user accounts were claimed to be on some hacker forums. 00:18:32.090 --> 00:18:38.309 However, not all 6.5 million passwords were visible and the dump seemed to only be in 00:18:38.309 --> 00:18:43.340 the hands of a few people at the time, with just a sample of it posted publicly. 00:18:43.340 --> 00:18:49.560 Now, the posting and the investigation all happened in June 2012, but my research shows 00:18:49.560 --> 00:18:55.840 the hacker got into the network back in March of that year, a whole three months earlier 00:18:55.840 --> 00:19:02.400 which means LinkedIn had no idea of this breach until it showed up on this public forum. 00:19:02.400 --> 00:19:09.250 [00:20:00] So, the hacker did this hack back in March 2012 but in May of 2012, before LinkedIn 00:19:09.250 --> 00:19:13.640 even knew they were breached, he hacked into another website too and I’m not exactly 00:19:13.640 --> 00:19:17.990 sure what steps he did here, but I’ve got high confidence of how it went. 00:19:17.990 --> 00:19:22.610 So, by May of 2012, the hacker had already cracked quite a few hashes in the database 00:19:22.610 --> 00:19:27.221 that he stole from LinkedIn and was testing some of these logins by logging into LinkedIn 00:19:27.221 --> 00:19:29.530 with those usernames, and it was working. 00:19:29.530 --> 00:19:33.960 My theory is that he went through the cracked passwords looking for anyone that worked for 00:19:33.960 --> 00:19:39.230 a big IT company as an engineer or admin, because this hacker was in the business of 00:19:39.230 --> 00:19:42.000 selling massive databases to make money. 00:19:42.000 --> 00:19:44.429 So, this was his thing. 00:19:44.429 --> 00:19:49.100 Looking through his cracked passwords, he found a quality assurance engineer who worked 00:19:49.100 --> 00:19:50.860 at Dropbox. 00:19:50.860 --> 00:19:57.220 He tested that the password worked by logging into this Dropbox engineer’s LinkedIn account. 00:19:57.220 --> 00:19:59.220 Yep, he got in no problem. 00:19:59.220 --> 00:20:05.400 Now, this Dropbox engineer has stated on the record that yes, in fact, he was reusing passwords 00:20:05.400 --> 00:20:06.400 at the time. 00:20:06.400 --> 00:20:10.720 His Twitter, Facebook, LinkedIn, and Google accounts all had the same password, so this 00:20:10.720 --> 00:20:15.200 hacker actually gained access to a ton of this engineer’s accounts. 00:20:15.200 --> 00:20:21.030 [MUSIC] But did this engineer use the same password where he worked too, at Dropbox? 00:20:21.030 --> 00:20:27.909 I don’t know for sure but the hacker was able to login as the engineer at Dropbox. 00:20:27.909 --> 00:20:32.710 I mean, he was able to get into the corporate network with this login either through a VPN 00:20:32.710 --> 00:20:35.750 or an admin web portal; I’m not sure. 00:20:35.750 --> 00:20:41.070 Obviously I shouldn’t need to tell you this, but it’s not a good idea to reuse passwords 00:20:41.070 --> 00:20:43.080 for this exact reason. 00:20:43.080 --> 00:20:48.740 Now, this quality assurance engineer didn’t have access to files that users stored on 00:20:48.740 --> 00:20:54.820 their Dropbox accounts but he did have access to users’ metadata, information about their 00:20:54.820 --> 00:20:59.960 accounts and stuff, because he would sometimes need to look into issues that users were facing. 00:20:59.960 --> 00:21:05.510 The thing is, if a hacker has this guy’s login information, then the hacker can access 00:21:05.510 --> 00:21:07.770 anything this engineer can. 00:21:07.770 --> 00:21:13.270 So, the hacker got in and grabbed all the user data he could that this engineer had 00:21:13.270 --> 00:21:20.480 access to which consisted of usernames, e-mail addresses, hashed and salted passwords. 00:21:20.480 --> 00:21:25.779 Then the hacker transferred this to himself and got out. 00:21:25.779 --> 00:21:30.340 A month later, the FBI was investigating this LinkedIn breach. 00:21:30.340 --> 00:21:35.370 One of the things they looked for was to see if that IP address or user agent was logging 00:21:35.370 --> 00:21:39.290 into any LinkedIn accounts as users of the site. 00:21:39.290 --> 00:21:44.340 Sure enough, there were logs indicating that the same person had logged into about thirty 00:21:44.340 --> 00:21:51.320 different LinkedIn user accounts, meaning the hacker had cracked the usernames and passwords 00:21:51.320 --> 00:21:55.679 for these LinkedIn users and was testing it to verify it worked. 00:21:55.679 --> 00:21:59.809 One of those accounts belonged to a Dropbox employee and I don’t know if it was the 00:21:59.809 --> 00:22:05.610 same quality assurance engineer but the FBI saw that connection and thought maybe Dropbox 00:22:05.610 --> 00:22:07.750 might be the next target. 00:22:07.750 --> 00:22:13.220 So, the FBI called Dropbox to tell them this information and even gave them IPs and user 00:22:13.220 --> 00:22:15.020 agents to look for. 00:22:15.020 --> 00:22:21.200 Dropbox looked through their logs and confirmed that yeah, those IPs did connect in as a quality 00:22:21.200 --> 00:22:24.440 assurance engineer and got into the corporate network. 00:22:24.440 --> 00:22:28.679 [MUSIC] Once Dropbox did confirm there was unauthorized access into the network, they 00:22:28.679 --> 00:22:30.990 immediately set up a War Room to handle the incident. 00:22:30.990 --> 00:22:34.950 This is basically like Command Central, a place where all data can be combined and up-to-date 00:22:34.950 --> 00:22:36.640 information is relayed to. 00:22:36.640 --> 00:22:41.770 Now, at the time in 2012, Dropbox had just under 150 employees working there and just 00:22:41.770 --> 00:22:46.640 like at LinkedIn, this was the biggest thing going on at Dropbox at the time, so it was 00:22:46.640 --> 00:22:50.130 practically an all-hands-on-deck response. 00:22:50.130 --> 00:22:53.960 Dropbox had over twenty people working on this incident but they knew they needed even 00:22:53.960 --> 00:22:58.789 more help, so they started hiring more security incident responders to just come on in and 00:22:58.789 --> 00:22:59.789 help. 00:22:59.789 --> 00:23:04.320 They first discovered that someone had unauthorized access into the corporate network of Dropbox. 00:23:04.320 --> 00:23:08.640 This seemed contained though, as the connections didn’t seem to make it into their production 00:23:08.640 --> 00:23:11.070 portion where dropbox.com was ran out of. 00:23:11.070 --> 00:23:12.960 This was in the corporate side. 00:23:12.960 --> 00:23:16.809 While this is still a big deal to have someone lurking around in your corporate network, 00:23:16.809 --> 00:23:21.860 they weren’t able to see the crown jewels of what data users were storing in their Dropbox 00:23:21.860 --> 00:23:22.860 accounts. 00:23:22.860 --> 00:23:27.280 Now, specifically they were seeing that a Dropbox engineer was connecting into the Dropbox 00:23:27.280 --> 00:23:33.140 network from Russia, then once they connected, they went to the internal Dropbox Wiki which 00:23:33.140 --> 00:23:39.070 has information on how to troubleshoot certain things and other technical details about Dropbox’s 00:23:39.070 --> 00:23:40.070 network. 00:23:40.070 --> 00:23:41.700 The Dropbox team kept examining the logs. 00:23:41.700 --> 00:23:46.460 They saw which Dropbox engineer had his username and password stolen and went through the logs 00:23:46.460 --> 00:23:49.799 to see if there was any other suspicious activity around that. 00:23:49.799 --> 00:23:54.450 This engineer had an account at dropbox.com, so they looked at his recent activity and 00:23:54.450 --> 00:23:59.760 it shows that he invited another Dropbox user to join his Dropbox team. 00:23:59.760 --> 00:24:04.059 The thing is, the Dropbox engineer did not invite [00:25:00] that user, so this means 00:24:04.059 --> 00:24:09.360 the hacker got into the engineer’s Dropbox account and then invited himself to see that 00:24:09.360 --> 00:24:10.890 engineer’s files. 00:24:10.890 --> 00:24:14.809 After they had their accounts linked up, the Dropbox engineer’s account transferred some 00:24:14.809 --> 00:24:18.370 large files to the hacker’s Dropbox. 00:24:18.370 --> 00:24:23.710 When Dropbox looked into what these files were, it was a list of twenty million Dropbox 00:24:23.710 --> 00:24:29.250 user details; e-mail, username, and salted password hashes. 00:24:29.250 --> 00:24:33.610 This made Dropbox aware that not only were they breached but the hacker stole at least 00:24:33.610 --> 00:24:36.440 twenty million user details from their customers. 00:24:36.440 --> 00:24:43.820 But they still weren’t sure how the hacker got these or even if it was from Dropbox at 00:24:43.820 --> 00:24:46.549 all. 00:24:46.549 --> 00:24:48.700 The next victim here is a company called Formspring. 00:24:48.700 --> 00:24:52.370 This is a social networking site which is focused on asking questions. 00:24:52.370 --> 00:24:55.820 Think of it like a place that’s dedicated to ask-me-anything-type interviews. 00:24:55.820 --> 00:25:02.010 In 2012 they had 30 million registered users and in June of 2012, the hacker got one of 00:25:02.010 --> 00:25:07.100 the admin usernames and passwords from Formspring’s server and logged in using SSH. 00:25:07.100 --> 00:25:11.480 My guess is that he got this login from the LinkedIn data too, but I’m not sure on that. 00:25:11.480 --> 00:25:16.080 He also logged into one of the web admin panels using the same username. 00:25:16.080 --> 00:25:21.040 He was able to install a malicious program called madnez.php on the server so that he 00:25:21.040 --> 00:25:22.770 could get back in anytime he wanted. 00:25:22.770 --> 00:25:26.370 It’s the same madnez.php that was found on that iMac. 00:25:26.370 --> 00:25:30.000 He found their internal Wiki and did a search there for hashed passwords. 00:25:30.000 --> 00:25:34.980 I guess what he was looking for was information about them or where they’re stored or something. 00:25:34.980 --> 00:25:39.700 Using the web admin panel, he was able to run SQL commands on the database and grabbed 00:25:39.700 --> 00:25:46.480 a large amount of user info, specifically e-mails, usernames, and salted password hashes, 00:25:46.480 --> 00:25:47.539 then he logged out. 00:25:47.539 --> 00:25:49.149 That was in June. 00:25:49.149 --> 00:25:56.100 [MUSIC] On July 9th, someone posted a database dump of Formspring users on some underground 00:25:56.100 --> 00:25:57.100 forum. 00:25:57.100 --> 00:26:00.419 It contained 420,000 accounts. 00:26:00.419 --> 00:26:03.230 Someone saw this and contacted a journalist. 00:26:03.230 --> 00:26:10.290 The e-mail addresses in the dump contained the word Formspring in them a lot, like user+formspring@gmail.com, 00:26:10.290 --> 00:26:11.290 that kind of stuff. 00:26:11.290 --> 00:26:14.500 So, the journalist called up Formspring to get some answers. 00:26:14.500 --> 00:26:19.180 Formspring had no idea they were breached and had no idea how this database got on the 00:26:19.180 --> 00:26:24.270 forum, but this turned into an all-hands-on-deck situation for them, too. 00:26:24.270 --> 00:26:28.409 They only had a few dozen people working there at the time but everyone who was technical 00:26:28.409 --> 00:26:30.990 got involved with this investigation. 00:26:30.990 --> 00:26:34.440 When one journalist posted about it, soon many more journalists were calling, so the 00:26:34.440 --> 00:26:37.630 marketing team had to get involved too, trying to handle PR. 00:26:37.630 --> 00:26:41.049 First, the Formspring security team needed to confirm the data. 00:26:41.049 --> 00:26:46.789 They took the 420,000 users and compared it to their database and it was a match. 00:26:46.789 --> 00:26:48.490 It certainly was their data. 00:26:48.490 --> 00:26:51.020 Next, they started looking for anomalous activity. 00:26:51.020 --> 00:26:56.760 That’s when they found someone had SSH’d into the server from a Russian IP. 00:26:56.760 --> 00:27:02.360 They took the IP and looked at more logs which indicated that this user logged into the web 00:27:02.360 --> 00:27:07.600 admin portal and from there, they were able to see what the user agent was for the person 00:27:07.600 --> 00:27:09.260 who accessed it. 00:27:09.260 --> 00:27:14.240 They also saw this hacker accessed the Wiki and placed madnez.php on the web server and 00:27:14.240 --> 00:27:17.470 ran some SQL queries from the admin control panel. 00:27:17.470 --> 00:27:20.159 They discovered all this in about one day. 00:27:20.159 --> 00:27:24.159 I guess their environment was just a lot smaller than LinkedIn to be able to get through it 00:27:24.159 --> 00:27:25.659 all quicker. 00:27:25.659 --> 00:27:29.410 Once Formspring confirmed that they had an intrusion, they needed to contain it. 00:27:29.410 --> 00:27:33.620 They changed the username that was used to login, deleted madnez.php, put more rules 00:27:33.620 --> 00:27:37.679 in place to change passwords more frequently, and set up monitoring rules to look for logins 00:27:37.679 --> 00:27:42.179 that weren’t from where the admin lives, and then totally destroyed and rebuilt certain 00:27:42.179 --> 00:27:44.171 servers that they knew the hacker had been on. 00:27:44.171 --> 00:27:48.730 On top of that, they notified all their users that a breach had occurred. 00:27:48.730 --> 00:27:54.190 They told users what data had been stolen and had them change their passwords immediately. 00:27:54.190 --> 00:27:59.399 The day after they discovered this breach, the FBI called them and said hey, heard you 00:27:59.399 --> 00:28:00.470 had a break-in. 00:28:00.470 --> 00:28:02.159 Can we see what happened? 00:28:02.159 --> 00:28:06.510 Formspring sent the FBI all the logs they could to assist in the investigation. 00:28:06.510 --> 00:28:10.600 A few weeks later, Formspring had everything back to normal and things were working just 00:28:10.600 --> 00:28:11.919 fine again. 00:28:11.919 --> 00:28:18.299 But this story isn’t over; one guy hacked into three major websites and the FBI is now 00:28:18.299 --> 00:28:19.299 on the trail. 00:28:19.299 --> 00:28:21.350 You’ve got to hear what happens next. 00:28:21.350 --> 00:28:22.840 Stay with us. 00:28:22.840 --> 00:28:27.409 [00:30:00] At this point, the FBI was aware of all three of these cases. 00:28:27.409 --> 00:28:33.000 Someone had breached LinkedIn, Dropbox, and Formspring all from the same IPs and same 00:28:33.000 --> 00:28:36.220 user agents with a trail connecting it all. 00:28:36.220 --> 00:28:39.519 Pretty much the day LinkedIn found out that they’d been breached, they called the FBI 00:28:39.519 --> 00:28:43.320 and the FBI began interviewing people at LinkedIn and collecting logs from them. 00:28:43.320 --> 00:28:46.399 They saw that the hacker had connected from multiple IPs in Russia. 00:28:46.399 --> 00:28:49.310 They also saw the user agent with the word Sputnik in it. 00:28:49.310 --> 00:28:52.720 LinkedIn was sending them hard drives full of logs to examine and feeding them all the 00:28:52.720 --> 00:28:53.910 information they were finding. 00:28:53.910 --> 00:28:59.130 They even supplied an image of the engineer’s iMac that got hacked to the FBI. 00:28:59.130 --> 00:29:02.429 While reviewing all this data, the FBI found something crucial in the logs. 00:29:02.429 --> 00:29:07.350 [MUSIC] They knew what IP and user agent the hacker had, so they looked at all the people 00:29:07.350 --> 00:29:12.039 who logged into linkedin.com, the public website, in the last few years. 00:29:12.039 --> 00:29:16.289 They found a person named Jammiro Quatro. 00:29:16.289 --> 00:29:20.679 This person had registered for a LinkedIn account way before this hack and had the same 00:29:20.679 --> 00:29:23.289 IP and user agent as the hacker. 00:29:23.289 --> 00:29:25.320 This could be gold. 00:29:25.320 --> 00:29:30.529 Like I said, users of LinkedIn often post their full resume there, so if this user had 00:29:30.529 --> 00:29:37.000 information about himself posted on his account, it could wrap up this whole story really quick. 00:29:37.000 --> 00:29:40.470 But Jammiro had a blank LinkedIn account. 00:29:40.470 --> 00:29:45.019 He wasn’t associated to any company and he didn’t have a single connection or friend 00:29:45.019 --> 00:29:46.039 on LinkedIn. 00:29:46.039 --> 00:29:50.809 But to create a LinkedIn account you need an e-mail address, so the FBI looked to see 00:29:50.809 --> 00:29:58.169 what e-mail address registered this account and it was chinabig01@gmail.com. 00:29:58.169 --> 00:30:02.120 The FBI thought this might be the e-mail address of the hacker. 00:30:02.120 --> 00:30:06.539 Now, the FBI had quite a few IP addresses that they were considering suspicious with 00:30:06.539 --> 00:30:11.340 this, but they narrowed down their interest to five that may be owned by the hacker, and 00:30:11.340 --> 00:30:13.260 all of them were in Russia. 00:30:13.260 --> 00:30:17.610 If this had been in the US, the FBI could issue a subpoena to an ISP and get information 00:30:17.610 --> 00:30:21.480 on who pays the bill for that connection and get answers almost immediately. 00:30:21.480 --> 00:30:26.529 But things work differently when the FBI wants information from an ISP in Russia. 00:30:26.529 --> 00:30:31.570 There is a thing called the Mutual Legal Assistance Treaty, or MLAT. 00:30:31.570 --> 00:30:36.799 MLAT was set up to allow foreign nations to cooperate in helping criminal investigations 00:30:36.799 --> 00:30:41.200 by supplying law enforcement with internet service subscriber info. 00:30:41.200 --> 00:30:47.730 So, the FBI requested from Russia subscriber records through MLAT to see whose IPs those 00:30:47.730 --> 00:30:48.730 were. 00:30:48.730 --> 00:30:54.250 But this is not a fast process; it takes eight months to five years to get subscriber info 00:30:54.250 --> 00:30:59.279 through MLAT, so the FBI had to wait for a while on this. 00:30:59.279 --> 00:31:04.870 [MUSIC] In the meantime, they started cross-referencing the LinkedIn data with Dropbox and Formspring 00:31:04.870 --> 00:31:05.870 data. 00:31:05.870 --> 00:31:09.669 In all three attacks they found similar IOCs, or indicators of compromise; the same IPs, 00:31:09.669 --> 00:31:12.899 the same user agents, the same browser and OS. 00:31:12.899 --> 00:31:16.720 Once again, they looked for users on those sites from those IPs who registered for an 00:31:16.720 --> 00:31:19.279 account before this hack took place. 00:31:19.279 --> 00:31:24.480 Dropbox also had a user registered with chinabig01@gmail.com. 00:31:24.480 --> 00:31:31.179 That person was named Jammis Gurus, a bit different from the Jammiro Quatro from LinkedIn. 00:31:31.179 --> 00:31:36.570 Formspring also had a user registered as chinabig01@gmail.com, too. 00:31:36.570 --> 00:31:40.669 Because there were so many similar indicators on all three breaches, the FBI was starting 00:31:40.669 --> 00:31:45.390 to believe that this chinabig01 e-mail address might have been owned by the hacker. 00:31:45.390 --> 00:31:50.500 So, the next step is the FBI contacted Google, the owners of Gmail, and issued a search warrant 00:31:50.500 --> 00:31:52.769 to get any information on that user. 00:31:52.769 --> 00:31:57.260 See, Google is a US company, so it’s fairly easy for the FBI to get information from a 00:31:57.260 --> 00:31:58.710 US-based company. 00:31:58.710 --> 00:32:02.929 Actually, I think they have to comply with law enforcement in this kind of way, and Google 00:32:02.929 --> 00:32:06.620 loves collecting logs on its users, so they had plenty to share. 00:32:06.620 --> 00:32:11.010 [MUSIC] First, the FBI saw that whoever was connecting to the server had the same IPs 00:32:11.010 --> 00:32:13.920 and user agents as the intruder who got into the other companies. 00:32:13.920 --> 00:32:19.019 Next, the FBI agent was able to see what search terms this person Googled while logged into 00:32:19.019 --> 00:32:20.150 their account. 00:32:20.150 --> 00:32:25.850 Here are some of those search terms; WordPress vulnerabilities, TrueCrypt hack, Oracle export 00:32:25.850 --> 00:32:30.200 utility, EMS data export for Oracle. 00:32:30.200 --> 00:32:36.269 The user’s Google activity also showed them visiting a few sites like insiderpro.com which 00:32:36.269 --> 00:32:40.040 was the forum that these database dumps were getting posted to. 00:32:40.040 --> 00:32:44.309 The user also visited articles which talked about the LinkedIn hack. 00:32:44.309 --> 00:32:48.399 Then the FBI took a look in their inbox and looked at what e-mails they had and saw a 00:32:48.399 --> 00:32:51.640 welcome e-mail to Vimeo, a video file-sharing website. 00:32:51.640 --> 00:32:56.779 So, he requested information from Vimeo which also came back with matching user agents and 00:32:56.779 --> 00:32:58.370 IP addresses. 00:32:58.370 --> 00:33:01.860 The FBI also saw evidence that this person was logging into some LinkedIn accounts which 00:33:01.860 --> 00:33:04.519 were employees of automattic.com. 00:33:04.519 --> 00:33:10.639 Now, Automattic is the parent company to WordPress. [00:35:00] The FBI contacted Automattic and 00:33:10.639 --> 00:33:15.299 requested to see any login activity from these Russian IPs and sure enough, there were some 00:33:15.299 --> 00:33:16.820 login activities. 00:33:16.820 --> 00:33:21.000 Someone from Russia was logging in with different Automattic employee usernames and passwords. 00:33:21.000 --> 00:33:26.650 It’s unclear what exactly the hacker stole out of Automattic’s site, if anything, but 00:33:26.650 --> 00:33:32.250 it is clear he got in multiple times with different Automattic engineers’ usernames. 00:33:32.250 --> 00:33:36.299 The FBI agent then saw a welcome e-mail to afraid.org. 00:33:36.299 --> 00:33:39.340 This is a website which offers dynamic DNS services. 00:33:39.340 --> 00:33:44.250 It’s a US-based company, so the FBI agent issued a search warrant to get data on who 00:33:44.250 --> 00:33:47.440 owned the account related to chinabig01. 00:33:47.440 --> 00:33:54.610 The name on this account came back as “Zopaqwe1”, and afraid.org also showed that whoever was 00:33:54.610 --> 00:33:59.010 accessing the site had the user agent with Sputnik in it, too. 00:33:59.010 --> 00:34:05.519 The FBI did a Google search on this “Zopaqwe1” which is a strange and unique word, and found 00:34:05.519 --> 00:34:09.770 a user registered on an online gaming site called kongregate.com. 00:34:09.770 --> 00:34:15.750 The FBI requested user details here and confirmed the user agent and IPs matched, but also discovered 00:34:15.750 --> 00:34:21.560 the user had registered a credit card on that site and had purchased some game credits. 00:34:21.560 --> 00:34:26.639 The FBI tried to trace the bank details of that card but it led them to a bank in Russia 00:34:26.639 --> 00:34:29.409 which they could not get extra information on. 00:34:29.409 --> 00:34:33.560 However, they did look to see what e-mail address was registered with this “Zopaqwe1” 00:34:33.560 --> 00:34:40.540 Kongregate account, and the e-mail for this user was r00talka@mail.ru. 00:34:40.540 --> 00:34:48.869 Now, since mail.ru is hosted in Russia, the FBI couldn’t issue a subpoena for that, 00:34:48.869 --> 00:34:49.869 either. 00:34:49.869 --> 00:34:54.510 But the FBI Googled the beginning of that e-mail address, r00talka, and found a Gmail 00:34:54.510 --> 00:34:57.610 user with the same name, r00talka@gmail.com. 00:34:57.610 --> 00:35:03.690 [MUSIC] So, the FBI issued a search warrant with Google to get information on that Google 00:35:03.690 --> 00:35:07.010 user, and Google responded with more information. 00:35:07.010 --> 00:35:10.920 The first thing they saw was what Google searches that user had searched for, and they were 00:35:10.920 --> 00:35:18.230 searching for things like LinkedIn hack, MySQL count fields, change Mac address WiFi Windows 00:35:18.230 --> 00:35:19.230 7. 00:35:19.230 --> 00:35:22.080 There were also some Google Map searches that this user did. 00:35:22.080 --> 00:35:28.100 They saw the user searched for a dentist in Moscow and some other map searches in Russia. 00:35:28.100 --> 00:35:33.970 Next, the FBI agent was able to look at e-mails for this r00talka Gmail account. 00:35:33.970 --> 00:35:39.480 He saw this person had registered an account at VKontakte which is like the Russian version 00:35:39.480 --> 00:35:40.480 of Facebook. 00:35:40.480 --> 00:35:45.010 The site would e-mail you anytime someone messaged you there and there were people messaging 00:35:45.010 --> 00:35:49.990 him asking about hacking e-mail accounts and different relationship-type stuff that was 00:35:49.990 --> 00:35:50.990 going on. 00:35:50.990 --> 00:35:57.430 But here, everyone is referring to him as Zhenya and everyone only spoke Russian to 00:35:57.430 --> 00:35:58.700 him. 00:35:58.700 --> 00:36:02.831 By this point, the subscriber records for that IP address came back from the MLAT request 00:36:02.831 --> 00:36:08.599 to Russia and it showed IPs were owned by two people, and it gave their physical address. 00:36:08.599 --> 00:36:12.790 Yevgeniy Nikulin had one IP and someone else had the other. 00:36:12.790 --> 00:36:18.690 Yevgeniy lived on the same street that this person was doing Google Map searches on, so 00:36:18.690 --> 00:36:23.030 the FBI started looking up information about Yevgeniy and found photos of what he looks 00:36:23.030 --> 00:36:24.030 like. 00:36:24.030 --> 00:36:28.050 They compared those photos with the person on VKontakte’s account and they looked like 00:36:28.050 --> 00:36:29.710 the same person. 00:36:29.710 --> 00:36:34.569 The VK account was for a person who went by the name Zhenya which is actually a common 00:36:34.569 --> 00:36:37.280 nickname for people named Yevgeniy. 00:36:37.280 --> 00:36:43.720 I’m not sure how but the FBI investigation led them to a Russian guy named Kislitsin. 00:36:43.720 --> 00:36:49.500 [MUSIC] Kislitsin has been known in the past to broker deals between hackers and people 00:36:49.500 --> 00:36:51.369 buying database dumps. 00:36:51.369 --> 00:36:56.670 The FBI found Kislitsin’s e-mail address which was a Hotmail address owned by Microsoft, 00:36:56.670 --> 00:37:00.230 so they issued a search warrant with Microsoft to see what was in his inbox. 00:37:00.230 --> 00:37:05.730 There, the FBI saw e-mails going back and forth with the buyer of the Formspring data. 00:37:05.730 --> 00:37:11.190 The buyer ultimately decided to buy the dump for an equivalent of 7,100 US dollars. 00:37:11.190 --> 00:37:16.960 I’m not sure how much data was in there though; somewhere between 400,000 and 30 million 00:37:16.960 --> 00:37:17.960 user records. 00:37:17.960 --> 00:37:23.250 Supposedly, the person who bought this was half-Belgian and half-Turkish, and what’s 00:37:23.250 --> 00:37:28.030 really strange is they used a middle man for this cash deal and he was also involved with 00:37:28.030 --> 00:37:33.190 the E-Trade and Scottrade hacks which I talked about in Episode 76, Knaves Out. 00:37:33.190 --> 00:37:38.650 The FBI indicted Kislitsin as a co-conspirator to this but ultimately was unable to capture 00:37:38.650 --> 00:37:39.650 him. 00:37:39.650 --> 00:37:45.600 However, the FBI was able to arrange a meeting with him in the Russian embassy in Moscow. 00:37:45.600 --> 00:37:51.750 So, they visited with this Kislitsin guy and he gave them a lot of information, not only 00:37:51.750 --> 00:37:57.150 information about this case but information on a few other cases the FBI was investigating, 00:37:57.150 --> 00:37:58.150 too. 00:37:58.150 --> 00:38:03.970 While meeting with Kislitsin, he told them that Yevgeniy Nikulin was the person who broke 00:38:03.970 --> 00:38:09.100 into Dropbox and still had access to it and had the Formspring [00:40:00] data, all with 00:38:09.100 --> 00:38:12.870 the goal to sell the database dumps on the black market for money. 00:38:12.870 --> 00:38:17.560 This was enough information for the FBI to issue an indictment for Yevgeniy. 00:38:17.560 --> 00:38:21.650 Multiple trails led right to him, but would they be able to catch him? 00:38:21.650 --> 00:38:25.550 Stay with us through the break to find out. 00:38:25.550 --> 00:38:29.849 So, who is Yevgeniy Nikulin? 00:38:29.849 --> 00:38:35.859 Well, he’s Russian, from Moscow, born in 1987, so that made him twenty-five years old 00:38:35.859 --> 00:38:37.290 in 2012. 00:38:37.290 --> 00:38:42.500 Yevgeniy loves cars so much that he started a business in Moscow buying luxury cars and 00:38:42.500 --> 00:38:46.790 renting them out to people, and it was from that where he was often seen driving Maseratis, 00:38:46.790 --> 00:38:49.589 Lamborghinis, and Bentleys around town in Russia. 00:38:49.589 --> 00:38:52.640 I don’t know where all this hacking started for him. 00:38:52.640 --> 00:38:53.970 Details of his past are foggy. 00:38:53.970 --> 00:38:57.720 I imagine he got into IT and computers like anyone else; probably started with playing 00:38:57.720 --> 00:39:01.940 video games and then wanting to hack the video games or cheat, or maybe wanting to change 00:39:01.940 --> 00:39:05.630 his grades in school or wanting to just mess around with his friends by hacking into them 00:39:05.630 --> 00:39:06.819 like it was a game. 00:39:06.819 --> 00:39:08.619 Who knows why he got started in hacking? 00:39:08.619 --> 00:39:14.290 But by 2012 he was pretty familiar with how computers worked and how to exploit them. 00:39:14.290 --> 00:39:18.720 From reading about him, I also feel like his online life overlapped with some of these 00:39:18.720 --> 00:39:22.220 pretty notorious Russian cyber-criminals. 00:39:22.220 --> 00:39:24.640 He knew some of the other big hackers. 00:39:24.640 --> 00:39:26.170 Maybe they taught him. 00:39:26.170 --> 00:39:30.630 Maybe they were hanging out in the same forums or something and maybe Yevgeniy wanted to 00:39:30.630 --> 00:39:36.220 be part of that hacking world that they were part of, because after all, he liked expensive 00:39:36.220 --> 00:39:42.970 things and was seeing some of the Russian hackers making gravy from their digital exploits. 00:39:42.970 --> 00:39:47.960 The FBI issued an indictment for Yevgeniy Nikulin but the problem was, he was in Russia 00:39:47.960 --> 00:39:51.380 and Russia was not going to arrest Yevgeniy for the FBI. 00:39:51.380 --> 00:39:55.390 Even if Russia did arrest him, he’s not gonna get extradited to the US for trial. 00:39:55.390 --> 00:39:57.740 So, the FBI had to wait. 00:39:57.740 --> 00:40:02.570 They knew the exact address of where Yevgeniy lived but had no way to go into Russia to 00:40:02.570 --> 00:40:03.570 get him. 00:40:03.570 --> 00:40:10.050 Now, up until this point, the world had thought the LinkedIn data breach was for 6.5 million 00:40:10.050 --> 00:40:14.099 users because after all, that’s what was posted on insiderpro.com and what’s more 00:40:14.099 --> 00:40:17.890 is that LinkedIn never clarified how many accounts got stolen. 00:40:17.890 --> 00:40:24.750 But in May 2016, someone posted that they had even more LinkedIn credentials for sale. 00:40:24.750 --> 00:40:32.760 They claimed to have 117 million user details from LinkedIn and was selling it for just 00:40:32.760 --> 00:40:35.960 over $2,000 in Bitcoin. 00:40:35.960 --> 00:40:38.280 This triggered a whole new news cycle. 00:40:38.280 --> 00:40:39.810 HOST3: Morning topic; America’s money. 00:40:39.810 --> 00:40:43.690 A security breach at LinkedIn turns out to be much bigger than first thought. 00:40:43.690 --> 00:40:44.690 HOST4: That’s right. 00:40:44.690 --> 00:40:49.370 The social network for business now says a hacker stole 117 million user passwords in 00:40:49.370 --> 00:40:53.840 the 2012 breach, far more than the original estimate of about 6.5 million. 00:40:53.840 --> 00:40:56.599 JACK: I think about all the users of LinkedIn. 00:40:56.599 --> 00:41:01.680 Yes, of course; professionals looking to network, but also many top executives have accounts 00:41:01.680 --> 00:41:02.680 there. 00:41:02.680 --> 00:41:05.680 I mean, after all, if your business is listed there, shouldn’t the leader of that business 00:41:05.680 --> 00:41:07.200 be on there too? 00:41:07.200 --> 00:41:09.440 But on top of that, you have government officials on there. 00:41:09.440 --> 00:41:14.860 Lawmakers are there, members of congress, FBI agents, NSA agents, senators, and yes, 00:41:14.860 --> 00:41:16.600 even the president of the United States. 00:41:16.600 --> 00:41:22.090 Barack Obama made his account in 2007 when he was running for president and was president 00:41:22.090 --> 00:41:24.750 in 2012 when this happened. 00:41:24.750 --> 00:41:31.119 [MUSIC] This news swept through lots of circles and impacted a lot of people. 00:41:31.119 --> 00:41:36.160 What’s more is this new dump contained a lot of cracked passwords that anyone can see 00:41:36.160 --> 00:41:37.810 in plain text. 00:41:37.810 --> 00:41:41.110 It wasn’t that LinkedIn stored passwords in plain text but the hackers were able to 00:41:41.110 --> 00:41:43.940 find ways to crack a lot of the passwords that were in there. 00:41:43.940 --> 00:41:48.450 Oh, and in fact, we got to see what the most common passwords that got cracked were. 00:41:48.450 --> 00:41:52.829 I’ll read you the top six [00:45:00] most common passwords that LinkedIn users were 00:41:52.829 --> 00:41:54.150 using in 2012. 00:41:54.150 --> 00:41:58.940 The most common was simply ‘123456’. 00:41:58.940 --> 00:42:05.750 Over 700,000 users had used this password because yes, LinkedIn’s minimum password 00:42:05.750 --> 00:42:09.050 length was six characters at the time. 00:42:09.050 --> 00:42:17.320 The next most popular password was ‘LinkedIn’, then the password ‘password’, then ‘123456789’, 00:42:17.320 --> 00:42:22.930 then ‘12345678’, then ‘111111’. 00:42:22.930 --> 00:42:27.030 People use bad passwords and you’re telling me some of those users are using the same 00:42:27.030 --> 00:42:28.590 passwords on multiple sites? 00:42:28.590 --> 00:42:31.510 On top of that, they’re using the same password at work? 00:42:31.510 --> 00:42:33.750 Ugh, it’s outrageous. 00:42:33.750 --> 00:42:39.520 A few months after that, in October 2016, the FBI got the break they were waiting for. 00:42:39.520 --> 00:42:44.310 Yevgeniy Nikulin was spotted in Prague, in the Czech Republic. 00:42:44.310 --> 00:42:48.160 With the indictment all processed and things ready to go, the Czech police tracked him 00:42:48.160 --> 00:42:51.270 to a restaurant where he was eating with his girlfriend. 00:42:51.270 --> 00:42:55.000 There’s bodycam footage of the police arresting him. 00:42:55.000 --> 00:42:59.880 Here, have a listen. 00:42:59.880 --> 00:43:02.319 POLICE: [CZECH] 00:43:02.319 --> 00:43:07.300 JACK: There’s actually not much to listen to, so I’ll describe what’s going on. 00:43:07.300 --> 00:43:09.570 Yevgeniy and his girlfriend are sitting at a restaurant. 00:43:09.570 --> 00:43:13.750 From the video, I see about three police officers coming in and they tell him to stay calm and 00:43:13.750 --> 00:43:14.930 put his hands where they can see them. 00:43:14.930 --> 00:43:19.030 Yevgeniy puts his hands on the table and they ask him to stand up and walk backwards towards 00:43:19.030 --> 00:43:20.040 the officer. 00:43:20.040 --> 00:43:22.010 Yevgeniy does exactly that. 00:43:22.010 --> 00:43:26.010 Then they pat him down, take some things out of his pockets and handcuff him, all while 00:43:26.010 --> 00:43:28.740 the other officer is making sure the girlfriend isn’t getting up. 00:43:28.740 --> 00:43:36.369 It’s all done very quietly and without any fuss, and Yevgeniy was taken to a Prague jail. 00:43:36.369 --> 00:43:41.200 For the next two years, Yevgeniy’s lawyers fought to keep him from getting extradited 00:43:41.200 --> 00:43:42.200 to the US. 00:43:42.200 --> 00:43:47.400 I wasn’t able to get a second confirmation on this but his lawyer said the FBI was trying 00:43:47.400 --> 00:43:51.921 to pin Yevgeniy for hacking Hillary Clinton’s e-mails at the time and was trying to get 00:43:51.921 --> 00:43:53.650 him to confess to that. 00:43:53.650 --> 00:43:59.860 Eventually, two years after his arrest, in 2018 the Czech Republic did extradite him 00:43:59.860 --> 00:44:01.559 to the US for a trial. 00:44:01.559 --> 00:44:05.500 Yeah, I went through the court records and I never saw one reference to Hillary Clinton 00:44:05.500 --> 00:44:06.500 in there. 00:44:06.500 --> 00:44:11.499 The US had nine charges on him; computer intrusion, aggravated identity theft, conspiracy, and 00:44:11.499 --> 00:44:15.920 an international transmission of information causing damage to a protected computer. 00:44:15.920 --> 00:44:20.400 The victims of this case were listed as LinkedIn, Dropbox, and Formspring. 00:44:20.400 --> 00:44:28.440 But here’s why I love this story so much; Yevgeniy pleaded innocent on all these charges. 00:44:28.440 --> 00:44:32.620 [MUSIC] He claimed he didn’t do any of this and why is that my favorite part? 00:44:32.620 --> 00:44:39.660 Because it means this case had to go to trial which means witnesses, evidence, FBI testimony, 00:44:39.660 --> 00:44:42.750 and so much more becomes public record. 00:44:42.750 --> 00:44:49.059 To research this story, I got the pleasure of reading hundreds of pages of court transcripts. 00:44:49.059 --> 00:44:53.790 It was glorious to hear all the details from victims and law enforcement. 00:44:53.790 --> 00:44:55.210 We rarely hear these things. 00:44:55.210 --> 00:44:59.650 Like, there were three people from LinkedIn who all testified, explaining how the hacker 00:44:59.650 --> 00:45:02.109 got in and what their incident response plan was. 00:45:02.109 --> 00:45:06.670 There were three people from Dropbox giving testimony, and the CEO from Formspring explained 00:45:06.670 --> 00:45:08.250 everything he saw. 00:45:08.250 --> 00:45:12.970 On top of that, there were three FBI agents and a Secret Service agent who all gave testimony 00:45:12.970 --> 00:45:16.840 on how they were able to link all these pieces together and track him down. 00:45:16.840 --> 00:45:22.010 It’s only from all this that we know anything about this story other than what you’ve 00:45:22.010 --> 00:45:23.010 seen in the headlines. 00:45:23.010 --> 00:45:28.109 I mean, I reached out to LinkedIn multiple times and the FBI multiple times to get someone 00:45:28.109 --> 00:45:32.740 to tell me about this story but nobody wanted to talk because I get it; what company wants 00:45:32.740 --> 00:45:36.600 to come on this show and tell me about the worst thing that’s ever happened to their 00:45:36.600 --> 00:45:38.600 company? No one. 00:45:38.600 --> 00:45:42.540 So, it’s just really rare for us to see all the details of what happened written out 00:45:42.540 --> 00:45:44.400 so wonderfully. 00:45:44.400 --> 00:45:49.070 This trial started in early 2020 but then the pandemic hit and the trial was delayed 00:45:49.070 --> 00:45:50.240 like, three months. 00:45:50.240 --> 00:45:55.369 During that time, the Secret Service arrested a hacker suspected for breaking into the SEC, 00:45:55.369 --> 00:45:57.329 Oleksandr Yaremenko. 00:45:57.329 --> 00:46:02.190 When they arrested him, they got access to his laptop and on it was all kinds of evidence 00:46:02.190 --> 00:46:08.660 on Yevgeniy; pictures of him, videos of him, chat messages with him, e-mails to him, tons 00:46:08.660 --> 00:46:09.660 more evidence. 00:46:09.660 --> 00:46:15.450 But it’s weird though because by 2020, Yevgeniy had been in jail for four years which if you 00:46:15.450 --> 00:46:21.420 think about it, that’s 13% of his life that he’s been in prison without anyone deciding 00:46:21.420 --> 00:46:23.960 on whether he’s guilty or not. 00:46:23.960 --> 00:46:27.040 This took a mental toll on him for sure. 00:46:27.040 --> 00:46:29.150 He barely spoke any English. 00:46:29.150 --> 00:46:33.359 He would sometimes shove guards or medical examiners or just try to walk out of the place 00:46:33.359 --> 00:46:34.359 sometimes. 00:46:34.359 --> 00:46:37.500 He made a mess in his cell by getting toilet paper wet and throwing it up on the ceiling. 00:46:37.500 --> 00:46:43.170 He kept asking the judge for permission to have a Game Boy or a PSP to play. 00:46:43.170 --> 00:46:45.510 Yevgeniy didn’t testify himself. 00:46:45.510 --> 00:46:48.640 He had an interpreter in the court room saying everything to him. 00:46:48.640 --> 00:46:52.579 The whole time, he kept [00:50:00] saying he had nothing to do with this but the trial 00:46:52.579 --> 00:46:56.830 started up and there was quite a lot of evidence connecting him to the incidents. 00:46:56.830 --> 00:47:01.350 Just to recap the trail here, IPs that accessed the victims’ networks were registered to 00:47:01.350 --> 00:47:03.040 his name specifically. 00:47:03.040 --> 00:47:07.280 The IP used to steal data from LinkedIn led to a certain browser user agent, and that 00:47:07.280 --> 00:47:11.309 was associated to a LinkedIn account with a Gmail address, and that e-mail was registered 00:47:11.309 --> 00:47:15.660 at afraid.org which had a username that was on kongregate.com, and that person bought 00:47:15.660 --> 00:47:19.900 things with a bank card, and that bank card matched to other things that Yevgeniy bought. 00:47:19.900 --> 00:47:24.579 On top of that, there was Kislitsin who said that Yevgeniy did this, and Yaremenko’s 00:47:24.579 --> 00:47:26.520 computer which had more evidence. 00:47:26.520 --> 00:47:29.130 On July 10th, 2020, the trial concluded. 00:47:29.130 --> 00:47:33.090 The jury found him guilty on all nine counts. 00:47:33.090 --> 00:47:38.359 The judge then sentenced him to 88 months in prison which is just over seven years, 00:47:38.359 --> 00:47:44.140 and they also ordered him to pay 1.7 million dollars in restitution for the damage he caused 00:47:44.140 --> 00:47:45.579 to the companies he hacked. 00:47:45.579 --> 00:47:50.520 Oh, and after that, he has to do three years of supervised release which I’m not quite 00:47:50.520 --> 00:47:54.089 sure how that works if you’re not a citizen of the US. 00:47:54.089 --> 00:47:59.060 [MUSIC] So, what do we learn from this story? 00:47:59.060 --> 00:48:04.300 Well, it sounds like in 2012, these victim companies weren’t doing user behavior anomaly 00:48:04.300 --> 00:48:05.300 detection. 00:48:05.300 --> 00:48:09.800 Like, if a user VPNs in from California and then an hour later that same user VPNs in 00:48:09.800 --> 00:48:12.760 from Russia, that should trigger an alert, right? 00:48:12.760 --> 00:48:14.390 Yeah, well, it didn’t. 00:48:14.390 --> 00:48:16.950 The technology at the time didn’t really do that kind of correlation. 00:48:16.950 --> 00:48:21.230 Now there’s better tools for monitoring user behavior analytics and I think tools 00:48:21.230 --> 00:48:22.650 like that have a lot of potential. 00:48:22.650 --> 00:48:28.690 Next, it’s crazy to me that some people use the same password for their LinkedIn account 00:48:28.690 --> 00:48:30.640 as their work accounts. 00:48:30.640 --> 00:48:32.970 Don’t reuse passwords like that. 00:48:32.970 --> 00:48:36.010 Use a complex, unique password for every account you have. 00:48:36.010 --> 00:48:38.119 The best way to do that is to use a password manager. 00:48:38.119 --> 00:48:40.220 They aren’t hard to use, so go get one. 00:48:40.220 --> 00:48:44.350 I have a affiliate link to one in the show notes if you just want a good recommendation. 00:48:44.350 --> 00:48:48.300 It’s also worth noting that these companies seemed to have exceptional logging turned 00:48:48.300 --> 00:48:51.640 on and when they learned about this breach, they were able to archive those logs and do 00:48:51.640 --> 00:48:55.550 system snapshots right away to preserve any data that can be used forensically. 00:48:55.550 --> 00:49:00.460 I’ve seen a lot of companies just not log properly and it just always really bothers 00:49:00.460 --> 00:49:01.460 me. 00:49:01.460 --> 00:49:05.619 Oh, and that LinkedIn engineer who was hosting those two websites on his home computer, he’s 00:49:05.619 --> 00:49:10.589 moved those websites to host them on Linode now which is one of our sponsors. 00:49:10.589 --> 00:49:14.930 I think one of the lessons he learned from this was that opening ports from the internet 00:49:14.930 --> 00:49:18.190 into your home network can be dangerous. 00:49:18.190 --> 00:49:24.370 It exposes your computer to a world full of chaos which can ultimately result in someone 00:49:24.370 --> 00:49:26.609 getting access to your home network. 00:49:26.609 --> 00:49:30.650 I do think about that a lot in this story; if he wasn’t hosting those little websites 00:49:30.650 --> 00:49:34.850 at home, he probably wouldn’t have been the way in for this hacker. 00:49:34.850 --> 00:49:42.079 It’s also interesting to see that bad guys target employees at their house, because that 00:49:42.079 --> 00:49:44.710 network is often not as strong as the corporate network. 00:49:44.710 --> 00:49:51.339 But here’s the crazy part of all this; remember that LinkedIn dump of 117 million user details 00:49:51.339 --> 00:49:53.240 that showed up in 2016? 00:49:53.240 --> 00:49:59.420 Later on that year, it just hit the public for anyone to see, so anyone can go look in 00:49:59.420 --> 00:50:05.640 the LinkedIn database to see what is in there, and there are still many people who did not 00:50:05.640 --> 00:50:09.780 change their passwords or changed it to something and then just changed it right back to what 00:50:09.780 --> 00:50:10.829 it was before that. 00:50:10.829 --> 00:50:14.390 What about all those people who reused passwords on all the other sites? 00:50:14.390 --> 00:50:17.860 Like, yeah, I changed my LinkedIn password ‘cause I was told to, but I didn’t change 00:50:17.860 --> 00:50:21.190 all the other six things that use that same password. 00:50:21.190 --> 00:50:24.690 That’s where we pick up in the next episode. 00:50:24.690 --> 00:50:31.700 Someone finds a password in the LinkedIn database and has quite a story to tell about that. 00:50:31.700 --> 00:50:41.170 (OUTRO): [OUTRO MUSIC] Hey, do you know about the Darknet Diaries shop? 00:50:41.170 --> 00:50:43.799 Listen, I love coming up with new shirt designs. 00:50:43.799 --> 00:50:46.099 Every month I throw a few more up in the shop. 00:50:46.099 --> 00:50:49.839 These shirts look great; one is of Medusa but she’s got Ethernet cables coming out 00:50:49.839 --> 00:50:53.680 of her head instead of snakes, and there’s one that looks like a bouquet of flowers but 00:50:53.680 --> 00:50:56.140 the flowers are actually made of computer cables. 00:50:56.140 --> 00:51:00.069 Another one is of an archer who’s shooting an arrow but the arrow looks like a USB symbol. 00:51:00.069 --> 00:51:04.210 You’ve got to see these shirts for yourself to understand what I’m saying, so visit 00:51:04.210 --> 00:51:06.330 shop.darknetdiaries.com and find some shirts. 00:51:06.330 --> 00:51:10.799 I’m an independent creator who loves bringing this show to you free of charge every two 00:51:10.799 --> 00:51:15.850 weeks but what really helps me keep on that schedule are my Patreon supporters. 00:51:15.850 --> 00:51:20.119 These are people who donate money to the show every month to help keep it going. 00:51:20.119 --> 00:51:25.109 If you want to show your support for this show, please visit patreon.com/darknetdiaries 00:51:25.109 --> 00:51:26.250 and consider donating. 00:51:26.250 --> 00:51:27.400 Thank you. 00:51:27.400 --> 00:51:30.670 This show is made by me, the chief biscuit-dunker, Jack Rhysider. 00:51:30.670 --> 00:51:33.320 Sound design by the dream alchemist, Andrew Meriwether. 00:51:33.320 --> 00:51:37.480 Editing help this episode by the wizard of light bulb moments, Damienne, and our theme 00:51:37.480 --> 00:51:41.010 music is by the phonic magician, Breakmaster Cylinder. 00:51:41.010 --> 00:51:47.000 Even though when you ASCII stupid question, you get a stupid ANSI. 00:51:47.000 --> 00:51:48.390 This is Darknet Diaries.