Another's code - darkness: why is it dangerous to download "harmless" software from GitHub
Probably, everyone who reads this article is well acquainted with GitHub - the largest web service for hosting IT projects and their joint development. Here you can find almost any open source project. To compile the project, you may need some specific software that the user does not have right now, and the assembly process from the source itself requires certain knowledge and experience. Understanding this, developers, in addition to source code, very often place ready-made binary files on a geo. Ilya Pomerantsev, expert in the analysis of malicious code CERT Group-IB , using an example of a real case, shows how using untested third-party code can lead to the loss of cryptocurrency.
This story began when our client downloaded an executable file from one of the GitHub domains - raw.githubusercontent.com. Our TDS Polygon system found the object to be malicious and was handed over to analysts.
Download source - GitHub of the user under the nickname faca5. Studying the source code of the BitTXGenerator project, a generator of fake bitcoin transactions, has not yielded any results. In all files, the author is listed as a bunkdeath, the development date is 2010, DBMS often appears in file names, and there is no mention of bitcoin and cryptocurrency.
It’s easy to find the original repository and description of the original project.
Subsequently, we managed to find the demo video of the author using BitTXGenerator. It was posted by a user under the nickname Herbert Grün. Interest was attracted by a frame where you can see the author’s open windows, including ArtMoney.
This is a well-known program for modifying the parameters of computer games. For example, to get endless virtual money. This raises doubts as to whether the Electrum app really displays the real wallet balance.
Let's move on to the analysis of the sample itself. From behavioral markers, it became clear that we have a self-extracting archive, inside which there is a compiled AutoIt script:
DIE analysis confirms this conjecture:
Next, pay attention to the process tree. We see that the file PXCeHZSXMe.exe , which was inside the sfx archive BitTXGenerator1.2.1.exe , drops and runs the script eVMcf.au3 , which can be found among the created files:
After decompilation and subsequent deobfuscation PXCeHZSXMe.exe we are faced with a straightforward AutoIt script that extracts the payload from the resource section and saves it to disk, then to run it.
Execution begins with a search for open windows of Kaspersky Anti-Virus and Avast. If they are, then HPE falls asleep for 20 and 30 seconds, respectively. Apparently, the antivirus is trying to circumvent, but since it will not bypass it in this way, the logic of this action is absolutely incomprehensible. Also interesting is the Base64 decoding function.
For this operation, the author decided to resort to Shellcode. Another action without logic, because a similar function can be easily implemented on AutoIt:
The resource section encodes three files:
- AutoIt executable. Runs the script ( HLTH.exe )
- AutoIt script containing malicious functionality ( eVMcf.au3 )
- A text file with the names of the files to which the AutoIt script and AutoIt executable will be saved
Let's move on to the analysis of the second stage of unpacking, implemented using eVMcf.au3 .
Script execution begins with a search for a virtual environment, as well as an open Avast dialog box. Why this time the Kaspersky Anti-Virus dialog box stopped frightening the author of malware, will always remain a mystery.
It is interesting how Malvara goes into hibernation. Rather, the way in which she checks that this "hibernation" really was. The fact is that many "stupid" sandboxes rewind time. That is, when you try to call the WinAPI function Sleep , the sandbox skips it, immediately returning control back to the malware stream. This is a great indicator for detecting it. It is enough to take the difference between the system time before and after the system call. However, how this mechanism is implemented in our sample again raises many questions.
The fact is that the WinAPI function GetTickCount returns the time in milliseconds, that is, very accurately. Even if the code was originally written in assembly language, and the optimization was maximum - the time difference would never be strictly equal to the time of "hibernation". We are dealing with an interpreted language. It just doesn't make any sense.
What follows is an optional restart check. Implemented by checking for the existence of a named semaphore.
The payload itself is stored as the last line in the form of an AutoIt comment and encoded using Base64.
The decoding function is exactly the same as that used in the first stage. This suggests that both scripts have the same author.
It is possible to store one or two payloads. Injection into the RegSvcs and wscript process is supported. There is support for x86 and x64. It is optionally possible to process the payload as a batch script and save it to a file for later launch.
The injection function itself again raises a number of questions. In all AutoIt loaders that we know, injection is performed using Shellcode. In the same case, the entire procedure of embedding in another process is implemented directly on AutoIt. This is doubly strange if you recall how Base64 decoding is implemented.
After decoding the comment, we got two new executable files. The first one is an sfx archive. We will leave it for later.
The second is an application written in Delphi.The main form corresponds to the interface of the software advertised by the author.
When you click on the Generate Transaction button, the text Status: Generating Transaction is displayed. Then the timer starts, after which one of the 16 prepared texts appears.
The Broadcast Transaction button will display Status: Broadcasting to all peers and also start the timer. As a result, Status: Broadcast successful will simply be displayed.
There are several more timers that display hardcoded information about supposedly connected peers at different intervals.
As a result, it turns out that the functionality promised by the author is just a fake.
Now, let's ask ourselves, why was it that PR software that does nothing?
Here we recall the first file.
He’s still doing something.
The unpacking procedure is similar to that which was carried out with the source file. As a result, we faced another application on Delphi. The main form contains the TMemo element, a large number of timers that do not have handlers, and an onCreate event handler for the form itself.
When creating a form, the module sets an interceptor for the clipboard. When new content appears, it is checked for compliance with the Bitcoin wallet. If a match is found, then the contents are replaced with a wallet from the TMemo list. That is, there is a substitution of the wallet address.
For the first wallet, we found information about two incoming transactions totaling $ 775 (approximately 50,000 rubles). I note that we also found other instances of malware with a different set of wallets.
This is just one of many examples of how thoughtless use of someone else's code can end, especially in compiled form. Yes, studying the source may take some time, but it will help to save the lion's share of nerves, and possibly money.