It is not a surprise that new variants of Mirai and more come to light, being available to anyone the source code of the bot, the CnC server and the download server. However, they all had relatively similar features (except for the variant for Windows, of course).
On March 19 came a new version of Mirai that caught our attention because of its size. While the usual is to find Mirai binaries of around tens of Kbs, this new sample has 1.6 Mbs. The TELNET connection that preceded the download of the binary is exactly the same as in previous catches.
– This article has been based on the analysis of the x86 version:
mirai.x86: 7e17c34cddcaeb6755c457b99a8dfe32
Inquiring in the IP of the server in charge of the distribution of the samples, we find that it has the directory listing enabled, something not surprising in itself. If it was the inclusion of two new architectures that we had not previously found: x86_64 and x86_686, in addition to removing support for arm7.
To the left, the usual directory listing in the distribution of Mirai in the TELNET service, whereas to the right we have the directory listing of the distribution server of the new version
Like previous samples, it does not have fingerprints of the compiler, so the same technique of deletion of symbols and sections must have been used, that was broadcast at the beginning of last September:
strip" release/"$2" -S --strip-unneeded --remove-section=.note.gnu.gold-version --remove-section=.comment --remove-section=.note --remove-section=.note.gnu.build-id --remove-section=.note.ABI-tag --remove-section=.jcr --remove-section=.got.plt --remove-section=.eh_frame --remove-section=.eh_frame_ptr --remove-section=.eh_frame_hdr
While the first versions contain between 200 and 250 functions, the sample before us today has more than 3000, which made it difficult to analyze. This has been based, essentially, on the automation through r2pipe of the results obtained with commands related to the references to the flags of Radare2.
Among the strings, we can find references to file paths belonging to the OpenSSL encryption library, which is the reason for the large size of the sample before us, since it includes it embedded.
After execution in a controlled environment, the opening of ports 1756 and 42205 is detected for communication with the servers.
Analyzing the main, we detected that the first references to the table_unlock_value and table_lock_value functions, which are responsible for decrypting and assigning table values, have disappeared. These contain the fundamental information for the connection to the servers, so it could indicate that the modifications related to the encryption of the connection would finally be related to these communications.
On the left, a block of the main function of a previous Mirai binary already analyzed. To the right, the same block without references to the mentioned functions.
However, these functions do exist, as they are present in the attack_app_http function.
Function code attack_app_http where constant calls are made to table_unlock_value
This may be because in previous versions, the binary download was not executed by the attacking bot, but during a subsequent connection by a third server (dlr). However, everything points to the fact that this component was removed from the architecture in this variant, since the request for malware to be downloaded by the IoT device is hardcoded in the binary, a request that we had not found in the previously captured samples.
Since the call comes in the first instance by the function attack_parse, and this is in charge of the information management the sent by the CnC server, it could be deduced that this new variant absorbs the malware functionality of download servers infection (dlr. {Arq}), executing itself such requests in case this is indicated.
Part of the request to download the sample hardcoded in the code
Request of the download server in an attack of another variant of Mirai
As in previous cases, hardcoded passwords are still managed in the scanner_init function. After more than 9 months of dissemination of the botnet, one would think that the potentially vulnerable devices would be close to the total. However, seeing that new samples continue to execute connections with the same passwords (and therefore against the same devices), we know that the degree of infection is far from the maximum.
Part of the scanner_init function where passwords are declared without decryption
Examining the attack functions in search of the use of encryption, we found that in the attack_init function, memory was reserved for 11 different attacks, whereas in all samples previously detected it was only reserved for 10. Everything indicated that Mirai had a new attack in its repertoire.
Call to the new attack from the attack_init function
This new attack has, at first glance, the same structure as attack_app_http. For example, it includes the switch with 5 cases for the assignment of the User-Agent, however, this new version incorporates continuous calls to the OpenSSL library
Examples of SSL functions called from attack_app_http_2
Everything indicates that this new sample is part of the attack request to provoke the denial of service. Such an attack would take advantage of the inability of the objective to mitigate it if it does not have the key to decrypt the traffic, which would affect the increase of the effectiveness of the same.
Even so, it is not the first reference to the use of SSL by Mirai, because, as you can see in the source code of the CnC distributed at the end of September, it already had a reference to the use of SSL, which was disabled. It seems that it is not so.
Code block of the attack.go function relative to the source code of the CnC
Following the new measures being taken by the different service providers in the face of Mirai’s likely next attack, it is growing in sophistication and strength. And it does not seem like it is going to stop doing it in the next few months. We will be attentive to its evolution.
