Penetration testing in the cloud is unique and has its own security standards. Although cloud providers' security measures can mitigate some vulnerabilities, many organizations are still at risk due to the complexity of these services.
The Differences - Penetration Testing for Cloud Infrastructure vs. Traditional Infrastructure
Penetration testing for cloud infrastructures is as distinctly different from penetration testing for traditional infrastructures as cloud infrastructures are different from traditional hosting infrastructures. Redlings' cloud penetration testing specifically targets these differences and identifies the configuration and implementation errors that often go unchecked. Cloud providers such as Amazon AWS, Google Cloud Platform (GCP) and Microsoft Azure offer a high number of services, but generally follow a shared responsibility model where the cloud provider is responsible for the security of the cloud, such as the hardware and backend infrastructure, and you are responsible for the security in the cloud, such as the configuration of your servers, the permissions granted in your environment and more.
How hackers typically gain access to your cloud infrastructure
.
Below are some of the common methods malicious actors use to gain access to your cloud environment. Although this is aimed at compromising Amazon Web Services (AWS) credentials, these ideas apply to almost all cloud providers on a larger scale. Some of these methods include:
-
A third party with access to your cloud infrastructure is behaving in a dubious or malicious manner, performing actions that are unknown to you.
-
A trusted third party with access to your cloud infrastructure is compromised (supply chain scenarios).
-
Misconfigured repositories lead to loss of confidential data.
-
Errors during a commit lead to the release of confidential data.
-
Locally stored credentials, are stolen by Local File Inclusion (LFI) or Remote Code Execution (RCE).
-
Credentials are stolen through server-side request forgery (SSRF)
-
An already known third-party database is compromised. Its users continue to use a compromised password.
-
Reuse of a password for different accounts occurs.
-
Phishing emails or vishing (voice-over-IP phishing).
-
Physical attack vectors
-
Systems of employees are compromised and then bring this into your environment
-
Mistakes made by employees lead to unintended consequences
Penetration Testing for Amazon Web Services (AWS)
The AWS architecture consists of a set of powerful APIs. Our security engineers are deeply integrated into the AWS ecosystem and test for a number of AWS-specific misconfigurations, including the following:
-
Analyze permissions for permission escalation paths (via services like Lambda, EC2, etc.).
-
Look for misconfigured roles and try to access them
-
Establish persistence through backdoor users / roles.
-
List instances, security groups, and AMIs to perform EC2 attacks.
-
Misuse of Simple Systems Manager to remotely access instances.
-
Analyzing EC2 user data for secrets or system credentials.
-
Identify routes between VPCs for lateral movement and escalation.
-
Check if the buckets are misconfigured (not authenticated).
-
Verify S3 bucket access to sensitive files and data after authentication.
-
Use existing S3 buckets to filter data or perform additional attacks
-
Analyze code and configuration to reveal confidential information
-
Escalate permissions through Lambda IAM roles and SDKs.
-
Data exfiltration through modification of data processing functions.
-
Create new Lambda functions to alert attackers to Blue Team activity (e.g., remove previous AWS backdoors).
-
Modify/evade security group rules for access to RDS databases.
-
Bypass RDS authentication by copying backups and changing the RDS password.
-
Exfiltration of RDS data over the cross-account C2 channel.
-
Various methods to evade detection, cover tracks, and generally stay under the radar
-
Downloading logs to get a better idea of general activity in the area.
Microsoft Azure Penetration Testing
Penetration testing in the Azure cloud is unique and brings its own security considerations. While some vulnerabilities are mitigated by Azure's security measures, many organizations are at risk due to the complexity of these services. One of the strongest features of Azures is the immense flexibility offered to users when setting up the environment. While flexibility is great, it is also a major security risk.
Redlings' penetration testing specifically addresses these needs and identifies the configuration and implementation flaws that often go unchecked. Below are some examples of such cloud services that can be tested:
-
Microsoft Azure
-
Office 365 / SharePoint Online / MS Teams
-
Microsoft Account
-
SharePoint Online
-
Visual Studio Team Services
-
Microsoft Dynamics 365
Google Cloud Platform (GCP) penetration testing
In our assessments, we go beyond automated scanning to provide an in-depth assessment of your environment. We check for various vulnerabilities and misconfigurations, including:
-
Escalation checks for permissions for all IAM members (users / service accounts) accessing your environment.
-
Verify that the least privilege is missing, and show what an attacker would do with that additional access
-
Analyze and exploit the Kubernetes Engine configuration.
-
Testing security controls (Can you tell we are filtering data from your virtual machines, Google Storage, databases, or other places? 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, integrated security tools like Cloud Security Scanner.
-
Check your outside perimeter from the inside: What is publicly visible that shouldn't be?
-
Escalation / misuse of permissions between users, projects and organizations.
-
Backdoor/ persistence methods on an account-by-account basis (survival of the attacker despite "getting caught").
-
Code review of cloud functions, exploitation through cloud function triggers, configuration and setup.
-
Switching between clouds / on-premise environments (abuse of cloud / environment trusts through services / functions such as interconnect, shared VPCs and VPC peering).
