RINP // CYBERSECURITY SERVICES
Penetration Test · Cloud Security
We validate identity and privilege chains in your cloud against real attack paths.
Across AWS, Azure, and GCP, we test identity, privilege chains, and data access paths. We verify whether configuration findings are actually exploitable. We prioritize the results by business impact and deliver them as an executive summary, a technical report, and a remediation plan.
- Privilege escalation and transitive privilege chains are verified through controlled testing.
- Identity, privilege chains, and data access paths are assessed within a single attack scenario.
- Findings are turned into remediation priorities based on business impact and exploitability.
3 providers
- 01
AWS · account level
IAM / network / data chain
- 02
Azure · Entra ID
Subscription authority relationship
- 03
GCP · project level
Service account + transitive authority
AWS · Azure · GCP · attacker's eye
What this service is, and is not
- It tests exploitable attack paths across cloud identity, the network layer, data access, and workloads under controlled testing.
- It turns privilege chains and data access paths into verified technical findings backed by a safe PoC.
- It delivers the executive summary and the technical remediation plan from a single, shared risk picture.
- Not a configuration checklist or posture report (CSPM output); real exploit value is proven.
- Not testing of provider infrastructure, impact on third-party tenants/projects/subscriptions, or destructive actions.
- Not a human-layer or physical-facility test; Social Engineering Simulation is a separate scope.
Scope and boundaries
- Manual penetration testing at the level of 1+ account/subscription/project in AWS, Azure or GCP
- IAM/identity, network segmentation, storage/secrets and data-exposure control areas
- Compute layer, virtual machines and non-Kubernetes container workloads (by package level)
- Kubernetes deep review and serverless workloads (Deep Review and Advanced packages)
- Logging, audit and detection validation (control-effectiveness observation)
- Controlled manual validation and safe proof-of-concept production
- Attack-path diagram or control break at Package Level 2+ when evidence forms
- Deliverables - executive summary, technical findings report, evidence set and fix-priority work list
- Configuration checklist, posture scoring and CSPM-output interpretation
- CI/CD and IaC review (not in the core package; taken as a separate add-on)
- Testing the <b>provider's (AWS/Azure/GCP) own infrastructure</b> and provider-managed shared services
- Actions affecting third-party tenants, projects or subscriptions
- Service-disrupting actions such as DoS, DDoS, flooding and stress testing
- Social engineering (the human layer is the Social Engineering Simulation line) and physical-facility testing
- Persistence, data deletion or irreversible production changes
- Written authorization, proof of ownership and an approved scope are clarified before testing.
- The access model is gray-box by default; a read-only or controlled test role is fixed in the proposal.
- MFA, VPN, jump host and PIM/JIT constraints are shared before the proposal.
- An attack-path diagram is used only if a chain was actually validated.
- The starting price is an approximate budget; the final proposal is set once the access model and complexity are verified.
- Written authorization and a list of accounts/subscriptions/projects
- Region list, critical-asset and data definitions, high-level topology
- Test window, escalation and emergency-stop contacts
- Read-only or controlled test role; MFA, VPN and PIM/JIT constraints
- Optional: tagging, IAM policies / RBAC export, IaC repo access, CSPM outputs, incident history
Every engagement runs under written authority with a stop gate and escalation line. See Rules of Engagement.
How we work: six steps from cloud scoping to retesting
Kick-off & rules of engagement
Written authorization, scope (account/subscription/project), region list, access role and test window are confirmed; the decision pressure and the evidence object to accelerate are clarified.
Inventory & attack surface
In-scope account/subscription/project inventory, IAM trust relationships and the attack surface are mapped across the eight control areas; AI-assisted analysis accelerates, an expert validates.
Threat model & priority exploit paths
Priority exploit paths are identified by business impact; privilege-chain, data-access-path and transitive-authority hypotheses are queued for controlled validation.
Controlled validation & chained exploitation
We validate prioritized attack hypotheses with a safe PoC, within provider rules, written authorization, and defined stop conditions.
Finding assessment & impact clarification
We prioritize verified chains by data classification, critical asset, business impact, and exploitability.
Reporting and post-remediation retest
We deliver the executive summary, the technical report, and safe PoC reproduction steps; after the client remediates the findings, we retest selected chains.
What we deliver
Executive summary
- Cloud risk picture: summarizes critical privilege and data access findings together with their business impact.
- Decision summary: shows which accounts, assets, and controls to address first.
- Retest result: shows the state of the privilege chain after the client's remediation.
Technical report and remediation plan
- Technical report: covers the privilege chain, the data access path, safe PoC steps, and the recommended control.
- Cloud surface summary: shows the accounts, services, and critical assets that were tested.
- Remediation plan: ranks findings by business impact and assigns owners.
- Control recommendations: describes actionable steps for IAM, network, and data access.
Optional outputs
- Attack-path diagram (if a proven chain exists; 1–2 in Deep Review, 3+ validated chains in Advanced).
- Control mapping (CIS / NIST CSF / Microsoft Cloud Security Benchmark) - roughly +10%.
- Limited fix-validation note: a point check; not a substitute for a full retest.
Leadership sees which cloud risk to address first. The technical team tracks the privilege chain, the data access path, and the control to apply.
Decision profile
- Duration
- 2–4 weeks, scope-proportional
- Depth
- Privilege chain & data-access path
- Delivery
- Management + technical
- Scope
- AWS · Azure · GCP components
- Best for
- New landing zone / architecture change
Which is the right start, and when?
These three approaches do not produce the same evidence object. Starting without knowing the difference wastes time and budget chasing the wrong proof.
| Criterion | ÖnerilenCloud Security Penetration Test | Application Security Penetration Test | Configuration Audit or Posture |
|---|---|---|---|
| Decision question | Where does the cloud authority chain and data-access path truly open up? | Does the critical flow truly break in the new release? | On which control do the configuration checklist and posture score deviate? |
| Primary evidence object | Privilege chain, data-access path, transitive authority, fix-priority order | Validated technical proof on the critical flow, a fix-first backlog | Framework-compliance score, deviation list, posture report |
| Ideal trigger | New landing zone, architecture change or multi-account chain visibility | New release, critical-flow validation, customer security review | Framework-compliance pressure, audit readiness or an annual posture scan |
| Wrong match | Presenting a cloud checklist or CSPM output as risk | Trying to close a cloud authority-chain question with an application-surface test | Substituting a configuration report for a penetration test; not measuring exploit value |
One example of decision clarity
Anon case
New landing zone: is the cloud authority chain protected by evidence?
Ahead of a new cloud deployment, an organization scoped us to test cross-account IAM relationships and the access paths to critical data. We agreed on written authorization, the access role, and the test window.
Our controlled testing revealed two privilege escalation chains and an access path reaching critical data. We verified the findings reproducibly with a safe PoC.
We delivered the executive summary, the technical report, and the remediation priorities. After the client applied the IAM controls, our retest confirmed that the chains were broken.
What this case produced
- The cloud deployment was updated based on verified privilege chains.
- The access path reaching critical data was verified technically.
- The IAM controls were confirmed through a retest.
Let's clarify your cloud scope together
This form helps us clarify the cloud provider, the accounts, the access role, the critical data, and the test window.
Frequently asked questions
CSPM and configuration audits list deviations. A cloud penetration test, by contrast, uses controlled testing to verify the privilege chains and data access paths an attacker could actually use.
The standard scope covers identity, network, data, and workload controls within the cloud environment. If a CI/CD and IaC review is needed, it is planned as a separate add-on.
Once the client remediates the findings, the same chain is retested. If the architecture or scope has changed, a new test scope is defined.
An attack path diagram is produced only when a verified chain exists. The number of chains delivered per package tier is stated in the proposal.
The account or project list, regions, critical asset and data definitions, the test role, MFA, and network access conditions should be shared before the engagement begins.
Production testing is carried out under written authorization, provider rules, approval gates, and defined stop conditions. Destructive actions and third-party assets are kept out of scope.
Related services and add-ons
If your cloud surface carries a different pressure, or you need to move to the source pipeline, open the right bridge here.
Network Security Penetration Test
If the focus is network-surface exposure, segmentation impact and chainable access flaws, the Network Security Penetration Test is the right start.
PT-1Application Security Penetration Test
If the focus is web, API or mobile business logic, critical-flow validation and user-authority boundaries, the Application Security Penetration Test is the right start.
CI/CDCI/CD & IaC Review (add-on)
If the focus is the source-code pipeline, IaC templates and deployment-pipeline security, the CI/CD and IaC Review add-on is taken alongside the Cloud Security Penetration Test.
// PT-3 · DISCOVERY
Let's clarify your cloud scope, privilege chains, and critical data paths together.
In a discovery call, we define the provider, the accounts, the access model, the critical assets, and the test window together.