What it is
We build dedicated cloud accounts, subscriptions or projects that follow how your organization uses the cloud: identity setup, networking, workloads, storage and logging. Our operators run attacks in those accounts while your team detects and responds using cloud audit logs and your monitoring tools.
It suits cloud security teams, SOC analysts who handle cloud alerts, and platform engineers who own cloud configuration. Facilitated courses on the same topics are under cloud attack simulation training.
Scenarios
Leaked access keys
Keys exposed in a code repository are used to enumerate the account, create new users and read storage.
Privilege escalation through IAM
A low-privilege identity abuses role assumption or policy permissions to gain administrative access.
Federated identity takeover
An identity provider account, including one reset after a deepfake help desk call, is used to sign in to cloud consoles.
Storage exposure and exfiltration
Bucket or blob policies are changed to allow public or cross-account access, and data is copied out.
Workload compromise
A vulnerable container or virtual machine is used to reach instance metadata, take credentials and move into the control plane.
Defense evasion
Audit logging is disabled or altered, and guardrails are removed to hide activity.
How an exercise runs
We review your cloud architecture, identity model and logging, and choose scenarios that match the services you use. The brief names the accounts, permitted actions, budget limits and stop conditions.
We create isolated accounts with infrastructure as code, using test identities and synthetic data. Logging, alerting and the cloud security services you use are configured to match your production settings.
Our operators run the attack steps through the cloud APIs and consoles. Your team works the alerts, queries audit logs, and takes containment actions such as revoking keys and changing policies.
We compare the attack steps with the log entries and alerts they produced and the actions your team took. Afterward the accounts are reset from code or torn down.
What the range includes
Cloud accounts
Dedicated accounts, subscriptions or projects in AWS, Azure or Google Cloud, separate from your production organization.
Identity setup
Users, roles, groups and federation set up to match your identity model, using test identities only.
Logging and detection
AWS CloudTrail, Azure Activity Log or Google Cloud Audit Logs, with flow and workload logs, sent to your SIEM or to OpenSearch or Wazuh in the range.
Reset and cost control
Infrastructure as code for resets, budget alerts, and teardown after the exercise.
Deployment options
| Option | How it works | When it fits |
|---|---|---|
| Your cloud organization | We create range accounts in a separate organizational unit or tenant that you own, with no trust to production. | You want the range under your billing and governance, or need your own cloud security services in scope. |
| Hosted by DeployOpen | We run the accounts in our cloud organization and give your team access. | You want to start without setting up accounts, or you run exercises a few times a year. |
| Hybrid with on-premises identity | Range cloud accounts connect to an on-premises directory that is also built in the range. | Your cloud access depends on Active Directory or another on-premises identity provider. |
Identity and control-plane focus
The scenarios center on identity and the cloud management API. Your team works from audit logs to establish which identity called which API, from where, with which role, and what changed.
Workload and network scenarios are included where they lead into the control plane, for example a compromised workload that reads credentials from instance metadata. Steps are mapped to the cloud techniques in MITRE ATT&CK.
What you receive
Each exercise ends with a debrief for the security and platform teams. Written findings follow.
Debrief session
- Attack timeline against audit log entries and alerts
- Review of containment decisions
- Observations from security and platform staff
Detection findings
- API calls that raised alerts and those that did not
- Audit log settings or log sources that were missing
- Rules to add or tune
Response findings
- Order and timing of key revocation and policy changes
- Persistence left after containment
- Coordination between security and platform teams
Improvements
- Configuration and guardrail changes for your accounts
- Scenario code kept for reruns
- Option to rerun after changes
Questions
Does this touch our production cloud accounts?
No. The range uses separate accounts with no trust relationships to production. Attack activity stays in range accounts and follows each provider's policy on security testing.
Which cloud providers do you cover?
AWS, Azure and Google Cloud. Scenarios can span more than one provider where your environment does.
How close is the range to our cloud setup?
We follow your account structure, identity model, logging and the services you use, as far as the scenarios need. The brief records any differences.
Who pays for cloud usage?
In your cloud organization, resources bill to your accounts, with budget alerts set during build. For a hosted range, usage is included in the fixed-scope engagement.
Can we rerun scenarios?
Yes. Each scenario is kept in a library for your range, with its configuration and scoring sheet. You can rerun it with a new group, or after changing a rule or procedure to compare results.
How is data handled?
Range data, recordings and findings stay in the deployment you choose. We agree retention and deletion rules before the first session and sign an NDA on request. Synthetic data is the default, and production data is used only with your written approval.
How to prepare
Share an outline of your cloud organization: accounts, identity provider, main services, and where logs are sent. If the range will sit in your organization, name a cloud administrator who can approve the new accounts.
Choose the scenarios closest to the services you run, and confirm who will respond: SOC, cloud security, platform engineering, or all three.
