Old dogs may not be taught new tricks, but the same isn't true for Java exploit kits.
One of the top four exploit kits in the world, g01pack, has added a new wrinkle to its repertoire of tricks to evade detection, according to researchers at Trusteer. It now contains a new exploit that modifies how it delivers malware to an infected system.
The kit is designed to attack a vulnerability that was patched in Java 6 by Oracle in 2012. Despite that -- and the fact that the latest version of Java is 7.x -- Trusteer estimates that the package is still infecting one out of every 3000 computers connected to the Internet a month.
Oracle declined to comment for this story.
With a typical exploit kit, a small patch of shell code is injected into a machine through a vulnerability. Once in memory, it sends for its payload.
Payloads contain an smorgasbord of malware programs for working mischief on a computer. For example, g01pack has such dark gems as Zeus, Torpig, Gozi and Shylock in its payload.
With this latest variation of g01pack, the shell code writes a program to the hard drive of the infected system that that writes yet another program to the job of fetching the payload. "A sort of buffer zone is created between the exploited process and the final execution of the payload," Trusteer CTO Amit Klein told CSO in an interview.
As simple as the technique may be, the change in behavior appears to be fooling some defense systems. "This seems to be confusing many security mechanisms because the malicious activities now take place in two locations," Klein said.
[Java exploits in the news: Recently patched Java flaw already targeted in mass attacks, researchers say | Most Java-enabled browsers vulnerable to widespread Java exploits, Websense says]
"The initial exploitation takes place on the browser or plug-in process, and the download and execution takes place in another process," he added.
If a security program is looking for suspicious calls to the Internet from a program in memory, then it might be fooled when those calls are made from a program located elsewhere on the systems.
"That's because the exploited process doesn't run the payload, it just runs a new instance of the Java process that appears to be a legitimate," Klein said.
Identifying the payload written to a system's hard disk can be difficult, too. The download program uses a list of 20 names that it randomly assigns to payload files. Moreover, the names are names found on legitimate processes running on a typical Windows machine -- Google Update, Firefox, Chrome, Opera and such.
"If you not careful enough to check the full path names when you're looking at the running processes, you'll just see processes that look legitimate," Klein said.
The writers of this flavor of g01pack appear to be behind the times, noted Rapid 7 Chief Security Officer HD Moore. "The fact that this exploit works at all is a testament to how bad the AV industry is," he told CSO.
The second stage of the g01pack exploit isn't as elegant as new exploits that compromise the Java sandbox, he continued. "If you do the sandbox escape in Java, you can do in-memory execution of anything you want," he said. "You don't have to write a file to disk anywhere."
"Their techniques are pretty primitive compared to what's already out there," Moore said.
It's also surprising to see them attacking an exploit closed six months ago in a version of Java in only about 40 percent of the installed base and dropping, he said. "It seems like an inefficient use of their time."
Read more about application security in CSOonline's Application Security section.