Archive for the ‘Shellcode’ Category

« Older Entries

Tracking Coreflood from Shellcode

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 »

Shellcode analysis — download n’ exec

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 »

Tool for shellcode analysis

Monday, December 17th, 2007

Here’s some favorite c that I use to reverse engineer shellcode that I collect from malicious files, malicious web sites and attacking network traffic:

unsigned char shellcode[] = “”;

void main() {
void (*c)();
printf(”Shellcode it is!\n”);
*(int*)&c = shellcode;
c();
}

Basically, the code creates a buffer that stores your collected shellcode, creates a pointer to a void function empty of instruction, points the function to the beginning of the buffer and transfers control to it, just like an attacker’s exploit. Drop the hex into the array as a c-style string, compile it, and toss it into Olly for stepping and analysis!
We’ll look at a current example from a site in the wild in an upcoming post.

Posted in Exploit, Reversing, Shellcode | 1 Comment »

« Older Entries