Skip to main content

LOLSnif Malware

A boringly deep analysis of a very complex VBS Malware dropper

A code snippet of the script

LOLSnif is a new(ish) variant of the common trojan Ursnif.

Here, we take a look at the very complex and heavily encoded/obfuscated script that drops the malicious DLL on the victim machine.

Apologies if it gets a bit boring, I’ve crammed in too much stuff here. Feel free to skip sections that are of less interest.

It all starts the usual way, phishing email brings in a link that serves the initial script. The script itself has the malware in it, which is dropped on the victim machine on successful execution.

This script has a lot of anti-analysis, anti-sandbox features that are clever and heavily encoded which makes them well-hidden.

Let’s take a step-by-step look at this malware:

There are more than 500 lines of code in the script and most of those lines have thousands of chars in them. This is a very long script, based on those numbers alone.

A lot of that is garbage, as is common with scripting malwares. What makes this one more complex than your average malware, is the lengths this author(s) has gone to in order to hide the code and make it hard to analyse.

For the purpose of this analysis (as with most of my work), we will analyse it dynamically and we’ll be clever in our approach. We will disable the anti-analysis features one by one and then make the malware execute the way we want. We will then record all the relevant actions and examine the results to form a complete analysis for Incident Response.

Anti-Sandbox features

This malware has a few tricks that allow it determine if it’s being executed in a sandbox — these are highly effective tricks and I can confirm that it evades analysis by major sandboxing solutions available in the market.


Image for post

Let’s take a look at the function above.

The malware creates a WMI instance to query information in the cimv2 category for the local machine. This can be used to run queries on WMI, which is structured in classes.

Next, it uses a select statement to extract all info from the Win32_Processor class (table) and then goes ahead with querying the ‘NumberOfCores’ field.

The malware is trying to query the number of cores on the victim machine. Once it has that number, it runs it against am If statement:

If luck.NumberOfCores < (95 + (-((10 + 138.0) - (81 + (-25.0))))) Then
onomatopoeia = True
End If
If onomatopoeia Then
End If

From the code snippet above, (95 + (-((10 + 138.0) — (81 + (-25.0))))) equals ‘3’.

So if the number of cores is less than 3, the condition is ‘True’. If true, the program runs the function ‘DCZwCUL’, which (we’ll see later) exits the program. It gives you a fake message about a missing ‘MSVCR102.dll’ which in reality doesn’t exists (try googling it).

Tip: Increase the number of cores to your VM to 4 or more and you'll bypass this feature. 


Image for post

In this function, the malware tries to query the physical memory of the victim machine. It again uses the WMI classes for this purpose.

This time it queries the ‘Win32_ComputerSystem’ field.

If the physical memory is less than 1030 Mb, it terminates execution.

Tip: increase the memory of your VM to more than 1030 and you'll successfully bypass this feature. 

Common Analysis Tools

Personally, I like this list of common tools these malware authors use for anti-analysis techniques. I get to see a few new ones every now and then and I add them to my arsenal :)

Image for post

As you can see, the list above is quite comprehensive. Basically, the malware checks if you’ve got any of these tools running on your analysis machine and if it finds any of the ones listed in the function’s array, it terminates execution.

This function works flawlessly. I tested it by running a couple of these tools on the machine (procmon, procexp) and it identified those and terminated the program.

Tip: You can have these tools on your analysis machine, just make sure they are not running at the time of analysis - most of these are portable executables. I've written this quick script that tells you if any of these are detectable on your system. Run this script and see if any of these are detected. You'll have to terminate the detected tools to bypass this feature.

Logical Volume Size

Image for post

Another trick the malware uses is the size of the logical volumes on your analysis machine. In the above code snippet, you can see that the malware terminates execution if the size is less than 60 Gb. Most VM’s are less than that (especially in commercial cloud-based sandboxes).

Tip: If you can have a vm with a logical volume size of more than 60 Gb, you'll be able to bypass this feature completely. 

Number of files in certain folders

Image for post

This is another neat trick by the authors. The malware checks a couple of directories to see how many files are in them to make sure it’s not an analysis machine the malware is running on.

The two directories it checks are:


Here’s how it works:

The function declares two variables, to be used for comparison purposes later in the function.

PsRTozXY = (622 — ((10 + (39 + 2901.0)) — 2331.0))
(622 — ((10 + (39 + 2901.0)) — 2331.0)) = 3
PsRTozXY = 3

PsRTozXY_download = (397 — ((88 + (-25.0)) + (81 + 250.0)))
(397 — ((88 + (-25.0)) + (81 + 250.0))) = 3
PsRTozXY_download = 3

If CreateObject("Scripting.FileSystemObject").GetFolder(ibrdYdE).Files.Count < PsRTozXY Then
End If

ibrdYdE refers to another function in the program:

Function ibrdYdE()
ibrdYdE = CStr(WScript.CreateObject(“Scripting.FileSystemObject”).GetSpecialFolder(((16 + (-11.0)) + (-((81 + (-49.0)) + (-29.0))))) + “\”)
End Function

ibrdYdE returns the special folder — ‘\temp\’ based on the function above.

GetSpecialFolder(((16 + (-11.0)) + (-((81 + (-49.0)) + (-29.0))))) + “\”)

‘(((16 + (-11.0)) + (-((81 + (-49.0)) + (-29.0)))))’ = 2; 2 returns ‘\temp’

So, if there are less than 3 files in the ‘temp’ folder, terminate execution.

The second folder is the \Downloads\ folder, which is easier to see in the code itself:

sallow = fkvQdFqe.ExpandEnvironmentStrings("%USERPROFILE%") + "\Downloads\"

Again, if there are less than 3 files in the Downloads folder, terminate execution.

Tip: Just put some random files in the Downloads folder, the malware just checks the number of files not the type of files or extensions. In the 'temp' folder (c\users\yourUser\appdata\local\temp) there should be more than 3 files usually by default.

So, as you can see, quite a few anti-analysis, anti-sandbox features in this malware and all well-written.

Terminate Function

Now that we’ve had a look at all the anti-analysis functions in the malware, let’s quickly take a look at the function that is used to terminate execution of the malware.

Image for post

From the code above, you can see that once the function is called, it calls three other functions and then terminates the program using ‘WScript.Quit

The first function it calls is Crete():

This function doesn’t lead to anything, no requests are made.

The second function is kZDlOhis():

Image for post

This function deletes the malware from the temp folder.

The last function is frank():

This function displays a misleading message, about a missing DLL that actually doesn’t exists, its a made-up file.

Image for post

After this, the program terminates.

Execution after bypassing the anti-analysis checks

Now that we know how to bypass the anti-analysis checks, let’s take a look at how the malware actually executes.

This function does most of the work for the malware:

Image for post

What’s happening in this function is this:

  1. Create the Object ‘ADODB.Stream’ — which in this case is used to write the binary data (the actual malware DLL) to the disk.
  2. Define the Charset of the data to be written
  3. Read through all the arrays supplied in the script with the binary data
  4. Write all that data to the file “” using the ‘SaveToFile’ function
  5. Position is ‘0’ which means, re-write if file already exists
  6. Close the file
Image for post
The archived files dropped on the disk as ‘’

As you can see, all the values in Array are the arrays in the script, with the data to be written. Here’s an example:

Image for post

This is the function that loads the DLL and executes it:

Image for post

As you can see, it uses rundll32 to load the malicious dll. The malicious dll is ‘do343.scss’.

The malware also creates a URL file in the temp folder — this can be used as an IOC. It is linked to

Image for post

Malware DLL

Now that we know how to bypass all the anti-analysis techniques this malware uses and how to execute the malware in our analysis machine, let’s get to the final DLL that is the malware LOLSnif.

Among other commonly seen malware functions, this malware also reaches out to the C2 and tries to post the victim machine information.

Image for post
System Info being sent to the C2

The DLL in this case works with DGA as we can see with all these requests that are being made:

Image for post
C2 connections


The dropper for this malware is very complex. The authors have gone to great lengths to make it as hard as possible to analyse the code. There are layers and layers of encoding and obfuscation. To analyse it, you need to peel back each layer one by one, right to the end where it reveals the final payload, the malicious DLL.



At the time of this publishing, these are some of the Hashes for the LOLSnif DLLs:










HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections\SavedLegacySettings

URL Substring:

The best IOC to block if possible is this URL sub-string, it should cover the bulk of the campaign:



These are DGA generated so I’, putting these in here only for context.,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,URL,mitre/spearphishing-link,ursnif,vbs,,,,,,,,,,,


Popular posts from this blog

Grinju Downloader: Anti-analysis (on steroids) | Part 2

  This malware takes anti-analysis and stealth techniques to a new level We took a look at this malware in the Part 1 of this publication. Now let’s carry on with the analysis and dig deeper into the various anti-analysis and stealth-exec features of this malware in Part2. Malpedia Inventory: Secondary Macro Code First of all, here’s the entire code that is dumped in the sheet once all the macro functions have been completed. Take a look at these lines and try to figure out what they are meant to do. Then we’ll take a look at the most important of these briefly before moving on to the next section. =CLOSE(FALSE) =FORMULA(LEN(APP.MAXIMIZE())+-459,Sheet1!R18690C129) =FORMULA(LEN(GET.WINDOW(7))+-131,Sheet1!R18691C129) =FORMULA(LEN(GET.WINDOW(20))+-893,Sheet1!R18692C129) =FORMULA(LEN(GET.WINDOW(23)=3)+433,Sheet1!R18693C129) =FORMULA(LEN(GET.WORKSPACE(31))+864,Sheet1!R18694C129) =FORMULA(LEN(GET.WORKSPACE(13)>770)+707,Sheet1!R18

Grinju Downloader: Anti-analysis (on steroids) | Part 1

  This malware takes anti-analysis and stealth techniques to a new level Malpedia Inventory: I’ve come across some great anti-analysis code in malware over the years. This one takes the top spot. On that note, let’s get into it, this is a long one! Since this malware employs a very complex structure, I’ve decided to divide the analysis into different sections. I’ll try to keep it as simple as possible but having said that, it really is a very complicated project. Hence, publishing in parts. TLDR: This is a very well-thought and equally well-written malware. There’s no VBA that you can analyse. The values and formulas that are used are spread across the worksheets to thousands of rows. The functions, among other things, are used to close the file, corrupt it and also delete the dropped scripts to make analysis extremely hard. In fact, you cannot analyse this malware without altering the code it self. Along the way, you’ll also

TrickBot C2i and Configs March 2019

There are some new additions in the latest target list. These are the targeted URIs extracted from the complete configs. Some of the regex'd URIs are very interesting and highly effective. Article by  Vishal Thakur C2: Target list: <lm></lm> <lm></lm> <lm>*.aspx*</lm> <lm>*.aspx*</lm> <lm>https://www.ulsterbankanytimebanking.