THREAT-Infra-NewlyRegisteredLookalikeDomain Google Chronicle · YARA-L

Detect First-Seen Resolution of Adversary-Registered Lookalike Domain in Google Chronicle

Before a phishing, business email compromise, or adversary-in-the-middle credential-harvesting campaign can run, the operator must first acquire infrastructure — most commonly by registering a domain that visually or semantically impersonates the target organisation's own brand or a high-value SaaS login surface (identity provider, mail, file sharing, e-signature, HR). Because registration is cheap, automated, and frequently done only hours or days before the campaign launches, the resulting domain has two properties defenders can exploit without any external intelligence feed: it has never before been resolved anywhere in the estate, and its hostname carries both a brand-impersonation token and a credibility/lure token (login, sso, mfa, verify, support) or is encoded in punycode to hide homoglyph substitution. This detection therefore combines a purely internal first-seen (newly-observed-domain) baseline — every registrable hostname resolved or connected to in the preceding 30 days — with a hostname-composition score, and alerts only where a hostname is simultaneously novel to the environment and structurally shaped like impersonation infrastructure. It deliberately avoids domain-age or registrar lookups so it functions in air-gapped and egress-restricted SOCs, and it is scoped to the acquisition/staging boundary: the alert fires on the very first resolution, ideally before any credential is submitted. Note that first-seen alone is far too noisy to alert on (a large estate observes thousands of genuinely new domains daily via ad tech, CDNs, and telemetry endpoints), which is why the composition score is a required second condition rather than an enrichment.

MITRE ATT&CK

Tactic
Resource Development

YARA-L Detection Query

Google Chronicle (YARA-L)
yaral 
rule newly_registered_lookalike_domain_resolution {
  meta:
    author = "Detection Engineering"
    description = "Detects DNS resolution of adversary-registered lookalike domains combining a brand-impersonation token with a credential-lure token or punycode encoding"
    severity = "HIGH"
    confidence = "medium"
    mitre_attack = "T1583.001"
    reference = "https://attack.mitre.org/techniques/T1583/001/"

  events:
    $dns.metadata.event_type = "NETWORK_DNS"
    re.regex($dns.network.dns.questions.name, `(?i)(contoso|okta|entra|microsoft|office365|docusign|adobe|sharepoint|onedrive|workday|zoom|xn--)`)
    re.regex($dns.network.dns.questions.name, `(?i)(login|signin|sso|secure|auth|mfa|verify|account|support|helpdesk|portal|reset)`)
    not re.regex($dns.network.dns.questions.name, `(?i)\.(microsoft\.com|microsoftonline\.com|office\.com|okta\.com|oktacdn\.com|sharepoint\.com|docusign\.net|myworkday\.com)$`)
    $host = $dns.principal.hostname

  match:
    $host over 24h

  condition:
    $dns
}
high severity medium confidence

Chronicle YARA-L 2.0 rule matching DNS questions that carry both a brand-impersonation or punycode marker and a credential-lure token, excluding the impersonated vendors' own registrable domains, grouped per host over a 24-hour match window. Chronicle's first-seen semantics are supplied separately through a prevalence or entity-risk enrichment rather than inline, so pair this with a low-prevalence domain signal to reach the same precision as the Defender implementation.

Data Sources

Google Chronicle SIEMDNS events

Required Tables

NETWORK_DNS

False Positives & Tuning

  • Partner, reseller, and co-branded hostnames legitimately containing a brand token
  • Phishing-simulation platforms resolving deliberately lookalike domains
  • Vendor regional and acquisition domains not present in the exclusion pattern
  • Legitimate internationalised domains encoded in punycode

Other platforms for THREAT-Infra-NewlyRegisteredLookalikeDomain

Microsoft Sentinel (KQL) Splunk (SPL) Elastic Security (Elastic) IBM QRadar (QRadar) Sumo Logic CSE (Sumo) CrowdStrike LogScale (LogScale) All platforms (combined) →

Testing Methodology

Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Resolve a First-Seen Brand-Plus-Lure Hostname

    Expected signal: Sysmon Event ID 22 with QueryName=microsoft-login-verify.atomic-test.invalid, an empty or NXDOMAIN QueryResults, and Image pointing at nslookup.exe. No Sysmon Event ID 3 follows because the name does not resolve.

  2. Test 2Browser Connection to a First-Seen Hyphen-Padded Lookalike Host

    Expected signal: Sysmon Event ID 22 with QueryName=okta-sso-account.atomic-test.invalid and Image=powershell.exe. In Microsoft Defender for Endpoint, a DeviceNetworkEvents row with RemoteUrl carrying the hostname and InitiatingProcessFileName=powershell.exe, subject to the tenant recording failed connection attempts.

  3. Test 3Resolve a Punycode Homoglyph Hostname

    Expected signal: Sysmon Event ID 22 with QueryName beginning xn-- and an empty or NXDOMAIN QueryResults. Note the label is not decodable punycode; resolvers and Sysmon record the queried string as sent regardless, which is what the detection matches on.

  4. Test 4Resolve a First-Seen Lookalike Hostname from Linux

    Expected signal: A DNS query record for docusign-secure-portal.atomic-test.invalid in Zeek dns.log, the endpoint agent's DNS event stream, or auditd if resolver syscalls are audited, attributed to the getent process. The lookup returns NXDOMAIN and the command exits non-zero, which the shell fallback absorbs.

Last updated: 2026-08-29 Research depth: deep
References (5)

Response Playbook

Triage

  1. Confirm the hostname is genuinely first-seen rather than a baseline artefact: re-run the baseline half of the query over 90 days and check whether the subsearch or distinct set was truncated. A truncated baseline is the single most common cause of a false first-seen verdict.
  2. Inspect the hostname composition manually: which brand is being impersonated, is the registrable label a homoglyph or typo variant, and is the brand token in the registrable domain itself or only in a subdomain label (adversary-controlled subdomain padding such as microsoft-login.<random>.tld is far more suspicious than a brand token in a genuine vendor's own domain).
  3. Identify how many distinct devices and users resolved the hostname, and over what interval. A tight burst across many users is campaign delivery; a single device is more likely browsing or a targeted lure.
  4. Determine the initiating process and referrer: was the resolution driven by a browser (user clicked something), an Office application (document-embedded link), or a mail client preview? Pull the parent process chain and any preceding mail delivery event.
  5. Search mail telemetry for messages delivered in the preceding 48 hours containing the hostname in a link or attachment, and identify all recipients — including those who have not yet resolved it, who are the population still at risk.
  6. Check whether the connection progressed beyond DNS to an actual TLS session and, if so, whether it carried a POST-shaped upload consistent with credential submission rather than a page fetch.
  7. Correlate the resolved IP with other first-seen hostnames from the same detection window; shared hosting IPs frequently reveal a whole registered cluster from the same operator.

Containment

  1. Sinkhole or block the hostname and, where the registrable domain is clearly adversary-controlled, the full domain and any sibling hostnames resolving to the same IP, at DNS and web proxy.
  2. Recall or purge the delivering mail from all recipient mailboxes, including recipients who have not yet clicked, and block the sending infrastructure.
  3. For any user who reached the site after DNS resolution, treat credentials as exposed: force a password reset, revoke all active refresh tokens and sessions, and re-register multi-factor authentication if the site was an adversary-in-the-middle proxy capable of relaying the second factor.
  4. Review authentication logs for those users for sign-ins from unfamiliar IPs or user agents in the window following the resolution, and revoke any resulting sessions and consented OAuth applications.
  5. Add the hostname, its registrable domain, and the resolved IP to the blocklist and to the watchlist used by adjacent detections so recurrence is caught immediately.
  6. If the impersonated brand is the organisation's own, notify the brand-protection or legal function so a takedown request can be filed with the registrar and hosting provider.

Evidence Collection

  1. DNS resolution records (Sysmon Event ID 22 or DeviceNetworkEvents) showing the first resolution timestamp, the full query name, the resolved addresses, and the initiating process for every affected device.
  2. Proxy or firewall logs for any subsequent HTTP/HTTPS session to the resolved address, including full request URI, method, user agent, bytes sent, and TLS server name indication.
  3. The delivering email in original form with full headers, plus the extracted link chain including any redirector hops between the mail body and the final hostname.
  4. Identity provider sign-in logs for all affected users spanning the resolution window and the following 24 hours, including session, device, and multi-factor claim detail.
  5. Browser history and cache for affected devices confirming whether a credential form was rendered and, where recoverable, whether it was submitted.
  6. A passive record of the sibling hostnames resolving to the same address, to scope the operator's wider registered infrastructure.

Escalation Criteria

  • !The impersonated brand is the organisation's own identity provider or mail surface, indicating the campaign is specifically targeting this organisation rather than opportunistic.
  • !A subsequent HTTP session to the hostname carried an outbound request body consistent with credential submission, or a successful sign-in follows within minutes from an unfamiliar location.
  • !Multiple users across different business units resolved the hostname inside a short window, confirming a mass-delivered campaign rather than an individual mistake.
  • !The hostname is punycode-encoded with homoglyph substitution of the corporate brand, which is a deliberate evasion investment and rarely accompanies low-effort commodity spam.
  • !Any affected account holds privileged, finance-approval, or payroll-modification rights.
  • !The resolved address also serves other first-seen lookalike hostnames impersonating the same brand, indicating an infrastructure cluster prepared for a sustained campaign.

Investigation Guide

Related Techniques

T1583.001 — Acquire Infrastructure: Domains (parent technique; the adversary registering the impersonating domain)T1584.001 — Compromise Infrastructure: Domains (the same lure pattern served from a hijacked rather than registered domain, which this detection also catches because the specific hostname is still first-seen)T1583.004 — Acquire Infrastructure: Server (the hosting standing behind the registered domain, useful for clustering sibling hostnames by resolved address)T1608.005 — Stage Capabilities: Link Target (the phishing page actually placed on the acquired domain)T1566.002 — Phishing: Spearphishing Link (the delivery vector that drives users to resolve the hostname)T1557.003 — Adversary-in-the-Middle: DHCP Spoofing and related AiTM proxy tradecraft, where the lookalike domain fronts a session-relaying reverse proxy rather than a static credential formT1078 — Valid Accounts (the outcome if credentials or session tokens harvested at the lookalike domain are subsequently used)

Forensic Artifacts

  • >Sysmon Event ID 22 records containing QueryName, QueryResults, and the initiating Image and ProcessGuid, which tie the resolution to a specific process ancestry.
  • >Sysmon Event ID 3 network connection records to the resolved address, correlated by ProcessGuid to the same process that performed the resolution.
  • >Sysmon Event ID 1 process creation for the browser or Office process that initiated the lookup, showing the parent chain and any command-line URL argument.
  • >Web proxy access logs recording the full URI, TLS server name indication, method, and request size for the session, which distinguishes a page view from a credential POST.
  • >Browser profile artefacts: history and download databases, session restore files, and cached page resources showing whether a credential form rendered.
  • >The local DNS resolver cache on the endpoint, which can retain the entry and its remaining time-to-live shortly after the event.
  • >Mail transport logs and the original message with headers, establishing delivery time, sender infrastructure, and the full recipient set.

Tuning Guidance

The brand and lure token lists are the whole detection and must be populated per environment before deployment; shipped as-is with only generic SaaS names they will miss impersonation of your own organisation, which is the highest-value case. Add every trading name, product name, and internal portal name your users would recognise, and add the specific identity provider, mail, file-sharing, e-signature, HR, and expense platforms your users actually authenticate against — impersonating a SaaS product nobody uses generates no clicks, so adversaries target the real stack. The known-good suffix list is equally load-bearing: without it every new CDN or regional endpoint belonging to the impersonated vendor alerts, so seed it from the top brand-token-bearing hostnames already in your 30-day baseline and re-review it quarterly. On the baseline itself, be aware that both implementations compute it inline and will be silently truncated on a large estate — the KQL distinct set and especially the Splunk subsearch have hard result limits, and a truncated baseline manufactures false first-seen verdicts at scale. Before this goes to production, move the baseline into a scheduled summary index, watchlist, or lookup refreshed nightly, and have the detection reference that instead. Score threshold: 50 is chosen so that brand-plus-lure (65), brand-plus-punycode (65), and lure-plus-punycode (50) all fire while a brand token alone (40) does not; if your baseline is clean and you want earlier warning, drop to 40 and accept the brand-only volume, and if you are drowning raise to 65 to require two strong signals. Exclude your security awareness platform's simulation domains by hostname, not by suppressing the whole detection, and exclude ad-tech and analytics hostnames by adding their stable parent domains to the known-good suffix list rather than by lowering the score. Finally, prioritise alerts where the resolution was followed within minutes by an actual TLS session and an outbound request larger than a typical page fetch — the resolution alone is early warning, but resolution plus submission is an incident.

Hunting Queries

Groups first-seen hostnames by the address they resolve to and surfaces addresses serving three or more novel hostnames in the same week. Phishing operators habitually park a batch of registered lookalike domains on one host, so this clusters an entire campaign's infrastructure even when individual hostnames score below the alerting threshold. Expect legitimate shared hosting, CDN, and website-builder addresses to dominate the top of the results — triage the cluster contents, not the count.

Hunting — KQL
kql 
// Hunt: first-seen hostnames clustered on a shared address - reveals an operator's whole registered estate
let BaselineWindow = 30d;
let DetectWindow = 7d;
let SeenBefore = DeviceNetworkEvents
    | where Timestamp between (ago(BaselineWindow) .. ago(DetectWindow))
    | extend HostName = tolower(iff(RemoteUrl startswith "http", tostring(parse_url(RemoteUrl).Host), RemoteUrl))
    | where isnotempty(HostName)
    | distinct HostName;
DeviceNetworkEvents
| where Timestamp > ago(DetectWindow)
| extend HostName = tolower(iff(RemoteUrl startswith "http", tostring(parse_url(RemoteUrl).Host), RemoteUrl))
| where isnotempty(HostName) and isnotempty(RemoteIP)
| where HostName !in (SeenBefore)
| summarize NewHostNames = dcount(HostName), HostNames = make_set(HostName, 25), Devices = dcount(DeviceName) by RemoteIP
| where NewHostNames >= 3
| order by NewHostNames desc
Hunting — SPL
spl 
index=sysmon sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=22 earliest=-7d
| eval QueryNameLower=lower(QueryName)
| search NOT [
    search index=sysmon sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=22 earliest=-30d latest=-7d
    | eval QueryNameLower=lower(QueryName)
    | fields QueryNameLower
    | dedup QueryNameLower
  ]
| where QueryResults!=""
| stats dc(QueryNameLower) as NewHostNames, values(QueryNameLower) as HostNames, dc(host) as Devices by QueryResults
| where NewHostNames>=3
| sort - NewHostNames

Enumerates every punycode-encoded hostname resolved in the estate over 30 days without requiring a first-seen match. Punycode is the standard vehicle for homoglyph brand impersonation, and in most western enterprises the legitimate volume is small enough to review by hand — decode each label and compare it visually against the brands your users authenticate to. Organisations with genuine internationalised partner domains should allowlist those before treating the remainder as leads.

Hunting — KQL
kql 
// Hunt: punycode hostnames resolved anywhere in the estate, regardless of first-seen status
DeviceNetworkEvents
| where Timestamp > ago(30d)
| extend HostName = tolower(iff(RemoteUrl startswith "http", tostring(parse_url(RemoteUrl).Host), RemoteUrl))
| where HostName startswith "xn--" or HostName contains ".xn--"
| summarize FirstSeen = min(Timestamp), LastSeen = max(Timestamp), Connections = count(), Devices = make_set(DeviceName, 20), Processes = make_set(InitiatingProcessFileName, 10) by HostName
| order by FirstSeen desc
Hunting — SPL
spl 
index=sysmon sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=22 earliest=-30d
| eval QueryNameLower=lower(QueryName)
| where match(QueryNameLower, "(^|\.)xn--")
| stats min(_time) as FirstSeen, max(_time) as LastSeen, count as Resolutions, dc(host) as Devices, values(host) as DeviceList, values(Image) as Processes by QueryNameLower
| sort - FirstSeen

Drops the first-seen requirement entirely and lists every hostname carrying a brand token that does not sit under that vendor's own registrable domain. This catches impersonation infrastructure that predates the baseline window — for example a domain registered months in advance and only now activated — which the standing detection cannot see. The output is a review list rather than an alert: the volume is dominated by legitimate resellers, documentation mirrors, and partner portals, so work it top-down by device count.

Hunting — KQL
kql 
// Hunt: brand tokens appearing outside the vendors' own registrable domains
let BrandTokens = dynamic(["contoso", "okta", "entra", "microsoft", "office365", "docusign", "sharepoint", "onedrive", "workday"]);
let KnownGoodSuffixes = dynamic([".microsoft.com", ".microsoftonline.com", ".office.com", ".okta.com", ".oktacdn.com", ".sharepoint.com", ".docusign.net", ".myworkday.com", ".live.com", ".windows.net"]);
DeviceNetworkEvents
| where Timestamp > ago(14d)
| extend HostName = tolower(iff(RemoteUrl startswith "http", tostring(parse_url(RemoteUrl).Host), RemoteUrl))
| where isnotempty(HostName)
| where HostName has_any (BrandTokens)
| where not(HostName has_any (KnownGoodSuffixes))
| summarize Connections = count(), Devices = dcount(DeviceName), DeviceList = make_set(DeviceName, 15), SampleUrl = any(RemoteUrl) by HostName
| order by Devices desc
Hunting — SPL
spl 
index=sysmon sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=22 earliest=-14d
| eval QueryNameLower=lower(QueryName)
| where match(QueryNameLower, "(contoso|okta|entra|microsoft|office365|docusign|sharepoint|onedrive|workday)")
| search NOT (QueryNameLower="*.microsoft.com" OR QueryNameLower="*.microsoftonline.com" OR QueryNameLower="*.office.com" OR QueryNameLower="*.okta.com" OR QueryNameLower="*.oktacdn.com" OR QueryNameLower="*.sharepoint.com" OR QueryNameLower="*.docusign.net" OR QueryNameLower="*.myworkday.com" OR QueryNameLower="*.live.com" OR QueryNameLower="*.windows.net")
| stats count as Resolutions, dc(host) as Devices, values(host) as DeviceList by QueryNameLower
| sort - Devices

Atomic Red Team Tests

Test 1 Resolve a First-Seen Brand-Plus-Lure Hostname
windows

Issues a DNS query for a hostname that combines a brand token and a credential-lure token under the reserved .invalid top-level domain. The name is guaranteed never to resolve and no traffic leaves the network beyond the resolver, but the query itself is recorded and carries the exact composition the detection scores at 65 points.

Command

powershell 
nslookup microsoft-login-verify.atomic-test.invalid

Cleanup

powershell 
ipconfig /flushdns

Expected Telemetry

Sysmon Event ID 22 with QueryName=microsoft-login-verify.atomic-test.invalid, an empty or NXDOMAIN QueryResults, and Image pointing at nslookup.exe. No Sysmon Event ID 3 follows because the name does not resolve.

Expected Detection

SPL detection fires: the name is absent from the 30-day baseline subsearch and scores 40 (brand token 'microsoft') plus 25 (lure token 'login') plus 10 (two or more hyphens) = 75, above the threshold of 50. The KQL detection does not fire from this test because DeviceNetworkEvents records connections rather than failed name resolutions — use the second test for the Defender path.

Test 2 Browser Connection to a First-Seen Hyphen-Padded Lookalike Host
windows

Drives an HTTPS connection attempt from PowerShell to a hyphen-padded lookalike hostname, producing the connection-side telemetry the Defender query baselines on rather than the DNS-side telemetry. The hostname uses the reserved .invalid top-level domain so the attempt fails at resolution and no adversary infrastructure is contacted.

Command

powershell 
powershell.exe -Command "try { Invoke-WebRequest -Uri 'https://okta-sso-account.atomic-test.invalid/' -UseBasicParsing -TimeoutSec 5 } catch { Write-Output 'Connection attempted - check network telemetry' }"

Cleanup

powershell 
ipconfig /flushdns

Expected Telemetry

Sysmon Event ID 22 with QueryName=okta-sso-account.atomic-test.invalid and Image=powershell.exe. In Microsoft Defender for Endpoint, a DeviceNetworkEvents row with RemoteUrl carrying the hostname and InitiatingProcessFileName=powershell.exe, subject to the tenant recording failed connection attempts.

Expected Detection

Both queries score the hostname at 75: brand token 'okta' (40), lure tokens 'sso' and 'account' (25), two or more hyphens (10). Because the name has never been observed, it survives the first-seen filter and is emitted with Score=75.

Test 3 Resolve a Punycode Homoglyph Hostname
windows

Queries a punycode-encoded hostname to exercise the homoglyph branch of the score independently of the brand token list. Punycode labels are the standard mechanism for visually substituting characters in a brand name, and this test confirms the xn-- prefix detection works even when no plain-text brand token is present in the hostname.

Command

powershell 
nslookup xn--secure-login-atomic.atomic-test.invalid

Cleanup

powershell 
ipconfig /flushdns

Expected Telemetry

Sysmon Event ID 22 with QueryName beginning xn-- and an empty or NXDOMAIN QueryResults. Note the label is not decodable punycode; resolvers and Sysmon record the queried string as sent regardless, which is what the detection matches on.

Expected Detection

SPL detection fires with Score=60: punycode prefix (25), lure tokens 'secure' and 'login' (25), two or more hyphens (10). No brand token is present, confirming the punycode-plus-lure combination alone clears the threshold of 50. The punycode hunting query also returns this hostname.

Test 4 Resolve a First-Seen Lookalike Hostname from Linux
linux

Performs the equivalent first-seen lookalike resolution from a Linux endpoint using getent, which exercises the standard resolver path and is captured by auditd, Zeek, or an endpoint agent's DNS telemetry rather than by Sysmon. Confirms the detection logic is portable to the non-Windows estate where DNS telemetry is collected centrally.

Command

bash 
getent hosts docusign-secure-portal.atomic-test.invalid || echo 'Resolution attempted - check DNS telemetry'

Cleanup

bash 
systemd-resolve --flush-caches 2>/dev/null || resolvectl flush-caches 2>/dev/null || true

Expected Telemetry

A DNS query record for docusign-secure-portal.atomic-test.invalid in Zeek dns.log, the endpoint agent's DNS event stream, or auditd if resolver syscalls are audited, attributed to the getent process. The lookup returns NXDOMAIN and the command exits non-zero, which the shell fallback absorbs.

Expected Detection

Where Linux DNS telemetry is normalised into the same index or table, the hostname scores 75: brand token 'docusign' (40), lure tokens 'secure' and 'portal' (25), two or more hyphens (10). If Linux DNS is not collected, this test produces no detection, which is itself a useful coverage finding to record.

Related Detections

Tactic Hub

TA0042Resource Development

Detection Variants (2)

Different telemetry and tradecraft for the same technique — pick the one that matches the data you collect.

Parent Technique

T1583.001Domains

Related Techniques

T1583.001DomainsT1584.001Compromise Infrastructure: DomainsT1583.004ServerT1608.005Link TargetT1566.002Spearphishing LinkT1557.003DHCP SpoofingT1078Valid Accounts

Same Tactic: Resource Development

Popular Detections