The Java Signed Applet Attack is a staple social engineering option. This attack presents the user with a signed Java Applet. If the user allows this applet to run, the attacker gets access to their system. Val Smith’s 2009 Meta-Phish paper made this attack popular in the penetration testing community.

Last week’s Java 1.7 update 51 takes steps to address this vector. By default, Java will no longer run self-signed applets. This free lunch is over.

A lot of pen testers use an applet signed with a self-signed code signing certificate. For a long time–this was good enough. The old dialog to run a self-signed applet wasn’t scary. And, thanks to the prevalence of self-signed applets in legitimate applications, users were already familiar with it.

Over time, Oracle added aggressive warnings to the self-signed applet dialog. These warnings didn’t stop users from running malicious self-signed applets though.

Starting with Java 1.7u51, we should not rely on self-signed Java applets in our attacks. Going forward, we will need to sign our applet attacks with a valid code signing certificate. This isn’t a bad thing to do. Signing an applet makes the user prompt much nicer. 

Even with a valid code signing certificate–it’s dangerous to assume a Java attack will continue to “always work” in social engineering engagements. Java is heavily abused by attackers. I expect more organizations will disable it in the browser altogether (when they can). We should update our social engineering process to stay relevant.

Here’s my recommendation:

Always profile a sample of your target’s systems before exploitation. I wrote a System Profiler to help with this. A System Profiler is a web application that maps the client-side attack surface for anyone who visits it. Reconnaissance extends the life of all attack vectors by allowing an informed decision about the best attack for a target’s environment.

If Java makes sense for a target’s profile–use it. If Java doesn’t make sense, look at social engineering attack vectors beyond Java. The Microsoft Office Macro Attack is another good option to get a foothold. In environments that do not use application whitelisting yet, a simple Windows Dropper attack will work too.