Overview
Desktop clients still run trading tools, clinical workstations, point-of-sale back offices and engineering software across many US organizations. They often trust the local machine too much, keeping secrets on disk or talking straight to a database. We examine the binary, its traffic and its update path, then show which weaknesses a user on a shared or compromised workstation could exploit.
A thick client puts code and often credentials on the user's own machine, which changes the threat model entirely. We start on the host, inspecting how the application stores configuration, connection strings, tokens and cached data, and whether a standard user can read secrets, tamper with files or escalate privileges through weak permissions, services or installers.
We then turn to the binary and the wire. Reverse engineering reveals hard-coded secrets, hidden functionality and weak cryptography, while runtime analysis shows how the application behaves when its inputs and memory are manipulated. For two-tier designs that connect directly to a database, we test whether the client's trust can be abused to run queries or reach data the user should never touch; for three-tier designs we test the service in between.
The goal is to show what an insider or a compromised endpoint can actually achieve, not to list theoretical weaknesses. Every finding is reproduced, scored with CVSS v4.0, and paired with a fix aimed at the right layer, whether that means moving trust to the server, tightening file permissions, or removing secrets from the client. Critical issues are reported as soon as we confirm them.
How US engagements run
- Delivered remotely from India, 9.5 hours ahead of US Eastern in US daylight time and 10.5 hours in winter; calls and testing windows are set around your time zone at scoping
- Fixed-price proposals in US dollars, with scope, dates and the free retest written in before any work begins
- Written authorization signed by someone with authority over every target, because the federal Computer Fraud and Abuse Act and state laws make permission the dividing line
- Reports that name the requirement a test supports, such as PCI DSS 11.4, the FTC Safeguards Rule or SOC 2, without claiming a QSA, ASV or C3PAO role we don't hold
What's included
Our approach
- Environment setupWe install the client with test accounts and map its architecture and dependencies.
- Host reviewWe inspect local storage, permissions and privilege paths on the machine.
- Binary & runtimeWe reverse engineer and instrument the binary to observe its real behavior.
- Traffic testingConnections to databases and services are intercepted, replayed and manipulated.
- Report & debriefFindings are evidenced, scored and explained to your application owners.
What you receive
- Architecture summary with identified trust boundaries
- Risk-rated findings with reproduction evidence
- CVSS v4.0 scores and layer-specific remediation
- Analysis of client-side versus server-side enforcement
- Free retest of fixed issues and an attestation letter
Standards & frameworks
- OWASP ASVS
- PTES
- NIST SP 800-115
- MITRE ATT&CK
- CVSS v4.0
- CWE
- SOC 2
Frequently asked questions
What do you need to test a thick client?
An installer or build, test accounts for each role, and a test instance of any database or service it connects to. If the application only runs against production data, we agree safe limits in writing and favor non-destructive techniques throughout.
Can you test an old application you do not have source for?
Yes. Legacy clients are common and we routinely test compiled binaries without source. Reverse engineering, host inspection and traffic analysis let us assess an application whose developers have long since moved on.
Why test the database connection?
Two-tier applications often trust the client to behave, which means a user who can read the connection string or craft their own queries may reach data the interface never shows. Testing that path reveals whether real enforcement lives on the server or only in the client.
Will a SOC 2 auditor accept your application pentest report?
Penetration testing isn't written into the SOC 2 criteria, yet it is common for auditors and enterprise buyers to look for a recent test. Our report records scope, dates, method and rated findings, and the retest letter shows what was fixed. Your auditor still decides which evidence they accept.
Can testing fit around our US release schedule?
Yes. Testing windows, call times and code-freeze periods are agreed around your time zone at scoping. We deliver from India, which is 9.5 hours ahead of US Eastern during US daylight time and 10.5 hours in winter, and any critical issue is passed to your nominated contact the day it is verified.