Thick Client Penetration Testing
Your desktop and client-server applications run on machines you don't control — and they carry the code, the credentials and the logic an attacker wants. We test them the way an attacker with that machine would: decompiling the binary, reading the memory, intercepting the protocol and reaching the backend behind it.
Veteran researchers. CERT-In empaneled. Manual, methodical, and far beyond what a scanner can crawl.
The surface a scanner can't crawl
A thick client is not a web page.
It is a compiled application that runs on the user's machine, performs real processing locally, stores data and configuration on disk and in the registry, and talks to its server — often over a proprietary or non-HTTP protocol. That design moves a large part of the application, and frequently its secrets, onto hardware an attacker may fully control. Connection strings, cryptographic keys, license logic, cached credentials and entire business rules can sit inside the binary, in local files, or in process memory — waiting for anyone willing to look.
Thick clients are also more bespoke than web or mobile applications, so they demand a deliberate, manual approach. Automated scanning barely applies: there is no URL to crawl, the traffic may never touch HTTP, and the most serious findings live in decompiled code, memory and disk. Our researchers reverse-engineer the client, intercept its communications, manipulate its controls and trust assumptions, and then exploit the server behind it — proving what an attacker could achieve from a workstation they already own.
"On a thick client, the application is already in the attacker's hands. We test from exactly that position."
Architecture defines the attack surface
How a thick client is wired changes everything about how it can be attacked. The first thing we establish is its architecture — because a two-tier and a three-tier design expose very different trust boundaries.
Client talks directly to the database
The application on the user's machine connects straight to a database server. Convenient to build — and dangerous, because the client must carry database connection details and credentials, and the database trusts a client the attacker controls. Recovering those credentials or crafting queries directly against the database is often the shortest path to compromise.
Client talks to an application server, which talks to the database
An application server sits between the client and the database, so the user never reaches the data store directly. This is the stronger pattern — but it only holds if the server treats every request from the client as untrusted. We test whether that middle tier truly enforces authentication, authorization and validation, or whether a manipulated client can still drive it.
Four surfaces, one attacker mindset
A thick client has to be attacked everywhere it lives at once — in its files and binaries, in its memory, on the wire, and on the server it trusts. We work systematically across all four surfaces.
We map the application before we attack it: its architecture, the platform and infrastructure it depends on, the languages and frameworks it is built with, and the business logic it implements. This tells us where the secrets and the trust boundaries are, and which known weaknesses its components carry.
The work scanners cannot do. We analyze the files the application writes (configuration, logs, cached data), perform static analysis by decompiling the binary, perform dynamic analysis by reverse-engineering it at runtime, and inspect process memory for sensitive information and the chance to manipulate it directly.
We intercept and analyze the application's communications — both the traffic generated during installation and update, and its run-time traffic — to surface sensitive information in transit and to reach and test the APIs and services it talks to, including protocols that never touch HTTP.
A thick client is a doorway to a backend. We test that backend the way any attacker would: protocol-level abuse such as flooding and buffer overflows, and the full application-layer attack surface — the OWASP-class injection, authentication and access-control flaws behind the client.
A disciplined, attacker-led methodology
We work to a structured methodology aligned with industry standards — the OWASP Thick Client Application Security Verification Standard (TASVS) and the OWASP Desktop App Security Top 10 — so coverage is repeatable and defensible, while the exploitation itself stays creative and adversarial. Every thick client engagement is organized around four attack surfaces, each broken down into the specific techniques we apply.
What we look for
The findings that matter on a thick client rarely appear in a scan report. These are the classes we reach by hand.
Hardcoded secrets
Credentials, API keys, connection strings and license logic embedded in the binary or recoverable through decompilation.
Insecure local storage
Sensitive data, configuration and cached credentials written to disk, the registry or temp files in clear text or with reversible protection.
Weak cryptography
Home-grown, outdated or improperly used encryption that an attacker can defeat to expose stored or transmitted data.
DLL hijacking & binary tampering
Insecure library loading, missing integrity checks, and binaries that can be patched to bypass licensing or security controls.
Sensitive data in memory
Secrets and tokens left exposed in process memory, recoverable by dumping or instrumenting the running application.
Insecure deserialization
Untrusted data deserialized by the client or its backend in ways that lead to tampering or code execution.
Broken access control & trust boundaries
Client-side security controls and privilege checks that the server fails to re-enforce, allowing a manipulated client to do more than it should.
Backend injection
SQL and other injection reaching the database or application server through the channels the client uses.
This is a manual discipline. Tooling assists; it doesn't assess.
On a web app, a scanner gives you breadth. On a thick client, there's almost nothing for it to crawl — so the work is human from the start.
The right instruments, in expert hands
We use specialized tooling throughout — decompilers and debuggers, binary and dependency analyzers, process and registry monitors, memory inspectors, and proxies that can intercept proprietary, non-HTTP protocols. These tools accelerate a researcher; they do not replace one. Every output is interpreted, and a custom test setup is built for each application.
Where the real findings live
The serious issues — recoverable secrets, defeatable encryption, manipulable memory, bypassable trust boundaries and the injection behind the client — require a human who can read decompiled code, reason about intent and chain weaknesses into impact. Our researchers reverse-engineer, intercept, manipulate and exploit, surfacing what no automated scan is built to find.
Choose the depth of visibility
We tailor the engagement to how much we know going in. More context means deeper coverage in the same time.
We test the application from the outside with no internal knowledge or documentation — exactly as an attacker who has only the installed client would. Best for validating the real-world exposure of a shipped application.
We test with partial knowledge: valid accounts across roles, architecture or data-flow documentation, protocol or API details, and an application walk-through. This is the most common and cost-effective model, letting us reach authenticated, role-specific and backend flaws far more efficiently.
We test with full visibility — including architecture and, where in scope, source code — for the deepest coverage of complex, high-value or business-critical clients.
How an engagement works
A clear path from a controlled test environment to remediation — designed to give your team findings they can act on immediately.
What we can test
The same attacker mindset extends across every platform your clients run on — and the systems behind them.
What you receive
Every engagement ends in a report your team can act on — written for both the engineers who will fix the issues and the leaders who must understand the risk.
Executive summary
Risk posture and business impact in plain language for leadership.
Detailed findings
Each issue with severity, affected component, reproducible proof-of-concept and clear evidence.
Remediation guidance
Specific, prioritized fixes — not generic advice.
Standards mapping
Findings mapped to the OWASP Thick Client Application Security Verification Standard (TASVS) and the OWASP Desktop App Security Top 10.
Remediation retest
We re-verify fixes so you can confirm the risk is genuinely closed.
Direct researcher access
A debrief with the people who did the testing, not a handoff to a call centre.
Supports ISO 27001, SOC 2, PCI-DSS and RBI/SEBI assessment requirements
Frequently asked questions
Why can't a regular vulnerability scanner test our desktop application?
Scanners are built for web surfaces they can crawl. A thick client has no URLs to enumerate, often communicates over non-HTTP protocols a scanner can't read, and keeps its most serious weaknesses inside compiled code, local storage and memory. Reaching those requires reverse engineering, traffic interception and manual analysis — a human discipline, with tools as assistants.
Do you need our source code?
No. We can assess a thick client from the compiled binary alone (black-box) by decompiling and instrumenting it. Source code, architecture documents and valid accounts (grey-box or white-box) let us go deeper and faster — but they are an accelerant, not a requirement.
Will testing affect our production systems?
We work in a representative, isolated test environment by default and scope any production-facing testing explicitly with your team. Protocol-level tests such as flooding are conducted only under agreed conditions so they never disrupt live operations.
Two-tier or three-tier — does it matter for the test?
Yes. A two-tier client carries database credentials and is trusted directly by the data store, so recovering those credentials is a priority. A three-tier design adds an application server, and we focus on whether that server re-validates every request from a client the attacker controls. We confirm the architecture during scoping.
How often should we test?
At minimum annually, and after any significant change to the client, its protocols, its cryptography or its backend — as well as when compliance requires it.
Do you retest after we fix the issues?
Yes. Remediation retesting is included so you can confirm each finding is genuinely resolved.
Find it before they do.
Tell us about your desktop or client-server application and we'll scope an assessment that fits — or connect you directly with a researcher.