Recently I am learning about thick client application pentesting and have found that it is hard to get a tool for intercepting thick client application traffic.

Has anyone come across a thick client application for pentesting, or know whether there is any software that can work as an interceptor proxy like Burp Suite for thick client applications? I am looking for a tool that is not only able to intercept http traffic but also tcp traffic.

I have done some searching on google and found Mallory. So far this is the best tool I can find out there. I have tested it and it is working as expected, however it is not stable and has not been updated for quite some time.

Another problem I am facing is, if the application is using windows domain authentication (NTLM Authentication), the TCP traffic will then be encrypted. Is there any way to see the plain text traffic and modify the data before it's sent to server (just like how Burp did it for HTTPS traffic)?

  • What is a thick client?
    – Elias
    Commented Aug 9, 2017 at 8:24
  • It is also refer as fat client
    – overshadow
    Commented Aug 9, 2017 at 9:55
  • Are you trying to white-box or black-box? Commented Aug 10, 2017 at 14:33
  • I am trying both whitebox and blackbox
    – overshadow
    Commented Aug 11, 2017 at 5:45

8 Answers 8


This tool https://github.com/jrmdev/mitm_relay seems to do this. It uses a trick: It embeddeds every request into a HTTP POST Request so you can relay it through burp and use every function of burp with arbitrary protocols(well binary could be hard). Burp then passes the request back to the proxy which strips the http part and forwards the content to the server/client.

  • This looks interesting, I will definitely give it a try. Thank you for your comment.
    – overshadow
    Commented Aug 7, 2017 at 13:34

As suggested by Ian, Burp Suite Invisible Proxy mode would be best for capturing request from Proxy unaware Thick client application.

Consider an Thick client application making request to www.example.com. Inorder to capture the request through burp the following can be done:

  1. Resolving the domain to loopback the local IP address( This can be done by making the following changes in HOST file located in **c:\windows\system32\drivers\etc** (For windows). www.example.com

2.Next burp has to listen to the loopback Local IP address. Configure the burp to listen to and the port which is used by the application.

  1. At last the request has to be redirected to the actual host.

But the above method has a limitation that burp cannot handle if the request isdirectly fired to an ip instead of to a domain name. This can be overcome-d by Burp Suite with Microsoft Loopback Adapter Method. The below link could give you a clear idea of it.


  • I know this method can only be done if the application is trying to communicate through HTTP(s) protocol, correct me if I am wrong. I am actually looking for a tool that able to intercept others communication protocol like TCP, UDP and etc.
    – overshadow
    Commented Aug 7, 2017 at 13:36
  • 1
    In that case, Echomirage can be used and still this is more sloppy than Mallory and no latest updates for the tool. One more tool is Interactive TCP Relay(ITR) which is better than Mallory and Echomirage in capturing non-HTTP traffic.
    – Jaka
    Commented Aug 7, 2017 at 14:04
  • I have tried Echomirage before but not always working. I will give a try on TCP Relay(ITR). Thank you.
    – overshadow
    Commented Aug 8, 2017 at 6:16

If you're looking for a tool which can intercept both HTTP and general TCP traffic, which is also under active development, I'd recommend looking at bettercap

Things like HTTP incerception are built-in and there's a framework for adding modules to handle other protocols.

  • Hi Rory, thanks for your valuable suggestion, I will give it a try. Just to ask If the application use AD authentication and the network traffic is encrypted, can bettercap cater with this? I am not sure is this possible or not as I am not familiar how AD authentication work and how they encrypt the traffic. I am wondering is there any approach like how Burp use to see encrypted (HTTPS) network traffic like import the Burp cert to our trusted store.
    – overshadow
    Commented Aug 11, 2017 at 4:09

If you intend on writing an official-looking report for your pen test, then I suggest Canape from Context IS.

Not only it is the best GUI-based pluggable proxy I've come across, but it's the only one that has a well-designed interface.

BenjaminH's answer uses Burp, which is nice. I also ran across this Burp Add-on -- https://github.com/summitt/Burp-Non-HTTP-Extension -- which I think is more-functional. However, if you want something pretty for a report then Canape is probably still the way to go.

  • Thank you @atdre for your suggestion. I am very interesting on the burp extension you suggested. How come I could not find it in BApp Store? I will got test out it later. For Canape, it is freeware or commercial tool? Able to intercept NON-HTTP traffic as well?
    – overshadow
    Commented Aug 8, 2017 at 4:18
  • Yes, for Canape, it is non-Http traffic (as well as Http, but not as efficient for just Http as Burp) and it is freeware as well as open-source software entirely. For Burp BApp store, I have found many that are on GitHub, Bitbucket, and others places -- it is up to the developer where he or she puts his or her code.
    – atdre
    Commented Aug 8, 2017 at 16:15

Burp may well suit you for all the tasks. It has an 'invisible' mode which was specifically designed to intercept traffic for non-proxy aware thick client applications. If you can get this working as intended, it may preclude you needing to intercept the encrypted TCP traffic too.

More info here: https://portswigger.net/burp/help/proxy_options_invisible.html

Good luck and HTH!


I prefer using Fiddler for intercepting purposes. This is simple to use with unlimited features.

You can check HTTPSDecryption with Fiddler for instructions.


I highly recommend mitmproxy which is an intercepting proxy with lots of features allow you to intercept packets and change them before they are forwarded to and from the target host.

It allows for transparent proxying which is useful for applications that don't have the option to add proxy settings or don't honour the operating system proxy settings.

It has the ability to inspect TLS through the use of a self-signed CA you install.

You can use mitmproxy with an upstream proxy which is useful if you're in an environment which requires you to use a proxy to access the internet.

It is very flexible, you can use it as a simple intercepting proxy using the interactive GUI or you can leverage it as a python library allowing you to inspect and change packets programatically, there are some examples on GitHub.


I'm working on a tool for intercepting arbitrary protocols, called Mallet. It is based on the Netty framework, and is organised as a pipeline of handlers. A common "graph" of handlers would look something like this:

Listener->SOCKS Server->Handler->Handler->Interceptor->Handler->Target

The SOCKS server handler accepts a connection, and negotiates a SOCKS handshake with the client, in order to determine where it should relay the connection to. Getting the client to negotiate the SOCKS handshake might be as simple as a configuration setting, or may involve socksifying the client in some way (tsocks, sockscap, etc).

The handlers can be any of the existing Netty ChannelHandlers, which implement various protocols, such as SSL, HTTP, MQTT, etc, or may be a custom ChannelHandler written by yourself that decodes the protocol in question into something you can work with more easily. Probably most important is a frame decoder that chunks the stream into individual messages, then something that translates the bytes into an object of some sort.

I have also implemented a simple ScriptHander class that can execute scripts using any JSR223 scripting language such as Groovy, Nashorn(ECMAScript), JLua, Jython, JRuby, etc, etc. This makes it possible to automate processing of messages, which is often necessary due to timeouts in the client or server. (Timeouts are much less of a problem in the HTTP world!)

The interceptor can then allow you to view and manually edit the message (if desired), before passing it on to further handlers (e.g. to recalculate checksums, etc), and finally on to the Target.

You can see early progress in our github repo at https://github.com/RoganDawes/Mallet

Issues and pull requests are welcome.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .