Docs › Discovery

How Discovery Works

Last updated 2026-07-14

How Discovery Works

This page explains the complete discovery process — from initial port probing through to asset classification and data persistence. Understanding this flow will help you configure targets effectively and troubleshoot issues.

Discovery Scan Types

Scan Type	Best For	How It Works
Smart Scan	Discovering an entire subnet automatically	Two-phase: seed scan to find live hosts, then credential matching to collect full data. Recommended for most use cases.
Seed Scan	Quick survey of what's on a network	Port-only scan — finds live hosts and open ports but does not authenticate. Creates UNKNOWN_ENDPOINT assets.
Targeted Scan	Scanning a specific known host	Direct SSH, WinRM, SNMP, or API connection to a single host with a specific credential.

Smart Scan — Complete Flow

A Smart Scan is the most common and powerful scan type. It runs in two phases:

Phase 1: Seed Scan (Host Discovery & Fingerprinting)

The seed scan probes every IP in the configured CIDR range(s) to find live hosts and collect fingerprint data.

For each IP in the CIDR range:
  1. TCP Port Probing
     → Probes 17 ports: 22, 80, 135, 161, 443, 445, 502, 515, 2404, 3389, 5985, 8006, 8080, 8443, 9100, 20000, 44818
     → Ports 502, 2404, 20000 and 44818 are OT protocol ports (Modbus, IEC 60870-5-104,
       DNP3, EtherNet-IP) included in the TCP connect test for OT device detection
     → Uses 300ms timeout per port (200ms once host is confirmed live)
     → Records all open ports

  2. SSH Banner Grabbing (port 22)
     → If port 22 is open, reads the SSH version string (up to 256 bytes, 500ms)
     → Example: "SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.6"
     → Used for OS inference and device type detection

  3. SNMP UDP Probe (port 161)
     → Sends a lightweight SNMPv2c GET request with community "public"
     → If the device responds, port 161 is marked as open
     → A second GET retrieves sysDescr (e.g. "Cisco IOS Software, C2960...")
     → Used for device type, vendor, and model inference

  4. Credential-Free Recognition
     → mDNS, SSDP/UPnP, NetBIOS and ARP queries, plus public-SNMP reads,
       identify many devices with no credentials at all
     → Feeds vendor, hostname and device-type hints into inference

  5. HTTP(S) Appliance Fingerprinting (ports 80, 443, 8080, 8443)
     → Reads HTTP(S) responses to fingerprint web-facing appliances
     → Captures the TLS certificate as additional identity evidence

  6. ICMP Ping
     → Supplementary reachability check (not used as sole trigger for asset creation)

  7. Device Type Inference
     → 11-rule heuristic engine applied in priority order (see below)
     → Result: asset created as SERVER, NETWORK_DEVICE, PRINTER, IOT_DEVICE,
       HYPERVISOR, OT_DEVICE, or UNKNOWN_ENDPOINT

Result: List of live hosts with open ports, SSH banner, SNMP sysDescr, and inferred type

Device Type Inference Rules

Applied in priority order — first match wins:

#	Condition	Inferred Type
1	SNMP sysDescr contains Cisco, Juniper, Arista, Brocade, MikroTik, pfSense, OPNsense, FortiGate, SonicWall, Ubiquiti	NETWORK_DEVICE
2	SNMP sysDescr contains HP ETHERNET, Ricoh, Xerox, Canon, Epson, Konica, Brother, LaserJet, JetDirect	PRINTER
3	MAC OUI matches an OT vendor (Siemens, Schneider Electric, Rockwell / Allen-Bradley, ABB) or an OT protocol port (502, 2404, 20000, 44818) is open	OT_DEVICE
4	Ports 9100 or 515 open + port 80 open	PRINTER
5	Port 8006 open	HYPERVISOR (Proxmox)
6	SSH banner contains Cisco or MikroTik	NETWORK_DEVICE
7	Port 161 open + no SSH/WMI/RDP ports	NETWORK_DEVICE
8	Only ports 80/443 open (no SSH/WMI/RDP/SNMP)	IOT_DEVICE
9	Port 22 open	SERVER
10	Ports 135, 3389, or 5985 open	SERVER
11	None of the above	UNKNOWN_ENDPOINT

Phase 2: Credential Matching & Full Scan

For each live host found in Phase 1:

For each live host:
  1. Check Scan Hints (cached from previous scans)
     → If a hint exists, try that connector/credential first
     → If the hint succeeds, skip to normalization
     → If the hint fails 3 times, it is discarded

  2. Infer Connector Types from Open Ports
     → Port 22          → SSH_UNIX (Linux/UNIX and macOS)
     → Port 135         → WMI_WINDOWS
     → Port 3389        → WMI_WINDOWS (try WMI first, WinRM fallback)
     → Port 5985/5986   → WINRM_WINDOWS
     → Port 161         → SNMP
     → Port 8006        → PROXMOX
     → Port 9440        → NUTANIX_PRISM

  3. Match Credentials
     → For each inferred connector type, find credentials whose match pattern
       covers this IP (CIDR match, IP match, or "All")
     → Credentials are tried in priority order (lower number = first)

  4. Execute Full Connector
     → SSH Connector: detects ESXi automatically via "esxcli system version get"
       - If ESXi: uses esxcli commands (version, hardware, CPU, memory, VIBs,
         services, processes, datastores, disks, VMs) → classified as HYPERVISOR
       - If Linux: uses standard commands (hostname, packages, services, etc.)
     → WinRM: system info, software, services, processes, hotfixes, disks
     → SNMP: sysName, sysDescr, interfaces, IPs, MACs
     → On success, a scan hint is saved for next time

  5. Carry Seed Metadata
     → Open ports, SSH banner, and SNMP sysDescr from Phase 1 are merged
       into the connector evidence so they persist through normalization

Normalization Pipeline

After discovery, all collected evidence passes through the normalization pipeline:

Stage	Purpose
1. Identifier Normalization	Normalizes MAC addresses, serial numbers, and other identifiers to consistent formats
2. Type Resolution	Applies type ranking — a more specific type (e.g. VM) is never downgraded to a less specific one (e.g. UNKNOWN_ENDPOINT). Hypervisor-hosted assets are reclassified from PHYSICAL_HOST to VM.
3. Identity Resolution	Matches incoming evidence to existing assets using (in priority order): serial number, virtualization UUID, MAC address, FQDN, IP address, hostname+type. Prevents duplicate assets.
4. SSH / Software Enrichment	Detects running software from process lists using Software Detection Rules
5. Lifecycle Enrichment	Matches OS version to lifecycle/EOL data from endoflife.date
6. Asset Persistence	Creates or updates the asset record. Serializes open ports, banners, ESXi data (VIBs, processes, storage, disks), and cloud attributes to custom_attributes JSON. Applies OUI-based manufacturer lookup as fallback for vendor field.
7. Identifier & IP Persistence	Batch upserts identifiers and IP addresses with ON DUPLICATE KEY UPDATE
8. Relationship Persistence	Batch upserts relationships (HOSTED_ON, MANAGED_BY, CONNECTED_TO_NETWORK, etc.). Corrects VM types — assets hosted on a HYPERVISOR are reclassified from PHYSICAL_HOST/SERVER to VM.
9. DNS Enrichment	Background service resolves reverse DNS for asset IPs (asynchronous, does not delay scan)

ESXi Auto-Detection

When the SSH connector successfully authenticates to a host, it runs esxcli system version get. If the output contains version information (not "NOT_ESXI"), the connector switches to ESXi-specific discovery mode:

Asset classified as HYPERVISOR (not PHYSICAL_HOST)
Uses esxcli and vim-cmd commands instead of standard Linux commands
Collects VIB packages, ESXi services, BusyBox processes, datastores, physical disks, and VM inventory
Data stored in custom_attributes JSON and displayed on the asset detail tabs

Manufacturer Identification

uControl Insight identifies device manufacturers through multiple methods (in priority order):

SNMP sysDescr — Parses vendor name from the system description string
SSH / WinRM / esxcli — Vendor field from dmidecode, Win32_ComputerSystem, or esxcli hardware platform get
MAC OUI Lookup — Falls back to an embedded database of ~300 IEEE OUI prefixes

Open Ports & Services

Open ports detected during seed scans are persisted in the asset's custom_attributes JSON and displayed on both the Assets list and detail pages. Services are derived from port numbers:

Port	Service
22	SSH
80, 8080	HTTP
135	RPC
161	SNMP
443, 8443	HTTPS
445	SMB
515	LPD
3389	RDP
5985	WinRM
8006	Proxmox
9100	Print