In the end, the computer turns into an obedient zombie node with remote control.
A new malware program , containing game cheats and cracked versions of popular programs, is distributed through hundreds of fake GitHub repositories. At first glance, the scheme seems straightforward: the victim is tricked into downloading a ZIP archive with a catchy name like "FPS booster," "Skin changer for Counter-Strike 2," or "professional" version of Voicemod. In practice, the chain is significantly more complex. The fake download page conceals a multi-stage delivery process involving C/C++, VBS, and .NET downloaders, a modified Vidar, a separate Golang component, and a Python backdoor that establishes a reverse SSH tunnel and turns the infected system into a remotely controlled host.
Researchers have dubbed the new stealer BoryptGrab . Its core functionality is typical of infostealers, but it's implemented in a more comprehensive manner: it collects data from browsers, desktop crypto wallets, browser extensions, Telegram, and Discord, takes screenshots, scrapes system information, and additionally extracts files with specified extensions from popular directories. Some variants can also download the TunnesshClient backdoor. This backdoor does more than just steal data: it establishes a reverse SSH tunnel, forwards traffic, and can execute operator commands.
The first traces of the campaign date back to 2025. The earliest discovered ZIP archive is dated late 2025, and the first commit in the oldest GitHub account found appeared as early as April 2025. The archive names follow a consistent pattern: they feature popular products, gaming terms, version numbers, and words like "download," "tool," "premium," or "github-io." Examples include fake archives purporting to be Voicemod Pro, Wondershare, cheats for Valorant, Call of Duty, Rainbow Six Siege, and Arena Breakout, as well as less obvious lures like the "git deployer app." A separate layer consists of ZIP files whose names explicitly use the "github-io" combination, which points to the next stage of the chain.
The distribution begins with fake GitHub repositories . The campaign's authors clearly had search engine rankings in mind: the READMEs of many repositories are injected with SEO keywords to rank the fake pages higher in search results. One example, a repository simulating a download for Voicemod Pro, appeared in Google search results almost immediately below the legitimate result. This is enough to infect: a user searches for a free tool, sees a familiar name, and is redirected not to the official website, but to a fake GitHub page.
Next, it begins disguising itself as GitHub's own infrastructure. The malicious README contains a link to a page of the form github.io/.github/, and its code resides in a separate repository disguised as a standard .github directory. Researchers found Russian-language comments on the intermediate HTML page. The logic is simple, yet convenient for attackers: the page takes a hard-coded link from the source code, obtains a Base64 URL from it, decodes the address, and redirects to the next node. The final intermediate site then renders a fake GitHub download page and generates a ZIP archive with malicious content.
The campaign doesn't have a single chain. The authors use multiple delivery routes and vary components. In some repositories, researchers found deleted scripts.js that previously pulled in an intermediate URL and redirected. In others, the JavaScript doesn't simply retrieve the address, but downloads an encrypted link, decrypts it using AES, and only then redirects the user. There are also more recent variants that have added Python scripts that simulate a normal download process. Some pages send tracking data to the operators. In other words, GitHub is being used not as a one-time storefront, but as an entire ecosystem of decoys, redirects, and fake downloaders.
One of the main infection routes relies on DLL sideloading. An executable file is included in the ZIP archive, which loads a substituted libcurl.dll. This scheme is convenient because the program may appear harmless, but the malicious logic is moved to the DLL, which is loaded alongside the application. The substituted library retrieves the payload from its own resource section, then decrypts the launcher payload using XOR and AES in CBC mode, and then calls the exported EntryWrapper function from the decrypted module.
This launcher obfuscates download addresses using XOR obfuscation and then pulls BoryptGrab from the command-and-control server. In some variants, the downloader passes the -b parameter with the assembly name to the stealer. Detected values include Shrek, Sonic, Leon, CryptoByte, Yaropolk, Yarostnick, and others. The assembly names appear to be internal labels used by the operators, likely used to differentiate campaign variants, traffic sources, or target branches. Through another endpoint, the same launcher can retrieve additional EXE files. Researchers have determined that some of these files are obfuscated variants of the Vidar stealer. Another route leads to the PyInstaller component TunnesshClient, and yet another to a Golang downloader named HeaconLoad.
In this scheme, TunnesshClient is established through scheduled tasks. The launcher creates XML files in the %TEMP% directory and uses them to register tasks, which then execute the downloaded PyInstaller backdoor. This mechanism ensures persistence after reboots and eliminates the need for attackers to manually regain control of the machine each time.
The second prominent route is built around a VBS downloader. Some ZIP variants, instead of DLL sideloading, contain a VBS script with junk variables to obfuscate analysis. Strings are hidden in the script as integer arrays, and a function with a short name converts the arrays back to text. The script contains privilege escalation logic and ultimately deploys a Base64-encoded PowerShell payload. After decoding, PowerShell downloads the binary file from an external host and executes it. In some samples, the VBS also adds an exception for Microsoft Defender, preventing the C:\ drive from being scanned by antivirus software. This is a very telling move for an infostealer: the operator doesn't just want to steal data, but also ensure that the artifact collection occurs without being intercepted by security software.
The file downloaded via VBS again turns out to be a launcher component written in C/C++. It accesses the attackers' API via a route like /api/{BUILD_NAME} and receives BoryptGrab. In some chains, the stealer itself downloads TunnesshClient rather than the launcher. This interchangeability complicates detection: in one build, the backdoor appears early on, while in another, it appears only after the data theft is complete.
There are also additional branches. One variant uses a .NET executable with a hidden Base64-encoded VBS loader. This loader, in turn, downloads a binary file from a different address. Other launcher variants work with the /api/app, /api/app.zip, /api/payload, and /api/client2 endpoints. Some ZIP archives even contain HeaconLoad directly, without any intermediate steps. Therefore, the campaign appears not as a single linear set of steps, but rather as a construction set of interchangeable modules.
HeaconLoad, written in Go, is responsible for further delivery. It attaches itself via the Run branch in the registry and via a scheduled task. It then begins sending HTTP POST requests to /healthcheck to the operator server. Each beacon message contains system information and a hardcoded build tag. Among the detected tags were leon, shrek, sonic, yaropolk, yarostnick, yasno, kylka, and voblya. The server responds with the bundle_available and bundle_hash fields. The first flag indicates whether the archive is ready for download, and the second provides a checksum. If the bundle is available, HeaconLoad downloads the ZIP package, unpacks it, and runs the first executable file it finds. Researchers also saw Russian-language messages in the logs of this component.
One of the delivery branches leads to custom Vidar builds. Binaries downloaded via /api/custom_exe?build={BUILD_NAME} retain the characteristic network patterns of this family. They send files like information.txt to the server via HTTP POST and employ several layers of obfuscation: strings are XOR-encrypted, the code contains opaque predicates and redundant blocks, which are not needed for logic but to hinder reverse engineering. Furthermore, this variant dynamically resolves APIs and can perform code injection or APC injection, that is, inject code into other processes or queue its calls to asynchronous thread procedures.
BoryptGrab itself is written in C/C++. It has an --output-path or -o parameter, which specifies the directory for storing collected data. Some builds also support the --build-name parameter, also known as -b. The value is stored in the BUILD NAME field in the UserInformation.txt file. If no argument is passed, some samples use the default name, No_name. Other versions have the build name hardcoded into the binary, and some samples don't even write the BUILD NAME in the report. The recorded labels include neutral options like Data, Leon, Yasno, and CryptoByte, as well as crude internal names, further demonstrating the tool's rudimentary yet active development cycle.
Before its main operation, BoryptGrab checks to see if it's running in a virtual machine. To do this, the samples query registry keys and search for files associated with virtualized environments. Additionally, the stealer checks the list of active processes against a pre-prepared set of names, meaning it tries to detect analysis tools. It then attempts to gain elevated privileges. This combination of anti-VM and anti-analysis is designed to reduce the chances of running in a sandbox and complicate behavioral analysis.
If the operator hasn't manually specified a directory, the stealer automatically generates a directory name for storing artifacts. It includes the current time, public IP address, and country code. The program then begins systematic collection.
Of particular interest is its work with browsers. BoryptGrab collects data from Brave, CentBrowser, Chromium, Google Chrome, Microsoft Edge, Mozilla Firefox, Opera, Vivaldi, and Yandex Browser. For Chromium-based browsers, it uses techniques to bypass Chrome App-Bound Encryption. This is a mechanism that is designed to more tightly bind secrets, such as cookies and saved passwords, to a specific application and system context. The attackers incorporated developments from public GitHub repositories dedicated to bypassing and decrypting App-Bound Encryption into the code. BoryptGrab contains an encrypted resource, PAYLOAD_DLL. After decryption, it contains logic similar to open-source PoC projects, but is supplemented with functions for extracting data from Firefox and Yandex Browser.
To work with browser data, the stealer additionally downloads the helper component x32_chromium.exe to the %TEMP% directory. This auxiliary utility is required for certain operations to extract or decrypt browser artifacts.
In addition to browsers, BoryptGrab targets crypto wallets . The list is extensive: Armory Wallet, Atomic, AtomicDEX, Binance, Bitcoin Core, BitPay, Blockstream Green, Chia Wallet, Coinomi, Copay, Daedalus Mainnet, Dash Core, Dogecoin, Electron Cash, Electrum, ElectrumLTC, Ethereum, Exodus, GreenAddress, Guarda, Jaxx Desktop, Komodo Wallet, Ledger Live, Ledger Wallet, Litecoin Core, MEW Desktop, MyEtherWallet, NOW Wallet, Raven Core, StakeCube, Trezor Suite, Wasabi Wallet, and several others. The stealer searches their directories, attempts to extract their contents, and provides logs, which show that stealing cryptocurrency artifacts was one of the authors' main goals.
Another feature, File Grabber, allows you to collect files with specified extensions from popular directories. The code even contains a spelling error, "Filegraber," which indirectly suggests some poor internal development. However, the feature itself is quite practical: the operator obtains not only passwords, tokens, and wallets, but also documents, spreadsheets, configuration files, backups, and other files that could be useful for further access or extortion.
The collection doesn't stop there. BoryptGrab can grab Telegram files, extract browser passwords, and, in newer versions, even harvest Discord tokens. Once complete, everything is archived and sent to the attackers' server.
The most dangerous module in the entire bundle is TunnesshClient, written in Python and packaged in PyInstaller. Its primary purpose isn't theft, but rather the creation of a remote control channel. The component first contacts the operator's server via the routes /api/get_challenge and /api/get_credentials. The server issues a challenge, the client calculates the SHA256 hash, receives an encrypted response, and decrypts the JSON with SSH credentials. The program then sends system information to /api/get_port, obtains the port number for forwarding, and creates an SSH tunnel .
A reverse SSH tunnel essentially reverses the standard access model. Instead of the operator connecting directly to the victim's machine, the infected system itself establishes an SSH connection to the attacker's server and opens a channel through which the operator then logs in. This approach is particularly useful for bypassing NAT, proxies, and some network filters: the connection originates from the victim's machine and often appears less suspicious than an incoming connection.
Once the tunnel is established, TunnesshClient can execute a set of commands based on numeric operation codes. One code enables SOCKS5 proxy mode, another runs a shell command, and other codes allow file listing, sending the victim's file in Base64 format, writing a file to the machine, searching for files on request, and sending an entire folder as a ZIP archive, also in Base64 format. In other words, the operator receives not just a communication channel, but a nearly complete mini-toolkit for interactive work with the infected system.
There's also a second variant of TunnesshClient. It operates differently: it sets up a local SSH server directly on the victim's machine, then sends the username and password to the operator via HTTP POST. It can then forward traffic to the local SSH service. This variant supports fewer commands and essentially boils down to proxying and local SSH forwarding, but for an attacker, this is sufficient to establish a foothold and move forward manually.
Researchers have repeatedly noted Russian-language traces throughout the chain: HTML comments, binary logs, error messages, and individual infrastructure features. None of this automatically proves the operator's origins, but it does provide grounds for cautious consideration of a likely Russian-language development environment or, at a minimum, Russian-speaking participants in the campaign.
BoryptGrab's key feature isn't any single exotic technique, but rather a combination of several effective approaches. The authors use GitHub as a showcase and SEO lure, spoof the download path via github.io, generate malicious ZIP archives on the fly, alternate between VBS, .NET, C/C++, and Go components, add a browser security bypass, move some of the logic to encrypted resources, and, if necessary, enable a backdoor with a reverse SSH tunnel. For the user, it all starts with the simple desire to download a "free tool." For the attacker, such a click can result in the theft of passwords, crypto wallets, documents, and the establishment of persistent remote access.
A new malware program , containing game cheats and cracked versions of popular programs, is distributed through hundreds of fake GitHub repositories. At first glance, the scheme seems straightforward: the victim is tricked into downloading a ZIP archive with a catchy name like "FPS booster," "Skin changer for Counter-Strike 2," or "professional" version of Voicemod. In practice, the chain is significantly more complex. The fake download page conceals a multi-stage delivery process involving C/C++, VBS, and .NET downloaders, a modified Vidar, a separate Golang component, and a Python backdoor that establishes a reverse SSH tunnel and turns the infected system into a remotely controlled host.
Researchers have dubbed the new stealer BoryptGrab . Its core functionality is typical of infostealers, but it's implemented in a more comprehensive manner: it collects data from browsers, desktop crypto wallets, browser extensions, Telegram, and Discord, takes screenshots, scrapes system information, and additionally extracts files with specified extensions from popular directories. Some variants can also download the TunnesshClient backdoor. This backdoor does more than just steal data: it establishes a reverse SSH tunnel, forwards traffic, and can execute operator commands.
The first traces of the campaign date back to 2025. The earliest discovered ZIP archive is dated late 2025, and the first commit in the oldest GitHub account found appeared as early as April 2025. The archive names follow a consistent pattern: they feature popular products, gaming terms, version numbers, and words like "download," "tool," "premium," or "github-io." Examples include fake archives purporting to be Voicemod Pro, Wondershare, cheats for Valorant, Call of Duty, Rainbow Six Siege, and Arena Breakout, as well as less obvious lures like the "git deployer app." A separate layer consists of ZIP files whose names explicitly use the "github-io" combination, which points to the next stage of the chain.
The distribution begins with fake GitHub repositories . The campaign's authors clearly had search engine rankings in mind: the READMEs of many repositories are injected with SEO keywords to rank the fake pages higher in search results. One example, a repository simulating a download for Voicemod Pro, appeared in Google search results almost immediately below the legitimate result. This is enough to infect: a user searches for a free tool, sees a familiar name, and is redirected not to the official website, but to a fake GitHub page.
Next, it begins disguising itself as GitHub's own infrastructure. The malicious README contains a link to a page of the form github.io/.github/, and its code resides in a separate repository disguised as a standard .github directory. Researchers found Russian-language comments on the intermediate HTML page. The logic is simple, yet convenient for attackers: the page takes a hard-coded link from the source code, obtains a Base64 URL from it, decodes the address, and redirects to the next node. The final intermediate site then renders a fake GitHub download page and generates a ZIP archive with malicious content.
The campaign doesn't have a single chain. The authors use multiple delivery routes and vary components. In some repositories, researchers found deleted scripts.js that previously pulled in an intermediate URL and redirected. In others, the JavaScript doesn't simply retrieve the address, but downloads an encrypted link, decrypts it using AES, and only then redirects the user. There are also more recent variants that have added Python scripts that simulate a normal download process. Some pages send tracking data to the operators. In other words, GitHub is being used not as a one-time storefront, but as an entire ecosystem of decoys, redirects, and fake downloaders.
One of the main infection routes relies on DLL sideloading. An executable file is included in the ZIP archive, which loads a substituted libcurl.dll. This scheme is convenient because the program may appear harmless, but the malicious logic is moved to the DLL, which is loaded alongside the application. The substituted library retrieves the payload from its own resource section, then decrypts the launcher payload using XOR and AES in CBC mode, and then calls the exported EntryWrapper function from the decrypted module.
This launcher obfuscates download addresses using XOR obfuscation and then pulls BoryptGrab from the command-and-control server. In some variants, the downloader passes the -b parameter with the assembly name to the stealer. Detected values include Shrek, Sonic, Leon, CryptoByte, Yaropolk, Yarostnick, and others. The assembly names appear to be internal labels used by the operators, likely used to differentiate campaign variants, traffic sources, or target branches. Through another endpoint, the same launcher can retrieve additional EXE files. Researchers have determined that some of these files are obfuscated variants of the Vidar stealer. Another route leads to the PyInstaller component TunnesshClient, and yet another to a Golang downloader named HeaconLoad.
In this scheme, TunnesshClient is established through scheduled tasks. The launcher creates XML files in the %TEMP% directory and uses them to register tasks, which then execute the downloaded PyInstaller backdoor. This mechanism ensures persistence after reboots and eliminates the need for attackers to manually regain control of the machine each time.
The second prominent route is built around a VBS downloader. Some ZIP variants, instead of DLL sideloading, contain a VBS script with junk variables to obfuscate analysis. Strings are hidden in the script as integer arrays, and a function with a short name converts the arrays back to text. The script contains privilege escalation logic and ultimately deploys a Base64-encoded PowerShell payload. After decoding, PowerShell downloads the binary file from an external host and executes it. In some samples, the VBS also adds an exception for Microsoft Defender, preventing the C:\ drive from being scanned by antivirus software. This is a very telling move for an infostealer: the operator doesn't just want to steal data, but also ensure that the artifact collection occurs without being intercepted by security software.
The file downloaded via VBS again turns out to be a launcher component written in C/C++. It accesses the attackers' API via a route like /api/{BUILD_NAME} and receives BoryptGrab. In some chains, the stealer itself downloads TunnesshClient rather than the launcher. This interchangeability complicates detection: in one build, the backdoor appears early on, while in another, it appears only after the data theft is complete.
There are also additional branches. One variant uses a .NET executable with a hidden Base64-encoded VBS loader. This loader, in turn, downloads a binary file from a different address. Other launcher variants work with the /api/app, /api/app.zip, /api/payload, and /api/client2 endpoints. Some ZIP archives even contain HeaconLoad directly, without any intermediate steps. Therefore, the campaign appears not as a single linear set of steps, but rather as a construction set of interchangeable modules.
HeaconLoad, written in Go, is responsible for further delivery. It attaches itself via the Run branch in the registry and via a scheduled task. It then begins sending HTTP POST requests to /healthcheck to the operator server. Each beacon message contains system information and a hardcoded build tag. Among the detected tags were leon, shrek, sonic, yaropolk, yarostnick, yasno, kylka, and voblya. The server responds with the bundle_available and bundle_hash fields. The first flag indicates whether the archive is ready for download, and the second provides a checksum. If the bundle is available, HeaconLoad downloads the ZIP package, unpacks it, and runs the first executable file it finds. Researchers also saw Russian-language messages in the logs of this component.
One of the delivery branches leads to custom Vidar builds. Binaries downloaded via /api/custom_exe?build={BUILD_NAME} retain the characteristic network patterns of this family. They send files like information.txt to the server via HTTP POST and employ several layers of obfuscation: strings are XOR-encrypted, the code contains opaque predicates and redundant blocks, which are not needed for logic but to hinder reverse engineering. Furthermore, this variant dynamically resolves APIs and can perform code injection or APC injection, that is, inject code into other processes or queue its calls to asynchronous thread procedures.
BoryptGrab itself is written in C/C++. It has an --output-path or -o parameter, which specifies the directory for storing collected data. Some builds also support the --build-name parameter, also known as -b. The value is stored in the BUILD NAME field in the UserInformation.txt file. If no argument is passed, some samples use the default name, No_name. Other versions have the build name hardcoded into the binary, and some samples don't even write the BUILD NAME in the report. The recorded labels include neutral options like Data, Leon, Yasno, and CryptoByte, as well as crude internal names, further demonstrating the tool's rudimentary yet active development cycle.
Before its main operation, BoryptGrab checks to see if it's running in a virtual machine. To do this, the samples query registry keys and search for files associated with virtualized environments. Additionally, the stealer checks the list of active processes against a pre-prepared set of names, meaning it tries to detect analysis tools. It then attempts to gain elevated privileges. This combination of anti-VM and anti-analysis is designed to reduce the chances of running in a sandbox and complicate behavioral analysis.
If the operator hasn't manually specified a directory, the stealer automatically generates a directory name for storing artifacts. It includes the current time, public IP address, and country code. The program then begins systematic collection.
Of particular interest is its work with browsers. BoryptGrab collects data from Brave, CentBrowser, Chromium, Google Chrome, Microsoft Edge, Mozilla Firefox, Opera, Vivaldi, and Yandex Browser. For Chromium-based browsers, it uses techniques to bypass Chrome App-Bound Encryption. This is a mechanism that is designed to more tightly bind secrets, such as cookies and saved passwords, to a specific application and system context. The attackers incorporated developments from public GitHub repositories dedicated to bypassing and decrypting App-Bound Encryption into the code. BoryptGrab contains an encrypted resource, PAYLOAD_DLL. After decryption, it contains logic similar to open-source PoC projects, but is supplemented with functions for extracting data from Firefox and Yandex Browser.
To work with browser data, the stealer additionally downloads the helper component x32_chromium.exe to the %TEMP% directory. This auxiliary utility is required for certain operations to extract or decrypt browser artifacts.
In addition to browsers, BoryptGrab targets crypto wallets . The list is extensive: Armory Wallet, Atomic, AtomicDEX, Binance, Bitcoin Core, BitPay, Blockstream Green, Chia Wallet, Coinomi, Copay, Daedalus Mainnet, Dash Core, Dogecoin, Electron Cash, Electrum, ElectrumLTC, Ethereum, Exodus, GreenAddress, Guarda, Jaxx Desktop, Komodo Wallet, Ledger Live, Ledger Wallet, Litecoin Core, MEW Desktop, MyEtherWallet, NOW Wallet, Raven Core, StakeCube, Trezor Suite, Wasabi Wallet, and several others. The stealer searches their directories, attempts to extract their contents, and provides logs, which show that stealing cryptocurrency artifacts was one of the authors' main goals.
Another feature, File Grabber, allows you to collect files with specified extensions from popular directories. The code even contains a spelling error, "Filegraber," which indirectly suggests some poor internal development. However, the feature itself is quite practical: the operator obtains not only passwords, tokens, and wallets, but also documents, spreadsheets, configuration files, backups, and other files that could be useful for further access or extortion.
The collection doesn't stop there. BoryptGrab can grab Telegram files, extract browser passwords, and, in newer versions, even harvest Discord tokens. Once complete, everything is archived and sent to the attackers' server.
The most dangerous module in the entire bundle is TunnesshClient, written in Python and packaged in PyInstaller. Its primary purpose isn't theft, but rather the creation of a remote control channel. The component first contacts the operator's server via the routes /api/get_challenge and /api/get_credentials. The server issues a challenge, the client calculates the SHA256 hash, receives an encrypted response, and decrypts the JSON with SSH credentials. The program then sends system information to /api/get_port, obtains the port number for forwarding, and creates an SSH tunnel .
A reverse SSH tunnel essentially reverses the standard access model. Instead of the operator connecting directly to the victim's machine, the infected system itself establishes an SSH connection to the attacker's server and opens a channel through which the operator then logs in. This approach is particularly useful for bypassing NAT, proxies, and some network filters: the connection originates from the victim's machine and often appears less suspicious than an incoming connection.
Once the tunnel is established, TunnesshClient can execute a set of commands based on numeric operation codes. One code enables SOCKS5 proxy mode, another runs a shell command, and other codes allow file listing, sending the victim's file in Base64 format, writing a file to the machine, searching for files on request, and sending an entire folder as a ZIP archive, also in Base64 format. In other words, the operator receives not just a communication channel, but a nearly complete mini-toolkit for interactive work with the infected system.
There's also a second variant of TunnesshClient. It operates differently: it sets up a local SSH server directly on the victim's machine, then sends the username and password to the operator via HTTP POST. It can then forward traffic to the local SSH service. This variant supports fewer commands and essentially boils down to proxying and local SSH forwarding, but for an attacker, this is sufficient to establish a foothold and move forward manually.
Researchers have repeatedly noted Russian-language traces throughout the chain: HTML comments, binary logs, error messages, and individual infrastructure features. None of this automatically proves the operator's origins, but it does provide grounds for cautious consideration of a likely Russian-language development environment or, at a minimum, Russian-speaking participants in the campaign.
BoryptGrab's key feature isn't any single exotic technique, but rather a combination of several effective approaches. The authors use GitHub as a showcase and SEO lure, spoof the download path via github.io, generate malicious ZIP archives on the fly, alternate between VBS, .NET, C/C++, and Go components, add a browser security bypass, move some of the logic to encrypted resources, and, if necessary, enable a backdoor with a reverse SSH tunnel. For the user, it all starts with the simple desire to download a "free tool." For the attacker, such a click can result in the theft of passwords, crypto wallets, documents, and the establishment of persistent remote access.
