Thick client penetration testing from Sumrite for software that lives on the desktop.
Desktop apps hold session data locally and trust the network. We test installed clients the way attackers with laptop access would — memory, storage, updates, and traffic.
What this helps you achieve
Protect data on shared PCs
Find credentials in memory, logs, or config files.
Harden updates and installers
Reduce tampering and local privilege escalation.
Meet enterprise deployment reviews
Satisfy security for finance, healthcare, and government desktops.
Validate client-server trust
Ensure the app cannot be tricked into leaking data.
Sumrite’s testers run your thick client VAPT by hand, and the report is issued through a CERT-In empanelled auditor. One team from scoping to sign-off, built for Indian regulators, enterprise buyers and government work.
Accepted where it is requiredRegulators, auditors and procurement teams that ask for a CERT-In empanelled auditor’s report, including SEBI-regulated entities and government and PSU contracts.
One team, one contractSumrite handles scoping, testing, the report and the retest. You do not manage a second vendor.
Real testing, not a scanManual exploitation with evidence for every finding, and a retest after your fixes.
Yes. We run the full engagement for you and route the formal attestation through our network of CERT-In empanelled partner auditors, so you deal with one team from scoping to report.
What is thick client VAPT?
Thick client VAPT is a security test of software installed on a desktop or laptop, such as a trading terminal, a hospital records client, an internal finance tool or an Electron app. Unlike a web app, a thick client does much of its work on the user's machine, so it often stores session data locally, keeps secrets in memory or configuration files, and trusts the network more than it should. A tester examines the installed application the way an attacker with access to the laptop would: reading local storage and memory, decompiling .NET, Java or Electron code, intercepting traffic between the client and its server, and checking whether the installer or auto-update can be abused to run code or gain higher privileges. The server the client talks to is tested too, because a client-side check is no protection if the server trusts whatever it receives.
Thick client testing methodology
Information gathering: architecture, technology (.NET, Java, Electron, native), installer and update mechanism
An unsigned update path that runs attacker code as admin
How an engagement runs
Scope and NDA. Tell us what needs testing and why. You get a fixed-price quote and an NDA is signed before any technical detail changes hands.
Rules of engagement. Targets, test windows, accounts, safety contacts and anything off-limits are agreed in writing before testing starts.
Expert-led testing. A researcher tests by hand, using tools to speed up the routine parts. Every finding is reproduced and confirmed before it is reported.
Report. An executive summary for leadership, then each finding with a CVSS severity, the evidence, steps to reproduce and a fix your team can apply.
Re-test. Once fixes are in, we test them again and record the result, so the final report shows what was found and what is now closed.
Thick Client VAPT: common questions
Which desktop technologies do you test?
.NET (WinForms and WPF), Java, Electron and native Windows and macOS applications, together with the backend services they connect to.
Why test a thick client if the server is already tested?
The client often holds secrets, cached data and logic of its own. Attackers with access to one laptop can extract those, or use the client to send requests the server was never designed to receive.
We run the full engagement for these frameworks, and where a formal audit or attestation is needed we route it through our local partner firms, so you deal with one team.
Every phase is run by a security expert, with tools used only to speed up the routine parts. Findings are reproduced and confirmed before they reach your report.
Static and binary
Decompile .NET, Java and native binaries
Hard-coded credentials, keys and connection strings
DLL hijacking, side-loading and installer permissions
Local and runtime
Local storage, registry, configuration files and memory
Process hooking and tampering
Licence and client-side control bypass
Network and server
Interception of proxy-unaware and non-HTTP traffic
Server-side authorisation the client simply assumes
◆ Expert-only work: beyond scanners and AI
Reverse-engineering custom protocols
Hooking the client to test how far the server trusts it
Recovering credentials from memory
Chaining a local weakness into server compromise
Step 3 of 603
Draft report in 48 hours
Findings are written for two readers at once: developers who need the exact fix and auditors or buyers who need confidence.