Monday, November 3

Research

Okay, so MS08-067 Worm(s). I got some intel from some various listservers that I belong to about a new worm (or worms) that were starting to be seen in the wild. So I got a few url’s to play with and started poking around. Note, these are not all the url’s that I tried to get the exploit/worm from. They are not all of the same worm, and they may or not be related... BTW -- I am not a very good malware analyzer, Just an FYI.


It appears, one of the variants of this worm that I am looking at attempts to spread, not only though network vulnerabilities (08-067), but also through P2P networks like Emule.


So, I tried to get one of the files, named 6767.exe in this case. This EXE file does several things, some of which are very unclear as to the reason... as I said, I’m not a malware guy...




This exe downloads, and upon execution (again, in my particular sample, I am sure it will change), from a network perspective, on MY machine, it didn’t do anything. I have read several write ups of the 6767.exe variant, and I saw what it was “supposed” to do. But in my particular example, it didn’t do anything. I don’t know if it some kind of virtual machine detection in it, and that’s why it didn’t execute? I don’t know. Just throwing that out there. Maybe it has some kind of sleep function so that it won’t execute right away.. making reverse engineering difficult. (boring!) For a list of what it does to a machine, take a look here. At this point I am more interested in how it spreads, not really what it does to the machine.


So, I downloaded a second sample “10wrjcenew.exe”, and executed it.


It tried to download two files, the first was “mimi.1268772” from ls.lenovowireless.net, and the second was pp.av from “218.4.137.213”. After this pp.av file was downloaded, the malware then attempted to register my computer on ce.10wrj.com. With this string:





This connection succeeded, but was immediately terminated. Since this particular HTTP connection was tried over and over again to register, and since the mac address is a vmware mac address, I can only guess that the machine receiving the Client Registration knows which mac addresses are vmware and doesn’t attempt to infect those? Just a theory. I found some interesting information about this here.


The two files were saved, actually on the desktop (because the malware I had executed was sitting on the Desktop), and were named svchost.exe and winlogon.exe.


So, you can tell that this is a completely different worm from the first one I tried.


Then, after that, scanning commenced on port 139 to try and find other hosts. Now I have a double NAT going on here, (172.16 addresses (vmware) are being bridged out to 192.168 (home network) addresses, then translated to the internet.. I didn’t notice it, but the worm must have looked up my ‘external’ address at some point because the malware never did scan my local subnet, it only scanned the public address scheme of my local subnet. Upon further review of the malware through other websites, I also found this to be the case.


After successfully connecting (which didn’t happen in my case) on port 139, it then exploits the other machine on port 445. Which is detected by Snort through rules:


[1:7224:8] NETBIOS SMB-DS srvsvc NetrPathCanonicalize unicode little endian overflow attempt

[3:14817:1] NETBIOS SMB srvsvc NetrpPathCononicalize unicode little endian path cononicalization stack overflow attempt

[3:14783:1] NETBIOS DCERPC NCACN-IP-TCP srvsvc NetrpPathCononicalize little endian path cononicalization stack overflow attempt


So I suggest you check out the newest subscription ruleset through Sourcefire at www.snort.org. Like I said, I am not a malware guy, I just did some clicking around to see what was out there and what it did. I haven’t reversed a binary in almost 4 years. Who has the time!? ;)


Subscribe in a reader

No comments: