Microsoft’s September 28 security post shows how a small PowerShell workflow can enrich a list of suspicious domains through Microsoft Defender Threat Intelligence (MDTI) and Microsoft Graph. The important idea for a security leader is not the script itself. It is the operating model: every domain gets the same read-only enrichment, the analyst receives a sortable decision surface, and the raw response remains available for investigation evidence.
That matters when a phishing campaign produces dozens or hundreds of lookalike domains. Manual WHOIS lookups are slow, inconsistent, and difficult to defend later. A controlled enrichment path can help a SOC see shared registrants, registrars, nameservers, and registration timing before those relationships disappear into a pile of individual alerts.
What Microsoft actually introduced
The Community Hub post describes Get-MDTIWhois.ps1, an educational example that reads domains from a text file and calls the Graph host WHOIS endpoint. It writes two outputs:
| Output | Operational purpose | Control to add |
|---|---|---|
| Normalized CSV | A sortable, comparable view of registrant, registrar, date, and nameserver fields for triage. | Version the input and output, record the run time, and restrict access because WHOIS can contain personal data. |
| Raw JSON | The complete API response for investigation, registrar-specific fields, and audit review. | Retain it with the incident or case record and apply the same retention and sharing policy as other threat intelligence. |
This is a workflow pattern, not a new Microsoft security control. Microsoft labels the script as provided for educational and demonstration purposes, so review its code, test its behavior, and monitor the API before considering production use.
Check entitlement and least-privilege access first
Microsoft’s current Graph threat-intelligence overview documents the API as a way to support triage, incident response, threat hunting, and intelligence workflows. For application access, the documented permission is ThreatIntelligence.Read.All; Microsoft also says the calling user needs at least the Security Reader role. Confirm the tenant’s current Defender XDR or Sentinel entitlement, permission consent, and data-handling requirements before building the automation.
The method used by the example is the documented Get whoisRecord request:
GET /security/threatIntelligence/hosts/{hostId}/whoisKeep the application read-only. It should be able to collect evidence, not change Sentinel rules, Defender settings, domain records, or tenant configuration.
Design the enrichment path around decisions
A useful implementation has a narrow chain of responsibility:
| Stage | What happens | Evidence to retain |
|---|---|---|
| 1. Intake | Collect domains from an alert, proxy/DNS hunt, or case file. Normalize case, trim whitespace, and de-duplicate without losing the original list. | Original input, source alert or case, operator, tenant, and timestamp. |
| 2. Enrichment | Call Graph once per host, retry transient 429/5xx responses with backoff, and continue when one host fails. | HTTP result, retry count, error reason, and module/script version. |
| 3. Review | Sort by shared registrant, nameserver, registrar, and registration date to identify infrastructure clusters. | Analyst notes, pivot fields, and the domains grouped into a campaign hypothesis. |
| 4. Action | Use the result to prioritize investigation, create a scoped hunt, or propose an indicator. Do not turn WHOIS alone into an automatic block. | Decision, approver, corroborating signals, and rollback or expiry date. |
A 404 is not a safe verdict. It means the service has no current WHOIS record for that host. Keep the domain in context and combine it with reputation, DNS, certificate, endpoint, mail, and user-report evidence.
Use Sentinel watchlists for repeatable joins, not as the case file
Microsoft’s Sentinel watchlist guidance supports joining a normalized list to logs with _GetWatchlist() and recommends using the SearchKey for efficient joins. That makes the CSV useful for recurring hunts such as proxy hits, newly registered domains, or email click telemetry.
Keep the raw JSON and the analyst’s reasoning with the incident. A watchlist is a shared detection input, not a replacement for the investigation record. It also should not be treated as a real-time enrichment mechanism; use a controlled Logic App, Azure Function, or other playbook only when the latency and change-management model have been reviewed.
Guardrails for growing businesses
- Privacy: WHOIS fields can contain personal data. Limit who can read or export the results, define retention, and avoid distributing the CSV broadly.
- Secret handling: use a managed identity or protected secret path where possible; never hard-code a client secret or commit one with the script.
- API resilience: handle throttling and transient failures, preserve partial results, and make failed domains obvious rather than silently dropping them.
- Human approval: require corroborating evidence before adding a block indicator or changing a detection rule.
- Reproducibility: save the input, output, script version, permission set, and analyst decision together.
A 30-day readiness plan
| Window | Work | Exit evidence |
|---|---|---|
| Days 1–5 | Confirm Defender/Sentinel entitlement, Graph permissions, Security Reader access, data residency, and the incident-retention path. | Approved access design and data-handling decision. |
| Days 6–12 | Review the Microsoft example, test it against benign and known-bad domains, and measure throttling, 404s, and transient errors. | Test output, failure matrix, and rollback or disable procedure. |
| Days 13–20 | Run a pilot with one SOC queue. Compare the normalized CSV with manual enrichment and record where the pivots changed triage. | Before/after timing, analyst feedback, and sample campaign analysis. |
| Days 21–30 | Connect approved output to a Sentinel watchlist or hunt, brief analysts on the 404 and privacy caveats, and schedule a monthly review. | Production change record, monitoring, owner, retention rule, and review date. |
Frequently asked questions
Is the PowerShell script a Microsoft-supported product? No. Microsoft published it as an educational, demonstration project. Treat it like sample code: review, test, monitor, and adapt it before production use.
What permissions does the Graph workflow need? Microsoft documents ThreatIntelligence.Read.All for application access and at least the Security Reader role for the calling user. Validate current tenant licensing and consent before deployment.
Does a missing WHOIS record mean a domain is safe? No. A missing record is an enrichment result, not a verdict. Continue the investigation with other signals.
Should every CSV be loaded into a Sentinel watchlist? Only when the list supports a repeatable hunt or join. Preserve the raw response and case evidence separately, and use near-real-time automation only when it has its own controls.
Need a threat-intelligence operating model?
Accred Consulting can review your Microsoft security data paths, least-privilege Graph access, Sentinel hunting workflow, and evidence controls so enrichment improves response without creating a new blind spot.
Plan a Security Operations Review