When ISC reader Yin reported earlier today that one of their servers had been hacked via the Apache Struts remote command execution vulnerability (CVE-2013-2251), at first this was flagged as "business as usual". Said vulnerability, after all, is known since July, and we've been seeing exploit attempts since early August (diary here). So it wasn't quite a surprise to see an unpatched internet-exposed server subverted. Given the rampant scanning, it was more a surprise that it had survived unscathed until now.

As a result of a successful attack, the bad guys modify the core index.jsp on the affected server, to include a snippet like the following:

The associated site is still live, which is why the above is an image and not a clickable URL. If you still insist to go looking, be careful, and don't blame us!  Leaving the web server and Struts vulnerability aspect of things, let's now look at what's lurking on that namu-in site:

Yup, there's an APPLET tag. A Java exploit again, it seems. Oracle Java is the true gift that keeps on giving...!

daniel@foo3:~/malware$ ls -al Init.jar
-rw-r--r-- 1 daniel users 49019 Oct 24 16:04 Init.jar
daniel@foo3:~/malware$ md5sum Init.jar
714ef7f35f2bac61c4bace8706f88b98  Init.jar

daniel@foo3:~/malware$ unzip Init.jar
Archive:  Init.jar
  inflating: META-INF/MANIFEST.MF
  inflating: Print.class
  inflating: Init$MyColorModel.class
  inflating: Init$MyColorSpace.class
  inflating: Init.class

The presence of the "MyColorModel" and "MyColorSpace" files in the JAR archive suggests that this could be an exploit for CVE-2013-2465, the 2D/AWT vulnerability which affects all Java Versions up to 1.7_21. On closer investigation, this is confirmed, Init.class indeed exploits CVE-2013-2465, and then calls Print.class, which in turn seems to create a file named "mspaints.exe":

The content of the file is drawn from the variable "data" or "data1", depending on the OS version encountered. Both these variables are defined within the "Print.class":

Sequences of 7777... are kinda rare in real world EXEs. A corresponding series of zeros (00) would be a lot more common. And look how the file starts with "3A2D".. if this is a real EXE then these first two bytes would have to be "MZ" (5A4D). So .. this "data" array is probably just XORed with 0x77?  Let's try:

daniel@foo3:~/malware$ echo "3A2D" | perl -pe 's/(..)/chr(hex($1)^0x77)/ge'
MZ

Busted! :)

Feeding the entire two "data" arrays through the same Perl operation turns the hexadecimal set into binary files, all while XOR-ing every byte with 0x77:
daniel@foo3:~/malware$ cat data.hex | perl -pe 's/(..)/chr(hex($1)^0x77)/ge' > data.exe
daniel@foo3:~/malware$ file data.exe
data.exe: PE32 executable for MS Windows (GUI) Intel 80386 32-bit
daniel@foo3:~/malware$ md5sum data.exe
cd2dd181257375c840f13988c8c7b6d5  data.exe

Searching for this MD5 hash on VirusTotal https://www.virustotal.com/#search gives us a result with a rather dismal 3/47 detection rate. But at least someone else already uploaded it earlier today.

The next stage of the analysis is now on the two EXE files, data.exe and data1.exe. This task is - commonly - quite a bit more tricky than just reverse-engineering JavaScript or Java, because static analysis (like we did on the Applet) can be quite reliably thwarted on an EXE, and dynamic analysis (= actually running the file) can be full of "surprises".  Case in point:

daniel@foo3:~/malware$ strings data.exe | grep -i Debug
OutputDebugStringA
IsDebuggerPresent

Looks like our EXE invokes the Windows API method "IsDebuggerPresent" to verify whether a debugger is currently running. Chances are, the EXE will behave differently when is suspects that someone (like a malware analyst :) is watching its every move. In this case here it is nonetheless quite readily possible to determine what the two EXEs are doing: They are, as so often, simply "downloaders" that fetch the next stage of the attack code. There are four downloaded files, and all come from www-sandulsori-co-kr.

daniel@foo3:~/malware$ ls -al *
-rw-r--r-- 1 daniel users 55296 Oct 24 12:21 common.gif
-rw-r--r-- 1 daniel users 71680 Oct 24 12:21 common.png
-rw-r--r-- 1 daniel users  7680 Oct 21 08:08 favicon1.ico
-rw-r--r-- 1 daniel users 79872 Oct 17 09:44 favicon.ico
daniel@foo3:~/malware$ md5sum *
e2004ec5fef378b2e41f6eef6931650b  common.gif
3fed1004befb9834b699a88ccdce757e  common.png
c85f70642ad402077c6447dc6ad6f7bb  favicon1.ico
93a2dc2dcdb4bb17ae168cb60cff2e9b  favicon.ico
daniel@foo3:~/malware$ file *
common.gif:   PE32 executable for MS Windows (console) Intel 80386 32-bit
common.png:   PE32+ executable for MS Windows (console) Mono/.Net assembly
favicon1.ico: PE32 executable for MS Windows (GUI) Intel 80386 32-bit
favicon.ico:  PE32 executable for MS Windows (DLL) (GUI) Intel 80386 32-bit

Note how all four files claim to be an image, even though they are an EXE. The two files named "common" contain the Windows EPathObj exploit (CVE-2013-3660) which results in SYSTEM privileges on versions of Windows that don't have Patch MS13-053 (July 2013). Analysis of the two favicon files is still ongoing. The involved domains (overall) are: www-namu-in-com, currently at 110.45.165.42 for Stage#1, www-sandulsori-co-kr, currently at 111.92.188.21 for Stage#2, and www-staticscount-com, currently at 74.82.173.187 for the Command&Ccontrol (C&C).  These sites and IP blocks are not necessarily hostile per se, they could also be victims of an earlier hack / take-over.

The moral of the story is that all of the above is based on Exploits of vulnerabilities that have patches available since about three months. If your patching of OS and Applications is lagging behind to this extent because of lack of resources or priority, you'll need to catch up asap. As shown above, the bad guys are delivering exploit cocktails that provide SYSTEM level privileges on Windows machines which lack the necessary patches, and current anti-virus patterns offer little coverage against it.