Fake-SMS: How Deep Does the Rabbit Hole Really Go?
Tracking a Bad Actor Through the Maze of Obfuscated Malware Code
Follow the White Rabbit.
When it comes to using open-source code, it is important to consider how, why, and when it is safe to do so. While using open-source code is generally considered safe, it is crucial to understand that this does not automatically guarantee complete trustworthiness or better security compared to non-FOSS solutions. Here, a key question arises: should we still use FOSS even if the code is obfuscated? The answer is a resounding NO, and I would argue that such code shouldn’t be considered FOSS. In this article, I delve into the case of a developer who concealed malicious code within their open-source tool. Surprisingly, the actual code responsible for its advertised functionality constituted a mere ~2.5% of the entire project, with the remaining bulk being comprised of malware code and code dedicated to generating ASCII art for the CLI tool.
During the analysis part of the article, you will see first-hand code obfuscation using different techniques, such as:
- packing — code compression;
- instruction pattern transformation;
- encryption;
- dummy code insertions;
- opaque predicate insertion;
- arithmetic code obfuscation;
- encoding, etc.
You will also see how doing forensic analysis on a Git repository (repo), can lead to interesting conclusions. Furthermore, incorporating search engines, blogs, and social media into your reconnaissance efforts will contribute to a comprehensive analysis and the development of a more complete timeline of events.
What is malware? Malware can be described as software that carries out actions without the user’s awareness or permission, resulting in damage to a computer system or network. There are a number of types of malware, some of which you’ve probably heard of before, such as worms, rootkits, viruses, Trojan horses, spyware, etc. Although their levels of sophistication and ability to bypass security defenses may differ significantly, all of them are detrimental and can cause adverse effects on the infected systems. The objective of this, or any malware analysis, is to proactively provide users with valuable insights required to understand the purpose and behavior of malware, ultimately enabling them to thwart forthcoming cyber attacks.
Also, you can, if you will, imagine the code at hand as a crime scene, where the body (the malicious code) in this case was missing. At the beginning, like any good inspector, I had a hunch, but only at the later steps was I able to prove that there was a crime, find the body, and identify the perpetrator.
Technically, this approach could be classified as an unstructured hunt, where the analysis is guided by curiosity. Its boundless nature permits exploration of rabbit holes and hunches, although it does require a deeper knowledge of attack frameworks and strategies in order to yield favorable results, unlike a structured hunt.
Table of Contents
- Genesis — How It All Started
- Prep your environment and tools
- Analyzing the Fake-SMS article
- Timeline — what does it all mean?
- Analyzing the Git repo
- Peeling back the layers
- Who is the author of this malware?
- Conclusion — The Big Crunch
Genesis — How It All Started
On one cold January morning, I was doing what one might do. I was scrolling through X (tweet link) when a post caught my eye. It was a post promoting an open-source tool called Fake-SMS. Although the project currently isn’t malware, back in 2022, the project was malicious. The duration for which the tool harbored malicious coding remains uncertain, but my analysis has led me to the conclusion that it persisted for a minimum of one month.
A piece of Python code that gives you the ability to send free SMS messages. This sounded too good to be true and my internal alarms were going off, and all I could think of was SCAM! However, the post was from a reputable source, or so I believed at the time. I was unsure what to think, but one thing was certain: further investigation was necessary. I did also look briefly into the writer of the article, Hackers Arise (Master OTW, three_cube), only to find conflicting information and opinions about this “expert.” I have skimmed a couple of his books, and I must admit, I wasn’t impressed. It appeared that they were targeted at absolute beginners/skiddies, which is exactly why publishing articles about open-source tools that contain malware is problematic. His hacker-arise website also didn’t do him any favors — an aesthetically unappealing website that appears to have been created using Wix with constant pop-up messages promoting his paid content (courses, books, etc.) in addition to article text that already referenced his paid work.
While there are people who claim he is a scam artist (for example, this article), he also has a stamp of approval from people like David Bombal and people at Null Byte. Did this “master hacker” know that he was promoting malware and knowingly fooled his large audience, or was the “master” tricked into promoting malware? Either answer doesn’t bode well for him, so I’ll leave the readers to make up their own minds whether he is a true master or just a Jordan Belfort of the cybersecurity space.
Prep your environment and tools
To initiate a malware analysis process, it is essential to prepare your work environment. There are two possible approaches to this. You can opt for a virtual environment or utilize a separate physical system to conduct the analysis. Each option presents its own set of advantages and disadvantages, leaving the decision in your hands as the analyst. Subsequently, the following step entails establishing network access for the systems being tested. It is advisable to create isolated network environments, as the greater control you exert, the lower the probability of encountering any issues.
Once the environment is set up, the next step typically involves selecting the necessary tools for the analysis process. In this particular instance, I solely relied on static analysis, which involves examining a file without actually running it. I was able to conduct the analysis without ever executing the malware in the controlled environment. Due to its amateurish nature, I didn’t require any additional tools to handle obfuscation, packing techniques, or encryption that was used to conceal the actual code. This forensic approach is safer to perform when permitted, although it can be easier to analyze malware by monitoring its behavior during execution. It is worth mentioning that while static analysis proved useful in this case, it is largely ineffective against sophisticated malware, where the use of dynamic analysis would probably yield better results.
Fortunately, this was not the scenario here, as the malware was relatively simple and did not necessitate the use of specialized tools for analysis. Often, the analysis approach will depend on the desired outcome of the analysis. Do you want to identify a file’s size or hash, or do you want to extract metadata? Do you want to determine its functionality, or perhaps you want to find indicators of compromise? Depending on your goals, you may opt for static analysis, dynamic analysis, or a combination of both techniques.
If you are interested in reading more about malware handling, I would recommend taking a look at the NIST SP 800–83.
Channeling my inner Sherlock Holmes
This whole situation woke up my inner detective, whether it be Sherlock, Hercule Poirot, or Benoit Blanc, depending on your age and preference for detective series. My investigation started at the source, which in this case is the aforementioned article.
Analyzing the Fake-SMS article
At the time of writing, the website that was hosting the article is unavailable, resulting in the unavailability of the article link. Fortunately, the Wayback Machine came through in the clutch by providing a link.
Upon accessing the article, the very first thing I noticed were discrepancies between the article and the GitHub repo housing the Fake-SMS project, despite the article being updated on February 10th.
- The article uses a Bash script that doesn’t contain any obfuscated code, while the project is written in Python, and by looking at the commit history, it was never a Bash script. However, a quick internet search yielded an older article on the geeksforgeeks.com website promoting the tool back in July 2021, which confirms that the project was originally written in Bash.
- The timelines don’t match. The article was written on June 30th, 2022, and the initial commit seems to have been made on October 30th, 2022. How is this possible? After doing some research, the tools seem to have existed back in 2021 (as indicated by the geeksforgeeks article), but what isn’t clear is if the tool was always malware or if the author added the malicious code sometimes between 2021 and 2023. Also, the tool’s Git commit history was altered; the oldest forks I was able to find were from 2022. The original history was either changed before anyone forked the repo or the original repo with Bash code was deleted and the new one, with Python code, was created under the identical URL to take its place.
Timeline — what does it all mean?
After concluding my analysis, I created an estimated timeline of the events from the information I was able to collect. All the timeline events are described in more detail in the text that follows the timeline graphics.
The oldest version of the code I was able to find was on the linuxquestions.com website, where a user sought advice regarding the usage of obfuscated code that was present in the Fake-SMS tool (link to a post). If you are interested, you can find the source code below:
It would seem that the original Bash code didn’t contain any code other than one needed in order to send one free SMS a day. This confirmed my earlier suspicions that the malicious code was added sometimes between 2021 and 2023 by the original author.
Analyzing the Git repo
A small and efficient script to send SMS all over the world anonymously
After opening the Fake-SMS repo (github.com/machine1337/fake-sms), I noticed a number of things:
- For what the script does, it isn’t small. Also, sending one SMS a day is hardly efficient.
1.1. Installation instructions aren’t good, as they don’t suggest the creation of a virtual environment. Rather, it promotes global package installation.
1.2. You need to install an unnecessary package termcolor that doesn’t aid in SMS sending and whose only purpose is to format the ASCII art. - Sending the message this way isn’t really anonymous, as your IP address could give you away.
- The CLI ASCII text art is different compared to the one displayed in the article.
- The code was written in Python and not in Bash, as stated in the article. So far, I know the code was once Bash, and it was changed to Python at some point. Rewriting projects using a different programming language isn’t a normal or frequent occurrence.
- The repo doesn’t contain an Issues tab that the user could use in order to report a bug, or in this case, to leave a comment on the project, signaling the malicious code. This was very odd to me.
- The repo only has one relatively recent commit (dated November 14th, 2023) with the very vague message “error fix.” This was an indicator that the Git history was rewritten and that something was strange about this project.
When looking at the project, one has to wonder: Why was the commit history altered? I think the final straw for me was the obfuscated line of code in the current repo that is used in order to conceal the usage of a public API, TextBelt. After deobfuscating the current code and finding out it uses the TextBelt API, I started to dig deeper. In an attempt to conceal the project’s history, the developer altered the Git commit history, overlooking the fact that the forks still retained the original code, untainted by the revisionist history. It is unclear whether the author was unaware that the forks would preserve the old, malicious code or simply believed that no one would bother to investigate deeper. On a side note, the author could have eliminated the forks from the project by temporarily changing it to a private repository and then reverting it back to the public. Presto chango, and the history of the “bad code” would’ve been removed. He either wasn’t aware of this option or he didn’t want to lose the project’s stars, of which he has a whopping 408⭐ at the moment of writing this article with a total of 60 forks. While I agree with the sentiment that the GitHub stars shouldn’t be an indicator of the quality or legitimacy of the project, they often are.
Continuing my analysis, I proceeded to look for the oldest accessible forks. I uncovered two, both from November 2022 (hxlxmjxbbxs/fake-sms and Doru991/fake-sms). At first glance, the code contained within these forks had a striking resemblance to the code found in the present repo. It would have been a dead end if not for the commit history, which diverged significantly from the one currently available.
From the commit history, it appears that the Python code originated with the initial commit (7688162) on October 30, 2021, exactly four months after the hacker-arise article. Nevertheless, due to the potential history rewrites, it is safer to say that the changes from Bash to Python occurred at some point within that four-month time frame. Also, a particularly intriguing commit (3d620ea) caught my attention, dated November 12, 2022, with the message “Delete fakesms.py”. This commit turned out to be the smoking gun I was looking for. After examining the changes introduced by this commit, I was able to extrapolate the presence of the malicious source code. In this case, the author intended to hide much more than the public API he was using. The discovered code is posted below, with the abbreviation of the variable’s “wopvEaTEcopFEavc” value, which was too large to include in this snippet.
Peeling back the layers
Just like it is the case with an onion, this malware consisted of multiple layers. In order to reach the tool’s core, I had to remove numerous layers of obfuscated code. I was confident that I had to arrive at the source code sooner or later because, when working with interpreted languages, you must eventually give the interpreter something it understands. Put differently, the code must be executed at some point. The obfuscated code here is comically bad, where simply replacing the eval command with a print statement unwraps the first layer of obfuscation and every subsequent layer after.
Without much surprise, I didn’t get the plaintext but rather another obfuscated layer.
I unrolled the second layer exactly like the first, by replacing the eval with a print statement, and in doing so, I got:
Again, after replacing the eval with a print statement, I got:
By repeating the same procedure, I got several more obfuscated layers that used different combinations of obfuscation techniques.
Where the last obfuscated layer was given as:
Finally, I got to the core of the onion (source code) after one last replacement of eval with print.
In order to better understand this malware, I’ve included just the malicious code part of the tool below.
Upon examining the provided code, it becomes evident that both the Linux and Windows systems initiate the download of a remote file. Naturally, my initial action upon accessing the source code was to thoroughly examine the file(s) being fetched from https://dark.devsecwise.com/pytempi.py and https://dark.devsecwise.com/systemfile.py. Unfortunately, the website was dead, so I wasn’t able to download and inspect them further. However, after using a search engine on the domain dark.dvesecwise I discovered a LinkedIn post from November 4, 2022, that analyzed this malware. The attacker was able to perform a remote code execution (RCE) attack on anyone who had run the tool on their computer. If you are interested in the detailed analysis of the code after execution, go and read the article written by Francesco Marano. The post is written in Italian, so you will have to, like I did, translate the article before reading it. :)
As a counterpoint, I will provide you with the code that was used in order to facilitate the transmission of a single SMS per day.
It is obvious from the code that the promised feature was not fully delivered. Despite prompting the user for a message input, the actual message was never sent. The entered message was stored, but it was never utilized, and the “Hello world” message was sent in its place. So not only were you not able to send your desired one free SMS per day, you also received a malware installation as a “reward” for your efforts.
Stats for “nerds”
Below, you will find supplementary details regarding the malware that you might find useful.
- Filename: fakesms.py
- File size: 1.66949844360352 KB
- MD5: D5C8063A0A5F4292D616BFC5C3FCEB47
- SHA-256: 7673072621F94777F1DF767103F8052299A84692D2598C71EA340F722113DD55
Who is the author of this malware?
Now that everything has unfolded, let’s take a moment to delve into the background of the individual responsible for this whole mess. Who is he, and why did he do this? One thing was certain: I was determined to find him, like Liam Neeson was in Taken. Although Francesco’s article provided me with the name Sikander Khan and I knew a few of his aliases, such as Machine404 and unkownclay, I still felt compelled to thoroughly examine his GitHub profile for any additional information. As it turns out, the juice was worth the squeeze, and I successfully uncovered the true identity of the author, making the pursuit worthwhile.
After looking at his GitHub profile’s README, not much information was available regarding his identity as most of the social media links have been removed. Nonetheless, the GitHub commit history was there to tell the whole story. After looking at the initial commit, I was able to extrapolate the name of the university he attended, his LinkedIn profile, and uncover a plethora of additional information (geographical location, current employer, etc.). Following the advice I received from security subreddits, I opted to exercise caution and refrain from sharing all the links I stumbled upon. Nevertheless, it would only take a few minutes for anyone with a curious inclination to unearth the same information. What I will disclose is that, according to his LinkedIn profile, his true name is Sikander Rasheed, which bears a striking resemblance to the name Francesco mentioned in his article, Sikander Khan.
I was also able to find a link to his YouTube channel and surprise, surprise, the channel has been terminated for violating YouTube’s Community Guidelines. The same as it did before, the Wayback Machine provided me with a link that offered further insights into the person behind the malware. His YouTube definitely gives me the “Master Hacker” vibe. Through his featured video, I was able to discover his Facebook page, and in doing so, I learned about some of his other aliases. The reason for his multitude of names remains unclear. One possible answer could be that he sought to conceal his true identity after being called out by the aforementioned LinkedIn post. This could explain why he changed his online handles and tried to remove traces of his real identity, although he kept forgetting about the Git commit history.
After examining his GitHub profile, which currently has a decent following of 669 followers, I’ve noticed that many of his projects have undergone history rewrites. This leads me to suspect that the malware in question isn’t the only one he developed and successfully distributed. Finally, I find it ironic at best that he, a self-proclaimed “good guy,” a red teamer, and a bug bounty hunter, has done such a huge disservice to an open-source/security community. Why did he do this? His motivation isn’t clear, but this is definitely not a constructive approach to gaining knowledge in the field of security!
Conclusion — The Big Crunch
This article highlights the fact that malware doesn’t have to be excellent, complicated, or sophisticated in order to achieve success. Why should you spend time developing complex malware or a 0-day exploit when the stupid thing suffices. The reality is that it is easier to distribute a malicious package or script than it is to thoroughly conduct a security review of each published package or script. To avoid becoming a victim of even the most inexperienced malware authors, it is crucial to maintain constant vigilance over all the code you utilize, including scripts, packages, and libraries.
Is it possible that, at the time the hacker-arise article was written, the tool contained no malicious code? It does appear to be a possibility, although there is still uncertainty surrounding the credibility of Hacker Arise. While there is a possibility that the original article endorsed an actual (albeit useless) tool, at some point the article was tunneling traffic to the Git repo, which contained malware. Even after other users brought this to the author’s attention through tweet replies (link), the author continued promoting both the article and the Git repository.
If I could leave you with one piece of advice, it would be this: If you are not paying for the product, you are the product!
Finally, if you are still reading and are interested in some of my other work, I keep myself busy most days on GitHub, where I work on interesting projects.
