Once again, attackers are leveraging a previously unknown critical security hole in Java to break into targeted computers. Interestingly, the malware and networks used in this latest attack match those found in the recently disclosed breach at security firm Bit9.
The discovery of the Java zero-day is being co-credited to FireEye and CyberESI, two companies that specialize in tracking cyber espionage attacks. In its writeup, FireEye said multiple customers had been attacked using a newly-found flaw in the latest versions of Java — Java 6 Update 41, and Java 7 Update 15.
FireEye said the Java exploit used in this attack downloaded a remote access Trojan called McRat. This threat, also known as HiKit and Mdmbot.F, calls home to a malicious control server at the Internet address 110.173.55.187. Turns out, this is the same malware and control server that was used in the attack on Bit9, according to details that Bit9 released in a blog post this week documenting a sophisticated attack that resulted in a breach of its own systems last year.
Alex Lanstein, a senior security researcher at FireEye, said it’s unlikely in this case that multiple attack groups are using the same infrastructure and malware.
“Same malware, same [command and control server], I’d have to say it’s the same group that hit Bit9,” Lanstein said.
The discovery of the new Java zero-day comes just days after Oracle released an update to fix at least five security flaws in Java, flaws that were apparently used in attacks on Apple, Facebook, Twitter and at least 37 other companies. At the beginning of February, Oracle pushed out an update that fixed some 50 other serious security problems in the widely-used program. Meanwhile, a team of Polish researchers has documented the presence of two other unfixed critical holes in the latest versions of Java 7.
Most consumers can get by without Java installed, or least not plugged into the browser. Because of the prevalence of threats targeting Java installations, I’d urge these users to remove Java or unplug it from the browser. If this is too much trouble, consider adopting a dual-browser approach, keeping Java unplugged from your main browser, and plugged in to a secondary browser that you only use to visit sites that require the plugin.