Credential Theft Assessment

A credential is anything that proves to a system that you are who you claim to be, and there are far more of them than users directly see. The most familiar are passwords, but a password is often not even the most useful thing to steal. Passwords are frequently held as hashes - the NTLM hashes Windows keeps, the hashes in an application's user database - and a hash can sometimes be used directly, without ever being cracked back into a password. Kerberos tickets act as credentials inside a Windows network and can be captured and reused. And increasingly, the credentials attackers most want are the artefacts a system issues after you have already authenticated: the session cookie that represents your logged-in session in a web application, the OAuth access and refresh tokens that authorise an API call, the JSON Web Tokens that carry identity between services, the long-lived API keys and personal access tokens that automate access, and the private keys and certificates that authenticate machines. The reason this matters is simple and uncomfortable: these post-authentication credentials usually bypass multi-factor authentication entirely. An attacker who steals your live session cookie does not need your password, and does not need to pass the multi-factor check you already passed - the application simply sees them as you, for as long as that session lasts. We begin by establishing which of these credential types your systems actually rely on, because each is stolen, and defended, differently.

The routes to a credential are many, and we test your exposure across them. Password spraying tries a handful of common passwords across many accounts to stay under lockout thresholds; credential stuffing replays the enormous corpus of username-and-password pairs already exposed in other organisations' breaches, on the well-founded bet that people reuse them. Phishing remains the most reliable route of all, and the modern form is particularly dangerous: an adversary-in-the-middle proxy that sits between your user and your own login page, relaying the real sign-in - password, multi-factor prompt and all - while quietly keeping the session token issued at the end. This is the same technique our Cloud and Identity Assessment examines against your third-party logins, and whose human-security aspects are tested by our Social Engineering Assessment; here we are concerned with it against the applications you run yourself, and with what your own session handling does to make it more or less devastating.

We also assess theft that needs no interaction at all: session cookies and tokens lifted by malware from a compromised endpoint, credentials intercepted on the wire if transport lacks proper TLS encryption, and session tokens stolen through cross-site scripting in your own applications. We further assess the security measures that are supposed to make a stolen credential useless - whether multi-factor authentication actually holds, and whether the multi-factor-fatigue and prompt-bombing techniques that wear users down with repeated push notifications would get an attacker waved through.

Once an attacker has any foothold, the credential-gathering moves inward, and this is the territory of Windows networks in particular. One important vector for the harvesting of credentials is from caches on compromised hosts - the material left in memory and on disk that lets one machine become a stepping stone to the next. We test pass-the-hash and related techniques, which reuse a stolen password hash to authenticate as its owner without ever recovering the plaintext, and the Kerberos attacks that drive so much internal compromise: Kerberoasting, which requests service tickets for privileged accounts and cracks them offline, and AS-REP roasting, which does the same against accounts configured without Kerberos pre-authentication. The offline cracking step itself - turning a captured hash or ticket into a usable password - is the subject of our dedicated Password Resilience Assessment, and the lateral movement these credentials enable is mapped end to end by our Network Infrastructure and Breach Impact Assessments. Here our focus is the credentials themselves: where they are exposed, how they are reused, and what an attacker accumulates as they move.

This is where a Credential Theft Assessment goes somewhere a third-party-focused assessment cannot: into the session and token handling of the software you build and run, which is both a prime target and something entirely within your power to fix. A web session is only as safe as the way it is created, carried, and ended.

On creation, we test whether a fresh session identifier is issued the moment a user authenticates - failing to do so invites session fixation, where an attacker plants a known session identifier and waits for the victim to log into it - and whether session identifiers and tokens are generated with enough randomness that they cannot be guessed or predicted. On transmission, we examine how the session is carried: whether session cookies are marked HttpOnly so that a cross-site scripting flaw cannot read them, Secure so they never traverse plaintext, and with an appropriate SameSite setting; and whether tokens are ever leaked into URLs, logs, or referrer headers where they do not belong. On expiry, we test the part organisations most often get wrong - whether logging out actually invalidates the session on the server or merely clears it in the browser, whether idle and absolute timeouts exist, whether a password change revokes existing sessions, and whether there is any means of revoking a session at all once it is suspected stolen.

Where your systems use token-based authentication, we look hard at the tokens themselves. JSON Web Tokens are a frequent source of trouble: signatures that are not actually verified, the "none" algorithm accepted, weak signing secrets that can be cracked offline, algorithm-confusion tricks, tokens that never expire, and sensitive data placed in claims that anyone holding the token can read. We assess whether refresh tokens are short-lived and rotated, whether tokens are bound to a particular client so that a stolen one cannot simply be replayed elsewhere, and whether any of it can be revoked when it must be. And we test the logic around all of this - the multi-step login flows that elevate a session before every factor is complete, the "remember me" tokens with no real expiry, and the access-control checks that are quietly not re-evaluated when a user's privileges change mid-session.

Because these are your systems, the fixes are real and available - not a vendor's checkbox but a change you can make - and we frame our recommendations around that. At the session layer, this means issuing fresh, high-entropy session identifiers on authentication, setting cookie flags correctly, enforcing server-side invalidation on logout and on password change, and building the ability to revoke a session you suspect is stolen. At the token layer, it means verifying signatures properly and with a strong algorithm, keeping access tokens short-lived and rotating refresh tokens, binding tokens to a client where the stakes justify it, and keeping sensitive data out of anything the holder can read. The single most powerful step, here as in our Cloud and Identity Assessment, is phishing-resistant authentication - WebAuthn and passkeys that are bound to your application's own domain and therefore cannot be relayed by an adversary-in-the-middle proxy at all - together with requiring a user to re-authenticate for sensitive actions rather than trusting a session that may already have been stolen. We pair this with the screening of credentials against known-breached datasets at the point they are set, rate limiting and lockout to blunt spraying and stuffing, and the detection that would notice anomalous session use, an impossible login, or a sudden burst of failed authentications. Where you would rather these changes were implemented than merely recommended, our Security Engineering service can build them in, and the broader protection of the data a stolen credential would ultimately reach is the remit of our Secure Data Architecture offering.

You receive a clear picture of your exposure across every credential type your systems rely on, the routes by which each could be stolen, and - most importantly - the effectiveness of the controls that should make a stolen credential useless. The session-management and token findings come with concrete, developer-ready remediation rather than general advice. We handle any credentials, hashes, or tokens encountered during the engagement under strict, pre-agreed controls, and destroy them on completion. The most uncomfortable and common discovery is that a single stolen session quietly defeats an organisation's entire multi-factor investment - far better learned from us than from the attacker who has already done it.