Thick Client Penetration Testing

1.1. Requirements Gathering

• Installer: A working installer (.msi, .exe) or access to a standard "build" of the application.
• Environment: A virtual machine (usually Windows) that mimics the production user environment.
• Credentials: Two user accounts with different privilege levels (e.g., "User" and "Manager") to test authorization issues.

1.2. Define Scope

• Client-Side: The local binary, configuration files, and local storage.
• Server-Side: The network traffic and the backend API/Server.
• Exclusions: Underlying OS vulnerabilities or third-party services not owned by the client.

Analyzing the code without running it. This is often the most critical phase for thick clients.

2.1. Identify Language & Framework

• Use tools like CFF Explorer or Detect It Easy (DIE) to determine the language.
• .NET (C#): Common. Easy to decompile.
• Java: Common. Easy to decompile.
• C/C++: Native binary. Harder to reverse engineer (requires disassembly).

2.2. Decompilation / Disassembly

• Reverse engineer the binary to read the source code.
• .NET: Use dnSpy or ILSpy. You can often read the original C# code, modify it, and recompile it.
• Java: Use JD-GUI or JADX.
• Native (C/C++): Use Ghidra or IDA Pro to analyze assembly instructions.

2.3. Secret Hunting (Hardcoded Credentials)

• Search the source code/strings for:
• Strings Analysis: run the strings command on the binary to find interesting text patterns.

2.4. Configuration Files & Registry

• Check the installation directory for .config, .ini, .xml, or .json files.
• Check the Windows Registry (regedit) for keys created by the app.
• Vulnerability: Storing passwords or sensitive connection details in plaintext in these files.

3.1. Network Communication Analysis

• Open Wireshark or TCPView and run the application.
• Identify the protocols used:
• HTTP/HTTPS: Can be proxied easily with Burp Suite.
• TCP/Proprietary: Requires specific tools (Echo Mirage, NoPE plugin) or manual analysis.
• Direct DB Connection: Identify traffic on ports 1433 (SQL), 3306 (MySQL), or 1521 (Oracle).

3.2. Traffic Interception

• Proxying HTTP(S): Configure the system proxy to route traffic through Burp Suite. You may need to install the Burp CA certificate on the Windows Trusted Root store.
• Proxying TCP: If the app uses non-HTTP traffic:
• Use Echo Mirage (legacy) or Burp NoPE Proxy to hook the process and intercept traffic.
• Bypassing SSL Pinning: If the app refuses to connect through Burp, use Frida or modify the binary (via dnSpy) to remove the certificate validation check.

3.3. Client-Side Logic Bypasses

• Scenario: The "Admin" button is greyed out for your user.
• Attack:

3.4. Memory Analysis

• Use Process Hacker or Cheat Engine to search memory.
• Attack: Search for your password or sensitive data in RAM. If it exists in plaintext, it's a vulnerability.

4.1. Server-Side Injection

• Using the intercepted traffic (in Burp Suite), attempt standard injection attacks against the backend.
• SQL Injection: Especially common in 2-Tier apps where raw SQL might be constructed on the client.
• Parameter Tampering: Change price values, IDs, or privileges in the traffic before it reaches the server.

4.2. Privilege Escalation (Local)

• DLL Hijacking: Check if the application attempts to load DLLs from insecure paths (like the Downloads folder). An attacker could place a malicious DLL there to gain code execution.
• Unquoted Service Paths: If the app installs a Windows Service, check if the path contains spaces and lacks quotes.
• File Permissions: Check if the installation folder allows "Write" access for standard users. This allows a user to replace the .exe with a malicious one.

4.3. Other Common Thick Client Findings

• Hardcoded Credentials: DB passwords or API keys in the binary.
• Insecure Storage: Storing passwords in plaintext config files or Registry.
• Lack of Traffic Encryption: sending data over cleartext HTTP or TCP.
• Improper Authorization: Client-side checks only; backend accepts requests from low-privilege users for admin actions.
• DLL Hijacking: Vulnerable to local privilege escalation.
• Lack of Obfuscation: Code is easily decompiled (often accepted risk, but worth noting).

• Executive Summary: High-level, non-technical summary for management, focusing on business risk.
• Technical Report: Detailed report for developers.
• Vulnerability Details: For each finding:
• Description: A clear explanation (e.g., "OWASP M2: Insecure Data Storage").
• Affected Platform(s): (Windows, Linux, MacOS).
• Evidence: Screenshots, code snippets, HTTP requests, and file paths.
• Impact: The potential business impact.
• Risk Rating: (Critical, High, Medium, Low).
• Remediation: Provide clear, thick-client-specific, and prioritized instructions.
• Shift Logic to Server: Never trust the client. Perform all authorization checks on the server.
• Obfuscation: Use Dotfuscator or similar tools to make reverse engineering harder (though not impossible).
• Certificate Pinning: Enforce strict SSL pinning to prevent MitM attacks.
• Secure Storage: Use Windows DPAPI (Data Protection API) to encrypt local data instead of plaintext files.

• Present the findings in a debrief meeting.
• After the client's development team has implemented the fixes, perform a targeted re-test to validate that the vulnerabilities have been successfully remediated.