During these difficult times, users of many organisations find themselves working remotely, away from their usual office locations. For a lot of organisations, this is business as usual, and infrastructure is in place to support secure working practices from remote locations. However, for some, this is uncharted territory, and some ways in which internal data can be leaked are not identified as easily as others.
One of the ways in which potentially sensitive detail can be leaked is via DNS queries for resources that are expected to only exist internally. Such queries often occur automatically as part of “service discovery”, where DNS SRV records are requested, and can potentially “leak” out on to the internet. Whilst the service discovery problem applies to multiple service protocols, we’re going to focus on Lightweight Directory Access Protocol (LDAP) service endpoints.
Typically, a host connected to a local network will utilise the default internal DNS Name Server(s) (NS) to resolve domains related to LDAP services (such as Active Directory). The QNAME for a DNS query for an internal LDAP service is of the form: _ldap._tcp._<internaldomain>.
When a host is unable to connect to their organisation’s internal DNS NS, attempts are made to resolve the LDAP domain(s) via an external DNS NS, such as one owned by their current Internet Service Provider, thereby leaking internal domain information to the internet.
External DNS NS are unable to resolve the internal LDAP domain(s), and therefore return an NXDOMAIN response.
There are certain risks involved when an internal domain name is leaked via DNS SRV records:
Individuals with access to one of the DNS NS utilised in the domain lookup process (which may be recursive or iterative depending on local DNS configuration) for the LDAP domain may acquire insight into the infrastructure of the user’s organisation, and possibly also the location of infrastructure/users.
Additionally, when a user with a corporate device is working remotely and not connected to the organisation’s network, they may be connected to an insecure or untrustworthy internet service provider or local DNS server, thereby opening a potential attack vector.
For example, a corporate user may be staying at a hotel that offers a WiFi service. Many hotels use their own DNS NS to conduct DNS lookups. Should the DNS NS belonging to the hotel become (or already be) compromised, threat actors could acquire logs that may identify a device – and therefore individual – that works for your organisation, as well as any insight the threat actor can gather from the name of the LDAP domains themselves.
We queried Augury, our data analyst’s portal, for internal Passive DNS (PDNS) NXDOMAIN records that occurred during the period of 1100 – 1200 UTC on 21 May 2020, and identified 32,043 distinct LDAP domains belonging to other organisations which were leaked within DNS SRV records.
We identified internal domains belonging to a wide-range of organisations across multiple sectors, showing that this issue is not limited in scope.
One suggestion to prevent these leakages would be to ensure correct configuration of LDAP service discovery records, and if running Active Directory on a server using the Microsoft DNS service, to use the DNS Management Console to verify that the appropriate zones and resource records are created for each DNS zone. However, every infrastructure is different, making it difficult for us to suggest overarching configuration changes to solve this problem for within your organisation. The main aim of this blog post is to inform readers that this problem exists, and to ensure that if you are unable to mitigate the problem, you are aware of the potential risks.