After the first two parts here and here, we can move forward giving the sample a run inside a disassembler to look what's inside and, eventually, into a debugger to see it live.

IDA has some difficulties to analyze the sample due to the facts it heavily uses anti-disassembly trick:

Note that the conditional jump to 41062E never gonna happens. We can patch those bytes \xF8\x72\x01 with NOP instruction or leave them alone knowing the fact that IDA can be fooled during analysis. Also at 41062F the sample delays its execution, invoking GetTickCount function and dividing the remainder of the DIV instruction by a predefined constant. So until the CMP instruction is satisfied it will run this bunch of code a pseudo-random number of times. It appears that this technique can trick some antivirus heuristic controls.

After condition is verified, the flow reaches the CALL instruction at 4105c3, we see another anti-disassembly technique, the misaligned PUSH instruction.

Clearly the misaligned PUSH at 4105c7 is there to fool the disassembler and we need to fix it if we want to have a better look on that piece of code. By defining manually that byte at 4105d0, IDA can now better analyze the code:

Now it's clear what this piece of code does: it pushes the address of the function at 4105a2 onto the stack. This pointer will be the argument of SetUnhandledExceptionFilter function that, in the end, will exit from the process in case of unhandled exception.

Let's focus on what happens at address 410508, because it's where the fun starts:

After some studies I tried to interpret that code and the results are shown below.

Basically malware is starting its activities: first it loads libraries with the OleInitialize and LoadLibraries calls, after it fires up a delayer routine that, in malware intentions, will fool the heuristic controls of Kaspersky Antivirus. After that it enable some required privileges with the fourth call:

This routine will cycle through and enable all these privileges:

And after that it tries to get if the process is running within LocalSystem or not. In both cases it will impersonate or the LocalSystemUser or the LocalUser using the API call to GetUserNameA.

In the next session we'll go deeper into the analysis trying to better understand its codebase.

After we were able to unpack the sample like we did in the previous post, it's time to understand what the malware is intended to do. The very first thing that I normally do is to give the sample a dry run inside a dedicated virtual machine, just to observe its behavior and monitoring its API calls. These calls can be monitored with a little tool called ApiLogger - that can be found here and it's automatically installed by the Flare-vm script.

The API logger works by injecting a DLL into the target process. Once loaded, the DLL will insert a series of detours style hooks into specific API calls. When these API are accessed by any code in the process, they will trigger a notification message which gets sent to the main interface.

It's clear that malware tries to steal informations (probably credentials) of various software via calls to RegOpenKeyA and RegOpenKeyExA:

And at the end of the run, it tries to connect to the domain singatradeing.com:

We can catch this connection with another great tool from FireEye, FakeNet-NG that will capture and fake responses to all the queries DNS and HTTP  requests, saving all activities into a pcap file that could be analyzed with Wireshark:

We can see that the malware resolved the domain name singatradeing.com with a query DNS (that is faked by FakeNet-NG):

And sent an http GET request to: http://singatradeing.com/espnphp/coreserver/shit.exe

Our fake response served an executable file that was run by the malware:

After that, the malware deleted itself. For this reason, remember to make a copy of the sample executable.

I wasn't able to download the real executable (shit.exe) but I'm sure it will be easy to find it.

More informations related to that domain can be found here.

Recap

The malware sample, when it runs, tries to steal credentials from the registry keys, tries to download another executable and run it, deleting itself at the end.

During my day by day job, I had the chance to came across a mail that was blocked by an antispam platform. Attached to this mail there was a sample recognized as a variant of Pony Stealer malware. Since I've been greatly interested into malware analysis in the last few months, I thought it would be fun, and also a useful exercise, to apply all the notions I've been reading so far and writing this post, maybe, would help me in fixing methodologies and concepts. I hope this will be a two parts blog post: during this first part I will focus on unpacking the malware, during the second one I'll try to analyze its real behavior. Let's the journey begin.

Noob alert

First things first: I'm no expert at all. This is my first experience in reversing malware - and also in blogging something - and so expect a lot of shady things and confused assumptions. Learning something new is always a good idea and I hope that digging into malware analysis will allow me to glue together some skills that I'm trying to learn in the last couple of  years. Also, do not rely on the memory addresses in the screenshots. As this post was written during various sessions, memory addresses changed every time due to operating system memory protections (ASLR).

Lab setup

You can find great tutorials online on how to setup a professional and secure lab to test all malicious sample you get. I'd like to point you out to these useful resources:

• Microsoft Windows 7 and 10 images
• Flare-vm
• Malware Analysis Virtual Machine

Running the sample into online sandbox

Since, right now, I don't have a working setup of Cuckoo sandbox on my behalf, the very first thing I did was uploading the sample into a freely usable sandbox online with these results: http://tinyurl.com/y9gspzmt. As you can see, it labels the sample as a variant of the VBObfus.g family. I didn't find  a lot of informations about this malware family, but dynamic analysis shows me very few indicators:

• No evidence of malware activity into screenshot.
• No network activity.
• Every string is almost obfuscated.
• No extracted files.
• No evidence of process injection.

Important to note, although no clear evidences, the sample is classified as malicious with threat level as 71/100. Pretty strange, uh?

Hybrid Analysis has this great feature: if you click on the sample filename, in this case SKMBT_C36018060720040_pdf.exe, it shows a bunch of useful informations such as API calls used by the executable, registry keys it gets and/or sets during its runtime, filesystem activity, handles opened to files, operating system modules and other kind of libraries it uses. With all these informations we should have a proper level of confidence of what happens during the sandbox run. Let's dig into some of them.

First thing I looked at, was the activity on the filesystem:

No files saved and the infamous msvbvm60.dll caught my attention, but we will deal with this later. Nothing too much interesting into registry section too:

There's a possibility to filter the operations (Query, Open, Write and Delete) but I didn't find anything related to write or delete operations.

The most interesting section is the API calls section. To understand the malware behavior during its run inside the sandbox, it's necessary to analyze what API this sample calls. Following this and this useful resources, I started checking API calls, trying to find any evidence of anti-debug or anti-vm techniques, mainly because there's no evidence of process injection and nowadays process injection is a very, very common technique. After checking all API anti-debug calls found in documentation I was clearly missing something because I wasn't able to find any of them. So it's time to give it a run into my lab and observe its behavior.

Static analysis

Before give it a run, let's check with some basic tools how's the file is built:

So, really we're dealing with a VisualBasic 5/6 executable file.

Let's dig into more details with the executable:

With this great tool we can find some initial informations:

File Version Info Size=1548 -> 060Ch
Translations : 040904B0     Language : English (U.S.)  -  ( 0 4 0 9 )

CompanyName  =  NIrSOft
FileDescription  =  ELEctrum
FileVersion  =  6.02
InternalName  =  Bulbotuber
LegalCopyright  =  LAVasoft
LegalTradeMarks  =  THE ERAser PROject
OriginalFilename  =  Bulbotuber.exe
ProductName  =  ASUs
ProductVersion  =  6.02
Comments  =  Pwa, INA.

Don't know how useful these informations are but, anyway, it's always better to have informations rather than nothing. Assumed that it's a VB5/6 executable file and I don't know how to deal with it inside IDAPro, my next action will be to run it inside my Analysis VM, with the intent to understand better its behavior.

Dynamic analysis

Interestingly it seems to me that, after some sort of unpacking in memory, there is clearly a process injection:

Apparently there must be in place some sort of anti-debug and/or anti-vm tricks. Easily enough in x32dbg there is a life-saving plugin, named ScyllaHide, that is capable of doing some black magic to hide the debugger from malware. We can avoid the process crashing during its run inside the debugger.

We can observe that the sample creates another process with the same name - a copy of itself - and this is typically an indication of the process hollowing.

I won't dig into describing the process injection because there are some great guys that have created very complete and clear tutorials on how to approach this technique. I can suggest this site maintained by this great guy: Sergey and also his Youtube channel here. I strongly suggest to follow all of his videos and tutorials: they are a great way to learn malware analysis and unpacking.

Unpacking the malware

To unpack the malware we'll focus mainly on these three API calls:

kernel32.CreateProcessW

ntdll.NtWriteVirtualMemory

ntdll.NtResumeThread

New process creation

First API call to breakpoint into debugger is kernel32.CreateProcessW, that creates a new process and its primary thread (cit. Microsoft). We're interested in its syntax:

BOOL CreateProcessA(
  LPCSTR                lpApplicationName,
  LPSTR                 lpCommandLine,
  LPSECURITY_ATTRIBUTES lpProcessAttributes,
  LPSECURITY_ATTRIBUTES lpThreadAttributes,
  BOOL                  bInheritHandles,
  DWORD                 dwCreationFlags,
  LPVOID                lpEnvironment,
  LPCSTR                lpCurrentDirectory,
  LPSTARTUPINFOA        lpStartupInfo,
  LPPROCESS_INFORMATION lpProcessInformation
);

And more interestingly, its structure on the stack when its called:

In accordance with the calling convention the function parameters are pushed on the stack in reverse order.  At address 0x0018F460 there's the function fifth parameter dwCreationFlags, with the value of 0x00000004. This value means CREATE_SUSPENDED; we have reached the start of the hollowing process: a new copy of the process has been created in suspended mode.

We can confirm its PID 2660, running the function CreateProcessW until it returns and checking in memory dump the value of the first parameter pushed on the stack at address 0x0018F470 with the value of 0x0643008C:

The new process PID is at address 0x06430094: 0x0A64 that translate into decimal in 2660.

Running the newly created process

We won't bother too much with ntResumeThread API call. Just note that when you reach breakpoint on this call, you know that the malware is ready to run itself (the new copy of itself actually) and, for this reason, you need to be very caution. Just don't let this call run because you're executing the malware itself.

Unpacking the malware

The interesting part: this API call let us to dump the hidden payload stored inside the malware. So, breakpoint on it and let the malware run until it reaches the breakpoint. As before:

NtWriteVirtualMemory(
  IN HANDLE               ProcessHandle,
  IN PVOID                BaseAddress,
  IN PVOID                Buffer,
  IN ULONG                NumberOfBytesToWrite,
  OUT PULONG              NumberOfBytesWritten OPTIONAL );

Basically we're interested in two arguments, in particular: the BaseAddress and the Buffer. These two parameters tell us where the buffer (the malware payload) will be written inside the newly created child's memory. During its run, the malware makes a lot of calls to this function and I single stepped all of them: when breakpoint is reached, analyze the stack:

Focus on the third argument: 0x064B6000 and follow it into the memory dump:

It seems we found something interesting, uh? :-)

We found that a PE file will be copied inside a memory address. Easy to dump it, right now: right click on to that address and follow it into memory map and after that dump that segment into a file.

So we have dumped an entire segment into a bin file. We can open it with an hex editor, scroll down until we reach the start of PE file (MZ magic bytes) and clear all junk from MZ to the beginning of the dump. Save to a new exe file and we're ready to open it with another great tool made by hasherazade: PE Bear. Luckily for us, IAT (Import Address Table) was not corrupted and we can see all the API the (real)malware calls when it runs.

Basically we have unpacked the malware.

I will try to update this post with the second part as soon as I'll figure it out. :-)

This writeup covers the Vulnhub CTF machine named Homeless by Min Ko Ko. Honestly this was a hard box and I had a hard time with some really nasty tricks but finally, I learned a lot. Seriously, a lot.

After booting up victim box and kali, initial phase, as always, is discovering the box:

Box had from my DHCP server address 172.16.10.127

Mapping some ports:

Nothing too much interesting, standard HTTP port and SSH port. What seems interesting is the robots.txt that gives some clue about a special wordlist that eventually will be used in the next phases. But, trust me, we are very far from there right now. :-)

So, time to open up our browser and give a look around. What caught my attention is that somewhere on the page is rendered our browser User-Agent header:

So, instantly, what comes to mind is Shellshock! Sadly I spent two entire days poking around with every single point of injection trying to take advantage of this bug but nothing showed up. Literally nothing. :-\

So I went brutal and I downloaded every single piece of this website and analyzed every single evidence. Very much time but, in the end, well spent:

This small file, favicon.jpg, it’s not the usual one.

Another big trick. What’s this image? What’s his purpose? Again I spent another day analyzing this image without any luck…after a while I tried to insert what is written in that caption “Cyberdog Sledding Portal” inside the User-Agent header and…

So, this little bastard was expecting some password to open it up. Again, bastard!

Back on track again, we need to go to another location: /myuploader_priv. Seems pretty easy uh? Upload a PHP reverse shell and we go in. Sadly, for the second time, no:

I tried to upload every kind of files, of every size, tried changing every single header but nothing. Every file I tried to upload was always too large. I went manually and tried to upload files containing one, two, three characters and so I was able to get the max allowed file size that is 8 BYTES. Seriously? What the f**ck is supposed to mean? No way to upload PHP shells or reverse shells because, as far as I know, the smallest code execution snippet is this: <?=`$_GET[1]`?>. No way to fit in this ridiculously 8 bytes limit. So, how we can step forward? Simple, manually.

So, I found that the only commands we can execute are limited to two characters long, so with <?=’ls’ inside a file named sploit.php we found:

That was hard.

But nothing compared to this:

Ok, I really need a hint :-|

After checking this login form and, in particular, that piece of code I really wanted to die.

How can I suppose to break this one?

Another three days passed and I was asking for some help on every single social media I had. Thanks to this guy that pointed me in this right direction, I found this useful python script that can generate md5 collisions.

But, yeah, it’s not that easy, right?

They’re binary and we can’t send them directly to the HTTP form without encoding problems that, essentially, will break the md5 signature…

Maybe we can try to encode them:

And send them to their good form:

Please, kill me and give me flag…not now:

Basically we have a command execution form:

So we can have a shell via netcat. Luckily we have a good version of it:

And from now on, it’s pretty easy. Standard usual enumerating stuff:

We have a username and we have a good wordlist: Rockyou.txt so we can brute force it. Sadly this was long, very long. But finally we had a shot:

We can now have a real shell with lowpriv access:

Found and fixed a cronjob and modified it to send back a python reverse shell with root privileges:

And finally:

Yeah. Try Harder.