WEBVTT - What was Stuxnet? Part Two 0:00:04.160 --> 0:00:07.160 Get in tech with technology with tech Stuff from how 0:00:07.240 --> 0:00:13.760 stuff works dot com. Hey there, and welcome to tech Stuff. 0:00:13.800 --> 0:00:17.000 I am your host, Jonathan Strickland. I'm an executive producer 0:00:17.040 --> 0:00:19.319 here at how Stuff Works and I love all things tech. 0:00:19.360 --> 0:00:22.439 And if you listen to the previous episode, you heard 0:00:22.520 --> 0:00:26.079 part one of what was Up with stocks Net, the 0:00:26.680 --> 0:00:31.920 infamous computer virus that made headlines in ten and opened 0:00:32.000 --> 0:00:35.320 up a new era of cyber warfare. If you have 0:00:35.520 --> 0:00:38.400 not already listened to that episode, I recommend you go 0:00:38.440 --> 0:00:40.720 do it, because we're gonna pick up right where we 0:00:40.840 --> 0:00:43.559 left off now. In the previous episode, I set the 0:00:43.560 --> 0:00:47.199 ground by talking about how Iran had been pursuing a 0:00:47.320 --> 0:00:53.520 nuclear power strategy and potentially developing nuclear weapons as well, 0:00:53.960 --> 0:00:57.640 much to the constern nation of other nations like the 0:00:57.720 --> 0:01:02.480 United States, and that at some point at a uranium 0:01:02.560 --> 0:01:07.000 enrichment facility in Iran, people began to notice that centrifuges 0:01:07.040 --> 0:01:10.120 were really acting up. They were breaking down way more 0:01:10.200 --> 0:01:14.000 frequently than they should have been considering their age and 0:01:14.080 --> 0:01:17.680 how much they were working. At the same time, there 0:01:17.840 --> 0:01:23.880 was this tiny little anti virus company that had found 0:01:24.000 --> 0:01:27.240 some sort of weird code on an Iranian machine that 0:01:27.319 --> 0:01:31.160 was having a problem. It was constantly crashing and rebooting, 0:01:31.360 --> 0:01:34.560 and that led to the discovery of some malware that 0:01:34.720 --> 0:01:38.400 Microsoft would later name stuck s net. That malware would 0:01:38.880 --> 0:01:43.600 affect various machines running on different versions of Windows, and 0:01:43.880 --> 0:01:47.800 it seemed really really virulent, like it would very quickly 0:01:47.920 --> 0:01:50.840 infect a machine, but no one was really sure what 0:01:50.920 --> 0:01:54.040 it was doing. At this point. They they had not 0:01:54.160 --> 0:01:57.920 really unraveled the payload of the malware. They more or 0:01:58.000 --> 0:02:00.800 less understood how it was spreading, how it was going 0:02:00.880 --> 0:02:04.720 from one computer to the next, but they weren't sure why, like, 0:02:05.000 --> 0:02:07.880 what was the purpose of it? What did it actually do? 0:02:08.560 --> 0:02:10.760 And that's kind of where we pick up now. The 0:02:10.880 --> 0:02:15.359 date we're talking about is July. This is less than 0:02:15.400 --> 0:02:20.360 a week after the news broke about stocks net actually 0:02:20.440 --> 0:02:23.480 being a thing, And there was a security analyst with 0:02:23.560 --> 0:02:28.280 Samantech named Liam Omerchu who took a look at the 0:02:28.360 --> 0:02:31.520 main stucks net file and he was gob smacked. The 0:02:31.720 --> 0:02:35.720 file was way larger than your typical malware would tend 0:02:35.760 --> 0:02:42.040 to be. Malicious software is usually pretty simple. It's often inelegant, 0:02:42.600 --> 0:02:45.600 and it might only be fifteen kilobytes in size or less. 0:02:45.639 --> 0:02:47.440 It just needs to be big enough to do whatever 0:02:47.480 --> 0:02:50.080 it is the hacker intended for it to do, and 0:02:50.120 --> 0:02:53.919 smaller sizes are usually easier to slip in through something 0:02:53.960 --> 0:02:56.480 else than something that's larger. But Stuck's net was different. 0:02:56.520 --> 0:03:00.600 It was five kobyites, much larger than your typic a malware, 0:03:01.080 --> 0:03:04.560 and it didn't seem to contain any filler data in it. 0:03:04.560 --> 0:03:08.080 It wasn't like there was some sort of extra piece 0:03:08.120 --> 0:03:10.360 of data to make it look like it was something else, 0:03:10.400 --> 0:03:13.240 like a JPEG or a music file or something along that. 0:03:13.600 --> 0:03:17.200 Oh Murchu saw that the file had been through a 0:03:17.240 --> 0:03:22.400 packer sort of like a ZIP application, something that would 0:03:22.440 --> 0:03:26.200 compress the file. What's more, the people who had made 0:03:26.200 --> 0:03:30.160 it used an off the shelf compressor called Ultimate Packer 0:03:30.360 --> 0:03:34.000 for execute Able or up X, so they didn't bother 0:03:34.080 --> 0:03:35.920 to make their own tool. They used en off the 0:03:35.920 --> 0:03:38.760 shelf tool that made it very easy to unpack because 0:03:38.800 --> 0:03:40.560 all you had to do is have a copy of 0:03:40.560 --> 0:03:43.680 this tool. So oh Murchu was able to unpack this 0:03:43.760 --> 0:03:47.600 file without very much fuss. But here's the thing. Even 0:03:48.240 --> 0:03:51.120 though this wasn't a case where hackers had created a 0:03:51.160 --> 0:03:56.480 customized packer, which would make it more difficult to detect uh. 0:03:56.600 --> 0:04:03.440 The simple compression was a bit of a h I 0:04:03.440 --> 0:04:05.800 don't want to say a trap, but it was certainly 0:04:05.840 --> 0:04:10.520 misleading because the rest of the file showed that they 0:04:10.520 --> 0:04:13.280 had gone to a considerable length to hide what was 0:04:13.360 --> 0:04:16.880 happening and to create a very sophisticated type of malware. 0:04:17.160 --> 0:04:20.800 The unpacked file ballooned in size to one point one 0:04:20.880 --> 0:04:24.400 eight megabytes. Remember it had been five kilobytes, so this 0:04:24.480 --> 0:04:27.640 is more than twice the size of that packed file. 0:04:28.200 --> 0:04:32.080 At this stage, Omerchu saw what Baldwyn had noticed. Baldwyn, 0:04:32.160 --> 0:04:34.560 of course, was the analyst I talked about in the 0:04:34.680 --> 0:04:38.400 last episode who had discovered that there were references to 0:04:38.960 --> 0:04:42.080 two different pieces of software created by a German company 0:04:42.120 --> 0:04:47.640 called Siemens that made programs that were designed for other businesses. 0:04:48.000 --> 0:04:52.440 So this was the point where Omerchu saw that same information. 0:04:52.839 --> 0:04:55.279 The payload of the virus took the form of a 0:04:55.480 --> 0:04:59.200 d l L file. D l L stands for Dynamic 0:04:59.360 --> 0:05:02.960 Link lie Bray. It's a file extension found in Windows machines. 0:05:03.360 --> 0:05:07.880 The stocks net DLLL contained smaller d l l's within it, 0:05:08.360 --> 0:05:12.080 and each of those layers were encrypted, so it was 0:05:12.120 --> 0:05:16.200 like unraveling it you found another puzzle, and inside that 0:05:16.279 --> 0:05:19.560 was another puzzle, and the puzzles all were using different 0:05:20.240 --> 0:05:23.159 strategies in order to encrypt them, so it made it 0:05:23.240 --> 0:05:25.600 very tricky to find out what it should actually this 0:05:25.680 --> 0:05:28.840 thing was supposed to do. He also saw the stocks 0:05:28.880 --> 0:05:32.159 net was being incredibly sneaky. The malware was designed to 0:05:32.320 --> 0:05:36.800 live in a computer's memory, so instead of a computer 0:05:36.960 --> 0:05:40.040 referencing it's hard drive space in order to pull up 0:05:40.080 --> 0:05:44.039 information from the malware, which would make it easier to 0:05:44.960 --> 0:05:47.680 actually track down if you were looking for it, it 0:05:47.680 --> 0:05:51.159 would just reference it in its actual memory. And it 0:05:51.279 --> 0:05:55.440 altered the application programming interface for Windows so that it 0:05:55.480 --> 0:05:59.839 could execute code without getting picked up by anti virus software. Essentially, 0:06:00.200 --> 0:06:02.800 when Windows would go to execute a process related to 0:06:02.839 --> 0:06:05.760 Stuck's Net, the altered a p I would direct that 0:06:05.880 --> 0:06:09.920 inquiry to the file resting in the computer's memory beneath 0:06:09.960 --> 0:06:13.960 detectable levels, so the computer would just from its perspective, 0:06:14.120 --> 0:06:17.479 look like everything was working perfectly, but in reality, things 0:06:17.520 --> 0:06:20.159 were getting re routed so that it was covering up 0:06:20.320 --> 0:06:23.680 the viruses tracks. Stucks Net would also hide its processes 0:06:24.240 --> 0:06:28.599 within other processes, so it was abbuse skating what was 0:06:28.680 --> 0:06:34.159 going on, and it was really a confusing and effective 0:06:34.240 --> 0:06:38.960 way to hide what was actually happening. Oh Mrchue's conclusion 0:06:39.480 --> 0:06:42.359 was that the programmers who made this must have really 0:06:42.440 --> 0:06:45.240 known their stuff, and they must have worked really hard 0:06:45.320 --> 0:06:48.000 to make it difficult to detect stucks net even without 0:06:48.000 --> 0:06:52.160 a thorough or even with rather a thorough investigation. Oh 0:06:52.240 --> 0:06:54.839 Virtue also saw that the code had been encrypted and 0:06:54.880 --> 0:06:58.159 that it contained further encrypted files within it, and whomever 0:06:58.200 --> 0:07:00.040 had set it up had gone to great pains to 0:07:00.080 --> 0:07:02.719 get very difficult to get at the raw code, and 0:07:02.720 --> 0:07:05.159 he noted that the malware had an expiration date on 0:07:05.200 --> 0:07:08.800 it as well. That date was June two thousand twelve, 0:07:09.640 --> 0:07:12.560 and that meant that the malware would actually consult a 0:07:12.600 --> 0:07:15.440 computers onboard clock and look and see what day it is, 0:07:15.480 --> 0:07:19.080 what time it is. If the date was after June 0:07:19.080 --> 0:07:23.360 two thousand twelve, the malware wouldn't install itself on the 0:07:23.360 --> 0:07:26.480 target computer. So it was like a checklist, like, check 0:07:26.520 --> 0:07:29.400 the date is it before June two thousand twelve, It 0:07:29.560 --> 0:07:32.840 is gravy, let's go there. If it was after, like 0:07:33.320 --> 0:07:36.800 too late now and stop. So any computers previously infected 0:07:36.920 --> 0:07:40.920 with stucks net could continue and would continue to be compromised. 0:07:40.920 --> 0:07:46.880 They wouldn't magically become clear on June twelve, but no 0:07:47.160 --> 0:07:50.600 new computers would get infected by stocks net. Oh Merchu 0:07:51.040 --> 0:07:54.720 and his team also found that the malware had a 0:07:54.840 --> 0:07:58.800 phone home kind of feature. Every single time it infected 0:07:58.840 --> 0:08:01.520 a new computer, the malware would attempt to send a 0:08:01.560 --> 0:08:06.000 message back to headquarters. The headquarters was masked by using 0:08:06.040 --> 0:08:09.640 two domains that appeared at least on casual inspection to 0:08:09.800 --> 0:08:14.120 belong to soccer fans. One u r L was To 0:08:14.480 --> 0:08:18.920 Day's Football dot com Football spell fu t b o L, 0:08:19.600 --> 0:08:23.080 and the other was My Premieer My Premier Football dot 0:08:23.120 --> 0:08:25.880 com and again football Fu t b o L. The 0:08:25.920 --> 0:08:29.600 owner of the domains was unknown, but when they started 0:08:29.640 --> 0:08:31.600 to take a closer look at it, they realized that 0:08:31.640 --> 0:08:34.480 the registration had a fake name attached to it and 0:08:34.520 --> 0:08:37.280 that the credit cards associated with the account were fraudulent. 0:08:37.840 --> 0:08:41.640 The servers hosting the domains were in Malaysia and Denmark, 0:08:41.880 --> 0:08:45.599 but that didn't really necessarily mean anything. It was just confusing. 0:08:45.800 --> 0:08:50.120 The phone home messages included a small amount of encrypted data. 0:08:50.559 --> 0:08:53.319 O Merchu's team was able to break the encryption, however, 0:08:53.360 --> 0:08:56.640 and they saw that an infected machine would send a message. 0:08:56.679 --> 0:09:01.079 They gave the server the infected machines internal I P address, 0:09:01.120 --> 0:09:04.880 which version of Windows the machine was using, and whether 0:09:04.960 --> 0:09:08.480 or not that machine also happened to have those two 0:09:08.600 --> 0:09:13.800 Siemens programs installed on it. Eventually, the researchers figured out 0:09:13.840 --> 0:09:16.800 that stucks net would shut itself down if it could 0:09:16.800 --> 0:09:20.880 not find evidence of those Siemens programs on the host machine. 0:09:21.440 --> 0:09:24.160 The virus would continue to try and infect other machines 0:09:24.280 --> 0:09:27.800 from its infected host if it were on a network system, 0:09:27.840 --> 0:09:30.520 but otherwise it would not unleash it's payload if the 0:09:30.520 --> 0:09:34.480 Siemens programs weren't present, which was also confusing because here 0:09:34.520 --> 0:09:37.240 you had some malware that was so specific that it 0:09:37.360 --> 0:09:40.679 only leapt into action if those two programs were on 0:09:40.720 --> 0:09:43.120 the host computer. Otherwise it wouldn't do anything at all. 0:09:43.760 --> 0:09:48.439 So it clearly wasn't meant to rek havoc across all machines. 0:09:48.720 --> 0:09:52.760 It was still problematic that was infecting lots of different computers, 0:09:52.800 --> 0:09:55.920 because obviously you never want to have malware infect your computer. 0:09:56.320 --> 0:09:58.720 But if you didn't have those Siemens programs on your computer, 0:09:58.840 --> 0:10:01.480 it didn't do anything else apart from a tip to 0:10:01.920 --> 0:10:05.800 In fact, other computers network to yours. It didn't mess 0:10:05.880 --> 0:10:09.120 with your files, it didn't encrypt anything without your permission, 0:10:09.240 --> 0:10:14.000 it didn't delete anything. Everything was fine. So a lot 0:10:14.040 --> 0:10:17.240 of the code and implementation suggested that stocks net was 0:10:17.320 --> 0:10:20.560 probably the product of years of work from at least 0:10:20.640 --> 0:10:24.319 one or two or maybe three teams of talented programmers. 0:10:25.160 --> 0:10:28.040 There were some gaps in the code and implementation, however, 0:10:28.400 --> 0:10:32.640 that led some security experts to call it perpect perplexing, 0:10:32.760 --> 0:10:36.520 lye sloppy, or careless. One of those was Nate Lawson, 0:10:36.559 --> 0:10:39.480 who's a cryptographer, who criticized the code and said that 0:10:39.520 --> 0:10:42.760 it smacked of amateurism in many ways. And here's a 0:10:42.760 --> 0:10:45.600 direct quote. He said, I really hope it wasn't written 0:10:45.640 --> 0:10:48.080 by the USA, because I'd like to think our elite 0:10:48.120 --> 0:10:52.000 cyber weapon developers at least know what Bulgarian teenagers did 0:10:52.040 --> 0:10:57.880 back in the early nineties. Sick Burn Lawson. As part 0:10:57.880 --> 0:11:00.880 of their research, Ovirtua and his team over its Sumantech 0:11:01.120 --> 0:11:05.440 had contacted the domain name system service providers that were 0:11:05.480 --> 0:11:08.560 responsible for those two U r l's, and they decided 0:11:08.600 --> 0:11:13.640 to create a new destination for all those communications. Uh. 0:11:13.960 --> 0:11:17.439 It was kind of like a just a redirect, so 0:11:18.320 --> 0:11:21.440 these messages that were supposed to go to these two 0:11:21.520 --> 0:11:25.240 u r l's that we're posing as soccer fan sites 0:11:25.720 --> 0:11:28.959 would instead end up going Samantech. And they were hoping 0:11:28.960 --> 0:11:31.320 that by looking at the messages that these computers were 0:11:31.360 --> 0:11:33.600 sending back, they might be able to figure out what 0:11:33.760 --> 0:11:36.400 the heck this malware was trying to do. So they 0:11:36.400 --> 0:11:38.440 started looking for any patterns to get a better idea 0:11:38.440 --> 0:11:40.560 of what was going on, and one of the things 0:11:40.559 --> 0:11:43.319 they saw was that the majority of computers that were 0:11:43.320 --> 0:11:47.040 sending the messages were in Iran. Iran also had the 0:11:47.080 --> 0:11:51.600 most computers hosting the sought after Siemens programs, so that 0:11:51.720 --> 0:11:54.600 made them suspect that perhaps the people who made this 0:11:54.960 --> 0:11:59.679 malware were targeting Iran specifically for some reason. And the 0:11:59.720 --> 0:12:02.520 path Iran computers had never really been at the high 0:12:02.720 --> 0:12:06.200 end of infection rates whenever malware would break out, so 0:12:06.320 --> 0:12:08.920 that suggested to the team that they must have been 0:12:09.160 --> 0:12:14.680 the intended target, otherwise their percentage would not be so high. Uh, 0:12:15.000 --> 0:12:18.840 someone had to be concentrating on them. Working with that 0:12:18.880 --> 0:12:22.880 information that Iran was in fact the intended target, and 0:12:22.920 --> 0:12:25.440 then the virus was specifically looking for machines that had 0:12:25.440 --> 0:12:28.920 a particular type of industrial control software on it. They 0:12:28.920 --> 0:12:31.880 started to form hypotheses as to what the purpose of 0:12:31.960 --> 0:12:35.280 the malware could have been. So one possible explanation is 0:12:35.320 --> 0:12:38.319 that was part of an espionage project aimed at Iran's 0:12:38.440 --> 0:12:42.800 nuclear power program. Uh Natan's had attracted worldwide attention, as 0:12:42.840 --> 0:12:45.640 it could have been a front operation that appeared to 0:12:45.679 --> 0:12:48.960 be making nuclear fuel for power purposes, but in reality 0:12:49.040 --> 0:12:52.400 was secretly enriching uranium in order to make nuclear weapons, 0:12:52.679 --> 0:12:54.800 So that was one of the possibilities. They also thought 0:12:54.800 --> 0:12:59.320 that maybe it was targeting perhaps gas pipelines or electric 0:12:59.320 --> 0:13:03.640 power grids. They weren't entirely sure. Also, the propagation methodology 0:13:03.679 --> 0:13:07.240 suggested that perhaps the programmers had wanted to infect machines 0:13:07.320 --> 0:13:11.199 belonging to engineers who were responsible for transferring commands to 0:13:11.320 --> 0:13:15.080 programmable logic controllers or p lcs. Those are the type 0:13:15.080 --> 0:13:18.960 of controllers that the Siemens software would communicate with. Those 0:13:19.000 --> 0:13:23.000 commands would exist on air gapped systems, and typically you 0:13:23.000 --> 0:13:29.000 would transfer the commands by downlaying the commands the proper 0:13:29.000 --> 0:13:32.160 set of instructions onto a USB stick, and then you 0:13:32.200 --> 0:13:36.200 would transfer the commands to a computer responsible for controlling 0:13:36.200 --> 0:13:39.160 the p lcs via that USB stick, So you don't 0:13:39.200 --> 0:13:41.679 have the machine the kind of the overseer for all 0:13:41.720 --> 0:13:44.240 these plc's connected to the Internet, that would be a 0:13:44.280 --> 0:13:48.960 security vulnerability. Instead, you would create the program instructions on 0:13:49.320 --> 0:13:52.439 a different machine, put it on USB stick, and then 0:13:52.480 --> 0:13:57.840 transferred over to the overseer computer. And uh. The problem 0:13:57.920 --> 0:14:01.200 was that stucks net would propagate it self and copy 0:14:01.280 --> 0:14:05.240 itself onto USB sticks that were inserted onto computers that 0:14:05.520 --> 0:14:08.640 had been infected by stocks net. So you could have 0:14:08.679 --> 0:14:12.920 an engineer who's just innocently trying to transfer some commands 0:14:13.080 --> 0:14:17.520 to another computer actually infect that computer, so the engineers 0:14:17.520 --> 0:14:20.800 themselves became the carriers of the virus. If one worked 0:14:20.840 --> 0:14:24.160 from the hypothesis that the code was in fact meant 0:14:24.240 --> 0:14:28.720 to target computers at Iran's uranium enrichment facility, it narrowed 0:14:28.720 --> 0:14:31.800 done the list of potential attackers. For one thing, the 0:14:31.840 --> 0:14:34.960 sophistication of the code, the links the hackers went to 0:14:35.040 --> 0:14:38.120 in order to avoid detection, and the rapid response to 0:14:38.160 --> 0:14:41.600 the presence of the code being announced to the world 0:14:41.640 --> 0:14:44.240 in general suggested that there must have been a state 0:14:44.320 --> 0:14:49.160 sponsored group, a government funded attempt, So whomever was doing 0:14:49.200 --> 0:14:53.720 this had access to some pretty extensive resources. The candidates 0:14:53.720 --> 0:14:58.600 that people were identifying early on included Russia China, both 0:14:58.640 --> 0:15:01.480 of them had been working on date sponsored cyber warfare 0:15:01.520 --> 0:15:05.400 strategies for a few years. Israel was another possibility, and 0:15:05.440 --> 0:15:09.280 then there was, of course, the United States. There was 0:15:09.320 --> 0:15:12.080 also the chance that Iran had somehow developed this malware 0:15:12.120 --> 0:15:16.040 itself and then accidentally unleashed it on its own computers, 0:15:16.120 --> 0:15:20.360 but that was considered a lesser possibility. So who done it? 0:15:20.920 --> 0:15:23.320 I'll talk more about that in a second, but first 0:15:23.680 --> 0:15:33.400 let's take a quick break to thank our sponsor. So 0:15:33.440 --> 0:15:37.600 while they were looking through the code, the semantic team 0:15:37.680 --> 0:15:40.480 noted that they saw something that looked like it was 0:15:40.520 --> 0:15:43.640 a date that was written out in Unix format. So 0:15:43.720 --> 0:15:48.240 when you unscramble that the date would have been May nine, 0:15:48.360 --> 0:15:51.920 nineteen seventy nine, and this was a potential hint as 0:15:51.960 --> 0:15:58.640 to the origin of this malware. On May nine, the 0:15:58.680 --> 0:16:04.040 Iranian government executed a businessman named Habib El Ghanian by 0:16:04.160 --> 0:16:07.400 fire by firing squad so al Ghanian had been accused 0:16:07.480 --> 0:16:11.000 of spying on Iran on behalf of Israel. He was 0:16:11.040 --> 0:16:14.640 a philanthropist and a member of the Jewish community in Iran, 0:16:15.400 --> 0:16:18.120 and he was then accused by the government saying you 0:16:18.160 --> 0:16:22.400 aren't actually you're an Israeli spy. There was nothing in 0:16:22.560 --> 0:16:26.520 the code itself that would directly link to that event. 0:16:26.640 --> 0:16:31.720 There were no mentions of the name El Ghanaian in there, 0:16:31.840 --> 0:16:34.640 but there was that date and that was something that 0:16:34.720 --> 0:16:36.480 kind of stood out to the team when they were 0:16:36.520 --> 0:16:38.880 thinking about They did a Google search on that date 0:16:38.920 --> 0:16:41.240 to see if anything notable had happened, and when they 0:16:41.240 --> 0:16:44.560 saw that, they thought, huh, because one of the entities 0:16:44.600 --> 0:16:48.000 we thought about as possibly being responsible for this was Israel, 0:16:48.120 --> 0:16:51.200 so maybe that's an implication there. So I thought maybe 0:16:51.200 --> 0:16:55.480 this is a actually a long run at some form 0:16:55.560 --> 0:16:59.720 of retribution in response to that execution. There was another 0:17:00.600 --> 0:17:04.000 potential reference to Israel that was found in this code, 0:17:04.080 --> 0:17:07.800 although this one is definitely very tenuous, and that was 0:17:07.840 --> 0:17:10.080 in the form of one of the file directories and 0:17:10.160 --> 0:17:12.760 a file that was found within that stuck snet code. 0:17:12.760 --> 0:17:16.879 The file directory contained the words Murtis m y r 0:17:17.000 --> 0:17:21.800 t u S and Guava. Murtis is the genus that 0:17:21.880 --> 0:17:26.239 Guava belongs to, and in Jewish history, there is a 0:17:26.240 --> 0:17:30.520 prominent figure named Queen Esther but before she became Queen 0:17:31.160 --> 0:17:35.800 Esther's name was Hadasa, which is the Hebrew word for 0:17:35.960 --> 0:17:40.159 myrtle or Murdis. Now, again, this was like a long 0:17:40.240 --> 0:17:43.439 shot connection if you're looking at this, but it was 0:17:43.480 --> 0:17:47.040 a possible clue that maybe someone from Israel was involved. However, 0:17:47.359 --> 0:17:50.800 other people pointed out that there was another potential explanation 0:17:50.920 --> 0:17:54.360 for the Murtis name, that in fact it wasn't Murtis 0:17:54.400 --> 0:17:59.000 but my rt use because r TU could stand for 0:17:59.200 --> 0:18:04.680 remote riminal unit, So it wasn't, you know, a smoking 0:18:04.720 --> 0:18:07.640 gun by any stretch of the imagination. The Semantic team 0:18:07.680 --> 0:18:11.000 also saw that the stucks net code contained a function 0:18:11.440 --> 0:18:15.919 that logged every machine the malware had infected along its way, 0:18:16.040 --> 0:18:18.960 So that instance of malware, once it passed from one 0:18:19.000 --> 0:18:22.240 machine to another, it would send a note back to 0:18:22.440 --> 0:18:25.479 h Q, and that note would include, hey, I jumped 0:18:25.480 --> 0:18:29.000 from machine A to machine B. So by looking at 0:18:29.040 --> 0:18:32.000 an instance of the malware, you could track all the 0:18:32.040 --> 0:18:35.480 machines and it infected. In fact, you could trace the 0:18:35.600 --> 0:18:39.560 infection from the last point all the way to the 0:18:39.640 --> 0:18:42.320 very first one. So if you intercepted the message, as 0:18:42.480 --> 0:18:46.480 Semantic had been doing, because they had contacted those domain 0:18:46.560 --> 0:18:49.600 name servers to send that traffic to them instead of 0:18:49.600 --> 0:18:53.600 to those bogus soccer sites. You could actually trace back 0:18:53.720 --> 0:18:57.880 every infected machine to that point of infection, and from 0:18:57.920 --> 0:19:00.280 there you could look at the computers that were initially 0:19:00.320 --> 0:19:05.240 targeted as the starting point. Using that method, they identified 0:19:05.320 --> 0:19:09.560 five companies in Iran that served as the insertion points 0:19:09.560 --> 0:19:13.400 for the malware, and according to Samantech, those five companies 0:19:13.440 --> 0:19:18.639 accounted for twelve thousand infected machines at those locations and 0:19:18.720 --> 0:19:22.800 were responsible for an additional one hundred thousand more machine 0:19:22.800 --> 0:19:26.560 infections in more than one hundred countries. Now, one of 0:19:26.560 --> 0:19:31.040 the reasons stucks net was uncovered so quickly, relatively speaking, 0:19:31.560 --> 0:19:35.240 was because the designers had made it so viral. Using 0:19:35.320 --> 0:19:38.480 USB as an injection method helped reduce the target zone 0:19:38.520 --> 0:19:41.400 for the virus, but still the methods that stucks net 0:19:41.440 --> 0:19:45.080 depended upon to go from machine to machine pretty much 0:19:45.080 --> 0:19:49.040 guaranteed that it would eventually infect computers outside of its 0:19:49.080 --> 0:19:53.080 intended target zone. Most people agree that the stucks net 0:19:53.240 --> 0:19:58.040 designers wanted to really contain the infection. They just wanted 0:19:58.040 --> 0:20:02.880 to surgically target specif efect machines, but they also really 0:20:03.240 --> 0:20:07.040 really wanted to get a hit, So it was kind 0:20:07.080 --> 0:20:10.159 of a balancing act. How do you make sure that 0:20:10.280 --> 0:20:14.360 your malware is virulent enough so that you are guaranteed 0:20:14.359 --> 0:20:17.560 to hit your target, but you don't want it spreading 0:20:17.560 --> 0:20:20.360 throughout the world. They thought they got a good balance, 0:20:20.480 --> 0:20:24.240 especially with a USB delivery methodology, but as it turns out, 0:20:24.359 --> 0:20:28.960 it definitely expanded beyond Iran's borders, and that in turn 0:20:29.440 --> 0:20:32.399 made it more likely that someone was going to figure 0:20:32.400 --> 0:20:35.120 out that it existed. And once you know it exists, 0:20:35.440 --> 0:20:38.960 you can start to make countermeasures and protect yourself against 0:20:39.040 --> 0:20:42.200 it and try to remove the virus from infecting machines. 0:20:42.880 --> 0:20:46.000 So that computer that was caught in that crash reboot 0:20:46.040 --> 0:20:49.960 phase ended up being a red flag. But even if 0:20:49.960 --> 0:20:53.520 that computer had not failed at that time, some other 0:20:53.560 --> 0:20:57.840 machine would surely have done something similar and then stucks 0:20:57.880 --> 0:21:00.960 that would have been uncovered. So it probably would have 0:21:01.040 --> 0:21:04.520 just been another month, maybe two months. It's impossible to 0:21:04.600 --> 0:21:09.800 say because history is already unfolded. But it wouldn't have 0:21:09.840 --> 0:21:13.119 gone unknown forever, because again, it was just it was 0:21:13.160 --> 0:21:16.960 too violent. It was moving beyond the intended audience or 0:21:16.960 --> 0:21:20.240 intended targets. Even at the stage however, no one was 0:21:20.280 --> 0:21:23.359 totally sure what Stuck's net was actually doing. They knew 0:21:23.440 --> 0:21:26.359 what how it was doing things like how it was 0:21:26.680 --> 0:21:29.639 infecting machines, and they knew that it was looking for 0:21:29.680 --> 0:21:34.760 this Siemens software packages, but it didn't know why, what 0:21:35.040 --> 0:21:39.000 is its purpose? It was clearly searching for logic controllers, 0:21:39.200 --> 0:21:41.760 so stuff that was going to control industrial equipment. This 0:21:41.920 --> 0:21:45.280 was not something that was meant to infect the average 0:21:45.280 --> 0:21:49.399 person's PC. It was very much an industrial approach and 0:21:49.440 --> 0:21:53.040 it was targeting Iranian companies that seemed to be clear 0:21:53.600 --> 0:21:56.360 and security researchers had figured out that stucks net would 0:21:56.440 --> 0:22:00.800 replace a legitimate DLL file for a Siemens software package 0:22:00.880 --> 0:22:03.600 with what appeared to be a duplicate, and in fact 0:22:03.640 --> 0:22:06.640 it could do all of the functionality of the original 0:22:06.720 --> 0:22:10.120 DLL file. It just had a few extra tricks up 0:22:10.119 --> 0:22:14.480 its sleeve, like it could overwrite instructions to logic controllers 0:22:14.920 --> 0:22:18.399 which could be used to sabotage machinery. So, in other words, 0:22:18.520 --> 0:22:24.160 you send a command to a particular industrial device, this 0:22:24.840 --> 0:22:28.560 malware could potentially change that command. Not only could it 0:22:28.640 --> 0:22:33.000 change it, it could send feedback that the intended command 0:22:33.200 --> 0:22:35.400 was the one that went through, so to you when 0:22:35.400 --> 0:22:38.280 you review it it looks like, oh no, everything did 0:22:38.320 --> 0:22:40.440 exactly what was supposed to do. I mean, I told 0:22:40.480 --> 0:22:44.200 it to do X, and according to the computer log 0:22:44.600 --> 0:22:48.040 that's what happened. It did X. But in reality it 0:22:48.080 --> 0:22:50.920 did Why. It's just that the Duck's net was such 0:22:50.960 --> 0:22:54.720 a clever, clever little piece of software. It could cover 0:22:54.960 --> 0:22:58.720 up its tracks and make you think that everything was 0:22:58.760 --> 0:23:00.840 working the way it was supposed to, and yet stuff 0:23:00.880 --> 0:23:04.320 was breaking. The malware would also sent dormant for about 0:23:04.600 --> 0:23:08.359 two weeks and just record all operations that would go 0:23:08.440 --> 0:23:12.240 on during those two weeks, but it wouldn't change anything. Then, 0:23:12.520 --> 0:23:16.000 when the malware would start messing with stuff, start changing 0:23:16.000 --> 0:23:21.600 those operations, start changing those commands internally, it would replay 0:23:21.640 --> 0:23:25.920 the recordings of those operations from the previous two weeks. 0:23:26.480 --> 0:23:30.480 This is kind of like movies, you know, like in Speed, 0:23:31.080 --> 0:23:35.960 where Keano Reeves's character is able to get the video 0:23:36.000 --> 0:23:39.600 footage of him on the bus repeated on a loop 0:23:39.920 --> 0:23:43.640 so that Dennis Hopper's character doesn't get wise that they're 0:23:43.640 --> 0:23:46.080 actually trying to get off the bus and instead they're 0:23:46.119 --> 0:23:51.040 just being really focused about going more than There are 0:23:51.040 --> 0:23:53.560 a ton of movies that do this where someone has 0:23:53.840 --> 0:23:56.760 messed with a security camera, so it's just showing a 0:23:56.840 --> 0:24:00.879 repeated loop of video while they go and do something sneaky. 0:24:00.920 --> 0:24:04.680 That's exactly what this this virus was doing, except instead 0:24:04.680 --> 0:24:08.000 of being video footage, it's a recording of the operations 0:24:08.119 --> 0:24:14.399 that it was going through. On August, a Semantech team 0:24:14.400 --> 0:24:17.240 went public with the assertion that stuck net was designed 0:24:17.240 --> 0:24:22.040 to cause physical damage to infrastructure controlled by logic controllers. 0:24:22.840 --> 0:24:27.000 They still weren't sure exactly what type of systems might 0:24:27.040 --> 0:24:30.840 be the targets. They suspected it was nuclear power plants 0:24:31.000 --> 0:24:35.320 or nuclear enrichment facilities, uranium enrichment facilities, but they weren't 0:24:35.400 --> 0:24:37.399 entirely certain. They said it could be gas lines, or 0:24:37.440 --> 0:24:40.679 it could be something else. But they figured the purpose 0:24:40.760 --> 0:24:44.679 was not to steal information, but rather actual sabotage to 0:24:44.720 --> 0:24:48.320 cause physical damage to targets, and that would be the 0:24:48.359 --> 0:24:51.840 first documented case of actual cyber warfare. Five days later, 0:24:51.880 --> 0:24:54.879 a little bit later in August, Iranian officials ordered the 0:24:54.960 --> 0:24:58.560 outbound connections to those two dummy u r l's that 0:24:58.720 --> 0:25:01.280 had been gathering in from a on stocks net infective 0:25:01.320 --> 0:25:05.119