Overview

T1589.003 (Employee Names) is a reconnaissance technique where adversaries collect the names of an organization's employees to support follow-on attacks. Gathered names are used to derive email address formats, build targeted phishing lures, identify high-value individuals, and enumerate potential valid account usernames — all before the attacker ever touches your infrastructure.

Because this activity happens almost entirely in publicly accessible spaces — LinkedIn, company websites, GitHub, conference speaker lists — it rarely generates alerts inside a traditional SOC. However, detecting downstream abuse of harvested names (suspicious OSINT tooling, unusual directory queries, bulk HR data access) is both possible and critical: catching reconnaissance early is one of the few opportunities to disrupt an attack before initial access occurs.

Attacker Perspective

Adversaries treat employee name harvesting as a low-risk, high-reward first step that directly enables phishing, credential attacks, and social engineering.

• LinkedIn scraping via automated tools: Attackers use tools like linkedin2username or CrossLinked to query LinkedIn for employees of a target company and automatically generate common email format permutations (e.g., [email protected]).
• Website and directory enumeration: Tools like theHarvester or Maltego scrape company "About Us" pages, press releases, and public staff directories to extract names, titles, and department affiliations in bulk.
• GitHub and code repository mining: Attackers search GitHub commit histories using patterns like git log --format='%an %ae' or tools like gitrob to extract developer names and associated corporate email addresses from public repositories.
• Active Directory enumeration from an internal foothold: Once inside a network, adversaries use net user /domain, ldapsearch, or BloodHound's SharpHound collector to enumerate all domain user display names and correlate them with harvested external data.

This technique is particularly attractive because it requires no exploitation, leaves no footprint on the victim's systems during the external phase, and directly multiplies the effectiveness of every subsequent attack technique the adversary attempts.

Detection Strategy

Required Telemetry

• Windows Security Event Log — Audit Directory Service Access: Enable via GPO: Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → DS Access → Audit Directory Service Access = Success, Failure. Generates Event ID 4661 (object handle requested) and Event ID 4662 (operation performed on AD object). Required to detect LDAP-based user enumeration.
• Windows Security Event Log — Audit Account Management: Enable via GPO: Advanced Audit Policy → Account Management → Audit User Account Management = Success, Failure. Generates Event ID 4720 (account created), 4722 (account enabled), and 4798/4799 (user/group membership enumerated). Event ID 4798 is especially valuable — it fires when a process enumerates the local groups of a specific user account.
• Windows Security Event Log — Audit Logon Events: Enable Audit Logon = Success, Failure. Generates Event ID 4624 and 4625. Bulk 4625 failures with varying usernames drawn from a name list indicate credential stuffing against harvested names.
• PowerShell Script Block Logging: Enable via GPO registry key: HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging → EnableScriptBlockLogging = 1. Generates Event ID 4104. Captures PowerShell-based AD enumeration commands such as Get-ADUser, Get-ADGroupMember, and ([adsisearcher]) queries.
• Windows Sysmon — Process Creation (Event ID 1): Deploy Sysmon with a configuration that logs all process creation events including full command-line arguments. Captures execution of enumeration tools like net.exe, nltest.exe, dsquery.exe, and ldifde.exe.
• Windows Sysmon — Network Connection (Event ID 3): Logs outbound network connections per process. Enables correlation of enumeration tools making LDAP connections (port 389 or 636) to domain controllers.
• LDAP/Active Directory Query Logs: On Windows Server 2016+ DCs, enable LDAP diagnostic logging: HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics → "15 Field Engineering" = 5. Logs expensive or bulk LDAP queries to the Directory Services event log, which can reveal SharpHound or similar collector activity.
• Web Proxy / Secure Web Gateway Logs: Required to detect outbound connections to known OSINT aggregators or scraping services. Log fields needed: src_ip, dst_domain, url, user_agent, bytes_out, bytes_in, http_method.
• HR/Identity Platform Audit Logs (Workday, BambooHR, Azure AD, Okta): Enable audit logging for all read operations on user directory data. Fields: actor, action, target_resource, timestamp, ip_address. Bulk exports or mass read operations on employee records are high-fidelity signals.
• Linux Auditd (for Linux-based systems or jump hosts): Add rules: -a always,exit -F arch=b64 -S execve -F exe=/usr/bin/ldapsearch -k ldap_enum and -w /etc/passwd -p r -k passwd_read. Captures ldapsearch invocations and reads of local user databases.
• DNS Query Logs: Enable query logging on your internal DNS resolver. Captures lookups for LDAP SRV records (e.g., _ldap._tcp.dc._msdcs.domain.local) which tools like SharpHound generate during DC discovery.

Key Indicators

• Bulk LDAP user queries from non-admin hosts: In Windows Security logs (Event ID 4662), look for Object Type = user with Access = Read Property fired in rapid succession (50+ events within 60 seconds) from a workstation SubjectLogonId. The Properties field will reference attributes like displayName, mail, sAMAccountName.
• Execution of known enumeration binaries: In Sysmon Event ID 1, flag when Image matches any of: net.exe, net1.exe, nltest.exe, dsquery.exe, ldifde.exe, csvde.exe, AdFind.exe. Pay close attention to CommandLine containing strings like user /domain, group /domain, /dclist, or objectcategory=person.
• PowerShell AD enumeration commands: In Event ID 4104 (Script Block Logging), flag script blocks containing Get-ADUser, Get-ADGroupMember, ([adsisearcher]'objectCategory=person'), or Get-NetUser (PowerView). Flag especially if ScriptBlock contains -Filter * or -Properties * indicating bulk retrieval.
• Credential stuffing pattern against AD: In Event ID 4625, flag when a single WorkstationName or IpAddress generates failures against 10 or more distinct TargetUserName values within a 5-minute window. A secondary signal is when the TargetUserName values follow a naming convention pattern (all firstname.lastname format), which suggests list-based attacks.
• SharpHound or BloodHound collection artifacts: In Sysmon Event ID 1, flag processes with Image matching SharpHound.exe or child processes of powershell.exe with CommandLine containing Invoke-BloodHound or -CollectionMethod All. Also flag creation (Sysmon Event ID 11) of files matching *_BloodHound.zip or 20*_computers.json.
• Bulk HR system exports: In identity platform audit logs, flag when action = user.list, directory.search, or equivalent and the query returns more than 100 records in a single session, especially from an IP outside the HR department's known address range.
• Unusual LDAP SRV record lookups: In DNS query logs, flag workstations (non-DC, non-management hosts) querying _ldap._tcp.dc._msdcs.* or _kerberos._tcp.* SRV records, which indicate domain reconnaissance tooling running on that endpoint.
• Outbound connections to OSINT scraping targets (external phase indicator): In web proxy logs, flag dst_domain matching known OSINT aggregators where corporate SSO is not involved, particularly where user_agent appears non-browser (e.g., python-requests, Go-http-client, curl) combined with large bytes_in responses.

Detection Logic

Rule 1: Bulk Active Directory User Enumeration from Workstation
IF event_id = 4662 AND object_type = "user" AND access_mask CONTAINS "Read Property" AND subject_logon_id NOT IN [known_admin_logons] AND source_host NOT IN [dc_list, admin_workstations] THEN count(event_id) BY subject_logon_id, source_host WITHIN 60s IF count > 50 THEN alert(HIGH)

Catches bulk LDAP reads of user objects consistent with SharpHound, AdFind, or ldifde bulk exports. Expected volume is low in most environments — fewer than 5 alerts per week. Tune the threshold based on your domain size; larger enterprises may need a higher count threshold.

Rule 2: Suspicious AD Enumeration Binary Execution
IF event_id = 1 AND image IN ["net.exe","net1.exe","dsquery.exe","nltest.exe","AdFind.exe","ldifde.exe","csvde.exe"] AND command_line MATCHES_ANY ["user /domain","group /domain","/dclist","objectcategory=person","objectclass=user"] AND parent_image NOT IN ["explorer.exe","cmd.exe" WHERE parent_user IN [it_admin_group]] THEN alert(MEDIUM)

Catches explicit command-line enumeration of domain users. Net.exe with /domain flags is extremely common in admin workflows, so expect moderate false positives until parent process and user exclusions are tuned. Focus initial investigation on executions where the parent process is an Office application, browser, or script interpreter.

Rule 3: PowerShell Bulk User Enumeration via Script Block
IF event_id = 4104 AND script_block_text MATCHES_ANY ["Get-ADUser","Get-NetUser","([adsisearcher]","Invoke-BloodHound","Get-ADGroupMember"] AND script_block_text MATCHES_ANY ["-Filter \*","-Properties \*","-CollectionMethod"] AND user NOT IN [approved_admin_accounts] THEN alert(HIGH)

Catches PowerShell-based AD enumeration including PowerView and BloodHound's PowerShell wrapper. High-fidelity rule — the combination of a bulk filter flag with an enumeration cmdlet is rarely legitimate outside scheduled admin scripts. Expect very low false positive volume if service account exclusions are applied.

Rule 4: Credential Stuffing Against Domain Using Name-Format Usernames
IF event_id = 4625 AND failure_reason = "Unknown user name or bad password" AND target_username MATCHES_REGEX "^[a-z]+\.[a-z]+$" THEN count(DISTINCT target_username) BY source_ip, workstation_name WITHIN 5m IF count > 10 THEN alert(CRITICAL)

Catches downstream abuse of harvested employee names as username lists in password spraying or stuffing attacks. The regex filter on firstname.lastname format dramatically reduces noise from typo-based failures. Expected volume is very low — any trigger warrants immediate investigation.

Tuning Guidance

• IT and security admin workstations running legitimate AD management tools: Tools like Active Directory Users and Computers (ADUC), RSAT, and identity governance platforms (SailPoint, Saviynt) routinely generate bulk LDAP reads. Exclude by adding source_host IN [approved_admin_workstations] and user IN [it_admin_group, identity_governance_service_accounts] to Rules 1 and 2. Maintain a documented and reviewed allow-list.
• Scheduled HR sync and provisioning scripts: Azure AD Connect, Okta provisioning agents, and HRIS integration scripts generate high volumes of user object reads on a predictable schedule. Exclude by user IN [sync_service_accounts] and optionally add a time-of-day window condition. Validate the schedule matches observed behavior.
• Security tooling (vulnerability scanners, EDR, SIEM forwarders): Some security products perform periodic AD inventory. Identify their service accounts and host IPs and add to exclusion lists. Review quarterly to ensure the list doesn't become a blind spot.
• Net.exe use by help desk staff: net user /domain username is commonly run by tier-1 analysts to check account status. Distinguish this from bulk enumeration by requiring the alert threshold to exceed single-user lookups — flag only when more than 10 distinct usernames are queried in a session from the same host.
• Developer environments running local LDAP testing: Developers may run ldapsearch or PowerShell AD queries against test environments. Exclude known dev lab subnets from internal enumeration rules, but ensure those subnets cannot reach production domain controllers.

When the Alert Fires: Investigation Steps

1. Verify the alert is real — confirm the raw event exists in the source log. Pull the raw event directly from your SIEM by querying the specific Event ID, timestamp, and host name identified in the alert. Confirm the fields (e.g., SubjectLogonId, CommandLine, ScriptBlockText) match what the detection rule evaluated — rule logic errors can produce phantom alerts.
2. Identify the affected host and user — flag if privileged. Extract the source_host, subject_user_name, and subject_logon_id from the event and cross-reference against your identity provider (Active Directory, Azure AD, or Okta) to determine the user's role, department, and group memberships. Escalate immediately if the account is a member of Domain Admins, IT staff, or any service account with elevated rights.
3. Pull the full command-line and parent process chain. Query Sysmon Event ID 1 in your SIEM for all processes spawned on the affected host in the 30 minutes surrounding the alert, filtered by the same LogonId. Build the parent-child tree: if an enumeration binary like net.exe was spawned by powershell.exe which was spawned by winword.exe or a browser, treat this as a confirmed compromise indicator.
4. Check for network connections and files written to disk. Query Sysmon Event ID 3 for outbound connections from the affected host around the time of the alert, looking specifically for connections to domain controller IPs on port 389 (LDAP) or 636 (LDAPS), and any external IPs. Simultaneously query Sysmon Event ID 11 (File Create) for newly created files matching patterns like *.zip, *bloodhound*, *_users.json, or *.csv in temp or user-writable directories.
5. Determine the scope of enumeration — what data was accessed. If LDAP diagnostic logging is enabled, query the Directory Services event log on the domain controller that handled the connection for queries during the alert window. Identify which attributes were requested (e.g., displayName, mail, memberOf) and the total number of user objects returned — this tells you exactly what the attacker now knows about your environment.
6. Search for lateral movement from this host. Query Windows Security Event ID 4624 (Type 3 — Network logon) and Event ID 4648 (explicit credential use) on all domain controllers and neighboring hosts, filtered for the affected user's LogonId or source IP in the 4 hours following the enumeration event. Also check Sysmon Event ID 3 for SMB connections (port 445) or WinRM connections (port 5985) originating from the affected host to other internal systems.
7. Escalation decision — what separates a confirmed incident from benign activity. Treat the activity as a confirmed incident requiring immediate containment if any of the following are true: the enumeration tool (e.g., SharpHound, AdFind) is not an approved IT tool; the enumerating account is not in the IT or security team; a file containing user data was created and subsequently transferred over the network; or credential stuffing alerts fired within 24 hours of the enumeration event. If the activity matches a known admin workflow and no network transfer occurred, document it as a true positive with no malicious intent and work with the admin to shift that activity to a monitored service account.

Response Playbook

Containment

• Isolate the affected host at the network layer — keep it powered on. Apply a firewall policy or NAC quarantine VLAN to block all inbound and outbound traffic except to your forensic collection infrastructure. Do not power off the machine; volatile memory may contain attacker tools, injected code, or decrypted credentials that are critical for investigation.
• Disable the affected user account immediately. In Active Directory, run Disable-ADAccount -Identity [username] or use the Azure AD portal to block sign-in. If the account is a service account, coordinate with application owners before disabling to avoid service disruption — but do not delay more than 30 minutes waiting for approval if active exfiltration is suspected.
• Invalidate all active sessions for the affected account. In Azure AD, use the "Revoke Sessions" function in the portal or run Revoke-AzureADUserAllRefreshToken -ObjectId [objectId]. For on-premises environments, force a Kerberos TGT reset by running Invoke-ADServiceAccountPasswordReset or manually resetting the account password, which invalidates existing Kerberos tickets after the ticket lifetime expires (default 10 hours — consider temporarily reducing this in Group Policy if active compromise is confirmed).
• Block identified C2 IPs and suspicious external destinations. Push block rules to your perimeter firewall and DNS sinkhole for any external IPs or domains identified in Sysmon Event ID 3 or proxy logs during the alert window. For DNS, add the domains to your internal DNS blocklist or Secure DNS policy immediately.
• Kill any active malicious processes on the isolated host. If EDR is deployed (CrowdStrike, Defender for Endpoint, SentinelOne), use the remote response capability to terminate identified malicious processes by PID without destroying forensic artifacts. If EDR is unavailable, wait until the host can be accessed physically or via an out-of-band management channel.

Eradication

• Remove identified persistence mechanisms. Check and clean the following locations: Scheduled Tasks (schtasks /query /fo LIST /v or Task Scheduler GUI), registry run keys (HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run and the HKCU equivalent), startup folder (%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup), and Windows Services (sc query type= all). Remove any entries not recognized as legitimate.
• Search for and delete dropped enumeration tools or payloads. Query your EDR or Sysmon Event ID 11 logs for all files created on the affected host in the 24 hours before and after the alert. Hash any suspicious files and submit to VirusTotal. Delete confirmed malicious files and document their paths and hashes as IOCs for future detection rules.
• Reset credentials for all accounts that executed or were touched by the malicious activity. This includes the primary affected account, any accounts whose credentials may have been cached on the host (check LSASS credential cache indicators via EDR), and any service accounts used to run enumeration tools. Use a secure, out-of-band channel to communicate new credentials to affected users.
• Search for additional backdoors on any lateral movement targets identified in Step 6. Run your EDR's threat hunting query or a Sysmon-based hunt across all hosts the affected user authenticated to, looking for the same IOCs (file hashes, process names, registry keys) discovered on the primary host.
• Rotate any API keys, secrets, or tokens that may have been exposed. If the enumeration accessed systems where credentials were stored in plaintext, environment variables, or configuration files — including HR systems, LDAP bind accounts, or cloud identity providers — rotate those secrets immediately. Notify the relevant application and platform owners.

Recovery

• Verify the host is clean before reconnecting to the network — re-image if confidence is low. Run a full EDR scan and manually review persistence locations. If any doubt exists about the completeness of eradication (particularly if the dwell time before detection exceeded 24 hours), re-image the endpoint from a known-good baseline rather than attempting cleanup. A compromised host that re-enters the network is more dangerous than the delay of re-imaging.
• Re-enable the user account only after confirming no persistence remains and credentials are reset. Document the re-enablement action with a ticket number and the analyst who approved it. Notify the user's manager and set an expectation that the account will be under enhanced monitoring for the next 72 hours.
• Monitor the previously affected host and user for 72 hours post-remediation. Create a temporary watchlist in your SIEM containing the host name, user account, and any identified IOC hashes. Set alerts for any recurrence of flagged behaviors at a lower threshold than the original detection rule. Assign a specific analyst to review these alerts daily for the monitoring period.
• Document the full attack timeline and close the incident with a written lessons-learned review. Record the first evidence of enumeration, every action taken during investigation and response, and the total scope of data accessed. Distribute the lessons-learned summary to the SOC team and, where applicable, to IT, HR (if employee data was accessed), and executive leadership.
• Review and update detection rules based on new IOCs and attacker TTPs observed. If the attacker used a tool or command pattern not covered by existing rules, create a new detection or update the tuning on existing rules. If the attacker evaded detection for a period, identify the telemetry gap and prioritize closing it. Submit new IOCs (file hashes, C2 domains, attacker IPs) to your threat intelligence platform and share with your ISAC if appropriate.