[00:00.000 --> 00:05.820]  So, hi everybody. Good afternoon and welcome to this talk in the ICS village here at DEF CON,
[00:05.820 --> 00:11.700]  or there in DEF CON. This talk is the journey of ICS project files from visibility to forensics
[00:11.700 --> 00:16.100]  and exploitation. And I will explain what this means and what we'll talk about in a minute. But
[00:16.100 --> 00:21.620]  first, who I am. My name is Nadav. I'm the head of the research team at Clarity. And just a bit
[00:21.620 --> 00:28.460]  of background, Clarity is an ICS cybersecurity company. What we do is protect ICS networks.
[00:28.460 --> 00:34.400]  This protection is usually based on a deep understanding of the protocols and the assets
[00:34.400 --> 00:39.780]  that exist in such a network. And the job of the research team at Clarity is to do just that,
[00:39.780 --> 00:44.400]  is to investigate different ICS devices, different ICS protocols, to understand
[00:44.400 --> 00:49.880]  what a proper behavior is, what something that's a bit different that might be dangerous would look
[00:49.880 --> 00:57.020]  like. And based on this understanding, to improve the protection of the networks that we protect.
[00:57.020 --> 01:03.260]  I think that's the main agenda of the Clarity research team. But not only do we understand
[01:03.260 --> 01:08.680]  how the protocols work, we also usually use this understanding of OT networks and OT environments
[01:08.680 --> 01:14.900]  and leverage it to vulnerability research. So the team basically also plays with the PLCs,
[01:14.900 --> 01:20.500]  plays with the OT software to try and find vulnerabilities. And as you can see here
[01:20.500 --> 01:27.000]  in the picture in the slide, that's our lab. That's what we call our playground. And basically,
[01:27.020 --> 01:33.460]  what we do is we come in the morning and we start playing with PLCs. Or basically, now in COVID-19
[01:33.460 --> 01:38.240]  times, we stay at home in the morning and start playing with PLCs. We've actually had to install
[01:38.240 --> 01:45.560]  internet-based switches so that we can power cycle some of the PLCs from away if we did anything that
[01:46.280 --> 01:51.120]  caused them to fall for some reason. And obviously, when we find these vulnerabilities,
[01:51.120 --> 01:56.140]  we will report to vendors. We will have the vendors issue patches and advisories to,
[01:56.140 --> 02:01.360]  obviously, to our customers and to the public at all. So that's basically my job. My job is
[02:01.360 --> 02:09.480]  to play with PLCs and try to find interesting points security-wise in these PLCs. And here,
[02:09.480 --> 02:15.600]  let's talk about what we're going to say today. So basically, the agenda is ICS project files,
[02:15.600 --> 02:20.180]  the good of them, what are these project files, what do I mean when I say an ICS project file,
[02:20.180 --> 02:25.500]  and what information it may contain and how it may be used for the good. The bad side is
[02:26.140 --> 02:30.380]  once we've done that and we've understood how these project files work, how they look,
[02:30.380 --> 02:36.280]  we will also try to understand why they may be vulnerable. They may pose some risk to the
[02:36.280 --> 02:42.240]  engineer's computer. And lastly, the ugly would be, I would try to convince you that not only
[02:42.240 --> 02:46.480]  these vulnerabilities exist, but they're not only theoretical vulnerabilities, they may be used
[02:46.480 --> 02:53.660]  by an attacker to infect an engineer. So basically, the flow of this presentation would be
[02:53.660 --> 02:58.980]  exactly the flow that my team and I did when we came to investigate project files. We started off
[02:59.580 --> 03:03.760]  from understanding how these project files work and what information can be found in them,
[03:03.760 --> 03:10.160]  so that we can better improve our capability to assist our customers in listing the assets in
[03:10.160 --> 03:16.640]  the network and identifying any potential soft spots in the network. So we started by that. And
[03:16.640 --> 03:20.620]  then when we looked into these project files, as we will do in a few minutes, we started understanding
[03:20.620 --> 03:27.380]  that they may be a bit risky in how they work. And so we start looking into these vulnerabilities,
[03:27.380 --> 03:33.860]  and then we'll go through these vulnerabilities that we found. So let's get to it. And I think
[03:33.860 --> 03:39.560]  we best start with what is an ICS project file. Because when I say ICS project file, it doesn't
[03:39.560 --> 03:45.960]  necessarily mean anything. So I think it's best to define this file. And let's start with what
[03:45.960 --> 03:51.160]  is an ICS engineering software. So basically, here are a few just a few screenshots of very
[03:51.160 --> 03:57.020]  common engineering software that we might encounter. And basically, when I say ICS project file,
[03:57.020 --> 04:03.560]  what I mean is how this engineering software saves its information. So for example, if you work on
[04:04.180 --> 04:09.900]  configuring a PLC using the B&R Automation Studio we see here, then the engineer would want at some
[04:09.900 --> 04:15.660]  point to save all the work they've done, so that later on they can use it or they can reopen it,
[04:15.660 --> 04:20.780]  they can edit it or anything like that. An ICS project file would be a file, a directory,
[04:20.780 --> 04:25.920]  anything, an entity in which all this information is saved. So when I say ICS project file, it doesn't
[04:25.920 --> 04:33.080]  necessarily mean just one specific file. It means the logical entity in which the ICS software saves
[04:33.080 --> 04:39.000]  all its information. And when that is the definition, you can start thinking and translating
[04:39.000 --> 04:44.400]  it into the information that we expect to find in these project files. Because I want to convince
[04:44.400 --> 04:48.780]  you that these project files are interesting. Don't forget, we came into this challenge trying to
[04:48.780 --> 04:54.560]  improve our capability to understand networks by looking at these project files. So let's think
[04:54.560 --> 05:00.340]  what information we expect to find in these project files. And obviously, we'll start from the
[05:00.340 --> 05:08.780]  topmost layer. And I think it makes sense that a project file that describes a plant or a
[05:08.780 --> 05:13.660]  manufacturing site or anything like that would have to contain the network layout. So from the
[05:13.660 --> 05:18.700]  topmost layer, we will see the network layout. As you can see here, some screenshots from the
[05:18.700 --> 05:24.400]  Step 7 engineering station by Siemens or from Rockwell's engineering software. You can see that
[05:24.400 --> 05:30.320]  it holds a list of assets in the network. So for example, here we have a profit bus
[05:30.320 --> 05:35.860]  with a few S7-400 stations. And we can use this file to identify that we have
[05:36.520 --> 05:42.380]  four stations along this bus and understand what they are and where they are. Next, let's dive
[05:42.380 --> 05:47.400]  into these stations because this project file has to contain information about the specific assets
[05:47.400 --> 05:53.120]  within the network. And so looking at the specific asset, you can see just a few more
[05:53.120 --> 05:59.460]  screenshots here describing how we may identify all the different slots on the device.
[05:59.460 --> 06:04.920]  So as you can see here, again, a snapshot from Siemens's software showing the exact slots and
[06:04.920 --> 06:09.380]  the model and the order number and the firmware for every slot, which is very interesting information.
[06:09.380 --> 06:15.320]  We can see that it also has, for example, here from BNR, you can also see the serial information,
[06:15.320 --> 06:21.100]  the serial number, or the network addresses. So the information about the hardware of
[06:21.100 --> 06:26.360]  every device in the network is very interesting and exists in these project files.
[06:26.900 --> 06:32.840]  But we can also dive even deeper because these engineering software obviously are used to
[06:32.840 --> 06:38.440]  engineer. And so programming the logic on these devices happens through these softwares and we
[06:38.440 --> 06:43.500]  would expect it to be saved within these project files. And indeed, diving into one specific device,
[06:43.500 --> 06:49.220]  looking into the guts of what is saved in this project file would be the actual logic.
[06:49.220 --> 06:52.920]  So again, a few screenshots here, but you can see that these project files will contain the block
[06:52.920 --> 06:59.040]  diagram, the ladder diagram, whatever type of logic we configured, we expect these project
[06:59.040 --> 07:05.760]  files to contain it. So that's going from the topmost layer of the network
[07:05.760 --> 07:12.500]  to the internals of a specific PLC, the actual logic that every PLC is running.
[07:12.560 --> 07:18.160]  And so I think hopefully that shows you that these project files are useful. They are able to provide
[07:18.160 --> 07:24.220]  us with a full inventory of assets, their details, their models, their firmwares, whatever, and of course
[07:24.220 --> 07:30.760]  also their logic, which is great for us and great for the engineer to use as backup,
[07:30.760 --> 07:37.260]  which is nice. They're also very easy to collect. The advantage with looking into project files,
[07:37.260 --> 07:43.060]  and here again, think of me as a person wanting to improve the visibility into the network,
[07:43.060 --> 07:48.480]  one alternative for me could be, for example, to just capture traffic from the network and try to
[07:48.480 --> 07:52.660]  map the network from this traffic. But capturing traffic requires a lot of work. It requires
[07:52.660 --> 07:57.860]  configuring expand ports, it requires waiting for interesting traffic to come, whereas looking into
[07:57.860 --> 08:01.740]  project files, all it means is that I have to access the file on the engineer's computer or on
[08:01.740 --> 08:06.180]  the backup server, because an engineer would probably use some kind of backup server that will
[08:06.180 --> 08:10.380]  hold all these project files in one place, so I don't have to look far. And I have these files
[08:10.380 --> 08:15.860]  at the palm of my hands without having to work too hard. And once I do have these files, all I
[08:15.860 --> 08:20.700]  have to do is just write some kind of script that knows how the file is built,
[08:20.700 --> 08:26.580]  and we'll get to it in a few minutes. And once I've done that, I can, within seconds, determine exactly
[08:26.580 --> 08:33.220]  all those details that I could, that I showed you just a second ago, starting from the network
[08:33.220 --> 08:38.400]  and going down to the actual logic. So that's very great, and that allows us to collect a lot of
[08:38.400 --> 08:44.520]  information within a second. But the next question should be, why do I care about this information? So
[08:44.520 --> 08:49.620]  why did we, why do we mind about the network or about the model information?
[08:50.230 --> 08:57.720]  And my claim is that the first step in securing an OT network would be this type of visibility,
[08:57.720 --> 09:02.760]  not only in securing, also in promising the continuous operation of such a network. But
[09:02.760 --> 09:08.440]  obviously, my perspective and Defcon's perspective is the security side. So let's start with network.
[09:08.440 --> 09:13.380]  Obviously, mapping the network is critical to understanding that any new devices connected
[09:13.380 --> 09:18.200]  to the network could be a malicious actor who connected to the network. And obviously,
[09:18.200 --> 09:22.960]  on the other side, identifying that a device is missing from the network, could be something
[09:22.960 --> 09:28.020]  happened to a device. And so we need to have this full picture before we start diving into the
[09:28.020 --> 09:34.860]  network to identify any changes that might have happened. Next, it also helps us to identify the
[09:34.860 --> 09:39.660]  roles of assets within the network, because if I have this project file, I can identify that every
[09:39.660 --> 09:45.420]  PLC has a specific responsibility. And so this PLC is part, is in charge of this part of the
[09:45.420 --> 09:52.820]  process line. And this PLC is in charge of that part. And so when anything we don't expect happens,
[09:52.820 --> 09:59.560]  I will be able to quickly identify what is the root cause of that. And also, it will help me
[09:59.560 --> 10:05.740]  manage these PLCs and assign people in charge for them, for example, and more. Next, we will have
[10:05.740 --> 10:10.900]  the detailed inventory. Because as you could see before, we also have the model, we also have the
[10:10.900 --> 10:16.300]  firmware version, and that's great for an engineer or for a security person to assess their security
[10:16.300 --> 10:22.260]  posture. Because when you know how many devices you have of each model, and what firmware they're
[10:22.260 --> 10:28.000]  using, you're able to identify very quickly how vulnerable you are to a new vulnerability that
[10:28.000 --> 10:32.760]  might have been published, how deep is your backlog in terms of firmware upgrades you need
[10:32.760 --> 10:40.380]  to perform on your devices, because you don't want to be too old or too vulnerable. So having this
[10:40.940 --> 10:47.100]  detailed inventory allows you to know where you're standing and keep yourself up to date with
[10:47.100 --> 10:54.540]  any new releases by vendors, for example. And lastly, when something does happen, it might be
[10:55.160 --> 11:00.200]  a security event, it might be an operational event. But when something does happen,
[11:00.200 --> 11:05.800]  if you do have a snapshot of where the plant was or where the site was yesterday, it's a lot easier
[11:05.800 --> 11:11.460]  to identify what has changed and what might be the root cause of the issue today. And also it's a
[11:11.460 --> 11:16.720]  lot easier to start everything up again tomorrow, because you know exactly where you are. You can
[11:16.720 --> 11:22.560]  use the configuration files, the ICS project files, to reconstruct everything very quickly.
[11:22.560 --> 11:28.500]  So you can also identify the cause of the issue and start again, which is great in terms of incident
[11:28.500 --> 11:35.920]  response in the OT industry where downtime is critical. So hopefully, I convinced you that
[11:36.580 --> 11:41.220]  that this information is critical, that ICS project files hold interesting information and
[11:41.220 --> 11:46.060]  that this information is important. One side note that is not the main issue that we speak about
[11:46.060 --> 11:52.080]  in this presentation, it has been spoken of in previous presentations, but one side note is
[11:52.080 --> 11:56.740]  seeing how these project files contain such valuable information also means that they may
[11:56.740 --> 12:01.700]  be used by malicious actors themselves. Because a malicious actor trying to plan an attack on
[12:01.700 --> 12:08.340]  an OT facility may use this information in the project files to plan their attack better, to
[12:08.340 --> 12:15.720]  identify vulnerable devices, to map tags on specific devices that affecting them would affect the
[12:15.720 --> 12:21.480]  the operation of the plant. And so these project files are very interesting from a security
[12:21.480 --> 12:27.940]  perspective, both from an operational perspective, both to the OT engineer, but also to the
[12:28.600 --> 12:35.220]  hacker doing the recon at this stage. So that's just a side note that these project files need
[12:35.220 --> 12:40.960]  to be saved. I know that a lot of people like saving their ICS project files on a Dropbox
[12:40.960 --> 12:47.060]  folders, etc. That's something to think of and making sure that these shared directories are
[12:47.060 --> 12:56.360]  secure. So ICS project files at this point, and hopefully if I convinced you that the
[12:56.360 --> 13:01.440]  thought process that we had convinced you, ICS project files are great. It's a super easy way
[13:01.440 --> 13:06.180]  to get tons of information that we want, which is very nice from Clarity's perspective or
[13:06.180 --> 13:11.500]  from my perspective, because the things I had to do to get all the model information of
[13:11.500 --> 13:15.480]  all the devices in the network before were a lot more complex. And now all I have to do is
[13:15.480 --> 13:20.800]  understand how a project file is built, and have the engineer provide me with the project file,
[13:20.800 --> 13:25.820]  and I'm able to produce all the information. So that sounds super easy and super great.
[13:25.820 --> 13:31.960]  But is it really? So I think this question builds up to what an ICS project file really looks like.
[13:31.960 --> 13:38.200]  We only discussed what ICS project files are in theory. But let's talk about what an ICS
[13:38.200 --> 13:43.360]  project file really looks like. What does it mean when I say ICS project file?
[13:44.300 --> 13:51.160]  Sorry, so the most basic use case would be just a text file. You may go to the
[13:51.160 --> 13:56.080]  software, you may click export on the software, and what you get is just an Excel file that
[13:56.080 --> 14:01.880]  my grandma can open with her office that we just recently installed for her, and understand
[14:01.880 --> 14:06.980]  everything in the network. So you can see that the IP addresses of the devices, the models of
[14:06.980 --> 14:12.500]  the devices, the versions, which is very nice, very easy, very useful, and that's great stuff. It's not
[14:12.500 --> 14:16.900]  very good for me as a researcher because then my boss will fire me if all files look like that,
[14:16.900 --> 14:22.940]  but it's great for my grandma and for the common engineer trying to understand the network format.
[14:23.540 --> 14:30.440]  And obviously, we have many formats, different formats of ICS textual project file. So another
[14:30.440 --> 14:35.880]  example for a project file by one of Rockwell's softwares, and as you can see here, an XML,
[14:35.880 --> 14:41.420]  which is also nice and very script friendly. If you want to write a script that will pass this
[14:41.420 --> 14:45.980]  information, you can see very easily that you can see the name of the bus, you can see the type of
[14:45.980 --> 14:52.520]  the network, you can see the host name of the devices. So for ICS project files being textual,
[14:53.080 --> 14:58.800]  it's really great, and we have everything we need for that. But that's not always the case. Sometimes,
[14:58.800 --> 15:03.840]  and for example, here, this is an ACB file. It's a file generated by the AliceLogix 5000,
[15:03.840 --> 15:09.340]  the Rockwell software. You can see that while it starts as a textual file, and you might think that
[15:09.340 --> 15:16.640]  your day is a good day, within a few lines, this becomes something that is clearly not English.
[15:16.640 --> 15:21.420]  And indeed, this file is most of the information within it, and all of the interesting information
[15:21.420 --> 15:26.380]  is saved in some kind of binary format. And so in this case, my grandma would probably call me and
[15:26.380 --> 15:31.220]  ask for help. And this help will not be easy. You have to try and understand what this project file
[15:31.220 --> 15:37.540]  looks like. You have maybe to reverse engineer the program, maybe to black box and understand,
[15:37.540 --> 15:41.680]  to do some black box research and understand how this project file is built. And indeed,
[15:41.680 --> 15:46.320]  that's what we have to do when we encounter such files. And you see that the Rockwell ACB file
[15:46.320 --> 15:54.460]  is not the only case. This is an example for a Siemens device, a file outputted by the Dixie5
[15:54.460 --> 16:00.720]  software, and another example by another Rockwell software, an older version of the AliceLogix.
[16:00.720 --> 16:06.280]  So binary formats are very common as well. And in terms of research and understanding how they
[16:06.280 --> 16:12.260]  are built, you have to work a lot harder for that. Still, not only do we have binary formats
[16:12.260 --> 16:16.300]  or textual formats, we also have the cases where a project file is not really a file.
[16:16.300 --> 16:21.720]  It might be a directory. This is, for example, the project file that is generated by the Siemens
[16:23.000 --> 16:27.040]  Step7 software. And as you can see, it's just a directory containing a lot of subdirectories,
[16:27.040 --> 16:31.020]  containing a lot of other subdirectories, containing a lot of binary files. And so the
[16:31.020 --> 16:35.320]  project file here, the challenge of understanding where the information is, is not only understanding
[16:35.320 --> 16:39.880]  what the binary format is, it's also understanding where the file is. And in this case, we just see
[16:40.020 --> 16:45.560]  a few tens of project files. But as you can see here in this one of Mitsubishi's
[16:45.560 --> 16:51.120]  softwares, you can see that we got a directory that's about 7,000 files. So you have a lot of
[16:51.120 --> 16:57.220]  sifting through the files to do before you can start working for reals. And obviously,
[16:57.220 --> 17:01.200]  sometimes these archives may not be just a zip archive or just a plain directory,
[17:01.200 --> 17:06.040]  it may be a cub file. And I don't know how many of you are familiar with cub archives,
[17:06.040 --> 17:11.460]  they're a very old format. And what is today has been replaced by zip. And just finding a
[17:11.460 --> 17:18.980]  Python library to un-cub a cub archive is a challenge of itself, even though this format is
[17:19.500 --> 17:24.160]  publicly available and everything. Just finding a script to un-cub the file was a challenge of
[17:24.160 --> 17:30.100]  itself. But obviously, when it comes to directories, most of the files we need are zipped. And
[17:30.100 --> 17:35.360]  obviously, a zip is just an archive that contains a directory. And what the software does is take
[17:35.360 --> 17:41.000]  the whole directory containing all the information of the project and zip it into a single file.
[17:41.000 --> 17:45.620]  And as we'll see in a minute, this file may be saved with a different file extension. So it
[17:45.620 --> 17:51.800]  won't be .zip, it may be .something else. But if you just open it and check, you will see that
[17:51.800 --> 17:56.680]  actually, in fact, that's a zip file containing a lot of other types of files. And we'll go into
[17:56.680 --> 18:04.620]  that in just a second when we show an example. So just to recap, project files provide great
[18:04.620 --> 18:10.440]  information, and they come in many, many, many shapes and sizes. And so we have to work sometimes
[18:10.440 --> 18:17.080]  very hard to collect this information. So let's just see just one example, another screenshot of
[18:17.080 --> 18:24.900]  the file. This file was generated by Crimson, software by RedLion, to program HMIs. And as
[18:24.900 --> 18:31.200]  you can see, this file, while it's binary and not very readable for the common user, but you can
[18:31.200 --> 18:35.240]  see just by looking at it that it does hold some interesting information. For example, if you look
[18:35.240 --> 18:40.200]  here, you can see the model G306. And obviously, when we know that this file was used to configure
[18:40.200 --> 18:45.880]  G306, then we can identify that this field shows the model. We still have to work into understanding
[18:46.720 --> 18:51.840]  what... how do I get to this model? What means... how do I extract the model from this file?
[18:51.840 --> 18:56.800]  But we see that it has a model. We can also see that there are some numbers here, not sure what
[18:56.800 --> 19:02.860]  they mean. We have the string major, which might be a part of the major firmware version or
[19:02.860 --> 19:07.860]  anything like that. And so the research team would have to do a lot of digging and some reverse
[19:07.860 --> 19:14.480]  engineering into understanding what this Crimson file looks like. And the objective is
[19:14.480 --> 19:18.860]  to turn this file into something that's human readable. So for example, here, as you can see,
[19:18.860 --> 19:24.640]  what we were able to extract from this file is indeed the module and also the IP address. And
[19:24.640 --> 19:29.180]  obviously, I can't see, at least with a glance, I can't see the IP address here, but it took some
[19:29.180 --> 19:33.040]  work and some reverse engineering of the software to understand where this IP address is located
[19:33.040 --> 19:38.960]  within the file. And we could also identify that this is indeed an HMI and identify the exact
[19:38.960 --> 19:44.100]  version of the Redline Crimson software that was used to generate this file. In this case,
[19:44.100 --> 19:50.520]  these files are compressed. So it's one compression method that is pretty specific
[19:50.960 --> 19:55.240]  that was used to save all this information. Once they were uncompressed, we could start and
[19:55.240 --> 20:04.580]  identify exactly the interesting fields within this file. So that's one example. Let's think of
[20:04.580 --> 20:10.720]  another example for a project file. And let's have a look at the way the Siemens Step 7
[20:10.720 --> 20:15.460]  saves its files. And as I mentioned before, basically, it's a directory. And so when you
[20:15.460 --> 20:21.060]  export from the Siemens Step 7, you get a directory, which usually you will zip. And what
[20:21.060 --> 20:25.980]  we get from our customers would be just a zipped file. And this zip extracts into this directory
[20:25.980 --> 20:31.120]  containing many files, as you could see before. And looking into these files, what we identified
[20:31.120 --> 20:35.780]  when we tried to find the interesting information is that one of the subdirectories within the SDB
[20:35.780 --> 20:40.700]  subdirectory is the interesting subdirectory. But that contained a lot of files with the names
[20:40.700 --> 20:47.380]  very informative names, 000a1.pg. So obviously, no file here is called,
[20:47.380 --> 20:52.360]  I am the interesting file or model and firmware file or anything like that, but rather
[20:53.400 --> 20:58.380]  these internal names. And so looking into these files, we identified that one of these files
[20:58.380 --> 21:03.360]  contained the interesting information. And just by opening it, you can see, again, some interesting
[21:03.360 --> 21:08.500]  strings hidden within this binary file. So you can see the order number again, you can see the model
[21:08.500 --> 21:16.740]  here. And so now we've discovered what the file was, what interesting file, what is the interesting
[21:16.740 --> 21:22.180]  file within this directory, we would still have to do a lot of reverse engineering to understand
[21:22.180 --> 21:28.920]  how to extract this information from that. And that basically is the job that we do. We commit
[21:28.920 --> 21:33.620]  to being able to understand the project file to extract all this information that we deem
[21:33.620 --> 21:39.420]  interesting in this project file. And when we get a new project file, a new format, a new
[21:39.420 --> 21:44.960]  requirement from a customer, what we will do is we will try to understand how this software works,
[21:44.960 --> 21:53.260]  same as we will do for a protocol, same as we will do for any type of such request. So just let's do
[21:53.380 --> 21:58.500]  a quick overview of what we see in these project files that we look into. And I think the most
[21:58.500 --> 22:05.420]  common thing that is found in all or in a great percentage of project files in the world, no matter
[22:05.420 --> 22:10.020]  the vendor, no matter the software, is a zip archive. Because usually these projects will
[22:10.020 --> 22:15.420]  contain a lot of different files. For example, one file will contain the hardware configuration,
[22:15.420 --> 22:21.400]  one file will contain the logic, one file will contain the list of assets, etc. And the project
[22:21.400 --> 22:29.640]  file is simply a zip directory containing all these files. Looking into this project file,
[22:29.640 --> 22:35.400]  and once we've unzipped this project file, we see a lot of files. And what we'll usually see,
[22:35.400 --> 22:41.060]  and what is very common in these files, is first OLE files. OLE is a format used by older
[22:41.060 --> 22:45.700]  Office documents, so it's a format by Microsoft. And it's a very convenient format for developers
[22:45.700 --> 22:50.240]  to hold a lot of binary information in different streams. So it's very convenient, and we see it
[22:50.240 --> 22:57.300]  in use a lot in ICS software. Next, we will see a lot of database files. And this makes sense
[22:57.300 --> 23:00.840]  when you come to think of it, because these project files need to contain a lot of information
[23:00.840 --> 23:05.640]  per every device. For example, you will need to contain the firmware, the model, the IP address,
[23:05.640 --> 23:10.960]  etc., etc. And so it makes sense to save it in a database format. And so we see SQL databases,
[23:10.960 --> 23:16.200]  MSSQL databases, a lot of database formats. One of these formats, just as a side note,
[23:16.200 --> 23:22.120]  is the Access database, another format by Microsoft that was used by Access. And that's,
[23:22.120 --> 23:28.420]  again, a very old format. And actually, so again, finding a Python library to access
[23:28.420 --> 23:33.540]  such a database, we couldn't do it. We simply couldn't find a Python-native library
[23:33.540 --> 23:40.300]  that could access the Access database. And so just a few weeks ago, we published our
[23:40.300 --> 23:47.060]  open-source Python library to interpret Access databases, which is nice. Now you can do it just
[23:47.060 --> 23:53.100]  by inputting in Python. Next, we will also see a lot of proprietary binary format. As I mentioned
[23:53.100 --> 23:58.100]  before, no one forces the vendor to work with a specific database or anything like that. So the
[23:58.100 --> 24:03.700]  vendor might decide that they want to save the information in their own proprietary format.
[24:04.160 --> 24:08.740]  And they will design this format. They will write the code to access this format and to
[24:08.740 --> 24:13.440]  parse this format, the information in there, and to obviously to save the information into this
[24:13.440 --> 24:18.440]  file. And so we see a lot of proprietary binary formats. Lastly, as I mentioned before,
[24:18.440 --> 24:22.520]  if you're really lucky from an engineer's perspective, if you're really lucky,
[24:22.520 --> 24:26.880]  you will get a text file you can open and just review the text file and understand everything.
[24:26.880 --> 24:30.420]  Obviously, from the researcher's perspective, it's less fun, because all you have to do is
[24:30.420 --> 24:36.120]  open the text file. But in my perspective, still, this is a very convenient and a very good way
[24:36.120 --> 24:44.160]  to save the information. So all that means that if we take a look back at what we discussed
[24:44.160 --> 24:48.880]  so far about what project files do, what information they contain, how they are built,
[24:48.880 --> 24:54.260]  then we can think of a few traits that are occurring. First is we see a lot of binary
[24:54.260 --> 24:58.980]  formats that are developed internally. And as I mentioned just a second ago,
[24:58.980 --> 25:03.340]  this is because the vendors will develop their own code and they will do that by themselves.
[25:04.100 --> 25:09.240]  Next, we will see that if the format is proprietary or if it's public or if it's a
[25:09.240 --> 25:14.220]  database or anything like that, still, a complex parsing is required in order to extract the
[25:14.220 --> 25:18.280]  information from this file or to save the information to this file. Because we're talking
[25:19.020 --> 25:23.720]  about a very big amount of information in various types. You sometimes want to save the IP address,
[25:23.720 --> 25:28.160]  you sometimes want to save the compiled logic. So various types. And obviously,
[25:28.160 --> 25:35.320]  it will require some complex parsing work. Lastly, it will hold some proprietary information.
[25:35.320 --> 25:39.480]  Every vendor will save their own information. Every vendor will design the file as they wish to
[25:40.000 --> 25:45.020]  save the information that they were looking for. So we will see a lot of proprietary information
[25:45.020 --> 25:50.140]  in proprietary formats that will be complex. And thinking of all these three traits,
[25:50.140 --> 25:54.720]  it sounds quite familiar, or at least to a researcher working in the ICS domain,
[25:54.720 --> 25:59.440]  sounds quite familiar. It sounds quite familiar because these traits are very common in ICS
[25:59.440 --> 26:07.740]  protocols as well. And so when we had reviewed enough ICS project files to extract the information
[26:07.740 --> 26:12.680]  from them, and at some point we had a nice collection of ICS project files formats that
[26:12.680 --> 26:18.040]  we support and understand, we started to think ICS protocols. And the next thought, as a security
[26:18.040 --> 26:22.400]  researcher, when you think of ICS protocols, the next thought is oil. And the reason for that is
[26:22.400 --> 26:28.040]  that vulnerabilities in ICS protocols exist, and exist a lot. And they are published weekly,
[26:28.040 --> 26:32.860]  and these devices are very vulnerable. And the reason for that is that this code was usually
[26:32.860 --> 26:38.260]  developed with no security in mind. And so when you're thinking of something that is comparable
[26:38.260 --> 26:44.720]  to ICS protocols, your next thought would be, let's check how secure this may be. And indeed,
[26:44.720 --> 26:51.240]  just a quick Google of ICS project file vulnerabilities showed us that not very.
[26:51.240 --> 26:55.700]  The answer is not very. And so just a quick Google, and you can see a lot of vulnerabilities
[26:55.700 --> 27:03.800]  that have been published in recent years. And just a quick lookup in the ICS self-website,
[27:03.800 --> 27:10.120]  for example, for Advisor is published recently. You can see here one type of vulnerability that's
[27:10.120 --> 27:15.840]  an SQL injection. Another is a use-after-free. Another is a stack buffer overflow. And so
[27:15.840 --> 27:20.360]  vulnerabilities are constantly published on these devices. And all these vulnerabilities, as you can
[27:20.360 --> 27:29.340]  see, are relevant to the ICS project files. 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:38.480]  So just a quick example for that, we can have a look at the vulnerability that was published in
[27:38.480 --> 27:45.620]  2016, just four years ago. And this vulnerability, and I put here the CV, is crashing the engineering
[27:45.620 --> 27:49.860]  software with a malicious project. This means that if the engineer would double-click on a
[27:49.860 --> 27:55.160]  malicious project, the engineering software would crash. And that vulnerability got, at the time,
[27:55.240 --> 28:00.880]  a CVSS score of 4.2, which is a low CVSS score. And not only that, the Advisor contains this,
[28:00.880 --> 28:05.140]  some kind of disclaimer sentence saying these vulnerabilities are not exploitable remotely
[28:06.000 --> 28:10.980]  and cannot be exploited without user interaction. So that's some kind of disclaimer saying,
[28:10.980 --> 28:15.140]  yes, this is a vulnerability, but no, it's not very, very interesting, or at least not
[28:15.140 --> 28:19.020]  at this time. And the reason I'm saying at this time is because we can look at the same
[28:19.020 --> 28:23.700]  vulnerability or similar vulnerability published in 2019. Again, a vulnerability that means that
[28:23.700 --> 28:29.280]  when you open a project file, when you double-click a project file, the engineering station,
[28:29.280 --> 28:35.340]  the engineering software would crash. 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:46.180]  And no disclaimer in this case at all. So there is some kind of growing understanding that these
[28:46.180 --> 28:51.780]  vulnerabilities, while they are not as sexy as protocol vulnerabilities, they are not as accessible
[28:51.780 --> 28:57.300]  as network vulnerabilities, they are interesting and they are dangerous. Another example for the
[28:57.300 --> 29:02.260]  growing security focus is the Pwn2Own competition that was held in Miami this year. So Pwn2Own
[29:02.260 --> 29:09.380]  is an organization of competitions that invite hackers to compete on finding specific
[29:09.380 --> 29:17.000]  vulnerabilities in specific devices. For example, find a remote code execution in a Tesla car.
[29:17.000 --> 29:21.860]  If you do, you get a lot of money for that. And so the first Pwn2Own competition that was targeted
[29:22.600 --> 29:28.720]  on ICS products was held just in the beginning of this year, and it had five categories,
[29:28.720 --> 29:36.380]  and one of which was finding vulnerabilities in ICS project files. And so even an organization
[29:36.380 --> 29:42.480]  like that, which is very oriented towards security and very up-to-date in terms of understanding the
[29:42.480 --> 29:49.280]  security world, sets one of the categories in the competition as vulnerabilities in ICS project files.
[29:49.280 --> 29:53.840]  And not only that, the winner in this category would win $20,000. So the motivation is
[29:54.360 --> 30:03.750]  not only interest, but also gaining a lot of money. And by the way, there was a winner in
[30:03.750 --> 30:11.530]  this category. Someone collected this prize, and this category also held a product by Schneider as well,
[30:11.530 --> 30:17.830]  which we also collected the prize for. So I think at this point, what we can say
[30:18.470 --> 30:21.950]  is that project files are great for asset management. They are very interesting. The
[30:21.950 --> 30:28.170]  information they hold are very interesting and valuable to an engineer and to the security
[30:28.710 --> 30:34.470]  of this network. They're also great for researchers' employment. And what do I mean by that?
[30:34.470 --> 30:40.490]  My job is based on the fact that these project files are complex. If anyone could just open a
[30:40.490 --> 30:46.570]  project file and extract the data from it, my day would be a lot less interesting. And so they're
[30:46.570 --> 30:53.170]  great for me. But also, they might be great for an attacker, not only for recon purposes, for mapping
[30:53.170 --> 30:57.890]  the network, as we mentioned before, but also because they are vulnerable. And what I would
[30:57.890 --> 31:03.090]  want to show you is that they're vulnerable, not just in theory. So we saw that there were
[31:03.090 --> 31:09.690]  vulnerabilities published. But let's do a quick overview of these parts that we saw before,
[31:09.690 --> 31:15.150]  that comprise a common ICS project file. And as you can remember, we discussed the zip file,
[31:15.150 --> 31:19.550]  we discussed OLE files, etc. And let's take it step by step. And I will show you that
[31:19.550 --> 31:25.470]  just in the recent months, vulnerabilities have been published for every part of this project file.
[31:26.330 --> 31:32.650]  So let's think of it step by step. And we started off with a zip. And what I wanted to show for
[31:32.650 --> 31:39.370]  zip files is the very common zip slip vulnerability. And so what this actually means is there is no
[31:39.370 --> 31:44.770]  sanitation on zip paths. But let's explain what this means in a more technical way. So let's have
[31:44.870 --> 31:50.310]  a look at what the header of the zip file looks like. So take it in for a second, I'll have a drink.
[31:54.060 --> 32:00.440]  Okay, great. So as you can see, as you can see, a zip file holds a lot of different files within
[32:00.440 --> 32:04.900]  it, right? When you double click a zip file, it extracts into multiple files and multiple
[32:04.900 --> 32:12.480]  directories. And the way that the file is saved for real, in its binary data, is that its header
[32:12.480 --> 32:17.440]  contains the list of files to which we need to extract the information. So for example, this file
[32:18.140 --> 32:23.940]  will extract information to a directory called example-slash-uex. And another file will be
[32:23.940 --> 32:32.900]  extracted to example-slash-file1.txt. And another file will be extracted to example-slash-filewithalongname.sql.
[32:32.900 --> 32:36.260]  So when you double click this file, you will get a new directory called example, and within it,
[32:36.260 --> 32:43.000]  you will get three files. And that makes sense. And that's just how the zip file header works.
[32:43.000 --> 32:49.740]  But this also means that if not properly handled, an attacker may use these attributes
[32:49.740 --> 32:55.380]  of a zip file. And how they may use it? They may employ the special characters that allow
[32:55.380 --> 33:02.420]  directory traversal. Because this slash dot dot slash means go up one directory. And so instead
[33:02.420 --> 33:08.120]  of saving the file within the example directory, this will cause the software that extracts this
[33:08.120 --> 33:17.240]  file to save this file somewhere outside of the targeted directory. And so we may write files
[33:17.240 --> 33:22.300]  basically to any location we want on the computer on which this file is extracted. And this is a
[33:22.300 --> 33:28.680]  very common vulnerability. It has been known for years. It has been handled in many products.
[33:28.680 --> 33:34.600]  But what we see in the ICS domain, unfortunately still, is that some products still do not
[33:34.600 --> 33:38.880]  sanitize the paths and do not make sure that there is no use of these characters and allow
[33:38.880 --> 33:44.200]  an attacker to employ this vulnerability and save files basically to any location they want
[33:44.200 --> 33:50.040]  on the target computer. And saving files on any location sometimes would directly mean
[33:50.040 --> 33:54.080]  being able to take control of the computer, because you may override some files. You may
[33:54.080 --> 33:58.660]  save files, for example, like we did here. And you may save files to the startup directory and
[33:58.660 --> 34:04.700]  save in the store.exe. And that's obviously not something we want. So that's just a very, very
[34:04.700 --> 34:11.340]  basic vulnerability in zip files that is still very, very common and may happen if the product
[34:11.340 --> 34:18.280]  does not make sure that the paths within the zip file header are valid. So that's zip files.
[34:18.280 --> 34:23.240]  But let's take a step in and I'll just show a couple of vulnerabilities that were published
[34:23.240 --> 34:30.600]  just in the recent months in these exact things. This path reversal CWE means exactly that,
[34:30.600 --> 34:37.100]  means that someone could use this attribute. And as you can see here, just in the past,
[34:37.100 --> 34:42.800]  during the past year, several vulnerabilities have been published in this exact method.
[34:42.800 --> 34:47.260]  So that's a zip file. Now let's have a look at the OLE files that we mentioned that are very
[34:47.260 --> 34:52.520]  common within zip files. And here I will not go into a lot of details, but as I mentioned before,
[34:52.520 --> 34:59.100]  OLE files are the files used by office products and, sorry, old office products. And old office
[34:59.100 --> 35:04.800]  products, we all know that have been vulnerable for years, right? You would not open an email
[35:04.800 --> 35:11.060]  saying, hey, please download and open this world document I sent you from someone you don't know,
[35:11.060 --> 35:15.100]  because you know that this could be dangerous. And still, a document from the FBI showed that
[35:15.100 --> 35:21.580]  the most common used vulnerabilities still today in 2020 are, I think, five of the 10 most common
[35:21.580 --> 35:29.540]  used vulnerabilities in real life are still vulnerabilities in office files. And so OLE
[35:29.540 --> 35:34.840]  files, vulnerable. It doesn't matter if you wrap it with Office or wrap it with an ICS engineering
[35:34.840 --> 35:40.220]  software. They are vulnerable. That's OLE files. Next, let's discuss databases.
[35:42.140 --> 35:46.540]  And when you think of database and you're a security researcher, the next thing that comes
[35:46.540 --> 35:52.180]  to your mind is SQL injection. That's, again, a very, very common vulnerability in the handling
[35:52.180 --> 36:00.440]  of SQL queries when working with databases. And it's very common in the world, and specifically
[36:00.440 --> 36:06.500]  in ICS software. It still exists. It may exist if the software uses a database to save its
[36:06.500 --> 36:13.460]  information. So let's take just one example for a vulnerability that was discovered as part of
[36:13.460 --> 36:21.220]  the Pwn2Own competition by Uri from my team. And what... sorry, by Amir and Sharon from my team.
[36:21.240 --> 36:27.640]  And what they discovered was that one of these products saves this information within a
[36:27.640 --> 36:33.540]  database. And if you save... and this database holds the version in which the information was saved.
[36:33.540 --> 36:39.200]  So if you change the version field to a lower version, then when the software opens this
[36:39.200 --> 36:46.940]  database, it will run some migration scripts on the file. And what we found was
[36:46.940 --> 36:54.320]  that you could use one type of SQL injection in these parts and create a full remote code
[36:54.320 --> 37:00.000]  execution just based on an SQL injection in the database. And what it looks like is, as you can
[37:00.000 --> 37:04.180]  see, the engineer would double-click the project file, the engineering software would open, and within a second
[37:05.940 --> 37:11.560]  we will see a notepad pop up. And in this case, notepad, but in a malicious case, it will not be notepad.
[37:11.560 --> 37:17.900]  It will be some kind of software that might cause damage. So that's databases. Let's go on to binary
[37:17.900 --> 37:23.000]  formats. And obviously, binary formats are risky because they mean that someone had to write a lot
[37:23.000 --> 37:29.720]  of code. Someone had to design a format that would be secure enough. And all this work
[37:29.720 --> 37:36.860]  has been done usually years ago when no one was security-oriented. And so vulnerabilities
[37:36.860 --> 37:41.980]  in binary formats exist and exist a lot, and we see a lot of them published
[37:42.960 --> 37:48.640]  on a monthly basis. And so I won't go into details in this case because simply you
[37:48.640 --> 37:52.340]  can understand that the complexity of a binary format means that many vulnerabilities may be found
[37:52.340 --> 37:59.120]  within that. For example, just one example here, this article by Ed Kovacs from Security Week
[37:59.120 --> 38:05.180]  is reviewing a vulnerability published in the Red Lion HMI files that we saw before. So those
[38:05.180 --> 38:10.300]  compressed files and those Crimson compressed files we saw before, we saw earlier, are vulnerable
[38:10.300 --> 38:18.280]  to some vulnerabilities that were discovered by security researchers and were published before.
[38:18.700 --> 38:22.900]  So that's binary formats. Lastly, we said that if you're really lucky,
[38:22.900 --> 38:28.020]  you would have a text file. And one might think that a text file, how hard can it be?
[38:28.020 --> 38:34.220]  What can be vulnerable within a text file? And still a vulnerability published by Uri from my
[38:34.220 --> 38:39.720]  team just a few months ago in one of Siemens's products showed that the parsing of a textual
[38:39.720 --> 38:45.740]  file within the software may have caused a remote code execution. So again, if you would double
[38:45.740 --> 38:53.420]  click the project file, code would be executed. And that's even though this file was just a
[38:53.420 --> 38:59.900]  textual format, the bug was obviously in the parsing of this file. So what we could see is
[38:59.900 --> 39:06.080]  that taking apart the common ICS project file, you can understand that every part of it may be
[39:06.080 --> 39:10.020]  vulnerable. And basically what I want to convince you is these vulnerabilities may exist, they're
[39:10.020 --> 39:15.280]  not something that is out of the ordinary. So let's take one type of project files, and this
[39:15.280 --> 39:21.500]  would be a project file used by Phoenix Contact software PLCnext. And let's see exactly how this
[39:21.500 --> 39:27.200]  vulnerability works, just so we can get a hang of how this vulnerability works. And so this
[39:27.200 --> 39:35.800]  vulnerability was discovered by Amir from my team, and this vulnerability allows
[39:35.800 --> 39:43.240]  remote code execution when a project is opened in the PLCnext software by Phoenix Contact.
[39:43.520 --> 39:48.360]  Let's understand how it works. So first of all, this is the software. This is just a screenshot
[39:48.360 --> 39:52.440]  of the software. As you can see, it holds some information. It shows all the information about
[39:52.440 --> 39:57.600]  the HMI, the PLC, etc. And this is just how the software looks like. But let's see how the
[39:57.600 --> 40:04.040]  information is saved behind the scenes. And indeed, in this case, the information is saved in a pcwex
[40:04.040 --> 40:09.980]  file. And as I mentioned before, the pcwex file is actually just a zip file with a different
[40:09.980 --> 40:15.040]  extension. And so if you extract it, you can see that there are a few files within this file.
[40:15.040 --> 40:21.200]  And one of the files that was of interest for us is the project.proj file. 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:46.860]  And this file will be loaded when the project starts or will be accessed when the project is
[40:46.860 --> 40:53.320]  loaded. And this file that is pointed to here would be the targets file. And this targets file,
[40:53.320 --> 40:57.900]  again, is a textual file. But as you can see here now, it gets interesting because it contains the
[40:57.900 --> 41:03.400]  names of some DLLs that need to be loaded when the project is built. And so what we discovered was
[41:03.400 --> 41:09.860]  that basically when you open a project file, you... when you open a project file, this whole chain of
[41:09.860 --> 41:15.700]  events happens. And if you want to be... to think of it from a malicious actor's point of view,
[41:15.700 --> 41:23.000]  what you would want to do is to be able to send a malicious pcwex file and get the engineer to
[41:23.000 --> 41:29.980]  open it. And you would change the pointer here to anything you want, basically any other file you
[41:29.980 --> 41:35.400]  want. And let this other targets file contain a pointer to your malicious DLL. And let's see what
[41:35.400 --> 41:40.100]  it looks like in real life. So we start again with the same directory structure, because we only
[41:40.100 --> 41:46.440]  change a bit of lines within the files. And within the project file, we changed it. Instead of using
[41:46.440 --> 41:51.500]  some kind of environment variable, we'll simply point it to a malicious SMB server that is accessible
[41:51.500 --> 41:56.540]  to the victim's machine. So we don't have to drop this file ahead on the victim's machine.
[41:56.540 --> 42:00.480]  All we have to do is make the victim's machine approach us and request for the malicious targets
[42:00.480 --> 42:06.300]  file. And within the targets file, again, what we would do is we would point to a malicious DLL
[42:06.300 --> 42:12.900]  that is used, that is loaded when the project is built. And so what happens basically when the
[42:12.900 --> 42:17.600]  project is open, that the software is automatically building the project. And so they access this
[42:17.600 --> 42:24.260]  project file, this project.proj file, and collect the malicious.targets file from our server.
[42:24.260 --> 42:27.540]  And based on this malicious.targets file, they will collect the DLL
[42:28.300 --> 42:34.300]  again from our server and execute it. And once they've done that, basically, we ran our own DLL
[42:34.300 --> 42:41.140]  on the remote machine with the permissions of the software, and we've taken over the control.
[42:41.140 --> 42:46.520]  And that's the whole vulnerability. And that's pretty cool, in my opinion. And obviously,
[42:46.520 --> 42:51.600]  this vulnerability was disclosed to Phoenix, and we would like to acknowledge their quick
[42:51.600 --> 42:56.260]  remediation of that. It took, I think, less than two months between the time we disclosed this
[42:56.260 --> 43:00.320]  vulnerability to Phoenix and the time they released the fixed version and its advisory,
[43:00.320 --> 43:06.740]  which is very nice and not very common in the ICS domain. So we would like to thank Phoenix
[43:06.740 --> 43:14.060]  for fixing this in such a hurry. Cool. So what did we do so far? We showed that
[43:14.060 --> 43:18.580]  those project files are interesting, and we showed that they are vulnerable. We showed that you can
[43:18.580 --> 43:22.260]  find vulnerabilities in them. And some of these vulnerabilities, you don't even have to work very
[43:22.260 --> 43:28.580]  hard in order to explain. So let's complete the last piece of the puzzle. The last piece of the
[43:28.580 --> 43:34.880]  puzzle would be how I can use these vulnerabilities in order to take over an engineer's computer.
[43:34.980 --> 43:39.480]  Because if you think of a protocol vulnerability, you know that the PLC is there. You know that
[43:39.480 --> 43:43.880]  you are here. All you have to do is communicate with the PLC, and you are done. But in the case
[43:43.880 --> 43:47.940]  of a project file, you know that the engineer is here. You know that you are here, but you want to
[43:47.940 --> 43:52.360]  get the engineer to open a project file of your own. So the attack vector here is something that
[43:52.360 --> 44:00.700]  I need to convince you that exists. So we had a look, and we tried to think what ways could be
[44:00.700 --> 44:07.000]  used to get a victim engineer to open an ICS project file. Because you know that when someone
[44:07.000 --> 44:11.440]  sends you a doc file, as I mentioned before, via email, someone you don't know, you will probably
[44:11.440 --> 44:16.320]  be suspicious about it and not do anything with that. But if you're an OT engineer and they send
[44:16.320 --> 44:22.840]  you a Rockwell ACD file or any other type of ICS engineering file, then you might be curious. This
[44:22.840 --> 44:27.840]  is your world. You're interested. You want to understand what's going on. You will want to open
[44:27.840 --> 44:33.200]  this file. You will be curious. So instead of sending you a doc file, in theory, the malicious
[44:33.200 --> 44:39.800]  actor could send you an ACD file or a project file and get you to open that. It would be more likely
[44:39.800 --> 44:45.940]  that you do. And this type of phishing campaigns happens. In the COVID-19 world, you know that
[44:45.940 --> 44:51.360]  and many papers have been published on that, that the fact that phishing is on
[44:51.360 --> 44:56.940]  the rise and targeted phishing towards ICS industries is on the rise. So as you can see here,
[44:56.940 --> 45:01.620]  this may be used as a phishing campaign that is very targeted and very specific
[45:03.120 --> 45:05.240]  towards OT engineers.
[45:11.530 --> 45:17.010]  Sorry, and not only phishing campaigns or not only phishing campaigns via email, what we thought
[45:17.010 --> 45:22.710]  next was, let's check the forums, the support forums in the ICS domain, because we know these
[45:22.710 --> 45:28.770]  support forums are very, very, in very, very common use. And many people use them to ask questions,
[45:28.770 --> 45:36.570]  to help other people to get some support, both the vendors' own forums and the public forums.
[45:36.570 --> 45:40.990]  So we had a look at these forums and we looked for people who might have posted
[45:40.990 --> 45:45.630]  these project files and had a look at what they have done. And so, for example, this is just
[45:45.630 --> 45:50.330]  one message from a forum that we found. I have an ACD file, but I do not have the software to
[45:50.330 --> 45:55.110]  read the controller tags. Can anyone please help me convert this file into a PDF? And they published
[45:55.110 --> 45:59.650]  with this message, they published an ACD file. And what you could see in the comments section
[45:59.650 --> 46:04.770]  is that many, many people did download this file and did open this file and help this person. And
[46:04.770 --> 46:10.090]  obviously, this was the happy case where someone did need help and many people did help him. But if
[46:10.090 --> 46:19.650]  it was a malicious case, then this question could have caught many ICS engineers and have taken
[46:19.650 --> 46:25.370]  control over the computer if this was a malicious case. So this attack vector of getting an ICS
[46:25.370 --> 46:33.930]  engineer to open a project file, I think, may happen. It's really real, either as part of a
[46:33.930 --> 46:39.350]  request or anything like that. And the reason this is very critical, and more critical than
[46:39.350 --> 46:47.370]  using just a doc file, is that this engineer who sent an ICS project file via email from
[46:47.370 --> 46:52.030]  the internet, they will open it on their computer. And this computer, you know that this computer, by
[46:52.030 --> 46:57.630]  definition, has access to the shop floor, has access to the actual physical devices. Whereas
[46:57.630 --> 47:03.750]  if this was just a Microsoft Word document, this engineer might have opened it on their own
[47:03.750 --> 47:09.330]  computer, which is not connected to anything interesting. But if you provide the engineer with
[47:09.330 --> 47:14.070]  the project file, they would take it to the computer that is connected to the shop floor,
[47:14.070 --> 47:19.590]  because it has the engineering software installed on it. So basically, the hacker, with just one
[47:19.590 --> 47:25.350]  step, got access not only to an engineer's computer, but to the actual critical engineer
[47:25.350 --> 47:31.990]  computer and to the actual critical network. And so, hopefully, what I could convince you with
[47:31.990 --> 47:36.350]  along this talk was that ICS project files, they are very interesting.
[47:37.410 --> 47:42.830]  They allow you great visibility into a network and great understanding of your network. And so,
[47:42.830 --> 47:46.870]  I don't want anyone to go home and delete all your project files, right? Because you have to
[47:46.870 --> 47:51.410]  keep working, and this may provide you of great value if you handle these files right. Obviously,
[47:51.410 --> 47:55.810]  you also have to secure your files to make sure that no malicious actor gains access to those
[47:55.810 --> 48:01.130]  files as well. But they are very important. But on the other side, you have to be aware
[48:01.130 --> 48:07.590]  that these project files can be just as malicious as a doc file. And this means that you don't want
[48:07.590 --> 48:12.950]  to open any ICS project file that is uploaded to a support forum or to anything like that.
[48:12.950 --> 48:17.510]  And actually, these files may be even more dangerous than these doc files, because what
[48:17.510 --> 48:21.750]  we said just a minute ago, that they will provide the attacker with access directly to the critical
[48:21.750 --> 48:28.510]  network. So, these files for an attacker actually are a great way to spread through phishing
[48:28.510 --> 48:33.190]  campaigns that are targeted, that are going directly to the ICS engineer, not just to anywhere
[48:33.190 --> 48:39.390]  around the world. And so, they're very critical in that. And they will get this attacker a foothold
[48:39.390 --> 48:46.570]  in the ICS network. And so, the bottom line here of this talk is just use these ICS project files
[48:46.570 --> 48:53.310]  to gain visibility into your network. And that is great. But be suspicious of any ICS project
[48:53.310 --> 48:58.150]  file that might have been sent to you, and that might pose risks to your network.
[48:58.650 --> 49:02.910]  And that's it. Thank you very much, and have a great conference.