Thick-client pentesting: Windows desktop applications 2026

A thick-client is a desktop application that runs business logic on the user's machine and keeps local state, instead of delegating everything to a browser or to a remote backend. In 2026 thick-clients remain the dominant format in trading floors, specialised ERPs, industrial software, hospital management platforms, legal practice tools and a good share of the vertical software running critical operations. Auditing a web app has nothing in common with auditing a thick-client: the binary lives inside the attacker's perimeter, validation logic is reachable with a decompiler and the secrets the developer thought were hidden inside the DLL are extracted in hours.

This guide covers why a thick-client needs a specific pentest, which architectures dominate the current Windows landscape, the technical phases of the audit, the tooling a serious team uses every day, the vulnerability families that show up again and again in real reports, the particular case of Electron and the minimum hardening that should enter any desktop software development cycle.

The essentials. A thick-client exposes its binary, its traffic and its logic to the end user. The most profitable vulnerabilities are not typical web ones but reverse engineering of .NET assemblies, DLL hijacking, unauthenticated IPC, hardcoded secrets and local authentication bypasses. Defence requires signed binaries, secrets stored in DPAPI or Windows Credential Manager, real certificate pinning and the acceptance that obfuscation slows the attacker down but does not stop them.

Why a thick-client deserves a separate pentest

A thick-client changes the threat model compared to a traditional web app for three technical reasons.

First, client logic is accessible. A web app delivers HTML, CSS and a JavaScript bundle that gets minified and sometimes obfuscated, but critical validation logic lives on the server. In a thick-client the licence validation, the local authorisation workflows, the signed forms and sometimes even pricing logic itself live inside the binary. Whoever has the executable can read them.

Second, local debugging is viable and cheap. An attacker sitting at their PC loads the app in WinDbg, x64dbg or dnSpy, sets breakpoints, inspects memory and modifies the flow. That cannot be done against a remote backend without prior exploitation.

Third, secrets end up in the binary. API keys for SaaS services, database connection strings, embedded certificates, confidential client OAuth tokens, symmetric encryption keys, URLs of internal endpoints not exposed externally. The developer assumes "it is not visible" because it is compiled; a strings grep and a decompiler show it in minutes.

A compliance layer sits on top of all that: PCI DSS, NIS2, DORA and ISO 27001 explicitly cover software that processes sensitive data, without distinguishing web from desktop format. A thick-client that moves PCI data or transactions under DORA falls within the scope of the pentest the regulator demands.

Typical architecture of a Windows thick-client

Technical surface varies with the product stack. The five families that cover the vast majority of Windows desktop applications in 2026:

• .NET (WPF, WinForms, MAUI). The dominant stack for new Windows enterprise software. Assemblies ship as .exe and .dll with IL code that dnSpy or ILSpy decompile back into something very close to the original C#. Obfuscation with commercial products (Dotfuscator, ConfuserEx) raises cost but rarely blocks a motivated attacker.
• MFC and native C++. Legacy suite still common in industry, healthcare and banking. Classic PE binaries, no intermediate IL. Reverse engineering with IDA Pro or Ghidra, more expensive but also more opaque to the average attacker.
• Electron. The trendy option for multi platform apps that reuse web teams. The binary is a packaged Chromium with a JavaScript bundle inside an ASAR file, unpacked with a single command.
• Java Swing and JavaFX. Sectors where Java remains lingua franca: healthcare, public administration, defence. .class and .jar files decompile with JD-GUI or CFR into very readable Java.
• Delphi legacy. There are thousands of enterprise applications written in Delphi decades ago still running in production. Binaries are harder to reverse, but opacity does not equal security: the logic is in there.

Identifying the stack is the first step because it conditions tools, vectors and expected depth.

Phases of a thick-client pentest

The methodology we apply at Secra and that any serious team follows is articulated in five overlapping phases.

1. Information gathering. Inventory of the binary and its environment: executable architecture (32 or 64 bit), Authenticode signatures, loaded DLLs, embedded resources, configuration files (.config, .ini, .json), registry branches touched, associated Windows services, listening ports, embedded certificates. Sysinternals' Sigcheck, PEStudio and dependencies.exe cover the bulk of this phase.
2. Reverse engineering. Decompilation by stack. For .NET, dnSpy or ILSpy give readable C# code; for native, IDA Pro or Ghidra; for Java, JADX or CFR; for Electron, asar extract and then static analysis of the JS bundle. Search for suspicious strings, cryptographic keys, internal endpoints and authorisation logic that can be patched.
3. Traffic analysis. Configuration of an intercepting proxy (Burp Suite, mitmproxy) between the app and the backend. Pinning bypass when present, capture of the full flow, identification of custom protocols (binary RPC, MQTT, AMQP, WebSocket) that escape conventional HTTP. Wireshark for non HTTP traffic.
4. Logic abuse. Client manipulation: patching of licence checks, local authentication bypass, modification of operation limits, abuse of client side roles that the backend trusts without revalidating. This is the phase where it gets confirmed that the backend is not actually the security boundary.
5. IPC analysis. Identification of inter process communication channels inside the software itself: named pipes, COM objects, RPC endpoints, local sockets, mailbox files. Verification of authentication, authorisation and input validation on each one. One of the most underestimated vectors by development teams.

Tooling for thick-client pentesting

The stack any desktop auditor keeps ready:

• IDA Pro and Ghidra for reverse engineering native binaries. Ghidra is free and open source; IDA Pro remains the industry reference.
• dnSpy and ILSpy for .NET. dnSpy further allows editing and recompiling assemblies on the fly, which is gold for validating bypasses.
• JADX and CFR to decompile Java into readable code.
• Frida for cross platform dynamic instrumentation. Hooks functions, modifies arguments and return values at runtime, neutralises integrity checks and pinning.
• WinDbg and x64dbg for native debugging. WinDbg is Microsoft's canonical tool for memory analysis, dumps and crash analysis.
• Process Monitor (ProcMon) and Process Explorer from Sysinternals to observe registry, filesystem, network and child process call activity. Indispensable to discover DLL hijacking, writes into controllable paths and abuse of environment variables.
• Procdump to dump the memory of a running process and search for secrets the binary only materialises at runtime.
• Wireshark for non HTTP traffic and raw capture on virtual interfaces.
• Burp Suite as HTTP proxy, configured against the client with a CA certificate of our own imported into the Windows store.
• API Monitor to intercept Win32 API calls and observe parameters without needing a debugger.

Common vulnerabilities in thick-clients

The families that show up in practically every serious report:

Hardcoded credentials and API keys in the binary

SQL Server connection strings with cleartext username and password, cloud service API keys, confidential client OAuth tokens, symmetric encryption keys. A strings.exe over the binary or a decompiler delivers them. String obfuscation slows the average attacker, not the motivated one.

Insecure deserialization

BinaryFormatter in .NET, ObjectInputStream in Java, pickle in embedded Python clients. If the thick-client receives serialized blobs from the backend or from IPC without type validation, an attacker with control of the channel executes code on the client machine. Microsoft marked BinaryFormatter as obsolete and dangerous but it keeps showing up in existing code.

DLL hijacking and DLL preloading

The Windows loader searches DLLs following a specific order that includes the working directory and controllable folders. If the app loads a DLL by name without absolute path and an attacker can write into a folder in the search order before the system one, they replace the legitimate DLL with a malicious one. ProcMon with a filter Result is NAME NOT FOUND and Path ends with .dll maps the problem in minutes.

Insecure IPC

Named pipes without restrictive ACL, COM objects accessible from lower privilege sessions, RPC endpoints without authentication, local sockets that listen on 0.0.0.0 when they should listen on 127.0.0.1. Any of the four turns an app meant to be single user into a multi user or even network surface.

Registry abuse

Configuration keys written to HKLM with permissions that allow modification by standard users, combined with services that read that configuration as SYSTEM. An unprivileged user modifies the path of the binary the service invokes and obtains execution as SYSTEM on the next reboot. It is a classic local privilege escalation pattern.

Path traversal in file operations

Export, import, template management or attachment functions that take a filename from the user and concatenate it to a base path without sanitisation. An input like ..\..\Windows\System32\drivers\etc\hosts allows reading or writing wherever the process has permissions.

Insecure cryptography

Custom XOR implementations, hashing without salt, hardcoded keys in the binary, use of ECB instead of authenticated modes, non cryptographic pseudo random generators for tokens. Custom crypto is almost always broken; the only exception is standard protocols implemented with standard libraries.

Local authentication bypass

Modification of the .NET assembly to replace return false with return true in the licence validation function. Patching of the native binary to skip the conditional jump distinguishing admin account from normal account. Edition of the local configuration file the client treats as authoritative. If the decision lives on the client, the client changes it.

Missing memory protections

Binaries compiled without DEP, without ASLR, without SafeSEH, without CFG (Control Flow Guard). They turn any memory corruption into trivial code execution. Verifiable with dumpbin /headers or PEStudio in seconds.

Electron specifically

Electron deserves its own section because it packages a full Chromium and a Node.js runtime, and the default configuration in new applications usually leaves open surface.

The points to always review:

• nodeIntegration enabled. Lets the window's JavaScript code access Node APIs and, by extension, the filesystem and child processes. Any XSS in loaded content turns into local RCE.
• contextIsolation disabled. Makes the preload JavaScript context share space with the rendered page's context, leaving untrusted code able to manipulate the exposed bindings.
• webSecurity disabled or allowRunningInsecureContent enabled. Turns off Same Origin Policy and allows loading HTTP content in an HTTPS window.
• ASAR without protections. The app's JavaScript bundle lives in resources/app.asar and unpacks with npx asar extract app.asar out/ in seconds. It is not encrypted or signed; it is just a packager. All client logic becomes readable.
• DevTools in production. If the menu exposes DevTools or a shortcut opens them, the attacker inspects and modifies the app live.

The audit of an Electron app starts by unpacking the ASAR, reviewing package.json to detect Electron versions with known CVEs, mapping BrowserWindow instances with their webPreferences and enumerating the ipcMain.handle channels the renderer can invoke.

Network traffic analysis

The client talks to its backend in many ways beyond plain HTTP. The audit must cover the four usual situations.

HTTPS with certificate pinning. The modern standard defence. Bypass with Frida if the implementation uses a standard library (HttpClientHandler in .NET, OkHttp in Java); binary modification to swap the pin if it is custom. Well done pinning rotates certificates from the server and combines several signals, but the usual case is a hardcoded hash easy to locate.

Custom protocols over TCP. Binary RPC, proprietary serialised formats. Wireshark captures raw traffic and a parallel binary analysis reveals the protocol. Frequent in industrial and trading software.

MQTT, AMQP, gRPC. Patterns increasingly common in IoT software and microservice architectures. Each one has its own authentication and authorisation model the auditor must validate.

Local communication with Windows services. Named pipes, sockets on localhost, COM. Audit as if it were external traffic, because another user account on the same machine is a possible attacker.

Recommended hardening for thick-client

The minimum set any serious thick-client development should incorporate before shipping to production:

• Binaries signed with Authenticode and a valid organisation certificate, not self signed or development. Integrity verification at startup performed by the software itself, not only trust in Windows.
• Secrets in DPAPI or Windows Credential Manager, never in the binary or in plain configuration files. DPAPI encrypts with a key derived from the user or machine account; Credential Manager is the correct option for credentials of external services.
• Real certificate pinning against the backends, with rotation managed from the server and a documented contingency plan for revocation emergencies.
• .NET obfuscation with a mature commercial product (Dotfuscator, ConfuserEx in its maintained version, Eziriz .NET Reactor). It does not stop the motivated attacker but raises cost and filters the casual one.
• Runtime integrity. Periodic verification that the binary has not been modified in memory or on disk. Limited in value (an attacker with control of the machine neutralises it) but useful to detect opportunistic tampering.
• Anti debugging with moderation. Trivial detections like IsDebuggerPresent get bypassed in seconds; serious commercial ones (Themida, VMProtect) raise the cost but break legitimate analysis tools and hamper production error diagnosis.
• Compilation with all compiler protections enabled: DEP, ASLR, SafeSEH, CFG, GS. No perceptible performance cost.
• Sysmon coverage on endpoints where the critical app runs, with rules that detect loading of unsigned DLLs, writes to sensitive paths and creation of unexpected child processes from the binary.
• Signed and verified automatic update policy, with a server side manifest the client validates before applying.

Frequently asked questions

Is .NET obfuscation enough to protect the code?

No. Obfuscation raises the cost of reversing the code but no commercial product blocks an attacker with time. It serves to filter the casual attacker and to make copy paste of proprietary logic harder. The real defence is not putting anything on the client that the backend cannot revalidate.

Is Electron secure for enterprise applications?

Yes if configured correctly. The problem is not Electron but the default configurations many teams do not review: nodeIntegration: true, contextIsolation: false, outdated dependencies, ASAR as the bundle's only "protection". With contextIsolation: true, nodeIntegration: false, sandbox enabled and audited dependencies, risk approaches that of an equivalent web SPA.

How long does a thick-client pentest take?

Depends on stack and complexity. A medium sized .NET app with a conventional HTTP backend gets covered in 8 to 12 business days. A native C++ industrial software app with custom protocols and several IPC services may need 20 to 30 days. Electron apps usually sit closer to the web side. The complete audit includes reporting and retest.

Why does trading banking still use thick-clients in 2026?

Latency and control. The thick-client processes market data locally, runs risk calculations without a round trip to the server and keeps UI response times a browser does not guarantee. It also allows integrations with hardware (card readers, cryptographic tokens) the web still limits. The trade off is a larger attack surface, compensated by a specific pentest.

Is it ethical to implement anti debugging in a commercial product?

Depends on the product and on transparency with the customer. Anti debugging hinders legitimate analysis by the customer's security team and complicates debugging when a user reports a crash. Products incorporating it should document it and allow disabling it under NDA for authorised audits. Relying on it as the only defence layer is a mistake.

When does it make sense to retest after patching?

After every significant block of fixes, not after every individual bug. The development team groups corrections in a release and the offensive team validates the complete block. Retest should be included in the original pentest scope, not invoiced separately, to avoid friction that delays the closure of critical findings.

Related resources

• What is Mimikatz and credential dumping: key tool for local post exploitation, complements the logic abuse phase when the thick-client shares credentials with the system.
• Active Directory pentesting and tier model: context of the corporate environment where thick-clients usually live, with the layered protection model.
• Top 10 pentesting tools 2026: catalogue of utilities covering IDA, Ghidra, Frida and the rest of the desktop stack.
• What is PKI: fundamentals of binary signing and Authenticode certificate issuance.
• Kerberos attacks in Active Directory: adjacent vector when the thick-client authenticates against domain resources.

Thick-client audit with Secra

At Secra we cover pentesting of Windows desktop applications with profiles specialised in native reverse engineering, .NET and Electron, dynamic instrumentation with Frida and WinDbg, custom protocol analysis and mapping of findings to OWASP ASVS adapted to the desktop context. If your organisation develops or deploys thick-clients in sensitive environments (banking, healthcare, industry, defence) and needs serious technical validation, get in touch via contact or check our services for web and mobile audit and infrastructure audit.