Below is a plausible narrative on how the breach may have gone down, based on Microsoft’s own After Action Report. These details are not proven, but involve the most plausibly relevant bureaucratic movements, government personnel, and operational tactics.
Purpose
During the Summer of 2023, SVR Director Sergey Naryshkin attends a regular Security Council meeting and receives strategic objectives to help with the Ukraine effort. This may include:
- Intelligence on US DoD contractors’ efforts and technologies against Russia.
- Intelligence on US leadership for an influence campaign
- Intelligence on current US government technological infrastructure
Director Naryshkin takes these strategic objectives to his SVR leadership and they conclude that the most efficient and effective way to answer these questions is to gain intelligence from Microsoft. They know that most US federal government and even DoD infrastructure utilize Microsoft’s on-prem or Azure cloud services. Thus, instead of targeting each entity separately, they should target Microsoft’s communications to kill multiple birds with one stone. SVR leadership tasks its Foreign Counterintelligence Directorate and its Science & Technology Directorate to produce a task force aimed at breaching Microsoft’s internal communications for the above-mentioned objectives.
Fall of 2023, the Task Force produces a Plan of Attack. Winter of 2023-2024, the Team enacts the plan.
Reconnaissance (TA0043) and Resource Development (TA0042)
Task Force Team Leader (TL) distributes the following tasks for simultaneous completion:
- Operative Alpha to analyze past internal Microsoft compromises to compile a list of most commonly used administrative/service account usernames and passwords.
- Operative Bravo to reach out to the Operational Support Service to create a distributed proxy infrastructures.
- Operative Charlie to enumerate plausible internal Microsoft 365 tenant subdomains.
The OpSupport Service obtains operational funds to pay for a legitimate residential proxy service with dozens of addresses based in the US with Monero (XMR) cryptocurrency. OpSupport uses their own proxy/VPN via an Eastern European entity with a US server to purchase the residential proxies via AnyIP proxy service. OpSupport sends the proxy infrastructure information back over to Bravo. Bravo reports back to TL with infrastructure.
Alpha returns and reports with list of most commonly used usernames/passwords within past internal Microsoft environments.
Charlie writes a python script to check for tenant name availability (like the one below). Or uses https://o365.rocks/. Then inputs various test/staging environment names into the script to check for plausible testing/staging tenant names. If there is a hit, the operative then queries Google and Github for reference to this domain to see if there is a connection to internal Microsoft infrastructure.
import requests
import json
def check_tenant_name_availability(tenant_name, client_id, client_secret, tenant_id):
url = f"https://graph.microsoft.com/v1.0/domains/{tenant_name}.onmicrosoft.com"
# Obtain an access token using client credentials
token_url = f"https://login.microsoftonline.com/{tenant_id}/oauth2/v2.0/token"
token_data = {
'grant_type': 'client_credentials',
'client_id': client_id,
'client_secret': client_secret,
'scope': 'https://graph.microsoft.com/.default'
}
token_response = requests.post(token_url, data=token_data)
token = token_response.json().get('access_token')
if not token:
print("Failed to obtain access token")
return
headers = {
'Authorization': f'Bearer {token}'
}
response = requests.get(url, headers=headers)
if response.status_code == 404:
print(f"The tenant name '{tenant_name}' is available.")
elif response.status_code == 200:
print(f"The tenant name '{tenant_name}' is already taken.")
else:
print(f"An error occurred: {response.status_code}, {response.text}")
# Example usage
tenant_name = "exampletenantname"
client_id = "your_client_id"
client_secret = "your_client_secret"
tenant_id = "your_tenant_id"
check_tenant_name_availability(tenant_name, client_id, client_secret, tenant_id)
Initial Access (TA0001) and Credential Access (TA0006)
TL tasks Alpha to run a slow, password spray script on the plausible tenant domains, utilizing the proxy infrastructure and compiled credentials. After two weeks, Alpha receives a hit on prodstaging.microsoft.com with the username testdevadmin and password password123. Script output indicates that testdevadmin requires no MFA.
Alpha logs into portal.azure.com with these credentials and finds that the testdevadmin user has the Global Administrator Role. The operative then goes to “App registrations” to view connected OAuth apps. He finds a test OAuth app.


Alpha sees an OAuth app in this Test environment and views its supported account types.


Alpha sees that this app allows for multi-tenant account access — meaning that it can be accessed from both Production and Test Microsoft environments.
Discovery (TA0007) and Lateral Movement (TA0008)
Alpha pivots to production Microsoft environment and logs in to the Azure Portal using the same test tenant credentials and sends a request for the Test OAuth App. This provides a prompt for the test admin to approve it. Now this app has permissions within both the test and prod tenants.
With this foothold, the Threat Actors can add additional API permissions to create new users, create new apps, and to access all production mailboxes now that the app has access in the prod environment:
- full_access_as_app
- Directory.AccessAsUser.All
Mail.ReadWrite.All
- EWS.AccessAsUser.All