Rhino Security Labs

GCP Penetration Testing Services

Introduction to GCP Penetration Testing

Cloud penetration testing is different than traditional penetration testing, just like cloud architecture/infrastructure is different than traditional on-premise architecture/infrastructure. Cloud providers like Google Cloud Platform (GCP) offer many features/services, but generally follow the a shared-responsibility model, where the cloud provider is in charge of the security of the cloud, such as security relating to hardware and backend infrastructure, and you are in charge of the security in the cloud, such as configurations of your servers, privileges granted within your environment, and much more.

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 environmentalthough 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:

  • 3rd Parties
    • A 3rd party is doing malicious things that you are unaware of
    • A 3rd party you trust is compromised
  • Git Repositories
    • Misconfigured repositories leaking sensitive data
    • Mistakes in commits, publishing sensitive data
  • Application/Server Level Vulnerabilities
    • Credentials stored locally stolen through local file inclusion (LFI) or remote code execution (RCE)
    • Credentials stolen through a servers metadata through server-side request forgery (SSRF) or RCE
  • Password Reuse
    • An old 3rd party database is compromised, your users are still using a compromised password
    • Users using the same password across many accounts
  • Social Engineering
    • Phishing emails or pretext calls
    • Physical vectors
  • Internal Employees
    • Employees getting compromised, then bringing that to your environment
    • Employee mistakes leading to unintended consequences

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.

Make the process from penetration testing your GCP cloud environment as simple and efficient as possible.

We can walk you through the entire process, and it will help us to understand a better idea of your security assessment needs.