Microsoft Office — CraftedSignal Threat Feed

Microsoft Office 'Office Test' Registry Persistence Abuse

hello@craftedsignal.io — Sat, 27 Jan 2024 17:30:00 +0000

The “Office Test” registry key, located under HKCU\Software\Microsoft\Office Test\Special\Perf, is a legitimate feature that allows specifying a DLL to be executed every time an MS Office application is started. Attackers can abuse this functionality by modifying the registry to point to a malicious DLL, achieving persistence on a compromised host. This allows for continued malicious activity even after a system restart or user logout. Elastic has published a rule to detect this behavior. The modification of this registry key, excluding deletions, is a strong indicator of potential abuse, and can be detected via endpoint detection and response (EDR) solutions as well as traditional Sysmon logging.

Attack Chain

An attacker gains initial access to a system, often through phishing or exploiting a vulnerability.
The attacker establishes a foothold and escalates privileges to make necessary registry modifications.
The attacker modifies the HKCU\Software\Microsoft\Office Test\Special\Perf registry key, adding a new entry or modifying an existing one to point to a malicious DLL.
The attacker ensures the malicious DLL is present on the system, either by dropping it directly or using existing system tools to download it.
A user launches a Microsoft Office application (e.g., Word, Excel, PowerPoint).
The Office application loads the DLL specified in the “Office Test” registry key during startup.
The malicious DLL executes its payload, which could include establishing a reverse shell, installing malware, or exfiltrating data.
The attacker maintains persistence, allowing them to regain access to the system each time an Office application is started.

Impact

Successful exploitation allows attackers to maintain persistent access to a compromised system. The injected DLL can be used to execute arbitrary code, potentially leading to data theft, malware installation, or further compromise of the network. The relatively low risk score suggests a common technique, but the potential for persistent access makes it a significant threat.

Recommendation

Deploy the provided Sigma rule to your SIEM and tune for your environment to detect unauthorized modifications to the “Office Test” registry key (HKCU\Software\Microsoft\Office Test\Special\Perf\*).
Enable Sysmon Registry event logging to capture registry modifications and activate the Sigma rule above.
Monitor process execution logs for Office applications to detect if a suspicious DLL has been loaded or executed, as described in the investigation guide.
Implement enhanced monitoring and alerting for similar registry modifications across the network, as described in the remediation steps.

XSL Script Execution via COM Interface in Microsoft Office

hello@craftedsignal.io — Fri, 26 Jan 2024 18:22:00 +0000

Attackers are increasingly leveraging the Microsoft.XMLDOM COM interface in Microsoft Office applications to execute malicious scripts. This technique involves embedding malicious JScript or VBScript within XSL transformations, which are then processed by Office applications like Word, Excel, PowerPoint, and Publisher. The exploitation begins when a user opens a specially crafted document. This campaign abuses legitimate functionalities for malicious purposes. This technique can be used for initial access, defense evasion, and execution of arbitrary code. The observed behavior includes the loading of msxml3.dll and the spawning of child processes.

Attack Chain

A user receives a phishing email containing a malicious Office document.
The user opens the document in Microsoft Word (winword.exe), Excel (excel.exe), PowerPoint (powerpnt.exe), or Publisher (mspub.exe).
The Office application loads msxml3.dll to process XML content within the document.
The document contains an embedded XSL script with malicious JScript or VBScript code.
The XSL transformation is initiated, executing the embedded script via the COM interface.
The script spawns a new process (cmd.exe, powershell.exe, or mshta.exe) to execute arbitrary commands.
The spawned process downloads and executes a payload from a remote server.
The payload establishes persistence, escalates privileges, and performs malicious activities such as data exfiltration or lateral movement.

Impact

Successful exploitation can lead to arbitrary code execution, potentially compromising sensitive data and allowing attackers to gain initial access to the targeted system. This can result in data breaches, financial losses, and reputational damage. The scope of impact includes any Windows systems running vulnerable versions of Microsoft Office. If successful, the attacker can achieve persistence, perform lateral movement and compromise other systems on the network.

Recommendation

Deploy the Sigma rule “XSL Script Execution via COM” to your SIEM to detect the execution of hosted XSL scripts using the Microsoft.XMLDOM COM interface.
Monitor for the loading of msxml3.dll by Microsoft Office applications and subsequent process creations to identify potential exploitation attempts.
Implement application whitelisting to restrict the execution of unauthorized scripts and executables, particularly those not located in standard directories.
Block the execution of unusual or unsigned child processes spawned by Microsoft Office applications to prevent malicious script execution.
Educate users about the risks of opening suspicious attachments or clicking on links in phishing emails (T1566).

Suspicious Execution via Microsoft Office Add-Ins

hello@craftedsignal.io — Wed, 03 Jan 2024 14:00:00 +0000

Attackers are increasingly leveraging malicious Microsoft Office Add-Ins to gain initial access and persistence on victim systems. These add-ins, often delivered through phishing campaigns, contain embedded malicious code. This detection identifies unusual execution patterns, such as Office applications (WINWORD.EXE, EXCEL.EXE, POWERPNT.EXE, MSACCESS.EXE, VSTOInstaller.exe) launching add-ins (wll, xll, ppa, ppam, xla, xlam, vsto) from suspicious paths like Temp or Downloads directories, or with atypical parent processes (explorer.exe, OpenWith.exe, cmd.exe, powershell.exe). The detection logic filters out known benign activities to minimize false positives, focusing on anomalies indicative of malicious intent, such as installations of Logitech software. This activity matters because successful exploitation can lead to arbitrary code execution, data theft, and further compromise of the victim’s network.

Attack Chain

A user receives a phishing email containing a malicious Microsoft Office document.
The user opens the document, which prompts them to enable macros or install an add-in.
The malicious add-in (wll, xll, ppa, ppam, xla, xlam, vsto) is downloaded from a remote server or dropped into a suspicious directory, such as %TEMP% or %APPDATA%.
The user executes an Office application (WINWORD.EXE, EXCEL.EXE, POWERPNT.EXE, MSACCESS.EXE), which loads the malicious add-in.
The malicious add-in executes arbitrary code, potentially downloading and executing a second-stage payload.
The add-in may establish persistence by modifying registry keys or creating scheduled tasks.
The attacker gains initial access to the system and can perform reconnaissance, lateral movement, and data exfiltration.
The attacker achieves their objective, which could include data theft, ransomware deployment, or intellectual property theft.

Impact

A successful attack can lead to complete system compromise, data theft, and potential ransomware deployment. Organizations across all sectors are at risk, particularly those with a high volume of email traffic. The use of malicious Office Add-Ins provides attackers with a persistent foothold within the victim’s environment, allowing for long-term data collection and disruption of business operations. This can lead to significant financial losses, reputational damage, and legal liabilities.

Recommendation

Deploy the Sigma rule Office Add-In Loaded From Suspicious Path to detect add-ins loaded from temporary or download directories based on process.args and process.name.
Deploy the Sigma rule Office Add-In Loaded By Suspicious Parent to detect add-ins loaded by cmd.exe or powershell.exe based on process.parent.name.
Investigate any instances of VSTOInstaller.exe executing with the /Uninstall argument, as this may indicate suspicious activity, correlating with the exclusion rule in the provided query.
Monitor for Office applications launching add-ins with parent processes of explorer.exe or OpenWith.exe using process creation logs and the provided query logic.
Implement stricter email filtering to prevent phishing emails containing malicious Office documents from reaching end-users.

Suspicious MS Office Child Process

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

This detection identifies suspicious child processes spawned by Microsoft Office applications (Word, PowerPoint, Excel, Outlook), which are commonly targeted for initial access via malicious documents or macro exploitation. The rule focuses on identifying anomalous process executions originating from these applications, a tactic often employed to execute arbitrary code or download additional payloads. Attackers leverage Office applications due to their widespread use and inherent scripting capabilities. Successful exploitation can lead to arbitrary code execution, lateral movement, and data exfiltration. This detection helps defenders identify and respond to potential security breaches originating from Microsoft Office applications, reducing the attack surface and minimizing potential damage. The rule specifically looks for processes like cmd.exe, powershell.exe, mshta.exe, wscript.exe, and others being spawned by Office applications.

Attack Chain

A user receives a malicious Microsoft Office document (e.g., Word, Excel) via email or downloads it from a compromised website.
The user opens the document, triggering the execution of a malicious macro or exploitation of a vulnerability within the Office application.
The Office application (e.g., winword.exe, excel.exe) spawns a suspicious child process such as cmd.exe or powershell.exe.
The spawned process executes a command to download a malicious payload from a remote server using bitsadmin.exe or certutil.exe.
The downloaded payload is a reverse shell or a malware dropper, which establishes a connection to an attacker-controlled server.
The attacker gains initial access to the compromised system and attempts to escalate privileges and perform reconnaissance.
The attacker uses discovery commands with net.exe, ipconfig.exe, tasklist.exe, and whoami.exe to map the environment and identify valuable targets.
The attacker moves laterally to other systems within the network, aiming to compromise critical assets and achieve their objectives, such as data theft or ransomware deployment.

Impact

Successful exploitation can lead to arbitrary code execution, allowing attackers to gain initial access to the compromised system. This can result in data theft, installation of malware, lateral movement to other systems, and ultimately, significant disruption to business operations. The widespread use of Microsoft Office makes it a prime target, potentially affecting a large number of users and organizations. Failure to detect and respond to these attacks can result in significant financial losses, reputational damage, and compromise of sensitive data.

Recommendation

Enable process creation logging (Sysmon Event ID 1 or Windows Security Event Logs) to ensure the visibility required to detect suspicious child processes.
Deploy the Sigma rule Suspicious MS Office Child Process to your SIEM and tune the rule based on your environment to reduce false positives.
Investigate any alerts generated by the Suspicious MS Office Child Process Sigma rule by examining the parent process tree and associated network connections.
Implement application control policies to restrict the execution of unauthorized processes from Microsoft Office applications.
Regularly update Microsoft Office applications to patch known vulnerabilities.
Block known malicious domains or IPs associated with malware delivery and command and control, based on threat intelligence feeds and IOCs from external sources.

Persistence via Visual Studio Tools for Office (VSTO) Add-ins

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

Attackers can leverage Visual Studio Tools for Office (VSTO) add-ins to establish persistence within Microsoft Office applications. VSTO add-ins, designed to extend the functionality of Office applications, can be manipulated by threat actors to execute malicious code upon application startup. By modifying specific registry keys associated with VSTO add-ins, adversaries can ensure their code is loaded and executed each time an Office application is launched. This technique allows for covert and persistent access to compromised systems, enabling further malicious activities such as data exfiltration, lateral movement, or the deployment of additional payloads. The detection of this persistence mechanism is crucial for defenders to identify and mitigate potential compromises within their environment.

Attack Chain

Attacker gains initial access to the target system via unspecified means (e.g., phishing, exploiting a vulnerability).
The attacker identifies the registry keys associated with VSTO add-ins for Office applications (Outlook, Word, Excel, PowerPoint). These keys are typically located under \Software\Microsoft\Office\[Application]\Addins\.
The attacker modifies the registry to add or modify entries related to a malicious VSTO add-in. This involves setting the LoadBehavior value to 3 to ensure the add-in is loaded on startup.
The attacker places the malicious VSTO add-in files (DLLs) in a location accessible to the Office application.
The attacker may also modify the \Software\Microsoft\VSTO\Security\Inclusion\ registry key to bypass security warnings related to unsigned add-ins.
The user launches the targeted Office application (e.g., Outlook).
The Office application loads the malicious VSTO add-in based on the modified registry entries.
The malicious VSTO add-in executes its payload, enabling the attacker to perform malicious activities on the system.

Impact

Successful exploitation allows attackers to achieve persistent code execution within Microsoft Office applications. This can lead to the compromise of sensitive data, the deployment of additional malware, and the establishment of a long-term foothold within the targeted environment. The scope of impact depends on the privileges of the user account and the capabilities of the malicious VSTO add-in. Since Office applications are commonly used, a successful attack could potentially affect a large number of users within an organization.

Recommendation

Deploy the Sigma rule Potential Persistence Via Visual Studio Tools for Office to your SIEM to detect suspicious registry modifications related to VSTO add-ins.
Monitor registry modifications under the paths \Software\Microsoft\Office\Outlook\Addins\, \Software\Microsoft\Office\Word\Addins\, \Software\Microsoft\Office\Excel\Addins\, \Software\Microsoft\Office\Powerpoint\Addins\, and \Software\Microsoft\VSTO\Security\Inclusion\ (see Sigma rule and references).
Implement application control policies to restrict the execution of unsigned or untrusted VSTO add-ins.
Regularly review and audit installed Office add-ins to identify and remove any suspicious or unauthorized extensions.

Office Application Autorun Registry Key Modification

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

Attackers may target Microsoft Office applications’ autostart extensibility points (ASEPs) in the Windows Registry to establish persistence. By modifying specific registry keys, malicious actors can ensure that their code is executed each time an Office application, such as Word, Excel, or Outlook, is launched. This technique is often employed to maintain a foothold on a compromised system. While legitimate add-ins also leverage these registry keys, unauthorized modifications can lead to the execution of arbitrary code, potentially resulting in data theft, system compromise, or further exploitation. Defenders should be aware that many legitimate applications modify these keys. Thorough testing and tuning is required.

Attack Chain

An attacker gains initial access to the system via an unrelated method.
The attacker identifies the relevant Office application ASEP registry keys: \Software\Wow6432Node\Microsoft\Office, \Software\Microsoft\Office and specific application keys like \Word\Addins, \Excel\Addins, etc.
The attacker modifies the registry key to point to a malicious executable or script. This could be achieved using tools like reg.exe or PowerShell.
The registry modification ensures that the malicious code is executed upon the next launch of the targeted Office application.
The user launches the Office application (e.g., Word, Excel, Outlook).
The Office application reads the modified registry key and executes the associated malicious code.
The malicious code performs its intended actions, such as downloading additional payloads, establishing command and control, or stealing data.
The attacker maintains persistence on the system through the modified registry key, ensuring continued access and control.

Impact

Successful exploitation allows attackers to achieve persistence on compromised systems. This can lead to data exfiltration, deployment of ransomware, or further lateral movement within the network. The modification of these keys is often performed to maintain a persistent presence, allowing attackers to regain access to the system even after reboots or user logoffs. While the number of direct victims is unknown, the potential for widespread impact is significant, especially in organizations heavily reliant on Microsoft Office applications.

Recommendation

Enable registry modification logging and deploy the provided Sigma rules to your SIEM to detect suspicious changes to Office application autostart registry keys.
Regularly audit the Office application add-ins installed on systems to identify and remove any unauthorized or malicious extensions (reference: Sigma rules).
Implement application whitelisting to prevent the execution of unauthorized executables and scripts (reference: Attack Chain).
Monitor process execution events for Office applications launching unusual or suspicious child processes (reference: Attack Chain).
Tune and customize the provided Sigma rules based on your environment’s baseline of legitimate Office add-in activity to minimize false positives (reference: Sigma rules).

MS Office Macro Security Registry Modifications

hello@craftedsignal.io — Tue, 02 Jan 2024 12:00:00 +0000

Microsoft Office applications allow users and developers to manage macro security settings. Attackers can abuse these settings by modifying the registry to automatically trust macros or disable security warnings. This increases the likelihood of successful macro execution, potentially establishing persistence or enabling further malicious activities on the compromised system. The modifications specifically target the AccessVBOM and VbaWarnings registry values. This is a common tactic used to bypass security controls and execute malicious code within an organization, often as part of a phishing or spear phishing campaign.

Attack Chain

The attacker crafts a malicious Office document containing VBA macros.
The victim receives the malicious document via email or other means (T1566).
The victim opens the document, potentially triggering a prompt to enable macros.
If macros are enabled or trusted due to existing settings, the malicious VBA code executes (T1204.002).
The VBA code modifies the Windows Registry to disable macro security warnings by setting HKEY_CURRENT_USER\Software\Microsoft\Office\*\Security\VbaWarnings to 1 or modifying AccessVBOM (T1112).
The attacker can then use the trusted macro environment to execute arbitrary code (T1059.005).
The attacker may establish persistence by creating scheduled tasks or modifying startup entries (T1547.001).
The attacker achieves their final objective, which may include data exfiltration, lateral movement, or deploying ransomware (TA0005, TA0002).

Impact

Successful exploitation allows attackers to bypass Office macro security protections, potentially leading to arbitrary code execution and system compromise. Disabling macro security warnings increases the attack surface within an organization, as users are no longer prompted to approve macro execution, which can lead to further malware infection and data breaches. The rule is designed to detect registry changes that could enable this type of attack.

Recommendation

Enable Sysmon registry event logging to detect the registry modifications described in this brief to trigger the detections (Sysmon Registry Events).
Deploy the Sigma rule “MS Office Macro Security Registry Modifications” to your SIEM and tune for your environment.
Use Group Policy Objects (GPOs) to centrally manage Office macro security settings and prevent users from modifying them (references).
Investigate any alerts generated by this rule to determine the source of the registry modification and whether malicious macros were subsequently executed (rule description).

Detection of Office Macro File Creation

hello@craftedsignal.io — Tue, 02 Jan 2024 12:00:00 +0000

The creation of Office macro files (.docm, .xlsm, .pptm, etc.) can be an indicator of malicious activity, often linked to initial access attempts such as phishing campaigns or malware distribution. Attackers frequently embed malicious macros within these files to execute arbitrary code on a victim’s machine upon opening the document and enabling macros. While legitimate use cases for macro-enabled documents exist, their creation should be monitored, especially when originating from unusual processes or locations. This activity is related to the technique T1566.001 (Phishing: Spearphishing Attachment). Defenders need to monitor file creation events for specific Office macro extensions, filtering out common false positives to identify potential threats.

Attack Chain

An attacker crafts a malicious Office document (e.g., .docm, .xlsm) containing a VBA macro.
The attacker sends the malicious document as an attachment via email (spearphishing).
The user receives the email and opens the attached Office document.
The user is prompted to enable macros within the document.
If the user enables macros, the embedded VBA code executes.
The VBA code may execute PowerShell or other scripting languages to download a malicious payload.
The downloaded payload is saved to disk (e.g., in the user’s temp directory).
The payload executes, establishing persistence or performing other malicious actions, such as ransomware deployment.

Impact

Successful exploitation can lead to arbitrary code execution, malware installation, data exfiltration, and potentially complete system compromise. The impact can range from individual user infection to widespread organizational damage, depending on the attacker’s objectives and the level of access gained. In a widespread attack, numerous systems could be infected, leading to significant downtime, data loss, and financial repercussions.

Recommendation

Deploy the Sigma rule Office Macro File Creation to your SIEM to detect the creation of suspicious Office macro files (logsource: file_event/windows).
Investigate any alerts generated by the Sigma rule, focusing on the parent processes of the file creation event.
Implement user awareness training to educate employees about the risks of opening unsolicited attachments and enabling macros.
Enable Sysmon file creation logging to capture the necessary events for the Sigma rule to function effectively.