Chains

chains

chains is the grouped path command for targeted multi-command execution and operator-first path review.

Use it when the interesting Azure story is not hidden in one table, but in how several already shipped commands fit together.

What This Command Gives You

• a grouped attack-path view built from already-exported HarrierOps Azure evidence
• faster answers when the real story lives across several commands
• one readable path row instead of scattered clues across multiple exports
• the likely target, current confidence boundary, and next review step in one place

Run It

Start with the family overview:

ho-azure chains --output table

Then run one live family directly:

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

For saved structured output:

ho-azure chains deployment-path --output json

Family Overview

The current live family set is:

family	state	summary	backing commands
credential-path	implemented	Follow credential clues from surfaced secret-bearing or token-bearing evidence toward the likely downstream service.	env-vars, tokens-credentials, databases, storage, keyvault
deployment-path	implemented	Follow controllable deployment and automation paths toward the Azure footprint they are most likely to change next.	devops, automation, permissions, rbac, role-trusts, arm-deployments, aks, functions, app-services
escalation-path	implemented	Follow the strongest current-foothold escalation stories toward the next defended identity or control step.	privesc, permissions, role-trusts
compute-control	implemented	Follow token-capable compute footholds toward the identity-backed Azure control they can reach next.	tokens-credentials, workloads, managed-identities, permissions

That is the intended experience: chains first shows you which path family is mature enough to use now, then each family turns several flat commands into one shorter, operator-facing answer.

When To Use It

• when several commands already hint at one path and you want HarrierOps Azure to assemble the first honest review set for you
• when the path question is more important than any one flat command output
• when you need the next target story, confidence boundary, and follow-up step now
• when you want to jump straight to credential follow-up, deployment follow-up, defended escalation follow-up, or compute-to-control follow-up without stitching the joins by hand

What To Look For

• which family is implemented right now
• which supporting commands each family draws from
• the path question each family answers best: likely downstream service, Azure change path, defended escalation story, or direct compute-to-control pivot
• short next-review guidance that makes the right follow-up obvious
• the top rows first once you enter a family, because the output is meant to be read as a priority queue

Loot Behavior

The base ho-azure chains overview still uses ranked-cutoff loot behavior. It is a family index surface, not a semantic-priority surface, even though live family runs can use semantic-high-band loot when their JSON rows ship a defended priority contract.

Why It Matters

Many real Azure attack paths are not hidden inside one table.

chains turns scattered evidence into a next-step review set without pretending HarrierOps Azure proved more than it really did. Its value is not replacing the underlying commands. Its value is helping you move from a visible clue to the right next target faster.

It does that by joining exported evidence from the supporting commands into one easier-to-read path row. Instead of leaving a secret clue, workload clue, or config clue isolated in its source command, chains attempts to pull the likely downstream resource forward and put the issue, candidate target, and confidence boundary in the same view.

This is where chaining stops being theoretical. The command exists to get the strongest path in front of the operator quickly and make the next move obvious.

Why Chains Earns A Place

The command-chaining notes behind this page treat chains as a curated orchestration layer, not a replacement for subcommands.

That model fits HarrierOps Azure well because:

• chain families are grounded in recognizable cloud problems such as credential abuse, deployment abuse, escalation, and identity-backed compute pivots
• HarrierOps Azure already has the evidence surfaces needed to tell a shorter, more honest next-step story
• the grouped result saves manual stitching without hiding where current visibility stops
• the output feels like an operator-facing path surface instead of a theoretical note spread across several separate tables

The current product reasoning behind chains tracks closely with broader cloud guidance about credential exposure, CI/CD abuse, non-human identities, and attack-path prioritization:

• MITRE ATT&CK Cloud Matrix
• OWASP Non-Human Identities Top 10
• OWASP Top 10 CI/CD Security Risks
• Microsoft Defender for Cloud attack paths
• NSA Top Ten Cloud Security Mitigation Strategies

What Should Stand Out First

• exact named target matches first
• rows that already point toward the strongest and most immediate Azure path
• narrowed candidate rows after that
• blocked-visibility rows below exact matches
• short next-review guidance on every row

The strongest rows should rise first because this command is built for rapid triage, not for cataloging every possible path with equal weight.

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

• If you see target resolution = named match for a Key Vault-backed setting, go next to Keyvault because it shows the visible vault boundary behind that reference.
• If you see a deployment source that already looks attacker-usable now, go next to Devops or Automation because those pages explain the execution surface and trusted-input story behind the row.
• If you see a current foothold that already holds stronger Azure control, go next to Privesc, Permissions, or RBAC because they show the exact escalation proof behind the grouped story.
• If you see a direct token opportunity on a compute row, go next to Workloads, VMs, Managed-Identities, and Permissions because those pages validate the host foothold, the attached identity, and the stronger Azure control behind the row.
• If you see a credential-shaped database row, go next to Databases because it confirms the server inventory, endpoint naming, and visible database context behind the path clue.
• If you see visibility blocked, go next to the affected flat command because that command is the shortest place to confirm the permission gap before you trust any follow-on target story.

Current Chain Families

The current live families are:

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

This page should stay explicit that these four families are the live grouped chain surface today.

What To Do Next

• Start with the top rows first because they are meant to be your first attack-path queue.
• Prefer the family that matches your current question instead of reading every source command in parallel.
• Prefer exact named-target rows before narrowed candidates inside credential-path.
• Prefer clearly attacker-usable source paths before softer deployment context inside deployment-path.
• Prefer explicit current-foothold transforms before trust-adjacent leads inside escalation-path.
• Prefer direct token-opportunity rows before broad compute inventory when the compute foothold already exposes an attached identity path.
• Treat visibility blocked as a stop sign, not a cue to guess.
• Use chains to narrow the next review target, then validate it in the matching flat command or the specific chain-family page.

Boundary

chains is a grouped operator command.

It should show defensible path stories using already-shipped evidence surfaces. It is not a secret retrieval command, speculative join engine, or a broad grouped sweep replacement for every command.