In recent weeks, the Cerberus Android malware source code has been made public, which we have already written about on several occasions.
After its developer posted on an underground forum stating that it was washing its hands of the project and, following a failed auction, it ended up sharing the source code with its customers and all the premium users of the aforementioned forum.
In light of this decision, it is now possible to see, in its entirety, how the malware functions beyond what was already known from analyzing the samples detected.
Message from the main developer
What is more interesting than the malicious application code itself, is the analysis of the code running on the control server. After all, analyzing the samples has already provided large amounts of information about how the malware works. Nevertheless, this is the first time that we have got our hands on the code run by the server and it is of interest to know whether, beyond the record of stolen credentials, there is some type of automated mechanism for using them.
As we have already stated, analyzing the source code of the malicious application itself is not the most interesting aspect, although it obviously allows us to get a much clearer idea about how this malware works, as well as the likelihood of it enabling hidden functionalities to be discovered or, depending on what version of the code we are dealing with, functions that had not yet been applied to the final versions, which were still in development.
One of the most interesting parts of the code to analyze is the communication protocol with the control server, since, by having access to the source code, it is easier to develop small programs or scripts that simulate the application and communicate with the control server to get information about the current campaign. Part of the code can even be directly reused to develop useful tools to analyze any potentially new versions.
Source code for sending information collected through content-injected bank phishing attack
The names of the encryption functions can be seen clearly in the source code. However, although it was previously known that it used RC4 encryption, it is now much easier and clearer to see.
Encryption functions and hexadecimal code
In the app code, we can also obtain the entire list of URLs used by the Trojan to contact the control server and send stolen data. In the following image, we can see how the URLs are defined as constants that will be subsequently used in the code that makes the request with the sending of data.
The following URLs correspond to the first version of the Trojan, as can be seen in our primer report on this.
URLs defined as constants
Server-Side, we find the functionality split into two main elements:
If we go over the server installation script, we can see how two different sites are configured in NGINX, one of them for gate in port 80 and the other for restapi in port 8080.
Furthermore, the latter is configured to be accessible through the TOR network and not through the usual network, so that only the attacker who knows the ONION domain should be capable of making requests to the API.
Access to the server´s source code could reveal, apart from hidden functionality, security flaws in the code that could be used by other attackers or by analysts and authorities to take control of the botnet in order to disrupt it. One of the vulnerabilities we could come across are SQL injection vulnerabilities in the database queries.
However, it seems that the developers have tried to cover their tracks by using prepared statements from the PHP library, which prevents vulnerabilities such as this, at least in the gate.
Code entrusted with adding a new infected device to the database
As well as the malicious application and the back-end code, in the code repository we also come across the panel code used by the administrators of each Cerberus botnet.
This panel is a ReactJS application that connects to the Rest API exposed through the TOR network.
The release of the source code of one of the year´s most popular Android bank Trojans has upsides and downsides. On the one hand, the fact that this banker is no longer being supported has brought the original project to an end, which, in principle, means one less player in the banking malware game.
Furthermore, it gives the impression that, perhaps, this type of business is not so profitable for its developers after all, as, otherwise, they would not turn their backs on the project if it were truly profitable and of interest to them.
The list of affected entities remains unchanged, everything is the same as that described in our Cerberus analysis and in our subsequent update on the new version in March.
The downside, on the other hand; the publication of the source code opens the door to new developers seeking to create new bankers based on Cerberus, meaning that new variants or families could start popping up over the next few months. Therefore, we must be on the lookout for new bankers that may show up in the near future.