2

I ran file on some Linux malware ELF files that I've acquired over the last couple of years. I noticed some oddities:

ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.0.0, not stripped

ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.15, not stripped

ERROR: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linkederror reading (Invalid argument)

ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), statically linked, stripped

One ELF file has an entry point of 0xc07068, but it's some kind of "packer", the unpacked executable (a Kaiten botnet executable) is at the usual entry point.

The "ERROR" noted above is from an ELF file with PHeaders, but not SHeaders. The "section headers" have been carefully mangled so as not to be readable by any program that believes in ELF headers The ELF loader in Linux kernels only reads the PHeaders, so that file can be executed.

My question is: who compiles this way, and how? I mean, Linux 2.0.0 was released 12-Jun-1996 according to kernel.org. An executable for Linux 2.0.0 might or might not be very portable, but how would you keep an ancient system for compiling malware running? It's not impossible to get an executable's entry point at some arbitrary address, but you do have to go out of your way, just like you'd have to go out of your way to mangle an executable's SHeaders.

Bruce Ediger
  • 4,552
  • 2
  • 25
  • 26
  • 1
    Couldn't this have been simply mangled after compilation by a post-processor, maybe to fool a malware detector? – Ari Trachtenberg Jun 30 '15 at 21:37
  • @AriTrachtenberg - certainly. The post-processor could be any hex editor, in the case of the mangled SHeader executable. And maybe such a trick fools anything that uses libelf, but it won't fool anything more robust - it doesn't fool the kernel's loader. But why keep a Linux 2.0.0 machine (or VM) around? What's the advantage there? – Bruce Ediger Jul 01 '15 at 16:05
  • =file= just looks for magic bytes, which are easily manipulated. It could have been compiled anywhere. – Ari Trachtenberg Jul 01 '15 at 22:08
  • @AriTrachtenberg - The linux "file" command does a good deal more than looking at magic bytes: https://support.f5.com/kb/en-us/solutions/public/16000/300/sol16347.html "file" has an ELF file parser, and it caused some problems. Note that the "strings" utility uses libbfd, also parses ELF headers, and also had a vulnerability: http://lcamtuf.blogspot.com/2014/10/psa-dont-run-strings-on-untrusted-files.html – Bruce Ediger Jul 02 '15 at 02:00

0 Answers0