Applications

Client-side application pentest

A test of the software you install on other people’s machines — desktop applications, thick clients, browser extensions and endpoint agents — focused on what it lets a local user become, and what its update channel could deliver.

Book a scoping call All services

areas covered

stages, scoping to retest

In-house

testers, never subcontracted

portal.cyberlysecure.com/acme-health/coverage

Acme Health — Test coverage4 practices · 15 services · one team

In-house

Web app

API

SaaS

Mobile

Client-side

External

Internal

Segment test

Wireless

Cloud config

Hardware & IoT

AI & LLM

Social eng.

Physical

Red team

ApplicationsNetworkCloud & devicesPeople & premises

6 in scope · one team · one report

In-house testers 0 subcontracted

Every surface one team

What this is

What the test covers.

Installed software runs with privileges the user does not have, on machines the attacker may already stand on. A weak file permission, a hijackable library path or an unsigned update can turn your product into the local privilege escalation somebody else was looking for.

We test the application, the service it installs, how the two talk, and how it updates itself.

PTES OWASP ASVS CWE Top 25

What we test

Local privilege escalation through services, scheduled tasks and installers
File, directory and registry permissions created at install time
Library and DLL search-order hijacking
Update channel integrity: transport, signing and rollback
Hardcoded credentials, tokens and connection strings
Inter-process communication — named pipes, local sockets, COM and RPC
Local data storage, logs and crash dumps
Licensing, offline and tamper checks
Browser extension permissions, content scripts and message passing

How it runs

From scoping call to retest, here’s what happens.

Typically one to two weeks, depending on components and platforms.

Scope and authorize

We agree builds, platforms, privilege model and test window in writing.

Install and observe

We watch exactly what the installer creates, with which permissions, and what runs afterwards and as whom.

Attack from a standard user

Everything is tested from the privileges a normal employee has — the position a real attacker starts from.

Test the update path

We check whether an attacker on the network or the machine can influence what your software installs next.

Report, readout and retest

Each finding comes with reproduction steps, followed by a readout and a retest.

What it surfaces

The kind of thing this test tends to find.

Real examples of what this engagement uncovers — anonymized, and never every time. What matters is that you find out before somebody else does.

A privileged service writable by any local user

Library loading from a path a standard user controls

Credentials or tokens stored in plain text in the install directory

Update checks that accept an unsigned or downgraded package

Local IPC that performs privileged actions for anyone who asks

Getting started

What you get, and what we need from you.

What you get

Technical report — Every finding, the evidence behind it and clear guidance your engineers can act on.
Executive summary — Your risk explained in plain language for leadership and the board.
Attestation letter — Signed confirmation of testing to hand your auditors.
Readout call — A walkthrough with the people who tested your systems.
Retest — Confirmation your fixes worked, documented for whoever needs to see it.

What we need from you

Installers for each platform and edition in scope
A licence or activation key if the product needs one
A note of which components are expected to run with elevated privileges
One named contact for the duration of the test

Missing something on this list? Bring it to the call — we scope around what you have.

Others in Applications