Checking for ICS Internet Exposure Using

In this article I will take you through the process of performing an internet exposure check for your ICS. We will look at what “exposure” means in the realm of networking, followed by a sample search for the internet exposure of a random IP address that I chose for no particular reason other than that it showed up on Shodan ( under the criteria that I was looking for (this is how many victims are chosen).

All possible precautions to hide the identity of the IP owner were performed without taking too much away from the overall article's content.

ICS exposure 101

One would be hard-pressed to find an ICS environment that doesn’t have at least some IP networking technology connected to it. In reality, though, most ICSs have been completely integrated into IP networks. This wasn’t always the case and often these IP networks were an afterthought or were added to the ICS by people whose primary job isn’t IP networking, let alone cybersecurity. For that reason, it is an easy mistake to make and it occurs quite often that an ICS unwillingly gets directly connected to the internet. Sometimes this is done intentionally as well, to give the ICS remote connectivity for one reason or the other. Whatever the cause or reason, having ICS equipment connected directly to the internet is bad. Let me reiterate that: internet-accessible ICS equipment is a BAD IDEA! The equipment wasn’t designed to handle this, and even the most basic security precautions (such as a login prompt with authentication and authorization capabilities) is missing from most, if not all, ICS equipment. Here’s an example: if port 44818 of a Rockwell Automation controller or network card is exposed to the internet, all an attacker would need to connect to your controller and start causing mayhem would be the FactoryTalk Studio 5000 programming suite or one of the many available programming APIs that can communicate over the CIP protocol. For example, Python
has the well-developed CPPPO module (

For this reason, it is imperative that you check your ICS exposure on the network from time to time. Next, we’ll see how that’s done.

Figuring out the scope

Before we can see what is exposed out on the internet, we need to know what our internet (or public) IP address is. You can figure this out by navigating to will show you your public IP address, along with a bunch of network related data. You can now use that public IP address to start querying Shodan for results. Keep in mind that many organizations will have a range of IP addresses (a subnet) assigned to them and might be using several different connections to the internet. Your organization might have a central proxying firewall deployed at corporate that handles the web requests for all remote sites. A tunnel to the corporate network will relay web traffic, while the local internet connection can be (mis)used for other connectivity into the remote site/plant (think VPN or FTP). In this case, the IP address you get from will be the corporate IP address. The IP address we are interested in investigating would be the one for the remote site.  In this case, we want to make sure we investigate the entire range for our organization. Luckily, makes this really easy. If we scroll down the results, we see the recorded IP range for our public IP address, in the ASN (Autonomous System Number) section:

Within the ASN section, the subnet assigned to your company (which is the autonomous system) is shown as “route”. In the example above this is This means the company owns the entire IP address range from to This will be the IP address range we have to investigate.

So, with the range of IP addresses set, let’s look at what all can be found.

Shodan searches 101 describes itself as “The search engine for Security, the world’s first search engine for Internet-connected devices”:

The way Shodan operates is not by indexing the content of connected devices (like Google will index the HTML a web server supplies to visitors), but by indexing the details about the internet-exposed service (like the make, model and version of the web service that is installed on a server). For example, from a web service the following information is given by the Headers of a web response:

HTTP/1.1 200 OK
Date: Thu, 03 Oct 2019 07:52:40 GMT
Server: Apache/2.2.29 (Unix) mod_ssl/2.2.29 OpenSSL/1.0.1e-fips mod_bwlimited/1.4
Transfer-Encoding: chunked
Content-Type: text/html

The Headers show we contacted an Apache server, version 2.2.29 of Apache to be exact, running on a Unix machine.

Another example would be the service banner shown below, returned from the ENIP service of a Rockwell device:

Product name: 1761-NET-ENI/D
Vendor ID: Rockwell Automation/Allen-Bradley
Serial number: 0x6xxxxxx8
Device type: Communications Adapter
Device IP:

As you can see from the banners, we connected to a 1761-NET-ENI/D module. An interesting bit of additional info is that the IP address shown in the output is the IP address of the internal network, and obviously not the public internet IP address. This is because the internet attached module is in/on the same backplane/rack as the local NIC for the ICS network, we are (conveniently) presented with the IP address range of the internal network.

Back to the task at hand. By default, without signing up, Shodan allows you to perform a minimum set of search activities. You can only look for phrases or single IP addresses. For example, it allows you to search for “” or “Rockwell”. Once you sign up for a free account, you can perform more sophisticated searches such as port searches:

Signing up also allows you to search by network subnet, which we will use for our exposure search:

With one single, simple search (, we are presented with every exposed port/service for that entire subnet. Of course, the real hard labor was done by the Shodan indexing bots that scour the internet for (new) devices with exposed services. But hey, someone has to get their hands dirty, right?

There is a lot of information shown in this output. Most of it is probably has a legit business use, such as VPN, HTTP(S) and SSH access, that is necessary to perform day-to-day business activities or to allow customers to retrieve necessary information. What we, as ICS people, are interested in is the exposure of our sensitive control systems. The enterprise subscription for the Shodan service allows you to search for “tag:ics”, filtering out only the juicy stuff. However, not all is lost if you don’t want to invest in this type of functionality. We could search the results, page by page, looking for the ICS-tagged results, which is not a small task, but doable. But if we think for a minute and look at the type of devices we have, we can add keywords to our search like “Siemens,” “Emerson,” or “Rockwell” (add terms for common technology found in your facility).

And there we have the results we were looking for. Clicking on the IP address shows the details found in the Shodan database:


Here is a quick summary of how we got to the Shodan results for our IP address:

  1. Figure out the public IP address we are using by visiting (Alternatively, if you install the Shodan python module (pip install shodan) you can run the command shodan myip from the terminal to find your public IP address)
  2. If applicable, find out the IP range that your company might use, found in the ASN details from the output of Perform a search for your IP address or IP subnet (net: …) on
  3. Narrow down the returned results with additional search phrases around technology or ICS vendors that you use (for example “Siemens,” “Emerson,” or “Rockwell”)
  4. If results are found, start praying 🙂

As a final note, I would like to point out that Shodan offers an IP monitoring service that will alert you if changes occur to the external exposure of an IP address in a range you specify:

The service is not free, but the value of knowing when your systems (all of a sudden) show up on the outside is invaluable, in my opinion.


About the Author

Pascal Ackerman is a seasoned industrial security professional with a degree in electrical engineering and with 18 years of experience in industrial network design and support, information and network security, risk assessments, pentesting, threat hunting and forensics. After almost two decades of hands-on, in-the-field and consulting experience, he joined ThreatGEN in 2019 and is currently employed as Principal Analyst in Industrial Threat Intelligence & Forensics. His passion lays in analyzing new and existing threats to ICS environments and he fights cyber adversaries both from his home base and while traveling the world with his family as a digital nomad.