This is the challenge description:
Inside the zip file, we got 2 EXEcutables.
Lets check the 1st one first
Lets try to find information about this EXE file without running it. This is called Static analysis. First, use PEiD and EXEinfo PE.
Nothing. But if we check the PE-header (containing sections information and other useful info) in EXEinfo PE, we’ll find something very interesting.. The resources section (.rsrc) is very big. This is a common character of packed malware.
Also we find that it’s a 32-bit executable from the “Magic” and “Machine type” bits.
What to do next?
Lets check that resources section. We’ll use NTcore’s CFF-explorer. First, lets check out its size.
It’s 0x00083CD8 in hex. That’s 539864 in decimal. 539864 bytes = 539.864 KBs. hmmmm. Lets check what’s making up those 539 KBs.
Other than the EXE’s icons, we have 2 interesting resources. One called “TYPESCR” and the other called “TYPELIB“. Both have the word “type” in their title, so lets call them “SCR” and “LIB” for now. Lets see what’s in them..
The “LIB” has an MZ header (which means it’s a PE file; most probably an EXE or a DLL). and the other one has a strange signature.
Lets dump both of them and check the “SCR” against known file signatures using TrID.
TrID detected the “SCR” file as a VBE file (an encoded VBS file). Lets rename the “SCR” file to “SCR.vbe”, and decode it to VBS using this tool..
Nice. We now have the decoded VBS file.
Lets read it using notepad++.
That’s the flag… vb$_dr0pp3r5_4r3_c0mm0n. We might need to submit it this way
That was pretty easy. We solved this challenge using only static analysis.
Now I want to do 4 more things:
- Check the 2nd EXE file from the challenge’s zip.
- Understand what this VBS file does exactly.
- Re-solve this challenge using Dynamic analysis.
- Find out what the other resource file was. the “TYPELIB” one.
It’s exactly the same..
Analyzing what the VBS file does:
1- It grabs our computer’s username, using this method, then assignes it to a local variable called user (Lines 1-3).
2- Then it checks the value of this “user”.. if it’s equal to “B$1d3s” (which it will probably never be), then it will show you the flag. Otherwise, it will show you the message that says “USERNAME – Try Harder :D” (where USERNAME is the value of that local var user).
Pretty simple and straight-forward.
Re-solving the challenge using dynamic analysis:
Take a snapshot in the VM, and run our tools, then run the v1 EXE.
Quick note: I added some filters to Process Monitor in order to reduce the noise and huge amount of unwanted values.
Once we run it, nothing appears. I thought we would see the MessageBox that said “Try harder”, but apparently the programmer made a small mistake or something. But the malware deleted itself (the v1.EXE file), and we have a lot of entries in Process Monitor. Lets check the most interesting ones.
It created two files, an EXE and a VBE file. In both files, it calls “CreateFile” to grab a file Handle and create the new file, then calls “WriteFile”, then finally “CloseFile” to close the file handle. Pretty straight forward.
Lets examine those two files..
Does that Icon on the EXE look familiar?
Those 2 files are the “TYPELIB” and “TYPESCR” from the resources. They were dropped to this path “%localappdata%\Microsoft\” and then it executes the EXE with the .vbe as a parameter to it.
Since the worm didnt work as expected, lets drag and drop the VBE file on the EXE file.
Analyzing the dropped EXE file:
From looking at its icon, you can pretty much guess what it is. But lets pretend that we’re seeing this icon for the first time..
If you checked the file’s properties, it says clearly that it’s the “Windows Script Host“.
And if we used Sigcheck on it, same result. SigCheck would be more helpful if the EXE was digitally signed by microsoft.
Also if we googled the md5 hash of this EXE, we will find many results online saying that this is the hash of Microsoft’s “Wscript.exe”.