|
Archive for the ‘Shellcode’ 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 »
Friday, June 13th, 2008
Sometimes, it can be surprisingly difficult to get malicious code removed from servers. It can be due to a lack of server support by the owners and their support staff, a lack of responsiveness from the ISP, or an intended scheme to profit from malware distribution, as with the groups involved at the RBN this past year.
It’s just as surprising when users’ systems are getting attacked with malcode that’s been in circulation for at least five years and right now, it’s almost completely undetected by the major av vendors. Here are some scanning results on the executable. Four of thirty two scanners is not pretty:
Anyways we are observing some download and execute shellcode attacking user systems that pull down the malicious file from a server (that server’s admin, the owners of the site, and the ISP have all been contacted over the past couple of days. At least the ISP got back to us with a low priority ticket). Here is an example of the malcode calling “urlmon.UrlDownloadToFileA” on hxxp:// 20x.x16.xx.xx/ white.ccs and copying the undetected “AFCode” or “CoreFlood” variant download to c:\index.tmp. We use a tool and process that we posted last year for shellcode examination:
And here is the call to “kernel32.Winexec” to get that file started on the system, which drops and loads its dll file:
The binary, c:\index.tmp, doesn’t carry much of an unpacking stub. We see more xor loops and import redirection tricks than anything, which makes it unusual that the AV crowd can’t keep up with this one. It drops a set of unusual looking dat files, and adds CLSIDs and an unusual ShellIconOverlayIdentifiers registry entry for startup. Inside the dropped dll, we find a slew of strings that suggest this malicious component is simply reused Coreflood code:
AFCORE
Removing AF from the system . . .
AF up time: %t
Flooding %s . . .
Flooding of %s has been completed
Processing diskflood log file %s . . .
The file immediately POSTs information about its host operating system, version of the software, etc, back to another server over http, among other things.
It’s not especially fun to see this coreflood family back in the wild. Coreflood seems to have caused problems for individuals performing online banking in the past few years, as the Secret Service found it on Joe Lopez’s laptop in the disturbing BofA v Lopez. But I suppose we’ll never really know for sure about that one. It was settled out of court, and neither side will respond to repeated calls regarding their own settlement.
Update: over the weekend, the malicious “white.ccs” file was silently removed from the server. And the ISP handling the problem interestingly deleted the support ticket they had issued for my request.
Posted in Security breach, Shellcode, Targeted attack, Undetected malware | 3 Comments »
Tuesday, December 18th, 2007
In a previous post, I mentioned that we could use c code to analyze some shellcode currently being posted in the wild by malicious web site operators.
These malicious websites are delivering malware by exploiting several Windows based vulnerabilities. The websites attack visitors by targeting vulnerabilities in .ani file parsing, .wmf file parsing, and rtsp content-type string parsing in the QuickTime plugin.
In our labs, we visit these web sites with vulnerable systems, allowing the pages to compromise the systems. We then analyze the techniques being used. Let’s take a quick look at a major part of the attack — the shellcode within the delivered malformed wmf file. We’ll take a look at the low level data content of the malformed file itself:
After seeing a lot of these malformed files, you can spot the shellcode right away. I did in the above image after a quick visual scan, but sometimes details of the file format need to be known to find the shellcode on the first try.
We copy out the string of shellcode hex data into a c-style string, like this one:
“\x83\xec\x10\xd9\xee\xd9\x74\x24\xf4\x58\x33\xc9\xb1\xdb…”
I copy it into the buffer in the c file from the previous post, and the assignment will look like this:
unsigned char shellcode[] = “\x83\xec\x10\xd9\xee\xd9\x74\x24\xf4\x58\x33\xc9\xb1…”
I compile it using gcc, but you can use the cl.exe Microsoft compiler if you would like — whatever c compiler should be fine. I’ve never seen a problem with substituting one for another:
C:\sh\>gcc sh3ll.c -o sh3ll.exe
The compiler emits an expected warning that can be ignored, and now we have an executable to work with. We’ll run it in Olly to its entry point, and then search for the beginning of the shellcode string in memory. When we find it, we’ll set a memory access break point on that memory location and then let the process run to that point by hitting f9.
When the debugger arrives at this starting point for the shellcode, the debugger shows us a very strange listing — “jno” instruction followed by a bunch of “cnq” instructions? The listing looks very strange:
We hit f7 a few times and notice “xor byte ptr ds:[eax+12], 99″, followed by a loopd instruction that takes us back to a few lines prior. This loop is an xor decoder loop, implemented in this shellcode because we are exploiting BoF, and usually that means we are attacking a string handling flaw. Any “00″ or null bytes in the code will likely crash the code, as explained in chaps 3, 7, 9.
We also notice that ecx is set to “0xdbh” at 0040200e, meaning that this loop will decode the subsequent 219 bytes of data:
We can continue stepping through the code with f7, watching the decoding taking place, until ecx decrements to zero. When it finishes, we step through a bit more slowly.
Stepping into the instructions with f7 now reveals the code searching for kernel32’s location in the process space using the common and reliable technique of parsing the PEB and its module initialization linked lists. It then searches for LoadLibraryA, ExitThread, and WinExec win32 api calls. It loads urlmon and finds URLDownloadToFileA. These calls all tell us that this shellcode’s functionality is download and execute — and we can observe the url strings that the code is communicating with.
Download and execute shellcode like this happens to be some of the most prevalent shellcode that we see served up by malicious web sites.
Hope that you learned a few things about the sorts of techniques we can use to analyze shellcode and its behaviors. Let me know what you think of it!
Posted in Exploit, Reversing, Shellcode, Vulnerability | No Comments »
|
|
|
|
