Android.Lightdd (the name is derived from the presence of the additional Trojanized package ending in the word ‘lightdd’) has been dubbed as the follow up to Android.Rootcager AKA Droid Dreams, one of the first threats seen in the wild that attempted to use an exploit to root an Android device. Although the original reports on the discovery of the threat called out five accounts, Symantec has found additional publisher accounts under which apps were repackaged (at the current time all of these account have been disabled).
The key point to note is that even though the news of the return of ‘Droid Dreams’ has created a bit of a stir with approximate high download rates being quoted - due to the fact that the threat was available through official channels - unlike its predecessor, this threat does not carry out any system level exploits and does not require the infected user to carry out any complex steps to restore the device back to the pre-infection state.
This threat follows a very formulaic pattern. In addition to containing the malicious code base, which runs as a service called ‘CoreService’, the repackaged app also contains a configuration file ‘prefar.dat’ (included in the assets folder in the apk file). The contents of which (encrypted in DES) are three urls, which the threat uses to establish the malicious host to contact. At this point in time, all three hosts are offline.
Once a connection to the host is made, the threat is capable of sending back device specific information related to the infected host. Information includes the Model, Language, Country, IMEI, IMSI, OS Version, etc., as well as the list of package names installed on the infected device. The one unique field hard coded into each package is the product ID, which we believe is being used to distinguish the package that was responsible for the infection.
At its core, Android.Lightdd is a downloader Trojan, but with certain caveats. The threat is subject to the Android security model, therefore any download attempts will not work, as long as the user does not consent to the installation of the suggested app.
There are four possible ways an infected host could be recommended to download an additional payload. Links could be presented as “Market Prompts”, “Web Prompts”, “Update Prompt” and a “Download Prompt”. Minor variances separate the different methods, and suffice to say, the end results are the same. The more concerning part is that Android Market place links were being used as download repositories.
What still remains a bit of a mystery and subject to speculation is the bigger picture. All apps discovered until now contained more or less the same base code, i.e. they all were downloaders. But what is the point of that? Information harvesting, followed by the downloading of additional downloader, doesn’t really add up. Or was it to download additional threats with more advanced features later on?
If you suspect that you might be infected by this threat (e.g. spotted a running service in the background called “CoreService”), download the latest update to Norton Mobile Security and do a full scan to protect yourself.
By: Irfan Asrar
The key point to note is that even though the news of the return of ‘Droid Dreams’ has created a bit of a stir with approximate high download rates being quoted - due to the fact that the threat was available through official channels - unlike its predecessor, this threat does not carry out any system level exploits and does not require the infected user to carry out any complex steps to restore the device back to the pre-infection state.
This threat follows a very formulaic pattern. In addition to containing the malicious code base, which runs as a service called ‘CoreService’, the repackaged app also contains a configuration file ‘prefar.dat’ (included in the assets folder in the apk file). The contents of which (encrypted in DES) are three urls, which the threat uses to establish the malicious host to contact. At this point in time, all three hosts are offline.
Once a connection to the host is made, the threat is capable of sending back device specific information related to the infected host. Information includes the Model, Language, Country, IMEI, IMSI, OS Version, etc., as well as the list of package names installed on the infected device. The one unique field hard coded into each package is the product ID, which we believe is being used to distinguish the package that was responsible for the infection.
At its core, Android.Lightdd is a downloader Trojan, but with certain caveats. The threat is subject to the Android security model, therefore any download attempts will not work, as long as the user does not consent to the installation of the suggested app.
There are four possible ways an infected host could be recommended to download an additional payload. Links could be presented as “Market Prompts”, “Web Prompts”, “Update Prompt” and a “Download Prompt”. Minor variances separate the different methods, and suffice to say, the end results are the same. The more concerning part is that Android Market place links were being used as download repositories.
What still remains a bit of a mystery and subject to speculation is the bigger picture. All apps discovered until now contained more or less the same base code, i.e. they all were downloaders. But what is the point of that? Information harvesting, followed by the downloading of additional downloader, doesn’t really add up. Or was it to download additional threats with more advanced features later on?
If you suspect that you might be infected by this threat (e.g. spotted a running service in the background called “CoreService”), download the latest update to Norton Mobile Security and do a full scan to protect yourself.
By: Irfan Asrar
