Thick Client & Desktop App Penetration Testing

The core problem with any thick client is that it runs on a machine the attacker controls. Every check the application performs locally can be observed, disabled or lied to. A “you can’t do this” button greyed out in the interface is trivially re-enabled once someone opens the binary in a decompiler. Anything the security of your system depends on has to live on the server, and testing reveals every place it doesn’t.

Many thick clients connect straight to a database with credentials baked into the application. Extract those, and an attacker often has direct database access, bypassing every business rule the application was supposed to enforce. This two-tier architecture is common in older enterprise software and is one of the most serious patterns we find.

First we understand what we’re dealing with: the language and framework, whether it’s a standalone two-tier client or a front end to web services, what it stores locally, and how it authenticates. This shapes everything that follows, because a Java client and a native C++ application fail in different ways.

We decompile the binary to read its logic, hunting for hardcoded secrets, weak cryptography, hidden functionality and the client-side checks that beg to be bypassed. .NET and Java assemblies often decompile back to near-original source, which means any secret in the code is effectively public.

Tools used in penetration testing of thick clients

The tools used in penetration testing at this layer are specialised. We reach for dnSpy and JADX to decompile .NET and Java, Ghidra for native binaries, Frida for runtime instrumentation and hooking, Process Monitor to watch file and registry activity, and proxies such as Burp Suite together with Echo Mirage or a configured system proxy to intercept traffic that doesn’t speak plain HTTP. None of it replaces the engineer’s judgement; it just gives them the view an attacker would have.

With the application running we watch it work: what it writes to disk and the registry, what secrets sit in memory, and whether we can hook functions with Frida to change behaviour on the fly. Bypassing a licence check or an authorisation gate at runtime proves that client-side enforcement is no enforcement at all.

We intercept and tamper with the traffic between client and server, checking for weak or absent transport security, missing certificate validation, and server-side trust in values the client should never be trusted to set. This is usually where a local weakness becomes a genuine breach, because the server takes the tampered request at face value.

Database passwords, API keys, encryption keys and connection strings hardcoded into the executable are the classic finding. Developers assume the compiled form hides them. Decompilation shows they don’t, and a single extracted database credential can expose everything behind the application.

Authorisation decisions, input validation, price calculations and feature gating done only on the client are all bypassable, because the client belongs to the attacker. We routinely re-enable disabled functions, open up restricted features and alter values the server then accepts without question.

Sensitive data cached in cleartext files, unprotected registry keys, or weakly encrypted local databases hand an attacker with access to the machine a rich supply of information, from credentials to personal data covered by GDPR.

An update mechanism that fetches code over an unauthenticated channel, or an application that loads libraries from a writable path, gives an attacker code execution on the user’s machine. These issues turn a business application into a foothold for wider compromise.

A plain-language read for leadership on what an attacker could do with a copy of your application, and which findings carry real business risk versus which are lower priority.

Every finding with impact, a CVSS score, reproduction steps and a concrete, developer-ready fix, whether that means moving a check to the server, removing a hardcoded secret, or hardening the update process. Decompiled snippets and screenshots back up each one.

An attestation letter for auditors and clients, and a no-cost retest after your developers remediate, to confirm the fixes hold when the same techniques are applied again.

If the desktop application touches cardholder data, PCI DSS 4.0 requirement 6 on secure software and requirement 11.4 on penetration testing both apply. ISO 27001 Annex A control 8.28 on secure coding and SOC 2’s expectations around secure development are directly supported by a thick client assessment, and testing follows the OWASP application-security guidance adapted for compiled clients.

Where the application processes personal data, GDPR Article 32 expects appropriate technical measures, and for financial entities DORA’s focus on the resilience of critical software includes the desktop tools that run core operations.