Refocusing on Research

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.

Unauthenticated NetBIOS Discovery

Rumble NetBIOS Discovery

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.

Opportunistic SNMP Enumeration

Rumble SNMP v3 Discovery

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.

DNS Upstream Resolver Detection

Rumble DNS Resolver Discovery

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.

Similar Content

Server Message Block Research The Rumble scan engine received big updates this month for the HTTP, RDP, and SMB protocols. The SMB work was focused on improving protocol support for SMB1, SMB2, and SMB3, including better desktop/server detection, and reporting of available compression methods in SMB3 (to support CVE-2020-0796 investigations). One thing that stood out during this work was the SMB2 SessionID field. Similar to a web application session, this field is allocated by the server and used to identify an authenticated session.
Earlier this week, Gerry Gosselin and Eric Rioux of VertitechIT were investigating a strange result in the Rumble asset inventory; After scanning an external subnet with Rumble, they noticed that the main internet router was responding to SNMP probes on its normal address and HSRP address. The router in question had a strong SNMP v2 community as well an IP ACL on the SNMP service. Rumble still reported the router vendor, manufacturing date, and MAC address via SNMP, all unauthenticated and from the internet.

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.