{ "id": "a9e22841-a351-479e-b448-376ee2e5c802", "created_at": "2026-04-06T00:10:57.951461Z", "updated_at": "2026-04-10T03:21:09.530274Z", "deleted_at": null, "sha1_hash": "0eeb102dd486707619702ca25bbe0b72f1f70916", "title": "Keys to the (SaaS) kingdom", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 512570, "plain_text": "Keys to the (SaaS) kingdom\r\nBy Jennifer Ring\r\nPublished: 2025-05-29 · Archived: 2026-04-05 13:39:27 UTC\r\nPublished by Digital Forensics and Incident Response (DFIR) and Cyber Intelligence on 29 May 2025\r\nPrimary author: Tony Mau, DFIR\r\nIn May 2025, the CyberCX Digital Forensics and Incident Response (DFIR) team was engaged to investigate an\r\nincident in which the threat actor performed a domain registration hijacking attack through social engineering to\r\nverify themselves as legitimate domain owners to the domain registrar to take control of an organisation’s domain.\r\nDuring the investigation, the CyberCX DFIR and CyberCX Intelligence teams became aware of a campaign\r\nconsisting of multiple incidents associated with the same threat actor utilising domain registration hijacking to\r\ntarget financial technology, technology and professional service sectors.\r\nUsing this access, the threat actor was able to modify domain name system (DNS) records, including mail\r\nexchanger (MX) records, to redirect inbound emails to an attacker-controlled mail server. The threat actor was\r\nable to leverage legitimate functionality to verify the compromised domains on various SaaS platforms and\r\nattempted to abuse password reset functionality to reset credentials to privileged accounts through redirected\r\nemails.\r\nThis article focuses on some of the tactics, techniques and procedures (TTPs) that we’ve observed as part of this\r\ncampaign:\r\nhttps://cybercx.com.au/blog/keys-to-the-saas-kingdom/\r\nPage 1 of 4\n\nDomain registration hijacking\r\nCyberCX understands that the threat actor undertook a social engineering attack, leveraging fraudulent identity\r\ndocuments, including passports, to impersonate and verify themselves as the legitimate domain owners to the\r\ndomain registrar.\r\nUsing this access, the threat actor modified DNS records, including nameserver (NS) records and mail exchanger\r\n(MX) records, to threat actor controlled IP addresses. As a result, inbound emails to the domain were redirected to\r\nthe attacker’s mail server. Notably in at least one instance, these emails were not redirected back to the legitimate\r\nmail servers.\r\nBy leveraging their control over the domain, the threat actor was able to perform the following attack chain to\r\ntarget software-as-a-service platforms associated with the domain:\r\nFigure 1 – Threat actor attack chain\r\nSaaS platform domain verification\r\nIn at least one instance, the threat actor performed a novel technique to add an external cloud account with the\r\nhighest level of administrator permissions to the legitimate SaaS platform’s administration portal.\r\nThe threat actor was able to verify the domain on an external Atlassian organization, likely by adding TXT\r\nrecords to the compromised DNS, which enabled them to discover and centrally manage all Atlassian products\r\nassociated with the domain by leveraging Atlassian Guard’s Automatic Product Discovery feature. This feature\r\nis intended to allow Atlassian organization owners to discover and take control of shadow IT infrastructure created\r\nby users in their domain.\r\nIn February 2024, as part of updated Automatic Product Discovery functionality, Atlassian introduced the\r\nability for Organization Admins in the verified domain to join unmanaged Atlassian instances associated with the\r\ndomain. These users are added with the Organization Admin role.\r\nhttps://cybercx.com.au/blog/keys-to-the-saas-kingdom/\r\nPage 2 of 4\n\nFigure 2 – Automatic Product Discovery “Join as admin” option, sourced from Atlassian documentation\r\nThe threat actor was able to abuse this functionality to add an external Gmail account from an external threat actor\r\ncontrolled Atlassian organization, after performing domain verification, to the legitimate Atlassian organization’s\r\nAdministration portal as an Organization Admin. Using this access, the threat actor would have been able to\r\nremove all other Organization Admins, effectively taking control of their Atlassian organization and all associated\r\nAtlassian products including Confluence and Jira.\r\nEmail redirection\r\nThe threat actor also leveraged the email redirection to target SaaS platforms that utilise “magic link”\r\npasswordless authentication. By forcing authentication to domain accounts on these SaaS platforms, the threat\r\nactor was able to generate and intercept magic link URLs. Notably, some SaaS platforms such as Slack allow\r\nusers to join all workspaces associated with the domain that have the “Allow invitations and approve invitations\r\nfor any email address from these domains” option configured. The threat actor was observed accessing\r\nunmonitored Slack workspaces using compromised accounts and using Slack Connect to direct message users\r\noutside of the organisation as part of further social engineering attacks.\r\nMicrosoft’s self-service password reset portal was also abused for privileged account discovery using the\r\nautomated emails generated using the “Contact your administrator” link to identify accounts with Helpdesk\r\nAdministrator, Password Administrator, User Administrator or Global Administrator roles, as configured by\r\ndefault in Microsoft Entra ID.\r\nImpact\r\nhttps://cybercx.com.au/blog/keys-to-the-saas-kingdom/\r\nPage 3 of 4\n\nCyberCX is not aware of any ransomware activity associated with this campaign, however, in multiple instances,\r\nthe threat actor was able to successfully exfiltrate sensitive data and subsequently attempted to extort the\r\ncompromised organisation.\r\nAssessment\r\nCyberCX Intelligence has observed limited public reporting relating to this technique.\r\nCyberCX recommends organisations should work with their domain registrar to implement a domain registry\r\nlock, which will prevent any modifications to DNS server records, modification of contacts, transferring of\r\ndomains or deletion of domain names without proper authentication. An out of band communication channel\r\nshould further be established as part of this authentication procedure.\r\nAdditionally, organisations should audit their shadow IT infrastructure across all SaaS applications to ensure that\r\nthey have sufficient visibility of all systems created by their domain users which have not been directly approved\r\nby the organisation.\r\nMITRE ATT\u0026CK mapping\r\nTactic  Technique / Tool  Mitre ID \r\nReconnaissance Gather Victim Identity Information T1589\r\nResource Development\r\nCompromise Infrastructure: Domains T1584.001\r\nCompromise Infrastructure: DNS Server T1584.002\r\nInitial Access Valid Accounts: Cloud Accounts T1078.004\r\nPersistence Valid Accounts: Cloud Accounts T1078.004\r\nPrivilege Escalation Account Manipulation: Additional Cloud Roles T1098.003\r\nCredential Access Forced Authentication T1187\r\nDiscovery Account Discovery: Email Account T1087.003\r\nLateral Movement Remote Services: Cloud Services T1021.007\r\nExfiltration Email Collection: Remote Email Collection T1114.002\r\nSource: https://cybercx.com.au/blog/keys-to-the-saas-kingdom/\r\nhttps://cybercx.com.au/blog/keys-to-the-saas-kingdom/\r\nPage 4 of 4", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "references": [ "https://cybercx.com.au/blog/keys-to-the-saas-kingdom/" ], "report_names": [ "keys-to-the-saas-kingdom" ], "threat_actors": [], "ts_created_at": 1775434257, "ts_updated_at": 1775791269, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/0eeb102dd486707619702ca25bbe0b72f1f70916.pdf", "text": "https://archive.orkl.eu/0eeb102dd486707619702ca25bbe0b72f1f70916.txt", "img": "https://archive.orkl.eu/0eeb102dd486707619702ca25bbe0b72f1f70916.jpg" } }