Claroty Simplifies Protocol Identification


The Claroty research team (Team82) has released a custom, generic EtherNet/IP stack detection tool.

The tool helps identify and classify commercial and homegrown products using the same third-party ENIP stack code. By identifying the ENIP stack, users inside the enterprise as well as vendors will be able to better understand their exposure to newly disclosed vulnerabilities, and subsequently prioritize updates.

Team82 has used the EtherNet/IP & CIP Stack Detector as the centerpiece of several ENIP-related research projects, including an important November 2020 disclosure of a stack-overflow vulnerability in Real Time Automation’s (RTA) 499ES ENIP stack. Using the detection tool, Team82 researchers identified 11 devices sold by six different automation vendors that were built on top of the affected stack.

Following a second Team82 report published last April detailing five vulnerabilities discovered in the popular open-source OpENer EtherNet/IP stack, researchers understood there was a clear gap for asset owners wishing to quickly triage what devices are affected once a critical ENIP stack vulnerability is identified and publicly disclosed.

This gap was especially flagrant with open-source components such as OpENer; OpENer ENIP implements ENIP and CIP and is used by leading automation vendors in numerous commercial products. Users struggled because many products don’t clearly describe or list the components being used in a commercial device, and that includes which protocol stacks are implemented. Situations such as this are also adding fuel to important discussions around the need for software bills of materials (SBOM), which further close that window of exposure users face when vulnerabilities are disclosed and/or are being publicly attacked.


Team82’s EtherNet/IP & CIP Stack Detector can be used for security research and as part of an internal investigation to quickly scan many devices to retrieve their EtherNet/IP protocol stack. Users can also leverage this tool for:

Vulnerability Research and Remediation

Researchers may quickly deploy this tool to identify connected industrial devices and the ENIP stacks implemented on those devices for network communication and data transfer between devices and workstations. The tool would allow researchers to classify groups of devices running the same ENIP stack, and understand the scale of vulnerabilities and affected devices.

Asset owners, meanwhile, could run the tool to identify devices running an ENIP stack affected by a newly identified vulnerability. Too often, users are blind to the components running in commercial products and may be unaware of their exposure to critical bugs that have been disclosed. This complicates patch management decisions and could leave them vulnerable to publicly disclosed exploits, for example.

Honeypot Detection

The tool can significantly aid ICS honeypot creators to improve the stealthiness of their work in order to keep attackers from easily identifying a honeypot.

Honeypots are lures used by researchers and blue teams to ensnare attackers’ traffic to study their tactics and techniques in order to fortify network defenses. ICS honeypots mimic devices such as internet-connected programmable logic controllers (PLCs), and Team82’s tool can parse the protocol in use and help researchers separate legitimate traffic from honeypot traffic.

Let’s look at one example for this unique use case: Conpot is a popular industrial control system honeypot that supports the ENIP/CIP ICS protocol (using the CPPPO protocol stack implementation). If you look at conpot’s source code you can clearly see that a default ENIP serial number is being used – 0x006c061a.

Serial numbers are unique to each PLC, meaning that normally multiple PLCs should not have the same serial number. Yet, a Shodan search for this particular serial number, below, reveals that more than 340 connected PLCs have the same one. One can easily deduce that this is a ICS honeypot.

Playing this scenario out further, regardless of whether the serial number is changed to a random one, since the tool parses ENIP stack signatures, it can still determine whether this is honeypot traffic. Furthermore, if we can identify a perfectly “normal” honeypot, attackers can do the same. Therefore, honeypot creators can use the tool to classify their honeypots, improve them, and make it difficult for attackers to discern whether they’ve landed in a honeypot.


This tool performs behavioral profiling by breaking down the EtherNet/IP and CIP protocols to specific properties and attributes, which later creates a unique signature for the ENIP stack in use based on all the collected parameters. For example, the signature 0000010110100100000 identifies the CPPPO ENIP stack used by CONPOT.

Supersetting all the unique implementation hints reveals the identity of the ENIP stack being used. A parameter can be any delicate attribute of the protocol and the implementation, for example, an attribute that determines whether a certain feature of the ENIP protocol is currently supported. Scanning two different devices that use the same core ENIP stack (e.g. an SDK purchased from the same vendor) will result in the same unique signature.

Researchers are collecting the following boolean flags during a scan:

  • ENIP Register Session Number Sequential (0x1, 0x10, 0x100, 0x1000, 0x10000)
  • ENIP Can Register Session with Bad Options (Used value: 1)
  • ENIP Can Register Session with Bad Length (Used value: 3)
  • ENIP Is List Targets Supported
  • ENIP List Services Protocol Version is 1
  • ENIP List Services Name (‘Communications’ variation)
  • ENIP List Services Name Capability Flags Reserved Bit Are Empty
  • CIP Forward Open is supported
  • CIP Forward Open allows multiple requests for connection id 0
  • CIP Forward Open is O2T Sequential by 1
  • CIP Forward Open is T2O zero
  • CIP Forward Open can open with bad connection flags


This tool enables Claroty’s Team82 researchers to identify various classes of ENIP stacks and group similar stack implementations.

For example, Team82’s researchers identified the unique signature generated by devices running RTA’s ENIP stack. With that, Team82 started to scan many ENIP-compatible devices in order to detect all potentially affected devices.

Eventually through this tool, researchers were able to scan 290 unique ENIP-compatible devices, which revealed 32 unique ENIP stacks. Of the 290 unique devices scanned, 11 devices were found to be running RTA’s ENIP stack in products from six unique vendors and appropriate actions were taken accordingly (disclosure process).

Team82 was able to scan 290 different ENIP-compatible modules and classify them into 32 categories. Each category represents a unique ENIP stack implementation. Of the 290 scanned devices, 11 were found to be using RTA’s ENIP stack.


Much discussion is happening about software vendors providing a software bill of materials (SBOM). Within ICS, SBOMs are not commonplace, despite their potential importance in a number of areas, including vulnerability management.

SBOMs are analogous to ingredient labels on food products, or parts lists for toys and automobiles. They are a structured list of components such as libraries and modules required to compile and link software, and even the supply chain relationships between them. With an SBOM in hand, an organization can quickly see whether a vulnerable component is running in their environment and break through the black-box nature of some ICS and OT software packages or firmware installations.

This type of visibility into the components used to build commercial firmware or software products is vital for decision makers struggling to assess their risk in the event of an incident which would hamper response or vulnerability remediation.

The U.S. government, for one, has determined there is value in SBOMs. An executive order issued last year by the Biden administration included a section on supply chain security that included SBOMs among secure development practices as mandatory for each product purchased by the federal government. This is vital for buyers of commercial products who may not understand the exposure created by the inclusion of an open-source component running under the hood.

Team82’s EtherNet/IP & CIP Stack Detector, in the meantime, can be used to lessen that risk. Users are encouraged to download the tool, try it in their environments, and share their feedback with Team82 and the community.