TrustedSec is proud to announce the release of The Social-Engineer Toolkit (SET) v5.4 codename "Walkers". This version has a significant amount of changes, performance upgrades, bug fixes, and efficiency. This blog post will cover some of the major highlights from Java 7 Update 45 and how to get around the security "enhancements". Most importantly, a massive overhaul on how the Java Applet behaves. Most recently, Java released Java 7 Update 45 which made some significant changes on restrictions on how Applets need to behave. First and foremost, there are requirements now to build into the manifest of the applet in order to meet the specifications for the new changes. As an example of what SET used in the past, html tags were passed that contained dynamic information such as encrypted shellcode, variables, but most importantly, the name of the Applet. For example: applet name"Whatever you want!" If you didn't have the name specified (as well as manifest options explained shortly), the Applet would look pretty bad: The ability to control names through applet tags is no longer acceptable and needs to be built into the Applet. Because of this, SET has updated the build process for the Applet. The manifest files are now automatically generated and incorporated into the applet. When this is done, on a self-signed certificate Applet, it look a little bit better without the yellow highlighted warning, but still not perfect because of it being self signed: Still not horrible, but not as good as a legitimate code signing certificate. Regardless, if you build your pretext properly, this won't be an issue for you. Next, other options such as expiration warning messages were changed: Also resetting the time for dates and CRL lookups were employed which look like this: If you were to use the old method with a legitimate code signing certificate, it would look like this: Now with the new SET deployment method built into 5.4, when using legitimate code signing certificates for your payload delivery (recommended), it now looks like the below and we have full control to customize the name field to whatever we want for a better attack vector: Additional manifest records were required to make the Applet function the same as before:

Permissions: all-permissions
Codebase: *
Application-Name: Publisher verified safe (SECURE).

If you want to change any of these in SET, simply edit the manifest file with what you want the name of the Applet to be, for example, if you edit src/webattack/java_applet/manifest.mf and change the Application-Name: Publisher verified safe (SECURE). to whatever you want, then go into src/html/unsigned/unsigned.jar and copy it to src/webattack/java_applet. Next run:

jar ufm Java_Update.jar manifest.mf

This will add the manifest to the unsigned, next use your own code signing certificate or self sign it. As SET progresses in the next few releases, we will be adding the ability to do this all for you automatically and building the applet if the Java developer tools are installed and detected. Regardless - the changes to Java 7 Update 45 provide little to no difference in how the Applet attack works or the ability to use it as a viable attack vector. This does show a shift in Java policy to be more restrictive on the applets themselves, as time progresses there will be more changes the restrict the ability even more however, at this time none of them appear to affect anything at all from a security standpoint. Mostly topical. In addition to the Java updates, EnableStageEncoding now is in the set_config under STAGE_ENCODING. By default this option is turned to off, there has been instances where enable second stage shikata_ga_nai causes the payload to die during the second stage delivery. Haven't pinpointed the exact cause but deals mostly when running natively in memory vs. disk. There is also more changes to how the payload delivery system works with better obfuscation on the payloads due to anti-virus signatures being written for certain components of static analysis. This has been changed to be completely dynamic - won't need to worry about that anymore. Lastly, a number of big fixes including proper powershell generation when using the powershell generator or through the PSEXEC_COMMANDS. We hope you enjoy this release, it's been under development now for over a month and excited to see the stability enhancements, new features for the toolkit.