WEBVTT 00:00.000 --> 00:01.560 So, hi everybody. 00:01.600 --> 00:07.320 Good afternoon and welcome to this talk in the ICS village here at DEF CON, or there in DEF CON. 00:07.460 --> 00:12.920 This talk is the journey of ICS project files from visibility to forensics and exploitation. 00:13.200 --> 00:16.000 And I will explain what this means and what we'll talk about in a minute. 00:16.000 --> 00:17.760 But first, who I am. 00:17.760 --> 00:18.640 My name is Nadav. 00:18.640 --> 00:20.800 I'm the head of the research team at Clarity. 00:21.060 --> 00:25.160 And just a bit of background, Clarity is an ICS cybersecurity company. 00:25.160 --> 00:28.460 What we do is protect ICS networks. 00:28.460 --> 00:36.160 This protection is usually based on a deep understanding of the protocols and the assets that exist in such a network. 00:36.200 --> 00:50.520 And the job of the research team at Clarity is to do just that, is to investigate different ICS devices, different ICS protocols, to understand what a proper behavior is, what something that's a bit different that might be dangerous would look like. 00:50.520 --> 00:57.020 And based on this understanding, to improve the protection of the networks that we protect. 00:57.020 --> 01:01.720 I think that's the main agenda of the Clarity research team. 01:01.720 --> 01:11.500 But not only do we understand how the protocols work, we also usually use this understanding of OT networks and OT environments and leverage it to vulnerability research. 01:11.500 --> 01:19.540 So the team basically also plays with the PLCs, plays with the OT software to try and find vulnerabilities. 01:19.540 --> 01:24.720 And as you can see here in the picture in the slide, that's our lab. 01:24.720 --> 01:26.300 That's what we call our playground. 01:26.300 --> 01:31.020 And basically, what we do is we come in the morning and we start playing with PLCs. 01:31.040 --> 01:36.620 Or basically, now in COVID-19 times, we stay at home in the morning and start playing with PLCs. 01:36.620 --> 01:48.400 We've actually had to install internet-based switches so that we can power cycle some of the PLCs from away if we did anything that caused them to fall for some reason. 01:48.480 --> 01:53.020 And obviously, when we find these vulnerabilities, we will report to vendors. 01:53.020 --> 01:59.040 We will have the vendors issue patches and advisories to, obviously, to our customers and to the public at all. 01:59.040 --> 02:00.880 So that's basically my job. 02:00.880 --> 02:08.220 My job is to play with PLCs and try to find interesting points security-wise in these PLCs. 02:08.860 --> 02:11.880 And here, let's talk about what we're going to say today. 02:11.920 --> 02:24.240 So basically, the agenda is ICS project files, the good of them, what are these project files, what do I mean when I say an ICS project file, and what information it may contain and how it may be used for the good. 02:24.280 --> 02:33.400 The bad side is once we've done that and we've understood how these project files work, how they look, we will also try to understand why they may be vulnerable. 02:33.400 --> 02:37.540 They may pose some risk to the engineer's computer. 02:37.720 --> 02:49.620 And lastly, the ugly would be, I would try to convince you that not only these vulnerabilities exist, but they're not only theoretical vulnerabilities, they may be used by an attacker to infect an engineer. 02:49.640 --> 02:58.380 So basically, the flow of this presentation would be exactly the flow that my team and I did when we came to investigate project files. 02:58.380 --> 03:14.740 We started off from understanding how these project files work and what information can be found in them, so that we can better improve our capability to assist our customers in listing the assets in the network and identifying any potential soft spots in the network. 03:14.740 --> 03:16.500 So we started by that. 03:16.500 --> 03:24.840 And then when we looked into these project files, as we will do in a few minutes, we started understanding that they may be a bit risky in how they work. 03:24.840 --> 03:31.440 And so we start looking into these vulnerabilities, and then we'll go through these vulnerabilities that we found. 03:31.440 --> 03:33.360 So let's get to it. 03:33.360 --> 03:37.080 And I think we best start with what is an ICS project file. 03:37.080 --> 03:40.980 Because when I say ICS project file, it doesn't necessarily mean anything. 03:40.980 --> 03:44.140 So I think it's best to define this file. 03:44.140 --> 03:48.000 And let's start with what is an ICS engineering software. 03:48.000 --> 03:54.020 So basically, here are a few just a few screenshots of very common engineering software that we might encounter. 03:54.480 --> 04:00.980 And basically, when I say ICS project file, what I mean is how this engineering software saves its information. 04:00.980 --> 04:17.560 So for example, if you work on configuring a PLC using the B&R Automation Studio we see here, then the engineer would want at some point to save all the work they've done, so that later on they can use it or they can reopen it, they can edit it or anything like that. 04:17.560 --> 04:24.240 An ICS project file would be a file, a directory, anything, an entity in which all this information is saved. 04:24.240 --> 04:28.100 So when I say ICS project file, it doesn't necessarily mean just one specific file. 04:28.100 --> 04:34.820 It means the logical entity in which the ICS software saves all its information. 04:34.900 --> 04:42.760 And when that is the definition, you can start thinking and translating it into the information that we expect to find in these project files. 04:42.760 --> 04:45.780 Because I want to convince you that these project files are interesting. 04:45.780 --> 04:53.640 Don't forget, we came into this challenge trying to improve our capability to understand networks by looking at these project files. 04:53.660 --> 04:58.020 So let's think what information we expect to find in these project files. 04:58.160 --> 05:01.600 And obviously, we'll start from the topmost layer. 05:01.600 --> 05:13.120 And I think it makes sense that a project file that describes a plant or a manufacturing site or anything like that would have to contain the network layout. 05:13.120 --> 05:15.640 So from the topmost layer, we will see the network layout. 05:15.640 --> 05:23.620 As you can see here, some screenshots from the Step 7 engineering station by Siemens or from Rockwell's engineering software. 05:23.620 --> 05:28.500 You can see that it holds a list of assets in the network. 05:28.500 --> 05:33.000 So for example, here we have a profit bus with a few S7-400 stations. 05:33.000 --> 05:40.900 And we can use this file to identify that we have four stations along this bus and understand what they are and where they are. 05:41.480 --> 05:49.640 Next, let's dive into these stations because this project file has to contain information about the specific assets within the network. 05:49.720 --> 05:59.460 And so looking at the specific asset, you can see just a few more screenshots here describing how we may identify all the different slots on the device. 05:59.460 --> 06:09.380 So as you can see here, again, a snapshot from Siemens's software showing the exact slots and the model and the order number and the firmware for every slot, which is very interesting information. 06:09.380 --> 06:18.980 We can see that it also has, for example, here from BNR, you can also see the serial information, the serial number, or the network addresses. 06:18.980 --> 06:26.360 So the information about the hardware of every device in the network is very interesting and exists in these project files. 06:26.900 --> 06:33.900 But we can also dive even deeper because these engineering software obviously are used to engineer. 06:34.080 --> 06:40.860 And so programming the logic on these devices happens through these softwares and we would expect it to be saved within these project files. 06:40.860 --> 06:49.220 And indeed, diving into one specific device, looking into the guts of what is saved in this project file would be the actual logic. 06:49.220 --> 07:02.600 So again, a few screenshots here, but you can see that these project files will contain the block diagram, the ladder diagram, whatever type of logic we configured, we expect these project files to contain it. 07:02.940 --> 07:12.500 So that's going from the topmost layer of the network to the internals of a specific PLC, the actual logic that every PLC is running. 07:12.560 --> 07:17.060 And so I think hopefully that shows you that these project files are useful. 07:17.060 --> 07:32.080 They are able to provide us with a full inventory of assets, their details, their models, their firmwares, whatever, and of course also their logic, which is great for us and great for the engineer to use as backup, which is nice. 07:32.780 --> 07:34.540 They're also very easy to collect. 07:34.620 --> 07:49.780 The advantage with looking into project files, and here again, think of me as a person wanting to improve the visibility into the network, one alternative for me could be, for example, to just capture traffic from the network and try to map the network from this traffic. 07:49.780 --> 07:52.300 But capturing traffic requires a lot of work. 07:52.300 --> 08:08.040 It requires configuring expand ports, it requires waiting for interesting traffic to come, whereas looking into project files, all it means is that I have to access the file on the engineer's computer or on the backup server, because an engineer would probably use some kind of backup server that will hold all these project files in one place, 08:08.040 --> 08:09.380 so I don't have to look far. 08:09.380 --> 08:13.860 And I have these files at the palm of my hands without having to work too hard. 08:13.860 --> 08:23.280 And once I do have these files, all I have to do is just write some kind of script that knows how the file is built, and we'll get to it in a few minutes. 08:23.280 --> 08:35.460 And once I've done that, I can, within seconds, determine exactly all those details that I could, that I showed you just a second ago, starting from the network and going down to the actual logic. 08:35.540 --> 08:40.100 So that's very great, and that allows us to collect a lot of information within a second. 08:40.100 --> 08:44.400 But the next question should be, why do I care about this information? 08:44.400 --> 08:49.620 So why did we, why do we mind about the network or about the model information? 08:50.230 --> 09:02.660 And my claim is that the first step in securing an OT network would be this type of visibility, not only in securing, also in promising the continuous operation of such a network. 09:02.660 --> 09:07.000 But obviously, my perspective and Defcon's perspective is the security side. 09:07.000 --> 09:08.440 So let's start with network. 09:08.440 --> 09:17.520 Obviously, mapping the network is critical to understanding that any new devices connected to the network could be a malicious actor who connected to the network. 09:17.520 --> 09:24.160 And obviously, on the other side, identifying that a device is missing from the network, could be something happened to a device. 09:24.160 --> 09:31.780 And so we need to have this full picture before we start diving into the network to identify any changes that might have happened. 09:32.660 --> 09:42.320 Next, it also helps us to identify the roles of assets within the network, because if I have this project file, I can identify that every PLC has a specific responsibility. 09:42.320 --> 09:46.740 And so this PLC is part, is in charge of this part of the process line. 09:46.800 --> 09:48.940 And this PLC is in charge of that part. 09:48.940 --> 09:58.480 And so when anything we don't expect happens, I will be able to quickly identify what is the root cause of that. 09:58.480 --> 10:04.300 And also, it will help me manage these PLCs and assign people in charge for them, for example, and more. 10:04.820 --> 10:07.320 Next, we will have the detailed inventory. 10:07.320 --> 10:17.140 Because as you could see before, we also have the model, we also have the firmware version, and that's great for an engineer or for a security person to assess their security posture. 10:17.140 --> 10:33.980 Because when you know how many devices you have of each model, and what firmware they're using, you're able to identify very quickly how vulnerable you are to a new vulnerability that might have been published, how deep is your backlog in terms of firmware upgrades you need to perform on your devices, 10:33.980 --> 10:39.320 because you don't want to be too old or too vulnerable. 10:39.320 --> 10:50.160 So having this detailed inventory allows you to know where you're standing and keep yourself up to date with any new releases by vendors, for example. 10:50.880 --> 10:58.700 And lastly, when something does happen, it might be a security event, it might be an operational event. 10:58.700 --> 11:10.560 But when something does happen, if you do have a snapshot of where the plant was or where the site was yesterday, it's a lot easier to identify what has changed and what might be the root cause of the issue today. 11:10.660 --> 11:15.860 And also it's a lot easier to start everything up again tomorrow, because you know exactly where you are. 11:15.860 --> 11:22.380 You can use the configuration files, the ICS project files, to reconstruct everything very quickly. 11:22.380 --> 11:31.900 So you can also identify the cause of the issue and start again, which is great in terms of incident response in the OT industry where downtime is critical. 11:32.140 --> 11:42.900 So hopefully, I convinced you that that this information is critical, that ICS project files hold interesting information and that this information is important. 11:42.940 --> 11:59.020 One side note that is not the main issue that we speak about in this presentation, it has been spoken of in previous presentations, but one side note is seeing how these project files contain such valuable information also means that they may be used by malicious actors themselves. 11:59.020 --> 12:18.180 Because a malicious actor trying to plan an attack on an OT facility may use this information in the project files to plan their attack better, to identify vulnerable devices, to map tags on specific devices that affecting them would affect the the operation of the plant. 12:18.180 --> 12:32.900 And so these project files are very interesting from a security perspective, both from an operational perspective, both to the OT engineer, but also to the hacker doing the recon at this stage. 12:32.900 --> 12:35.960 So that's just a side note that these project files need to be saved. 12:35.960 --> 12:42.600 I know that a lot of people like saving their ICS project files on a Dropbox folders, etc. 12:42.600 --> 12:48.000 That's something to think of and making sure that these shared directories are secure. 12:49.300 --> 13:00.500 So ICS project files at this point, and hopefully if I convinced you that the thought process that we had convinced you, ICS project files are great. 13:00.500 --> 13:14.440 It's a super easy way to get tons of information that we want, which is very nice from Clarity's perspective or from my perspective, because the things I had to do to get all the model information of all the devices in the network before were a lot more complex. 13:14.440 --> 13:22.880 And now all I have to do is understand how a project file is built, and have the engineer provide me with the project file, and I'm able to produce all the information. 13:22.940 --> 13:25.820 So that sounds super easy and super great. 13:25.820 --> 13:27.080 But is it really? 13:27.080 --> 13:31.960 So I think this question builds up to what an ICS project file really looks like. 13:31.960 --> 13:35.840 We only discussed what ICS project files are in theory. 13:36.340 --> 13:39.980 But let's talk about what an ICS project file really looks like. 13:39.980 --> 13:43.360 What does it mean when I say ICS project file? 13:44.300 --> 13:49.840 Sorry, so the most basic use case would be just a text file. 13:49.840 --> 14:03.200 You may go to the software, you may click export on the software, and what you get is just an Excel file that my grandma can open with her office that we just recently installed for her, and understand everything in the network. 14:03.200 --> 14:12.220 So you can see that the IP addresses of the devices, the models of the devices, the versions, which is very nice, very easy, very useful, and that's great stuff. 14:12.220 --> 14:22.940 It's not very good for me as a researcher because then my boss will fire me if all files look like that, but it's great for my grandma and for the common engineer trying to understand the network format. 14:23.540 --> 14:29.580 And obviously, we have many formats, different formats of ICS textual project file. 14:29.580 --> 14:38.820 So another example for a project file by one of Rockwell's softwares, and as you can see here, an XML, which is also nice and very script friendly. 14:38.820 --> 14:48.260 If you want to write a script that will pass this information, you can see very easily that you can see the name of the bus, you can see the type of the network, you can see the host name of the devices. 14:49.780 --> 14:56.060 So for ICS project files being textual, it's really great, and we have everything we need for that. 14:56.060 --> 14:57.980 But that's not always the case. 14:58.100 --> 15:00.840 Sometimes, and for example, here, this is an ACB file. 15:00.840 --> 15:05.380 It's a file generated by the AliceLogix 5000, the Rockwell software. 15:05.820 --> 15:16.640 You can see that while it starts as a textual file, and you might think that your day is a good day, within a few lines, this becomes something that is clearly not English. 15:16.640 --> 15:23.980 And indeed, this file is most of the information within it, and all of the interesting information is saved in some kind of binary format. 15:23.980 --> 15:27.600 And so in this case, my grandma would probably call me and ask for help. 15:27.600 --> 15:29.180 And this help will not be easy. 15:29.180 --> 15:31.740 You have to try and understand what this project file looks like. 15:31.740 --> 15:41.200 You have maybe to reverse engineer the program, maybe to black box and understand, to do some black box research and understand how this project file is built. 15:41.200 --> 15:44.680 And indeed, that's what we have to do when we encounter such files. 15:44.680 --> 15:48.300 And you see that the Rockwell ACB file is not the only case. 15:48.300 --> 16:00.720 This is an example for a Siemens device, a file outputted by the Dixie5 software, and another example by another Rockwell software, an older version of the AliceLogix. 16:00.720 --> 16:03.380 So binary formats are very common as well. 16:03.380 --> 16:08.660 And in terms of research and understanding how they are built, you have to work a lot harder for that. 16:09.940 --> 16:16.300 Still, not only do we have binary formats or textual formats, we also have the cases where a project file is not really a file. 16:16.300 --> 16:17.500 It might be a directory. 16:17.560 --> 16:24.080 This is, for example, the project file that is generated by the Siemens Step7 software. 16:24.080 --> 16:30.320 And as you can see, it's just a directory containing a lot of subdirectories, containing a lot of other subdirectories, containing a lot of binary files. 16:30.320 --> 16:38.920 And so the project file here, the challenge of understanding where the information is, is not only understanding what the binary format is, it's also understanding where the file is. 16:38.920 --> 16:41.980 And in this case, we just see a few tens of project files. 16:42.200 --> 16:49.740 But as you can see here in this one of Mitsubishi's softwares, you can see that we got a directory that's about 7,000 files. 16:49.740 --> 16:56.080 So you have a lot of sifting through the files to do before you can start working for reals. 16:56.180 --> 17:03.240 And obviously, sometimes these archives may not be just a zip archive or just a plain directory, it may be a cub file. 17:03.300 --> 17:07.600 And I don't know how many of you are familiar with cub archives, they're a very old format. 17:07.600 --> 17:10.080 And what is today has been replaced by zip. 17:10.080 --> 17:20.860 And just finding a Python library to un-cub a cub archive is a challenge of itself, even though this format is publicly available and everything. 17:20.860 --> 17:24.640 Just finding a script to un-cub the file was a challenge of itself . 17:25.220 --> 17:29.960 But obviously, when it comes to directories, most of the files we need are zipped. 17:29.960 --> 17:33.320 And obviously, a zip is just an archive that contains a directory. 17:33.440 --> 17:41.000 And what the software does is take the whole directory containing all the information of the project and zip it into a single file. 17:41.000 --> 17:45.420 And as we'll see in a minute, this file may be saved with a different file extension. 17:45.420 --> 17:48.540 So it won't be .zip, it may be .something else. 17:48.540 --> 17:55.720 But if you just open it and check, you will see that actually, in fact, that's a zip file containing a lot of other types of files. 17:55.720 --> 17:59.660 And we'll go into that in just a second when we show an example. 18:00.300 --> 18:08.000 So just to recap, project files provide great information, and they come in many, many, many shapes and sizes. 18:08.080 --> 18:13.220 And so we have to work sometimes very hard to collect this information. 18:13.540 --> 18:17.600 So let's just see just one example, another screenshot of the file. 18:17.600 --> 18:24.600 This file was generated by Crimson, software by RedLion, to program HMIs. 18:24.600 --> 18:34.440 And as you can see, this file, while it's binary and not very readable for the common user, but you can see just by looking at it that it does hold some interesting information. 18:34.440 --> 18:37.700 For example, if you look here, you can see the model G306. 18:37.700 --> 18:44.120 And obviously, when we know that this file was used to configure G306, then we can identify that this field shows the model. 18:44.120 --> 18:48.660 We still have to work into understanding what... how do I get to this model? 18:48.660 --> 18:51.840 What means... how do I extract the model from this file? 18:51.840 --> 18:53.160 But we see that it has a model. 18:53.160 --> 18:57.320 We can also see that there are some numbers here, not sure what they mean. 18:57.320 --> 19:03.800 We have the string major, which might be a part of the major firmware version or anything like that. 19:03.800 --> 19:12.460 And so the research team would have to do a lot of digging and some reverse engineering into understanding what this Crimson file looks like. 19:12.460 --> 19:17.340 And the objective is to turn this file into something that's human readable. 19:17.340 --> 19:24.560 So for example, here, as you can see, what we were able to extract from this file is indeed the module and also the IP address. 19:24.560 --> 19:34.180 And obviously, I can't see, at least with a glance, I can't see the IP address here, but it took some work and some reverse engineering of the software to understand where this IP address is located within the file. 19:34.400 --> 19:43.100 And we could also identify that this is indeed an HMI and identify the exact version of the Redline Crimson software that was used to generate this file. 19:43.100 --> 19:46.360 In this case, these files are compressed. 19:46.360 --> 19:53.140 So it's one compression method that is pretty specific that was used to save all this information. 19:53.140 --> 20:00.480 Once they were uncompressed, we could start and identify exactly the interesting fields within this file. 20:01.140 --> 20:03.660 So that's one example. 20:03.660 --> 20:06.240 Let's think of another example for a project file. 20:06.240 --> 20:11.760 And let's have a look at the way the Siemens Step 7 saves its files. 20:11.760 --> 20:14.420 And as I mentioned before, basically, it's a directory. 20:14.600 --> 20:20.720 And so when you export from the Siemens Step 7, you get a directory, which usually you will zip. 20:20.720 --> 20:23.600 And what we get from our customers would be just a zipped file. 20:23.600 --> 20:28.340 And this zip extracts into this directory containing many files, as you could see before. 20:28.480 --> 20:38.760 And looking into these files, what we identified when we tried to find the interesting information is that one of the subdirectories within the SDB subdirectory is the interesting subdirectory. 20:38.760 --> 20:45.260 But that contained a lot of files with the names very informative names, 000a1.pg. 20:45.260 --> 20:55.280 So obviously, no file here is called, I am the interesting file or model and firmware file or anything like that, but rather these internal names. 20:55.280 --> 21:00.320 And so looking into these files, we identified that one of these files contained the interesting information. 21:00.320 --> 21:05.740 And just by opening it, you can see, again, some interesting strings hidden within this binary file. 21:05.780 --> 21:09.600 So you can see the order number again, you can see the model here. 21:09.940 --> 21:24.400 And so now we've discovered what the file was, what interesting file, what is the interesting file within this directory, we would still have to do a lot of reverse engineering to understand how to extract this information from that. 21:24.520 --> 21:27.580 And that basically is the job that we do. 21:27.580 --> 21:35.820 We commit to being able to understand the project file to extract all this information that we deem interesting in this project file. 21:35.820 --> 21:50.720 And when we get a new project file, a new format, a new requirement from a customer, what we will do is we will try to understand how this software works, same as we will do for a protocol, same as we will do for any type of such request. 21:50.980 --> 21:57.180 So just let's do a quick overview of what we see in these project files that we look into. 21:57.500 --> 22:08.660 And I think the most common thing that is found in all or in a great percentage of project files in the world, no matter the vendor, no matter the software, is a zip archive. 22:08.660 --> 22:12.440 Because usually these projects will contain a lot of different files. 22:12.440 --> 22:19.840 For example, one file will contain the hardware configuration, one file will contain the logic, one file will contain the list of assets, etc. 22:20.220 --> 22:27.280 And the project file is simply a zip directory containing all these files. 22:27.940 --> 22:33.180 Looking into this project file, and once we've unzipped this project file, we see a lot of files. 22:33.180 --> 22:39.040 And what we'll usually see, and what is very common in these files, is first OLE files. 22:39.040 --> 22:43.300 OLE is a format used by older Office documents, so it's a format by Microsoft. 22:43.300 --> 22:48.780 And it's a very convenient format for developers to hold a lot of binary information in different streams. 22:48.780 --> 22:53.320 So it's very convenient, and we see it in use a lot in ICS software. 22:53.960 --> 22:56.200 Next, we will see a lot of database files. 22:56.480 --> 23:02.240 And this makes sense when you come to think of it, because these project files need to contain a lot of information per every device. 23:02.240 --> 23:06.500 For example, you will need to contain the firmware, the model, the IP address, etc., etc. 23:06.560 --> 23:08.760 And so it makes sense to save it in a database format. 23:08.760 --> 23:14.180 And so we see SQL databases, MSSQL databases, a lot of database formats. 23:14.260 --> 23:21.400 One of these formats, just as a side note, is the Access database, another format by Microsoft that was used by Access. 23:21.400 --> 23:23.680 And that's, again, a very old format. 23:24.260 --> 23:30.940 And actually, so again, finding a Python library to access such a database, we couldn't do it. 23:30.940 --> 23:37.420 We simply couldn't find a Python-native library that could access the Access database. 23:37.420 --> 23:46.300 And so just a few weeks ago, we published our open-source Python library to interpret Access databases, which is nice. 23:46.300 --> 23:49.400 Now you can do it just by inputting in Python. 23:50.220 --> 23:52.660 Next, we will also see a lot of proprietary binary format. 23:52.660 --> 23:57.720 As I mentioned before, no one forces the vendor to work with a specific database or anything like that. 23:57.720 --> 24:03.700 So the vendor might decide that they want to save the information in their own proprietary format. 24:04.160 --> 24:05.600 And they will design this format. 24:05.600 --> 24:13.900 They will write the code to access this format and to parse this format, the information in there, and to obviously to save the information into this file. 24:13.900 --> 24:16.320 And so we see a lot of proprietary binary formats. 24:16.940 --> 24:26.880 Lastly, as I mentioned before, if you're really lucky from an engineer's perspective, if you're really lucky, you will get a text file you can open and just review the text file and understand everything. 24:26.880 --> 24:31.780 Obviously, from the researcher's perspective, it's less fun, because all you have to do is open the text file. 24:31.940 --> 24:38.680 But in my perspective, still, this is a very convenient and a very good way to save the information. 24:39.720 --> 24:52.560 So all that means that if we take a look back at what we discussed so far about what project files do, what information they contain, how they are built, then we can think of a few traits that are occurring. 24:52.560 --> 24:56.720 First is we see a lot of binary formats that are developed internally. 24:56.940 --> 25:03.340 And as I mentioned just a second ago, this is because the vendors will develop their own code and they will do that by themselves. 25:04.100 --> 25:17.260 Next, we will see that if the format is proprietary or if it's public or if it's a database or anything like that, still, a complex parsing is required in order to extract the information from this file or to save the information to this file. 25:17.260 --> 25:22.060 Because we're talking about a very big amount of information in various types. 25:22.060 --> 25:25.760 You sometimes want to save the IP address, you sometimes want to save the compiled logic. 25:25.760 --> 25:27.360 So various types. 25:27.360 --> 25:31.520 And obviously, it will require some complex parsing work. 25:32.280 --> 25:35.320 Lastly, it will hold some proprietary information. 25:35.320 --> 25:37.020 Every vendor will save their own information. 25:37.020 --> 25:42.540 Every vendor will design the file as they wish to save the information that they were looking for. 25:42.540 --> 25:47.640 So we will see a lot of proprietary information in proprietary formats that will be complex. 25:47.640 --> 25:55.960 And thinking of all these three traits, it sounds quite familiar, or at least to a researcher working in the ICS domain, sounds quite familiar. 25:55.960 --> 26:00.900 It sounds quite familiar because these traits are very common in ICS protocols as well. 26:01.260 --> 26:16.560 And so when we had reviewed enough ICS project files to extract the information from them, and at some point we had a nice collection of ICS project files formats that we support and understand, we started to think ICS protocols. 26:16.600 --> 26:21.480 And the next thought, as a security researcher, when you think of ICS protocols, the next thought is oil. 26:21.480 --> 26:26.280 And the reason for that is that vulnerabilities in ICS protocols exist, and exist a lot. 26:26.280 --> 26:30.140 And they are published weekly, and these devices are very vulnerable. 26:30.160 --> 26:35.800 And the reason for that is that this code was usually developed with no security in mind. 26:35.800 --> 26:43.840 And so when you're thinking of something that is comparable to ICS protocols, your next thought would be, let's check how secure this may be. 26:43.840 --> 26:51.240 And indeed, just a quick Google of ICS project file vulnerabilities showed us that not very. 26:51.240 --> 26:52.580 The answer is not very. 26:52.580 --> 26:59.640 And so just a quick Google, and you can see a lot of vulnerabilities that have been published in recent years. 27:00.300 --> 27:06.440 And just a quick lookup in the ICS self-website, for example, for Advisor is published recently. 27:06.440 --> 27:11.120 You can see here one type of vulnerability that's an SQL injection. 27:11.120 --> 27:12.460 Another is a use-after-free. 27:12.460 --> 27:15.020 Another is a stack buffer overflow. 27:15.320 --> 27:18.940 And so vulnerabilities are constantly published on these devices. 27:18.940 --> 27:24.540 And all these vulnerabilities, as you can see, are relevant to the ICS project files. 27:24.540 --> 27:29.340 And so these formats, these files, are vulnerable. 27:29.360 --> 27:34.300 Not only they are vulnerable, they're also growing in terms of awareness to the vulnerabilities. 27:34.300 --> 27:40.980 So just a quick example for that, we can have a look at the vulnerability that was published in 2016, just four years ago. 27:41.420 --> 27:47.220 And this vulnerability, and I put here the CV, is crashing the engineering software with a malicious project. 27:47.220 --> 27:52.700 This means that if the engineer would double-click on a malicious project, the engineering software would crash. 27:52.940 --> 27:58.480 And that vulnerability got, at the time, a CVSS score of 4.2, which is a low CVSS score. 27:58.480 --> 28:08.680 And not only that, the Advisor contains this, some kind of disclaimer sentence saying these vulnerabilities are not exploitable remotely and cannot be exploited without user interaction. 28:08.760 --> 28:16.000 So that's some kind of disclaimer saying, yes, this is a vulnerability, but no, it's not very, very interesting, or at least not at this time. 28:16.000 --> 28:22.220 And the reason I'm saying at this time is because we can look at the same vulnerability or similar vulnerability published in 2019. 28:22.220 --> 28:31.060 Again, a vulnerability that means that when you open a project file, when you double-click a project file, the engineering station, the engineering software would crash. 28:31.060 --> 28:35.340 And so the meaning of the vulnerability is the same. 28:35.340 --> 28:41.220 But this time, and we're three years ahead, it got a CVSS score of 7.8, which is a high CVSS score. 28:41.220 --> 28:43.240 And no disclaimer in this case at all. 28:43.240 --> 28:55.980 So there is some kind of growing understanding that these vulnerabilities, while they are not as sexy as protocol vulnerabilities, they are not as accessible as network vulnerabilities, they are interesting and they are dangerous. 28:56.240 --> 29:01.620 Another example for the growing security focus is the Pwn2Own competition that was held in Miami this year. 29:01.620 --> 29:11.220 So Pwn2Own is an organization of competitions that invite hackers to compete on finding specific vulnerabilities in specific devices. 29:11.220 --> 29:17.000 For example, find a remote code execution in a Tesla car. 29:17.000 --> 29:19.180 If you do, you get a lot of money for that. 29:19.180 --> 29:34.260 And so the first Pwn2Own competition that was targeted on ICS products was held just in the beginning of this year, and it had five categories, and one of which was finding vulnerabilities in ICS project files. 29:34.260 --> 29:49.280 And so even an organization like that, which is very oriented towards security and very up-to-date in terms of understanding the security world, sets one of the categories in the competition as vulnerabilities in ICS project files. 29:49.280 --> 29:52.740 And not only that, the winner in this category would win $20,000. 29:52.740 --> 29:58.420 So the motivation is not only interest, but also gaining a lot of money. 30:01.070 --> 30:04.350 And by the way, there was a winner in this category. 30:04.350 --> 30:13.730 Someone collected this prize, and this category also held a product by Schneider as well, which we also collected the prize for. 30:14.130 --> 30:21.010 So I think at this point, what we can say is that project files are great for asset management. 30:21.010 --> 30:21.870 They are very interesting. 30:21.870 --> 30:30.010 The information they hold are very interesting and valuable to an engineer and to the security of this network. 30:30.490 --> 30:33.050 They're also great for researchers' employment. 30:33.290 --> 30:34.470 And what do I mean by that? 30:34.470 --> 30:38.130 My job is based on the fact that these project files are complex. 30:38.130 --> 30:45.850 If anyone could just open a project file and extract the data from it, my day would be a lot less interesting. 30:45.850 --> 30:47.410 And so they're great for me. 30:47.630 --> 30:56.590 But also, they might be great for an attacker, not only for recon purposes, for mapping the network, as we mentioned before, but also because they are vulnerable. 30:56.650 --> 31:01.410 And what I would want to show you is that they're vulnerable, not just in theory. 31:01.410 --> 31:04.370 So we saw that there were vulnerabilities published. 31:04.370 --> 31:12.830 But let's do a quick overview of these parts that we saw before, that comprise a common ICS project file. 31:12.830 --> 31:16.870 And as you can remember, we discussed the zip file, we discussed OLE files, etc. 31:16.870 --> 31:18.690 And let's take it step by step. 31:18.690 --> 31:25.470 And I will show you that just in the recent months, vulnerabilities have been published for every part of this project file. 31:26.330 --> 31:29.030 So let's think of it step by step. 31:29.030 --> 31:31.070 And we started off with a zip. 31:31.210 --> 31:37.130 And what I wanted to show for zip files is the very common zip slip vulnerability. 31:37.410 --> 31:40.950 And so what this actually means is there is no sanitation on zip paths. 31:40.950 --> 31:44.350 But let's explain what this means in a more technical way. 31:44.350 --> 31:48.290 So let's have a look at what the header of the zip file looks like. 31:48.290 --> 31:50.310 So take it in for a second, I'll have a drink. 31:54.060 --> 31:54.880 Okay, great. 31:54.880 --> 32:00.860 So as you can see, as you can see, a zip file holds a lot of different files within it, right? 32:00.860 --> 32:05.780 When you double click a zip file, it extracts into multiple files and multiple directories. 32:05.780 --> 32:16.220 And the way that the file is saved for real, in its binary data, is that its header contains the list of files to which we need to extract the information. 32:16.220 --> 32:22.860 So for example, this file will extract information to a directory called example-slash-uex. 32:22.860 --> 32:28.200 And another file will be extracted to example-slash-file1.txt. 32:28.200 --> 32:32.900 And another file will be extracted to example-slash-filewithalongname.sql. 32:32.900 --> 32:37.980 So when you double click this file, you will get a new directory called example, and within it, you will get three files. 32:38.500 --> 32:39.340 And that makes sense. 32:39.340 --> 32:43.000 And that's just how the zip file header works. 32:43.000 --> 32:50.860 But this also means that if not properly handled, an attacker may use these attributes of a zip file. 32:50.860 --> 32:51.980 And how they may use it? 32:51.980 --> 32:56.640 They may employ the special characters that allow directory traversal. 32:56.640 --> 33:01.080 Because this slash dot dot slash means go up one directory. 33:01.640 --> 33:15.800 And so instead of saving the file within the example directory, this will cause the software that extracts this file to save this file somewhere outside of the targeted directory. 33:15.800 --> 33:21.520 And so we may write files basically to any location we want on the computer on which this file is extracted. 33:21.520 --> 33:23.320 And this is a very common vulnerability. 33:23.320 --> 33:24.620 It has been known for years. 33:24.620 --> 33:28.460 It has been handled in many products. 33:28.460 --> 33:46.600 But what we see in the ICS domain, unfortunately still, is that some products still do not sanitize the paths and do not make sure that there is no use of these characters and allow an attacker to employ this vulnerability and save files basically to any location they want on the target computer. 33:46.600 --> 33:53.820 And saving files on any location sometimes would directly mean being able to take control of the computer, because you may override some files. 33:53.820 --> 33:56.520 You may save files, for example, like we did here. 33:56.520 --> 34:00.300 And you may save files to the startup directory and save in the store.exe. 34:00.300 --> 34:03.080 And that's obviously not something we want. 34:03.440 --> 34:16.400 So that's just a very, very basic vulnerability in zip files that is still very, very common and may happen if the product does not make sure that the paths within the zip file header are valid. 34:16.580 --> 34:18.280 So that's zip files. 34:18.280 --> 34:27.480 But let's take a step in and I'll just show a couple of vulnerabilities that were published just in the recent months in these exact things. 34:27.480 --> 34:34.380 This path reversal CWE means exactly that, means that someone could use this attribute. 34:34.500 --> 34:42.800 And as you can see here, just in the past, during the past year, several vulnerabilities have been published in this exact method. 34:42.800 --> 34:44.280 So that's a zip file. 34:44.280 --> 34:48.620 Now let's have a look at the OLE files that we mentioned that are very common within zip files. 34:48.620 --> 34:58.520 And here I will not go into a lot of details, but as I mentioned before, OLE files are the files used by office products and, sorry, old office products. 34:58.520 --> 35:02.860 And old office products, we all know that have been vulnerable for years, right? 35:02.860 --> 35:12.720 You would not open an email saying, hey, please download and open this world document I sent you from someone you don't know, because you know that this could be dangerous. 35:12.720 --> 35:28.680 And still, a document from the FBI showed that the most common used vulnerabilities still today in 2020 are, I think, five of the 10 most common used vulnerabilities in real life are still vulnerabilities in office files. 35:28.740 --> 35:31.400 And so OLE files, vulnerable. 35:31.400 --> 35:35.580 It doesn't matter if you wrap it with Office or wrap it with an ICS engineering software. 35:35.580 --> 35:36.720 They are vulnerable. 35:36.720 --> 35:37.960 That's OLE files. 35:38.040 --> 35:40.220 Next, let's discuss databases. 35:42.140 --> 35:49.020 And when you think of database and you're a security researcher, the next thing that comes to your mind is SQL injection. 35:49.020 --> 35:57.360 That's, again, a very, very common vulnerability in the handling of SQL queries when working with databases. 35:57.360 --> 36:01.520 And it's very common in the world, and specifically in ICS software. 36:01.520 --> 36:02.360 It still exists. 36:02.360 --> 36:07.420 It may exist if the software uses a database to save its information. 36:07.420 --> 36:17.780 So let's take just one example for a vulnerability that was discovered as part of the Pwn2Own competition by Uri from my team. 36:17.800 --> 36:21.220 And what... sorry, by Amir and Sharon from my team. 36:21.240 --> 36:28.140 And what they discovered was that one of these products saves this information within a database . 36:28.140 --> 36:33.360 And if you save... and this database holds the version in which the information was saved. 36:33.360 --> 36:46.060 So if you change the version field to a lower version, then when the software opens this database, it will run some migration scripts on the file. 36:46.060 --> 36:58.280 And what we found was that you could use one type of SQL injection in these parts and create a full remote code execution just based on an SQL injection in the database. 36:58.280 --> 37:08.240 And what it looks like is, as you can see, the engineer would double-click the project file, the engineering software would open, and within a second we will see a notepad pop up. 37:08.240 --> 37:11.560 And in this case, notepad, but in a malicious case, it will not be notepad. 37:11.560 --> 37:14.480 It will be some kind of software that might cause damage. 37:14.480 --> 37:16.380 So that's databases. 37:16.760 --> 37:18.360 Let's go on to binary formats. 37:18.360 --> 37:23.480 And obviously, binary formats are risky because they mean that someone had to write a lot of code. 37:23.480 --> 37:28.100 Someone had to design a format that would be secure enough. 37:28.100 --> 37:35.860 And all this work has been done usually years ago when no one was security-oriented. 37:35.860 --> 37:44.680 And so vulnerabilities in binary formats exist and exist a lot, and we see a lot of them published on a monthly basis. 37:44.680 --> 37:53.440 And so I won't go into details in this case because simply you can understand that the complexity of a binary format means that many vulnerabilities may be found within that. 37:54.020 --> 38:04.720 For example, just one example here, this article by Ed Kovacs from Security Week is reviewing a vulnerability published in the Red Lion HMI files that we saw before. 38:04.720 --> 38:18.280 So those compressed files and those Crimson compressed files we saw before, we saw earlier, are vulnerable to some vulnerabilities that were discovered by security researchers and were published before. 38:18.700 --> 38:20.400 So that's binary formats. 38:20.560 --> 38:24.640 Lastly, we said that if you're really lucky, you would have a text file. 38:24.640 --> 38:28.020 And one might think that a text file, how hard can it be? 38:28.020 --> 38:31.080 What can be vulnerable within a text file? 38:31.080 --> 38:44.480 And still a vulnerability published by Uri from my team just a few months ago in one of Siemens's products showed that the parsing of a textual file within the software may have caused a remote code execution. 38:44.480 --> 38:50.720 So again, if you would double click the project file, code would be executed. 38:50.720 --> 38:56.940 And that's even though this file was just a textual format, the bug was obviously in the parsing of this file. 38:57.540 --> 39:06.740 So what we could see is that taking apart the common ICS project file, you can understand that every part of it may be vulnerable. 39:06.740 --> 39:12.140 And basically what I want to convince you is these vulnerabilities may exist, they're not something that is out of the ordinary. 39:12.160 --> 39:20.140 So let's take one type of project files, and this would be a project file used by Phoenix Contact software PLCnext. 39:20.140 --> 39:26.460 And let's see exactly how this vulnerability works, just so we can get a hang of how this vulnerability works. 39:26.480 --> 39:43.240 And so this vulnerability was discovered by Amir from my team, and this vulnerability allows remote code execution when a project is opened in the PLCnext software by Phoenix Contact. 39:43.520 --> 39:45.640 Let's understand how it works. 39:45.640 --> 39:47.520 So first of all, this is the software. 39:47.520 --> 39:49.000 This is just a screenshot of the software. 39:49.000 --> 39:50.840 As you can see, it holds some information. 39:50.960 --> 39:54.840 It shows all the information about the HMI, the PLC, etc. 39:54.840 --> 39:56.620 And this is just how the software looks like. 39:56.620 --> 39:59.500 But let's see how the information is saved behind the scenes. 40:00.240 --> 40:04.740 And indeed, in this case, the information is saved in a pcwex file. 40:04.740 --> 40:10.560 And as I mentioned before, the pcwex file is actually just a zip file with a different extension. 40:10.560 --> 40:15.040 And so if you extract it, you can see that there are a few files within this file. 40:15.040 --> 40:19.280 And one of the files that was of interest for us is the project.proj file. 40:19.680 --> 40:21.200 And why is that? 40:23.760 --> 40:28.200 The reason for that is that this file is just an XML, a textual file. 40:28.480 --> 40:34.640 But as you can see here, it contains an import line that imports a file from a specified location. 40:34.640 --> 40:41.180 And so what you would do is you would... this line here contains basically a pointer to another file. 40:41.180 --> 40:47.540 And this file will be loaded when the project starts or will be accessed when the project is loaded. 40:47.540 --> 40:52.300 And this file that is pointed to here would be the targets file. 40:52.320 --> 40:54.660 And this targets file, again, is a textual file. 40:54.660 --> 41:01.200 But as you can see here now, it gets interesting because it contains the names of some DLLs that need to be loaded when the project is built. 41:01.740 --> 41:10.980 And so what we discovered was that basically when you open a project file, you... when you open a project file, this whole chain of events happens. 41:11.080 --> 41:23.640 And if you want to be... to think of it from a malicious actor's point of view, what you would want to do is to be able to send a malicious pcwex file and get the engineer to open it. 41:23.640 --> 41:30.360 And you would change the pointer here to anything you want, basically any other file you want. 41:30.540 --> 41:34.840 And let this other targets file contain a pointer to your malicious DLL. 41:34.840 --> 41:36.780 And let's see what it looks like in real life. 41:36.780 --> 41:43.080 So we start again with the same directory structure, because we only change a bit of lines within the files. 41:43.080 --> 41:45.580 And within the project file, we changed it. 41:45.580 --> 41:53.580 Instead of using some kind of environment variable, we'll simply point it to a malicious SMB server that is accessible to the victim's machine. 41:53.580 --> 41:56.540 So we don't have to drop this file ahead on the victim's machine. 41:56.540 --> 42:01.280 All we have to do is make the victim's machine approach us and request for the malicious targets file. 42:01.460 --> 42:11.020 And within the targets file, again, what we would do is we would point to a malicious DLL that is used, that is loaded when the project is built. 42:11.080 --> 42:16.320 And so what happens basically when the project is open, that the software is automatically building the project. 42:16.320 --> 42:24.260 And so they access this project file, this project.proj file, and collect the malicious.targets file from our server. 42:24.260 --> 42:31.120 And based on this malicious.targets file, they will collect the DLL again from our server and execute it. 42:31.120 --> 42:41.140 And once they've done that, basically, we ran our own DLL on the remote machine with the permissions of the software, and we've taken over the control. 42:41.140 --> 42:43.100 And that's the whole vulnerability. 42:43.100 --> 42:45.500 And that's pretty cool, in my opinion. 42:45.500 --> 42:52.680 And obviously, this vulnerability was disclosed to Phoenix, and we would like to acknowledge their quick remediation of that. 42:52.680 --> 43:03.620 It took, I think, less than two months between the time we disclosed this vulnerability to Phoenix and the time they released the fixed version and its advisory, which is very nice and not very common in the ICS domain. 43:03.820 --> 43:09.900 So we would like to thank Phoenix for fixing this in such a hurry. 43:10.360 --> 43:10.960 Cool. 43:10.960 --> 43:13.260 So what did we do so far? 43:13.260 --> 43:17.820 We showed that those project files are interesting, and we showed that they are vulnerable. 43:17.820 --> 43:19.840 We showed that you can find vulnerabilities in them. 43:19.840 --> 43:23.660 And some of these vulnerabilities, you don't even have to work very hard in order to explain. 43:23.840 --> 43:28.000 So let's complete the last piece of the puzzle. 43:28.000 --> 43:34.880 The last piece of the puzzle would be how I can use these vulnerabilities in order to take over an engineer's computer. 43:34.980 --> 43:39.080 Because if you think of a protocol vulnerability, you know that the PLC is there. 43:39.080 --> 43:39.940 You know that you are here. 43:39.940 --> 43:42.860 All you have to do is communicate with the PLC, and you are done. 43:42.900 --> 43:46.100 But in the case of a project file, you know that the engineer is here. 43:46.100 --> 43:50.380 You know that you are here, but you want to get the engineer to open a project file of your own. 43:50.380 --> 43:54.880 So the attack vector here is something that I need to convince you that exists. 43:55.300 --> 44:05.360 So we had a look, and we tried to think what ways could be used to get a victim engineer to open an ICS project file. 44:05.360 --> 44:14.740 Because you know that when someone sends you a doc file, as I mentioned before, via email, someone you don't know, you will probably be suspicious about it and not do anything with that. 44:14.740 --> 44:22.700 But if you're an OT engineer and they send you a Rockwell ACD file or any other type of ICS engineering file, then you might be curious. 44:22.700 --> 44:24.200 This is your world. 44:24.200 --> 44:25.180 You're interested. 44:25.180 --> 44:27.020 You want to understand what's going on. 44:27.020 --> 44:28.320 You will want to open this file. 44:28.320 --> 44:29.480 You will be curious. 44:29.600 --> 44:38.940 So instead of sending you a doc file, in theory, the malicious actor could send you an ACD file or a project file and get you to open that. 44:38.940 --> 44:40.780 It would be more likely that you do. 44:41.240 --> 44:43.700 And this type of phishing campaigns happens. 44:43.700 --> 44:55.700 In the COVID-19 world, you know that and many papers have been published on that, that the fact that phishing is on the rise and targeted phishing towards ICS industries is on the rise. 44:55.700 --> 45:05.240 So as you can see here, this may be used as a phishing campaign that is very targeted and very specific towards OT engineers. 45:11.530 --> 45:26.470 Sorry, and not only phishing campaigns or not only phishing campaigns via email, what we thought next was, let's check the forums, the support forums in the ICS domain, because we know these support forums are very, very, in very, very common use. 45:26.470 --> 45:36.570 And many people use them to ask questions, to help other people to get some support, both the vendors' own forums and the public forums. 45:36.570 --> 45:44.430 So we had a look at these forums and we looked for people who might have posted these project files and had a look at what they have done. 45:44.430 --> 45:47.550 And so, for example, this is just one message from a forum that we found. 45:47.550 --> 45:51.670 I have an ACD file, but I do not have the software to read the controller tags. 45:51.670 --> 45:54.390 Can anyone please help me convert this file into a PDF? 45:54.510 --> 45:57.550 And they published with this message, they published an ACD file. 45:57.950 --> 46:04.670 And what you could see in the comments section is that many, many people did download this file and did open this file and help this person. 46:04.670 --> 46:09.710 And obviously, this was the happy case where someone did need help and many people did help him. 46:09.710 --> 46:22.770 But if it was a malicious case, then this question could have caught many ICS engineers and have taken control over the computer if this was a malicious case. 46:22.770 --> 46:29.290 So this attack vector of getting an ICS engineer to open a project file, I think, may happen. 46:29.290 --> 46:36.030 It's really real, either as part of a request or anything like that. 46:36.030 --> 46:50.130 And the reason this is very critical, and more critical than using just a doc file, is that this engineer who sent an ICS project file via email from the internet, they will open it on their computer. 46:50.130 --> 46:57.310 And this computer, you know that this computer, by definition, has access to the shop floor, has access to the actual physical devices. 46:57.310 --> 47:07.310 Whereas if this was just a Microsoft Word document, this engineer might have opened it on their own computer, which is not connected to anything interesting. 47:07.310 --> 47:17.710 But if you provide the engineer with the project file, they would take it to the computer that is connected to the shop floor, because it has the engineering software installed on it. 47:17.710 --> 47:27.850 So basically, the hacker, with just one step, got access not only to an engineer's computer, but to the actual critical engineer computer and to the actual critical network. 47:28.310 --> 47:36.350 And so, hopefully, what I could convince you with along this talk was that ICS project files, they are very interesting. 47:37.410 --> 47:42.410 They allow you great visibility into a network and great understanding of your network. 47:42.410 --> 47:45.890 And so, I don't want anyone to go home and delete all your project files, right? 47:45.890 --> 47:51.030 Because you have to keep working, and this may provide you of great value if you handle these files right. 47:51.030 --> 47:56.810 Obviously, you also have to secure your files to make sure that no malicious actor gains access to those files as well. 47:56.810 --> 47:58.630 But they are very important. 47:58.830 --> 48:04.730 But on the other side, you have to be aware that these project files can be just as malicious as a doc file. 48:05.230 --> 48:12.950 And this means that you don't want to open any ICS project file that is uploaded to a support forum or to anything like that. 48:12.950 --> 48:22.630 And actually, these files may be even more dangerous than these doc files, because what we said just a minute ago, that they will provide the attacker with access directly to the critical network. 48:23.710 --> 48:34.210 So, these files for an attacker actually are a great way to spread through phishing campaigns that are targeted, that are going directly to the ICS engineer, not just to anywhere around the world. 48:34.210 --> 48:36.410 And so, they're very critical in that. 48:36.510 --> 48:40.950 And they will get this attacker a foothold in the ICS network. 48:40.950 --> 48:48.150 And so, the bottom line here of this talk is just use these ICS project files to gain visibility into your network. 48:48.190 --> 48:49.830 And that is great. 48:49.830 --> 48:58.150 But be suspicious of any ICS project file that might have been sent to you, and that might pose risks to your network. 48:58.650 --> 48:59.630 And that's it. 48:59.630 --> 49:02.910 Thank you very much, and have a great conference.