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

1 engagement

SEVERE R-01 ↔ B-01 Sender-impersonation phishing of broker / benefits clients High confidence

Red · Adversary Vector R-01

Sender-impersonation phishing of broker / benefits clients

The DMARC p=none posture on a health-analytics firm's apex is the single highest-impact finding in this recon set. The attack does not require any compromise of Acclaim's infrastructure — only knowledge of the domain and the firm's client list (publicly inferable from the marketing site's customer-facing content). Very likely end-state: PHI-bearing replies or wire-transfer reroutes into adversary-controlled mailboxes. Counter: r_01 → b_01.

Blue · Defensive Control B-01

Stage DMARC to `p=quarantine`, escalate to `p=reject`

Counter to r_01. Two-step rollout: (1) publish v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@acclaimhealthanalytics.com; pct=100; and monitor aggregate reports for 14 days to identify legitimate senders failing alignment; (2) escalate to p=reject after the report stream is clean. Tighten SPF in parallel (~all → -all). Implementation can be done at the registrar/DNS provider without touching WordPress.com.

Moderate · Plan Mitigation

5 engagements

MODERATE R-04 ↔ B-04 Typosquatted lookalike combined with permissive SPF High

Red R-04

Typosquatted lookalike combined with permissive SPF

Typosquat-based phishing is a perennial low-effort vector against any business with a public website. The recon does not surface evidence of any defensive typosquat registrations by Acclaim. Counter: baseline brand-monitoring (b_04).

Blue B-04

Defensive typosquat registration + brand monitoring

Counter to r_04. Defensively register the high-likelihood lookalikes (acclaim-healthanalytics.com, acclaimhealth-analytics.com, acclaimhealthanalytics.net/.org/.health) and configure passive monitoring (e.g., dnstwist + a CT-log watcher) for newly-registered confusables. Cheap, deterministic mitigation against a vector that doesn't require any platform-level coordination.

MODERATE R-02 ↔ B-02 XML-RPC system.multicall credential amplification Moderate

Red R-02

XML-RPC system.multicall credential amplification

Classical WordPress credential-amplification vector. Acclaim's posture is bounded by Automattic platform defaults — WordPress.com typically applies brute-force throttling, which downgrades but does not eliminate the vector. Self-mitigation by Acclaim is limited because /xmlrpc.php control sits at the platform level. Counter: r_02 → b_02.

Blue B-02

Disable or restrict XML-RPC at the WordPress.com tenant level

Counter to r_02. WordPress.com tenants can disable XML-RPC entirely via the tenant control panel, or restrict it to specific IP ranges. If disable is not feasible (because Jetpack or other integrations require it), enable application-layer rate-limiting via Jetpack's brute-force protection module. Audit any application passwords in /wp-admin/authorize-application.php.

MODERATE R-03 ↔ B-03 WP REST user enumeration for targeted credential attacks Moderate

Red R-03

WP REST user enumeration for targeted credential attacks

Standard WordPress default state. The recon did not directly observe the wp/v2/users route returning data (only oembed/1.0 was confirmed accessible), so this vector is rated moderate confidence — present in the threat surface but contingent on the route not being explicitly disabled. Counter: r_03 → b_03.

Blue B-03

Disable WP REST `wp/v2/users` route for unauthenticated callers

Counter to r_03. Add a rest_endpoints filter (or install a plugin such as Disable REST API) to require authentication on the wp/v2/users route. Confirms the recon's assumption that the route may be enabled and removes the username-enumeration surface entirely. Compatible with continued use of public oembed/SEO routes.

MODERATE R-05 ↔ B-05 Unpatched WP/Divi/Jetpack CVE exposure if cadence lags Low

Red R-05

Unpatched WP/Divi/Jetpack CVE exposure if cadence lags

Generic WordPress stack exposure. The realistic risk on managed WordPress.com hosting is unlikely at any given moment — Automattic's platform-ops cadence is one of the better in the WP ecosystem — but the recon cannot affirmatively confirm current patch level. Confidence is low because the vector is contingent on a platform-level state the recon did not directly measure. Counter: r_05 → b_05.

Blue B-05

Confirm WordPress.com platform patch SLA + enable Jetpack security scanning

Counter to r_05. Contact Automattic / WordPress.com tenant support to confirm the patch-cadence SLA for the tenant's plan tier. Enable Jetpack Scan (paid feature) for automated CVE detection across core/theme/plugins. Document the chain-of-custody for patch responsibility so any incident-response engagement knows which layer owns remediation.

MODERATE R-07 ↔ B-07 Undiscovered sibling-apex client portal (watch item) Low

Red R-07

Undiscovered sibling-apex client portal (watch item)

This is a watch vector, not a confirmed finding. The recon's passive enumeration converged cleanly on the marketing apex but did not pivot to corporate-trademark or address-of-record searches that would surface sibling apexes. Roughly even chance such an apex exists for a B2B health-data firm of this size. Counter: extend recon scope (b_07).

Blue B-07

Pivot recon to corporate-records and trademark searches to test sibling-apex hypothesis

Counter to r_07. Run a follow-up corvus-recon scoped to "Acclaim Health Analytics LLC" as a corporate entity rather than as an apex — pivot through SEC filings (if applicable), state-level business filings, trademark databases, and historical employee LinkedIn for product references. Goal: confirm or rule out the existence of a separately-hosted PHI portal that this recon did not surface.

Low · Monitor

1 engagement

LOW R-06 ↔ B-06 Shared 51-domain cert reputation contamination Moderate

Red R-06

Shared 51-domain cert reputation contamination

The actual security impact of co-tenancy on a multi-SAN cert is low — TLS itself does not allow lateral movement between SANs. The realistic adversary use is reputation correlation: if a co-tenant gets blocklisted, downstream IP-reputation feeds may flag Acclaim by association. Mitigation requires moving off WordPress.com to dedicated infrastructure, which is a structural decision beyond technical hardening. Counter: r_06 → b_06.

Blue B-06

Evaluate dedicated hosting if cert-based trust signals matter downstream

Counter to r_06. If any downstream consumer of Acclaim's services performs cert-pinning, shared-IP reputation lookups, or SAN inspection, evaluate moving the marketing site to a dedicated hosting tier (WordPress.com Business / VIP, or a managed-WP provider that issues per-tenant certificates). The cert-based reputation signal cannot be improved without leaving shared hosting.

Baseline · Surface-Wide

3 controls

B-08 Baseline

Enforce MFA across all Google Workspace + WordPress.com administrative accounts

Baseline. Mandatory MFA on Google Workspace (covers inbound mail, calendar, drive), WordPress.com administrator accounts (covers site management), GoDaddy (covers registrar lock state), and any analytics or BI tooling not surfaced by this recon. Reduces effectiveness of credential-stuffing across r_02, r_03, and any unrelated future credential leaks.

B-09 Baseline

Publish CAA records pinning issuance to authorized CAs

Baseline (addresses ent_017). Publish 0 issue "letsencrypt.org" and any other CA actually used by Automattic for the apex. Closes the cert-misissuance attack class even though direct exploitation is very unlikely. Low-effort one-time DNS change at GoDaddy.

B-10 Baseline

Enable DNSSEC at the registrar + nameserver layers

Baseline (addresses ent_015). Coordinate DNSSEC enablement at GoDaddy and DS-record publication at WordPress.com's nameservers. Lower priority than the DMARC fix; this is residual hardening rather than a load-bearing control.