{
	"id": "e915ebae-4c79-4a68-b7fc-3484f898416a",
	"created_at": "2026-04-06T00:17:40.583631Z",
	"updated_at": "2026-04-10T03:20:24.927833Z",
	"deleted_at": null,
	"sha1_hash": "ca6817527c85ac05b7749ba30483fb5cd195a399",
	"title": "DeleFriend: Severe design flaw in Domain Wide Delegation could leave Google Workspace vulnerable for takeover",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2466579,
	"plain_text": "DeleFriend: Severe design flaw in Domain Wide Delegation could\r\nleave Google Workspace vulnerable for takeover\r\nBy Team Axon\r\nPublished: 2023-11-28 · Archived: 2026-04-05 16:41:24 UTC\r\nBy Yonatan Khen, Threat Hunting Expert at Team Axon\r\nTL;DR: \r\nHunters’ Team Axon uncovered a design flaw in Google Workspace's Domain-Wide delegation feature,\r\nwhich results in misuse of existing delegations, potentially enabling privilege escalation and unauthorized\r\naccess to Workspace APIs without Super Admin privileges. Team Axon has dubbed this design flaw as\r\nDeleFriend.\r\nThis design flaw and research paper were responsibly disclosed to Google in advance as part of the “Bug\r\nHunters” program in August 2023. As of this publication, the flaw remains active.\r\nTeam Axon created a proof-of-concept tool included in this blog post to assist organizations in detecting\r\nmisconfigurations and reducing DeleFriend’s exploitation risks.\r\nThis research paper delves into the Domain Wide Delegation feature, detailing its mechanism and potential\r\nfor malicious use.\r\nThe \"Let’s go hunting\" section presents thorough threat hunting, detection techniques, and best practices\r\nfor countering Domain-Wide delegation attacks.\r\nRead the press release here\r\nTable of Contents:\r\nExecutive Summary\r\nGCP \u003c\u003e GWS Authentication Fundamentals\r\nUnderstanding Domain-Wide Delegation\r\nAbusing Domain-Wide Delegation\r\nScenario 1: New delegation with interactive GWS access\r\nScenario 2: DeleFriend - Compromise existing delegation\r\nDeleFriend Mitigation Recommendations\r\nTeam Axon Threat Hunting Recommendations\r\nSummary of Best Practices\r\nConclusion\r\nReferences\r\nExecutive Summary\r\nhttps://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover\r\nPage 1 of 26\n\nOver the past few years, there has been a notable shift towards cloud technology, with the development of cloud\r\nand SaaS tools designed to boost efficiency by integrating features that simplify work processes. One of these\r\nfeatures is Google's Domain-Wide delegation. This feature permits a comprehensive delegation between Google\r\nCloud Platform (GCP) identity objects and Google Workspace (GWS) applications. In other words, it enables\r\nGCP identities to execute tasks on Google SaaS applications, such as Gmail, Google Calendar, Google Drive, and\r\nmore, on behalf of other Workspace users.\r\nDuring 2023, Team Axon conducted extensive research on the Domain-Wide delegation feature and its potential\r\nimplications for organizations. The research primarily focused on gaining a thorough understanding of the relevant\r\nattack surface, the service internals, and, most importantly, how it can be detected effectively.\r\nThis paper aims to illustrate how threat actors with varying privileges in a target GCP environment can potentially\r\nabuse Domain-Wide delegation. In addition, we’ll also introduce a new proof-of-concept tool that allows for a full\r\ntakeover of the Google Workspace domain using relevant GCP role permissions. With this tool, red teams,\r\npentesters and security researchers can evaluate their security risks and improve the posture of their Workspace\r\nand GCP environments. \r\nThe final sections of the blog post offer actionable insights on digital forensics, threat-hunting methodologies, and\r\ndetection engineering best practices based on telemetry logs from Google Cloud Platform and Google Workspace.\r\nGCP \u003c\u003e GWS Authentication Fundamentals\r\nBefore delving into the feature internals, let’s first discuss the relationship between GWS and GCP. \r\nDomain-Wide delegation is based on the systemic connection between Google Cloud and Workspace, but aside\r\nfrom both being developed by Google, what is the connection between the two?\r\nThe Google ecosystem offers a robust suite of tools and services to meet the diverse needs of organizations. Two\r\nof these services - Google Cloud and Google Workspace (or Cloud Identity) - have distinctive roles but are\r\nintricately linked, particularly when we examine authentication.\r\nThe concept of integrating identity is key to setting up user authentication and access control for GCP services.\r\nWhile GCP IAM is capable of managing control and visibility for resources internally (for example, projects or\r\nindividual compute resources), it does not dictate who can access the GCP itself. \r\nWhen a business chooses to use Google Cloud, it needs a central 'hub' for managing all users, groups, settings, and\r\ndata. This 'hub' (or ‘directory’) can either be Google Workspace or a Google Cloud Identity account. Google\r\ncategorizes those with the term ‘IDaaS’ or identity-as-a-service.\r\nThough Google Workspace is commonly known for its productivity tools like Gmail, it also has a crucial role in\r\nmanaging user identities across Google Cloud services. Google Cloud Identity plays as the cheaper option for\r\norganizations who like to use GCP, but do not necessarily need the productive applications offered by Workspace\r\n(for example organizations that are using O365).\r\nInterestingly, even for organizations who are using third party identity providers (IdP), such as Okta or Azure AD,\r\nto manage their users and identities, Google still requires authentication through their IDaaS mechanisms. This\r\nhttps://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover\r\nPage 2 of 26\n\nmeans organizations that want to use GCP services will still need to sync their third party IdP with either GWS or\r\nCloud Identity directories.\r\nGoogle's IDaaS concept \r\nIt's crucial to understand the interconnected nature of Google Cloud and Workspace, as this understanding\r\nunderscores how the misuse of one could potentially impact the other.\r\nUnderstanding Domain-Wide Delegation\r\nGoogle Workspace's Domain-Wide delegation allows an identity object, either an external app from Google\r\nWorkspace Marketplace or an internal GCP Service Account, to access data across the Workspace on behalf of\r\nusers. This feature, which is crucial for apps interacting with Google APIs or services needing user impersonation,\r\nenhances efficiency and minimizes human error by automating tasks. Using OAuth 2.0, app developers and\r\nadministrators can give these service accounts access to user data without individual user consent.\r\nGoogle Workspace allows the creation of two main types of global delegated object identities:\r\nGWS Applications: Applications from the Workspace Marketplace can be set up as a delegated identity.\r\nBefore being made available in the marketplace, each Workspace application undergoes a review by\r\nGoogle to minimize potential misuse. While this does not entirely eliminate the risk of abuse, it\r\nsignificantly increases the difficulty for such incidents to occur.\r\nGCP Service Account: Differently from the third party applications, Google also allows the creation of\r\ninternal delegated identities in GCP, with identity-based service accounts. Those service accounts can\r\nleverage OAuth 2.0 to create temporary tokens and authorize against Google APIs, including access to\r\nWorkspace REST APIs. \r\nIn this blog post, we will primarily focus on the misuse of delegation via GCP Service Accounts. As mentioned\r\nearlier, Marketplace applications represent a smaller attack surface due to the rigorous security audits that\r\nGoogle carries out before approving any new application.\r\nDomain-Wide Delegation: Under the Hood\r\nhttps://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover\r\nPage 3 of 26\n\nThe next step is to understand how it works under the hood when leveraging a GCP service account private key\r\npair to initiate a request to Google APIs on behalf of other identities in Google Workspace.\r\nIn terms of implementing a delegated authorization, Google aligns with other well-known Cloud providers by\r\nutilizing OAuth 2.0 RFC 6749. The fundamental concept here involves allowing an identity to grant permission to\r\ndifferent Workspace REST API applications, without the need to expose his credentials. \r\nLet’s see how it works. The following diagram illustrates the steps created by the delegated identity to access\r\nGoogle API. \r\nOAuth 2.0 High-Level diagram \r\n1. Identity creates a JWT:  The Identity uses the service account's private key (part of the JSON key pair file) to\r\nsign a JWT. This JWT contains claims about the service account, the target user to impersonate, and the OAuth\r\nscopes of access to the REST API which is being requested.\r\nhttps://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover\r\nPage 4 of 26\n\nGoogle Credential object that represents a JWT\r\n2. The Identity uses the JWT to request an access token: The application/user uses the JWT to request an\r\naccess token from Google's OAuth 2.0 service. The request also includes the target user to impersonate (the user's\r\nWorkspace email), and the scopes for which access is requested.\r\n3. Google's OAuth 2.0 service returns an access token: The access token represents the service account's\r\nauthority to act on behalf of the user for the specified scopes. This token is typically short-lived and must be\r\nrefreshed periodically (per the application's need).  It's essential to understand that the OAuth scopes specified in\r\nthe JWT token have validity and impact on the resultant access token. For instance, access tokens possessing\r\nmultiple scopes will hold validity for numerous REST API applications.\r\nExample of an access token\r\n4. The Identity uses the access token to call Google APIs: Now with a relevant access token, the service can access\r\nthe required REST API. The application uses this access token in the \"Authorization\" header of its HTTP requests\r\nhttps://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover\r\nPage 5 of 26\n\ndestined for Google APIs. These APIs utilize the token to verify the impersonated identity and confirm it has the\r\nnecessary authorization. \r\nAPI call to Google APIs using the returned access token \r\n5. Google APIs return the requested data: If the access token is valid and the service account has appropriate\r\nauthorization, the Google APIs return the requested data. For example, in the following picture, we’ve leveraged\r\nthe users.messages.list method to list all the Gmail message IDs associated with a target Workspace user. \r\nAPI results of users.messages.list \r\nAbusing Domain-Wide Delegation\r\nUp until now, we’ve discussed the feature internals, but have not touched on how it could potentially be abused.\r\nLet’s review two scenarios that include different permissions of the target identity within GCP and Google\r\nWorkspace. \r\nThe first scenario is a typical abuse of Domain-Wide delegation as an impactful post-exploitation method of\r\ncreating a new delegation after gaining access to a Super Admin privilege on the target Workspace environment.\r\n This technique has been observed in the wild by Team Axon and has been known to be exploited by threat actors\r\nin recent years. \r\nhttps://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover\r\nPage 6 of 26\n\nThe second scenario is a new method to abuse existing delegations rather than creating a new one. Instead of\r\nrequiring Super Admin privilege on the Workspace environment, the method requires less privileged access on the\r\nrelevant GCP projects in order to enumerate successful combinations of service account keys and OAuth scopes.\r\nThe concept will be detailed in the “DeleFriend״ section.\r\nScenario 1: New delegation with interactive GWS access\r\nIn the first scenario, an actor typically gains initial access to an IAM identity, with the ability to create service\r\naccounts in a GCP project. In addition, after extensive work in the target domain, he now holds a super admin\r\nprivilege to GWS, and is looking for smart options to achieve strong persistence and exfiltration capabilities. \r\nAttack steps:\r\n1. Generating a New Service Account and Corresponding Key Pair The initial step starts with generating\r\na new service account. On GCP, new service account resources can be produced either interactively via the\r\nconsole or programmatically using direct API calls and CLI tools. This requires the role\r\niam.serviceAccountAdmin or any custom role equipped with the iam.serviceAccounts.create permission.\r\nOnce the service account is created, we'll proceed to generate a related key pair. This key pair will consist\r\nof parameters that hold relevant information about the service account, including a private key. Basically,\r\nthis key pair enables authentication of the service account. After this process, we can perform tasks using\r\nthe identity of the service account, leveraging all the permissions that it's been accorded. The ability to\r\ngenerate a new key pair is facilitated by the iam.serviceAccountKeys.create permission.\r\nGoogle’s Service Account (SA) private key, is a JSON file composed of the following:\r\nGCP Organization Metadata:\r\ntype: will always point to service_account object type.\r\nproject_id: the global GCP organization resource name. From our research, this attribute provides\r\nan additional level of classification and security to provide protection against impersonation attacks\r\nwith the global service account ID.\r\nprivate_key_id: unique hash identifier of the private key. This value is available in the GCP Console\r\nalso after the private key creation. \r\nprivate_key: private key value. This value won’t be available in the GCP console after the private\r\nkey creation. \r\nclient_email: the GCP SA IAM email representation, a format of: \r\nThe default filename given by Google upon downloading the keys composed from a fixed naming format:\r\n\u003cgcp_project_id\u003e-\u003cprivate_key_id{12}\u003e.json. This format makes these files particularly attractive to red team\r\nmembers and potential attackers once they've gained access to a workstation or storage. We'll delve into methods\r\nfor finding these files in the Threat Hunting Posture section.\r\nhttps://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover\r\nPage 7 of 26\n\nService Account Private Key Pair JSON\r\n2. Creation of new delegation: After having a relevant identity object and a related private key that enables\r\nauthentication with Google APIs, we need to establish a new delegation rule for the service account resource\r\nwithin Google Workspace. This delegation rule will enable us to perform the Google APIs activity on Workspace\r\nREST API applications. It's important to understand that only the Super Admin role possesses the capability to set\r\nup global Domain-Wide delegation in Google Workspace. \r\nFurthermore, Domain-Wide delegation cannot be set up programmatically. It can only be created and adjusted\r\nmanually through the Google Workspace console. Throughout our research, we tried both documented and\r\nundocumented methods of doing this, without any success. Interestingly, even admins who manage subdomains\r\nwithin Google Workspace cannot delegate permissions to applications and service accounts.\r\nThe creation of the rule can be found under the page API controls → Manage Domain-Wide delegation in Google\r\nWorkspace Admin console. \r\nAPI controls page in Google Workspace Admin Console\r\n3. Attaching OAuth scopes privilege: When configuring a new delegation, Google requires only 2 parameters, the\r\nClient ID, which is the OAuth ID of the GCP Service Account resource, and OAuth scopes that define what API\r\ncalls the delegation requires. \r\nhttps://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover\r\nPage 8 of 26\n\nSetting domain-wide delegation configuration\r\nOAuth scopes is a concept in Google APIs that limits an application's access to a user's account. Each scope\r\nrepresents a specific permission granted by the user to the application.\r\nOAuth scopes permissions in Google APIs example. The full list can be found here.\r\nFor example, if an application requests access to a user's Google Calendar data, the scope would be\r\nhttps://www.googleapis.com/auth/calendar. If the application also requested access to Google Drive, another\r\nscope https://www.googleapis.com/auth/drive would be needed.\r\nhttps://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover\r\nPage 9 of 26\n\nEach scope corresponds to a specific set of permissions, such as read, write, or delete. For instance, granting a\r\nread scope allows the application to view data but not modify it. Conversely, granting a write scope allows the\r\napplication to modify data.\r\nIt's important to note that, for security purposes, scopes should be as limited as possible. The best practice of least\r\nprivilege always should be applied, where an application only asks for the permissions it absolutely needs to\r\nfunction. We’ll revisit that in the threat hunting section when speaking about posture best practices.\r\nIt is important to note that the delegation is attached to the service account identity itself in the form of the OAuth\r\nClient ID, and NOT for a specific key. This is important as we’ll discuss how it can be abused in the next\r\nexploitation method. \r\n4. Acting on behalf of the target identity: At this point, we have a functioning delegated object in GWS. Now,\r\nusing the GCP Service Account private key, we can perform API calls (in the scope defined in the OAuth scope\r\nparameter) to trigger it and act on behalf of any identity that exists in Google Workspace. As we learned, the\r\nservice account will generate access tokens per its needs and according to the permission he has to REST API\r\napplications.\r\nIn the given example, we utilize the users.messages.list API to iterate through and list the message IDs of emails\r\nin the target inbox. We then use users.messages.get to fetch the entire email content associated with the GWS\r\nIdentity of a user named Eli Ohana.\r\nObviously, the example demonstrates requests to the Gmail REST API, but in theory, it can be used on any other\r\nWorkspace applications based on the OAuth scopes attached to the object.\r\nBonus: Cross-Organizational delegation\r\nWhile this scenario pointed to an adversary with relevant permissions to create a new service account in GCP, our\r\nresearch observed that OAuth SA ID is global and can be used for cross-organizational delegation.  There has\r\nbeen no restriction implemented to prevent cross-global delegation. In simple terms, service accounts from\r\ndifferent GCP organizations can be used to configure domain-wide delegation on other Workspace organizations.\r\nThis would result in only needing Super Admin access to Workspace, and not access to the same GCP account, as\r\nthe adversary can create Service Accounts and private keys on his personally controlled GCP account. \r\nWe're uncertain if this functionality was an intentional design by Google, but it certainly elevates the risk of\r\ncreating more “invisible” domain-wide delegations if an adversary creates the service accounts outside of the\r\ntarget organization’s visibility.\r\nhttps://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover\r\nPage 10 of 26\n\nScenario 2: DeleFriend - Compromise existing delegation\r\nIn the first scenario, we discussed a situation where the actor already gained privileged access to the Super Admin\r\naccount in GWS. While this isn’t uncommon in breaches, we researched further possibilities for abusing GWS\r\ndelegation objects using lower privileges. We tried to look for ways to pivot from limited GCP permissions to\r\nWorkspace, without necessarily holding a Super Admin privilege. \r\nWe discovered a way to do exactly this. \r\nThere is one questionable decision Google made when designing the feature. When the delegation configuration is\r\ncreated, it is defined by the service account resource identification (the OAuth ID) and not by the specific\r\nprivate key/s attached to the identity. This means that in case we have access to a relevant GCP service account\r\nresource with existing Domain-Wide delegation within the IAM Policy, nothing stops us from creating a new\r\nkey, enumerating all the existing JWT possibilities and using that existing delegation to perform API calls to\r\nGoogle Workspace on behalf of other identities in the domain.\r\nNow, understanding the theory behind this is one thing, but we want to give you a little bit more. That’s why we\r\nhave written a proof-of-concept tool that can help the security community increase awareness around Domain-Wide delegation attacks, and improve the security posture of their environments.  \r\nIntroducing DeleFriend POC - a new tool to automate, find, and abuse existing delegation between GCP and\r\nGWS. \r\nLet’s see how the POC tool works:\r\nhttps://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover\r\nPage 11 of 26\n\n1. Enumerate GCP Projects using Resource Manager API.\r\n2. Iterate on each project resource, and enumerate GCP Service account resources to which the initial IAM\r\nuser has access using GetIAMPolicy.\r\n1. GCP IAM Policies are attached directly to resources (including service accounts). As a result, GCP\r\ndoesn’t maintain a centralized location for IAM permissions, we’re leveraging the GetIAMPolicy\r\nmethod in order to check whether the target IAM user (which is the provided access token)  has a\r\nrole on the enumerated service account.\r\n3. Iterate on each service account role, and find built-in, basic, and custom roles with\r\nserviceAccountKeys.create permission on the target service account resource. It should be noted that the\r\nEditor role inherently possesses this permission. There is a substantial range of potential attack vectors that\r\ninvolve the Editor role. Additionally, it's also worth mentioning the default service accounts, which are\r\ngranted Editor permissions across the entire project by default.\r\nIn order to validate that each of the roles has the appropriate permission for creating private keys, we’re\r\nleveraging the method iam.roles.get, and that’s to receive all the permissions under the role in order to\r\nreceive a clear indication of whether the role is relevant for the attack.\r\n \r\nSince custom roles’ unique identifier is built differently in GCP,  the function check_permission\r\ndistinguishes between them with identify roles starting with ‘projects/’ prefix.\r\nSnippet from DeleFriend: enumeration of custom roles\r\n4. Create a new KEY_ALG_RSA_2048 private key to each service account resource which is found with\r\nrelevant permission in the IAM policy.\r\nIn this step, we would create a Google key pair TYPE_GOOGLE_CREDENTIALS_FILE using the\r\nserviceAccounts.keys.create method for each Service Account we’ve found to have appropriate permission\r\nduring the initial enumeration. Interestingly, we’ve found that the relevant JSON with the private key is\r\nreturned within the privateKeyData attribute key in a base64 format. It can be confusing as the result of the\r\nmethod is JSON as well.\r\nhttps://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover\r\nPage 12 of 26\n\nSnippet from DeleFriend key creation function that extracts the private key value from privateKeyData\r\nattribute key\r\n5. Iterate on each new service account and create a JWT object for it which is composed of the SA private key\r\ncredentials and an OAuth scope. The process of creating a new JWT object will iterate on all the existing\r\ncombinations of OAuth scopes from oauth_scopes.txt list, in order to find all the delegation possibilities.\r\nThe list oauth_scopes.txt is updated with all of the OAuth scopes we’ve found to be relevant for abusing\r\nWorkspace identities. However, if you come across any additional ones, please don't hesitate to contribute\r\nby adding them and submitting a pull request to the repository.   \r\nAs we discussed previously, a JWT object with the service account private key credentials is required in\r\norder to generate temporary access tokens to access Google APIs. The JWT creation process is carried out\r\nbehind the scenes within the google-auth package. After loading the service account private key to a\r\nCredentials instance, the method name _make_authorization_grant_assertion is responsible to create and\r\nsign the JWT.\r\nhttps://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover\r\nPage 13 of 26\n\nJWT method creation\r\nfrom google-auth SDK package\r\n6. The _make_authorization_grant_assertion method reveals the necessity to declare a target workspace user,\r\nreferred to as subject, for generating JWTs under DWD. While this may seem to require a specific user, it's\r\nimportant to realize that DWD influences every identity within a domain. Consequently, creating a JWT for\r\nany domain user affects all identities in that domain, consistent with our combination enumeration check.\r\nSimply put, one valid Workspace user is adequate to move forward. This user can be defined in\r\nDeleFriend’s config.yaml file. If a target workspace user is not already known, the tool facilitates the\r\nautomatic identification of valid workspace users by scanning domain users with roles on GCP projects. It's\r\nkey to note (again) that JWTs are domain-specific and not generated for every user; hence, the automatic\r\nprocess targets a single unique identity per domain.\r\n7. Enumerate and create a new bearer access token for each JWT and validate the token against tokeninfo\r\nAPI.\r\nThe JWT is exchanged with a temporary access token that allows access to Google APIs. In order to check\r\nif the combination of the OAuth scope and the service account has Domain-Wide delegation, we’re\r\nvalidating the token against tokeninfo API, while each response code to a combination is a jackpot for\r\nan existing delegation for the specific OAuth scope. This is the most reliable and simple method we’ve\r\nfound during our research to validate the JWT combinations.\r\nhttps://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover\r\nPage 14 of 26\n\nValidating access token combinations using tokeninfo\r\nAn example of a successful JWT combination with delegation enabled by DeleFriend\r\nAfter discovering DeleFriend and completing our tool's research and development, we came across Chris\r\nMoberly’s research, “GCP Privilege Escalation,\" which briefly mentioned the exploitation of DWD through a\r\nGCP UI console access, allowing the creation of a Super Admin account. This insightful blog could have greatly\r\nexpedited our research process, as it depicts the same concept that we have identified. However, we're pleased that\r\nour in-depth exploration of the DWD feature allowed us to develop a programmatic and systematic method to\r\nidentify Service Accounts with delegation.  After looking into Moberly’s research, we could not find any\r\nparameter in the UI that hints at whether a service account enables DWD (it is possible this feature has been\r\ndeprecated). But, Chris’s blog is a highly recommended read for valuable insights for GCP red teaming and we\r\nwould like to take the opportunity to credit him for being the first that publish materials around DWD\r\nexploitation. \r\nDeleFriend Mitigation Recommendations\r\nCloud vulnerabilities, or “attacking abuse techniques,” have a completely different concept from old school on-premise vulnerabilities we’ve been used to. Most of them are based on a design flaw of a feature, rather than a\r\nhttps://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover\r\nPage 15 of 26\n\nlogical code error in the application itself. The same is with DeleFriend. \r\nSince the root cause is part of the design of the feature, we put together a couple of suggestions for improving the\r\nfeature, which were also introduced to Google as part of our vulnerability bug report. We think this section is\r\nparticularly interesting, as it shows the difficulty of fixing the “new era” of over-permissive features and the\r\ntradeoff that sometimes comes with it. Please note that these recommendations are related to the design of the\r\nfeature, and not practical recommendations for users and organizations. (see the “Postures \u0026 Hygiene” section for\r\nthat) \r\nConfiguration is based on the entire Service Account, instead of a particular private key\r\nOur recommendation would be to consider updating the delegation requirements to be based on a specific\r\npredefined private key(s), and not for the whole service account id. We understand this design was probably meant\r\nto provide flexibility with dynamic key creation to the service accounts, however, it opens a door for lateral\r\nmovement attack methods from GCP to Workspace, and abuse of existing delegations without the need for Super\r\nAdmin on the domain. Granting GCP IAMs with the singular permission of serviceAccountKeys.create, which is\r\nalso included in common roles like Editor and Owner, can enable the takeover of existing delegations and,\r\nconsequently, control over the entire Workspace. This effectively equates these roles to having Super Admin\r\npermissions within Workspace, the highest level of permission available. This is a flaw in the permission structure\r\nthat needs to be rectified.\r\nWhile disabling the whole design of delegation per OAuth ID might impact the feature capabilities, we suggest\r\nimplementing at least an optional requirement to configure Domain-Wide delegation by a specific private key. We\r\nexpect the optional requirement feature will be highly used by organizations as our research found that\r\norganizations mostly don’t generate keys dynamically for delegations but use the same private key for the whole\r\nlifetime of the service/application.\r\nBlock JWT enumeration on API level \r\nWhile generating a new JWT for each OAuth scope is designed to control different REST API accesses, we\r\nrecommend implementing a limit on the number of JWT requests within a short time frame. This would curtail or\r\nat least make it more challenging to identify authorized Domain-Wide delegation combinations by a newly\r\ngenerated or stolen private key pair. \r\nOver-permissive permission to the Editor role \r\nWe suggest considering the removal of the iam.serviceAccountKeys.create permission from the Editor basic role\r\nin GCP. While the Editor role is meant for high privileges within the project, this permission can potentially lead\r\nto Domain-Wide delegation abuse. Even though setting up Domain-Wide delegation needs Super Admin rights, it\r\nequates the Editor role to the same level.\r\nDomain-Wide Delegation Abuse: The “Ultimate Backdoor” \r\nDomain-wide delegation abuse is a powerful attack vector, so let’s list the advantages that this backdoor brings to\r\nattackers. \r\nhttps://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover\r\nPage 16 of 26\n\nImpact: When an actor is unintentionally granted access to a delegated identity object with high OAuth\r\nscope privileges, they can perform various actions on the most frequently used SaaS applications in the\r\ntarget domain. Notably, such access directs access to all identities under the GWS domain, compared to an\r\napplication contest on a specific user identity, potentially leading to email theft from Gmail, data\r\nexfiltration from the drive, or any other API action based on the OAuth scopes of the DWD.\r\nLong life: By default, GCP Service account keys are created without an expiry date. This feature makes\r\nthem ideal for establishing backdoors and ensuring long-term persistence.\r\nEasy to hide: The creation of new service account keys for existing IAMs or, alternatively, the setting of a\r\ndelegation rule within the API authorization page is easy to conceal. This is because these pages typically\r\nhost a wide array of legitimate entries, which are not examined thoroughly enough.\r\nAwareness: IT and Security departments may not always be cognizant of the Domain-Wide delegation\r\nfeature. They might especially be unaware of its potential for malicious abuse.\r\nHard to detect: Since delegated API calls are created on behalf of the target identity, the API calls will be\r\nlogged with the victim details in the corresponding GWS audit logs. This makes it challenging to identify\r\nsuch activities. We’ll revisit that in the hunting section and see how we can scope that.\r\nTeam Axon Threat Hunting Recommendations\r\nForensics \u0026 Data Point Connections\r\nBefore delving into threat-hunting examples, it's important to first review the GCP and GWS data sets to\r\ndetermine what elements are key for our examination. Understanding the structure of the logs, as well as how\r\nGCP and GWS are interconnected, is vital for effectively carrying out threat hunting and posture assessment.\r\nIdentify Delegated OAuth Requests to Google APIs \r\nWhen an application or a delegated service account performs an API call on behalf of another user, an application\r\nevent of the type token, will be audited. This event represents OAuth token activity made by identity objects in the\r\nWorkspace domain. When the application needs to authorize in order to receive a temporary access token, an\r\nEVENT_NAME value of authorize will be logged, while actual API calls will be logged with the value activity.\r\nFor each of the token events, the target user on which the activity was performed on their behalf, will be logged\r\nunder the attribute ACTOR_EMAIL. This can be highly confusing for security investigators, as without knowing\r\nwhat token events are, they might think the activity was done by the user value in ACTOR_EMAIL although the\r\nactivity was made by delegated OAuth context.\r\nSo, how to identify what is the identity object which initiated the API call? A hidden attribute inside the\r\nEVENT_PARAMTERS JSON name app_name will include the delegated object which performed the action on\r\nbehalf of the target identity. Alternatively, the attribute client_id can be used either in cases where the application\r\nis configured with an OAuth name.\r\nhttps://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover\r\nPage 17 of 26\n\napp_name key under EVENT_PARAMTERS\r\nDomain-Wide delegation Created\r\nThe value admin in ID_APPLICATION_NAME, as the name suggests, represents events made in the context of\r\nGWS administration. It can be either for the activity made from the Admin Console interactively or via the admin\r\nAPI. \r\nWhen a new global delegation is created or modified, an event name AUTHORIZE_API_CLIENT_ACCESS will\r\nbe logged under the admin log source. This event represents global OAuth access to an identity object. Global\r\nmeans this event won’t be created for OAuth consent of a specific user (for example, a user that installed a\r\nspecific application and consented to his account), but for domain delegation which affects the entire domain and\r\nthe identities within it. \r\nAs we’ve discussed, Google allows two main options for identity objects: GWS Marketplace applications and\r\nGCP Service accounts. \r\nSo how do we identify them in the logs?\r\nUnder the EVENT:PARAMTERS JSON, there is a key name API_CLIENT_NAME. This value represents the\r\ndelegated object name that is assigned to the domain.\r\nFrom here, we’ve identified two patterns that are matching two identity objects we’ve presented above.\r\n1. GWS Marketplace applications will be declared with a naming convention ending with\r\napps.googleusercontent.com. This domain convention is associated with GWS marketplace applications and\r\nserving as a unique identifier for applications.\r\nGWS Marketplace Application audited\r\nIn case you would like to understand what the exact application is, the first 12 integers in the UID, can be\r\ncorrelated with the last directory within the relevant Marketplace application URI,  for instance,\r\n7081045131.apps.googleusercontent.com.\r\nhttps://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover\r\nPage 18 of 26\n\nApplication identifier from the Marketplace URI\r\n2. GCP Service Accounts are declared with the OAuth Service Account ID, which is made up of 21 integer values.\r\nIt is important to note that the Service Account ID is the only identifier that exists in this particular event, as the\r\nIAM email address isn’t available.\r\nGCP Service Account OAuth ID audited\r\nInterestingly, during our research, we found that Google doesn’t provide the initiating caller IP of Domain-Wide\r\ndelegation events for GCP service account objects. The IP value is usually audited under the attribute\r\nIP_ADDRESS, which exists in almost all of the events in the Workspace schema. As we couldn’t think of any\r\nreasonable reason for that, we addressed it to Google. This forensic insight is highly important, as the IP address is\r\none of the most valuable attributes for investigation purposes, especially in this kind of event, as we want to\r\nunderstand the characteristics of the identity that was created by the global delegation. \r\nGlobal delegation events with GCP SA identity objects, audited without initiating IP caller value\r\nConnecting the dots: GSW \u0026 GCP\r\nAs we’ve examined in the GWS logs, the events that represent activity made by GCP Service Accounts included\r\nonly a 21-integer number. During threat hunting or incident investigations, it is highly important to understand\r\nhttps://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover\r\nPage 19 of 26\n\nforensic data point connections between the data sources, as at first impression, this integer represents nothing to\r\nus. \r\nFirst, it is important to understand what this 21-integer number means. This number represents the OAuth ID of\r\nthe target Service Account. A mandatory and globally unique value that Google attached to every Service Account\r\nthat is created in the GCP domain. \r\nService Account OAuthID\r\nIn order to pivot and find the SA IAM identity behind the OAuth ID, we can do a couple of steps by examining\r\nthe GCP audit logs, and by that getting a full picture of the potential event or incident. The main purpose is to find\r\nimportant information that isn’t included in the Workspace log, in order to enrich the investigation and provide\r\nmore context. \r\nThe most recommended method to understand more about the SA is to pivot to the relevant GCP audit logs,\r\nspecifically for private key creation to the relevant service account. Those logs can be identified under the GCP\r\nEvent Name CreateServiceAccountKey. \r\nThe following diagram represents the connection between the two attributes in the different data sources. \r\nhttps://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover\r\nPage 20 of 26\n\nData point connections between the target OAuth ID in GCP \u003c\u003e GSW\r\nHunting Thesis \u0026 Investigation Flow\r\nHUNTING FOR SUSPICIOUS DELEGATIONS TO INTERNAL GCP SERVICE ACCOUNTS\r\nOverview \r\nThe thesis looks for the creation or update of domain delegation event AUTHORIZE_API_CLIENT_ACCESS in\r\nGoogle Workspace admin logs and focusing on GCP service account identities by identifying the target\r\napplication as an integer.\r\nGiven that the AUTHORIZE_API_CLIENT_ACCESS event in Google Workspace doesn't contain details on the\r\ntarget service account rather than the OAuth client ID, the thesis performs a cross-correlation with the related GCP\r\nevents to gather information on the relevant GCP Service Account details, such as the related GCP project, and\r\nprivate key creation events on the target identity object.\r\nRelevant Data Sources\r\nGoogle Workspace Audit Logs\r\nOptional: GCP Audit Logs (threat hunting enrichment)\r\nBlind Spots\r\nBackdoored Google Workspace application from the Google Marketplace. This is less likely to happen as\r\nGoogle has an in-depth approval process review for Marketplace applications.\r\nInvestigation Flow\r\nLook into the creation time of the GCP Service Account private key (for instance, older keys could be less\r\nsuspicious).\r\nInvestigate the actor email that created the delegation configuration.\r\nInvestigate the service account by correlating the OAuth ID to the GCP service logs.\r\nInvestigate the IP which created the GCP Service Account key (this is crucial as the delegating IP\r\nisn't recorded in Google Workspace logs).\r\nInvestigate the user who created the GCP Service Account key.\r\nhttps://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover\r\nPage 21 of 26\n\nExamine the IP address linked to the authentication session of the Google Workspace super admin who\r\ncreated the delegation rule.\r\nInvestigate the API calls made by the Service Account delegation.\r\nWhat API calls is it making, and to which REST API applications?\r\nInvestigate the target user identity which the API call made on his behalf\r\nDo the API calls happen repetitively on the same identities? Is the target identity an employee or a\r\nprogrammatic user account?\r\nReview the OAuth scopes attached to the identity object (eg: read-only, edit, administration)\r\n→ SQL Query can be found here. \r\nHUNTING FOR ANOMALOUS WORKSPACE OAUTH CALLS\r\nOverview \r\nThe thesis looks for suspicious OAuth API calls. Namely, detecting anomalous token events with a combination of\r\nan unseen API call and a target Workspace user made by a GCP Service Account Identity object. Please note that it\r\nis recommended that this thesis be used with UEBA or ML algorithms- the provided is a proof of concept\r\nimplementation using SQL. \r\nRelevant Data Sources\r\nGoogle Workspace Audit Logs\r\nBlind Spots\r\nThe attacker uses API calls and targets a user who is frequently accessed by the breached Service Account. \r\nInvestigation Flow\r\nExamine the IP address that initiated the API calls\r\nExamine the API calls to the Workspace REST API application and assess the impact\r\nReview the OAuth scopes attached to the identity object (eg: read-only, edit, administration)\r\nExamine what Service Account Identity object performed the activity.\r\n→ SQL Query can be found here. \r\nHUNTING FOR EXTENSIVE SERVICE ACCOUNT KEY CREATIONS OVER A SHORT PERIOD OF TIME\r\nOverview \r\nThe thesis looks for extensive service account private key creations over a short period of time which can indicate\r\nan automatic attacking activity to find Service Accounts with DWD functionality. This thesis is specifically based\r\non Delefriend characteristics. \r\nRelevant Data Sources\r\nGCP Audit Logs\r\nhttps://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover\r\nPage 22 of 26\n\nBlind Spots\r\nThe compromised identity has a relevant role in a small number of Service Accounts, which results in a key\r\ncreation number that doesn’t meet the threshold. \r\nInvestigation Flow\r\nExamine the IP address that initiated the API calls\r\nExamine the User Agent that initiated the API calls\r\nExamine the Service Account Key Management config (we would expect it’ll mostly be\r\nUSER_MANAGED)\r\nExamine if any of the involved Service Accounts have a Domain-Wide Delegation configured\r\nPivot for any further activity made by the involved IAM identity\r\n→ SQL Query can be found here. \r\nPostures \u0026 Hygiene\r\nINACTIVE DELEAGED SA OBJECTS\r\nThe importance of managing inactive delegated service accounts in GCP has been underscored in this paper,\r\nparticularly after demonstrating how a single dormant service account can lead to a complete takeover of the\r\nwhole Workspace domain.\r\nSo, how can we prevent this? To help identify inactive delegated service account entities in your GWS\r\nenvironment, we've developed a posture query that analyzes Workspace audit logs.\r\nThe logic will work as follows:\r\n1. Retrieves data on the creation and removal of global delegations within the Workspace domain.\r\n1. Filters for GCP Service Account identity objects.\r\n2. Sorts creation and deletion events for each identity.\r\n2. Creates a statistical summary of application API calls made by the delegated object, which is based on the\r\nService Account OAuth ID.\r\n3. Provides a snapshot of inactive Identity objects (those that haven't been removed) and a summary of their\r\nAPI usage, such as the number of API calls and the last time they were seen.\r\nhttps://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover\r\nPage 23 of 26\n\nInactive delegated SA found from the query\r\nGuidelines\r\nReview the query results, focusing on service accounts that haven't initiated any API calls in a reasonable\r\ntime frame, which can be identified by the LAST_API_CALL and DAYS_SINCE_LAST_CALL attributes.\r\nWe decided to not limit the query to a certain threshold as it should be based on your organization's policy.\r\nEvaluate the inactive delegations outlined in the query results. If they aren't in use, you may want to\r\nconsider removing them.\r\nExamine the private keys of the found GCP service accounts. If you encounter a key that isn't recognizable,\r\nyou might want to consider revoking it and generating a new one.\r\nIf the delegation is determined to be in the expected configuration, despite it not currently being utilized,\r\nreview the OAuth scopes attached to the service. You might want to consider removing any scopes that are\r\nnot absolutely needed for the service to function. \r\n → The query can be found here.\r\nGCP SA PRIVATE KEYS ON WORKSTATIONS\r\nIn the explanatory sections, we've studied the naming convention for GCP SA private keys upon creation. Once a\r\nkey pair has been created, it is automatically downloaded and will not be retrievable afterward. Neglecting a GCP\r\nSA key pair can create a significant security posture gap. Hence, it is advised to actively search for and expose any\r\nunused pairs that might be stored insecurely in workstations and servers.\r\nThe naming structure of the GCP SA key pair includes the GCP Project ID that the Service Account is associated\r\nwith, and a randomly generated string of 12 characters:\r\n\u003cgcp_project_id\u003e-\u003cprivate_key_id{12}\u003e.json\r\nhttps://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover\r\nPage 24 of 26\n\nAn example of GCP SA key pair naming convention\r\nBy cleverly utilizing and cross-correlating GCP audit logs and EDR data, we are able to reliably hunt for file\r\nevents associated with GCP SA key pairs. We’ll leverage the project names from the GCP audit logs in order to\r\nmake the search as efficient and accurate as possible and search them in the form of the naming convention in the\r\nEDR data. \r\n→ The query can be found here.\r\nGuidelines:\r\nReview the query results, focusing on key pairs that might be forgotten for workstations by the key\r\ncreator. \r\nIt is recommended to guide and educate the relevant employees on saving the key pairs in a secure place,\r\nand not in their workstations. \r\nIf there's a suspicion that a private key pair has been exposed or leaked, delete the private key pair from the\r\ncorresponding Service Account and generate a new pair.\r\nSummary of Best Practices\r\nSmartly manage roles for GCP resources with Domain-Wide delegation, ensuring only necessary IAM\r\nusers have permission to create private keys on sensitive service accounts. Ideally, create each service\r\naccount in a separate project if possible.\r\nLimit OAuth scopes in delegations as much as possible. Adhere to the principle of least privilege, where an\r\napplication only requests the permissions it absolutely needs. Also, refrain from using administrative\r\nscopes such as https://www.googleapis.com/auth/admin to minimize potential impact in case of a\r\ncompromise.\r\nImplement detection engineering and threat hunting practices for any signs started from newly suspicious\r\ndelegations and numerous amount of private key creations over a short period of time.  Follow the methods\r\nand queries outlined in the blog post.\r\nMaintain a continuous, close examination of security posture and address any hygiene gaps. Various\r\nmethods for this are detailed in the blog post.\r\nConclusion\r\nIn today’s blog post, we drew attention to the design vulnerability in Google Workspace. The concern was rooted\r\nin an overly permissive design of the Domain-Wide Delegation feature, posing a risk of unauthorized domain\r\nidentity access. This design flaw and research paper were responsibly reported to Google in advance as part of the\r\nhttps://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover\r\nPage 25 of 26\n\n“Bug Hunters” program in August 2023. As of this publication, the flaw remains active.  To support organizations\r\nin understanding and managing the risks associated with this technique, we’ve provided a proof-of-concept tool\r\nand a detailed technical breakdown of our discoveries.\r\nWe wrapped up with the \"Let’s go hunting\" section, detailing threat detection methods and offering\r\nrecommendations to safeguard against Domain-Wide Delegation attack methods. We are sharing this knowledge\r\nand recommendations with the broader community to ensure that any organization is able to safeguard against\r\nDomain-Wide Delegation attack methods and we encourage everyone to share with potentially affected parties.\r\nVulnerability Disclosure Timeline\r\nAug 7, 2023 – Hunters discloses the vulnerability to Google.\r\nAug 7, 2023 – Google initially responds, identifying the vulnerability as “Abuse Risk”.\r\nOct 31, 2023 – Google accepts the DeleFriend report. \r\nReferences\r\nhttps://support.google.com/a/answer/162106\r\nhttps://developers.google.com/identity/protocols/oauth2\r\nhttps://github.com/googleapis/google-auth-library-python/tree/main\r\nhttps://blog.sygnia.co/incident-response-in-google-cloud-foundations\r\nhttps://about.gitlab.com/blog/2020/02/12/plundering-gcp-escalating-privileges-in-google-cloud-platform/ \r\nhttps://developers.google.com/identity/protocols/oauth2/policies\r\nhttps://cloud.google.com/identity/docs/overview \r\nImportant: The DeleFriend POC tool was created as a proof-of-concept tool to increase awareness around OAuth\r\ndelegation attacks in GCP and Google Workspace and to improve the security posture of organizations that use the\r\nDomain-Wide-Delegation feature. DeleFriend POC tool should be used solely for authorized security research\r\npurposes. This tool is provided “as is” and Hunters disclaims any and all warranties and liabilities regarding the\r\nuse/misuse of this tool. Use responsibly.\r\nTo stay updated on threat hunting research, activities, and queries, follow Team Axon’s Twitter account\r\n(@team__axon).\r\nHUNTERS © 2023 All rights reserved\r\nThe Hunters and Axon Team trademarks, service marks and logos used herein are owned by Cyber Hunters Ltd.\r\nAll other trademarks used herein are the property of their respective owners.\r\n \r\nSource: https://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-work\r\nspace-vulnerable-for-takeover\r\nhttps://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover\r\nPage 26 of 26",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover"
	],
	"report_names": [
		"delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover"
	],
	"threat_actors": [],
	"ts_created_at": 1775434660,
	"ts_updated_at": 1775791224,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/ca6817527c85ac05b7749ba30483fb5cd195a399.pdf",
		"text": "https://archive.orkl.eu/ca6817527c85ac05b7749ba30483fb5cd195a399.txt",
		"img": "https://archive.orkl.eu/ca6817527c85ac05b7749ba30483fb5cd195a399.jpg"
	}
}