In the past, I've seen exploit code writers throw in a closing </textarea> tag nullifying the technique of using textarea tags to manipulate document.write script. An older method of decoding JavaScript was to change script like document.write(r) to document.write("<textarea>"+r+"</textarea>"). The output would be placed in an html textarea object. The following decoded sample reveals a closing textarea tag which renders the decoding technique useless.
</textarea><html>
<head>
<title></title>
<script language="JavaScript">
var memory = new Array();
var mem_flag = 0;
function having() { memory=memory; setTimeout("having()", 2000); }
A recent example originated from various advertising content that redirected to srv(dot)ad-adnet(dot).net/code/smain.php?scout=jvcxeng. The sv.ad-adnet.net request returned obfuscated code.
<script language="javascript">
var enschr="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/";
var i;var enschrs=new Array();for(i=0;i<enschr.length;i++){enschrs[i]=enschr.charAt(i);}var rvenchr=new Array();for(i=0;i<enschrs.length;i++){rvenchr[enschrs[i]]=i;}var ensstr, enscnt;function sensstr(str){ensstr=str;enscnt=0;}function rrvren(){if(!ensstr) return -1;while(true){if(enscnt >= ensstr.length) return -1;var [truncated]...
In this example, Malzilla is used to decode the eval function.
The eval() function is replaced in Malzilla with the decoded result and decoded again. It looks like the second decoded result is “---“.
The “---“ appears to be used to make analysts think they received a result or lack of a result. The decoded content contains a bunch of whitespace that requires the analyst to scroll down to see the exploit code. The only explanation is the bad guys are attempting to to throw analysts off.
It's isn't an elaborate effort, but it is interesting to know the bad guys know that analysts are looking at and decoding their exploit code and are trying to counteract analyst techniques with a wide variety of TTPs.