How Stuxnet (PLC virus) spreads – Part 3

Continued from How Stuxnet (PLC virus) spreads – Part 2 » Read here

Compromising the Network

How Stuxnet (PLC virus) spreadsGiven the well-secured industrial control system described above, how could a worm like Stuxnet ever penetrate all the way to the PLCs? Yet clearly it did – Siemens reports that it is aware of at least 22 sites that experienced infected control systems and certainly there were other sites, such as sites with other vendors’ products, who would have not reported infections back to Siemens. Suggesting possible answers to this question is the goal of this paper.

For this analysis, assume that the date is May 1, 2010. At that date, the Stuxnet worm had been refined over the course of about 12 months into its mature form, using the shortcut or LNK vulnerability rather than “autorun.inf” to propagate via USB drives. No patches existed for the zeroday vulnerabilities the worm used. No anti-virus signatures existed for the worm.

No security researchers knew the worm existed. With the variety of propagation technologies available to the worm, many scenarios would lead to the state-of-the-practice network described in the previous section to be compromised.

The discussion that follows illustrates one way the target ICS could have been infiltrated. At each stage, alternative pathways are also noted.

Figure 5: Compromising the Site’s Networks
Figure 5: Compromising the Site’s Networks

Initial Handoff of the Wormv

v – Analysis by Symantec indicates that the worm was initially handed off by its developers to at least five separate organizations inside Iran. Severally of these organizations were repeatedly targeted over a period of a year.

In our primary scenario, a company employee returns from an off-site visit to a contractor’s facility with an infected USB flash drive. The employee has been given the infected drive deliberately by a saboteur employed at the contractor facility.

Alternative pathways: the infected drive may have been simply targeted at the contractor with the assumption that the worm would eventually be transferred to the target site. Most contractor/client relationships are well known in the industry, making selection of a suitable contractor relatively easy. The initial handoff of the worm to an employee of the target company could also occur at industry tradeshows. Free “branded” USB flash drives are commonly used as give-aways by vendors or as an alternative to CD’s for distribution of conference materials.

In the past year, one of the authors of this paper was given a “new” USB drive at a major control vendor tradeshow as a gift. The USB drive was infected!

The worm could have also been sent to the organization through a targeted email that contained a special dropper program designed to install Stuxnet. For example, the authors have been able to construct a proof-of-concept dropper for of Stuxnet that is based on an infected PDF.

Infection of Initial Enterprise Computer

Once the employee inserts the infected USB flash drive into his workstation and navigates to the drive using Windows Explorer, the workstation is immediately infected. Anti-virus on the workstation does not generate any alerts, because there are no signatures for the Stuxnet worm at this time. The fact that the workstation is fully patched is of no help, because the LNK vulnerability on shortcut files that the worm uses to infect the machine has no patch at this point in time. Nor do the escalation of privilege vulnerabilities the worm uses to gain system-level access on the workstation. The worm is also able to install what is called “rootkit” software that hides the files used by the worm when browsing the infected flash drive.

Alternative pathways: The initial infection of a computer on the target company network could also occur by the contractor supplying PLC project files that are infected. Due to the nature of contractor/client relationships and the need for continuous collaboration, a variety of project files are freely exchanged between team members. These files not only include the PCS 7 project files that the Stuxnet worm could piggy back on, but also other potentially vulnerable file formats including drawing, spreadsheet, database and PDF files that future worms could exploit.

It is unlikely that the transfer of these files can be completely prevented, since many are essential to the engineering design process.

Propagation to other Enterprise Computers

As noted earlier, once on a network, Stuxnet is designed to spread aggressively. Thus within a few hours, the worm would likely spread to printer servers and file servers on the Enterprise Control Network connected directly or indirectly to the compromised workstation.

At this point, the worm might lay dormant, infecting new USB flash drives as they are inserted into compromised equipment, waiting for someone to carry such a flash drive and the worm to a protected network. Alternatively, it may request new instructions from a command and control server – see the section “Peer-to-Peer Networking” below. All personnel carrying and using infected flash drives would be unaware that the worm is installed on their drives, because the rootkit hides the worm’s files from the user.

Alternative pathways: Some additional alternative paths for infection of the Enterprise Control Network include:

  • The employee may have attached an “approved” external drive to an infected machine while visiting a contractor and subsequently brought this drive back into the company network.
  • The employee may have connected his or her laptop to a compromised network offsite, and thus infected the laptop and then subsequently connected it to the Enterprise Control Network on his or her return.
  • A contractor may have visited the site, bringing and using a compromised external drive on the site network.
  • A contractor may have visited the site, bringing and using a compromised laptop on the site network.
  • A contractor or employee at another facility may have used a file share at this site over the WAN and so compromised the Enterprise Control Network.

Penetrating the Perimeter Network

In our primary scenario, we will assume that one of the workstations on the Enterprise Control Network belongs to an employee who occasionally interacts with the person who manages the historian server on the Perimeter Network. As is commonly done in the industry, the manager has a file share configured on his workstation, as do most employees in that group.

The control system team uses the shares on their own workstations to exchange large files with each other over the Enterprise Control Network, rather than exchange the files via the space-limited file servers located on the Enterprise Control Network. Of course, only specific domain accounts are permitted to
access these shares. Stuxnet uses the domain credentials of the user logged into the compromised machine to send a copy of itself to the manager’s workstation and activates that copy, compromising that workstation.

In many power plants, the historian manager would routinely access the Siemens WinCC Central Archive Server (CAS) historian server from his workstation over a VPN.

Typically, the administrator uses both the web interface and Siemens OS Client to the historian to access the CAS server. The web interface provides a view of functionality that the historian exposes to users, and the OS Client allows the administrator to access advanced features of the historian, used primarily for configuration and administration tasks.

Since the manager’s workstation is now compromised, the Stuxnet worm contacts the local instance of the SQLServer database “client” on the compromised workstation and discovers the OS Clients’ connection to the WinCC database that is installed as part of all CAS servers. The worm contacts the WinCC SQLServer database on the CAS server and propagates to the CAS server on the Perimeter Network through that database connection. The worm installs itself on the CAS server by manipulating both the CAS database contents and stored procedures within the database. The worm now has a foothold on the Perimeter Network.

Alternative pathways: Some alternate paths of infection of the Perimeter Network include:

    • At many “real world” sites, the Perimeter Network hosts are not patched routinely. As a result, any VPN connection from a compromised host on the Enterprise Control Network to a host on the Perimeter Network using common Windows RPC communications is at risk. Specifically any host on the Perimeter Network with no patch for the 2008 MS08-067 vulnerability would allow the worm to compromise the Perimeter Network.

    • While it does not follow the Siemens security recommendations, it is not unusual for the VPN connections from Enterprise Control Network workstations to the Perimeter Network to not aggressively restrict communications to specific ports and hosts. Often workstations with VPN connections to the Perimeter Network can communicate with any port on any host on the Perimeter Network. In such cases, any Enterprise Control Network workstation with a VPN connection to the Perimeter Network puts at risk every server or workstation on the Perimeter Network with file sharing enabled or a printer connected.

    • A contractor or vendor using a remote access mechanism to provide assistance with the support of hosts on the Perimeter Network may remotely access that network from a compromised laptop or workstation. If the contractor can communicate with any exposed file shares or print spoolers on the Perimeter Network, that would permit compromise of those hosts. If the contractor or vendor’s workstation can communicate with any unpatched hosts exposing the MS08-067 vulnerability, that channel also permits compromise of hosts on the Perimeter Network.

  • While this does not follow the Siemens security recommendations, site administrators on the Enterprise Control Network are known to use file shares to exchange information with servers on the Perimeter Network. Such file shares expose the Perimeter Network to compromise.
SOURCE: How Stuxnet Spreads – A Study of Infection Paths in Best Practice Systems by: Eric Byres, P. Eng. ISA Fellow, Andrew Ginter, CISSP, Joel Langill, CEH, CPT, CCNA ( – Develop best practice guidelines to certify the security and reliability of your infrastructure and information assets

SEARCH: Articles, software & guides //

Premium Membership //

Premium membership gives you an access to specialized technical articles and extra premium content (electrical guides and software).
Get Premium Now ⚡

About Author //


Edvard Csanyi

Edvard - Electrical engineer, programmer and founder of EEP. Highly specialized for design of LV/MV switchgears and LV high power busbar trunking (<6300A) in power substations, commercial buildings and industry fascilities. Professional in AutoCAD programming. Present on

Leave a Comment

Tell us what you're thinking... we care about your opinion!