Endpoints

endpoints

endpoints is the ingress-first command for public IPs and Azure-managed hostnames tied back to source assets.

Use it when you need the fastest answer to "what looks externally reachable, and what does it belong to?"

What This Command Answers

• What endpoint strings look worth reviewing first?
• Which exposed-looking hostname or public IP belongs to which asset?
• Which ingress path is the clearest next investigation target?

Run It

ho-azure endpoints --output table

For saved structured output:

ho-azure endpoints --output json

Example Table Output

endpoint	asset	kind	family	ingress	why it matters
52.160.10.20	vm-web-01	VM	public-ip	direct-vm-ip	VM exposes a public IP; review NIC and NSG context next.
app-empty-mi.azurewebsites.net	app-empty-mi	AppService	managed-web-hostname	azurewebsites-default-hostname	Azure-managed hostname published by App Service.
app-public-api.azurewebsites.net	app-public-api	AppService	managed-web-hostname	azurewebsites-default-hostname	Azure-managed hostname published by App Service.

When To Use It

• when you want an ingress-first starting point before deeper workload review
• when the environment has mixed service types and you need a simple external-path view
• when hostnames and public IPs matter more than abstract resource names

What To Look For

• clearly public and directly attributable endpoints
• Azure-managed hostnames tied to important workloads
• source asset context in the same row
• summaries that explain why an endpoint matters without claiming confirmed listener proof

Why It Matters

Visible endpoints often define where an attacker or operator starts.

Joining endpoint strings to the assets behind them is much more useful than leaving them scattered across service-specific tables. endpoints helps you see likely ingress surfaces quickly and pivot into the right workload next.

What Should Stand Out First

• clearly public endpoints first
• source asset context visible in the same row
• hostnames or public IPs tied to already-interesting workloads
• enough summary to make the next pivot obvious

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

• If you see a VM public IP endpoint, go next to Network-Effective because it shows the combined inbound-rule evidence behind that exposed asset.
• If you see an Azure-managed hostname for an App Service or Function App, go next to app-services or functions because those commands show the workload hardening and identity context behind that endpoint.
• If the source asset carries managed identity, go next to Managed-Identities because it shows whether that exposed workload is also an Azure token path.

What To Do Next

• Use the top-ranked endpoints to choose the next workload or network command.
• Treat endpoint strings as an ingress clue, not proof of live reachability.
• Pair public-looking ingress with workload identity and network posture before drawing stronger conclusions.

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

endpoints is an ingress-triage command.

It should make externally relevant paths obvious. It is not final exposure proof or a replacement for the combined network view.