Microsoft has observed campaigns misusing legitimate file hosting services increasingly use defense evasion tactics involving files with restricted access and view-only restrictions. While these campaigns are generic and opportunistic in nature, they involve sophisticated techniques to perform social engineering, evade detection, and expand threat actor reach to other accounts and tenants. These campaigns are intended to compromise identities and devices, and most commonly lead to business email compromise (BEC) attacks to propagate campaigns, among other impacts such as financial fraud, data exfiltration, and lateral movement to endpoints.
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.
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:
An example attack chain is provided below, depicting the updated defense evasion techniques being used across stages 4, 5, and 6:
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:
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:
These techniques make detonation and analysis of the sample with the malicious link almost impossible since they are restricted.
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.
Microsoft recommends the following mitigations to reduce the impact of this threat:
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.
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.
| Application | Action type | Description |
| OneDrive/ SharePoint | AnonymousLinkCreated | Link created for the document, anyone with the link can access, prevalence is rare since mid-April 2024 |
| SharingLinkCreated | Link created for the document, accessible for everyone, prevalence is rare since mid-April 2024 | |
| AddedToSharingLink | Complete list of users with whom the file is shared is available in this event | |
| SecureLinkCreated | Link created for the document, specifically can be accessed only by a group of users. List will be available in the AddedToSecureLink Event | |
| AddedToSecureLink | Complete list of users with whom the file is securely shared is available in this event | |
| Dropbox | Created shared link | A link for a file to be shared with external user created |
| Added shared folder to own Dropbox | A shared folder was added to the user’s Dropbox account | |
| Added users and/or groups to shared file/folder | These action types include the list of external users with whom the files have been shared. | |
| Changed the audience of the shared link | ||
| Invited user to Dropbox and added them to shared file/folder |
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:
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:
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.
Microsoft Threat Intelligence continues to track and disrupt malicious activity attributed to a Russian state-sponsored actor we track as Star Blizzard, who has continuously improved their detection evasion capabilities while remaining focused on email credential theft against targets.
Microsoft Threat Intelligence has observed Storm-1811 misusing the client management tool Quick Assist to target users in social engineering attacks that lead to malware like Qakbot followed by Black Basta ransomware deployment.
Microsoft Threat Intelligence presents cases of threat actors misusing OAuth applications as automation tools in financially motivated attacks.
Microsoft Defender Experts observed a multi-stage adversary-in-the-middle (AiTM) and business email compromise (BEC) attack targeting banking and financial services organizations over two days. This attack originated from a compromised trusted vendor, involved AiTM and BEC attacks across multiple supplier/partner organizations for financial fraud, and did not use a reverse proxy like typical AiTM attacks.