Internal Audit as External Threat Hunter - Quant. Sec.
What mapping our own Squarespace site revealed about residual risk, multi-tenancy, and sensor noise.
Introduction
Most organizations treat external reconnaissance as something that happens *to* them. Attackers map DNS, fingerprint services, pull Certificate Transparency history, inventory reverse-IP neighbors, and probe for weak identity controls. Defenders usually respond after the fact—or never see the full external view of their own assets.
In August 2026 we inverted that posture. We treated `
` as a target and ran a deliberate, time-boxed internal security audit using the same techniques an external threat hunter or opportunistic attacker would employ. The engagement window was short—roughly 9–14 August—but the dataset was dense: DNS and registration mapping, service fingerprinting, Certificate Transparency review, large-scale host and path probing against co-tenant neighbors, and correlation against our own live defensive sensors (QuantC and QuantumGuard).
The central finding was not a compromise. The origin was never hijacked. There was no evidence of a phishing kit or intermediary on the live site. Hosting resolved cleanly to Squarespace’s multi-tenant anycast edge. What the exercise did expose, with unusual clarity, was the residual attack surface that persists on legitimate modern SaaS platforms and the ways that surface can still produce brand abuse, detection confusion, and false narratives.
This article is a case study of that work. It is written for practitioners who run or consume internal audits, for teams that rely on SaaS web hosting, and for anyone who has ever looked at reverse-IP results or dual service fingerprints and wondered whether they were looking at compromise or normal platform behavior.
Scope and Method
The engagement was framed as an internal control and adversary simulation exercise, not a penetration test of Squarespace itself. We stayed within policy constraints that mattered: no further use of certain third-party lookup APIs after a mid-engagement decision, no mass exploitation of co-tenant sites, and heavy reliance on local reverse-IP dumps plus direct resolution and probing.
Core techniques included:
Ownership and consistency checks via dig, WHOIS/RDAP, and Certificate Transparency (
).
Service and implementation fingerprinting with nmap and direct HTTP/TLS inspection.
Host and path surface mapping at scale.
Correlation of the recon activity against live QuantC and QuantumGuard traffic and alert streams.
Explicit testing of common phishing-kit and intermediary indicators (path patterns, cookie behavior, 404 body shapes, historical certificate names).
The working questions evolved in a deliberate progression:
Is DNS and hosting consistent with ownership?
Are the “stranger” hostnames visible on reverse-IP lookups evidence of compromise or multi-tenancy?
Does the Go `net/http` fingerprint imply a phishing kit or intermediary?
What attack surface remains even if the stack is legitimate SaaS?
What do our own sensors record when we thrash our own edge?
How do the roughly 1,900 `.academy` neighbors actually distribute in public IP space?
Those questions produced a clear high-level verdict: origin not compromised, hosting identity established as Squarespace multi-tenant anycast the most material residual risks concentrated in identity and brand controls rather than server ownership.
Infrastructure Reality: Legitimate Multi-Tenancy Looks Crowded
At the time of the audit the domain was approaching its September 2026 expiry. Authoritative nameservers were a combination of NS1 (p07 set) and Squarespace’s own DNS service. The web edge resolved to the well-documented Squarespace anycast addresses in the 198.49.23.0/24 and 198.185.159.0/24 ranges. PTR records on those addresses were empty—expected behavior for multi-tenant edges. TLS certificates were Let’s Encrypt for the customer hostnames; bare-IP connections without proper SNI/Host returned 403 responses carrying Squarespace edge markers and a DigiCert `*.squarespace.com` certificate.
Customer content is name-gated. Connecting to the anycast IPs with a foreign Host header or no SNI does not freely serve the site. That fact closed one common worry: an attacker cannot simply pull the full customer site by IP alone.
The reverse-IP neighbor picture, however, was large. Local dumps and subsequent resolution work produced a working set of roughly 2,020 domains. Of those, approximately 1,898 ended in `.academy`. The overwhelming majority of resolvable `.academy` names (about 1,767) pointed exclusively at the same Squarespace anycast quartet that serves our own site. A much smaller set lived on Cloudflare, Google, AWS-ish, GitHub Pages-style, Vercel-style, or miscellaneous VPS addresses. A handful mixed. Roughly 80–90 names failed to resolve at all.
This is the normal appearance of a popular multi-tenant platform, not a takeover. Shared anycast edges concentrate thousands of customer hostnames onto a small set of public IPs. Tools that emit reverse-IP lists therefore surface large populations of “strangers.” Interpreting those strangers as owned or compromised infrastructure is a common analytical error. The correct reading is co-tenancy and platform monoculture: reputation and scanner noise on the shared IPs can affect many customers at once, and the blast radius of any platform-level issue is wide.
The Dual-Fingerprint Puzzle
nmap consistently labeled the service as a Golang `net/http` server. The HTTP `Server` header simultaneously returned `Squarespace`. HTML comments, site identifiers, crumb cookies, and CDN behavior all confirmed the Squarespace CMS and edge. Certificate Transparency history showed only the expected apex and www names issued since domain creation; no anomalous intermediate or kit-related names appeared.
This combination is not evidence of two competing servers or of a malicious Go-based intermediary sitting in front of Squarespace. It is the expected layering of a Go-implemented platform that brands itself with a product header. The implementation fingerprint and the product identity coexist because they describe different layers of the same edge.
The residual risk is operational rather than technical compromise. Security operations tools that key heavily on service banners or implementation fingerprints can disagree with tools that key on the `Server` header or on application markers. That disagreement creates opportunities for delay, over-allowlisting, or attacker kits that deliberately spoof the Squarespace header on a Go stack. Documenting the dual fingerprint internally so that it is treated as known platform behavior, rather than anomalous, is a practical control.
Separate testing against classic Gophish-class indicators (distinctive 404 bodies, specific tracking paths, admin static assets, characteristic cookies) produced no supporting evidence on the origin. The hypothesis of an active malicious Go kit on this particular site was rejected.
What the Sensors Recorded
While the recon ran, we captured live streams from QuantC and QuantumGuard. The volumes were substantial: QuantC traffic logs on the order of hundreds of thousands of lines with heavy Squarespace string hits; QuantumGuard main and traffic logs measuring in the millions of lines across active and rotated files. Top talkers predictably included the local host, the gateway, and the Squarespace anycast addresses, followed by other CDN and cloud ranges.
The practical lesson is straightforward. When you deliberately generate external-looking traffic against your own edge, your sensors will record a great deal of legitimate platform noise. Distinguishing that noise from real attacks requires tuning that accounts for the expected behavior of the platforms you actually use. Self-recon is one of the cleaner ways to obtain that ground truth.
A secondary observation concerned scan technique quality. A side probe against a Cloudflare address produced the familiar mass of “open” ports under default nmap behavior. Connect-style scanning with reason codes largely restored sanity (mostly connection refused, with limited exceptions). Default scanner settings against anycast or CDN edges routinely invent service inventories that do not exist. Technique discipline matters as much as tool choice.
Residual Risks That Actually Matter
Because the origin itself was clean, the material residual risks shifted to identity and brand surfaces:
Email authentication gap - No MX, no SPF, and no DMARC. Spoofed mail from `
.org` remains trivially possible. This is the highest-severity finding: an attacker can construct credible phishing or “webmail/portal” narratives without ever touching the website.
Domain lifecycle - Expiry in September 2026 and unconfirmed transfer-lock status create a time-bound takeover window if auto-renew or registrar MFA fails.
Clone feedstock - The public site is large, CDN-backed, and carries identifiable markers. High-fidelity visual and structural clones can be stood up off-origin.
Shared-IP reputation and camouflage - Co-tenant activity and scanner noise on the anycast addresses can affect reputation scoring and create cover for lookalike infrastructure.
Process/detection risk - The dual fingerprint and the density of co-tenant traffic both increase the chance of SOC confusion or false narratives.
None of these require origin compromise. They are asymmetric, brand-centric risks that classic “is the box owned?” checklists systematically under-weight.
Lessons for Internal Audit Practice
First, internal audit gains force when it deliberately adopts external attacker techniques. Ownership checks, reverse-IP context, fingerprint layering, Certificate Transparency continuity, and sensor correlation under self-generated load produce a more accurate external view than configuration reviews alone.
Second, multi-tenancy must be treated as a first-class analytical category. Large reverse-IP neighbor sets on SaaS platforms are usually evidence of shared infrastructure, not of lateral movement or takeover. Misreading them generates both false incidents and missed residual risks.
Third, fingerprint disagreement is not automatically malice. Implementation and product headers can describe the same edge. The operational task is to document the expected combination so that tools and analysts do not treat it as anomalous.
Fourth, residual risk frequently lives outside the origin. Clean hosting does not eliminate brand email spoofing, visual cloning, domain lifecycle exposure, or shared-reputation effects. Defense priorities should reflect that distribution.
Fifth, self-recon is a high-value sensor exercise. Watching QuantC and QuantumGuard ingest the traffic we ourselves generated provided direct insight into noise versus signal on the actual platforms we use.
Sixth, scan quality and interpretation discipline remain foundational. Default nmap behavior against CDN anycast edges invents open ports; connect scanning and reason codes restore reality. The same principle applies to rate-limit responses (heavy 429s during list probing) and to SSL name-mismatch noise on shared certificates.
Finally, neighbor graphs supply threat context even when they do not supply owned assets. Mapping the concentration of nearly two thousand `.academy` names onto the same anycast edges illustrates both the monoculture risk of popular platforms and the reputation blast radius that comes with them.
Practical Remediation Priorities
Immediate actions (days, not weeks) center on identity controls:
Publish a restrictive SPF record (`v=spf1 -all`) and a reject-policy DMARC record with appropriate rua reporting.
Confirm auto-renew, transfer lock, and MFA on the registrar account.
Confirm MFA and session hygiene on the Squarespace account.
Consider a short public statement that the domain does not host webmail or customer portals.
Thirty- to ninety-day work includes CAA records if compatible with the certificate authority in use, brand and lookalike monitoring via Certificate Transparency, an internal SOC note on the dual fingerprint, and a deliberate decision on DNSSEC versus acceptance of residual DNS risk. Optional front-end protections (for example, a DNS or WAF layer) can be evaluated if policy requires them.
These steps do not “fix” multi-tenancy or eliminate cloneability; they close the highest-leverage identity gaps that the audit surfaced.
Closing Judgment
This audit did not uncover a compromised Squarespace origin or a hidden phishing kit on quantitativesecurity.org
It did something more useful for internal security practice: it demonstrated that legitimate, modern SaaS hosting still produces an external attack surface that classic ownership checklists miss.
Reverse-IP neighbor graphs and nearly two thousand `.academy` hostnames resolve overwhelmingly to the same Squarespace anycast edges that serve the brand—evidence of multi-tenancy, not takeover. The Go `net/http` fingerprint coexists with the `Server: Squarespace` header because the edge is a Go-implemented platform, not because a second malicious service was present. Certificate Transparency and long-lived Let’s Encrypt issuance support continuity of control.
The material threats that remain are asymmetric and brand-centric: absence of SPF and DMARC enables spoofed mail; a public, highly cloneable site enables off-origin portals; dual fingerprints and shared IP reputation enable detection failure and false narratives. Live QuantC and QuantumGuard streams during the recon showed sensors absorbing large volumes of legitimate edge traffic—another concrete lesson in tuning for real attacks versus self-generated noise.
The case is a successful internal audit that mapped truth and residual risk, not as an incident of origin compromise. The defense priority is identity controls (mail authentication, domain lock, MFA) and operational clarity about what shared hosting actually implies, followed by optional platform hardening. The offensive methods used—DNS and IP graphing, layered fingerprinting, list-scale probing, and sensor correlation—are the same class of tactics used against organizations every day. Running them against oneself is how internal audits earn their keep.
