The information stealer abuses legitimate APIs and libraries to exfiltrate data to Discord webhooks.
The post ‘SolyxImmortal’ Information Stealer Emerges appeared first on SecurityWeek.
Designed for long-term access, the framework targets cloud and container environments with loaders, implants, and rootkits.
The post VoidLink Linux Malware Framework Targets Cloud Environments appeared first on SecurityWeek.
Some attackers are increasingly moving away from simple redirects in favor of more “selective” methods of payload delivery. This approach filters out regular human visitors, allowing attackers to serve malicious content to search engine crawlers while remaining invisible to the website owner.
What did we find?
During a malware investigation, we identified a selective content injection attack inside the main index.php file of a WordPress website.
Instead of always loading WordPress normally, this modified file checks who is visiting the site.
Continue reading Malware Intercepts Googlebot via IP-Verified Conditional Logic at Sucuri Blog.
The botnet’s propagation is fueled by the AI-generated server deployments that use weak credentials, and legacy web stacks.
The post GoBruteforcer Botnet Targeting Crypto, Blockchain Projects appeared first on SecurityWeek.
We recently handled a case where a customer reported strange SEO behavior on their website. Regular visitors saw a normal site. No popups. No redirects. No visible spam.
However, when they checked their site on Google, the search results were flooded with eBay-type-looking websites and “Situs Toto” gambling spam.
This is a professional-grade SEO cloaking attack. The malware turns the application into a double agent: it serves your genuine website content to real people but swaps it for a massive list of gambling ads the second a search engine bot crawls the page.
Continue reading Google Sees Spam, You See Your Site: A Cloaked SEO Spam Attack at Sucuri Blog.
We recently investigated a case involving a WordPress website where a customer reported persistent fake pop-up notifications appearing on their site. The warnings were urging them to update their browser (Chrome or Firefox), even though their software was already fully up-to-date.
What made this case particularly unique was the targeting. The fake alerts were not visible to regular visitors on the public-facing site. They only appeared when the site owner was logged into the wp-admin dashboard.
In mid-2025, we identified a malicious driver file on computer systems in Asia. The driver file is signed with an old, stolen, or leaked digital certificate and registers as a mini-filter driver on infected machines. Its end-goal is to inject a backdoor Trojan into the system processes and provide protection for malicious files, user-mode processes, and registry keys.
Our analysis indicates that the final payload injected by the driver is a new sample of the ToneShell backdoor, which connects to the attacker’s servers and provides a reverse shell, along with other capabilities. The ToneShell backdoor is a tool known to be used exclusively by the HoneyMyte (aka Mustang Panda or Bronze President) APT actor and is often used in cyberespionage campaigns targeting government organizations, particularly in Southeast and East Asia.
The command-and-control servers for the ToneShell backdoor used in this campaign were registered in September 2024 via NameCheap services, and we suspect the attacks themselves to have begun in February 2025. We’ve observed through our telemetry that the new ToneShell backdoor is frequently employed in cyberespionage campaigns against government organizations in Southeast and East Asia, with Myanmar and Thailand being the most heavily targeted.
Notably, nearly all affected victims had previously been infected with other HoneyMyte tools, including the ToneDisk USB worm, PlugX, and older variants of ToneShell. Although the initial access vector remains unclear, it’s suspected that the threat actor leveraged previously compromised machines to deploy the malicious driver.
The driver file is signed with a digital certificate from Guangzhou Kingteller Technology Co., Ltd., with a serial number of 08 01 CC 11 EB 4D 1D 33 1E 3D 54 0C 55 A4 9F 7F. The certificate was valid from August 2012 until 2015.
We found multiple other malicious files signed with the same certificate which didn’t show any connections to the attacks described in this article. Therefore, we believe that other threat actors have been using it to sign their malicious tools as well. The following image shows the details of the certificate.
The filename used for the driver on the victim’s machine is ProjectConfiguration.sys. The registry key created for the driver’s service uses the same name, ProjectConfiguration.
The malicious driver contains two user-mode shellcodes, which are embedded into the .data section of the driver’s binary file. The shellcodes are executed as separate user-mode threads. The rootkit functionality protects both the driver’s own module and the user-mode processes into which the backdoor code is injected, preventing access by any process on the system.
To obfuscate the actual behavior of the driver module, the attackers used dynamic resolution of the required API addresses from hash values.
The malicious driver first retrieves the base address of the ntoskrnl.exe and fltmgr.sys by calling ZwQuerySystemInformation with the SystemInformationClass set to SYSTEM_MODULE_INFORMATION. It then iterates through this system information and searches for the desired DLLs by name, noting the ImageBaseAddress of each.
Once the base addresses of the libraries are obtained, the driver uses a simple hashing algorithm to dynamically resolve the required API addresses from ntoskrnl.exe and fltmgr.sys.
The hashing algorithm is shown below. The two variants of the seed value provided in the comment are used in the shellcodes and the final payload of the attack.
The malicious driver registers itself with the Filter Manager using FltRegisterFilter and sets up a pre-operation callback. This callback inspects I/O requests for IRP_MJ_SET_INFORMATION and triggers a malicious handler when certain FileInformationClass values are detected. The handler then checks whether the targeted file object is associated with the driver; if it is, it forces the operation to fail by setting IOStatus to STATUS_ACCESS_DENIED. The relevant FileInformationClass values include:
These classes correspond to file-delete and file-rename operations. By monitoring them, the driver prevents itself from being removed or renamed – actions that security tools might attempt when trying to quarantine it.
The driver also builds a global list of registry paths and parameter names that it intends to protect. This list contains the following entries:
To guard these keys, the malware sets up a RegistryCallback routine, registering it through CmRegisterCallbackEx. To do so, it must assign itself an altitude value. Microsoft governs altitude assignments for mini-filters, grouping them into Load Order categories with predefined altitude ranges. A filter driver with a low numerical altitude is loaded into the I/O stack below filters with higher altitudes. The malware uses a hardcoded starting point of 330024 and creates altitude strings in the format 330024.%l, where %l ranges from 0 to 10,000.
The malware then begins attempting to register the callback using the first generated altitude. If the registration fails with STATUS_FLT_INSTANCE_ALTITUDE_COLLISION, meaning the altitude is already taken, it increments the value and retries. It repeats this process until it successfully finds an unused altitude.
The callback monitors four specific registry operations. Whenever one of these operations targets a key from its protected list, it responds with 0xC0000022 (STATUS_ACCESS_DENIED), blocking the action. The monitored operations are:
Microsoft designates the 320000–329999 altitude range for the FSFilter Anti-Virus Load Order Group. The malware’s chosen altitude exceeds this range. Since filters with lower altitudes sit deeper in the I/O stack, the malicious driver intercepts file operations before legitimate low-altitude filters like antivirus components, allowing it to circumvent security checks.
Finally, the malware tampers with the altitude assigned to WdFilter, a key Microsoft Defender driver. It locates the registry entry containing the driver’s altitude and changes it to 0, effectively preventing WdFilter from being loaded into the I/O stack.
The malware sets up a list intended to hold protected process IDs (PIDs). It begins with 32 empty slots, which are filled as needed during execution. A status flag is also initialized and set to 1 to indicate that the list starts out empty.
Next, the malware uses ObRegisterCallbacks to register two callbacks that intercept process-related operations. These callbacks apply to both OB_OPERATION_HANDLE_CREATE and OB_OPERATION_HANDLE_DUPLICATE, and both use a malicious pre-operation routine.
This routine checks whether the process involved in the operation has a PID that appears in the protected list. If so, it sets the DesiredAccess field in the OperationInformation structure to 0, effectively denying any access to the process.
The malware also registers a callback routine by calling PsSetCreateProcessNotifyRoutine. These callbacks are triggered during every process creation and deletion on the system. This malware’s callback routine checks whether the parent process ID (PPID) of a process being deleted exists in the protected list; if it does, the malware removes that PPID from the list. This eventually removes the rootkit protection from a process with an injected backdoor, once the backdoor has fulfilled its responsibilities.
The driver delivers two user-mode payloads.
The first payload spawns an svchost process and injects a small delay-inducing shellcode. The PID of this new svchost instance is written to a file for later use.
The second payload is the final component – the ToneShell backdoor – and is later injected into that same svchost process.
Injection workflow:
The malicious driver searches for a high-privilege target process by iterating through PIDs and checking whether each process exists and runs under SeLocalSystemSid. Once it finds one, it customizes the first payload using random event names, file names, and padding bytes, then creates a named event and injects the payload by attaching its current thread to the process, allocating memory, and launching a new thread.
After injection, it waits for the payload to signal the event, reads the PID of the newly created svchost process from the generated file, and adds it to its protected process list. It then similarly customizes the second payload (ToneShell) using random event name and random padding bytes, then creates a named event and injects the payload by attaching to the process, allocating memory, and launching a new thread.
Once the ToneShell backdoor finishes execution, it signals the event. The malware then removes the svchost PID from the protected list, waits 10 seconds, and attempts to terminate the process.
The final stage of the attack deploys ToneShell, a backdoor previously linked to operations by the HoneyMyte APT group and discussed in earlier reporting (see Malpedia and MITRE). Notably, this is the first time we’ve seen ToneShell delivered through a kernel-mode loader, giving it protection from user-mode monitoring and benefiting from the rootkit capabilities of the driver that hides its activity from security tools.
Earlier ToneShell variants generated a 16-byte GUID using CoCreateGuid and stored it as a host identifier. In contrast, this version checks for a file named C:\ProgramData\MicrosoftOneDrive.tlb, validating a 4-byte marker inside it. If the file is absent or the marker is invalid, the backdoor derives a new pseudo-random 4-byte identifier using system-specific values (computer name, tick count, and PRNG), then creates the file and writes the marker. This becomes the unique ID for the infected host.
The samples we have analyzed contact two command-and-control servers:
ToneShell communicates with its C2 over raw TCP on port 443 while disguising traffic using fake TLS headers. This version imitates the first bytes of a TLS 1.3 record (0x17 0x03 0x04) instead of the TLS 1.2 pattern used previously. After this three-byte marker, each packet contains a size field and an encrypted payload.
Packet layout:
The backdoor supports a set of remote operations, including file upload/download, remote shell functionality, and session control. The command set includes:
| Command ID | Description |
| 0x1 | Create temporary file for incoming data |
| 0x2 / 0x3 | Download file |
| 0x4 | Cancel download |
| 0x7 | Establish remote shell via pipe |
| 0x8 | Receive operator command |
| 0x9 | Terminate shell |
| 0xA / 0xB | Upload file |
| 0xC | Cancel upload |
| 0xD | Close connection |
We assess with high confidence that the activity described in this report is linked to the HoneyMyte threat actor. This conclusion is supported by the use of the ToneShell backdoor as the final-stage payload, as well as the presence of additional tools long associated with HoneyMyte – such as PlugX, and the ToneDisk USB worm – on the impacted systems.
HoneyMyte’s 2025 operations show a noticeable evolution toward using kernel-mode injectors to deploy ToneShell, improving both stealth and resilience. In this campaign, we observed a new ToneShell variant delivered through a kernel-mode driver that carries and injects the backdoor directly from its embedded payload. To further conceal its activity, the driver first deploys a small user-mode component that handles the final injection step. It also uses multiple obfuscation techniques, callback routines, and notification mechanisms to hide its API usage and track process and registry activity, ultimately strengthening the backdoor’s defenses.
Because the shellcode executes entirely in memory, memory forensics becomes essential for uncovering and analyzing this intrusion. Detecting the injected shellcode is a key indicator of ToneShell’s presence on compromised hosts.
To protect themselves against this threat, organizations should:
By following these recommendations, organizations can reduce their risk of being compromised by the HoneyMyte APT group and other similar threats.
More indicators of compromise, as well as any updates to these, are available to the customers of our APT intelligence reporting service. If you are interested, please contact intelreports@kaspersky.com.
36f121046192b7cac3e4bec491e8f1b5 AppvVStram_.sys
fe091e41ba6450bcf6a61a2023fe6c83 AppvVStram_.sys
abe44ad128f765c14d895ee1c8bad777 ProjectConfiguration.sys
avocadomechanism[.]com ToneShell C2
potherbreference[.]com ToneShell C2
The Evasive Panda APT group (also known as Bronze Highland, Daggerfly, and StormBamboo) has been active since 2012, targeting multiple industries with sophisticated, evolving tactics. Our latest research (June 2025) reveals that the attackers conducted highly-targeted campaigns, which started in November 2022 and ran until November 2024.
The group mainly performed adversary-in-the-middle (AitM) attacks on specific victims. These included techniques such as dropping loaders into specific locations and storing encrypted parts of the malware on attacker-controlled servers, which were resolved as a response to specific website DNS requests. Notably, the attackers have developed a new loader that evades detection when infecting its targets, and even employed hybrid encryption practices to complicate analysis and make implants unique to each victim.
Furthermore, the group has developed an injector that allows them to execute their MgBot implant in memory by injecting it into legitimate processes. It resides in the memory space of a decade-old signed executable by using DLL sideloading and enables them to maintain a stealthy presence in compromised systems for extended periods.
Additional information about this threat, including indicators of compromise, is available to customers of the Kaspersky Intelligence Reporting Service. Contact: intelreports@kaspersky.com.
The threat actor commonly uses lures that are disguised as new updates to known third-party applications or popular system applications trusted by hundreds of users over the years.
In this campaign, the attackers used an executable disguised as an update package for SohuVA, which is a streaming app developed by Sohu Inc., a Chinese internet company. The malicious package, named sohuva_update_10.2.29.1-lup-s-tp.exe, clearly impersonates a real SohuVA update to deliver malware from the following resource, as indicated by our telemetry:
http://p2p.hd.sohu.com[.]cn/foxd/gz?file=sohunewplayer_7.0.22.1_03_29_13_13_union.exe&new=/66/157/ovztb0wktdmakeszwh2eha.exe
There is a possibility that the attackers used a DNS poisoning attack to alter the DNS response of p2p.hd.sohu.com[.]cn to an attacker-controlled server’s IP address, while the genuine update module of the SohuVA application tries to update its binaries located in appdata\roaming\shapp\7.0.18.0\package. Although we were unable to verify this at the time of analysis, we can make an educated guess, given that it is still unknown what triggered the update mechanism.
Furthermore, our analysis of the infection process has identified several additional campaigns pursued by the same group. For example, they utilized a fake updater for the iQIYI Video application, a popular platform for streaming Asian media content similar to SohuVA. This fake updater was dropped into the application’s installation folder and executed by the legitimate service qiyiservice.exe. Upon execution, the fake updater initiated malicious activity on the victim’s system, and we have identified that the same method is used for IObit Smart Defrag and Tencent QQ applications.
The initial loader was developed in C++ using the Windows Template Library (WTL). Its code bears a strong resemblance to Wizard97Test, a WTL sample application hosted on Microsoft’s GitHub. The attackers appear to have embedded malicious code within this project to effectively conceal their malicious intentions.
The loader first decrypts the encrypted configuration buffer by employing an XOR-based decryption algorithm:
Login
for ( index = 0; index < v6; index = (index + 1) )
{
if ( index >= 5156 )
break;
mw_configindex ^= (&mw_deflated_config + (index & 3));
}After decryption, it decompresses the LZMA-compressed buffer into the allocated buffer, and all of the configuration is exposed, including several components:
%ProgramData%\Microsoft\MFhttp://www.dictionary.com/image?id=115832434703699686&product=dict-homepage.pngThe malware also checks the name of the logged-in user in the system and performs actions accordingly. If the username is SYSTEM, the malware copies itself with a different name by appending the ext.exe suffix inside the current working directory. Then it uses the ShellExecuteW API to execute the newly created version. Notably, all relevant strings in the malware, such as SYSTEM and ext.exe, are encrypted, and the loader decrypts them with a specific XOR algorithm.
Decryption routine of encrypted strings
If the username is not SYSTEM, the malware first copies explorer.exe into %TEMP%, naming the instance as tmpX.tmp (where X is an incremented decimal number), and then deletes the original file. The purpose of this activity is unclear, but it consumes high system resources. Next, the loader decrypts the kernel32.dll and VirtualProtect strings to retrieve their base addresses by calling the GetProcAddress API. Afterwards, it uses a single-byte XOR key to decrypt the shellcode, which is 9556 bytes long, and stores it at the same address in the .data section. Since the .data section does not have execute permission, the malware uses the VirtualProtect API to set the permission for the section. This allows for the decrypted shellcode to be executed without alerting security products by allocating new memory blocks. Before executing the shellcode, the malware prepares a 16-byte-long parameter structure that contains several items, with the most important one being the address of the encrypted MgBot configuration buffer.
As mentioned above, the loader follows a unique delivery scheme, which includes at least two stages of payload. The shellcode employs a hashing algorithm known as PJW to resolve Windows APIs at runtime in a stealthy manner.
unsigned int calc_PJWHash(_BYTE *a1)
{
unsigned int v2;
v2 = 0;
while ( *a1 )
{
v2 = *a1++ + 16 * v2;
if ( (v2 & 0xF0000000) != 0 )
v2 = ~(v2 & 0xF0000000) & (v2 ^ ((v2 & 0xF0000000) >> 24));
}
return v2;
}The shellcode first searches for a specific DAT file in the malware’s primary installation directory. If it is found, the shellcode decrypts it using the CryptUnprotectData API, a Windows API that decrypts protected data into allocated heap memory, and ensures that the data can only be decrypted on the particular machine by design. After decryption, the shellcode deletes the file to avoid leaving any traces of the valuable part of the attack chain.
If, however, the DAT file is not present, the shellcode initiates the next-stage shellcode installation process. It involves retrieving encrypted data from a web source that is actually an attacker-controlled server, by employing a DNS poisoning attack. Our telemetry shows that the attackers successfully obtained the encrypted second-stage shellcode, disguised as a PNG file, from the legitimate website dictionary[.]com. However, upon further investigation, it was discovered that the IP address associated with dictionary[.]com had been manipulated through a DNS poisoning technique. As a result, victims’ systems were resolving the website to different attacker-controlled IP addresses depending on the victims’ geographical location and internet service provider.
To retrieve the second-stage shellcode, the first-stage shellcode uses the RtlGetVersion API to obtain the current Windows version number and then appends a predefined string to the HTTP header:
sec-ch-ua-platform: windows %d.%d.%d.%d.%d.%d
This implies that the attackers needed to be able to examine request headers and respond accordingly. We suspect that the attackers’ collection of the Windows version number and its inclusion in the request headers served a specific purpose, likely allowing them to target specific operating system versions and even tailor their payload to different operating systems. Given that the Evasive Panda threat actor has been known to use distinct implants for Windows (MgBot) and macOS (Macma) in previous campaigns, it is likely that the malware uses the retrieved OS version string to determine which implant to deploy. This enables the threat actor to adapt their attack to the victim’s specific operating system by assessing results on the server side.
Downloading a payload from the web resource
From this point on, the first-stage shellcode proceeds to decrypt the retrieved payload with a XOR decryption algorithm:
key = *(mw_decryptedDataFromDatFile + 92);
index = 0;
if ( sz_shellcode )
{
mw_decryptedDataFromDatFile_1 = Heap;
do
{
*(index + mw_decryptedDataFromDatFile_1) ^= *(&key + (index & 3));
++index;
}
while ( index < sz_shellcode );
}The shellcode uses a 4-byte XOR key, consistent with the one used in previous stages, to decrypt the new shellcode stored in the DAT file. It then creates a structure for the decrypted second-stage shellcode, similar to the first stage, including a partially decrypted configuration buffer and other relevant details.
Next, the shellcode resolves the VirtualProtect API to change the protection flag of the new shellcode buffer, allowing it to be executed with PAGE_EXECUTE_READWRITE permissions. The second-stage shellcode is then executed, with the structure passed as an argument. After the shellcode has finished running, its return value is checked to see if it matches 0x9980. Depending on the outcome, the shellcode will either terminate its own process or return control to the caller.
Although we were unable to retrieve the second-stage payload from the attackers’ web server during our analysis, we were able to capture and examine the next stage of the malware, which was to be executed afterwards. Our analysis suggests that the attackers may have used the CryptProtectData API during the execution of the second shellcode to encrypt the entire shellcode and store it as a DAT file in the malware’s main installation directory. This implies that the malware writes an encrypted DAT file to disk using the CryptProtectData API, which can then be decrypted and executed by the first-stage shellcode. Furthermore, it appears that the attacker attempted to generate a unique encrypted second shellcode file for each victim, which we believe is another technique used to evade detection and defense mechanisms in the attack chain.
We identified a secondary loader, named libpython2.4.dll, which was disguised as a legitimate Windows library and used by the Evasive Panda group to achieve a stealthier loading mechanism. Notably, this malicious DLL loader relies on a legitimate, signed executable named evteng.exe (MD5: 1c36452c2dad8da95d460bee3bea365e), which is an older version of python.exe. This executable is a Python wrapper that normally imports the libpython2.4.dll library and calls the Py_Main function.
The secondary loader retrieves the full path of the current module (libpython2.4.dll) and writes it to a file named status.dat, located in C:\ProgramData\Microsoft\eHome, but only if a file with the same name does not already exist in that directory. We believe with a low-to-medium level of confidence that this action is intended to allow the attacker to potentially update the secondary loader in the future. This suggests that the attacker may be planning for future modifications or upgrades to the malware.
The malware proceeds to decrypt the next stage by reading the entire contents of C:\ProgramData\Microsoft\eHome\perf.dat. This file contains the previously downloaded and XOR-decrypted data from the attacker-controlled server, which was obtained through the DNS poisoning technique as described above. Notably, the implant downloads the payload several times and moves it between folders by renaming it. It appears that the attacker used a complex process to obtain this stage from a resource, where it was initially XOR-encrypted. The attacker then decrypted this stage with XOR and subsequently encrypted and saved it to perf.dat using a custom hybrid of Microsoft’s Data Protection Application Programming Interface (DPAPI) and the RC5 algorithm.
General overview of storing payload on disk by using hybrid encryption
This custom encryption algorithm works as follows. The RC5 encryption key is itself encrypted using Microsoft’s DPAPI and stored in the first 16 bytes of perf.dat. The RC5-encrypted payload is then appended to the file, following the encrypted key. To decrypt the payload, the process is reversed: the encrypted RC5 key is first decrypted with DPAPI, and then used to decrypt the remaining contents of perf.dat, which contains the next-stage payload.
The attacker uses this approach to ensure that a crucial part of the attack chain is secured, and the encrypted data can only be decrypted on the specific system where the encryption was initially performed. This is because the DPAPI functions used to secure the RC5 key tie the decryption process to the individual system, making it difficult for the encrypted data to be accessed or decrypted elsewhere. This makes it more challenging for defenders to intercept and analyze the malicious payload.
After completing the decryption process, the secondary loader initiates the runtime injection method, which likely involves the use of a custom runtime DLL injector for the decrypted data. The injector first calls the DLL entry point and then searches for a specific export function named preload. Although we were unable to determine which encrypted module was decrypted and executed in memory due to a lack of available data on the attacker-controlled server, our telemetry reveals that an MgBot variant is injected into the legitimate svchost.exe process after the secondary loader is executed. Fortunately, this allowed us to analyze these implants further and gain additional insights into the attack, as well as reveal that the encrypted initial configuration was passed through the infection chain, ultimately leading to the execution of MgBot. The configuration file was decrypted with a single-byte XOR key, 0x58, and this would lead to the full exposure of the configuration.
Our analysis suggests that the configuration includes a campaign name, hardcoded C2 server IP addresses, and unknown bytes that may serve as encryption or decryption keys, although our confidence in this assessment is limited. Interestingly, some of the C2 server addresses have been in use for multiple years, indicating a potential long-term operation.
Decryption of the configuration in the injected MgBot implant
Our telemetry has detected victims in Türkiye, China, and India, with some systems remaining compromised for over a year. The attackers have shown remarkable persistence, sustaining the campaign for two years (from November 2022 to November 2024) according to our telemetry, which indicates a substantial investment of resources and dedication to the operation.
The techniques, tactics, and procedures (TTPs) employed in this compromise indicate with high confidence that the Evasive Panda threat actor is responsible for the attack. Despite the development of a new loader, which has been added to their arsenal, the decade-old MgBot implant was still identified in the final stage of the attack with new elements in its configuration. Consistent with previous research conducted by several vendors in the industry, the Evasive Panda threat actor is known to commonly utilize various techniques, such as supply-chain compromise, Adversary-in-the-Middle attacks, and watering-hole attacks, which enable them to distribute their payloads without raising suspicion.
The Evasive Panda threat actor has once again showcased its advanced capabilities, evading security measures with new techniques and tools while maintaining long-term persistence in targeted systems. Our investigation suggests that the attackers are continually improving their tactics, and it is likely that other ongoing campaigns exist. The introduction of new loaders may precede further updates to their arsenal.
As for the AitM attack, we do not have any reliable sources on how the threat actor delivers the initial loader, and the process of poisoning DNS responses for legitimate websites, such as dictionary[.]com, is still unknown. However, we are considering two possible scenarios based on prior research and the characteristics of the threat actor: either the ISPs used by the victims were selectively targeted, and some kind of network implant was installed on edge devices, or one of the network devices of the victims — most likely a router or firewall appliance — was targeted for this purpose. However, it is difficult to make a precise statement, as this campaign requires further attention in terms of forensic investigation, both on the ISPs and the victims.
The configuration file’s numerous C2 server IP addresses indicate a deliberate effort to maintain control over infected systems running the MgBot implant. By using multiple C2 servers, the attacker aims to ensure prolonged persistence and prevents loss of control over compromised systems, suggesting a strategic approach to sustaining their operations.
File Hashes
c340195696d13642ecf20fbe75461bed sohuva_update_10.2.29.1-lup-s-tp.exe
7973e0694ab6545a044a49ff101d412a libpython2.4.dll
9e72410d61eaa4f24e0719b34d7cad19 (MgBot implant)
File Paths
C:\ProgramData\Microsoft\MF
C:\ProgramData\Microsoft\eHome\status.dat
C:\ProgramData\Microsoft\eHome\perf.dat
URLs and IPs
60.28.124[.]21 (MgBot C2)
123.139.57[.]103 (MgBot C2)
140.205.220[.]98 (MgBot C2)
112.80.248[.]27 (MgBot C2)
116.213.178[.]11 (MgBot C2)
60.29.226[.]181 (MgBot C2)
58.68.255[.]45 (MgBot C2)
61.135.185[.]29 (MgBot C2)
103.27.110[.]232 (MgBot C2)
117.121.133[.]33 (MgBot C2)
139.84.170[.]230 (MgBot C2)
103.96.130[.]107 (AitM C2)
158.247.214[.]28 (AitM C2)
106.126.3[.]78 (AitM C2)
106.126.3[.]56 (AitM C2)
In early 2025, security researchers uncovered a new malware family named Webrat. Initially, the Trojan targeted regular users by disguising itself as cheats for popular games like Rust, Counter-Strike, and Roblox, or as cracked software. In September, the attackers decided to widen their net: alongside gamers and users of pirated software, they are now targeting inexperienced professionals and students in the information security field.
In October, we uncovered a campaign that had been distributing Webrat via GitHub repositories since at least September. To lure in victims, the attackers leveraged vulnerabilities frequently mentioned in security advisories and industry news. Specifically, they disguised their malware as exploits for the following vulnerabilities with high CVSSv3 scores:
| CVE | CVSSv3 |
| CVE-2025-59295 | 8.8 |
| CVE-2025-10294 | 9.8 |
| CVE-2025-59230 | 7.8 |
This is not the first time threat actors have tried to lure security researchers with exploits. Last year, they similarly took advantage of the high-profile RegreSSHion vulnerability, which lacked a working PoC at the time.
In the Webrat campaign, the attackers bait their traps with both vulnerabilities lacking a working exploit and those which already have one. To build trust, they carefully prepared the repositories, incorporating detailed vulnerability information into the descriptions. The information is presented in the form of structured sections, which include:
Contents of the repository
In all the repositories we investigated, the descriptions share a similar structure, characteristic of AI-generated vulnerability reports, and offer nearly identical risk mitigation advice, with only minor variations in wording. This strongly suggests that the text was machine-generated.
The Download Exploit ZIP link in the Download & Install section leads to a password-protected archive hosted in the same repository. The password is hidden within the name of a file inside the archive.
The archive downloaded from the repository includes four files:
The execution flow and capabilities of rasmanesc.exe
Webrat is a backdoor that allows the attackers to control the infected system. Furthermore, it can steal data from cryptocurrency wallets, Telegram, Discord and Steam accounts, while also performing spyware functions such as screen recording, surveillance via a webcam and microphone, and keylogging. The version of Webrat discovered in this campaign is no different from those documented previously.
Previously, Webrat spread alongside game cheats, software cracks, and patches for legitimate applications. In this campaign, however, the Trojan disguises itself as exploits and PoCs. This suggests that the threat actor is attempting to infect information security specialists and other users interested in this topic. It bears mentioning that any competent security professional analyzes exploits and other malware within a controlled, isolated environment, which has no access to sensitive data, physical webcams, or microphones. Furthermore, an experienced researcher would easily recognize Webrat, as it’s well-documented and the current version is no different from previous ones. Therefore, we believe the bait is aimed at students and inexperienced security professionals.
The threat actor behind Webrat is now disguising the backdoor not only as game cheats and cracked software, but also as exploits and PoCs. This indicates they are targeting researchers who frequently rely on open sources to find and analyze code related to new vulnerabilities.
However, Webrat itself has not changed significantly from past campaigns. These attacks clearly target users who would run the “exploit” directly on their machines — bypassing basic safety protocols. This serves as a reminder that cybersecurity professionals, especially inexperienced researchers and students, must remain vigilant when handling exploits and any potentially malicious files. To prevent potential damage to work and personal devices containing sensitive information, we recommend analyzing these exploits and files within isolated environments like virtual machines or sandboxes.
We also recommend exercising general caution when working with code from open sources, always using reliable security solutions, and never adding software to exclusions without a justified reason.
Kaspersky solutions effectively detect this threat with the following verdicts:
Malicious GitHub repositories
https://github[.]com/RedFoxNxploits/CVE-2025-10294-Poc
https://github[.]com/FixingPhantom/CVE-2025-10294
https://github[.]com/h4xnz/CVE-2025-10294-POC
https://github[.]com/usjnx72726w/CVE-2025-59295/tree/main
https://github[.]com/stalker110119/CVE-2025-59230/tree/main
https://github[.]com/moegameka/CVE-2025-59230
https://github[.]com/DebugFrag/CVE-2025-12596-Exploit
https://github[.]com/themaxlpalfaboy/CVE-2025-54897-LAB
https://github[.]com/DExplo1ted/CVE-2025-54106-POC
https://github[.]com/h4xnz/CVE-2025-55234-POC
https://github[.]com/Hazelooks/CVE-2025-11499-Exploit
https://github[.]com/usjnx72726w/CVE-2025-11499-LAB
https://github[.]com/modhopmarrow1973/CVE-2025-11833-LAB
https://github[.]com/rootreapers/CVE-2025-11499
https://github[.]com/lagerhaker539/CVE-2025-12595-POC
Webrat C2
http://ezc5510min[.]temp[.]swtest[.]ru
http://shopsleta[.]ru
MD5
28a741e9fcd57bd607255d3a4690c82f
a13c3d863e8e2bd7596bac5d41581f6a
61b1fc6ab327e6d3ff5fd3e82b430315
Known since 2014, the Cloud Atlas group targets countries in Eastern Europe and Central Asia. Infections occur via phishing emails containing a malicious document that exploits an old vulnerability in the Microsoft Office Equation Editor process (CVE-2018-0802) to download and execute malicious code. In this report, we describe the infection chain and tools that the group used in the first half of 2025, with particular focus on previously undescribed implants.
Additional information about this threat, including indicators of compromise, is available to customers of the Kaspersky Intelligence Reporting Service. Contact: intelreports@kaspersky.com.
The starting point is typically a phishing email with a malicious DOC(X) attachment. When the document is opened, a malicious template is downloaded from a remote server. The document has the form of an RTF file containing an exploit for the formula editor, which downloads and executes an HTML Application (HTA) file.
Fpaylo
Malicious template with the exploit loaded by Word when opening the document
We were unable to obtain the actual RTF template with the exploit. We assume that after a successful infection of the victim, the link to this file becomes inaccessible. In the given example, the malicious RTF file containing the exploit was downloaded from the URL hxxps://securemodem[.]com?tzak.html_anacid.
Template files, like HTA files, are located on servers controlled by the group, and their downloading is limited both in time and by the IP addresses of the victims. The malicious HTA file extracts and creates several VBS files on disk that are parts of the VBShower backdoor. VBShower then downloads and installs other backdoors: PowerShower, VBCloud, and CloudAtlas.
This infection chain largely follows the one previously seen in Cloud Atlas’ 2024 attacks. The currently employed chain is presented below:
Malware execution flow
Several implants remain the same, with insignificant changes in file names, and so on. You can find more details in our previous article on the following implants:
In this research, we’ll focus on new and updated components.
Compared to the previous version, the backdoor runs additional downloaded VB scripts in the current context, regardless of the size. A previous modification of this script checked the size of the payload, and if it exceeded 1 MB, instead of executing it in the current context, the backdoor wrote it to disk and used the wscript utility to launch it.
The script collects information about running processes, including their creation time, caption, and command line. The collected information is encrypted and sent to the C2 server by the parent script (VBShower::Backdoor) via the v_buff variable.
VBShower::Payload (1)
The script is used to install the VBCloud implant. First, it downloads a ZIP archive from the hardcoded URL and unpacks it into the %Public% directory. Then, it creates a scheduler task named “MicrosoftEdgeUpdateTask” to run the following command line:
wscript.exe /B %Public%\Libraries\MicrosoftEdgeUpdate.vbs
It renames the unzipped file %Public%\Libraries\v.log to %Public%\Libraries\MicrosoftEdgeUpdate.vbs, iterates through the files in the %Public%\Libraries directory, and collects information about the filenames and sizes. The data, in the form of a buffer, is collected in the v_buff variable. The malware gets information about the task by executing the following command line:
cmd.exe /c schtasks /query /v /fo CSV /tn MicrosoftEdgeUpdateTask
The specified command line is executed, with the output redirected to the TMP file. Both the TMP file and the content of the v_buff variable will be sent to the C2 server by the parent script (VBShower::Backdoor).
Here is an example of the information present in the v_buff variable:
Libraries: desktop.ini-175| MicrosoftEdgeUpdate.vbs-2299| RecordedTV.library-ms-999| upgrade.mds-32840| v.log-2299|
The file MicrosoftEdgeUpdate.vbs is a launcher for VBCloud, which reads the encrypted body of the backdoor from the file upgrade.mds, decrypts it, and executes it.
VBShower::Payload (2) used to install VBCloud
Almost the same script is used to install the CloudAtlas backdoor on an infected system. The script only downloads and unpacks the ZIP archive to "%LOCALAPPDATA%", and sends information about the contents of the directories "%LOCALAPPDATA%\vlc\plugins\access" and "%LOCALAPPDATA%\vlc" as output.
In this case, the file renaming operation is not applied, and there is no code for creating a scheduler task.
Here is an example of information to be sent to the C2 server:
vlc: a.xml-969608| b.xml-592960| d.xml-2680200| e.xml-185224|| access: c.xml-5951488|
In fact, a.xml, d.xml, and e.xml are the executable file and libraries, respectively, of VLC Media Player. The c.xml file is a malicious library used in a DLL hijacking attack, where VLC acts as a loader, and the b.xml file is an encrypted body of the CloudAtlas backdoor, read from disk by the malicious library, decrypted, and executed.
VBShower::Payload (2) used to install CloudAtlas
This script is the next component for installing CloudAtlas. It is downloaded by VBShower from the C2 server as a separate file and executed after the VBShower::Payload (2) script. The script renames the XML files unpacked by VBShower::Payload (2) from the archive to the corresponding executables and libraries, and also renames the file containing the encrypted backdoor body.
These files are copied by VBShower::Payload (3) to the following paths:
| File | Path |
| a.xml | %LOCALAPPDATA%\vlc\vlc.exe |
| b.xml | %LOCALAPPDATA%\vlc\chambranle |
| c.xml | %LOCALAPPDATA%\vlc\plugins\access\libvlc_plugin.dll |
| d.xml | %LOCALAPPDATA%\vlc\libvlccore.dll |
| e.xml | %LOCALAPPDATA%\vlc\libvlc.dll |
Additionally, VBShower::Payload (3) creates a scheduler task to execute the command line: "%LOCALAPPDATA%\vlc\vlc.exe". The script then iterates through the files in the "%LOCALAPPDATA%\vlc" and "%LOCALAPPDATA%\vlc\plugins\access" directories, collecting information about filenames and sizes. The data, in the form of a buffer, is collected in the v_buff variable. The script also retrieves information about the task by executing the following command line, with the output redirected to a TMP file:
cmd.exe /c schtasks /query /v /fo CSV /tn MicrosoftVLCTaskMachine
Both the TMP file and the content of the v_buff variable will be sent to the C2 server by the parent script (VBShower::Backdoor).
VBShower::Payload (3) used to install CloudAtlas
This script was previously described as VBShower::Payload (1).
This script is used to check access to various cloud services and executed before installing VBCloud or CloudAtlas. It consistently accesses the URLs of cloud services, and the received HTTP responses are saved to the v_buff variable for subsequent sending to the C2 server. A truncated example of the information sent to the C2 server:
GET-https://webdav.yandex.ru| 200| <!DOCTYPE html><html lang="ru" dir="ltr" class="desktop"><head><base href="...
VBShower::Payload (5)
This script was previously described as VBShower::Payload (2).
This is a small script for checking the accessibility of PowerShower’s C2 from an infected system.
VBShower::Payload (7)
This script is used to install PowerShower, another backdoor known to be employed by Cloud Atlas. The script does so by performing the following steps in sequence:
"HKCU\Console\%SystemRoot%_System32_WindowsPowerShell_v1.0_powershell.exe"::"WindowPosition"::5122 "HKCU\UConsole\taskeng.exe"::"WindowPosition"::538126692
powershell.exe -ep bypass -w 01 %APPDATA%\Adobe\AdobeMon.ps1
"%APPDATA%\Adobe\p.txt". Then, renames the file "p.txt" to "AdobeMon.ps1"."%APPDATA%\Adobe". Gets information about the task by executing the following command line, with the output redirected to a TMP file:cmd.exe /c schtasks /query /v /fo LIST /tn MicrosoftAdobeUpdateTaskMachine
VBShower::Payload (8) used to install PowerShower
The decrypted PowerShell script is disguised as one of the standard modules, but at the end of the script, there is a command to launch the PowerShell interpreter with another script encoded in Base64.
Content of AdobeMon.ps1 (PowerShower)
This is a small script for collecting information about the system proxy settings.
VBShower::Payload (9)
On an infected system, VBCloud is represented by two files: a VB script (VBCloud::Launcher) and an encrypted main body (VBCloud::Backdoor). In the described case, the launcher is located in the file MicrosoftEdgeUpdate.vbs, and the payload — in upgrade.mds.
The launcher script reads the contents of the upgrade.mds file, decodes characters delimited with “%H”, uses the RC4 stream encryption algorithm with a key built into the script to decrypt it, and transfers control to the decrypted content. It is worth noting that the implementation of RC4 uses PRGA (pseudo-random generation algorithm), which is quite rare, since most malware implementations of this algorithm skip this step.
VBCloud::Launcher
The backdoor performs several actions in a loop to eventually download and execute additional malicious scripts, as described in the previous research.
Unlike VBShower, which uses a global variable to save its output or a temporary file to be sent to the C2 server, each VBCloud payload communicates with the C2 server independently. One of the most commonly used payloads for the VBCloud backdoor is FileGrabber. The script exfiltrates files and documents from the target system as described before.
The FileGrabber payload has the following limitations when scanning for files:
Part of VBCloud::Payload (FileGrabber)
As mentioned above, PowerShower is installed via one of the VBShower payloads. This script launches the PowerShell interpreter with another script encoded in Base64. Running in an infinite loop, it attempts to access the C2 server to retrieve an additional payload, which is a PowerShell script twice encoded with Base64. This payload is executed in the context of the backdoor, and the execution result is sent to the C2 server via an HTTP POST request.
Decoded PowerShower script
In previous versions of PowerShower, the payload created a sapp.xtx temporary file to save its output, which was sent to the C2 server by the main body of the backdoor. No intermediate files are created anymore, and the result of execution is returned to the backdoor by a normal call to the "return" operator.
This script was previously described as PowerShower::Payload (2). This payload is unique to each victim.
This script is used for grabbing files with metadata from a network share.
PowerShower::Payload (2)
As described above, the CloudAtlas backdoor is installed via VBShower from a downloaded archive delivered through a DLL hijacking attack. The legitimate VLC application acts as a loader, accompanied by a malicious library that reads the encrypted payload from the file and transfers control to it. The malicious DLL is located at "%LOCALAPPDATA%\vlc\plugins\access", while the file with the encrypted payload is located at "%LOCALAPPDATA%\vlc\".
When the malicious DLL gains control, it first extracts another DLL from itself, places it in the memory of the current process, and transfers control to it. The unpacked DLL uses a byte-by-byte XOR operation to decrypt the block with the loader configuration. The encrypted config immediately follows the key. The config specifies the name of the event that is created to prevent a duplicate payload launch. The config also contains the name of the file where the encrypted payload is located — "chambranle" in this case — and the decryption key itself.
Encrypted and decrypted loader configuration
The library reads the contents of the "chambranle" file with the payload, uses the key from the decrypted config and the IV located at the very end of the "chambranle" file to decrypt it with AES-256-CBC. The decrypted file is another DLL with its size and SHA-1 hash embedded at the end, added to verify that the DLL is decrypted correctly. The DLL decrypted from "chambranle" is the main body of the CloudAtlas backdoor, and control is transferred to it via one of the exported functions, specifically the one with ordinal 2.
Main routine that processes the payload file
When the main body of the backdoor gains control, the first thing it does is decrypt its own configuration. Decryption is done in a similar way, using AES-256-CBC. The key for AES-256 is located before the configuration, and the IV is located right after it. The most useful information in the configuration file includes the URL of the cloud service, paths to directories for receiving payloads and unloading results, and credentials for the cloud service.
Encrypted and decrypted CloudAtlas backdoor config
Immediately after decrypting the configuration, the backdoor starts interacting with the C2 server, which is a cloud service, via WebDAV. First, the backdoor uses the MKCOL HTTP method to create two directories: one ("/guessed/intershop/Euskalduns/") will regularly receive a beacon in the form of an encrypted file containing information about the system, time, user name, current command line, and volume information. The other directory ("/cancrenate/speciesists/") is used to retrieve payloads. The beacon file and payload files are AES-256-CBC encrypted with the key that was used for backdoor configuration decryption.
HTTP requests of the CloudAtlas backdoor
The backdoor uses the HTTP PROPFIND method to retrieve the list of files. Each of these files will be subsequently downloaded, deleted from the cloud service, decrypted, and executed.
HTTP requests from the CloudAtlas backdoor
The payload consists of data with a binary block containing a command number and arguments at the beginning, followed by an executable plugin in the form of a DLL. The structure of the arguments depends on the type of command. After the plugin is loaded into memory and configured, the backdoor calls the exported function with ordinal 1, passing several arguments: a pointer to the backdoor function that implements sending files to the cloud service, a pointer to the decrypted backdoor configuration, and a pointer to the binary block with the command and arguments from the beginning of the payload.
Plugin setup and execution routine
Before calling the plugin function, the backdoor saves the path to the current directory and restores it after the function is executed. Additionally, after execution, the plugin is removed from memory.
FileGrabber is the most commonly used plugin. As the name suggests, it is designed to steal files from an infected system. Depending on the command block transmitted, it is capable of:
For each detected file, a series of rules are generated based on the conditions passed within the command block, including:
Resource scanning
If all conditions match, the file is sent to the C2 server, along with its metadata, including attributes, creation time, last access time, last modification time, size, full path to the file, and SHA-1 of the file contents. Additionally, if a special flag is set in one of the rule fields, the file will be deleted after a copy is sent to the C2 server. There is also a limit on the total amount of data sent, and if this limit is exceeded, scanning of the resource stops.
Generating data for sending to C2
This is a general-purpose plugin, which parses the transferred block, splits it into commands, and executes them. Each command has its own ID, ranging from 0 to 6. The list of commands is presented below.
"%APPDATA%\ntsystmp.vbs". The path to launch the file dropped on the remote system is passed to the launched VB script as an argument.
Content of the dropped VBS
This plugin is used to steal cookies and credentials from browsers. This is an extended version of the Common Plugin, which is used for more specific purposes. It can also drop, launch, and delete files, but its primary function is to drop files belonging to the “Chrome App-Bound Encryption Decryption” open-source project onto the disk, and run the utility to steal cookies and passwords from Chromium-based browsers. After launching the utility, several files ("cookies.txt" and "passwords.txt") containing the extracted browser data are created on disk. The plugin then reads JSON data from the selected files, parses the data, and sends the extracted information to the C2 server.
Part of the function for parsing JSON and sending the extracted data to C2
This plugin is used to collect information about the infected system. The list of commands is presented below.
net group "Exchange servers" /domain Ipconfig arp -a
As mentioned in one of our previous reports, Cloud Atlas uses a custom Python script named get_browser_pass.py to extract saved credentials from browsers on infected systems. If the Python interpreter is not present on the victim’s machine, the group delivers an archive that includes both the script and a bundled Python interpreter to ensure execution.
During one of the latest incidents we investigated, we once again observed traces of this tool in action, specifically the presence of the file "C:\ProgramData\py\pytest.dll".
The pytest.dll library is called from within get_browser_pass.py and used to extract credentials from Yandex Browser. The data is then saved locally to a file named y3.txt.
According to our telemetry, the identified targets of the malicious activities described here are located in Russia and Belarus, with observed activity dating back to the beginning of 2025. The industries being targeted are diverse, encompassing organizations in the telecommunications sector, construction, government entities, and plants.
For more than ten years, the group has carried on its activities and expanded its arsenal. Now the attackers have four implants at their disposal (PowerShower, VBShower, VBCloud, CloudAtlas), each of them a full-fledged backdoor. Most of the functionality in the backdoors is duplicated, but some payloads provide various exclusive capabilities. The use of cloud services to manage backdoors is a distinctive feature of the group, and it has proven itself in various attacks.
Note: The indicators in this section are valid at the time of publication.
0D309C25A835BAF3B0C392AC87504D9E протокол (08.05.2025).doc
D34AAEB811787B52EC45122EC10AEB08 HTA
4F7C5088BCDF388C49F9CAAD2CCCDCC5 StandaloneUpdate_2020-04-13_090638_8815-145.log:StandaloneUpdate_2020-04-13_090638_8815-145cfcf.vbs
5C93AF19EF930352A251B5E1B2AC2519 StandaloneUpdate_2020-04-13_090638_8815-145.log:StandaloneUpdate_2020-04-13_090638_8815-145.dat (encrypted)
0E13FA3F06607B1392A3C3CAA8092C98 VBShower::Payload(1)
BC80C582D21AC9E98CBCA2F0637D8993 VBShower::Payload(2)
12F1F060DF0C1916E6D5D154AF925426 VBShower::Payload(3)
E8C21CA9A5B721F5B0AB7C87294A2D72 VBShower::Payload(4)
2D03F1646971FB7921E31B647586D3FB VBShower::Payload(5)
7A85873661B50EA914E12F0523527CFA VBShower::Payload(6)
F31CE101CBE25ACDE328A8C326B9444A VBShower::Payload(7)
E2F3E5BF7EFBA58A9C371E2064DFD0BB VBShower::Payload(8)
67156D9D0784245AF0CAE297FC458AAC VBShower::Payload(9)
116E5132E30273DA7108F23A622646FE VBCloud::Launcher
E9F60941A7CED1A91643AF9D8B92A36D VBCloud::Payload(FileGrabber)
718B9E688AF49C2E1984CF6472B23805 PowerShower
A913EF515F5DC8224FCFFA33027EB0DD PowerShower::Payload(2)
BAA59BB050A12DBDF981193D88079232 chambranle (encrypted)
billet-ru[.]net
mskreg[.]net
flashsupport[.]org
solid-logit[.]com
cityru-travel[.]org
transferpolicy[.]org
information-model[.]net
securemodem[.]com
In March 2025, we discovered Operation ForumTroll, a series of sophisticated cyberattacks exploiting the CVE-2025-2783 vulnerability in Google Chrome. We previously detailed the malicious implants used in the operation: the LeetAgent backdoor and the complex spyware Dante, developed by Memento Labs (formerly Hacking Team). However, the attackers behind this operation didn’t stop at their spring campaign and have continued to infect targets within the Russian Federation.
More reports about this threat are available to customers of the Kaspersky Intelligence Reporting Service. Contact: intelreports@kaspersky.com.
In October 2025, just days before we presented our report detailing the ForumTroll APT group’s attack at the Security Analyst Summit, we detected a new targeted phishing campaign by the same group. However, while the spring cyberattacks focused on organizations, the fall campaign honed in on specific individuals: scholars in the field of political science, international relations, and global economics, working at major Russian universities and research institutions.
The emails received by the victims were sent from the address support@e-library[.]wiki. The campaign purported to be from the scientific electronic library, eLibrary, whose legitimate website is elibrary.ru. The phishing emails contained a malicious link in the format: https://e-library[.]wiki/elib/wiki.php?id=<8 pseudorandom letters and digits>. Recipients were prompted to click the link to download a plagiarism report. Clicking that link triggered the download of an archive file. The filename was personalized, using the victim’s own name in the format: <LastName>_<FirstName>_<Patronymic>.zip.
The attackers did their homework before sending out the phishing emails. The malicious domain, e-library[.]wiki, was registered back in March 2025, over six months before the email campaign started. This was likely done to build the domain’s reputation, as sending emails from a suspicious, newly registered domain is a major red flag for spam filters.
Furthermore, the attackers placed a copy of the legitimate eLibrary homepage on https://e-library[.]wiki. According to the information on the page, they accessed the legitimate website from the IP address 193.65.18[.]14 back in December 2024.
A screenshot of the malicious site elements showing the IP address and initial session date
The attackers also carefully personalized the phishing emails for their targets, specific professionals in the field. As mentioned above, the downloaded archive was named with the victim’s last name, first name, and patronymic.
Another noteworthy technique was the attacker’s effort to hinder security analysis by restricting repeat downloads. When we attempted to download the archive from the malicious site, we received a message in Russian, indicating the download link was likely for one-time use only:
The message that was displayed when we attempted to download the archive
Our investigation found that the malicious site displayed a different message if the download was attempted from a non-Windows device. In that case, it prompted the user to try again from a Windows computer.
The message that was displayed when we attempted to download the archive from a non-Windows OS
The malicious archives downloaded via the email links contained the following:
<LastName>_<FirstName>_<Patronymic>.lnk;.Thumbs directory containing approximately 100 image files with names in Russian. These images were not used during the infection process and were likely added to make the archives appear less suspicious to security solutions.
A portion of the .Thumbs directory contents
When the user clicked the shortcut, it ran a PowerShell script. The script’s primary purpose was to download and execute a PowerShell-based payload from a malicious server.
The script that was launched by opening the shortcut
The downloaded payload then performed the following actions:
https://e-library[.]wiki/elib/query.php?id=<8 pseudorandom letters and digits>&key=<32 hexadecimal characters> to retrieve the final payload, a DLL file.%localappdata%\Microsoft\Windows\Explorer\iconcache_<4 pseudorandom digits>.dll.https://e-library[.]wiki/pdf/<8 pseudorandom letters and digits>.pdf. This PDF was saved to the user’s Downloads folder with a filename in the format: <LastName>_<FirstName>_<Patronymic>.pdf and then opened automatically.The decoy PDF contained no valuable information. It was merely a blurred report generated by a Russian plagiarism-checking system.
A screenshot of a page from the downloaded report
At the time of our investigation, the links for downloading the final payloads didn’t work. Attempting to access them returned error messages in English: “You are already blocked…” or “You have been bad ended” (sic). This likely indicates the use of a protective mechanism to prevent payloads from being downloaded more than once. Despite this, we managed to obtain and analyze the final payload.
The DLL file deployed to infected devices proved to be an OLLVM-obfuscated loader, which we described in our previous report on Operation ForumTroll. However, while this loader previously delivered rare implants like LeetAgent and Dante, this time the attackers opted for a better-known commercial red teaming framework: Tuoni. Portions of the Tuoni code are publicly available on GitHub. By deploying this tool, the attackers gained remote access to the victim’s device along with other capabilities for further system compromise.
As in the previous campaign, the attackers used fastly.net as C2 servers.
The cyberattacks carried out by the ForumTroll APT group in the spring and fall of 2025 share significant similarities. In both campaigns, infection began with targeted phishing emails, and persistence for the malicious implants was achieved with the COM Hijacking technique. The same loader was used to deploy the implants both in the spring and the fall.
Despite these similarities, the fall series of attacks cannot be considered as technically sophisticated as the spring campaign. In the spring, the ForumTroll APT group exploited zero-day vulnerabilities to infect systems. By contrast, the autumn attacks relied entirely on social engineering, counting on victims not only clicking the malicious link but also downloading the archive and launching the shortcut file. Furthermore, the malware used in the fall campaign, the Tuoni framework, is less rare.
ForumTroll has been targeting organizations and individuals in Russia and Belarus since at least 2022. Given this lengthy timeline, it is likely this APT group will continue to target entities and individuals of interest within these two countries. We believe that investigating ForumTroll’s potential future campaigns will allow us to shed light on shadowy malicious implants created by commercial developers – much as we did with the discovery of the Dante spyware.
e-library[.]wiki
perf-service-clients2.global.ssl.fastly[.]net
bus-pod-tenant.global.ssl.fastly[.]net
status-portal-api.global.ssl.fastly[.]net
In August 2025, we discovered a campaign targeting individuals in Turkey with a new Android banking Trojan we dubbed “Frogblight”. Initially, the malware was disguised as an app for accessing court case files via an official government webpage. Later, more universal disguises appeared, such as the Chrome browser.
Frogblight can use official government websites as an intermediary step to steal banking credentials. Moreover, it has spyware functionality, such as capabilities to collect SMS messages, a list of installed apps on the device and device filesystem information. It can also send arbitrary SMS messages.
Another interesting characteristic of Frogblight is that we’ve seen it updated with new features throughout September. This may indicate that a feature-rich malware app for Android is being developed, which might be distributed under the MaaS model.
This threat is detected by Kaspersky products as HEUR:Trojan-Banker.AndroidOS.Frogblight.*, HEUR:Trojan-Banker.AndroidOS.Agent.eq, HEUR:Trojan-Banker.AndroidOS.Agent.ep, HEUR:Trojan-Spy.AndroidOS.SmsThief.de.
While performing an analysis of mobile malware we receive from various sources, we discovered several samples belonging to a new malware family. Although these samples appeared to be still under development, they already contained a lot of functionality that allowed this family to be classified as a banking Trojan. As new versions of this malware continued to appear, we began monitoring its development. Moreover, we managed to discover its control panel and based on the “fr0g” name shown there, we dubbed this family “Frogblight”.
We believe that smishing is one of the distribution vectors for Frogblight, and that the users had to install the malware themselves. On the internet, we found complaints from Turkish users about phishing SMS messages convincing users that they were involved in a court case and containing links to download malware. versions of Frogblight, including the very first ones, were disguised as an app for accessing court case files via an official government webpage and were named the same as the files for downloading from the links mentioned above.
While looking for online mentions of the names used by the malware, we discovered one of the phishing websites distributing Frogblight, which disguises itself as a website for viewing a court file.
The phishing website distributing Frogblight
We were able to open the admin panel of this website, where it was possible to view statistics on Frogblight malware downloads. However, the counter had not been fully implemented and the threat actor could only view the statistics for their own downloads.
The admin panel interface of the website from which Frogblight is downloaded
Additionally, we found the source code of this phishing website available in a public GitHub repository. Judging by its description, it is adapted for fast deployment to Vercel, a platform for hosting web apps.
The GitHub repository with the phishing website source code
As already mentioned, Frogblight was initially disguised as an app for accessing court case files via an official government webpage. Let’s look at one of the samples using this disguise (9dac23203c12abd60d03e3d26d372253). For analysis, we selected an early sample, but not the first one discovered, in order to demonstrate more complete Frogblight functionality.
After starting, the app prompts the victim to grant permissions to send and read SMS messages, and to read from and write to the device’s storage, allegedly needed to show a court file related to the user.
The full list of declared permissions in the app manifest file is shown below:
After all required permissions are granted, the malware opens the official government webpage for accessing court case files in WebView, prompting the victim to sign in. There are different sign-in options, one of them via online banking. If the user chooses this method, they are prompted to click on a bank whose online banking app they use and fill out the sign-in form on the bank’s official website. This is what Frogblight is after, so it waits two seconds, then opens the online banking sign-in method regardless of the user’s choice. For each webpage that has finished loading in WebView, Frogblight injects JavaScript code allowing it to capture user input and send it to the C2 via a REST API.
The malware also changes its label to “Davalarım” if the Android version is newer than 12; otherwise it hides the icon.
 |
 |
fetchOutbox and getFileCommands. Other methods are called when specific events occur, for example, after the device screen is turned on, the com.capcuttup.refresh.PersistentService foreground service is launched, or an SMS is received. The full list of all REST API client methods with parameters and descriptions is shown below.
| REST API client method | Description | Parameters |
| fetchOutbox | Request message content to be sent via SMS or displayed in a notification | device_id: unique Android device ID |
| ackOutbox | Send the results of processing a message received after calling the API method fetchOutbox | device_id: unique Android device ID msg_id: message ID status: message processing status error: message processing error |
| getAllPackages | Request the names of app packages whose launch should open a website in WebView to capture user input data | action: same as the API method name |
| getPackageUrl | Request the website URL that will be opened in WebView when the app with the specified package name is launched | action: same as the API method name package: the package name of the target app |
| getFileCommands | Request commands for file operations
Available commands: |
device_id: unique Android device ID |
| pingDevice | Check the C2 connection | device_id: unique Android device ID |
| reportHijackSuccess | Send captured user input data from the website opened in a WebView when the app with the specified package name is launched | action: same as the API method name package: the package name of the target app data: captured user input data |
| saveAppList | Send information about the apps installed on the device | device_id: unique Android device ID app_list: a list of apps installed on the device app_count: a count of apps installed on the device |
| saveInjection | Send captured user input data from the website opened in a WebView. If it was not opened following the launch of the target app, the app_name parameter is determined based on the opened URL | device_id: unique Android device ID app_name: the package name of the target app form_data: captured user input data |
| savePermission | Unused but presumably needed for sending information about permissions | device_id: unique Android device ID permission_type: permission type status: permission status |
| sendSms | Send information about an SMS message from the device | device_id: unique Android device ID sender: the sender’s/recipient’s phone number message: message text timestamp: received/sent time type: message type (inbox/sent) |
| sendTelegramMessage | Send captured user input data from the webpages opened by Frogblight in WebView | device_id: unique Android device ID url: website URL title: website page title input_type: the type of user input data input_value: user input data final_value: user input data with additional information timestamp: the time of data capture ip_address: user IP address sms_permission: whether SMS permission is granted file_manager_permission: whether file access permission is granted |
| updateDevice | Send information about the device | device_id: unique Android device ID model: device manufacturer and model android_version: Android version phone_number: user phone number battery: current battery level charging: device charging status screen_status: screen on/off ip_address: user IP address sms_permission: whether SMS permission is granted file_manager_permission: whether file access permission is granted |
| updatePermissionStatus | Send information about permissions | device_id: unique Android device ID permission_type: permission type status: permission status timestamp: current time |
| uploadBatchThumbnails | Upload thumbnails to the C2 | device_id: unique Android device ID thumbnails: thumbnails |
| uploadFile | Upload a file to the C2 | device_id: unique Android device ID file_path: file path download_id: the file ID on the C2 The file itself is sent as an unnamed parameter |
| uploadFileList | Send information about all files in the target directory | device_id: unique Android device ID path: directory path file_list: information about the files in the target directory |
| uploadFileListLog | Send information about all files in the target directory to an endpoint different from uploadFileList | device_id: unique Android device ID path: directory path file_list: information about the files in the target directory |
| uploadThumbnailLog | Unused but presumably needed for uploading thumbnails to an endpoint different from uploadBatchThumbnails | device_id: unique Android device ID thumbnails: thumbnails |
The app includes several classes to provide the threat actor with remote access to the infected device, gain persistence, and protect the malicious app from being deleted.
capcuttup.refresh.AccessibilityAutoClickServicecapcuttup.refresh.PersistentServicecapcuttup.refresh.BootReceiverIn later versions, new functionality was added, and some of the more recent Frogblight variants disguised themselves as the Chrome browser. Let’s look at one of the fake Chrome samples (d7d15e02a9cd94c8ab00c043aef55aff).
In this sample, new REST API client methods have been added for interacting with the C2.
| REST API client method | Description | Parameters |
| getContactCommands | Get commands to perform actions with contacts Available commands: ● ADD_CONTACT: add a contact to the user device ● DELETE_CONTACT: delete a contact from the user device ● EDIT_CONTACT: edit a contact on the user device |
device_id: unique Android device ID |
| sendCallLogs | Send call logs to the C2 | device_id: unique Android device ID call_logs: call log data |
| sendNotificationLogs | Send notifications log to the C2. Not fully implemented in this sample, and as of the time of writing this report, we hadn’t seen any samples with a full-fledged implementation of this API method | action: same as the API method name notifications: notification log data |
Also, the threat actor had implemented a custom input method for recording keystrokes to a file using the com.puzzlesnap.quickgame.CustomKeyboardService service.
Another Frogblight sample we observed trying to avoid emulators and using geofencing techniques is 115fbdc312edd4696d6330a62c181f35. In this sample, Frogblight checks the environment (for example, device model) and shuts down if it detects an emulator or if the device is located in the United States.
Part of the code responsible for avoiding Frogblight running in an undesirable environment
Later on, the threat actor decided to start using a web socket instead of the REST API. Let’s see an example of this in one of the recent samples (08a3b1fb2d1abbdbdd60feb8411a12c7). This sample is disguised as an app for receiving social support via an official government webpage. The feature set of this sample is very similar to the previous ones, with several new capabilities added. Commands are transmitted over a web socket using the JSON format. A command template is shown below:
{
"id": <command ID>,
"command_type": <command name>
"command_data": <command data>
}It is also worth noting that some commands in this version share the same meaning but have different structures, and the functionality of certain commands has not been fully implemented yet. This indicates that Frogblight was under active development at the time of our research, and since no its activity was noticed after September, it is possible that the malware is being finalized to a fully operational state before continuing to infect users’ devices. A full list of commands with their parameters and description is shown below:
| Command | Description | Parameters |
| connect | Send a registration message to the C2 | – |
| connection_success | Send various information, such as call logs, to the C2; start pinging the C2 and requesting commands | – |
| auth_error | Log info about an invalid login key to the Android log system | – |
| pong_device | Does nothing | – |
| commands_list | Execute commands | List of commands |
| sms_send_command | Send an arbitrary SMS message | recipient: message destination message: message text msg_id: message ID |
| bulk_sms_command | Send an arbitrary SMS message to multiple recipients | recipients: message destinations message: message text |
| get_contacts_command | Send all contacts to the C2 | – |
| get_app_list_command | Send information about the apps installed on the device to the C2 | – |
| get_files_command | Send information about all files in certain directories to the C2 | – |
| get_call_logs_command | Send call logs to the C2 | – |
| get_notifications_command | Send a notifications log to the C2. This is not fully implemented in the sample at hand, and as of the time of writing this report, we hadn’t seen any samples with a full-fledged implementation of this command | – |
| take_screenshot_command | Take a screenshot. This is not fully implemented in the sample at hand, and as of the time of writing this report, we hadn’t seen any samples with a full-fledged implementation of this command | – |
| update_device | Send registration message to the C2 | – |
| new_webview_data | Collect WebView data. This is not fully implemented in the sample at hand, and as of the time of writing this report, we hadn’t seen any samples with a full-fledged implementation of this command | – |
| new_injection | Inject code. This is not fully implemented in the sample at hand, and as of the time of writing this report, we hadn’t seen any samples with a full-fledged implementation of this command | code: injected code target_app: presumably the package name of the target app |
| add_contact_command | Add a contact to the user device | name: contact name phone: contact phone email: contact email |
| contact_add | Add a contact to the user device | display_name: contact name phone_number: contact phone email: contact email |
| contact_delete | Delete a contact from the user device | phone_number: contact phone |
| contact_edit | Edit a contact on the user device | display_name: new contact name phone_number: contact phone email: new contact email |
| contact_list | Send all contacts to the C2 | – |
| file_list | Send information about all files in the specified directory to the C2 | path: directory path |
| file_download | Upload the specified file to the C2 | file_path: file path download_id: an ID that is received with the command and sent back to the C2 along with the requested file. Most likely, this is used to organize data on the C2 |
| file_thumbnail | Generate a thumbnail from the target image file and upload it to the C2 | file_path: image file path |
| file_thumbnails | Generate thumbnails from the image files in the target directory and upload them to the C2 | folder_path: directory path |
| health_check | Send information about the current device state: battery level, screen state, and so on | – |
| message_list_request | Send all SMS messages to the C2 | – |
| notification_send | Show an arbitrary notification | title: notification title message: notification message app_name: notification subtext |
| package_list_response | Save the target package names | packages: a list of all target package names. Each list element contains: package_name: target package name active: whether targeting is active |
| delete_contact_command | Delete a contact from the user device. This is not fully implemented in the sample at hand, and as of the time of writing this report, we hadn’t seen any samples with a full-fledged implementation of this command | contact_id: contact ID name: contact name |
| file_upload_command | Upload specified file to the C2. This is not fully implemented in the sample at hand, and as of the time of writing this report, we hadn’t seen any samples with a full-fledged implementation of this command | file_path: file path file_name: file name |
| file_download_command | Download file to user device. This is not fully implemented in the sample at hand, and as of the time of writing this report, we hadn’t seen any samples with a full-fledged implementation of this command | file_url: the URL of the file to download download_path: download path |
| download_file_command | Download file to user device. This is not fully implemented in the sample at hand, and as of the time of writing this report, we hadn’t seen any samples with a full-fledged implementation of this command | file_url: the URL of the file to download download_path: downloading path |
| get_permissions_command | Send a registration message to the C2, including info about specific permissions | – |
| health_check_command | Send information about the current device state, such as battery level, screen state, and so on | – |
| connect_error | Log info about connection errors to the Android log system | A list of errors |
| reconnect | Send a registration message to the C2 | – |
| disconnect | Stop pinging the C2 and requesting commands from it | – |
Authentication via WebSocket takes place using a special key.
The part of the code responsible for the WebSocket authentication logic
At the IP address to which the WebSocket connection was made, the Frogblight web panel was accessible, which accepted the authentication key mentioned above. Since only samples using the same key as the webpanel login are controllable through it, we suggest that Frogblight might be distributed under the MaaS model.
The interface of the sign-in screen for the Frogblight web panel
Judging by the menu options, the threat actor can sort victims’ devices by certain parameters, such as the presence of banking apps on the device, and send bulk SMS messages and perform other mass actions.
Since some versions of Frogblight opened the Turkish government webpage to collect user-entered data on Turkish banks’ websites, we assume with high confidence that it is aimed mainly at users from Turkey. Also, based on our telemetry, the majority of users attacked by Frogblight are located in that country.
Even though it is not possible to provide an attribution to any known threat actor based on the information available, during our analysis of the Frogblight Android malware and the search for online mentions of the names it uses, we discovered a GitHub profile containing repos with Frogblight, which had also created repos with Coper malware, distributed under the MaaS model. It is possible that this profile belongs to the attackers distributing Coper who have also started distributing Frogblight.
GitHub repositories containing Frogblight and Coper malware
Also, since the comments in the Frogblight code are written in Turkish, we believe that its developers speak this language.
The new Android malware we dubbed “Frogblight” appeared recently and targets mainly users from Turkey. This is an advanced banking Trojan aimed at stealing money. It has already infected real users’ devices, and it doesn’t stop there, adding more and more new features in the new versions that appear. It can be made more dangerous by the fact that it may be used by attackers who already have experience distributing malware. We will continue to monitor its development.
More indicators of compromise, as well as any updates to these, are available to the customers of our crimeware reporting service. If you are interested, please contact crimewareintel@kaspersky.com.
APK file hashes
8483037dcbf14ad8197e7b23b04aea34
105fa36e6f97977587a8298abc31282a
e1cd59ae3995309627b6ab3ae8071e80
115fbdc312edd4696d6330a62c181f35
08a3b1fb2d1abbdbdd60feb8411a12c7
d7d15e02a9cd94c8ab00c043aef55aff
9dac23203c12abd60d03e3d26d372253
C2 domains
1249124fr1241og5121.sa[.]com
froglive[.]net
C2 IPs
45.138.16.208[:]8080
URL of GitHub repository with Frogblight phishing website source code
https://github[.]com/eraykarakaya0020/e-ifade-vercel
URL of GitHub account containing APK files of Frogblight and Coper
https://github[.]com/Chromeapk
Distribution URLs
https://farketmez37[.]cfd/e-ifade.apk
https://farketmez36[.]sbs/e-ifade.apk
https://e-ifade-app-5gheb8jc.devinapps[.]com/e-ifade.apk
Online casino spam has been without a doubt one of the most prevalent types of spam content that we’ve seen on infected websites in recent years. An extremely common method of promoting low-quality or otherwise undesirable websites is for spammers to hack websites and fill them full of backlinks to pump their SEO. Historically this has been most common with pharma spam as well as essay writing services, knockoff designer goods and others. However, in the last period there’s been an unmistakable shift to online casinos.
Continue reading Slot Gacor: The Rise of Online Casino Spam at Sucuri Blog.
Summer is flying by and before you know it, you’ll be buying backpacks and taking first-day-of-school photos. Back-to-school season brings new classes and friends, but it also brings new digital dangers. By the time you’ve dropped your kids off for their first day of class, chances are they’ve already been exposed to their first cyberthreat of the day. New devices, new online accounts, and relaxed summer screen habits could make your children vulnerable to a slew of online threats.
For most kids, especially teenagers, being online is a big part of daily life. From scrolling through TikTok and watching YouTube videos to chatting with friends and gaming, 46% of teens say they’re online “almost constantly.” Cybercriminals know this and are always looking for opportunities to cash in on your kids’ online activity. Threats like social media phishing have skyrocketed from 18.9% to 42.8%. Some of these scams are directly aimed at children, including a rash of fake school emails designed to steal sensitive personal information. Since more than 80% of data breaches start with stolen passwords, it’s more important than ever that your children use strong passwords that are difficult to crack. The good news? We’ve put together a digital safety checklist to help you boost your entire family’s cybersecurity in just one weekend.
Want to secure your whole family’s digital life? Complete this back-to-school digital security checklist and use it to protect your entire household in under an hour.
Complete this weekend: Install reputable antivirus software: Keep your family cyber safe by installing antivirus software on all devices. Webroot Total Protection offers comprehensive online security and protection for up to ten devices. It includes real-time monitoring to safeguard you from bank and credit card fraud and identity theft. Enable automatic updates: Outdated software puts you and your family at risk for cyberfraud. Protect your important digital data by enabling automatic updates for all your apps, software and devices. This ensures you always have the latest security patches, and you can schedule updates to happen overnight, so they won’t interrupt your family’s screen time. Create a strong Wi-Fi password: Every smart home device you have, from Nest thermostats to Ring doorbell cameras, connects to your Wi-Fi and creates an opportunity for hackers to break in. Be sure to lock down your home network by creating a strong password for your router.
Set up encrypted connections: Consider using a VPN (Virtual Private Network) to protect your personal information. Whether you’re at home or public Wi-Fi, Webroot Secure VPN provides encrypted connections for safe browsing and online transactions. Create a backup system for schoolwork and important files: Keep all your homework, projects and other valuable files safe from online fraud with regular backups. Carbonite offers automatic, encrypted backups and unlimited cloud storage, giving you peace of mind that your digital data is always stored safely and easy to restore.
Monthly tasks (general): Review and update passwords: Pick your child’s three most important passwords and update them together. Be sure to make them long and strong – nothing easy to guess like “12345”, “password”, or your pet’s name. Check your child’s app downloads and permissions: Remove unnecessary apps and manage permissions to deny unwanted data sharing. Review parental control settings: Review parental control settings on all devices and adjust as needed.
Elementary (6-10 years)
This week: Set up strict parental controls: Make managing screen time and content access on all devices easy with Webroot Parental Controls. Whether your kids are playing Minecraft or chatting on Discord, it’s an easy way to keep them safe while giving them space. It even lets you tailor different levels of protection according to their ages. Create a “safe list”: Make a list of parent-approved websites and apps for your kids. Establish device-free homework zones and times: Create a digital detox zone in your home to disengage from all things digital – no texting, email or social media allowed! Practice the “ask first” rule: Teach your kids to ask a parent before accessing any new downloads or websites
Ongoing: Monitor all online activity: Always be aware of the games, apps and sites your child uses and anyone they are communicating with. Keep devices in common areas: Limit online activity to spaces in your home where it’s easy to keep an eye on what your kids are doing. Teach basic online “stranger danger”: Stranger danger is just as important for online interactions as it is for in-person encounters. Be sure your child knows the basics to keep them safe in all situations.
Middle school (11-13 years)
This week: Set up password manager and teach them to use it: Strong, unique passwords are a simple, yet powerful security tool. Webroot solutions include password managers that store your credentials and credit card information and automatically fill in login information for you. Start using Webroot’s password manager with your kids and teach them how easy it is to generate secure passwords. Configure social media privacy settings: Work together with your kids to create safe social media settings. Establish screen time limits: Create screen time limits and stick to consequences if the agreement is broken. Create a family media agreement with clear rules: Create a media-use contract together and be sure to include screen time, study time, and mental health breaks.
Ongoing: Check-in regularly about online experiences: Establish a monthly check-in to discuss what they’re seeing and experiencing online. Monitor friend lists and follower requests: Regularly check on and manage new friend and follower requests for your children. Instill in your children to not accept friend requests from anyone they do not know IRL. Discuss oversharing risks: Remind your kids to not share locations, school names, and other personal details on social media.
High school (14-18 Years)
This week: Transition to collaborative security: Work together with your teens to create a security plan. Discuss the need for a digital safety strategy in a matter-of-fact way, just as you’d discuss the need for driving safety rules. Review the need for password security and remind them how important it is that they never share their passwords with anyone but their parents or caregivers. Discuss the impact of their digital footprint: Remind your kids that their current digital lives can have an impact on their future. Explain how social media profiles, postings, and other content can affect college applications and job opportunities and their safety. Set up two-factor authentication: Establish and enforce two-factor authentication (2FA) on all important accounts, such as email, banking and even social media. Review gaming and social media privacy settings: Gaming apps are often automatically set to share personal information. Work with your teen to review and adjust settings.
Ongoing: Monthly “digital wellness” conversations: Make sure to check in with your teens on the emotional effects of their online habits. Discuss academic integrity: Talk about AI cheating, online ethics, and responsible use. Set boundaries about using AI tools for schoolwork. Address dating app safety and sextortion risks: No matter how uncomfortable it may be, be straightforward with your kids about the risks of sexting. Be sure they understand that any sexual messages or images they share digitally can live forever. Even on a platform like Snapchat, where images are supposed to be temporary, someone can screenshot, save and share messages and images with others. Just one text to the wrong person could have deeply painful and humiliating consequences.
Starting conversations about online safety with your kids isn’t always easy, but with the right approach, you can help them build digital confidence and awareness.
For elementary kids:
For middle schoolers:
For high schoolers:
Webroot offers real-time protection to keep your family safe online without slowing down devices during homework time. With coverage for multiple devices, including phones, tablets, and computers, it’s easy to protect every member of your household.
Cybersecurity doesn’t go on summer break, so take an hour this weekend to complete the checklist and strengthen your family’s digital defenses before the first bell rings. With Webroot’s powerful tools, you’ll get year-round protection, so you can focus on having a safe, smart, and cyber-savvy school year!
Additional resources:
The post Back-to-school cyber safety: Parent checklist appeared first on Webroot Blog.
Ready, set, pack! Summer travel season is here and that means family road trips, beach vacations, international adventures and more. While summertime is prime time for getaways, did you know it’s also prime time for online fraud? Scammers are targeting the travel industry, putting millions of travelers at increased risk. Research shows that the travel and tourism sector ranked third in cyberattacks, with nearly 31% of hospitality organizations experiencing a data breach and a record 340 million people affected by cybercrimes. According to Mastercard, travel-related fraud in 2024 increased by 18% during the summer peak season and 28% in the winter peak season.
Being in an unfamiliar environment can put your personal information at risk if you’re relying on public Wi-Fi networks, using shared devices, and carrying valuable personal and business data on mobile devices. Let’s be honest, when you go into “vacation mode” and start relaxing, it’s only natural that you might also start letting your guard down. Even the best trips can have stressful moments, and when you miss a flight or get lost in a new destination, it’s easy to become less vigilant about protecting your cybersecurity. This is especially true when you travel to foreign countries. In fact, 90% of international travelers admit to risky tech practices while abroad. Fewer than 1 in 3 travelers (31%) protect their data with a virtual private network (VPN) when traveling internationally.
Believe it or not, the risks to your data security start long before your vacation begins. As soon as you start booking your trip, the cybercriminals start circling. Fraud rates in sectors associated with the early stages of trip planning increased more than 12% between 2023 and 2024. At a time when inflation and economic pressures are on the rise, people are looking for deep discounts, and scammers are seizing the opportunity to steal your private data and your money.
Before you hit the road, help protect your digital data and devices with a few simple security practices.
No matter what your summer destination, make cybersecurity part of your travel plans. From securing your Wi-Fi connection and turning off Bluetooth to enabling two-factor authentication, small steps can make a big difference. Let Webroot keep all your digital data safe while you’re on the go. Then all you have to worry about is remembering to turn on your out-of-office reply!
Looking for more information?
Fighting Back Against Loyalty Fraud
Protect Yourself Against AI Phishing Attacks
The post Tips to make your summer travels cyber safe appeared first on Webroot Blog.
The month of June is a time for fun in the sun and a break from the school year, but did you know it’s also the perfect time to step up your family’s online security? June is Internet Safety Month, a yearly reminder to strengthen your defenses against online threats. In today’s hyper-connected world, we use the internet for just about everything, from shopping to banking to streaming and work. That goes for your kids as well. Many of their favorite activities, including gaming and connecting with friends on social media, are connected to the internet. While all this access means added convenience, it also means constant threats to your family’s online safety.
From phishing scams to malware, hackers are constantly looking for ways to exploit weaknesses in cybersecurity systems and software. Their goal is always the same: to get access to personal data and use it for profit. The rising numbers tell the story. In 2024, the FBI’s Internet Crime Complaint Center (IC3) received more than 850,000 cybercrime complaints, with reported losses exceeding $10.3 billion. This is partly due to the increase in data breaches. Studies show that 51% of Americans report they’ve been victims of a data breach, and 64% say they’ve changed their online behavior for fear of escalating online threats like ransomware and identity theft.
It’s not just adults getting targeted online. Children and teens are increasingly exposed to scams (even extortion scams), cyberbullying, and inappropriate content—especially during summer when screen time surges. A recent Pew Research study found that 45% of teens are online almost constantly. So how do you let your kids enjoy their screens safely? Webroot Total Protection and Webroot Essentials offer parental controls that make it easy to manage your children’s online activity and content access. You can block specific websites, filter out inappropriate content and set daily limits on computer time. You can also monitor what sites your kids visit and interact with, and even tailor different levels of protection for each child. Whether your kids are watching YouTube, chatting on Discord, or gaming with friends, it’s a simple way to keep them safe without having to hover over them every time they’re online.
As we spend more time on our mobile devices, cybercriminals are following suit. A recent security report shows that 70% of fraud is now carried out through mobile channels. From phones and tablets to laptops, the mobile devices your family relies on daily are brimming with personal data. Now more than ever, we need to take steps to protect ourselves and our family. Webroot Essentials provides multi-device protection with real-time threat intelligence. Whether you’re on Android, iOS, Windows or Mac, all the devices in your household are constantly safeguarded against the latest online threats.
Are you still using passwords like your dog’s name and 123? And what about your kids? Chances are their Roblox passwords aren’t as tough to hack as they should be. If there’s one weak link in most people’s security, it’s their passwords. Cybercriminals know that, and they’re taking full advantage. In fact, the 2025 Verizon Data Breach Investigations Report found 81% of data breaches were caused by compromised passwords. Here are some tips to keep all your family’s passwords secure.
It’s important to stay aware of the latest online threats. Social engineering scams are designed to gain your trust and then trick you into sharing sensitive details by clicking on fake links or downloading malicious software. The most common type of social engineering is phishing. In a phishing attack, hackers pretend to be someone you trust and use fraudulent emails, texts and websites to try and steal personal information.
Scammers often use phishing to target children. They pose as friends, influencers, or game platforms to trick them into clicking fake links and handing over details like credit card numbers. These scams often start with an offer of an exciting reward or a prize. Take some time to talk with your kids about these common scams.
Home security means more than just deadbolts and alarms. With smart TVs, video doorbells, and wireless thermostats, our homes are more connected than ever. While all these Internet of Things (IoT) devices making our lives more convenient, each one is a potential entry point for hackers. Webroot Secure VPN provides encrypted connections for safe browsing at home. When your family is on the go, it protects your online privacy on unsecured networks and shields your personal information from cyberthieves.
Cybercriminals never take a break and neither should you. Internet Safety Month is the perfect opportunity to step up the digital safety of your entire household. And remember – online security isn’t just an annual event. Your sensitive data deserves year-round protection, and you can get it with family-friendly solutions from Webroot. Don’t wait for a data breach or other disaster to take action. Keep your kids safe and your data secure by strengthening your digital defenses today!
Avoiding Scams that Target Kids and Teens
Protecting Young Online Gamers
How Americans View Data Privacy
Social Security Numbers and Identity Theft
Protect Yourself from AI-Enabled Phishing
Common Types of Phishing Attacks
Defending Your Digital Identity from Evolving Threats
The post Build strong digital defenses for your entire family appeared first on Webroot Blog.
In today’s digital world, your personal data is like cold hard cash, and that’s why cyberthieves are always looking for ways to steal it. Whether it’s an email address, a credit card number, or even medical records, your personal information is incredibly valuable in the wrong hands.
For hackers, breaking into a company database is like hitting the mother lode, giving them access to millions of personal records. Why? Because whether you know it or not, many companies are collecting and storing your private data. Think about all the information you hand over when you order something online, like your full name, your credit card number, your home address, and maybe even your birthdate just to snag an extra discount. If a company you do business with becomes part of a data breach, cybercriminals may have full access to your confidential information.
Unfortunately, data breaches are on the rise and affecting more companies and consumers than ever. In 2024, more than 1.3 billion people received notices that their information was exposed in a data breach. Chances are you’ve received at least one of these letters, which means you have been put at risk for identity theft and major financial losses.
Data breaches occur when sensitive, protected, or confidential data is hacked or leaked from a company or organization. Sometimes businesses are targeted because they have outdated or weak security. While no industry is immune, some sectors are more likely to become victims of breaches because of the sensitive nature of the data they handle. Here are some of the most likely targets for access to consumer data:
The type of information stolen in data breaches varies depending on the organization, but here’s a list of the kind of data cybercriminals are seeking:
Once data is exposed in a breach, cybercriminals will test your usernames and password combinations across thousands of sites, knowing that most people recycle their emails and passwords. Here are just some of the ways hackers exploit your stolen information:
Data breaches are a fact of life in the digital world we live in, but you can protect yourself with some smart security measures. By using strong passwords, password managers, antivirus software, and identity protection plans, you can reduce your risk of becoming a victim of cybercrime, and even get help to restore your identity, your financial losses and your reputation.
It’s like putting a lock on your personal data. When it comes to your sensitive information, it’s always better to be safe than sorry.
Keeping educational systems secure
How to keep your personal data safe
Protect yourself from identity theft
Safeguarding your devices from malware
The post The danger of data breaches — what you really need to know appeared first on Webroot Blog.
Earlier last week, I ran into a sample that turned out to be PureCrypter, a loader and obfuscator for all different kinds of malware such as Agent Tesla and RedLine.
Upon further investigation, I developed Yara rules for the various stages, which can be found here (excluding the final payload):
With that out of the way, all of this reminded me of the fact that we can also write Yara rules for unique identifiers specific to malware written in .NET, or any other .NET assemblies for that matter.
A bit of history
This isn’t my first encounter with analysing .NET malware at scale: several years ago, I co-authored a presentation with Santiago on hunting SteamStealer malware, which was surging exponentially at the time (the malware intended to steal your Steam inventory items and/or your account). A huge thanks goes to Brian Wallace who had developed a tool at the time called GetNetGUIDs which made it trivial to extract all the GUID types and start clustering to identify patterns: basically, which of the malware samples are likely authored by the same person or belong to the same attack campaign.
.NET assemblies or binaries often contain all sorts of metadata, such as the internal assembly name and GUIDs, specifically; the MVID and TYPELIB.
GUID: Also known as the TYPELIB ID, generated when creating a new project.
MVID: Module Version ID, a unique identifier for a .NET module, generated at build time.
TYPELIB: the TYBELIB version – or number of the type library (think major & minor version).
These specific identifiers can be parsed with the strings command and a simple regular expression (regex): [a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12}
Taking a sample of PureLogStealer posted by James_in_the_box, you could then write a Yara rule based on the MVID or Typelib detected.
As shown on VirusTotal for this sample:
|
| Figure 1 - Sample with MVID 9066ee39-87f9-4468-9d70-b57c25f29a67 |
And the resulting (simple) Yara rule, could then be as follows:
rule PureLogStealer_GUID
{
strings:
$mvid = "9066ee39-87f9-4468-9d70-b57c25f29a67" ascii wide fullword
condition:
$mvid
}
There are however some issues with this:
The MVID is stored as a binary value rather than a string, whereas the Typelib GUID is effectively stored as a string and since we only have the MVID here, the sample above will not be detected with this rule.
It is important to note that VirusTotal does not seem to report the Typelib.
It is cumbersome to “do it the manual way” with strings and regex, especially on larger data sets – and it’s prone to issues such as:
false positives: if you run "strings" on the sample and then use the following CyberChef recipe – we get plenty of GUIDs, but only 1 is the actual Typelib;
false negatives: we miss out on unique identifiers, which means we might miss detection of samples, campaigns or actors.
Note that with tools such as IlSpy or dnSpy(Ex), you can also view the Typelib GUID and MVID, however, not all tools display all data, for example:
|
| Figure 2 - dnSpy detects the Typelib GUID of the sample |
And if we go the "oldschool" route using ildasm:
|
| Figure 3 - ildasm displays the MVID or Module Version ID |
For all the above reasons, let’s go beyond and do more: both with Yara, and with a new Python tool I’ve created.
The now and the tooling
Before we dive into the tooling, some final history to say that Yara has evolved and thanks to that, we can now hunt and detect more effectively due to the following modules added:
This means that using the .NET module, we can now write a Yara rule like so instead:
import "dotnet"
rule PureLogStealer_GUID
{
condition:
dotnet.guids[0]== "9066ee39-87f9-4468-9d70-b57c25f29a67"
}
And indeed:
|
| Figure 4 - Yara now detects the sample |
Yara rule
Let’s now leverage the power of Yara and its dotnet and console modules to write a new Yara rule that displays useful data of any given .NET sample that can be leveraged to create meaningful rules, for example: assembly name, typelib and MVID.
|
| Figure 5 - Yara rule to display .NET information to the console |
We first verify if the binary is a .NET compiled file, if so, log certain Portable Executable (PE) or binary information to the console as well, and then display all relevant .NET information.
And the output will be, again for the same sample:
|
| Figure 6 - Yara rule output: sample metadata! |
Meaning we can now write a rule as follows:
import "dotnet"
rule PureLogStealer_GUID
{
condition:
dotnet.guids[0]=="9066ee39-87f9-4468-9d70-b57c25f29a67" or
dotnet.typelib=="856e9a70-148f-4705-9549-d69a57e669b0"
}
Python tool
But what if we want to run this on a large set of samples and produce statistics, which we can then use to hunt or classify malware families, or cluster campaigns?
A newly developed Python tool will help you do exactly just that. It supports both a single file as well as a whole folder of your samples or malware repository. It will skip over any non-.NET binary and simply report the typelib, MVID and typelib ID (if present, which is seldom the case and rarely useful).
If we run it on our single sample like before:
|
| Figure 7 - New tool output on single sample |
The tool (or script) has the following capabilities:
| |
|
I highly recommend to use the tool rather than the Yara rule, as it detects .NET metadata more reliably. Both Yara rule and Python tool can be adapted to display less or more information according to your needs.
Clustering
Tracking attacker’s campaigns is always an exercise, and can be both fun and exhausting, depending on how many rabbit holes you (want to) go through. An example of clustering campaigns as well as malware developers was done in the work I did with Santiago as mentioned earlier, which resulted in the following graphics:
|
| Figure 9 - Statistics from 2016 research (bonus obfuscation stats) |
This was a pretty large dataset (1.300 samples!) and specific to SteamStealers at the time.
For our analysis purposes, I took 4 of the most current popular malware (that are .NET based or have at least a .NET variant) according to Any.run’s Malware Trends: https://any.run/malware-trends/. These are:
RedLine
Agent Tesla
Quasar
Pure*: basically anything related to PureCrypter, PureLogs, …
Downloading the latest available samples per family from MalwareBazaar, then running my DotNetMetadata Python script, and playing around with pandas and matplot, we can create the following graphs per family:
RedLine – 56 samples
|
| Figure 10 - RedLine Typelib GUID frequency |
| |
|
Agent Tesla – 140 samples
| |
|
| |
|
Quasar – 141 samples
| |
|
|
| Figure 15 -Quasar MVID frequency |
Pure* family - 194 samples
|
| Figure 16 - Pure* Typelib GUID frequency |
|
| Figure 17 -Pure* MVID frequency |
While these piecharts are certainly hypnotic and display the frequency - or occurrence of the same typelib or MVID, we can also leverage these and create meaningful Yara rules for clustering samples per family, especially in the case of Quasar, the MVID with GUID "60f5dce2-4de4-4c86-aa69-383ebe2f504c" appears like a good candidate.
You might think that while these charts look visually appealing (depending on your art preferences), they may not be particularly useful because they don't scale well with larger datasets. You’re exactly right! By limiting the amount of results displayed, we can indeed produce even better results. In our sample dataset for the 4 malware families above, so a total of 531 samples, let’s run our visualisations again and now we will:
Run it on the whole sample set
Extract the assembly name
List only the top 10 of assembly names
Use a bar chart instead of a pie
And the result:
|
| Figure 18 - Assembly name frequency - looking better right? |
The top 3 is then:
“Client”: Quasar family
“Product Design 1”: Pure family
“Sample Design 1”: Pure family
Client is likely the default assembly name when compiling the Quasar malware (project), and Product Design and Sample Design are likely default assembly names from the PureCrypter builder.
If we then want to write a Yara rule for Quasar based on the default assembly name:
import "dotnet"
rule Quasar_AssemblyName
{
condition:
dotnet.assembly.name == "Client"
}
But why stop there? We can build a Yara rule to classify our malware dataset or repository:
import "dotnet"
import "console"
rule DotNet_Malware_Classifier
{
condition:
(dotnet.assembly.name == "Client" and console.log(“Likely Quasar, assembly name: ", dotnet.assembly.name)) or
(dotnet.assembly.name == "Product Design 1" and console.log("Likely Pure family, assembly name: ", dotnet.assembly.name)) or
(dotnet.assembly.name == "Sample Design 1" and console.log("Likely Pure family, assembly name: ", dotnet.assembly.name))
}
And we run this new Yara rule on the combined samples of the Pure family and Quasar:
|
| Figure 19 - Simple "malware classifier" |
We can combine sets of Yara rules bases on assembly name, Typelib, MVID and so on to create rules with a higher confidence, and we can use this in further hunting, classification and... much more.
Bonus
If you’ve made it this far, it only makes sense to add in an additional extra use-case for all of this: finding new crypters or obfuscators!
When I ran the script on the +500 samples, there was 1 assembly / binary that stood out:
|
| Figure 20 - Potential new crypter "Cronos" |
Making a simple Yara rule again:
import "dotnet"
rule cronos_crypter
{
strings:
$cronos = "Cronos-Crypter" ascii wide nocase
condition:
dotnet.is_dotnet and $cronos
}
Running this on the Unpac.me dataset yields:
|
| Figure 21 - Unpac.me Yara hunt results |
4 matches in 12 weeks: it appears this crypter is not popular (yet): 2 Async RAT samples and 2 PovertyStealer samples have used it so far.
Bonus on Bonus
Let’s go with a final bonus round: improving the previous “classification” rule by also reviewing results for Async RAT. Seeing the previous crypter was used on at least 2 Async RAT samples, I wanted to see some statistics for this malware as well, for just the assembly name. This results in the following, based on 86 samples:
| ||
| Figure 22 - Another pie chart: AsyncRat top used assembly names |
Jumping out are the following assembly names:
AsyncClient
Client --> Also seen in Quasar!
XClient
Output
Loader
Stub
AsyncClient is likely the default name when building the Async RAT project. But we are interested in widening the net: from the previous rule DotNet_Malware_Classifier, let’s update it with these new “generic” or default assembly names:
import "dotnet"
import "console"
rule DotNet_Malware_Classifier
{
condition:
(dotnet.assembly.name == "Client" and console.log("Suspicious assembly name: ", dotnet.assembly.name)) or
(dotnet.assembly.name == "Output" and console.log("Suspicious assembly name: ", dotnet.assembly.name)) or
(dotnet.assembly.name == "Loader" and console.log("Suspicious assembly name: ", dotnet.assembly.name)) or
(dotnet.assembly.name == "Stub" and console.log("Suspicious assembly name: ", dotnet.assembly.name))
}
|
| Figure 23 - Classifier Yara rule results |
In this blog post, two new tools were presented to extract metadata from .NET malware samples. Specifically, we can now reliably extract 2 unique GUIDs: the Typelib and the MVID.
The Python script is capable of extracting the desired data from a large set of .NET assemblies, whereas the Yara rule is tailored for use with one particular sample. Of course, either of them can be used interchangeably: you can still fine-tune the Yara rule for a large set and work this way if you don’t want to rely on an external script. Similarly, the script can be extended to extract more data to be used.
Based on the output of these tools, you can then create Yara hunting rules, combine it with your existing rule sets, or use them in an attempt to classify malware families or specific attack campaigns.
Some closing remarks:
GUIDs could be spoofed or even removed. No method is 100% reliable.
However, this method can enhance already existing rulesets, especially those where .NET obfuscators (e.g. SmartAssembly) obfuscate (user) strings, modules and more, making it harder to write Yara rules for a malware family. Detecting based on GUID however, can work regardless of obfuscation method.
That said, obfuscating or deobfuscating may also alter the GUIDs. Keep this in mind when creating your detection rules based on an original or unpacked/deobfuscated sample.
If you encounter a GUID comprised entirely of zeros, such as 00000000-0000-0000-0000-000000000000, avoid using it for hunting since it's an empty GUID. This indicates the value may not be set or has been altered. This would make for a poor hunting rule as it can be a default value for any .NET project.
You can also use this methodology and tooling for .NET assemblies that are not malicious: extract developer information and other metadata per your use case or purpose.
The Python tool in addition, just as the Yara rule, allows for analysing, classifying and hunting on much more .NET (meta)data.
Happy .NET hunting! You can find the tools and some of the example Yara rules in the repository: https://github.com/bartblaze/DotNet-MetaData
As always, feedback is welcomed.
 |
| Figure 1 - Fake SDA website |
 |
| Figure 2 - Sending credentials to steamdesktopauthenticator[.]com |
 |
| Figure 3 - Sending credentials to steamdesktop[.]com |
 |
| Figure 4 - Malicious SDA fork (click to enhance) |
