{
	"id": "2862b450-e2f5-4cb4-99a9-42ecf820d31d",
	"created_at": "2026-04-06T00:11:57.106332Z",
	"updated_at": "2026-04-10T13:11:50.906041Z",
	"deleted_at": null,
	"sha1_hash": "f2cd427933918b2da6ffac2df8ce2c3646b6efed",
	"title": "How to maintain persistent access in a SaaS-native company",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1306324,
	"plain_text": "How to maintain persistent access in a SaaS-native company\r\nBy Luke Jennings\r\nArchived: 2026-04-05 14:53:38 UTC\r\nAs an attacker, we have a wide range of persistence options available to us in a traditional account or endpoint\r\ncompromise scenario. From discovering a user's password, to creating new backdoor accounts, to using one of an\r\ninsane number of \"run keys\" to keep an implant running beyond reboot, or even moving laterally to other internal\r\nsystems - an attacker has plenty of choice.\r\nBut how does this change in a SaaS-first world? In this post, we'll consider some of the new challenges and\r\nopportunities that are presented to an attacker who wants to maintain persistence in the new world order, so you\r\ncan better investigate incidents and quickly defend against attacks. We'll cover a variety of techniques, including\r\nmalicious mail rules, OAuth backdoor tricks and document sharing links to see how persistence can be\r\nmaintained, even in the event of password changes and device wipes.\r\nSo what’s changed?\r\nIn a traditional compromise scenario, a common example would be an endpoint compromised through phishing,\r\nwhich is used to deliver a malicious implant to establish a command and control channel with the endpoint. In\r\norder to maintain access, an attacker would likely use one or more endpoint persistence methods to ensure their\r\nimplant is launched again post-reboot when the user turns their laptop off for the day. \r\nThis would often become a foothold into the internal network of the compromised organization. The endpoint or\r\nuser is the start, but an attacker may seek to move laterally to other endpoints and servers on the internal network,\r\nwhere security is often much lower than the external perimeter.\r\nThe old way: an attacker gains persistent access through the user's endpoint\r\nhttps://pushsecurity.com/blog/maintaining-persistent-access-in-a-saas-first-world/\r\nPage 1 of 13\n\nIn a SaaS-first world, this situation has begun to change somewhat. There are many companies now that have\r\nsignificantly reduced the size of their internal networks or are even fully in the cloud and do not have any internal\r\nnetwork infrastructure. In this case, traditional lateral movement becomes much more difficult or impossible.\r\nAdditionally, endpoints are becoming increasingly hard targets to compromise and incident response teams have\r\nmatured and have gotten better at cleaning up endpoint compromises. \r\nThe consequence of this is that attackers need to make the most use of the access they have during an endpoint or\r\nuser compromise and maintain access where possible, even in the event of a password reset and full laptop wipe.\r\nAdditionally, new SaaS-focused persistence options are now possible, which are also often resistant to password\r\nchanges and endpoints wipes, so these are increasingly attractive options for an attacker. \r\nOne other change is that persistence is less binary than it has been traditionally. Typically, persistence would often\r\nbe on a per-user or per-endpoint basis. Either an attacker would have full control of a user account (e.g. knowing\r\nthe password) or full control of an endpoint (e.g. an implant running on the endpoint). The main differentiation\r\nwould be in whether endpoint-level access was administrative level control over the endpoint or an implant\r\nrunning as a low-privileged user account. However, in the SaaS-world persistence is much more asset dependent\r\nand thus less binary. It could be persistent access to email, or documents, or chat conversations or any number of\r\nother assets and capabilities.\r\nMail rules\r\nAn attacker abusing mail rules to gain persistent access\r\nMail rules are a handy feature found in most email clients. You might have used them to forward emails to your\r\nteammates while you’re off sipping Piña Coladas, or to move incoming email from that spammy colleague to the\r\n“don’t read” folder. However, they can also be used for a range of malicious activities, such as forwarding emails\r\nto an external address (e.g. password resets, invoices, “confidential” emails etc) or deleting emails (e.g. security\r\nalerts!). A good example of a real-world attack involving this technique was the 2020 SANS breach.\r\nhttps://pushsecurity.com/blog/maintaining-persistent-access-in-a-saas-first-world/\r\nPage 2 of 13\n\nExample of a malicious mail rule redirect\r\nIf you want to read more about this technique, you can check out our previous article.\r\nOAuth attack #1: Custom OAuth app integration\r\nAttacker uses OAuth integrations to gain persistent access\r\nOAuth apps can be used to request permanent access to a set of permissions on behalf of a user. This can be as\r\nsimple as the ability to verify a user’s identity for a simple social login or it could be as permissive as having full\r\ncontrol over email, document stores, wiki pages, admin capabilities, etc. You can read more details about this in\r\nour previous article. \r\nHowever, from an attacker’s perspective a custom OAuth app could be created with sensitive permissions and\r\nconnected to a user’s account in order to maintain access to their data. In the event that an attacker has\r\ncompromised a user’s account or endpoint, they could directly consent to their own malicious OAuth app on\r\nbehalf of the user in order to gain persistence. This could also be achieved as part of a consent phishing attack to\r\neffectively compromise a user’s account and gain this persistence at the same time. In either case, this would\r\nenable continued access to the user’s data even if their password is changed and their endpoint fully wiped.   \r\nhttps://pushsecurity.com/blog/maintaining-persistent-access-in-a-saas-first-world/\r\nPage 3 of 13\n\nAttacks utilizing these types of techniques are becoming increasingly common and Microsoft even wrote about\r\nsome real-world attacks they uncovered recently that involved the use of malicious OAuth apps.\r\nOAuth attack #2: SaaS platform integration\r\nA similar approach to using a custom OAuth app is to make use of legitimate SaaS services that allow an attacker\r\nto make sensitive integrations as a more hide-in-plain-sight approach. For example, let’s take the popular SaaS\r\nplatform Canva, a graphic design tool that is used to create social media graphics, presentations, posters,\r\ndocuments and other visual content, as an example. Canva, like many SaaS platforms, allows you to make\r\nintegrations with document stores like OneDrive and Google Drive in order to easily import and export files\r\nbetween Canva and them. If an attacker is interested primarily in maintaining access to a user’s files, then they\r\ncould make an integration with a platform like Canva and then use that to maintain access.\r\nWhile this doesn’t provide any raw capabilities beyond a custom OAuth app, an attacker may be more likely to go\r\nundetected in this scenario. Discovering an integration with a completely unknown, unverified OAuth app that\r\nhasn’t been seen in use elsewhere in the organization, or anywhere at all, is suspicious. Finding an integration with\r\na major SaaS platform, particularly if it is one in use by other users in the organization, is much less suspicious.\r\nAdditionally, many of them will have verified ticks having been through Microsoft’s or Google’s own verification\r\nprocesses. The only downside for an attacker is having to find SaaS platforms that request the correct permissions\r\nand provide the functionality that the attacker is looking for, whereas a custom OAuth app could be used to\r\nrequest any permissions and code could be written to use those permissions however an attacker would like.\r\nIf a custom OAuth app is the equivalent of a custom implant on an endpoint, then using a legitimate SaaS platform\r\nintegration is the equivalent of a more living-off-the-land approach, such as using TeamViewer, RDP or\r\nPowershell, etc.\r\nhttps://pushsecurity.com/blog/maintaining-persistent-access-in-a-saas-first-world/\r\nPage 4 of 13\n\nAbusing a legitimate app to create custom permissions for data access\r\nhttps://pushsecurity.com/blog/maintaining-persistent-access-in-a-saas-first-world/\r\nPage 5 of 13\n\nUsing Canva to gain access to OneDrive\r\nOAuth attack #3: Legitimate desktop/mobile app impersonation\r\nOk, we promise this is the last OAuth variation example - but it’s another interesting way to abuse OAuth\r\nconnections! Previously, we spoke of either connecting a custom OAuth app or using an OAuth integration via a\r\nlegitimate SaaS platform. A custom OAuth app has the most flexibility for an attacker, but looks far more\r\nsuspicious if discovered, whereas a legitimate SaaS platform looks much more….well, legitimate!\r\nWhat if you could have both of those advantages in one? Well, that can be achieved, too! The reason SaaS\r\nplatforms don’t have the same flexibility is because they keep their client IDs and secrets for their apps so the\r\nattacker can only use the OAuth app indirectly via the features provided by the SaaS platform. However, some\r\nOAuth connections are made using desktop or mobile apps that obviously can’t keep their OAuth app secrets\r\nsecret from a user. While it is generally not possible for an attacker to make use of these in a consent phishing\r\nattack, due to not controlling the reply URLs, they can be used in a pure persistence scenario with an already\r\ncompromised account. \r\nLet’s take Mozilla Thunderbird, a cross-platform email client, as an example. The client IDs and secrets for\r\ndifferent OAuth apps are actually stored in the source code in this case: \r\nhttps://pushsecurity.com/blog/maintaining-persistent-access-in-a-saas-first-world/\r\nPage 6 of 13\n\nThunderbird stores client IDs and secrets for different OAuth apps in the source code\r\nAs an attacker, this gives us multiple advantages. \r\nApp Impersonation - These are client IDs that will be seen in use legitimately by other users and we can\r\nimpersonate them. In Thunderbird’s case, the Microsoft app isn’t actually a verified app but the Google one\r\nshows as verified. Whatever the case, it looks much less suspicious than a completely unknown app with\r\nno known business use case. \r\nFlexible Use - We have access to the client IDs and secrets, so we can do whatever we want with the\r\nOAuth integration, writing custom code to query APIs as we please. We are not limited to the functionality\r\nprovided by Thunderbird itself.\r\nArbitrary Permission Granting - We aren’t actually limited to just the permissions that Thunderbird\r\nwould normally request (e.g. email/calendar). Since we’re in control of the OAuth secrets, we can just\r\nrequest whatever scopes we want. For example, shown below is us using the Microsoft Thunderbird OAuth\r\nsecrets to request permissions that also include access to all files, Sharepoint, AD access, etc. \r\nhttps://pushsecurity.com/blog/maintaining-persistent-access-in-a-saas-first-world/\r\nPage 7 of 13\n\nAbusing Thunderbird for arbitrary permission granting\r\nhttps://pushsecurity.com/blog/maintaining-persistent-access-in-a-saas-first-world/\r\nPage 8 of 13\n\nWe're able to grant access to whatever we want, not just email\r\n(Semi-)Bypass Google Restricted Scopes - When it comes to arbitrary permission granting, there is a\r\ncaveat with Google in that some of the more sensitive scopes Google offer are only available to selected\r\napproved and verified apps. Therefore, we can’t necessarily just request access to any permission with\r\nGoogle. For example, if we modify Thunderbird to request access to Google Drive (a restricted scope) then\r\nwe get the following: \r\nAccess to Gmail is also considered a restricted scope. However, obviously Thunderbird is an email client, so if it\r\nuses OAuth it’s going to want access to Gmail, right? Well, yes, the Thunderbird app ID is permitted access to\r\nGmail data, so we can use it to gain that access and appear as a legitimate verified app, in addition to requesting\r\nany other non-restricted permissions we’re interested in: \r\nhttps://pushsecurity.com/blog/maintaining-persistent-access-in-a-saas-first-world/\r\nPage 9 of 13\n\nUsing the Thunderbird app to gain access to Gmail\r\nDocument-sharing links\r\nhttps://pushsecurity.com/blog/maintaining-persistent-access-in-a-saas-first-world/\r\nPage 10 of 13\n\nAn attacker abusing document-sharing links to get persistent access\r\nOk, no more OAuth, we promise! The final option we want to highlight is the (ab-)use of document-sharing links.\r\nMany organizations make use of OneDrive, Sharepoint and Google Drive for document editing, sharing and\r\ncollaboration. However, it’s pretty common to want to share documents with people outside your organization\r\nsometimes too, right? That’s where document-sharing links come in. You can create a document sharing link to\r\nshare with specific individuals in other Google/Azure organizations or you can create anonymous links that\r\nanyone with knowledge of the (unguessable randomized) link can access.\r\nVery similar functionality is present in both OneDrive and Google Drive, but this same legitimate functionality\r\ncan also be abused by attackers to maintain backdoor access to either select files or entire root folders. Sharing a\r\nroot folder will cause future files to inherit those sharing permissions. This is a modern repeat of the age-old\r\nproblem of access control list (ACL) management on internal file servers, only now internet-based attackers can\r\npotentially abuse this without needing VPN or similar access. \r\nhttps://pushsecurity.com/blog/maintaining-persistent-access-in-a-saas-first-world/\r\nPage 11 of 13\n\nAbusing OneDrive document-sharing functionality\r\nOneDrive files now shows shared status\r\nConclusion\r\nhttps://pushsecurity.com/blog/maintaining-persistent-access-in-a-saas-first-world/\r\nPage 12 of 13\n\nWe've demonstrated a few new persistence options attackers are using against organizations as they move to the\r\ncloud. While some existing persistence and lateral movement options are no longer working in these\r\nenvironments, attackers have been able to quickly adapt to new conditions to get at their targets.\r\nSome of these attacks have already been seen in the wild and others may already be happening under the radar. In\r\nany case, being aware of how attackers will try to compromise SaaS-first organizations helps you prepare to\r\ndefend and respond to these attacks. \r\nIt’s extremely important for incident response teams to adapt to these changes, as a password reset and a device\r\nwipe is not sufficient to regain control of a user account, even when no lateral movement to internal systems has\r\nbeen performed.\r\nNew steps need to be added to IR playbooks in the event of user or device compromises to cover the revocation of\r\nOAuth permissions and refresh tokens, the auditing of mail rules and changes to document sharing configurations.\r\nSource: https://pushsecurity.com/blog/maintaining-persistent-access-in-a-saas-first-world/\r\nhttps://pushsecurity.com/blog/maintaining-persistent-access-in-a-saas-first-world/\r\nPage 13 of 13",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://pushsecurity.com/blog/maintaining-persistent-access-in-a-saas-first-world/"
	],
	"report_names": [
		"maintaining-persistent-access-in-a-saas-first-world"
	],
	"threat_actors": [],
	"ts_created_at": 1775434317,
	"ts_updated_at": 1775826710,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/f2cd427933918b2da6ffac2df8ce2c3646b6efed.pdf",
		"text": "https://archive.orkl.eu/f2cd427933918b2da6ffac2df8ce2c3646b6efed.txt",
		"img": "https://archive.orkl.eu/f2cd427933918b2da6ffac2df8ce2c3646b6efed.jpg"
	}
}