Find the path between cloud configuration and material access.
Across AWS, Microsoft Azure and Google Cloud Platform, a cloud condition matters because of what it connects: an identity to a role, a workload to a secret, an exposed service to a control plane, or one environment to another. The assessment combines configuration review with attack-path analysis and controlled validation.
SCOPE → DISCOVER → TEST → VALIDATE → REPORT → RETEST
ASSESSMENT BOUNDARY
What is being assessed?
The engagement boundary is defined by systems, identities, workflows and restrictions—not only a list of URLs or assets.
- AWS, Microsoft Azure and GCP environments in scope
- IAM, privileged roles, service identities and trust relationships
- Externally exposed resources, services and workloads
- Storage, secrets and credential-exposure paths
- Network controls and administrative interfaces
- Logging, monitoring and security configuration
- Cloud-to-enterprise attack paths where scoped
What Botnet tests.
Testing is manual-led and supported by appropriate tooling. Findings are manually validated before reporting. Coverage follows reachable trust decisions and agreed risk; source-code review is not implied unless explicitly scoped.
Identity paths
Roles, trust relationships, excessive permissions and reachable escalation conditions.
Exposure
Public resources, administrative surfaces and routes from internet-facing workloads.
Data access
Storage policy, workload access and unintended paths to sensitive resources.
Network control
Segmentation, service-to-service reachability and management-plane boundaries.
Secrets
How credentials and secrets are exposed to identities, workloads or deployment processes.
Visibility
Whether agreed actions are represented in available logging and security controls.
How the work progresses.
- 01
Boundary
Confirm provider, accounts/projects, access level, production restrictions and excluded services.
- 02
Inventory
Establish an in-scope view of identities, exposed assets and relevant relationships.
- 03
Analyze
Review configuration and construct plausible privilege and access paths.
- 04
Validate
Safely test selected paths within authorization and change-control constraints.
- 05
Contextualize
Relate conditions to affected systems, data and existing controls.
- 06
Report
Deliver prioritized evidence and remediation actions with provider context.
EVIDENCE + ACTION
What the customer receives.
- Cloud scope and trust-boundary summary
- Identity and exposure attack-path findings
- Evidence with affected resources and permissions
- Severity/risk context and prioritized remediation guidance
- Testing limitations and unvalidated paths
- Technical readout and one re-test result for agreed remediated findings
Evidence over assumption.
01Attack-path analysis across identities and resources
02Explicit distinction between configuration observation and validated reachability
03Production-aware safeguards
04Evidence designed for cloud and security owners to act on
Before scoping.
Which cloud providers are supported?
Botnet Security supports AWS, Microsoft Azure and Google Cloud Platform. The exact accounts, projects, subscriptions and services are confirmed during scoping.
Is this a configuration review or penetration test?
The engagement mode can include authenticated review, controlled offensive validation, or both, depending on scope and authorization.
What access is required?
Access depends on the agreed mode. Least-privilege read access may support review; validation actions require separately agreed permissions and safeguards.
Define the target, constraints and required evidence.
An assessment request starts a scoping conversation. It does not authorize testing. Work proceeds only after scope acceptance, executed authorization/SOW and kickoff.