Indicator Enrichment

A takedown request names a credential-harvesting page served from a github.com URL and asks you to block the domain. The indicator arrives with no verdict attached and no context beyond the string.

Do I block github.com, and what would tell me I am wrong?

Blocking a domain is a statement about who operates it. The ticket describes one page, the card describes the operator, and the whole risk in this ticket is treating those as the same fact.

• Whether the indicator is malicious. No step in this run reads a threat feed, calls explain() or scores anything. That is a separate run, and this card must not be read as its answer.
• Whether anything of yours touched it. The run reads the indicator, never your traffic. Direction, timing and which host connected live in your proxy and mail logs.
• Who owns it, in words a human wrote. REGISTERED_BY returns two ORGANIZATION names for github.com — github hostmaster and github, — scraped fragments rather than a company. Readable ownership comes from the WHOIS arm, whisper.history.whois, and that arm is dated.
• How large the web footprint is. The link-count step is written to saturate: for a hub this size both directions return the step's own saturation flag, so the number is a floor and not a count.

Measured on 2026-08-09. whisper.identify returns Github, category saas, roles DNS_OPERATOR, MAIL_RECEIVER and ORIGIN_AS, and host_class = multi_tenant_user_content. The domain resolves to four IPv4 addresses in two networks: 140.82.121.3 and 140.82.121.4 in 140.82.121.0/24 on AS36459 — GITHUB, and 20.205.243.166 and 4.228.31.150 on AS8075 — MICROSOFT-CORP-MSN-AS-BLOCK.

Delegation and mail are split the same way. Eight authoritative nameservers, four at NS1 and four at AWS. Six mail exchangers, five Google and one Outlook. Eight SPF_INCLUDE targets — Google, Marketo, Outlook, Salesforce, Zendesk and Mailchimp — plus twelve SPF_IP mechanisms. And 36,131 hostnames hang off the domain by CHILD_OF.

Four arms come back empty for two different reasons, and neither reason is a finding about the domain. The co-hosted, ASN-profile and prefix-profile arms anchor on a label a hostname does not carry, so they return zero rows at HTTP 200 by construction. The nested-SPF arm is empty for a different reason: anchoring on spf.protection.outlook.com shows 104 MAIL_FOR, 11 SPF_IP, 4 NAMESERVER_FOR and no SPF_INCLUDE at all, so the second level is there under a different edge type. Zero rows is never a verdict.

There is no score in this run, so nothing suggests anything. The pivot is one field most readers skim: host_class comes back multi_tenant_user_content, which the identify reference glosses as a platform where anyone can publish.

That string decides the ticket. Registrant, ASNs, nameservers and mail servers all describe GitHub, Inc., and not one of them is the party that put a page on the domain. The 36,131 subdomains are the same argument in another column: a block on the apex is a block on every tenant, and the tenant count is the cost of getting this wrong.

The conclusion rests on the operator today being the operator the card describes, and the card's identity half is an observation with a date on it. The WHOIS arm holds 30 snapshots for github.com, from 2017-06-20 to 2024-09-22 14:40:57, against a create date of 2007-10-09. The registrant field on that newest snapshot is empty. Control could have changed after it and the arm would not know.

Delegation is the independent check. The newest snapshot records eight nameservers; live NAMESERVER_FOR returns eight; compared name by name the two sets are identical, with nothing on either side the other lacks. Two layers observed years apart agree on who answers for the domain. Divergence there is the signal that the identity half is the thing to distrust, and it is the query to run before trusting any of this on a domain you do not already know. The SPF and delegation queries are runnable on DNS and email.

github.com is a multi-tenant platform rather than attacker infrastructure: host_class = multi_tenant_user_content, 36,131 subdomains, addresses in the operator's own AS36459 and in AS8075, and a delegation unchanged since the last WHOIS observation. Block the URL, not the domain, and route the ticket to the platform as hosting abuse.

Nothing here says the reported page is harmless. This run makes no claim about it in either direction, and four things would change the answer:

• a threat read on the host or its addresses, which this run does not perform and which has to be asked for separately;
• live delegation diverging from the last WHOIS snapshot, the drift test above;
• whisper.identify returning a different host_class later — the atlas is a classification that moves, not a constant;
• evidence that the operator, rather than a tenant, published the page.

Enrichment is context, not a verdict. Read as a verdict, a card's silence about threat becomes an answer it never gave.