Skip to main content
Threatsys

Cyber Security Testing

Thick Client Security Testing

Desktop and installed-client testing: local storage, IPC, binary protections and server-side controls.

Every engagement includes manual validation, a two audience report and free re-testing.

Get a scoped quote+91 96682 00222

What this actually is

Desktop applications get forgotten. They were written years ago, they run inside the network so nobody worried, and the security model often assumes the user will not tamper with their own machine.

We test the binary, the local storage, the way it talks to its backend, and what happens when someone with a debugger decides to change the rules. Trading terminals, banking clients, healthcare systems and industrial consoles all sit in this category.

The recurring finding is a client enforcing rules the server should be enforcing. Once you can patch the binary or intercept the traffic, those rules stop existing.

What we go after

  • Binary analysis, decompilation and anti-tamper review
  • Local storage, configuration files and credential caching
  • Registry, file system and memory exposure
  • Client to server protocol interception and manipulation
  • Authentication, session and privilege enforcement
  • DLL hijacking and insecure update mechanisms
  • Server-side enforcement of client-side controls

How we run it

  1. 01

    Scope and authorise

    Targets, testing windows, escalation contacts and safety limits, all agreed in writing before anyone touches anything.

  2. 02

    Map the surface

    We enumerate what is actually exposed, which is usually more than the asset register says.

  3. 03

    Test by hand

    Tooling gives coverage, our engineers give proof. Every finding is reproduced before it is written down.

  4. 04

    Report

    An executive narrative your board can act on, and a technical annexe with the exact request, payload and fix.

  5. 05

    Re-test and sign off

    Once you have fixed it we verify each one at no extra cost, then close the engagement properly.

What you receive

  • Findings with reproduction steps and patched-binary proof
  • Assessment of what the server enforces versus what the client assumes
  • Remediation guidance for the development team
  • Free re-test on the next build

Who needs this

Organisations running installed desktop applications that handle money, health records, trading or industrial control.

How long it takes

One to two weeks per application.

Standards this satisfies

  • OWASP
  • CERT-In
  • ISO 27001
  • SEBI CSCRF

Why it matters

Desktop applications are frequently the oldest software in the business and the least tested, while holding direct database credentials and running with more privilege than anything on the web.

Because they are installed on a machine the user controls, the client can be inspected, patched and driven directly. Any logic you trusted to the client is reachable.

Choose the depth you actually need

Most of the price difference between quotes comes down to this one choice, and it is rarely explained. Pick one to see what it covers, what it suits and what it costs you.

You give us working accounts at each privilege level and a short walkthrough. We then test what a real attacker reaches after the first stolen password, which is where the findings that matter almost always live. This is what we recommend for most engagements.

Choose this when

  • Any application with authenticated functionality
  • Multi-tenant products, where tenant isolation is the real risk
  • Getting the most findings for the money

Effort and cost

Moderate effort and by far the best coverage per rupee. Most of the serious findings we report come out of authenticated testing rather than unauthenticated.

Tested against OWASP ASVS, not a checklist we invented

We test to the OWASP Application Security Verification Standard, which sets verification levels across authentication, session management, access control, input validation, cryptography, error handling and business logic. Working to a published standard means you can tell an auditor or a customer exactly what was verified and to what depth. It also makes this year's test comparable with last year's, which a bespoke in-house checklist never is.

Scope it yourself, before you call anyone

Answer a few questions and you get an indicative number, the working behind it and what your answers tell us. It runs in your browser, so nothing you type reaches us.

1/5

What needs testing?

Pick everything in scope. Effort is driven by unique functionality, not by how many IP addresses you own.

What we look for, and keep finding

These are the classes of problem this work exists to surface. Not every engagement finds all of them, but these are the ones that turn up often enough to be worth naming.

  • Broken access control

    The most common serious finding we report, and the one scanners miss most reliably. An identifier that is not checked against the caller, an admin function reachable by guessing its path, a role that can be changed in the request. The user is logged in. They are simply reading or doing something that is not theirs.

  • Injection and unsafe query construction

    SQL, NoSQL, OS command and template injection. Modern frameworks prevent most of it, which is exactly why the remaining cases hide in the hand written query somebody added under deadline, or in the reporting module nobody has looked at since it shipped.

  • Authentication and session weaknesses

    Tokens that do not expire, password reset flows that can be redirected, multi-factor that can be skipped by replaying an earlier step, and sessions that survive a password change. We test the whole lifecycle rather than just the login form.

  • Business logic abuse

    Nothing is technically broken. The application simply allows a sequence it should not: a discount applied twice, a payment confirmed before it clears, a limit avoided by splitting a request. This requires understanding what the application is for, which is why automation cannot find it.

  • Sensitive data exposure

    Data returned by an API that the interface never displays, secrets in client side code, verbose errors that reveal structure, and personal data in logs. The response body is where we find most of it.

  • Security misconfiguration

    Default credentials, directory listing, debug endpoints reachable in production, permissive CORS and missing security headers. Individually minor, and routinely the first step in a chain that ends somewhere serious.

Who runs your engagement

A senior tester, named before you sign

Testing is led by an engineer holding OSCP, CREST or equivalent, and you are told who it is before the engagement starts. They write the report themselves rather than handing notes to someone else, and they are on the call when findings are walked through. If the person changes, we tell you why.

Questions we get asked

The app only runs inside our network. Is this necessary?

Insider risk and compromised endpoints are both realistic. If a laptop is compromised, the attacker inherits everything the client can do, which is usually far more than it should be.

Often scoped alongside

Ready to scope your thick client security testing?

Thirty minutes with a senior engineer, and you leave with a written scope and indicative effort.

Book a 30-min consultation+91 96682 00222