The creators of the SymbOS.Exy family of threats are at it again. They have resurfaced with yet another signed Symbian threat: SymbOS.Exy.E. New Certificate Previous ones used with SymbOS.Exy.A, SymbOS.Exy.B, and SymbOS.Exy.C. Unlike the previous versions of the threat that used provocative names such as “SexySpace” and “SexyView”, the new version is circulating with the name “LanPackage”, pretending to be a system enhancement /language pack add-on. A distinct feeling of Déjà vu is how I would best describe examining this threat. Not only is the code base largely the same as previous editions of the threat, but so is main the method of propagation. Once infected, the threat silently sends multimedia messaging service (MMS) messages to randomly generated numbers, asking the recipient to click on a link to download and install a copy of the threat from a malicious server. One slightly obvious distinction in the latest version, is the authors unusual incorporation of a skull image in the message sent out, in addition to the usual suggestive text meant to entice the recipient to download and install the threat. If you think about it, the image could be seen as taking away from the author’s overall message of trying to gain the user’s confidence, just as a warning label would on a packet of cigarettes. Yet despite this and the important fact that the content certificate and the publisher certificate used to sign the malware were revoked by “Symbian Signed”, the threat has managed to effect a large user base in China, where a large percentage of users had revocation checking turned off on their devices. The threat gathers information such as the phone type, the International Mobile Equipment Identity (IMEI) number, and the International Mobile Subscriber Identity (IMSI) number. It then opens a Web browser and sends an HTTP request to the following URL: http://[REMOVED].com/Jump.jsp?Version=2.0&PhoneType=[PHONE TYPE]&PhoneImei=[IMEI NUMBER]&PhomeImsi=[IMSI NUMBER]&Source=0& Interestingly enough, it seems that not only did the author decide to reuse the same code base for the threat but also to revive the same server-side code (Java sever page scripts) on the malicious server where the threat reports to manage the content retrieved from an compromised device. (Obtained by Symantec Security Response as a result of a bug in the settings used by the malicious server.) Another interesting point of this threat is the redirection used by the server-side code to direct traffic to a social networking site. Based on the previous history of this threat, I would not be surprised if the next few versions of this threat were to turn up in the next few months. Special thanks to John McDonald for researching the threat.