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 AzureFox 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:

azurefox chains --output table

Then run one live family directly:

azurefox chains credential-path --output table
azurefox chains deployment-path --output table
azurefox chains escalation-path --output table

For saved structured output:

azurefox 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
workload-identity-path	planned	Follow workload-linked identities toward the permissions and trust relationships that make the next Azure control step plausible.	managed-identities, permissions, role-trusts

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 AzureFox 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, or defended escalation follow-up without stitching the joins by hand

What To Look For

• which family is implemented versus still only planned
• which supporting commands each family draws from
• the path question each family answers best: likely downstream service, Azure change path, or defended escalation story
• 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

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 AzureFox 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 AzureFox well because:

• chain families are grounded in recognizable cloud problems such as credential abuse, deployment abuse, and workload-identity misuse
• AzureFox 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 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

The next planned family already called out in the chaining notes is:

• workload-identity-path

That is useful orientation for where the category is going, but this page should stay explicit that only credential-path, deployment-path, and escalation-path are live 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.
• 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.