How to Set Up a Network Research Laboratory: MonikerLink (CVE-2024-21413) Case Study 

Every now and then, you come across a situation where you need to get hands-on to understand how an exploit or malware works and then create a detection rule. Plus, there are times when it’s essential for the attacking machine to be on the local network to capture network traffic or utilize its own detection tools. 

In this article, we’ll show you how to set up a working environment to gather IOCs and write detection rules, using CVE-2024-21413 as an example. We’ll walk you through integrating the ANY.RUN virtual machine into a local VPN network for this purpose. To do this, we’ll: 

1. Let’s quickly analyze the CVE and prepare a Proof of Concept (PoC). 

2. Set up a local VPN network with the ANY.RUN machine. 

3. Verify the functionality of the PoC and gather NTLM Hash using Impacket. 

4. Gather IoCs and draft a detection rule. 

Description of CVE-2024-21413 and Preparing a PoC 

 This Outlook vulnerability can lead to the leakage of an NTLM Hash, potentially enabling the execution of arbitrary code without alerting the user. 

In essence, when the victim clicks on a link within an email, a file is downloaded from a remote server and executed without any warning prompt. Additionally, during the file’s execution, there’s an attempt to authenticate against the remote server via the SMB protocol, resulting in an NTLM Hash leak. 

One telltale sign of a malicious link is the presence of an exclamation mark at the end of the file URL, enabling it to bypass security mechanisms. With this in mind, let’s draft a sample email to illustrate how to circumvent Outlook’s protection mechanism: 

As depicted in the screenshot above, we appended an exclamation mark to the end of the link and followed it with random text. We designated the attacker’s server as the IP address. In our scenario, this server is a machine on the local network running Kali Linux, which we’ll integrate shortly. 

For a comprehensive demonstration, we also require a document file that, upon opening, triggers the execution of a program, such as “winver.exe” from the System32 directory. You can obtain the RTF file from this link — it leverages CVE-2017-11882 to launch an arbitrary application: 

Integrating of ANY.RUN into a local VPN network 

In order to integrate into the local network, we require a functional OpenVPN server, which will double as the attacker’s host. It’s crucial to exercise caution as malware could potentially gain access to this server. Setting up a VPN server is a detailed process that warrants its own article, hence it’s beyond the scope of this discussion. 

To ensure the stable operation of the internet connection, it’s important not to overlook configuring keep-alive packets in the OpenVPN server configuration file. 

Next, we’ll need a client configuration file, known as “OVPN”, which will be utilized to establish the connection of the virtual machine to the network when initiating the task. 

Navigate to your profile and access the “Custom OpenVPN configs” tab to upload the OVPN client file.

Create a new task, upload the sample, select our VPN configuration and run the task: 

As we remember, the IP address of our VPN server is “10.2.0.1”. Let’s check if it’s accessible using the “ping” utility in ANY.RUN’s virtual machine: 

Seeing the responses from the OpenVPN server confirms that the ANY.RUN virtual machine has successfully connected to the local network. 

With that, the network connection setup is finished.  

Verifying PoC and Collecting NTLM Hashes 

CVE-2024-21413 utilizes the SMB protocol to fetch a remote file, thus requiring an SMB server capable of not only serving the required files but also storing NTLM hashes. For this purpose, we’ll employ the SmbServer from the Impacket package as our server. 

First and foremost, let’s set up a directory containing an “rtf” file. (For sourcing the file, refer to the instructions above): 

Next, let’s run impacket-smbserver: 

We’re now ready to click on the link within the generated email. Head over to AnyRun and select “Malicious Link”.

After a brief wait, we notice that “winver.exe” has surfaced in the processes, and the “About Windows” window has popped up on the screen, all without any warning window from Outlook despite the error. 

Now, let’s navigate back to the server console and confirm that we have successfully collected an NTLM hash. This hash can be subsequently subjected to brute force attacks using utilities such as HashCat or John The Ripper. 

Collecting IOCs and writing a signature 

From the blue team’s perspective, the main task is to collect IOCs and develop detection rules. 

One effective approach is to leverage ANY.RUN’s detection mechanism, which has already flagged numerous malicious activities, including the exploitation of CVE-2017-11882, along with various signatures, and more. 

Also, in the Network Threats tab, we observe the detection of the “Impacket SMB Server” that we utilized. Interestingly, this server is frequently employed in other attacks as well. (Read our tweet for reference). 

However, we can also write another signature to detect potential leakage of NTLM hashes to an external network. 

The following rule tracks potential authentication data leakage via the NTLM protocol, which violates local network security policies: 

alert smb any any -> $EXTERNAL_NET any (msg: "POLICY [ANY.RUN] Possible NTLM Hash leak over SMB to External Network (NTLMSSP_AUTH)"; 
flow: established, to_server; 
content: "SMB"; offset: 5; depth: 3; 
content: "NTLMSSP|00 03 00 00 00|"; distance: 0; 
sid: 8001383; rev: 1;) 

This rule has three main conditions: 

1. It detects SMB traffic. 

2. It looks for access to the external network. 

3. It checks for the presence of the NTLM identifier and authentication in the message type within the packet. 

Summary and attack prevention 

The best practice is to keep software updated promptly and to block any outgoing SMB traffic to external networks. By doing so, this type of attack would be thwarted as it would be impossible to reach the attacker’s server. 

In summary, we have explored how to integrate ANY.RUN into a local network and remotely monitor threats using ANY.RUN. 

About ANY.RUN

ANY.RUN is a cloud malware sandbox that handles the heavy lifting of malware analysis for security teams. Every day, 400,000 professionals use our platform to investigate incidents and streamline threat analysis.

Advantages of ANY.RUN 

• Real-time detection: Within roughly 40 seconds of uploading a file, ANY.RUN can detect malware and automatically identify many malware families using YARA and Suricata rules. 

• Interactive analysis: Unlike many automated solutions, ANY.RUN allows you to interactively engage with the virtual machine directly through your browser. This interactive capability helps prevent zero-day exploits and sophisticated malware that can evade signature-based detection. 

• Cost-Effective: For businesses, ANY.RUN’s cloud nature translates into a cost-effective solution, as it doesn’t require any setup or maintenance effort from your DevOps team. 

• Great for onboarding new security team members: ANY.RUN’s intuitive interface allows even junior SOC analysts to quickly learn how to analyze malware and extract indicators of compromise IOCs. 

Try our sandbox with a free account →