How to intercept thick client application traffic (tcp or http[s])

Question

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)?

Answer 1

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.

Answer 2

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(127.0.0.1). This can be done by making the following changes in HOST file located in **c:\windows\system32\drivers\etc** (For windows).

127.0.0.1 www.example.com

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

3. 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.

https://paladion.net/thick-client-testing-toolkit-part-3-tools-testing-techniques-interception-testing/

Answer 3

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.

Answer 4

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.

Answer 5

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!

Answer 6

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

You can check HTTPSDecryption with Fiddler for instructions.

Answer 7

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.

Answer 8

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.