MalwareBytes Reversing Malware Writeup

tags: malware 2022 reversing TeamT5 2021 winter security camp

去年(2021) 獲選參加 TeamT5 的寒假資安培訓營，收穫豐富。過了一年，想說複習之前學習的逆向惡意程式內容，也順手做紀錄。為了練習英文寫作，所以接下來都是使用英文書寫，請大家包含。如果想看中文的話，也歡迎搭配其他參加大大的技術分析文章 。

For educational usage binary

Binary download link

After unzipping the zip file, you are good to execute the binary.

Tools I used

• Virtual Machine
  • Parallel Desktop 17.1 with Windows 10 in it
• Static Analysis
  • IDA Pro 7.6
  • Detect It easy v3.03
  • pestudio 9.27
• Dynamic Analysis
  • x32dbg Version: Nov 26 2019
• Network monitor
  • Wireshark Version 3.4.2
  • Fiddler v5.0.20211.51073

IDA Pro great configuration(Optional)

IDA Pro has two friendly configurations that makes our analysis much more comfortable.

• Synchronize with option: It synchronizes the pseudocode and the assembly. It is easier to jump from high-level language to low-level language by synchronizing. Also, with this configuration, it's easier to make the comparison.
  
• Show line prefixes option: It is easier to see the exact address where the function is executed
  
  
  • The result
    
    

After these two configurations, we are good to go!

Stage-1

Descriptions

After executing the binary, we can see a message box pop up. We can see a string from the console message that says, I am so sorry, you failed! :(. The string is the exact spot we start our journey! Besides that, we know the flag format is flag{...}.

Observe the variables

Dragging the binary to the IDA Pro, let's start the analysis.

Now let's observe the path where it shows, I am so sorry, you failed! :(. To avoid this path, let's see why it chooses this failing path? From the image below, we can find out that at (1) it call sub_4014F0, at (2) test al, al , and at (3) jnz loc_4019A5 which results in the failing path at (4). From calling convention, we know that al derives from sub_4014F0 and al=0 leads to the failing path. Hence let's examine this function and see what happened inside.

In sub_4014F0, we can see that there is a comparison if sub_403380 equals 0x3B47B2E6. If the answer is yes, we can go to the correct path at [5]. Besides that, we can find out that szUrl is passed to the first argument of sub_403380. By making the educated guess, the goal of solving the problem could be filling szUrl with the correct value as the input and validating the comparison.

And thus, let's find out the reference of szUrl.

By pressing x in IDA Pro, we can get the references of szUrl. From the image below, at [2] is where we press the x of szUrl. At [1] is the place where szUrl comes from. Finally, at [3] is where szUrl is being used.

Let's first examine [3], we can see szUrl is setted as an argument of function sub_4033D0

It's time to check function sub_4033D0, we can see that szUrl is one of the arguments of InternetOpenUrlA

• the esi register dervives from the argument of sub_4033D0 which szUrl comes from
  

  

• From docs-ms-InternetOpenUrlA, it is documented that the lpszUrl is A pointer to a null-terminated string variable that specifies the URL to begin reading. Only URLs beginning with FTP:, HTTP:, or HTTPS: are supported.

• To keep it simple, these functions open an URL.

Seeing the following code in sub_4033D0, we can determine that InternetReadFile is called.

• From docs-ms-InternetReadFile, hFile is an Handle returned from a previous call to InternetOpenUrl, FtpOpenFile, or HttpOpenRequest.

So if we can confirm that the result of output from InternetOpenUrlA is passed through InternetReadFile's first argument, we can ensure that the binary will download some contents from the szUrl.

And the answer is yes!

Let's examine [1] where szUrl comes from.

From the image below, we can see that szUrl is one of the arguments of sub_4031C0

Let's rely on the decompilation of IDA Pro. We can figure out that szUrl is part of the CryptDecrypt function

• From docs-ms-CryptDecrypt, we can find out that szUrl is served as pbData
  • pbData: A pointer to a buffer that contains the data to be decrypted. After the decryption has been performed, the plaintext is placed back into this same buffer.

We can guess from the info we get that szUrl must be decrypted. After the decryption of the URL, the binary will request the URL. Eventually, the binary will download some content from the URL.

Find out the decryption key

We know from the image below that CryptHashData is called to create a hash from the binary passes.

The pbData derives from the key_buf, the fourth argument of sub_4031C0.

This hash's importance is because it will derive the decryption key (which will be used to decrypt the szUrl) at CryptoDerivekEY later.

Now, let's find out where the key_buf is referenced. From the image below, we can see at least nine places key_buf is referenced

Patch the anti-debugger

The key_buf is mangled at nine places before activating the decryption. So to protect the integrity of the key_buf, we have to enter each function and patch any branch that will violate the content of key_buf. And that means we have to fix nine functions.

There are several methods to patch the binary, you can either use PE-bear to patch (like the author of this binary does), or you can patch it by x32dbg which I prefer the latter one.

TODO: The process of patching the anti-debug

• Tips:
  • Save the patched binary each time you finish patching each function. This will save you tons of time
  • How to check if we patch correctly?
    • If it does not return an error that means you are good to go

Nine addresses to patch

1. In sub_4019D0: patch 0x401A0E with nop bytes
2. In sub_401A50: patch 0x401A97 with nop bytes
3. In sub_401B00: patch 0x401B72 with nop bytes
4. In sub_401C20: patch 0x401C42 with nop bytes
5. In sub_402730: patch 0x402817 with nop bytes
6. In sub_402880: patch 0x4028A7 with nop bytes
7. In sub_402B70: patch 0x402D71 with nop bytes
8. In sub_402DE0: patch 0x402F7E with nop bytes
9. In sub_401BC0: patch 0x401BE4 with nop bytes

The result of patching:
It shows that You are on the right track! at the console with the popup Nope :(

Obtain the link

Start the Wireshark and start to monitor the network. We can find that the binary is trying to query pastebin.com and downloading data from the website (we already know from static analysis).

To ensure 104.23.99.190 is the IP of pastebin.com, we can dig pastebin.com and confirm that's true.

To see the encrypted data, you have to enable the decrypt HTTPs options in Fiddler which we get the complete url pastebin.com/raw/9FugFa91

The downloaded content

Analyze the content from the URL

Although we obtain the contents from the URL, we still fail to continue running the binary. So let's dive down to static analysis and reveal what the binary does afterward.

Let's focus on the string Nope :( and xrefs it. It's referenced at funciton sub_401690

Let's discover function sub_401690 and see the secret inside.

There are four processes in function sub_401690. It's worthy of analyzing this function dynamically with x32dbg.

1. Base64 decoded
2. Decompressed with RtlDecompressBuffer
3. XOR decrypted with the key from the clipboard

We can get the key malwarebytes from the dump data while there are a bunch of empty spaces in this binary. (reason: malwarebytes xor 0 = malwarebytes)

4. MZ check
   From the image below, we can see that the start of the dump data is MZ which will be validated later. This is the stage2.exe binary, and we can dump the binary from x32dbg with offset 0xE400 from the start of address 0x752e40.
   
   
   • Where to find the dump data?
     Right-click the .text section -> Find in Dump -> Address: EDI
     
     
   • How to find the offset 0xE400?
     • We can find it from the clue given from the console!
       
       
     • We can see 00E4(in little Endian) and we convert it to E400
       
       

TODO: Let's discuss each function seperately

Base64 decoded

Decompressed with RtlDecompressBuffer

XOR dcrypted with the key from the clipboard

MZ check

Stage-1 Result

• Obtain second PE
  • Scylla usage

Stage-2

Execute second PE

This is the message I got from the second PE.

Analyze the code

1. Get ModuleFileName
2. ExpandEnvironmentStringsA
3. Compare the hash
4. EnumWindow to find the specific process
5. Check if the binary is executed in the debugger
6. XOR the shellcode

Obtain the shellcode

Bypass the two following branches, and we can get the shellcode injected later.

• 
• 

The dump data we get will be served as shellcode. It comes from the address 0x2fe000

• How to dump data in x32dbg? There are two ways:
  1. Use savedata function: savedata file-directory,start address,offset
     
     
  2. Use x32dbg plugin Scylla
     
     

Process Hollowing

Use PE-bear to inject the shellcode back to stage.exe. This is impressive when I see the author's instruction video

Steps

• There are 6 steps:
  1. Add section in stage2.exe.
     
     
  2. Choose the shellcode we just dump and add section name and press ok.
     
     
  3. we can see the shellcode is added to stage2.exe section.
     
     
  4. Change the characteristics to e0
     
     
     • How to change?
       
       
     • The result
       
       
  5. Go back to assembly and set the entry point to 0x13000
     
     
  6. Save the patched binary
     
     

Result: Get the flag!

Conclusion

This is an interesting binary to learn Windows API, patch binary, static/dynamic analysis, dump data with x32dbg, and injecting shellcode to process.

Resources:

• malwarebytes tutorial
• high-level-observation-writeup
• low-level-observation-writeup
• TeamT5 Winter Security Camp classmates wrietup

Notes

cmp

• cmp A B => A - B to see if they are the same
  • If returns 0 => A = B => ZF=1

test

• test eax eax => eax AND eax to see if they are the same
  • If returns 0 => eax = 0 => ZF=1

Zero flag: if the result equals 0 ZF=1
e.g. cmp 100 100 => results in 0 => ZF=1 => JZ will be taken (which is same as JE)

• JE equals JZ
  • JE: Jump if cmp is equal
  • JZ: Jump if Zero

xor:

• xor eax eax equals mov eax, 0 but with shorter opcode