At Cisco Live Melbourne 2025, the SOC observed many interesting behaviors from the various clients of the conference network. One of the more interesting ones was observations relates to the DNS traffic emitted by Windows clients on the network, looking for their organization’s Active Directory Domain Controllers. With our Endace full packet capture for the event, we were able to capture DNS traffic from clients on the network and perform analysis using Splunk Enterprise.

As a reminder, when a Windows client is seeking to talk to a domain controller it will make DNS queries for SRV records for names like _kerberos._tcp.dc._msdcs.DOMAINNAME or _ldap._tcp.dc._msdcs.DOMAINNAME. These DNS requests enable the client to find nearby Kerberos or LDAP servers for their domain.

In the Cisco Live Melbourne 2025 SOC, we saw clients send out DNS queries for approximately 3,800 distinct names starting with “_ldap” or “_kerberos”. While most of them returned a failure of some sort (NXDOMAIN or SERVFAIL), approximately 300 had a successful DNS response. Some of these were successful in subsequent attempts to connect to the service (meaning the domain controllers are accessible in some fashion from the public internet), and a few were followed up by cleartext LDAP BINDs, leaking credential information across the local network and Internet. (SEE DANIEL’S BLOG POST)

There are several things to consider from this.

First, there is an open-source intelligence (OSINT) aspect to this. The operators of any wireless network that you connect to with your laptop gain telemetry about your organization.

Second, a malicious wireless network could – depending on how your clients are configured – trick the client into sharing authentication information with it. Tools such as Responder are designed for this purpose. Properly configured modern Windows clients will use SMB signing, LDAP over TLS, LDAP channel binding, and other forms of protection against a hostile network environment. Are you sure your clients are configured in a way that makes them robust against a hostile network?

Third, if your organization has Active Directory domain controllers on the public Internet, are you taking the necessary steps to protect them?

Finally, the Cisco Live network is designed to be a safe network for attendees to use. But that is no guarantee that – elsewhere – the same SSID could not be used to stand up a hostile network. Clients will usually auto-connect when they see a wireless network they’ve connected to before.

One reliable mitigation for all of this is a VPN client. A properly configured VPN client like Cisco Secure Client can support both a full tunnel VPN and “Start Before Login”. With this feature, the client computer connects to the VPN as early as possible. All traffic, including DNS lookups, are sent over the VPN. While this does not eliminate all these risks, it raises the safety bar substantially.

Check out the other blogs by my colleagues in the Cisco Live Melbourne 2026 SOC.

We’d love to hear what you think! Ask a question and stay connected with Cisco Security on social media.

Cisco Security Social Media

LinkedIn Facebook Instagram X

Authors

Cisco Cybersecurity Viewpoints

Where security insights and innovation meet. Read the e-book, see the video, dive into the infographic and more...

Why Cisco Security?

Explore our Products & Services