A Remote Access Tool (RAT) is used to remotely access a computer. It has legitimate uses but it can also be used for malicious purposes. I've seen it used in malware I've analyzed and I've always been curious as to how it works.

I was following along the Handmade Hero project ¹ when the topic about dynamic DLL loading came up. This is a process of dynamically loading a DLL at runtime which is useful if you want your program to check if a DLL is present in a system before loading it.

Two of the system calls that were discussed were LoadLibrary and GetProcAddress. These were familiar to me as I've seen them used on malware shellcode I analyzed in the past. I later learned that this is also used as an anti-virus evasion technique. I found this interesting.

Having learned how to do runtime DLL loading myself I decided to give it a try. And of course, a RAT is perfect for this.

Planning the RATchitecture

A lot of famous RATs are packed with features like the ability to log keystrokes, take screenshots, and turn on a webcam. I just want mine to be simple and have basic functionality like:

• Execute command line commands remotely
• Download a file to the client
• Exfiltrate data via file upload

You can already do a lot of things even with the above basic functions. You can download a payload to the client, run it via remote command and then upload the results. You can even update the RAT itself using the same process!

As an extra, I also wanted it to be stealthy. I am aware however that this is something that is not easily done. There are myriads of security defenses and I don't think I have the time and energy to have my RAT to be up-to-date with the latest evasion techniques. Having basic anti-debugging and anti-sandbox checks is enough for me.

I've never made a RAT before but thankfully there are a lot of great resources online that helped me a lot:

• ParadoxiaRat is my main resource and has done a lot of the features I wanted to implement.
• DarkRAT is a leaked source code that gave me an idea of how a RAT used in the wild looks like
• VXUnderground's WinAPI tricks taught me that there are alternative ways to do certain things to avoid detection

As for the name of the project, I decided on "RATwurst" after the german sausage, Bratwurst. Don't ask me why. I just thought it's funny that it had the letters RAT in it.

The nitty gRATty details

The client is written in ANSI C because it's the language I prefer. Since I am only targeting Windows I chose MSVC for the compiler. Which is great because it allows me to use Visual Studio for debugging.

The server, on the other hand, is written in Python because I wanted another excuse to practice with it. Choosing Python has been a good choice though because of the excellent low level socket and cmd libraries.

Sockets are used for communication between client and server. I've applied basic XOR obfuscation to the data to mask the traffic. The client and server can handle sending of strings and even executables over the network.

When RATwurst is first executed. It does some anti-sandbox checks via process enumeration. It checks if there are more than 15 processe that are running and if there are virtualization tools present like vmware.exe. It will also setup an auto-run registry entry for persistence. And also move the executable to Windows' temp folder and re-run it from there.

Anti-debbuging checks are littered throughout the code which checks the amount of time it takes to reach from one part of the code to the next. This is used to detect if someone is stepping through the code, increasing the delay between code execution.

When no shenanigans is detected then it'll proceed to work as intended.

For eduRATional purposes only

I've made the source of my project available on Github. The aim is to share what I've learned so that others can learn too.

I am aware of news of RAT authors having been arrested because of their work. They actively sought to gain money from their creation, I, of course, have no such plans.

To make sure that I save myself from any legal problems, I've placed a disclaimer that I am not responsible for any misuse. While I am skeptical that a piece of text would prevent any legal action towards me, I do see other projects having their own disclaimers so I decided to do the same.

I've also submitted my creation to a multi-scanner service like VirusTotal. This would help distribute my RATs signature to anti-virus companies so it can easily be detected when used in the wild.²

A RATisfying learning experience

Making this project has been a lot of fun.

The most useful thing that I learned is the client and server communication via sockets. I've dabbled with it before but only in this project have I actually sent actual data back and forth.

I am also happy that I got to use more Windows APIs. It's fun to play around with what's available and it is opening my mind as to what other things I can make in the future.

And of course, this project has given me a good insight into the techniques used by malware. Learning about them is not enough until you've built one yourself.

Since my last post about my investigations of a Facebook phishing site, I have received several messages from friends asking me to check out other suspected phishing/scam sites. One of the most alarming out of them was this one where I was able to find the file where the scammer stores the phished usernames and passwords.

This particular phishing site conducts its operations like this:

• An ad is shown on Facebook, promising free coupons for famous fast food restaurants
• Clicking on the ad takes the user to a fake Facebook login page hosted on blogger.com
• Login page then sends phished username and passwords to a PHP file hosted on 000webhost

The phished passwords are then stored in a .txt file (blatantly named, victims.txt), which is publicly accessible on an open directory. Getting to this directory involved following the scripts and the URLs used by the scammers. It's not that hard to find as long as you know where to look.

What's scary is that the size of this text file kept on getting bigger. I knew I had to act quickly.

Stopping the scammers

Unfortunately, with phishing sites like these, there's not much we could do but report it to the relevant hosting providers. The problem is that sometimes it may take some time before the site gets reviewed, which is excruciating because the longer the wait, the more people fall victim. Some might even just ignore your report altogether!

I reported the fake login page to Blogger.com and did not receive any response at all. I understand that Blogger.com is a big platform and I bet they receive numerous reports like this. I guess this is why the scammer used this platform as they know they won't be taken down too quickly. Their profile even listed two sites that both had fake login pages.

Thankfully, 000webhost got back to me and eventually took down the page that hosted the PHP and text files.

You'd think that this is a victory. But sadly, setting up a new phishing site is rather easy so within a few hours there is already a new one. Of course, I reported this new site too. Only for a new one to pop up later...

You can see how this can become an endless cat and mouse game.

Stopping from other sources

One way that could be effective to stop the scammer's operations is by reporting the Facebook advertisement that is used to lure users to the phishing site. Unfortunately, my friend who shared this with me did not get a chance to snap a screenshot of the ad. If he did then it would probably have more impact on stopping their operations. Maybe the Facebook abuse team can trace the payment details used to pay for the ad, and maybe block it.

If you know anyone who may have seen a Facebook advertisement that offers free coupon codes for fast food restaurants that might be pointing to a suspicious login page, then please do contact me!

Awareness is the key

As of this posting, the landing page is still up while the page that hosts the PHP and victims file is down. I'm sure it'll be back up soon. All I was able to do was delay their operations. A minor inconvenience for them.

This is why out of everything, spreading awareness is the best countermeasure. If people are more aware of phishing sites and how to avoid them then that would greatly diminish their impact. This is why I continue to post and write about phishing sites. Seeing the number of victims rising like that made me act knowing that I at least have the power to prevent things from escalating.

And you have the power too, dear reader. Educate your family and friends by warning them or by showing them my posts. Remember, awareness is our best defense!

This is a writeup for Emprisa maldoc challenge that I made for CyberDefenders.org. You can play it here.

The very first thing that I do when confronted with a malicious document is to run it in a malware lab. This particular document, however, would not exhibit anything malicious on recent versions of Word.

A quick search of the hash on malware sandboxes would reveal that the document makes use of the CVE-2017-18822 vulnerability. This is a vulnerability that became known and was promptly patched around November of 2017.

The above details give us a hint on how to trigger the document, which is to run the maldoc on a version of Microsoft Word that doesn't have the patches that fix the vulnerability. The easiest way to do this is to boot up a new VM with a fresh install of Windows 7 and with updates disabled.

This new environment is where the document would trigger once double-clicked. After a bit of loading, a pop-up would later appear greeting the analyst with congratulations (this is a stand-in for a malicious payload for this challenge), but of course, it is clear that we are not done yet.

Tools such as Process Hacker will reveal a new process named EQNEDT32.EXE getting spawned right after opening the document. Those who have read through the CVE details would know that this is the expected behavior, as the vulnerability uses this process to run malicious code. In this case, the exploit downloads a file from the internet and automatically runs it.

Another tool such as Regshot would reveal newly created files. It can determine these by taking a snapshot before the malicious document is opened, then taking another one after the downloaded payload gets triggered, and finally comparing the two snapshots and listing the differences. It's an invaluable tool to have.

Running rtfdump.py would then reveal some telling details about our maldoc, like for example, magic signatures and object streams.

Upon close inspection of the hexdump of the largest object stream (still via rtfdump), one would see a sequence of NOPs (aka a NOPsled) in certain parts. A NOPsled such as this usually indicates the possible start of shellcode. Carving this part of the shellcode and running it on an emulator such as speakeasy or scdbg won't work properly, however.

The output shows the first line to be LoadLibrary, and then there's an error after that. This indicates that maybe there's a problem with the shellcode.

On further inspection, a little more further down there is another set of seemingly readable strings. This could indicate another shellcode. Or, maybe, a continuation of the first one? In between these supposed two shellcodes is a readable string that seems out of place in between the gibberish. Carving the two shellcodes and then combining them would now work when run on an emulator.

If the previous solution was not immediately clear to you then there is another approach to the above. And that is to step through the EQNEDT32 process as soon as it runs. However, attaching to this process is tricky as it triggers only for a split second and then exits. To debug this, a debugger should be automatically connected as soon as the process starts. Check out this post for details on how to do this.

Once attached, the painstaking process of debugging begins. Thankfully, we have an idea of what code is being loaded into memory. And this is the shellcode that has a NOPSled during our analysis with rtfdump.py above. Looking for this sequence and then putting a breakpoint where the memory location is accessed would stop the program just before the shellcode is run. Once the breakpoint triggered, we could step through the shellcode and find out what exactly the shellcode does and which Libraries are being called.

From here, we could also backtrack from where the shellcode is called to figure out how the exploit is triggered via a buffer overflow. This requires a bit of knowledge in reverse engineering. An alternative is to check out the CVE details in search for the tool that was likely used to make the exploit, and then examining the code.

After all of that, you should have everything that you need to answer all the questions in the challenge. You may have noticed that I have not revealed the answers outright. You still have to find it on your own. However, I do hope that by walking you through the process, I have helped you understand how to get there.

If you have more questions, or want to tell me what you think of the challenge, feel free to leave a comment below or send me a mesage at @accidentalrebel.