When securing any environment, be it physical or digital, it's important to have an understanding of the components that make up that environment. While organisations may try to keep a tight handle on what devices are allowed in their environment by maintaining asset lists, network-related policies and network access control systems (Microsoft NAP, PacketFence, etc.), potential gaps in such defenses and the proliferation of BYO devices in enterprise environments can result in unsecured hosts or unwanted guests on your network.
Below we’ll take a look at some potential sources of information when trying to identify what hardware, OS or application is responsible for creating network traffic. This is not an exhaustive list, but should give an indication of just how much can be gleaned from network traffic if one knows where to look and has the right tools that enable metadata extraction and exploration.
Ethernet connected devices are ultimately identified using a MAC address. This address is 6 octets in length, the first 3 of which are an Organizationally Unique Identifier, or OUI. This identifier is assigned by IEEE to vendors/manufacturers of network interfaces, and allows for the identification of a network interfaces source. Though there are thousands of vendors/manufacturers represented in IEEE's OUI list, in a typical environment one would only expect to see perhaps dozens of unique OUIs. As such, unauthorized devices may be conspicuous depending on their manufacturer.
Below we can see ARP traffic originating from a device with an OUI of 00:15:17. This is OUI is associated with Intel Corporation.
User-agent (UA) strings are provided by a client to a server in order to elicit a platform-appropriate response from the server, e.g., on a mobile platform, the user-agent string will let the server know to respond with a version of a website appropriate for such a device. User-agent strings utilised by browsers generally take the form, however, there are no assurances that this format will be adhered to by all clients:
Mozilla/[version] ([system and browser information]) [platform] ([platform details]) [extensions]"
As an example, at the time of writing, my Chrome browser presents the following UA when communicating over HTTP:
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36"
This shows, among other things, that I'm running a 64-bit build of Chrome 68.0.3440.106 on a Windows 10 machine.
HTTP traffic can also include a Server value, which describes the device serving up data to a client, e.g., below we can see the Server value for a Jetty webserver, version 5.1, running on a Linux box using kernel 3.5:
Quick UDP Internet Connections, or QUIC, is a UDP based protocol used for encrypted web traffic. Although QUIC is ostensibly an alternative to traditional TCP based HTTPS traffic, its design includes the provision of a user-agent string in its initial hello. This takes a somewhat different form than the UA strings used in HTTP, but can be similarly revealing.
Below we can see a QUIC connection being created to googleapis.com by a Intel-based Apple MAC running OSX 10.13.4 (High Sierra) and Google Chrome version 68.
Simple Service Discovery Protocol, or SSDP, is a UDP-based, HTTP-esque protocol used for zero-configuration networking (zeroconf) by products such as Google's Chrome. SSDP traffic includes a couple of potential sources of identifying information:
Below we can see traffic emanating from a Windows machine running Chrome, version 67.
Multicast Domain Name Service, or mDNS, is a multicast form of DNS used by software such as Apple's Bonjour.
Query responses can contain quite a lot of information about the source device, e.g., the device’s name, OS and even details about the device’s hardware.
Below we can see values extracted from various systems emitting mDNS traffic:
|Linux VM||OS=Debian GNU/Linux 9.5
HW=VMware Inc. VMware Virtual Platform
|Linux Workstation||OS=Ubuntu 16.04.2 LTS
HW=Dell Inc. Precision Tower 3420
|Apple MacBook Pro||model=MacBookPro14,2
Hypertext Transfer Protocol Secure, or HTTPS, is an encrypted form of HTTP which leverages TLS/SSL. The encrypted nature of the traffic makes it inherently opaque, and it’s (mostly) designed in such a way as to minimise the amount of data it divulges to anyone listening in. However, while HTTPS data doesn’t explicitly describe the source of traffic, analysis of the traffic can reveal patterns from which such information can be derived.
To this end, JA3 (named after the JA initials of its three creators) is a method which may be used to fingerprint TLS connections based on the settings used by the connection instantiator in the initial Client Hello. By looking at the TLS version, selected cipher suites, extensions, elliptic curves and elliptic curve point format, a fingerprint can be generated which may be capable of uniquely identifying the application or platform responsible for initiating the connection.
Below we can see a JA3 detection of a Meterpreter HTTPS-based shell.
Dynamic Host Configuration Protocol, or DHCP, is a protocol used by a networked device to communicate with a related server in order to be allocated an IP address.
DHCP has two potential sources of identifying information.
Below we can see an example of DHCP traffic from a device running a Microsoft OS; note the vendor class ID of MSFT 5.0. The parameter list "1,3,6,15,31,33,43,44,46,47,121,249,252" indicates that this is specifically running Windows 10.
Understanding what devices are on your network can provide context to your analysis or investigations, and can help you detect intruders. Corvil provides access to this data, and thus can help you better understand the nature of the ecosystem you’re trying to secure.