Hint for our fellow researchers who might wonder what they have been missing:
1. Fire up your WinCC system.
2. Infect the system with Stuxnet. Don’t be shy here — Stuxnet is a friendly virus, it only attacks the bad guys. You may even copy the compromised DLL to your target by hand if you don’t want to worry about all the LNK stuff. (Don’t forget to rename the original DLL first though.) The main attack is all in the DLL, it’s standalone.
3. Connect to any of your S7 PLCs.
4. Watch the traffic in Wireshark. You’ll see Stuxnet after five seconds. Don’t worry to miss it. It will reoccur after five seconds. Than again, and again. It’s a constant loop. Really wasn’t that difficult, was it?
What you see is the fingerprinting of Stuxnet’s main operative thread. To give you a little head start here, look at the video capture. This is what you’re going to get.
As you can see, Stuxnet reads DB 890 (no matter if you have configured it or not).
To relate that to code, load the Stuxnet DLL into your debugger. Set a breakpoint at memory location 0070D9F9. This is the entry point to the executive routine of the operative thread. To save you the hassle of trying to make sense out of all the pushs and pops, we have added symbols and comments that explain what’s going on. (You won’t find the symbolics in your DLL code.)
What you see in the code and comments is a lot of hard forensic evidence. To give a short explanation, Stuxnet reads DB 890 and checks if type & length match. If not, it does nothing and exits. If Stuxnet does find a match, it inspects the first DWORD of the data block and checks if it contains the string ‘HNDS’. (At this time, some folks should get nervous.) If the match isn’t found, again it exits. If Stuxnet finds a match, it modifies the content of the second DWORD to the content that you see in the screenshot and writes it to the PLC. If you want to see the manipulations in Wireshark, you need to configure properly so that Stuxnet gets a match in 890.