Thick Client Application Penetration Testing Guide

Why Thick Client Pentest Still Matters

Thick client applications are desktop programs that run a meaningful share of their business logic on the user's machine, in contrast to thin clients (web browsers) that mostly render server-rendered content. Many Indian sectors are still heavily thick-client: core banking front-ends, brokerage trading terminals, life and general insurance underwriting tools, ERP and tally-style accounting suites, dealer-management systems, healthcare imaging viewers, and government-front-line citizen-service apps.

These applications were largely built before modern threat models existed. They commonly run with elevated privileges, read and write the Windows registry, install local services and scheduled tasks, store credentials in registry or local files, and talk to backend systems over custom binary protocols or direct database connections. None of this is wrong by itself, but it creates an attack surface that web pentest methodology does not cover.

Two-Tier vs Three-Tier: The Threat Model Diverges

Two-tier thick client architectures connect the client directly to a database server (Oracle, SQL Server, PostgreSQL, Sybase). The thick client embeds the database connection string, the credential, and the SQL queries. The client is, in security terms, the application layer. SQL injection, where present, runs on the client side; database credentials are recoverable from the binary or memory.

Three-tier architectures place an application server between the client and the database. The client talks to a custom binary protocol or a SOAP/REST/gRPC endpoint, and the application server brokers all database access. This is closer to a modern web architecture, and many of the same testing techniques apply at the application server layer.

Indian banking sees both. Some core banking front-ends are pure two-tier (and as a result extremely sensitive). Trading terminals often have a hybrid: a binary TCP feed for market data (one-way) plus a three-tier service for orders. Methodology diverges in the first hour of the engagement, after we identify which model the application uses.

Reconnaissance and Binary Analysis

Step one is identification: what language and framework is the binary? PEStudio, Detect-It-Easy, dnSpy for .NET, Resource Hacker for embedded resources, and strings for low-effort discovery of hardcoded connection strings, internal hostnames, secrets and debug messages.

.NET binaries are typically decompiled cleanly with dnSpy or ILSpy. Native C++ binaries require IDA Pro, Ghidra or Binary Ninja. Obfuscation (ConfuserEx, Dotfuscator, VMProtect) is encountered occasionally and slows but does not stop analysis.

Key things to look for at this stage: hardcoded credentials, hardcoded API keys and signing keys, hardcoded encryption keys (AES with a constant key is depressingly common), client-side authentication or licence checks (often easily patched), client-side input validation that the server then trusts, internal IP and hostname leakage, debug or backdoor menu options activated by registry keys or hotkeys.

Traffic Interception: HTTP, TLS, Custom Binary

Web traffic from the client is trivially intercepted with Burp or mitmproxy as a system proxy plus a trusted CA on the workstation. Where the client uses HTTP but ignores the system proxy, Proxifier or netsh winhttp can force traffic through a local intercept.

TLS with certificate pinning is the harder case. We use Frida hooks on the client process to override the certificate validation routine, or for .NET we patch the certificate-validation callback at runtime. Where this fails, sometimes a Windows network driver (winsock SSL hook) is needed.

Custom binary protocols over TCP require packet captures with Wireshark, plus protocol reverse engineering. The Burp Non-HTTP Proxy extension and dedicated tools like CANAPE help. Once the protocol structure is decoded, replay and fuzz testing surfaces authentication and message-handling weaknesses fast.

Memory, Process and DLL Analysis

Process Hacker, Process Explorer and Sysinternals VMMap are used to inspect the running process. We look for: command-line arguments containing secrets, open handles to sensitive registry keys or files, child processes spawned in the user context, named pipes and local TCP listeners, and the working directory contents (often a goldmine of plaintext logs).

Memory dumps with procdump or WinDbg are searched for plaintext passwords, session tokens, decrypted PII and database connection strings that were decrypted in memory at runtime even when stored encrypted on disk.

DLL hijacking and side-loading are tested with Process Monitor: identify DLLs the application loads from user-writable paths, drop a malicious DLL there, watch the application execute it under the application's privilege. Many Indian thick-client deployers install the binary into the user's home directory rather than Program Files, which makes this attack trivial.

Registry, Filesystem and Local Storage

Thick clients persist data locally. We sweep the Windows registry (HKCU and HKLM hives belonging to the application), AppData (Roaming and Local), ProgramData, and the application's install directory. Findings commonly include: plaintext passwords, plaintext API keys, recently accessed customer records, cached database queries, debug log files with PII, recovery tokens, licence keys and Windows DPAPI blobs.

DPAPI blobs are interesting: they are bound to a user's Windows credential, so an attacker who can read the blob and the user's login credential (or who runs as the same user) can decrypt them. This is fine within the user's context but completely insecure as a defence against another user on the same machine, the IT helpdesk, or a compromised local admin.

Server-Side Testing (Three-Tier and Hybrid)

Where the thick client talks to an application server, we test the server-side endpoints as well, using OWASP API Top 10 methodology where the protocol is HTTP-based, and custom test plans where the protocol is binary. Common server-side findings: trusting client-supplied user IDs, role flags, branch codes or account-segment codes (the equivalent of mass assignment in API world), missing authorisation checks on individual operations (function-level authorisation gaps), and inadequate input validation on the server because the client already validated.

For two-tier apps, the SQL traffic to the database is itself the testable surface. Direct SQL injection, stored procedure abuse, and privilege escalation through database roles are tested. We coordinate with the customer DBA on read-only test environments wherever possible.