Let's assume that based on our initial recon,
we identified a web application vulnerability in our target
organization. Exploiting web app vulnerabilities is outside
the scope of this course,
but we listed some other Pluralsight resources earlier in
this module that show you how to do that.
Now that we've landed in our target environment,
we need to take a look around and carry out some internal reconnaissance,
looking for opportunities to move us closer to our end objectives.
First, let's find out some information about the local network by
running ifconfig. We can see that we have an IP address of
192.168.48.140, and a subnet mask of 255.255.255.0,
indicating that we're in a class C network. That
helps to limit our scanning range.
Using nmap,
we can look for other hosts in the subnet by specifying
the ‑sn flag and a class C subnet range with /024 for the
final octet of the IP address.
The ‑sn flag does host discovery only and doesn't scan ports, is therefore
quicker, and allows us to narrow down the list of IP addresses we want to
scan in more detail. There are four IP addresses in addition to our own.
The .20 IP address presents itself as a pfSense device, which is primarily
a network firewall.
It has other capabilities, of course, and we'd need to investigate
further to confirm its full functionality, but let's assume for now that
it's a firewall. To find out a bit more about the remaining host on the
network, we again run nmap, but this time using the ‑a option, which
specifies several nmap features, including OS detection,
version detection, default script scanning, and traceroute.
We also specify the target IP address range using a comma‑separated list in
the final IP address octet. Let's start with the .130 host.
It's running a flavor of Linux and has two open ports. Port 8009 is
running an Apache Jserv protocol or AJP service.
AJP is an optimized version of the HTTP protocol that allows a
standalone web service such as Apache to talk to Tomcat.
Apache is faster than tomcat at serving static content, so AJP acts
to let Apache serve any static content, but then proxy the request
to Tomcat for Tomcat‑related content.
We see the Tomcat server running on port 9090.
The host of .134 is running a Python web server on port
8080 and is presenting a login page.
Port 20000 is also open, which nmap as guest is available for
distributed network protocol, or DNP traffic.
DNP is a control system protocol primarily used in power
and water utilities in North America.
One of its primary purposes is to communicate with supervisory control
and data acquisition, or SCADA systems. In this instance, nmap hasn't
been able to determine the OS version.
Finally,
the .136 host appears to be a Windows operating system. Port
135 is the RPC Endpoint Mapper service.
It's a service that allows other systems to discover what services are
advertised on the machine and what port to find them on.
It's a sensitive port that's associated with a lot of security
vulnerabilities and should never be exposed to the internet,
but it's needed in an Active Directory and server client
environment for many services to operate properly.
Ports 139 and 445 are open for file and print sharing via SMB, and the
script results show that SMB version 2 is in use,
which is known to have a number of remote code execution vulnerabilities.
One final scan we'll run before exploring our initial
findings in more detail is to look for specific types of
industrial control system device.
Nmap offers a number of useful scans for this,
but we'll look specifically for Modbus devices.
Modbus has been around since the 1970s and has become a de
facto standard communication protocol for connecting
industrial electronic devices.
Modbus communicates over port 502,
which isn't among the 1000 most common ports used by the default nmap
scan, so it won't show up as part of our ‑a scan.
We could scan specifically for port 502, but using the Modbus discover script
can provide more information about the target port, such as the server ID.
I've set the scan to be aggressive here because I know that the lab
environment is stable, but this option should be used with caution for
reasons outlined earlier in this module.
The results of the scan against the Windows host show port 502 as
open, and there's a Modbus server with ID 1.
Unfortunately, nmap's test to determine more information
about the device failed on this occasion.
That happens sometimes and we have to figure out other ways to find it.
We'll learn more about Modbus in the next module.
So here's what we have so far.
We've gained access to a host at .140 and identified what we
believe to be a pfSense firewall at .20.
Other hosts include a Linux box at .130 that's running a SCADA system and
offering a user interface via a Tomcat server on port 9090 that utilizes AJP to
separate how static and dynamic content are served.
The device at .134 exposes a Python web server on port 8080 and offers a
login page in which we were able to successfully apply default credentials.
At .136, we have a Windows box with file sharing and RPC enabled. But more
importantly from our perspective, it also has port 502 open,
which likely suggests that we have a device that
communicates over the Modbus protocol.
Let's take a look at those devices presenting web servers, starting with .134.
Well, this is encouraging. We seem to have OpenPLC running on this device.
A common vulnerability in industrial control systems is the use of
default credentials. With a quick Google search,
we can find and then try the default credentials for OpenPLC. And
on this occasion, we're in luck. At this stage,
we don't want to interact with any of the control systems; we're just
interested in gathering information about our target.
So let's browse through some of the tabs.
We can see that the PLC is currently in run mode,
so it's operational. It's running a program called PS Demo,
which is provided in a structured text or ST file. Structured text is
one of the 5 languages supported by the IEC 61131‑3 standard,
designed for programmable logic controllers.
OpenPLC,
in common with the Modbus standard and other similar client server
applications, uses the term slave for a device that provides a
response to a so‑called master device.
In this course, we're using the term server instead of
slave and client instead of master.
This PLC has one server device which is called Demo_factory. On the
Monitoring tab, we see lots of interesting information.
First, we see that it's dynamic and appears to be showing the
status of different digital inputs and outputs.
We can also see the names of the different control
instrumentation elements, such as Start and Stop,
which are presumably buttons to operate the process.
There's a safety door, which probably provides an interlock to an
enclosed area where automated machinery is operating.
There's also a sensor,
a picker, which has the ability to hold a box and move in the Z‑axis
and rotate, there are various indicator lights showing the operating
status of the machine, and a conveyor belt.
That's a lot of information that may come in useful later.
Let's now take a look at the Linux box that has Tomcat running on port 9090.
Unfortunately, we have the default Tomcat page, which, whilst giving
us some information about the server itself, doesn't tell us
anything about the application it's hosting.
There's really no way for us to know which files are found in
which directories on the web server unless the whole server has
directory listings enabled by default.
But if we go directly to a page,
it will be displayed, so we just need to know the name of the page.
Let's turn to a tool called DIRB.
There's a GUI version of DIRB called DirBuster, but for what we need,
the command‑line version is just fine. DIRB allows us to
brute‑force files and directories to do just that.
We call DIRB with the target web server and provide it with a
word list to try as possible web pages, and very quickly we see
a route web page called ScadaBR.
We also see pages for docs, examples, and manager,
all of which could be useful additional sources of information.
Let's try browsing to the ScadaBR page.
ScadaBR is an open source SCADA system that enables the
creation of interactive displays of information and
controls for automation projects.
And sure enough, we get a login screen.
Well, this time we're not so lucky. The operator is showing good
security practice and change the default credentials.
We'll have to try harder with this one.
Let's update our network sketch with the new information we've gathered.
We've determined that the device at .130 is likely a SCADA system,
which, if we were able to crack the credentials,
we may be able to access a human machine interface of some sort.
We could try brute‑forcing the credentials, but in an ICS
environment, that can be dangerous.
We'd be better off trying to find a password representation,
such as a hash, and cracking it offline.
We've also confirmed that the device at .134 is a PLC
controlling some interesting factory components.
We've confirmed that the default credentials work for this
device and that we're able to access the underlying logic
code through a structured text file.
We haven't found anything else about the device communicating over
Modbus yet, though. Let's see what we can do about that.
There's no obvious way to gain direct access to the device at .136
without searching for and exploiting vulnerabilities,
which is risky in an ICS environment.
Let's try something more passive and monitor network traffic using Wireshark.
And straightaway, we see a pattern that jumps out at us.
We'll go into detail about what these messages mean in the next module, but
for now it's clear that there's Modbus communication between the PLC and the
factory environment and that inputs are read and coils, or outputs, are
written to. Completing our network sketch, we've confirmed that the factory
device at .136 is using Modbus to communicate with the PLC at .134 and that
this communication involves a repeating cycle of reading inputs and writing
outputs.