From Domain Lists to Decisions: Scaling WHOIS Threat Intelligence with MDTI and Microsoft Graph
The real problem isn't WHOIS. It's what WHOIS costs you at scale. Ask any SOC analyst whether WHOIS data is useful and they'll say yes without hesitation. Registrant emails, creation dates, registrars, and nameservers are among the most durable pivots in domain-based threat intelligence — the threads that tie a single phishing domain back to an entire adversary campaign. Now ask them how often they actually pull WHOIS for every suspicious domain in an alert. The honest answer is: not always. And that gap is the real problem. Here's why. When a campaign surfaces two hundred lookalike domains, manual WHOIS becomes a losing game: It's slow. One-domain-at-a-time portal lookups don't finish before the incident clock runs out. It's inconsistent. Different analysts capture different fields, so the data can't be compared or correlated. It's un-auditable. Screenshots and copy-paste don't hold up in an investigation review months later. It loses the pattern. By the time you've checked twenty domains by hand, the shared registrant email that connected them has scrolled off the screen. The outcome of all this friction is the part that should worry a security leader: analysts quietly stop enriching, or enrich only a sample. The pivot that would have collapsed twenty alerts into one campaign never happens. The newly registered domain that should have been escalated gets triaged as routine. The intelligence exists — the process just can't reach it fast enough. The outcome we're actually after Reframe the goal. This isn't a project to "run WHOIS." It's a project to produce a specific set of outcomes: Every suspicious domain gets enriched — not a hand-picked sample. Enrichment is consistent and structured, so patterns across domains become visible instead of buried. The output is audit-ready — defensible in an investigation and reusable in a report. The whole thing is fast enough to happen inside the incident, not the day after. Get-MDTIWhois.ps1 exists to deliver exactly those outcomes. It reads a list of domains, calls Microsoft Defender Threat Intelligence (MDTI) through Microsoft Graph, and returns both a normalized CSV for immediate triage and the raw JSON for deep investigation — in one pass, read-only, with nothing changed in your environment. What changes for the analyst The clearest way to see the value is the before-and-after. Before: An alert fires on a suspected phishing campaign with two hundred candidate domains. The analyst opens a portal, checks a handful of domains, eyeballs a few registrant fields, and makes a judgment call on incomplete data. Correlation is mental and fragile. Twenty related alerts stay twenty separate alerts. After: The analyst drops the domains into a text file, runs one command, and gets a spreadsheet where all two hundred are enriched with the same fields. Sorting by registrant email instantly reveals that forty of them share one address, one budget registrar, and creation dates in the same week. Twenty alerts become one campaign. One judgment call becomes one defensible conclusion. That's the outcome: not "we ran WHOIS," but "we saw the campaign the manual process would have missed." Where the value shows up This translates into concrete wins across several SOC workflows: Faster campaign triage. Shared registrant emails and nameservers collapse dozens of alerts into a single adversary-infrastructure story — directly reducing mean-time-to-respond. Better newly-registered-domain hunting. Enrich domains from DNS or proxy logs, sort by registration date, and surface the freshly registered domains that are disproportionately malicious — before they're clicked. Enrichment that feeds the platform. The normalized CSV drops straight into a Sentinel watchlist, or the same Graph call can be wrapped in a Logic App / Azure Function playbook to auto-enrich domain entities the moment an incident is created. Reusable intelligence. Registrant and nameserver pivots become custom indicators and hunting queries — value that compounds over time instead of being thrown away after each investigation. Why this approach, specifically There are other ways to get WHOIS. A few reasons this approach earns its place in a modern, Defender-portal-centric SOC: It uses first-party intelligence. MDTI is Microsoft's own threat-intelligence graph, queried natively through Microsoft Graph — no third-party data broker, no separate contract, no data leaving your Microsoft trust boundary. It's read-only by design. The script cannot modify Sentinel, Defender, tenant settings, or domain records. Enrichment tooling should never be able to change the environment it observes — and this one can't. It's built to survive real-world APIs. Throttling (HTTP 429) and transient 5xx errors are retried with backoff; permanent misses (404) aren't retried needlessly; a single failed domain never aborts the run. You always get a complete, dependable result set. It handles secrets the way you'd want. Client secrets come from an environment variable or a secure prompt — never hard-coded, never committed to source control. The engineering exists to protect the outcome: a complete, consistent, trustworthy enrichment set every single time, even when the input list is messy or the API is having a bad day. The output is built for decisions, not just data Two files, two jobs: The normalized CSV is the decision surface. One row per domain, every registrant/registrar/date/nameserver field an analyst pivots on — sortable, filterable, watchlist-ready. This is where twenty alerts become one campaign. The raw JSON is the safety net. Full API fidelity per domain, preserved for the audit trail and for the registrar-specific edge cases the normalized view can't anticipate. Together they answer both questions a SOC actually asks: "What do I do right now?" (CSV) and "Can I stand behind it later?" (JSON). What it takes to get there The barrier to entry is low: An Entra ID app registration with the Graph application permission ThreatIntelligence.Read.All (admin-consented), on a tenant with MDTI API access. A text file of domains, one per line. One command: $env:MDTI_CLIENT_SECRET = "<client-secret>" .\Get-MDTIWhois.ps1 ` -TenantId "<tenant-id>" ` -ClientId "<client-id>" ` -InputTxt ".\domains.txt" Under the covers it authenticates with a client-credentials grant, normalizes and de-duplicates the input, calls GET /security/threatIntelligence/hosts/{domain}/whois per domain, and writes both outputs. Minutes of setup; a repeatable capability afterward. Use it responsibly The project is provided as-is, for educational and demonstration purposes, and is not intended for production use without independent review, validation, and monitoring. Keep in mind: A 404 means MDTI has no current WHOIS record for that host — not that the domain is safe. WHOIS fields vary by registrar — always retain the raw JSON for anything you'll act on. WHOIS can contain personal data — validate your storage and sharing obligations before distributing enrichment output. Never commit secrets — use the environment-variable or secure-prompt path. The bottom line The value here isn't that WHOIS is difficult. It's that the friction of doing WHOIS well, for everything, quietly erodes detection quality — analysts under time pressure enrich less, correlate by memory, and miss the campaign hiding in plain sight. Get-MDTIWhois.ps1 removes that friction. It turns a flat list of domains into structured, audit-ready intelligence in a single read-only pass, so the pivot that reveals the adversary's infrastructure actually happens — inside the incident, not after it. That's the outcome worth automating. Disclaimer This article and the referenced tooling are provided “as-is,” for educational and demonstration purposes only, without warranties of any kind, express or implied. They are not intended for production, safety-critical, or regulated use without independent review, testing, validation, and appropriate safeguards. The views expressed are the author’s own and do not necessarily represent those of any employer or of Microsoft. You are solely responsible for how you deploy, modify, or adapt this tooling, and for ensuring compliance with all applicable laws, regulations, licensing terms, privacy obligations, and organizational security policies. Source: MDTI-WHOIS in the Microsoft Security Operations Toolkit. Provided as-is for educational purposes; test in a controlled environment before production use.
SmartScreen reputation issue for EV Code Signed Windows application
Hello Microsoft Defender Threat Intelligence Team, We are the developer of a legitimate Windows desktop application called "ShangJing". Recently, our users reported that Microsoft Defender SmartScreen displays the following warning when downloading and launching our application: "Microsoft Defender SmartScreen can't verify this file is safe." The application is not malicious and has been digitally signed with a GlobalSign EV Code Signing Certificate. Application information: Product Name: ShangJing Publisher: Zhaoyi Information Technology (Shanghai) Co., Ltd. Certificate: GlobalSign EV Code Signing Certificate File: 尚镜_2.0.0_platinum_setup.exe Issue: Users receive SmartScreen reputation warning when downloading our application. We have already submitted the file through Microsoft Security Intelligence submission portal 7 days ago, but we have not received any update yet. Submission ID: 0c015296-b9cf-4130-9eaf-fc59cd145370 The file is distributed through our official website: https://www.changine.cn/downloads We would like to understand: 1. Is this caused by insufficient SmartScreen reputation for a newly released binary? 2. Is there any additional verification required from the software publisher side? 3. How can we ensure our legitimate application gains proper SmartScreen reputation? Our application is widely used for live streaming and camera-related workflows. It does not contain any malicious behavior. We would appreciate any guidance from the Microsoft team. Thank you.
Need information on generating sample events for Threat Intelligence" (both duplicate posts)
Two things are tripping this up, and they're common mix-ups: First — Attack Simulation Training doesn't generate Threat Intelligence events. If you used the built-in phishing simulator, its logs only show up under Email & collaboration → Attack simulation training → Simulations — they're intentionally excluded from real Threat Intelligence telemetry. That's likely why nothing's showing up even though you ran a campaign. Second — your EICAR test should actually work, but check the right place: not the generic Office 365 Management Activity API's AuditLogRecordType page in isolation — go specifically to the RecordType values used for Defender for Office 365 threat events: 28 = ThreatIntelligence (phishing/malware events) 41 = ThreatIntelligenceUrl (Safe Links time-of-click/block events) Plus ThreatIntelligenceAtpContent, ThreatFinder, MSTIC To reliably generate one: Confirm Purview audit logging is enabled for the tenant first — if it isn't, nothing downstream gets logged regardless of what you trigger. From an external mailbox, send a test user the EICAR string as a .txt attachment (exact 68-byte string, see Microsoft's anti-malware testing doc). Defender for Office 365 should detect and quarantine it. Verify it landed first in the portal UI: Email & collaboration → Explorer → Malware tab — if it's there, the underlying ThreatIntelligence record exists and the Management API call should return it (allow a short delay; these aren't instant). For the Safe Links side, send a known-safe-but-flagged test URL (Microsoft publishes test URLs for this) to trigger ThreatIntelligenceUrl. If it shows up in Explorer but still doesn't appear via the Management API, that's usually an API subscription/permission issue (you need an active subscription to the DLP.All or relevant Office 365 Management API content type, not just Graph permissions) — worth checking separately from the detection side.Can the Microsoft Defender portal show the server details as per security group?
Yes — this is exactly what Device Groups + RBAC are designed for in Microsoft Defender (assuming you're managing these servers through Defender for Endpoint, which is the typical path for cross-vendor server monitoring). The model: Device groups are the scoping unit (not Entra security groups directly) — create one per vendor/company (e.g., "Company A Servers", "Company B Servers"), using a matching rule (tag, OS, name pattern, etc.) to auto-assign devices. RBAC roles then get tied to an Entra security group and granted access to only specific device groups. So: Company A's people go in an Entra group → that group is assigned an MDE role scoped to "Company A Servers" only → they only ever see those devices, alerts, and incidents in the portal. You as admin keep your existing Global Admin/Security Admin role (or get added to both device groups' RBAC scope), so you retain visibility across both. Path: Settings → Endpoints → Permissions → Device groups to create the groups, then Permissions → Roles to create a role and tie it to your Entra security group with that device group as the scope. One thing to verify before committing to this design: this RBAC model affects what shows in alerts, incidents, advanced hunting (scoped automatically), and inventory — but make sure nobody from Company A/B also needs organization-wide Defender features like global threat analytics, since those aren't scopable the same way. If you're actually talking about servers monitored via Defender for Cloud (Azure subscription-based, not MDE-onboarded), the equivalent mechanism is Azure RBAC at the subscription/resource group level (assign Security Reader scoped to the RG containing Company A's VMs) — different mechanism, same outcome. Worth clarifying which portal/product this is so the right one gets recommended.
Microsoft Defender doesn't, Spy hunter shows a Hijacker
Spy Hunter indicates a "Elex Hijacker" and three other problems were as Defender and McAfee do not show any problem. Is Spy Hunter legitimate? I did have a Search engine redirect problem that has a name "ext.ladispatcher.com" and "search-load.com" while using Chrome browser with Chrome search engine. But no problem with Microsoft Edge and Bing. My monitor screen occasionally momentary collapses and reverts back to normal in a split second. Could there be a connection to malware.? Please let me know if i am posting on the wrong site.Need information on generating sample events for Threat Intelligence
Hi community, I am working on exploring MS Threat Intelligence and its features. But I am not able to generate sample data for this product, nor able to view the Threat Intelligence logs using Microsoft Management API following the schema - https://learn.microsoft.com/en-us/office/office-365-management-api/office-365-management-activity-api-schema#auditlogrecordtype I tried sending some mails from external email account to my organisation's test user containing EICAR files, and also tried with some safe but malicious test URLs. But still unable to get data inside Threat Intelligence. Can someone please help me here for generating events and viewing the content using Management APIs?
Need information on generating sample events for Threat Intelligence
Hi community, I am working on exploring MS Threat Intelligence and its features. But I am not able to generate sample data for this product, nor able to view the Threat Intelligence logs using Microsoft Management API following the schema - https://learn.microsoft.com/en-us/office/office-365-management-api/office-365-management-activity-api-schema#auditlogrecordtype I tried sending some mails from external email account to my organisation's test user containing EICAR files, and also tried with some safe but malicious test URLs. But still unable to get data inside Threat Intelligence. Can someone please help me here for generating events and viewing the content using Management APIs?
Can the Microsoft Defender portal show the server details as per security group?
I'm using Microsoft Defender to monitor the servers. I have multiple groups of people working from various other vendors. I would like create multiple security groups and add people based on their company and configure the defender such a manner that only people from Company "A" can see their own servers and people working from Campany "B" can see their respective servers. Also, I as admin can see both "A's" and "B's" servers. Can this be achieved using Microsoft Defender? If yes, how to achieve this? Any step-by-step approach would help. Or if there are any other ways, please suggest. Thanks
