Cloud and Identity Assessment

It helps to follow a realistic path rather than a list of controls. A member of staff receives an email with a link - a shared document, a voicemail notification, a security alert. The link does not lead to a crude fake; it leads to a reverse proxy under the attacker's control that sits invisibly between the user and the genuine login page. The user sees the real sign-in screen, enters their password, and approves the multi-factor prompt - and it all works, because the proxy is relaying every step to the real provider in real time. What the proxy quietly keeps is the prize: the authenticated session token the provider issues after multi-factor succeeds. The attacker replays that token and is now logged in as the user, multi-factor already satisfied, without ever knowing or needing the password. This is an adversary-in-the-middle attack, and it is the single most important reason that "we have MFA" is no longer the end of the conversation: push prompts, SMS, and authenticator-app codes are all defeated by it, and only phishing-resistant methods such as FIDO2 and passkeys, which refuse to authenticate to the wrong domain, reliably are not. From that first session an attacker rarely stops. They grant a malicious application consent to read mail and files, quietly acquiring a refresh token that survives the eventual password reset; they hunt for the over-privileged role or the exposed cloud credential that turns one mailbox into the whole tenant. Our assessment is built around exactly these chains - and, if you wish, we can demonstrate the opening move directly through a Social Engineering Assessment.

The first element of our Cloud and Identity Assessment is to assess the surface that attack path moves through. We test how multi-factor authentication is actually implemented - whether it is enforced on every account, and whether it is the kind an adversary-in-the-middle attack defeats. We check whether you have any phishing-resistant authentication in place. We map your conditional-access policies for the gaps attackers live in: excluded users and groups, policies left in report-only mode and never enforced, location or device loopholes, and above all the legacy authentication protocols - older mail and sign-in endpoints - that bypass conditional access and multi-factor entirely. We examine application consent and the enterprise applications and service principals already present in your environment, because a single over-permissioned app, or an unrestricted user-consent setting, is a standing invitation to the persistence trick described above. We assess how privileged access is handled: how many standing administrators you carry, whether high privilege is granted just-in-time or held permanently, and whether the most powerful roles are protected accordingly. And for organisations running a hybrid estate, we examine the seam between on-premises directory and cloud - the synchronisation account, the federation trust, and the token-signing material whose theft would let an attacker forge their own valid logins for any user at all. We work here from the attacker's vantage point - what an intruder could reach and become - and where a particular provider's deeper internals call for vendor-specific tenant work beyond that, we scope it explicitly with you rather than imply a depth we have not agreed.

The second element is the cloud side - AWS, Azure, or Google Cloud as your environment requires - where we hunt for the misconfigurations that turn a foothold into control. The centre of this is identity and access management itself: we look for over-permissioned roles and wildcard policies, and we trace the privilege-escalation primitives that let a limited principal promote itself, such as the ability to pass a more privileged role to a service, to edit a policy it is already attached to, or to assume roles in a chain across accounts. We check what is exposed to the world - storage buckets, disk snapshots, databases, and serverless endpoints reachable without authentication - and we follow the credentials an attacker would actually use: keys committed to repositories, secrets sitting in environment variables and configuration, and the instance metadata endpoint that hands out a host's cloud credentials to anything able to reach it, which is why we check whether it is protected against server-side request forgery rather than left in its older, exploitable form. Where you build with infrastructure as code, we review it directly, catching insecure patterns before they are ever deployed. And throughout, we ask whether any of this would be seen: whether your cloud audit logs are switched on, retained, and actually watched, or whether an attacker could move through your control plane unobserved.

We work primarily from read-only access to your environment, combined with an assumed-breach perspective: rather than only listing misconfigurations, we ask what a single compromised user or workload could actually reach and become from there. Automated posture tools have their place and we use them for breadth, but the findings that matter - the privilege-escalation chain, the over-trusted application, the federation gap - come from human reasoning about how the pieces fit together. You receive a map of your cloud and identity attack surface, the specific paths that carry the highest risk, and prioritised remediation grounded in the realities of your platforms. Because the control plane increasingly is the perimeter, this is the assessment whose findings tend to carry the largest blast radius, and the one we most often recommend revisiting as a cloud footprint grows. Where you would rather the fixes were made than merely described - tightening policies, re-tiering privilege, closing a federation gap, moving to phishing-resistant authentication - our Security Engineering service can carry them out.