Welcome back, aspiring cyberwarriors!
Lately, we’ve covered several tools you can use with your laptop to track nearby devices and people. While they’re useful, their effectiveness depends on the strength of your Bluetooth adapter, and, of course, you need to have your laptop with you.
This time, we’re doing things differently. We want to show you a device that can automatically monitor nearby devices for extended periods, anywhere you choose to place it, and as often as you want. It doesn’t rely solely on Bluetooth, as it also uses Wi-Fi, which is far more likely to be enabled, increasing the chances of detecting someone in your area.
Paxcounter is an open-source firmware project that takes a cheap little ESP32 development board and turns it into a sensor that can count people. Almost every smartphone in the world is constantly sending out small Wi-Fi signals, called probe requests, and Bluetooth signals too, even when the phone is not connected to anything. Paxcounter listens for these signals in the air. It counts how many different devices it hears during each scan, and from that, it can tell you a real time estimate of how many people are nearby.
The project started out as a simple way to measure how many passengers or pedestrians pass through a certain spot. But over time, it grew into something much bigger. Now it works as a general purpose IoT platform, built on hardware that usually costs somewhere between $10 and $30. Besides its main job of counting Wi-Fi and Bluetooth devices, a Paxcounter can also read environmental sensors, track its GPS position, keep accurate time, and send all of that data out through LoRaWAN, MQTT, a local serial connection, or straight onto an SD card.
The way Paxcounter counts people is simple, but it was clearly built with privacy in mind from the very start. Every scan cycle, which lasts 60 seconds by default, the device switches its Wi-Fi and Bluetooth radios into scanning mode and listens for probe requests and advertisement packets coming from nearby devices. Each of these packets carries a MAC address. Paxcounter takes just the last two bytes of that address and turns them into a short, temporary ID. This ID is only used to check for duplicates during that one scan cycle. Once the cycle ends, the count of unique IDs gets sent out, and the whole list is wiped from memory. The firmware also does not try to fingerprint any device. It never tries to figure out a phone’s brand, its operating system, or who owns it. All it wants to know is whether that device has already been counted in the current window.
This scan and clear cycle just keeps repeating, either nonstop or on a schedule if deep sleep power saving is turned on. The results, which include the Wi-Fi count, the Bluetooth count, and sometimes live sensor readings too, get packed into a small payload and sent out through whatever channel the device is set up to use. One thing worth knowing is that Wi-Fi and Bluetooth scanning actually share the same 2.4 GHz radio hardware on the ESP32. So running both scans at the same time slightly lowers the accuracy of each one. Because of that, the project’s own advice is to split Wi-Fi only counting and Bluetooth only counting across two separate devices whenever the best possible accuracy is needed for both.
Paxcounter comes with a hardware abstraction layer and its own pin mapping files for dozens of ESP32 and ESP32-S3 boards. These come from well known manufacturers like LILYGO and TTGO, Heltec, Pycom, WeMos, M5Stack, and Adafruit, and there is also a generic template ready for boards that are not officially supported yet. LILYGO even sells a ready-made board called Paxcounter LoRa, built specifically to run this firmware.
Depending on which board you pick, your device can end up supporting a LoRaWAN radio for sending data over long distances while using very little power, an OLED status screen, or a single color, RGB, or larger LED matrix light to show status. It can also support a physical button for flipping through display pages or sending an alarm message, battery voltage monitoring, GPS positioning, a real time clock chip along with IF482 or DCF77 time telegram output, and even an SD card slot for logging data locally when there is no network around.
Because the whole system was designed to be truly portable, the documentation goes into real detail about power draw, which usually sits somewhere between 450 and 1000 milliwatts depending on how the device is set up. It also makes good use of the ESP32’s deep sleep mode, so a device can keep running for a long stretch of time on just one 18650 lithium ion battery cell. Members of the community have already shared several 3D printable enclosure designs on Thingiverse for the more popular boards.
Paxcounter is built using PlatformIO instead of the plain Arduino IDE. This choice lets it work smoothly with editors like Visual Studio Code, Atom, or Eclipse, and it gives the project reproducible, script driven builds. In fact, the repository runs an automated PlatformIO build check every single time the code changes, using GitHub Actions, and there is even a CodeFactor badge that keeps an eye on ongoing code quality.
The configuration is intentionally spread across a handful of different files instead of being crammed into just one. This keeps board specific settings, behavioral settings, and personal settings nicely separated from each other. The platformio.ini file is where you select which board’s hardware profile you want to compile against. The paxcounter.conf file handles behavioral settings, things like how long a scan cycle lasts, sleep timing, and payload options. The shared lmic_config.h file sets the LoRaWAN region and frequency plan, so it matches the rules where you live. The shared loraconf.h file holds the device’s LoRaWAN join credentials, and the project recommends using OTAA rather than ABP for this. And the shared ota.conf file stores the Wi-Fi credentials the device uses for over the air firmware updates.
You can upload firmware the traditional way, over USB, or once a device has joined a LoRaWAN network, you can push updates over the air instead. A remote command tells the board to connect to Wi-Fi, check a hosted repository called PAX.express for a newer build, and then download and flash it automatically. If anything goes wrong during that process, it will roll back to the previous version on its own. Devices can also be set up to open a small local web based bootstrap menu right when they power on, which lets you upload a firmware file manually, even from a phone in tethering mode, without needing PlatformIO installed on site.
Beyond just picking a board, Paxcounter gives you a long list of settings you can tune to fit your needs. It can log environmental data from sensors like the Bosch BMP180, BME280, BMP280, or BME680, read a Nova SDS011 particulate matter sensor to track dust in the air, and keep accurate time using either a DS3231 real time clock or a connected GPS module.
On boards that come with an OLED display, Paxcounter shows live status information you can cycle through with a short press of the button. This includes the current pax count, meaning the people count, a histogram of recent activity, GPS status, environmental sensor readings, and the time of day.
A long press of that same button sends an alarm message out over the network instead, which is a simple way to flag a problem from out in the field without needing any other kind of interface. Even on boards that do not have a display at all, a status LED still tells you what the device is doing through its blink pattern. You get a brief flash whenever a new Wi-Fi or Bluetooth device is spotted, a quick blink while the device is joining the LoRaWAN network, a short blink during data transmission, and a slow, long blink if there is a LoRaWAN stack error. Boards that have an RGB LED get a color coded version of these same signals.
Once a Paxcounter has counted the people nearby and packed everything into a message, that data has to go somewhere so you can actually see it. How that happens depends on which output the device is using, and the good news is you can turn on more than one at the same time. If you are using LoRaWAN, which is the most common setup, the device does not send the data straight to you. Instead, a nearby LoRaWAN gateway picks up the signal first and forwards it on to a network server, usually The Things Stack. There is a small decoder script included with the project, and its job is to take that raw message and turn it into numbers you can actually read, something like a pax count of 14. From there, The Things Stack can pass the data along to your own app or dashboard using MQTT or a webhook, or you can simply watch it come in live through the built in console.
If a board does not have LoRa hardware built in, it can just skip the gateway completely and send that same kind of data straight to an MQTT service over Wi-Fi instead. You can also connect the device to a computer using a USB cable and read the numbers directly from a serial connection. This is a simple way to test things out without needing to set up a network at all. If SD card logging is turned on, everything also gets saved locally as a CSV file, so you can pull the card out later and open it up in a spreadsheet. This comes in handy in places where there is no network coverage to rely on.
Because a single Paxcounter device is cheap to build and can be left running unattended for a long time, you will find it popping up in a pretty wide range of places. Retailers and shopping centers use it to measure foot traffic without needing to install cameras. Event organizers use it to watch how crowds move around a venue in real time. Pentesters can get a passive read on how many Wi-Fi and Bluetooth devices are active in a building, or to notice unexpected devices showing up where they shouldn’t, all without needing camera access or network credentials.
Since Paxcounter’s whole job involves listening to wireless traffic, its documentation is unusually upfront about the legal side of things. It points out that sniffing Wi-Fi and Bluetooth MAC addresses may be regulated or restricted depending on where you live, and it links to specific starting references for the US, the UK, the Netherlands and the EU, and Germany. It also makes clear that the legal responsibility for how a device is built and deployed falls on the person doing it, especially for public deployments where the results might get published somewhere. On the technical side of privacy, the project’s own design actually holds up pretty well against that legal backdrop. Identifiers are only ever built from the last two bytes of a scanned MAC address, they are kept in memory just for the length of one scan cycle, and then they are discarded completely. No MAC addresses or identifiers are ever sent out over the network, and the firmware does not do any extra tracking or fingerprinting of the devices it scans.
What really makes Paxcounter stand out is not any single feature on its own. It is the whole combination working together. One piece of open source firmware supports dozens of cheap boards, runs for a long time on a small battery, counts people without saving anything identifying about them, doubles as a general environmental sensor node, speaks LoRaWAN, MQTT, serial, and SD card all at once, and can be fully reconfigured from a distance once it is out in the field. The full source code, the complete board list, and all the documentation are available on GitHub.
If you enjoy experimenting with frequencies and trying new things, we recommend signing up for our SDR for Hackers training. With Master OTW, you’ll learn how to use your computer and inexpensive SDR hardware to explore and hack a wide range of radio signals.
The post SDR (Signals Intelligence) for Hackers: Tracking People with ESP32-Paxcounter first appeared on Hackers Arise.
Recently, our teams in Latin America investigated a series of incidents involving misconfiguration, the deployment of BitLocker, and the exploitation of corporate printers. Attackers used the devices to notify organizations that their infrastructure had been compromised and they had to pay a ransom to recover their data.
This article analyzes two incidents that occurred in June in Colombia and in May in Mexico. We highlight the similarities in the attackers’ communications and outline emerging trends in ransom amounts.
In both cases, the affected users initially noticed a padlock icon next to their drives in Windows Explorer. This indicated that the drive was encrypted with BitLocker, blocking access to its contents.
Drive icon indicating that the drive is locked
A recovery key was required to unlock the drive.
Attempt to access the disk’s contents and the prompt for the BitLocker recovery key
This is not the first time we have seen such threats; a few years ago, our team discovered a threat known as ShrinkLocker, which utilized BitLocker to achieve its goals.
One of the incidents occurred in Colombia in June. The attackers exploited an internet-exposed RDP service on a machine connected to an 8 TB storage device containing mission-critical data. After taking control of the system and manipulating user credentials, the attackers enabled BitLocker exclusively on the drive that primarily stored financial data. Once the encryption was complete, they locked the drive and used the company’s printers to produce ransom notes.
Ransomware note
Unfortunately, it was not possible to obtain evidence in the case due to the company’s rush to restore the encrypted disk. The communication with the attackers revealed a demand for just $3,000, and the company considered paying the ransom. After that, the system was restored before the forensic team could take any action, eliminating the evidence needed to assess the incident.
Attacker’s reply to the victim’s email sent to the address in the printed ransom note
This attack was made possible by an internet-facing remote desktop service (RDP) with additional open ports, which employees used to access corporate information. By exploiting this network exposure and misconfiguration, attackers breached the system, identified an additional drive, and leveraged BitLocker to encrypt the data and demand a ransom payment. Leaving RDP ports open without proper security controls jeopardizes the security of systems and information, as highlighted in the our “Global Report: Anatomy of a Cyber World“.
Exposed ports identified in the system in recent months
The company confirmed that, due to compatibility issues with applications required for operation, EPP (Endpoint Protection Platform) protection was disabled on the system, making it easier for attackers to validate, enumerate, and execute applications without revealing malicious activity to central monitoring systems.
In another incident, which occurred in Mexico in May, our team identified how the threat actor gained initial access to the infrastructure. They exploited a misconfigured MSSQL service. This allowed them to execute commands on the system after obtaining the database login credentials from code insecurely published on GitHub.
XEntry team attack
In this incident, the attack began three months prior to detection, with the intruder discovering and verifying their access to the environment. After confirming their access and privilege level within the MSSQL server settings, which extended beyond the DBMS to the underlying operating system, the attackers initially focused on manipulating certain aspects of the web server configuration on the same system. They lowered the server’s security settings and created web shell files in the publicly accessible folders. Many of these attempts to manipulate the service or create malicious files were contained by existing EPP security controls, but despite the alerts, the necessary investigation to address the activity was not conducted.
Commands executed when attempting to manipulate the web server
The attackers subsequently confirmed their ability to execute commands locally and set up their attack infrastructure to transmit data via a communications bridge. By exploiting the MSSQL service, they gained access to each of the organization’s internal systems.
The database engine used by the company was Microsoft SQL Server 2019.0150.2160.04, misconfigured to allow operating system сommand execution via the xp_cmdshell extended stored procedure.
Due to this misconfiguration of an internet-exposed service, the attackers established a channel capable of executing any type of command directed at the server and the local infrastructure within its scope.
Attack path
One of the main objectives was to identify shared systems and resources that provided access to critical information. Our analysis confirmed the attackers’ access to systems storing configuration parameters for networking, enterprise management, and cloud services, among others.
A subset of the critical information identified and collected by the attackers
In early May, the attackers focused on running additional scans and deploying ManageEngine’s Endpoint Central RMM (Remote Monitoring and Management) to establish persistence and begin the final stages of their intrusion.
Scanning and RMM deployment
Further RMM-type applications, such as Mesh Agent and Tactical RMM, were installed in the days that followed. These were used to deploy scheduled tasks responsible for enabling the BitLocker service and individually encrypting the infrastructure’s disks, generating a key for each encrypted system.
Commands executed through RMM tools to collect Bitlocker keys
Finally, in mid-May, the attackers managed to execute a Group Policy Object (GPO) used to deploy activation and encryption tasks, as well as other policies responsible for continued deployment of RMM applications via scheduled tasks. The activity initially targeted critical systems but later spread to every system synchronized with the domain controller. Users became aware of the attack when their machines displayed a blue screen with the message “Hacked by XEntry Team”, and their credentials stopped working to access their systems.
A few hours later, ransom notes began emerging from office printers.
Ransom note printed by the XEntry team
These cases confirm that adversary’s objective is to gain access to infrastructure while avoiding investment in or partnership with ransomware groups. Instead, they leverage built-in Microsoft tools to facilitate data encryption and ransom payments. Monitoring and centralizing logs on protected resources, as well as promptly managing alerts, are critical to countering this type of intrusion.
“As a guarantee, we have no negative online reviews about non-fulfillment of our obligations…” (Ransom note from the first case)
“Our reputation is the guarantee that all content will be fulfilled…” (Ransom note from the second case)
Our teams continue to monitor these threats.
Welcome back, aspiring cyberwarriors!
If you’ve spent any time hunting through vulnerability databases, you may have noticed a recurring trend involving a certain brand of budget networking gear. Tenda routers appear time and again, not because researchers have it in for the company, but because of persistent, systemic security failures that remain largely unaddressed. These issues have almost turned Tenda into a textbook example of what not to do when it comes to product security management.
In this article, we’ll explore the reasons behind Tenda’s notorious reputation, examine the modern threats posed by their devices, and dive into a practical lab to exploit one of their information-disclosure vulnerabilities. Let’s get rolling!
Tenda is a Chinese manufacturer of networking hardware, primarily recognized for offering budget-friendly equipment for home and small business networking. Their product lineup includes wireless routers, range extenders, network switches, and IP cameras.
At first glance, you might overlook Tenda as just a small Chinese company without significant influence. However, a quick search on Shodan reveals an entirely different story.
There are over 12,000 hosts that could potentially serve as gateways for both the Chinese government and hackers worldwide to access various networks.
To understand the issues with Tenda, it’s essential to recognize a troubling pattern of behavior rather than focusing on a single vulnerability. When Carnegie Mellon’s CERT/CC identifies a significant backdoor in the firmware of several router models and reaches out to Tenda for a coordinated disclosure, one might expect a company of Tenda’s stature to acknowledge the issue and take steps toward a resolution. Unfortunately, that hasn’t been the case. CERT/CC’s recent advisory on this backdoor reveals that Tenda has remained silent since they were contacted in May 2026, with no patches released for any of the five affected router models.
This isn’t just a one-off incident. Back in 2020, researchers from Independent Security Evaluators discovered a hardcoded telnet password embedded in the Tenda AC15 AC1900. They notified the company and waited nearly double the standard 90-day disclosure period without receiving a response, ultimately publishing their findings without any acknowledgment from Tenda. If you look even further back to 2013, you’ll find a security researcher documenting a LAN-side backdoor in the Tenda W302R and W330R routers, which was also never patched. When a company remains unresponsive for over a decade and across multiple hardware iterations, it indicates a fundamental flaw in its business model rather than just a series of mistakes.
The scale of Tenda’s problems becomes even clearer when looking at firmware analysis studies instead of individual disclosures. Research scanning extensive batches of Tenda firmware images has revealed that nearly one in five contain hardcoded default credentials or even empty passwords embedded directly in the binary. This isn’t a rare oversight; rather, it points to a recurring design choice made across an entire line of products. When you combine this statistic with a vendor that ignores security disclosures, it means Tenda is, in effect, distributing routers that come pre-loaded with vulnerable access points, easily exploitable by anyone who knows where to look.
A particularly egregious example is CVE-2026-11405. This vulnerability deserves special attention due to the way it undermines the basic principles of router security. It resides within the login function of the httpd web server binary that runs on several router models. Typically, when a user submits a password, the router checks it using MD5-based verification. However, if this check fails, instead of simply rejecting the login attempt, the code unwittingly falls through to a second, undocumented authentication route. It retrieves a hidden configuration value called sys.rzadmin.password and directly compares it in plaintext to the password submitted by the attacker. If they match, the router grants administrative access at role level two, and critically, the username input during this attempt isn’t validated at all. This means that any username coupled with the correct backdoor password gains access.
Consider the implications for an average user who has followed all the right steps. You purchase the router, log into the web interface, and change the default admin password to a strong, unique one, just as every security guide advises. Unfortunately, none of that matters here since the backdoor password exists entirely outside the interface that you interacted with. It is stored in the device’s configuration, hidden from any user-facing menu and unaffected by any password changes you make through the regular admin panel. The only way to eliminate this risk is through a complete firmware rewrite from the vendor, and as of now, Tenda has provided no indication that such an update is forthcoming.
Backdoors aren’t the only serious vulnerability affecting this ecosystem. CVE-2026-36794 targets the Tenda W3 router and highlights a stack-based buffer overflow that an unauthenticated remote attacker can exploit simply by sending a specially crafted HTTP request.
There’s no need for a login or any user interaction; the attacker just requires network access to the device’s web interface. The consequence is a device crash, leading to a straightforward denial of service.
Now, let’s dive right in. While the recent backdoor vulnerability we discussed is certainly eye-catching for 2026, today we will focus on an older issue: CVE-2020-35391, which affects the Tenda N300. I have chosen this example intentionally, as it highlights a troubling trend within Tenda, specifically the consistent shipping of exploitable authentication flaws.
The issue lies in how the router manages configuration backup requests. Normally, an authenticated administrator can easily request a copy of the device’s configuration file for backup by accessing an endpoint at cgi-bin/DownloadCfg/RouterCfm.cfg. The problem arises because this endpoint fails to properly enforce authentication before releasing the file. An attacker can simply send a direct request to that endpoint and sometimes gain access to the complete configuration file. Once you have that configuration file, open it up and find the line labeled extend_pass.
That single line contains the administrative password for the router’s web interface, made accessible without any login credentials. From here, exploiting this vulnerability is straightforward. Just take that password, navigate to the router’s usual login page, and authenticate as the administrator. You will then have full control over the device, including its DNS settings, port forwarding rules, and every device connected behind it.
These days, Tenda hardware remains quite popular in various countries due to its affordability. However, we must be more cautious about security, as overlooking it could lead to significantly higher long-term costs.
If you’re interested in exploring how to both attack and secure routers, consider enrolling in the VPN & Router Hacking course. This course delves into router exploitation through manual RCE (Remote Code Execution), information disclosure, and unauthorized code execution on devices like Netgear, Netis, and Telesquare, as well as enterprise-grade systems like FortiPAM and FortiSwitchManager – and much more.
The post Router Hacking: Why the World’s Most Popular Budget Router Keeps Making Headlines for the Wrong Reasons first appeared on Hackers Arise.
Completed another Hack The Box machine focused on Active Directory exploitation and privilege escalation.
The attack involved SMB enumeration, credential discovery through log analysis, Kerberos authentication, Shadow Credentials abuse, and DLL hijacking to gain user-level access. Further enumeration revealed a WSUS infrastructure weakness, allowing exploitation through Kerberos delegation abuse, certificate-based authentication, and a WSUS machine-in-the-middle attack to achieve Domain Admin privileges. This challenge strengthened my understanding of modern AD attack paths, Kerberos abuse techniques, and enterprise infrastructure security.
#HackTheBox #HTB #CyberSecurity #ActiveDirectory #RedTeam #PenetrationTesting #OffensiveSecurity #EthicalHacking #InfoSec …
Learn MoreHack The Box: Logging Machine Walkthrough – Medium Difficulty
The post Hack The Box: Logging Machine Walkthrough – Medium Difficulty appeared first on Threatninja.net.
In February 2026, we discovered a set of malicious activities that had been ongoing since late 2025. These activities involved a RAT module written in Go with proxy capabilities, which served as the main stage of the attack. The attack targeted government and diplomatic entities in Southeast Asia and showed a level of sophistication that caught our attention.
During the attack, the main malware, dubbed GoSerpent, received an encrypted argument and started communicating with a remote server. It was also used to deploy further malicious tools to collect sensitive data and dump credentials on the system.
Monitoring the activities of this threat actor revealed that in May 2026, they came back with an evolved set of malicious tools: a new RAT and proxy tool, Stowaway, which resembled the initial malware, as well as an additional stealthy tool to exfiltrate sensitive data collected in the previous few months through network shares.
We found earlier versions of the GoSerpent backdoor used since 2021 against victims in Southeast Asia with relatively simpler code that received command-line arguments in plain text. Even though the newer variant is stealthier, the attackers continued using the simpler version alongside the latest one in their recent attacks.
What makes this threat particularly concerning is the strategic deployment of various tools with sophisticated data collection and exfiltration capabilities.
In this article, we introduce the malicious tools uncovered by us, which have been used since late 2025.
The initial phase of the attacks involved deployment of the GoSerpent backdoor, followed by additional malicious tools. During this phase, the main goal was to collect sensitive files and store them for future exfiltration, which was done by a data collecting tool, ThumbcacheService. The attackers also needed system credentials to exfiltrate the collected data through network drives at a later stage. This was achieved through a number of credential dumping tools deployed in this phase via the GoSerpent backdoor.
The primary weapon in this campaign is the GoSerpent backdoor, a sophisticated Go-based remote access Trojan that has been active since at least 2021, with the most recent variant deployed in 2026.
This malware receives encrypted and base64-encoded command-line arguments containing a C2 server address and communication password, which are decrypted using AES-CBC mode with a fixed IV (31323334353637383930616263646566) and keys derived from predefined strings.
The backdoor connects to command-and-control servers using ChaCha20 encryption for communications, with the SHA256 hash of the communication password serving as the encryption key.
GoSerpent supports multiple C2 commands by receiving special command values. The commands include the following:
| Command | Symbol (as derived from corresponding function names) | Description |
| 2BA1 | Sync | Respond to the server to show the infection is active |
| 3BA2 | Exit | Exit process |
| 4BA3 | Ls | Start listening on a port |
| 5BA4 | Connect | Connect to a remote server |
| 6BA5 | Hello | Create a shell on the infected machine |
| 7BA6 | Ul | Upload a file or directory to the server |
| 8BA7 | Dl | Download from the server |
| 9BA8 | Ss5 | Start a SOCKS5 proxy on the infected machine |
| ABA9 | Cl | Close a listening port |
| CBAB | RF | Forward to a connected node |
GoSerpent can establish SOCKS5 proxy servers to route traffic through compromised hosts, enabling attackers to access other networks while masking their true IP addresses. The backdoor is capable of deploying additional malicious tools, including ThumbcacheService for file collection, Mimikatz for credential dumping, and QuarksDumpLocalHash for local account password hash extraction. The malware exhibits strong persistence mechanisms and uses filenames that mimic legitimate system processes such as lass.exe and updates.exe to evade detection.
McMx is a basic Go-based proxy and remote access tool that represents a simpler variant of the GoSerpent backdoor, apparently compiled from a different GitHub repository path.
Unlike the latest variant of GoSerpent, which uses encrypted command-line arguments, McMx receives input parameters from text files in plaintext format — in a way that resembles older versions of GoSerpent. The malware features similar function names with apparent typos present in both tools.
Before executing McMx, attackers manipulate batch files to generate configuration files containing C2 parameters. The patterns observed show the use of echo commands to create configuration files with parameters like remote host addresses, ports, and secret keys. The McMx malware is then deployed with this configuration.
The tool shares core functionalities with GoSerpent, including:
Following initial deployment of the GoSerpent backdoor, attackers typically wait several days before utilizing it to download and execute additional malware components for data collection and credential dumping.
ThumbcacheService is a malicious DLL deployed as a Windows service that functions as a sophisticated file collection mechanism within the GoSerpent ecosystem. The malware employs XOR encryption with a single-byte key of 0x13 for string obfuscation. It decrypts embedded strings and creates a database file named thumbcache_605a.db in the C:\Users\Public\ directory to store collected sensitive files. It specifically targets documents with the following extensions: .doc, .docx, .pdf, .xls and .xlsx.
The targeted files are then archived using 7-Zip and protected with a predefined password @vx0a9n5W2M0c3D6.#, enforcing a 20MB size limit for archives.
The malicious service also monitors the $Recycle.Bin directory for deleted files with the extensions of interest, ensuring comprehensive data collection.
The threat actor deploys the following tools via GoSerpent backdoor to dump credentials:
These tools work together to maximize information extraction from compromised systems. The stolen credentials were used in later stages of the attack to facilitate the exfiltration of sensitive files collected by ThumbcacheService.
After the initial phase of the malware deployments, the attackers allowed a few weeks for the ThumbcacheService to silently collect sensitive files without exfiltrating them. In the meantime, the credential dumping tools also continued to steal credentials. In May 2026, the threat actor came back with a set of new tools. The main malware of this round of activity was another Go-based RAT and proxy tool, Stowaway. It was used to deploy the two-stage data exfiltration tool TmcLoader/TmcPayload, which was the last piece of the data theft puzzle.
Stowaway is a proxy and remote access tool compiled from an open-source framework with customized functions to make the infection stealthier. This malware features both network admin and agent capabilities, enabling attackers to establish chained proxy paths across multiple hosts with the following functionalities:
Communications are transported over TCP, HTTP, or WebSocket channels protected by AES-256-GCM or TLS encryption.
As the next step, the attackers deliver two files to the victim machine via Stowaway:
Login{BBF061R2-BE25-4F6D-8B2D-1A6A39C3FSA2}.db — an encrypted configuration fileTmcLoader is a stealthy C++ loader module registered as a Windows service. The malware embeds an encrypted payload dubbed TmcPayload within its .data section, which is decrypted and loaded into the memory space of the svchost process to maintain persistence and avoid detection.
TmcLoader employs dynamic API resolution through a circular XOR encryption, where each byte is XORed with the value of the subsequent byte, combined with Base64 encoding for string obfuscation to hide API names.
The loader creates a unique event to prevent multiple infections on the same system. After that, it extracts and decrypts the embedded TmcPayload. This payload component is responsible for exfiltrating sensitive data from the victim’s machine.
TmcPayload generates a file path from an obfuscated string: C:\Users\Public\Libraries\{BBF061R2-BE25-4F6D-8B2D-1A6A39C3FSA2}.db.
It then checks for the existence of this configuration file. If the file doesn’t exist, it delays execution for a random period of time before rechecking. The configuration file contains encrypted network share credentials and destination paths for data exfiltration. It specifically references the thumbcache_605a.db file created by ThumbcacheService as the file to be exfiltrated, demonstrating the integrated nature of the attack chain.
What distinguishes this threat actor’s approach is the deliberate integration between different components of their toolset. The chain from ThumbcacheService to TmcLoader/TmcPayload demonstrates sophisticated operational planning:
thumbcache_605a.db database file.thumbcache_605a.db.This integration shows that the threat actor has carefully orchestrated their tools to work together seamlessly, ensuring that data collected by one component is available for exfiltration by another component.
The malware operators leverage legitimate hosting providers, including Alibaba Cloud and UCLOUD HK, for their command-and-control infrastructure. The use of legitimate hosting platforms demonstrates operational security awareness, making detection more challenging.
The technical similarities between GoSerpent and the newer Stowaway tools strongly suggest the threat actor’s deep familiarity with network proxy technologies. The consistent use of legitimate domain names as secret keys, with GoSerpent employing www.microsoft.com and www.spacex.com and Stowaway utilizing github.code, indicates a standardized operational methodology.
While the exact attribution of the GoSerpent campaign remains uncertain, there are indications of a potential link to the TetrisPhantom threat actor. The similarities in victim targeting, technical capabilities, and operational methodologies suggest a possible connection. However, further investigation is necessary to confirm this association.
The GoSerpent campaign represents a sophisticated and evolving threat to government and diplomatic entities in Southeast Asia. The threat actor’s use of customized tools, such as the GoSerpent backdoor, Stowaway, and TmcLoader, demonstrates a high degree of technical expertise and operational planning. The integration of these tools to collect and exfiltrate sensitive data highlights the actor’s focus on long-term access and intelligence gathering. As the threat landscape continues to shift, it is essential for organizations to remain vigilant and implement robust security measures to detect and prevent such attacks. By understanding the tactics, techniques, and procedures (TTPs) employed by this threat actor, defenders can better prepare themselves to counter similar threats in the future.
GoSerpent
EBFFD5A76AAA690BCDB922F82E0BACC5
DC506FF7BB72735444FB3703A6BEE6D8
McMx
D6E86BF8A90E9B632ADD5FA495F97FBC
ThumbcacheService
CB6C4C70A3B171FA3404B8E1A3382116
64E9D1950E42BC98486DFD9919463D1C
Stowaway
CBBB6D483737EA3566726E51752DFF40
7F223EE0716CE2AD56F55D3744419449
19F8BEFCB035F52BF70094E6B4F5779A
846EF7C1C7323849B2A778C5E4CDA162
TmcLoader
D08A059E8B815E3B891505BC8777FC28
93A1569D5D5AB2C4761FEDF84F83709E
152.32.160[.]239
8.220.194[.]108
8.220.214[.]132
8.220.209[.]155
8.220.193[.]189
101.36.104[.]87
144.48.6[.]46
103.138.13[.]30
47.80.22[.]58
152.32.222[.]113
43.106.30[.]226
In January 2026, we identified multiple attacks involving unknown malware that captures the contents of cryptocurrency wallet windows. During the investigation, we reconstructed the complete infection chain, which consisted of four tightly linked stages initiated by the execution of the previously described malicious PowerShell script TookPS. However, this campaign differs from previous activity in that it uses a new framework to deliver all malicious modules and orchestrate them via an SSH tunnel. In total, the framework includes more than 20 malicious payloads and implants, covering a wide variety of functions. At the time of writing, the threat remains active.
Kaspersky’s products detect this threat as Trojan-Downloader.Win32.TookPS.*, Trojan.Win64.BypassUAC.*, Trojan-Banker.Script.Agent.gen, Trojan.Win32.Dllhijack.*, Backdoor.Win32.TeviRat.*, Trojan-PSW.Win64.Stealer.*, Trojan-Spy.Win64.Keylogger.*, Trojan-Spy.Win64.Agent.*, Trojan.Win64.Agent.*.
TookPS is a downloader used for retrieving malicious commands and scripts from attacker-controlled servers to further propagate attacks. The first campaign using TookPS was discovered in March 2025. At that time, malicious scripts delivered a Python‑based infostealer along with a script that installed and configured an SSH tunnel on the victim’s machine. The next wave appeared in April 2025: the payload was changed, and TookPS was used to deliver the TeviRAT malware with the same SSH installer.
Then at the end of April 2025, TookPS underwent minor changes, yet its attack chain was completely redesigned. Unlike previous incidents, in this case, TookPS was used solely for the initial infection, with an automated SSH bot responsible for payload delivery. This new malicious campaign has multiple stages that cover the full attack lifecycle, from initial infection to persistence and data exfiltration. Among various malware strains, at one of the stages, the TeviRAT backdoor is delivered to the compromised host, ultimately fetching another version of a TookPS script.
We dubbed this updated TookPS campaign “OkoBot”.
Original OkoBot infection chain
We will break down this chain in greater detail later in the article. However, this is not the only version of OkoBot we were able to find. Already in March 2026, we discovered a new phase in the development of the framework, with Volume2 now being installed directly using TookPS. The HDUtil launcher → extl injector → Rilide chain was found to be abandoned in this newer version since it was replaced in full by the identical ext_daemon Volume2 plugin. TeviRAT was also removed, most likely because its functions were covered by the new plugins dispatcher.
New OkoBot infection chain
The initial infection is primarily delivered through two vectors: a ClickFix attack, and malware distributed through GitHub that masquerades as legitimate software. One such example is the fake SQL Server Management Studio (SSMS) package distributed through GitHub. In fact, it is actually the legitimate Audacity — a popular audio editor — compiled with a malicious implant embedded in one of its libraries. Because the repository was indexed by most search engines and appeared at the top of the results for the query SSMS, the malware looked legitimate and quickly earned users’ trust.
Malicious application distribution report
This repository was created at the end of March 2025 and existed until June of that year. It consisted of a single file, README.md, which provided a fake SSMS installation guide written in an official style and likely derived from excerpts of Microsoft’s documentation. However, the download link for the program, located at the beginning of the guide, pointed to the latest release in the same repository.
Both infection vectors trigger the execution of the malicious script TookPS, which installs SSH on the victim’s system, establishes a connection to the attacker-controlled SSH server and subsequently forwards the SSH daemon port. Following a delay, an automated SSH bot connects to the forwarded port.
The automated SSH bot collects system information such as usernames, antivirus software installed, the IP address, and OS version. It harvests cryptocurrency wallet files, browser cookies, profiles, and other credentials through an SSH tunnel. For subsequent delivery of malicious modules, it disables Windows Defender notifications via a registry modification. Moreover, it gains access to the graphical session on the victim’s system using the following sequence:
termsrv.dll with a patched one to permit multiple concurrent RDP sessionsApple Sync to maintain a reverse SSH tunnel that forwards the local RDP port every hourAfter that, the SSH bot begins retrieving malicious modules over SFTP.
One of the deployed modules is HDUtil, an auxiliary utility protected with VMProtect and heavily obfuscated. This launcher is used by the SSH bot during an attack to deploy various malicious modules via the target command. Additionally, it implements three auxiliary commands that were not observed during the attacks we analyzed. Nevertheless, their presence and potential capabilities further demonstrate the high degree of integration among all components of the framework.
At startup, the launcher verifies its execution environment by checking the HWID in the contents of %PROGRAMDATA%\hwid.dat, a technique consistently employed throughout the framework. If the file is missing or contains invalid data, such as a non‑MD5 hash, the launcher terminates without performing any further actions. Otherwise, the specified commands are executed. For example, enumsessions provides a list of sessions along with detailed information, including the session type (Console, Services, RDP, and others), username, connection host, and domain. In turn, enumadapters returns the names of all graphics adapters present on the system.
Example output of HDUtil enumeration commands
The most important command of the launcher is target, which enables payload execution on the system. An optional nouac argument enables automatic UAC bypassing via Windows RPC and an auto-elevated msconfig.exe program, allowing the payload to run with elevated privileges stealthily. This technique has been known for a long time, discovered and described in 2019 by the Project Zero team, who provided a full report with a detailed technical description.
Below is the list of all HDUtil commands.
| Command | Description |
| target [nouac [user=<user>]] [noattach] <file> | Starts file and prints its output. If optional argument noattach passed, command to be executed in background. If optional argument nouac passed, automatic UAC bypass to be performed. If optional argument user passed, new process to be executed under , otherwise default local administrator to be chosen. |
| pcopy <file> <dir_src> <dir_dst> | Copies file <file> located in <dir_src> to <dir_dst>. Not used by SSH bot. |
| enumadapters | Prints names of graphical adapters on current system. Not used by SSH bot. |
| enumsessions | Prints all sessions on current system. Not used by SSH bot. |
The first malicious module delivered to the infected system via SFTP is executed using the previously described launcher with the command .\HDUtil.exe target extl.exe. It is a heavily obfuscated DLL injector protected with VMProtect. At startup, the module enters an infinite loop and uses the EnumWindows and IsWindowVisible API methods to enumerate the PIDs of active windows and retrieve the corresponding executable filenames. For processes associated with widely used Chromium‑based browsers, the module invokes a routine that injects a specialized implant.
The injector opens a process, allocates a memory region, and writes the payload directly into this region as unencrypted raw bytes. Then it resolves two exported implant functions, LdrInitMain and LdrCallMain, based on a pre-specified hash derived from a modified version of DJB2 hash function. The first function performs the final PE unpacking, including rebase operations and the initialization of the import and exception tables. The second function directly initiates malware execution.
Setting up protections on the regions and launching the implant
This loader installs malicious browser extensions and hides them from the user. It uses an internal engine that resolves the addresses of stripped functions by analyzing the byte patterns of their calls using YARA-style syntax. This approach enables the malicious code to access critical Chromium engine functions required for extension installation and management. This functionality is also implemented for other browsers with appropriate modifications. For example, in the case of Microsoft Edge, the corresponding DLL msedge.dll is hooked using the specific patterns.
List of the functions hooked by the malware
Using the obtained address of the BrowserProcess object, the loader traverses the inheritance hierarchy and subsequently resolves a pointer to the function responsible for registering observers of browser‑window creation, specifically ProfileManager::BrowserListObserver::OnBrowserAdded. With a specialized built‑in engine, they are hooked using the attacker’s own implementations while preserving the original function’s address.
The loader replaces the functions it finds with its own
When a new Chromium window is opened, a hooked function is invoked that silently installs extensions. This routine scans the user’s %APPDATA% directory, loads all .crx files (Chromium-based browsers extension format), and records them in the ext_table. The extensions are then installed in the browser.
During installation, the extension is unpacked into a non‑default extensions directory, Local Extension Settings, and its manifest is dynamically modified. An object named custom_args is added, containing the fields hwid (the identifier of the infected system) and browser (the name of the browser in which the extension is installed). Then, using previously resolved internal functions of chrome.dll, the extension is installed and all requested permissions are granted.
Extensions are unpacked into a non-default directory
All extensions loaded in this manner are added to a special array to be subsequently identified among regular extensions and to remain hidden from the user.
The remaining patched functions are used to hide the installed malicious extensions from the user. When invoked with registered extensions as parameters, they perform no operation and return a constant value. This enables the threat actor to suppress notifications related to the malicious nature of the extensions and to exclude them from the displayed list of installed extensions. As a result, the behavior of other extensions remains unaffected.
Stub for hiding malicious extensions
During the attack, the Rilide extension was installed on the victim’s system using the previously described loader. Rilide is a stealer targeting Chromium-based browsers that has been frequently used by Russian-speaking threat actors since April 2023. The malware is designed to steal sensitive user data, including login credentials, cookies, and financial information, with a specific emphasis on cryptocurrency theft.
The final module delivered via SFTP is an open-source utility called Volume2, which is executed with elevated privileges using the command .\HDUtil.exe target nouac noattach Volume2.exe. The executable was linked with the malicious protobuf.dll library. Although the library seems identical to the legitimate DLL, it has been modified to include a malicious exported function, ProtobufGetVer2. This function decrypts and initiates a malicious implant. The payload is encrypted using AES GCM, initialized with a static 256‑bit key and a 96‑bit nonce. The GCM authentication tag is omitted, resulting in the absence of integrity verification. Starting in March 2026, the name of protobuf.dll was changed to version.dll, although its contents remained a modified ProtoBuf library.
Decrypting implant using AES GCM and subsequent mapping
The loaded implant functions as a malicious plugin dispatcher. Upon initialization, it reads and verifies the HWID before establishing communication with the C2 server via the HTTP protocol. Each request follows a predefined binary format: a 2-byte numeric bot identifier encoded in little-endian format, followed by an AES CBC-encrypted JSON object. By default, the BotID is set to 0, and the key and IV consist of 32 and 16 bytes of 0xff, respectively. The implant polls the server every 20 seconds to retrieve new commands. The request contains client data encoded in Base64, and the server may respond with a command containing three mandatory fields: TaskIndex (the command number from the dispatcher), TaskID (a unique task identifier), and HWID (the client identifier). The dispatcher supports four built-in commands:
| Task index | Action |
| 1 | Reconfigure client: update session keys, assign ID, switch to another C2 |
| 2 | Load DLL implant into memory and run its entry point |
| 3 | Load plugin into process and register tasks with RegisterPlugin function |
| 4 | Restart dispatcher as new process |
| x | If the task number is none of the above, search for it among the registered plugins |
Each plugin is required to export two functions: RegisterPlugin and PluginDispatch. These functions are used to manage and configure plugins. The RegisterPlugin function registers the plugin’s tasks with the dispatcher, whereas the PluginDispatch function is invoked when the plugin is called. Both these functions, as well as other external API functions, are located within the base libraries using one algorithm. This algorithm iterates through the export table and uses a specialized callback that calculates the MurmurHash3 hash and compares it against the target value to identify the appropriate function.
Resolving a plugin initialization function
During the analysis, we were able to discover five plugins that implement functions under their unique task identifiers.
We identified four malicious implants that are delivered to the system via the process injector plugin.
The malware is functionally identical to the browser extensions loader (extl.exe) described above, but less obfuscated and not protected with VMProtect.
Similarly to extl.exe, this malware monitors the list of active processes in the system and injects an implant into Trezor Suite, Ledger Wallet, and Ledger Live processes. The implant is malware that collects seed phrases of Ledger and Trezor cryptocurrency wallets. Initially, it verifies the HWID, and if it fails, it terminates immediately. Then, based on the value of BaseDllName, the malware determines the process context and uses the corresponding implementation for either Trezor or Ledger. It then utilizes the previously described technique to hook the internal Electron framework functions.
List of functions hooked by the malware
Then the malware communicates with the C2 (moonsand[.]store) over HTTPS, sending a Base64-encoded JSON request containing the fields Pid, HWID, and Build. In response, it receives a JSON payload containing the Wait flag. If this flag is set to true, the malware initiates periodic USB device scans filtered by VID and PID (Vendor and Product ID). Upon detecting a connected Trezor or Ledger hardware wallet, it invokes the hooked functions to display a hard‑coded phishing page designed for seed phrase recovery, with a distinct layout used for each identified wallet. If the Wait flag is set to false, the phishing page is displayed immediately.
When the seed phrase is entered and validated, the JavaScript code of the page outputs the phrase to the console prefixed with @:app:print. This prefix helps identify the malware messages in the hooked function mal_LogConsoleMessage.
Phishing pages for seed phrase recovery
The obtained seed phrase is subsequently sent to the C2 server within a JSON payload containing fields such as App (ledger or trezor), Build, DeviceName, DeviceHardwareId, and SeedData. Furthermore, an identical JSON, encrypted with the RC4 algorithm using the HWID as the key, is saved in a temporary directory under the filename sh_<ts>.json, where <ts> is the file creation timestamp.
This module is a keylogger that, in addition to recording user input, performs three malicious activities:
CF_HDROP for files dragged between windows, CF_DIB for copied bitmap images, and CF_UNICODETEXT for Unicode text. Each format is handled appropriately, and all copy events are logged under the Clipboard section. Text data is written directly to the log, while copied files are recorded by their file paths. Images are saved as JPG files following the naming pattern bf_YYYY-MM-DD hh_mm_ss.jpg, and the path to the saved image is added to the log.sc_YYYY-MM-DD hh_mm_ss.jpg. A corresponding message is recorded in the log under the Screenshot section, including the path to the screenshot.Thus, the keylogger creates three types of different file artifacts, which are placed in a temporary directory. Below is an example of a log file generated by the keylogger.
Example of the keylogger log file
This module, which we dubbed OkoSpyware, captures both keystrokes and the video stream of the target application’s window. It first compiles a list of over 100 executable names, including cryptocurrency wallet applications (such as Exodus or Litecoin QT), password managers (such as KeePassXC or 1Password), and other widely used applications, to identify which processes should be monitored among all active system processes. For each identified process, the module uses a bundled FFmpeg instance to capture an MP4 video of the window while concurrently logging keystrokes within that window. The resulting video file is saved in %TEMP% as media_<ts> (where <ts> is the recording’s start timestamp). In the same folder, a JSON file named oko_<ts>.json is created, containing metadata about the captured stream, such as the process name, intercepted input, the stream’s MD5 hash, and additional details.
Example of an OkoSpyware metadata file
The malware also monitors the state of browsers, and when the window title matches a specified regular expression — for instance, a MetaMask or Tonkeeper wallet extension page — it performs video recording and input logging, adding the window title value to the corresponding field in the JSON metadata file.
The TookPS script launched via a scheduled task receives a PowerShell exfiltration script as its payload from the C2. All files created by the MC Keylogger and OkoSpyware are sent to the C2 server to the endpoint ir-post.php. After that, the files are deleted from the victim’s system and a command history file, ConsoleHost_history.txt, is cleared.
Sequential exfiltration of artifacts from the temporary directory
At the time of writing, we have detected hundreds of victims of the OkoBot campaign in more than 25 countries, with the largest proportion of attacked end users found in Brazil, Vietnam, Canada, Mexico, and Türkiye.
Distribution of users attacked by OkoBot by country, April 2025–June 2026 (download)
At the time of writing, we can’t attribute this malicious campaign to any known crimeware actor. However, during the analysis, we observed that the servers hosting the PowerShell scripts used in the initial infection stage implement server-side geoblocking. When attempting to retrieve the malicious script using an IP from Russia or CIS countries, the server returns an empty response. This technique is very popular among Russian-speaking threat actors.
It was previously mentioned that the campaign uses the malicious Rilide extension, an infostealer that is actively spreading on Russian-speaking, invitation-only cybercrime forums. Additionally, the source code of the SeedHunter phishing pages includes comments in Russian.
The framework described here has numerous modules — mostly written in C and C++ — that are obfuscated and use a variety of packing techniques. Across all stages, specific patterns and techniques can be identified that are borrowed and used in other modules, which allows us to conclude that there is a close interconnectedness among all stages, forming a full‑fledged high‑level framework. Overall, these modules enable a wide range of functions, such as collecting local files, executing remote commands, downloading arbitrary browser extensions, and stealing crypto wallets.
The OkoBot campaign has been ongoing for over a year, and it remains active at the time of publication. Moreover, it is adapting, which indicates that this framework is being maintained and distribution campaigns continue.
Additional information about this threat, with a comprehensive IoC list and decryption scripts, is available to customers of the Kaspersky Threat Intelligence Reporting service. Contact: intelreports@kaspersky.com.
B07D451EE65A1580F20A784C8F0E7A46 # protobuf.dll
187A1F68AE786E53D3831166DC84E6D2 # protobuf.dll
D84E8DC509308523E0209D3CD3544619 # protobuf.dll
83E6B8FCB92A0B13E109301F8FF649CF # version.dll
7306885BB4C98F2A9F056104CF092BC9 # PowerShell wrapper
B4C2E16CDB513BE4DC798F88E2527334 # CMD wrapper
2157D2429124AD28DB7A26F2477CB985 # Environment enumerator
77CECF5E2A622AE07D8AE9913457AB57 # Dropper
E0C3BC27A65750E740C4F1719E531C7D # Process injector
3D2B43F91F65BFBF36A9C71B6B418876 # ext_daemon.exe
70FEF9FD6E351F4D53CFEEE8DCDFCD99 # seedhunter_x64.exe
ACD31C9941B6C1CABD4E45E6877B9038 # keylog_x64.dll
DD52F5108A176C62AD807C327734AD12 # oko.dll
AC93A821617AEA1F56D4BC0BEF4AF327 # HDUtil.exe
11DBC8A2BEA04B15F8F68F3F01E8FAF9 # extl.exe
%USERPROFILE%\.ssh\go.bat
%PROGRAMDATA%\HDVideo\HDUtil.exe
%PROGRAMDATA%\hwid.dat
%PROGRAMDATA%\oko_ver
%TEMP%\extl.exe
%APPDATA%\hwid.dat
2baserec2[.]guru # TookPS
recavb22[.]online # TookPS
kbeautyreviews[.]com # TookPS
coffeesaloon[.]online # TookPS
104.243.43[.]16 # SSH bot
104.243.32[.]213 # SSH bot
62.210.188[.]209 # SSH bot
livewallpapers[.]online # Volume2 C2
thatwascringe[.]com # Volume2 C2
moonsand[.]store # SeedHunter C2
Welcome to this week’s edition of the GBHackers cybersecurity newsletter — your weekly cybersecurity bulletin covering the 40 most important stories from July 6–10, 2026. This week the security world collided with AI head-on: prompt-injection attacks turned chatbots into C2 agents, five major AI coding assistants fell to a single attack pattern, and thousands of […]
The post Cybersecurity Newsletter Weekly – The 40 Biggest Cybersecurity Stories – Accenture Breach, AI Attack, Exploits Releases, Data Breaches & More appeared first on GBHackers Security | #1 Globally Trusted Cyber Security News Platform.
Just completed the CCTV machine from Hack The Box!
After enumerating the target, I discovered a ZoneMinder instance exposed on the web interface. Using the default administrative credentials, I gained access to the application and identified a SQL injection vulnerability in the removetag endpoint. By leveraging SQLMap, I extracted the database contents and recovered valid credentials through bcrypt hash cracking with Hashcat, allowing SSH access as the mark user and securing the User flag.
For privilege escalation, I discovered a locally running MotionEye service and extracted authentication details from its configuration files. After accessing the internal web interface through SSH port forwarding, I exploited a command injection vulnerability in the image filename configuration to obtain a root shell and capture the Root flag.
Really enjoyed this Easy-difficulty box — a great combination of web application exploitation, SQL injection, credential recovery, and Linux privilege escalation techniques!
#HackTheBox #HTB #PenetrationTesting #CyberSecurity #PrivilegeEscalation #SQLInjection #EthicalHacking #Linux #OffensiveSecurity …
Learn MoreHack The Box: CCTV machine walkthrough – Easy Difficulty
The post Hack The Box: CCTV machine walkthrough – Easy Difficulty appeared first on Threatninja.net.
Welcome back, aspiring cyberwarriors!
During pentests, it’s not uncommon to find a Grafana somewhere inside an organization’s infrastructure. Sometimes it can even be exposed directly to the Internet. It’s always worth checking Grafana for vulnerabilities, as it has been affected by multiple security issues over the years.
Grafana is an open-source monitoring and visualization platform used by organizations to display dashboards containing information collected from servers, applications, databases, cloud services and networking equipment. Administrators rely on it to monitor the health of their infrastructure in real time, making it one of the most widely deployed monitoring apps in enterprise environments. Since Grafana often connects to numerous backend services and contains valuable configuration information, compromising it can sometimes give hackers an excellent foothold into the rest of the network.
Of course, you could manually inspect every Grafana installation looking for known vulnerabilities, but that quickly becomes time-consuming, especially during larger engagements where multiple servers have to be assessed.
Fortunately, there is a Grafana-Final-Scanner. It’s a tool designed specifically to automate this process. Instead of manually checking every instance the scanner performs the work for you by checking whether the target is vulnerable to a collection of publicly known vulnerabilities.
We’ll begin by downloading the repository and installing its dependencies.
kali > git clone https://github.com/Zierax/Grafana-Final-Scanner.git
kali > cd Grafana-Final-Scanner
kali > python3 -m venv venv
kali > source venv/bin/activate
kali > pip3 install -r requirements.txtOnce everything has been installed successfully, it’s worth taking a quick look at the list of vulnerabilities supported by the scanner.
At the time of writing, the tool is capable of checking for more than fifteen different Grafana vulnerabilities.
Now let’s point it at our target.
kali > python3 scanner.py -u https://target/grafana/loginAfter a short scan, the tool analyzes the target and reports any vulnerabilities it successfully identifies.
In our case, the results were promising. The scanner identified CVE-2024-8118 and an OAuth Authentication Bypass vulnerability. It also gave us the URL. We opened the page and the application asked us for an administrator key that we obviously didn’t have.
Fortunately, web applications don’t always behave exactly as their developers intended. Developers occasionally leave sensitive information inside the application’s front-end code. JavaScript, HTML comments, hardcoded credentials, authorization logic have all been discovered by hackers countless times over the years.
With that in mind, we opened the page’s HTML source code to see exactly how the authorization process was implemented. The comments were written in Russian, but the logic itself was fairly easy to understand.
Instead of verifying a specific administrator key, the application simply checked whether any key existed. So the validation routine wasn’t actually validating the value at all. It simply checked if some key was provided.
The next step was straightforward. We opened the browser’s Developer Console and manually created the expected key.
The application accepted it.
We bypassed the authentication and accessed the admin panel.
Finding a vulnerability is only part of the pentest. Understanding how the application behaves after exploitation is equally important. Sometimes the scanners get you only halfway there, while manual analysis can help you find the remaining pieces needed to fully demonstrate the impact.
It’s also a good reminder that developers occasionally leave sensitive information hidden inside client-side code. You never know what useful information may have been left behind.
While running the scanner from the command line works perfectly for testing targets, the project also includes a convenient web interface.
This can be useful during larger pentests where dozens of Grafana instances need to be assessed.
You can start it with this command:
kali > python scanner.py --serve --db vulndb.jsonGrafana is one of the most common monitoring platforms you’ll encounter during internal and external penetration tests. Because it frequently contains sensitive operational data and often communicates with numerous backend systems, compromising it can sometimes provide hackers with an excellent entry point into an organization’s network.
Grafana-Final-Scanner can make it much easier to determine whether your Grafana is exposed to known vulnerabilities.
If you enjoy web application pentesting and would like to improve your skills for bug bounty hunting, we have our Web Application Hacking training. You’ll gain the practical knowledge and skills you need to start finding web application vulnerabilities.
The post Pentesting: Using Grafana to Pentest a Fitness App first appeared on Hackers Arise.
Welcome back, aspiring hackers!
The density of WiFi access points in modern cities has now reached a point where a large-scale surveillance system may be able to identify almost anyone who walks near a router, even if that person is not carrying a mobile phone. Researchers from the Karlsruhe Institute of Technology (KIT) have published a scientific paper describing this kind of system and the technology that makes it possible.
At the center of this surveillance method is a feature called beamforming, which first appeared with the WiFi 5 (802.11ac) standard in 2013–2014. The basic idea was introduced with WiFi 5, but it became much more refined and effective with WiFi 6 (802.11ax), where the technology matured into something more practical.
Beamforming, also called spatial filtering, is a signal processing technique used to send and receive wireless signals in specific directions rather than spreading them evenly in every direction. In simple marketing language, this is often described as a router that “does not broadcast equally everywhere anymore, but instead follows the user with a focused beam.” That description is not wrong, but it leaves out the technical depth behind the idea.
From an engineering point of view, beamforming works by combining several antennas into a group called an array. When the signals from these antennas are timed and lined up correctly, they boost each other in certain directions. In other directions, they cancel each other out. The result is a signal that is far more focused and efficient than older systems, which simply broadcast outward in every direction at once.
Beamforming gives both senders and receivers the ability to focus on signals coming from one direction while blocking out noise from others. Because of that, the technique is used not only in WiFi, but also in radar, sonar, seismology, wireless communications, radio astronomy, acoustics, and biomedical engineering.
As radio waves move through space, they do not simply travel in a straight, clean line. They interact with the world around them in many different ways. They can pass through objects, reflect off surfaces, become absorbed, become polarized, bend around obstacles, scatter in different directions, or refract as they cross boundaries between materials. This means that when a WiFi system sends a signal and later receives it back, the final result contains information about everything the signal encountered along the way. By comparing the expected signal with the received one, it becomes possible to measure interference and use that information to correct transmission errors. But that same interference also reveals details about the environment itself.
For example, when a person enters the path of a WiFi signal, the signal changes. Human bodies affect radio waves in measurable ways. The signal may weaken, shift, scatter, or behave differently depending on movement, posture, and position. If researchers analyze these changes carefully, they can infer a surprising amount of information about the surrounding environment. They may detect whether people are present, what they are doing, and in some cases even who they are.
This whole research area has grown into a separate field known as WiFi Sensing.
Most WiFi Sensing research is presented as useful and harmless, and in many cases it really is. It can support smart-home features, occupancy detection and other practical applications. But the privacy concerns are obvious. When these methods are combined with activity recognition and the massive spread of WiFi hotspots, they can reveal highly sensitive information. One of the most troubling possibilities is that someone could be identified in the range of a hotspot and then tracked over time without ever knowing it.
There are several ways a person can be identified through WiFi. One important method relies on analysis of Channel State Information (CSI), which is sent at the physical layer of WiFi communication. CSI is detailed and useful for WiFi sensing. It gives a rich picture of how the wireless channel behaves. The problem is that CSI is not always easy to access. In many cases, it requires modified firmware and specialized hardware support, which limits how widely it can be used in practice.
The table above compares roughly 25 different systems, evaluating them across several key dimensions. The Paper column lists the name of each system, while the Identities column shows how many different people each system is capable of distinguishing between. The Accuracy column then reflects how reliably each system correctly identifies a person. On the technical side, the Pre-Processing column describes the signal processing techniques each system applies to clean and transform raw WiFi data before passing it to a machine learning model, and the Model Architecture column identifies what type of model is used. The Perspective column shows how subjects were positioned or moving during data collection, such as standing orthogonally, performing gestures, or typing keystrokes.
Beamforming entered the picture for a different reason. As mentioned earlier, it was introduced in WiFi 5 to improve throughput and make wireless communication more efficient. But beamforming also depends on environmental information that is similar to CSI. The difference is that this information is gathered on the transmitter side rather than the receiver side.
The key new dimensions here are the Inference column, showing the wide variety of tasks these systems tackle, from respiratory rate monitoring and crowd counting to sign language recognition.
In a typical beamforming setup, client devices send something called Beamforming Feedback Information (BFI) back to the access point. BFI is a condensed snapshot of current signal conditions. It tells the access point how the wireless channel looks so that it can adjust its transmission for better performance.
The key difference between CSI and BFI is that BFI is transmitted back to the access point without encryption. This makes it much easier to collect using standard, off-the-shelf hardware, without needing any special software modifications. That significantly lowers the bar for potential misuse. The privacy concern gets even more serious when you consider that the IEEE is already working on making WiFi sensing an official standard through the upcoming 802.11bf update and based on the current draft, without putting strong privacy protections in place.
Researchers at KIT showed that people can be identified using only BFI data, even when they are not carrying a smartphone or any other wireless device. The method does not depend on a person bringing along a tracked gadget. It works using ordinary WiFi devices already present in the environment and already communicating with one another.
As radio waves move through space and interact with the human body, they create patterns that can be captured, analyzed, and compared. In that sense, the process starts to resemble imaging, almost as if the wireless system were building a rough picture of a scene without using a camera. The result is not a photograph in the normal sense, but the data can carry enough structure to support identity inference.
“The technology turns every router into a potential surveillance device,” says Julian Todt, one of the study’s authors. “If you regularly walk past a café that has a WiFi network, you could be identified without your knowledge and later recognized by government agencies or commercial companies.”
That is a serious warning, and it captures the core concern very well. Intelligence services and cybercriminals already have many easier ways to monitor people, including compromising CCTV systems or intercepting video communications. But wireless networks are different. They create a nearly invisible surveillance layer that already exists in a huge number of places.
Unlike earlier approaches that depended on LiDAR sensors or on reflection-based systems using walls, furniture, and human bodies, this method works with standard WiFi equipment. By collecting BFI data, researchers can build representations of people from several different viewing angles. These representations are then used to distinguish one person from another, even when the number of people is large. Once the machine learning model has been trained, the identification process can happen in just a few seconds.
The study involved 197 participants. The researchers reported that they were able to identify individuals with nearly 100% accuracy, regardless of viewing angle or walking style. That is an impressive result, but it did not come easily. To reach that level of accuracy, the model needed a substantial amount of machine learning training. Each person in the training set performed around 20 walking passes before the model was trained.
During the research two TP-Link Archer BE800 routers were used. The experiment relied on channels 37 and 85. It also used two non-overlapping 160 MHz channels in the 6 GHz band available under WiFi 6E. The hardware included Intel AX210 WiFi network adapters.
The researchers stress that the technology is powerful, but also potentially dangerous. The risks are especially serious in authoritarian states, where systems like this could be used for large-scale population surveillance. In such settings, the ability to identify people without their phones, without cameras and without obvious visible monitoring would be a major privacy threat.
For that reason, the authors strongly recommend that privacy protections and security safeguards be built into the upcoming IEEE 802.11bf standard from the start, rather than added later as an afterthought.
In fact, WiFi-based sensing has become so effective that some modern routers already include motion-detection features right out of the box, and manufacturers openly advertise them.
Features such as WiFi Motion Detection allow homeowners to monitor activity inside their homes through mobile apps, using nothing more than changes in WiFi signal patterns.
A feature designed for convenience in a home can also become part of a much broader surveillance system when deployed at scale.
As an additional note, several tools already exist that monitor wireless activity in nearby environments. They don’t work exactly the same way as the techniques we covered earlier, but they’re still useful.
Pi.Alert scans devices connected to a WiFi network, detects unknown devices, and sends notifications when devices unexpectedly disconnect from the network. It is often used as a practical awareness tool for keeping track of what is present on a home or local network.
WireTapper discovers nearby wireless signals, including WiFi networks, Bluetooth devices, hidden cameras, vehicles, headphones, televisions, and cellular towers. It gives the user a broader view of the wireless environment around them, which can be useful for awareness and inspection.
We also have an video on this topic with Master OTW and Yaniv Hoffman. In the video, OTW explains how hackers can use SDR, AI, and Wi-Fi signals to detect human movement through walls, how the technology works, and talk about practical ways to defend against it. Feel free to check it out.
As modern routers gain advanced sensing, they can also become tools for observing and identifying people through the way their bodies interact with wireless signals. The KIT research shows that this is a practical technology that can identify individuals with remarkable accuracy using ordinary WiFi hardware. Although WiFi sensing can be valuable for smart homes and automation, it also raises serious privacy concerns. Privacy protections will need to become just as important as performance improvements.
If you’re interested in Wi-Fi security, our Wi-Fi Hacking training can help you gain the necessary experience. This attack vector is often underestimated, and many organizations are vulnerable to it. It is definitely valuable in penetration testing.
The post Wi-Fi Hacking: Wi-Fi Can Now Identify You Without Your Phone first appeared on Hackers Arise.
Welcome back, aspiring investigators!
Let’s talk about something that has become one of the biggest problems in the crypto world. It’s drainers. If you haven’t heard the word before, don’t worry, you’re about to become very familiar with it. Drainers are a type of phishing attack, and they have swept through the cryptocurrency world at a truly striking pace. In fact, they are now growing so fast that they have already overtaken ransomware, both in how widespread they are and in the sheer amount of money they steal. To understand exactly how this works, we dug into the mechanics of drainers as well as the whole shadowy little market that has grown up around them. That’s what we are going to explore together today.
The basic idea behind any phishing campaign is to catch you making a mistake. Hackers want you to hand over information or access that should never leave your hands. In the specific case of drainers, the goal is a little different from classic phishing. The hacker wants to trick you into granting a smart contract permission to interact with your funds. Once you give that permission, the damage is already done. Drainers mostly go after blockchains that support smart contracts. That means they target users on Ethereum and Ethereum-like networks, such as Base, Polygon, and Optimism. But don’t think Ethereum is the only battlefield. Drainers built for Solana exist too, and a drainer aimed at Bitcoin has already made an appearance.
Imagine you want to connect your MetaMask wallet to some project’s website because you’re hoping to grab a little free crypto. Maybe you want to buy a brand-new token while it’s still cheap, before the price shoots up. You click Connect, you type in your password, and you sign a transaction that approves access to your wallet. And that, right there, is exactly the moment a drainer catches you. Instead of a legitimate contract that would let you receive tokens, the hacker gets you to sign a malicious smart contract. In doing so, you unknowingly grant permission for your funds to be transferred out. In effect, you agree, with your own hand, to give away all your money.
So how does a hacker actually pull this off? It works best with something called an airdrop, which is simply a giveaway of new tokens. Airdrops attract a swarm of people who are hoping to get a little bit of crypto that might grow tens of times in value down the road. These giveaways do genuinely happen sometimes, as a real way to promote a new token. So people have learned to trust them. In that exact moment, the user is driven by something we call FOMO, the fear of missing out on a gain.
In their rush to grab the airdrop, a person often doesn’t stop to check who actually created the page they are interacting with, or what the smart contract they are approving actually does under the hood. The website itself might be a perfect copy of the real one, built by the hacker down to the smallest detail, while the smart contract underneath does the opposite of what it promises. Instead of giving you money, it takes it.
In 2024, drainers overtook ordinary ransomware, both in how far they spread and in how much money they brought in. Now, don’t get it wrong, ransomware is still very much the scourge of large businesses. But scammers, being the opportunists they are, have rushed into this new and still relatively uncrowded niche. The very first drainers spread quietly, as scripts traded on darknet marketplaces. Back in 2022 there were 55 unique forums where you could find drainers being sold or discussed. By 2024, that number had jumped to 129 such places, more than double in just two years.
And keep in mind, that count only covers a place as niche and honestly as sparse as the dark web. Most of the real action these days happens on Telegram and Discord.
The biggest drainers active in 2024 had names like Angel, Inferno, Ping, Ace, Cerberus, Nova, Medusa, MS, CryptoGrab, and Venom. Of that whole list, mainly Angel and Ace are still active today, but a new player has stepped onto the stage, one called Vanilla. It hasn’t been studied very closely yet, because it runs on a private model that is difficult for the average scammer to even get access to.
According to Scam Sniffer, a company that closely analyzes different types of crypto fraud, total losses from drainers in 2024 added up to $494.000.000.
That figure only counts the large-scale hacks that could actually be tallied and confirmed. Since drainers mostly target ordinary, everyday users, small thefts of just a few thousand dollars here and there don’t even make it into that statistic. So the real number is almost certainly much higher.
Among the large-scale cases recorded in 2024, there were more than three hundred thirty thousand victims. The single biggest theft that year came to $55.000.000. All together, there were roughly thirty major fraudulent campaigns, which is one and a half times more than the year before, in 2023. In the first quarter of 2024 alone, drainers showed almost sixfold growth. Compare that to ransomware, which only doubled over that same stretch of time.
So what do all these numbers really mean? Well, because the barrier to entry into this line of work is so remarkably low, it has started attracting scammers who used to work in more old-fashioned territory, like email phishing, luring victims to fake bank login pages and other traditional scam types. A couple of months of this kind of work could buy an apartment, a car, and regular vacations somewhere warm like Thailand. Take one risk, and you can just walk away, or so the thinking goes. But of course, once someone gets a real taste of easy money like that, nobody actually walks away after two months. The business pulls them back in.
Think about the contrast here. A ransomware group has to negotiate with a company, arrange for payment, and handle the whole business of decryption afterward. That’s a lot of hassle and a lot of steps where things can go wrong. A drainer, on the other hand, just steals the money immediately. No negotiation needed.
Like plenty of other kinds of scams out there, drainers are distributed under what’s called a SaaS model, short for Software-as-a-Service. In this criminal corner of the internet, they’re called DaaS, meaning Drainer-as-a-Service.
There’s also a very characteristic division of labor inside these operations. You’ve got developers, who build the actual malware. You’ve got workers, the rank-and-file operatives out doing the scamming day to day. And alongside them you’ve got recruiters, traffic-generation specialists, and providers of various supporting services that keep the whole machine running. The main job, naturally, falls to the developers. They are the ones who create the malicious software and work to make it more convenient to use, easier to deploy, and easier to scale up.
So what does a hacker actually need in order to pull off a phishing campaign like this?
First, they need domains for their future sites, and these domains are usually spelled just similarly enough to the name of the real project they’re impersonating, so a distracted eye won’t catch the difference. Then they need hosting, which is simply a place to put the site once it’s built. Naturally, they also need a landing page, one designed to closely resemble the legitimate project’s real page. Underneath that landing page sits the drainer code itself, which is typically JavaScript code hosted directly on the site. On top of all that, they’ll usually build a control panel that shows them how many users have been lured in and tracks how those users are behaving on the page. And finally, hackers take their own security seriously too, relying on VPNs, proxies, and fake sockpuppet accounts to cover their tracks.
Professional hackers usually go a step further and set up a full command-and-control server, which lets them manage the drainer’s behavior remotely and adjust it on the fly.
Once all of that infrastructure is in place, all that’s left is bringing in people, actual victims to walk through the trap. That job falls to traffic arbitrage specialists, sometimes called traffic drivers. Their whole task is to funnel users toward the phishing page. They accomplish this in all sorts of ways, everything from buying Google ads to jumping directly into comment sections and posts to engage with real users. Some scammers even go so far as to clone the official support channels of legitimate projects, so a victim reaching out for help ends up talking to the scammer instead.
Put it all together, and what you get is a genuine sales funnel, a designed path that walks victims toward the trap, just like any legitimate marketing funnel would walk a customer toward a purchase.
Here’s how the profits typically get divided up. Operators, the people running the overall scheme, take home twenty to thirty percent of whatever gets stolen. The rest goes to the workers, the people directly out there scamming victims day to day. A worker’s exact cut depends on their skill level. Beginners give up thirty percent of their take to the operators, while the most experienced workers only give up ten to fifteen percent.
And how is a worker’s skill level judged? Simply by how much they have already managed to steal over time. If you’ve stolen up to $10.000 total, you’re considered a beginner. Between $25.000 and $30.000 puts you at mid-level. And starting from $100.000, usually climbing toward a million or more, you’re considered a true professional in this dark little trade.
Knowledge in this underground world gets passed around among workers through tutorials. A tutorial itself becomes an item that gets bought, sold, and traded, almost like a piece of merchandise. Entire communities have formed just to gain access to these tutorials, treating them like valuable trade secrets. The writing style of these tutorials makes it fairly clear that AI tools were used to help put them together.
Broadly speaking, the same traffic-driving scheme used in ordinary, everyday phishing applies here too, just adapted for the world of crypto. A worker is essentially doing the same job as any online advertising specialist would. Their goal is simply to increase the number of people clicking through to the phishing page. That means hunting for users who are genuinely interested in Web3 and DeFi projects, people who hold crypto wallets and who are drawn to airdrops, token swaps, and exchanges.
This whole process involves demographic analysis and geolocation analysis, essentially the same ordinary targeting techniques that any advertiser in any industry would recognize. Workers also handle what they call “site design,” which really just means cloning the pages of existing, trusted projects. They’ll even use classic marketing techniques like A/B testing to see which fake page tricks more people.
Now let’s walk through a few high-profile examples of drainer thefts.
Arkham is a company that provides on-chain analytics, and it’s a genuinely popular tool for tracking transactions. Traders rely on it, for instance, to check an asset’s price and see exactly where it’s trading across different platforms.
Back in 2023, Arkham’s owners launched their own token along with an airdrop of coins to celebrate. But hackers saw an opportunity and created numerous fake profiles on X specifically to redirect users toward phishing pages containing a drainer. Remarkably, these bot accounts proved quite resilient and managed to avoid being banned for a long stretch of time. They mimicked Arkham’s real activity closely and spread malicious links far and wide.
A huge number of these fake sites were created during the campaign, and each one typically had a lifespan of just weeks, or a couple of months at most. Angel’s software allowed a hacker to copy landing pages quickly and place them on brand-new domains almost instantly. The whole process has been simplified so much that a worker only needs to type a few commands into a conversation with a Telegram bot in order to deploy an entirely new phishing site.
An even bigger impact can be achieved by a hacker hijacking the real, verified account of some authoritative company, or even a government organization.
And that’s what happened with the United States Securities and Exchange Commission, or the SEC. On January 9, 2024, its account on X was compromised through a technique called SIM swapping, which basically means reissuing a SIM card tied to the phone number linked to that account. Officials, unfortunately forgetting about basic security hygiene, hadn’t even enabled multi-factor authentication on the account.
Lately, the SIM-swapping community and the drainer community have grown noticeably closer, almost like two neighboring criminal industries starting to collaborate. Swappers now routinely supply drainers with freshly hijacked accounts to use.
The hackers behind this attack posted that the SEC had officially approved investing in Bitcoin without needing to buy crypto directly on an exchange like Binance or Coinbase. This caused an immediate stir, because investors had been waiting a long time for exactly this kind of decision from the SEC, and many expected it to be announced any day. Following the fake post, the hackers urged people to claim an “official SEC airdrop” on a special site that contained a drainer.
That single fake post even caused a real spike in Bitcoin’s price. It rose by a full thousand dollars, just from a fake tweet.
Scammers, as it turns out, wouldn’t really be scammers if they didn’t also scam each other. At one point, the developer behind the Pink Drainer felt like he was getting close to being unmasked, so he decided to get out of the game entirely and cash out his loot. Here’s the catch, though. You can’t just sell crypto obtained through a scam outright. To actually withdraw the funds, a scammer first has to launder the money, or else an exchange might get suspicious and freeze it before it ever reaches a real bank account.
To avoid enabling things like terrorism financing, or simply to stay within the law, exchanges use a system of scoring and refuse to accept “dirty” crypto. This scoring system is called an AML score, short for anti-money-laundering. There are plenty of laundering methods out there, and while trying one of them, Pink Drainer’s own developer ended up getting scammed himself. He fell for one of the simplest kinds of fraud imaginable called address poisoning.
Here’s how it works. Hackers generate crypto addresses that closely resemble a victim’s real address, and then they send that victim a tiny amount of crypto, just enough so that the lookalike address shows up in the victim’s transaction history.
From the user’s side, here’s what it looks like in practice. You send, say, one hundred dollars to some other wallet, maybe an exchange you use regularly. Then, five or ten minutes later, you receive a few tiny transfers that appear to come from that very same wallet. But in reality, they only come from a similar-looking address, one that might share, say, an identical start and end to the real address, while the middle is different.
The hacker is betting that on your next transfer, you’ll simply scroll through your history, pick the most recent address you see, and send your money not back to yourself, but straight into the hacker’s pocket. And that’s exactly how Pink Drainer got caught in his own kind of trap. He picked what looked like the last transaction in his history and sent ten ETH, worth about $15.000 at the time, straight to some unknown “colleague” who was never really his colleague at all.
Because draining is so easy and profitable, this type of scam is not going away anytime soon. If anything, the ways malicious payloads get delivered will only keep getting more sophisticated from here. Drainers are increasingly setting their sights on younger blockchains too. On Ethereum-based networks, it’s steadily getting harder for hackers to operate, since protective measures keep appearing that they have to find new ways to bypass. On Solana, though, no such protections really exist yet, which makes it a much softer target. New kinds of drainers will keep emerging as well. Some scammers have already started building actual apps for Google Play and the App Store, moving beyond simple websites and into places millions of people trust by default. So stay alert out there, and think twice before you click any button, especially one promising you free money. If it feels too good to be true, in crypto more than almost anywhere else, it usually is.
If you’re interested in cryptocurrency forensics, we have a dedicated training called Bitcoin and Cryptocurrency Forensics. You will get to dive into blockchain analysis and cryptocurrency investigations, learning the skills needed to become a cryptocurrency forensic analyst. You can buy the training separately or attend it live on September 15-17 at 3 PM UTC.
The post Cryptocurrency Drainers: How Hackers Steal Cryptocurrency first appeared on Hackers Arise.
