Thick client penetration testing services
Thick client penetration testing checks installed desktop software, such as trading terminals, banking and ERP clients, point-of-sale and hospital systems, for secrets left on the user's machine, checks the server never repeats, and traffic or database connections an attacker can take over. BERRY9 tests two-tier and three-tier client-server applications and the back end they talk to, working from Hyderabad for teams across India.
- Tests
- Installed desktop applications
- Designs
- Two-tier and three-tier client-server
- Delivery
- Remote, from Hyderabad
- Starts from
- INR 27,000 + 18% GST
Last reviewed
Pathinstalled client → F-01 → config file → F-02 → database login → F-03 → ledger tables
Also mappedupdate server · F-04
- F-01The client's settings file, readable by every user of the PC, holds the database passwordHigh
- F-02That shared account can open a connection to the production database from any office machineHigh
- F-03Approval limits are enforced only in the desktop screens, so the database accepts any change sent to it directlyCritical
- F-04New versions are fetched over plain HTTP and installed without a signature checkMedium
01 / What it is
What thick-client penetration testing is
Desktop software that does real work on the user's computer hands that computer a share of the trust. A thick-client test asks what someone sitting at that machine can learn, change or skip.
A thick client, also called a fat client or rich client, is an application installed on the user's own computer that does a large share of its work there: it draws the screens, applies business rules, keeps files and settings on the machine, and talks to a server or a database over the network. Thick-client penetration testing examines that installed program, the data it leaves on the computer and the conversation it has with its server, to find what a user, or malware running as that user, could change or read that the design never meant to allow.
A browser application keeps most of its logic on the server, so testing the server covers most of the risk. A thick client moves logic, credentials and sometimes whole database connections onto a machine the user controls. Anything shipped inside the installer, written to disk or held in memory while the program runs can be inspected by whoever sits at that keyboard, so the test treats the client as territory the attacker already owns.
Desktop clients are commonly built with .NET (Windows Forms or WPF), Java (Swing or JavaFX), native C or C++, or Electron, which wraps a web front end in a desktop shell. The classes of weakness are much the same across them; what changes is how the program is packaged and how its code and traffic are examined.
Software that usually turns out to be a thick client:
Trading and dealer terminals
Order entry and market screens installed at brokers and dealers, where a client that trusts itself on limits or user rights can move money.
Banking branch and back-office software
Teller, loan processing and reconciliation programs on staff desktops, many of them older two-tier designs that connect straight to a core database.
ERP and accounting clients
Desktop front ends for finance, payroll, inventory and purchasing, often shared by whole departments whose roles differ only on screen.
Point-of-sale software
Billing counters in shops and restaurants that store prices, discounts, offline transactions and sometimes card data on the till itself.
Hospital and laboratory systems
Patient registration, pharmacy, imaging and lab result software on ward and lab PCs, where a local cache can hold health records.
Products you ship to customers
Licensed desktop software and agents that your customers install on their own machines, where a weakness in one release reaches every installation.
02 / Two-tier or three-tier
Two-tier and three-tier client-server application testing
How the desktop program reaches its data decides where the test looks hardest. A client that talks to the database itself carries very different risks from one that only calls an application server.
| Aspect | Two-tier (client to database) | Three-tier (client to application server) |
|---|---|---|
| How the parts connect | The desktop program opens its own connection to the database and runs queries itself | The desktop program calls an application server or web service, and only that server talks to the database |
| Where the credentials live | A database login has to be available to the client, often in a settings file, the registry or the binary | The client holds a user session or token; the database login stays on the server |
| Where rules are enforced | Usually only in the clientThe database sees one shared account and cannot tell a clerk from a manager | They can be enforced on the server, though many such programs still repeat or replace them locally |
| Biggest risk | Someone who recovers the connection details reaches the database directly, with every limit in the screens bypassed | The server trusts requests because they normally come from its own client |
| Where the test spends its time | Recovering credentials, checking what the shared database account may do, and finding checks that exist only on screen | The calls between client and server, which are then tested on their own like any API |
Many estates mix the two: an older module that still reads the database directly, sitting beside newer screens that use a web service. Scoping starts by finding out which connections the program actually makes, because a three-tier diagram on paper sometimes hides a two-tier shortcut in the code.
Electron and other hybrid clients add a further layer. Their screens are web pages, so they can carry web flaws such as script injection, and a flaw in the page can reach operating-system functions that an ordinary browser would never expose.
03 / What we test
What a desktop application security test covers
Eight areas make up the test. The first four ask what the client gives away or trusts; the last four ask how the program, its connections and its installation can be turned against the machine and the server.
Local files, registry and settings
What the program writes to disk and to the Windows registry: settings files, logs, caches, offline databases and temporary exports. The question is whether passwords, tokens, personal data or business records sit there in readable form, and which other users of the PC can read or change them.
Secrets inside the binary
Database passwords, API keys, encryption keys and licensing secrets compiled into the executable or its libraries. Anything shipped to users' machines should be assumed readable, so a secret found here belongs to everyone who has the installer.
Trust placed in the client
Checks that exist only in the desktop screens: field validation, approval limits, hidden buttons, role-based menus and price or discount rules. If the server or the database accepts a request without repeating the check, any user who can send that request directly can step past it.
Traffic to the server
Whether the connection is encrypted, whether the client checks the server's certificate, what is sent in each request, and whether a request captured on the network can be changed or replayed to act as another user or to change an amount.
Database connections and accounts
For two-tier clients: how the connection string is stored, how strong the database login is, and what that login may read, write or execute once someone uses it outside the program. A shared account with owner rights turns one leaked password into control of the data.
Libraries, plugins and updates
Where the program loads its DLLs and plugins from, and whether a file placed in a writable folder would be loaded instead. The update channel is checked too: whether new versions arrive over an encrypted connection and are verified before they are installed.
Installer, services and local privilege
The permissions on the install folder, on services the product installs and on scheduled tasks it creates. A service running with system rights from a folder ordinary users can write to is a route from a standard login to administrator on that machine.
Secrets held in memory
Whether passwords, session tokens or decrypted records stay readable in the running process after they are used. Memory exposure matters most on shared terminals, where several people use the same machine in a day.
Understanding how a client works often means reading its compiled code. Programs built on .NET and Java can usually be turned back into readable source with little effort, which is one reason hidden secrets in them do not stay hidden.
04 / Method
How a thick-client test runs
Five steps move the work from an installed client to a ranked list of fixes. The client is examined first, then the server is tested with what the client revealed.
Show details for How a thick-client test runs
Step 1
Scoping and the test machine
Agree which program and version are in scope, which user roles matter, whether the server side is included and which environment the client will point at. The installer is set up on a test machine that matches what your users run.
OutputAgreed scope and an installed client
Step 2
Mapping the application
The client is used as each role would use it, while the test records which files, registry keys, processes, services and network connections it touches. This turns the architecture notes into a map of what the program really does on the machine and on the wire.
OutputMap of components, data and connections
Step 3
Examining the client
The program files, settings and stored data are examined for secrets and weak protection, and the running program is observed to see which decisions it makes locally. Checks that live only in the client are listed for the next step.
OutputClient-side findings and candidate bypasses
Step 4
Testing the server through and around the client
Requests the client sends are repeated, changed and sent without the client, to see whether the server or database repeats the checks the screens apply. Two-tier connections are tested with the recovered database login, within the limits the scope sets.
OutputServer-side findings, each reproduced
Step 5
Reporting
Findings are written up for the product owner and for the developers, each with where it sits (client, server or database), why it matters and how to fix it, ordered so the fixes that remove the most risk come first.
OutputExecutive and engineering reports with a fix order
A thick-client test looks at one release of the program. A new version can bring back old weaknesses, so a major release, a new server component or a change of framework is a good point to test again.
05 / Common findings
Weaknesses that keep turning up in desktop software
Most thick-client findings trace back to one assumption: that users will only ever reach the server through the program they were given. These are the forms that assumption usually takes.
Show details for Weaknesses that keep turning up in desktop software
| Finding | What goes wrong | Severity | How it is fixed |
|---|---|---|---|
| Credentials stored in readable files | Database passwords, service accounts or API keys kept in settings files, the registry or log files that every user of the computer can open, sometimes behind an encoding that only looks like encryption. | VariesRises sharply when the credential reaches production data. | Remove the credential from the client; issue each user a session from a server, or protect machine secrets with the operating system's own key store. |
| Hard-coded keys in the executable | Encryption keys, signing keys or vendor API keys compiled into the program. One copy of the installer is enough to recover them, and the same key protects every installation. | VariesCannot be fixed by changing a setting; needs a new release. | Move the secret to the server side, or derive a key per installation instead of shipping one shared key. |
| Business rules checked only on screen | Transaction limits, approval steps, discounts and role permissions applied by the desktop program but not by the server or database, so a request sent directly is accepted. | VariesOften the most serious class in financial software. | Repeat every check on the server, using the user's own identity, and treat anything the client sends as untrusted input. |
| Direct database access with a shared login | A two-tier client connecting as one powerful database account for all users, so whoever finds the login can read or change every table outside the program. | VariesCommon in older line-of-business software. | Put an application server between the client and the database, or give each user a database login with only the rights that role needs. |
| Unencrypted or unverified traffic | Client-server traffic sent in clear text, or encrypted without checking the server's certificate, so anyone on the same network can read or alter it. | VariesMatters more on branch, shop and warehouse networks. | Encrypt every connection and make the client refuse a server whose certificate does not check out. |
| Libraries loaded from writable folders | The program loads a DLL or plugin from a location ordinary users can write to, so a planted file runs with the program's rights the next time it starts. | VariesSerious when the program or its service runs with high rights. | Load libraries only from protected folders using full paths, and lock down write access to the install directory. |
| Insecure update mechanism | New versions downloaded without encryption or installed without checking a digital signature, which lets someone on the network or in control of the download location replace the program. | VariesReaches every machine that updates. | Sign every release, verify the signature before installing, and fetch updates only over an encrypted channel. |
| Weak permissions on services and install folders | A Windows service or scheduled task installed by the product runs with system rights from a folder or registry key that standard users may change. | VariesTurns a standard user into a local administrator. | Install under protected program folders, set permissions so only administrators can change the files, and run services with the least rights they need. |
The table rates each class as Varies because the same weakness is minor in a viewer that shows public data and critical in a program that moves money. Each finding in the report is rated for your application and the data behind it.
06 / What you receive
What you receive from a thick-client test
Fixes for a desktop program land in three places: the client, the server and the database. The reports say which, so that changes on the server are not left waiting for the next client release.
Show details for What you receive from a thick-client test
- An executive report for the product owner and management: what was tested, which weaknesses touch money, health records or customer data, and how much work the fixes involve.
- An engineering report for the developers that places each finding in the client, the server or the database, with the file, setting, request or query involved and the specific change needed.
- A proof of concept per finding, showing the weakness as it was found, which later lets your developers confirm their change has closed it.
- A CVSS 3.1 score on each finding, alongside a plain rating of what it means for your application.
- A remediation matrix that separates the changes you can make in configuration or on the server now from the ones that need a new client release.
For the layout of a full report, open the sample VAPT report. The VAPT methodology walks through the five phases a desktop client test follows.
Finding F-01 · Thick-client test
Database password in the client settings file gives direct write access to the ledger
- Severity
- High
- Component
- Branch accounting client, settings file and core database
- Starting point
- A standard teller login on a branch PC
Steps to reproduce
- The settings file in the program folder is readable by every user of the computer and contains the database connection details.
- The shared database account in that file can connect from any machine on the branch network.
- Connected outside the program, the account can change ledger entries that the desktop screens would only allow a manager to approve.
Server=db-core;
Database=Ledger;
User Id=ledger_app;
Password=********
Fix
Take the database login out of the client, route the program through an application server that checks each user's role, and change the exposed password.
Example layout, not client dataCredential exposure · Two-tier
07 / Your inputs
What we need from you for a thick-client test
A desktop test needs the program as your users get it, accounts for the roles that matter, and a route to the servers it talks to. Brief architecture notes save time on every step.
Show details for What we need from you for a thick-client test
What we need from you
- The installer for the exact version in scope, with any license key or activation step the program needs.
- Test accounts for each role, for example a clerk, a supervisor and an administrator, so the test can compare what each is allowed to do.
- Network access to the server side: the application server or database the client talks to, reached over a VPN or from a test network, ideally in a test environment rather than production.
- Architecture notes, even brief ones, naming the components, the ports and protocols they use and where the important data is stored.
- Written authorization covering the client, its servers and any third-party hosting, from someone entitled to give it.
Where the client runs. The program needs a Windows machine, or whatever your users run, that matches the real setup closely enough for local findings to mean something.
Third-party software. When the program is bought from a vendor rather than built in-house, the vendor's license may limit reverse engineering or testing, and some vendors want notice before their product is tested.
Source code helps but is optional. The test works from the installed program, as an attacker would. If your team owns the code, a source code review alongside it finds the same issues faster and with exact lines to fix.
Installers, test logins and architecture notes you share fall under the engagement agreement, while the privacy notice applies only to messages sent through this website. The work is delivered remotely from BERRY9's one office in Hyderabad, and a visit to your premises can be arranged when a client only runs on site.
08 / Who needs it
Who needs thick-client security testing
Desktop clients are most common where work is done at a counter, a terminal or a branch desk, and where the software was built before browsers could do the job. Those are also the places where the client often decides who may do what.
Show details for Who needs thick-client security testing
Banks, brokers and financial services
Teller software, dealer terminals, treasury tools and payment operations clients decide who may move how much. When those decisions live in the desktop program, a thick-client test shows whether the server would stop a user who goes around it.
Retailers and restaurants
Billing software on tills often works offline and syncs later, so prices, refunds and card data can sit on the device. Where it handles card data, see PCI DSS penetration testing.
Hospitals, labs and diagnostics
Registration, lab and imaging software on shared ward PCs caches patient data locally and is often years older than the network around it.
Manufacturers and distributors
ERP clients, warehouse terminals and plant-floor programs connect office users to production and inventory data, frequently through a shared database account.
Software vendors
If your product is a desktop application your customers install, their security teams will ask how it has been tested. A report on the release they run answers that question and finds weaknesses before a customer's tester does.
Two frameworks often bring the question up. PCI DSS version 4.x expects penetration testing of the cardholder data environment (requirement 11.4), which includes point-of-sale and payment software that stores, processes or transmits card data. ISO/IEC 27001:2022 asks organizations to manage technical vulnerabilities (control 8.8), and a test of the desktop software in scope is one form of evidence for it; see ISO 27001 penetration testing. BERRY9 holds ISO/IEC 27001:2022 certificate 26MEQVU27.
BERRY9 tests the software and is neither an auditor nor a certifier of your organization. Whether a thick-client report satisfies a framework or a customer's questionnaire is for your auditor or that customer to decide.
09 / Related tests
Thick-client testing with API, web and network testing
A desktop program is the front of a larger system. These tests cover the parts behind and beside it, and are often scoped in the same engagement.
Show details for Thick-client testing with API, web and network testing
API security testing
In a three-tier design the desktop program is only one caller of the server's API. Testing that API directly, role by role, shows what any caller can do once the desktop screens are out of the way.
Web application testing
Many desktop products have a web portal or admin console beside them, and Electron clients are web pages inside a window. Both are tested the way a browser application is.
Network penetration testing
A two-tier client needs its database reachable from users' desks. A network test shows who else can reach that database and the servers beside it.
Source code review
With the code in hand, a reviewer can follow every place the program handles a secret or trusts its own input, including paths the test did not reach through the screens.
Mobile application testing
A mobile app is a thick client on a phone. If the same back end serves a desktop program and an app, the two tests share a server and are planned together.
Every other test BERRY9 offers, and how each is priced, appears on the offensive security services page.
10 / Price
What thick-client penetration testing costs
A thick-client penetration test starts from INR 27,000 + 18% GST; the final price is set in a written proposal after scoping. Desktop programs run from a single form to a suite of modules with their own servers, so the scope sets the figure.
Thick-client penetration test
Starts fromINR 27,000 + 18% GST
Program size, roles and the server side move the figure, and the proposal states yours.
Request a scoping call- Size of the program. A single-screen utility and a client with dozens of modules, reports and integrations are very different amounts of work.
- Number of user roles. Every role adds its own permissions to compare, on screen and at the server.
- Two-tier, three-tier or both. Testing the server's API or the database account adds work beyond the client itself.
- Technology and protection. Native code, obfuscated builds and custom protocols take longer to examine than a plain managed application.
Duration: The schedule depends on the build and the server side, and it is fixed in the written proposal.
For how desktop, web, API and network tests compare on cost, see the VAPT pricing guide.
The starting price for small scopes includes one free retest. For larger scopes, the retest terms are written into the proposal before work starts.
Thick-client testing by city
11 / Inquiry
Tell us about your desktop application
Tell us what the program does, what it is built with, whether it talks to a database or an application server, how many user roles it has, and your deadline. With that we can say what the test should cover and what it will cost.
To talk it through first, call +91 86868 92922 or email contact@berry9.com.
12 / FAQ
Frequently asked questions
Short answers about scope, price and how testing works. For anything else, call +91 86868 92922.
What is thick client penetration testing?
Thick client penetration testing examines a desktop application installed on users' computers that does significant work locally and talks to a server or database. The test examines the program files, the data it stores on the machine, its memory and its network traffic, then checks whether the server side repeats the controls the client applies. The result is a list of weaknesses, where each one sits and how to fix it. See the section on What thick-client penetration testing is above.
What is the difference between a thick client and a thin client?
A thin client, such as a web application in a browser, keeps almost all logic and data on the server and mainly displays results. A thick client is installed on the user's computer and handles screens, business rules, local storage and sometimes database connections itself. Because more of a thick client runs on a machine the user controls, more of its security depends on what that machine can see and change. See the section on What thick-client penetration testing is above.
What is the difference between two-tier and three-tier thick-client testing?
In a two-tier application the desktop program connects straight to the database, so testing focuses on how the database credentials are protected and what the shared database account may do. In a three-tier application the program calls an application server, which then reaches the database, so testing focuses on whether that server trusts requests just because they appear to come from its own client. See the section on Two-tier and three-tier client-server application testing above.
How is thick-client testing different from web application testing?
Testing a web application works mostly against the server through the browser. A thick-client test adds the installed program itself: the files and registry entries it writes, secrets compiled into it, libraries it loads, the installer and services it sets up, and data left in memory. The server side is still tested, often as an API, but with the extra knowledge the client gives away. See the section on What a desktop application security test covers above.
Can you test .NET and Java desktop applications?
Desktop programs built with .NET or Java are among the most common thick clients, and the same classes of weakness apply to them as to native and Electron clients: stored secrets, client-side checks, unprotected traffic and weak installation permissions. Tell us the framework and version when you ask for a proposal, and the scope will state how the program is examined. See the section on What thick-client penetration testing is above.
Can banking and trading desktop applications be penetration tested?
They can. Teller and branch software, dealer and trading terminals, and back-office finance clients are thick clients, and they are a main reason this kind of test exists, because they often enforce limits and approvals on the user's desktop. Such tests are usually run against agreed test accounts and, preferably, a test environment rather than live accounts. See the section on Who needs thick-client security testing above.
Do you need our source code for a thick-client test?
No. The test is run against the installed program, the way an attacker would approach it. If your team owns the code, a source code review alongside the test finds problems faster, reaches paths the screens do not show, and points to the exact lines to change. See the section on What we need from you for a thick-client test above.
Will thick-client testing affect our production servers or database?
It can if it is pointed at them, which is why the target environment is chosen during scoping. A test environment with its own database is the safer choice, especially for two-tier clients, where testing may write to the database directly. Whatever the target, the limits on what may be changed are set out in writing before any test traffic is sent. See the section on How a thick-client test runs above.
How much does thick client penetration testing cost in India?
A thick-client penetration test from BERRY9 starts from INR 27,000 + 18% GST; the final price is set in a written proposal after scoping. The figure depends on the size of the program, the number of user roles, whether the server's API or the database is tested too, and how the client is built and protected. See the section on What thick-client penetration testing costs above.
Which application builds and servers belong in the scope?
The build your users run, ideally the same installer and version, and every server the client talks to: the application server, any database it connects to directly, and update or licensing services. A test environment that mirrors production is the usual target; if the client can only reach production, the written scope says which actions are off limits. Older builds still in use can be listed separately when they behave differently.