Workstation Security Assessment

Once an attacker has remote code execution on a device, the next step is privilege escalation. How can an attacker who has access to a machine go from a standard user account to a local administrator? The truth is that completely preventing local privilege escalation is very difficult, but one can at least close the easiest pathways an attacker might use. We assess the workstation's hardening against the moves a real attacker makes once they have a foothold. This includes looking for misconfigurations, vulnerable services, weak permissions, and unpatched components. A general guide we follow is the principle of least authority: privilege escalation becomes harder the less a system assigns more authority to programs and processes than they need. We look for ambient authority in application permissions and execution policy, testing whether unauthorised executables, scripts, and living-off-the-land techniques using legitimate built-in tools are constrained or run freely.

Hardening against remote code execution on a device compromised over the network is one thing, but what if an attacker simply grabbed your laptop while you were on the train, or stuck a USB stick into your machine after gaining access to your premises? What could they achieve? On most computers, the reality is that any data on your systems could be accessed by an attacker with physical access to your computer, regardless of any software-level security. Simply booting into a Linux distribution on a USB stick bypasses your operating system, and accessing your files is then simply a matter of executing a few commands.

Thankfully, the solution is simple: whole disk encryption, which keeps all your data encrypted while your computer is not physically powered on. We can check if your computers have whole disk encryption enabled, and advise on setting it up if not. This connects with our Secure Data Architecture offering. That said, whole disk encryption is not a panacea. It likely does not provide protection against an attacker who has access to your computer when it is powered on; protecting against this danger is mostly impossible, but we can at least advise on implementing suspend/lock behaviour that unmounts the disk and keeps keys out of RAM.

Additionally, one security strategy against attackers who may have physical access is simply to minimise the amount of sensitive information that gets saved on your computer at all. By default, browsers and other programs tend to save far more information than they need to (in the form of caches, history, cookies, and more). We examine credential exposure on the endpoint: what is cached, what is recoverable from memory or disk, and what an attacker would harvest to move onward - the raw material for the attacks covered in our Credential Theft Assessment.

The most efficient way to run this is against your standard build - the gold image and policy set the bulk of your fleet shares - since a weakness there is a weakness replicated across every machine at once. For distributed and remotely managed fleets, we also consider how the build holds up away from the corporate network, where many endpoint protections quietly relax - a concern this assessment shares with our Remote Worker Security Assessment. Of course, if your organisation doesn't have standardised builds for staff workstations, setting up such builds, along with centralised security policy configuration (e.g. using Active Directory), is itself a valuable security step; we can advise on that if desired.

You receive a clear account of how far an attacker gets from an initial endpoint foothold and how to shorten that journey - hardening recommendations, privilege and credential improvements, detection gaps to close, and the configuration changes that make your standard build resilient by default rather than by exception. It is a concrete, prioritised list of build changes, not a vague exhortation to "harden the endpoints", and the work of applying it across your fleet is something our Security Engineering service can take on directly.