{ "id": "eb2daf10-9ac2-4be1-9969-21d58e04a742", "created_at": "2026-04-06T00:13:03.728347Z", "updated_at": "2026-04-10T13:12:13.970111Z", "deleted_at": null, "sha1_hash": "545399a8938b352c74eb1c05bdfa629b72dcc92f", "title": "Microsoft Internal Solorigate Investigation - Final Update", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 36959, "plain_text": "Microsoft Internal Solorigate Investigation - Final Update\r\nBy MSRC Team\r\nPublished: 2021-02-18 · Archived: 2026-04-05 20:15:20 UTC\r\nWe believe the Solorigate incident is an opportunity to work with the community, to share information, strengthen\r\ndefenses and respond to attacks. We have now completed our internal investigation into the activity of the actor\r\nand want to share our findings, which confirm that we found no evidence of access to production services or\r\ncustomer data. The investigation also found no indications that our systems at Microsoft were used to attack\r\nothers. Because of our defense-in-depth protections, the actor was also not able to gain access to privileged\r\ncredentials or leverage the SAML techniques against our corporate domains.\r\nAdditional Details\r\nAs we previously reported, we detected unusual activity in December and took action to secure our systems. Our\r\nanalysis shows the first viewing of a file in a source repository was in late November and ended when we secured\r\nthe affected accounts. We continued to see unsuccessful attempts at access by the actor into early January 2021,\r\nwhen the attempts stopped.\r\nThere was no case where all repositories related to any single product or service was accessed. There was no\r\naccess to the vast majority of source code. For nearly all of code repositories accessed, only a few individual files\r\nwere viewed as a result of a repository search.\r\nFor a small number of repositories, there was additional access, including in some cases, downloading component\r\nsource code. These repositories contained code for:\r\na small subset of Azure components (subsets of service, security, identity)\r\na small subset of Intune components\r\na small subset of Exchange components\r\nThe search terms used by the actor indicate the expected focus on attempting to find secrets. Our development\r\npolicy prohibits secrets in code and we run automated tools to verify compliance. Because of the detected activity,\r\nwe immediately initiated a verification process for current and historical branches of the repositories. We have\r\nconfirmed that the repositories complied and did not contain any live, production credentials.\r\nLessons Learned\r\nThe cybersecurity industry has long been aware that sophisticated and well-funded actors were theoretically\r\ncapable of advanced techniques, patience, and operating below the radar, but this incident has proven that it isn’t\r\njust theoretical. For us, the attacks have reinforced two key learnings that we want to emphasize —embracing a\r\nZero Trust mindset and protecting privileged credentials.\r\nhttps://msrc-blog.microsoft.com/2021/02/18/microsoft-internal-solorigate-investigation-final-update/\r\nPage 1 of 2\n\nA Zero Trust, “assume breach” philosophy is a critical part of defense. Zero Trust is a transition from implicit trust\r\n—assuming that everything inside a corporate network is safe—to the model that assumes breach and explicitly\r\nverifies the security status of identity, endpoint, network, and other resources based on all available signals and\r\ndata. We’ve recently shared guidance for using Zero Trust principles to protect against sophisticated attacks like\r\nSolorigate.\r\nProtecting credentials is essential. In deployments that connect on-premises infrastructure to the cloud,\r\norganizations can delegate trust to on-premises components. This creates an additional seam that organizations\r\nneed to secure. A consequence of this decision is that if the on-premises environment is compromised, this creates\r\nopportunities for attackers to target cloud services. We strongly recommend mastering identity in the Cloud, as\r\ndescribed in protecting your M365 cloud services from on-premise attacks.\r\nWe have also shared additional insights on these best practices in Turning the page on Solorigate and opening the\r\nnext chapter for the security community. Though our internal investigation is closing, it does not mean we are\r\ndone. It means we are maintaining our normal Zero Trust security posture, where our security teams work\r\ncontinually to protect users, devices and data from ongoing threats to our environment. Our collaborative work\r\nwith the cybersecurity community to protect from ongoing threats continues and, as we learn more, we will share\r\nlearnings and guidance as appropriate.\r\nSource: https://msrc-blog.microsoft.com/2021/02/18/microsoft-internal-solorigate-investigation-final-update/\r\nhttps://msrc-blog.microsoft.com/2021/02/18/microsoft-internal-solorigate-investigation-final-update/\r\nPage 2 of 2", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "origins": [ "web" ], "references": [ "https://msrc-blog.microsoft.com/2021/02/18/microsoft-internal-solorigate-investigation-final-update/" ], "report_names": [ "microsoft-internal-solorigate-investigation-final-update" ], "threat_actors": [ { "id": "aa73cd6a-868c-4ae4-a5b2-7cb2c5ad1e9d", "created_at": "2022-10-25T16:07:24.139848Z", "updated_at": "2026-04-10T02:00:04.878798Z", "deleted_at": null, "main_name": "Safe", "aliases": [], "source_name": "ETDA:Safe", "tools": [ "DebugView", "LZ77", "OpenDoc", "SafeDisk", "TypeConfig", "UPXShell", "UsbDoc", "UsbExe" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775434383, "ts_updated_at": 1775826733, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/545399a8938b352c74eb1c05bdfa629b72dcc92f.pdf", "text": "https://archive.orkl.eu/545399a8938b352c74eb1c05bdfa629b72dcc92f.txt", "img": "https://archive.orkl.eu/545399a8938b352c74eb1c05bdfa629b72dcc92f.jpg" } }