Posts

Deceptive PDF Disguised as RingCentral Leads to Phishing Attacks

/in /by

Overview

The SonicWall Capture Labs threat research team has observed PDF files masquerading as Ring Central, which is a communication and collaboration platform. This is achieved by incorporating malicious URLs with the intention of executing social engineering attacks for credential theft.

Infection Cycle

The PDF document bears the message, "You have a new voice message." alongside the Ring Central logo. It prompts the user to take action with the instruction, "Click here to listen." However, upon clicking the provided link, the user is redirected to an adobe privileged host URL. Malware authors are abusing sites (or hosts) that identify privileged locations that host trusted content (in this case, an Adobe URL).

Figure 1: PDF document

Upon accessing the Adobe URL, the user is initially presented with a progress bar, cleverly designed to simulate the loading process of a voice message.

Figure 2: Fake voice message loading

Subsequently, a webpage unfolds, adorned with the Ring Central logo and featuring a conspicuous button labelled, "Listen to Voice Message." This orchestrated sequence is deliberately crafted to mislead individuals, creating a false sense of legitimacy by leveraging familiar branding elements. The user, encountering the seemingly authentic environment, may be enticed to click on the provided button, unknowingly falling victim to the deceptive tactics employed by the malicious actors. It underscores the sophistication of the social engineering technique, as it exploits trust in recognizable visuals to enhance the effectiveness of the fraudulent scheme.

Figure 3: Fake Ring Central on Adobe domain

Following the user’s click on the provided link in the PDF file, a redirection occurs, leading them to another malicious URL. At this destination, the user is presented with a phishing page cleverly designed to imitate the Microsoft sign-in interface. The deceptive page is crafted to closely resemble the legitimate Microsoft sign-in page, tricking users into believing they are interacting with an authentic platform.

Figure 4: Microsoft phishing page

On this fraudulent Microsoft sign-in page, unsuspecting users may be prompted to enter their login credentials — such as usernames and passwords — under the false pretense of accessing the supposed voice message or related content. However, the entered information is captured by malicious actors for unauthorized access and potential misuse.
Non-existence of this malicious file (at the time of writing this blog) on popular malware search portals like the Virus Total and the Reversing Labs indicates its spreading potential:

Figure 5: Virus Total

This multi-stage attack involves the initial lure of a fake voice message in the PDF, the redirection to a malicious URL, and the presentation of a deceptive Microsoft sign-in page. It highlights the need for users to exercise caution and verify the authenticity of online interactions, especially when prompted to provide sensitive information, to prevent falling victim to phishing attempts and safeguard personal security.

SonicWall Protections

SonicWall Capture Labs provides protection against this threat via the following signature:

  • GAV: MalAgent.A_1994

This threat is also detected by SonicWall Capture ATP w/RTDMI and the Capture Client endpoint solutions.

IOCs

  • 85a38010b20ce02fd0387b1e36e0ab68a2d87d39d754434e6929dca67e9bc962

Relevant Links

  • hxxps://new[.]express[.]adobe[.]com/webpage/jWVSJkpCewb2X
  • hxxps://zqpfl[.]ipisecti[.]ru/97c9zhbt/

Fake AnyDesk Drops a Myriad of Malicious Tools

/in /by

Overview

This week, the Sonicwall Capture Labs threat research team analyzed a fake copy of AnyDesk. AnyDesk is a legitimate remote desktop application commonly used by tech support agents to troubleshoot computer problems remotely and provide remote assistance. Cybercriminals are known to use such tools by silently installing the application and then using it to remotely control a victim’s machine. However, in this scenario, an unsuspecting user is tricked into installing what seems to be a legitimate copy of AnyDesk. In reality, the download comes with an assortment of malicious software.

Infection Cycle

The malware is hosted on a website with a domain name “Anydesk.cyou” that closely resembles the real AnyDesk website.

Figure 1: Fake AnyDesk website hosting a fake AnyDesk application

The website downloads a file named “Anydsk.exe” which uses the legitimate AnyDesk icon.

Figure 2: Fake application named Anydsk.exe next to a copy of the legitimate AnyDesk.exe using very similar icons

Upon execution, it opens up an installation window that guides you through the installation process.

Figure 3: Fake AnyDesk installation window

This process in fact installs a legitimate copy of the software application in question, however it also installs other components.

The components of the legitimate AnyDesk software are installed in the following directory:

  • %AppData%\Roaming\CAS_BYBAnyDesk\AnyDesk.exe
  • %AppData%\Roaming\AnyDesk\ad.trace
  • %AppData%\Roaming\AnyDesk\service.conf
  • %AppData%\Roaming\AnyDesk \system.conf
  • %AppData%\Roaming\AnyDesk user.conf
    Upon completed installation, it adds a shortcut link to the user’s desktop which runs a legitimate copy of AnyDesk.

Figure 4: Running a legitimate copy of the AnyDesk software application

However, more component files have been installed along with AnyDesk in the %APPDATA% directory as seen in the figure below.

Figure 5: More files, both malicious and clean, were seen installed within a folder in the %APPDATA% directory.

During runtime, we have observed that N0vaDesktop.exe was used to spawn the legitimate wscript executable to run a file named “try.vbs” which contains the following code.

Figure 6: Contents of try.vbs

It executes a batch file named “test.bat” which then launches lnnloader.exe. Below are the contents of test.bat.

Figure 7: Contents of test.bat

Lnnloader.exe is used for reconnaissance and was seen perusing the file system and its registry.

Figure 8: Memory dump of lnnloader.exe seen with the infected system’s information.

It then runs Haloonoroff.exe which was seen constantly connecting to a remote server.

Figure 9: Haloonoroff.exe seen connecting to a remote server

A log file named “Haloonoroff_.log” (or Haloonoroff_20231214.log) was seen created which appeared to be process log.

Figure 10: Event log for Haloonoroff.exe

OTGContainer.exe and SearchRun.exe were copies of N0vaDesktop.exe. PSpendZ.exe is a legitimate tool named PSSuspend, while rar.exe is the command line archiving tool. The rest are non-malicious files.

Interestingly, we also found traces of what seemed to be Tencent QQ -related files that were not seen used during our analysis.

Figure 11: Tencent QQ component files

SonicWall Protections

SonicWall Capture Labs provides protection against this threat via the following signature:

  • GAV: Trojanspy.ANY (Trojan)

This threat is also detected by SonicWall Capture ATP with RTDMI™ and the Capture Client endpoint solutions.

Thanos ransomware encrypts files and installs PowerAdmin for backdoor access

/in /by

The Sonicwall Capture Labs threat research team has recently been tracking a new variant of Thanos ransomware. It is named after the Marvel supervillian and according to the FBI, is created by Moises Luis Zagala Gonzalez, a Venezualan-French cardiologist. Thanos is Ransomware as a Service (RaaS) and has been sold in the underground market place since around Feb 2020. It contains a suite of functionality that includes network spreading, anti-analysis and additional tool download.

Infection Cycle:

Upon infection, the malware encrypts files and drops the following text file on to the desktop:


Each encrypted file is given a .locked file extension. HOW_TO_DECYPHER_FILES.txt is dropped into all directories containing encrypted files.

The malware is written in C# and is trivial to decompile. We can easily see all of its functions:



The malware contains many components to enable it to spread more effectively and hinder analysis. The anti-analysis component contains a list of programs to kill:



The list is base64 encoded. Decoding it reveals the following program names:

AppFilter http analyzer stand-alone fiddler effetech http sniffer firesheep IEWatch Professional dumpcap wireshark wireshark portable sysinternals tcpview NetworkMiner NetworkTrafficView HTTPNetworkSniffer tcpdump intercepter Intercepter-NG ollydbg x64dbg x32dbg dnspy dnspy-x86 de4dot ilspy dotpeek dotpeek64 ida64 procexp procexp64 RDG Packer Detector CFF Explorer PEiD protection_id LordPE pe-sieve MegaDumper UnConfuserEx Universal_Fixer NoFuserEx NetworkMiner NetworkTrafficView HTTPNetworkSniffer tcpdump intercepter

The SniffersKiller function is used to kill all programs in the list if they are running:



The Anti_Analysis class contains basic debugger and sandbox detection:



The network component contains a wake-on-lan function. If the infected machines IP address indicates that it is within a LAN, the malware issues a wake-on-lan signal to bring any sleeping machines back online for potential infection:



Once these machines have woken up, the malware checks if they are online by checking replies to pings:



For each ping response, the malware attempts to log in to each machine. It contains a short basic list of usernames and passwords which it will try:



It contains a DownloadTool function to download additional components.



The base64 string in this function decodes to:

https://www.poweradmin.com/paexec/paexec.exe

PowerAdmin is an open source remote system administration tool similar to PAExec. In this case, it is used as a backdoor to remotely control the infected machine.

We reached out to the email address in the ransom note for details on file retrieval but received no response.

SonicWall Capture Labs provides protection against this threat via the following signature:

GAV: Thanos.RSM_1 (Trojan)

This threat is also detected by SonicWall Capture ATP w/RTDMI and the Capture Client endpoint solutions.

Multi-Stage Chinese Trojan Records Everything, Even Sounds

/in /by

Overview

This week the SonicWall Capture Labs threat research team investigated a sample of malware that has multiple infostealer, monitoring and C2 capabilities. The name of the file is translated as ‘Easy Language Program’ from Chinese, and it has two embedded payloads that are only accessible once a variety of system, language and time zone checks have been passed.

Infection Cycle

The original sample is packed with NsPack, which hinders static analysis. Normally, this format can be unpacked with relative ease, but due to certain unknown changes made, the sample had to be manually extracted from memory while being debugged.

Figure 1: Original sample detection

Figure 2: Unpacked sample detection

When the file is run, there is no window or visible activity. It will attempt to establish the correct environment by collecting information in the following ways:

  • Location via GetSystemLocale, GetTimeZoneInformation, GetLocalTime, FileTimeToLocalTime, FileTimeToSystemTime
  • Debuggers via IsDebuggerPresent, OutputDebugString, GetTickCount, GetEnvironmentStrings, CreateToolhelp32Snapshot, IsProcessorFeaturePresent, NtQuerySystemInformation

If any of these return the incorrect information, the file will terminate immediately. Successfully bypassing these measures will drop two files named ‘Delfile.sys’ and ‘Del.exe’.

Figure 3: Embedded file locations

The .sys file is used explicitly to run ‘Del.exe’ and has a self-modifying section for runtime. There are no imports, functions or libraries listed. ‘Del.exe’ is used to control and register system services. A registry key is written to ‘SYSTEM\CurrentControlSet\Services\DelFile’. This is the persistence mechanism.

Figure 4: Output showing the self-modifying ‘INIT’ section of ‘Delfile.sys’

The main executable uses process injections to inject itself into KernelBase.dll where it hooks into and begins enumerating multiple areas of the system, including but not limited to:

  • Keyboard/Mouse: GetKeyState, GetAsyncKeyState, GetCursorPos
  • Processes: GetCurrentProcess, CreateToolhelp32Snapshot, Process32First, Process32Next
  • Desktop: GetForegroundWindow, GetFocus, GetCapture
  • Registry: RegQueryValue, RegOpenKey, RegCreateKey
  • System Drive Volume: GetVolumeInformation
  • Clipboard: GetClipboardData, FlushClipboardData
  • Audio: waveOutWrite, midiStreamOpen
  • Game software: Xbox, TenCent

The malware also looks for several networking applications: F5 VPN, Checkpoint VPN, SonicWall MobileConnect and Juniper Networks Junos Pulse. There also appears to be HTML code for a page that will show a fake error, potentially to grab credentials.

Figure 5: Partial list of software in unpacked sample

Figure 6: “Bogus message code” is referenced with HTML page code

In addition to this list, there are networking functions used to configure sockets using an older library (ws2_32.dll), along with bcrypt to encrypt any extracted data for transfer. All of the ws2_32 functions are obfuscated by using ordinals instead of the names. Additional tools confirm C2 capabilities, but no network connections were made during analysis.

Figure 7: All of the function names have been removed and replaced with original codes

Figure 8: Partial output of capa showing evasion and C2 capabilities

SonicWall Protections

To ensure SonicWall customers are prepared for any exploitation that may occur due to this malware, the following signatures have been released:

  • MalAgent.Lang.A
  • MalAgent.Lang.B
  • MalAgent.Lang.Del.A
  • MalAgent.Lang.Del.B

IOCs

Hashes
Main: 306710d0aef6d8f233f92a33530fce2758fab778cebe0dde2d047a50428b9813
Main (unpacked): 49d383c2422c1be0651d6c49acbf34f6e3547db3b5305bab3ea480fe383a9481
Del.exe: 7a21cd7f0364e50a2e631348e662a86fc7351ced4b7a9c8eb3f6d0688a2ec52d
Delfile.sys: 85cb69375e8be5ec8f0dfb130253fa13af3563d5dab2e4dc0b10c3dd1336c39a

URLs

  • hxxp://yy[.]com/5336/1705313832
  • hxxp://www.super-ec[.]cn
  • hxxp://wghai[.]com/ec
  • hxxp://qsyou[.]com/ec
  • hxxp://www.wghai[.]com
  • hxxp://bbs.wghai[.]com/forum-17-1.html/forum-12-1.html/memcp.php/ip.asp/time.asp/gonggao.txt/ec-user6.php/ec-bd.php/ec-jh.php

Novel Malicious code evasion method for AI/ML based detection

/in /by

The SonicWall Capture Labs Threat Research team has observed Remcos RAT (Remote Access Trojan) being distributed by adding malicious code in existing open-source software. This appears to be an attempt to evade Security products which are based on Machine Learning / Artificial Intelligence as most of the machine code will be same to that of the clean application code. The malicious code also has anti-sandboxing and anti-emulation features added to it. This further helps in evading Security products.

Binary Comparison with clean application

In the malware sample that we have analyzed, we noticed that the legitimate code was taken from TightVNC Software, which is free and Open-Source remote desktop software that lets you access and control a computer over the network. The source is available on the website downloads page. Below image is the comparison of the analyzed sample against a clean TightVNC viewer (2.8.81) application, which shows approximately 90% of the code is similar in both these files.

Fig1: Binary comparison the sample with the clean binary (TightVNC viewer.exe)

Malicious code Analysis

On analyzing the malware sample binary code, it is observed that a malicious function, which has code to load required DLLs (kernel32.dll, wininet.dll, etc.,) to download additional payloads, has been added to the legitimate source code before compilation. The malicious code is placed in such a way that it gets executed always and exits with an error message if it encounters any failure in the checks (filename not matching, download failing etc.,)

Fig-2: Left side is the original clean code and right side is the decompiled code from the malware

Below is the image which shows that the malicious function is exclusively available in the sample only.

Fig-3: Showing that malicious code does not have a matching function in clean binary

Infection Cycle

The malware code is obfuscated, and it uses anti-emulation and anti-sandbox techniques to evade detection in a controlled environment. The malware terminates the execution by displaying an error message while executed in the controlled environment:

Fig4: Code displays error message in controlled environment

Anti-Sandboxing feature

The malware retrieves its own executable file name and calculates a checksum value by adding each alphabet’s ascii value in the filename. If the checksum value is either 0x7AE or 0x718 then malware continues execution otherwise the malware terminates itself. The corresponding filename for the checksum value 0x7AE is “patchSvc_beta_v2.exe” and filename length must be 0x14. The filename length for checksum value 0x718 must be 0x12. Below is the code to calculate the checksum and filename length:

Fig5: Code calculates and compares checksum of its own executable

Anti-Emulation feature

The malware downloads a PNG image file from Unified Resource Locator (URL) h[t][t]ps://www.pleumeurbodou.com/squelettes/img/port.png by setting user agent value as “spirochete” to the web request:

Fig6: Code downloads a PNG image from an URL

Initial 0x20 bytes from the downloaded PNG image file are used to decrypt the API name “InitOnceExecuteOnce”. The malware retrieves the address of API “InitOnceExecuteOnce” using GetProcAddress and invokes this API by passing argument of the next executable module of the malware. Because the API name is dynamically decrypted using the downloaded image file bytes, this acts as an anti-emulation / anti-analysis feature when the URL is not serving any data or is unreachable.

Fig7: Code decrypts an API name using downloaded data

Next the malware resolves the address and invokes the “VirtualProtect” API by the same manner, it used to execute the “InitOnceExecuteOnce” API. The malware modifies the memory protection to PAGE_EXECUTE_READWRITE to decrypt the next layer code using a hardcoded key and again modifies the memory protection to PAGE_EXECUTE_READ before transferring control to the decrypted code:

Fig8: Code decrypts next layer malicious code

Next the malware drops ASUS software component files into “%APPDATA%\TaskWordpad_test” along with malicious DLL file “AsIO.dll.” The malware executes the “atkexComSvc.exe” which loads malicious DLL file “AsIO.dll” and further executes and injects Remcos malware into explorer.exe:

Fig9: Code does create process for a dropped file

Fig10: Process execution sequence

Remcos is a well-known Remote Access Trojan (RAT) which collects various information from the victim’s machine including executable’s name, computer name, Windows version, RAM information and key logs etc., The malware keeps the Remcos data into registry entry “HCU\Software\Rmc-OPX7KW.” Please refer here for detailed analysis of Remcos RAT.

Fig11: Remcos data stored in the registry entry

The malware keeps the keylogging information into file “C:\ProgramData\remcos\logs.dat” and sends the stolen data to the C&C server “retghrtgwtrgtg.bounceme.net”:

Fig12: File stores keystrokes information

Detection by Security Products

For the first few initial days when the sample was submitted to VirusTotal, it can be observed that there were virtually no detections, which only slowly improved over time. This shows that malware can evade ML/AI based security products during the initial days of propagation by hiding inside a legitimate application code.

Fig13: detections on VirusTotal over time

This threat is detected by SonicWALL Capture ATP with RTDMI.

IOCs

SHA256:

  • 6e07b6ef7a182f367f596cbe4baa148336fa7e7592166ce51e483db81221e220

Network Connections:

  • h[t][t]ps://www.pleumeurbodou.com/squelettes/img/port.png
  • h[t][t]ps://i.imgur.com/vUptouc.png
  • retghrtgwtrgtg.bounceme.net

User Agent:

  • spirochete

Microsoft Security Bulletin Coverage for December 2023

/in /by

Overview

Microsoft’s December 2023 Patch Tuesday includes 33 vulnerabilities, 10 of which are Elevation of Privilege. The vulnerabilities can be classified into the following categories:

  • 10 Elevation of Privilege Vulnerabilities
  • 8 Remote Code Execution Vulnerabilities
  • 5 Information Disclosure Vulnerabilities
  • 5 Denial of Service Vulnerabilities
  • 5 Spoofing Vulnerabilities

December Vulnerabilities by Impact

SonicWall Capture Labs threat research team has analyzed and addressed Microsoft’s security advisories for the month of December 2023 and has produced coverage for seven of the reported vulnerabilities.

Vulnerabilities with detections

CVE-2023-35631   Win32k Elevation of Privilege Vulnerability
ASPY 512 Exploit-exe exe.MP_353
CVE-2023-35632   Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability
ASPY 518 Exploit-exe exe.MP_359
CVE-2023-35633   Windows Kernel Elevation of Privilege Vulnerability
ASPY 513 Exploit-exe exe.MP_354
CVE-2023-35644   Windows Sysmain Service Elevation of Privilege Vulnerability
ASPY 514 Exploit-exe exe.MP_355
CVE-2023-36005   Windows Telephony Server Elevation of Privilege Vulnerability
ASPY 515 Exploit-exe exe.MP_356
CVE-2023-36391   Local Security Authority Subsystem Service Elevation of Privilege Vulnerability
ASPY 516 Exploit-exe exe.MP_357
CVE-2023-36696   Windows Cloud Files Mini Filter Driver Elevation of Privilege Vulnerability
ASPY 517 Exploit-exe exe.MP_358

Remote Code Execution Vulnerabilities

CVE-2023-21740   Windows Media Remote Code Execution Vulnerability
CVE-2023-35628   Windows MSHTML Platform Remote Code Execution Vulnerability
CVE-2023-35629   Microsoft USBHUB 3.0 Device Driver Remote Code Execution Vulnerability
CVE-2023-35630   Internet Connection Sharing (ICS) Remote Code Execution Vulnerability
CVE-2023-35634   Windows Bluetooth Driver Remote Code Execution Vulnerability
CVE-2023-35639   Microsoft ODBC Driver Remote Code Execution Vulnerability
CVE-2023-35641   Internet Connection Sharing (ICS) Remote Code Execution Vulnerability
CVE-2023-36006   Microsoft WDAC OLE DB provider for SQL Server Remote Code Execution Vulnerability

Elevation of Privilege Vulnerabilities

CVE-2023-35624   Azure Connected Machine Agent Elevation of Privilege Vulnerability
CVE-2023-35631   Win32k Elevation of Privilege Vulnerability
CVE-2023-35632   Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability
CVE-2023-35633   Windows Kernel Elevation of Privilege Vulnerability
CVE-2023-35644   Windows Sysmain Service Elevation of Privilege Vulnerability
CVE-2023-36003   XAML Diagnostics Elevation of Privilege Vulnerability
CVE-2023-36005   Windows Telephony Server Elevation of Privilege Vulnerability
CVE-2023-36011   Win32k Elevation of Privilege Vulnerability
CVE-2023-36391   Local Security Authority Subsystem Service Elevation of Privilege Vulnerability
CVE-2023-36696   Windows Cloud Files Mini Filter Driver Elevation of Privilege Vulnerability

Denial of Service Vulnerabilities

CVE-2023-35621   Microsoft Dynamics 365 Finance and Operations Denial of Service Vulnerability
CVE-2023-35635   Windows Kernel Denial of Service Vulnerability
CVE-2023-35638   DHCP Server Service Denial of Service Vulnerability
CVE-2023-35642   Internet Connection Sharing (ICS) Denial of Service Vulnerability
CVE-2023-36010   Microsoft Defender Denial of Service Vulnerability

Information Disclosure Vulnerabilities

CVE-2023-35625   Azure Machine Learning Compute Instance for SDK Users Information Disclosure Vulnerability
CVE-2023-35636   Microsoft Outlook Information Disclosure Vulnerability
CVE-2023-35643   DHCP Server Service Information Disclosure Vulnerability
CVE-2023-36009   Microsoft Word Information Disclosure Vulnerability
CVE-2023-36012   DHCP Server Service Information Disclosure Vulnerability

Spoofing Vulnerabilities

CVE-2023-35619   Microsoft Outlook for Mac Spoofing Vulnerability
CVE-2023-35622   Windows DNS Spoofing Vulnerability
CVE-2023-36004   Windows DPAPI (Data Protection Application Programming Interface) Spoofing Vulnerability
CVE-2023-36019   Microsoft Power Platform Connector Spoofing Vulnerability
CVE-2023-36020   Microsoft Dynamics 365 (on-premises) Cross-site Scripting Vulnerability

VMware vCenter DCERPC Dealloc Pointer Manipulation

/in /by

Overview

SonicWall Capture Labs Threat Research Team became aware of the threat CVE-2023-34048 (a vCenter Server out-of-bounds write vulnerability), assessed its impact, and developed mitigation measures for the vulnerability.

VMware vCenter Server is a centralized management platform for VMware vSphere environments, designed to provide a unified and efficient administration experience. It allows IT administrators to manage virtualized hosts and virtual machines across multiple physical servers from a single console. vCenter Server plays a crucial role in resource provisioning, monitoring and performance evaluation of virtual infrastructures.

The identified vulnerability in VMware’s vCenter Server is a critical security flaw stemming from an out-of-bounds write issue in its implementation of the Distributed Computing Environment / Remote Procedure Call (DCERPC) protocol. This protocol is used for inter-process communication, and the vulnerability arises due to improper handling of certain inputs. Consequently, a malicious actor with network access to vCenter Server can exploit this vulnerability to execute an out-of-bounds write operation.

This type of vulnerability can be particularly dangerous as it may allow the attacker to write data outside the bounds of allocated memory buffers, potentially leading to remote code execution. Such an exploit could provide the attacker with unauthorized control over the vCenter Server, posing a significant risk to the security and integrity of the virtualized environment managed by vCenter.
Our research concluded that the most feasible outcome of such an attack is the creation of a Denial of Service (DoS) condition on the server, and it is highly unlikely remote execution can be achieved. This vulnerability underscores the need for stringent security measures and prompt patching of software components in enterprise virtualization infrastructures. To mitigate this vulnerability, we recommend that you update to the latest version of VMware vCenter Server.

The affected versions are:

  • vCenter Server 4.0 (including updates and specific builds like 4.0.0.10021, 4.0.0.12305)
  • vCenter Server 4.1 (including updates 1 and 2, and specific builds like 4.1.0.12319, 4.1.0.14766, 4.1.0.17435)
  • vCenter Server 5.0 (including beta, updates and specific build 5.0.0.16964)
  • vCenter Server 5.5 (including updates and variations like 1, 1a, 1b, 1c, 2, 2b, 2d, 2e, 3, 3a, 3b, 3d, 3e, 3f, b, c, u1, u2, u3a, u3b)
  • vCenter Server 7.0 (including updates and variations like a, b, c, d, 1, 1a, 1c, 1d, 2, 2a, 2b, 2c, 2d, 3, 3a, 3c, 3d, 3e, 3f, 3g, 3h, 3i, 3j, 3k, 3l, 3m, 3n)
  • vCenter Server 8.0 (including updates and variations like a, b, c, 1, 1a, 1b, 1c)

CVE Details

This vulnerability has been assigned the Common Vulnerabilities and Exposures (CVE) identifier CVE-2023-34048.

The overall CVSS score is 9.8 (CVSS:3.1/ AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H/E:X/RL:X/RC:X).

The base score is 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), based on the following metrics:

  • Attack vector is network.
  • Attack complexity is low.
  • Privileges required is none.
  • User interaction is none.
  • Scope is unchanged.
  • Impact of this vulnerability on data confidentiality is high.
  • Impact of this vulnerability on data integrity is high.
  • Impact of this vulnerability on data availability is high.

Technical Overview

In DCE/RPC, there are several packet types (as seen in Figure 1), each serving a specific purpose in the communication process. These packet types are defined as part of the protocol and are used to manage various aspects of RPC communication, such as establishing connections, transmitting data and handling errors.

Figure 1 – Packet Types

The packet types numbered 11 through 19 are of particular interest when assessing this vulnerability. The descriptions of each packet type are listed below:

  • RPC Bind (11): Used to establish a connection between a client and a server. It contains information about the requested interface, data representation and any optional authentication data.
  • RPC Bind Acknowledgement (12): Sent by the server in response to a bind request, indicating acceptance of the bind or providing negotiation results.
  • RPC Bind NAK (Negative Acknowledgement) (13): Sent by the server if it cannot accept the bind request, often with information about why the request was rejected.
  • RPC Alter Context (14): refers to an "Alter Context" indication, used to modify the context of an existing association between communication partners in an RPC session, typically to change or negotiate protocol data units or other session parameters.
  • RPC Alter Context Response (15): is the "Alter Context Response," which serves as a confirmation to an Alter Context request (Packet Type 14), indicating the acceptance, rejection, or modification of the proposed context changes in an RPC session.
  • RPC Auth3 (16): represents the "Auth3" indication, a message used in the authentication process, typically as the third step in a three-way handshake for establishing a secure and authenticated communication session.
  • RPC Shutdown (17): signifies the "Shutdown" indication, which is used to notify the communication parties of an impending shutdown or termination of the association in the RPC session.
  • RPC Remote Alert (18): is the "Remote Alert" indication, used to signal an alert or notification from a remote procedure call, indicating a significant event or condition that requires attention during the RPC communication process.
  • RPC Orphaned (19): represents the "Orphaned" message, which is used to indicate that a remote procedure call has been orphaned, or abandoned, typically signaling that the client has terminated the call before the server has completed processing.

Delving further into the “libdcerpc.so” library to understand how vCenter Server manages RPC network communication is crucial. This exploration is key to comprehending the complexities of the vulnerability. The group of functions shown in Figure 2, within this library, play a vital role in regulating data flow, safeguarding security and upholding the communication process’s integrity. Working collaboratively, the following functions address different facets of network interaction, each with its distinct function.

Figure 2 – Simple Overview of Nested Functions

  • Receive_dispatch(): This function acts as the entry point for processing incoming network messages, managing packet reception and handling based on their types and the connection state.
  • Receive_packet(): Responsible for the actual reception and processing of packets, this function manages data fragments, handles overflow buffers and ensures the accurate reconstruction of data.
  • Rpc__cn_unpack_hdr(): Specializing in unpacking packet headers, this function adjusts packet fields according to data representation and byte order, playing a critical role in the interoperability of different systems.
  • Rpc_cn_assoc_eval_network_event(): This function processes network events in relation to an RPC association. It evaluates events with or without a fragment buffer, affecting the association’s state and maintaining the consistency of the network communication.

To further our understanding, it is essential to delve into two key foundational concepts:

  • Pointer Manipulation: This involves the ability to effectively handle and manipulate memory addresses stored in pointers. Proficiency in pointer manipulation allows for direct interaction with memory, which is crucial in systems programming and memory management tasks.
  • Structure Memory Layout: Understanding how data structures are laid out in memory is critical. This includes knowing the size and alignment of different data types and how they are sequenced within a structure. A thorough grasp of memory layout is vital for efficient memory usage and for interfacing with hardware or low-level system components.

Pointer Manipulation (Linear Understanding)

In 64-bit systems, pointers usually have an 8-byte (64-bit) size, enabling them to address a vast memory space. Manipulating these pointers for memory navigation involves a linear process. Consider a pointer defined as “long long *ptr = (long long *)0x7fff5fbffec0,” which points to an 8-byte long long integer. Moving this pointer is accomplished in increments equal to the size of the data type it references.

To advance the pointer to the next long long integer, you increment it: ptr++, which adds 8 bytes to the address, making it point to 0x7fff5fbffec8. Similarly, decrementing the pointer with ptr– moves it back by 8 bytes to 0x7fff5fbffec0.
 
This linear movement can be extended to skip multiple elements, like ptr += 2 to move forward 16 bytes, or ptr -= 2 to move back 16 bytes. This approach allows for effective traversal and manipulation of memory locations, but it requires careful handling to avoid errors like accessing invalid memory areas.

Figure 3 – Pointer Example

Pointer Manipulation (Vertical Understanding)

In the context of a debugger’s memory window, which typically displays memory in a linear, byte-oriented format, moving a pointer as demonstrated in the example reflects a vertical traversal through memory addresses. The memory window is often organized in rows and columns, with each row representing a contiguous block of memory addresses. When the pointer long long *ptr = (long long *)0x7fff5fbffec0; is incremented (ptr++), it moves ‘down’ to the next memory block, shifting from 0x7fff5fbffec0 to 0x7fff5fbffec8.
This is because each increment steps through 8 bytes (the size of a long long in a 64-bit system), effectively descending to the next row in the memory window. Conversely, decrementing the pointer (ptr–) moves it ‘up’ to the previous memory block. Adjustments like ptr += 2 or ptr -= 2 result in moving two rows down or up, respectively.
In the debugger’s memory window, this movement appears vertical, navigating through the memory rows, while each column within a row typically represents a single byte. This visualization aids in understanding how pointers access and manipulate specific locations in the system’s memory space.

Structure Layout

Viewing memory as linear or vertical from above, we can now understand the “rpc_cn_fragbuf_s_t” structure in C as seen Figure 4. This structure, with its specific memory alignment and field layout, is designed to manage fragment buffers in RPC communication. The structure begins with an ‘rpc_list_t’ link, occupying 16 bytes, which serves as a linked list node. This allows the fragment buffer to be part of a list, with pointers to the next and previous elements. Following this is a 4-byte ‘unsigned32 freebuf’, a flag indicating whether the buffer should be freed. Another 4-byte ‘unsigned32’ field, ‘max_data_size’, specifies the maximum data capacity of the fragment buffer.

Figure 4 – Structure Layout

The rpc_cn_fragbuf_dealloc_fn_t fragbuf_dealloc is an 8-byte function pointer for deallocating the fragment buffer. Next is an 8-byte pointer_t data_p, pointing to the actual data stored in the fragment buffer. The unsigned32 data_size field, 4 bytes long, records the current size of the data. An additional 4-byte unsigned8 overhead_area[4] is reserved for miscellaneous use or overhead information.

Finally, a 1-byte unsigned8 data_area[1] array is a flexible array member used to reference the start of the data region, typically used to access the packet data (pkt_p pointer) stored in the buffer. The structure is aligned to 8 bytes, ensuring optimal access on 64-bit systems and maintaining compatibility with different compilers through conditional compilation directives (__declspec(align(8)) for MSVC and __attribute__((aligned(8))) for GCC/others).

Triggering the Vulnerability

Identified in Figure 5 as the start of the vulnerability, this code manipulates pointers and memory within a network packet structure, specifically within an RPC binding header. Initially, the variable authlen is assigned the value of the auth_len field from the packet’s common header. An offset is then calculated, which is set to authlen + 8.

The pointer ppDealloc is set to point to a specific location within the packet, calculated by subtracting this offset from the address at the end of the fragment (frag_len from the packet’s start). The value at ppDealloc is then accessed and stored in pDealloc. Following this, the code performs a byte swap operation on the 4 bytes immediately following ppDealloc.

Figure 5 – epilogue of rpc__cn_unpack_hdr()

The reason behind why this works is the following formula:

  ppDealloc = pkt_p + (frag_len – (auth_len + 8))

The math in the round brackets (frag_len – offset) creates a negative number result, which moves the pkt_p pointer upward to the fragbuf_dealloc pointers address when added together (in other words, subtracted because of the negative number).

In the disassembly of the RPC communication process, shown in Figure 6, a sequence of operations is performed on the “rpc_cn_fragbuf_s_t” structure. The operations reveal intricate aspects of vulnerability exploitation. The steps are as follows:

Figure 6 – Disassembly of rpc__cn_unpack_hdr()

  • [1] Auth_len Retrieval: The disassembly begins with the retrieval of the auth_len value from the memory (indicated by movzx ecx, word ptr [pkt_p+0Ah]). This step is crucial for understanding the subsequent operations involving authentication length.
  • [2] Frag_len Retrieval: Immediately following is the extraction of frag_len (movzx eax, word ptr [pkt_p+8]). This value is essential for determining the length of the fragment.
  • [3] Auth_len Modification: The value of auth_len is then increased by 8 (lea rdx, [rcx+8]), resulting in a total of 24 in decimal. This modification plays a role in adjusting the authentication length for further processing.
  • [4] Subtraction to Create Negative Value: A critical operation involves subtracting auth_len from frag_len (sub rax, rdx). This results in a negative number (-24), indicating a decrease in fragment length relative to the authentication length.
  • [5] Pointer Manipulation: The magic of this vulnerability lies here. The pkt_p pointer is adjusted by adding the negative number (-24) (add rax, pkt_p). This effectively moves the pointer backward in memory, reaching the dealloc member above in the structure, and creating an unexpected behavior in memory management.
  • [6] Byte Order Reversal: Finally, there is a reversal of the base address byte order from 0x00007f74 to 0x747f0000 (bswap edx). This operation changes the way bytes are read and interpreted, further complicating the vulnerability exploitation process.

Due to the vulnerability involving a byte-swap of the base address, it is important to note that an attacker lacks control over the final, byte-swapped base address. This limitation is critical because it restricts the attacker’s ability to execute arbitrary code or manipulate the server’s operations in a specific, intended manner.
Instead, the most feasible outcome of such an attack is the creation of a Denial of Service (DoS) condition on the server. In a DoS scenario, the attacker can disrupt the normal functioning of the server, potentially causing it to crash or become unresponsive, but cannot directly control or alter the server’s behavior beyond causing this disruption. This limitation stems from the inability to predict or influence the final state of the memory after the byte swap, making it highly unlikely to execute precision attacks like injecting or executing specific malicious code. As a result, the attack vector, while serious, is likely confined to causing service interruptions rather than enabling direct system compromise or data theft.

Figure 7 below involves checking packet information and determining an event type based on the packet information. Execution returns to the calling function receive_dispatch, and it then follows with a check on the “class” member of the “packet_info_table” at index “ptype” (packet type) which is true (non-zero). This area of code assigns v14 the value of fragbuf_p and returns from the if else statement calling rpc_cn_assoc_eval_network_event().

Figure 7 – Receive_Dispatch()

Once inside the rpc_cn_assoc_eval_network_event function, an attempt is made to deallocate the fragment buffer. However due to an invalid function pointer, the application will crash at the call to “fragbuf_dealloc(fragbuf),” suggesting the pointer has been manipulated from the above swap of the base address.

Figure 8 – RPC_CN_ASSOC_EVAL_NETWORK_EVENT()

Exploitation

The following packet, in Figure 9, produces a Denial-of-Service (DoS) crash or segment fault:

Figure 9 – Attack Packet

This demo video below demonstrates the results of the packet in Figure 9 being sent to the vulnerable version VMWare vCenter Server 8.0U1c. As explained in Figure 8, a crash occurs on a jmp rax instruction, since rax now has an invalid pointer stored within it.

Figure 10 – Video of attack packet causing crash

SonicWall Protections

To ensure SonicWall customers are prepared for any exploitation that may occur due to this vulnerability, the following signatures have been released:

  • IPS: 4176 VMware vCenter Malformed DCERPC Traffic
  • IPS: 4187 VMware vCenter Malformed DCERPC Traffic 2
  • IPS: 19483 VMware vCenter Malformed DCERPC Traffic 3
  • IPS: 19484 VMware vCenter Malformed DCERPC Traffic 4
  • IPS: 19485 VMware vCenter Malformed DCERPC Traffic 5

Recommended Mitigations

The risks posed by this vulnerability can be mitigated or eliminated by:

  • Applying the vendor-supplied patch to eliminate this vulnerability.
  • Utilizing up-to-date IPS signatures to filter network traffic.
  • Alternatively, consider taking the server offline.

Splunk Remote Code Execution

/in /by

Overview

The SonicWall Capture Labs Threat Research team has observed attackers targeting a critical vulnerability affecting Splunk Enterprise. Splunk Enterprise does not safely sanitize extensible stylesheet language transformations (XSLT) that users supply. This means that an attacker can upload a malicious XSLT that may result in remote code execution on the Splunk Enterprise instance. This issue is identified as CVE-2023-46214, has a CVSS base score of 8.8 and can lead to remote code execution (RCE) in Splunk Enterprise through insecure XML Parsing. Splunk Enterprise versions below 9.0.7 and 9.1.2 and Splunk Cloud versions below 9.1.2308 are known to be vulnerable. The vulnerability has been patched in Splunk Enterprise versions 9.0.7 and 9.1.2.

CVE Details

This vulnerability has been assigned the Common Vulnerabilities and Exposures (CVE) identifier CVE-2023-46214.

The overall CVSS 3.1 score is 8.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H).
The base score is 8.8 (AV:N/AC:L/PR:N/UI:R/S:U/C:/I:H/A:H), based on the following metrics:

  • Attack vector is network.
  • Attack complexity is low.
  • Privileges required is none.
  • User interaction is required.
  • Scope is unchanged.
  • Impact of this vulnerability on data confidentiality is high.
  • Impact of this vulnerability on data integrity is high.
  • Impact of this vulnerability on data availability is high.

Temporal score is 8.0 (E:P/RL:O/RC:C), based on the following metrics:

  • The exploit code maturity level of this vulnerability is proof-of-concept code.
  • The remediation level of this vulnerability is an official fix.
  • The report confidence level of this vulnerability is confirmed.

Technical Overview

Splunk Enterprise is a data analytics platform that forms the backbone of many corporate IT infrastructures.
CVE-2023-46214 stems from improper sanitization of extensible stylesheet language transformations (XSLT) that users supply. The attack can be performed remotely but requires authentication (knowledge of valid credentials) and some user interaction.
Splunk’s built-in functionality allows XSLT file to transform data. Attackers can leverage this functionality and execute a malicious script within this XSLT file. Upon successful login, and after uploading the XSLT file, the attacker gains the ability to execute commands on the Splunk server.

Exploitation

The SonicWall Capture Labs Threat Research team has been able to recreate the publicly released proof of concept (PoC).

The following steps are needed to exploit this vulnerability:

  • An attacker needs to know the username and password of at least one registered user as it is an authenticated vulnerability.
  • The exploitation starts by sending a HTTP POST login request to the victim server.
  • Once logged in, an attacker uploads a malicious XSL, which is the main part of payload. An example of this payload can be seen in Figure 1 below.

Figure 1: Sample – malicious XSLT file

  • In the final step, an attacker gets reverse shell upon successful execution via runshellscript SPL command within the Splunk web search interface , as seen in Figure 2.

Figure 2: Execute SPL command runshellscript to send the reverse shell

Figure 3: SonicWall Capture Labs Threat Research Exploitation

SonicWall Protections

To ensure SonicWall customers are prepared for any exploitation that may occur due to this vulnerability, the following signature has been released:

  • IPS:15942 – Splunk Enterprise XML Injection

Remediation Recommendations

Admins still running one of the vulnerable software versions should upgrade to version 9.0.7 or 9.1.2, which fixes this issue.
If that’s not possible, users can limit the ability of search job requests to accept XML stylesheet language (XSL) as valid input. Further steps to mitigate are dictated on the official link.

Remediation Recommendations

ownCloud GraphAPI Sensitive Data Exposure

/in /by

Overview

This week, the SonicWall Capture Labs Threat Research Team became aware of a disclosure of sensitive information vulnerability in ownCloud’s GraphAPI application, assessed its impact and developed mitigation measures for the vulnerability. ownCloud, an open-source software for sharing and syncing of files in distributed environments, published an advisory on this sensitive credentials and configuration disclosure vulnerability affecting ownCloud graphapi application versions 0.2.x before 0.2.1 and 0.3.x before 0.3.1.

It can be exploited effortlessly by an unauthenticated remote attacker and carries significant associated critical risk. The vulnerability was also given the highest CVSS score of 10.0. Because of all this, it’s not only capturing the imagination of the cybersecurity community, but it’s also reportedly being exploited in the wild rapidly, making it a strong candidate to join CISA’s Known Exploited Vulnerabilities (KEV) catalog. Hence, it is advisable for ownCloud users to take the mitigation steps provided in the remediation recommendations section.

Update 12/3/23

Due to this vulnerability’s severity and easy of exploitation, it is catching attention of cybersecurity community all around the world resulting in many exploring a way to exploit the containerized deployment, previous reported as unexploitable. Researchers at Rapid7 recently reported a technique to overcome the hardening offered by the mod_rewrite segment of the .htaccess file, making the docker mode of installation as vulnerable as the manual one removing any speculation around the severity of this CVE due to limited exploitation possibilities.

CVE Details

This vulnerability has been assigned the Common Vulnerabilities and Exposures (CVE) identifier CVE-2023-49103.

The overall CVSS score is 10.0 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H).
Base score is 10.0 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H), based on the following metrics:

  • Attack vector is network.
  • Attack complexity is low.
  • Privileges required is none.
  • User interaction is none.
  • Scope is changed.
  • Impact of this vulnerability on data confidentiality is high.
  • Impact of this vulnerability on data integrity is high.
  • Impact of this vulnerability on data availability is high.

Technical Overview

The vulnerable version of the graphapi application, which comes installed by default if you choose manual or docker-based way of installation, contains the endpoint /apps/graphapi/vendor/microsoft/microsoft-graph/tests/GetPhpInfo.php. That endpoint reveals the critical configuration details as a part of the output of the phpinfo function when accessed by the unauthenticated remote attacker as seen in Figure 1.

Figure 1: Vulnerable endpoint in graphapi

However, the ownCloud docker does not expose the vulnerable endpoint by default due to the additional mod_rewrite block present in the .htaccess file, as illustrated in Figure 2, which triggers a redirection to the login page when someone navigates to the endpoint. On the other hand, by default, the manual installation allows access to the endpoint making the docker mode of installation relatively safer. It’s noteworthy to mention that enabling graphapi is not a prerequisite for the exploit to work.

Figure 2: Additional mod_rewrite block in docker installation

Triggering the vulnerability

Triggering this vulnerability is a breeze, as it only requires hitting the vulnerable endpoint, such as http(s)://example-owncloud[.]com/apps/graphapi/vendor/microsoft/microsoft-graph/tests/GetPhpInfo.php. The attacker only needs to have network access to the vulnerable software.

Exploitation

As demonstrated in Figure 3, successful exploitation of this vulnerability yields the attackers a bunch of juicy information that is stored in the environment variable. This includes the configuration variables of the webserver and may also contain critical information such as mail server credentials, license keys, AWS secrets and other confidential data in case of containerized deployment with vulnerable configuration.

Figure 3: Sample successful exploitation

SonicWall Protections

To ensure SonicWall customers are prepared for any exploitation that may occur due to this vulnerability, the following signature has been released:
  • IPS:4186 ownCloud GraphAPI Sensitive Data Exposure

Threat Graph

SonicWall sensors have confirmed the spike in the exploitation attempts of this vulnerability and may witness even a surge in upcoming days considering the simplicity of exploitation.

Figure 4: SonicWall signature hits data (Updated 12/3/23)

Remediation Recommendations

ownCloud has released an update to address the issue, and it is strongly recommended to update the graphapi application to the latest version 0.3.1.

Those who are not able to update immediately can also apply the workaround by deleting the root cause file /apps/graphapi/vendor/microsoft/microsoft-graph/tests/GetPhpInfo.php and plan for the update as early as possible.

Relevant Links

The Unseen Layers: Exploring the Tactics of Multistage .NET Malware Packers

/in /by

OVERVIEW

Recently, the SonicWall Capture Labs Threat Research team has identified a new .NET Packer that is currently being widely used by the various stealers such as Lokibot, AgentTesla etc. In the ever-evolving landscape of cybersecurity threats, malicious actors continue to develop sophisticated techniques to compromise systems and exploit vulnerabilities. One such method gaining prominence is the use of multistage .NET malware packers. These devious tools leverage the capabilities of the .NET framework to execute nefarious activities, posing a significant challenge to the cybersecurity of endpoints.
Packers employ the dynamic loading features of .NET, allowing them to download and execute additional modules or payloads off the land without ever touching the secondary storage such as Hard Disks.

To avoid detection, Packer employs evasion techniques such as polymorphic code, obfuscation and encryption. These methods make it difficult for security tools to analyze the malicious code, as it constantly changes its appearance or remains concealed within layers of encryption.

INFECTION CYCLE

Currently, Packer is mainly delivered though phishing emails with a .ZIP file as an attachment. The ZIP attachment contains the PE Packer file.

Figure 1: Infection Chain

TECHNICAL OVERVIEW

Layer 1 of Packer consists of an encrypted layer and the final payload as resource objects. Its execution begins by decrypting the next layer, which is encrypted as a resource of the Packer file named “QuanLyKhSan.GUI.ucDichVu.FR”.

Figure 2: Resource objects stored in layer 1

Figure 3: Decryption code logic for layer 2

Layer 2, which is a DLL file, consists of six exported functions.

Figure 4: Layer 2 classes along with function names

It decrypts the resource “GloriousCore.Properties.Resources.resources.HgoHWhJ”, which is an encrypted fifth layer. Meanwhile, decrypting it causes it to sleep for 15 seconds to evade detection from emulators.

UNVEILING THE FINAL PAYLOAD

1.) Loading of Ⴈ.dll

  • a. Ⴈ.dll is hardcoded in layer 2 as an encrypted byte array.
  • b. The byte array is first transformed using a simple XOR operation.

    Figure 5: XOR operation

  • c. The transformed array is then decompressed using the deflate algorithm and loaded into memory.
  • d. “Ⴈ.dll” has an encrypted resource named "Xeros.Vu.resources. Ⴐ"

2.) Decryption of resource “Xeros.Vu.resources. Ⴐ”

  • a. Layer 2 uses GZipStream to decompress the resource object “Ⴐ”.
  • b. It decrypts the decompressed buffer using an XOR loop.
  • c. The decrypted bytes are a DLL module called “ReactionDiffusion.dll”

    Figure 6: Functions names and XOR keys are stored in an encoded array.

3.) An instance of the ReactionDiffusion.dll module is created.

  • a. ReactionDiffusion.dll decrypts the method name “CausalitySource”.

    Figure 7: Invoking the function “CausalitySource”

  • b. The resource “HgoHWhJ” is a PNG file.

  • c. Packer uses steganography to hide the encrypted layer 5. It executes the function “RestoreOriginalBitmap” to convert the bitmap PNG file into an encrypted byte array.

    Figure 8: Bitmap decoding function from ReactionDiffusion.dll

  • d. An encrypted byte array is decrypted using an XOR loop with three byte keys.

    Figure 9: Decryption function for layer 5

  • e. Final output is the “Tyrone.dll” module.
    4.) Tyrone.dll has an embedded encrypted final payload. In this case, it’s LokiBot.

    Figure 10: Final payload embedded as resource

  • a. Encrypted resource “bcBuFuHG” is decrypted using a simple XOR.

Figure 11: Loading of resource using Resource Manager

Figure 12: Decryption code of the final payload

Lastly, the final payload is injected into a newly created self-process using process hollowing. The final payload in this analyzed Packer is identified as LokiBot, for which we have already written a blog post.

Evidence of the detection by SonicWall’s patented RTDMI™ engine can be seen below in the Capture ATP report for this file:

Figure 13: RTDMI ATP result report conclusion

As .NET malware packers continue to evolve, so must our cybersecurity strategies. Staying informed about the latest threat vectors, adopting advanced security solutions and fostering a proactive cybersecurity posture are essential steps in mitigating the risks posed by these insidious threats. By understanding the intricacies of .NET malware packers, organizations can better protect their systems and data from the ever-present challenges of the digital landscape.

IOCs:

ZIP

  • 070b7112e24ec3a1f2d7cfab98cee1e7f3940a33b199e4ae04b367f9dd20d451

Packer

  • 301e3dd329bd0c0aa4f40a68100350867bd5c956a13f238eedbf68d58c13f2e9
  • 26c034022d9d6924477e3e79cc95590f394e3ccf2ad743163c5a80baacf2a66f
  • 4c9c03f472adf45cc9f246fdf83b28fd1e197bc2ad831dfb75371bb14d5b5585

Lokibot

  • d51297e331fce1ba9f707991445e746a5bce48b1892dfc79d107dcbff9a0b2cf

AgentTesla

  • a02e8a878b70f214f0b9cff49a7d1f594114b80dd1935f9f9e4ea19fb978ba54