Demystifying threats to satellite communications in critical infrastructure | MJ Emanuel: this mp4 audio file was automatically transcribed by Sonix with the best speech-to-text algorithms. This transcript may contain errors.

MJ Emanuel:
Good afternoon everyone, I was about to say morning. I'm here to talk about satellite communication usage in critical infrastructure.

I think this is something that we don't really fully understand. And so we just kind of like, say, that's scary, that's bad.

You know, there's a lot of, there is a lot of news and headlines about the wind turbine disruption after the ViaSat compromise.

But, you know, the wind turbines didn't actually stop producing energy. So I think we need to talk a little bit more about the nuance of when are data flows just interrupted and when is it visibility that's interrupted? And that's what I'm gonna try to do in this talk.

So my name is MJ Emanuel. I am on the ICS incident response team at CISA in the threat hunting subdivision, and I did kind of a mix of forensics and threat intelligence. I also will be teaching at the The Alperovitch Institute next semester about critical infrastructure and cyber.

So as I said, my you know, my goals for this talk are kind of to structure it around an incident response we had earlier this year at CISA for a SATCOM service provider. But I'm really going to be talking more about how data is generated in critical infrastructure and how it flows, because I think we need to understand like what's normal to talk about what how can we derive impacts from that? And then consequent driven impact analysis is really, really the key to this.

So this is something that's really been pushed by INL for the past couple of years. If you've heard of CCE, that's cyber. What is it, cyber-enabled, consequence-driven engineering? So it's something that's being talked about when we were talking about how do we design these systems. But I think it's something that we also need to bring about when we're analyzing these systems and thinking about threat intelligence for critical infrastructure.

So our incident kicked off just from an outside tip that there was suspicious activity in a telecommunications environment. So we initially attempted to perform victim notification to this telecom provider, and then we quickly realized that the impacted entity wasn't the telecommunications provider, it wasn't the owner of the IP, but it was who they are releasing it to and who they are releasing to was a satellite communications provider.

I think this was like a perfect "oh, no, what did we just get into?" example that kind of highlighted what happened later in this case, because I don't think anyone, any of us really can appreciate how convoluted the satellite services industry is.

There's been an insane amount of consolidation and an insane amount of mergers that make it really opaque, and it makes it really hard to drive change because there are so many players on the back end that are never, ever interacting with the end users that are subscribing to the services.

So just an example, we're going to be talking mostly about Inmarsat BGANs for this talk because that was the type of service that was impacted in the incident.

I'm going to talk about. So this is just one of the many different types of satellite services that people can use. And just for this specifically, basically, the satellites are owned by Inmarsat. There are basically only four of them. And the current generation, runs on the L band. And basically, like any of the data that's flowing, it is going to go to one of those satellites and then come back down to only six ground stations around the world.

So something that's always going to happen when you're talking about using satellite services is how does that data flow from one of those six access stations back to the end users?

Because I think a lot of us kind of think about satellites like radios. We think the data is just going to go up and then down, but that's absolutely not how it happens. And then that when that data is in transmission, there's a lot of opportunities for there to be risk. And then there's also just only three terminal manufacturers. So I'm not really going to talk about this, but when we talk about like, supply chain issues because there are so many vendors in this space, there's just also a lot of opportunity there for there to be risk.

So after we initially started talking to the actual entity that was impacted by this incident, we quickly learned that they did have customers in critical infrastructure.

MJ Emanuel:
So CISA has both the ICS cert and US Cert and Legacy Incident Response teams. That means that we're responsible for both critical infrastructure or really any private sector companies that want to come to us as well as federal agencies. And I think that kind of gives us a little bit of a bias because when a federal agency comes to us with an incident, it's very easy to realize that something we want to resource. But when a random service provider comes to us or we come to them, it's not something that's always going to be a priority.

One of the really big, I will say, lively debates about this incident was a lot of people thought that the service that was being provided was just going to be satellite phones, that it was just the phones and just talk communication that was being transmitted by these networks. Those absolutely not the case.

So I'm going to talk a little bit about like what is SCADA so we can kind of think about what exactly was being like, what was actually flowing through those environments. So I think we kind of interchanged a lot of terminology like like it's all the same, but actually, ICS and SCADA are not interchangeable.

So ICS Industrial Control Systems is kind of the larger like a bucket of term. And then SCADA: supervisory control and data acquisition really refers to a specific type. It refers to data or refers to systems that are over a large geographic area. The opposite of that would be a DCS system, a distributed control system. And that's really more like one specific location. So look at DCS is something you might see at like a specific power generation facility, something that like it's local, probably all wired. And then a SCADA system might be like power transmission, like lines over like millions of miles or not millions but miles of of data.

So and then this communication, it really is up to whoever engineered the system. You know, I've seen people lay fiber. I've seen people use migrate cellular satellite. It's really up to whoever designed the system. And then let's talk a little bit about what kind of data is being generated.

So if you look on the right side, these are kind of like the field devices that are going to be like the lowest level when we talk about like these are these are dumb systems, These are just like your temperature sensors, your pressure systems, like maybe a valve that opens or close.

And then the control of that system is going to be from the PLC, the programmable logic controller. So the data is either being the data is either a command being generated from the operators that are sitting up upstream and the corporate at the control center and it's being pushed down to the field device or the data is some sort of temperature sensor or some sort of data that's being read and sent back upstream for the operator to have.

MJ Emanuel:
So that's the type of data that we're having, both things like maintenance data as well as commands, the commands that change the physical state of those devices on the on the right.

So I kind of want to drive home that point about that translation between logic and physical change. And I think a really interesting way to do that is the configuration files from Industroyer2. So right here is one of the configuration files or part of a configuration file from Industroyer one of Industroyer2 samples and I think Industroyer 2 isn't that exciting technically because all it's really doing is pushing commands in a specific protocol, the IEC 104 protocol, which is something mostly used outside of the US and the power sector.

But basically what you can do if you try hard enough is you get these these numbers, these IOAs: information object addresses. And then if you go back to the vendor documentation, in this case it was AB, you can start to map the IOAs back to the actual engineering functions that they're referring to. So these, these numbers, so these numbers that were in the configuration file, you can map here to the data points that describe the engineering function. And then later in the documentation, you can start to translate those back to like what actually is it changing?

And so in this case, it was both supervision alarms as well as circuit breaker failure, circuit failure, data failure, protection.

Those were the things that were being turned off and on from the configuration file of industroyer2. So I think it's really hard to get to this level of understanding because every state environment is going to be engineered differently. It's not like an HTTP status code that's going to be standardized. And I think this is kind of like the crux of why the field of ICS forensics has so much trouble is we kind of keep approaching it like it's going to be something standard like a lot of IT protocols, but it's really going to be it's it's not really about like what what function codes are being generated. It's about what systems they control at the end. And that's really hard to do.

The other thing that I wanted to talk about really quickly, I guess I kind of already said was just like, I think this is how we think of a lot of data flows happening, like from the specific control center back up and then down to the field, but that it really looks like this. So you almost have at least one kind of third party that's going to be like consolidating this information from the different end users and then sending it to the ground station and then to the satellite and back down. So in the incident that I'm talking about, like this was what was compromised, it was one of those things that's consolidating.

I think they had definitely dozens. It might be over 100 customers and a lot of different important sectors. And all of the data was being was being transmitted through this one entity.

So I think, you know, I love to talk about what are what are the pain points when we talk about critical infrastructure, like what are the things that would have the most impact and these types of service providers as well as things like integrators, like the people that are building these systems for their end users, are really, really sexy targets. And I think we should maybe focus a little bit more on them as we as we think about like where could things be the most painful?

Then this is like I had to kind of shorten this part down because I'm going to be well over time if I went into it. But I think we kind of touched on this yesterday in the fireside chat. But like I think it's really easy for us as researchers to kind of blame in users for not implementing best practices and even like really basic things like logging, but like we're what do we do now? And it's 2022 and like almost no one has logging in place in like actual critical infrastructure entities or even small businesses. And I think it's like time. It's it's time for us to start stop like judging them and just telling them to do it and giving them like additional ways to do it and show them how because shaming them obviously isn't working.

MJ Emanuel:
So with the very, very, very limited data we had, like the first thing they gave us was basically just two weeks worth of firewall logs. We eventually were able to to scrape some some older historic logs from some of the backups they had, but we basically had no historic network logging at all for this incident that was multi month dwell time.

So just like in the real world, we can just say analysis happens and then it happens. So the initial findings for this incident obviously, honestly weren't that exciting where we're able to trace it back to an unpatched FortiGate that was the FortiGate that both was used for remote employees to like log in to the service provider. But it was also the FortiGate that had static routes to all their customers. That was the last hop of transmitting all of their data traffic. It was really fun. So it was like a the CVE from 2018 for for FortiGate. There's a Metasploit module for it. It's nothing that's hard to do. And what that vulnerability allows you to do is to scrape creds from all of the active sessions that are, that are running on the device. And so all the adversary had to do was was move was move through the environment using those shared admin accounts.

MJ Emanuel:
And then the other thing that they were able to do when we were interviewing the owners of this network, they kept saying, But those are our backup devices. Like those are like emergency routes. Like, why? Why is the adversary doing things they're not supposed to be doing? And it's just like, yeah, I mean, it's still connected. Like, it's still like they had like basically an out-of-band FortiGate that used the same credentials as the real FortiGate.

So yeah, it was really not that hard for the adversary to move around. And then the one thing that we really did see them doing was focusing on just basically information that could give them additional access into the environment. So things like their network management platform or their rancid server or their radius database, these are all things that we saw them being very interested into.

And then the thing that was the most concerning was that all of their customer traffic was flowing through the environment, unencrypted. I kind of thought this was going to be the case, but honestly, I wasn't really sure because I've never looked at a service provider network like this. So let's talk about like, what does that actually mean if your data traffic is flowing, unencrypted in an environment?

Here are some of the different protocols that we consider to be protocols that we were able to capture because we were tapping for, I think, three or four months with their permission. And this is a good time to plug that says A does have some bro parsers for ICS protocols that are on our GitHub.

MJ Emanuel:
So we are also always taking suggestions for additional protocols. So if any of you guys do like ICS monitoring and want something parsed, please talk to me after this.

So when we're talking about unencrypted protocols, basically the reason why the traffic was able to to move that way was because the traffic was encrypted from like here to here on that FortiGate, and then it was encrypted like here to here, but then it's unencrypted in the middle. So it's like just basic. They weren't using an encryption, but like, I don't like when we were interviewing a lot of their end users with the permission of the company, most of them didn't realize that their data was at risk in that way.

And this is actually a simplified diagram of how the data was flowing. There is actually like 2 to 3 more hops to different telecommunication providers. And so that means that that data traffic was at risk at all of those different providers. So this was the point where people started to freak out. But I don't want us to do that yet. I think like something that is a really large misconception is that for some of these protocols, you can just like push a function code that says like, do bad and will blow something up. That's not how it works. So we're going to talk a little bit about what does it mean if you can do something like read a coil or write a coil.

MJ Emanuel:
So, you know, going back to the diagram earlier, if you are at that programmable logic controller and you're telling a temperature sensor to do something or you're opening a valve when it shouldn't be, how much additional work does it take for there to be some sort of physical impact? And that's really going to be unique to every case. And I think that's why doing true impact analysis on these systems is so hard.

So initial conclusions about the the incident followed for a compromise. We're not going to be able to detect anything else they're doing because there was no logging. The most exciting thing here is that they actually did take pcap and exfil it on the interface where the customer data traffic was flowing. So we knew that they knew what they had or they could have known what they had. I'm sure there was other we don't obviously know exactly why they did that, but in my opinion, I feel like they did understand the value of the data that that they were they had access to.

So what are the other potential consequences to that system? And in order to illustrate this point, I'm going to talk about a specific sector which really heavily uses remote connectivity, which is natural gas pipelines. So the main point here is basically the natural gas sector kind of has like three subcomponents.

MJ Emanuel:
There's production, there's transmission and there's distribution. And the important part here is that there's often a couple of really key players in the space, like it's very consolidated industry that does the transmission part. So they're responsible for transmitting gas basically across state lines over long distances, and then they have contracts with the distribution sector. So like the gas that's coming to you locally is never going to be coming from these transmission environments. Yeah.

So what kind of data is being generated? We I hope we have a little bit of a better understanding of what data traffic looks like, but like, what are the types of things that it's being used to control?

One of those things are compressor stations. So basically every 50 to 100 miles on natural gas pipelines, there are compressor stations that basically filter the gas re compress it and cool it down. It just helps with the efficiency of those systems. So in every 50 to 100 miles, there's basically, excuse me, a remote site that is going to be doing those functions. And so there are both commands that need to be sent to those, as well as maintenance data or other data that's coming back from how those systems are operating. So that's one of the big reasons why they use remote connectivity.

And then the other really big one are kind of the interconnect points. So as the data is coming from the transmission companies down to the distribution companies, the interconnect point is how the like when Company X buys from company Y like that, that valve there is is is physically diverting how much they they buy, how much gas they buy.

MJ Emanuel:
So in theory, an interconnect point is actually a much more exciting target to an adversary because if if you are able to compromise how that valve is working, then you can potentially turn off gas to any of the downstream customers.

And then so that's the kind of data that's being generated we're willing to talk about like how is that data at risk? So what means if commands are being spoofed, what means if you don't have if you can't see or if you don't have control over those environments, but maybe they'll still work, like with the wind turbines, What happens if you can't see them or control them?

And then the other really important part here is are these primary or secondary comms pathways, like luckily, because critical infrastructure often knows that they're important, they do have a lot of redundancy built in. So when we were talking to a lot of the end users of, of the service provider, it kind of varied by just how their business contract worked out. Like were these satellite communications being used as just backups or were they primary? And there was a mix of both.

And when we talk about like impact to control process, so like what are the impacts from the different commands that are being sent versus impact to the to the physical impacts of the system? I think a really helpful tool to kind of generate those ideas is the ICS attack framework from MITRE.

MJ Emanuel:
So this is kind of like the last three columns of that. And I think the first two columns kind of talk about like what are the what is the impact to the logic controller? And then the last column is kind of like what is the impact to the system as a whole?

Okay, I'm out of time but will go really quickly. Conclusions. There was a when we talked about mitigations, I'm going to say I don't really know about mitigations because I like to do threat analysis, not mitigations. But there was a lot of fanfare from this NSA cybersecurity advisory that came out a couple of weeks ago or months ago now. I think it's a really good starting point, but you can tell that it was really inspired by military applications of satellite communications. It doesn't really go into the nuances of other applications. Like one of the biggest things is it basically just says like encrypt your systems or excuse me, encrypt your data links and like they're not wrong. But also when we're talking about real time operations, like you often can't just add transact to that. That's going to mess up the timing. So I think we need to we can't just like keep telling people to read this.

MJ Emanuel:
We need to like think a little bit more harder about these systems. And then there's just other common sense like Patriot systems in that CSA. I think like the biggest mitigation that I took away from this experience is that and the customers that we are the end users of that satcom provider. The biggest thing that we really were informing them was that there was a lot of risk. They did not know in the systems that they had implemented. So we just really need to continue to tell them that you can't treat your third party communication pathways as trusted. Like you have to think about it like public internet, like even if it's a private data stream, it's really not private.

So final thoughts. Systems are complicated. Let's kind of go consequent driven in our analysis, like let's not just stop at where the Iot part stops. Let's let's go all the way down to the physical process. And then like, what drives change? Like when I was doing some of the research for this talk, I found like a document from 2006 that basically said everything that I'm saying. So like, obviously what we're doing isn't working and I think we need to have some we need to stop getting spun up about like ICS and like actually talk about like how can we protect these systems from an engineering perspective? Okay. That's it. Thank you. What questions do you have for me? That's it.

Ryan Naraine:
It was amazing. Thank you very much. Let's pick a gift for you. Any questions for MJ over here? Alex, quickly. There is.

Question :
Sure. You know, basically like. We don't have a place of knowledge. So basically it's mindset. It's like, don't touch it. So how did you move from that mindset and what steps to. Actually change that?

Yeah, I think that's a really good question.

Ryan Naraine:
Repeat the question.

MJ Emanuel:
Yeah, sorry. Basically, I think your question was like, how do we how do we move past telling people not to touch their systems? Amazing. I think and I come from oh, sorry, I come from a cyber background, not a not a engineering background. And I think the the first thing that I think we have to do is basically education, which is kind of what I'm trying to do here and make it seem less scary and like actually give people like the understanding of the different pieces so that then we can have a conversation. But honestly, I don't know what to. Yeah.

Question :
What did it say? So I think you're absolutely right. And in educating industry, it's very important step. But education without enforcement later, like doesn't work. It's like security development lifecycle. You can teach the developers how to write the secure code, but if it's no enforcement, it will be tons of bugs.

MJ Emanuel:
Yeah, I think what I really meant wasn't educating the industry, but it was educating people in cybersecurity so that they can stop thinking of it as something other and then kind of move forward like we have with other cyber problems, if that makes sense. But it's hard.

Ryan Naraine:
Thank you. Another big round of applause for MJ.

Sonix is the world’s most advanced automated transcription, translation, and subtitling platform. Fast, accurate, and affordable.

Automatically convert your mp4 files to text (txt file), Microsoft Word (docx file), and SubRip Subtitle (srt file) in minutes.

Sonix has many features that you’d love including enterprise-grade admin tools, advanced search, transcribe multiple languages, collaboration tools, and easily transcribe your Zoom meetings. Try Sonix for free today.