From help desk exploitation to supply chain compromise, attackers are exploiting blind spots in SaaS threat detection capabilities. Here’s what you need to know:
SaaS is a powerful enabler for businesses—and attackers. In recent weeks, Obsidian has observed threat actors exploiting the speed and flexibility of SaaS environments to execute attacks compromising identities and applications. While some of these TTPs aren’t new, they remain effective because many organizations still struggle to detect and respond to them.
Key questions to consider:
- How well-trained is your help desk at handling calls requesting account access resets?
- How confident are you that your internal and third-party applications are properly secured and monitored?
- Do you have a documented response playbook for when an admin account is compromised in your tenant?
We'll examine what this malicious activity looks like in your logging telemetry and provide actionable tips to protect your organization against these attack vectors.
Help Desk Social Engineering & MFA Bypass
Social engineering calls targeting service desk and IT personnel continue to be effective. These calls give attackers unique advantages. Adversaries typically gather intelligence on a few key personnel, usually those with high-ranking job titles and elevated permissions or access to sensitive resources.
Once the social engineering succeeds, the attacker’s initial access often lands them directly on a high-value account. Post-authentication activity is more deliberate. Immediate action on intent takes place before the victim organization becomes suspicious. Often, the victim’s MFA is also reset during the attacker’s call to the help desk. This allows the attacker to establish their own MFA methods on the account as soon as access is gained.
These malicious MFA methods prove useful when additional prompts are required. As the attacker moves through the environment and signs into various apps, their MFA methods enable continued access. If these methods are not removed during remediation, a Self-Service Password Reset (SSPR) battle can ensue between attacker and victim; one trying to regain access, the other trying to retain it.
Once inside, attackers typically delete emails related to help desk tickets, password resets, or MFA changes. At this point, they know they are on the clock. We’ve observed immediate efforts to search for and download sensitive documents detailing identity architecture, VPN setup, and remote access policies.
Even with access limited to a few hours, post-authentication activity is swift. Follow-up attacks often occur, informed by the intelligence gathered.
The help desk playbook for resetting passwords and MFA greatly impacts dwell time. In one case, the victim was completely locked out after a password reset and session revocation. Prompted to log in, they realized their credentials no longer worked—triggering suspicion and leading them to contact the help desk before the SOC received alerts.
If sessions are not revoked, the victim may not notice anything until their sessions expire, based on session lifetime and sign-in frequency policies. We’ve observed dwell time increase by up to 80% when sessions are not revoked. A difference of minutes versus hours can have an exponential impact when a prepared threat actor is executing a plan.
What does it look like?
Obsidian has several ways to collect data from various SaaS services. Below is a screenshot of what Microsoft logging telemetry looks like when an admin resets a user’s password and MFA, prompting the attacker to set a new password and MFA method during their initial login.
What should I do?
Step up the standards and requirements your IT team uses to reset passwords and MFA on accounts. Require a face-to-face video call where an employee can verify their identity visually, along with a corporate-supplied ID or verification card. Attackers often just need a couple of pieces of information to verbally convince an IT admin to reset access to a target account.
The industry needs to migrate toward requiring more robust forms of verification to complete an account access reset. Due to the rapid nature of this attack vector, detections must be in real-time. However, if it is not immediately noticed by the SOC, the usefulness of the alert may be limited to being a discoverable artifact that can help an incident response team understand what occurred.
Completely booting a target from their own account when sessions are revoked will certainly prompt a rapid response from the victim.
Always revoke sessions. When your IT team needs to reset access to an account, they should also revoke sessions. Various conditional access policies configured in a tenant will impact how long-lived certain sessions may be. Despite a password reset, an attacker will still have access via existing sessions until a policy is triggered that requires a new sign-in. Adopting a standard in which all sessions are revoked when access is reset will help reduce dwell time should an attacker be involved.
Compromised Applications, Compromising Applications
Organizations with a mature SaaS security posture are still vulnerable to application compromises and supply chain attacks. Unlike the abrupt nature of help desk social engineering, the lack of controls and monitoring of enterprise applications can lead to days of dwell time for an attacker.
What happens when a trusted enterprise application responsible for data security and resilience is compromised and used against your organization? Are you confident this sort of activity would be detected in real-time?
High-risk applications typically have a baseline of historical run locations. These apps run from dedicated data centers, ISPs, and IP ranges. If an app deviates from its normal access patterns, that may be the first indicator of compromise.
We’ve observed attackers take advantage of vulnerabilities in third-party applications to target customers of that third party. Despite compromising an application that has permission to access every file for every user within an organization, the attacker may instead take advantage of a different permission—one that allows privilege escalation and lateral movement. This is likely a decision tightly linked to the threat group’s overall modus operandi.
If an adversary is able to compromise an application that can modify other applications within a tenant, there are alarming levels of access paths available to them. It may be obvious to some security teams, but we cannot emphasize enough the importance and risk associated with the Application.ReadWrite.All permission for Microsoft service principals. This allows an app to add permissions or credentials to any existing application while triggering very little telemetry to alert the SOC.
Instead of being siloed to a single application with file access, this additional permission (arguably not needed by the application in the first place) allowed the attacker to compromise multiple applications, each with their own set of permissions. This ended up granting the attacker access to files and mail content, as well as the ability to create users within the tenant. This level of access is essentially equivalent to granting full administrative control to the attacker—all from a single compromised third-party application.
What does it look like?
Tracked adversary groups are known to take advantage of adding credentials to Microsoft service principals when the opportunity presents itself. Below is Microsoft logging telemetry showing a short time window where an app transitioned from running in expected locations to running from malicious IPs and adding credentials to another application.
What should I do?
Right-size application permissions. An application’s permissions should be scoped to its job function. If the app is intended to be a backup solution, restrict its access to files. If troubleshooting temporarily requires expanded access, reduce those permissions after the activity is completed. Had a backup app not been able to modify other applications, the impact would have been significantly reduced.
Regularly check which applications have high-risk permissions and where they are running from. In fact, go check your Microsoft tenant for applications with Application.ReadWrite.All right now!
Configure app instance property lock where available (Microsoft only). While this won’t prevent every application compromise scenario, it will certainly shrink your exposure to compromisable apps within your organization. This setting allows you to lock down certain service principals so that sensitive properties such as key credentials cannot be modified. Should a permission allowing app modification be exposed to an adversary, these restrictions would prevent some of your applications from having new credentials added to them that can be used by the attacker. Here you can read more details about How to configure app instance property lock for your applications.
Detect. Respond. Remediate. Sometimes simple event monitoring to detect the presence of rare activity is all you need to stay up to speed on these threats and drastically reduce dwell time and impact. Situations where an application is adding credentials to other applications or when new high-risk permissions are added to applications are typically low traffic given the high-risk nature of the activity. An email or Slack bot message stating, “DataBackupApp added key credentials to an application that can send mail on behalf of any user” should be enough to catch the attention of an analyst and hopefully trigger a response and remediate playbook that will cut the attackers access off before large scale damage can be done.
When BEC Actors Compromise Admin Accounts
Much of the spam and broad phishing campaigns that plague the internet generally tie back to your run-of-the-mill business email compromise (BEC) groups. Some of these actors are more organized than others but in the end, they all share the same goal, compromise user mailboxes to perform financial fraud. Sometimes only a single account is compromised and other times multiple accounts within the same organization are compromised and used to perform BEC activity. But what happens when a BEC actor gets their hands on a single admin account? For advanced threat actors, depending on their goals, admin account access opens up their playbook to a lot of opportunities since lateral movement is easier to achieve with admin level access. When you're a BEC actor though, your goal is clear cut and narrow. Instead of performing financial fraud via one compromised mailbox, what if you could utilize any mailbox within the org?
Obsidian observed a threat actor utilizing a compromised admin account to create themselves new admin accounts and grant themselves full mailbox access to several key accounts within the tenant. Evidence shows that the admin account was compromised via malware which was a stepping stone to target SaaS. From there they were able to read mailbox content, create inbox rules, and send mail on behalf of any of the accounts they granted themselves access to. The chance of a successful BEC increases when the attacker is able to compromise a mailbox belonging to someone in the finance department. Imagine the attacker's chance of success at a big pay day when they can control mail flow for several users in finance and for users within the IT department. By manipulating mailbox permissions they are reducing the chance a fraud conversation will be noticed by a victim as well as limiting the IT department’s exposure and awareness of the situation. Due to the level of control the attacker was able to leverage from a single compromised admin account, the dwell time soared to nearly 50 days resulting in damaging circumstances to the business.
What does it look like?
Below is a timeline of events from a Microsoft tenant where the attacker was able to add themselves full access to a target user’s mailbox content and the ability to send mail as that target account.
What should I do?
Avoid permanent full admin roles. Some SaaS services allow Just-in-Time (JIT) access workflows that provide approval workflows, time-limited activations, and detailed auditing. For Microsoft tenants you can take advantage of Privileged Identity Management (PIM), which supports these types of JIT capabilities instead of assigning admin to a user once and having it remain that way indefinitely.
Monitor programmatic access. It’s not very common for users to perform activity in SaaS services via Python, Go, Powershell, etc. Should a user or admin show signs of this activity from untrusted locations and they historically never access the service this way, it could be a clear indication that something is wrong. The compromised admin account was generating logs indicating first-time usage of a programmatic user agent within the first 24 hours of the attack. Had this type of activity been more thoroughly monitored and reviewed, the attack could have been stopped much further left in the timeline.
Final Thoughts:
Modern SaaS attacks are faster, stealthier, and harder to detect. By strengthening verification workflows, revoking sessions during resets, right-sizing app permissions, and monitoring rare activity, organizations can drastically reduce dwell time and exposure. SaaS enables speed, but that speed must be matched by your defense.
