The Curious Case of Felix Werner
Small note — I’ll be including all tools used in this article at the bottom, along with links for downloads and more information.
Once and a while, we all just have to come to appreciate the dedication and commitment that is shown by Roblox hackers. Yes, you read that correctly… Roblox hackers. But unfortunately, I won’t be discussing the ingenuity and programming expertise required to be a professional exploit writer for this fantastic game. No, today I’m going to be talking about Felix Werner. The majority of this article will be talking about the malware involved in this whole debacle, but it all leads to a very interesting conclusion with our friend Felix here.
A little backstory before we continue: I’m a member on a discord server known as Hacking-Coding. There’s plenty of good people on there (and some memes), but I would definitely recommend that you check it out. Anyways, one day, I was conversing in the voice channel when a member known as SnowLord brought it to my attention that he was looking at a particularly interesting malware sample. He claimed that it was designed to work as a “Roblox exploit”, dubbed Synapse, but he suspected that it contained some type of malware. It was most likely just a simple keylogger. He sent over the sample, which was a zipped archive called “Cracked Synapse v4.6.7.zip”.
Now for the fun part: dissection. This folder included a number of interesting directories and files. The most interesting, however, were the main two binary files included in the tool: “Synapse Cracked.exe” and “synapse-v4.5.1d-b2.bin”. The first file I decided to look at was the generic executable. During initial analysis, A number of interesting things emerged. First of all, the original name of the executable was “NathansBinderStub”, which is not only suspicious, but will be very important later on (as of yet, the name “Nathan” hasn’t been found to be of any significance).
After taking a small look at the code using dnSpy, a useful .NET decompilation tool, it became painstakingly obvious that it was an obfuscated .NET file, as shown here:
The next step would be to look over some of the variables included in the file and try to figure out the purpose and effects of the code that’s being ran. However, I’m not one to try to deal with annoyingly obfuscated code. Another_Researcher, a friend of mine who was giving me tips on analysis through this experience (and who’s pretty good at destroying .NET malware), brought a tool called de4dot to my attention. It’s very effective at finding the tool used to obfuscate a given .NET executable, and fixing it up a bit to improve readability. After running the tool on the binary, we are given a cleaned-up version with the same execution flow as the original.
There is one odd result included in this output, though… The tool claimed that it was encoded using an “Unknown Obfuscator”, meaning the tool that was used is either generally rare, custom made, or a modified version of a more popular obfuscator. Despite this, de4dot was still able to clean up the symbols in the file a bit to make it slightly less of a headache to deal with.
Now, we need to take a look at the constructor of the main class in the file to start to figure out what and how it runs.
Here we can see a call to the loads() method, which is located inside of the “Blank” class. This is where the code gets interesting… As mentioned before, the file is still somewhat obfuscated, so we need to find behavior that would help expose some of the effects of this code to place a breakpoint on. Luckily enough, this is relatively easy, as you can see from the decompilation of the first method.
From the method calls, it’s clear that it drops two files and starts them with Process.Start(). Interesting note: a large amount of the .NET calls inside of this set of malware were made specifically to the VB libraries, meaning it was probably originally written in VB.NET. Now, we’ll need to figure out exactly what’s stored in “tempPath” and “array” during runtime. We can put two breakpoints on the FileSystem.FilePut() calls and one just before the process is started. It would also be beneficial to check the rest of the code to guarantee that it won’t have any unexpected consequences. There actually is a check near the beginning of this binary that makes sure the files aren’t already dropped, but that’s not necessarily in the scope of this write-up. After starting the debugger and reaching our initial break, we can find all of the values we need to continue with the analysis.
Now those look an awful lot like portable executables. For those who don’t know, the PE format starts with the MZ signature from the MS-DOS relocatable 16-bit executable format days, in homage to Mark Zbikowski. We also see the two files that are dropped, and where we can find them after FileSystem.FilePut() is called on both of those executables. Skipping ahead, just before the process is started, we can view our Temp directory to see the two executables. The first, “Synapse.exe”, is the actual Roblox exploit; although I haven’t tested it, those who commented on the YouTube video where this was discovered claimed it worked, suggesting that this is legitimate (more on the youtube channel later). The second, “aaaa.exe”, is very interesting indeed. Considering that all of the operations that have taken place inside of the code have been unexpected until now, let’s take a look at the suspicious “aaaa” executable.
Not only is there no obfuscation whatsoever, but if these method names are properly named… Well, that’s about the most incriminating evidence that we need. In addition, when the malicious process is started, it runs under the name “Windows Update” in attempt to hide itself from the user. But just to see some of the wonderful programming that was put into this true artwork, we can take a look at some of the code. After taking a look at the “Form1” class’s instance variables (located in the “Microsoft” namespace), it’s clear that they made some attempt at encryption to prevent the credentials from being uncovered.
In addition to these encrypted strings, there also appears to be other variables that were used to specify certain operations that need to occur during execution. In short, they literally used strings to specify its configuration. Anyhow, the next course of action should be to decrypt this data. We can search through the rest of the class to find references to these variables. We find a number of calls to the Decrypt() method with the encrypted strings and the supposed decryption key, “PredatorLogger”, stored in plain-text.
This also happens to be the name of the malware that was included in this crack. It’s just generic spyware with a couple of different features, such as account stealing from specific platforms (Steam/Minecraft), which we can find by just leafing through the code for a bit.
The decompilation of the Decrypt() method lets us get the cleartext of the strings by doing nearly no work at all. Since it would be generally better to avoid running the payloads of this binary in order to set a breakpoint after the strings are decrypted, we can go ahead and take some of the included code to write a rudimentary program to do it for us.
The output (censored to prevent abuse) gives us the email, password, and domain of the attacker, though unfortunately the FTP information wasn’t initiated properly. This is likely just a biproduct of the stub generation with particular settings disabled. Disclaimer: I, personally, didn’t look into any of the logs that the malware sent to the email address or domain. And if you decide to take a look at these samples, you shouldn’t either. It’s unethical and illegal. Now, after looking at all of this, I’m sure you’re wondering what happened to the original “synapse-v4.5.1d-b2.bin” file. And even though it didn’t appear to be mentioned in “Synapse.exe”, it might be worth looking into to find more information about the attacker. We can repeat the same process that we used on the main executable on it to see what it does. This file was fairly different from the original, obfuscated in a different but seemingly more effective manner.
It was filled with hundreds of fake-looking classes and methods that were all encoded in this unicode gibberish. Every single identifier was replaced with this type of name. However, we have our friend de4dot on our side. After cleaning up the file, everything becomes much easier to understand.
After finding the entry-point, we are able to trace our way through the method calls until we reach something that seems vaguely interesting.
The method shown above calls the function Assembly.Load() on the variable array3, of which I have no intention of tracing the value. Let’s set up a breakpoint and see what happens.
After we arrive at the break, we are able to find another PE stored entirely in array3. Thanks to the robustness of dnSpy, we are able to save the encoded values in the array to a different file and decompile it, thanks to the fact that it was also written in .NET.
From what I gathered from the disassembly, the only noticeable purpose of the .bin file was to store various assets for the Synapse executable. The dumped file was nearly empty, with the only substantial material being located in the Resources section of the binary. I’m almost certain that I missed a great deal of interesting information from the original, but from all of the other data that had already been gathered, I didn’t really consider it necessary to continue following this lead. We had successfully dumped all of the malicious files and retrieved information about the attacker that we can use to identify and shut down their operation. All of the files included where uploaded to VirusTotal and would absolutely be detected the next time someone were to scan one of them.
A number of days later, I was talking with some people in that same discord server when a different friend of mine, named “Jazzy”, claimed that we found a piece of malware that he thought was interesting. Thinking that I had improved slightly from the previous experience, I offered to help. The sample he was looking at just so happened to be another Roblox “exploit”, apparently named “Bleu”. He sent three separate files, “Defiate_3.exe”, “Bleu.exe”, and “Bleu_Cracked.exe”. Both Defiate_3.exe and Bleu.exe were legitimate files, and most likely posed no malicious threat. The Bleu_Cracked.exe, on the other hand, was intriguing.
Looking at the size in comparison to the real version of Bleu, it’s obvious that the cracked version has some extra code or assets inside. This isn’t inherently malicious, or even terribly suspicious, but it does heighten the probability that it contains something unexpected. It appeared that this sample was also written in .NET, but the most interesting aspect of this new piece of malware was the original name of the executable.
Despite being totally unrelated, both of the samples that I had received from completely different sources both served the same purpose and were obfuscated with the same tool. I even compared the signatures and sizes of the two files just to verify that they weren’t the same binary, but it appeared that they were different. On the bright side, this made it incredibly easy to deobfuscate and analyze.
Looking at the code, it’s obvious that the two samples are very similar, with the only difference being in the files that were dropped. Following the same procedure as the Synapse sample, we were able to retrieve the two different dropped files.
It functions almost identically to Synapse, with the exception of the attached malicious stub. Instead of “PredatorLogger” with its fake windows update utility, we are left with a file named “CookieVenomStub.exe”.
Simply researching the name of this file gives a clear picture of what the intention of this “crack” seems to be.
If any more verification is needed, we can just decompile the dropped CookieVenom executable.
The code shown to the left seems to send a user’s stolen Roblox authentication cookies to the included discord webhook, which I’ve censored to prevent any abuse. This suggests that the stolen cookies are being sent to a discord-based log server, of sorts.
The next day, I was talking with Jazzy again about the strange amount of coincidence to the whole situation. When I asked him where he got the Synapse crack, he linked me to a YouTube video posted on a channel named “Felix”. This is the moment that things finally started to fit together.
I wanted to verify that the programs that he was distributing were actually the samples that I was looking at before. After crawling through multiple adfly links and I downloaded the two new releases at the time (the newer ones have changed up obfuscation methods since Another_Researcher and I took a look at it… Yes, the kid’s still spreading) of Bleu and Synapse. After decompiling them, we get:
Same obfuscator, same file dropping technique, same everything except for the malicious executable. Both of the updated Synapse and Bleu cracks install CookieVenom, and it looks like he’s discontinued the full-blown spyware, for the moment.
Looking back at the video descriptions, there was a link to a discord server that me and Another_Researcher quickly joined. When we were talking to the admins (who shall remain unnamed), a couple of them admitted that they knew about the cookie logger, and Another_Researcher was able to find out that the webhook actually led to a separate discord that members could join, for a price. It seemed as if all of the members of the server were completely desensitized to the fact that what they were doing was illegal.
Unfortunately, he is still spreading his malware. We did, and continue to hinder his efforts in a number of ways, such as getting his log accounts suspended and reporting his discord server and webhooks to, hopefully, have discord shut them down. However, it is an on-going fight. If you can, report his YouTube channel with valid proof (maybe this article?) so that it gets taken down and he loses his chance to reach kids looking to cheat in Roblox… It would take a long while to reacquire all of the subscribers he has. It’s also possible that law enforcement will get involved, so, as I mentioned before, be ethical in all of your endeavors regarding this scammer.
Thanks for reading.
Tools
dnSpy — An incredibily useful .NET debugger and assembly editor.
IDA — A native debugger with the most functionality that anyone could ask for in a disassembler.
de4dot — A .NET deobfuscation tool which attempts to identify and undo the obfuscator used on a specific file.
Process Hacker — Although not showcased in this tutorial, it is a very helpful tool that allows a full tree view of all processes and forks, along with many other features.
Fiddler — A useful web debugger, as recommended by Another_Researcher.
Wireshark — The classic packet sniffer. Very useful in almost every scenario.
