Android Worms And How To Prevent Them

Recently, a malware attack in China infected around 100,000 Android devices in a few days. FireEye described the attack in their blog, and christened it XXShenqi. They call it a phishing attack, but I prefer the term worm, in that infected devices sent SMS messages to the owner’s contact list attempting to convince them to install the malware on their own device. Traditional worms such as Conficker attempt to spread to other devices directly over the network. The XXShenqi worm required the intervention of the device owner to be tricked into installing the malware, so it was a worm spreading a Trojan. I like to keep the word phishing for attacks which attempt to steal login credentials.

It’s interesting to compare this attack with the SpamSoldier worm that hit US Android users almost two years ago. The same basic technique was used: infected devices sending SMS messages to spread the infection. However, there were a couple of important differences. While the XXShenqi worm messaged the victim’s contact list, SpamSoldier sent messages to a list of phone numbers downloaded from a command and control server. Since a message from someone on your contacts list is more likely to be trusted than a message from a random number you have never seen before, this gave a significant advantage to XXShenqi. In addition, Chinese Android owners are not served by the Google Play Store, so they are used to downloading apps from third party sources. Most US users only download from Google Play and are suspicious of unlicensed libraries. This meant that the infection rate for XXShenqi was much better. FireEye stated that around 20,000,000 SMS messages were sent and about 100,000 devices infected. That’s an infection rate of 1 in 200. For SpamSoldier we estimate the infection rate was around 1 in 1,000.

XXShenqi is said to have been written by a bored student as an experiment. There appears to have been no attempt at monetization, though there was a spyware element. The malware emailed copies of all the SMS messages on the infected machines back to the author. SpamSoldier, on the other hand, attempted to monetize using the free gift card scam that was shut down by the FTC a few months later. Both attacks used a single server for distributing the malware, so distribution could be stopped by taking down or blocking access to that server. The SpamSoldier attack used a server in Asia for distribution of malware and command and control of the infected device. However, in the US the big mobile phone carriers are also Internet backbone providers, so it was possible for them to block access to that server without physical or legal access.

Though both of these threats were fairly short lived, it is easy to see how a determined malware author could write a far more robust worm of this type – for example, hosting the malware on a large number of compromised domains rather than a single server, and using a domain generation algorithm and/or fast flux to protect the command and control server against takedown. Even at the relatively low infection rate of SpamSoldier we still saw a brief period of exponential growth before the takedown. If an attack of this type could resist takedown for weeks or months rather than days, it could pose a significant threat.

However, any large scale attack of this type will generate a lot of similar SMS messages. In order to protect against attacks of this type, it is important for carriers to implement content based filtering of malicious SMS messages. Furthermore the filtering has to be able to respond rapidly enough to the exponential growth of worm based attacks. That’s why Cloudmark recommends an automated approach based on messages signatures and user feedback to the GSMA’s 7726 Spam Reporting System. In the case of SpamSoldier, 89% of the malicious messages were reported after they were being flagged as spam by the Cloudmark Global Threat Network. However, not all US carriers had content based filtering in place for that attack. If they had, the attack would never have been able to spread.


Leave a Reply

Your email address will not be published. Required fields are marked

Learn More About Cloudmark
Our Products
News and Events
Site Map  •  Privacy Policy  •  ©2002–2017 Cloudmark, Inc.