Windows Notepad is a lonely tool. It barely does the job in a pinch, with only the most basic functions you’d expect in a text editor. Older versions drove non-Windows users nuts with its inability to handle CR and LF line endings. There’s no Intellisense-style autocomplete. No auto-detection of languages like XML, JSON, or PHP. And forget about regular expressions for search and replace.
So perhaps it shouldn’t have been surprising when I spun up a Windows Active Directory lab environment, installed Sysinternals Sysmon, and watched Notepad pick up the phone and make a call:
Huh?
Notepad is connecting to the domain controller on its LDAP port.
The phone call is coming from inside the house.
Sure, Notepad can be used to open and save files on remote file shares. But an LDAP query from Notepad to a domain controller? Or, as SANS ISC handler Xavier Mertens wrote recently: “What looks more legit than a process called “notepad.exe” […]?”
Under the hood
This is a lab environment, built with a single Windows Server 2019 domain controller, one Windows Server 2019 file server, and one Windows 10 22H2 domain-joined workstation, all running in VM (VMware Workstation). Patches were applied prior to building the domain and minimal configurations were applied to both systems.
Sysinternals Sysmon 14 was loaded into the environment with Olaf Hartong’s sysmon-modular baseline configuration (sysmonconfig.xml) published in mid-December 2022.
Why Notepad queries LDAP
The observed event is straightforward: notepad.exe initiates a network connection to a domain controller on port 389/tcp. But why would Notepad make an LDAP query?
It turns out the answer is rather mundane: it’s an artifact of the open/save dialog box.
Notepad leverages the standard Windows APIs for opening and saving files, no different from most Windows shell applications. It’s a good programming practice, in addition to implementing a familiar user interface/user experience (UI/UX).
Think about how you use files with a text editor. Do you go through the GUI and double-click files? Invoke notepad.exe from the command line? Or do you open Notepad and use the open/save dialogs?
I had staged a Sysmon XML file on my domain controller — this was an isolated, temporary lab environment, after all — but accidentally opened the local copy on my workstation VM. Rather than exit Notepad, I hit Ctrl+O and typed in the remote file share path of the DC to open the source copy of the file.
It was after this when Sysmon logs showed the network connection event (Figure 1).
If you pay close attention to the file open/save dialog box, you’ll notice that the address bar and file name input boxes support name completion. This extends not only to files and folders, but also remote shares and server names. And remote shares can include the Windows domain’s SYSVOL as well as other Distributed File System (DFS) shares.
Turning on DNS logging with Sysmon, we see that the LDAP connection (Figure 1) is preceded by a DNS lookup for a service record for the domain:
At this point, it’s time to fire up Wireshark and look at the network traffic to get a better picture.
This time, I’m using the open dialog in Notepad, and typing in the UNC path for my test file server (“\\file01”) to show the available shares.
First is the DNS query for the file server, followed by the SMB negotiation to set up the SMB session (SMB and SMB2 protocols). There’s a brief interlude for the workstation to retrieve a Kerberos ticket (KRB5 protocol) from the DC, and then the SMB session setup is completed.
With the SMB session established, we see the workstation enumerating one of the shares (“\\file01\stuff”) on the server. It’s here that we see the DNS request for a service record (_ldap._tcp.pdc._msdcs.ad.rjf), followed by a LDAP query. Microsoft’s specifications show that this DNS record is specifically looking for the primary domain controller hosting the default naming context.
The LDAP query is searching for the Netlogon attribute, a way to determine running services on the DC. The query’s filter is specific to the client (Host=WKS01; DnsHostName=wks01.ad.rjf). The DC’s response provides expected values: ad.rjf (the AD domain), DC01 (the domain controller), and Default-First-Site-Name (the AD site, which hasn’t been changed from its default in this lab environment).
While not shown in these screenshots, there are corresponding DNS queries for the AD site and the DC, generated by Notepad according to Sysmon.
Through additional testing, I could recreate this behavior with a dedicated file server with visible shares; any Distributed File System (DFS) share on a domain; and any share from the previous options, when mapped to a drive letter. It also appears to trigger when one of these shares is pinned to Quick Access in the top-left of the dialog; these locations are typically pre-loaded when the dialog opens, which I’ve seen cause issues when those locations are no longer accessible.
To answer the question of why is Notepad querying LDAP: it’s the file open/save dialog looking for available AD services when a file share is accessed or browsed.
Notepad is still lonely. At least it has the open/save dialog to help keep it company.