One of the most important aspects of a good computer worm is how well it can spread. Every piece of malware has their own way of spreading, whether it be by the USB Autorun feature, email spam, traversing and copying itself to the network, or other ways; each piece of malware is unique.
One thing I want to mention here is the method of spreading payloads via Bluetooth. As more and more devices have Bluetooth these days (computers included) it’s getting to be a more standard way of communicating between computers. Bluetooth offers many services, such as network sharing, file transfer, printer sharing, and much more – most of which can be exploited for the benefit of the malware author that decides to utilize this protocol.
One form of worm — for example, Conficker — lays dormant until it is activated. Usually in this state of dormancy, the malicious payload isn’t on the infected computer anywhere. This leaves the actions performed when the malware awakens a secret, to make it harder to defend against.
In a closed-knit community such as a business or campus where the majority of computers share the same build and specs, you may find that all of the computers house the ability to enable Bluetooth sharing. Because Bluetooth is device-to-device, all devices have to be somewhat close to each other (or in some cases linked by more devices with Bluetooth in-between).
To put my idea simply, is to split and encrypt a payload into a set amount of pieces relative to the target number of computers infected. If you’re planning on infecting 200 computers, consider 20 pieces. 500 computers? Try 50 pieces. When your worm (without the payload) infects a computer, leave behind one piece. When it’s time to enable your payload, send out a request to a service you set up to listen for instructions on each computer to send its payload piece to all nearby Bluetooth-enabled devices. Sending payload samples to uninfected computers shouldn’t be a worry, because in order for Bluetooth to work, both computers need to set a unique key that matches the other computer. If a computer isn’t infected with your worm, they will see that you are trying to send them a file, but either, 1) They won’t have the key to accept it, or 2) They’ll be able to accept it but not be able to do anything with it.
After sending out and receiving the payloads of all nearby Bluetooth devices, each device can then send out all their parts to more computers – kind of like a rippling effect. All computers that were unable to be reached by anything other than the outside row of the epicenter are now being sent the payload pieces of all computers nearby – from one computer. Then they can send those pieces to another computer, and those pieces to another computer. Eventually, every computer in your little community should have all pieces of the payload. It is then when your script puts them together and executes your payload.
Coding tip: To prevent people who reverse engineer your worm before your payload is distributed to find out how many pieces there are (which would help in the collection and analytical processes), consider having a loop in your code to keep trying all possible combinations of what order to place the code in until it compiles with no errors. That way, nobody can tell how many pieces there are or what order they go in.
The downfall of this idea is the ability to turn on and off Bluetooth. An attack of this nature can be prevented if just one piece of the payload is stopped from spreading – if all computers with a copy of that piece are shut down or have Bluetooth disabled. That is why an ideal amount of pieces would be about 10% of the target infected computers – there’s plenty of duplicates. But still, it’s not reliable enough without a helping hand; perhaps some code in your worm that disables disabling Bluetooth, or just enables it when it receives instruction to spread the payload out?
