by Robin Dost
I recently took a look at the wave of MuddyWater malware samples from 2026 and came across something interesting I wanted to share.
The sample I analyzed (SHA256: “81a6e6416eb7ab6ce6367c6102c031e2ae2730c3c50ab9ce0b8668fec3487848“) turns out to be LampoRAT, as already described in Unite42’s article.
According to previous analysis, the malware was developed on a workstation named “Jacob” more on that in my earlier post.
I won’t go into full detail about the RAT itself, that has already been covered extensively.
I’ll link a few relevant articles below if you’re interested.
Right now my focus is more on actor-centric detection, specifically identifying infrastructure early rather than chasing IOCs after the fact.
Quick overview
The malware uses the Telegram Bot API as a command-and-control channel.
After infection, the client connects to a hardcoded bot token and waits for commands from the operator.
Received commands are executed locally via the Windows shell, and the results are sent back to the attacker via Telegram.
Because all of this runs over legitimate HTTPS traffic to Telegram, it blends in much better than traditional C2 infrastructure.
The interesting part
The actor uses a bot with the username:
stager_51_bot
In offensive operations, a stager is typically a small initial payload that establishes a foothold and then pulls in additional components.
The “51” immediately suggests some form of sequential usage and that’s where things get interesting.
Enumerating the pattern
I wrote a quick script to check which usernames of the form:
stager_X_bot (1 ≤ X ≤ 100)
are actually registered.
We don’t even need a Telegram account for this.
Instead, we can abuse the way Telegram’s web interface behaves and completely avoid the API.
If a username exists -> it shows up
If not -> it doesn’t
Simple as that.
Since stager_51_bot is currently offline, here’s how it looks:
Username not taken:
Username not taken:
If the user exists, the username is highlighted as the page title.
for x in {1..100}
do
res=$(curl -s https://t.me/stager_$x\_bot | grep "tgme_page_title")
if [ -n "$res" ]; then
echo "Bot exists stager_$x\_bot";
fi
sleep 3
done(The sleep is just there to avoid rate limiting)
Results:
I then pulled the Telegram IDs for all identified bots and built a small table:
| Username | Telegram ID | Display Name | Still Active |
| stager_51_bot | 8398566164 | Olalampo | No |
| stager_55_bot | 8468064242 | stager_55bot | Yes |
| stager_56_bot | 8372926576 | foltinao\ | Yes |
| stager_58_bot | 8466129060 | Nikoro | Yes |
| stager_59_bot | 8331208203 | hayday | Yes |
| stager_60_bot | 8128190363 | clash | Yes |
| stager_61_bot | 8357834418 | Asus | Yes |
| stager_62_bot | 8405262043 | apple | Yes |
| stager_63_bot | 7824201354 | bot | Yes |
| stager_64_bot | 8236964013 | active | Yes |
Observations
At first glance, it looks like these bots are sequentially created starting at around stager_51_bot.
But once you look at the Telegram IDs, things don’t line up.
While Telegram IDs generally increase over time, they do not match the numeric order of the bot names.
Bots with higher numbers are not necessarily newer, and some appear to have been created earlier despite their naming.
This strongly suggests that the naming scheme is not tied to creation order, but maybe controlled by the operator most likely as part of internal tooling or campaign logic.
Another interesting detail is the display names:
- Random-looking words like Olalampo, Nikoro, foltinao
- Game-related names like HayDay and Clash
- Generic words like apple, bot, active
Nothing conclusive here just… weird enough to notice.
Also worth mentioning:
When putting Olalampo, Nikoro or foltinao into a translator, it consistently suggests the same language, despite there being no real translation ^^
No idea if that means anything. Probably nothing. Still interesting.
Attribution (or lack of it)
There is currently no definitive proof that all identified bots belong to the same campaign or actor.
The observed connections are based on naming patterns and timing and should be treated as a hypothesis, not a confirmed attribution.
And that’s important.
Why this matters
The interesting part here is not a single bot.
It’s the pattern.
Instead of looking at individual IOCs, we’re seeing a reusable naming and infrastructure scheme, something that can potentially be tracked and predicted.
Detection / Prevention
Looking at the Telegram requests generated by the RAT, we can already preemptively block known infrastructure.
Example request:
https://api.telegram.org/bot8398566164:AAEJbk6EOirZ_ybm4PJ-q8mOpr1RkZx1H7Q/GetWebhookInfo (Token is invalid, don’t bother)
Since we have multiple bot IDs, we can derive detection patterns like:
| https://api.telegram.org/bot8468064242.* |
| https://api.telegram.org/bot8372926576.* |
| https://api.telegram.org/bot8466129060.* |
| https://api.telegram.org/bot8331208203.* |
| https://api.telegram.org/bot8128190363.* |
| https://api.telegram.org/bot8357834418.* |
| https://api.telegram.org/bot8405262043.* |
| https://api.telegram.org/bot7824201354.* |
| https://api.telegram.org/bot8236964013.* |
But more importantly:
Instead of blocking static IOCs, we can move towards pattern-based detection, for example:
- monitoring Telegram API usage
- correlating with suspicious bot naming schemes
- identifying unusual communication patterns
Long term, this is far more robust than chasing individual indicators.
Final thoughts
I’ve been experimenting with different tracking techniques to identify patterns like this earlier.
To make that easier, I built a platform that helps me to automate exactly this kind of analysis.
More on that soon, releasing on Monday :3
Conclusion
The observed naming and infrastructure pattern shows that even simple components like Telegram bots can be used to build reusable and scalable C2 infrastructure.
Even without definitive attribution, analyzing these patterns allows early identification of potential infrastructure and enables proactive detection and blocking.
The real value here is the pattern behind it.
More References
https://unit42.paloaltonetworks.com/boggy-serpens-threat-assessment