Skip to content

Storage

Colby Farley edited this page Apr 7, 2026 · 4 revisions

storage

storage is the storage-account-first exposure and access triage command for AzureFox.

Use it when you need to know which storage accounts look easiest to reach, weakest to defend, or most likely to hold accessible data first.

What This Command Answers

  • Which storage accounts should you inspect first?
  • Which accounts combine exposure with weaker access posture?
  • Which storage boundary most changes the data-access story in the environment?

Run It

azurefox storage --output table

For a saved structured artifact:

azurefox storage --output json

Example Table Output

account exposure auth / transport protocols inventory
stlabpub01 blob-public=yes; public-net=enabled; default=Allow shared-key=yes; tls=TLS1_0; https-only=no hns=no; sftp=no; nfs=no blob=3; file=1; queue=2
stlabpriv01 blob-public=no; public-net=disabled; default=Deny shared-key=no; tls=TLS1_2; https-only=yes hns=yes; sftp=yes; nfs=no blob=2; table=1

When To Use It

  • when storage accounts are likely to be the shortest path to useful data
  • after inventory suggests a storage-heavy estate
  • when you need to rank storage targets without jumping straight into object enumeration

What To Look For

  • public access or broadly reachable network posture
  • shared-key access and other weaker auth patterns
  • weaker transport or boundary cues
  • service-shape signals such as HNS, SFTP, or NFS that suggest more interesting workflows

Why It Matters

Storage is often where the useful data, exports, logs, backups, and staging material actually live.

Most subscriptions have many storage accounts, but only a few deserve immediate review. storage helps you identify the accounts whose exposure, auth posture, and service shape make them the best next targets instead of forcing you to page through a flat list.

What Should Stand Out First

  • public-access accounts before quieter internal-only posture
  • public-network-enabled accounts near the top
  • permissive firewall defaults, shared-key access, and weaker TLS posture before stronger defaults
  • service-shape cues such as HNS, SFTP, NFS, and lack of private endpoints when the rest of the exposure story is already concerning

If You See..., Go Next To...

  • If you see public_access=true or network_default_action=Allow, go next to resource-trusts because it shows whether that storage exposure is part of a broader public-resource pattern.
  • If you see allow_shared_key_access=true on an account that is also reachable, go next to permissions because it shows which principals are most likely to control or extend that storage path.

What To Do Next

  • Prioritize the accounts that combine reachability with weaker auth or transport posture.
  • Treat service-shape cues as hints about where richer data workflows may exist.
  • Use the storage account boundary to decide whether your next question is about trust, privilege, or deeper service-specific follow-up.

Boundary

storage is a storage-account posture and prioritization command.

It should rank the best storage targets to review next. It is not a container, blob, queue, or file-share enumeration workflow.

Clone this wiki locally