arkha-corvus/letsdefend-soc336-windows-ole-zero-click-rce-exploitation-detected-cve-2025-21298-We are expected to investigate a critical alert reporting a Windows OLE zero-click RCE exploitation (CVE-2025-21298) delivered via a malicious RTF attachment.
We are expected to investigate a critical alert reporting a Windows OLE zero-click RCE exploitation (CVE-2025-21298) delivered via a malicious RTF attachment.
On 4 February 2025, at 16:18, a security alert was triggered following the receipt of an email by Austin @ letsdefend.io. The message originated from projectmanagement @ pm.me and included an attachment. The attached file was immediately flagged as malicious by the organisation’s security monitoring systems. This detection indicates that the attachment likely contained harmful content.
This section investigates the project management email identified within the inbuilt email security system. The aim is to understand the nature of the email and the potential threats faced by the user.
Upon examination, it is apparent that the email in question is malicious and designed as a phishing attempt. The email delivers a weaponised Rich Text Format (RTF) file, which is crafted to exploit a known vulnerability in Windows Object Linking and Embedding (OLE).
The main objective of this attack is to achieve remote code execution on the target system. By exploiting the Windows OLE vulnerability, the attacker seeks to gain initial access to the system or potentially deliver additional payloads, increasing the risk to the recipient.
The flagging of the IP address by these independent sources indicates a high likelihood of its involvement in suspicious or harmful operations. This consensus between security tools strengthens the case for treating the IP address as a potential threat within the environment.
The command execution indicates that regsvr32.exe, a legitimate Windows utility, was leveraged to fetch and run a remote script from the attacker's side. The script was executed via the scrobj.dll library, a method frequently employed in fileless malware attacks, where malicious code runs directly in memory to evade conventional file-based detection mechanisms.
Upon further examination, it has been determined that the script was downloaded from Austin's endpoint, indicating that script.sct was allowed to be managed from a remote server.
I extended my analysis by examining the hash linked to the RTF file, which provided clear evidence that it was a malicious file. This hash had been flagged multiple times and identified by various security vendors, confirming its repeated use in malicious activity.
I proactively took the initiative to contain Austin's device in order to prevent any further damage or potential security risks. Additionally. This prompt action helped to minimise the impact and maintain the safety of the network.
Upon completion of my investigation, I concluded that the file in question, or the malware associated with it, posed a significant threat. The analysis confirmed that the software was indeed harmful and required immediate attention.
Afterwards, I documented my lessons learned from the incident for future reference and ensured all details regarding the malicious C2 attack were thoroughly communicated.
Thank you very much for taking the time to read this!
Your feedback would be greatly valued and appreciated.
