RED × BLUE

Threat Playbook

Adversary vectors paired with the defensive controls that close them. Read top-to-bottom — engagements are sorted by severity. Baseline controls below apply across the surface.

Severe

Moderate

Low

Baseline

Severe · Act Now

6 engagements

SEVERE R-01 ↔ B-01 Spear-phish Aladdin client admins from the CT-leaked tenant list High confidence

Red · Adversary Vector R-01

Spear-phish Aladdin client admins from the CT-leaked tenant list

The CT-log subdomain list (ev_004, ev_034) names schwab.blackrock.com, bnymim.blackrock.com, bnppam.blackrock.com, unicredit.blackrock.com, schroders.blackrock.com, swissre.blackrock.com, jhi.blackrock.com, mfc.blackrock.com, mswm.blackrock.com, ispgruppo.blackrock.com, gruppobper.blackrock.com, smam.blackrock.com, smtam.blackrock.com, helvetia.blackrock.com, principal.blackrock.com, thrivent.blackrock.com, svb.blackrock.com, poste.blackrock.com, coppel.blackrock.com, equitrust.blackrock.com, dellife.blackrock.com, pfa.blackrock.com, pic.blackrock.com, gmo.blackrock.com, ifm.blackrock.com, futurefund.blackrock.com, fondsavs.blackrock.com, jhi.blackrock.com, plus the BAML/EV-cert anomaly (ev_088, ev_089). All are NXDOMAIN externally — but their existence and naming alone is a confidential client disclosure usable for credible spear-phishing pretexts against client-side Aladdin admins. Very likely the highest-yield social-engineering vector in the surface.

Blue · Defensive Control B-01

Close the Aladdin tenant-leak feedback loop with CT-monitoring and client-side phishing-resistance hardening

Stand up an internal CT-monitoring pipeline (Cert Transparency, Censys) on *.blackrock.com that alerts on any new SAN containing a client name; the tenant list is already public, but adversary-staged look-alike domains (schwab-blackrock.com, aladdin-bnymim.com) should be detected early. Push each Aladdin client to phishing-resistant MFA (FIDO2 / WebAuthn) for their admin accounts; provide a template phishing-awareness brief referencing the specific tenant subdomain so client SOCs can cross-reference. Co-publish a static IP allowlist for Aladdin SSO that clients can ingest into their secure-web-gateway. Where possible, narrow the tenant subdomain naming to anonymized indices (aladdin-t0234.blackrock.com) on next cert renewal — the existing names cannot be retracted, but new tenants should not extend the disclosure.

SEVERE R-02 ↔ B-02 Hostile-registration window: iunits.com + gachallenge.com expire within 32 days High confidence

Red · Adversary Vector R-02

Hostile-registration window: iunits.com + gachallenge.com expire within 32 days

iunits.com expires 2026-07-12 (~27 days from investigation) and gachallenge.com expires 2026-07-17 (~32 days). The 5-day cluster lets an adversary monitor both with a single daily WHOIS job. iunits.com is the oldest BlackRock-affiliated domain (registered 1999-07-12) and the only portfolio domain without DNSSEC — a hostile registrant very likely can immediately publish A/MX/TXT records without DNSSEC inconsistency. Payoff: brand-impersonation phishing against Canadian iShares investors (iUnits was BlackRock's pre-iShares Canadian ETF brand) and gachallenge-themed marketing pretext targets. The control is straightforward (renew + add DNSSEC), but the urgency window is small.

Blue · Defensive Control B-02

Renew iunits.com and gachallenge.com before the July expiry window; enable DNSSEC on iunits.com

Renew iunits.com (2026-07-12) and gachallenge.com (2026-07-17) before the cluster window opens — the controls are simple CSC renewals plus enabling DNSSEC on iunits.com (the only portfolio domain currently without it). Add internal monitoring on RDAP/WHOIS for both domains: a daily check that expiry date moves forward when the renewal lands. Independently of these two, audit the rest of the portfolio for any other domains within the next 90-day window and renew early. Consider transferring expired-brand domains (iUnits is a discontinued Canadian ETF brand) to a 'sinkhole' pool rather than letting them lapse; CSC's defensive registration pricing is materially cheaper than the impersonation-incident recovery cost.

SEVERE R-03 ↔ B-03 Spoof @ishares.nl — no SPF, DMARC p=none, no DNSSEC High confidence

Red · Adversary Vector R-03

Spoof @ishares.nl — no SPF, DMARC p=none, no DNSSEC

ishares.nl is BlackRock-registered per SIDN RDAP (ev_007) yet has the weakest mail-auth posture in the entire portfolio (ev_106, ev_120). With no SPF published, DMARC p=none, and no DNSSEC, an adversary very likely sends mail from @ishares.nl that lands authenticated for downstream relays. Combined with a hostile-registered look-alike or a TLS cert from any CA (the domain has no CAA either), the surface is set up for a high-success investor-phishing campaign aimed at Dutch retail iShares investors. The single drift from p=reject to p=none on this one ccTLD is the lever.

Blue · Defensive Control B-03

Bring ishares.nl up to portfolio standard (SPF -all, DMARC p=reject, DNSSEC)

Publish v=spf1 -all on ishares.nl if no outbound mail is sent; if it is sent, mirror the blackrock.com SPF include set and use -all. Tighten DMARC from p=none to p=quarantine for two weeks, then p=reject; the existing vali.email RUA aggregator gives the observability needed to detect legitimate-mail failures. Enable DNSSEC at SIDN (DS records into the SIDN parent). This single domain's gap drift is the strongest argument H2 (uneven posture) wins in ACH — closing it materially flattens the configuration delta between the core and the periphery.

SEVERE R-04 ↔ B-04 Cred-stuff and AiTM against Okta SSO using Hunter employee list Moderate confidence

Red · Adversary Vector R-04

Cred-stuff and AiTM against Okta SSO using Hunter employee list

Hunter reports 15,910 mailboxes (ev_022, ev_051) on the canonical {first}.{last}@blackrock.com pattern, with department-scoped slices confirming the scale (ev_087, ev_098). Okta SSO endpoints are reachable globally (ev_013, ev_014, ev_015). An adversary very likely performs credential-stuffing against the corporate, US Aladdin, and EMEA Aladdin Okta endpoints using HIBP/Cit0day-derived password material aligned to the Hunter list. The Duo SSO MFA tenants (ent_113) and the use of EV-grade certs on baml.login (ev_089) elevate the difficulty, but adversary-in-the-middle phishing kits (Evilginx, Tycoon) likely relay session cookies in real time, defeating push-MFA. Confidence is moderate because Duo MFA enforcement is observable but its phishing-resistance level (FIDO2 vs. push) is not.

Blue · Defensive Control B-04

Phishing-resistant MFA on Okta + Duo; conditional access policies on the SSO endpoints

Mandate FIDO2 / WebAuthn (security keys, platform authenticators) across the three Okta tenants and both Duo SSO tenants — push-MFA is bypassable via AiTM kits (Evilginx, Tycoon). Add Okta ThreatInsight + Duo Risk-Based Auth with hard-block on impossible-travel and high-risk session anomalies. Block legacy authentication protocols at the Okta network policy. Geo-fence the corporate and Aladdin EMEA SSO endpoints to the EU and North America with explicit allow-listing for legitimate travel exceptions. Sub-task: rotate any LastPass-stored corporate credentials still in scope from the 2022-2023 LastPass breach window and verify rotation against an independent breach-corpus lookup.

SEVERE R-05 ↔ B-05 Compromise of DNRAdmin@Blackrock.com → portfolio-wide registrar takeover Moderate confidence

Red · Adversary Vector R-05

Compromise of DNRAdmin@Blackrock.com → portfolio-wide registrar takeover

RDAP cross-confirms DNRAdmin@Blackrock.com as the admin/tech contact across 19+ portfolio domains at CSC Corporate Domains (IANA 299). Compromise of this single mailbox or its CSC-portal credential very likely enables zone-wide hijack (NS changes, DNSSEC tamper, transfer-lock removal). The all-four-locks posture on blackrock.com (ev_005) raises the bar — an attacker still needs the CSC portal session to lift locks — but does not negate the threat. Brave web-search quota was exhausted (ev_110), so the breach-corpus check that Codex-baseline pivot piv_034 (ev_121) queued was not executed; a future recon pass with breach-corpus access should re-test. Confidence is moderate (mechanism is observable; exploitation status unknown). Severity is severe — recovery is slow and reputational damage is total.

Blue · Defensive Control B-05

Harden CSC registrar-portal authentication for DNRAdmin@Blackrock.com

Confirm DNRAdmin@Blackrock.com is configured at CSC with phishing-resistant MFA (hardware keys, not SMS/email OTP) and IP allowlisting to a small set of NetOps egress addresses. Verify CSC's portal session timeout is short (≤15 minutes idle). Run the breach-corpus check that the original Codex pivot piv_034 (ev_121) queued but did not execute (Brave quota was exhausted, ev_110) — confirm DNRAdmin is not present in HIBP, Cit0day, or Combolist material. Establish a documented split-knowledge dual-control process for any unlock of the four registry locks on blackrock.com. Periodically rotate the CSC portal credential out of the password manager (LastPass) into a hardware-token-only vault.

SEVERE R-08 ↔ B-08 Aladdin supply-chain poisoning via Harbor/Artifactory/SVN post-foothold Moderate confidence

Red · Adversary Vector R-08

Aladdin supply-chain poisoning via Harbor/Artifactory/SVN post-foothold

Harbor production clusters (EWD, HAL) with admin and preprod variants (ev_017, ev_080), JFrog Artifactory (ev_016), and an active SVN server (ev_020) are all internal-only but enumerable via CT logs. Once an adversary obtains an Okta/VPN foothold (R-04 or R-05), the supply-chain inventory is the natural pivot. A poisoned Harbor image or JFrog artifact likely ships into Aladdin or downstream BlackRock-owned infrastructure used by 1,000+ institutional clients. Confidence is moderate — exploitability depends on internal segmentation that passive recon cannot test.

Blue · Defensive Control B-08

Internal segmentation + signed-image enforcement on Harbor / Artifactory / SVN

Enforce signed-image admission (Cosign / Sigstore + Kyverno) at the Aladdin / BlackRock Kubernetes admission controllers — only Harbor-pushed images signed by the build pipeline run in production. Restrict Harbor admin (harbor-admin-ewd.blackrock.com, harbor-admin-hal.blackrock.com) to a jump-host with hardware-key MFA. For JFrog Artifactory, enforce repo-level RBAC and require signed builds. Plan the SVN decommissioning: migrate remaining repos to Git, scrub commit history for credentials with truffleHog/gitleaks before publishing to the new SCM, then sunset SVN. Network-segment internal-only subdomains away from each other so a compromise of one (e.g., dev-remote) cannot pivot directly to Harbor.

Moderate · Plan Mitigation

5 engagements

MODERATE R-06 ↔ B-06 No CAA — any CA may issue certs for the apex or any subdomain High

Red R-06

No CAA — any CA may issue certs for the apex or any subdomain

DNS CAA query returned NODATA (ev_116, ev_002). Under CA/Browser Forum baseline, the missing CAA record means any globally trusted CA may issue a certificate for blackrock.com or any subdomain without a CAA-check. The threat is unlikely to be exploited absent a CA-side compromise, but the gap is inconsistent with the otherwise-hardened posture (DNSSEC + 4 registry locks + active HackerOne). Trivially fixed by publishing CAA records pinning issuance to the observed CAs (DigiCert Global G2, DigiCert EV RSA G2).

Blue B-06

Publish CAA records pinning issuance to the observed CAs

Publish CAA records on blackrock.com pinning issue and issuewild to digicert.com (and any other CA-of-record). Add a iodef mailto pointing to the security team for the rare legitimate violation alert. This is a one-line DNS change with no operational risk and closes the rogue-cert-issuance defense-in-depth gap. Audit the rest of the portfolio for the same gap; only domains intentionally issuing certs across multiple CAs should remain without CAA.

MODERATE R-07 ↔ B-07 30+ SaaS vendors — third-party breach blast radius Moderate

Red R-07

30+ SaaS vendors — third-party breach blast radius

BlackRock's ~30+ SaaS dependencies enumerable from DNS TXT (ev_002, ev_060, ev_066, ev_113) each represent a separate supply-chain pivot. The LastPass enterprise tenant (ent_252) likely intersects with the 2022-2023 LastPass breach corpus and warrants targeted rotation. The Okta-tenant triplet (corporate / Aladdin US / Aladdin EMEA) is the identity backbone — any Okta-side incident has severe blast radius (cf. Lapsus$ 2022, Okta support-system compromise 2023). The Anthropic and OpenAI enterprise tenants are likely targets for prompt-injection, training-data exfiltration, and IP-leak attacks. The breadth itself raises third-party risk-management overhead even if no individual vendor is per-se weak.

Blue B-07

Vendor-tier the SaaS stack; concentrate breach response on identity and supply-chain crowns

Maintain a tiered vendor inventory: Tier-0 (Okta, Duo, LastPass, Anthropic, OpenAI, Microsoft 365, Salesforce, Atlassian, MongoDB Atlas), Tier-1 (Slack, Zoom, DocuSign, Censys, JFrog), Tier-2 (everything else). For Tier-0, require: SOC2 Type II, contractual breach-notification SLAs, federated SSO via the BlackRock Okta tenant, and quarterly access review. Subscribe to vendor security advisories. For the LastPass tenant specifically, audit and rotate any secret last touched before 2023-12 (post-breach window). For the LLM tenants, deploy prompt-injection / data-loss-prevention controls and disable training data sharing.

MODERATE R-09 ↔ B-09 Pretext attacks on NetOps@blackrock.com (SOA-RNAME-derived NOC mailbox) Moderate

Red R-09

Pretext attacks on NetOps@blackrock.com (SOA-RNAME-derived NOC mailbox)

The SOA RNAME field on blackrock.com encodes netops.blackrock.com, which decodes to netops@blackrock.com — the NOC mailbox managing the zone (ev_114). An adversary likely uses this as a pretext target for a 'DNS emergency' email or a call to CSC's portal-support line claiming to be from NetOps. Confidence is moderate; mitigation is procedural (CSC-side caller verification, NetOps-mailbox phishing controls).

Blue B-09

Phishing-resistance hardening on NetOps mailbox + CSC caller verification protocol

Treat netops@blackrock.com as a high-value mailbox: hardware-key MFA, automatic forwarding restrictions, no auto-reply, and SOC monitoring on inbound messages purporting to be from CSC. Coordinate with CSC's account team to require a callback to a known NetOps phone number for any portal-credential reset or lock-removal request — and document the protocol so NetOps staff cannot be socially-engineered into bypassing it. Consider rotating the SOA RNAME to a less identity-rich label (dnsadmin.blackrock.com) so the SOA does not encode the team's mailbox; this is cosmetic but removes one public identifier.

MODERATE R-10 ↔ B-10 Possible Azure DMZ subdomain-takeover via wildcard cert Low

Red R-10

Possible Azure DMZ subdomain-takeover via wildcard cert

The wildcard cert *.extdns.azblkdmz.blackrock.com (ev_036, ev_092, ev_099) hides individual Azure DMZ hostnames but those hostnames likely exist in BlackRock's internal Azure tenant. If any of the underlying Azure resources is decommissioned without removing the DNS record (a dangling CNAME), an adversary likely can claim the Azure resource name and serve under the BlackRock wildcard cert chain. Confidence is low because the dangling-CNAME condition is not testable from passive recon; severity is moderate because Azure-takeover patterns are well-documented and the surface is real.

Blue B-10

Subdomain-takeover hunt across the Azure DMZ wildcard tenants

Audit the Azure tenant backing *.extdns.azblkdmz.blackrock.com for orphaned CNAMEs (records pointing to azurewebsites.net, blob.core.windows.net, cloudapp.azure.com, trafficmanager.net targets that no longer exist). Repeat for the FIT zones (*.fit-blz.azure.blackrock.com, *.fit-tsz.azure.blackrock.com). Subscribe to internal CT-log monitoring on all wildcard certs so a takeover-issued cert under a BlackRock wildcard would alert. Enforce 'delete DNS before deleting Azure resource' as a deprovisioning standard.

MODERATE R-11 ↔ B-11 Legacy SVN — credential-in-history risk post-foothold Low

Red R-11

Legacy SVN — credential-in-history risk post-foothold

An active SVN server (svn.blackrock.com) is unusual in modern enterprise contexts; likely a maintenance-mode legacy system. SVN commit histories likely contain credentials, hardcoded secrets, and references to internal hostnames not otherwise exposed. Reachability requires an internal foothold; exploit difficulty depends on the specific Apache mod_dav_svn version, which is not observable passively.

Blue B-11

SVN sunset path; credential-history scrub on any extracted repos

Commit to a dated SVN sunset (90-180 days). Until then: restrict svn.blackrock.com access to a minimal user set behind hardware-key MFA, patch to the latest Apache + mod_dav_svn, and forward access logs to the SOC. When repos migrate to Git, run truffleHog / gitleaks across full SVN history before publishing — credentials in committed history are the dominant exploitation pattern.

Baseline · Surface-Wide

4 controls

B-12 Baseline

Tighten blackrock.com mail-auth from p=quarantine/~all to p=reject/-all

blackrock.com currently runs SPF ~all (SoftFail) and DMARC p=quarantine (ev_117). The portfolio's smaller domains (futureadvisor.net, alts-iq.com) already run -all + p=reject. Move the corporate domain to the stricter posture once the existing emaildefense.proofpoint.com RUA telemetry confirms no legitimate-mail loss in a two-week observation. The current posture is unusual for an org with this defensive maturity elsewhere and is likely a legacy carve-out for a deprecated send-path; identify and migrate.

B-13 Baseline

Brand-monitoring on look-alike domains across the iShares / BlackRock cluster

Subscribe to a brand-monitoring service (or operate one in-house against passive-DNS sources) that watches for newly-registered domains containing blackrock, ishares, aladdin, iunits, impactinvesting, and the Aladdin tenant client names that CT has now leaked. Auto-feed hits into an evaluation queue: assess, defensive-register if available cheap, or file a UDRP. The iShares cluster (.us, .nl, .it, plus the registered marketing/chart variants) is unusually broad and warrants continuous coverage.

B-14 Baseline

MDN Observatory remediation on the public marketing surface

blackrock.com scored MDN Observatory F (5/10, 5 tests failed) on 2026-06-15 (ev_062). The failing tests are likely a mix of CSP, HSTS, cookie flags, and referrer policy on the marketing edge. None individually is severe, but the F grade is a public reputation signal and inconsistent with the otherwise hardened posture. Remediation is bounded scope and pure config — fix and re-scan.

B-15 Baseline

Continuous attack-surface management via the existing Censys tenant + HackerOne program

BlackRock already has verified Censys (ent_204, ent_120, ent_255) and HackerOne (ent_119, ent_195, ent_213) tenants. Operationalize them: feed the Censys ASM inventory into the same CT-monitoring pipeline (B-01); explicitly include the Aladdin tenant subdomains and brand-domain cluster in the HackerOne scope so external researchers can report look-alikes and rogue-cert issuance. Run quarterly purple-team exercises against the SSO endpoints using the explicit threat model from R-04.