VAPT

VAPT of Thick Client Applications

Thick clients are the applications that never got a security review. They predate the web team, they run on machines the user controls, and they frequently hold database credentials in a configuration file because that was normal when they were written. Testing covers the binary, the host it runs on and the backend behind it, since a client running on the user's desktop is an attacker-controlled component of the system.

Methodology

01
Binary and dependency analysis
Executable and library inventory, compiler protections, code signing, installer behaviour and the versions of every bundled third-party component.
02
Decompilation and static review
For managed code, decompilation to source and review for hardcoded credentials, connection strings, cryptographic keys and authorisation logic. Native binaries are disassembled where the risk justifies it.
03
Local storage and privilege assessment
Configuration files, registry keys, local databases, temporary files and log output examined for secrets. Installation directory and service permissions checked for local privilege escalation.
04
Inter-process communication testing
Named pipes, COM objects, local sockets, shared memory and Windows services exposed by the application, tested for authentication and authorisation from a low-privileged context.
05
Traffic interception
Network traffic proxied, including non-HTTP protocols and direct database connections. Where the client talks to a database directly, that connection is the finding.
06
Runtime manipulation
Memory inspection and patching, control flow modification, and testing whether authorisation decisions made in the client are re-checked by the server.
07
Backend testing
Every service the client calls tested independently for authentication, authorisation and injection.
08
Reporting and retest
Technical report and executive summary together, then a retest evidencing closure.

Approach to testing

The client is treated as attacker-controlled. Any control implemented only in the binary is assumed bypassed, and the test is whether the server notices.
Direct database connectivity from the client is tested explicitly. Where present it is usually the most severe finding, because every user holds credentials that reach the data directly.
Testing runs from a standard, non-administrative Windows account, because that is how the application is deployed and privilege escalation from that position is the realistic risk.
The installer is assessed as part of the application — DLL search order, service creation permissions and update mechanisms are common escalation paths.
Grey box by default: an installable build, test credentials for at least two roles, and documentation of the backend interfaces.

Types of assessment

Grey box (default)

Installable build with credentials for multiple roles. Best coverage per unit of effort.

White box

Full source and build pipeline. Necessary where the client contains significant business logic or cryptography.

Privilege escalation focus

Narrow scope on whether the application allows a standard user to gain local administrator on the host. Common requirement for managed desktop estates.

Backend-only

Where the client is legacy and unchangeable, testing concentrates on whether the server can defend itself against a malicious client.

Frameworks and standards

OWASP ASVS 4.x: Verification controls applied to the client and its backend.
CWE Top 25: Weakness taxonomy, which fits desktop software better than web-specific lists.
NIST SP 800-115 / PTES: Testing lifecycle and exploitation standard.
CIS Microsoft Windows Benchmarks: Host baseline where the client's installation affects it.
CVSS v3.1: Severity scoring, with local attack vector reflected honestly rather than inflated.

Tools used

Tooling is where testing starts, not where it ends. Every automated result is reproduced by hand before it reaches a report.

dnSpy / ILSpy

Decompilation and runtime patching of .NET assemblies.

JD-GUI / Procyon

Java decompilation.

Ghidra

Disassembly and analysis of native binaries.

Process Monitor / Process Explorer

File, registry and process activity, and DLL search order analysis.

Burp Suite with a non-HTTP proxy

Traffic interception including protocols Burp does not natively handle.

Wireshark

Raw protocol analysis, particularly for direct database connections.

Frida

Runtime hooking and memory manipulation.

AccessChk / icacls

File, service and registry permission assessment for escalation paths.

Checklist approach

The checklist is the floor, not the ceiling. It guarantees coverage so nothing standard is missed; the findings that matter usually come from what a tester does after it is complete.

Secrets and configuration

Connection strings and credentials in configuration files or the registry
Hardcoded cryptographic keys in the binary
Secrets written to logs or temporary files
Credentials cached locally after authentication
Encryption of local configuration and its key storage

Local privilege escalation

Write permissions on the installation directory
Unquoted service paths and weak service permissions
DLL search order hijacking opportunities
Scheduled tasks or services running as SYSTEM with user-writable inputs
Update mechanism integrity and signature verification

Inter-process communication

Named pipe permissions and authentication
COM object registration and access control
Local listening sockets and their authentication
Shared memory access control

Network and backend

Direct database connectivity from the client
TLS usage and certificate validation on all connections
Authorisation re-checked server-side for every client action
Injection through parameters the client sends
Session handling and token storage

Binary protections

Code signing on executables and libraries
ASLR, DEP and stack protections on native binaries
Obfuscation of managed assemblies where business logic warrants it
Anti-tamper and integrity verification
Third-party component versions against known CVEs

How findings are scored

Every finding is scored on CVSS 3.1 and placed in one of five levels. The executive summary adds a sixth band — Compliant — so components that passed appear on the same chart as those that did not.

Critical: Immediate measures must be taken. These vulnerabilities can allow an attacker to take complete control of the application or server — stealing user data, tricking users into supplying sensitive information, or defacing the site.
High: Maximum risk associated with a specific vulnerability instance. May enable an attacker to compromise the application and its data, partially or completely, or to modify application behaviour beyond its intended purpose. To be handled with utmost priority.
Medium: Considerable risk. May enable an attacker to exploit the application to a particular level, gaining low-level information that can be used to craft more specific attacks.
Low: Lowest risk. May allow an attacker to gain some information about the application that was not intended to be known, without an exploitation technique currently available at that instance.
Informational: A functionality or component is missing best-practice implementation. Not a risk today, but may become one as the application changes or as exploitation techniques, policy or legal requirements evolve.

Scan types selected

Safe Checks
Standard / OWASP Top 10
Destructive
SANS Top 25
Business Logic Vulnerability Testing

Standard toolset by stage

OSINT: Datasploit, Google Dorks, Shodan
Enumeration & Scanning: Nmap, Wfuzz, Unicornscan
Domain Enumeration: Nikto, DnsRecon, Knock
Crawling & Fuzzing: Burp Suite, Acunetix, Netsparker
Vulnerability Analysis: OpenSSL, sqlmap, CVE-Details
Exploitation: Metasploit, Netcat, Exploit-DB

Free toolkit

Penetration Testing Checklists

Sixteen assessment checklists covering the targets we test: web applications, Android, iOS, APIs, networks, Active Directory, thick clients, WiFi, SCADA and ATMs — plus red team test cases, firewall audit, malware analysis and vendor security assessment.

16 checklists · ZIP · 775 KB

Download the toolkit

Deliverables

Technical assessment report (PDF)
Executive summary (PDF, one page)
Finding register (spreadsheet)
Proof-of-concept artefacts: patched binaries, captured traffic, escalation scripts
Remediation walkthrough with the development team
Retest report evidencing closure

Frequency

One-time: A first assessment of a legacy application, or a gate before wider deployment.
Biannually: Applications under active development, or handling financial or regulated data.
Annually: Stable legacy applications with no development activity, where the assessment confirms nothing has drifted.
Per major release: Triggered by changes to authentication, data handling, the update mechanism or the installer.

Resource deployment

Thick client testing usually requires a build of the standard operating environment, which is easiest to provide as a virtual machine image. Where the application cannot be installed outside the client estate — common for applications with hardware dongles, domain dependencies or licence servers — testing runs on site. A typical on-site engagement places one tester with the client for three to four days, with decompilation and reporting completed remotely where the binary may leave the premises.

How CSS tests

A unified swarm of agents, for blind spot detection

AI agents drive several testing tracks against the same target at once, then cross-check each other. A single tester works one hypothesis at a time; parallel agents cover the space a sequential pass leaves behind.

File and registry permission enumeration across an installation is exhaustive machine work, and the one writable path that grants SYSTEM is rarely the obvious one.
DLL search order analysis requires tracing every library load under every code path — a tester samples the startup path and misses the one loaded on a rarely used feature.
Managed binaries decompile to thousands of methods; enumerating those touching cryptography, authentication or connection strings is search rather than insight.
Agent findings are cross-checked against manual testing so nothing unreproduced reaches the report.

Every agent finding is validated by a human tester on a real host before it reaches the report. The swarm decides what to look at; it does not decide what is true.

Why this differs

What CSS does that most vendors do not

Every one of these is checkable. Ask any vendor for the same and compare the answers.

The backend is in scope

Many thick client assessments stop at the binary. The server is tested against a malicious client, which is the only assumption that holds once the binary is on the user's machine.

Exploited, not scanned

Escalation and bypass are demonstrated on a real host with reproducible steps, not inferred from a decompiler.

Both reports, always

Technical report and executive summary together.

Fixation, not a backlog

Thick client remediation often means architectural change. CSS works the sequencing with the team and retests to evidence closure.

Reporting

Two documents, two audiences

Both are produced for every engagement. They are not the same document at two lengths — they answer different questions and are written separately. The structure below is the one CSS actually issues.

Technical assessment report

For the engineers who will fix it

Disclaimer, and Limitations on Disclosure and Use
Risk Level & Description — the five levels above, scored on CVSS 3.1
Scan Type — which of the five assessment types were selected
Assessment Scope — the control areas covered
Assessment Date — the exact testing window
Objective of the Assessment — objectives listed against completion status
Tools Utilization — manual and automated tooling by stage
Summary of the Assessment
Overall Recommendations, split into Must Have and Should Have
Vulnerability Overall Classifications as per Organization
Security Issues Highlighted
The Key Findings — each with evidence and detailed recommendation
Summary of Findings & Conclusion

For this assessment specifically

Scope, application version, host operating system and the test window
Every finding with CVSS v3.1 vector and CWE reference
Reproduction steps including the exact host state required
Evidence: decompiled excerpts, permission output, captured traffic
Local privilege escalation paths demonstrated end to end
Backend findings reported separately from client findings
Retest results appended against each original finding

Executive summary

For the people who will fund the fix

Objectives, each against a completion status
Overall Finding of the Assessment — total threats identified, broken down by component and severity
Summary of the Assessment
Artefacts of the Assessment — the key findings as a numbered register with severity
Observation of the Assessment — the major attacks the organisation should be prepared for, given what was found
Overall Recommendation, including a Business Enabling Recommendation sequence
Must Have and Should Have actions

For this assessment specifically

What a user of this application can do to the host and to the data behind it
Severity distribution and movement since the previous assessment
The three things that most need funding, with an honest note where the fix is architectural
Regulatory exposure where the client handles regulated data
Remediation timeline and retest date
One page

Case studies

What this finds in practice

Representative engagement patterns. Sector and scale only — no client is named, and no detail is included that could identify one.

A distribution company's order management client, roughly 600 desktop users.

Finding: The application connected directly to the SQL Server database with a shared credential stored, lightly obfuscated, in a configuration file next to the executable. Every user effectively held read and write access to the entire database, independent of their role in the application.
Recommendation: Move to an application server between the client and the database so credentials never reach the desktop, and enforce role checks server-side. As an interim control, restrict the shared account to stored procedures only.
Outcome: The interim control shipped in three weeks and removed direct table access. The application server followed over two quarters, which was the correct fix but not one available quickly.

An engineering firm's licence-managed CAD integration tool.

Finding: The updater service ran as SYSTEM and read its update package from a directory writable by all users. Placing a crafted package there executed arbitrary code as SYSTEM on the next update check, giving any standard user local administrator.
Recommendation: Restrict the update directory to administrators, and verify the package signature before execution rather than after download.
Outcome: Both implemented. The signature check was the more important of the two, since it closed the class rather than one instance of it.

A bank's internal treasury client used by around 40 staff.

Finding: Transaction approval limits were enforced in the client's UI and re-checked nowhere. Patching a single comparison in the decompiled assembly allowed a junior user to approve transactions above their authorised limit, and the server accepted them.
Recommendation: Enforce approval limits server-side against the authenticated user's role. Treat the client as a presentation layer with no authority.
Outcome: Server-side enforcement implemented before the next release. A reconciliation against historical transactions confirmed no prior abuse, which made the finding closable rather than an incident.

Scope this assessment

Most scopes are settled in one call. Tell us what the application does and who uses it, and we will tell you what testing it properly involves.

Start a conversation All VAPT capabilities