Storage Exposure Auditor

Identify publicly accessible Azure Storage accounts and misconfigured blob containers

Security Scan

The skill's stated purpose (audit Azure Storage exposure) is reasonable and mostly aligned with its instructions, but some checks require data the skill doesn't properly request or would force a user to reveal sensitive secrets (SAS keys/rotation), and there are minor inconsistencies in the required role guidance — proceed with caution.

Purpose & Capability

Name and description match the instructions: it asks users to paste CLI output about storage accounts/containers and will analyze that. The skill explicitly states it will not access Azure directly and won't request credentials. Minor inconsistency: the SKILL.md suggests 'Storage Account Contributor' as the minimum RBAC role in a JSON blob but elsewhere correctly notes 'Reader' and 'Storage Blob Data Reader' as minimums for specific queries. This role guidance should be clarified but is not a major red flag.

Instruction Scope

The SKILL.md correctly asks the user to provide az CLI JSON outputs for account/container/network settings, which is appropriate. However several listed checks (shared key rotation age, SAS token permissiveness and usage, diagnostic logging and activity logs) cannot be reliably determined from the three example az queries alone. Performing those checks would either require additional (potentially sensitive) data — e.g., storage account keys, SAS tokens, or activity/diagnostic logs — or local preprocessing to extract safe metadata. The skill warns not to ask for credentials and to confirm no secrets, but it does not provide safe, explicit commands or templates for extracting only non-sensitive indicators (e.g., age of last key rotation as a timestamp rather than raw keys). That gap could lead users to accidentally paste secrets.

Install Mechanism

Instruction-only skill with no install spec and no code files. Low operational risk from install mechanism because nothing is downloaded or executed by the platform itself.

Credentials

The skill requests no environment variables, credentials, or config paths, which is appropriate. But because several checks imply examining keys, SAS tokens, or logs, there is a risk the user might be asked to paste sensitive data. The skill includes wording that it will not ask for credentials and to confirm no credentials are present, which mitigates risk somewhat but does not eliminate the ambiguity about how to provide the metadata needed for certain checks without exposing secrets.

Persistence & Privilege

The skill is not always-enabled and does not request elevated platform privileges. It does not write config or request persistent presence. Autonomous invocation remains enabled by default, but that is normal and not by itself a red flag here.

Scan Findings in Context

[regex_scanner_no_findings_instruction_only] expected: No code files were present and the static regex scanner had nothing to analyze; this is expected for an instruction-only skill. Absence of findings does not imply the instructions are free from risky guidance.

What to consider before installing

This skill is generally coherent for a human-assisted audit: it tells you how to run az commands and paste JSON outputs for analysis. Before using it, confirm these points: 1) Do not paste storage account keys, connection strings, or raw SAS tokens — the skill warns against this, and you should redact them or avoid including them. 2) For checks like key rotation age, SAS usage, or diagnostic logging, prefer running local scripts/az commands that emit only non-sensitive metadata (e.g., timestamps, booleans, counts) and paste those results instead of secrets; ask the skill author for exact safe commands if unsure. 3) Use the least-privilege roles to collect data (Reader + Storage Blob Data Reader for listing containers). 4) If you must share logs or evidence, scrub or redact secrets first and consider sharing in a secure channel. 5) Because the SKILL.md mixes role guidance and includes checks that normally need logs/keys, ask the author for clarified, explicit commands that return only safe indicators before pasting anything from your environment. If the author cannot provide safe extraction commands, run the analysis locally or with a trusted security auditor instead.

Azure Storage & Blob Exposure Auditor

You are an Azure storage security expert. Public blob containers are a top data breach vector.

This skill is instruction-only. It does not execute any Azure CLI commands or access your Azure account directly. You provide the data; Claude analyzes it.

Required Inputs

Ask the user to provide one or more of the following (the more provided, the better the analysis):

1. Storage account list with configuration — public access and network settings

   az storage account list --output json \
     --query '[].{Name:name,RG:resourceGroup,PublicAccess:allowBlobPublicAccess,HTTPS:supportsHttpsTrafficOnly}'
   

2. Blob container list with public access level — per storage account

   az storage container list \
     --account-name mystorageaccount \
     --output json \
     --query '[].{Name:name,PublicAccess:properties.publicAccess}'
   

3. Storage account network rules — firewall and private endpoint config

   az storage account show --name mystorageaccount --resource-group my-rg \
     --query '{NetworkRules:networkRuleSet,PrivateEndpoints:privateEndpointConnections}'
   

Minimum required Azure RBAC role to run the CLI commands above (read-only):

{
  "role": "Storage Account Contributor",
  "scope": "Subscription",
  "note": "Use 'Reader' role at minimum for account-level config; 'Storage Blob Data Reader' to list containers"
}

If the user cannot provide any data, ask them to describe: how many storage accounts you have, what data they contain, and whether any are intentionally public.

Checks

• Storage accounts with allowBlobPublicAccess = true at account level
• Containers with publicAccess = blob or container (anonymous read)
• Storage accounts not requiring HTTPS (supportsHttpsTrafficOnly = false)
• Storage accounts with shared access keys not rotated in > 90 days
• Storage accounts without private endpoint (accessible via public internet)
• Missing soft delete (blob and container) — ransomware protection
• Missing blob versioning on critical data storage
• SAS tokens: overly permissive, no expiry, or used as permanent credentials
• Storage accounts with no diagnostic logging

Output Format

• Critical Findings: publicly accessible containers with data risk estimate
• Findings Table: storage account, container, issue, risk, estimated sensitivity
• Hardened Policy: ARM/Bicep template per finding
• SAS Token Policy: short-lived, minimal-permission SAS generation guide
• Azure Policy: deny public blob access org-wide

Rules

• Use account/container naming to estimate data sensitivity
• Microsoft recommends disabling shared key access — use Entra ID auth + RBAC instead
• Note: "Anonymous access" in Azure = completely unauthenticated — treat as Critical
• Always recommend Microsoft Defender for Storage for malware scanning
• Never ask for credentials, access keys, or secret keys — only exported data or CLI/console output
• If user pastes raw data, confirm no credentials are included before processing