Recent Attacks In InfoSec News: Storm-0558 threat actor breached Microsoft Exchange accounts, affecting 25 organizations, including government agencies and related consumer accounts in the public cloud…
Let’s learn about what happened! According to BleepingComputer, “Threat Group Storm-0558 , believed to be a cyber-espionage outfit focused on collecting sensitive information by breaching email systems, has breached the email accounts of more than two dozen organizations worldwide, including U.S. and Western European government agencies, according to Microsoft.
Microsoft discovered that starting from May 15, 2023, Storm-0558 threat actors managed to access Outlook accounts belonging to roughly 25 organizations (reportedly including the U.S. State and Commerce Departments) and some consumer accounts likely connected to them. Microsoft investigations determined that Storm-0558 gained access to customer email accounts using Outlook Web Access in Exchange Online (OWA) and Outlook.com by forging authentication tokens to access user email,” Microsoft said in a blog post published late Tuesday evening.”
If you’re like me you’re curious about what specifically was done here, luckily for us Microsoft just published a new article on their security blog regarding an analysis of the attack. Let’s go through it step by step and try to gain some understanding.
Here’s some background on the threat actor, “Historically, this threat actor has displayed an interest in targeting media companies, think tanks, and telecommunications equipment and service providers. The objective of most Storm-0558 campaigns is to obtain unauthorized access to email accounts belonging to employees of targeted organizations. Storm-0558 pursues this objective through credential harvesting, phishing campaigns, and OAuth token attacks. This threat actor has displayed an interest in OAuth applications, token theft, and token replay against Microsoft accounts since at least August 2021. Storm-0558 operates with a high degree of technical tradecraft and operational security.”
Now, lets break some of this down: OAuth is a standard that apps can use to provide client applications with “secure delegated access”. OAuth works over HTTPS and authorizes devices, APIs, servers, and applications with access tokens rather than credentials. OAuth separates the role of the client from the resource owner. The client requests access to the resources controlled by the resource owner and hosted by the resource server. The resource server issues access tokens with the approval of the resource owner. The client uses the access tokens to access the protected resources hosted by the resource server.
According to Microsoft, “One of the most prevalent malware families used by Storm-0558 is a shared tool tracked by Microsoft as Cigril. This family exists in several variants and is launched using dynamic-link library (DLL) search order hijacking.”
DLL hijacking is very serious and one of the most common modern attack methods in a lot of recent major cyber-attacks. Arguably one of the most impactful (at least here in North America) was the attack on the US treasury and commerce departments. Remember the SolarWinds / SunBurst supply chain meltdown of 2020? Yea, that one.
Lets take a look at DLL search order hijacking and how it works. According to MITRE, “DLL Search Order Hijacking is when adversaries execute their own malicious payloads by hijacking the search order used to load DLLs. Windows systems use a common method to look for required DLLs to load into a program. Hijacking DLL loads may be for the purpose of establishing persistence as well as elevating privileges and/or evading restrictions on file execution.
Adversaries may plant trojan dynamic-link library files (DLLs) in a directory that will be searched before the location of a legitimate library that will be requested by a program, causing Windows to load their malicious library when it is called for by the victim program. Adversaries may also perform DLL preloading, also called binary planting attacks, by placing a malicious DLL with the same name as an ambiguously specified DLL in a location that Windows searches before the legitimate DLL”
If you’re curious how to identify a DLL hijacking attack with Process Explorer, take a look at this article by upgaurd.com, they have a really interesting section on it : https://www.upguard.com/blog/dll-hijacking. Lets move on with Microsoft’s analysis,
“After gaining access to a compromised system, Storm-0558 accesses credentials from a variety of sources, including the LSASS process memory and Security Account Manager (SAM) registry hive. Microsoft assesses that once Storm-0558 has access to the desired user credentials, the actor signs into the compromised user’s cloud email account with the valid account credentials. The actor then collects information from the email account over the web service.”
I’m sure you’re aware but let’s review Lsass.exe and SAM here, Lsass.exe the process that is responsible for enforcing the security policy on Windows systems. When a user attempts to logon to the system, this process verifies their log on attempt and creates access tokens based on the user’s permission levels. LSASS is also responsible for user account password changes. All events associated with this process) are logged within the Windows Security Log. Several tools exist to extract both cleartext and hashed credentials stored in memory by this process. SAM, the Security Accounts Manager is the service responsible for managing the database that contains the usernames and groups defined on the local machine. The SAM service, which implemented in Samsrv.dll, is loaded into the Lsass process.
On June 16, 2023, Microsoft determined that the threat actor was accessing the customers Exchange Online data using OWA. They found instead of stealing issued Azure AD tokens via malware on infected customer devices, the actors were utilizing Exchange Online authentication artifacts, which are typically derived from Azure AD authentication tokens (Azure AD tokens). Further in-depth analysis over the next several days led Microsoft analysts to assess that the internal Exchange Online authentication artifacts did not correspond to Azure AD tokens in Microsoft logs.
“Microsoft analysts began investigating the possibility that the actor was forging authentication tokens using an acquired Azure AD enterprise signing key. In-depth analysis of the Exchange Online activity discovered that in fact the actor was forging Azure AD tokens using an acquired Microsoft account (MSA) consumer signing key.”
This is a subtle but important difference between an authentication token using an acquired Azure AD enterprise signing key and an Azure AD token using an acquired Microsoft account (MSA) consumer signing key, an authentication token using an acquired Azure AD enterprise signing key is used for enterprise applications such as Azure Integration Services, Azure Logic Apps, and Azure API Management for example. It is used to authenticate users and grant them access to resources in the enterprise environment.
On the other hand, as far as I understand it, an Azure AD token using an acquired Microsoft account (MSA) consumer signing key is used for consumer applications that are integrated with Azure AD, like Xbox, outlook.com, social media apps, productivity tools, etc (outlook OWA specifically in this instance). The MSA keys are therefore the token signing keys used by that service to validate authentication tokens for those services. The token is signed with a consumer signing key that is acquired from Microsoft account.
According to Microsoft,
“Storm-0558 acquired an inactive MSA consumer signing key and used it to forge authentication tokens for Azure AD enterprise and MSA consumer to access OWA and Outlook.com. All MSA keys active prior to the incident — including the actor-acquired MSA signing key — have been invalidated. Azure AD keys were not impacted. The method by which the actor acquired the key is a matter of ongoing investigation.”
Microsoft claims they have “substantially hardened key issuance systems” and “revoked all previously active keys and issued new keys using these updated systems”. Microsoft goes into more specific detail as to how this attack was carried out.
“Once authenticated through a legitimate client flow leveraging the forged token, the threat actor accessed the OWA API to retrieve a token for Exchange Online from the GetAccessTokenForResource API used by OWA. The actor was able to obtain new access tokens by presenting one previously issued from this API due to a design flaw. This flaw in the GetAccessTokenForResourceAPI has since been fixed to only accept tokens issued from Azure AD or MSA respectively. The actor used these tokens to retrieve mail messages from the OWA API.”
What’s particularly interesting is the Actor tooling section of this article in which they go into further detail,
“Storm-0558 uses a collection of PowerShell and Python scripts to perform REST API calls against the OWA Exchange Store service. For example, Storm-0558 has the capability to use minted access tokens to extract email data such as downloaded emails, downloaded attachments, locate and downloads convos, and get email folder info.
The generated web requests can be routed through a Tor proxy or several hardcoded SOCKS5 proxy servers. The threat actor was observed using several User-Agents when issuing web requests”
The scripts contain highly sensitive hardcoded information such as bearer access tokens and email data, which the threat actor uses to perform the OWA API calls. The threat actor has the capability to refresh the access token for use in subsequent OWA commands.
A lot to dig into here, there’s some additional pieces in the article which I’ll leave out here, but check it out if you want to dig further into the specifics: https://www.microsoft.com/en-us/security/blog/2023/07/14/analysis-of-storm-0558-techniques-for-unauthorized-email-access/
Ref:
3. Advanced certificate signing options in a SAML token — Microsoft Entra | Microsoft Learn
4. Azure AD — Differentiate between App token and User token — Stack Overflow
