Vanguard (Part 1): Telegram raid protection

Over the past weeks, I’ve been immersed in developing Vanguard. Initially it was little more than a hack, which was developed quickly and without much consideration towards the cleanliness of the code. I needed a way to have public Telegram links without the risk of raids, or getting botted.

Raids are highly disruptive, and annoying. They also carry moderate risk because there’s a chance your channel or group, being public, gets reported for metrics manipulation. Platforms like Instagram and Twitter heavily discourage viewer and interaction metrics manipulation. Although this still happens regularly, if any social media company finds that your account has engaged in this manipulation, you could be warned, suspended, or banned. And the truth is, it’s not particularly complicated or expensive to do this. Of course, Telegram, as a social platform, is no exception. While there are mechanisms to prevent raids, none are ideal.

The providers of these services are called SMM panels. Their prices vary from a few cents per thousand users to tens or hundreds of dollars per thousand users. Most of these panels are just resellers of SMM APIs and don’t actually control the fake Telegram users. Some examples of how these panels look like:

Raid-prevention mechanisms

Moderation bots

One of the most popular moderation bots is Rose. Rose has many features to prevent spams, it has a highly configurable and comprehensive warning system, with a strike system that bans repeated offenders. It also has specific AntiRaid features, which can be enabled automatically if a certain number of users join the group within a minute, and also manually. However, the “joined” messages will still clog up the Telegram chat, making the chat somewhat unusable for the next few minutes during the raid.

In addition to these features, Rose and other bots also have features such as captchas that users must fill out to join the group. Some captchas show up in the group, whereas other bots are configured to DM the joining users the captcha challenge before they are admitted into the group.

Caveat on captchas

Generally, these methods add significant friction to the joining process and are not too difficult to defeat using captcha farms like Anti Captcha. Some of these services are automated with AI, and others use real humans in low-cost-of-living regions tasked with solving captchas, resulting in high success rates at a fraction of a cent for each solved challenge.

Approval-only groups

Telegram allows you to make your groups approval-only, even if they are public. This is effective for preventing spammers but could create a significant administrative burden during raids, since tens of thousands of fake users would join the group at the same time, completely trashing the join request queue, which by the way cannot be automatically dismissed, so users would have to click the “dismiss” button several thousand times until all requests are dismissed. This also means there’s a significant risk of dismissing real users, who wouldn’t be notified their request was dismissed. I find this all to be highly cumbersome and a pretty terrible UX.

What problems does Vanguard solve?

Keep in mind that I’m not saying Vanguard is superior to any other method, and I definitely don’t think it’s flawless. Every solution has its advantages and disadvantages.

Let’s take a look at what Vanguard offers. Starting with the drawbacks.

Drawbacks

PoW challenges

Proof-of-work challenges imply the user’s device has to spend some processing power, making Denial-of-Service attacks unscalable. The idea behind PoW challenges is that the challenge is sufficiently small to solve for a single user, but the more simultaneous processes an attacker wishes to spin up, the more expensive solving this challenge becomes.

There are many kinds of PoW challenges. Vanguard is currently using something called a “time-lock puzzle”. Specifically, it implements RSA-based time-lock puzzles where the server generates a 2048-bit semiprime modulus (N = p*q) and requires clients to compute x^(2^t) mod N through repeated squaring. The server pre-computes the answer for instant verification without revealing the factorization. This puzzle takes approximately 500,000 iterations by default, forcing sequential computation that cannot be parallelized. Other popular methods include Hashcash, which is related to Bitcoin mining, and Scrypt, which is used for other cryptocurrencies like Litecoin because of the inherent design properties of Scrypt which makes it difficult to implement in custom hardware.

Regardless, some users validly dislike PoW as a waste of computing resources, especially if these users are on old or less powerful devices. Vanguard is designed to target smartphones and computers manufactured in the last ~15 years. Meaning, most commonly used hardware nowadays should be able to solve these challenges. This is a conscious design choice because Vanguard is made to protect Telegram groups and channels, and most Telegram users are using the official desktop and mobile applications, in which case it is easy to say they will be running hardware capable of completing Vanguard challenges.

However, as you can see, Vanguard is not pretending to be a universal solution for any webpage or online content.

You can no longer have a public Telegram username

Vanguard requires you make your groups and channels to protect private. This means they will no longer have a username in the form of @username. This of course makes discovery more difficult. An alternative is to move the @username to a gateway channel that just contains a link to the Vanguard challenge.

Vanguard offers limited-time links. Any admin with the permission to create links can create additional links, which could potentially be a backdoor if there is ever a rogue admin. Therefore, Vanguard must be the only entry point to the group.

Self-hosting or trusting a third-party

This problem is quite similar for Telegram bots: You either self-host them or you trust the developers to keep your data safe.

Advantages

No manual challenges

Although this could also be a challenge if the automated PoW challenge ever fails, captchas suck. Joining a group and being questioned, and demanded you type some letters and numbers sucks. With Vanguard, users join immediately without any delay, once they pass the automated PoW challenge.

Raids are nearly impossible

The kind of platforms used for raids are actually marketing promotion tools in order to boost follower count. These platforms require you provide a link, which must be a Telegram link. These platforms cannot take a JS-intensive PoW webapp challenge. And even if they could, this would be tremendously wasteful. Due to the strict ratelimiting that Vanguard implements (100 requests per 30-second window by default), they’d be joining extremely slowly, especially if they join from the same IP address, but even if they use multiple IPs, joining takes some time because challenges have to be built at the server. The server pre-generates challenges asynchronously and maintains a cache to prevent DoS attacks, with a queue management system that rejects clients when too many are waiting (maximum 10 clients in queue by default).

Of course, nothing is impossible, but Vanguard raises the bar for raids significantly.

A multi-layered approach

The best approach to any kind of security is to use redundant systems that complement each other. Even if you use Vanguard, it is a good idea to enable some anti-raid bot like Rose that bans users whenever a raid is detected.

Just use Anubis / go-away

There are many good projects with a similar purpose, but Vanguard is sufficiently different to warrant creating an entirely new project.

Berghain is, by the looks of it, the oldest. But they all focus on the same problem: They are reverse proxies (Berghain works a bit differently, but the concept is similar), and they all work to tackle bots and DDoS attacks. They all have PoW, and some even offer captcha mechanisms.

The key here is that all these software programs are built to challenge the user upon their first visit and allow them to continue browsing the website uninterruptedly afterwards. Vanguard is different because it is expected that one user will have a single device to complete the challenge on. Every new visit is a potential new user since the content is not hosted on the website but on Telegram. Each challenge expires after 60 seconds, and successful solutions generate temporary Telegram invite links that also expire quickly.

Furthermore, Vanguard’s challenges are significantly more complex and take longer to solve than those of the other projects. The implementation uses Web Workers for non-blocking client-side computation. The server uses HMAC signatures to prevent challenge tampering and validates that solutions come from the same IP address that requested the challenge. This will be addressed in the future by adding browser fingerprinting and scores to IPs and users based on their risk profile and perhaps eventually making the difficulty scalable such that low-risk users have an easier challenge and high-risk users have to spend more time solving it.

Regardless, I have my own opinions on Anubis. Among other things, Anubis is extremely easy to bypass. By simply changing the user agent to not contain “Mozilla”, you are able to pass through completely unfiltered. This is by design, as clients like curl and other headless implementations don’t have the capacity to run JS. Anubis specifically targets those clients that pose as real browsers but actually aren’t, which tends to be the case with web scrapers that don’t respect the robots.txt standard, which is the case with unscrupulous AI companies. Also, Anubis being a Bitcoin-derived cryptographic algorithm essentially means that the time to solve the challenge is non-deterministic, and the progress bar doesn’t actually show the real progress of the calculation. I find this not very good for UX.

In the future, I might release a post on Anubis specifically, but I don’t want to dedicate this post to that.

Technical Architecture

Vanguard is written in Go with a lightweight JavaScript frontend. The architecture consists of:

Backend (Go): Handles challenge generation, verification, rate limiting, and Telegram API integration
Challenge Generation: Uses crypto/rand for secure prime generation, with a modulus cache (TTL: 60 minutes) to avoid expensive regeneration
Challenge Cache: Pre-generates 5 challenges asynchronously to handle burst traffic without blocking
Rate Limiting: Per-IP sliding window rate limiting with automatic cleanup of expired entries
Frontend (JavaScript): Web Workers for non-blocking PoW computation

The server maintains several concurrent goroutines for cleanup tasks, ensuring memory efficiency and preventing resource exhaustion under load.

DDoS Protection Mechanisms

While Vanguard is still under heavy development, it already implements several DDoS protection mechanisms:

Queue Management: When the challenge cache is depleted, clients are placed in a queue (maximum 10 clients by default). If the queue is full, new clients receive HTTP 420 responses and are immediately rejected to prevent resource exhaustion.
Challenge Pre-generation: The server asynchronously pre-generates challenges to avoid CPU-intensive operations during request handling, preventing computational DoS attacks.
Memory Cleanup: Automated goroutines periodically clean up expired challenges and rate limit entries to prevent memory exhaustion attacks.
Request Validation: Challenges are tied to specific IP addresses and include HMAC signatures to prevent replay attacks and challenge manipulation.

Note that these protections are basic and will be enhanced as development continues. The current implementation focuses on preventing the most common attack vectors while maintaining a simple, auditable codebase.

Current Status and Future Development

Vanguard is actively deployed and protecting several Telegram groups, but it’s important to note that it’s still under heavy development. The codebase shows clear TODOs indicating areas for improvement:

Mutex Optimization: Current mutex usage is coarse-grained and blocks entire data structures. Future versions will implement finer-grained locking for better concurrency.
Challenge Reuse Prevention: The challenge cache tracks used challenges but doesn’t yet implement full garbage collection.
API Endpoints: The v2 API endpoints for timelock challenges are partially implemented and need completion.
Security Hardening: While basic protections are in place, additional layers like browser fingerprinting and risk-based difficulty adjustment are planned.

Where’s the code?

Vanguard is currently being developed in private since there are a few things I want to ensure I got correctly before releasing, like the cryptographic implementation, as well as clean up and reorganise the source code. As I mentioned earlier, Vanguard was initially born as little more than a hack, and the choices I made to shorten development time to hours instead of weeks, will definitely negatively affect the code quality and future maintainability. Now that Vanguard is deployed and has proven to work, it’s time to clean it up and take care of those issues.