In October 2011, we documented a particular targeted attack campaign – The Nitro Attacks. In that instance, the attackers were primarily targeting chemical companies. Despite our work in uncovering and publishing the details behind the attacks, the attackers continued undeterred, even using our own report in their social engineering campaign!
The attackers have escalated their efforts however. As discussed in our previous blog, a new Java zero-day vulnerability has been seen being exploited in the wild. We can confirm that some of the attackers behind this round of attacks are actually the Nitro gang.
The traditional modus operandi of the Nitro attackers is to send an email to victims. That email contains an attachment, which is a password-protected self-extracting zip file. The email claims to be an update for some piece of commonly installed software. The targeted user extracts it, runs it, and is infected with a copy of Backdoor.Darkmoon (also known as Poison Ivy).
In these latest attacks, the attackers have developed a somewhat more sophisticated technique. They are using a Java zero-day, hosted as a .jar file on websites, to infect victims. As in the previous documented attacks, the attackers are using Backdoor.Darkmoon, re-using command-and-control infrastructure, and even re-using file names such as “Flash_update.exe”. It is likely that the attackers are sending targeted users emails containing a link to the malicious jar file. The Nitro attackers appear to be continuing with their previous campaign.
The attackers have been using this zero-day for several days since August 22. We have located two compromised websites serving up the malware:
One sample of malware downloaded by the exploit has been identified as 4a55bf1448262bf71707eef7fc168f7d – “hi.exe” or “Flash_update.exe”
This particular sample connects to hello.icon.pk, which resolves to 22.214.171.124. That same IP was used by the Nitro attackers back in 2011.
The Java exploit is detected by Symantec as Java.Awetook. The vulnerability consists of a privilege escalation due to a class that allows access to protected members of system classes, which should not be accessible. Because of this, malicious code can bypass the restrictions imposed by the sandbox and use the “getRuntime().exec()” function in order to execute a malicious payload. In our tests, we have confirmed that the zero-day works on the latest version of Java (JRE 1.7), but it does not work on the older version JRE 1.6. A proof of concept for the exploit has been published and the vulnerability has already been added in Metasploit.
IPS detections for the exploit are covered under:
Leave a reply