Guide

Thick Client Pentesting (2026): Methodology, Checklist and Tools

Thick client pentesting is security testing of applications installed on a user's computer. You test the local files and code, the memory, and the network traffic between the client and its servers. For traffic that Burp Suite cannot see, such as raw TCP, TLS, UDP, DTLS and QUIC, use a proxy built for non-HTTP protocols, for example InterceptSuite.

Last updated October 6, 2026

Start 7-day free trial Intercept thick-client traffic

What thick client pentesting covers

A thick (or fat) client does real work on the user's machine: it holds logic, stores data and often speaks its own protocol to a server or straight to a database. That makes the attack surface larger than a browser talking to a web server. A tester looks at the application on disk, in memory and on the wire.

2-tier and 3-tier applications

A 2-tier client connects directly to a database, so connection strings, credentials and queries live in or flow from the client. A 3-tier client talks to an application server, which talks to the database. In both cases, anything the client enforces can usually be changed by the user, so every check that matters must also be made on the server.

Methodology

1. Information gathering
Identify the technology (.NET, Java, native C/C++, Electron), the installer, the files and services it adds, and which servers and ports it talks to.
2. Local data and configuration
Look in the install folder, user profile, registry, logs and temp files for stored credentials, tokens, connection strings and keys.
3. Binary and code analysis
Decompile or disassemble the application to find hard-coded secrets, weak checks done on the client, and the logic behind each network call.
4. Runtime and memory
Watch file, registry and process activity while the app runs, hook functions, and look at what sits in memory after login.
5. Network traffic
Capture and edit what the client sends and receives. This is where most server-side flaws appear, because the server may trust the client.
6. Authentication and authorisation
Test login, session handling, role checks and what happens when you change an ID, a role or a flag in a request.
7. Updates and installation
Check how updates are fetched and verified, and whether the installer or loaded libraries can be replaced.
8. Reporting
Record the steps, the exact requests and the impact so developers can reproduce each finding.

Thick client pentesting checklist

Area	What to check	Tools
Local storage	Plain-text credentials, tokens or keys in files, registry or logs	Procmon, file and registry review
Binary	Hard-coded secrets, debug code, missing code signing, weak obfuscation	Decompilers and disassemblers
Memory	Secrets left in memory after logout	Debuggers, Frida, memory viewers
Network: HTTP	Missing or weak TLS certificate validation, sensitive data in requests, broken access control	Burp Suite, ZAP, mitmproxy
Network: non-HTTP	Plaintext protocols, weak or missing TLS, replayable or editable messages	InterceptSuite, PETEP, NoPE, Wireshark
Database access	Direct database connections with shared accounts (2-tier apps)	Traffic capture, database client
Authentication	Client-side checks, weak sessions, token reuse	Proxy and replay tools
Authorisation	Changing a user ID or role in a request is accepted	Proxy and replay tools
Updates and installer	Unsigned updates, writable install paths, DLL search order	Procmon, signature tools
Logging	Sensitive data written to logs	File review

Tools by phase

No single tool covers a whole engagement. These are common choices for each phase.

Static analysis	dnSpy or ILSpy for .NET, Ghidra for native code, JD-GUI or similar for Java
Dynamic and runtime	Process Monitor, x64dbg, Frida
HTTP and HTTPS traffic	Burp Suite, OWASP ZAP, mitmproxy
Non-HTTP traffic (raw TCP, TLS, UDP, DTLS, QUIC, STARTTLS)	InterceptSuite, PETEP with Deluder, NoPE or mitm_relay with Burp, Wireshark for capture. Echo Mirage is no longer maintained.
Packet capture and analysis	Wireshark, tcpdump

For side-by-side details on the non-HTTP tools, see the comparison of mitm_relay, NoPE, PETEP and Deluder, mitmproxy vs InterceptSuite, PETEP vs InterceptSuite and the Echo Mirage alternative guide.

OWASP Desktop App Security Top 10

The OWASP Desktop App Security Top 10 lists the most common weaknesses in desktop applications. Network testing maps most directly to DA7, Insecure Communication, and supports several of the others.

ID	Risk	How to test it
DA1	Injections	Send crafted input in fields and in intercepted requests.
DA2	Broken Authentication & Session Management	Test login, token reuse and session expiry on the wire.
DA3	Sensitive Data Exposure	Check local files, memory and traffic for secrets.
DA4	Improper Cryptography Usage	Review how the app encrypts data and which TLS versions and ciphers it accepts.
DA5	Improper Authorization	Change IDs and roles in requests and check the server response.
DA6	Security Misconfiguration	Review install paths, permissions and debug settings.
DA7	Insecure Communication	Intercept all traffic, including non-HTTP protocols, and check it is encrypted and validated.
DA8	Poor Code Quality	Review decompiled code for unsafe patterns.
DA9	Using Components with Known Vulnerabilities	List bundled libraries and versions.
DA10	Insufficient Logging & Monitoring	Check what the app records about failed and suspicious actions.

For a step-by-step DA7 walkthrough, read testing DA7 on non-HTTP protocols.

Intercepting thick client traffic

HTTP and HTTPS clients often honour the system proxy or have a proxy setting, so Burp Suite, ZAP or mitmproxy work well. Non-HTTP and proxy-unaware clients are harder: the app may ignore proxy settings, and the protocol may be raw TCP, TLS, UDP, DTLS or QUIC.

Run a proxy that handles the protocol. InterceptSuite exposes a SOCKS5 listener for TCP, TLS, DTLS, QUIC and UDP.
Send the application through it: set the proxy in the app if it has one, or use a transparent redirector such as ProxyBridge for apps that do not.
Install and trust the proxy's CA certificate so TLS can be decrypted.
Read the traffic in Proxy History, hold packets with interception rules, and edit them in text or hex.
Resend and compare with Replay, for example after changing a user ID or a length field.

Full walkthroughs: intercept thick-client traffic, when Burp Suite isn't enough and debugging a custom binary protocol.

Practise on a vulnerable thick client

Damn Vulnerable Thick Client App (DVTA) is an intentionally vulnerable desktop application built for practice, and NetSPI's BetaFast and BetaBank are lab applications used in several tutorials. Run them in a lab you control and work through the checklist above.

Frequently asked questions

What is thick client penetration testing?

It is security testing of applications installed on a user's computer, such as desktop clients and fat clients. It covers the local files and code, the memory, and the network traffic between the client and its servers or databases.

How is it different from web application testing?

A web app runs on the server and the browser is a thin layer. A thick client carries logic, stored data and often its own network protocol on the user's machine, so you test the binary, local storage and non-HTTP traffic as well as the server.

Why does Burp Suite not show my thick client's traffic?

Many thick clients ignore proxy settings or use raw TCP, TLS or UDP instead of HTTP. Burp only handles HTTP, so you need a proxy that handles those protocols and a way to send the application through it.

Which tools are used for thick client pentesting?

Common choices are decompilers (dnSpy, Ghidra), Process Monitor, Frida, Burp Suite or mitmproxy for HTTP traffic, and tools such as InterceptSuite, PETEP or NoPE for non-HTTP traffic.

Where can I practise?

Damn Vulnerable Thick Client App (DVTA) is an intentionally vulnerable application built for practice. NetSPI's BetaFast and BetaBank are other lab applications used in tutorials.