Thick Client Security Testing: Methodology and Common Vulnerabilities
What is a Thick Client?
A thick client (also called a fat client or rich client) is a desktop application that performs significant processing locally, as opposed to a thin client which relies entirely on a server. Examples include ERP systems, banking applications, VPN clients, trading platforms, and enterprise software suites. They typically communicate with backend APIs or databases over the network.
Thick clients present a fundamentally different attack surface to web applications — the attacker has physical access to the executable, can intercept and modify all local processing, and can analyse the binary directly.
Two-Tier vs Three-Tier Architecture
Understanding the architecture is the first step in thick client testing. Two-tier applications connect directly to a database server — the database credentials are embedded in the application, making credential extraction a critical attack. Three-tier applications communicate with a middleware API layer which then accesses the database, resembling web application security more closely.
Two-tier architectures are significantly higher risk — a successful client compromise often yields direct database access.
Static Analysis
Binary Analysis
Begin by determining what the application is built with. Tools like Detect-It-Easy or PEiD identify the runtime (.NET, Java, Electron, native). .NET applications can be decompiled with dnSpy or ILSpy. Java applications can be decompiled with jadx or JD-GUI. Electron apps expose JavaScript source in the application resources.
Hardcoded Secrets
Search the application binary and configuration files for hardcoded credentials, API keys, connection strings, and private keys. Use strings on the binary, grep configuration files, and search the registry for stored values. Hardcoded database credentials are a critical finding in two-tier applications.
Sensitive Data in Configuration Files
Examine all configuration files in the application directory and AppData folders. Check app.config, web.config, settings.json, and any XML or INI files for credentials, internal hostnames, and API endpoints.
Dynamic Analysis
Network Traffic Interception
Proxy all application traffic through Burp Suite or OWASP ZAP. For HTTPS traffic, you must install a custom CA certificate and — for applications with certificate pinning — either bypass pinning using Frida scripts or patch the binary. Analyse traffic for: authentication flaws, unencrypted sensitive data, verbose error messages from the server, and insecure direct object references.
Process and Memory Analysis
Use Process Monitor (ProcMon) to observe file system and registry access. Use Process Hacker or x64dbg for memory inspection. Sensitive data such as passwords, tokens, and decryption keys often reside in process memory in cleartext even when stored encrypted on disk. Memory forensics tools like volatility can dump and analyse process memory.
Local Storage Analysis
Examine all locations where the application stores data locally: SQLite databases, XML files, the Windows Registry, credential managers, and browser storage (for Electron apps). Look for plaintext credentials, session tokens, and sensitive user data stored without encryption.
Common Thick Client Vulnerabilities
DLL Hijacking
Windows applications that load DLLs from the application directory without fully-qualified paths are vulnerable to DLL hijacking. An attacker with write access to the application directory can place a malicious DLL that gets loaded instead of the legitimate one, achieving code execution in the application context.
Insecure Update Mechanisms
Auto-update functionality that downloads updates over HTTP, lacks signature verification, or stores update packages in user-writable directories is vulnerable to man-in-the-middle attacks and local privilege escalation. An attacker can replace the update package with a malicious executable.
Client-Side Access Control
Business logic enforced only on the client is trivially bypassed. If the application hides an admin button based on a local flag, an attacker can patch the binary or modify memory to enable it. All authorisation decisions must be enforced server-side.
Insecure IPC
Applications using named pipes, COM objects, or local sockets for inter-process communication may be vulnerable if those channels lack proper authentication. Other processes or users on the same machine may be able to send commands to the application.
Testing Tools
- Burp Suite — HTTP/HTTPS traffic interception
- Wireshark — Low-level network analysis
- dnSpy / ILSpy — .NET decompilation and debugging
- jadx — Java decompilation
- Frida — Dynamic instrumentation and certificate pinning bypass
- x64dbg / OllyDbg — Native binary debugging
- Process Monitor — File system and registry monitoring
- CyberChef — Data decoding and cryptanalysis
Conclusion
Thick client penetration testing requires a broader skillset than web application testing — combining binary analysis, network interception, memory forensics, and traditional application security testing. The unique risks of local processing, embedded credentials, and client-side logic make thick clients a high-value target. A thorough assessment should cover all three layers: the client binary, the communication channel, and the backend services.