A configuration review tells you which settings are wrong. A cloud penetration test tells you what somebody can do with them. Protonyte starts from a low-privileged identity - a developer key, a compromised function, an exposed container - and tries to reach your data and your billing, the way a real intrusion in a cloud account actually unfolds.
These are two different jobs and it is worth being plain about which you need. Our cloud security assessment goes across the whole account and measures it against the CIS benchmark: every bucket, every role, every log setting, scored and listed. It is the right starting point if you have never had one.
This page is the other job. We are given one small foothold and we try to get somewhere with it, the way an attacker would. Not "this role is over-permissive" but "this role let us read the deployment pipeline, which held a key to the production account". Most organizations should have the review first and this second - and we will say so rather than sell you the wrong one.
Identity first, because in a cloud account almost every path runs through a permission somebody granted and nobody revisited.
The cloud equivalent of Active Directory, and just as productive.
What can be read, listed or written by someone who should not.
Breaking out of the thing you landed in.
Functions and pipelines hold more privilege than anyone remembers granting.
Whether the account is as separated as the diagram says.
What your trail recorded while we were in there.
We agree the accounts, the starting foothold, and what each provider permits before anything begins.
Read-only enumeration of what exists and who can touch it.
From the foothold outward, one permission at a time.
The point of the exercise: what an attacker would leave with.
The route, the permissions that allowed it, and the smallest change that breaks it.
Two documents and a conversation. Written so the person who signs the invoice and the person who writes the fix can both use them.
The work follows CIS Benchmarks, MITRE ATT&CK for Cloud, NIST SP 800-115 and OWASP Top 10, so the coverage can be checked rather than taken on trust, and the report maps to what your auditor or your enterprise customer already recognises.
This page is one part of our penetration testing service. Where a finding needs a different kind of engagement to answer properly, we say so in the report rather than selling you the test we happen to be running.
No, and buying the wrong one is a common waste of money. An assessment measures your whole account against a benchmark and lists what is wrong; a penetration test starts from one foothold and shows what can be reached with it. If you have never had either, have the assessment first.
For ordinary penetration testing of your own resources, the major providers permit it under their published customer testing policies without prior approval, with specific exclusions - denial of service being the main one. Some activities still require notice. We check the current policy for your provider during scoping and keep the test inside it.
Less than people expect. A deliberately low-privileged identity is the most useful starting point, because it is what an attacker would have. For a wider review we also ask for read-only audit access, which lets us see paths we could not have discovered from the foothold alone.
Yes. Cluster RBAC, service-account token exposure, workload isolation, admission control and the path from a compromised pod to the node and then to the cloud account are all in scope, on EKS, AKS, GKE or self-managed.
No. We prove access rather than use it: a file is read, not copied out; a privilege is obtained, not exercised against your data. Anything we create for the test is listed in the report and removed at the end.
Tell us what you need tested. Our team will reply with a clear scope and quote.
An assistant, not a person, so check anything important with us. Please do not type passwords or card numbers here. Messages are kept so we can answer you better.