We’ve come to an end with the project. Please visit the project page: https://github.com/caius-git/Remote-control . A quick overview of the project: we managed to create a working Remote control program that is able to control Windows 10 machines through a encrypted python socket connection. Practically it works like a malware.
Technical description and recap
We started by establishing a connection between the client and the server, so we had to implement a server-client structure and we did this by using python sockets. After that we encrypted the connection and made it possible to send data and thus instructions over that socket connection, so that we could establish control. Once we had our foundation set, we focused our efforts into the many features our program had, and we finally completed it by avoiding Windows Defender.
A list of all the features that were implemented:
- Encrypted TLS connection
- Persistence (will attempt to connect until successful)
- Download function
- Upload function
- Open website
- Crash prevention
- And of course, the system commands..
Bypassing Windows Defender
I want to dedicate a section to the last great success of the project: being able to run the program without it getting picked up or blocked by Windows Defender. A lot of people might think that Windows Defender is basically useless anyway, and that used to be the case years ago, but Microsoft has put considerable effort into it and nowadays I would say that it’s better than the majority of AV’s on the market (and it’s what I personally use). So it’s not like this is just a joke. But then, how did we manage to avoid it?
A very simple distraction function was the first thing I tried, but it didn’t work back then. That, however, doesn’t mean that we should completely disregard the idea.
This is the distraction function. As you can see, it’s just a while loop that goes on for a little while. What purpose does this serve? Well, the idea is that the AV will scan this file to see what the program does when its started up: but since the program is going to be stuck doing this while loop for a couple seconds or so, the AV stops analyzing it to save resources (if it analyzed every single file/executable for longer than that, it would eat system resources, and the process would be painfully slow).
Now don’t get too excited and think that slamming something similar to your code will just magically make your file invisible. It probably won’t. Like I said, this didn’t work the first time I tested it (by the way, the while loop can last longer, the number was originally a lot bigger, but I cut it down for testing purposes and stuck with it when it worked). And I’m not even sure how much of my success I can credit to this couple lines of code: its very possible that it didn’t even really help us (should test the program without this function: but time for the project has run out).
Other things that help make this program invisible to Windows Defender include the fact that this isn’t some known code that we copied from the internet or generated using a well known tool like msfvenom, so it’s not going to be present in any databases that AV’s typically utilize. This is probably the biggest single reason it’s a lot easier to avoid detection. Custom malware has the downside of being more difficult to produce but the upside of being a lot more customizable and easier to hide.
Last noteworthy change in the program before we were able to evade Windows Defender: I changed the port from a random TCP port to something that’s used commonly, in this case 8080. Since this is a known port, it won’t arouse as much suspicion when its used. The downside here being that if something is already running on that port, our program won’t work, but I think it’s worth the risk. Main takeaway here is that if you have a custom malware running on non-suspicious ports, your chances of success are pretty high.
First, are there any problems that could use a fixing at the end of the project? What comes to mind is our keylogger and how it cannot be stopped after being started, though I ultimately decided that this bug is fundamentally too time-consuming to fix and something that can also entirely be avoided by not caring about closing down the keylogger (it still closes down when the program is quit).
I could probably work on this project for another 100 hours without radically changing the original scope, but what would I start with? Well, there’s some features that we didn’t implement but that could be quite easy to do:
- More persistence! Make the program execute itself on computer startup
- Kind of counterproductive, but some kind of a warning that the program is active would be nice. I’ve never intended this program to be used in a negative way (which is why we didn’t include delivery in the scope).
- Possible code cleaning… though this would be a longer process
I’m not too opposed to continuing the project after this, but it is honestly quite time-consuming and definitely not an easy thing to develop on your own. That being said, we’ll have to keep in mind that if a relative beginner was able to make something that could be used for real in a couple of months, the bar isn’t set all too high…
Coming to the end here, we can conclude the project for now on a positive note. We managed to do everything we set out to do, and we actually went even further than that. The project plan also didn’t drastically change at any point. So it can be said that the project went quite smoothly indeed.
A reminder to visit the github page if you haven’t already, since it contains everything we produced during the project. Also: we don’t have an “official” release yet, but the 0.3 beta that is currently out on github is the “finished” version, despite the name. You could treat it as a full release if you wanted as well.
All in all, I quite enjoyed working on this project despite it being quite challenging for a solo project member (having someone help with the documentation would have been amazing). It was a nice challenge nevertheless, and I’m sure it’ll help me in the future.