Skip to content

Cloud Penetration Test๐Ÿ”—

Service Overview๐Ÿ”—

The Secureworks Cloud Penetration Test methodically evaluates your cloud environment's security through simulation of real-world attack scenarios and adversary behaviors. Our testing framework addresses multiple threat vectors, delivering an in-depth assessment of security gaps, misconfigurations, and vulnerabilities that could be leveraged by sophisticated threat actors.

To conduct these tests effectively, certain levels of access and information are required, such as access accounts (such as Reader accounts and developer accounts), credentials for service principals, and technical infrastructure like remote testing appliances and VPN connectivity. Below is a detailed overview of each testing objective, the real-world scenarios they represent, and the access or information needed to execute them.

Cloud Test Objectives Description
Cloud Reconnaissance Simulate an external attacker with no authenticated access attempting to gather information about your cloud environment.
Unauthenticated Attacker Reconnaissance Access or Information Required: None. This test is conducted entirely from an external perspective without any internal access or credentials.

Objective: Simulate an external attacker with no authenticated access attempting to gather information about your cloud environment. The goal is to identify publicly accessible resources and information that could be leveraged to mount an attack across your AWS, Azure, and GCP infrastructure.

Real-World Scenario: An unauthenticated attacker on the internet is searching for exposed cloud resources or leaked information that could provide a foothold into your cloud infrastructure. Such attackers often use automated tools and manual searching to scan for misconfigurations, open ports, and publicly accessible data.
Assumed Breach Scenarios Simulate scenarios where an internal account or service has been compromised to assess the potential impact on your cloud environment.
Compromised Developer Credentials Access or Information Required:
  • Developer Account Credentials: Username and password for a developer account within the cloud environment
  • Multi-Factor Authentication Details: Information on MFA setup, if applicable
  • Access to relevant development tools and platforms
Objective: Assess the risk and potential impact if a developer's cloud credentials are compromised, including the possibility of privilege escalation to higher privilege levels across cloud services and resources.

Real-World Scenario: A developer falls victim to a phishing attack, resulting in their credentials being compromised. An attacker now has the same access as the developer and attempts to exploit this access to escalate privileges or access sensitive resources across multiple cloud services.
Compromised Low-Privileged Regular User Access or Information Required:
  • Regular User Account Credentials: Access to a standard user account
  • Multi-Factor Authentication Details: Information on MFA setup, if applicable
  • Basic resource access permissions
Objective: Evaluate the threat posed by a compromised low-privileged user account, including attempts to access sensitive data or escalate privileges across cloud services.

Real-World Scenario: An employee's credentials are compromised through social engineering or malware. The attacker uses this low-privileged access as a starting point to navigate the environment, searching for ways to gain higher privileges or access restricted data.
On-Premises to Cloud Lateral Movement Access or Information Required:
  • On-Premises Network Access via Remote testing appliance
  • User Account Credentials: Access to a standard user account
  • Basic resource access permissions
Objective: Simulate a compromised on-premises resource that can be used to gain access to cloud systems, exploiting hybrid connections and existing permissions across all cloud environments.

Real-World Scenario: An attacker gains control over an on-premises resource (e.g., a workstation or a compromised AD user) and attempts to leverage this access to compromise cloud resources through established hybrid connectivity solutions such as DirectConnect, ExpressRoute, or Cloud Interconnect.
Cloud to On-Premises Lateral Movement Access or Information Required:
  • Compromised Cloud Resource Access: Cloud resource access (e.g., VM, container, managed service or service principal)
  • User Account Credentials: Access to a standard user account
  • User Account Credentials: Access to a cloud user account
Objective: Assess whether a compromised cloud resource can be used to gain access to on-premises systems across any cloud platform connection.

Real-World Scenario: An attacker gains control over a cloud-based resource and attempts to pivot into the corporate network through established hybrid connections, potentially compromising internal systems and data.
Azure Specific Scenarios Scenarios below have been developed to target customerโ€™s Azure Cloud environments.
Compromised Service Principal of an Application Access or Information Required:
  • Service Principal Credentials: Application ID and authentication keys or certificates
Objective: Assess the risk and potential impact if an application's service principal credentials are compromised, including the possibility of privilege escalation to contributor, subscription owner, or global administrator levels within the Azure environment.

Real-World Scenario: An attacker exploits a vulnerability in the application, successfully executing a Remote Code Execution (RCE) attack. This allows the attacker to run arbitrary commands on the application server. By leveraging this access, the attacker navigates through the system and locates poorly secured configuration files or environment variables containing the service principal's credentials (Application ID and authentication keys or certificates). With these credentials in hand, the attacker can now impersonate the application, potentially accessing all resources and data the compromised service principal has permissions to access.
Conditional Access Testing Access or Information Required:
  • Test User Accounts: Accounts with policies applied, including various roles and access levels
  • Conditional Access Policy Configurations (Reader Account): Detailed settings of existing policies
Objective: Evaluate the effectiveness of Entra ID Conditional Access policies in preventing unauthorized access and assess whether they can be bypassed.

Real-World Scenario: An attacker attempts to access sensitive resources by circumventing conditional access policies, possibly by spoofing trusted locations or devices.
AWS Specific Scenarios Scenarios below have been developed to target customerโ€™s AWS Cloud environments.
Compromised IAM Role Testing Access or Information Required:
  • Service Principal Credentials: Application ID and authentication keys or certificates
Objective: Assess the risk and potential impact if an AWS IAM role is compromised, including the possibility of privilege escalation through role assumption and trust relationships.

Real-World Scenario: An attacker successfully compromises an EC2 instance with an attached IAM role or obtains temporary credentials through a compromised application. They attempt to leverage AWS STS to assume additional roles or exploit trust relationships between accounts.
Cross-Account Access Testing Access or Information Required:
  • Test account access in AWS Organization
  • Cross-account role ARNs
  • Resource sharing configurations
Objective: Evaluate the security of cross-account access configurations and AWS Organizations setup, including resource sharing and role assumption across accounts.

Real-World Scenario: An attacker gains access to a lower-environment AWS account and attempts to leverage cross-account roles and resource sharing to access production environments or more privileged accounts.

Service Methodology๐Ÿ”—

The Secureworks Cloud Penetration Test methodically evaluates your cloud environmentโ€™s security by simulating real-world attack scenarios, adversarial behaviors, and advanced lateral movement techniques. Below is the phased approach, updated to incorporate your specified sections:

Pre-Engagement Planning & Scoping๐Ÿ”—

Secureworks initiates testing with a collaborative kickoff to align on objectives, risks, and logistics. This phase ensures minimal disruption to operations while maximizing test efficacy.

  • Scope Finalization: Define cloud accounts, hybrid connections, and APIs in-scope (e.g., AWS Organizations, Azure Subscriptions).
  • Access Coordination: Establish credential requirements (e.g., developer accounts, service principal keys) and deploy Remote Testing Appliances (RTAs) for hybrid attack simulations.

Cloud Reconnaissance & Enumeration๐Ÿ”—

Secureworks conducts unauthenticated and credentialed discovery to map attack surfaces in your cloud environment. This phase identifies exposed services, misconfigured resources, and credential leakage risks:

  • Unauthenticated Scans: Probe for public-facing storage (S3 buckets, Azure Blobs), exposed APIs, and metadata services (e.g., AWS IMDSv1).
  • Credentialed Audits: Map IAM roles, Entra ID Conditional Access policies, and overly permissive network security groups.
  • Service Enumeration: Use tools like ScoutSuite, Pacu, and custom scripts to interrogate cloud APIs for weaknesses such as unsecured databases, DNS vulnerabilities, or GitHub token exposures.

Examples:

  • Identifying public Kubernetes pods with unprotected dashboards
  • Enumerating Azure AD app registrations with excessive Graph API permissions

Assumed Breach Scenarios & Lateral Movement๐Ÿ”—

Secureworks simulates post-compromise activities to evaluate how attackers might escalate privileges or pivot across hybrid and multi-cloud environments:

  • Credential Theft: Extract secrets from vaults (AWS Secrets Manager, Azure Key Vault) or environment variables.
  • Role Escalation: Abuse trust relationships (e.g., AWS AssumeRole, Azure Management Groups) to gain administrative access.
  • Hybrid Pivots: Use federated identities (e.g., Azure AD Connect) to move from cloud to on-premises systems.

Examples:

  • Using stolen GCP service account keys to bypass Organization Policy constraints
  • Exploiting misconfigured VPC peering to access restricted subnets

Exploitation & Privilege Escalation๐Ÿ”—

Leveraging enumerated vulnerabilities, Secureworks emulates adversarial exploitation techniques to demonstrate business impact:

  • IAM Abuse: Assume overly permissive roles to deploy backdoors (e.g., malicious Cloud Functions) or exfiltrate data.
  • Workflow Compromise: Attack CI/CD pipelines (e.g., GitHub Actions, Azure DevOps) to inject malicious code.
  • Serverless Exploits: Exploit insecure Lambda layers or Azure Functions for remote code execution.

Examples:

  • Exploiting AWS SSM Agent misconfigurations to execute arbitrary commands on EC2 instances
  • Bypassing GCP Identity-Aware Proxy (IAP) to access internal web apps

Remote Retest๐Ÿ”—

Secureworks will conduct one (1) remediation validation ("RV") for only the high- and critical-severity findings listed in the final report. After primary test completion, Customer has ninety (90) days in which to remediate issues, schedule the RV, and have Secureworks perform the RV. Customer must submit the RV request through email to the Secureworks point of contact for the assessment within thirty (30) days of delivery of the final report or the RV is forfeited.

For external penetration tests, findings discovered after pivoting and post-exploitation can be difficult to validate and are therefore not included in RV. For internal penetration tests, RV can only be performed if the original test used the Secureworks RTA.

Secureworks will issue a brief report summarizing the results of the RV, which will include information about whether Customer successfully remediated the issues.

Note

Secureworks only conducts RVs remotely, regardless of whether the assessment was conducted on-site.

Outcome๐Ÿ”—

Presentation of findings and deliverables compiled by Secureworks will be provided to you in the form of a report. The report will include the following:

  • Executive summary
  • Methods, detailed findings, narratives, and recommendations, if any
  • Attachments as needed for relevant details and supporting data

Customer shall have one (1) week from delivery of the report to provide comments to be included in the final report. If there are no comments received from Customer before the expiration of the review period, the report will be deemed final.

Upon completion of the Services, the Customer-designated contact will receive a secure/encrypted email confirmation from Secureworks. Unless otherwise notified in writing to the contrary by the Customer designated contact, within five (5) business days of such email confirmation, the Services and this SOW shall be deemed complete.

Scoping information๐Ÿ”—

Cloud Penetration Testing focuses on test objectives selected by the Customer.

Description Objective
Unauthenticated Attacker Reconnaissance 1 week
Assumed Breach - Compromised Developer Credentials 1 week
Assumed Breach - Compromised Low-Privileged Regular User 1 week
Assumed Breach - On-Premises to Cloud Lateral Movement 1 week
Assumed Breach - Cloud to On-Premises Lateral Movement 1 week
Azure - Compromised Service Principal of an Application 1 week
Azure - Conditional Access Testing 1 week
AWS - Compromised IAM Role 1 week
AWS - Cross-Account Access Testing 1 week

While we do perform some OSINT to find undocumented assets associated with the customer, no live testing of those systems will be performed without written approval. Any modifications to scope will be discussed and documented with Customer before proceeding, and may incur additional fees through a Change Order.

Cloud Penetration Testing relies on an objective-based methodology adhering to an artificially compressed timeline. Supplying additional information allows for efficient testing which can remain focused on impactful results. Providing a set of valid credentials for a specified test account allows Secureworks to perform more accurate testing, and to configure tooling for the most efficient testing possible.

Work is conducted during business hours of the Secureworks consultant. After-hours feature is available for an additional cost.

Scheduling and Booking Information๐Ÿ”—

See Service Scheduling for information about scheduling this service.