"I dedicated this post to our members in BlackHat & Def Con 2013, who's helping the effort to present our group in the security community, with regret that I could not make it to go there this time.
Thank you to @hugbomb and @kafeine for the help in the EK confirmation, to @hFireF0X and other Kernel Mode members for helping figuring & quick mitigating the new version of Zero Access spotted in this case!"
Background
I was mentioned about an infection by our team's @hugbomb:
@MalwareMustDie FYI http://yusn. net/ is infected, your neck of the woods..
— hugbomb (@hugbomb) July 28, 2013
I cleaned the site within 24hrs, after releasing my neck of the woods.. :-)
I made domestic report in here -->>[0day.jp], and this is the post about how the malicious redirection was made.
The nature of the infection is, only IE browser with java plugin access is affected, a non direct access. Some parts of the a kind of ACL used in this redirector us still on decoding process, so maybe we can report more feature they use upon 100% finished. If you meet the accepted condition, you will be redirected to Glazukov Exploit Kit to infect you with Zero Access/Sireref malware. I had hard time in confirming this site, so I had to ask many friends to confirm the case and its condition by some tests. The good thing is the site's admin is very supportive and asked me to make investigation properly and allowing this post to be publicly published to prevent more infection.
First, let's see carefully how the result of injection code was:
Explanation:
We see the javascript tagged codes, usage of specific cookie, user will be firstly forced to call the landing page of Glazunov Exploit Kit at upper URL, then the checking interface of browser components using PluginDetect will be performed, the condition in Java Exploitation will depend on detected Java version.
If the Java version is ver 7 the JNLP base infection via "buj58i7kc3.jnlp" will be perform, or else the direct Jar class "weptblklaadp.nfpmuqaplgapmsrrmnranye.class" of "8.zip" a CVE-2013-1493 JAR Exploit. In my previous report here -->>[kernelmode.info] I know the payload is a new type of ZeroAccess/ MaxPlus / Sireref payload trojan.
Spotting the infection source
So how this code can be injected? This is the point of this post.
Please see the picture above in the marked red below part. It stated:
Confirming this to the site owner and found that error wasn't suppose to be happened.
I executed the first stage on checks by run into .htaccess, php.ini, default.php etc, wasn't finding anything suspicious, and went deeper to find the apache module is in place, so does the web server daemon used.
Went back to .htaccess and found myself staring into this line :
OK, this is the Wordpress Super Cache plugin is running, intrigued by the error caused by the same plugin made me dive into the plugin directories:
This is just perfectly strange, since everything was installed on 2012/07/23 at exactly midnight :-)) lame..
Just to be sure I made detail comparison to the original plugin: 
To find the size changes, but no differences in codes after I "diff"-ed them.. weird.. Making me think the attacker was storing stuff to normal after injection stored?
Let's see what we got now, WP cache plugin error, strange plugin files dates, and an injected code.
Went back to the injected code, found that the obfuscation built by Zend, and using this as grep "significant" character to find the list of the injection code's file sources:
Noted: the yellow color is the files and their path, all of them was injected in the first lines, and the green color is the similarity found in Zend framework builder used.
below is the list of these injectors:
And now we know why the error in the top page occured! :-)
The attacker also injected codes in the current WordPress Theme used by the victim, again I pasted the "atahualpa" theme files injected by the malware code:
Understanding the malicious code works..
Well, the code used to inject pages is as per pasted "safe" code here-->>[PASTEBIN]
The first obfscation extracted the code into this one -->>[PASTEBIN]
I noted (AGAIN) The code is only for view and can't be executed, a.k.a. I "hexed" the codes.
Following the decoded one, in the below line number you'll see this codes:
It shown the regex operation to grab and replace the original contents, and insert the injection code after assembled with the tags ＜BODY and ＜/HTML (marked in purple color), to be noted all of these are possible by the abuse of Wordpress plugin mentioned.
I tried to manually further decode to find two similar pattern obfuscation blocks, each block contains these parts with the below logic:
Obfuscation block...
Decoder..
Parser of the decoded codes..
Well the above codes are a rough copy-paste of my notepads, all you have to do next is grab the blob of data, modified a bit as per those moronz wanted, decode it using the logic seen in the decoder parts, and parse it out.
I tried to follow the flow of codes manually, use only one text editor, but it looks like things went off the rails somewhere.. So it looks like I get stuck in the final decode status here -->>[PASTEBIN]
During to the decoding the blob manually, some of the interesting result shown:
Exclusion of the user agents...
Passing ot the user-agent to the Exploit Kit url...
At this point I realize that more effort in de-obfuscation will take more time and energy (I have to do it from beginning all over again), which I don't have thise right now, not in the weekdays. So I reproduced the injection source script in the PHP with WP server test environment to get the injection code as per pasted here, bit by bit in text -->>[PASTEBIN]
Noted that the path of the exploit kit and the name of zip/Jar file name has changed. The code is hexed also.
I look further to finish decoding this weekend, hope this writing helps people who got hit by the same threat. Be free to ask me question via comment part of this post.
#MalwareMustDie!!