SaaS Hacking: The New Internal Network Attackers Already Use

The attacker does not have to land malware on a domain controller anymore.

In many organizations, the most useful data already lives somewhere else: Microsoft 365, Google Workspace, Salesforce, Slack, GitHub, Atlassian, Zendesk, ServiceNow, Docusign, Dropbox, and dozens of smaller SaaS tools owned by business teams rather than infrastructure teams.

That changes the shape of the intrusion. A compromised identity is no longer just a login. It is a route map across the business.

TL;DR

• SaaS hacking is not one technique. It is an attack style built around valid identities, OAuth grants, API tokens, integrations, exports, and misconfigured sharing.
• The attacker often moves through applications instead of hosts: email to files, files to CRM, CRM to support tickets, support tickets to source code, source code to secrets.
• MFA is necessary, but it does not automatically stop stolen sessions, malicious app grants, overprivileged integrations, or weak SaaS-native controls.
• Defenders need SaaS telemetry in the same incident response workflow as endpoint, identity, and cloud logs.
• The practical question is no longer “did malware execute?” It is “what could this identity or integration read, export, invite, authorize, or automate?”

Why SaaS Became The Internal Network

The old internal network had file shares, mail servers, domain controllers, ticketing systems, finance tools, and source repositories. Attackers moved laterally by stealing credentials, browsing shares, dumping hashes, and pivoting from host to host.

The modern version is distributed across SaaS.

Email lives in Exchange Online or Gmail. Files live in SharePoint, OneDrive, Google Drive, Box, or Dropbox. Customer records live in Salesforce or HubSpot. Internal decisions happen in Slack and Teams. Engineering work lives in GitHub, GitLab, Jira, Confluence, Linear, and CI/CD platforms. Support data lives in Zendesk or ServiceNow. Contracts live in Docusign. HR and payroll live in another set of SaaS platforms entirely.

This is not just “cloud.” It is a permission graph.

If an attacker controls the right account, they can search mail, enumerate files, export CRM records, read internal tickets, invite external users, authorize applications, create API tokens, and use built-in export features. None of that requires an exploit. Much of it looks like normal user behavior unless the organization is watching the SaaS control plane.

MITRE ATT&CK maps part of this under Valid Accounts: Cloud Accounts (T1078.004). The important detail is that valid cloud accounts can support initial access, persistence, privilege escalation, and defense evasion. In SaaS environments, “valid” is often enough.

A Real Pattern: Snowflake Was Not A Snowflake Bug

Mandiant’s 2024 reporting on UNC5537 is still one of the clearest examples of the SaaS attack model.

Mandiant said the campaign targeted Snowflake customer database instances for data theft and extortion. The key point was not a breach of Snowflake’s enterprise environment. Mandiant reported that every incident it responded to in that campaign traced back to compromised customer credentials. Many credentials came from historical infostealer infections. Some had been exposed years earlier and were still valid.

The failures were ordinary and dangerous:

• accounts without MFA
• old credentials that had not been rotated
• no network allow lists for sensitive SaaS access
• contractor systems outside normal endpoint monitoring
• large data stores reachable through normal application interfaces

Once inside, the attacker did not need a kernel exploit. They used database clients, performed reconnaissance, listed tables, staged data, and exported it.

That is the lesson for every SaaS owner: a platform can work exactly as designed while still becoming the breach path. The weak point may be identity governance, token hygiene, contractor access, data export policy, or missing telemetry.

The SaaS Attack Chain

SaaS intrusions usually follow a recognizable pattern.

1. Initial Access

The entry point is often one of five things:

Traditional controls do not cover these equally. MFA helps against password-only login. It does less against already-issued sessions, approved app grants, stolen OAuth refresh tokens, or service integrations that never behave like human users.

2. Application Reconnaissance

The attacker starts asking business questions:

• Which apps does this user have access to?
• Are they a Salesforce admin, helpdesk agent, finance approver, developer, or executive assistant?
• What groups, shared drives, channels, repositories, and customer records can they read?
• Which integrations are installed?
• Can they create reports, exports, API tokens, external shares, mailbox rules, webhooks, or connected apps?

This is lateral movement, but the nodes are applications and datasets rather than workstations.

3. Data Discovery

Attackers search for high-value terms:

• password, secret, token, apikey, private_key
• invoice, wire, bank, payroll, customer export
• incident, breach, legal, contract, acquisition
• AWS_ACCESS_KEY_ID, SNOWFLAKE, OKTA, GITHUB_TOKEN

The search box becomes a post-exploitation tool. So do saved reports, CRM filters, mailbox search, Drive search, Slack history, Confluence pages, and support-ticket attachments.

4. Persistence

SaaS persistence is often quiet:

• a new OAuth grant
• a new API token
• a mailbox forwarding rule
• a new recovery method
• a trusted device registration
• an external guest account
• an integration installed in a workspace
• a new admin user with a plausible name
• a webhook pointing to attacker infrastructure

Password resets may not remove these. That is why SaaS incident response must include session revocation, token revocation, application grant review, trusted device review, and integration inventory.

5. Exfiltration

Exfiltration may look like normal product use:

• Salesforce report export
• Google Drive bulk download
• SharePoint sync
• mailbox export
• Git clone
• Slack export or API scraping
• Zendesk ticket attachment download
• Snowflake stage and GET
• Docusign envelope export

Blocking malware does not stop a user from exporting a CSV if the user’s role allows it.

What Makes SaaS Hacking Hard To Detect

SaaS attacks exploit a visibility split.

Security teams usually own the identity provider, EDR, SIEM, and network controls. Business teams often own the SaaS applications. The most important logs may sit behind separate admin consoles, premium audit licenses, short retention windows, or vendor-specific APIs.

That creates gaps:

• The identity provider sees the login, but not the Salesforce report export.
• EDR sees the laptop, but not the OAuth refresh token used from a cloud host.
• The proxy sees google.com, but not which Drive files were shared.
• The SIEM sees a Slack login, but not the webhook created inside the workspace.
• The SaaS owner sees an export, but may not know the user was phished two hours earlier.

Attackers benefit from that fragmentation. They do not need to hide everywhere. They only need to operate in the place nobody correlates.

Detection: Look For Business-Logic Anomalies

SaaS detection should focus on what the account did, not only where it logged in from.

High-signal behaviors include:

For Microsoft Entra ID, start with app consent, service principal, role assignment, risky sign-in, and device registration events. A simple KQL hunting pattern looks like this:

AuditLogs
| where OperationName has_any (
  "Consent to application",
  "Add service principal",
  "Add app role assignment to service principal",
  "Add member to role",
  "Register device"
)
| project TimeGenerated, OperationName, TargetResources, InitiatedBy, Result
| order by TimeGenerated desc

That does not detect the whole attack. It gives responders a place to start when a user, app, or tenant looks wrong.

For Google Workspace, prioritize third-party app access, OAuth app approvals, Drive sharing events, Gmail delegation and forwarding, admin role changes, suspicious login events, and bulk download patterns. Google’s admin controls allow organizations to restrict internal and third-party app access to Workspace services and to decide how unconfigured third-party apps are handled.

For Salesforce and similar CRM systems, monitor report exports, unusual API clients, impossible travel, connected app authorization, profile or permission-set changes, guest user exposure, and large reads from customer objects such as Accounts, Contacts, Cases, Opportunities, and Users.

For GitHub, GitLab, and developer SaaS, watch for new personal access tokens, new SSH keys, OAuth app approvals, repository cloning spikes, secret scanning alerts, workflow changes, and organization membership changes.

Response: Treat SaaS Compromise Like A Breach, Not A Password Ticket

When a corporate identity appears in stealer logs, approves a suspicious app, or signs in from attacker infrastructure, the first instinct is often password reset.

That is incomplete.

Use this triage model:

Then ask the questions that actually determine blast radius:

1. Which SaaS apps did this identity access after compromise?
2. Which files, records, tickets, reports, repositories, and exports were touched?
3. Did the attacker create persistence through an app, token, device, rule, guest, or integration?
4. Did the account have access to other customers, tenants, environments, or vendors?
5. Did any downloaded data contain secrets that create a second-stage compromise?

If the answer to question five is yes, the incident has moved beyond SaaS. Rotate the exposed downstream secrets.

Hardening That Actually Changes The Outcome

SaaS hardening is not a single product setting. It is governance plus telemetry plus response muscle.

Start here:

1. Require phishing-resistant MFA for privileged and high-data accounts. FIDO2/passkeys or equivalent controls matter most for admins, finance, HR, developers, support agents, CRM owners, and executives.
2. Disable broad user consent where possible. In Microsoft Entra ID, restrict user consent to verified publishers and low-risk permissions, or require admin approval for broader access.
3. Restrict third-party app access in Google Workspace. Treat unconfigured apps as untrusted until reviewed.
4. Inventory SaaS applications and owners. Every major SaaS platform needs a business owner, security owner, admin list, data classification, log source, and incident contact.
5. Review integrations quarterly. OAuth apps, connected apps, API tokens, webhooks, marketplace add-ons, and service accounts should have an owner and expiry expectation.
6. Limit data exports. Restrict bulk export rights to roles that truly need them. Alert on first-time and high-volume exports.
7. Use network and device conditions for crown-jewel SaaS. Sensitive platforms should not accept logins from arbitrary locations when trusted device or trusted network controls are practical.
8. Centralize SaaS audit logs. If a platform holds sensitive data, its audit logs belong in the SIEM or equivalent detection workflow.
9. Practice token revocation. Incident response teams should know how to revoke sessions, refresh tokens, OAuth grants, API keys, and trusted devices before the incident.
10. Monitor for secrets inside SaaS content. Search repositories, tickets, wikis, and shared drives for cloud keys, tokens, passwords, private keys, and .env files.

The goal is not to make SaaS impossible to use. The goal is to make the most dangerous actions visible, reversible, and owned.

The Defender’s Mental Shift

SaaS hacking is not exotic. It is what happens when attackers follow the data.

If the data moved out of the internal network, the attack path moved with it. If business users can export it, attackers can try to export it. If integrations can read it forever, attackers will look for the token that lets them do the same.

The strongest defenders will stop treating SaaS as a procurement category and start treating it as production infrastructure.

That means identity monitoring is not enough. Endpoint monitoring is not enough. SaaS admin consoles are not enough. The useful view is the chain:

identity event -> app authorization -> business action -> data movement -> persistence

That is where modern SaaS intrusions become visible.

Related Posts

• OAuth Consent Phishing in 2026: MFA Stops Password Theft, Not Bad App Grants - Deep dive on malicious app grants and OAuth token abuse.
• Identity-First Attacks in Cloud: How Permissions Become the New Perimeter - How valid permissions replace traditional perimeter compromise.
• Your Data on the Dark Web: How to Find It - Useful context for infostealer logs and credential exposure.
• Trusted Email Is the New Phishing Infrastructure - How legitimate SaaS notification systems become phishing delivery paths.
• C2 Without Owning C2: When Attackers Use Your Trusted Services - How attackers abuse trusted SaaS platforms for command and control.

Sources

• Google Cloud / Mandiant: UNC5537 Targets Snowflake Customer Instances for Data Theft and Extortion
• Microsoft Learn: Configure how users consent to applications in Microsoft Entra ID
• Google Workspace Admin Help: Control which apps access Google Workspace data
• MITRE ATT&CK: Valid Accounts: Cloud Accounts (T1078.004)