Things I'd do if I ever have time

Wish list

Please help a man further his career by donating expensive hardware. Cash works too.

Public Hotspots and Corporate Laptop Ownership Clues

Published: 06/13/2010

Reference trace file:

Everyone knows that Windows machines can be readily identified when scanning a network because it's so chatty and broadcasts all kinds of messages out in the open. One would think that Windows 7 improves upon this issue, but it doesn't. Let's also take things one step further - if you have a machine that's a member of an Active Directory domain, would it be easily identifiable as such by someone sniffing the air or wire?

In another article that I'm working on, I took a newly-imaged Windows 7 laptop and added it to an AD domain. Let's see what happens when we associate this machine to some public hotspot (simulated here for legal reasons) and what kind of scatter traffic our it sends out over the air...

Microsoft Windows, the network blabbermouth

So in our trace file we have a ten-minute Wi-Fi session which simulates a traveling corporate user connecting to an airport coffee shop's wireless network and afterward does ... nothing. This is just to get a baseline reading of what the machine itself does so we completely remove the human element out of the equation (other than making the conscious effort to connect to the hotspot). I've also filtered out some 802.11 frames from the trace, aside from the Authentication and Association frames.

The first four frames show the basic Wi-Fi association process. Here we have a Cisco access point with the SSID "PublicHotspot." We can ignore packet 5 since it's just an IGMP multicast from the AP. At packet 6, Windows 7 sends out a couple of ICMPv6 packets from its link-local IPv6 address to ff02::16, the all-MLDv2 (Multicast Listener Discovery) address for participating routers. This is followed by two link-local Multicast Name Resolution queries to ff02::1:3 for the host MYCLIENT01 (which is the name configured on the operating system). It does this quite a few times throughout the trace.

Somewhere along the line, the laptop will inevitably need an IPv4 address. This happens at packet 10. The DHCP Discovery message contains the first IPv4 clue for a nearby snooper that this is a Windows machine since it uses the Vendor class identifier option with a value of "MSFT 5.0." At packet 12, the local DHCP server responds with a DHCP Offer which proposes an address lease for and the DNS suffix "" The client makes the DHCP Request and at packet 15 the server sends the DHCP ACK.

We're not even at the one-second mark into the trace and already we see our first clue that the client is an Active Directory domain member. At packet 22, the client sends out a DNS request for the SRV record It's basically looking for a domain controller, something that would exist only within a private corporate LAN. This an immediate dead-giveaway since Windows hosts which are not members of an AD domain wouldn't care about LDAP services. In addition, we now know the DNS namespace of this machine's AD domain:, so there's an extremely high probability that the user is an employee of ACME Corporation whose best customer is Wile E. Coyote.

The DNS server eventually responds in packet 32 with information about the authoritative nameserver for the domain (which actually does publicly exist, by the way, so my simulated corporate domain namespace wasn't a good choice apparently). Now the client decides to send another DNS request for SRV record, to which the DNS server responds similarly.

Starting at packet 36, we see six legacy NetBIOS Name Service packets start to broadcast out. Of course. This is strangely expected because Microsoft always leaves this protocol enabled after all these years, even though no one cares. It tries to register both its Workstation and Server services for its machine's NetBIOS name (MYCLIENT01). The specific NetBIOS services are determined via the suffix values, in this case <00> and <20>, respectively. Within these we also see two NetBIOS Name Service broadcasts for the NetBIOS name "CORP." This refers to the Active Directory NetBIOS domain name which the machine is a member of. These NetBIOS broadcasts happen quite frequently within the span of the trace. At packet 212, the machine starts looking for a domain controller through NetBIOS, as shown by the suffix value <1c>, and it will continue on and on for the duration of the Wi-Fi session. Incredibly annoying.

I'll skip looking at the rest of the IPv6 traffic in this trace and focus on IPv4. Over the course of the next ten seconds, there are quite a few more DNS queries which provide more indications as to which company this laptop belongs to. Here's the abbreviated list:

You'll also later in the trace eventually see a DNS request for an odd resource record: _VLMCS._TCP in packet 384. This refers to a Microsoft KMS (Key Management Server) which is used in private corporate networks for activating Windows Vista / 7 Enterprise edition installations.

Six seconds into the trace at packet 305, a DNS request is made for, to which the client eventually makes an HTTP request for the file ncsi.txt. This refers to the Network Connectivity Status Indicator feature which allows Windows Vista / 7 to determine whether it has Internet connectivity. The file that gets downloaded only contains the string "Microsoft NCSI."

Windows also makes both NetBIOS and DNS-based queries for WPAD (Web Proxy Automatic Discovery). Some corporate networks may implement this via DHCP option 252, but otherwise I'm unsure why querying this via NetBIOS is needed.

At exactly ten minutes into the session, I manually disconnected from the Wi-Fi network as evidenced by the two 802.11 Deauthentication frames at packets 406 and 407. You would figure Windows would be a good citizen and release the leased IP address beforehand.

Some devices just won't stop talking

Not all operating systems are silent and there are legitimate reasons why they behave the way they do, but in this case there is a total of seventy-five NetBIOS packets, sixty-eight DNS queries sourced from the client, twenty-nine DHCPv6 Solicit packets, thirty-nine ICMPv6 packets, and thirty-four IGMP multicasts. All this without the user doing a single thing.

Some corporate enterprises deploy managed client firewalls which implements limitations on outbound traffic if the machine is located in non-trusted networks (that is, if the network address space doesn't match the private corporate LAN's), but there are plenty of companies which don't. In theory, one could create a set of Group Policy-based outbound rules for Windows Firewall with Advanced Security, but for those who don't have such a solution in place, beware what your road warriors are unintentionally announcing on public networks which anyone can see the contents of from a distance.

Go back to the main articles list.