Cloud identities and permissions
Roles and policies that may allow more access than the workload or user requires.
Utilities Studio / Cybersecurity
Show your cloud team which permissions an attacker could exploit.
Test attack paths across AWS, Azure, and Google Cloud permissions and workloads. Validate exploitable risk with evidence and remediation guidance.
A cloud warning tells your DevOps team that a setting needs attention. You also need to know what access it creates and which workloads are affected. We test the agreed identities and service boundaries, then document the starting access and path taken so your team can address the permission or configuration behind it.
The assessment
Cloud penetration testing investigates how an attacker could exploit weaknesses in your cloud environment. It examines the interaction between identities, services, and workloads within the authorized scope. We document the starting access, the path tested, and the impact demonstrated, so your team can address the permissions or configuration behind the finding.
Roles and policies that may allow more access than the workload or user requires.
Publicly reachable services and storage within the agreed account or project boundaries.
The access available from a workload and its connections to other cloud services.
Trust relationships and paths between resources, with cross-account testing only where authorized.
Working with your team
Confirm the assets, permissions, and production limits. Name the contacts and record the dates, reporting format, support arrangements, and retest terms.
Investigate the agreed attack paths and validate findings. Keep your team updated and escalate critical issues immediately through the agreed channel.
Walk your engineers through the report and remediation priorities. Carry out the agreed retesting and document which fixes worked and what remains unresolved.
The number of accounts, subscriptions, or projects, the services in use, identity complexity, and the depth of authorized exploitation determine the effort.
We confirm timing after agreeing access, cloud-provider constraints, workload sensitivity, and rules of engagement. Retesting follows the agreed remediation window when included.
Pentest delivery
We share validated findings during the test through the agreed secure channel. Critical issues go to your nominated contact immediately. Progress updates cover completed work, blockers, and what comes next.
Your engineers get affected assets, reproduction steps, evidence, and remediation guidance. We explain severity using the demonstrated impact. An executive summary sets out the business risk and the limits of the assessment.
A technical findings review lets your engineers discuss the evidence and recommended fixes with us. We name the technical contact and agree the support period and response arrangements before testing.
Retesting checks fixes to the original findings and records the result. Before booking, we specify the findings covered, retest rounds, time window, and any charges. New features or changed environments need a scope review.
We agree the findings format and handover method with your team. If you use Jira, Linear, or GitHub, we scope the export or ticket handover, required access, and treatment of sensitive evidence before testing.
Your proposal sets the start date, testing window, and report delivery date after we review scope and access. Bring your audit or release deadline so remediation and retesting can be planned around it.
Delivery references: NIST SP 800-115 and CREST's penetration testing programme guide.
The practitioner behind the work
Sheeraz Ali is our Head of Cybersecurity. His work spans application, cloud, network, and AI assessments. His personal track record includes leading pentests at Cobalt and building the internal pentest programme at SolarWinds.
Read Sheeraz's security backgroundSheeraz's personal track record
His website lists OSCP, CRTP, CRTE, CREST CRT and CPSA, CBBH, and CKA.
At SolarWinds, he delivered 120+ internal pentests. As CTO at Pwned Labs, he built a platform serving 40,000+ practitioners. He co-developed Mobexler, selected for Black Hat Arsenal, and presented research at Nullcon and c0c0n.
Explore his career timelineFAQ
A configuration assessment reviews settings and control gaps. A penetration test investigates exploitability and impact through authorized attack paths. They can complement one another, and the proposal defines which work is included.
AWS, Azure, and Google Cloud environments can be scoped. The assessment plan identifies the specific services, accounts, identities, and workload boundaries included.
We review production sensitivity and provider requirements before agreeing a scope. Testing windows, permitted techniques, and exclusions must reflect the operational risk of the environment.
Bring the previous report and a list of changes to your code, permissions, or infrastructure. We can use those to scope the next assessment. Check which earlier findings were fixed and which fixes were verified; the date on the old report does not answer those questions.
Review AWS, Azure, and Google Cloud security. Assess IAM permissions, exposed services, and workload boundaries, with a prioritized hardening plan.
Review privileged access, service accounts, authentication, and permission boundaries. Get an IAM assessment and practical least-privilege recommendations.
Assess internal and external networks for exploitable services, access weaknesses, and routes to sensitive systems. Get evidence and remediation priorities.
Tell us what your team needs to resolve, which systems are involved, and any deadline. We will work through the scope and reporting needs with you.