Thick Client Penetration Testing: What to Expect

4

Thick client penetration testing checks the security of desktop software. It looks at the installed application itself, the data it stores locally, and how it talks to a server, not just the network layer a website test would cover. If you are commissioning one for the first time, the useful question is not just what it means. It is what actually happens once a tester starts, and how you judge whether the work was done properly.

What Is Thick Client Penetration Testing?

A thick client is desktop software that keeps most of its processing and data locally. It does not depend entirely on a remote server, the way Microsoft Teams, Outlook or a bespoke line-of-business tool do. OWASP’s Thick Client project splits these applications into two types: two-tier designs, which talk straight to a database, and three-tier designs, which go through an application server first.

A thick client runs directly on the user’s machine. That means penetration testing has to reach further than a web application test would. The tester must examine the executable itself, not just the traffic it sends.

Why Your Business Might Need One

Plenty of everyday business software is a thick client, even if nobody thinks of it that way. Point-of-sale tills, VPN clients, trading terminals, healthcare record systems and internal admin tools all count. So does the human-machine interface software that industrial businesses use to monitor production equipment.

If any of that software touches payment card data, personal records or anything an attacker would want, treat it with the same scrutiny as a public website. A tool built in-house years ago and never revisited is a common blind spot. Nobody assumes an internal application is exposed, so nobody checks.

What Happens During a Thick Client Penetration Test

A proper engagement moves through distinct stages rather than a single automated pass.

• Scoping. The tester and client agree which builds, environments and features are covered. They also agree whether the tester works with source code or without it, the same black box vs white box decision that shapes any penetration test.
• Client-side analysis. The tester decompiles or reverse engineers the application binary. They check for hardcoded credentials, weak licensing checks and business logic that should sit on the server but does not.
• Network traffic analysis. Traffic between the client and its server is intercepted. This sometimes needs tools built for non-proxy-aware software, to confirm the traffic is encrypted and certificates are checked properly.
• Server-side testing. The backend behind the client is tested the same way an API would be: authentication flaws, injection and data exposure.
• Local storage review. Config files, logs, cached credentials and registry entries are checked for anything sensitive sitting unprotected on disk.
• Reporting. Findings are written up with severity, evidence and a specific fix for each one.

Much of this cannot be automated. Expect a genuinely manual process, using tools such as Burp Suite or Wireshark for traffic, and dnSpy, Ghidra or IDA Pro to reverse engineer the binary itself.

What a Good Tester Actually Finds

The most common finding is a hardcoded credential: a database password, API key or encryption key left inside the binary or a configuration file. MITRE’s CWE-798 entry on this weakness explains why it matters so much for desktop software. The same credential is often identical across every installation, so one leaked copy of the application can compromise every customer running it.

Other frequent findings include unencrypted local storage of cached passwords, and weak cryptography that only looks like encryption. Testers also find DLL hijacking, where an attacker swaps in a file the application loads. Security checks enforced only in the interface, rather than on the server, are common too. A published case study makes this concrete. A .NET desktop application stored a database address and its credentials in plain text inside the binary, then sent them unencrypted over the network. That let the tester connect straight to the backend and pull out customer names, emails, phone numbers and device details, even though the software was never exposed to the internet.

How to Choose a Provider

Look for a firm accredited by CREST, the UK body that certifies penetration testing providers. Thick client work needs binary analysis and reverse engineering skills that a generic vulnerability scan will not provide. Ask what proportion of the work is manual rather than automated. Ask, too, for an example of a redacted report. That shows you how findings are actually written up before you commit. Aardwolf Security’s penetration testing team scopes this kind of engagement around the specific applications you run, not a generic package.

PCI DSS, ISO 27001 and NIST SP 800-115 are the frameworks most likely to require this kind of testing. That applies if you handle card payments or hold a security certification. Confirm the provider’s methodology maps to whichever one applies to you. Our wider guide on choosing a penetration testing company covers the same red flags, whatever the application type.

What Drives the Cost and Timeline

There is no single price that applies across the board. The effort depends heavily on the technology behind the application. A simple .NET tool with one clear client-server connection takes far less time to test. A native C++ application with several proprietary protocols and heavy obfuscation takes much longer. The number of user roles, the amount of client-server interaction, and whether the tester gets source code all change the scope too.

Compliance requirements add their own cost. If the report needs to satisfy PCI DSS, ISO 27001 or a specific regulator, expect more time spent on documentation and evidence, not just on finding issues. Ask any provider to break down their quote by activity: client-side analysis, network analysis, server-side testing and reporting. That way you can see where the budget goes, rather than accepting a single flat figure.

Signs the Testing Was Done Properly

A thorough engagement leaves a trail. You should see evidence that the tester actually opened the binary, not just captured its network traffic: screenshots of decompiled code, or memory analysis, for example. Findings should point to specific files, functions or registry keys, not generic statements like “insecure data storage” with no detail behind them. If every finding in the report could apply to any application in the world, the testing was probably shallow.

A good provider will also flag what they did not manage to cover. That might be a feature outside the agreed scope, or a protection, such as strong obfuscation, that limited how deep the reverse engineering could go. That kind of honesty is a better sign of quality than a report with no caveats at all.

If you are not sure whether any of your desktop software needs this kind of attention, it is worth a short conversation before committing to a full engagement. You can get in touch to talk through what you run and whether it is a priority.

Frequently Asked Questions

Is thick client testing the same as desktop application testing?

Yes, the two names describe the same service. A thick client is the architecture and a desktop application is the software running on it.

Do we need this if the software is only used internally?

Yes, if it holds anything sensitive. Insider threats, contractors and attackers who gain a foothold elsewhere on the network can all reach internal software, as the case study above shows.

Can we just run an automated scanner instead?

No. Decompiling a binary and judging whether a business logic flaw is exploitable both need a skilled person; scanners cannot do either reliably.

How is this different from the web application testing we already do?

Web application testing covers a browser sandbox and a server. Thick client testing adds the executable itself, along with local storage, memory and files on the machine it runs on.

What should the final report include?

Each finding should carry a severity rating, the evidence behind it, and a specific, actionable fix rather than generic advice.