Thick Client Application Penetration Testing

Raxis tests desktop applications the way an attacker with a copy of the binary would. Including decompiling, tampering, and abusing the trust between the client and its backend.

Request a Quote Schedule Demo

The App on the Desktop Is Part of Your Attack Surface

A thick client runs on hardware you do not control, which means the attacker already has the code. Raxis tests what they can do with it.

HTML markup gear icon

Local Data, Local Risk

Thick clients cache data, configuration, and credentials on disk and in memory. Weak protection there turns a lost laptop into a data breach.

Arrow circle application icon

The Binary Is in Their Hands

Once an application is installed, an attacker can decompile it, read its logic, and pull hardcoded credentials, API keys, and connection strings straight from the executable.

ghost and pencil icon

Trust the Client Shouldn’t Have

Many desktop applications trust input from their own front end and talk to backend databases and services with more privilege than any user should hold. We follow that trust to see where it breaks.

Request A Quote Schedule Demo

What We Test

A Raxis thick client penetration test covers the application, the machine it runs on, and the systems it talks to. We work from a real installation the way an attacker would, not from source access we assume you can provide.

Reverse engineering and binary analysis

We decompile and disassemble the application with tools like Ghidra and dnSpy to expose logic, hidden features, and secrets baked into the code.

Local storage and configuration

Public and misconfigured S3 buckets, Blob storage, and GCP buckets that leak data or allow unauthorized writes.

Memory analysis

We examine the running process for credentials, tokens, and sensitive data held in memory longer than they should be.

Traffic interception

We intercept and manipulate the application’s network communication, testing for cleartext transmission, weak encryption, and SSL pinning that can be bypassed.

Client-side control tampering

We patch the binary and hook functions to defeat license checks, authentication logic, and controls the application assumes only it can enforce.

Backend and API abuse

We test the databases, APIs, and services the client connects to, chaining a compromised client into access it was never meant to grant.

Findings We See in the Wild

These are real vulnerabilities our engineers find in thick client applications again and again.

Hardcoded Secrets

API keys, database passwords, and encryption keys compiled straight into the executable and recoverable by anyone with the binary.

Cleartext Local Storage

Sensitive data and credentials cached on disk without encryption, waiting on any machine the application runs on.

Broken Authentication Logic

Login and authorization checks enforced only on the client, bypassed by patching a single function or return value.

Weak or Bypassable Encryption

Homegrown encryption, hardcoded keys, and SSL pinning that falls to standard interception tools.

Overprivileged Backend Access

Clients that connect to databases and services with far more privilege than the user needs, handing that access to anyone who compromises the app.

Exposed Debug Features

Hidden menus, verbose logging, and developer functions left in production builds.

Common Thick Client Architectures We Test

Thick clients come in many forms. We test them across the frameworks and platforms enterprises actually run.

.NET and WPF

Windows desktop applications, including WinForms and WPF, where decompilation and patching are often straightforward for an attacker.

Java Applications

Cross-platform desktop clients where bytecode is readily decompiled and inspected.

C and C++ Native

Compiled native applications requiring deeper reverse engineering, memory analysis, and binary patching.

Electron and Hybrid

Applications that wrap web technology in a desktop shell, exposing both thick client and web vulnerability classes.

Two-Tier Database Clients

Applications that connect directly to a backend database, where the client often holds credentials and privileges an attacker can reuse.

ERP and Line-of-Business Tools

Custom and vendor enterprise clients that handle sensitive data and integrate deeply with internal systems.

Thick Client Penetration Testing FAQ

It is a security test of a desktop application, one that runs on a user’s own machine and holds real logic and data locally. Our engineers work from an installed build the way an attacker would: decompiling the binary, reading its secrets, tampering with its controls, and abusing the databases and services it connects to.

A web app runs on a server you control, so the attacker only sees what you send them. A thick client runs on the attacker’s machine, so they have the binary, the local files, and the memory. That opens up reverse engineering, local storage attacks, and client-side tampering that a web application test never has to consider.

No. We work from a compiled build, the same starting point a real attacker has. Source access can speed up a review and help us reach deeper coverage, so we are glad to use it when you can share it, but it is never required.

A working installer or build, test credentials and a test environment for the backend it talks to, and a point of contact. If the application needs specific hardware, a license, or a particular OS to run, we will confirm that during scoping.

We prefer to test against a staging or test backend so there is no risk to production data. When only production is available, we avoid disruptive techniques by default, flag anything sensitive during kickoff, and agree on limits with you before we start.

Yes, and it usually surfaces the highest-impact findings. Thick clients often talk to their backend APIs and databases with broad privileges. Once we recover those credentials from the client, we test what that access actually unlocks. We scope the backend into the engagement so the two are tested together.

.NET and WPF, Java, native C and C++, Electron and other hybrid apps, two-tier database clients, and custom ERP or line-of-business tools. If it installs and runs on a desktop and talks to a backend, we can test it. Tell us the framework during scoping and we will confirm our approach.

Most engagements run one to two weeks, including reporting. Reverse engineering a large native application, or testing a wide backend behind it, moves it toward the longer end. We give you a firm timeline once scope is set.

Yes. When a desktop application handles regulated data, testing it supports PCI DSS, HIPAA, SOC 2, and similar frameworks, and satisfies auditors who expect application-layer testing beyond the network. Raxis reports include an attestation letter you can share with customers and partners.

Senior US-based Raxis engineers holding certifications such as OSCP and OSCE. No outsourcing, and no junior testers learning on your application.

Let’s Chat About Your Project

Have questions about penetration testing? Want a quote or just a better sense of how we work? Reach out. We’ll answer your questions, walk you through our services, and put together a scope that fits your environment. No sales pressure, no obligation. Just a straightforward conversation with our team.

Request a Quote Schedule Demo