Mapping the SaaS Attack Surface

Mapping the SaaS Attack Surface

Speaker: Jaime Blasco

Conference: BSidesSF 2025 — April 26-27, 2025, San Francisco

YouTube: Watch on YouTube

Reading time: ~7 minutes

TL;DR

Attack surface management has long focused on infrastructure and cloud — but when 90% of an organization's applications are SaaS, the attack surface is mostly things the security team does not own and cannot directly scan. Jaime Blasco, co-founder and CTO of Nat Security, demonstrates a comprehensive methodology for mapping SaaS exposure using nothing but public DNS records, certificate transparency logs, SSO redirect behavior, and dark web credential dumps.

Introduction

The traditional definition of attack surface management (ASM) covers IP addresses, domain names, subdomains, and applications exposed to the internet. Security teams have built mature practices around scanning and managing that surface for on-premises and cloud infrastructure. The gap is SaaS — and it is a large one.

Jaime Blasco, co-founder and CTO of Nat Security and formerly of AlienVault (acquired by AT&T), spent much of his earlier career mapping adversary infrastructure for threat intelligence. The techniques he used to trace criminal organizations — passive DNS, certificate transparency logs, SSO behavior analysis — turn out to be exactly the right tools for mapping the SaaS footprint of any company from the outside, as an attacker would.

For some companies Blasco works with, 90% of their applications are SaaS-based — hosted, operated, and secured by vendors the organization does not control. If those applications are breached or misconfigured, the organization's data is exposed regardless of how well its perimeter is hardened.

DNS Records as SaaS Discovery Tools

▶ Watch: DNS-based SaaS discovery (3:00)

The most accessible layer of SaaS discovery starts with DNS. Blasco walks through a hierarchy of increasingly detailed signals:

MX records reveal email routing immediately: Google Workspace or Microsoft 365 can be identified from MX records within seconds. Presence of Proofpoint, Mimecast, or similar services is also visible at this layer.

SPF (Sender Policy Framework) TXT records are richer. SPF specifies which services are authorized to send email on a domain's behalf, which means every marketing platform, development tool, and SaaS service that sends transactional email shows up in the SPF record — HubSpot, SendGrid, and similar services are commonly visible.

Domain validation TXT records are the most revealing and most overlooked. Many SaaS vendors require customers to prove domain ownership by adding a specific TXT record. OpenAI's domain verification uses a predictable format. Vendors like Pagerduty use a subdomain prefix — not random strings — meaning a brute-force wordlist of vendor-specific prefixes can enumerate which providers a company has validated. Blasco identifies the correct pattern as generating a random string per customer (as Sendlayer does), noting that predictable prefixes effectively announce the vendor relationship to any observer. Most organizations never delete these records after onboarding.

CNAME records on subdomains point to SaaS provider infrastructure. SafeBase, Salesforce, Skilljar, and even Jamf (an MDM tool that should be internal) have all been found leaking via CNAME records that resolve to the vendor's domain.

Subdomain Enumeration and Passive DNS

▶ Watch: Subdomain brute forcing and certificate transparency (10:00)

Active subdomain enumeration uses tools like subfinder from Project Discovery. Passive DNS databases — which Blasco built in his previous life at AlienVault (now AlienVault OTX, available free) — aggregate historical DNS resolution data. Other commercial options include DomainTools, Silent Push, and SecurityTrails.

Certificate Transparency (CT) logs are particularly powerful. Every time a new TLS certificate is issued, the Certificate Authority writes a log entry. If that certificate is not a wildcard, it contains the specific subdomain. A public CT log aggregator like crt.sh exposes this data in real time. An organization that issues a certificate for staging.vendor-product.acme.com has just broadcast both the vendor relationship and the existence of a staging environment.

SaaS vendors that create customer-specific subdomains (the example given is 8fold.ai) inadvertently expose their full customer list to anyone who runs passive DNS or CT log queries against their infrastructure. Combining vendor domain knowledge with these data sources produces a map of every customer of that vendor.

SSO Redirect Enumeration at Scale

▶ Watch: SSO-based enumeration and automation (18:00)

Single sign-on redirect behavior is a particularly rich signal. The two SSO flows — Identity Provider (IdP) initiated and Service Provider (SP) initiated — both leak information in different ways.

In SP-initiated SSO, when a user visits the SaaS application and enters their email address, the application redirects them to their organization's IdP. If an attacker enters [email protected] in Asana's login form and Asana redirects to okta.okta.com, that confirms Okta is an Asana customer — trivially, without any breach required. Some applications go further: Palo Alto Prisma Access automatically redirects to the customer's IdP without requiring an email address at all, making customer enumeration fully automated without any user interaction.

For Microsoft Entra ID (formerly Azure AD), the tenant is identified by a GUID in the redirect URL. Once that tenant GUID is known, tools like Shodan, Censys, and Fofa can search for other applications that also redirect to that tenant — discovering every SaaS application in the organization's estate that uses Entra ID, without any prior knowledge of what those applications are.

Counter-enumeration: Blasco demonstrates the case of WalkMe and its use of AWS Cognito. Cognito, trying to protect against user enumeration, was configured to not redirect to the IdP if the user does not exist — preventing automatic SSO-based enumeration. However, this just shifts the attack: now the attacker needs a valid email address. Blasco's solution is to find a customer story on the WalkMe website, identify a named employee using Apollo.io (a sales intelligence tool), look up that employee's email address, and use it. SSO redirect confirmed. The recommendation to marketing teams follows accordingly: customer success stories are attack surface.

Dark Web and Infosteal Dumps as Tenant Discovery

▶ Watch: Credential dumps and tenant mapping (25:00)

Even invalid credentials in infostealer dumps are useful for this purpose. If a dump contains [email protected]:password123 and a URL like acme.service-now.com, the attacker now knows the target has a ServiceNow tenant — even if that password has been rotated long ago. Vendors offering this data include Hudson Rock, Constella Intelligence, and SpyCloud.

The Snowflake breach of 2024 is the explicit real-world anchor: a threat actor purchased access to compromised Snowflake credentials from infostealers, then systematically accessed every tenant whose credentials appeared in those dumps without MFA enforcement. The attack succeeded at scale precisely because the attacker could enumerate target tenants from the credential data and know which tenants were worth attempting.

Lazarus Group, Blasco notes, targets SaaS providers in the supply chains of their actual targets — cryptocurrency companies — using the same enumeration techniques to identify which tooling vendors serve the companies they are ultimately trying to compromise. Mandiant's 2024 M-Trends report confirmed that SaaS and cloud compromises now represent the norm rather than the exception in their incident response engagements.

Defensive Recommendations

For organizations:

• Delete DNS records immediately after domain validation. Every record left in place broadcasts a vendor relationship indefinitely.
• Register unrelated domain names for SSO and critical production infrastructure. The most sophisticated security organizations Blasco has observed use completely separate domain names with no tie to the company name for IdP configuration.
• Enforce IdP-initiated SSO wherever possible. This eliminates the SP-initiated redirect that leaks IdP information.
• Disable user invitations and open-enrollment in SaaS applications, which otherwise allow any address from the corporate domain to join.
• Monitor for unmanaged tenants and shadow IT — employees creating tenants in SaaS applications outside IT visibility.
• Monitor credential exposure on dark web sources and enforce password uniqueness to prevent credential stuffing.
• Deploy SaaS canary tokens. Canary Tokens recently added support for SAML IdP tokens — if an attacker enumerates your fake application, the canary fires.

For SaaS vendors:

• Avoid customer-specific subdomains. If tenant URLs must be unique, randomize them (as Duo and Snowflake do to some degree) rather than using the customer name.
• Do not charge for SSO. The "SSO tax" drives organizations to use username/password instead, degrading the security of every customer who cannot afford the premium tier.
• Use random tenant identifiers, not predictable patterns like customer.vendor.com.
• Enforce SP-initiated SSO validation — require the tenant ID, or the redirect becomes a free enumeration API.
• Do not auto-redirect in the SP-initiated flow without requiring user confirmation.

Notable Quotes

"Some companies we work with have 90% of their applications as SaaS-based. They are not really owned by them. So some of the traditional techniques I'm going to share are adapted from what I used to do to map adversary infrastructure."

"I truly don't recommend people to do customer success stories because of this — it is really easy to find the fact that you're a customer of a specific technology, and that's part of your attack surface."

"Do not charge for SSO, please. Everybody hates that."

Key Takeaways

• SaaS attack surface is broadly discoverable through entirely passive means. DNS records, CT logs, and SSO redirect behavior reveal an organization's full SaaS stack without any scanning or exploitation.
• Domain validation TXT records and CNAME records persist long after onboarding. Cleaning up these records on a regular cadence is low-effort and directly reduces information disclosure.
• SP-initiated SSO redirect is a free enumeration API. Any SaaS application that automatically redirects to an IdP based on an email address or without authentication is telling the world who its customers are.
• Infostealer credential dumps reveal tenants even when passwords are stale. Tenant URLs in dump data persist as valid attack surface information regardless of whether the credentials work.
• The Snowflake breach is the canonical SaaS supply chain attack. Credential enumeration from infostealer data, combined with absent MFA enforcement, produced a breach affecting hundreds of organizations from a single campaign.