Our mission is to empower our customers with amazing network visibility through applied research. With the v1.1.0 release behind us, we are excited to renew our focus on research. Last month, our founder and CEO HD Moore presented at Texas Cyber Summit and LASCON X on modern network discovery techniques.
A similar presentation can be found on our Youtube channel.
This post highlights three techniques from this presentation and how Rumble uses them to improve network visibility.
Rumble uses these lightweight, unauthenticated queries over UDP port 137 to identify hostnames, domain names, MAC addresses, and multi-homed devices. For Windows environments where NetBIOS over TCP/IP is enabled, this protocol provides great visibility, even across remote subnets. This capability is so useful that we published an open source tool for it.
Curious about how many systems in your environment expose NetBIOS over TCP/IP? Try this query to get a list of all NetBIOS-enabled systems in your inventory.
SNMP is a fantastic protocol for discovery, but is often a security risk, and many organizations have hardened their SNMP configurations as a result. Rumble supports opportunistic SNMP discovery; pulling information from network devices and servers when default communities are configured for SNMP v1 and v2 and extracting useful data from the pre-authentication stage of SNMP v3. This process allows Rumble to provide additional visibility even when best practices for SNMP have been applied.
Rumble uses this opportunistic discovery mode to obtain neighbor MAC addresses on remote subnets through ARP cache polling, can extract MAC addresses and vendor identifiers from the pre-authentication stage of SNMP v3 devices, and will enumerate port connections and VLAN membership information from switches. The initial discovery probes also leverage “stacked” queries to obtain the most information from each request with the least amount of traffic.
For organizations that use SNMP v2, Rumble scans can be configured with a valid read-only community string to provide even more information across your environment. Authenticated SNMP v3 support is also in the works and should be available later this year.
If you are wondering how many MAC addresses were identified in your environment using remote ARP cache enumeration, try querying for the “snmp.arpcache” source.
The Rumble DNS probe goes beyond basic fingerprinting and tries to identify the upstream resolvers and any EDNS0 Client Subnet data that is passed to the authoritative resolvers. This process works by reflecting a query off of the target caching resolver to a custom DNS server implementation. The returned queries include an encoded version of the upstream resolver source IP addresses and any client subnet data that was sent along with the query. This information can be used to identify misconfigured caching resolvers in your environment and ensure that client subnet information is not being leaked to third-party domain operators.
To get a list of all DNS services with a detected upstream resolver try querying for DNS services with the “resolvers” attribute.
Our last post covered some of the ways that Rumble gathers information from DNS services. While working on the tracer implementation, we identified a trick that other folks might find it useful. It turns out that most DNS resolvers do not filter the address ranges they will contact when handling a request, allowing for remote subnet “ping scans” with a little work. This technique isn’t foolproof, and is probably not new, but it may have interesting security implications.