The PrEP Model: An Introduction

By Trey Herr

How we think about malware (and cyber weapons) affects the way we make policy and conduct research. There is an alternative to the current approach, which approaches pieces of malware as individual objects – classifying code based entirely on its purpose instead of the components it contains. In the next few posts, I’m going to present an alternative model to how we currently think about malware and offer a definition of cyber weapons.[1]

The alternative to thinking about malware as a single unit, described only by its function to destroy or steal information, is to take a modular approach and break malware into its functional components – a Propagation Method, Exploits, and a Payload. The Propagation Method is the means of transporting malicious code from origin to target. Exploits act to enable infection and the operation of a Payload by taking advantage of vulnerabilities in the target system while the Payload is code written to achieve some desired malicious end like deleting data. Breaking out malware into these components might allow researchers and policymakers to consider the unique characteristics of each piece in turn. The botnet infrastructure employed as a Propagation Method in spear phishing attacks for example is quite different from the Payload these attacks distribute. Below, I outline each component in more detail using Stuxnet to provide examples:

Propagation Method: Getting from the Origin to the Target

Propagation is the act of delivering code to the target system; it could constitute an email attachment, compromised web site, or USB stick to jump a physical air gap between computers and may have multiple stages. Stuxnet included a two stage Propagation Method; computers at the centrifuge facility were networked together but likely not connected to the internet. A separate set of Windows machines, configured to communicate directly with the Siemens built Programmable Logic Controllers managing the centrifuges, were air-gapped (given physical separation) from all other machines with no direct link to the internet.[2] The first Propagation stage, including two exploits that had not yet been publicly released, manipulated each computer’s network services into replicating the malware to all connected computers. In all, this first stage Propagation had at least five different Propagation techniques associated with it including a peer to peer communications and update protocol, local area network shares, and the Microsoft local print network software.

Exploits: Entry and Execution

Aiding the propagation method and payload are subsidiary software programs that take advantage of vulnerabilities in computer systems or surrounding networks called Exploits. Vulnerabilities are aspects of a computer system, i.e. flaws, which allow third parties to effect unintended operations.[3] They may be purposefully included features or simple bugs in otherwise functional code but vulnerabilities’ presence doesn’t affect system operation. Exploits are written to take advantage of a particular exploit and provide the digital grease to allow other components of malware operate successfully. Part of the Stuxnet propagation method used an Access Exploit in the Windows Print Spool network service to spread between computers. From an infected machine, Stuxnet would submit a specially formatted print request to another, uninfected, machine. Instead of supplying information for a print job, the request would trigger a remote procedure call, injecting Stuxnet’s code from the original infected computer over the print network to the target machine. Here the propagation method was the network based remote procedure call but the Exploit was necessary to take advantage of a vulnerability in the Windows print software.

Payload: The Purpose of Malware

A Payload is the core content of malware: malicious software designed to execute on a computer system and achieve some predefined goal such as compromise password files or delete data. It could take advantage of code libraries present on a target system in order to execute and may combine several modules, each with a different but complimentary purpose. Stuxnet’s Payload was designed to damage the centrifuge systems at Natanz without alerting facility staff. One module infected the Programmable Logic Controllers for centrifuge rotation; running the affected machines up to just over their maximum design speed for 15 minutes then returning to normal for 27 days before slowing down almost to a standstill for 50 minutes.[4] This month long cycle was written to repeat until centrifuges began to crack from what would appear to be metal fatigue. A second Payload module opened and closed feed and exhaust valves controlling the flow of uranium hexafluoride gas to other centrifuges, disrupting the multi-stage enrichment process.[5] Stuxnet also had an obfuscation module that took normal diagnostic information on the centrifuge rotation speed and fed it into the machine’s Supervisory Control and Data Acquisition equipment so that nothing would appear to change until the machines had broken down. This deception of facility staff was critical to Stuxnet’s operation, as the destructive Payload needed several months to be effective.

This is a different way to think about malware, defined by its constitutive software elements rather than their individual function. Rather than labeling a collection of payloads and exploits as just a “keylogger”, we can think about the function of each component and their combined effect. Substituting a different exploit doesn’t change the function of the malware but it is now a new piece of collected code, which may be targeting substantially different software. The next post will take the PrEP framework and uses it to develop a model for cyber weapons…

[1] These posts are based off of a paper in the Journal of Information Warfare, which you can read here.

[2] Langner, R., 2013. Langer - To Kill a Centrifuge.pdf. The Langer Group.

[3] Mell, P. and Grance, T., 2011. The NIST definition of cloud computing (draft). NIST special publication, 800 (145), 7.

[4] Falliere, N., Murchu, L.O., and Chien, E., 2011. W32. stuxnet dossier. Symantec.

[5] Albright, D., Brannan, P., and Walrond, C., 2011. Stuxnet Malware and Natanz: Update of ISIS December 22, 2010 Report. ISIS, February, 15.