Finding Unmanaged Machines: Agentless Network Discovery from Your Gateway

Network discovery inventories the hosts on a gateway's local network and identifies which are not running the ET Ducky agent. It runs inside the same gateway used for out-of-band management. This post describes the scan, how hosts are classified as managed or unmanaged, and the current scope of the feature.

Trigger model

Network discovery does not run on a schedule. There is no background scanner. A scan runs only when an organization administrator starts one from the Network Discovery view under Systems. An active network scan can be detected by an intrusion-detection system, so ET Ducky performs a scan only in response to an explicit action.

Scan mechanism

When a scan starts, the cloud instructs the gateway to sweep its local subnets. For each address the gateway:

• tests liveness with an ICMP ping and by reading the local ARP or neighbor table, which also records hosts that do not answer ping but have recent layer-2 activity;
• attempts TCP connections to a small set of management ports to estimate the OS family. Ports 445, 5985, 5986, 3389, and 135 indicate Windows. Port 22 indicates Linux;
• records the IP address, the MAC address for hosts on its own network segment, and a reverse-DNS hostname where one resolves.

The gateway reports the discovered endpoints to the cloud in one batch. The sweep consists of a ping and a small number of TCP connection attempts per host. It is not a full port scan.

Managed and unmanaged classification

The cloud classifies each discovered host by correlating it against the organization's enrolled agents. It matches on MAC address first, then on hostname. A host that matches an agent is marked Managed and linked to that agent. A host with no match is marked Unmanaged.

MAC matching is accurate for hosts on the gateway's own subnet. Hosts reached across a router are correlated by hostname or IP address only. The OS estimate is derived from open ports and is not an authoritative fingerprint. Endpoints that stop appearing on later scans are retained with an earlier last-seen time rather than deleted.

Where it runs

Discovery runs inside the gateway used for out-of-band management, which is either a dedicated device or a regular agent with the OOB gateway role enabled. One gateway performs both functions: control of AMT, DASH, and IPMI hardware, and inventory of operating-system hosts. The two results are shown separately. OOB hardware appears under Agents, in the Discovered / OOB tab. Discovered OS hosts appear under Systems, in the Network Discovery view.

Views

Discovery is organized into several views. Topology draws the organization as a map: the cloud, each VLAN's out-of-band gateway, and the devices behind it. Coverage reports how many agent-compatible hosts run the agent, per subnet. Segments rolls up each VLAN and flags any that have no on-segment OOB gateway, so a segment with no out-of-band path is visible. OOB candidates lists managed hosts whose hardware is vPro/AMT-capable but not yet provisioned; these can be provisioned from the agent (see out-of-band management). Attack surface reports which services (SMB, RDP, SSH, WinRM, and others) are listening across the fleet and flags exposures. Non-computers groups printers, switches, phones, and IoT by hardware vendor. Results scope to a single organization through the selector.

Scope

Discovery and its views are read-only. They report and organize what is on the network; they do not change it. Deploying the agent to unmanaged hosts is a separate function that is not part of this release. That function installs the agent over WinRM and SSH using one-time enrollment tokens and relayed credentials. It is kept separate from discovery because remote installation across a network has a different risk profile than reading the network.

The scan requirements, access model, and accuracy notes are described in the Network Discovery documentation.