SXGuard — Swiss Security
...
Thick Client Penetration Testing
Methodology

Thick Client Penetration Testing

Static and dynamic analysis of locally installed desktop applications and the proprietary protocols behind them.

A desktop workstation running an installed business application

I) Introduction

Definition

A "Thick Client" (or Fat Client) is a full-featured desktop application installed locally on a user's machine. Unlike a web browser, it performs significant processing locally but relies on a connection to a backend server or database to function.

Primary Goal

The goal is to identify vulnerabilities in both the local application logic (client-side) and the communication/backend logic (server-side). Attackers often target thick clients to bypass logic checks, steal hardcoded secrets, or exploit the backend API.

Architecture Types

  • Two-Tier (Client-Server): The client connects directly to the database.
Client
direct connectionDatabasecreds in binary

High Risk: Often contains DB credentials in the binary

  • Three-tier (client - app server - database): The client connects to an application server (API), which then talks to the database. (More secure, similar to web apps).
Client
API callApp serverholds the credentials
Database

II) Penetration Test Phases

Phase 1: Planning and Scoping

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.

Phase 2: Static Analysis

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:
    • Database connection strings (User/Pass).
    • API Keys or Encryption Keys (AES, RSA).
    • Hardcoded "Backdoor" passwords for admin accounts.
  • 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.

Phase 3: Dynamic Analysis

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:
    • GUI Manipulation: Use tools like WinSpy++ or Enabler to forcefully enable greyed-out buttons.
    • Runtime Mod (dnSpy): Pause the application in the debugger, find the boolean isAdmin = false, change it to true, and resume.

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.

Phase 4: Exploitation

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).

Phase 5: Reporting

  • 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.

Phase 6: Remediation & Re-testing

  • 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.
Back to all services

Ready to scope this engagement?

Tell us about your environment and objectives — we'll return a tailored scope, timeline, and quote within 24 hours.

Request a Free Scoping Call