{ "id": "545fe1be-46ad-4a6c-9c9b-3501a10444a8", "created_at": "2026-04-06T00:10:19.54182Z", "updated_at": "2026-04-10T03:23:51.541575Z", "deleted_at": null, "sha1_hash": "8c72cc80ccbcfa34b502b91937c954af3faa167e", "title": "Behind The Breach: Self-Service Password Reset (SSPR) Abuse in Azure AD", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 1122754, "plain_text": "Behind The Breach: Self-Service Password Reset (SSPR) Abuse in\r\nAzure AD\r\nArchived: 2026-04-05 16:22:14 UTC\r\nIn several recent investigations of SaaS security incidents, the Obsidian threat research team identified a novel\r\nattack vector in the wild: abuse of the Azure AD self-service password reset (SSPR) feature.\r\nWith the glaring lack of coverage around this specific threat vector, our team felt it would be an important topic\r\nfor discussion. In this blog, we’ll explore the self-service password reset technique in more detail, share some\r\nfirsthand examples from the field, and discuss measures for mitigating this risk.\r\nSelf-service password reset is an Azure AD feature that allows users to reset their password without the\r\ninvolvement of an administrator or help desk. It is designed for convenience and productivity so that users who\r\nforgot their password or get locked out can easily reset it themselves with minimal friction.\r\nAdministrators are able to configure SSPR for the entire organization or a subset of groups via the Azure portal.\r\nThey can also define requirements for permitted forms of verification and the number of verification methods\r\nrequired to perform the reset.\r\nhttps://www.obsidiansecurity.com/blog/behind-the-breach-self-service-password-reset-azure-ad/\r\nPage 1 of 8\n\nHow is self-service password reset being abused?\r\nWe’ve already seen several organizations suffer breaches that began with SSPR as the initial access vector. There\r\nare two primary methods through which adversaries have been abusing this tool:\r\nSIM swapping to gain initial access\r\nAttacker registered MFA to establish persistence\r\nSIM swapping is an increasingly popular tactic that adversaries use to take control of a target phone number. This\r\ntypically involves social engineering a mobile carrier in order to initiate a number transfer to a new SIM card or\r\nbribing (via a broker) internal employees to execute a swap. If an adversary controls your number and your\r\norganization’s SSPR is configured to only require a single verification method, the attacker should have no\r\nproblem gaining entry.\r\nAfter establishing initial access, adversaries were seen enrolling their own MFA methods—typically mobile\r\nauthenticator applications or disposable emails—to guarantee their own persistence.\r\nIn one of our investigations, the victim recovered their phone service and regained access to their account with the\r\nhelp of their IT/security team. They still failed to reverse the malicious MFA enrollment, allowing the attacker to\r\ninitiate another SSPR and take back the account. Now imagine this technique at scale against a large user base and\r\nhow overwhelming it would be for any security team to address.\r\nhttps://www.obsidiansecurity.com/blog/behind-the-breach-self-service-password-reset-azure-ad/\r\nPage 2 of 8\n\nThe screenshot below shows a timeline of events where an adversary battled IT efforts to reset the victim’s\r\npassword. Unsure of what to do, the IT team temporarily disabled the account and ultimately decided to delete it\r\nentirely.\r\nStealing a target’s phone number and resetting their password might seem like a noisy method for initial access,\r\nbut our intel reveals time and time again that sophisticated adversaries can operate with extreme efficiency in\r\nSaaS environments. A few hours alone can allow bad actors to accomplish a wide variety of goals and cause\r\nsignificant damage to your business. After initial access, reconnaissance, and post-authentication operations, an\r\nattacker has access to a trove of internal intelligence which helps them carry out subsequent attacks with a higher\r\nlikelihood of success.\r\nWhat can I do to remain secure?\r\nCombating SSPR Abuse\r\nhttps://www.obsidiansecurity.com/blog/behind-the-breach-self-service-password-reset-azure-ad/\r\nPage 3 of 8\n\nThere are a few options available to eliminate the SSPR vector entirely or, at minimum, provide warnings of\r\npotential abuse.\r\nDisable SSPR globally. Microsoft recommends that SSPR be enabled for all users to reduce the burden on IT and\r\nminimize employee downtime should they forget their passwords. As many security practitioners know, this type\r\nof convenience often sits opposite of security.\r\nObsidian insights reveal that 39% of Microsoft tenants have SSPR disabled for more than 75% of their user\r\npopulation.\r\nThis demonstrates that organizations can function fine without the feature enabled. Disabling SSPR completely\r\nblocks initial access via SIM swap and opportunities for re-entry.\r\nIn cases where we’ve seen SSPR abuse lead to an incident, it is often enough motivation for the affected\r\norganization to disable it completely.\r\nRequire more than one method for SSPR. In a SIM swap attack, the stolen phone number can be used as a\r\nverification method to reset the password, essentially downgrading MFA to single factor authentication.  It is\r\npossible to configure SSPR to require 2 verification methods in order to perform the reset. This way the attacker\r\nwill need more than just the target’s phone number to complete the SSPR flow. Requiring two verification\r\nmethods in SSPR would raise the bar higher as it is for MFA, with a caveat of what methods are chosen.\r\nSSPR prompt where 2 methods are required for verification.\r\nRestrict the methods that can be used to perform an SSPR.  If globally disabling SSPR or requiring two\r\nmethods for all users isn’t an option, you can also choose to restrict which methods can be used to perform a\r\npassword reset.  Disabling mobile and office phones as a method will completely block SIM swap attacks.\r\nhttps://www.obsidiansecurity.com/blog/behind-the-breach-self-service-password-reset-azure-ad/\r\nPage 4 of 8\n\nHowever, since SSPR is not completely disabled, re-entry by an attacker via a malicious MFA method is still\r\npossible.\r\nMicrosoft UI for SSPR method selection\r\nDetect early signs of SSPR recon. Successful SIM swapping necessitates sufficient preliminary reconnaissance\r\nto identify a viable target. Aside from requiring the information to social engineer a mobile carrier, the adversary\r\nneeds to determine whether or not the target is even susceptible to SSPR abuse.\r\nGiven any email address, it is easy to validate if it is a valid Microsoft 365 account. The below curl command can\r\nbe used to determine if a given email address is a managed account in Microsoft 365:\r\ncurl -s -X POST https:///login.microsoftonline.com/common/GetCredentialType –data\r\n‘{“Username”:”user@domain.com”}’\r\nOnce you have valid Microsoft 365 accounts, you can initiate the SSPR flow and see which verification options\r\nare available. Attackers likely need to perform this recon as well if they are going to spend the time and effort\r\nperforming the initial SIM swap.\r\nThe Microsoft interface that appears during a SSPR clearly indicates whether one or two verification methods are\r\nrequired, making it easier for attackers to select vulnerable target accounts. Examining SSPR initiations that were\r\nnever completed from suspicious IPs can serve as an early warning of potential recon. A burst of these activities\r\nfor multiple accounts—especially high-value targets—reveals that your organization is likely being targeted and\r\ncan serve as justification for the reconfiguration or disabling of SSPR.\r\nThe below screenshot shows a variety of user accounts initiating SSPR flows from TOR exit nodes, but never\r\nfinishing them.  This is a strong indicator that an attacker is performing recon and identifying potential targets for\r\nhttps://www.obsidiansecurity.com/blog/behind-the-breach-self-service-password-reset-azure-ad/\r\nPage 5 of 8\n\nan SSPR attack.\r\nDetect suspicious SSPR activity. While migrating away from tenant configurations that make SSPR abuse\r\npossible, it is important to have the appropriate detections in place that would detect its abuse by an attacker.  If a\r\nSSPR flow is completed via SMS or phone call options from a rare and suspicious IP, it may indicate a potential\r\nSIM Swap attack that was then used to perform SSPR.  While detecting the initial SIM Swap may be out of reach\r\nfor security teams due to the lack of visibility into phone numbers and ICCID binding, identifying the follow-up\r\nattack methods are still within scope.\r\nhttps://www.obsidiansecurity.com/blog/behind-the-breach-self-service-password-reset-azure-ad/\r\nPage 6 of 8\n\nAvailability of SSPR settings data\r\nThose familiar with the Microsoft ecosystem will not be surprised when they learn that important settings related\r\nto SSPR are not available via an API or Powershell.  At the time of writing this blog post, users that can perform\r\nSSPR can be pulled from a reports endpoint in the MS Graph API.  However, the details around how many\r\nmethods are required to perform the reset and which methods can be used can only be found via an internal API\r\nused by the Azure Portal web UI.\r\nSSPR on other SaaS services\r\nWe’ve quickly checked if other SaaS services allow SSPR with a single method related to SIM. While it is not an\r\noption for the majority of services, there are indeed a few services that employ single factor SMS as an optional\r\nmethod for authentication, which would be vulnerable to similar SIM swapping attacks. Note that our team did not\r\ncheck SaaS service exhaustively. It is recommended that IT teams build awareness around SaaS services used in\r\ntheir organizations and make sure phone number-based authentication is disabled.\r\nhttps://www.obsidiansecurity.com/blog/behind-the-breach-self-service-password-reset-azure-ad/\r\nPage 7 of 8\n\nAnother such example of a SaaS service offering phone number authentication.\r\nConclusion\r\nAs SIM swapping becomes an active attack vector in the wild, it has more significant security implications on\r\nSSPR and other features that rely on the security of SIM. Security team should be aware of this attack vector, re-evaluate the risk level of enabling such features, and closely monitor any suspicious activities coming from this\r\nvenue.\r\nSource: https://www.obsidiansecurity.com/blog/behind-the-breach-self-service-password-reset-azure-ad/\r\nhttps://www.obsidiansecurity.com/blog/behind-the-breach-self-service-password-reset-azure-ad/\r\nPage 8 of 8", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "references": [ "https://www.obsidiansecurity.com/blog/behind-the-breach-self-service-password-reset-azure-ad/" ], "report_names": [ "behind-the-breach-self-service-password-reset-azure-ad" ], "threat_actors": [ { "id": "d90307b6-14a9-4d0b-9156-89e453d6eb13", "created_at": "2022-10-25T16:07:23.773944Z", "updated_at": "2026-04-10T02:00:04.746188Z", "deleted_at": null, "main_name": "Lead", "aliases": [ "Casper", "TG-3279" ], "source_name": "ETDA:Lead", "tools": [ "Agentemis", "BleDoor", "Cobalt Strike", "CobaltStrike", "RbDoor", "RibDoor", "Winnti", "cobeacon" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775434219, "ts_updated_at": 1775791431, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/8c72cc80ccbcfa34b502b91937c954af3faa167e.pdf", "text": "https://archive.orkl.eu/8c72cc80ccbcfa34b502b91937c954af3faa167e.txt", "img": "https://archive.orkl.eu/8c72cc80ccbcfa34b502b91937c954af3faa167e.jpg" } }