Haxoris Wiki

Exposed Management Interfaces

How Exposed Management Interfaces works

Exposed management interfaces are administrative consoles that answer from the ordinary user VLAN instead of a dedicated management network. The estate is predictable: vCenter and ESXi host clients, iLO, iDRAC and generic IPMI cards, switch and firewall web UIs, a Jenkins controller, Kubernetes and container dashboards, and database admin tools like phpMyAdmin or Adminer. Each was stood up on whatever subnet was convenient, the firmware defaults to listening on every interface, and no routed boundary keeps a workstation from opening the console.

The attacker gains the control plane rather than a single host. A reachable IPMI card offers virtual media and a serial console below the operating system; a vCenter login reaches every guest at once; a switch panel rewrites VLANs and mirrors traffic. It is easy to miss because the console is meant to answer - it is doing its job - and audits check that the managed hosts are patched, not that the management surface is unreachable. The service is often behind cleartext HTTP too, which belongs to the Cleartext Management Protocols page, and the default credentials that many of these consoles still carry belong to the Default Credentials On Devices And Appliances page.

Exposed Management Interfaces in practice

Sweep the user VLAN from a workstation vantage

Start from a standard DHCP lease so the result reflects what a phished workstation sees. Scan the common management and console ports read-only, without touching the services yet.

# management and out-of-band console ports, service discovery only
nmap -sS -Pn -n --open -T3 \
  -p 22,80,443,623,902,2379,3306,5432,6443,8006,8080,8443,9090,10000 \
  10.10.20.0/22 -oA /tmp/isr09-mgmt

# IPMI answers on UDP 623; probe it read-only, do not attempt cipher-zero auth
nmap -sU -Pn -n --open -p 623 --script ipmi-version 10.10.20.0/22 \
  -oN /tmp/isr09-ipmi.txt

An open 902 or 8006 is a hypervisor, 623 is an out-of-band card, and 6443 is a Kubernetes API. Any of them answering a user-VLAN address is the finding regardless of whether the login is reached.

Fingerprint what each open port actually is

A port number is not proof; pull the title and server banner so the report names the exact console and vendor.

awk '/Ports:.*open/ {print $2}' /tmp/isr09-mgmt.gnmap > /tmp/isr09-hosts.txt

nmap -sV -Pn -n --script "http-title,http-server-header,ssl-cert" \
  -p 80,443,8006,8080,8443,9090,10000 -iL /tmp/isr09-hosts.txt \
  -oN /tmp/isr09-fingerprint.txt

# certificate subject often names the appliance outright
echo | openssl s_client -connect ilo-esx01.lab.internal:443 2>/dev/null \
  | openssl x509 -noout -subject -issuer

Record reachability as the finding

The evidence a defender acts on is the grid of console-versus-source, not the individual banners. Collapse the sweep into one row per interface with the verdict attached.

source: 10.10.21.63 (user VLAN, standard DHCP lease)

interface                       port   type                 verdict
------------------------------  -----  -------------------  ------------------------------
vcenter01.lab.internal          8006   Proxmox / vCenter    FINDING: full hypervisor plane
esx01.lab.internal              902    ESXi host agent      FINDING: host management
ilo-esx01.lab.internal          623    IPMI 2.0             FINDING: below-OS console
sw-core01.lab.internal          443    switch web UI        FINDING: VLAN and SPAN control
jenkins.lab.internal            8080   Jenkins controller   FINDING: build plane, RCE path
k8s-api.lab.internal            6443   Kubernetes API       FINDING: cluster control plane
db-admin.lab.internal           80     Adminer / phpMyAdmin FINDING: direct DB admin

Every row is reachable from a user lease and therefore in scope even before authentication is tested.

Test whether management logins ride the production directory

The second half of the finding is identity, not reachability: a console that authenticates against the same directory as everyone’s laptop offers no separation. Check the join and the configured identity source read-only.

# is the hypervisor / console host joined to the production AD domain?
Resolve-DnsName vcenter01.lab.internal -Type A
nltest /dsgetdc:corp.lab.internal

# on a Windows management box, which directory answers its logins
(Get-CimInstance Win32_ComputerSystem).Domain

# a console whose SSO identity source is the production domain shares its
# blast radius with every user account - record that as a separate finding

A console that both answers from the user VLAN and authenticates against the production directory is a single-step path from one phished user to the control plane.

How to fix and prevent Exposed Management Interfaces

  1. Move the consoles onto a dedicated management network
    • No hypervisor, out-of-band, switch or orchestration interface should be routable from the user VLAN, only from a hardened jump path.
    • The segmentation work itself belongs to the Flat Networks And Missing Segmentation page.
  2. Bind each interface to its management address only
    • Set the console to listen on the management NIC, not on every interface, so a re-image does not re-expose it on the production subnet.
  3. Give the management plane its own identities
    • Separate administrative accounts and, where the product supports it, a separate directory or local-only admin, so a production credential cannot open the plane that controls production.
  4. Put every console behind MFA and a jump host
    • Reach consoles through a privileged access workstation with enforced MFA; default and shared logins on the appliances are covered by the Default Credentials On Devices And Appliances page.
  5. Inventory and monitor the interfaces
    • Keep a list of every management surface with an owner, and alert on any session whose source is outside the jump path or management subnet.

Last updated

References