[ Walkthrough : X-CTF 2016 – Worm ]

Quest: A malware was caught infecting “NUS GOVT” thumb drive. Encryption was used to encrypt outgoing data. Please submit the answer in the following format: XCTF{SHA1 of (key1 + key2 + key3)}

File: add4f352cbcb62fffe01eccf78a912b8

SHA1 Hash: 16e9245a14e223b83fde700aa6904e2f487ef07b

Let’s begin by firing up IDA Pro to see what we can find.

Going through the IAT, we can see that SetupDI… are called. A quick reference to MSDN reveals that these functions are used to enum plug and play devices.

SetupDiGetDeviceRegistryProperty function retrieves a specified Plug and Play device property.

imports
Figure 1. Imports

Cross-referencing (Press x in IDA Pro) the function reveals much more stuff… It seems like the malware is trying to find a USBSTOR device. This definitely makes sense since the quest already stated that the malware infected a “NUS GOVTthumb drive. Let’s do a breakpoint later in ollydbg to see what is really going on.  Further down the disassembly, we can see that it is trying to match with a String “NUS GOVT“. Just take note of this for now.

IDA
Figure 2. Checking for SPDRP_ENUMERATOR_NAME & SPDRP_FRIENDLYNAME

In the strings, we could see interesting artifacts as well… looks like the malware is trying to infect via autorun.inf… OK let’s take note of that for now. We could also see stuff like wsock32.dll, Ws2_32.dll… but in imports, we did not see any functions with relation to these libraries. Probably GetProcAddress is being used…

strings
Figure 3. autorun.inf in strings

Ok let’s fire up ollydbg. Crap we encountered access violation! Scrolling upwards we will realize what the malware is doing… Anti Debugging mechanism!

accessViolationDebugger
Figure 4. Access Violation

A jmp is made to 0x4141FD+1 if a debugger is found else the next eip should be 0x4041F4. We can simply just set new origin to 0x4041F4 to bypass the anti-debug stuff.

antiDebugger
Figure 5. fs[18h]
Let’s set a breakpoint @0x4026D1, refer to Figure 2 with a thumb drive plug in =).

NUSGOVT
Figure 6. Matching Thumb drive name with NUS GOVT

Ok… let’s just change the extracted device name to NUS GOVT manually as shown below.

mod
Figure 7. Changing name to NUS GOVT

Run the binary and see what happens…

The binary crashes again… but this time round some files are dropped into my thumb drive.

droppedFile
Figure 8. autorun.inf

Seems like there is a binary dropped into the RECYCLER folder. It seems to be hidden. Let’s use “attrib -h -s” to unhide the folders.

secure
Figure 9. Dropped Binary

Firing up the binary in IDA pro, it seems like the binaries are the same… But the hash is different. Loading the binary in OllyDbg, we encountered the same anti-debugger code. So let’s set up the same breakpoint again @0x4026D1 and change the thumb drive name to “NUS GOVT“… Being lazy i just hit on the run button and monitor any dynamic traces. Wireshark sniffed some http traffic!

traffic
Figure 10. HTTP traffic detected!

Remember earlier we suspect that GetProcAddress is used since we can’t see any network related API in imports and we noticed such libraries in the strings segment. Set a breakpoint @GetProcAddress and see if we can find anything useful.

WSA
Figure 11. WSAStartup via GetProcAddress

Returning back to user code… we see this in ollydbg… =(

1
Figure 12. Rubbish Codes?

Re-analyse the code to see a more english representation of the above =)

2
Figure 13. Assembly codes =)

Analyzing the functions above, we can see outgoing connections to nus.edu.sg/ctf.php with some stuff(passed in via arguments) appended to user agent string…. Lets return to see who call this function.

encryptedData
Figure 14. Encrypted Data?

It seems like the function @0x403210 is protected. Therefore if you were to put a software breakpoint inside 0x403210, it would become useless when the codes get rebuild in runtime. For this case, we should use hardware breakpoint instead. Seems like before calling 0x403210, a function @0x401FD0 is called twice to deobfuscate the code @0x403210. Then after invoking the function @ 0x403210, @0x401FD0 gets called twice again to re-obfuscate the code.

caller
Figure 15. Send Data out

Scrolling up from figure 15, we can see a pattern… It seems that a function @0x401090 is deobfuscated&reobfuscated 3 times before a call was made to the above send function (0x403210).

401090
Figure 16. 0x401090 the encryption method

Putting a breakpoint @0x401090. We can observe something pretty interesting… It seems like the function is passing in my Computer Name and a string which might be the encryption key.

key1
Figure 17. Key 1 found

Running through 2 more breakpoints, we would have collected the 3 keys!

key2
Figure 18. 2nd Key found
key3
Figure 19. 3rd key found

OK so the flag should be

sha1(“MED DNI PTS oRTO RUO VAN MOC iASP VED MDA IONDEADBEEFNU5_MA5T3R”)

XCTF{1f5020e4c091d1464c16c157bc0e56f3d81a3b3a}

WRONG!

It turns out that the above flag is wrong. Remember the autorun.inf… there are some parameters passed in… refer to Figure 8.

Lets try to re-run the steps with the parameters passed in…

newkey
Figure 20. A different 2nd Key

and… we got a different 2nd key!

sha1(“MED DNI PTS oRTO RUO VAN MOC iASP VED MDA IONMEDiCINENU5_MA5T3R”)

AND THE ACTUAL FLAG IS: XCTF{db8496580ff636bc51ade827d1999d32d5dabb1c}

40 points =D