Why it matters

Why desktop apps need their own test

A thick client does much of its work on the user's machine. Anything it stores, checks or decides locally can be read and changed by anyone who has the application, including an attacker who has compromised a single endpoint.

Many thick clients also talk directly to databases or internal services that were never designed to face an untrusted user. A web application test won't find those paths.

The risks go beyond the binary: credentials decrypted in memory at runtime, local services running with more privilege than the user, session artefacts that can be replayed, and back ends that trust any client that looks the part.

Scope

What we look at

Local storage and configuration

Credentials, keys, tokens and sensitive data left in configuration files, the registry, logs or temporary files.

Client-server traffic

What the client sends and receives, whether it's encrypted and authenticated, and whether it can be intercepted and changed.

Client-side security controls

Authentication, licensing and authorisation decisions made in the client that the server should be enforcing.

Binary analysis

Reverse engineering of the application for hard-coded secrets, hidden functionality and weak protection against tampering.

Local privilege escalation

MSI installers, services, file permissions and DLL loading that could let a standard user take over the machine.

Back-end services

The databases, APIs and services the client connects to, and how far a compromised endpoint could reach into the back end and move across your network.

Our approach

How we test it

  1. 01

    Understand the application

    We install and use the client as your users do, mapping its features, data and the services it talks to.

  2. 02

    Attack the client

    We analyse the binary, its local data and its traffic, and tamper with it to bypass controls.

  3. 03

    Attack the back end

    We use what we've learned to test the servers behind the client, as an attacker with a modified copy would.

What we find

Common weaknesses

Every finding comes with evidence, a risk rating and practical remediation guidance, and a free retest once it's fixed.

  • Hard-coded credentials

    Connection strings, API keys or passwords embedded in the binary or shipped configuration.

  • Controls enforced only in the client

    Permission checks the server trusts the client to make, which a modified client simply skips.

  • Modifiable client

    Binaries, configuration and service communications with no tamper resistance, so an attacker can change how the client behaves.

  • Direct database access

    Clients that connect straight to a database, exposing it to any user who extracts the credentials.

  • Unprotected traffic

    Plain-text or weakly authenticated protocols that can be read or changed in transit.

  • Local privilege escalation

    MSI repair actions, writable install folders, weak service permissions or DLL search-order issues that hand over the endpoint.

FAQ

Common questions

What do you need from us to test a thick client?

An installer or a build of the application, test accounts at each relevant permission level, access to a test environment for the services it connects to, and any technical or architectural documentation you have.

Do you test applications built on any technology?

We test common desktop technologies, including .NET, Java and native Windows applications. Tell us what your application is built on when we scope the work.

Do you test the server side as well?

Yes. Many of the most serious issues are in the services behind the client, so we test them from the point of view of an untrusted client.

Specialist testing

More specialist testing

See all our penetration testing

Between tests: attack surface management and continuous vulnerability management.

Find out what a copy of your client gives away

Tell us what you need tested and we'll give you a fixed-price quote and a clear scope, with a free retest included.