When you are a big fan of the Konosuba franchise, you are a bit curious when you spot a malware called “Megumin Trojan” (Written in C++) on some selling forums and into some results of sandbox submissions. Before some speculation about when this malware has appeared, this one is not recent and there are some elements that prove it was present on the market since the beginning of 2018.

Since the last days, there is an increased activity related to a new version that was probably launched not so long ago (a v2), and community started to talk about it, but a lot of them has misinterpretation with Vidar due to the utilization of the same boundary beacon string. This analysis will help you to definitely clarify how to spot and understand how Megumin Trojan is working and it definitely has a specific signature, that you can’t miss it with you dig on it (for both network activities & code).

This malware is a Trojan who has a bunch of features:

  • DDoS
  • Miner
  • Clipper
  • Loader
  • Executing DOS commands on bots
  • Uploading specific files from bots to C&C

It’s time to reverse a little all of that ūüôā

Anti-Analysis Techniques

The classy PEB

This malware is using one of the classiest tricks for detecting that the process is currently debugged, by checking a specific field into the¬†Process Environment Block (PEB). For those who are unfamiliar with this, it’s a structure that contains all process information.

typedef struct _PEB { 
  BYTE Reserved1[2]; 
  BYTE BeingDebugged; // HERE
  ...< Other fields >...
  PVOID Reserved12[1]; 
  ULONG SessionId; 

For our case, the value “BeingDebugged” will be “obviously” checked. But how it looks like when reversing it? Here it’s looking like this.


  • fs:[18] is where is located the Thread Environment Process (TEB)
  • ds:[eax+30] is necessary to have access into the PEB, that is part of the TEB.
  • ds[eax+2] remains to retrieve the value TEB.PEB.BeingDebugged


This one has been used multiple times during the execution process of Megumin Trojan.

Window Title

This other trick used here is to get the title of the program and comparing it with a list of strings. For achieving it, the malware is calling GetForegroundWindow at first for the Windows of the current process and then grabbing the title with the help of GetWindowTextA.



The comparison with the string is done step by step, by decrypting first the XOR string and comparing it with the Window Title, and continuing the functions until every value is checked.

The completed string list :

  • OllyDbg
  • IDA
  • ImmunityDebugger
  • inDb (Remain to WinDbg)
  • LordP (Remains to LordPE)
  • ireshark¬† (Remains to Wireshark)
  • HTTP Analyzer

This technique here is not able to work completely because it’s checking the Windows Title of the current process used and so, some strings won’t be able to work at all. When I was reversing it, I didn’t understand at all why it was done like this, maybe something that was done fast or another unrelated explanation and we will never know.

Dynamic Process Blacklist

When the malware is fully configured, it performs an HTTP POST request called /blacklist. The answer contains a list of processes that the attacker wants to kill whenever the payload is active, the content is encoded in base64 format.

When processes are flagged as blacklisted, those are stored into variables as Process Handles, and they are checked and killed by a simple comparison. For terminating them the ZwTerminateProcess (or NtTerminateProcess if you are looking on a disassembler) API call is used and after the accomplishment of the task, the value on memory is initialized again to -1 for continuing, again and again, to maintain that these processes will never be able to be active whenever the malware is up.


By default, all values are set to -1 (0xFFFFFFFF)

Network interactions list

Megumin is quite noisy, in term of interactions between bots and the C&C, and the amount of API request is more than usual compared to the other malwares that I have  analyzed. So to make as much as possible simple and understandable, I classified them into three categories.

General commands

/suicide Killing request
/config Malware config
/msgbox Fake message prompt window
/isClipper is Clipper activated
/isUSB Is set up to spread itself on removable drives
/blacklist Process blacklist
/wallets Wallet config for the clipper part
/selfDel Removing the payload of the original PE

Bot commands

/addbot?hwid= Add a new bot to the C&C (*)
/task?hwid= Ask for a task
/completed?hwid= Tell the C&C that task has been done
/gate?hwid= Gate for uploading/stealing specific files from bot to C&C
/reconnecttime Amount of time for next request between bot and C&C

(*) Only when the User-Agent is strictly configured as “Megumin/2.0

Miner commands

/cpu CPU Miner configuration
/gpuAMD GPU AMD Miner Configuration
/gpuNVIDIA GPU NVIDIA Miner Configuration

As a reminder, all response from the server are encoded in base64 with the only exception of the /config one, which is in clear.

Curiosity: This malware is also using the same boundary beacon as Vidar and some other malware.

That “messy” setup

This trojan is quite curious about how it’s deploying itself and the first time I was trying to understand the mess, I was like, seriously what the heck is wrong with the logic of this malware. After that, I thought it was just the only thing weird with megumin, but no. To complexify the¬†setup, interactions with the C&C are different between different stages.

For explaining everything, I decided to split it into multiple steps, to slowly understand the chronological order of it.

Step 1

  • In the first request, the malware is downloading a payload named “reserv.exe”. if this file is not empty it means the current payload is not the main build of the malware. reserv.exe is downloaded and saved into a specific folder hidden in %PROGRAMDATA% as “{MACHINE_GUID}” (for example {656a1cdc-0ae0-40d0-a8bb-fdbd603c3b13}),this file at the end is renamed as “update.exe”.
  • Then two or three requests are performed
    • /suicide
    • /msgbox
    • /selfDel (optional)
  • A scheduled task is created with this specific pattern for the persistence, the name of the payload will be “update.exe” and another one on the registry.
    • “Scheduled Updater – {*MACHINE_GUID*}”
  • Then the payload is killed and removed

Reminder: If the malware was not fast enough to download reserv.exe for whatever reasons, it is named by a random windows process name, and will continue the process over and over until it will grab reserv.exe

Curiosity: The way this malware is creating a folder into PROGRAMDATA is strictly the same way as Arkei, Baldr, Rarog & Supreme++ (Rarog fork).







Step 2

  • reserv.exe is again downloaded, and considering the file is empty, so at that time, the correct build for communicating with the C&C.
  • Those requests are performed
    • /suicide
    • /msgBox
    • /config

The config is the only request was the server is not encoding it in base64 format, there are 4 options possible.

Option 1 USB task (Spreading the build on removable drives)
Option 2 Clipper
Option 3 ???
Option 4 ???
  • A scheduled task is created with this specific pattern for the persistence and the name of the payload is at that time a random known legitimate windows process (also same thing on the registry).
    • “Scheduled Updater – {*MACHINE_GUID*}”
  • Then the payload is killed and removed

If this file is empty, it’s considered that it reached its final destination and its final C&C, so seeing two Megumin C&C on the same domain could be explainable by this (and It was the case on my side).

Step 3

  • reserv.exe is always checked for checking if there is a new build
  • Now the behavior on the network flows is totally new. The bot is now way more talkative and is going to be fully set up and registered to the C&C.
    • /suicide
    • /config
    • /addbot?hwid=…&….. # Registration
    • /blacklist
    • /wallets
    • /task?hwid=… # Performs a task
    • … a lot of possible tasks (explained below)
    • /completed?hwid=… # Alerting that the task is done
    • /reconnecttime

For the addbot part, the registration is requiring specific fields that will be all encoded in base64 format.

  • Machine GUID
  • Platform
  • Windows version
  • CPU Name
  • GPU Name
  • Antivirus
  • Filename (name of the megumin payload)
  • Username

example of request (Any.Run)


Step 4

  • reserv.exe is always checked for checking if there is a new build
  • If the bot is run after the registration, it will be possible to have this pattern of request
    • /suicide
    • /config
    • /task?hwid=… # Performs task
    • … a lot of possible tasks (explained below)
    • /completed?hwid=… # Alerting that the task is done
    • /reconnecttime

Fake messages

As shown above, the malware has also a feature to prompt a fake window and this could be used for making “some realistic scenario” of a typical fake software, crack or other crapware, lure the user during the execution that the software has been installed or there is an error during the false installation or execution. It’s really common to see nowadays fake prompt window for missing runtime DLL, or fake Fortnite hack or whatever Free Bitcoin trap generator, this kind of lure will always work in some kind of people, even more with kids.

For configuring the feature, the bot is sending a specific HTTP POST Request named “/msgbox” and After decoding the base64 response from the server the response is split into multiple variables :

  • An integer value that will represent the Icon of the Window
  • A second int value that will represent the buttons that will be used
  • The caption (Title)
  • The text that will be printed on the prompt window


Corresponding case input codes with the configuration of the prompt window are classified below:

uType – Uint Code – Icons – cases

Case Code Value Meaning
1 0x00000020L Question-mark message box
2 0x00000030L Information message box
3 0x00000040L Warning message box

uType – Uint Code – Buttons – cases

Case Code Value Meaning
0 0x00000002L Abort, Retry & Ignore buttons
1 0x00000006L Cancer, Try Again, Continue buttons
2 0x00004000L Help button
3 0x00000000L OK button
4 0x00000001L OK & Cancel buttons
5 0x00000005L Retry & Cancel buttons
6 0x00000004L Yes & No buttons
7 0x00000003L Yes, No & Cancel buttons


Before that the malware is executing the main module, all the regexes that will be used for catching the whished data are stored dynamically into memory.


Then when the malware is fully installed if the clipping feature is activated by the config request, another one called “/wallet” is performed. This command gives to the bot the list of all wallet configured to be clipped. the content is base64 encoded.

At this point,  the classy infinite loop like Qulab is performed and will remain the same until the program is killed or crashed.

  1. The content of the clipboard is stored into a variable.
  2. Step by step, all regexes are checking if it matches with the clipboard.
  3. If one regex triggers something, the content on the clipboard is switched by the one that the attacker wants and some data are sent to the C&C.

The whole process of the clipper is representing like this.




















For some investigation, this is the complete list of wallets, softwares, and websites targeted by this malware.

Bitcoin BitcoinGold BtcCash Ethereum
BlackCoin ByteCoin EmerCoin ReddCoin
Peercoin Ripple Miota Cardano
Lisk Stratis Waves Qtum
Stellar ViaCoin Electroneum Dash
Doge LiteCoin Monero Graft
ZCash Ya.money Ya.disc Steam
vk.cc QIWI


When the bot is sending a request to the C&C, there is a possibility to have nine different tasks to be performed and they are all presenting like this.


There are currently 3 main fields for the tasks.

  • DDoS
  • Executing files
  • Miscellaneous

Whenever a task is accomplished, the request “/completed?hwid=” is sent to the C&C. The reason for this is simple, tasks can be counted and when it reaches a specific amount, the task is simply deactivated.

Let’s reviewing them!



Socket HTTP

Task format


When there is a necessity to create threads for performing the DDoS tasks, it only grabs the specific fields and using it a length for a thread loop creation as shown below, lpStartAddress will contain the reference of the specific DDoS function that the bot has to do.


When inspecting it the function, we can see the layer 7 DDoS Attack by flooding the server by HTTP GET requests with the help of sockets.


When everything is configured, the send function is called for starting the DDoS.



Task format


As explained above, the technique will remain always the same for the thread setup, only the function addressed is different. For the HTTP DDoS task, it’s another Layer 7 DDoS Attack by flooding the server with HTTP requests by using the methods from the Wininet library :

It’s slower than the “socket” tasks, but it used for the case that the server is using 301 redirects.


Task format


The TCP task is Layer 4 DDoS Attack, by performing spreading the server TCP sockets requests with a specified port.


JS Bypass

Task format


When the website is using Cloudflare protection, the malware is also configured to use a known trick to bypass it by creating a clearance cookie for not being able to be challenged anymore.


The idea is when it’s reaching for the first time the Website, a 503 error page will redirecting the attacker into a waiting page (catchable by the string “Just a moment” as shown above), At this moment Cloudflare is, in fact, sending the challenging request,¬† so a¬†__cfduid cookie is generated and the content of the source code on this page is fetched by the help of a parser implemented in the malware. It needs 3 parameters at least, 2 of them are already available :

jschl_vc the challenge token
pass ???

The last field is the jschl_answer, as guessable this is the answer to the challenge asked by Cloudflare. To solve it, an interpreter was also implemented to parse the js code, catching the challenge-form value and a.value field for interpreting correctly the native code with the right setup.

This process shown as below is the interpreter that will analyze block per block the challenge with the help of a loop, the data is shelled and each block will be converted into an integer value, the sum of all of them will give us the jschl_answer value.


so at the end of the waiting page, this request is sent:


chk_jschl leads to the cf_clearance cookie creation if the answer to the challenge is correct and this cookie is proof that you are authentic and trusted by Cloudflare, so by keeping it bypasses for the next requests sent, the website will no longer challenging the attacker temporarily.

Miscellaneous curiosities

the default values for DDoS tasks are :

Time 180 (in seconds)
Threads 2500
Port 42



Task format


Seeing a loader feature is something that a quite common thing by the current trendings, customers that bought malware wants to maximize their investments at all cost. This trojan is also configured to pushed some payloads. There is nothing much to say about this. The only important element, in this case,¬†it’s that the loaded payload is stored into the %PROGRAMDATA% folder with the name of {MACHINE_GUID}.exe.

Load PE

Task format


Contrary to a simple loader feature, this one is typically a process hollowing alternative. It’s only working with 32 bits payload and using this classy process injection trick into a legitimate process.


For some reasons, the User-Agent “Mozilla/5.0 (Windows NT 6.1) Megumin/2.0” is catchable when it’s downloading the payload on this specific load PE task.

More information about process injections techniques here


Task format


When there is an update required with the malware, there is a possibility to push a new build to the bot by using this task.

Miscellaneous tasks


Task format


One of the miscellaneous tasks possible is the possibility to send some cmd commands on the bot. I don’t have a clue about the necessity of this task, but if it’s implemented, there is a reason for that.


Complete list available here


Task format


If the attacker knows exactly what he’s doing, he can steal some really specific files on the bot, by indicating the full path of the required one. The crafted request at the end will be on that form, for pushing it on the C&C.



The miner is one of the main features of the trojan. Most of the time, When analysts are reversing a miner, this is really easy to spot things and the main ideas are to understand the setup part and how it’s executing the miner software.

At the end for future purposes, I am considering their check-up list as relevant when reversing one:

  • Is it targeting CPU, GPU or both?
  • If it’s GPU, is Nvidia & AMD targeted?
  • Is it generating a JSON config?
  • What miner software is/are used
  • Are there any Blacklist Country or Specific countries spotted to mine?
  • What are the pools addresses?

On this malware, Both hardware type has been implemented, and for checking which miner software is required on the GPU part, it only checking the name of the GPU on the bot, if Nvidia or AMD is spotted on the text, request to the C&C will give the correct setup and miner software.


The base64 downloaded miner config contains two things:

  • The link of the miner software
  • The one-line config that will be executed with the downloaded payload by the help of ShellExecuteA

For some reasons, the User-Agent “Mozilla/5.0 (Windows NT 6.1) Megumin/2.0” is only catchable when it’s downloading the miner software for the CPU part, not for the GPU.


Login Page

The login page is quite fancy, simplest. Even if I could be wrong of with this statement, it’s using the same core template as Supreme++ (Rarog Fork) with some tweaks.

Something interesting to notice with this C&C, that there is no password but a 2FA Google authenticator on the authentication part.



There is not too much to say about the dashboard, its a classy stats page with these elements:

  • Top Countries
  • New bots infected (weekly)
  • Bots Windows Chart
  • Number of bots online (weekly)
  • Bots CPU chart
  • Bots GPU chart
  • Platform chart
  • AV Stats
  • Current cryptocurrencies values
  • Top stolen wallet by the clipper



  • Bots – Current list of bots
  • Tasks – Task creation & current task list
  • Files – All files that have been uploaded to the C&C with the help of the task “upload”


Task setup

Tasks that I’ve detailed above are representing like this on the C&C, as usual, it’s designed to be user-friendly for customers, they just want to configure fast and easily their stuff to be able to steal & being profitable quickly as possible.


When selected, there is a usual configuration setup for the task, with classy fields like :

  • Task Name
  • Max Executions routine
  • If the Task must be designed for targeting only one bot
  • And an interesting advanced setting tab


If we look at it, the advanced setting is where the C&C could targeting bots by :

  • Specific hardware requirements
  • Platform
  • Countries

Countries can be easily catchable on the Victim machine by checking the Locale of the Keyboard (I have already explained this tick on Vidar) and the IP.


So it means that malware could be designed to target highly specific areas.

When the task is completed, its represented like this.








  • “USB Spreading” remains to /isUSB API request
  • “Del exe after start” remains to /selfDel API request


Clipper is quite simple, it’s just the configuration of all wallet that will be clipped.



The miner tab is quite classy also, just a basic configuration of the config and where it will download the payload.


As usual, the process blacklist will remain the same as we saw in other miner malware. Some google search will be sufficient to know which processes are the most targeted.


A fancy message box configuration part with multiple possibilities.



It’s also possible to ban bots from specific countries, on the side bot side, the malware will check if the country is valid or not with the help of the IP and the Keyboard Language configuration.


On the code, it’s easily traceable by these checks, for more explanation about how it works for the keyboard part, this is already detailed on the Vidar paper.


For some reasons, there is also a possibility to change the username for the panel authentication, by doing this the 2FA Google Authenticator is required for confirming this.



For further investigation about this v2, I developed a small script called “ohana”, like the Vidar one to extract the configuration of each sample and it’s already available on my GitHub repository.




  • d15e1bc9096810fb4c954e5487d5a54f8c743cfd36ed0639a0b4cb044e04339f
  • e6c447c826ae810dec6059c797aa04474dd27f84e37e61b650158449b5229469
  • c70120ee9dd25640049fa2d08a76165948491e4cf236ec5ff204e927a0b14918
  • d431e6f0d3851bbc5a956c5ca98ae43c3a99109b5832b5ac458b8def984357b8
  • ed65610f2685f2b8c765ee2968c37dfce286ddcc31029ee6091c89505f341b97
  • 89813ebf2da34d52c1b924b408d0b46d1188b38f035d22fab26b852ad6a6fc19
  • 8777749af37a2fd290aad42eb87110d1ab7ccff4baa88bd130442f25578f3fe1


  • 90551.prohoster.biz
  • baldorclip.icu
  • santaluisa.top
  • megumin.top
  • megumin.world


  • C:\Users\Ddani\source\repos\MeguminV2\Release\MeguminV2.pdb
  • C:\Users\Administrator\Desktop\MeguminV2\Release\MeguminV2.pdb

Threat Actors

  • Danij (Main)
  • Moongod



rule Megumin : Megumin {
    description = "Detecting Megumin v2"
    author = "Fumik0_"
    date = "2019-05-02"

    $mz = {4D 5A}

    $s1 = "Megumin/2.0" wide ascii
    $s2 = "/cpu" wide ascii
    $s3 = "/task?hwid=" wide ascii
    $s4 = "/gate?hwid=" wide ascii
    $s5 = "/suicide" wide ascii

    $mz at 0 and (all of ($s*))


Megumin Trojan is not a complicated malware but about all the one that I have reversed, this is the most talkative one that I’ve analyzed and possesses a quite some amount of tasks. Let’s see with the time how this one will evolve, but it’s confirmed at that time, there is currently a lot of interesting stuff to do with this one :

  • in term of analysis
  • in term of cybercrime investigation



Special Thanks: S!Ri

Photo by Jens Johnsson on Unsplash

Last modified: May 6, 2019



Leave a Reply