Outlook — CraftedSignal Threat Feed

Persistence via Malicious Microsoft Outlook VBA Template

hello@craftedsignal.io — Thu, 04 Jan 2024 12:00:00 +0000

Attackers can leverage Microsoft Outlook’s VBA scripting capabilities to establish persistence on compromised systems. This is achieved by installing malicious VBA templates within the Outlook environment. These templates are designed to execute upon application startup, granting the attacker sustained access and control. The attack centers around unauthorized modifications to the VbaProject.OTM file, a critical component for VBA script storage in Outlook. This technique allows threat actors to maintain a foothold even after system restarts or user logoffs. Defenders need to monitor for suspicious changes to this file to identify and mitigate potential compromises.

Attack Chain

The attacker gains initial access to the target system, potentially through phishing or other social engineering methods (not detailed in source).
The attacker identifies a user with Microsoft Outlook installed and running on a Windows system.
The attacker modifies or replaces the existing VbaProject.OTM file located in the user’s Outlook profile (C:\Users\*\AppData\Roaming\Microsoft\Outlook\).
The modified VbaProject.OTM file contains malicious VBA code designed to execute when Outlook starts.
The victim launches Microsoft Outlook.
The malicious VBA code within VbaProject.OTM executes automatically upon Outlook startup, establishing persistence.
The VBA script can perform various malicious actions, such as downloading and executing additional payloads, establishing command and control, or exfiltrating data.

Impact

Successful exploitation can lead to persistent access to the compromised system, allowing attackers to steal sensitive information, deploy ransomware, or use the system as a staging ground for further attacks within the network. The number of victims and specific sectors targeted depends on the attacker’s objectives and scope of the campaign. If the attack succeeds, an attacker could gain complete control over the user’s email account and associated data, leading to significant data breaches and financial losses.

Recommendation

Deploy the Sigma rule Detect Outlook VBA Template Modification to your SIEM to identify unauthorized modifications to the VbaProject.OTM file based on file creation events.
Enable Sysmon file creation logging (Event ID 11) to activate the Detect Outlook VBA Template Modification rule.
Implement application control policies to restrict unauthorized modifications to Outlook VBA files as described in the “Response and remediation” section of the source.
Monitor file creation events related to VbaProject.OTM in the specified paths (C:\\Users\\*\\AppData\\Roaming\\Microsoft\\Outlook\\VbaProject.OTM) as highlighted in the rule query.

Unsecured Outlook Credentials Access in Windows Registry

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

Attackers may attempt to access unsecured Outlook credentials stored within the Windows registry to compromise user email accounts. This involves leveraging tools or scripts to directly read sensitive registry keys containing password or authentication information. This activity often occurs after initial access has been gained through phishing, exploitation of vulnerabilities, or other means. Successful compromise of Outlook credentials can lead to significant data breaches, financial losses, and reputational damage. The credential access activity is detected via Windows Security Event logs, specifically Event ID 4663, focusing on registry paths associated with Outlook profiles. Multiple stealers and keyloggers have been observed utilizing this technique.

Attack Chain

Initial access is gained via phishing, exploiting vulnerabilities, or other methods.
The attacker executes a malicious process (e.g., Snake Keylogger) on the compromised system.
The malicious process attempts to access the Windows registry using standard Windows APIs.
The process targets specific registry paths where Outlook stores profile information: *\Profiles\Outlook\9375CFF0413111d3B88A00104B2A6676* and *\Windows Messaging Subsystem\Profiles\9375CFF0413111d3B88A00104B2A6676*.
Windows Security Event logging generates Event ID 4663 when the registry object is accessed.
The attacker extracts the unsecured Outlook credentials from the registry.
The attacker uses the stolen credentials to access the victim’s Outlook account.
The attacker exfiltrates sensitive information, sends malicious emails, or performs other unauthorized actions.

Impact

Compromised Outlook credentials can lead to unauthorized access to email accounts, enabling attackers to steal sensitive information, impersonate users, and conduct further malicious activities. This can result in significant financial losses, data breaches, and reputational damage. The impact ranges from individual user compromise to enterprise-wide breaches depending on the scope of the attack. Threat actors may use compromised accounts to launch further attacks, potentially impacting other systems and data.

Recommendation

Enable “Audit Object Access” in Group Policy for Windows Security Event logs to track Event ID 4663 (per the “how_to_implement” section) and monitor registry access.
Deploy the Sigma rule Detect Suspicious Outlook Registry Access to identify unauthorized processes accessing Outlook credential registry paths.
Investigate any alerts generated by the Sigma rule Detect Suspicious Outlook Registry Access to determine if credential theft occurred.
Monitor for processes other than outlook.exe accessing the specific registry paths outlined in the search field to identify potentially malicious activity.

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.

Potential Masquerading as Communication Apps

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

Attackers may attempt to evade defenses by masquerading malicious processes as legitimate communication applications. This involves using names and icons that resemble trusted applications like Slack, WebEx, Teams, Discord, RocketChat, Mattermost, WhatsApp, Zoom, Outlook and Thunderbird to trick users and bypass security measures. This technique can be used to conceal malicious activity, bypass allowlists, or trick users into executing malware. The detection rule identifies suspicious instances by checking for unsigned or improperly signed processes, ensuring they match known trusted signatures, which helps in flagging potential threats that mimic trusted communication tools.

Attack Chain

An attacker gains initial access to a Windows system through various means such as phishing or exploiting a vulnerability.
The attacker deploys a malicious executable onto the compromised system.
The attacker renames the malicious executable to resemble a legitimate communication application, such as “slack.exe” or “Teams.exe”.
The attacker modifies or removes the code signature of the malicious executable to avoid detection based on trusted publishers.
The attacker executes the renamed and potentially unsigned malicious executable.
The masqueraded process performs malicious actions, such as establishing a reverse shell or downloading additional payloads.
The attacker uses the compromised system to move laterally within the network, escalating privileges and compromising additional systems.
The final objective is to exfiltrate sensitive data or deploy ransomware.

Impact

Successful masquerading attacks can lead to significant security breaches, including data theft, system compromise, and financial loss. By disguising malicious processes as legitimate communication apps, attackers can bypass security controls and operate undetected for extended periods. This can result in widespread damage and disruption, as well as reputational damage for the targeted organization. The impact can range from a few compromised systems to a complete network takeover, depending on the attacker’s objectives and the effectiveness of the masquerading technique.

Recommendation

Deploy the Sigma rule “Potential Masquerading as Communication Apps - Generic” to your SIEM and tune for your environment to detect unsigned or improperly signed communication applications.
Deploy the Sigma rule “Potential Masquerading as Communication Apps - Specific” to your SIEM and tune for your environment to detect unsigned or improperly signed instances of specific communication applications.
Enable process creation logging on Windows systems to capture the necessary events for the Sigma rules.
Review and validate the code signatures of all communication apps on your systems to ensure they are properly signed by trusted entities.
Implement application control policies to restrict the execution of unsigned or untrusted executables.

Suspicious Inter-Process Communication via Outlook COM

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

Attackers may exploit the Component Object Model (COM) interface in Microsoft Outlook to automate tasks such as sending emails or exfiltrating sensitive information. This attack involves leveraging unusual processes to interact with Outlook, potentially bypassing security measures. The activity is detected by monitoring for unexpected processes initiating communication with Outlook, especially those lacking trusted signatures or recently modified, indicating potential malicious activity. The detection focuses on identifying processes like rundll32.exe, mshta.exe, powershell.exe, cmd.exe, cscript.exe, and wscript.exe interacting with Outlook. This activity can lead to unauthorized access to sensitive email data or the ability to send malicious emails from compromised accounts.

Attack Chain

An attacker gains initial access to a Windows system, often through phishing or exploiting a vulnerability.
The attacker uses a scripting language or executable, such as PowerShell or cmd.exe, to interact with the Outlook application via its COM interface.
The script attempts to enumerate mailboxes and email messages.
Sensitive data from the email messages is collected and prepared for exfiltration.
The script initiates a network connection to a remote server controlled by the attacker.
The collected data is then exfiltrated to the attacker’s server.
Alternatively, the attacker crafts and sends emails from the compromised Outlook account to further propagate malware or conduct phishing campaigns.
The attacker cleans up any traces of the malicious script or executables to maintain persistence.

Impact

Successful exploitation could lead to the compromise of sensitive information contained within user email accounts. This includes confidential business communications, personal data, and potentially credentials. The impact extends to potential data breaches, financial losses, and reputational damage. The number of affected users and the extent of the damage depends on the attacker’s objectives and the level of access achieved within the compromised email environment.

Recommendation

Monitor process execution for unusual processes (rundll32.exe, mshta.exe, powershell.exe, pwsh.exe, cmd.exe, regsvr32.exe, cscript.exe, wscript.exe) spawning or interacting with OUTLOOK.EXE. Deploy the “Suspicious Outlook COM abuse by Scripting Host” Sigma rule to your SIEM and tune for your environment.
Implement code signature validation for all executables in your environment. This will help identify and block unsigned or untrusted executables.
Monitor for any network activity associated with the identified unusual processes. This helps to identify potential data exfiltration attempts.
Enable process creation logging with command line arguments to enhance visibility into potential malicious activities. This is critical for the Sigma rules to function correctly.
Regularly review and update your endpoint protection policies to ensure that similar threats are detected and blocked.
Investigate any alerts generated by the “Suspicious Outlook COM abuse by New Process” Sigma rule, correlating with user activity and network connections.

Suspicious Command Prompt Network Connection

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

This detection identifies suspicious network connections initiated by the command prompt (cmd.exe) on Windows systems. The rule focuses on cmd.exe processes executed with specific arguments, such as those indicating script execution (e.g., *.bat, *.cmd), access to remote resources (e.g., URLs), or those spawned by Microsoft Office applications (Excel, Word, etc.). Attackers frequently abuse cmd.exe to download malicious payloads, execute commands, or establish command and control channels. This detection aims to identify such potentially malicious activity by correlating process creation events with subsequent network connections. The rule excludes common private and reserved IP address ranges to reduce false positives. The targeted systems are Windows endpoints where adversaries attempt to leverage cmd.exe for malicious purposes.

Attack Chain

A user opens a malicious document (e.g., Word, Excel) or executes a seemingly benign application.
The document or application contains a macro or script that initiates a cmd.exe process.
The cmd.exe process is launched with arguments indicating script execution (/c, /k) and referencing a remote resource (e.g., a URL) or a local batch file.
The cmd.exe process attempts to download a payload from a remote server using protocols like HTTP, HTTPS, or FTP.
The downloaded payload is saved to disk, often with a disguised filename.
The cmd.exe process executes the downloaded payload, initiating further malicious actions.
The malicious payload establishes a command and control (C2) channel with a remote server.
The attacker uses the C2 channel to send commands to the compromised system, potentially leading to data exfiltration or other malicious activities.

Impact

Successful exploitation can lead to the compromise of Windows endpoints, potentially enabling attackers to download and execute malicious payloads, establish command and control channels, and perform further malicious activities such as data theft, lateral movement, or ransomware deployment. While this detection has a low severity, it serves as an early warning sign of potential compromise and should be investigated promptly.

Recommendation

Enable process creation logging with command line arguments to capture the full context of cmd.exe executions.
Monitor network connections from cmd.exe processes, focusing on connections to external IP addresses, using a network monitoring solution.
Deploy the Sigma rules provided in this brief to your SIEM to detect suspicious cmd.exe network connections.
Investigate any alerts generated by the Sigma rules, focusing on cmd.exe processes spawned by Office applications or those executing scripts from remote URLs.

Masquerading Business Application Installers

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

Attackers often attempt to trick users into downloading and executing malicious executables by disguising them as legitimate business applications. This tactic is used to bypass security measures and gain initial access to a system. These malicious executables, often distributed via malicious ads, forum posts, and tutorials, mimic the names of commonly used applications such as Slack, WebEx, Teams, Discord, and Zoom. The executables are typically unsigned or signed with invalid certificates to further evade detection. This allows the attacker to execute arbitrary code on the victim’s machine, potentially leading to further compromise. This campaign aims to target end-users who are less security-aware, and this makes social engineering attacks like this very effective.

Attack Chain

The user visits a compromised website or clicks on a malicious advertisement.
The user is prompted to download an installer file masquerading as a legitimate business application (e.g., Slack, Zoom, Teams) from a download directory.
The downloaded executable is placed in the user’s Downloads folder (e.g., C:\Users*\Downloads*).
The user executes the downloaded file.
The executable, lacking a valid code signature, begins execution.
The malicious installer may drop and execute additional malware components.
The malware establishes persistence, potentially using techniques such as registry key modification.
The malware performs malicious activities, such as data exfiltration or lateral movement.

Impact

Successful execution of a masqueraded business application installer can lead to a complete system compromise. The attacker gains initial access and can deploy various malware payloads, including ransomware, keyloggers, and data stealers. This can result in data breaches, financial loss, and reputational damage. Although the specific number of victims and sectors targeted are not detailed, the widespread use of the applications being spoofed (Slack, Zoom, etc.) suggests a broad potential impact.

Recommendation

Implement the Sigma rule Potential Masquerading as Business App Installer to detect unsigned executables resembling legitimate business applications in download directories.
Enable process creation logging to capture the execution of unsigned executables.
Educate users on the risks of downloading and executing files from untrusted sources.
Implement application whitelisting to restrict the execution of unauthorized applications.
Regularly update endpoint detection and response (EDR) tools to detect and prevent the execution of known malware.
Monitor process execution events for processes originating from the Downloads folder that lack valid code signatures.