Why GCP Pentesting?
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. mobile application penetration testing service,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.
Common GCP Attacks
- 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)
How do attackers gain access to GCP?
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:
- 3rd Parties
- Git Repositories
- Application/Server Level Vulnerabilities
A 3rd party is doing malicious things that you are unaware of A 3rd party you trust is compromised
Misconfigured repositories leaking sensitive data Mistakes in commits, publishing sensitive data
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
- Social Engineering
- Internal Employees
An old 3rd party database is compromised, your users are still using a compromised password Users using the same password across many accounts
Phishing emails or pretext calls Physical vectors
Employees getting compromised, then bringing that to your environment Employee mistakes leading to unintended consequences