Summary
SharePoint in Microsoft 365 (formerly SharePoint Online (SPO)[1]), is Microsoft's cloud-based solution for sharing and managing content such as files, data, news, and resources. Services such as Microsoft Teams and OneDrive use it for storing files. The Microsoft SharePoint Migration Tool (SPMT) migrates files from on-premises SharePoint and file shares to SharePoint in Microsoft 365.
In November 2022, Secureworks® Counter Threat Unit™ (CTU) researchers studied the API used by SPMT. At that time, the API enabled any user with 'Owners' permissions to upload and replace SPO files without generating audit log events. An attacker could create a team and then spoof or tamper with file metadata such as timestamps and the name of file creator. In March 2023, CTU™ researchers discovered that the API also allowed replacement of SPO design elements, enabling cross-site scripting (XSS) attacks. In the worst case, these attacks could lead to elevation of privilege and full compromise of the target tenant.
CTU researchers shared the spoofing and tampering findings with Microsoft on November 28, 2022. Microsoft confirmed the findings in January 2023 but stated that it was expected behavior. CTU researchers shared the XSS findings with Microsoft on March 17. Microsoft confirmed the findings in April and deployed a fix in August 2023. This fix implements a log event at the start of new migration job. The event specifies the account performing the job and the SPO site the migration targets.
Migrating files to SPO
SPMT allows users to migrate a large number of files from on-premises SharePoint servers and file shares (see Figure 1).
Figure 1. SPMT migration sources. (Source: Secureworks)
Files can be migrated to Microsoft Teams, SharePoint, and OneDrive (see Figure 2).
Figure 2. SPMT migration targets. (Source: Secureworks)
Migration requires site admin permissions. If migrating to Teams, the user running SPMT must have an Owners role, which includes site admin permissions to the corresponding backend SPO site. Typically, all users are able to create teams and the team creator is granted the owner role by default.
SharePoint migration process
Figure 3 illustrates the SharePoint migration process.
Figure 3. SPMT process. (Source: Secureworks)
Get migration information
Two HTTP POST requests are made to https: //<site>/_vti_bin/client.svc/ProcessQuery. The first query uses the XML payload shown in Figure 4 to request information about the container.
Figure 4. ProvisionMigrationContainers request. (Source: Secureworks)
The response is a JSON file with URLs to two Azure storage account containers (metadata and data) and a random symmetric encryption key (see Figure 5).
Figure 5. ProvisionMigrationContainersInfo response. (Source: Secureworks)
The second query uses the XML payload shown in Figure 6 to request the migration queue information.
Figure 6. ProvisionMigrationQueue request. (Source: Secureworks)
The response is a JSON file containing a URL to a migration queue (see Figure 7).
Figure 7. ProvisionMigrationQueueInfo response. (Source: Secureworks)
Upload metadata and files
Metadata and files are sent to dedicated blob storage containers via HTTP PUT requests. The metadata and files are first encrypted using the symmetric encryption key provided in the ProvisionMigrationContainersInfo response from step 1 and a random initialization vector (IV).
Uploading a file involves three HTTP PUT requests. The first request contains the encrypted file and includes the MD5 hash of the file in the Content-MD5 header (see Figure 8).
Figure 8. File upload request 1. (Source: Secureworks)
The URL of the second request ends with query parameter “?comp=metadata”, and the request contains the IV in the x-ms-meta-IV header (see Figure 9).
Figure 9. File upload request 2. (Source: Secureworks)
The URL of the third request ends with query parameter “?comp=snapshot”. This request does not specify additional special headers (see Figure 10).
Figure 10. File upload request 3. (Source: Secureworks)
Various metadata files are involved. Some are optional, but Manifest.xml, UserGroup.xml, Requirements.xml, ExportSettings.xml, and SystemData.xml are required. Manifest.xml (see Figure 11) is the most important metadata file. It contains SPObject elements that define what information is migrated and where it will be saved in the target site. The File element represents the migrated file and contains information such as folder names, creation and last modification times, and a reference of the person who created and modified the file. The ListItem element specifies how the file appears in a specific SharePoint list.
Figure 11. Manifest.xml. (Source: Secureworks)
Figure 12 lists the attributes of the File element. FileValue refers to the name of the encrypted file uploaded to the data container.
Figure 12. File element attributes. (Source: Secureworks)
Author and ModifiedBy refer to a User element in UserGroup.xml (see Figure 13). This metadata is important because the migration API uses it to set all of the attributes on the migrated copy of the data to be stored in SPO.
Figure 13. UserGroup.xml. (Source: Secureworks)
Start migration job
A migration job begins with an HTTP POST request to https: //<site>/_vti_bin/client.svc/ProcessQuery that contains the XML payload in Figure 14. Before sending, the payload must be “flattened” into a single line of code without line breaks or indenting. The request includes the URLs obtained in the previous steps: the first two URLs (lines 6 and 7) are for migration containers, and the third URL (line 8) is for the migration queue.
Figure 14. CreateMigrationJobEncrypted request. (Source: Secureworks)
Get status message
Making an HTTP GET request to the migration queue URL from step 1 reveals the status of the job. The response may have 1 to 30 messages (see Figure 15).
Figure 15. QueueMessage response. (Source: Secureworks)
The MessageText is a Base64-encoded JSON file (see Figure 16). The content is encrypted with the symmetric encryption key from step 1 and the IV (line 4).
Figure 16. Decoded MessageText. (Source: Secureworks)
Figure 17 shows a sample decrypted JobEnd message that indicates the migration is complete.
Figure 17. Decrypted JobEnd message. (Source: Secureworks)
Spoofing and tampering with SPO files
Calling the migration API directly without using the SPMT tool gives attackers full control over the metadata and enables spoofing of files and their attributes, including the file creator and timestamps. For instance, the AADInternals toolkit contains functionality to spoof the files (see Figure 18). By accessing the migration API directly, attackers can upload arbitrary files to SPO.
Figure 18. Spoofing files with AADInternals. (Source: Secureworks)
Modifying the Manifest.xml file to use the UniqueID of an existing file allows an attacker to tamper with the file content and metadata. The UniqueId can be fetched via an HTTP GET request to https: //<site>/_api/web/GetFileByServerRelativePath(decodedurl='/sites/<sitename>/<relativepath>/<filename>'). The response includes the file's UniqueId (see Figure 19).
Figure 19. GetFileByServerRelativePath response. (Source: Secureworks)
AADInternals provides functionality to tamper with existing SPO files (see Figure 20).
Figure 20. Tampering with existing SPO files via AADInternals. (Source: Secureworks)
Tampering with SPO design
The SPO user interface is based on ASP.NET web pages. These ASPX files are treated like other files in SharePoint, which means they can also be tampered with via the migration API. The content of an ASPX file can be downloaded by obtaining the file's UniqueId and making an HTTP GET request to https: //<site>/_api/web/GetFileById(‘<UniqueId>')/OpenBinaryStream. The response contains the file contents. For example, Figure 21 shows the content of AllItems.aspx, which renders the default view of SharePoint sites. An attacker could insert malicious code into the downloaded AllItems.aspx file (see line 17) and then replace the original file in SharePoint. When a user visits the infected SharePoint site, the malicious code is run with their permissions. Depending on the code and victim's permissions, this could lead to elevation of privilege and total control of the target tenant.
Figure 21. AllItems.aspx. (Source: Secureworks)
SPO has security settings that prevent non-administrators from running custom scripts on personal sites and self-service created sites such as Teams. By default, these capabilities are disabled on the tenant level (see Figure 22). Custom scripts can be enabled on the site level but only by users who have a tenant-level SharePoint Administrator role. Site administrators cannot enable custom scripts.
Figure 22. Tenant-level custom script settings. (Source: Secureworks)
CTU researchers noticed that the migration API does not respect custom script settings, so an attacker could modify existing ASPX files and inject arbitrary malicious content. The fix Microsoft implemented in August 2023 blocks these modifications if the settings to prevent custom scripts are selected (see Figure 23).
Figure 23. SPO design modification blocked. (Source: Secureworks)
Communication with Microsoft
CTU researchers reported the spoofing and tampering findings to the Microsoft Security Response Center (MSRC) on November 28, 2022. The MSRC responded on January 26, 2023:
MSRC has investigated this issue and concluded that this does not require immediate attention as Migration API overwrites the existing files (clearly documented in SharePoint Online Import Migration API | Microsoft Learn). When migrating content from SharePoint On-premises, customers want to preserve metadata from source files, to keep them on SharePoint Online. Appending versions is not supported and the files will be overwritten. Only SharePoint site collection administrator (SCA) is able to submit the job, and we expect that a SCA has sufficient knowledge about the migration. For large enterprise customers, a tenant admin is responsible for migration of all content for an organization. Therefore, preserving the name of the migrator does not make a lot of sense for the migration experience.
We have shared your report with the team responsible for maintaining the product or service and they will consider a potential future fix, taking the appropriate action as needed to help keep customers protected. We do not have a timeline for when this review will occur and will not be able to provide status for this issue moving forward.
As no further action is required by the MSRC, I am closing this case. Please know that there will be no further correspondence from Microsoft regarding this submission.
We appreciate your efforts and thank you for giving us the opportunity to improve our products and protect our customers!
On March 17, CTU researchers notified the MSRC that the migration API could be used to modify the SPO design, enabling XSS attacks. The MSRC responded on April 4:
We confirmed the behavior you reported. We'll continue our investigation and determine how to address this issue.
Please let me know if you have additional information that could aid our investigation, or if you have questions.
On July 12, the MSRC announced that a fix was deployed:
Just working through my emails and found that the engineering team has confirmed that the fix has completed rolling out for this report as of this week.
On July 27, CTU researchers notified the MSRC that the fix did not solve the issue. CTU researchers worked closely with the MSRC from August 3 to August 7 to implement a fix that addressed the issue. On August 10, CTU researchers confirmed that the fix was deployed and performed as expected.
Conclusion
Organizations using SharePoint in Microsoft 365 can minimize the impact of SPMT API abuse by implementing the following restrictions. These actions will limit the number of users capable of exploiting the API. However, the restrictions will likely impact productivity because users cannot add or invite new members to Teams and Microsoft 365 groups. Moreover, these actions do not impede exploitation of the API in OneDrive.
- Allow only specified administrators to create Microsoft 365 groups. This change prevents other users from creating Viva Engage communities, Microsoft Teams, plans in Planner, projects in Project for the web. As a result, the users cannot obtain Owners permissions.
- Remove unnecessary Owners from existing Teams and other services that are based on Microsoft 365 groups.
CTU researchers have urged Microsoft to allow organizations to disable the SPMT API across the tenant but to enable it for individual sites as needed.
[1] This analysis retains the SPO terminology that was in use during the investigation.