Welcome to the world of social engineering attacks, where the hacker’s weapon of choice isn’t complex code or sophisticated malware (at least for now), but rather a subtle art of manipulation. Instead of finding a weak point in your systems, attackers know that the weakest link in the chain isn’t the code – it’s us, the humans behind the screens.
In this article, I would like to discuss one of these techniques, so that further awareness can be spread about a masking and evasion technique that can change the perception of what files are considered safe. I intend to take a purple team approach regarding this issue that will highlight how attackers may try to abuse the issue and how users can protect themselves.
Understanding what Unicode phishing is
Before we dive further into this issue you must have a basic understanding of what Unicode phishing is. If you use modern technology like email, then you’re probably like most of us who are receiving daily message attempts from somebody trying to sell you something. Sometimes, an email may slip through the filters where an attack is trying to send you a malicious link. Of course, most users are aware enough to confirm if it’s a valid link, due to the numerous HR trainings that they had to complete. This constant cat-and-mouse game has led attackers to develop tricks that will fool users into believing that the domain is valid. For example, the attackers have figured out how to use Unicode characters to create believable Homoglyph domains.
Homoglyphs are letters or characters that look similar. For example, the character “a” looks similar to the character “ä”, which is often used in the German language. Unicode is a unique code assigned to characters so that any platform or program can understand and parse them. For example, the Unicode character for the letter “a” is U+0061, and the letter “ä” is U+00E4. The combination of Unicode characters lets us create a dangerous copy of domains, that users will often not spot (especially when using smaller fonts etc.). An example would be:
https://www.collectingflags.com turns into https://www.cöllectingflags.com
This is not a new trick, but it’s an effective technique. Fortunately, email filters and other protection mechanisms have caught on to these malicious tricks, which is why you often see filter rules implemented for Cyrillic and Unicode characters. Unfortunately, other variations of this attack can make for dangerous spear phishing attempts within your environment. The cause of this vulnerability could be a simple direction change that your users never saw coming.
Understanding the Right-To-Left-Override character.
The Right-To-Left-Override character (also known as RTLO) is a Unicode character that users need to be aware of. The RTLO character maps to Unicode U+202E and forces the machine to start reading text from a right-to-left direction vs what most English speakers are used to. The legitimate use case for this character is when users want to communicate in another language that utilizes this style/direction of writing (Arabic and other languages).
Unless the RTLO character is filtered out in an application, then it will be displayed as a blank character that is invisible to the human eye. Your computer, however, will follow the instructions and construct the link the way it was intended by the attacker.
Unfortunately, that makes for a dangerous Unicode phishing attack that can be used for domains. Let’s take the domain GEPJ.net as an example. Most users would most likely never click on a suspicious-looking domain, but if we switch things around, then gepj.net turns into Ten.jpeg. Do you think your users would click on the following?
https://www.CollectingFlags.com/OurTopEmployees/Ten.jpeg
Some users may argue that gepj.net/seeyolpmEpoTruO/moc.sgalFgnitcelloC.www//:sptth may not be the safest link to follow, but like most social engineering attempts it will be too late for the User before they notice.
While these RTLO domains can be a real danger to your users, the mitigating factor is often that modern browsers will identify and sanitize the character. That means that the domain will either not load, or the user has a chance to spot the real domain (gepj.net)
Unfortunately, that is not where the real danger stops. Let’s talk about escalating this issue from a Red Team perspective.
A well documented attack path
While creating phishing links with the RTLO character is a pretty dangerous way of using it, I want to take some time and discuss how the same character can be used for a more dangerous variation of this attack. If the RTLO character is not sanitized, then it can be used within the Windows operating system to spoof file extensions. This can present an opportunity for attackers to deliver a C2 beacon (or other malware) in the form of a seemingly harmless file extension like a PDF.
The RTLO character has no restriction on when it’s being placed into a text string, so attacks can inject the character right before the file extension is added within a filename. That can create some creative file extensions like Instructions_For_Raj.pdf, which is a malicious JAR file that was masked as a PDF file.
The RTLO technique has been around for a long time and has been well recorded by MITRE Att&ck as T1036.002 The technique has also been exploited in the wild, which can be seen in the table below (source MITRE).
| ID | Name | Description |
|---|---|---|
| G0098 | BlackTech | BlackTech has used right-to-left-override to obfuscate the filenames of malicious e-mail attachments.[4] |
| G0060 | BRONZE BUTLER | BRONZE BUTLER has used Right-to-Left Override to deceive victims into executing several strains of malware.[5] |
| G0137 | Ferocious Kitten | Ferocious Kitten has used right-to-left override to reverse executables’ names to make them appear to have different file extensions, rather than their real ones.[6] |
| G0004 | Ke3chang | Ke3chang has used the right-to-left override character in spearphishing attachment names to trick targets into executing .scr and .exe files.[7] |
| G0029 | Scarlet Mimic | Scarlet Mimic has used the left-to-right override character in self-extracting RAR archive spearphishing attachment file names.[8] |
Bypassing Multiple Layers of Defense Mechanisms
The Microsoft team has implemented multiple defense layers into the Office 365 environment that attempt to prevent this type of behavior, which users should be aware of when exploring this exploitation technique further.
First of all, Sharepoint and OneDrive utilize their own AV solution, which is highlighted in this article: https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/anti-malware-protection-for-spo-odfb-teams-about?view=o365-worldwide
There are a few important points that should be highlighted from the article:
- Microsoft recognized that this is a single layer of the defense and recommends that additional AV’s should be used in local environments.
- After the file is marked as malware, the user can’t open the synced file from their local machine.
- All file types are not automatically scanned. Heuristics determine the files to scan
- Safe Attachments for SharePoint, OneDrive, and Microsoft Teams also helps detect and block existing files that are identified as malicious in team sites and document libraries.
Microsoft also highlights that additional protection features are available, however additional licensing is required for Sharepoint/Teams safe attachments
Consumers may need to consider security vs cost, especially with Microsoft announcing that Teams is being separated into its own Office 365 license (adding additional base cost for businesses to use the product).
File delivery through trusted channels.
While the RTLO character can be used as a dangerous trick, it’s only useful if an application is found in the environment that does not sanitize the character. Modern email clients like Outlook will filter out these characters and if the file is delivered through a web browser, then the Unicode character will be sanitized, so that the real file extension is revealed. That is when attackers can use alternate, but still trusted communication channels to deliver these malicious messages.
One of those identified channels is the Microsoft Office 365 environment. Testing the sites further showed that the Microsoft Office 365 environment (not just Microsoft Teams) does not sanitize the RTLO character, which can create a dangerous combination of Unicode spoofing attacks that are not caught on the majority of the product pages. The below screenshot shows that behavior with an HTA file that has been designed to deploy custom PowerShell commands once executed by a User.
The ability to spoof file extensions creates a perfect environment for spear phishing through trusted channels when inside of an organization. It’s important to understand that Microsoft Team is powered by multiple Microsoft products to provide different capabilities to their User base. When we create a team in Teams, on the backend, we’re creating an Office 365 Group and the associated SharePoint document library and OneNote notebook, along with ties into other Office 365 cloud applications.
The architecture diagram released by Microsoft gives a further insight into the overall integration of different applications through the Microsoft Teams client
That means that you may be communicating through Teams client, but your files are stored on Microsoft Sharepoint. One of the primary idea’s behind using Sharepoint for document storage is the fact that it’s set up to offer collaboration between users. Since the library is created for a group, the intended purposes is to provide those users with a central location to sync those files to their local machine. The Teams desktop application makes the interaction between the apps and the operating system fairly flawless, which can be seen in the below screenshot. If the User selects the ‘Open in app’ option, then the file is synced down into a temporary OneDrive folder. An alternative option is for users to sync the whole document library to your machine.
If you sync these files down to your local machine, then the OneDrive client is used, which comes pre-installed on most modern Windows machines. In most cases, the OneDrive client provides the User with a security prompt to confirm that the file is being opened from a trusted location. It’s important for users to realize that the warning prompt itself carries the RTLO injection flaw and will display the spoofed file extension.
Out of the seven different applications that were listed in the architecture diagram provided by Microsoft, five failed to sanitize the RTLO character for file uploads. It should be noted that not all of the applications offer OneDrive/Sharepoint sync services, which reduces the risk of the attack succeeding due to the fact that the true file extension will be revealed (due to character sanitation in browsers) when the file is downloaded. Browsers will usually remove the character during the download, or will display that value of the RTLO character as %E2%80%AE. Users should still be careful about executing these files, but the overall detection is much easier.
If the file is first synced through Microsoft Teams utilizing the OneDrive client, then the RTLO character remains and the spoofed file extension delivery will not be noticed. This can then turn into an interesting lateral movement option for attackers, since Microsoft O365 groups often reach a wide audience to enable easy file sharing between users. RTLO injected files like C2 beacons or ransomware will then apply their own techniques to stay undetected from local AV solutions.
Does this impact both internal and external users?
This RTLO file extension spoofing issue is currently impacting both internal and external users. External users are usually restricted from specific actions, but it should be noted that it’s possible to target users with the RTLO flaw through Teams Meetings. That means that even if you’re not part of the organization, you can still receive files with the spoofed file extension through the the chat function (when the file is first linked through Sharepoint).
The above mentioned protections do provide users with an extra layer of security, due to the fact that the RTLO character would be sanitized when the file is downloaded through a web browser (or converted to %E2%80%AE to reveal the file extension). It’s still important that users are aware of this flaw, so that they can be extra careful when having these kinds of interactions.
Dropping out of the Clouds: Disclaimer
The Microsoft Security Response Center has asked for clarification that the escalation of this technique requires that an attacker has already gained malicious access to an organization. This is due to the permission requirements that are needed for some of the below techniques to properly function (the ODOpen://sync command specifically). The technique presented here is to highlight how C2 communication channels can be established using the OneDrive client and how it can aid attackers with exfiltrating data.
Unfortunately, the fact that Unicode injected characters are not sanitized can assist attackers with creating a more believable payload, that will then increase the chance of attackers succeeding with these lateral movement attempts through an organization. While there is a way to target external users with a file extension spoofing link, the real danger from this technique occurs when somebody is trying to spread out across the organization.
There are a few additional points that should be noted about the behavior of files in Microsoft Teams, specifically when it comes to icons. The Microsoft Teams client does not display custom icon’s that have been set for files. Instead it determines the icon to display based on the file extension that has been uploaded to the document library.
I am not aware of a vulnerability that allows the spoofing of these icons, but I want to highlight that spoofed icons can transfer once synced. There are programs out there like PS2EXE that allow for the customization of icon files that an executable displays. A majority of Users establish a trust with icons used by well known brands, which attackers can abuse in attempts to evade user detection.
If a malicious file is injected into the Microsoft Teams/Sharepoint environment and then opened/synced through OneDrive, then the spoofed RTLO file extension remains. The Icon for the file is generic while cloud synced, but is changed once the file is locally available (it has been executed by the user).
While User interaction is required, file delivery can also occur without warning prompts for users within the organization (external users will be presented with a permission issue), by abusing the Microsoft Teams trust in OneDrive associated protocol handlers. Think of protocol handlers as the go-betweens links for different apps or systems (a more in depth break down is available in my previous article). An easy example (if you’re on Windows) is to type in calculator:// into your browser bar and then hit enter, which will start the Calculator application on your machine. This an intended behavior that allows application to provide easier interactions between each other. For security reasons, Browsers will provide a prompt that confirms if you meant to start the application to prevent abuse. Unfortunately, desktop applications sometimes do not have the same protections, like we saw in recent examples of Microsoft’s MSDT (CVE-2022-30190) vulnerability. That is where the ODOPEN:// OneDrive protocol handler comes into play during RTLO file delivery with the Microsoft Teams desktop client.
Since Teams uses Sharepoint document libraries in the background, let’s take a closer look at that behavior. Sharepoint document libraries offer the option to sync whole libraries to your machine by using the OneDrive client, which is really triggered through invoking the odopen:// link. If you want to see the specific URL for the sync connection, then that can be extracted from Sharepoint Document Libraries by opening up your browsers developer tools > network. The link will then appear once the ‘Sync’ button has been clicked to invoke the ODOpen command (which presents a prompt in the browser that can be seen below).
The odopen:// protocol handler is important to the file delivery process, because Microsoft Teams attempts to protect itself against these types of attacks. Sometimes third party protocol handlers can carry security vulnerabilities, which can then lead to code execution that can be triggered through clickable links in the desktop application (CVE-2023-42222 ). That is why only specific protocol handlers have been allowed within the Microsoft Teams client, since they are internal products or approved 3rd party software that provides additional value to the User. The allowed protocols can in this case be discovered through the web browser, but this time we will have to trigger a disallowed protocol handler from Microsoft Teams. If we try to launch a disallowed protocol, then the warning console will disclose which protocols are actually allowed.
The prompt confirms that odopen:// is allowed to launch from the application, however another behavior has to be noticed to bypass the security prompts within Microsoft Teams. The odopen:// handler has a few different commands that behave different depending on how they’re called from the application. The difference is fairly simple, but it’s an important one to notice from an attackers perspective.
- The odopen://openfile? command in Teams is tied to the button that allows us to sync one specific file from the ‘Files section (like we saw earlier by clicking on open > open in app)
- odopen://sync lets us sync the whole folder for the library (the ‘sync’ button in Teams).
If file delivery is the main goal, then both will accomplish that task from a attackers perspective, but there are two important differences between the commands.
- The odopen://openfile? command will trigger the warning prompt that notifies users to only open file from source location.
- odopen://sync option syncs the whole document library, including any files that may be added at a later time.
The video below highlights the different security prompt behaviors between odopen://openfile and odopen://sync:
The ODOpen://sync command does have a valid and documented use, but in this case it can create a dangerous condition for the user. The command is used by admins to auto configure sync connections to Sharepoint sites, but it can be triggered in unintended ways through the the Microsoft Teams desktop application. If your users are unaware, then this behavior can lead to them potentially syncing malicious files with spoofed RTLO file extensions. Even worse, the sync connection can then establish a way to exfiltrate data that may not be noticed.
Using ODOPEN:// for RTLO file delivery
Like mentioned earlier, there are ways that attackers can trigger the file sync without requiring much user interaction. While Teams attempts to protect itself against cross-site scripting and other similar attacks, it doesn’t always limit its own products fully. Users can create a Microsoft Teams website tab that redirects to an attacker controlled site, which will then trigger the file sync.
The attacker controlled 3rd party page will then trigger a PHP redirect to the OneDrive URI, which causes the user to sync the files without any additional warning prompts. If the user navigates to the newly synced folder, then the RTLO character will remain to spoof the file extension.
Further testing of the behavior shows that files like EXE’s will trigger protections against RTLO injections in the form of a security pop up and quarantining of the file, but other file extensions like HTA could be used to cause malicious actions or trigger code, while carrying spoofed file extensions. The file execution still requires user interaction, but the attack can be more believable using a more trustable file extension like PDF or HTML.
In the video below you can see what the web behavior is like vs the Desktop application, which allows the sync due to the odopen:// URI being trusted. Additionally you can see how Microsoft Defender attempts to validate the redirect, but then still allows it to trigger the OneDrive sync with the malicious file. To be fair, the tab does show a disclaimer to be careful about trusting the content, but users may be caught off guard by the fact that the interaction is allowed in the first place (in the otherwise secure desktop application). Domains can also be spoofed, which can install a false sense of trust, even with the banner visible.
Unwatched channels lead to attack surface expansion
The danger behind being able to deceive users into auto syncing SharePoint sites during spear phishing attempts, is that it establishes a communication channel that may not be noticed by common protections. Other buttons in Microsoft Teams that will trigger the file sync action will show a warning prompt, but this seems to have been missed for ODOpen auto sync capability. File delivery through a trusted programs like Microsoft Teams, OneDrive and SharePoint can then lead to a dangerous combination for the user.
Related security research by Netskope backs up the concern of OneDrive abuse in the cloud space and it’s potential for malware delivery to users. While their research concentrated on the Japanese region specifically, the article also highlights the overall statistics for OneDrive and SharePoint malware delivery compared to other cloud solutions.
Microsoft OneDrive takes the top spot for the most malware downloads. In general, adversaries abuse Microsoft OneDrive because it is the most popular cloud storage app. Meanwhile, people who regularly use Microsoft OneDrive are more likely to click on links to download files shared with them on that platform. Therefore, the number of malware downloads that Netskope detects and blocks from Microsoft OneDrive is both a reflection of adversary tactics (abusing OneDrive to distribute malware) and victim behavior (their likelihood to click on the links and download the malware).
https://www.netskope.com/netskope-threat-labs/threat-labs-report-japan-april-2024
Again, this case presents an interesting opportunity for attackers to gain control through the sync between the applications (Sharepoint and OneDrive). The individual file permission control in folders by an attacker means that file names can appear or disappear from your OneDrive folder (once synced). That may not sound too malicious initially, but having that kind of control can provide an unmonitored entry point for an attacker. This behavior can unfortunately enable Command-And-Control infrastructure as described in related security researched released by Trellix The article gives a scary insight into how similar kind of attacks are already being abused by APTs in the wild to run multi-stage espionage operations on government officials.
Once the sync has been established through the previously described steps, dropping files (or removing them) into the the library is fairly easy for an attacker. If the User syncs the attacker controlled Document Library through OneDrive, then they will also sync the new files as they’re dropped into the library by the attacker. If the attacker wants to remove the file from the sync folder, then they have to either stop sharing the file or delete it through their connection.
While the next part of the attack-chain requires user interaction by executing an executable (or being compromised otherwise),the RTLO file delivery can aid with unfortunately exactly that by spoofing extensions for untrusted files.
This related research had me curious to explore this technique more, which is when I created ODCheck. (https://github.com/itssixtyn3in/ODCheck)
The PowerShell based tool functions as a proof-of-concept solution that will start monitoring a persons OneDrive folder for local sync activity once activated. The behavior of this tool is a bit different from other APT solutions, which use the Microsoft GraphAPI for communication and require some more advanced/expensive tools like CobaltStrike. While these tools have their own benefit for offensive security professionals, I wanted to come up with a solution that could provide wider availability and awareness about this attack path for security teams. Having a standalone executable also provides the option to explore the delivery using the RTLO character using file extensions that are seen as less malicious.
Once the targeted user activates the client, ODCheck will display a decoy timer, while also triggering a background job that runs commands based on the file names that it detects within the newly synced SharePoint folder (in case that the timer is closed by the user). That means that an attacker can control local actions of the infected User simply by dropping files into a SharePoint library that is under his control. When a specific filename is detected, then the mapped commands are run to enable further enumeration and control of the system. This can give an attacker the situational awareness, that may be needed to decide if they want to move forward with the exploitation attempt of the host, before deploying other C2 beacons. ODCheck can also attempt to run externally hosted PowerShell scripts, which allows establishing persistence and further customization.
Some of the default built in commands are as follows:
- Retrieve information about multiple Windows privilege escalation vectors.
- Trigger your preferred reverse shell command.
- Trigger CVE-2023-32214 on the machine for a DOS like condition.
- Attempt to run a PowerShell script from a remote location.
- Move a file out of the OneDrive folder into other local folders (for DLL injections etc)
It should also be noted that ODCheck places the output of each command into the OneDrive folder that was previously synced, which enables the retrieval of the enumerated information by an remote attacker. If the command runs, then an attacker can then simply wait for the new files with the content to appear in the folder. The below demo shows the full attack chain using ODCheck on a fully updated Windows machine with Windows Defender enabled (being attacked by a Kali machine).
Sharepoint syncs also have the interesting behavior that if you delete a file locally, it will be deleted for everybody, which means that attackers can attempt to remove their traces remotely.
Once the initial entry has been established, then exploitation and persistence can continue through covert cloud channels by using toolkits like GraphStrike to customize the communication of CobaltStrike beacons over the Microsoft GraphAPI.
Reporting the issue to Microsoft
The initial RTLO issue was submitted to the MSRC team on March 15th, 2024 and was quickly triaged for further review by the Microsoft team. While the Team decided that it’s a valid vulnerability, the severity that was assigned is moderate which means that the issue does not qualify for an immediate fix.
Microsoft stated that this choice is based on the fact that there is a warning prompt for users, which decreases some of the dangers that users are facing. Unfortunately the fact that the warning prompt also contains the file name with the spoofed extension did not raise the need for an immediate fix. The Microsoft Team was able to clarify that the severity rating are based on the following conditions https://www.microsoft.com/en-us/msrc/olsbugbar
Additional evidence was provided to Microsoft on April 12th, 2024 showing that the ODOpen protocol handler could be used to bypass the prompt with the auto sync capability, which was then reviewed in a new case (requested per the MSRC). The Microsoft Team decided that this does not raise the severity and unfortunately did not provide a statement on why it wouldn’t warrant an immediate fix.
Microsoft did state that this was considered for a fix in their backlog, but no date for a fix was provided. If you organization would like to review it’s current alerting against these kinds of attacks, then please check out ODCheck. If you have idea’s to further the project, then please do not hesitate to reach out.
How can your organization protect itself?
There are a few options for an organization to protect themselves against these kinds of attacks. The most important would be to make sure that you have a security solution that is able to detect the Right-To-Left-Override character for file extension spoofing. If you utilize Splunk then the following rule can be used to detect RTLO spoofing in progress
The MITRE recommendation for detecting RTLO injection states that defenders should also check their analysis tools to ensure they do not interpret the RTLO character and instead print the true name of the file containing it. It’s important to realize that the security logs in Office 365 will unfortunately not filter out the RTLO character, which can present an additional challenge for cybersecurity defenders. If you check the Microsoft Defender for Cloud apps activity log for example, then you will see the file presented with the spoofed extension.
Your organization may also want to consider to enable Safe Attachments for Sharepoint/OneDrive and Microsoft Teams. There are some additional licensing requirements that will have to be considered, but the feature can block files within your organization, so that they can be reviewed by Security Admins at a later time.
Microsoft has also released an article that highlights how their products can be used to threat hunt for C2 activity like Cobalt Strike within your environment, which can be crucial for organizational safety, especially with the rise of Cobalt Strike being able to use the Graph API for similar sync activities.
If you would like to test your environment for some of the techniques that were discussed in this article, then please check out ODCheck on Github. The tools page goes into further detail on it can be used to reproduce some of the issues and alerts brought up here.
By default, the following techniques can be tested with minimal setup:
| MITRE Technique | ID |
|---|---|
| Exfiltration over C2 Channel | T1041 |
| Masquerading: Right-to-Left Override | T1036.002 |
| Modify Registry | T1112 |
| Automated Collection | T1119 |
| Denial of Service | T0814 |
| Command and Scripting Interpreter: PowerShell | T1059.001 |
| Ingress Tool Transfer | T1105 |
| Web Service: Bidirectional Communication | T1102.002 |
All of these techniques can assist your organization with trying to spot these kinds of attacks. Hopefully Microsoft will soon implement their own fix, so that the issue will be stopped before these controls are required in the first place.
