Skip to main content

Thick Client Penetration Testing Tutorials - Part 2 ( Traffic Interception)

After getting the basics of thick client pentest, let’s delve into the very first steps you can take to commence thick client pentest.
Interception and setting up proxy of application.
Thick clients can be broken down into two types based on proxy settings:

1    1)      Proxy aware
     2)      Proxy unaware

Proxy aware are those applications which has settings in the application itself to route through IP address and ports for the purpose of logging in the application as well as transmit and receive data.
Whenever you log into the application, you will be given a prompt showing username/ password along with destination IP and port.
In case where the application does not have such settings, and only accepts username and password for authentication, you have to redirect the traffic from the application to your system to the actual server. This is the case of proxy unaware thick clients.

Let’s see how:

The very first step involves in getting the hostname of the thick client application’s url. We need to capture the particular traffic going through this url to our own machine.

Step 1: Ping the url you have got for testing (say
Step 2:  Note the reply ip address you get in the cmd console.
Step 3:  Now we need to know on which ports is the application interacting to send traffic. Now launch wireshark and activate it to capture active packets.
Step 4: Now run the thick client and login with your valid credentials and let Wireshark capture traffic for some time.
Step 5: Say after 10 minutes or so, go to wireshark statistics and find the particular ip in order to determine the ports being used.

Step 6: Click on IP destinations and you will be present with a similar screen as below:

Step 7: As you can see, suppose the above IP is the actual IP resolved while we pinged the url from the cmd in step 1, just expand the url and you can see the ports under TCP which are being used by the application to perform communications.
Keep a note of the 1. URL and 2. The TCP Ports (since we will need to intercept modifying these settings)
Step 8:  Add the hostname of the domain to your hosts file, so the system thinks that the hostname’s server is the machine itself (this helps to capture the traffic from the proxy unware thick client to your interception proxy)
Step 9:  Modify the hosts file in your system ( C:\Windows\System32\drivers\etc\hosts)
Step 10:  Open any text editor and launch the hosts file inside it.

Step 11: Now the actual server of the application won’t hit but remain inside your system, from where you can forward the traffic to your actual server.

In short, under normal scenario:

While for interception it’s like this:

 Step 12: So now whenever you fire up the application, the traffic from the application will be redirected to your own system from where you can intercept the request response and then forward it to the actual server.
Step 13: Now that we have configured the preliminary settings, let’s configure burp to understand the same, so we can intercept the traffic for the same.

Step 14: Here we have to use multiple bind to ports to capture the traffic hassle-free. The data we have from our initial assessment, we need to populate here.
Step 15: Assuming the above IP captured in wireshark ( is the IP for our thick client ( and the ports are 45716,45717,45718,45719, we setup the following in burp:

Similarly, for all the ports we keep adding the above setting.
Finally, we will see the following proxy option set:


Step 16: Make sure to enable the ‘invisible proxying’ option in burp, since we are intercepting proxy unaware applications this option will instruct Burp that its interface should be an emulated web server interface rather than the typical proxy style interface that's used by default.
Step 17: Once this is done, now restart the thick client, keep your burp interception on and enter the user id credentials, you will see burp starting to intercept the traffic in the application!

Key points:

We saw how to intercept traffic for thick clients using Burp Suite. ( note this only holds for http protocol thick clients, for non http protocol thick clients, we need to use other tools like fiddler)

The next article in the series will cover the penetration testing test cases along with vulnerabilities which we will find in thick clients. 


Popular posts from this blog

Web Services/ API Penetration Testing Part - 1

Hi Readers, today we will learn about another interesting part of Penetration Testing, this revolves around Security assessments of web services.
To start with let’s take a look at what web services are made of:
A web service is software composed of standardized XML messaging system.
The benefit of web services are since all of its communication is in XML, they are not restricted to any  operating system or programming languages
They are built on Web services are built on top of open standards such as TCP/IP, HTTP, Java, HTML, and XML.
Anatomy of Web Services
In simple language, any basic web services platform is a combination of XML and HTTP. They can be of: ·SOAP (Simple Object Access Protocol)·UDDI (Universal Description, Discovery and Integration)·WSDL (Web Services Description Language)

How does a Web Service Work
Web services depends on •             XML to tag the data ( as markup and syntax) •             SOAP to transfer a message •             WSDL to describe the availabilit…

Web Services/ API Penetration Testing Part - 2

Web Services and API Penetration Testing Part #2
Welcome readers to Part 2 of Web Services Penetration Testing. In this part, we will take a quick look into the various test cases, tools and method for security testing of Web Services. Black box Web Services Penetration Testing pre-requisite: èWeb Service Description Language (WSDL) file Grey box Web Services Penetration Testing pre-requisite: èSample requests/responses for methods along with WSDL file. Stages of Penetration Testing of Web Service: 1.Information Gathering 2.Black Box 3.Google hacking (using dorks to discover web services for websites hosted over network) 4.UDDI 5.Web Service Discovery (If no WSDL provided) 6.Authentication Type Discovery Testing Methodology: èAutomated Testing Tools ·SoapUI Pro ·OWASP ZAP ·IBM AppScan ·HP Webinspect ·WSBang ·WSMap
èManual Testing Tools ·Soap UI Free ·Burp Suite Pro ·Postman ( with burp) èExtensions: ·SAML Editor ·SAML Encoder / Decoder

Arbitrary file upload and RCE in Wonder CMS - CVE-2017-14521

By- Samrat Das

Hi Readers

Recently in one of my pentest research, I found a CMS " WonderCMS" hosted in github.
Curious to explore its functionalities, I downloaded and set it up in my local system.

After fiddling with the source code, I found that it did not have any kind of file upload security mechanism and allowed the user to upload any file type! After reporting it to them, I did not receive any security relevant response, hence decided to publish a blog on this.

Title of the Vulnerability:  Arbitrary File Upload Vulnerability Class: Security Misconfiguration Technical Details & Description: The application source code is coded in a way which allows arbitrary file extensions to be uploaded. This leads to uploading of remote shells/ malicious Trojans which can lead to complete system compromise and server takeover. CVE ID allocated:  CVE-2017-14521 Product & Service Introduction: Wonder CMS 2.3.1 WonderCMS is an open source CMS (Content Management System) built with P…