Overview

This week the SonicWall Capture Labs threat research team came across a sample purporting to be Windows Explorer. At a glance, everything checks out – it uses the legitimate Windows Explorer icon and the file properties say Microsoft – but, once executed, it installs and runs a crypto miner.

Infection Cycle

The sample arrives as a Windows executable file using the following icon and bearing these file properties:

Figure 1: Malware installer’s file properties showing Windows Explorer from Microsoft

Upon execution, it drops malicious files in the /Windows/Fonts/ directory, including the main crypto miner file, a batch file containing malicious commands to start the mining process, and two registry files whose registry subkeys and values will later be inserted into the system registry using regedit.exe.

• svchost.exe
• 1.bat
• server.reg
• restart.reg

It then spawns the Windows command interpreter to execute the batch file.

Figure 2: Cmd is used to run 1.bat

Simultaneoulsy, it also runs the attrib command to set attributes of the entire %fonts% directory as a read-only (+r) and archive (+a).

Figure 3: The malicious Explorer.exe will run the attrib command to change attributes of the Fonts directory

Meanwhile, the 1.bat file contains the following commands:

Figure 3A: Commands

The command installs and runs a crypto miner using the specified mining pool address, port and xmr wallet. It then installs the contents of the two .reg files using regedit.exe. Next, it deletes these registry files and proceeds to change the attributes of several component files.

Figures 4 and 5 show the contents of the reg files which were imported into the system registry.

Figure 4: Contents of server.reg

Figure 5: Contents of restart.reg

Our static analysis revealed another mining configuration that uses a different mining pool address, port and xmr wallet which we did not observe being used during runtime.

Figure 6: Alternate mining pool address and xmr wallet that may be used by this malware

SonicWall Protections

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

• GAV: Miner.XMR_1 (Trojan)

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

Overview

The SonicWall Capture Labs threat research team has been regularly sharing information about malware targeting Android devices. We’ve encountered similar RAT samples before, but this one includes extra commands and phishing attacks designed to harvest credentials.

This malware uses famous Android app icons to mislead users and trick victims into installing the malicious app on their devices. This malicious app uses any of the following icons:

 

Figure 1: The app icon used by the malware.

Figure 2: Installed malicious app

Infection Cycle

After the malicious app is installed on the victim’s device, it prompts the victim to enable two permissions:

• Accessibility Service
• Device Admin Permission

By requesting these permissions, the malicious app aims to gain control over the victim’s device, potentially allowing it to carry out harmful actions or steal sensitive information without the user’s awareness or consent.

Figure 3: Prompt for accessibility permission

Figure 4: Device admin activation

The malicious app establishes a connection with the Command-and-Control server to receive instructions and execute specific tasks accordingly.

Here are some of the commands received from the malware’s Command-and-Control (C&C) server:

Command	Description
dmpsms	Read Messages
dmpcall	Read Call logs
dmpcon	Device Contact list
getpackages	Installed package name
changewall	Change device wallpaper
toasttext	Notification data
opweb	Open URLs on web browser for phishing
vibratedev	Vibrate device
sendsms	Send messages
tont	Turn on the camera flashlight
tofft	Turn off the camera flashlight

 

The resource file contains the URL of the C&C server, but it was not active during the analysis.

Figure 5: C&C server

Here you see it receiving commands from the C&C server to access a specific URL in the browser to harvest credentials.

Figure 6: Browser to open specific URL

Some malicious HTML files related to well-known Android applications are in the ‘asset\website’ folder, as shown in the figure below:

Figure 7: Fraudulent HTML Pages

Figure 8: Instances of fraudulent HTML page -1.

Figure 9: Instances of fraudulent HTML page -2.

In these HTML files, the attacker prompts the victim to enter their user ID and password into the input fields.

Figure 10: Retrieves user input

After taking credentials using JavaScript, it collects and shares all the user information to the ‘showTt’ function.

Figure 11: Collect user credential

It retrieves all phone numbers stored on the victim’s device.

Figure 12: Fetching contact List

It attempts to change the device’s wallpaper to a specific resource if the ‘str’ parameter matches the decrypted value, such as 0, 1, or 2.

Figure 13: Changing the Device Wallpaper

It retrieves information about installed apps on the victim’s device.

Figure 14: Collecting installed package info

The below code snippet utilizes the “CameraManager” to toggle the flashlight of the victim’s device’s camera to either on or off.

Figure 15: Camera flashlight on-off

It sends a message to a number based on input received from the C&C server.

Figure 16: Sending a message from the victim’s device

We also noticed that certain malicious files have been recently uploaded to malware-sharing platforms like VirusTotal.

Figure 17: Latest sample found on VT

SonicWall Protections

SonicWall Capture Labs provides protection against this threat via SonicWall Capture ATP w/RTDMI.

Indicators of Compromise (IOCs)

0cc5cf33350853cdd219d56902e5b97eb699c975a40d24e0e211a1015948a13d

37074eb92d3cfe4e2c51f1b96a6adf33ed6093e4caa34aa2fa1b9affe288a509

3df7c8074b6b1ab35db387b5cb9ea9c6fc2f23667d1a191787aabfbf2fb23173

6eb33f00d5e626bfd54889558c6d031c6cac8f180d3b0e39fbfa2c501b65f564

9b366eeeffd6c9b726299bc3cf96b2e673572971555719be9b9e4dcaad895162

a28e99cb8e79d4c2d19ccfda338d43f74bd1daa214f5add54c298b2bcfaac9c3

d09f2df6dc6f27a9df6e0e0995b91a5189622b1e53992474b2791bbd679f6987

d8413287ac20dabcf38bc2b5ecd65a37584d8066a364eede77c715ec63b7e0f1

ecf941c1cc85ee576f0d4ef761135d3e924dec67bc3f0051a43015924c53bfbb

f10072b712d1eed0f7e2290b47d39212918f3e1fd4deef00bf42ea3fe9809c41

Overview

The SonicWall Capture Labs threat research team became aware of a cross-site scripting vulnerability in GitLab, assessed its impact and developed mitigation measures. GitLab, an open-source code-sharing platform, published an advisory on this vulnerability affecting GitLab CE/EE in all versions starting from 16.7 to 16.8.6, 16.9 before 16.9.4 and 16.10 before 16.10.2. Identified as CVE-2024-2279, it allows remote threat actors to perform arbitrary actions on behalf of victims, earning a high CVSS score of 8.7. To mitigate this threat, GitLab users are strongly encouraged to upgrade their instances to the latest versions, as mentioned in the vendor advisory.

Technical Overview

This vulnerability arises due to a flaw in the input validation mechanism while displaying suggestions to the user using the feature called ‘autocomplete for issues reference’ in the rich text editor. Autocomplete characters are a handy way for users to enter field values into markdown fields swiftly. While creating and displaying an issue enforces the escape of the special characters, the same is missing when the user types the character “#” and the backend engine tries to autocomplete from the list of issues.

This enables an attacker with access to ‘issues’ in the project to create an ‘issue’ using a crafted payload in the title field, leading to stored cross-site scripting. The exploit payload triggers when a victim is trying to mention any issue in the textbox using the autocomplete character #, which leads to an automatic execution of arbitrary action specified in the payload. This could include actions such as requesting a resource from the attacker-controlled server.

An escape method from the Lodash library is used to address this vulnerability, as seen in the related diff between version 16.10.1 and 16.10.2 in Figure 1. This method replaces special characters like &, <, >, “, and ‘ with their corresponding HTML entities before adding them to the Document Object Model (DOM).

Figure 1: Utilization of the escape method to resolve the issue

Triggering the Vulnerability

Leveraging this XSS vulnerability requires the attacker to meet the prerequisites below.

• The attacker must have network access to the target vulnerable system along with the rights to create the ‘issue’.
• The attacker must create an issue with a malformed payload. For instance, Malicious issue <img src=”http[:]//<attacker_controlled_server>/x.svg”>. This payload will load images from the server if the vulnerability is present.
• The victim must try to mention any issue using the autocomplete character #.

Exploitation

While the steps to trigger the vulnerability are straightforward, it can test the attacker’s patience since the exploitation requires the victim to try to mention any issue using the rich text editor, to be specific.

To begin with, the issue needs to be created with the crafted payload as seen in Figure 2. The attacker needs to host the x.svg image file at the server specified in the payload.

Figure 2: Malicious issue creation

The created issue will be listed as shown in Figure 3.

Figure 3: Issues list

When a user tries to refer to any issue by typing # in the rich text box, for instance, in the comment box of any other issue, the payload will be triggered. The exploitation can be verified by checking the access logs of the web server, where the access request on behalf of the victim can be seen, as shown in Figure 4.

Figure 4: Triggering XSS

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: 4383 GitLab Autocomplete Results XSS
• IPS: 4385 GitLab Autocomplete Results XSS 2

Remediation Recommendations

GitLab users are strongly encouraged to upgrade their instances to the latest versions as mentioned in the vendor advisory.

Relevant Links

• Vendor advisory
• Commit to fix the vulnerability

Overview

SonicWall Capture Labs threat research team has observed fileless .Net managed code injection in a native 64-bit process.  Native code or unmanaged code refers to low-level compiled code such as C/C++.  Managed code refers to code that is written to target .NET and will not work without the CLR (Microsoft .NET engine) runtime libraries. The injected code belongs to AgentTesla malware.

Technical Analysis

The initial infection vector is a Word document that the client received as an email attachment. Upon opening this document, it will ask the user to enable a VBA macro. If enabled, this VBA macro downloads a 64-bit executable from the internet and executes it.

The downloaded binary is a 64-bit, Rust-compiled binary. We are focusing on the techniques used by this binary to inject the malicious AgentTesla payload into its own process memory using CLR Hosting.

The following are details of the 64-bit downloaded executable file.

MD5 : 4521162D45EFC83FA76C4B5C0D405265

SHA256 :  F00ED06A1D402ECF760EC92F3280EF6C09E76036854ABACADCAC9311706ED97D

URL from which 64-bit executable downloaded:

https[:]//New-Coder[.]cc/Users/signed_20240329011751156[.]exe

Disabling Event Tracing for Windows (ETW)

On execution of the Rust binary, it patches the “EtwEventWrite” API from NTDLL using the NtProtectVirtualMemory, WriteProcessMemory and FlushInstructionCache APIs.

Figure 1:  After the malware patches the “EtwEventWrite” API

This 64-bit malware process downloads an encoded shellcode from the following URL which contains the AgenetTesla payload.

URL of the shellcode:

https[:]//New-Coder[.]cc/Users/shellcodeAny_20240329011339585[.]bin

Next, the malware starts the execution of the downloaded shellcode using the “EnumSystemLocalesA” API by passing the address of the shellcode to the API as the callback function argument.

Figure 2: Moved shellcode from read-write memory to executable memory and starts its execution

The shellcode parses PEB and PEB_LDR_DATA to resolve the API dynamically. It will resolve the VirtualAlloc, VirtualFree, and RtlExitUserProcess APIs using an API hashing technique.

Next, the shellcode allocates read-write memory using the “VirtualAlloc” API and moves 0x3E3C0 bytes from the shellcode to the allocated memory.  These bytes are the encoded AgentTesla payload.

Figure 3: Moved shellcode data in read-write memory and starts decryption routine

As shown in Figure 3 above, the first 4bytes (DWORD) are the size of encoded data followed by encoded data.

Next, it proceeds to decrypt the payload. The shellcode uses a customized decryption routine where it performs single-byte XOR decryption in a loop, and for every iteration, it decrypts 0x10 bytes in the payload with a 0x10-byte encryption key. In a decryption loop, every time the malware uses a different encryption key derived from a combination of XOR and arithmetic operations. It decrypts the 0x3E184 bytes of the memory buffer to get the final payload.

Figure 4: Single-byte XOR decryption

Next, the shellcode reads the DLL name array, which contains the names of DLLs that are required for the malware to perform its operation. This array is “ole32;oleaut32;wininet;mscoree;shell32”.

The shellcode parses the PEB structure to check for the presence of the above-mentioned DLLs in the loaded modules list and loads the DLL using the “LoadLibraryA” API if they are not present.

Once the required DLLs are loaded into memory, it resolves a few more APIs such as “VirtualProtect”, “SafeArrayCreate”, “CLRCreateInstance” etc., using the API Hashing technique.

AMSI Bypass Using Memory Patching

Next, the shellcode patches the “AmsiScanBuffer” and “AmsiScanString” API, as shown below.

Figure 5: “AmsiScanBuffer” API after patching

Figure 6: “AmsiScanString” API after patching

Disabling Event Tracing (2^nd time)

We have observed the second time patching in shellcode to disable Event Tracing, this might be to confirm the patching continues. It patches “EtwEventWrite” API with a single byte “0xCC” (return instruction).

Next, the shellcode starts CLR hosting.

These are the steps required to perform CLR Hosting, in order:

• Create a CLR MetaHost instance:

ICLRMetaHost* pMetaHost = NULL;

CLRCreateInstance(CLSID_CLRMetaHost, IID_ICLRMetaHost, (LPVOID*)&pMetaHost);

• Enumerate the installed runtimes:

pMetaHost->EnumerateInstalledRuntimes(&installedRuntimes);

Enumerate through runtimes and try to locate a specific dotnet version installed on the system.

One has to use “GetVersionString” method from the ICLRRuntimeInfo interface to find the supported .NET Framework version.  This .NET Framework version string will be passed to the GetRuntime API.

• Get RuntimeInfo using “GetRuntime”:

ICLRRuntimeInfo* runtimeInfo = NULL;

pMetaHost->GetRuntime(sz_runtimeVersion, IID_ICLRRuntimeInfo, (LPVOID*)&runtimeInfo);

• Get ICorRuntimeHost interface:

ICorRuntimeHost Interface allows more control over the managed runtime from the native code, It can be retrieved using ICLRRuntimeInfo::GetInterface

ICorRuntimeHost* pCorRuntimeHost =NULL;

runtimeInfo->GetInterface(CLSID_CorRuntimeHost,IID_ICorRuntimeHost,(LPVOID*)& pCorRuntimeHost);

• Retrieve the default AppDomain for the current process:

ICorRuntimeHost interface allows retrieval of the default AppDomain for the current process.

IUnknown* appDomainThunk;

pCorRuntimeHost->GetDefaultDomain(&appDomainThunk);

_AppDomain* defaultAppDomain = NULL;

appDomainThunk->QueryInterface(IID_AppDomain, &defaultAppDomain);

• Create SafeArray:

we must create SafeArray and copy the MSIL payload to this SafeArray since we can’t provide an unmanaged byte array to the “Load_3” method which loads the assembly into the app domain.

SAFEARRAYBOUND bounds[1];

bounds[0].cElements = sizeof (rawAssemblyByteArray);

bounds[0].lLbound = 0;

SAFEARRAY* safeArray = SafeArrayCreate(VT_UI1, 1, bounds);

SafeArrayLock(safeArray);

memcpy(safeArray->pvData, rawAssemblyByteArray, sizeof (rawAssemblyByteArray));

SafeArrayUnlock(safeArray);

• Load the assembly to the AppDomain:

_AssemblyPtr  managedAssembly = NULL;

defaultAppDomain->Load_3(safeArray, &managedAssembly)

• Find an entry point to the loaded assembly:

_MethodInfoPtr  pMethodInfo = NULL;

managedAssembly->get_EntryPoint(&pMethodInfo)

• Call the entry point:

pMethodInfo->Invoke_3(VARIANT(), SafeArray_Pointer_To_Arguement , &VARIANT())

The second parameter for the “Invoke_3” function is the SafeArray pointer to the arguments that will be passed to the MSIL payload.

ShellCode Executing Managed Code from a Native Code Using CLR hosting

Next, the shellcode calls the “CLRCreateInstance” API from mscoree.dll. The CLRCreateInstance API returns the new CLR MetaHost instance which will be used by malware to prepare a runtime so it can execute the MSIL AgentTesla payload in memory.

We can see in the below figure that multiple GUIDs have been used while retrieving CLR Hosting Interfaces, for e.g., to retrieve “ICorRuntimeHost” interface, it passed “CLSID_CorRuntimeHost” ,  “IID_ICorRuntimeHost” as an argument to the “GetInterface” API.

Figure 7: GUID used while CLR hosting

Next, the shellcode retrieves the ICorRuntimeHost interface and starts the CLR.

Figure 8: Call to GetInterface API to retrieve the ICorRuntimeHost interface

Figure 9: Call start method from ICorRuntimeHost interface to start CLR

Next, the shellcode retrieves the default app domain for the current process, as shown below.

Figure 10: Retrieve the default AppDomain for the current process.

Next, the shellcode creates SafeArray using the “SafeArrayCreate“ API by passing an argument as the size of managed code which is 0x3CC00. This SafeArray does have a pointer to the buffer where malware copies the MSIL payload.

Figure 11: Create a SafeArray and copy AgentTesla payload to it

Once a SafeArray was created, it could be loaded into an AppDomain with the “Load_3” method, this “Load_3” method gives a pointer to an Assembly object.

Figure 12:  Calls “Load_3” method to load the SafeArray into AppDomain

Next, the shellcode zeros out the MSIL payload from the region where it got decrypted then it destroys the SafeArray using the “SafeArrayDestroy” API.

Finally, the shellcode retrieves the entry point for the assembly and calls the “Invoke_3” method to start the 32-bit MSIL AgentTesla process within the context of the 64-bit native process.

Figure 13: Starts the MSIL AgentTesla process

Figure 14: Browser folder enumerated by 64-bit process once the fileless managed code injection has been done

In Figure 14 above, it looks like the 64-bit process is enumerating the browser folder, but its AgentTesla malware started its execution within the .NET engine.

SonicWall Protections

SonicWall Capture Labs provides protection against analyzed 64-bit executable (4521162d45efc83fa76c4b5c0d405265) as GAV: MalAgent.QZ (Trojan).

This threat was also detected by SonicWall Capture ATP w/RTDMI.

The initial infection vector which is a Word document file has been detected by SonicWall Capture ATP w/RTDMI.

IOCs

Document file:

MD5 : D99020C900069E737B3F4AB8C6947375

SHA256 : A6562D8F34D4C25A94313EBBED1137514EED90B233A94A9125E087781C733B37

64-bit downloaded executable:

MD5 : 4521162D45EFC83FA76C4B5C0D405265

SHA256 : F00ED06A1D402ECF760EC92F3280EF6C09E76036854ABACADCAC9311706ED97D

Shellcode blob:

MD5 : CD485BF146E942EC6BB51351FA42B1FF

SHA256 : 02C03E2E8CA28849969AE9A8AAA7FDE8A8B918B5A29548840367F3ECAC543E2D

Injected AgentTesla Payload:

MD5 : 6999D02AA08B56EFE8B2DBBD6FDC9A78

SHA256 : 7B6867606027BFCA492F95E2197A3571D3332D59B65E1850CB20AA6854486B41

URLs used by malware:

https[:]//New-Coder[.]cc/Users/signed_20240329011751156[.]exe  (64-bit exe downloaded)

https[:]//New-Coder[.]cc/Users/shellcodeAny_20240329011339585[.]bin (shellcode downloaded)