Going Out With a Bang — Virtual SCADA Hacking with GRFICSv2: Part 2

Introduction

Like Part 1, this exercise is a modification of one of Fortiphyd Logic’s tutorials on their Youtube channel, so a lot of credit has to go to them for giving me the inspiration.

What You’ll Need

I go in slightly greater detail in Part 1, but the tools you need to reproduce this exercise are:

• virtualization software (ex. VirtualBox or VMware Workstation Pro)

• GRFICSv2 VM environment

• Kali Linux (or ControlThings)

Links to the perspective tools are all provided in Part 1. Also like in Part 1, any other tools mentioned in this post can be found in a standard Kali/ControlThings installation. mbtget isn’t needed for this exercise.

The one major change I made to the default configuration of the GRFICSv2 environment is the creation of an admin user on the workstation VM as opposed to the default workstation user.

Shutting Down the Process… Permanently

In a continuation of the previous write-up, we’ve shut down the process, but it looks like a (hypothetical) OT operator intervened and managed to restore it back to normal operations.

Let’s go back to our initial arp-scan output, and look for what might be the device that intervened.

Let’s start here.

Like last time, we go back to Wireshark to see what the pcap can tell us:

Oh, interesting…

Another URL visited along TCP port 8080, similar to course, we have to visit this URL in our browser, just sans the “/uploadStatus” directory:

This would do it.

We know how we failed the last time, but we’re missing a final piece. Since we’re an intruder on this ICS network, where architecture and configurations are bespoke, we are at a disadvantage. We have a vague sense of what this process is meant to do, because of the industry of this (hypothetical) company, but that won’t give us the very specific information we need to bring it down.

We don’t even know where to begin because we don’t know what type of program to upload to this PLC that will cause any damage.

The best place to get to it is from the host we sniffed this from, which is most likely an OT engineering workstation. These are machines that host not only the PLC programming logic but also important documents like project files. These project files explain what the process is meant to do, what the devices are that make up the ICS process, and how they’re configured. Let’s try to SSH into it.

The common username of “admin” has already been seen on this network, so let’s start there. We use Hydra to try to brute force the password:

hydra -l admin -P /usr/share/wordlists/metasploit/unix_passwords.txt ssh://192.168.95.113:22 -t 4 -V

SSH didn’t work, and we can’t ping it.

Unsure of why it won’t work, although we’re leaning towards the same device having two network interface cards (NICs), we can just try a different host we’ve discovered.

What’s this device?

Let’s try to authenticate to it, but first, we need to find out the password. We have already seen poor password hygiene (via weak/default passwords) in this network, so there’s no reason to reinvent the wheel. Good ‘ole brute forcing might actually work here.

As stated before, we’ve already seen the use of “admin” in the network, so let’s try that again:

Pitiful.

It’s a trivial matter to SSH into the system:

We’re in…

We have to find whatever document is needed to upload to the PLC, so the first place to look is /home/admin/Documents:

cd Documents
ls

One file

Let’s view it with:

cat simplified_te.st

Note the values at the beginning of the file:

We now know what the max value is supposed to be.

Most of this will likely look foreign to the majority of attackers, but the things we’re interested in here are the set points, denoted as “_sp_c”, with the most important being the pressure set point.

Jackpot!

Changing these will set the target values for each variable to whatever we want to, forcing the system to try to meet them. We already know we have access to the OpenPLC Server where we can upload new logic, so we have an idea for how to attack:

1. Copy all of the text from the terminal.

2. Make a new text file.

3. Modify the sp values to the max value of 65535.

4. Save the file.

5. Upload it ourselves to the OpenPLC Server.

Let’s put it to action.

We modified the values and saved to a new text file on our Kali machine.

Add the new program and then upload it.

Success!

We can see pretty early on that this is the highest the kPA has ever gotten since we’ve been on this network:

We previously never saw it exceed approximately 2750kPa.

I wonder what the process itself looks like:

That’s not good…

Uh-oh…

I think we’re (hypothetical) fugitives now!

Takeaways

We’ve certainly made sure that production was shut down. This time, it looks like it will take a considerable amount of time, money, and resources to bring the chemical process back up again.

There are multiple ways we could have gone about achieving the end goal, and this is actually the third variation of this attack that I’ve come up with. To be clear, this wouldn’t have been possible if several basic cybersecurity best practices were in play:

• Continuous security monitoring with an EDR and SIEM.

• Strict password requirements.

• Strong network segmentation.

• Admin accounts that aren’t named “admin.”

If you have any ideas for improvement, think I missed something, questions or feedback, please don’t hesitate to leave a comment.