Lab 02 — Azure Storage Assessment

Mission Information

Field	Details
Career Path	Cloud Penetration Tester
Module	Azure Cloud Penetration Testing
Difficulty	Intermediate
Estimated Time	120–150 Minutes
Lab Type	Cloud Storage Security Assessment
Environment	Authorised Azure Lab Subscription
Primary Tools	Azure CLI, Azure PowerShell, Azure Portal
Output	Azure Storage Assessment Report
Cost	Azure Free Tier or Existing Lab Subscription

Mission Brief

You are working as a Cloud Penetration Tester for CloudNova Technologies.

The organisation has been engaged to assess the Azure Storage environment of Northstar Digital Services.

Northstar uses Azure Storage for:

Customer documents
Application data
Static website content
Database exports
Backup files
Security logs
Deployment packages
Virtual Machine diagnostics
Departmental file shares
Event-driven application workflows

The customer is concerned that rapid cloud adoption may have created:

Publicly accessible containers
Excessive Azure RBAC permissions
Weak Shared Access Signatures
Poor storage-key governance
Inadequate network restrictions
Missing data-protection controls
Incomplete logging
Cross-environment access paths

Your task is to perform a structured and non-destructive Azure Storage assessment.

You must identify security weaknesses without unnecessarily opening, downloading, modifying, or deleting customer data.

Mission Objectives

By completing this lab, you will:

Confirm the authorised Azure subscription and assessment scope.
Inventory Azure Storage Accounts.
Identify enabled storage services.
Review Azure RBAC assignments.
Distinguish management-plane and data-plane permissions.
Assess Blob container public-access settings.
Review Azure Files configuration.
Assess Storage Account network controls.
Review private endpoints and public-network access.
Evaluate access-key and Shared Access Signature governance.
Review encryption and secure-transfer settings.
Assess soft delete, versioning, and recovery controls.
Review diagnostic logging and Defender coverage.
Build storage-related attack paths.
Produce an enterprise-style Azure Storage assessment report.

Business Outcomes

This assessment helps the organisation answer:

Which Storage Accounts exist?
What business data do they support?
Are any containers publicly accessible?
Which users, groups, applications, and managed identities can access storage data?
Are access keys and Shared Access Signatures governed securely?
Are sensitive accounts accessible from the public internet?
Are private endpoints implemented correctly?
Can deleted or modified data be recovered?
Is suspicious storage activity logged and monitored?
Could a storage weakness lead to application or Azure compromise?

Prerequisites

Before beginning this lab, complete:

Lesson 01 — Azure Offensive Security Foundations
Lesson 03 — Azure RBAC Exploitation
Lesson 04 — Azure Network Enumeration
Lesson 06 — Azure Storage Security
Lab 01 — Microsoft Entra ID Assessment

You should understand:

Azure Storage Accounts
Blob containers
Azure Files
Management-plane permissions
Data-plane permissions
Azure RBAC
Storage Account keys
Shared Access Signatures
Private endpoints
Diagnostic settings
Rules of Engagement

Required Access

Use a dedicated lab identity with read-only access wherever possible.

Recommended access may include:

Reader
Storage Account Contributor for configuration review where approved
Storage Blob Data Reader for authorised test containers
Monitoring Reader
Security Reader

The exact information visible will depend on your assigned permissions.

Do not attempt to bypass missing permissions.

Rules of Engagement

You are authorised to:

Enumerate authorised Storage Accounts.
Review Storage Account configuration.
Review Azure RBAC assignments.
Review public-access settings.
List authorised containers and file shares.
Review network rules.
Review private endpoint configuration.
Review data-protection settings.
Review diagnostic settings.
Access metadata for authorised test objects.
Validate access using a dedicated test container and non-sensitive test object.
Create sanitised assessment evidence.

You are not authorised to:

Retrieve production access keys.
Regenerate Storage Account keys.
Generate production SAS tokens.
Download customer files.
Upload executable or malicious content.
Modify application data.
Delete blobs, files, queues, or tables.
Change container public-access levels.
Modify firewall rules.
Disable public-network access.
Create or remove private endpoints.
Disable logging.
Change encryption keys.
Modify immutability policies.
Alter lifecycle-management rules.
Perform denial-of-service or high-volume operations.

Stop immediately if sensitive customer information becomes unexpectedly accessible.

Lab Architecture

Authorised Test Identity
          │
          ▼
Azure Subscription
          │
          ├── Storage Account 01
          │     ├── Blob Containers
          │     ├── File Shares
          │     ├── Queues
          │     └── Tables
          │
          ├── Storage Account 02
          │     ├── Private Endpoint
          │     └── Application Data
          │
          └── Connected Identities
                ├── Users
                ├── Groups
                ├── Service Principals
                └── Managed Identities

Expected Deliverables

Create the following assessment package:

Azure Storage Assessment
│
├── 01 Engagement Context
├── 02 Storage Account Inventory
├── 03 Service Inventory
├── 04 Azure RBAC Review
├── 05 Public Access Review
├── 06 Blob Container Review
├── 07 Azure Files Review
├── 08 Access Key and SAS Governance
├── 09 Network Security Review
├── 10 Encryption and Transport Review
├── 11 Data Protection Review
├── 12 Monitoring Review
├── 13 Storage Attack Paths
├── 14 Findings
├── 15 Recommendations
└── 16 Evidence

Part 1 — Prepare the Assessment Environment

Task 1.1 — Verify Azure CLI

Run:

az version

Record:

Azure CLI version:
Operating system:
Assessment date:
Tester:

Task 1.2 — Authenticate

az login

Where device-code authentication is required:

az login --use-device-code

Task 1.3 — Confirm the Azure Context

Run:

az account show --output table

Record:

Tenant ID
Subscription ID
Subscription name
Signed-in identity
Subscription state

Store the active subscription ID:

SUBSCRIPTION_ID=$(az account show --query id -o tsv)

Confirm that the subscription is included in the Rules of Engagement.

Task 1.4 — Confirm Resource-Group Scope

List visible resource groups:

az group list --output table

Create an authorised scope table:

Resource Group	Environment	Business Owner	In Scope	Notes

Validation Checkpoint

Confirm:

The correct tenant is active.
The correct subscription is selected.
The test identity is authorised.
The approved resource groups are known.
No out-of-scope Storage Account will be queried.

Part 2 — Build the Storage Account Inventory

Task 2.1 — List Storage Accounts

Run:

az storage account list \
  --query "[].{Name:name,ResourceGroup:resourceGroup,Location:primaryLocation,Kind:kind,Sku:sku.name,PublicNetworkAccess:publicNetworkAccess}" \
  --output table

Export the authorised inventory:

az storage account list \
  --output json > azure-storage-accounts.json

Protect the exported file.

Task 2.2 — Create the Storage Inventory

Create a table:

Storage Account	Resource Group	Region	Account Type	Replication	Environment	Business Purpose

Classify each Storage Account as:

Production
Development
Testing
Shared services
Security logging
Backup
Unknown

Task 2.3 — Review a Specific Storage Account

Run:

az storage account show \
  --resource-group "<authorised-resource-group>" \
  --name "<authorised-storage-account>"

Review:

Account kind
SKU
Replication
Public-network access
Secure-transfer requirement
Minimum TLS version
Blob public-access setting
Shared-key access setting
Network default action
Encryption configuration
Hierarchical namespace
Infrastructure encryption
Private endpoint connections

Assessment Questions

Is the business owner known?
Is the environment classification documented?
Is replication appropriate for the workload?
Is public-network access required?
Is shared-key access still needed?
Does the account contain sensitive or regulated data?
Is the account connected to production applications?

Part 3 — Identify Storage Services

Task 3.1 — Review Blob Service Properties

Run:

az storage account blob-service-properties show \
  --resource-group "<authorised-resource-group>" \
  --account-name "<authorised-storage-account>"

Review:

Delete retention
Container delete retention
Versioning
Change feed
Restore policy
Last-access tracking

Task 3.2 — List Authorised Blob Containers

Use Microsoft Entra authentication:

az storage container list \
  --account-name "<authorised-storage-account>" \
  --auth-mode login \
  --query "[].{Name:name,PublicAccess:properties.publicAccess,LastModified:properties.lastModified}" \
  --output table

Do not use an account key unless explicitly authorised.

Task 3.3 — List Azure File Shares

Run:

az storage share-rm list \
  --resource-group "<authorised-resource-group>" \
  --storage-account "<authorised-storage-account>" \
  --output table

Task 3.4 — Record Services in Use

Create a service inventory:

Storage Account	Blob	Files	Queues	Tables	Data Lake	Static Website	Business Use

Validation Checkpoint

You should now understand:

Which Storage Accounts exist.
Which storage services are active.
Which accounts support applications, backups, or logging.
Which services require deeper assessment.

Part 4 — Review Azure RBAC

Task 4.1 — Capture the Storage Resource ID

Run:

STORAGE_ID=$(az storage account show \
  --resource-group "<authorised-resource-group>" \
  --name "<authorised-storage-account>" \
  --query id \
  --output tsv)

Task 4.2 — List Role Assignments

Run:

az role assignment list \
  --scope "$STORAGE_ID" \
  --include-inherited \
  --query "[].{PrincipalName:principalName,PrincipalType:principalType,Role:roleDefinitionName,Scope:scope}" \
  --output table

Task 4.3 — Identify Sensitive Storage Roles

Prioritise:

Owner
Contributor
Storage Account Contributor
User Access Administrator
Storage Blob Data Owner
Storage Blob Data Contributor
Storage Blob Data Reader
Storage File Data SMB Share Contributor
Storage Queue Data Contributor
Custom roles

Task 4.4 — Separate Management and Data Access

Create a permissions matrix:

Identity	Identity Type	Role	Management Plane	Data Plane	Scope	Observation

Assessment Questions

Are broad data roles assigned at subscription scope?
Do development identities access production storage?
Do guest users have storage roles?
Are service principals overprivileged?
Are managed identities scoped to only required accounts?
Can management-plane users retrieve account keys?
Are assignments inherited from a broad parent scope?

Part 5 — Review Public Blob Access

Task 5.1 — Check Account-Level Blob Public Access

Run:

az storage account show \
  --resource-group "<authorised-resource-group>" \
  --name "<authorised-storage-account>" \
  --query "{AllowBlobPublicAccess:allowBlobPublicAccess,PublicNetworkAccess:publicNetworkAccess}"

Task 5.2 — Review Container Access Levels

Run:

az storage container list \
  --account-name "<authorised-storage-account>" \
  --auth-mode login \
  --query "[].{Name:name,PublicAccess:properties.publicAccess}" \
  --output table

Potential values may indicate:

Private
Blob-level public access
Container-level public access

Task 5.3 — Classify Public Containers

Create a table:

Container	Access Level	Data Classification	Business Justification	Risk	Action

Task 5.4 — Validate Safely

Where public-access validation is explicitly authorised:

Select a dedicated non-sensitive test object.
Confirm its exact URL.
Use a browser or low-impact request.
Record only the response status.
Do not enumerate or download unrelated objects.
Stop if sensitive data becomes visible.

Example:

curl -I "https://<storage-account>.blob.core.windows.net/<authorised-container>/<test-object>"

Do not perform bulk anonymous enumeration.

Assessment Questions

Is public access intentional?
Is container listing enabled?
Is sensitive content present?
Are backup or configuration files exposed?
Are public containers monitored?
Is public access documented and approved?

Part 6 — Review Blob Data Exposure

Task 6.1 — List Objects in an Authorised Test Container

Run:

az storage blob list \
  --account-name "<authorised-storage-account>" \
  --container-name "<authorised-test-container>" \
  --auth-mode login \
  --query "[].{Name:name,Size:properties.contentLength,LastModified:properties.lastModified,BlobType:properties.blobType}" \
  --output table

Do not open or download production blobs unless explicitly authorised.

Task 6.2 — Review Object Naming

Look for names suggesting:

Backups
Database exports
Credentials
Configuration
Deployment artefacts
Source code
Security logs
Customer records
Certificates
Temporary files

Object names alone are not proof of sensitive content.

Task 6.3 — Review Metadata Only

For an authorised test object:

az storage blob show \
  --account-name "<authorised-storage-account>" \
  --container-name "<authorised-test-container>" \
  --name "<authorised-test-object>" \
  --auth-mode login

Record:

Object name
Size
Content type
Last modified
Encryption scope
Metadata
Version information

Part 7 — Review Azure Files

Task 7.1 — Inventory File Shares

Run:

az storage share-rm list \
  --resource-group "<authorised-resource-group>" \
  --storage-account "<authorised-storage-account>" \
  --query "[].{Name:name,Quota:shareQuota,EnabledProtocols:enabledProtocols,AccessTier:accessTier}" \
  --output table

Task 7.2 — Review Authentication Model

Identify whether Azure Files uses:

Storage Account keys
Microsoft Entra Kerberos
Active Directory Domain Services
Microsoft Entra Domain Services
NFS authentication
Private access

Task 7.3 — Review Network Exposure

Assess:

Public-network access
Private endpoints
Storage firewall
SMB reachability
NFS reachability
VNet integration
On-premises connectivity

Azure Files Review Table

File Share	Protocol	Authentication	Network Path	Data Sensitivity	Backup	Observation

Assessment Questions

Are Storage Account keys still used broadly?
Are file shares reachable from unnecessary networks?
Are share permissions reviewed?
Are snapshots and backups protected?
Are development and production shares separated?
Are SMB and NFS configurations appropriate?

Part 8 — Assess Access Key Governance

Important Safety Note

Storage Account keys are highly sensitive.

Do not retrieve them during this lab unless the Rules of Engagement explicitly authorise controlled key validation.

Task 8.1 — Review Shared-Key Configuration

Run:

az storage account show \
  --resource-group "<authorised-resource-group>" \
  --name "<authorised-storage-account>" \
  --query "{AllowSharedKeyAccess:allowSharedKeyAccess,DefaultToOAuthAuthentication:defaultToOAuthAuthentication}"

Task 8.2 — Review Business Usage

Document:

Which applications use account keys?
Where are keys stored?
Who can retrieve keys?
How frequently are keys rotated?
Are both keys actively used?
Is migration to Microsoft Entra authentication planned?

Access Key Governance Table

Storage Account	Shared Key Enabled	Known Consumers	Rotation Frequency	Key Owner	Risk

Assessment Questions

Is shared-key access required?
Can Microsoft Entra authentication replace it?
Are key-retrieval permissions restricted?
Are keys stored in Key Vault?
Are keys embedded in code or scripts?
Are emergency rotation procedures tested?

Part 9 — Assess Shared Access Signatures

Important Safety Note

Existing SAS tokens may not be centrally discoverable depending on how they were created.

Do not create production SAS tokens during this lab.

Task 9.1 — Review SAS Governance

Document organisational controls for:

SAS creation
SAS approval
Maximum lifetime
Allowed permissions
IP restrictions
HTTPS enforcement
Stored access policies
Revocation
Logging
Ownership

Task 9.2 — Review an Authorised Test SAS

Where a dedicated test SAS has been supplied, record:

Resource scope
Service
Permissions
Start time
Expiration time
Allowed IP range
Protocol
Stored access policy

Redact the signature value.

SAS Assessment Table

SAS Purpose	Resource	Permissions	Expiry	IP Restricted	HTTPS Only	Owner	Risk

Risk Indicators

Look for:

Long expiration
Read, write, and delete combined
Account-level scope
No IP restriction
HTTP allowed
Use in URLs or logs
No documented owner
No revocation plan
Production and development sharing the same token

Part 10 — Review Network Security

Task 10.1 — Display Network Rules

Run:

az storage account network-rule list \
  --resource-group "<authorised-resource-group>" \
  --account-name "<authorised-storage-account>"

Review:

Default action
IP rules
Virtual Network rules
Resource-instance rules
Bypass settings

Task 10.2 — Review Public-Network Access

Run:

az storage account show \
  --resource-group "<authorised-resource-group>" \
  --name "<authorised-storage-account>" \
  --query "{PublicNetworkAccess:publicNetworkAccess,DefaultAction:networkRuleSet.defaultAction,Bypass:networkRuleSet.bypass}"

Task 10.3 — Review Private Endpoints

List private endpoints:

az network private-endpoint list \
  --query "[].{Name:name,ResourceGroup:resourceGroup,Subnet:subnet.id,PrivateLinkServiceConnections:privateLinkServiceConnections}" \
  --output table

Identify endpoints connected to the authorised Storage Account.

Task 10.4 — Review Private DNS

Where authorised, review:

Private DNS zone
VNet links
Storage service records
Name resolution from connected VNets
Custom DNS forwarding

Network Review Table

Storage Account	Public Access	Default Action	IP Rules	VNet Rules	Private Endpoint	Trusted Services	Risk

Assessment Questions

Is public access required?
Does a private endpoint exist while public access remains enabled?
Are IP ranges overly broad?
Are trusted-service exceptions justified?
Are all required storage subresources covered?
Is private DNS configured correctly?
Can development networks reach production storage?

Part 11 — Review Transport and Encryption

Task 11.1 — Review Secure Transfer

Run:

az storage account show \
  --resource-group "<authorised-resource-group>" \
  --name "<authorised-storage-account>" \
  --query "{SecureTransferRequired:enableHttpsTrafficOnly,MinimumTlsVersion:minimumTlsVersion}"

Task 11.2 — Review Encryption

Run:

az storage account show \
  --resource-group "<authorised-resource-group>" \
  --name "<authorised-storage-account>" \
  --query encryption

Review:

Microsoft-managed keys
Customer-managed keys
Encryption services
Infrastructure encryption
Key source
Key Vault relationship

Encryption Review Table

Storage Account	HTTPS Required	Minimum TLS	Key Type	Key Vault	Infrastructure Encryption	Observation

Assessment Questions

Is secure transfer mandatory?
Is the minimum TLS version appropriate?
Are customer-managed keys required?
Is Key Vault access least privileged?
Are keys rotated?
Are recovery protections enabled?
Could key loss affect service availability?

Part 12 — Review Data Protection

Task 12.1 — Review Soft Delete

Run:

az storage account blob-service-properties show \
  --resource-group "<authorised-resource-group>" \
  --account-name "<authorised-storage-account>" \
  --query "{BlobDeleteRetention:deleteRetentionPolicy,ContainerDeleteRetention:containerDeleteRetentionPolicy}"

Task 12.2 — Review Versioning

Run:

az storage account blob-service-properties show \
  --resource-group "<authorised-resource-group>" \
  --account-name "<authorised-storage-account>" \
  --query "{Versioning:isVersioningEnabled,ChangeFeed:changeFeed,RestorePolicy:restorePolicy}"

Review:

Soft delete
Share snapshots
Backup
Retention
Restore testing

Task 12.4 — Review Immutability

Where applicable, review:

Time-based retention
Legal hold
Protected containers
Administrative permissions
Business requirements

Data Protection Table

Storage Account	Blob Soft Delete	Container Soft Delete	Versioning	Backup	Immutability	Recovery Tested

Assessment Questions

Can deleted data be recovered?
Are retention periods appropriate?
Are critical logs or backups immutable?
Are versioning costs and lifecycle rules governed?
Are restore procedures tested?
Can one identity both delete data and weaken recovery controls?

Part 13 — Review Lifecycle Management

Task 13.1 — Review Lifecycle Policies

Run:

az storage account management-policy show \
  --resource-group "<authorised-resource-group>" \
  --account-name "<authorised-storage-account>"

If no policy exists, document that result.

Task 13.2 — Assess Rules

Review:

Tiering actions
Delete actions
Version handling
Snapshot handling
Prefix filters
Blob-type filters
Retention periods

Assessment Questions

Could data be deleted prematurely?
Are old versions retained too long?
Are critical logs protected?
Are policies reviewed through change management?
Is the business owner aware of retention behaviour?

Part 14 — Review Monitoring and Logging

Task 14.1 — Review Diagnostic Categories

Capture the Storage Account resource ID:

STORAGE_ID=$(az storage account show \
  --resource-group "<authorised-resource-group>" \
  --name "<authorised-storage-account>" \
  --query id \
  --output tsv)

List diagnostic categories:

az monitor diagnostic-settings categories list \
  --resource "$STORAGE_ID" \
  --output table

Task 14.2 — Review Diagnostic Settings

Run:

az monitor diagnostic-settings list \
  --resource "$STORAGE_ID" \
  --output json

Review:

Enabled logs
Enabled metrics
Destination workspace
Storage destination
Event Hub destination
Retention approach

Task 14.3 — Review Microsoft Defender for Storage

Using the Azure Portal or approved tooling, determine:

Whether Defender for Storage is enabled
Which accounts are covered
Whether malware scanning is enabled where required
Whether alerts reach the SOC
Whether exceptions are documented

Monitoring Review Table

Storage Account	Diagnostic Settings	Read Logs	Write Logs	Delete Logs	Defender	SIEM Destination	Gap

Expected Detection Activities

The organisation should be able to identify:

Anonymous access
Unusual blob downloads
High-volume reads
Unexpected writes
Blob deletion
SAS-based access
Access from unusual IP addresses
Public-access configuration changes
Firewall changes
Key regeneration
Diagnostic-setting removal

Part 15 — Build Storage Attack Paths

Create at least three evidence-supported attack paths.

Do not perform destructive validation.

Attack Path 1 — Public Container Exposure

Internet
    ↓
Public Blob container
    ↓
Configuration backup discovered
    ↓
Application credential exposed
    ↓
Connected Azure service accessed

Attack Path 2 — Managed Identity to Storage

Compromised Azure Function
        ↓
Managed identity
        ↓
Storage Blob Data Contributor
        ↓
Production object modification
        ↓
Application impact

Attack Path 3 — Management Permission to Data Access

Storage management permission
        ↓
Ability to retrieve account key
        ↓
Shared-key authentication
        ↓
Broad data-plane access

Attack Path 4 — Storage Artefact Modification

Storage write access
        ↓
Deployment package modified
        ↓
Trusted workload deploys package
        ↓
Code executes under managed identity

Attack-Path Evidence Table

Step	Identity or Resource	Permission or Weakness	Evidence	Expected Detection

Every relationship should be supported by:

Role assignment
Configuration
Container setting
Network rule
Resource relationship
Application dependency
Monitoring evidence

Part 16 — Create Findings

Use the following structure.

Finding Title

Describe the affected resource and risk.

Severity

Use the approved risk methodology.

Affected Resource

Document:

Subscription
Resource group
Storage Account
Container or file share
Identity
Role
Scope

Observation

Explain what was identified.

Evidence

Include:

Sanitised command output
Public-access setting
Role assignment
Network configuration
Data-protection status
Monitoring configuration

Attack Path

Starting point
        ↓
Storage weakness
        ↓
Data or credential access
        ↓
Connected resource
        ↓
Business impact

Recommendation

Provide:

Immediate mitigation
Near-term control
Strategic improvement
Retest requirement

Example Finding 1

Finding Title

Production Blob Container Permits Anonymous Public Access

Observation

A Blob container used for operational backups permits anonymous Blob access.

Object names indicate that the container may contain application configuration and historical export files.

No business justification for public access was identified.

Potential Attack Path

Internet
    ↓
Public Blob URL
    ↓
Backup object accessed
    ↓
Configuration or credential exposure
    ↓
Connected application compromise

Business Impact

An external attacker may access sensitive operational files without authentication.

The exposed content could support additional attacks against Azure applications and business systems.

Recommendation

Disable anonymous container access.
Review all objects for sensitive information.
Rotate credentials that may have been exposed.
Disable account-level public Blob access where not required.
Review similar containers.
Enable storage access logging.
Alert on anonymous requests.
Validate remediation through an authorised external check.

Example Finding 2

Finding Title

Development Managed Identity Can Modify Production Blob Data

Observation

A managed identity attached to a development Function App has Storage Blob Data Contributor access to a production Storage Account.

Potential Attack Path

Development Function compromised
        ↓
Managed identity
        ↓
Production Blob write permission
        ↓
Application data or deployment artefact modified

Business Impact

Compromise of a lower-trust development workload could affect the integrity of production application data.

Recommendation

Separate development and production identities.
Remove production Storage access.
Reduce permissions to read-only where appropriate.
Scope access to only the required container.
Monitor managed-identity storage operations.
Review every workload using the identity.
Validate production and development separation.

Example Finding 3

Finding Title

Long-Lived Shared Access Signature Provides Excessive Storage Permissions

Observation

An authorised test SAS used by an external integration provides read, write, and delete permissions for twelve months without an IP restriction.

Business Impact

Exposure of the SAS could permit long-term external access and allow data theft, modification, or deletion.

Recommendation

Replace the SAS with Microsoft Entra authentication where possible.
Prefer user-delegation SAS.
Reduce permissions.
Shorten the validity period.
Restrict source IP addresses.
Require HTTPS.
Implement revocation procedures.
Monitor SAS-based access.

Part 17 — Create the Final Assessment Report

Your report should include the following sections.

1. Executive Summary

Explain:

Overall Azure Storage risk posture
Most important weakness
Business impact
Immediate priorities

2. Scope

Document:

Tenant
Subscription
Resource groups
Storage Accounts
Included services
Exclusions
Assessment date

3. Methodology

Describe:

Read-only enumeration
Role review
Public-access assessment
Network assessment
Data-protection review
Monitoring review
Attack-path analysis

4. Storage Inventory

Include:

Account
Environment
Business owner
Services
Data classification
Public exposure

5. Access Review

Include:

Users
Groups
Service principals
Managed identities
Management roles
Data-plane roles
Assignment scopes

6. Exposure Review

Include:

Public containers
Public-network access
Shared-key usage
SAS usage
Private endpoints
Trusted-service exceptions

7. Data Protection

Include:

Encryption
Soft delete
Versioning
Backup
Immutability
Lifecycle management

8. Monitoring Review

Include:

Diagnostic settings
Log destination
Defender coverage
Detection gaps
Retention

9. Attack Paths

Document at least three storage-related attack paths.

10. Recommendations

Organise remediation into:

Immediate — 0 to 7 Days

Remove unauthorised public access.
Revoke exposed SAS tokens.
Rotate exposed keys or credentials.
Remove unnecessary production access.
Enable logging for critical accounts.

Near Term — 8 to 30 Days

Replace shared-key access with Microsoft Entra authentication.
Introduce private endpoints.
Apply container-level least privilege.
Enable soft delete and versioning.
Improve Defender and SIEM integration.

Strategic — 31 to 90 Days

Establish enterprise storage governance.
Automate access reviews.
Standardise network restrictions.
Implement credential-lifecycle controls.
Introduce continuous public-exposure monitoring.
Standardise data classification and retention.

Validation Checklist

Before completing the lab, confirm:

Troubleshooting

Storage Container Listing Returns Authorisation Failure

Cause:

The test identity lacks a data-plane role.

Action:

Confirm the assigned Azure RBAC role.
Request authorised Storage Blob Data Reader access.
Do not use an account key as a workaround.
Document the limitation.

Storage Account Is Visible but Data Is Not

This is expected when the identity has management-plane Reader access but no data-plane permission.

Document the difference between:

Resource visibility
Data access

Network Rule Output Appears Empty

Cause:

All networks may be allowed.
No explicit rules may exist.
The account may use private endpoints only.
Permissions may be insufficient.

Review:

az storage account show \
  --resource-group "<authorised-resource-group>" \
  --name "<authorised-storage-account>" \
  --query networkRuleSet

SAS Tokens Cannot Be Listed

This may be expected.

Ad hoc SAS tokens are credentials and may not be centrally inventoried.

Assess:

Policy
Known integrations
Stored access policies
Logs
Application configuration

Do not attempt to discover tokens through unauthorised sources.

Blob Public Access Validation Fails

Possible causes:

Account-level public access disabled
Container is private
Incorrect object URL
Network restriction
Object does not exist

Do not change settings to force access.

Diagnostic Settings Are Missing

Record:

Affected Storage Account
Expected log categories
Missing destination
Detection impact
Recommended configuration

Do not create diagnostic settings unless explicitly authorised.

Cleanup

This lab is primarily read-only.

Cleanup activities include:

Remove any approved test object created for validation.
Delete temporary local exports when no longer required.
Store evidence in the approved encrypted location.
Redact account names, object names, IP ranges, and identifiers from portfolio material.
Sign out of Azure CLI:

az logout

Confirm that no keys, SAS tokens, public-access settings, network rules, or data objects were modified.

Portfolio Evidence

Create a sanitised portfolio entry containing:

Lab objective
Storage architecture diagram
Storage Account inventory template
Azure RBAC matrix
Public-access review
Network-control review
Data-protection matrix
Monitoring review
Three sanitised attack-path diagrams
Example finding
Remediation roadmap
Lessons learned

Do not publish:

Real Storage Account names
Container names
Customer data
Tenant or subscription identifiers
Access keys
SAS tokens
Internal IP ranges
Private endpoint details
Sensitive filenames

Learning Outcomes

After completing this lab, you should be able to:

Perform a structured Azure Storage assessment.
Inventory Storage Accounts and services.
Distinguish management-plane and data-plane permissions.
Assess Azure RBAC for users and workloads.
Identify public Blob exposure.
Review Azure Files security.
Evaluate access-key and SAS governance.
Assess public and private network paths.
Review encryption and transport security.
Evaluate recovery and data-protection controls.
Assess logging and Defender coverage.
Build realistic storage attack paths.
Produce an enterprise-quality assessment report.

Knowledge Review

What is the difference between management-plane and data-plane access?
Why are Storage Account keys highly sensitive?
What is the purpose of a Shared Access Signature?
Why should SAS permissions and lifetime be minimised?
What is the difference between Blob-level and container-level public access?
Why does a private endpoint not automatically disable public access?
How can a managed identity create a cross-environment storage attack path?
Why can Storage write access lead to code execution?
Which controls reduce the impact of deletion or ransomware?
Why should diagnostic settings be assessed?
What is the safest way to validate anonymous storage access?
Why may configuration evidence be sufficient without opening customer files?

Mission Complete

You have completed Lab 02 — Azure Storage Assessment.

You have:

Inventoried Azure Storage Accounts
Reviewed storage services
Assessed Azure RBAC permissions
Evaluated public Blob access
Reviewed Azure Files
Assessed access-key and SAS governance
Reviewed network controls
Evaluated encryption and transport security
Assessed recovery controls
Reviewed monitoring coverage
Built storage-related attack paths
Prepared an enterprise assessment report

Next Lab

➡️ Lab 03 — Azure VM Exploitation

In the next lab, you will perform an authorised Azure Virtual Machine assessment covering public exposure, Network Security Groups, authentication, administrative access, VM extensions, managed identities, disks, monitoring, controlled exploitation, and Azure VM attack paths.

Lab 02 — Azure Storage Assessment

Mission Information

Mission Brief

Mission Objectives

Business Outcomes

Prerequisites

Required Access

Rules of Engagement

Lab Architecture

Expected Deliverables

Part 1 — Prepare the Assessment Environment

Task 1.1 — Verify Azure CLI

Task 1.2 — Authenticate

Task 1.3 — Confirm the Azure Context

Task 1.4 — Confirm Resource-Group Scope

Validation Checkpoint

Part 2 — Build the Storage Account Inventory

Task 2.1 — List Storage Accounts

Task 2.2 — Create the Storage Inventory

Task 2.3 — Review a Specific Storage Account

Assessment Questions

Part 3 — Identify Storage Services

Task 3.1 — Review Blob Service Properties

Task 3.2 — List Authorised Blob Containers

Task 3.3 — List Azure File Shares

Task 3.4 — Record Services in Use

Validation Checkpoint

Part 4 — Review Azure RBAC

Task 4.1 — Capture the Storage Resource ID

Task 4.2 — List Role Assignments

Task 4.3 — Identify Sensitive Storage Roles

Task 4.4 — Separate Management and Data Access

Assessment Questions

Part 5 — Review Public Blob Access

Task 5.1 — Check Account-Level Blob Public Access

Task 5.2 — Review Container Access Levels

Task 5.3 — Classify Public Containers

Task 5.4 — Validate Safely

Assessment Questions

Part 6 — Review Blob Data Exposure

Task 6.1 — List Objects in an Authorised Test Container

Task 6.2 — Review Object Naming

Task 6.3 — Review Metadata Only

Part 7 — Review Azure Files

Task 7.1 — Inventory File Shares

Task 7.2 — Review Authentication Model

Task 7.3 — Review Network Exposure

Azure Files Review Table

Assessment Questions

Part 8 — Assess Access Key Governance

Important Safety Note

Task 8.1 — Review Shared-Key Configuration

Task 8.2 — Review Business Usage

Access Key Governance Table

Assessment Questions

Part 9 — Assess Shared Access Signatures

Important Safety Note

Task 9.1 — Review SAS Governance

Task 9.2 — Review an Authorised Test SAS

SAS Assessment Table

Risk Indicators

Part 10 — Review Network Security

Task 10.1 — Display Network Rules

Task 10.2 — Review Public-Network Access

Task 10.3 — Review Private Endpoints

Task 10.4 — Review Private DNS

Network Review Table

Assessment Questions

Part 11 — Review Transport and Encryption

Task 11.1 — Review Secure Transfer

Task 11.2 — Review Encryption

Encryption Review Table

Assessment Questions

Part 12 — Review Data Protection

Task 12.1 — Review Soft Delete

Task 12.2 — Review Versioning

Task 12.3 — Review File Share Recovery

Task 12.4 — Review Immutability

Data Protection Table

Assessment Questions