Prelude Today, we’re going to reverse engineer a real-world RAT (Remote Access Trojan) malware, and understand what it does exactly. This project will teach us a lot about common malware techniques and reverse engineering. I found the malware here. It is the first file in the folder linked, with MD5 149979213411fcac20f7cbc1a26e1521b80073aff05d4c0f967046ef5f23b13a. Disclaimer I’m analyzing this malware on a Windows VM that isn’t connected to the internet and doesn’t have any shared files with my host. Please only analyze malware on isolated environments to not infect yourself and others on your network. Tools We’ll Be Using The first tool we use is called IDA. We use the free version for disassembling the binary and writing comments. It also has a paid version for companies and people that do reverse engineering professionally Our second tool is OllyDbg. It is an amazing debugger for the Windows platform that is really fun to use and easy to learn. Finally, we’ll also be using the Sysinternals Suite. This is a suite of tools created by Mark Russinovich that helps a lot when doing things related to the WinAPI (Windows API) and Windows Internals. Getting Started The first thing we will do is search for the hash of the malware on Virustotal: The Virustotal Hash This gives a pretty strong indicator that this is indeed malware (64/72 = 88% of vendors marked is as such). Virustotal also has a “details” tab that shows more technical details about the malware (what IPs it communicates with, what files it changes etc.), but we won’t be using it today to not give us “spoilers” for the analysis. The file command indicates that this is a PE32 executable, or in other words a .exe for 32 bit Windows: A good starting point when analyzing malware is to look at the strings, by running a command such as strings. Sometimes the strings will be obfuscated (for example using exe.dmc instead of cmd.exe and then reversing it inside the code) and then you’ll have to deobfuscate them, but in this case the strings are not obfuscated and look very interesting: The names of functions used by the malware 1 2 3 4 5 6 7 8 ---EXCERPT--- NetUserEnum WNetAddConnection2A connect send RegCreateKeyEx NetScheduleJobAdd ---END EXCERPT--- A list of passwords 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 ---EXCERPT--- home harley golf godblessyou foobar fish enable database computer baseball asdfgh asdfg asdf alpha administrator admin123 admin Admin abcd abc123 901100 88888888 8888888 888888 88888 ---END EXCERPT--- Some registry keys, hosts, executable names, and interesting format strings 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 Software\Microsoft\Windows\CurrentVersion\Run %s\ipc$ %s TaskOK %s %s %s %s CopyOK %s %s %s %s\admin$\system32\dnsapi.exe %s LoginOK %s %s %s \\%s %d.%d.%d.%d %04d%02d%02d%02d%02d%02d HTTP/1.1 Host: fukyu.jp lg1=%s&lg2=%s&lg3=%s&lg4=%s&lg5=%s&lg6=%s 1.003 GET /updata/TPDA.php? 125.206.117.59 lg1=%s&lg2=%s&lg3=%s&lg4=%s&lg5=%s&lg6=%s&lg7=%d GET /updata/TPDB.php? http://fukyu.jp/updata/ACCl3.jpg \msupd.exe The Main Function A good way to start reverse engineering a program is often where it starts, which on the Windows platform is the WinMain function (sometimes malware authors put code before the WinMain function in order to make the malware harder to analyze, but in this case it doesn’t happen). Here is how it starts: The Start of Main Cool, so we have two calls here: The call to WSAStartup initiates usage of the Winsock DLL. Here, two arguments are passed to it: The version, which in this case is 0x202 , and a pointer to the WSADATA structure that contains the details of the Windows Socket implementation. This is a good indicator that the malware uses socket communication. The second call is a call to GetModuleFileNameA with the following arguments GetModuleFileNameA(NULL, ExistingFileName, 0x104). This call puts the path of the current executable into the buffer ExistingFileName. If we step through the function with OllyDbg, we see that ExistingFileName contains the current path of the executable: Call To GetModuleFileNameA Contents of Filename Buffer Next we have some string operations that concatenate the current executable path with the string ` /SYNC` . After that, we have a call to RegCreateKeyExA: The Call to RegCreateKeyExA A Registry? The Windows Operating System has a component called the Windows Registry. The Registry is an Hierarchical Database (in simple terms it just means that all keys except for special keys called root keys have parents) where apps and the OS itself can store data. For example: Have you ever booted up your computer and a program like Discord or Steam (or some malicious malware😈) started up without you telling it to? That’s possible thanks to the Registry Most programs save the location they are installed in in a registry key. This way, their uninstallers can know what files to remove. The entries in the registry are called keys. Each key contains value-data pairs. The data can be of these types. For example, REG_SZ is the type for a null-terminated string. In our uninstaller example, the usage of the registry might look as such: Use the HKLM\Software\ registry key Write the installation path (type REG_SZ) to the value InstallPath All of this wouldn’t be useful if there weren’t a way to access the registry programmatically. That’s the purpose of the Registry API. Here is a simple example of CRUD operations on the registry: ``` #include #include