One of the top samples send to app.any.run is tagged as #NanoCore. Because of that I wanted to have a look inside this malware. At first I run the sample under VM. Except some calls to Windows registry I have not found any interesting behavior. Then I run this sample under OllyDBG.

Since I could not find IsDebuggerPresent() import nor “VBox” related string which can stop malware from running on virtual vm I debugged the code from entry point. After I while I stuck in one of the calls that made process terminate.

Green arrow shows that this is a loop which calls function pointed by eax register and eax value is calculated as edi+ebx+8. In this case ebx is just counter incremented every time loop goes by. Edi however stores address where offsets of functions to be called are stored. Let’s check it.

So now it will be worth to check those calls, what they really do. While debugging I figured out that this is how this binary works. There is the table with functions pointers(their offsets) and then those pointers are loaded into eax register one by one then the code within particular address is executed. This will cause automatic Ida analysis to fail since Ida will not follow this trick. It is a nice technique to obfuscate the whole binary code in it.

I would image that in the source code the whole concept of those functions pointers global table containing pointers to functions that have no arguments and return no value at all.

Since I wanted to the network part of the code I was looking for some imports to WS32 library, but nothing was there. So I went through strings and there they are. Maybe library was statically linked with the malware code?

Also while running the binary I have not seen any traffic the was going to or from Internet under Wireshark. It could be environmental issue since I route the traffic from infected virtual machine to the Tor network using pfSense router as it was suggested by MalwareTechBlog but I have a feeling that the malware does not want to run on vm properly. It shuts down after a while and do not start any process or create any files in some weird places.

Debugging system call

Since I could not find out much while debugging those calls I have set breakpoint on KiFastSystemCall to check what syscall are called and what are parameters they are called with.

So it seems like nanocore tried to load some dll called nanocore.ENU.DLL and then also nanocore.ENU. Since it cannot found those it continued its work. Okay, still nothing interesting in here.

I decided to check why the process exits in a different way. This time I did investigation from the end, so I look for ExitProcess() calls in Ida. Below you can see entry point for nanocore.exe. The first breakpoint is set on the call which leads to the function which calls functions from the table that I have mentioned above(table of function pointers). The second one is the call which leads to ExitProcess() call. The problem is that I cannot reach the second breakpoint. I cannot reach even the code just after first breakpoint, so something terminates process within the context of the first call.

Since I cannot do much with this sample – did see any malicious behavior I leave it for now. The sample is 00219abf75eaba610d6e6001d1e1c204(md5).

Another sample – AutoIt packed script

I got another sample tagged as #nanocore from any.app.run and this time it seems like it tries to connect to somewhere in the network, at least there are some dns requests – this is what any.app.run shows in their analysis.

This time this is UPX compressed PE32 executable, at least this is what file command stands for. I have loaded the binary into OllyDBG, but it did not work. I landed in some random bytes section which cannot be executed. Because of this I was wondering what protection mechanism was used this time to make the reverse engineering harder.

OllyDBG cannot execute this line because it wants to read __security_cookie value from the memory(address=0x4c7480) that it cannot – I got access violation exception. I have tried to fill this opcode with NOPs, but after few opcodes there is another try to read to this memory which cannot be accessed, so it will not be the ideal solution to solve it this way. I got back to the static analysis going more carefully through strings and I have found out such message.

I have not heard of AutoIt since now. Googling leaded me to AutoIt site. So what is AutiIt, let’s follow their site.

AutoIt v3 is a freeware BASIC-like scripting language designed for automating the Windows GUI and general scripting. It uses a combination of simulated keystrokes, mouse movement and window/control manipulation in order to automate tasks in a way not possible or reliable with other languages.

Having this in mind and the thing that nano is Remote-Administration-Tool I am connecting dots and that leaded me to the conclusion that NanoCore could be using AutoIt for remote administration on particular machine to not implement the whole system integration logic. Also below you can find lots of references to strings. While I search for those strings it leaded me to AutoIt docs.

In AutoIt docs there is a description of TrayItemSetState() function call. Also other calls can be found there. Worth to note it. Then I found that there is a tool to switch from exe to AutoIt source code, which is basically BASIC script.

I used myaut2exe decompiler to extract this code from binary. It seems like this script is highly obfuscated one. Also string seems to have pretty weird encoding.