Hi all,

Today I came across a very strange problem... there was a new malware I had to analyse, but strangely it was impossible to load it into OllyDbg (cannot laod, no matter what event options I was using), no PE editor got along with it (they all reportes the exe was not legal), and in a VMWare the executable didn't run (not enough space available); but I was told it's running on a standalone system (not virtualized). I couldn't confirm that definitely yet, because I have currently no standalone system available as victim. But the guy who let it run there has the same md5sum, so I guess he used the same binary.

By looking into a hexdump of the file, I found that in the header there are a lot of 0x20 (spaces) where I'd expect 0x00 bytes. Here's the start of the hexdump (done using sfk):



If you look for instance at offset 0x3c, where the PE header offset is expected, you find 0x20e0, and of course there's nothing there. But, at offset 0x00e0 you can see the "PE".

Either this executable is really fucked up, I'm plain stupid, or there is some issue that such "executables" can somehow be started anyway? Maybe some feature I'm not aware of...?

Thanks for any help,
klaymen

[EDIT] Hmm I think I found a trace, seems to have to do with microsofts "Rich format"... still I can't yet make much sense out of it.

Rich Format? Don't see the link to it. It seems more likely to me that this is a trick to fool pe editors and things like that. If you say that this exe can be loaded by windows, then the windows loader is only considering the first byte of e_lfanew. Just replace the initial 0x20 with 0x00 and you'll have a 100% working exe again. Not that I tried, but I'm assuming so.

Edit: I tried to modify the e_lfanew value the same way and it doesn't work for me on my winxp.

Some crappy webservers tend to replace zeroes with spaces for files with "text/plain" mimetype, which might be assigned to .exe files if the server is not configured properly.

Thanks, I'm not yet 100% sure but I think I found the problem. Indeed all zero bytes in the files seem being replaced by spaces - I suspect not by the webserver, but by opening the exe in a notepad and writing it back (stupid hackers).

By asking again the other guy I now know he didn't calculate the md5 on the very file he successfully started, but made a second download. Actually this very malware URL seems to return different binaries (note that the host in the URL is an IP address, so no flux stuff or so). I suspect there's some kind of load balancing that redirects request to different backend servers, and one of the binaries there is just bogus. So finally it was no RCE issue at all ...

regarding the server serving different binaries, it may be checking the User-Agent in the GET request as well to decide what binary to serve.

Thanks - and yes, meanwhile I'm sure that source IP address as well as user agent are evaluated by the webserver.