NetworkHound Sniffs Out the Network Active Directory Forgot

Active Directory keeps the guest list. NetworkHound checks who is actually in the building.

Every corporate network has a machine nobody quite remembers. It may be an old server left behind by a completed project, a virtual machine that was supposed to be temporary, a web console listening on an unusual port or a test appliance quietly approaching its fifth birthday. It still responds, still exposes services and may still contain data, but it has slipped out of the official picture. That is the territory NetworkHound was built to explore.

Created by offensive security specialist Mor David, NetworkHound is a Python-based network topology analyser that begins with Active Directory and then looks beyond it. It can query domain computers, sites and subnets, resolve hostnames, scan ports, inspect web services, validate SMB connections and search configured network ranges for devices that do not appear in the directory at all. Its findings are exported as OpenGraph JSON for use inside BloodHound. This is not simply another tool with “Hound” added to the name. It fills a real gap between what the directory believes exists and what the network is prepared to answer for.

The directory is not the network

Active Directory is invaluable, but it is not an infallible inventory system. It knows about the machines joined to the domain. It does not automatically account for every printer, appliance, abandoned virtual machine, standalone server, embedded device or hastily installed management interface attached to the same network. NetworkHound starts with the organised world of domains, sites, subnets and computer objects. It then expands the search into the less orderly world of IP addresses, open ports, websites and file shares.

Its graph can contain domains, AD sites, subnets, computers, non-domain devices, websites and SMB shares. Relationships connect sites to domains, subnets to sites, devices to subnets, and hosts to the web or file-sharing interfaces they expose. That distinction matters. A conventional asset list might tell you that 10.20.4.17 has ports 443 and 445 open. NetworkHound can represent the address as a device inside a particular subnet, attach an HTTPS service and one or more file shares to it, and place the whole thing inside a navigable graph. A flat spreadsheet gives you facts. A graph gives those facts context.

Why BloodHound is the natural destination

BloodHound became popular because relationships often reveal more than isolated findings. A user account may appear harmless until it is connected to a group, a session, a delegated permission and finally a privileged system. OpenGraph extends that same idea beyond BloodHound’s traditional Active Directory and Entra ID data. It allows external collectors to introduce custom nodes, edges and properties, turning other platforms and infrastructure into graph data that can be searched and queried alongside the familiar environment. NetworkHound uses that opening to add network geography.

Instead of trying to become a complete replacement for BloodHound, it feeds BloodHound a different layer of reality: where machines live, which services they expose and which devices exist outside the directory’s official records. The project is included in SpecterOps’ BloodHound Community Extensions library. That listing gives it useful visibility, although SpecterOps explicitly states that community tools in the library are supplied as-is and have not been audited or endorsed. In other words, inclusion is recognition, not a security guarantee. As of 4 August 2026, the repository had accumulated 797 stars and 98 forks. Those figures do not prove that the software is production-ready, but they do show that its central idea has caught the attention of the security community.

It has more than one way to pick up a scent

Name resolution is often where network discovery begins to unravel. DNS may be incomplete, local search domains may behave differently, short hostnames may resolve where fully qualified names do not, and proxying UDP traffic can produce thoroughly confusing results. NetworkHound responds by trying several approaches. It can use normal socket resolution, nslookup, dnspython, system-level address resolution and short-hostname fallbacks. It also supports DNS over TCP, which is particularly useful when operating through restrictive firewalls or proxychains.

Authentication is similarly flexible. The tool supports a password, an NTLM hash or a Kerberos ticket through Impacket. Kerberos details can be read from a cache referenced by the KRB5CCNAME environment variable, while the current code can automatically extract the user and domain in that mode. It can also work without Active Directory credentials at all. The current program accepts individual IP addresses, explicit IP ranges and CIDR networks through its manual network mode. This turns NetworkHound into a more general OpenGraph network collector when the operator already knows which address space needs examining. That flexibility makes it useful in several situations: a defensive review of an internal estate, an authorised penetration test, a red-team exercise or a lab in which the network is only partly represented inside AD.

Beyond “port open”

Port scanning is only the start. NetworkHound uses configurable thread pools to scan common TCP ports across discovered addresses. The default list covers familiar services including SSH, DNS, HTTP, HTTPS, SMB, LDAP, RDP, WinRM, database ports, VNC and several common alternative web ports. Operators can replace the list, adjust the timeout and control the number of concurrent workers. When HTTP validation is enabled, NetworkHound attempts both HTTP and HTTPS against discovered ports. It records response codes and page titles, identifies certificate problems and can collect detailed TLS information including subjects, issuers, fingerprints, validity dates, cipher information and certificate warnings.

The present implementation goes further than its feature summary might suggest: it stores up to one megabyte of response body from each successful HTTP or HTTPS request and adds that material to the corresponding website node. That can be valuable when an otherwise anonymous service reveals a product name, login page or management interface. It also means the resulting JSON may contain sensitive page content and can become considerably larger than expected. Treat the output as security data, not as an innocent diagram.

SMB validation can test ports 139 and 445, identify server information, determine whether anonymous or authenticated access is required, and enumerate available shares when the supplied permissions allow it. Successful shares become separate FileShare nodes attached to the computer or device exposing them. This is where NetworkHound becomes genuinely interesting. It does not merely say that a machine exists. It begins to describe how that machine presents itself to the rest of the estate.

Finding the machines that never joined the club

The headline feature is shadow-IT discovery. NetworkHound can read the subnet definitions stored in Active Directory Sites and Services, sweep those address ranges and compare responding devices with known domain computers. Addresses that answer but do not correspond to AD computer objects can be introduced into the graph as separate Device nodes and marked as shadow IT.

Of course, “not in Active Directory” does not automatically mean “malicious” or even “unauthorised.” A device may be intentionally standalone. It could be an infrastructure appliance, an industrial controller, a printer or a system managed through a different directory. The value lies in surfacing the discrepancy.

Once a device appears in the graph, someone can ask the questions that should have been asked earlier: Who owns it? Why is it on this subnet? Which services does it expose? Does its certificate reveal an internal hostname? Can guests access its shares? Is it still required? NetworkHound does not answer every one of those questions, but it makes them much harder to avoid.

Installation is simple; preparation is less automatic

The current README identifies the project as version 1.2.1 and requires Python 3.8 or later. Its dependency file contains Impacket, LDAP3, Requests, urllib3, dnspython and the BloodHound OpenGraph library. The package versions are not pinned, so installing it months later may produce a different dependency combination from the one used by its author. Before importing NetworkHound’s results, the supplied model.json can be uploaded to BloodHound using a companion Python script. This defines distinct icons and colours for sites, subnets, devices, websites and file shares, making the resulting graph considerably easier to read.

There is an important technical distinction here. NetworkHound’s current model is uploaded through BloodHound’s custom-node endpoint and primarily defines generic node appearance. BloodHound’s current documentation separates generic OpenGraph data from structured extensions: generic graphs support node search and Cypher queries, while integrated pathfinding and relationship-based analysis require a structured extension schema. NetworkHound users should therefore treat the output first as a searchable and queryable topology graph, rather than assuming every custom relationship will automatically participate in BloodHound’s standard attack-path features. That does not make the graph less useful. It simply means the analyst still has work to do.

This hound is not quiet

NetworkHound performs active discovery. Depending on the selected options, it may send ICMP probes, open TCP connections across many ports, make HTTP and HTTPS requests, inspect certificates and attempt SMB authentication or share enumeration. Increasing the thread count can make the operation faster, but it also increases the rate at which the network is touched. This is not a passive sensor and it is not designed to be invisible. Monitoring tools, firewalls, endpoint products and attentive administrators may notice it. Run it only against systems you are authorised to assess, define the scope carefully and start with conservative port and thread settings.

The -Pn option deserves particular attention. One section of the README incorrectly describes it as scanning only hosts that answer a ping, while another section says it skips the ping check. The current code confirms the latter: -Pn treats every supplied address as potentially live and proceeds without waiting for an ICMP response. On a large subnet, that can dramatically increase the amount of scanning. The documentation also lists a default scan timeout of three seconds, while the current program sets it to ten. These are small discrepancies, but they matter in a tool that can touch hundreds or thousands of address-and-port combinations.

Still a young project

NetworkHound has the feel of an energetic security project rather than a finished commercial product. The GitHub repository contains no formal release packages despite the version badge in its README. Users currently take the code directly from the repository rather than selecting a packaged, signed release with accompanying release notes. Licensing also needs clarification. Source files and the README describe the project as “Non-Commercial,” but the repository root does not presently contain a conventional licence document spelling out the exact permissions and restrictions. Anyone considering commercial consulting, managed services or incorporation into another product should obtain explicit guidance from the author first.

There is no published security policy in the repository either. That is not unusual for a small project, but it reinforces the need to inspect the code, test it in a controlled lab and avoid feeding high-value credentials into an unfamiliar setup without appropriate precautions. None of these issues destroys the proposition. They simply define its maturity level.

Who is it for?

NetworkHound makes the most sense for people already comfortable with command-line security tools and BloodHound. A red team can use it to identify systems that fall outside the expected AD picture. A blue team can use the same information to investigate ownership gaps, forgotten services and insecure shares. A consultant can turn an untidy collection of hosts and interfaces into something easier to explain during a technical review.

It is less suitable for anyone expecting a one-click asset-management platform. It has no polished graphical front end of its own, does not continuously monitor changes and should not be mistaken for a vulnerability scanner. Discovering that a service exists is not the same as determining whether it is patched or exploitable. Its job is narrower and more focused: collect the network’s scattered clues and arrange them into a shape that makes sense.

The verdict

NetworkHound is built around a simple truth: official records and operational reality rarely match perfectly. Its strongest idea is not port scanning, DNS resolution or SMB enumeration in isolation. Plenty of tools already perform those jobs. The clever part is combining the results and placing them inside a graph where a subnet, machine, website and file share can be understood as parts of the same environment.

The project still needs tighter documentation, clearer licensing, formal releases and perhaps a fully structured OpenGraph schema with ready-made Cypher queries. It should also be approached as active security tooling rather than a harmless inventory script. Even so, it already offers something valuable. Active Directory can tell you which machines are expected to exist. NetworkHound goes out and asks the network which ones actually answer. And sometimes the machine that should not be there is the most interesting one in the room.