Mobile malware – same attacks – different pathogens

Mobile malware – same attacks – different pathogens

I’ve been blogging about mobile attacks and how they can be different than attacks on more traditional platforms. For example, I wrote about:

Now I’ve turned my focus to mobile malware. Like phishing and pharming, malware has shown considerable staying power on traditional devices and evolved to work with mobile devices. The theory of malware, or self-reproducing code at least, can actually be traced back to 1949 with early experimental code and exploits in the 1970s. Today malware like CryptoLocker, Zeus and of course Stuxnet are part of our shared industry vernacular. 

Mobile malware traces its roots back to a mobile virus called Timofonica in 2000. Today there are robust examples like Ghost Push which was discovered late in 2015. Ghost Push is a type of malware for Android devices that gains root access on the compromised device and is virtually impossible to remove without re-flashing the firmware. Ghost Push drains system resources and battery life, pushes advertisements and can download additional malicious software.

But it’s not just Android devices that are vulnerable. In my blog about pharming, I wrote about XcodeGhost and its variants which also were discovered in late 2015. XcodeGhost is a nefarious version of Apple’s integrated development environment,  Xcode. If an app was developed with XcodeGhost it could be potentially compromised even though the developers using the XcodeGhost programming framework may not have had malicious intent. Once they submitted their app to the App Store, the “Ghost” came along for the ride and could be remotely controlled to have the victim share sensitive information or be directed to malicious websites.

So what’s special about malware on mobile?

As with phishing and pharming, following a malicious link through the browser, email, social media and the like are all vehicles for exploitation on a mobile device. But apps are what really makes mobile a different target.

A malicious app can record sensitive information and send it to the attacker, dial premium-rate phone numbers or simply make your phone unusable. Many pirated and cracked apps also contain malware. For example this often occurs when sideloading apps.

On Android sideloading can be done by downloading apps that are not from the official Android Market by allowing “unknown sources” within the security settings. An Android device can also be rooted for more flexibility and potentially risk. For iOS it’s a bit more complicated, but can be achieved by installing Xcode on a Mac and following a number of steps for jailbreaking the device so you can get apps that are not from the Apple AppStore. But don’t think that if the iOS device is not jailbroken and one refrains from sideloading that there is 100 percent security. AceDeceiver is a perfect example of malware that works on non-jailbroken devices and was found to be stealing Apple IDs and passwords in early 2016 via apps downloaded from the Apple AppStore. 


Also, if you’ve ever installed an app on an iOS device from an organization’s enterprise app store, common for EMM solutions, you probably recall your iOS device asking if you want to trust the developer of the app you’ve downloaded, at least for the first time you install an app signed by that particular developer. In that case the app can be trusted through Settings, General, Device Management. This is another mechanism that attackers target.

The bottom line is that regardless of Android or iOS, there are a number of mechanisms to get apps on a device and those apps may contain malware. Once installed, malware can do any combination of nefarious actions already outlined as well as leak data, usually over SSL communication to a nefarious or compromised destination site and steal information such as files, histories, cookies and passwords.

This article is published as part of the IDG Contributor Network. Want to Join?

Insider: These ransomware situations can result in colossal outcomes
View Comments
Join the discussion
Be the first to comment on this article. Our Commenting Policies