Command Guides

Command Guides

These pages turn HarrierOps Azure command intent into operator-facing guidance.

They are written to answer four practical questions quickly:

• what the command is for
• when to run it
• what to look for in the output
• what to do next if the command finds something important

The current command-guide pass covers core, identity, config, secrets, storage, resource, network, compute, and orchestration because those sections usually establish orientation, privilege context, configuration shape, trust boundaries, ingress posture, workload consequence, and the first high-value data and secret paths earliest.

Core Command Guides

• inventory

Identity Command Guides

• whoami
• rbac
• principals
• permissions
• privesc
• role-trusts
• cross-tenant
• lighthouse
• auth-policies
• managed-identities

Config Command Guides

• arm-deployments
• env-vars

Secrets Command Guides

• keyvault
• tokens-credentials

Storage Command Guides

• storage

Resource Command Guides

• automation
• devops
• acr
• api-mgmt
• databases
• resource-trusts

Network Command Guides

• dns
• endpoints
• application-gateway
• network-effective
• network-ports
• nics

Compute Command Guides

• workloads
• app-services
• functions
• container-apps
• container-instances
• aks
• vms
• vmss
• snapshots-disks

Orchestration Command Guides

Chain Families

• chains
• chains credential-path
• chains deployment-path
• chains escalation-path
• chains compute-control

Planned Buckets

These category buckets are reserved now so the wiki can scale without constant sidebar reshuffling:

• investigations: targeted workflows and future generic workflows

Recommended Reading Order

Start with:

1. inventory
2. whoami
3. principals
4. permissions

Then pivot based on what you learn:

• use RBAC when you need the underlying assignment evidence
• use Privesc when you want the most credible escalation paths first
• use Role Trusts when indirect control matters more than direct RBAC
• use Cross-Tenant when the real control boundary may extend into another tenant
• use Auth Policies when tenant-wide identity posture may change how risky a finding really is
• use Managed Identities when workload-linked Azure identities look more important than human accounts
• use Lighthouse when outside-tenant delegated management may change the real control picture
• use ARM Deployments when recent infrastructure changes explain the current environment better than static inventory alone
• use Env Vars when workload configuration may reveal the next trust, secret, or dependency path
• use Keyvault when secret-management boundaries look more important than general resource counts
• use Tokens Credentials when you need the shortest path to likely credential-bearing workloads
• use Storage when exposed or weakly protected data stores may matter more than workload posture
• use Automation or Devops when the interesting path is already a named execution or deployment surface rather than a single workload
• use API-Mgmt, Databases, or ACR when service-level trust or software-supply posture matters more than generic inventory
• use Endpoints when you need the fastest ingress-first view of what looks externally reachable
• use Application-Gateway when the shared ingress tier matters more than any one public hostname
• use Network-Effective when you need the combined network picture instead of any one endpoint or rule table
• use Workloads when you want the fastest joined workload view across exposure and identity
• use App-Services, Functions, Container Apps, Container Instances, AKS, VMs, or VMSS when one compute family now matters more than the cross-service overview
• use Snapshots-Disks when the more useful follow-up path may be an offline disk or snapshot behind the live workload
• use Chains when one honest grouped path story is more useful than reading several flat command outputs separately
• use chains credential-path when the key problem is a visible credential clue and you need the shortest route to the likely downstream target
• use chains deployment-path when the important question is whether a deployment or automation surface can already change Azure now
• use chains escalation-path when you need the shortest defended story from the current foothold to stronger Azure control
• use chains compute-control when a token-capable workload foothold may already map to stronger Azure control through its attached identity

Practical Pattern

For a fast identity pass:

ho-azure inventory --output table
ho-azure whoami --output table
ho-azure principals --output table
ho-azure permissions --output table
ho-azure privesc --output table

For a quick secrets-oriented follow-up:

ho-azure keyvault --output table
ho-azure tokens-credentials --output table

For configuration and data-surface follow-up:

ho-azure arm-deployments --output table
ho-azure env-vars --output table
ho-azure storage --output table

For resource and network follow-up:

ho-azure automation --output table
ho-azure --devops-organization <org-name> devops --output table
ho-azure endpoints --output table
ho-azure application-gateway --output table
ho-azure network-effective --output table

For compute follow-up:

ho-azure workloads --output table
ho-azure app-services --output table
ho-azure functions --output table
ho-azure container-apps --output table
ho-azure container-instances --output table
ho-azure aks --output table
ho-azure vms --output table

For orchestration follow-up:

ho-azure chains credential-path --output table
ho-azure chains deployment-path --output table
ho-azure chains escalation-path --output table
ho-azure chains compute-control --output table

That gives you wider artifact packages, but the command guides below are still the best place to understand what each command is actually telling you.