So, we've gained initial access to our target environment.
The next step is to identify opportunities to move through the network to
identify our final target, industrial control systems.
We begin with internal reconnaissance.
There are a number of special considerations for conducting internal
reconnaissance and other potentially aggressive techniques in industrial
control system environments. ICS devices don't generally have a
requirement for performing high workloads,
so they tend to be fairly low spec in terms of processing capability,
but this means they can become overloaded under certain conditions, for example,
by intense brute‑forcing or conducting scans.
This can lead to faulting, resetting,
freezing, or a loss of network connectivity,
which can potentially compromise the availability of the entire system.
ICS typically use lower bandwidth network connections than are found in
traditional IT environments due to the use of older networking
equipment and the lower volumes of traffic that need to be carried.
Introducing high levels of network traffic through intensive network
scanning and fuzzing, for example,
can cause latency issues or even crash the network entirely.
Most ICS environments still contain a significant number of
legacy systems, whether that's controlled devices,
outdated servers, or workstations running on Windows XP, NT, or even Windows 95.
The end of life for a typical industrial control system is upwards of 20
years, and system‑wide architecture upgrades are rare,
primarily driven by the need to continue production.
Downtime costs money. But legacy systems are riddled with vulnerabilities,
things like command injection, SQL injection,
cross‑site scripting,
cross‑site request forgery, DLL hijacking, directory traversal, and many more.
These systems are also vulnerable to malware attacks, rootkits,
viruses, adware and spyware, worms, Trojans, and ransomware,
any of which can be delivered by drive‑by download,
watering hole attack, phishing, or web compromise.
The final consideration for testing in ICS environments is the weak
network stack handling that many ICS devices suffer from.
This is the inability of ICS devices to handle network traffic that
they weren't expecting, such as oversized packets,
malformed packets,
a high level of network traffic, and packets that use a
protocol other than that which was expected.
More generally, ICS protocols themselves can introduce vulnerabilities.
Modbus, for example,
which we'll look at in more detail later, transmits traffic in
plaintext and doesn't implement authentication checks.
This makes on‑path record and replay attacks trivial.
Modbus also has some undocumented function codes that are
proprietary codes used by vendors to implement functionality
that's not part of the Modbus standard.
One of the best examples of this is Schneider Electric's function code 90,
which implements a STOP CPU function. If we conduct an on‑path attack,
intercepting traffic between engineering software and a Schneider PLC, and
modify the function code of the captured packet to hexadecimal 5A, then we
could force the PLC to be placed into STOP mode.