Our analysis of Stuxnet has been ongoing for some time now, although we have not posted any information on our blog about it we have been continuously analyzing the threat since it was discovered earlier this year. Initial investigation into the threat pointed to a command and control infrastructure as the method to control the threat. The command and control servers used were taken offline shortly after this control mechanism was discovered. Our continued research has revealed that as well as being controlled via a command and control infrastructure, the threat also has the ability to update itself via a peer-to-peer component. Infected machines contact each other and check which machine has the latest version of the threat installed. Whichever machine has the latest version transfers it to the other machine and in this way the worm is able to update itself without contacting a central command and control server. P2P networks are often used for the very reason that they are difficult to take down as there is no central point of failure. The creators of Stuxnet were aware that they might lose control of their command and control servers so they built in a P2P update function to prepare for that eventuality. The P2P component works by installing an RPC server and client, when the threat infects a computer it starts the RPC server and listens for connections. Any other infected computer on the network can connect to the RPC server and ask what version of the threat is installed on the remote machine. If the remote version is newer then the local machine will make a request for the new version and will update itself with that. If the remote version is older the local machine will prepare a copy of itself and send it to the remote machine so that it can update itself. In this way an update can be introduced to any infected machine on a network and it will eventually spread to all other infected machines. All of the P2P requests take place over RPC as outlined below. The RPC server offers the following routines:
- 0: returns the version number of Stuxnet installed - 1: Receive an exe and execute it (via injection) - 2: load module and executed export - 3: inject code to lsass and run it - 4: Builds the latest version of Stuxnet and send to remote machine - 5: create process - 6: read file - 7: drop file - 8: delete file - 9: write data records These routines are called as outline here:
[Example of an old client requesting latest version of Stuxnet via P2P] The RPC client makes the following requests:
3a. If the remote version number is older then 4a. Prepare a standalone exe of the local Stuxnet version. 5a. Send the exe to the remote machine by calling RPC function 1. All of this means that even though the command and control servers for Stuxnet have been taken offline sometime ago, the attacks may stay be capable of updating and controlling the worm via this P2P communication channel. We are preparing a full technical paper about Stuxnet and will be presenting it at VB 2010 in Vancouver on Sept 29th.