Cloud environments can be compromised in a variety of ways and misconfigurations that can leave you vulnerable to external attackers. They aren’t the only potential threat though: internal employees should be closely monitored as well for a few reasons, including potential for their own malicious activity, their potential for compromise from an external attacker (separate from a direct cloud environment compromise), or even their potential for making mistakes that open a security hole or perform an unintended action.

GCP pentesting allows you to test the security of whole other level of your applications and infrastructure that usually would not be directly evaluated during a traditional pentest or by external attackers.

GCP pentesting is an authenticated look at an environment that aims to provide a near-simulation of a malicious actor with the same level of access. This includes a variety of methods of exploitation and feature/intended functionality abuse to benefit the attacker.

The assessment will ensure that the security of an organization/environment is the strongest it can be in the unfortunate event that a malicious actor gains unauthorized access.

This blog describes some of the common methods that malicious actors will use to gain access to your cloud environment—although it’s aimed towards the compromise of Amazon Web Services (AWS) credentials, the ideas apply to nearly all cloud providers at a larger scale. Some of these methods include:

Even if you enforce multi-factor authentication (MFA), strong passwords, and strong security policies, most of these methods get around those protections in one way or another. Someone is now in your environment, have you done the proper testing to ensure you have the ability to detect, respond, and react to this scenario? Ideally, the principle of least-privilege should prevent an attacker from expanding their access beyond what is expected, but is that really the case?

In our assessments, we go beyond automated scanning to provide an in-depth assessment of your environment. We check for a variety of different vulnerabilities and misconfigurations, some including:

• Privilege escalation checks for all IAM members (users/service accounts) that access your environment
• Checking for lack of least-privilege, demonstrating what an attacker would do with that extra access
• Kubernetes Engine configuration analysis and exploitation
• Testing security controls (can you detect us exfiltrating data from your virtual machines, Google Storage, databases, or anywhere else? Can we evade your technical controls? Can you stop us from acting maliciously or detect us when we do?)
• Best practices: Stackdriver logging/monitoring, encryption, built-in security tools such as Cloud Security Scanner
• Checking your external perimeter from within the inside: what is exposed publicly that shouldn’t be?
• Cross-user/project/organization privilege escalation/abuse
• Backdoor/persistence methods in the account (surviving “getting caught”)
• Code review of Cloud Functions, exploitation through Cloud Function triggers, configuration, and setup
• Pivoting between clouds/on-premise environments (abusing cross-cloud/environment trusts through services/features like Interconnect, shared VPCs, and VPC peering)

Rhino provides you with a report at the end of the process that details all vulnerabilities/misconfigurations discovered, as well as attack narratives for any complex attack paths taken while in the environment. We provide up-to-date and contextual risk ratings for each finding, along with guidance to perform effective remediation.

Our reports aim to help you understand the weaknesses within your environment, what risks those weaknesses bring, and how to go about remediating those weaknesses.

If, during our assessment, we discover something with a high priority, such as a critical risk vulnerability or an indication of a prior compromise, we will report it to you as soon as it is found and we will work to help you remediate and learn from the situation in the best way possible.

No, Google does not require any alert ahead of time for GCP pentesting, but we need to follow Google’s Acceptable Use Policy and cannot target resources that don’t belong to you.

We do not perform any testing for vulnerabilities in the category of “denial-of-service” to avoid breaking Google’s AUP, and also to not disrupt any of your operations during our pentest. Clients are typically notified before any potentially disruptive activity is performed.