Detecting OneNote (.One) Malware Delivery
I opened a dozen malicious OneNote files and clicked on every link so you don’t have to
Introduction/Objectives
Early in 2023, I started hearing about a new (to me, anyway) type of malware delivery — .one files opened using Microsoft OneNote:
As tweets like the one above gradually seeped into my consciousness, I decided to learn more, as I am always curious to know about new techniques that attackers are using (or old ones they are dusting off) to gain access to victim networks. I’d really enjoyed the QakBot/IcedID/HTML smuggling research I did at the end of 2022 and wanted to see if I could repeat this process for OneNote-delivered malware, for the educational benefit and [mild] enjoyment of all. My objectives were:
- 💡 Understand how OneNote is used to deliver malware.
- 🔭 Observe OneNote malware delivery in my lab.
- 📖 Review existing log-based detections for this activity, and identify possible ways to augment or strengthen these.
- ✍️ Write and share new or improved rules to detect OneNote malware delivery.
- 🍪 Celebrate with a tasty treat.
I hope this article provides another useful example of how current or aspiring detection specialists can research adversary techniques, extract observable patterns, and design/share detection rules to put those attackers in our sights!
Disclaimer
Before we proceed, I want to emphasize that I know OneNote malware has been covered already, by people with more experience than me. While I do think I’ve uncovered some novel log-based detections for the latest wave of OneNote-driven malware delivery, I am not claiming this as ground-breaking original research. So, don’t have a cow, man!
One Note About OneNote
Before getting started, I had to acknowledge that I didn’t really know much of anything about OneNote. Ok, I know it’s Microsoft’s built-in note-taking app. I had explored it briefly during my last job as a Security Analyst but gave it up in favor of good old pen and paper (seriously). So, in the interest of forming some very baseline familiarity with the tool, I fired it up in my lab and created a very simple Notebook, as shown below:
But what about a .one file?
With my example Notebook in the bag, I wanted to understand what a .one file is, how you create one, how you use one, and how it is being abused by threat actors. After researching a bit online, I found out that you can export a OneNote notebook to a .one file that can in turn be imported into the OneNote collection of another user so that they have their own copy of the notebook. This is a little odd, as OneNote notebooks are definitely intended to be shared directly via the web, but I suppose it’s conceivable that someone wanting to use or share notebooks in a disconnected/offline environment would want to use a .one file.
A .one file is also a good way to distribute a template notebook via the web. This will become apparent momentarily.
It was surprisingly difficult to create my own .one file. As far as I could tell you can’t do it using the OneNote desktop app, but after hunting through some menus in the OneNote online version I figured it out (screenshots below are just for anyone who’s curious to know what a legitimate .one file creation experience is like — it’s nothing to write home about).
Basics of the Attack
Having gained some rudimentary knowledge of OneNote .one files and their legitimate usage, I attempted to build a fuller understanding of the attack, that would eventually help me detect it. The basic flow is as follows:
- An attacker sends a phishing email containing a .one file attachment.
- The victim, hoping to access an important or useful document, opens the .one file in OneNote.
- The victim is deceived into double-clicking an attached file icon, which runs an attached HTA, VBS, or similar file using the corresponding built-in Windows utility (wscript.exe, mshta.exe, or what have you).
- The malicious HTA or VBS file calls the WMI provider host (WmiPrvSE.exe) which runs powershell via CMD to download a malicious batch file from transfer.sh, or a compromised website.
- Simultaneously to the step above, CDM/PowerShell are used to retrieve and open a legitimate .one file template from onenotegem.com, a site with helpful OneNote templates, or a compromised website. This leads the victim to think they have what they need, making them less likely to report the infection to IT/Security.
- The malicious batch file from step 4 copies the PowerShell executable and uses it to run an encrypted payload, which is the AsyncRAT trojan or similar info-stealing malware.
With this basic understanding in mind, it was time to gather some sample malicious .one files and test them out in the lab!
Gathering Samples
To gather my samples I turned to Malware Bazaar, an excellent resource I mentioned in my last post about HTML smuggling. I found I could efficiently find and download these samples using the tags “one” and “OneNote:”
https://bazaar.abuse.ch/browse/tag/OneNote/
https://bazaar.abuse.ch/browse/tag/one/
As before, I downloaded and extracted a number of these samples, naming them according to the “humanhash” property of each sample:
With these samples lined up and my link-clicking, attachment-opening fingers warmed up with the workout shown below, I was ready to begin!
Testing and Observing OneNote Malware Delivery
The sample notebooks I tested all contained some variation of this look and feel:
After repositioning the “button” graphic, you can see the offending attachments:
I dutifully double-click the attached file icon, dismissing the warning that it could harm my computer. After a few seconds, an invoice from Excel Business Systems pops up in OneNote, and a command prompt window appears for a split second. Below, I’ve included an annotated screenshot of the Process Creation logs, which I believe will be useful for understanding the chronology of the events:
And here, we can see additional log details from the final step in the malware delivery process, showing us based on the OriginalFileName property that system32.bat.exe is in fact a copied version of Microsoft PowerShell.exe:
Observations and Analysis
Of the dozen or so .one samples I analyzed, most of them downloaded a decoy notebook template from onenotegem.com, and the malicious batch file from transfer.sh. To their credit, transfer.sh had removed nearly all of the malicious batch files from their site, so the infection would not proceed in my lab as the malicious payload could not be found.
In one particularly head-spinning case, a malicious powershell script (rr.ps1) lead to process injection using RegAsm.exe, a legitimate Windows utility used for .NET assembly registration. I observed RegAsm.exe executing without any command-line parameters (a common indicator of process injection) and performing DNS lookups of suspicious domains:
Significantly, this malicious powershell script is still available on transfer.sh!
Another strange and possibly-relevant observation was that, in the screenshot above of the OneNote notebook with the row of malicious WSF attachments, the filenames contained some sort of non-printable character in the filename which causes the filename to appear partially-reversed in the logs:
After digging into this a bit more, I realized that the special character is actually a unicode character called “RIGHT-TO-LEFT-OVERRIDE”:
This character is represented by the unicode value U+202E. Try Googling that code (it’s a trip). Apparently there’s even a Mitre ATT&CK subtechnique for this — fascinating stuff!
Existing Detections
Of the existing log-based detection rules I found, the best one is “Suspicious OneNote Child Process”:
This one rule is really effective on its own! It looks for suspicious processes spawned by OneNote.exe, including all of the ones that I observed while executing my OneNote samples.
New Detection Ideas
I wondered, however, if I could come up with some additional rules which would match on the activity I observed, including the subtle variations. After all, building up detection “in depth” could result in multiple alerts, which could more reliably point a SOC to the correct investigative pathway. My ideas included:
- Double extension Image (process name). This could apply to process creation, network connections, DNS queries, and others.
- RegAsm.exe process injection.
- Right-to-left override in process CommandLine (my personal favorite!)
These rules were all interesting to write, but the right-to-left override rule was particularly challenging. Regex101 helped tremendously! I copied and pasted the following bizarre command-line value into the Test String dialog on regex101.com:
C:\Windows\SysWOW64\wscript.exe "C:\Users\vagrant\AppData\Local\Temp\OneNote\16.0\Exported\{CD943C96-FC1A-417A-A5B5-83A1844A2E58}\NT\1\filePdf.wsf"I noted that the unicode character was highlighted, so I copied and pasted that character on it’s own into a simple wildcard format and to my surprise it worked!
You can see the recipe right here: https://regex101.com/r/zLgqzk/1. I dropped it into the following Sigma rule which converted successfully into a Splunk query that detected all of the malicious OneNote attachments in my process creation logs. Note: the Regex below looks erroneous, but that’s only because the invisible unicode character reversed the character order. This rule really works!
title: Suspicious Command Line Containing Right-to-Left Override
id: ad691d92-15f2-4181-9aa4-723c74f9ddc3
status: experimental
description: Detects the presence of the u202+E character, which causes a terminal, browser, or operating system to render text in a right-to-left sequence. This is used in obfuscation and masquerading techniques.
references:
- https://redcanary.com/blog/right-to-left-override/
- https://unicode-explorer.com/c/202E
author: Micah Babinski, @micahbabinski
date: 2023/01/30
tags:
- attack.defense_evasion
- attack.t1036
- attack.t1036.002
logsource:
category: process_creation
product: windows
detection:
selection:
# you can't see it, but trust me, there's a right-to-left override character in the regex below! :P
CommandLine|re: ^.*.*$
condition: selection
falsepositives:
- Unknown
level: highConclusion
When I started writing this article I expected it to be a straightforward and fairly derivative take on a temporarily-popular method of malware delivery. But I ended up learning a lot about how OneNote can be abused, and observed some attacker techniques and behaviors that were completely new to me. On top of that, I believe the double file extension rules and the right to left override rules are novel and useful ways to detect these techniques in your environment. I’ve shared these in my personal Sigma rule stash on my GitHub available here:
And now, with my fifth objective in mind, I am off to eat a cookie, or should it be a lemon bar?
That’s all for now! As always, Happy Analyzing! 🧐
