Skip to content

Utilities Studio / Cybersecurity

Cloud penetration testing

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.

Your cloud team needs the attack path and the permission behind it.

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

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.

Inside the scope

Cloud identities and permissions

Roles and policies that may allow more access than the workload or user requires.

Exposed resources

Publicly reachable services and storage within the agreed account or project boundaries.

Workload attack paths

The access available from a workload and its connections to other cloud services.

Account boundaries

Trust relationships and paths between resources, with cross-account testing only where authorized.

What your team receives

  • An executive summary explaining the business impact and what the assessment covered
  • Technical findings that identify the affected component and give your engineers evidence and reproduction steps
  • Remediation guidance for the affected components and a findings review with your team
  • Retest results for the agreed findings, with rounds, time window, and pricing specified before booking

Working with your team

From scope to remediation.

01

Scope the work and agree delivery

Confirm the assets, permissions, and production limits. Name the contacts and record the dates, reporting format, support arrangements, and retest terms.

02

Test and share the evidence

Investigate the agreed attack paths and validate findings. Keep your team updated and escalate critical issues immediately through the agreed channel.

03

Review findings and verify fixes

Walk your engineers through the report and remediation priorities. Carry out the agreed retesting and document which fixes worked and what remains unresolved.

What are you paying for?

The number of accounts, subscriptions, or projects, the services in use, identity complexity, and the depth of authorized exploitation determine the effort.

Planning around your deadline

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

Know what to expect before the test starts.

When will we see findings?

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.

What will the report contain?

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.

Who helps us work through the fixes?

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.

What does retesting cover?

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.

Can findings go into our issue tracker?

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.

When can we start and get the report?

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

Led by Sheeraz Ali.

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 background

Sheeraz's personal track record

Pentest engagements at Cobalt
245
Vulnerabilities identified at Cobalt
1,592
CVEs discovered
28+
Machines and labs authored at Hack The Box
300+

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 timeline

FAQ

Questions before you book.

How does this differ from a cloud security assessment?

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.

Which cloud providers can you assess?

AWS, Azure, and Google Cloud environments can be scoped. The assessment plan identifies the specific services, accounts, identities, and workload boundaries included.

Can you test production cloud environments?

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.

We had a pentest last year. What should we test now?

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.

All cybersecurity services

What do you need to get moving?

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.