Overview

Domain Properties reconnaissance (T1590.001) is the act of collecting publicly available information about an organization's registered domains — including WHOIS records, registrar details, administrative contacts, name servers, and associated email addresses. Attackers use this data to map the target's digital footprint before launching more targeted attacks such as spear-phishing, infrastructure impersonation, or credential harvesting.

Because most of this activity occurs against public data sources — WHOIS databases, DNS registries, cloud identity endpoints — it leaves little trace in traditional perimeter logs. However, attackers who automate or tool-assist this phase do leave detectable artifacts on endpoints and in cloud audit logs, making it critical for SOC teams to instrument both host-based and identity-layer telemetry to catch early-stage reconnaissance before it converts into an intrusion.

Attacker Perspective

Before launching any targeted attack, adversaries map their target's domain properties to identify contacts for phishing, discover infrastructure relationships, and find weak points in domain registration hygiene.

• WHOIS automation: Attackers script bulk lookups using tools like whois, amass, or theHarvester to collect registrant email addresses, phone numbers, and registrar details across all domains owned by the target organization.
• Azure/O365 tenant enumeration: Attackers query Microsoft's unauthenticated endpoints — specifically https://login.microsoftonline.com/<domain>/v2.0/.well-known/openid-configuration and GetUserRealm — to confirm whether a domain is federated, managed, or using a third-party identity provider.
• Passive DNS and certificate transparency: Tools like dnsx, subfinder, and queries to crt.sh enumerate subdomains and historical DNS records, revealing shadow IT, staging environments, and forgotten assets.
• Crassus execution on-host: In post-compromise scenarios or insider threat situations, the tool Crassus.exe is executed locally to enumerate domain-related privilege escalation paths by inspecting PE metadata, DLL search order weaknesses, and domain trust configurations.

This technique is attractive to attackers because it requires no authentication, generates no alerts on the victim's systems in its most passive form, and directly feeds every subsequent phase of the attack lifecycle from phishing to infrastructure setup.

Detection Strategy

Required Telemetry

• Windows Process Creation Events (Event ID 4688): Enable via GPO: Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → Detailed Tracking → Audit Process Creation = Success. Also enable command-line logging via GPO: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit → ProcessCreationIncludeCmdLine_Enabled = 1. Without command-line capture, you see process names but not arguments.
• Sysmon Event ID 1 (Process Create): Deploy Sysmon with a configuration that captures Image, CommandLine, ParentImage, ParentCommandLine, User, and Hashes. Sysmon provides richer metadata than native 4688 events and is the preferred source for endpoint detection.
• Sysmon Event ID 3 (Network Connection): Required to detect outbound connections to WHOIS servers, DNS reconnaissance APIs, or cloud identity endpoints made by suspicious processes. Ensure NetworkConnect is enabled in your Sysmon config.
• Sysmon Event ID 7 (Image Loaded) and Event ID 25 (Process Tampering): Useful for detecting renamed or masqueraded binaries that share Crassus characteristics.
• Windows Defender / EDR Telemetry: Most EDR platforms (CrowdStrike, Defender for Endpoint, SentinelOne) emit process events with PE metadata fields including OriginalFileName and FileDescription — critical for catching renamed Crassus binaries where Image doesn't match the known filename.
• Azure AD / Entra ID Sign-In and Audit Logs: Enable and forward to SIEM via Azure Diagnostic Settings. Specifically, the AADNonInteractiveUserSignInLogs and AADServicePrincipalSignInLogs tables capture automated queries to identity endpoints. Look for anonymous or unauthenticated requests to GetUserRealm and autodiscover endpoints in your web application firewall or reverse proxy logs.
• DNS Query Logs: Enable DNS debug logging on Windows DNS servers (dnscmd /config /logLevel 0x8100) or deploy Sysmon Event ID 22 (DNS Query). This catches local processes performing internal domain enumeration.
• Web/Proxy Logs: Capture outbound HTTP/HTTPS requests including full URL, user-agent, source host, and destination. Required to detect queries to crt.sh, WHOIS REST APIs, Shodan, or Microsoft identity endpoints.

Key Indicators

• Known tool binary name — Sysmon EID 1 or EDR: Field Image ends with \Crassus.exe, OR field OriginalFileName equals Crassus.exe, OR field Description contains Crassus. This catches both native and renamed executions.
• WHOIS client execution — Sysmon EID 1: Field Image contains whois.exe or whois64.exe with CommandLine containing a domain name pattern (e.g., whois.exe contoso.com). Also watch for nslookup.exe, dig.exe, or host.exe invoked with external domain arguments by non-admin users.
• Scripted reconnaissance tools — Sysmon EID 1: CommandLine contains strings like amass enum, theHarvester -d, subfinder -d, dnsx -d, or python -m theHarvester. These tools are rarely present on managed corporate endpoints.
• Outbound connections to WHOIS/recon infrastructure — Sysmon EID 3: Field DestinationPort equals 43 (WHOIS protocol) from any endpoint other than dedicated IT management hosts. Also flag DestinationHostname matching crt.sh, whois.arin.net, api.shodan.io, dnsdumpster.com, or viewdns.info.
• Azure identity endpoint probing — Proxy/WAF logs: HTTP GET requests to https://login.microsoftonline.com/<any_domain>/v2.0/.well-known/openid-configuration, https://login.microsoftonline.com/GetUserRealm.srf?login=<email>, or https://autodiscover.<domain>/autodiscover/autodiscover.json from unauthenticated or external sources. Field user_agent containing python-requests, curl, Go-http-client, or blank is a strong indicator of scripted enumeration.
• Suspicious parent process spawning recon tools — Sysmon EID 1: ParentImage is cmd.exe, powershell.exe, or wscript.exe and child Image is nslookup.exe or whois.exe — particularly when User is not a known IT admin account.
• PowerShell domain enumeration — PowerShell Script Block Logging (Event ID 4104): Enable via HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging → EnableScriptBlockLogging = 1. Watch for script block content containing Resolve-DnsName, Get-ADDomain, nltest /domain_trusts, or web requests to WHOIS APIs like Invoke-WebRequest -Uri "https://api.whois.arin.net.

Detection Logic

Rule 1 (High Sensitivity — Broad Net): Any outbound WHOIS protocol connection from a non-IT endpoint
IF event_id = 3 AND destination_port = 43 AND source_host NOT IN [approved_it_hosts] THEN alert(severity=medium)

This catches any process making a raw WHOIS query. Expected volume is low in most environments — WHOIS on port 43 is almost never used by standard business applications. Expect occasional false positives from developer workstations running pentesting tools legitimately.

Rule 2 (Medium Sensitivity — Recon Tool Execution): Known reconnaissance tool executed on a Windows endpoint
IF event_id IN [1, 4688] AND (image ENDSWITH "\Crassus.exe" OR original_filename = "Crassus.exe" OR description CONTAINS "Crassus" OR commandline CONTAINS "amass enum" OR commandline CONTAINS "theHarvester -d" OR commandline CONTAINS "subfinder -d") THEN alert(severity=high)

This rule targets named tools that have no legitimate enterprise use. Alert volume should be near zero; any trigger warrants immediate investigation. The original_filename field catches renamed binaries — prioritize EDR telemetry over native Windows logs for this field.

Rule 3 (Medium Precision — Scripted Azure Identity Probing): Automated enumeration of Microsoft identity endpoints
IF log_source = "proxy" AND url CONTAINS "GetUserRealm" OR url CONTAINS "openid-configuration" AND user_agent IN ["python-requests", "curl", "Go-http-client", ""] AND request_count > 10 WITHIN 5 minutes THEN alert(severity=high)

Legitimate browser-based logins also hit these endpoints, so the user-agent filter and request rate threshold are critical to suppress noise. A single request from a browser is benign; ten requests in five minutes from a scripted client against different domain variants is enumeration.

Rule 4 (High Precision — Crassus PE Metadata Match Regardless of Filename): Execution of any binary with Crassus internal metadata
IF event_id = 1 AND (original_filename = "Crassus.exe" OR file_description CONTAINS "Crassus") AND image NOT ENDSWITH "\Crassus.exe" THEN alert(severity=critical)

This specifically catches adversaries who rename Crassus to blend in (e.g., svchost_helper.exe). The mismatch between the disk filename and the PE's embedded OriginalFileName field is a reliable masquerading indicator. Requires EDR or Sysmon with PE metadata enrichment. Expected volume: effectively zero false positives.

Tuning Guidance

• IT and security team workstations running legitimate recon tools: Penetration testers, threat intelligence analysts, and sysadmins may run whois, nslookup, or amass legitimately. Exclude by user IN [approved_pentest_accounts] or source_host IN [security_team_hosts], and require that these exclusions are tied to a change ticket window rather than being permanent.
• Developers querying DNS for debugging: nslookup.exe and Resolve-DnsName are commonly used by developers troubleshooting connectivity. Narrow your rule by also requiring parent_image to be something unexpected (e.g., cmd.exe spawned from explorer.exe rather than an IDE process) or restrict to external domain targets only.
• Azure AD Connect and identity sync services: These services legitimately call GetUserRealm and OpenID configuration endpoints during normal sync operations. Exclude by source_ip IN [aad_connect_server_ips] and user_agent CONTAINS "AADConnect".
• Monitoring and vulnerability scanners: Enterprise scanners like Qualys, Tenable, or Rapid7 may query domain metadata as part of asset discovery. Exclude by source_ip IN [scanner_ip_range] rather than by hostname, as scanner hostnames can be spoofed.

When the Alert Fires: Investigation Steps

1. Confirm the raw alert event exists in the source log. Pull the original event from Sysmon, your EDR console, or the proxy log using the event timestamp and host identifier — confirm the Image, OriginalFileName, and CommandLine fields match what the alert fired on, ruling out a parsing or forwarding artifact.
2. Identify the affected host and user account. In your SIEM, enrich the User field against your identity store — flag immediately if the account has elevated privileges (Domain Admin, Global Admin, service account) as this dramatically raises the risk tier and may indicate a compromised privileged session.
3. Pull the full process tree and command-line arguments. Using Sysmon EID 1 or your EDR's process tree view, trace from the suspicious process back to its root parent — look for unusual chains such as winword.exe → cmd.exe → Crassus.exe or wscript.exe → powershell.exe → subfinder.exe, which indicate execution triggered by a document or script rather than a human typing.
4. Check for outbound network connections from the triggering process. Query Sysmon EID 3 or EDR network telemetry for any connections made by the process or its children within a 30-minute window — specifically look for connections on port 43 (WHOIS), port 80/443 to reconnaissance sites (crt.sh, dnsdumpster.com, shodan.io), or unusual Microsoft identity endpoints.
5. Examine files written to disk during and after execution. Using Sysmon EID 11 (File Create) or EDR file telemetry, search for any output files dropped in %TEMP%, %APPDATA%, or user-writable directories within the same timeframe — recon tools often write results to disk before exfiltration, and finding a file named output.txt or domains.csv alongside tool execution is high-confidence confirmation.
6. Look for lateral movement from the affected host. Query Windows Security EID 4648 (explicit credential use), EID 4624 Type 3 (network logon), and Sysmon EID 3 for SMB/RDP connections originating from the host in the 24 hours following the alert — cross-reference destination hosts to determine if the attacker attempted to pivot after completing domain reconnaissance.
7. Make the escalation decision based on context. If the tool is Crassus or a named recon framework with no approved change ticket, the parent process chain is suspicious, and network connections to external recon infrastructure are present — escalate to a confirmed incident immediately. If the process was spawned interactively by a known IT admin account during a documented maintenance window with no external connections, treat as a policy violation and close with a tuning note.

Response Playbook

Containment

• Isolate the host at the network level — do not power it off. Use your EDR console (CrowdStrike Network Containment, Defender for Endpoint Isolate Device, or SentinelOne Network Quarantine) to cut network access while preserving the live memory state for forensics. If no EDR isolation is available, coordinate with network team to null-route the host's IP at the switch or firewall level.
• Disable the affected user account immediately. In Active Directory: Disable-ADAccount -Identity <username>. In Azure AD/Entra ID: revoke all active sessions via the Azure portal under the user's Authentication Methods blade — click "Revoke Sessions" to invalidate existing tokens without waiting for expiry.
• Block identified external reconnaissance destinations at the firewall and DNS. Push block rules for any IPs or domains the host communicated with (identified in step 4 of investigation). At the DNS layer, add NXDOMAIN overrides for identified recon domains in your internal DNS resolver to prevent other hosts from reaching the same infrastructure.
• Kill the malicious process if still running. From the EDR console or via a remote session to the isolated host, terminate the process by PID: taskkill /PID <pid> /F. Document the PID, process name, and parent PID before killing it — this metadata is needed for the eradication phase.

Eradication

• Locate and delete the tool binary and any output files. Based on the file paths identified in Sysmon EID 11 during investigation, remove the Crassus or recon tool executable and any output files it created. Run a hash-based scan across the environment using the file hash from your EDR to detect copies on other hosts: in Defender for Endpoint use Live Response run av-scan.ps1 or submit the hash to the Indicator block list.
• Audit and remove any persistence mechanisms installed. Check Autoruns categories on the affected host — specifically HKCU\Software\Microsoft\Windows\CurrentVersion\Run, scheduled tasks (schtasks /query /fo LIST /v), and new services (sc query type= all state= all). Remove any entries created after the time of initial compromise.
• Reset credentials for the affected account and any accounts whose credentials may have been accessed. Force a password reset for the triggering user via Set-ADAccountPassword and require re-enrollment of MFA. If Crassus or similar tools accessed credential stores (LSASS memory, SAM hive, or credential manager), treat all local accounts on that host as compromised and reset them.
• Rotate any API keys, secrets, or service account tokens that were accessible from the compromised host. Check the host's environment variables, configuration files, and browser-stored credentials for API keys to cloud services, domain registrars, or internal systems — rotate all of these immediately and audit their usage history for unauthorized calls.

Recovery

• Re-image the host if confidence in full eradication is below high. If the process tree showed suspicious parent chains, if multiple tools were found, or if the host was compromised for more than a few hours before containment, do not attempt cleanup — re-image from a known-good golden image and restore user data from pre-incident backup only after scanning that backup.
• Reconnect the host to the network only after a clean bill of health. Run a full EDR scan and verify no detections, confirm no new autoruns entries exist, and have a second analyst review the Sysmon baseline before removing network isolation. Document this sign-off in your ticketing system.
• Re-enable the user account only after credential reset and MFA re-enrollment are confirmed complete. Brief the user on what happened and instruct them to report any further anomalies — do not restore the account silently.
• Monitor the affected host and user account for 72 hours post-recovery. Create a temporary high-sensitivity watchlist in your SIEM scoped to the host IP and user account — alert on any process execution, network connection, or authentication event that deviates from the established baseline during this window.
• Conduct a lessons-learned review and update detection rules. Document the full attack timeline from first artifact to containment. Capture any new IOCs (file hashes, IPs, user-agent strings) and add them to your threat intelligence platform. Review which detection rules fired first, which missed the activity, and update tuning exclusions based on any false positives encountered during the response.