Skip to content
Colby Farley edited this page Apr 23, 2026 · 2 revisions

nics

nics is the grounding command for network interface placement, addressing, and subnet context.

Use it when you need to understand where workloads really sit on the network before you decide whether to pursue ingress, port, or workload-specific follow-up.

What This Command Answers

  • Where do these workloads actually sit on the network?
  • Which interfaces change the network story most?
  • Which NIC placement deserves follow-up because it affects reachability or adjacency?

Run It

ho-azure nics --output table

For saved structured output:

ho-azure nics --output json

Example Table Output

nic attached asset private ips public ip refs subnet / vnet nsg
nic-web-01 vm-web-01 10.0.1.4 pip-web-01 subnet=vnet-app; vnet=vnet-workload nsg-web
nic-db-01 - 10.0.2.5, 10.0.2.6 subnet=vnet-db; vnet=vnet-workload -

When To Use It

  • when you need interface, subnet, and NSG grounding for later network reasoning
  • after a workload or endpoint already looks important
  • when the key question is network placement rather than final exposure

What To Look For

  • NICs with public IP references
  • subnet and NSG context that changes how you read the workload
  • interfaces attached to already-interesting assets
  • unusual unattached or incomplete interfaces that stand out from routine placement

Why It Matters

Network placement often explains why a workload is reachable or isolated.

A NIC tied to a public IP, important subnet, or interesting NSG can matter more than the asset name alone. nics gives you the placement truth you need before drawing stronger conclusions from endpoint or rule tables.

What Should Stand Out First

  • NICs with public IP linkage
  • interfaces attached to important workloads
  • unusual unattached or incomplete interfaces
  • subnet and NSG context visible in the same row

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

  • If you see a NIC with public_ip_ids populated, go next to Network-Effective because it combines the endpoint, NIC, and inbound-rule evidence into one exposure view.
  • If you see a NIC attached to a VM or scale set that already looks important, go next to vms or vmss because those commands show the host or fleet context behind that network placement.

What To Do Next

  • Use nics to ground later network claims in actual placement.
  • Treat it as a support surface that tells you where the asset sits before you rank final exposure.
  • Pivot from the interesting NIC into the workload or combined network command that explains its consequence best.

Loot Behavior

Loot currently keeps the top-ranked rows for this command. That ordering is useful, but it is not yet a shipped semantic high / medium / low analyst contract unless the command explicitly labels rows with a defended priority contract.

Boundary

nics is a network grounding command.

It should expose placement, addressing, subnet, and NSG context. It is not final exposure judgment or a replacement for the combined network view.

Clone this wiki locally