Thick Client Penetration Testing Methodology: A Step-by-Step Breakdown

Why Thick Clients Need Their Own Methodology

Most penetration testing methodology is written for the web. That is a problem for desktop software, because a thick client breaks the central assumption web testing rests on: that the attacker only ever sees what the server chooses to send.

A thick client, sometimes called a fat client or rich client, installs and executes on a workstation the user controls completely. Its binary can be copied and decompiled. Its memory can be read. Its configuration files, registry keys and local databases sit on disk. Its network traffic can be intercepted and rewritten. Every control the developer placed in the client is, from the tester’s perspective, a suggestion.

These applications are also disproportionately concentrated in high-value environments. Trading platforms, electronic health record systems, enterprise resource planning software, industrial control interfaces and custom line-of-business tools built on .NET, Java, Electron and C++ are exactly where the sensitive data lives. This article walks through the methodology DarkPoint follows on a thick client penetration test, phase by phase.

Phase 1: Scoping and Environment Preparation

Thick client engagements need more preparation than most. Before testing begins, the tester needs the installer or application package, a representative environment that is ideally not production, and test accounts at every privilege level the application supports — including at least one administrative account, because a large proportion of findings are only provable by comparing what different roles can reach.

Scoping also has to settle a question web tests rarely face: which back-end services are in scope. A thick client typically speaks to APIs, databases, message queues or licensing services, and some of those may be third-party hosted and require separate authorization. Rules of engagement should record which components may be tested, which are observation-only, and how the tester should handle a finding that reaches beyond the agreed boundary.

Phase 2: Architecture and Attack Surface Mapping

The first testing activity is understanding what the application actually is. The tester identifies the development framework and runtime, catalogues installed files, services, scheduled tasks and drivers, and maps every channel the application communicates over — network sockets, named pipes, COM interfaces, local sockets, shared memory and the filesystem.

The output is an attack surface map covering both halves of the application: what runs locally, and what it depends on remotely. Almost every later phase draws on this map, and it routinely reveals components the organization had forgotten shipped with the product.

Phase 3: Static and Binary Analysis

Managed languages give up their source readily. .NET assemblies and Java bytecode decompile to near-original code, and Electron applications are typically packaged archives containing plain JavaScript. Native C and C++ binaries require disassembly and more patient work, but the objective is identical.

The tester examines the recovered code for:

• Hardcoded secrets — API keys, encryption keys, connection strings and service credentials embedded in the binary or its resources.
• Client-side security controls — authorization checks, licence validation, and feature gating implemented in the client, each of which is a candidate for bypass.
• Cryptographic implementation — custom or obsolete algorithms, hardcoded initialization vectors, keys derived predictably, and encryption used where signing was required.
• Binary protections — whether the application is obfuscated, signed, and compiled with the exploit mitigations its platform offers.

Anything found here is a lead, not yet a finding. It becomes a finding when a later phase proves it is reachable and exploitable.

Phase 4: The Local Attack Surface

This is the phase with no web application equivalent, and it is where thick client tests earn their keep.

• Local storage — configuration files, embedded databases, logs, caches and temporary files are examined for credentials, tokens, personal information and business data, along with the filesystem permissions protecting them.
• Registry and system configuration — Windows applications frequently store connection details and licensing state in registry keys that any local user can read, and sometimes write.
• Process memory — the tester inspects the running process for credentials, session tokens, encryption keys and decrypted records that persist far longer than they should.
• Inter-process communication — named pipes, COM objects, local sockets and shared memory are tested for missing authentication and weak access controls, since an unprivileged process on the same host can often reach them.
• DLL and dependency loading — search order hijacking and unsigned dependency loading are tested, because both turn an application flaw into local privilege escalation.
• Update mechanisms — the tester checks whether updates are delivered over an authenticated channel and whether their integrity is verified before execution, since an insecure updater is a reliable path to code execution.

Phase 5: Network and Protocol Analysis

Thick clients often speak protocols that were never designed to be inspected, which is precisely why they deserve inspection.

The tester intercepts client-server traffic, which frequently requires defeating certificate pinning or working with a proprietary binary protocol rather than HTTP. Once traffic is visible and modifiable, testing covers whether transport encryption is present and correctly validated, whether the protocol authenticates every request or trusts a session established once, whether messages can be replayed or tampered with, and whether the client can be made to talk to an attacker-controlled endpoint.

Applications that connect directly to a database deserve particular attention. A thick client holding database credentials and issuing queries on the user’s behalf often grants far more access than the interface suggests, and that access is available to anyone who can read the connection string recovered in Phase 4.

Phase 6: Server-Side Testing

Everything to this point establishes what the client can be made to do. This phase establishes what the server will accept when asked.

The tester takes the controls identified in the client and tests whether the server independently enforces them. Authorization is the recurring failure: an operation hidden from a standard user in the interface is very often permitted when the request is issued directly. The same applies to input validation, business logic constraints, quantity and price limits, and workflow ordering. Authentication and session management are tested here too — token lifetime, revocation, and whether privilege changes take effect server-side or only in the client’s local view.

The guiding assumption is straightforward: treat the client as hostile, and test whether the server was written as though it agreed.

Phase 7: Exploitation and Impact

Findings are then chained into demonstrations of real impact. A hardcoded key recovered from the binary is used to decrypt data it was never meant to unlock. A client-side authorization check is bypassed and the resulting privileged request is accepted by the server. A connection string extracted from a configuration file is used to reach the database directly. A hijackable DLL path is used to escalate privileges on the workstation.

Exploitation is what separates a list of observations from a report that justifies remediation budget. Each chain is evidenced and reproducible, and each is executed within the rules of engagement agreed in Phase 1.

Phase 8: Reporting

The deliverable includes an executive summary written for leadership, technical findings with severity ratings, reproduction steps and evidence, and prioritized remediation guidance. Thick client reports need to be explicit about where each fix belongs, because the correct remediation for a client-side control failure is almost always a server-side change. Where the engagement supports an audit, findings are mapped to the relevant framework requirements.

From Methodology to Engagement

Thick client testing is manual work that cannot be automated away, and it demands skills — binary analysis, memory inspection, protocol reverse engineering — that general application testers often do not carry. It is one of the reasons many firms quietly decline these engagements.

If you run desktop software that handles sensitive data, learn more about our thick client penetration testing service. Because most thick clients depend on a server-side API, these engagements frequently pair with API penetration testing, and organizations testing a full application estate often combine both with a web application penetration test. To scope an engagement, contact us.