|
Archive for the ‘Unpack’ Category
Tuesday, January 19th, 2010
In an early-2009 literary flourish we condemned spammers to hell, discussed the Tedroo spambot’s increased momentum due to the shutdown of other botnets, posted screenshots of the Tedroo spewed pharmaceutical spam and related scam sites, and noted its distribution via malicious pdf files. Tedroo’s increased presence and its distribution is continuing into 2010. As a matter of fact, while the distributors are relying on users’ delays in updating their vulnerable pdf readers like Acrobat, the distributors are actively maintaining/modifying the bot itself — AV scanner results on the repacked binaries are very low as the modified variants are newly re-released.
Vulnerable systems with out-of-date Adobe Acrobat installs are the main focus of the attacks involving the Tedroo spambot. The spambot commonly is being distributed via a set of canned attacks using what appears to be a version of the Liberty Exploit kit. The Liberty pack maintains an effective set of Acrobat attacks, and considering the thousands of Acrobat attacks prevented on ThreatFire systems since the beginning of Jan, the attacks themselves are well chosen — vulnerable versions of Acrobat Reader continue to be readily available, even in this new decade.
Once the malformed pdf’s shellcode is passed control on a victim system, it attempts to download multiple components from another server. In our samples, a system hosted in China. There are several downloads to choose from on the server. The first of the files is a loader, carrying a packing stub somewhat similar to the recent Bredolab packed malware with an outer layer of encryption on top of a UPX packed inner layer. It drops a dll to an alternate data stream of a random file in the windows or system32 directory. It then registers that ADS in the AppInit_DLLs so that the dll is loaded at startup. The dll is loaded, and maintains a long list of paths and executables. Most are related to security solutions (examples are listed below) and system components. It terminates a group of them immediately. It then adds entries for security software to the Restricted Software Policy list in the registry, an AVKill method that we haven’t seen fully described as one elsewhere: HKLM\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers\0\Paths\<SID>
C:\Documents and Settings\All Users\Application Data\PC Tools
C:\Program Files\Common Files\PC Tools
C:\Program Files\Kaspersky Lab
C:\Documents and Settings\All Users\Application Data\Kaspersky Lab
C:\Documents and Settings\All Users\Application Data\Kaspersky Lab Setup Files
C:\Program Files\ESET
C:\Program Files\Panda Security
C:\Program Files\Avira
C:\Program Files\Norton AntiVirus
C:\Program Files\Alwil Software
C:\Program Files\Agnitum
C:\Program Files\Symantec
With that undetected (on the day of discovery) component loaded and AV processes killed, the Tedroo spambot is loaded. In the latest loader variants associated with the bot, we observe an interesting entry point with anti-debug and anti-emulator tricks that can be vaguely described as an abuse of “Modern” CPU Instructions. In this case, the packer implements an unexpected x86 VMX instruction — VMLAUNCH. Versions of reverser-friendly Ollydbg decode it to “sgdt edx” and cannot handle the instruction at runtime, reporting to the user that it does not know how to step into it, while some vendor emulators also have a difficult time decoding it.
Windbg, on the other hand, decodes the vmlaunch command properly as specified by the Intel Reference material, seen below…
Following the malware entrypoint, a windbg deadlisting shows “mov ecx, 0×4fffh”, followed by the vmlaunch. On processors we observed, this setup thows an exception for an Illegal Instruction with ecx = 0×4fffh. The writers of this trick, however, took it upon themselves to force the code to trigger this exception 20,479 times (the decimal representation of 0×4fffh). It’s implemented by registering an SEH pointer to code that simply stores the counter, decrements it, and returns back into the ExcecuteHandler2 function within ntdll that’s within the standard flow of Windows exception handling. Each time, the exception “handler” code returns back into RtlDispatchException and eventually NtContinue, where CONTEXT.eip takes control directly back to the Illegal Instruction location, triggering yet another exception. When the counter finally is decremented to zero, the unpacking stub then modifies CONTEXT.eip on the stack so that flow passes out of this exception loop at ntdll.NtContinue and further into its unpacking stub. Tricky stuff indeed.
 Decrement ecx value within the process CONTEXT struct Continuing on its code path, the code first checks if it’s been run before on the victim system, looking for registry values it creates:
HKCU “Software\Microsoft\Windows\CurrentVersion\Run”
HKCU “Software\Microsoft\Windows\CurrentVersion\policies\Explorer\Run”
HKLM “Software\Microsoft\Windows\CurrentVersion\Run”
HKLM “Software\Microsoft\Windows\CurrentVersion\policies\Explorer\Run”
value: userini path: c:\windows\explorer.exe:userini.exe
It copies itself as an alternate data stream of explorer.exe
c:\windows\explorer.exe:userini.exe
It sets this ADS to load at startup in the various autorun registry entries listed above, and then runs thru a series of sleeps/gettickcout to delay activity and cloak itself.
After a long wait, the spambot calls InternetConnectA and HttpOpenRequestA to contact its hardcoded server and retrieves more spam templates. The resulting spam recently has all led to www . pharm directbook .com, another ”Canadian Pharmacy #1 Internet Online Drugstore”. This behavior is similar to that noted in our past post. The sites have been run for years by a group otherwise known as “Glavmed“, selling knockoff, illegal pills with shifty names like “Viagra Professional”…
In spite of the significant shutdowns over the past year, spam like Tedroo’s continues to mess it all up on the net. Don John couldn’t have tried to mess up a good thing any better himself.
Posted in Commodity Kit, Evasion technique, Exploit, Obfuscation, Reversing, Scams and Monetization, Shellcode, Spam, Trojan, Undetected malware, Unpack, Vulnerability | No Comments »
Wednesday, October 14th, 2009
ThreatFire protected systems have been preventing Urlzone (also known as Bebloh), which has been flying under the radar of most AV vendors, for most of the year. The family is long in the wild and a pernicious one, so why the lack of recognition? Let’s take a quick look at some complexities related to the unpacking stub and the file’s delivery.
Multiple variants of the family implement an unpacking stub that burns through anti-emulation time lock loops intermixed with additive decoding loops, and then transfer control to underlying layers of the unpacking code by making a service pack dependent calculation to the location that control must be transferred to.
All of these calculations are surrounded by garbage code, so let’s strip down the trick to its bare bones: calculations are made, edx is pushed on the stack and control is transferred to that location with a return instruction.
The correct value of edx is arrived at by subtracting a predictable data value copied from a location near the kernel32 module entrypoint to attain the expected value. Kernel32 changes across service packs, so uploading these samples to automation tools may produce varying results depending on whether or not the researcher downloading from the distribution web server indicated the same service pack in the http request on the client system as on the automation system.
So what data may change across service packs and protected OS’s? The data preceding and at the entrypoint of kernel32. The unpacking routine is dependent on finding the values in the Peb (Process Environment Block) for the “InLoadOrderModuleList”, which points to a list of loaded modules (dlls) within the process. This technique is often used in exploitation-delivered shellcode (see skape’s section 3.2.1 on using PEB to find kernel32). The unpacking stub then walks the list to find the pointer to the entry point of kernel32.
A predictable sequence of bytes exists prior to and at kernel32’s entrypoint per Service Pack. The calculation in the this post is meant for XP SP3, any SP prior causes the malware to calculate an incorrect location and exit. That predictable sequence also changes if the entrypoint of kernel32 is hooked. Any jmp instructions will break the control.
Hence, the 0×8b909090 value (the three nop bytes prior to kernel32.EP and the push ebp) for use in a sub from their hardcoded value to calculate the final jmp destination.
Following the sub from edx, ebx is discarded. Edx is pushed to the stack for a ret and the malicious execution continues from there…
Posted in Undetected malware, Unpack | 1 Comment »
Tuesday, May 20th, 2008
In part 1 of keeping strings real, strings were chased around in a disassembler to provide insight into the functionality of a piece of malware. Part two investigates the instance where there seem to be no recognizable strings in the target at all.
When doing a quick skim of a malware file (in this case, ldr.exe md5:007571544614a7646e750a51ccaf2e9e), sometimes you encounter data that looks similar to the below image. In this particular instance, it seems that these strings are encrypted.
Encrypted strings make it very difficult to do quick analysis. Fortunately, a there are a couple of options to get past this small road block. The string can be observed as it is passed around between functions, or debuggers can be used to halt execution when the target string data is accessed.
For this sample, the above strings were followed from the initial cross reference to a function that is self contained. It takes arguments, executes some code, and returns. The code has a loop, operates on individual bytes (reads from pointers into register halves), and performs a few additions. Is this a possible candidate for a string decryption? You betcha.
After walking through the function once in a debugger, it becomes obvious this function decrypts the string to a different buffer. This is an excellent first step, but there are a massive amount of strings in this file. It would be less than desirable to execute this function in a debugger and make note of the result for each and every encrypted string present. There has to be a faster and more elegant way to figure these out. Now what?
Enter Cryptanalysis. This particular function is not very large or complicated, so determining the algorithm used to reveal the strings should not take an unreasonable amount of effort. After determining the algorithm, it is possible to write a program or script to accept the encrypted string data and output the decrypted string.
Below is what the reversed function looks like.
This function accepts what looks like a null terminated pascal string. The first character in the string contains the length (0 to 255), followed by the ciphered string data, then a zero to indicate the end of the string.
The next step is to add the cipher key value to the first encrypted character in the string. This key value starts at 186 (or 0xBA in hexadecimal). On each loop pass, the key is increased by 2 and added to the next character in the string.
For instance, the character ‘a’ is represented by the number 97 (0×61). To encrypt this initial data based on the algorithm above, we would subtract 186 (0xBA). To decrypt it later, 186 (0xBA) is added to the encrypted data.
The result of this 97 – 186 subtraction is 167 (0xA7). This math looks funny, but it works this way when working with individual bytes and their associated range of 0 to 255 (unsigned).
This behavior is due to the wrap-around effect caused by an integer overflow. To see this in action on Windows, open calculator (calc.exe), change the view to scientific mode, then change the number system from decimal (Dec) to hexadecimal (Hex), lastly change the size from “Qword” to “Byte.” Now you can type in 61 minus BA and the result is A7 (167).
Keeping the above math in mind, the algorithm can now be re-implemented using IDA’s built in scripting language (IDC). The script will be need to be passed the source string data, extract a byte, add the key to the byte, store the result, add 2 to the key, and repeat this process till all bytes in the string have been processed.
The Byte() function will be used to extract the byte from the “address” of the string’s beginning found in IDA’s dissassembler window. The Message() function will display the deciphered byte in the message window, and the PatchByte() function will modify the representation of the byte inside of the disassembler window. (Note: PatchByte() can be commented out to prevent the script from actually modifying any data, it will simply print the result in the message window)
The script representation of this algorithm reconstruction is found in the image below, and the idc script itself can be downloaded from our PC Tools ThreatFire forum, where you can log in and scroll down the thread for 186plus2_decipher.zip:
Now it is time for some fun. An encrypted string is selected in IDA for decoding and the script is launched. The result:
Posted in Obfuscation, Reversing, Unpack | No Comments »
|
|
|
|
