Overview

This week, the SonicWall Capture Labs threat research team investigated a sample of the RemcosRAT that uses a PrivateLoader module to provide additional data and persistence on the victim’s machine. By installing VB scripts, altering the registry and setting up services to restart the malware at variable times or by control, this malware is able to infiltrate a system completely and remain undetected.

Infection Cycle

The sample is detected as a 32-bit PE file with no packer or protector.

Figure 1: Initial detection

When looking into the sections and API calls of the file, different tools give different reports. Detect It Easy shows API calls that have been cleared (to obfuscate what they’re doing), and TLS (Thread Local Storage) functionality, meaning that malicious code can be prepared or run before the main file has started at its entry point. PEStudio, however, shows all available API calls but no TLS functionality.

Figure 2: Every call from ws2_32.dll has been obfuscated

Figure 3: A separate tool shows all hidden calls

Once functions are properly labeled, the file is shown to have the following capabilities:

• Anti-analysis/ Anti-VM
  • GetSystemTimeAsFileTime
  • GetTickCount
  • IsDebuggerPresent
  • IsProcessorFeaturePresent
  • QueryPerformanceCounter
  • QueryPerformanceFrequency
• System Enumeration
  • CreateToolhelp32Snapshot
  • EnumDisplaySettingsW
  • EnumServicesStatusW
  • EnumSystemLocalesW
  • EnumWindows
  • FindFirstFileA/Ex/W
  • FindNextFileA/Ex/W
  • GetClipboardData
  • GetCurrentProcessId
  • GetCurrentThreadId
  • GetEnvironmentStrings
  • GetLogicalDriveStringsA
  • GetLocalTime
  • GetLocaleInfoA/W
  • GetNativeSystemInfo
  • GetStartupInfo
  • GetTimeZoneInformation
  • GetUserDefaultLCID
  • GetWindowThreadProcessId
  • IsLocaleValid
  • OpenClipboard
  • RegEnumKeyA/W
  • RegEnumValueA/W
  • SystemParametersInfoW
• Monitoring
  • GetCursorPos
  • GetForegroundWindow
  • GetKeyState
  • GetKeyboardLayout
  • GetKeyboardState
  • Mouse_event
  • ReadProcessMemory
  • SetWindowsHookExA
  • waveInAddBuffer
  • waveInStart
• Process Injection
  • GetProcessId
  • GetModuleHandleA/Ex/W
  • CreateProcessA/W
  • Process32FirstW
  • ProcessNextW
  • VirtualAlloc
  • VirtualFree
  • VirtualProtect
  • WriteProcessMemory
• Persistence
  • AdjustTokenPrivilege
  • ControlService
  • GetTempFileNameW
  • LookupPrivilegeValueA
  • OpenProcess
  • OpenProcessToken
  • RegCreateKeyA/Ex/W
  • RegDeleteKeyA/Ex/W
  • RegDeleteValueA/Ex/W
  • RegSetValueA/Ex/W
  • ShellExecuteExA/W
  • WriteFile
• Communication
  • InternetOpenUrlW
  • InternetReadFile
  • URLDownloadToFileW
  • URLOpenBlockingStreamW
  • Inet_addr
  • Gethostbyaddr
  • Gethostbyvalue
  • getservbyvalue
  • Connect
  • Send
  • socket
  • Recv

Runtime shows that if security checks are not initially cleared by modules within ntdll.dll, the main portion of the executable will not be touched before it exits. No files are dropped, and nothing is injected into memory.

Figure 4: Beginning of the security check function

Once security has been passed, which consists of VM, locale, timezone and analysis tool enumeration, two files are dropped.

• C:\Users\user\AppData\Local\Temp\install.vbs
• C:\Users\user\AppData\Roaming\data\notepads.exe

Notepads.exe is a copy of the parent executable placed for persistence. The script contains the following four lines and is deleted once executed – there is no check on whether or not this action is successful. The script will simply delete itself if it is run before ‘notepads.exe’ is dropped.

Figure 5: Install.vbs contents

User security access is then checked. If applicable, Windows User Access Control is disabled with the following command to allow for privileged access:

/k %windir%\System32\reg.exe ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLUA /t REG_DWORD /d 0 /f

Figure 6: UAC is disabled

At this point, the system is enumerated fully and hooks are implemented to track keystrokes, mouse actions, audio and screen grabs. Targeted software includes browsers by searching the following locations for logins and cookie data, as well as the clipboard data being pulled:

\AppData\Local\Google\Chrome\User Data\Default\Login Data

\AppData\Local\Google\Chrome\User Data\Default\Cookies

\AppData\Roaming\Mozilla\Firefox\Profiles\

\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders

\AppData\Local\Microsoft\Edge\

\Opera Software\Opera Stable\

\User Data\Default\Network\Cookies

This information is stored in ‘logins.json’ and ‘key3.db’, also seen in the screenshot below.

Figure 7: Browser paths and storage files

Once complete, ‘notepads.exe’ will open a socket on the system and reach out to two URLs. The first is a GET request to geoplugin(dot)net/json.gp, which returns geographic information pertaining to the victim’s IP address. The second is to nuevosremcs.duckdns.org. Once a connection is made, a config file is created and sent to the server. Here is the configuration observed during runtime:

{

“Host:Port:Password”: “nuevosremcs.duckdns.org:9090:1”,

“Assigned name”: “Nuevos”,

“Connect interval”: “1”,

“Install flag”: “Enable”,

“Setup HKCU\Run”: “Enable”,

“Setup HKLM\Run”: “Enable”,

“Install path”: “AppData”,

“Copy file”: “notepads.exe”,

“Startup value”: “system32”,

“Hide file”: “Disable”,

“Mutex”: “Rmc-WRNU47”,

“Keylog flag”: “1”,

“Keylog path”: “Application path”,

“Keylog file”: “logs.dat”,

“Keylog crypt”: “Disable”,

“Hide keylog file”: “Disable”,

“Screenshot flag”: “Disable”,

“Screenshot time”: “10”,

“Take Screenshot option”: “Disable”,

“Take screenshot title”: “”,

“Take screenshot time”: “5”,

“Screenshot path”: “AppData”,

“Screenshot file”: “Screenshots”,

“Screenshot crypt”: “Disable”,

“Mouse option”: “Disable”,

“Delete file”: “Disable”,

“Audio record time”: “5”

}

At this point the C2 has assumed control and can remotely stop, start and engage further monitoring or file downloads for other functionality.

SonicWall Protections

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

• PrivateLoader

IOCs

Parent sample / Notepads.exe: 27bb3968cc18fb0df5b14e6d1b805552

Install.vbs: a7fe45cc57afb3dba91ab77483fffa0a

Mutex Created

• \Sessions\1\BaseNamedObjects\Rmc-WRNU47

IP Addresses

• 246.82.10
• 237.33.50

URLs

• http://geoplugin.net/json.gp
• duckdns.org

Overview

The SonicWall Capture Labs threat research team became aware of CVE-2024-31984, which is a code injection vulnerability in XWiki’s management of space titles and has a critical CVSS score of 9.9. After assessing the impact, we developed mitigation measures to address the vulnerability. This vulnerability, originating from insufficient input validation, allows remote, authenticated attackers to execute arbitrary code on the target server by creating documents with maliciously crafted titles. The team’s efforts have focused on understanding the severity of the risk and ensuring that users can securely manage and operate their XWiki platforms without compromise.

The versions of XWiki Platform impacted by the remote code execution vulnerability encompass a broad range of releases. Specifically, the vulnerability affects all versions starting from 7.2-rc-1 up to, but not including the patched versions 14.10.20, 15.5.4 and 15.10-rc-1. This wide span of versions includes any builds prior to 4.10.20, making it imperative for users operating on these versions to update their systems. The vulnerability has been effectively addressed in the newer versions 14.10.20, 15.5.4 and 15.10-rc-1. For those unable to immediately upgrade, a manual patch is available for the Main.SolrSpaceFacet page (Figure 1) to mitigate the risk temporarily until an upgrade can be implemented. This patch is crucial as it prevents the execution of arbitrary Groovy code, which could compromise the confidentiality, integrity and availability of the XWiki installation.

Figure 1: Patch

Technical Overview

XWiki’s scripting capabilities form a core component of its architecture, allowing users to craft both simple and complex web applications directly within the XWiki interface without the conventional requisites of compiling code or deploying software components. This functionality is facilitated through an advanced scripting feature set that is embedded in the content of an XWiki page, alongside traditional wiki markup. XWiki supports a variety of scripting languages such as Velocity, Groovy, and Python, which are enabled by default, thus offering versatility and power to developers. The platform utilizes the JSR-223 scripting framework to evaluate script code seamlessly. This is executed via the script macro, which follows the syntax {{script language=”<script engine name>”}}<some code>{{/script}}, allowing for direct embedding of code in pages. Specific languages can be declared directly, for example, Groovy code is written within {{groovy}}<some code>{{/groovy}} blocks, enabling immediate and accessible scripting without leaving the XWiki page environment.

Regarding its content organization, XWiki uses a hierarchical structure termed as “Wiki”, “Space”, and “Page”, or alternatively, “Page” and “Child Page”. Historically, spaces functioned similarly to folders in a file system, designed to house a collection of pages. However, in more recent updates, XWiki has eliminated the distinction between a page and a space, streamlining its structure. Despite these advancements, a significant vulnerability has been identified within this framework. The issue arises from inadequate input validation of the title fields in XWiki Spaces. Specifically, when a user attempts to create or update a page using actions like “save” or “saveandcontinue”, the user-supplied title is stored without neutralizing special characters, potentially leading to code injection risks. This vulnerability extends to the rendering process of the space’s title in the “Main.SolrSpaceFacet” on the “Main.SolrSearchConfig” page, where script elements within space titles are executed due to the lack of special character neutralization, posing a critical security risk to the integrity and security of the XWiki installation.

Triggering the Vulnerability

The four main triggers of the vulnerability in XWiki, allowing remote code execution via the Solr-based search mechanism, can be detailed as follows:

• Crafted Document Titles: The vulnerability is triggered by creating a document with a specially crafted title. For instance, using the title structure {{/html}}{{async}}{{groovy}}println(“Hello from Groovy Title!”){{/groovy}}{{/async}} which contains embedded Groovy code allows arbitrary code execution when the document is processed or indexed by the Solr search engine.
• User Rights and Permissions: Any user with the ability to edit titles of a space, which by default is every user, can exploit this vulnerability. This broad default permission setting significantly widens the potential for exploitation.
• Search UI Interaction: The crafted code in the document title is executed when interacting with the XWiki search interface. Specifically, after the maliciously titled document is indexed, searching for this document and engaging with facets such as deploying the Location facet can lead to the execution of the embedded Groovy script.
• Insufficient Input Sanitization: The underlying issue of inadequate input validation and neutralization of special characters in the XWiki Spaces’ title field is a critical trigger. This allows embedded scripts in document titles to be executed without any filtering, directly compromising the application’s security.

Exploitation

The exploitation process targets the XWiki system by leveraging the ability to execute arbitrary code remotely. This process involves an automated script that uses five specific HTTP requests to interact with the XWiki installation:

• Login Page Request: Fetches the CSRF token necessary for session authenticity.

• URL: loginPageURL = baseURL + ‘xwiki/bin/login/XWiki/XWikiLogin?loginLink=1’

Figure 2: Login Request

• Login Submission Request: Submits login credentials and the CSRF token.

• URL: loginURL = baseURL + ‘xwiki/bin/loginsubmit/XWiki/XWikiLogin’

Figure 3: CSRF Token Post Request

• Document Edit Page Request: Accesses the document edit page to fetch another CSRF token and check document availability.

• URL (Initial attempt):
  • baseDocURL = baseURL + “xwiki/bin/edit/”
  • newDocURL = baseDocURL + targetDoc

• Document Save/Preview Request: Submits a malicious script embedded in the document’s title for preview and execution.

• URL: saveDocURL = baseURL + “xwiki/bin/preview/” + targetDoc

Figure 4: Malicious Script, Document Upload

• Document Search Request: Searches for the modified document to trigger attacker execution.

• URL: searchURL = baseURL + “xwiki/bin/view/Main/Search?text=test”

The attacker configures a client with the server’s URL, username and password, and begins the exploitation by requesting the XWiki login page to obtain a CSRF token (Figure 5). This token is extracted from the HTML content and used alongside the login credentials to authenticate successfully.

Figure 5: CSRF Form Token

After authentication, the attacker searches for an editable document. If unavailable, the document name is modified iteratively until one is found. Another CSRF token is then retrieved from the document editing page. The attack vector is a script embedded in the document’s title, using XWiki’s syntax to embed Groovy code that executes shell commands. The payload — containing the CSRF token, malicious title, and shell command—is submitted to the document’s preview URL for processing (Figure 4).

Finally, the attacker initiates a search query to ensure the Solr search engine processes the modified document, confirming the execution of the embedded command. The script concludes by reporting the success of the exploit, demonstrating how the XWiki system can be compromised by using crafted document titles to execute code remotely.

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: 4408 XWiki Platform SolrSpaceFacet Remote Code Execution

Remediation Recommendations

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.
• Configure the vulnerable product to allow access to trusted clients only.

Relevant Links

JIRA Ticket

Security Advisory

Commit Macro Changes

Patch

NVD

CWE-95