Legitimate hosting services, such as SharePoint, OneDrive, and Dropbox, are widely used by organizations for storing, sharing, and collaborating on files. However, the widespread use of such services also makes them attractive targets for threat actors, who exploit the trust and familiarity associated with these services to deliver malicious files and links, often avoiding detection by traditional security measures.

Importantly, Microsoft takes action against malicious users violating the Microsoft Services Agreement in how they use apps like SharePoint and OneDrive. To help protect enterprise accounts from compromise, by default both Microsoft 365 and Office 365 support multi-factor authentication (MFA) and passwordless sign-in. Consumers can also go passwordless with their Microsoft account. Because security is a team sport, Microsoft also works with third parties like Dropbox to share threat intelligence and protect mutual customers and the wider community.

In this blog, we discuss the typical attack chain used in campaigns misusing file hosting services and detail the recently observed tactics, techniques, and procedures (TTPs), including the increasing use of certain defense evasion tactics. To help defenders protect their identities and data, we also share mitigation guidance to help reduce the impact of this threat, and detection details and hunting queries to locate potential misuse of file hosting services and related threat actor activities. By understanding these evolving threats and implementing the recommended mitigations, organizations can better protect themselves against these sophisticated campaigns and safeguard digital assets.

Attack overview

Phishing campaigns exploiting legitimate file hosting services have been trending throughout the last few years, especially due to the relative ease of the technique. The files are delivered through different approaches, including email and email attachments like PDFs, OneNote, and Word files, with the intent of compromising identities or devices. These campaigns are different from traditional phishing attacks because of the sophisticated defense evasion techniques used.

Since mid-April 2024, we observed threat actors increasingly use these tactics aimed at circumventing defense mechanisms:

• Files with restricted access: The files sent through the phishing emails are configured to be accessible solely to the designated recipient. This requires the recipient to be signed in to the file-sharing service—be it Dropbox, OneDrive, or SharePoint—or to re-authenticate by entering their email address along with a one-time password (OTP) received through a notification service.
• Files with view-only restrictions: To bypass analysis by email detonation systems, the files shared in these phishing attacks are set to ‘view-only’ mode, disabling the ability to download and consequently, the detection of embedded URLs within the file.

An example attack chain is provided below, depicting the updated defense evasion techniques being used across stages 4, 5, and 6:

Initial access

The attack typically begins with the compromise of a user within a trusted vendor. After compromising the trusted vendor, the threat actor hosts a file on the vendor’s file hosting service, which is then shared with a target organization. This misuse of legitimate file hosting services is particularly effective because recipients are more likely to trust emails from known vendors, allowing threat actors to bypass security measures and compromise identities. Often, users from trusted vendors are added to allow lists through policies set by the organization on Exchange Online products, enabling phishing emails to be successfully delivered.

While file names observed in these campaigns also included the recipients, the hosted files typically follow these patterns:

• Familiar topics based on existing conversations
  • For example, if the two organizations have prior interactions related to an audit, the shared files could be named “Audit Report 2024”.
• Familiar topics based on current context
  • If the attack has not originated from a trusted vendor, the threat actor often impersonates administrators or help desk or IT support personnel in the sender display name and uses a file name such as “IT Filing Support 2024”, “Forms related to Tax submission”, or “Troubleshooting guidelines”.
• Topics based on urgency
  • Another common technique observed by the threat actors creating these files is that they create a sense of urgency with the file names like “Urgent:Attention Required” and “Compromised Password Reset”.

Defense evasion techniques

Once the threat actor shares the files on the file hosting service with the intended users, the file hosting service sends the target user an automated email notification with a link to access the file securely. This email is not a phishing email but a notification for the user about the sharing action. In scenarios involving SharePoint or OneDrive, the file is shared from the user’s context, with the compromised user’s email address as the sender. However, in the Dropbox scenario, the file is shared from no-reply@dropbox[.]com. The files are shared through automated notification emails with the subject: “<User> shared <document> with you”. To evade detections, the threat actor deploys the following additional techniques:

• Only the intended recipient can access the file
  • The intended recipient needs to re-authenticate before accessing the file
  • The file is accessible only for a limited time window
• The PDF shared in the file cannot be downloaded

These techniques make detonation and analysis of the sample with the malicious link almost impossible since they are restricted.

Identity compromise

When the targeted user accesses the shared file, the user is prompted to verify their identity by providing their email address:

Next, an OTP is sent from no-reply@notify.microsoft[.]com. Once the OTP is submitted, the user is successfully authorized and can view a document, often masquerading as a preview, with a malicious link, which is another lure to make the targeted user click the “View my message” access link.

This link redirects the user to an adversary-in-the-middle (AiTM) phishing page, where the user is prompted to provide the password and complete multifactor authentication (MFA). The compromised token can then be leveraged by the threat actor to perform the second stage BEC attack and continue the campaign.

Recommended actions

Microsoft recommends the following mitigations to reduce the impact of this threat:

• Enable Conditional Access policies in Microsoft Entra, especially risk-based access policies. Conditional access policies evaluate sign-in requests using additional identity-driven signals like user or group membership, IP address location information, and device status, among others, are enforced for suspicious sign-ins. Organizations can protect themselves from attacks that leverage stolen credentials by enabling policies such as compliant devices, Azure trusted IP address requirements, or risk-based policies with proper access control. If you are still evaluating Conditional Access, use security defaults as an initial baseline set of policies to improve identity security posture.
• Implement continuous access evaluation.
• Implement Microsoft Entra passwordless sign-in with FIDO2 security keys.
• Turn on network protection in Microsoft Defender for Endpoint to block connections to malicious domains and IP addresses.
• Implement Microsoft Defender for Endpoint – Mobile Threat Defense on mobile devices used to access enterprise assets.
• Leverage Microsoft Edge to automatically identify and block malicious websites, including those used in this phishing campaign, and Microsoft Defender for Office 365 to detect and block malicious emails, links, and files. Monitor suspicious or anomalous activities in Microsoft Entra ID Protection. Investigate sign-in attempts with suspicious characteristics (such as the location, ISP, user agent, and use of anonymizer services). Educate users about the risks of secure file sharing and emails from trusted vendors.

Appendix

Microsoft Defender XDR detections

Microsoft Defender XDR raises the following alerts by combining Microsoft Defender for Office 365 URL click and Microsoft Entra ID Protection risky sign-ins signal.

• Risky sign-in after clicking a possible AiTM phishing URL
• User compromised through session cookie hijack
• User compromised in a known AiTM phishing kit

Hunting queries

Microsoft Defender XDR 

The file sharing events related to the activity in this blog post can be audited through the CloudAppEvents telemetry. Microsoft Defender XDR customers can run the following query to find related activity in their networks: 

Automated email notifications and suspicious sign-in activity

By correlating the email from the Microsoft notification service or Dropbox automated notification service with a suspicious sign-in activity, we can identify compromises, especially from securely shared SharePoint or Dropbox files.

let usersWithSuspiciousEmails = EmailEvents
    | where SenderFromAddress in ("no-reply@notify.microsoft.com", "no-reply@dropbox.com") or InternetMessageId startswith "<OneTimePasscode"
    | where isnotempty(RecipientObjectId)
    | distinct RecipientObjectId;
AADSignInEventsBeta
| where AccountObjectId in (usersWithSuspiciousEmails)
| where RiskLevelDuringSignIn == 100

Files share contents and suspicious sign-in activity

In the majority of the campaigns, the file name involves a sense of urgency or content related to finance or credential updates. By correlating the file share emails with suspicious sign-ins, compromises can be detected. (For example: Alex shared “Password Reset Mandatory.pdf” with you). Since these are observed as campaigns, validating that the same file has been shared with multiple users in the organization can support the detection.

let usersWithSuspiciousEmails = EmailEvents
    | where Subject has_all ("shared", "with you")
    | where Subject has_any ("payment", "invoice", "urgent", "mandatory", "Payoff", "Wire", "Confirmation", "password")
    | where isnotempty(RecipientObjectId)
    | summarize RecipientCount = dcount(RecipientObjectId), RecipientList = make_set(RecipientObjectId) by Subject
    | where RecipientCount >= 10
    | mv-expand RecipientList to typeof(string)
    | distinct RecipientList;
AADSignInEventsBeta
| where AccountObjectId in (usersWithSuspiciousEmails)
| where RiskLevelDuringSignIn == 100

BEC: File sharing tactics based on the file hosting service used

To initiate the file sharing activity, these campaigns commonly use certain action types depending on the file hosting service being leveraged. Below are the action types from the audit logs recorded for the file sharing events. These action types can be used to hunt for activities related to these campaigns by replacing the action type for its respective application in the queries below this table.

OneDrive or SharePoint: The following query highlights that a specific file has been shared by a user with multiple participants. Correlating this activity with suspicious sign-in attempts preceding this can help identify lateral movements and BEC attacks.

let securelinkCreated = CloudAppEvents
    | where ActionType == "SecureLinkCreated"
    | project FileCreatedTime = Timestamp, AccountObjectId, ObjectName;
let filesCreated = securelinkCreated
    | where isnotempty(ObjectName)
    | distinct tostring(ObjectName);
CloudAppEvents
| where ActionType == "AddedToSecureLink"
| where Application in ("Microsoft SharePoint Online", "Microsoft OneDrive for Business")
| extend FileShared = tostring(RawEventData.ObjectId)
| where FileShared in (filesCreated)
| extend UserSharedWith = tostring(RawEventData.TargetUserOrGroupName)
| extend TypeofUserSharedWith = RawEventData.TargetUserOrGroupType
| where TypeofUserSharedWith == "Guest"
| where isnotempty(FileShared) and isnotempty(UserSharedWith)
| join kind=inner securelinkCreated on $left.FileShared==$right.ObjectName
// Secure file created recently (in the last 1day)
| where (Timestamp - FileCreatedTime) between (1d .. 0h)
| summarize NumofUsersSharedWith = dcount(UserSharedWith) by FileShared
| where NumofUsersSharedWith >= 20

Dropbox: The following query highlights that a file hosted on Dropbox has been shared with multiple participants.

CloudAppEvents
| where ActionType in ("Added users and/or groups to shared file/folder", "Invited user to Dropbox and added them to shared file/folder")
| where Application == "Dropbox"
| where ObjectType == "File"
| extend FileShared = tostring(ObjectName)
| where isnotempty(FileShared)
| mv-expand ActivityObjects
| where ActivityObjects.Type == "Account" and ActivityObjects.Role == "To"
| extend SharedBy = AccountId
| extend UserSharedWith = tostring(ActivityObjects.Name)
| summarize dcount(UserSharedWith) by FileShared, AccountObjectId
| where dcount_UserSharedWith >= 20

Microsoft Sentinel

Microsoft Sentinel customers can use the resources below to find related activities similar to those described in this post:

The following query identifies files with specific keywords that attackers might use in this campaign that have been shared through OneDrive or SharePoint using a Secure Link and accessed by over 10 unique users. It captures crucial details like target users, client IP addresses, timestamps, and file URLs to aid in detecting potential attacks:

let OperationName = dynamic(['SecureLinkCreated', 'AddedToSecureLink']);
OfficeActivity
| where Operation in (OperationName)
| where OfficeWorkload in ('OneDrive', 'SharePoint')
| where SourceFileName has_any ("payment", "invoice", "urgent", "mandatory", "Payoff", "Wire", "Confirmation", "password", "paycheck", "bank statement", "bank details", "closing", "funds", "bank account", "account details", "remittance", "deposit", "Reset")
| summarize CountOfShares = dcount(TargetUserOrGroupName), 
            make_list(TargetUserOrGroupName), 
            make_list(ClientIP), 
            make_list(TimeGenerated), 
            make_list(SourceRelativeUrl) by SourceFileName, OfficeWorkload
| where CountOfShares > 10

Considering that the attacker compromises users through AiTM,  possible AiTM phishing attempts can be detected through the below rule:

• Possible AiTM Phishing Attempt

In addition, customers can also use the following identity-focused queries to detect and investigate anomalous sign-in events that may be indicative of a compromised user identity being accessed by a threat actor:

• Signins From VPS Providers
• Signins from Nord VPN Providers
• Successful Signin From Non-Compliant Device

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn at https://www.linkedin.com/showcase/microsoft-threat-intelligence, and on X (formerly Twitter) at https://twitter.com/MsftSecIntel.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast: https://thecyberwire.com/podcasts/microsoft-threat-intelligence.

The post File hosting services misused for identity phishing appeared first on Microsoft Security Blog.

Octo Tempest is a financially motivated collective of native English-speaking threat actors known for launching wide-ranging campaigns that prominently feature adversary-in-the-middle (AiTM) techniques, social engineering, and SIM swapping capabilities. Octo Tempest, which overlaps with research associated with 0ktapus, Scattered Spider, and UNC3944, was initially seen in early 2022, targeting mobile telecommunications and business process outsourcing organizations to initiate phone number ports (also known as SIM swaps). Octo Tempest monetized their intrusions in 2022 by selling SIM swaps to other criminals and performing account takeovers of high-net-worth individuals to steal their cryptocurrency.

Building on their initial success, Octo Tempest harnessed their experience and acquired data to progressively advance their motives, targeting, and techniques, adopting an increasingly aggressive approach. In late 2022 to early 2023, Octo Tempest expanded their targeting to include cable telecommunications, email, and technology organizations. During this period, Octo Tempest started monetizing intrusions by extorting victim organizations for data stolen during their intrusion operations and in some cases even resorting to physical threats.

In mid-2023, Octo Tempest became an affiliate of ALPHV/BlackCat, a human-operated ransomware as a service (RaaS) operation, and initial victims were extorted for data theft (with no ransomware deployment) using ALPHV Collections leak site. This is notable in that, historically, Eastern European ransomware groups refused to do business with native English-speaking criminals. By June 2023, Octo Tempest started deploying ALPHV/BlackCat ransomware payloads (both Windows and Linux versions) to victims and lately has focused their deployments primarily on VMWare ESXi servers. Octo Tempest progressively broadened the scope of industries targeted for extortion, including natural resources, gaming, hospitality, consumer products, retail, managed service providers, manufacturing, law, technology, and financial services.  

In recent campaigns, we observed Octo Tempest leverage a diverse array of TTPs to navigate complex hybrid environments, exfiltrate sensitive data, and encrypt data. Octo Tempest leverages tradecraft that many organizations don’t have in their typical threat models, such as SMS phishing, SIM swapping, and advanced social engineering techniques. This blog post aims to provide organizations with an insight into Octo Tempest’s tradecraft by detailing the fluidity of their operations and to offer organizations defensive mechanisms to thwart the highly motivated financial cybercriminal group.

Analysis 

The well-organized, prolific nature of Octo Tempest’s attacks is indicative of extensive technical depth and multiple hands-on-keyboard operators. The succeeding sections cover the wide range of TTPs we observed being used by Octo Tempest.

Initial access 

Social engineering with a twist

Octo Tempest commonly launches social engineering attacks targeting technical administrators, such as support and help desk personnel, who have permissions that could enable the threat actor to gain initial access to accounts. The threat actor performs research on the organization and identifies targets to effectively impersonate victims, mimicking idiolect on phone calls and understanding personal identifiable information to trick technical administrators into performing password resets and resetting multifactor authentication (MFA) methods. Octo Tempest has also been observed impersonating newly hired employees in these attempts to blend into normal on-hire processes.

Octo Tempest primarily gains initial access to an organization using one of several methods:

• Social engineering
  • Calling an employee and socially engineering the user to either:
    • Install a Remote Monitoring and Management (RMM) utility
    • Navigate to a site configured with a fake login portal using an adversary-in-the-middle toolkit
    • Remove their FIDO2 token
  • Calling an organization’s help desk and socially engineering the help desk to reset the user’s password and/or change/add a multi-factor authentication token/factor
• Purchasing an employee’s credentials and/or session token(s) on a criminal underground market
• SMS phishing employee phone numbers with a link to a site configured with a fake login portal using an adversary-in-the-middle toolkit
• Using the employee’s pre-existing access to mobile telecommunications and business process outsourcing organizations to initiate a SIM swap or to set up call number forwarding on an employee’s phone number. Octo Tempest will initiate a self-service password reset of the user’s account once they have gained control of the employee’s phone number.

In rare instances, Octo Tempest resorts to fear-mongering tactics, targeting specific individuals through phone calls and texts. These actors use personal information, such as home addresses and family names, along with physical threats to coerce victims into sharing credentials for corporate access.

Reconnaissance and discovery 

Crossing borders for identity, architecture, and controls enumeration

In the early stage of their attacks, Octo Tempest performs various enumeration and information gathering actions to pursue advanced access in targeted environments and abuses legitimate channels for follow-on actions later in the attack sequence. Initial bulk-export of users, groups, and device information is closely followed by enumerating data and resources readily available to the user’s profile within virtual desktop infrastructure or enterprise-hosted resources. 

Frequently, Octo Tempest uses their access to carry out broad searches across knowledge repositories to identify documents related to network architecture, employee onboarding, remote access methods, password policies, and credential vaults.

Octo Tempest then performs exploration through multi-cloud environments enumerating access and resources across cloud environments, code repositories, server and backup management infrastructure, and others. In this stage, the threat actor validates access, enumerates databases and storage containers, and plans footholds to aid further phases of the attack.

Additional tradecraft and techniques:

• PingCastle and ADRecon to perform reconnaissance of Active Directory 
• Advanced IP Scanner to probe victim networks
• Govmomi Go library to enumerate vCenter APIs 
• PureStorage FlashArray PowerShell module to enumerate storage arrays 
• AAD bulk downloads of user, groups, and devices

Privilege escalation and credential access

Octo Tempest commonly elevates their privileges within an organization through the following techniques:

• Using their pre-existing access to mobile telecommunications and business process outsourcing organizations to initiate a SIM swap or to set up call number forwarding on an employee’s phone number. Octo Tempest will initiate a self-service password reset of the user’s account once they have gained control of the employee’s phone number.
• Social engineering – calling an organization’s help desk and socially engineering the help desk to reset an administrator’s password and/or change/add a multi-factor authentication token/factor

Further masquerading and collection for escalation

Octo Tempest employs an advanced social engineering strategy for privilege escalation, harnessing stolen password policy procedures, bulk downloads of user, group, and role exports, and their familiarity with the target organizations procedures. The actor’s privilege escalation tactics often rely on building trust through various means, such as leveraging possession of compromised accounts and demonstrating an understanding of the organization’s procedures. In some cases, they go as far as bypassing password reset procedures by using a compromised manager’s account to approve their requests.

Octo Tempest continually seeks to collect additional credentials across all planes of access. Using open-source tooling like Jercretz and TruffleHog, the threat actor automates the identification of plaintext keys, secrets, and credentials across code repositories for further use.

Additional tradecraft and techniques:

• Modifying access policies or using MicroBurst to gain access to credential stores
• Using open-source tooling: Mimikatz, Hekatomb, Lazagne, gosecretsdump, smbpasswd.py, LinPEAS, ADFSDump
• Using VMAccess Extension to reset passwords or modify configurations of Azure VMs
• Creating snapshots virtual domain controller disks to download and extract NTDS.dit
• Assignment of User Access Administrator role to grant Tenant Root Group management scope

Defense evasion

Security product arsenal sabotage

Octo Tempest compromises security personnel accounts within victim organizations to turn off security products and features and attempt to evade detection throughout their compromise. Using compromised accounts, the threat actor leverages EDR and device management technologies to allow malicious tooling, deploy RMM software, remove or impair security products, data theft of sensitive files (e.g. files with credentials, signal messaging databases, etc.), and deploy malicious payloads.

To prevent identification of security product manipulation and suppress alerts or notifications of changes, Octo Tempest modifies the security staff mailbox rules to automatically delete emails from vendors that may raise the target’s suspicion of their activities.

Additional tradecraft and techniques:

• Using open-source tooling like privacy.sexy framework to disable security products
• Enrolling actor-controlled devices into device management software to bypass controls
• Configuring trusted locations in Conditional Access Policies to expand access capabilities
• Replaying harvested tokens with satisfied MFA claims to bypass MFA

Persistence 

Sustained intrusion with identities and open-source tools

Octo Tempest leverages publicly available security tools to establish persistence within victim organizations, largely using account manipulation techniques and implants on hosts. For identity-based persistence, Octo Tempest targets federated identity providers using tools like AADInternals to federate existing domains, or spoof legitimate domains by adding and then federating new domains. The threat actor then abuses this federation to generate forged valid security assertion markup language (SAML) tokens for any user of the target tenant with claims that have MFA satisfied, a technique known as Golden SAML. Similar techniques have also been observed using Okta as their source of truth identity provider, leveraging Okta Org2Org functionality to impersonate any desired user account.

To maintain access to endpoints, Octo Tempest installs a wide array of legitimate RMM tools and makes required network modifications to enable access. The usage of reverse shells is seen across Octo Tempest intrusions on both Windows and Linux endpoints. These reverse shells commonly initiate connections to the same attacker infrastructure that deployed the RMM tools.

A unique technique Octo Tempest uses is compromising VMware ESXi infrastructure, installing the open-source Linux backdoor Bedevil, and then launching VMware Python scripts to run arbitrary commands against housed virtual machines.

Additional tradecraft and techniques:

• Usage of open-source tooling: ScreenConnect, FleetDeck, AnyDesk, RustDesk, Splashtop, Pulseway, TightVNC, LummaC2, Level.io, Mesh, TacticalRMM, Tailscale, Ngrok, WsTunnel, Rsocx, and Socat
• Deployment of Azure virtual machines to enable remote access via RMM installation or modification to existing resources via Azure serial console
• Addition of MFA methods to existing users
• Usage of the third-party tunneling tool Twingate, which leverages Azure Container instances as a private connector (without public network exposure)

Actions on objectives

Common trifecta: Data theft, extortion, and ransomware

The goal of Octo Tempest remains financially motivated, but the monetization techniques observed across industries vary between cryptocurrency theft and data exfiltration for extortion and ransomware deployment.

Like in most cyberattacks, data theft largely depends on the data readily available to the threat actor. Octo Tempest accesses data from code repositories, large document management and storage systems, including SharePoint, SQL databases, cloud storage blobs/buckets, and email, using legitimate management clients such as DBeaver, MongoDB Compass, Azure SQL Query Editor, and Cerebrata for the purpose of connection and collection. After data harvesting, the threat actor employs anonymous file-hosting services, including GoFile.io, shz.al, StorjShare, Temp.sh, MegaSync, Paste.ee, Backblaze, and AWS S3 buckets for data exfiltration.

Octo Tempest employs a unique technique using the data movement platform Azure Data Factory and automated pipelines to extract data to external actor hosted Secure File Transfer Protocol (SFTP) servers, aiming to blend in with typical big data operations. Additionally, the threat actor commonly registers legitimate Microsoft 365 backup solutions such as Veeam, AFI Backup, and CommVault to export the contents of SharePoint document libraries and expedite data exfiltration.

Ransomware deployment closely follows data theft objectives. This activity targets both Windows and Unix/Linux endpoints and VMware hypervisors using a variant of ALPHV/BlackCat. Encryption at the hypervisor level has shown significant impact to organizations, making recovery efforts difficult post-encryption.

Octo Tempest frequently communicates with target organizations and their personnel directly after encryption to negotiate or extort the ransom—providing “proof of life” through samples of exfiltrated data. Many of these communications have been leaked publicly, causing significant reputational damage to affected organizations.

Additional tradecraft and techniques:

• Use of the third-party services like FiveTran to extract copies of high-value service databases, such as SalesForce and ZenDesk, using API connectors
• Exfiltration of mailbox PST files and mail forwarding to external mailboxes

Recommendations

Hunting methodology

Octo Tempest’s utilization of social engineering, living-off-the land techniques, and diverse toolsets could make hunting slightly unorthodox. Following these general guidelines alongside robust deconfliction with legitimate users will surface their activity:

Identity

• Understand authentication flows in the environment.
• Centralize visibility of administrative changes in the environment into a single pane of glass.
• Scrutinize all user and sign-in risk detections for any administrator within the timeframe. Common alerts that are surfaced during an Octo Tempest intrusion include (but not limited to): Impossible Travel, Unfamiliar Sign-in Properties, and Anomalous Token
• Review the coverage of Conditional Access policies; scrutinize the use of trusted locations and exclusions.
• Review all existing and new custom domains in the tenant, and their federation settings.
• Scrutinize administrator groups, roles, and privileges for recent modification.
• Review recently created Microsoft Entra ID users and registered device identities.
• Look for any anomalous pivots into organizational apps that may hold sensitive data, such as Microsoft SharePoint and OneDrive.

Azure

• Leverage and continuously monitor Defender for Cloud for Azure Workloads, providing a wealth of information around unauthorized resource access.
• Review Azure role-based access control (RBAC) definitions across the management group, subscription, resource group and resource structure.
• Review the public network exposure of resources and revoke any unauthorized modifications.
• Review both data plane and management plane access control for all critical workloads such as those that hold credentials and organizational data, like Key Vaults, storage accounts, and database resources.
• Tightly control access to identity workloads that issue access organizational resources such as Active Directory Domain Controllers.
• Review the Azure Activity log for anomalous modification of resources.

Endpoints

• Look for recent additions to the indicators or exclusions of the EDR solution in place at the organization.
• Review any generation of offboarding scripts.
• Review access control within security products and EDR software suites.
• Scrutinize any tools used to manage endpoints (SCCM, Intune, etc.) and look for recent rule additions, packages, or deployments.
• Scrutinize use of remote administration tools across the environment, paying particular attention to recent installations regardless of whether they are used legitimately within the network already.
• Ensure monitoring at the network boundary is in place, that alerting is in place for connections with common anonymizing services and scrutinize the use of these services.

Defending against Octo Tempest activity

Align privilege in Microsoft Entra ID and Azure

Privileges spanning Microsoft Entra ID and Azure need to be holistically aligned, with purposeful design decisions to prevent unauthorized access to critical workloads. Reducing the number of users with permanently assigned critical roles is paramount to achieving this. Segregation of privilege between on-premises and cloud is also necessary to sever the ability to pivot within the environment.

It is highly recommended to implement Microsoft Entra Privileged Identity Management (PIM) as a central location for the management of both Microsoft Entra ID roles and Azure RBAC. For all critical roles, at minimum:

• Implement role assignments as eligible rather than permanent.
• Review and understand the role definition Actions and NotActions – ensure to select only the roles with actions that the user requires to do their role (least privileged access).
• Configure these roles to be time-bound, deactivating after a specific timeframe.
• Require users to perform MFA to elevate to the role.
• Optionally require users to provide justification or a ticket number upon elevation.
• Enable notifications for privileged role elevation to a subset of administrators.
• Utilize PIM Access Reviews to reduce standing access in the organization on a periodic basis.

Every organization is different and, therefore, roles will be classified differently in terms of their criticality. Consider the scope of impact those roles may have on downstream resources, services, or identities in the event of compromise. For help desk administrators specifically, ensure to scope privilege to exclude administrative operations over Global Administrators. Consider implementing segregation strategies such as Microsoft Entra ID Administrative Units to segment administrative access over the tenant. For identities that leverage cross-service roles such as those that service the Microsoft Security Stack, consider implementing additional service-based granular access control to restrict the use of sensitive functionality, like Live Response and modification of IOC allow lists.

Segment Azure landing zones

For organizations yet to begin or are early in their modernization journey, end-to-end guidance for cloud adoption is available through the Microsoft Azure Cloud Adoption Framework. Recommended practice and security are central pillars—Azure workloads are segregated into separate, tightly restricted areas known as landing zones. When deploying Active Directory in the cloud, it is advised to create a platform landing zone for identity—a dedicated subscription to hold all Identity-related resources such as Domain Controller VM resources. Employ least privilege across this landing zone with the aforementioned privilege and PIM guidance for Azure RBAC.

Implement Conditional Access policies and authentication methods

TTPs outlined in this blog leverage strategies to evade multifactor authentication defenses. However, it is still strongly recommended to practice basic security hygiene by implementing a baseline set of Conditional Access policies:

• Require multifactor authentication for all privileged roles with the use of authentication strengths to enforce phish-resistant MFA methods such as FIDO2 security keys
• Require phishing-resistant multifactor authentication for administrators
• Enforce MFA registration from trusted locations from a device that also meets organizational requirements with Intune device compliance policies
• User and sign-in risk policies for signals associated to Microsoft Entra ID Protection

Organizations are recommended to keep their policies as simple as possible. Implementing complex policies might inhibit the ability to respond to threats at a rapid pace or allow threat actors to leverage misconfigurations within the environment.

Develop and maintain a user education strategy

An organization’s ability to protect itself against cyberattacks is only as strong as its people—it is imperative to put in place an end-to-end cybersecurity strategy highlighting the importance of ongoing user education and awareness. Targeted education and periodic security awareness campaigns around common cyber threats and attack vectors such as phishing and social engineering not only for users that hold administrative privilege in the organization, but the wider user base is crucial. A well-maintained incident response plan should be developed and refined to enable organizations to respond to unexpected cybersecurity events and rapidly regain positive control.

Use out-of-band communication channels

Octo Tempest has been observed joining, recording, and transcribing calls using tools such as OtterAI, and sending messages via Slack, Zoom, and Microsoft Teams, taunting and threatening targets, organizations, defenders, and gaining insights into incident response operations/planning. Using out-of-band communication channels is strongly encouraged when dealing with this threat actor.

Detections

Microsoft 365 Defender

Microsoft 365 Defender is becoming Microsoft Defender XDR. Learn more.

NOTE: Several tools mentioned throughout this blog are remote administrator tools that have been utilized by Octo Tempest to maintain persistence. While these tools are abused by threat actors, they can have legitimate use cases by normal users, and are updated on a frequent basis. Microsoft recommends monitoring their use within the environment, and when they are identified, defenders take the necessary steps for deconfliction to verify their use.

Microsoft Defender Antivirus

Microsoft Defender Antivirus detects this threat as the following malware:

• HackTool:Win32/Mimikatz
• HackTool:Win64/Mimikatz
• Behavior:Win32/BlackCatExec
• Ransom:Win32/Blackcat
• Ransom:Linux/BlackCat
• Behavior:Win32/BlackCat
• Ransom:Win64/BlackCat

Turning on tamper protection, which is part of built-in protection, prevents attackers from stopping security services.

Microsoft Defender for Endpoint

The following Microsoft Defender for Endpoint alerts can indicate associated threat activity:

• Octo Tempest activity group

The following alerts might also indicate threat activity related to this threat. Note, however, that these alerts can also be triggered by unrelated threat activity.

• Suspicious usage of remote management software
• Mimikatz credential theft tool
• BlackCat ransomware
• Activity linked to BlackCat ransomware
• Tampering activity typical to ransomware attacks
• Possible hands-on-keyboard pre-ransom activity

Microsoft Defender for Cloud Apps

Using Microsoft Defender for Cloud Apps connectors, Microsoft 365 Defender raises AitM-related alerts in multiple scenarios. For Microsoft Entra ID customers using Microsoft Edge, attempts by attackers to replay session cookies to access cloud applications are detected by Microsoft 365 Defender through Defender for Cloud Apps connectors for Microsoft Office 365 and Azure. In such scenarios, Microsoft 365 Defender raises the following alerts:

• Backdoor creation using AADInternals tool
• Suspicious domain added to Microsoft Entra ID
• Suspicious domain trust modification following risky sign-in
• User compromised via a known AitM phishing kit
• User compromised in AiTM phishing attack
• Suspicious email deletion activity

Similarly, the connector for Okta raises the following alerts:

• Suspicious Okta account enumeration
• Possible AiTM phishing attempt in Okta

Microsoft Defender for Identity

Microsoft Defender for Identity raises the following alerts for TTPs used by Octo Tempest such as NTDS stealing and Active Directory reconnaissance:

• Account enumeration reconnaissance
• Network-mapping reconnaissance (DNS)
• User and IP address reconnaissance (SMB)
• User and Group membership reconnaissance (SAMR)
• Suspected DCSync attack (replication of directory services)
• Suspected AD FS DKM key read
• Data exfiltration over SMB

Microsoft Defender for Cloud

The following Microsoft Defender for Cloud alerts relate to TTPs used by Octo Tempest. Note, however, that these alerts can also be triggered by unrelated threat activity.

• MicroBurst exploitation toolkit used to enumerate resources in your subscriptions
• MicroBurst exploitation toolkit used to execute code on your virtual machine
• MicroBurst exploitation toolkit used to extract keys from your Azure key vaults
• MicroBurst exploitation toolkit used to extract keys to your storage accounts
• Suspicious Azure role assignment detected
• Suspicious elevate access operation (Preview)
• Suspicious invocation of a high-risk ‘Initial Access’ operation detected (Preview)
• Suspicious invocation of a high-risk ‘Credential Access’ operation detected (Preview)
• Suspicious invocation of a high-risk ‘Data Collection’ operation detected (Preview)
• Suspicious invocation of a high-risk ‘Execution’ operation detected (Preview)
• Suspicious invocation of a high-risk ‘Impact’ operation detected (Preview)
• Suspicious invocation of a high-risk ‘Lateral Movement’ operation detected (Preview)
• Unusual user password reset in your virtual machine
• Suspicious usage of VMAccess extension was detected on your virtual machines (Preview)
• Suspicious usage of multiple monitoring or data collection extensions was detected on your virtual machines (Preview)
• Run Command with a suspicious script was detected on your virtual machine (Preview)
• Suspicious Run Command usage was detected on your virtual machine (Preview)
• Suspicious unauthorized Run Command usage was detected on your virtual machine (Preview)

Microsoft Sentinel

Microsoft Sentinel customers can use the following Microsoft Sentinel Analytics template to identify potential AitM phishing attempts:

• Possible AitM Phishing Attempt Against Azure AD

This detection uses signals from Microsoft Entra ID Identity Protection and looks for successful sign-ins that have been flagged as high risk. It combines this with data from web proxy services, such as ZScaler, to identify where users might have connected to the source of those sign-ins immediately prior. This can indicate a user interacting with an AitM phishing site and having their session hijacked. This detection uses the Advanced Security Information Model (ASIM) Web Session schema. Refer to this article for more details on the schema and its requirements. 

Threat intelligence reports

Microsoft customers can use the following reports in Microsoft products to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection info, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

Microsoft Defender Threat Intelligence

• Octo Tempest
• Octo Tempest uses social engineering and AADInternals to compromise cloud identities

Microsoft 365 Defender Threat analytics  

• Actor profile: Octo Tempest
• Threat insights: Octo Tempest uses social engineering and AADInternals to compromise cloud identities

Hunting queries

Microsoft Sentinel

Microsoft Sentinel customers can use the TI Mapping analytics (a series of analytics all prefixed with ‘TI map’) to automatically match the malicious domain indicators mentioned in this blog post with data in their workspace. If the TI Map analytics are not currently deployed, customers can install the Threat Intelligence solution from the Microsoft Sentinel Content Hub to have the analytics rule deployed in their Sentinel workspace.

Microsoft Sentinel also has a range of detection and threat hunting content that customers can use to detect the post exploitation activity detailed in this blog in addition to Microsoft 365 Defender detections list above.

• Suspicious sign-in followed by MFA modification
• Account MFA modifications
• Okta SSO phishing detection
• Okta rare MFA operations
• Okta login from different locations
• Okta user password reset
• SharePointFileOperation via clientIP with previously unseen user agents
• SharePointFileOperation via devices with previously unseen user agents
• SharePointFileOperation via previously unseen IPs of risky ASN’s
• SharePointFileOperation via previously unseen IPs
• Anomalous AAD account manipulation
• New external user granted admin
• Anomolous sign-ins based on time
• New account added to admin group
• Authentication methods changed for privileged account
• Rare run command PowerShell script
• Azure NSG administrative operations
• Rare operations of create and update of snapshots
• AdFind usage
• Anomalous listing of storage keys
• Storage account key enumeration
• Potential Microsoft Security services tampering
• Potential Microsoft Defender tampering
• Office mail forwarding
• Multiple users Office mail forwarding

Further reading

Listen to Microsoft experts discuss Octo Tempest TTPs and activities on The Microsoft Threat Intelligence Podcast.

Visit this page for more blogs from Microsoft Incident Response.

For more security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.

To get notified about new publications and to join discussions on social media, follow us on X (formerly Twitter) at https://twitter.com/MsftSecIntel.

November 1, 2023 update: Updated the Actions of objectives section to fix the list of anonymous file-hosting services used by Octo Tempest for data exfiltration, which incorrectly listed Sh.Azl. It has been corrected to shz.al.

The post Octo Tempest crosses boundaries to facilitate extortion, encryption, and destruction appeared first on Microsoft Security Blog.

While the attack achieved the end goal of a typical AiTM phishing attack followed by business email compromise, notable aspects, such as the use of indirect proxy rather than the typical reverse proxy techniques, exemplify the continuous evolution of these threats. The use of indirect proxy in this campaign provided attackers control and flexibility in tailoring the phishing pages to their targets and further their goal of session cookie theft. After signing in with the stolen cookie through a session replay attack, the threat actors leveraged multifactor authentication (MFA) policies that have not been configured using security best practices in order to update MFA methods without an MFA challenge. A second-stage phishing campaign followed, with more than 16,000 emails sent to the target’s contacts.

This attack highlights the complexity of AiTM attacks and the comprehensive defenses they necessitate. This sophisticated AiTM attack requires beyond the typical remediation measures for identity compromise such as a password reset. Affected organizations need to revoke session cookies and roll back MFA modifications made by the threat actor. The incident also highlights the importance of proactive threat hunting to discover new TTPs on previously known campaigns to surface and remediate these types of threats.

To launch this attack, the attackers used an AiTM phishing kit developed, maintained, and operated by a threat actor that Microsoft tracks as Storm-1167. As part of our threat actor tracking and naming taxonomy, Microsoft uses Storm-#### designations as a temporary name given to an unknown, emerging, or developing cluster of threat activity, allowing Microsoft to track it as a unique set of information until we reach high confidence about the origin or identity of the actor behind the activity.

AiTM with indirect proxy

Adversary-in-the-middle (T1557, T1111) is a type of attack that aims to intercept authentication between users and a legitimate authentication service for the purpose of compromising identities or performing other actions. The attackers position themselves between a user and the service to steal credentials and intercept MFA in order to capture the session cookie. The attackers can then replay the session with the stolen session cookie before the token expiration time and impersonate the user without user intervention or MFA. With this session, the attackers could access the affected user’s resources and applications and perform business email compromise attacks and other malicious activities. More details about AiTM campaigns can be found on the blog Attackers use AiTM phishing sites as entry point to further financial fraud.

Unlike campaigns we have previously reported, this attack did not use the reverse proxy method that AiTM kits like EvilProxy and NakedPages use, in which the attacker’s server proxies the request from the application’s legitimate sign-in page. Instead, the attack used AiTM attack with indirect proxy method, in which the attacker presented targets with a website that mimicked the sign-in page of the targeted application, as in traditional phishing attacks, hosted on a cloud service. The said sign-in page contained resources loaded from an attacker-controlled server, which initiated an authentication session with the authentication provider of the target application using the victim’s credentials.

In this AiTM attack with indirect proxy method, since the phishing website is set up by the attackers, they have more control to modify the displayed content according to the scenario. In addition, since the phishing infrastructure is controlled by the attackers, they have the flexibility to create multiple servers to evade detections. Unlike typical AiTM attacks, there are no HTTP packets proxied between the target and the actual website.

When MFA is requested after successful password validation, the server displays a fake MFA page. Once the MFA is provided by the user, the attacker uses the same MFA token in the initiated session with the authentication provider. Following successful authentication, the session token is granted to the attacker, and victim is redirected to another page. The following diagram illustrates the AiTM attack observed in this scenario:

Attack chain: AiTM phishing attack leads to second-stage BEC

Our investigation into an AiTM phishing attack using the Storm-1167 AiTM kit uncovered details of a campaign that led to BEC activity. In the following sections, we present our in-depth analysis of the end-to-end attack chain.

Stage 1: Initial access via trusted vendor compromise

The attack started with a phishing email from one of the target organizations’ trusted vendors. The phishing email was sent with a seven-digit code as the subject. This code was unique for every target organization, which is likely a tracking mechanism for the attacker. The email body included a link to view or download a fax document. The link pointed to a malicious URL hosted on canva[.]com.

Sending phishing emails from a trusted vendor was one of the common behaviors that was observed for this threat actor across multiple targeted organizations. The intent of this behavior is to abuse the trusted vendor relationship and to blend with legitimate email traffic. A few of the target organizations had policies that automatically allow emails from trusted vendors, enabling the attacker to slip past detections.

Stage 2: Malicious URL click

Threat actors often abuse legitimate services and brands to avoid detection. In this scenario, we observed that the attacker leveraged the legitimate service Canva for the phishing campaign. Canva is a graphic design platform that allows users to create social media graphics, presentations, posters, and other visual content. Attackers abused the Canva platform to host a page that shows a fake OneDrive document preview and links to a phishing URL:

Stage 3: AiTM attack

Accessing the URL redirected the user to a phishing page hosted on the Tencent cloud platform that spoofed a Microsoft sign-in page. The final URL was different for every user but showed the same spoofed sign-in page.

After the target provided the password on the phishing page, the attacker then used the credentials in an authentication session created on the target website. When the attacker is prompted with MFA in the authentication session, the attacker modified the phishing page into a forged MFA page (as seen below). Once the target completed the multifactor authentication, the session token was then captured by the attacker.

The phishing pages for the AiTM attack were hosted on IP addresses located in Indonesia. The follow-on sign-ins described in the following sections were also observed from the same IP addresses.

Stage 4: Session cookie replay

In a stolen session cookie replay attack, the attacker uses the valid stolen cookie to impersonate the user, circumventing authentication mechanisms of passwords and MFA. In this campaign, we observed that the attacker signed in with the stolen cookie after a few hours from an IP address based in the United States. The attacker masqueraded as the target with this session replay attack and accessed email conversations and documents hosted in the cloud. In addition, the attacker generated a new access token, allowing them to persist longer in the environment.

Stage 5: MFA method modification

The attacker then proceeded to add a new MFA method for the target’s account, which was through phone based one-time password (OTP), in order to sign in using the user’s stolen credentials undetected. Adding a new MFA method, by default, does not require re-authentication. In this campaign, a common behavior that was observed was the attacker adding OneWaySMS, a phone-based OTP service, as a new MFA method in addition to the existing method used by the target. A phone number with the Iranian country code was observed added as the number used to receive the phone-based OTP.

Stage 6: Inbox rule creation

The attacker later signed in with the new session token and created an Inbox rule with parameters that moved all incoming emails on the user’s mailbox to the Archive folder and marked all the emails as read.

Stage 7: Phishing campaign

Followed by Inbox rule creation, the attacker initiated a large-scale phishing campaign involving more than 16,000 emails with a slightly modified Canva URL. The emails were sent to the compromised user’s contacts, both within and outside of the organization, as well as distribution lists. The recipients were identified based on the recent email threads in the compromised user’s inbox. The subject of the emails contained a unique seven-digit code, possibly a tactic by the attacker to keep track of the organizations and email chains.

Stage 8: BEC tactics

The attacker then monitored the victim user’s mailbox for undelivered and out of office emails and deleted them from the Archive folder. The attacker read the emails from the recipients who raised questions regarding the authenticity of the phishing email and responded, possibly to falsely confirm that the email is legitimate. The emails and responses were then deleted from the mailbox. These techniques are common in any BEC attacks and are intended to keep the victim unaware of the attacker’s operations, thus helping in persistence.

Stage 9: Accounts compromise

The recipients of the phishing emails from within the organization who clicked on the malicious URL were also targeted by another AiTM attack. Microsoft Defender Experts identified all compromised users based on the landing IP and the sign-in IP patterns. 

Stage 10: Second-stage BEC

The attacker was observed initiating another phishing campaign from the mailbox of one of the users who was compromised by the second AiTM attack. Microsoft revoked the compromised user’s session cookie, intervening with the second-stage attack.  

Microsoft Defender Experts: Extending security and threat defense

This AiTM attack’s use of indirect proxy is an example of the threat’s increasingly complex and evolving TTPs to evade and even challenge conventional solutions and best practices. Proactively hunting for and quickly responding to threats thus becomes an even more important aspect in securing organization networks because it provides an added layer to other security remediations and can help address areas of defense evasion.

Microsoft Defender Experts is part of Microsoft’s global network of more than 8,000 security analysts and researchers who, through our managed services like Microsoft Defender Experts for Hunting, help extend organizations’ ability to defend their environment, manage security, and even augment SOC teams. Our experts also enrich our vast cross-domain signals and let us deliver coordinated threat defense in our security products and solutions.

In this incident, because our experts actively research for new AiTM and BEC techniques, they were able to create advanced hunting detections for the Defender Experts service. These detections, combined with our experts’ own analyses of the anomalous emails and user behavior, enabled them to uncover the attack at its early stages, analyze the entire attack chain, and identify and promptly reach out to affected and targeted customers through Defender Experts Notifications. They then continuously monitored the attack for any additional compromised users or changes in the phishing patterns as it rapidly unfolded into a large-scale campaign.

Defender Experts also initiated rapid response with Microsoft 365 Defender to contain the attack including:

• Automatically disrupting the AiTM attack on behalf of the impacted users based on the signals observed in the campaign
• Initiating zero-hour auto purge (ZAP) in Microsoft Defender for Office 365 to find and take automated actions on the emails that are a part of the phishing campaign

Defender Experts further worked with customers to remediate compromised identities through the following recommendations:

• Revoking session cookies in addition to resetting passwords
• Revoking the MFA setting changes made by the attacker on the compromised user’s accounts
• Require re-challenging MFA for MFA updates as the default

Mitigation and protection guidance

Microsoft 365 Defender detects suspicious activities related to AiTM phishing attacks and their follow-on activities, such as session cookie theft and attempts to use the stolen cookie to sign into Exchange Online. To further protect themselves from similar attacks, organizations should also consider complementing MFA with conditional access policies, where sign-in requests are evaluated using additional identity-driven signals like user or group membership, IP location information, and device status, among others.

Mitigating AiTM phishing attacks

The general remediation measure for any identity compromise is to reset the password for the compromised user. However, in AiTM attacks, since the sign-in session is compromised, password reset is not an effective solution. Additionally, even if the compromised user’s password is reset and sessions are revoked, the attacker can set up persistence methods to sign-in in a controlled manner by tampering with MFA. For instance, the attacker can add a new MFA policy to sign in with a one-time password (OTP) sent to attacker registered mobile number. With this persistence mechanisms in place, the attacker can have control over the victim’s account despite conventional remediation measures.

While AiTM phishing attempts to circumvent MFA, implementation of MFA still remains an essential pillar in identity security and highly effective at stopping a wide variety of threats. MFA is the reason that threat actors developed the AiTM session cookie theft technique in the first place. Organizations are advised to work with their identity provider to ensure security controls like MFA are in place. Microsoft customers can implement through various methods, such as using the Microsoft Authenticator, FIDO2 security keys, and certificate-based authentication. 

Defenders can also complement MFA with the following solutions and best practices to further protect their organizations from such attacks: 

• Use security defaults as a baseline set of policies to improve identity security posture. For more granular control, enable conditional access policies, especially risk-based access policies. Conditional access policies evaluate sign-in requests using additional identity-driven signals like user or group membership, IP location information, and device status, among others, and are enforced for suspicious sign-ins. Organizations can protect themselves from attacks that leverage stolen credentials by enabling policies such as compliant devices, trusted IP address requirements, or risk-based policies with proper access control.
• Implement continuous access evaluation.
• Invest in advanced anti-phishing solutions that monitor and scan incoming emails and visited websites. For example, organizations can leverage web browsers that automatically identify and block malicious websites, including those used in this phishing campaign, and solutions that detect and block malicious emails, links, and files.
• Continuously monitor suspicious or anomalous activities. Hunt for sign-in attempts with suspicious characteristics (for example, location, ISP, user agent, and use of anonymizer services). 

Detections

Because AiTM phishing attacks are complex threats, they require solutions that leverage signals from multiple sources. Microsoft 365 Defender uses its cross-domain visibility to detect malicious activities related to AiTM, such as session cookie theft and attempts to use stolen cookies for signing in.

Using Microsoft Defender for Cloud Apps connectors, Microsoft 365 Defender raises AiTM-related alerts in multiple scenarios. For Azure AD customers using Microsoft Edge, attempts by attackers to replay session cookies to access cloud applications are detected by Defender for Cloud Apps connectors for Office 365 and Azure. In such scenarios, Microsoft 365 Defender raises the following alert:

• Stolen session cookie was used

In addition, signals from these Defender for Cloud Apps connectors, combined with data from the Defender for Endpoint network protection capabilities, also triggers the following Microsoft 365 Defender alert on Azure AD environments:

• Possible AiTM phishing attempt

A specific Defender for Cloud Apps connector for Okta, together with Defender for Endpoint, also helps detect AiTM attacks on Okta accounts using the following alert:

• Possible AiTM phishing attempt in Okta

Other detections that show potentially related activity are the following:

Microsoft Defender for Office 365

• Email messages containing malicious file removed after delivery​
• Email messages from a campaign removed after delivery​
• A potentially malicious URL click was detected
• A user clicked through to a potentially malicious URL​
• Suspicious email sending patterns detected

Microsoft Defender for Cloud Apps

• Suspicious inbox manipulation rule
• Impossible travel activity
• Activity from infrequent country
• Suspicious email deletion activity

Azure AD Identity Protection

• Anomalous Token
• Unfamiliar sign-in properties
• Unfamiliar sign-in properties for session cookies

Microsoft 365 Defender

• BEC-related credential harvesting attack
• Suspicious phishing emails sent by BEC-related user

Hunting queries

Microsoft Sentinel

Microsoft Sentinel customers can use the following analytic templates to find BEC related activities similar to those described in this post:

• Exchange workflow MailItemsAccessed operation anomaly
• Malicious Inbox Rule
• SharePointFileOperation via previously unseen IPs
• SharePointFileOperation via devices with previously unseen user agents
• User login from different countries within 3 hours
• TI Matching Analytics

In addition to the analytic templates listed above Microsoft Sentinel customers can use the following hunting content to perform Hunts for BEC related activities:

• Possible AiTM phishing attempt against Azure AD
• Unfamiliar Signin Correlation with AzurePortal Signin Attempts and AuditLogs
• Multiple users email forwarded to same destination
• Office Mail Rule Creation with suspicious archive mail move activity
• Sign-ins From VPS providers
• Successful sign-in from non-compliant device
• Risky sign-in with new MFA method

Further reading

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.

To get notified about new publications and to join discussions on social media, follow us on Twitter at https://twitter.com/MsftSecIntel.

The post Detecting and mitigating a multi-stage AiTM phishing and BEC campaign appeared first on Microsoft Security Blog.

April 2023 update – Microsoft Threat Intelligence has shifted to a new threat actor naming taxonomy aligned around the theme of weather. DEV-1101 is now tracked as Storm-1101.

To learn more about this evolution, how the new taxonomy represents the origin, unique traits, and impact of threat actors, and a complete mapping of threat actor names, read this blog: Microsoft shifts to a new threat actor naming taxonomy.

Adversary-in-the-middle (AiTM) phishing kits are part of an increasing trend that is observed supplanting many other less advanced forms of phishing. AiTM phishing is capable of circumventing multifactor authentication (MFA) through reverse-proxy functionality. DEV-1101 is an actor tracked by Microsoft responsible for the development, support, and advertising of several AiTM phishing kits, which other cybercriminals can buy or rent. The availability of such phishing kits for purchase by attackers is part of the industrialization of the cybercriminal economy and lowers the barrier of entry for cybercrime.

DEV-1101 offers an open-source kit that automates setting up and launching phishing activity and provides support services to attackers. The threat actor group began offering their AiTM phishing kit in 2022, and since then has made several enhancements to their kit, such as the capability to manage campaigns from mobile devices, as well as evasion features like CAPTCHA pages. These attributes make the kit attractive to many different actors who have continually put it to use since it became available in May 2022. Actors using this kit have varying motivations and targeting and might target any industry or sector.

Microsoft 365 Defender detects suspicious activities related to AiTM phishing attacks and follow-on activities, such as session cookie theft and attempts to use the stolen cookies to sign in.

In this blog post, we share information on DEV-1101, the tool they offer, and details on related AiTM campaigns. We also share best practices and detection details to further protect organizations from AiTM phishing attacks.

AiTM tool promotion

DEV-1101 began advertising their AiTM kit around May 2022 through a Telegram channel and an advertisement in exploit[.]in, a popular cybercrime forum. The advertisement describes the AiTM kit as a phishing application written in NodeJS with PHP reverse-proxy capabilities, automated setup, detection evasion through an antibot database, management of phishing activity through Telegram bots, and a wide range of ready-made phishing pages mimicking services such as Microsoft Office or Outlook.

On June 12, 2022, DEV-1101 announced that the kit would be open source with a $100 monthly licensing fee. The actor also provided links to additional Telegram channels and a now-defunct GitHub page.

In September 2022, DEV-1101 added the ability to manage servers running their kit through a Telegram bot rather than requiring the use of cPanel, further facilitating phishing activities and letting their customers manage campaigns from mobile devices.

DEV-1101 was able to increase the price of their tool multiple times due to the rapid growth of their user base from July through December 2022. This allowed DEV-1101 to dedicate themselves fully to the development and support of their tool. As of this writing, DEV-1101 offers their tool for $300, with VIP licenses at $1,000. Legacy users were permitted to continue purchasing licenses at $200 prior to January 1, 2023.

Microsoft observed several high-volume phishing campaigns from various actors using the tool offered by DEV-1101, comprising millions of phishing emails per day. DEV-0928, an actor Microsoft has tracked since September 2022, is one of DEV-1101’s more prominent patrons and was observed launching a phishing campaign involving over one million emails.

DEV-1101 phishing sequence

DEV-1101’s many different patrons take different approaches to phishing attacks. The example below is of an initial phishing message from a campaign launched by DEV-0928 using the DEV-1101 phishing kit. Clicking the Open button in the email leads to the next step in the sequence.

Two different evasions might result from clicking the link in the phishing message. The DEV-1101 kit’s antibot functionality might trigger an href redirection to a benign page. In this example, the DEV-0928 domain o365987656898087[.]xyz redirects to example.com:

The default redirection domain defined in the source code is example.com; however, any actor using the kit may define a different redirection domain.

The kit also allows threat actors to use CAPTCHA to evade detection. Inserting a CAPTCHA page into the phishing sequence could make it more difficult for automated systems to reach the final phishing page, while a human could easily click through to the next page.

While evasion through CAPTCHA was introduced in August 2022, the functionality then required active engagement from DEV-1101’s support to complete the setup for any requesting users. DEV-1101 later added CAPTCHA as a core functionality.

After the evasion pages, a phishing landing page is presented to the target from an actor-controlled host through the phishing actor’s reverse proxy setup:

At this point, the actor’s server captures credentials entered by the user. If the user has MFA enabled, the AiTM kit continues to function as a proxy between the user and the user’s sign-in service, meaning, as the user completes an MFA sign-in, the server captures the resulting session cookie. The attacker can then bypass MFA with the session cookie and the user’s stolen credentials.

The following diagram illustrates the AiTM phishing attack chain: 

For additional in-depth information on how AiTM phishing works, refer to the blog, From cookie theft to BEC: Attackers use AiTM phishing sites as entry point to further financial fraud.

Mitigating AiTM phishing attacks

While AiTM phishing attempts to circumvent MFA, MFA implementation remains an essential pillar in identity security and highly effective at stopping a wide variety of threats. MFA is the reason that threat actors developed the AiTM session cookie theft technique in the first place. Organizations are advised to work with their identity provider to ensure security controls like MFA are in place. Microsoft customers can implement MFA in Azure AD through various methods, such as using the Microsoft Authenticator, FIDO2 security keys, and certificate-based authentication. 

Defenders can also complement MFA with the following solutions and best practices to further protect their organizations from such attacks: 

• Use security defaults as a baseline set of policies to improve identity security posture. For more granular control, enable conditional access policies. Conditional access policies evaluate sign-in requests using additional identity-driven signals like user or group membership, IP location information, and device status, among others, and are enforced for suspicious sign-ins. Organizations can protect themselves from attacks that leverage stolen credentials by enabling policies such as compliant devices or trusted IP address requirements.
• Implement continuous access evaluation.
• Invest in advanced anti-phishing solutions thatmonitor and scan incoming emails and visited websites. For example, organizations can leverage web browsers that automatically identify and block malicious websites, including those used in this phishing campaign, and solutions that detect and block malicious emails, links, and files.
• Continuously monitor suspicious or anomalous activities. Hunt for sign-in attempts with suspicious characteristics (for example, location, ISP, user agent, and use of anonymizer services). 

Detection details and hunting queries 

Microsoft 365 Defender 

Because AiTM phishing attacks are complex threats, they require solutions that leverage signals from multiple sources. Microsoft 365 Defender uses its cross-domain visibility to detect malicious activities related to AiTM, such as session cookie theft and attempts to use stolen cookies for signing in.

Using Microsoft Defender for Cloud Apps connectors, Microsoft 365 Defender raises AiTM-related alerts in multiple scenarios. For Azure AD customers using Microsoft Edge, attempts by attackers to replay session cookies to access cloud applications are detected by Defender for Cloud Apps connectors for Office 365 and Azure. In such scenarios, Microsoft 365 Defender raises the following alert:

• Stolen session cookie was used

In addition, signals from these Defender for Cloud Apps connectors, combined with data from the Defender for Endpoint network protection capabilities, also triggers the following Microsoft 365 Defender alert on Azure AD environments:

• Possible AiTM phishing attempt 

A specific Defender for Cloud Apps connector for Okta, together with Defender for Endpoint, also helps detect AiTM attacks on Okta accounts using the following alert:

• Possible AiTM phishing attempt in Okta

In addition, Microsoft 365 Defender has the following related alerts for activity related to the DEV-0928 threat actor, as well as high-risk Azure AD sign-in activity:

• DEV-0928 activity group 
• Suspicious network connection to AiTM phishing site 
• Connection to Adversary-in-the-Middle (AiTM) phishing site

Microsoft Sentinel

Microsoft Sentinel customers can use the following Microsoft Sentinel Analytics template to identify potential AiTM phishing attempts:

• Possible AiTM Phishing Attempt Against Azure AD

This detection uses signals from Azure AD Identity Protection, specifically it looks for successful sign ins that have been flagged as high risk, and then combines this with data from Web Proxy services such as ZScaler to identify where users might have connected to the source of those sign ins immediately prior. This can indicate a user interacting with a AiTM phishing site and having their session hijacked. This detection uses the Advanced Security Information Model (ASIM) Web Session schema. More details on the schema and its requirements can be found in the documentation: https://learn.microsoft.com/azure/sentinel/normalization-schema-web

In addition, customers can use the following identity-focused Analytics and Hunting Queries to detect and investigate anomalous sign-in events that may be indicative of a compromised user identity being accessed by a threat actor:

• Anomalous sign-in location by user account and authenticating application
• Azure Portal Signin from another Azure Tenant
• User Accounts – Sign in Failure due to CA Spike
• Signins From VPS Providers
• Signins from Nord VPN Providers
• Successful Signin From Non-Compliant Device
• User Login IP Address Teleportation
• Anomalous Azure Active Directory apps based on authentication location
• Azure Active Directory signins from new locations
• Azure Active Directory sign-in burst from multiple locations

Microsoft Sentinel customers can also use the data provided by Microsoft Sentinel’s UEBA engine to hunt for anomalous login events such as where the ISP being logged in from is not commonly seen in the tenant, or if the user agent is uncommon amongst the user’s peer group. More details on Microsoft Sentinel UEBA feature can be found here: https://learn.microsoft.com/azure/sentinel/ueba-reference.

The post DEV-1101 enables high-volume AiTM campaigns with open-source phishing kit appeared first on Microsoft Security Blog.

Why it matters

In the new world of hybrid work, users may be accessing corporate resources from personally owned or unmanaged devices which increases the risk of token theft occurring. These unmanaged devices likely have weaker security controls than those that are managed by organizations, and most importantly, are not visible to corporate IT. Users on these devices may be signed into both personal websites and corporate applications at the same time, allowing attackers to compromise tokens belonging to both.

As far as mitigations go, publicly available open-source tools for exploiting token theft already exist, and commodity credential theft malware has already been adapted to include this technique in their arsenal. Detecting token theft can be difficult without the proper safeguards and visibility into authentication endpoints. Microsoft DART aims to provide defenders with the knowledge and strategies necessary to mitigate this tactic until permanent solutions become available.

Tokens are at the center of OAuth 2.0 identity platforms, such as Azure Active Directory (Azure AD). To access a resource (for example, a web application protected by Azure AD), a user must present a valid token. To obtain that token, the user must sign into Azure AD using their credentials. At that point, depending on policy, they may be required to complete MFA. The user then presents that token to the web application, which validates the token and allows the user access.

When Azure AD issues a token, it contains information (claims) such as the username, source IP address, MFA, and more. It also includes any privilege a user has in Azure AD. If you sign in as a Global Administrator to your Azure AD tenant, then the token will reflect that. Two of the most common token theft techniques DART has observed have been through adversary-in-the-middle (AitM) frameworks or the utilization of commodity malware (which enables a ‘pass-the-cookie’ scenario).

With traditional credential phishing, the attacker may use the credentials they have compromised to try and sign in to Azure AD. If the security policy requires MFA, the attacker is halted from being able to successfully sign in. Though the users’ credentials were compromised in this attack, the threat actor is prevented from accessing organizational resources.

Adversary-in-the-middle (AitM) phishing attack

Attacker methodologies are always evolving, and to that end DART has seen an increase in attackers using AitM techniques to steal tokens instead of passwords. Frameworks like Evilginx2 go far beyond credential phishing, by inserting malicious infrastructure between the user and the legitimate application the user is trying to access. When the user is phished, the malicious infrastructure captures both the credentials of the user, and the token.

If a regular user is phished and their token stolen, the attacker may attempt business email compromise (BEC) for financial gain. If a token with Global Administrator privilege is stolen, then they may attempt to take over the Azure AD tenant entirely, resulting in loss of administrative control and total tenant compromise.

Pass-the-cookie attack

A “pass-the-cookie” attack is a type of attack where an attacker can bypass authentication controls by compromising browser cookies. At a high level, browser cookies allow web applications to store user authentication information. This allows a website to keep you signed in and not constantly prompt for credentials every time you click a new page.

“Pass-the-cookie” is like pass-the-hash or pass-the-ticket attacks in Active Directory. After authentication to Azure AD via a browser, a cookie is created and stored for that session. If an attacker can compromise a device and extract the browser cookies, they could pass that cookie into a separate web browser on another system, bypassing security checkpoints along the way. Users who are accessing corporate resources on personal devices are especially at risk. Personal devices often have weaker security controls than corporate-managed devices and IT staff lack visibility to those devices to determine compromise. They also have additional attack vectors, such as personal email addresses or social media accounts users may access on the same device. Attackers can compromise these systems and steal the authentication cookies associated with both personal accounts and the users’ corporate credentials.

Commodity credential theft malware like Emotet, Redline, IcedID, and more all have built-in functionality to extract and exfiltrate browser cookies. Additionally, the attacker does not have to know the compromised account password or even the email address for this to work— those details are held within the cookie.

Recommendations

Protect

Organizations can take a significant step toward reducing the risk of token theft by ensuring that they have full visibility of where and how their users are authenticating. To access critical applications like Exchange Online or SharePoint, the device used should be known by the organization. Utilizing compliance tools like Intune in combination with device based conditional access policies can help to keep devices up to date with patches, antivirus definitions, and EDR solutions. Allowing only known devices that adhere to Microsoft’s recommended security baselines helps mitigate the risk of commodity credential theft malware being able to compromise end user devices.

For those devices that remain unmanaged, consider utilizing session conditional access policies and other compensating controls to reduce the impact of token theft:

• Reducing the lifetime of the session increases the number of times a user is forced to re-authenticate but minimizes the length of time session token is viable.
• Reducing the viable time of a token forces threat actors to increase the frequency of token theft attempts which in turn provides defenders with additional chances at detection.
• Implement Conditional Access App Control in Microsoft Defender for Cloud Apps for users connecting from unmanaged devices.

Protect your users by blocking initial access:

• Plan and implement phishing resistant MFA solutions such as FIDO2 security keys, Windows Hello for Business, or certificate-based authentication for users.
  • While this may not be practical for all users, it should be considered for users of significant privilege like Global Admins or users of high-risk applications.
• Users that hold a high level of privilege in the tenant should have a segregated cloud-only identity for all administrative activities, to reduce the attack surface from on-premises to cloud in the event of on-premises domain compromise and abuse of privilege. These identities should also not have a mailbox attached to them to prevent the likelihood of privileged account compromise via phishing techniques.

We recognize that while it may be recommended for organizations to enforce location, device compliance, and session lifetime controls to all applications it may not always be practical. Decisionmakers should instead focus on deploying these controls to applications and users that have the greatest risk to the organization which may include:

• Highly privileged users like Global Administrators, Service Administrators, Authentication Administrators, and Billing Administrators among others.
• Finance and treasury type applications that are attractive targets for attackers seeking financial gain.
• Human capital management (HCM) applications containing personally identifiable information that may be targeted for exfiltration.
• Control and management plane access to Microsoft 365 Defender, Azure, Office 365 and other cloud app administrative portals.
• Access to Office 365 services (Exchange, SharePoint, and Teams) and productivity-based cloud apps.
• VPN or remote access portals that provide external access to organizational resources.

Detect

When a token is replayed, the sign-in from the threat actor can flag anomalous features and impossible travel alerts. Azure Active Directory Identity Protection and Microsoft Defender for Cloud Apps both alert on these events. Azure AD Identity Protection has a specific detection for anomalous token events. The token anomaly detection in Azure AD Identity Protection is tuned to incur more noise than other alerts. This helps ensure that genuine token theft events aren’t missed.

DART recommends focusing on high severity alerts and focusing on those users who trigger multiple alerts rapidly. Detection rules that map to the MITRE ATT&CK framework can help detect genuine compromise. For example, a risky sign-in followed closely by indicators of persistence techniques, such as mailbox rule creation.

Response and investigation

If a user is confirmed compromised and their token stolen, there are several steps DART recommends evicting the threat actor. Azure AD provides the capability to revoke a refresh token. Once a refresh token is revoked, it’s no longer valid. When the associated access token expires, the user will be prompted to re-authenticate. The following graphic outlines the methods by which access is terminated entirely:

It’s crucial to use both the Azure AD portal, Microsoft Graph, or Azure AD PowerShell in addition to resetting the users’ passwords to complete the revocation process.

Importantly, revoking refresh tokens via the above methods doesn’t invalidate the access token immediately, which can still be valid for up to an hour. This means the threat actor may still have access to a compromised user’s account until the access token expires. Azure AD now supports continuous access evaluation for Exchange, SharePoint and Teams, allowing access tokens to be revoked in near real time following a ‘critical event’. This helps to significantly reduce the up to one hour delay between refresh token revocation and access token expiry.

Microsoft DART also recommends checking the compromised user’s account for other signs of persistence. These can include:

• Mailbox rules – threat actors often create specific mailbox rules to forward or hide email. These can include rules to hide emails in folders that are not often used. For example, a threat actor may forward all emails containing the keyword ‘invoice’ to the Archive folder to hide them from the user or forward them to an external email address.
• Mailbox forwarding – email forwarding may be configured to send a copy of all email to an external email address. This allows the threat actor to silently retrieve a copy of every email the user receives.
• Multifactor authentication modification – DART has detected instances of threat actors registering additional authentication methods against compromised accounts for use with MFA, such as phone numbers or authenticator apps.
• Device enrollment – in some cases, DART has seen threat actors add a device to an Azure AD tenant they control. This is an attempt to bypass conditional access rules with exclusions such as known devices.
• Data exfiltration – threat actors may use the inbuilt sharing functionality in SharePoint and OneDrive to share important or sensitive documents and organizational resources externally.

To strengthen your security posture, you should configure alerts to review high-risk modifications to a tenant. Some examples of this are:

• Modification or creation of security configurations
• Modification or creation of Exchange transport rules
• Modification or creation of privileged users or roles

Incident responders should review any audit logs related to user activity to look for signs of persistence. Logs available in the Unified Audit Log, Microsoft Defender for Cloud Apps, or SIEM solutions like Microsoft Sentinel can aid with investigations.

Conclusion

Although tactics from threat actors are constantly evolving, it is important to note that multifactor authentication, when combined with other basic security hygiene—utilizing antimalware, applying least privilege principals, keeping software up to date and protecting data—still protects against 98% of all attacks.

Fundamentally, it is important to consider the identity trust chain for the organization, spanning both internally and externally. The trust chain includes all systems (such as identity providers, federated identity providers, MFA services, VPN solutions, cloud-service providers, and enterprise applications) that issue access tokens and grant privilege for identities both cloud and on-premises, resulting in implicit trust between them.

In instances of token theft, adversaries insert themselves in the middle of the trust chain and often subsequently circumvent security controls. Having visibility, alerting, insights, and a full understanding of where security controls are enforced is key. Treating both identity providers that generate access tokens and their associated privileged identities as critical assets is strongly encouraged.

Adversaries have and will continue to find ways to evade security controls. The tactics utilized by threat actors to bypass controls and compromise tokens present additional challenges to defenders. However, by implementing the controls presented in this blog DART believes that organizations will be better prepared to detect, mitigate, and respond to threats of this nature moving forward.

The post Token tactics: How to prevent, detect, and respond to cloud token theft appeared first on Microsoft Security Blog.

After carefully reviewing the implications, a Microsoft security researcher shared the vulnerability with Google in April 2022 and also reported it with the Chromium bug tracking system. Fixes for the vulnerability, which is assigned as CVE-2022-2587 and has a Common Vulnerability Scoring System (CVSS) score of 9.8 (classifying the vulnerability as critical), were quickly released and have been successfully deployed to end users. We’d like to thank the Google team and the Chromium community for their professional resolution and collaborative efforts.

This research coupled with the recent release of ChromeOS Flex, which can convert various legacy PCs and Macs into Chromebooks, emphasizes the importance of analyzing and monitoring security for devices running ChromeOS. Moreover, as even the most hardened operating systems might contain security bugs, we emphasize the need for strong monitoring of all cross-platform devices and operating systems. The best approach for protecting unmanaged devices is by using Microsoft Defender for Endpoint’s device discovery capabilities to monitor suspicious traffic and help detect attacker activities on such devices.

In this blog post, we share some information about the vulnerability and examine how it could be triggered as well as the possible implications. Displaying how our cross-domain expertise helps us uncover new and unknown threats in the effort to continually improve security for all, we also share details from our research with the larger security community to emphasize the importance of collaboration to secure platforms and devices.

An overview of ChromeOS security

One well-known operating system that uses D-Bus is ChromeOS. ChromeOS is a Google-proprietary Linux-based operating system that runs on Chromebooks, Chromeboxes, Chromebits and Chromebases. ChromeOS is a closed-source system with open-source components that are derived from ChromiumOS, and the operating system uses Google’s own Chrome browser as its principal user interface.

In terms of security, ChromeOS is well hardened; some of the security features on ChromeOS include:

• Hardened sandbox (called minijail)
• Verified boot
• Locked-down filesystem (mounted with noexec, nosuid, nodev) and dm-verity
• Root user restrictions (SECURE_NOROOT)
• When development mode is entered, all locally stored data is wiped

As with other modern browsers, exploiting ChromeOS usually requires chaining vulnerabilities together. Due to hardening measures in ChromeOS, discovering vulnerabilities became a specific niche and, therefore, the number of public vulnerabilities is quite low compared to other operating systems. ChromeOS vulnerabilities generally fall into one of three different classes:

1. ChromeOS-specific logic vulnerabilities
2. ChromeOS-specific memory-corruption vulnerabilities
3. Broader threats such as Chrome browser vulnerabilities

In this case, the discovered vulnerability falls under the second class, ChromeOS-specific memory-corruption vulnerabilities.

Bug hunting

Having discussed and extensively researched D-Bus, we continued this analysis by enumerating the D-Bus services offered on ChromeOS. In general, D-Bus is an Inter-Process-Communication (IPC) mechanism that’s popular on desktop platforms, specifically Linux.

ChromeOS’s developer mode offers the dbus-send utility to send messages over D-bus. As there are many D-Bus services offered on ChromeOS (usually identified by the “org.chromium” prefix), we automated the process and used the dbus-send utility to fetch the full tree of services and their exported methods and signals.

Because most D-Bus services support the org.freedesktop.DBus.Introspectable interface, it’s possible to dynamically fetch exported methods and signals without reading the source code or reverse-engineering the binaries.

Fetching all the exported service names can be performed using the following command:

dbus-send --system --dest=org.freedesktop.DBus --type=method_call --print-reply /org/freedesktop/DBus org.freedesktop.DBus.ListNames

Using org.chromium.ResourceManager as an example, each service can then be enumerated for its declared methods and signals via the following command:

dbus-send --system --dest=org.chromium.ResourceManager --type=method_call --print-reply /org/chromium/ResourceManager org.freedesktop.DBus.Introspectable.Introspect

Considering that the more input a method receives, the higher the probability of finding a security issue, we then focused on methods that export arbitrarily large inputs, such as strings or arrays. It wasn’t long before we found an interesting service: org.chromium.cras.

The vulnerability

The org.chromium.cras D-Bus name is owned by CRAS (ChromiumOS Audio Server), which has a well-documented architecture under the ChromiumOS wiki pages. In essence, CRAS is a server that resides between the operating system and ALSA (Advanced Linux Sound Architecture) as a means of routing audio to newly attached audio-supporting peripherals, like USB speakers and Bluetooth headsets.

Reviewing the exported methods uncovered one method with a particularly interesting handling function: SetPlayerIdentity, which gets one string (an argument called identity) as an input. Since ChromiumOS is open-sourced, tracking the calls is straightforward:

1. In cras_dbus_control.c, the handler function for SetPlayerIdentity is handle_set_player_identity, which extracts the identity argument from the D-Bus message and invoke the cras_bt_player_update_identity function.
2. In cras_bt_player.c, the function cras_bt_player_update_identity that was called checks that the identity input value is not null and is different than the current player identity string (saved under player.identity). If so, it copies the identity variable to player.identity using the C library function strcpy. Of note, “player” is a global variable in the cras_bt_player module and includes an identity field in it, among others.

To the experienced security engineer, the mention of the strcpy function immediately raises red flags. The strcpy function is known to cause various memory corruption vulnerabilities since it doesn’t perform any bounds check and is therefore considered unsafe. As there are no bounds checks on the user-supplied identity argument before invoking strcpy (besides the default message length limitations for D-Bus messages), we were confident we could trigger a heap-based buffer overflow, therefore triggering a memory corruption vulnerability.

Heap-based buffer overflows can be the cause of multiple vulnerabilities, most notoriously leading to arbitrary code execution through various means. This could include overriding a function callback in an allocated object or overriding chunk metadata, which can trigger other unexpected behavior during the lifetime of a program.

Checking how the player.identity string is initialized shows that it’s set in the cras_bt_player_init function as the result of malloc(128), which means it’s allocated on the user’s heap with 128 bytes.

Therefore, the vulnerability could be triggered using a single command line by sending the identity user-controlled D-Bus argument with more than 128 bytes, as displayed in our example code below:

dbus-send --system --dest=org.chromium.cras --type=method_call --print-reply /org/chromium/cras org.chromium.cras.Control.SetPlayerIdentity string:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

As most users don’t need to enable ChromeOS’s developer mode and, thus, can’t use the dbus-send utility, our next task was to find a way to trigger the bug without using developer mode.

Triggering the bug remotely

Thinking we spotted a local memory corruption issue, we wanted to better understand how to trigger the bug. Since the involved functions exclusively get triggered from D-Bus, we looked for functions that trigger the SetPlayerIdentity D-Bus method—if the arguments to those don’t have bounds checks, then those functions could be used to trigger the vulnerability.

Examining the open-source ChromiumOS repositories found that the CRAS audio client invokes the SetPlayerIdentity method (and exports a function with the same name). In turn, it’s called by the CRAS audio handler component’s method MediaSessionMetadataChanged, which extracts the identity from a metadata structure representing a song’s title:

At this point, it was clear that the vulnerability could be triggered via changes to the audio metadata. Looking for MediaSessionMetadataChanged invocations revealed two interesting cases that could both be triggered remotely:

1. From the browser: the browser’s media component invokes the function when metadata is changed, such as when playing a new song in the browser.
2. From Bluetooth: the media session service in the operating system invokes the function when a song’s metadata changes, which can happen when playing a new song from a paired Bluetooth device.

Implications and reporting

We reported the vulnerability to Google in April 2022 as a part of the Chromium bug tracking system and were assigned Issue 1320917, which immediately got assigned as a priority 1 security bug. In parallel, we tracked the issue internally in Microsoft Security Vulnerability Research (MSVR), while using OSINT to look for indications of that vulnerability being used in the wild. We did not find any indications of in-the-wild exploitation.

The impact of heap-based buffer overflow ranges from simple DoS to full-fledged RCE. Although it’s possible to allocate and free chunks through media metadata manipulation, performing the precise heap-grooming is not trivial in this case and attackers would need to chain the exploit with other vulnerabilities to successfully execute any arbitrary code. Given the potential impact of the vulnerability, coupled with the fact that it could be remotely triggered, it’s a security risk that justifies the bug priority and how fast the fix was issued.

We were impressed with the speed of the fix and the effectiveness of the overall process. Within less than a week, the code was committed and, after several merges, made generally available to users. We thank the Google team and the Chromium community for their efforts in addressing the issue.

Improving security for all through research and threat intelligence sharing

As the threat and computing landscape continues to evolve, Microsoft strives to continuously improve security for all through research-driven protections and collaboration with customers, partners, and industry experts, regardless of the device or platform in use.

To defend against the evolving threat landscape, organizations must closely monitor all devices and operating systems across platforms, including unmanaged devices. Unmanaged devices are sometimes ignored or missed by security teams at join time, making them attractive targets for compromising, quietly performing lateral movements, jumping network boundaries, and achieving persistence for the sake of launching broader attacks. Microsoft Defender for Endpoint’s device discovery capabilities help organizations find certain unmanaged devices, including those running ChromeOS, and can detect if they are being operated by attackers when they start performing network interactions with servers and other managed devices.

Microsoft security researchers continually work to discover new vulnerabilities and threats, turning knowledge of a variety of wide-reaching issues into improved solutions that protect users and organizations across platforms every single day. This case displays how vulnerability disclosures and threat intelligence sharing are essential to effectively mitigate issues and protect users against present and future threats. Moreover, by expanding upon our prior research, we can also continue to make positive contributions to the overall security of devices worldwide, even on platforms we currently don’t directly support.

Jonathan Bar Or

Microsoft 365 Defender Research Team

The post Uncovering a ChromeOS remote memory corruption vulnerability appeared first on Microsoft Security Blog.

April 2023 update – Microsoft Threat Intelligence has shifted to a new threat actor naming taxonomy aligned around the theme of weather. SEABORGIUM is now tracked as Star Blizzard and ACTINIUM is now tracked as Aqua Blizzard.

To learn about how the new taxonomy represents the origin, unique traits, and impact of threat actors, and to get a complete mapping of threat actor names, read this blog: Microsoft shifts to a new threat actor naming taxonomy.

The Microsoft Threat Intelligence Center (MSTIC) has observed and taken actions to disrupt campaigns launched by SEABORGIUM, an actor Microsoft has tracked since 2017. SEABORGIUM is a threat actor that originates from Russia, with objectives and victimology that align closely with Russian state interests. Its campaigns involve persistent phishing and credential theft campaigns leading to intrusions and data theft. SEABORGIUM intrusions have also been linked to hack-and-leak campaigns, where stolen and leaked data is used to shape narratives in targeted countries. While we cannot rule out that supporting elements of the group may have current or prior affiliations with criminal or other nonstate ecosystems, MSTIC assesses that information collected during SEABORGIUM intrusions likely supports traditional espionage objectives and information operations as opposed to financial motivations.

This blog provides insights into SEABORGIUM’s activities and technical methods, with the goal of sharing context and raising awareness about a significant threat to Microsoft customers. MSTIC would like to acknowledge the Google Threat Analysis Group (TAG) and the Proofpoint Threat Research Team for their collaboration on tracking and disrupting this actor. Microsoft’s ability to detect and track SEABORGIUM’s abuse of Microsoft services, particularly OneDrive, has provided MSTIC sustained visibility into the actor’s activities and enabled us to notify impacted customers. As an outcome of these service abuse investigations, MSTIC partnered with abuse teams in Microsoft to disable accounts used by the actor for reconnaissance, phishing, and email collection. Microsoft Defender SmartScreen has also implemented detections against the phishing domains represented in SEABORGIUM’s activities.

Who is SEABORGIUM?

SEABORGIUM is a highly persistent threat actor, frequently targeting the same organizations over long periods of time. Once successful, it slowly infiltrates targeted organizations’ social networks through constant impersonation, rapport building, and phishing to deepen their intrusion. SEABORGIUM has successfully compromised organizations and people of interest in consistent campaigns for several years, rarely changing methodologies or tactics. Based on known indicators of compromise and actor tactics, SEABORGIUM overlaps with the threat groups tracked as Callisto Group (F-Secure), TA446 (Proofpoint) and COLDRIVER (Google). Security Service of Ukraine (SSU) has associated Callisto with Gamaredon Group (tracked by Microsoft as ACTINIUM); however, MSTIC has not observed technical intrusion links to support the association. 

Since the beginning of 2022, Microsoft has observed SEABORGIUM campaigns targeting over 30 organizations, in addition to personal accounts of people of interest. SEABORGIUM primarily targets NATO countries, particularly the US and the UK, with occasional targeting of other countries in the Baltics, the Nordics, and Eastern Europe. Such targeting has included the government sector of Ukraine in the months leading up to the invasion by Russia, and organizations involved in supporting roles for the war in Ukraine. Despite some targeting of these organizations, Microsoft assesses that Ukraine is likely not a primary focus for this actor; however, it is most likely a reactive focus area for the actor and one of many diverse targets.

Within the target countries, SEABORGIUM primarily focuses operations on defense and intelligence consulting companies, non-governmental organizations (NGOs) and intergovernmental organizations (IGOs), think tanks, and higher education. SEABORGIUM has a high interest in targeting individuals as well, with 30% of Microsoft’s nation-state notifications related to SEABORGIUM activity being delivered to Microsoft consumer email accounts. SEABORGIUM has been observed targeting former intelligence officials, experts in Russian affairs, and Russian citizens abroad. As with any observed nation-state actor activity, Microsoft directly notifies customers of Microsoft services that have been targeted or compromised, providing them with the information they need to secure their accounts.

Observed actor activity

Over many years of tracking, Microsoft has observed a consistent methodology from SEABORGIUM with only slight deviations in their social engineering approaches and in how they deliver the initial malicious URL to their targets. In this section, we provide detailed analysis of SEABORBIUM’s operational tactics as well as several examples of their campaigns.

Impersonation and establishing contact

Before starting a campaign, SEABORGIUM often conducts reconnaissance of target individuals, with a focus on identifying legitimate contacts in the targets’ distant social network or sphere of influence. Based on some of the impersonation and targeting observed, we suspect that the threat actor uses social media platforms, personal directories, and general open-source intelligence (OSINT) to supplement their reconnaissance efforts. MSTIC, in partnership with LinkedIn, has observed fraudulent profiles attributed to SEABORGIUM being used sporadically for conducting reconnaissance of employees from specific organizations of interest. In accordance with their policies, LinkedIn terminated any account (including the one shown below) identified as conducting inauthentic or fraudulent behavior.

SEABORGIUM also registers new email accounts at various consumer email providers, with the email address or alias configured to match legitimate aliases or names of impersonated individuals. While the creation of new consumer accounts is common, we have also observed SEABORGIUM returning to and reusing historical accounts that match the industry of the ultimate target. In one case, we observed SEABORGIUM returning to an account it had not used in a year, indicating potential tracking and reusing of accounts if relevant to targets’ verticals.

After registering new accounts, SEABORGIUM proceeds to establish contact with their target. In cases of personal or consumer targeting, MSTIC has mostly observed the actor starting the conversation with a benign email message, typically exchanging pleasantries before referencing a non-existent attachment while highlighting a topic of interest to the target. It’s likely that this additional step helps the actor establish rapport and avoid suspicion, resulting in further interaction. If the target replies, SEABORGIUM proceeds to send a weaponized email.

MSTIC has also documented several cases where the actor focuses on a more organizational approach to phishing. In these cases, the actor uses an authoritative approach in their social engineering and typically goes to directly sending malicious content.

These examples serve to demonstrate the actors’ capability to be dynamic and to adapt their social engineering approach to gain the trust of their victims.

Delivery of malicious content

Microsoft has identified several variations in the way that SEABORGIUM delivers a link that directs targets to their credential stealing infrastructure. 

URL in body of email

In the simplest case, SEABORGIUM directly adds a URL to the body of their phishing email. Occasionally, the actor leverages URL shorteners and open redirects to obfuscate their URL from the target and inline protection platforms. The email varies between fake personal correspondence with a hyperlinked text and fake file sharing emails that imitate a range of platforms.

PDF file attachment that contains a URL

MSTIC has observed an increase in the use of attachments in SEABORGIUM campaigns. These attachments typically imitate a file or document hosting service, including OneDrive, and request the user to open the document by clicking a button.

OneDrive link to PDF file that contains a URL

SEABORGIUM also abuses OneDrive to host PDF files that contain a link to the malicious URL. This activity does not represent any security issues or vulnerabilities on the OneDrive platform. The actors include a OneDrive link in the body of the email that when clicked directs the user to a PDF file hosted within a SEABORGIUM-controlled OneDrive account. As seen in the previous example, the victim is presented with what appears to be a failed preview message, enticing the target to click the link to be directed to the credential-stealing infrastructure. Occasionally, SEABORGIUM makes use of open redirects within the PDF file to further disguise their operational infrastructure. In the example below, SEABORGIUM uses a Google URL for redirection.

Credential theft

Regardless of the method of delivery, when the target clicks the URL, the target is directed to an actor-controlled server hosting a phishing framework, most often EvilGinx. On occasion, Microsoft has observed attempts by the actor to evade automated browsing and detonation by fingerprinting browsing behavior. Once the target is redirected to the final page, the framework prompts the target for authentication, mirroring the sign-in page for a legitimate provider and intercepting any credentials. After credentials are captured, the target is redirected to a website or document to complete the interaction.  

Data exfiltration and impact

SEABORGIUM has been observed to use stolen credentials and directly sign in to victim email accounts. Based on our experience responding to intrusions from this actor on behalf of our customers, we have confirmed that the following activities are common:

• Exfiltration of intelligence data: SEABORGIUM has been observed exfiltrating emails and attachments from the inbox of victims.
• Setup of persistent data collection: In limited cases, SEABORGIUM has been observed setting up forwarding rules from victim inboxes to actor-controlled dead drop accounts where the actor has long-term access to collected data. On more than one occasion, we have observed that the actors were able to access mailing-list data for sensitive groups, such as those frequented by former intelligence officials, and maintain a collection of information from the mailing-list for follow-on targeting and exfiltration.
• Access to people of interest: There have been several cases where SEABORGIUM has been observed using their impersonation accounts to facilitate dialog with specific people of interest and, as a result, were included in conversations, sometimes unwittingly, involving multiple parties. The nature of the conversations identified during investigations by Microsoft demonstrates potentially sensitive information being shared that could provide intelligence value.

Based on the specific victimology, documents stolen, conversations fostered, and sustained collection observed, we assess that espionage is likely a key motivation of the actor.

Sporadic involvement with information operations

In May 2021, MSTIC attributed an information operation to SEABORGIUM based on observations and technical overlaps with known phishing campaigns. The operation involved documents allegedly stolen from a political organization in the UK that were uploaded to a public PDF file-sharing site. The documents were later amplified on social media via known SEABORGIUM accounts, however MSTIC observed minimal engagement or further amplification. Microsoft was unable to validate the authenticity of the material.  

In late May 2022, Reuters along with Google TAG disclosed details about an information operation, specifically using hack and leak, that they attributed to COLDRIVER/SEABORGIUM. Microsoft independently linked SEABORGIUM to the campaign through technical indicators and agrees with the assessment by TAG on the actor responsible for the operation. In the said operation, the actors leaked emails/documents from 2018 to 2022, allegedly stolen from consumer Protonmail accounts belonging to high-level proponents of Brexit, to build a narrative that the participants were planning a coup. The narrative was amplified using social media and through specific politically themed media sources that garnered quite a bit of reach.

While we have only observed two cases of direct involvement, MSTIC is not able to rule out that SEABORGIUM’s intrusion operations have yielded data used through other information outlets. As with any information operation, Microsoft urges caution in distributing or amplifying direct narratives, and urges readers to be critical that the malicious actors could have intentionally inserted misinformation or disinformation to assist their narrative. With this in mind, Microsoft will not be releasing the specific domain or content to avoid amplification.  

Recommended customer actions

The techniques used by the actor and described in the “Observed actor activity” section can be mitigated by adopting the security considerations provided below:

• Check your Office 365 email filtering settings to ensure you block spoofed emails, spam, and emails with malware.
• Configure Office 365 to disable email auto-forwarding.
• Use the included indicators of compromise to investigate whether they exist in your environment and assess for potential intrusion.
• Review all authentication activity for remote access infrastructure, with a particular focus on accounts configured with single factor authentication, to confirm authenticity and investigate any anomalous activity.
• Require multifactor authentication (MFA) for all users coming from all locations including perceived trusted environments, and all internet-facing infrastructure–even those coming from on-premises systems.
• Leverage more secure implementations such as FIDO Tokens, or Microsoft Authenticator with number matching. Avoid telephony-based MFA methods to avoid risks associated with SIM-jacking.

For Microsoft Defender for Office 365 Customers:

• Use Microsoft Defender for Office 365 for enhanced phishing protection and coverage against new threats and polymorphic variants.
• Enable Zero-hour auto purge (ZAP) in Office 365 to quarantine sent mail in response to newly acquired threat intelligence and retroactively neutralize malicious phishing, spam, or malware messages that have already been delivered to mailboxes.
• Configure Defender for Office 365 to recheck links on click. Safe Links provides URL scanning and rewriting of inbound email messages in mail flow, and time-of-click verification of URLs and links in email messages, other Office applications such as Teams, and other locations such as SharePoint Online. Safe Links scanning occurs in addition to the regular anti-spam and anti-malware protection in inbound email messages in Exchange Online Protection (EOP). Safe Links scanning can help protect your organization from malicious links that are used in phishing and other attacks.
• Use the Attack Simulator in Microsoft Defender for Office 365 to run realistic, yet safe, simulated phishing and password attack campaigns within your organization. Run spear-phishing (credential harvest) simulations to train end-users against clicking URLs in unsolicited messages and disclosing their credentials.

Indicators of compromise (IOCs)

The below list provides IOCs observed during our investigation. We encourage our customers to investigate these indicators in their environments and implement detections and protections to identify past related activity and prevent future attacks against their systems.

NOTE: These indicators should not be considered exhaustive for this observed activity.

Detections

Intelligence gathered by the Microsoft Threat Intelligence Center (MSTIC) is used within Microsoft security products to provide protection against associated actor activity.

Microsoft Defender for Office 365

Microsoft Defender for Office offers enhanced solutions for blocking and identifying malicious emails. Signals from Microsoft Defender for Office inform Microsoft 365 Defender, which correlate cross-domain threat intelligence to deliver coordinated defense, when this threat has been detected. These alerts, however, can be triggered by unrelated threat activity. Example alerts:

• A potentially malicious URL click was detected
• Email messages containing malicious URL removed after delivery
• Email messages removed after delivery
• Email reported by user as malware or phish

Microsoft 365 Defender

Aside from the Microsoft Defender for Office 365 alerts above, customers can also monitor for the following Microsoft 365 Defender alerts for this attack. Note that these alerts can also be triggered by unrelated threat activity. Example alerts:

• Suspicious URL clicked
• Suspicious URL opened in web browser
• User accessed link in ZAP-quarantined email

Microsoft 365 Defender customers should also investigate any “Stolen session cookie was used” alerts that would betriggered for adversary-in-the-middle (AiTM) attacks.

Microsoft Defender SmartScreen

Microsoft Defender SmartScreen has implemented detections against the phishing domains represented in the IOC section above.

Advanced hunting queries

Microsoft Sentinel

Microsoft Sentinel customers can run the following advanced hunting queries to locate IOCs and related malicious activity in their environments.

The query below identifies matches based on domain IOCs related to SEABORGIUM actor across a range of common Microsoft Sentinel data sets:

https://github.com/Azure/Azure-Sentinel/blob/master/Detections/MultipleDataSources/SEABORGIUMDomainsAugust2022.yaml

Microsoft 365 Defender

Microsoft 365 Defender customers can run the following advanced hunting queries to locate IOCs and related malicious activity in their environments.

This query identifies matches based on domain IOCs related to SEABORGIUM against Microsoft Defender for Endpoint device network connections

https://github.com/Azure/Azure-Sentinel/blob/master/Hunting%20Queries/Microsoft%20365%20Defender/Campaigns/SEABORGIUMDomainIOCsAug2022.yaml

The post Disrupting SEABORGIUM’s ongoing phishing operations appeared first on Microsoft Security Blog.

Phishing remains to be one of the most common techniques attackers use in their attempts to gain initial access to organizations. According to the 2021 Microsoft Digital Defense Report, reports of phishing attacks doubled in 2020, and phishing is the most common type of malicious email observed in our threat signals. MFA provides an added security layer against credential theft, and it is expected that more organizations will adopt it, especially in countries and regions where even governments are mandating it. Unfortunately, attackers are also finding new ways to circumvent this security measure. 

In AiTM phishing, attackers deploy a proxy server between a target user and the website the user wishes to visit (that is, the site the attacker wishes to impersonate). Such a setup allows the attacker to steal and intercept the target’s password and the session cookie that proves their ongoing and authenticated session with the website. Note that this is not a vulnerability in MFA; since AiTM phishing steals the session cookie, the attacker gets authenticated to a session on the user’s behalf, regardless of the sign-in method the latter uses.

Microsoft 365 Defender detects suspicious activities related to AiTM phishing attacks and their follow-on activities, such as session cookie theft and attempts to use the stolen cookie to sign into Exchange Online. However, to further protect themselves from similar attacks, organizations should also consider complementing MFA with conditional access policies, where sign-in requests are evaluated using additional identity-driven signals like user or group membership, IP location information, and device status, among others. 

While AiTM phishing isn’t new, our investigation allowed us to observe and analyze the follow-on activities stemming from the campaign—including cloud-based attack attempts—through cross-domain threat data from Microsoft 365 Defender. These observations also let us improve and enrich our solutions’ protection capabilities. This campaign thus also highlights the importance of building a comprehensive defense strategy. As the threat landscape evolves, organizations need to assume breach and understand their network and threat data to gain complete visibility and insight into complex end-to-end attack chains.

In this blog, we’ll share our technical analysis of this phishing campaign and the succeeding payment fraud attempted by the attackers. We’ll also provide guidance for defenders on protecting organizations from this threat and how Microsoft security technologies detect it.

How AiTM phishing works

Every modern web service implements a session with a user after successful authentication so that the user doesn’t have to be authenticated at every new page they visit. This session functionality is implemented through a session cookie provided by an authentication service after initial authentication. The session cookie is proof for the web server that the user has been authenticated and has an ongoing session on the website. In AiTM phishing, an attacker attempts to obtain a target user’s session cookie so they can skip the whole authentication process and act on the latter’s behalf.  

To do this, the attacker deploys a webserver that proxies HTTP packets from the user that visits the phishing site to the target server the attacker wishes to impersonate and the other way around. This way, the phishing site is visually identical to the original website (as every HTTP is proxied to and from the original website). The attacker also doesn’t need to craft their own phishing site like how it’s done in conventional phishing campaigns. The URL is the only visible difference between the phishing site and the actual one. 

Figure 2 below illustrates the AiTM phishing process:

The phishing page has two different Transport Layer Security (TLS) sessions—one with the target and another with the actual website the target wants to access. These sessions mean that the phishing page practically functions as an AiTM agent, intercepting the whole authentication process and extracting valuable data from the HTTP requests such as passwords and, more importantly, session cookies. Once the attacker obtains the session cookie, they can inject it into their browser to skip the authentication process, even if the target’s MFA is enabled. 

The AiTM phishing process can currently be automated using open-source phishing toolkits and other online resources. Among the widely-used kits include Evilginx2, Modlishka, and Muraena.  

Tracking an AiTM phishing campaign

Using Microsoft 365 Defender threat data, we detected multiple iterations of an AiTM phishing campaign that attempted to target more than 10,000 organizations since September 2021. These runs appear to be linked together and target Office 365 users by spoofing the Office online authentication page.

Based on our analysis, these campaign iterations use the Evilginx2 phishing kit as their AiTM infrastructure. We also uncovered similarities in their post-breach activities, including sensitive data enumeration in the target’s mailbox and payment frauds.

Initial access

In one of the runs we’ve observed, the attacker sent emails with an HTML file attachment to multiple recipients in different organizations. The email message informed the target recipients that they had a voice message.

When a recipient opened the attached HTML file, it was loaded in the user’s browser and displayed a page informing the user that the voice message was being downloaded. Note, however, that the download progress bar was hardcoded in the HTML file, so no MP3 file was being fetched.

Instead, the page redirected the user to a redirector site:

This redirector acted as a gatekeeper to ensure the target user was coming from the original HTML attachment. To do this, it first validated if the expected fragment value in the URL—in this case, the user’s email address encoded in Base64—exists. If the said value existed, this page concatenated the value on the phishing site’s landing page, which was also encoded in Base64 and saved in the “link” variable (see Figure 7 below).

By combining the two values, the succeeding phishing landing page automatically filled out the sign-in page with the user’s email address, thus enhancing its social engineering lure. This technique was also the campaign’s attempt to prevent conventional anti-phishing solutions from directly accessing phishing URLs.

Note that on other instances, we observed that the redirector page used the following URL format:

hxxp://[username].[wildcard domain].[tld]/#[user email encoded in Base64]

In this format, the target’s username was used as part of an infinite subdomains technique, which we have previously discussed in other phishing campaigns.

After the redirection, the user finally landed on an Evilginx2 phishing site with their username as a fragment value. For example:

hxxp://login[.]nmmnvvx[.]xyz/yamRSmFG#[username]@[organizationname].[tld]

The phishing site proxied the organization’s Azure Active Directory (Azure AD) sign-in page, which is typically login.microsoftonline.com. If the organization had configured their Azure AD to include their branding, the phishing site’s landing page also contained the same branding elements.

Once the target entered their credentials and got authenticated, they were redirected to the legitimate office.com page. However, in the background, the attacker intercepted the said credentials and got authenticated on the user’s behalf. This allowed the attacker to perform follow-on activities—in this case, payment fraud—from within the organization.

Post-breach BEC

Payment fraud is a scheme wherein an attacker tricks a fraud target into transferring payments to attacker-owned accounts. It can be achieved by hijacking and replying to ongoing finance-related email threads in the compromised account’s mailbox and luring the fraud target to send money through fake invoices, among others.

Based on our analysis of Microsoft 365 Defender threat data and our investigation of related threat alerts from our customers, we discovered that it took as little time as five minutes after credential and session theft for an attacker to launch their follow-on payment fraud. From our observation, after a compromised account signed into the phishing site for the first time, the attacker used the stolen session cookie to authenticate to Outlook online (outlook.office.com). In multiple cases, the cookies had an MFA claim, which means that even if the organization had an MFA policy, the attacker used the session cookie to gain access on behalf of the compromised account.

Finding a target

The following days after the cookie theft, the attacker accessed finance-related emails and file attachments files every few hours. They also searched for ongoing email threads where payment fraud would be feasible. In addition, the attacker deleted from the compromised account’s Inbox folder the original phishing email they sent to hide traces of their initial access.

These activities suggest the attacker attempted to commit payment fraud manually. They also did this in the cloud—they used Outlook Web Access (OWA) on a Chrome browser and performed the abovementioned activities while using the compromised account’s stolen session cookie.

Once the attacker found a relevant email thread, they proceeded with their evasion techniques. Because they didn’t want the compromised account’s user to notice any suspicious mailbox activities, the attacker created an Inbox rule with the following logic to hide any future replies from the fraud target:

“For every incoming email where sender address contains [domain name of the fraud target], move the mail to “Archive” folder and mark it as read.”

Conducting payment fraud

Right after the rule was set, the attacker proceeded to reply to ongoing email threads related to payments and invoices between the target and employees from other organizations, as indicated in the created Inbox rule. The attacker then deleted their replies from the compromised account’s Sent Items and Deleted Items folders.

Several hours after the initial fraud attempt was performed, the attacker signed in once every few hours to check if the fraud target replied to their email. In multiple instances, the attacker communicated with the target through emails for a few days. After sending back responses, they deleted the target’s replies from the Archive folder. They also deleted their emails from the Sent Items folder.

On one occasion, the attacker conducted multiple fraud attempts simultaneously from the same compromised mailbox. Every time the attacker found a new fraud target, they updated the Inbox rule they created to include these new targets’ organization domains.

Below is a summary of the campaign’s end-to-end attack chain based on threat data from Microsoft 365 Defender:

Defending against AiTM phishing and BEC

This AiTM phishing campaign is another example of how threats continue to evolve in response to the security measures and policies organizations put in place to defend themselves against potential attacks. And since credential phishing was leveraged in many of the most damaging attacks last year, we expect similar attempts to grow in scale and sophistication.

While AiTM phishing attempts to circumvent MFA, it’s important to underscore that MFA implementation remains an essential pillar in identity security. MFA is still very effective at stopping a wide variety of threats; its effectiveness is why AiTM phishing emerged in the first place. Organizations can thus make their MFA implementation “phish-resistant” by using solutions that support Fast ID Online (FIDO) v2.0 and certificate-based authentication.

Defenders can also complement MFA with the following solutions and best practices to further protect their organizations from such types of attacks:

• Enable conditional access policies. Conditional access policies are evaluated and enforced every time an attacker attempts to use a stolen session cookie. Organizations can protect themselves from attacks that leverage stolen credentials by enabling policies such as compliant devices or trusted IP address requirements.
• Invest in advanced anti-phishing solutions thatmonitor and scan incoming emails and visited websites. For example, organizations can leverage web browsers that can automatically identify and block malicious websites, including those used in this phishing campaign.
• Continuously monitor for suspicious or anomalous activities:
  • Hunt for sign-in attempts with suspicious characteristics (for example, location, ISP, user agent, use of anonymizer services).
  • Hunt for unusual mailbox activities such as the creation of Inbox rules with suspicious purposes or unusual amounts of mail item access events by untrusted IP addresses or devices.

Coordinated threat defense with Microsoft 365 Defender

Microsoft 365 Defender provides comprehensive protection against this AiTM phishing campaign by correlating threat data from various domains. It also coordinates threat defense against the end-to-end attack chain using multiple solutions and has advanced hunting capabilities that allow analysts to inspect their environments further and surface this threat.

Leveraging its cross-signal capabilities, Microsoft 365 Defender alerts customers using Microsoft Edge when a session cookie gets stolen through AiTM phishing and when an attacker attempts to replay the stolen session cookie to access Exchange Online:

Microsoft 365 Defender’s unique incident correlation technology also lets defenders see all the relevant alerts related to an AiTM phishing attack pieced together into a single comprehensive view, thus allowing them to respond to such incidents more efficiently:

Microsoft 365 Defender is backed by threat experts who continuously monitor the computing landscape for new attacker tools and techniques. Their expert monitoring not only helps alert customers of a possible incident (such as a potential cookie theft during an authentication session), their research on the constantly evolving phishing techniques also enriches the threat intelligence that feeds into the abovementioned protection technologies.

Microsoft Defender for Office 365 detects threat activity associated with this phishing campaign through the following email security alerts. Note, however, that these alerts may also be triggered by unrelated threat activity. We’re listing them here because we recommend that these alerts be investigated and remediated immediately.

• Email messages containing malicious file removed after delivery​. This alert is generated when any messages containing a malicious file are delivered to mailboxes in an organization. Microsoft removes the infected messages from Exchange Online mailboxes using zero-hour auto purge (ZAP) if this event occurs.
• Email messages from a campaign removed after delivery​. This alert is generated when any messages associated with a campaign are delivered to mailboxes in an organization. Microsoft removes the infected messages from Exchange Online mailboxes using ZAP if this event occurs.

Microsoft Defender for Cloud Apps detects this AiTM phishing and BEC campaigns through the following alerts:

• Suspicious inbox manipulation rule. The attackers set an Inbox rule to hide their malicious activities. Defender for Cloud Apps identifies such suspicious rules and alerts users when detected.
• Impossible travel activity. The attackers used multiple proxies or virtual private networks (VPNs) from various countries or regions. Sometimes, their attack attempts happen at the same time the actual user is signed in, thus raising impossible travel alerts.
• Activity from infrequent country. Because the attackers used multiple proxies or VPNs, on certain occasions, the egress endpoints of these VPN and proxy servers are uncommon for the user, thus raising this alert.

Azure AD Identity Protection automatically detects and remediates identity-based risks. It detects suspicious sign-in attempts and raises any of the following alerts:

• Anomalous Token. This alert flags a token’s unusual characteristics, such as its token lifetime or played from an unfamiliar location.
• Unfamiliar sign-in properties. In this phishing campaign, the attackers used multiple proxies or VPNs originating from various countries or regions unfamiliar to the target user.
• Unfamiliar sign-in properties for session cookies. This alert flags anomalies in the token claims, token age, and other authentication attributes.
• Anonymous IP address. This alert flags sign-in attempts from anonymous IP addresses (for example, Tor browser or anonymous VPN).

In addition, Continuous Access evaluation (CAE) revokes access in real time when changes in user conditions trigger risks, such as when a user is terminated or moves to an untrusted location.

Learn how you can stop attacks through automated, cross-domain security with Microsoft 365 Defender.

Microsoft 365 Defender Research Team

Microsoft Threat Intelligence Center (MSTIC)

Appendix

Indicators of compromise (IOCs)

Redirector domains

• 32sssaawervvvv[.]biz
• adminmmi[.]biz
• auth2022[.]live
• cleanifl[.]com
• docpmsi[.]us
• vrtlsrvmapp[.]biz
• vrtofcvm[.]live

Phishing site domains  

• login[.]actionspsort[.]cam
• login[.]akasmisoft[.]xyz
• login[.]aueuth11[.]live
• login[.]auth009[.]xyz
• login[.]auth2022[.]live
• login[.]auth83kl[.]live
• login[.]bittermann-hh[.]co
• login[.]cbhbanlc[.]com
• login[.]cleanifl[.]com
• login[.]clfonl365[.]xyz
• login[.]gddss36[.]live
• login[.]grodno-pl[.]com
• login[.]hfs923[.]shop
• login[.]karlandpearson[.]com
• login[.]klm2136[.]click
• login[.]login-micro[.]mcrsfts-passwdupdate[.]com
• login[.]mcrosfts-updata[.]live
• login[.]mcrosfts-update[.]cloud
• login[.]mcrosfts-update[.]digital
• login[.]mcrosftts-update[.]cloud
• login[.]mcrsft-audio[.]xyz
• login[.]mcrsfts-cloud[.]live
• login[.]mcrsfts-passwd[.]cloud
• login[.]mcrsfts-passwd[.]digital
• login[.]mcrsfts-passwdupdate[.]com
• login[.]mcrsfts-update[.]cloud
• login[.]mcrsfts-update[.]digital
• login[.]mcrsfts-virtualofficevm[.]com
• login[.]mcrsftsvm-app[.]digital
• login[.]mcrsftsvm-app[.]live
• login[.]mcrsfts-voiceapp[.]digital
• login[.]mcrsftsvoice-mail[.]cloud
• login[.]microsecurity[.]us
• login[.]microstoff[.]xyz
• login[.]mljs365[.]xyz
• login[.]mwhhncndn[.]xyz
• login[.]mycrsfts-passwd[.]live
• login[.]qwwxthn[.]xyz
• login[.]seafoodsconnection[.]com
• login[.]sunmarks[.]co[.]uk
• login[.]tfosorcimonline[.]xyz
• login[.]whitmanlab[.]uk
• login[.]yi087011[.]xyz

Advanced hunting queries  

When an attacker uses a stolen session cookie, the “SessionId” attribute in the AADSignInEventBeta table will be identical to the SessionId value used in the authentication process against the phishing site. Use this query to search for cookies that were first seen after OfficeHome application authentication (as seen when the user authenticated to the AiTM phishing site) and then seen being used in other applications in other countries:

let OfficeHomeSessionIds = 
AADSignInEventsBeta
| where Timestamp > ago(1d)
| where ErrorCode == 0
| where ApplicationId == "4765445b-32c6-49b0-83e6-1d93765276ca" //OfficeHome application 
| where ClientAppUsed == "Browser" 
| where LogonType has "interactiveUser" 
| summarize arg_min(Timestamp, Country) by SessionId;
AADSignInEventsBeta
| where Timestamp > ago(1d)
| where ApplicationId != "4765445b-32c6-49b0-83e6-1d93765276ca"
| where ClientAppUsed == "Browser" 
| project OtherTimestamp = Timestamp, Application, ApplicationId, AccountObjectId, AccountDisplayName, OtherCountry = Country, SessionId
| join OfficeHomeSessionIds on SessionId
| where OtherTimestamp > Timestamp and OtherCountry != Country

Use this query to summarize for each user the countries that authenticated to the OfficeHome application and find uncommon or untrusted ones:  

AADSignInEventsBeta 
| where Timestamp > ago(7d) 
| where ApplicationId == "4765445b-32c6-49b0-83e6-1d93765276ca" //OfficeHome application 
| where ClientAppUsed == "Browser" 
| where LogonType has "interactiveUser" 
| summarize Countries = make_set(Country) by AccountObjectId, AccountDisplayName 

Use this query to find new email Inbox rules created during a suspicious sign-in session:

//Find suspicious tokens tagged by AAD "Anomalous Token" alert
let suspiciousSessionIds = materialize(
AlertInfo
| where Timestamp > ago(7d)
| where Title == "Anomalous Token"
| join (AlertEvidence | where Timestamp > ago(7d) | where EntityType == "CloudLogonSession") on AlertId
| project sessionId = todynamic(AdditionalFields).SessionId);
//Find Inbox rules created during a session that used the anomalous token
let hasSuspiciousSessionIds = isnotempty(toscalar(suspiciousSessionIds));
CloudAppEvents
| where hasSuspiciousSessionIds
| where Timestamp > ago(21d)
| where ActionType == "New-InboxRule"
| where RawEventData.SessionId in (suspiciousSessionIds)

The post From cookie theft to BEC: Attackers use AiTM phishing sites as entry point to further financial fraud appeared first on Microsoft Security Blog.

As it is with many of pre-installed or default applications that most Android devices come with these days, some of the affected apps cannot be fully uninstalled or disabled without gaining root access to the device. We worked with mce Systems, the developer of the framework, and the affected mobile service providers to solve these issues. We commend the quick and professional resolution from the mce Systems engineering teams, as well as the relevant providers in fixing each of these issues, ensuring that users can continue using such a crucial framework.

Collaboration among security researchers, software vendors, and the security community is important to continuously improve defenses for the larger ecosystem. As the threat and computing landscape continues to evolve, vulnerability discoveries, coordinated response, and other forms of threat intelligence sharing are paramount to protecting customers against present and future threats, regardless of the platform or device they are using.

Uncovering the vulnerabilities

Our research on the framework vulnerabilities began while trying to better understand how a pre-installed System application could affect the overall security of mobile devices. We discovered that the framework, which is used by numerous apps, had a “BROWSABLE” service activity that an attacker could remotely invoke to exploit several vulnerabilities that could allow adversaries to implant a persistent backdoor or take substantial control over the device.

The framework seemed to be designed to offer self-diagnostic mechanisms to identify and resolve issues impacting the Android device, indicating its permissions were inherently broad with access to valuable resources. For example, the framework was authorized to access system resources and perform system-related tasks, like adjusting the device’s audio, camera, power, and storage controls. Moreover, we found that the framework was being used by default system applications to leverage its self-diagnostic capabilities, demonstrating that the affiliated apps also included extensive device privileges that could be exploited via the vulnerable framework.

According to mce Systems, some of these vulnerabilities also affected other apps on both Android and iOS devices. Moreover, the vulnerable framework and affiliated apps were found on devices from large international mobile service providers. mce Systems, which offers “Mobile Device Lifecycle and Automation Technologies,” also permitted providers to customize and brand their respective mobile apps and frameworks. Pre-installed frameworks and mobile apps such as mce Systems’ are beneficial to users and providers in areas like simplifying the device activation process, troubleshooting device issues, and optimizing performance. However, their extensive control over the device to deliver these kinds of services could also make them an attractive target for attackers. 

Our analysis further found that the apps were embedded in the devices’ system image, suggesting that they were default applications installed by phone providers. All of the apps are available on the Google Play Store where they go through Google Play Protect’s automatic safety checks, but these checks previously did not scan for these types of issues. As part of our effort to help ensure broad protection against these issues, we shared our research with Google, and Google Play Protect now identifies these types of vulnerabilities.

We initially discovered the vulnerabilities in September 2021 and shared our findings with mce Systems and affected mobile service providers through Coordinated Vulnerability Disclosure (CVD) via Microsoft Security Vulnerability Research (MSVR). We worked closely with mce Systems’ security and engineering teams to mitigate these vulnerabilities, which included mce Systems sending an urgent framework update to the impacted providers and releasing fixes for the issues. At the time of publication, there have been no reported signs of these vulnerabilities being exploited in the wild.

The high-severity vulnerabilities, which have a Common Vulnerability Scoring System (CVSS) score of 7.0-8.9, are now identified as CVE-2021-42598, CVE-2021-42599, CVE-2021-42600, and CVE-2021-42601. We want to thank mce Systems’ engineering teams for collaborating quickly and efficiently in resolving these issues as well as to AT&T for proactively working with Microsoft to ensure customers can safely continue to use the framework.

Several other mobile service providers were found using the vulnerable framework with their respective apps, suggesting that there could be additional providers still undiscovered that may be impacted. The affected providers linked below have made updated app versions available to users before this disclosure, ensuring devices can be protected before these vulnerabilities could be exploited. We encourage these providers’ customers to update to the latest versions of these apps from the Google Play store, which include but are not limited to: com.telus.checkup, com.att.dh, com.fivemobile.myaccount, com.freedom.mlp,uat, and com.ca.bell.contenttransfer.

Additionally, the package com.mce.mceiotraceagent might be installed by several mobile phone repair shops. Mobile users are advised to look for that app name and remove it from their phone, if found.

Analyzing apps that use the mce framework

App manifest and permissions

When analyzing an Android application, the first thing that comes to mind is checking its manifest, maintained under the AndroidManifest.xml file. The manifest describes the application itself and its components, such as the following:

• Permissions (for example, camera access, internet access, and others)
• Activities and how they respond to Intents sent to them
• Content providers
• Receivers and the kind of content they expect to receive
• Services

Checking the manifest of an app affiliated with mce Systems’ framework shed light on some of its features and capabilities but did not immediately indicate that any vulnerabilities or security issues were present. Therefore, further research into the app’s functionality was needed by understanding its permissions.

Analysis of the app’s permissions on the mobile device revealed authorizations that could lead to powerful access and capabilities for an attacker. Those permissions included control over the following:

• Networking: access the internet, modify Wi-Fi state, network state, NFC, and Bluetooth
• File access: read and write to the external storage
• Peripherals: access the camera, record audio, get fingerprint information, and get the device’s physical location
• Private information: read phone numbers, account information, and contacts
• Management: install apps and modify device settings

With access to these valuable resources, the app could be abused by an attacker to implant a persistent backdoor on the device.

BROWSABLE activities

The “Activities” section of the app’s manifest detailed that the Intent-filter element included activities with a “BROWSABLE” category. While most Intents do not require a category, category strings detail the components that should handle the Intent. In particular, the BROWSABLE category allows the target Activity to be triggered from a web browser to display data referenced by a link, like an image. BROWSABLE activities appeal to attackers as the latter can exploit them via malicious web pages and other Intent-based attacks.

The Intent-filter element in the manifest dictates how the Activity can be triggered. In the app’s case, the Activity could be triggered by simply clicking a link with the “mcedigital://” scheme. This would start the com.mce.sdk.AppActivity Activity with an Intent with arbitrary data (besides the scheme).

Digging deeper: Reviewing the mce framework’s main functionality

We reviewed the effects of triggering the com.mce.sdk.AppActivity. Also known as appActivity, this Activity refers to the different functionalities provided by the app. AppActivity extends Activity and therefore has an onCreate method, which traditionally handles the creating Intent.

AppActivity

Here’s a brief description of AppActivity:

1. AppActivity has a member called “webView” and type “JarvisWebView,” a specialized class that extends WebView.
2. Upon creation, AppActivity has some optional display choices from the Intent (if they exist) and then loads a predefined web page to the WebView. That predefined page can get arbitrary query parameters from the Intent’s data; that is, everything after a “\?” will be added to the web page.

Thus, if a user clicks this:

mcedigital://ignored\?arbitrary_params

The App’s WebView loads the following web page:

file:///android_asset/applications/user/reflow-container-bundled/index.html?arbitrary_params

The app’s index.html web page (which is an asset built into the Android app) loads two JavaScript files:

• config.js: a nonexistent file
• bundle.js: contains much of the app’s logic

Since we wanted to understand the interplay between bundle.js (JarvisJSInterface) and the WebView (JarvisWebView), we analyzed both.

JarvisWebView and JarvisJSInterface

The main features of the WebView, JarvisWebView class, are the following:

• It allows JavaScript (with setJavaScriptEnabled)
• It allows cross-scripting deliberately (with setAllowUniversalAccessFromFileURLs)
• It exposes a JavascriptInterface (with addJavascriptInterface) called JarvisJSInterface

A JavaScript Interface is a conspicuous target to look for security issues, as it uses a JavaScript Bridge to allow invoking specific methods inside an Android app. In the case of JarvisJSInterface, three methods are exported:

• init(String): takes a string that will be used as a JavaScript callback method; in our case, it will always be window.AndroidCallback
• windowClose(): runs a callback registered by the Android app
• request(String): sends a service request from the JavaScript client to the server (Android app)

The request method is by far the most interesting, as it performs the following:

1. Interprets the given string as a JSON object
2. Extracts the following pieces from the JSON object:
   • Context: a random GUID generated by the client, used to link requests and responses
   • Service: the service we are about to call to
   • Command: an integer
   • Data: optional parameters sent to the service call
3. Invokes the method serviceCall, which finds the registered service, gets the method based on the command number, and eventually invokes that method using Java reflection

The serviceCall is a powerful method, as it allows the WebView to invoke “services” freely. But what are these services, exactly?

Services offered by the mce framework

After we examined the services offered by this framework per the app manifest, we then obtained a list of services that practically give the WebView complete control over the device. The most notable services include:

• Audio: access and manipulate volume levels, as well as play a tone with a given duration and frequency
• Camera: take a silent snapshot
• Connectivity: control and obtain valuable information from NFC, Wi-Fi, and Bluetooth
• Device: includes various device controlling mechanisms like battery drainage, performing a factory reset, and obtaining information on apps, addresses, sensor data, and much more
• Discovery: set the device to discoverable
• Location: obtain the location in various modes and set the location state
• PackageManager: acquire package info and silently install a new app
• Power: obtain charging state
• Sensor: acquire sensor data such as barometer data, light data, proximity data, and whether fingerprinting is working
• Storage: obtain content such as documents, media, images, and videos

These services inherit from a base class named “Service” and implement two methods:

• setServiceName: for service identification purposes
• setServiceMethodMap: for setting up the mapping between the command integer and the method name, argument names, and argument types

For example, here is the Camera service setting its methods:

• Method 0 is “getCameraList” and expects no arguments.
• Method 1 is “captureStillImageNoPreview” and expects one String argument.

Vulnerability findings

Based on our analysis of the mce framework, we discovered several vulnerabilities. It should be noted that while mobile service providers can customize their apps respective to mce framework so as not to be identical, the vulnerabilities we discovered can all be exploited in the same manner—by injecting code into the web view. Nonetheless, as their apps and framework customization use different configurations and versions, not all providers are necessarily vulnerable to all the discovered vulnerabilities.

Outdated command-injection vulnerability (CVE-2021-42599)

We found a command-injection vulnerability, tracked as CVE-2021-42599, in the Device service mentioned in the previous section. This service offers rich functionality, including the capability to stop activities of a given package. The client fully controls the argument “value,” and simply runs the following command:

am force-stop "value"

Since the argument is not sanitized, an attacker could add backticks or quotation marks to run arbitrary code, like the following:

am force-stop "a"; command-to-run; echo "a"

According to mce Systems, they have since removed the functionality behind this vulnerability and it is no longer present in more advanced framework versions.

Exploitation by JavaScript injection with PiTM in certain apps

The services offered by the mce framework further indicated that the following vulnerability resided in the logic of the JavaScript client for apps that are configured to enable plaintext communications such as the app that we initially analyzed. Interestingly, the code for the client is a heavily-obfuscated dynamic JavaScript code that is implemented over several files, mainly bundle.js. Due to the blind trust between the JavaScript client and the JarvisJSInterface server, an attacker who could inject JavaScript contents into the WebView would inherit the permissions that the app already has.

We conceived two injection strategies most likely to be leveraged by attackers:

1. Affect the JavaScript client behavior by supplying specific GET parameters from the BROWSABLE Intent.
2. Trigger an app with the BROWSABLE Intent to become an adversary-in-the-middle (AiTM) and view the device’s entire traffic. Inject JavaScript code if the client ever tries to fetch external content and interpret it as a script or HTML.

Once we reverse-engineered the client’s obfuscated code, we discovered that it could not inject JavaScript from the GET parameters. The only capability permitted was to affect some of the client’s self-tests upon initialization, such as a battery-draining test or a Wi-Fi connectivity test. However, the WebView-fetched plaintext pages that we discovered could be injected into with a PiTM attack.

Our proof-of-concept (POC) exploit code was therefore:

1. Perform a PiTM for the target device and lure the user into clicking a link with the “mcesystems://” schema.
2. Inject JavaScript into one of the plaintext page responses that does the following:
   • Hijack the JavaScript interface by calling init with our callback method
   • Use the JavaScript interface request method to get servicing
   • Send the data to our server for information gathering using XHR (XMLHttpRequest)

Local elevation of privilege with deserialization followed by injection (CVE-2021-42601)  

Some of the apps we analyzed did not pull plaintext pages. Thus, we looked for a local elevation of privilege vulnerability, allowing a malicious app to gain the system apps’ privileges, tracked as CVE-2021-42601.

In the apps mentioned above, we discovered that the main Activity attempted to handle a deep link (a link that launches an app instead of a browser on click) with Google Firebase. Interestingly, this deep-link handling tried to deserialize a structure called PendingDynamicLinkData (representing a link) from an Intent Extra byte array with the key com.google.firebase.dynamiclinks.DYNAMIC_LINK_DATA. This structure was used later by the mce framework to generate various JSON Objects that might contain data from a categoryId query parameter in the original link, and eventually ended up in the member mFlowSDKInput to be injected into the JarvisWebView instance in an unsafe way:

Since the categoryId query parameter might contain apostrophes, one could inject arbitrary JavaScript code into the WebView. We decided to inject a code that would reach out to a server and load a second-stage code, which was the exact one we used for our PiTM scenario.

Software design against JavaScript injection vulnerabilities

We worked closely with the mce Systems engineering team and discovered that the reason for unsafe loadUrl invocations with JavaScript injections was that the framework used an asynchronous model of operation. When the JavaScript client performs a request, it expects to be notified later when there are results. Since Android JavaScript Bridge only allows primitive types to be sent (for example, Strings), the mce framework notified the JavaScript client by injecting JavaScript with potentially unsafe arguments (the results themselves).

We offered mce Systems a slightly different software design that prevents unsafe JavaScript injection. The description of the flow of information in our proposal is as follows:

1. The JavaScript client invokes the request method on the Android JavaScript Bridge, supplying the request itself along with a request ID.
2. The Java server performs the request and stores the result in a cache. The said cache then maps request IDs to results.
3. The Java server notifies the client by carefully injecting the JavaScript loadUrl(“javascript:window.onMceResult(<requestID>);”) into the WebView. Note that the only non-constant string is the request ID, which can easily be sanitized. This method “wakes the client up”
4. The JavaScript client implementation of onMceResult invokes the Android JavaScript Bridge with the method String fetchResult(String requestId). Note that this method returns a string (which contains the result).

This way, the JavaScript client does not need to poll for asynchronous results while data is safely transferred between the client and the server.

Interestingly, Google AndroidX offers a very similar API: webMessageListener. While the said API works quite similarly to our suggestion, it only supports Android versions greater than Lollipop. Thus, the new mce framework now checks the Android version and uses this new Google API if supported or our offered solution for older devices.

The above is just one example of our collaboration to help secure our cross-platform ecosystem. According to mce Systems, all of our reported vulnerabilities were addressed.

Improving security for all through threat intelligence sharing and research-driven protections

Microsoft strives to continuously improve security by collaborating with customers, partners, and industry experts. Responding to the evolving threat landscape requires us to expand our capabilities into other devices and non-Windows platforms in addition to further coordinating research and threat intelligence sharing among the larger security community. This case highlighted the need for expert, cross-industry collaboration to effectively mitigate issues.

Moreover, collaborative research such as this informs our seamless protection capabilities across platforms. For example, intelligence from this analysis helped us ensure that Microsoft Defender Vulnerability Management can identify and remediate devices that have these vulnerabilities, providing security operations teams with comprehensive visibility into their organizational exposure and enabling them to reduce the attack surface. In addition, while we’re not aware of any active exploitation of these mobile vulnerabilities in the wild, Microsoft Defender for Endpoint’s mobile threat defense capabilities significantly improve security on mobile devices by detecting potential exploits, malware, and post-exploitation activity.

We will continue to work with the security community to share intelligence about threats and build better protection for all. Microsoft security researchers continually work to discover new vulnerabilities and threats, turning a variety of wide-reaching issues into tangible results and improved solutions that protect users and organizations across platforms every single day. Similarly inquisitive individuals are encouraged to check opportunities to join the Microsoft research team here: https://careers.microsoft.com/.  

Jonathan Bar Or, Sang Shin Jung, Michael Peck, Joe Mansour, and Apurva Kumar
Microsoft 365 Defender Research Team

The post Android apps with millions of downloads exposed to high-severity vulnerabilities appeared first on Microsoft Security Blog.