Comparison of the ransomware used against Enel and Honda

GLIMPS — Wed, 10 Feb 2021 09:15:52 +0000

Comparison of the ransomware used against Enel and Honda

François did an internship with us between April and August. He worked on the development of a tool that extracts symbols from a program written in Go. Here is an article that presents an application of his work for ransomware analysis and comparison.

EKANS analysis

EKANS (SNAKE upside down) is a new ransomware programmed in Go language which appeared in December 2019, it affected Honda and Enel among many other companies. The particularity of the EKANS, the one that has generated interest, does not lay in its method of propagation but rather in its willingness to “kill” industrial control systems. This peculiarity was notably studied and explained by Dragos.

GLIMPS technology makes it possible to detect similarities between binaries sharing source code, even if compiled differently or for different architectures. In addition, during my internship in the company, I developed a tool to extract symbols from the Go executable runtime.

Two malware with identified similarities, and written in Go… It is therefore a good case study to check the relevance of the results and to test the symbol retrieval tool in a real situation!

This analysis allowed us to verify the indisputable common origin of the viruses used in the Honda and Enel attacks.

Application of GLIMPS code conceptualization technology

GLIMPS has developed a code conceptualization technology that allows to compare compiled software very efficiently, even if they have undergone transformations during the compilation stages, or if they target different architectures.2 applications de cette technologie ont été développées :

GLIMPS-Malware compares a file to a database of millions of classified malware copies, in order to identify whether a file is benevolent or malicious, and if it is malicious, to characterize the probable origin of the attack.
GLIMPS-Audit will help the detailed analysis of a software, legitimate or malware, by identifying and documenting the known code (libraries on shelves…) constituting it. It also allows software-to-software comparison, which we have used in this analysis.

By passing files from the Honda and Enel attacks into GLIMPS-Malware, they are immediately detected as malicious files and characterized as variants of the SNAKE ransomware. We have recovered the right files !

Thanks to GLIMPS-Audit, we then compared the 2 ransomware between them. We can confirm that, despite the methods of offuscation, the ransomware that targeted Enel and Honda are almost identical and come from the same origin: out of 4369 functions, 4230 are identified for sure, and 88 additional matches have a good probability to be identical. Therefore, out of the 4369 functions of the 2 ransomware, there are less than 50 functions for which the correlation is less immediate.

The retrieval of runtime symbols

The Go language is a high-level language with a garbage collector and a runtime capturing execution errors (division by 0, overflow buffers, etc.). The Go runtime when it detects an error causes a “panic” and displays the error details. For example :

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x460c1f]
goroutine 1 [running]:
main.main()
/tmp/sandbox311401280/prog.go:18 +0x1f
exit status 2

This detail contains the path of the source files (/tmp/sandbox311401280/prog.go), the name of the functions (main.main), the line numbers (18), the address of the functions (pc=0x460c1f and +0x1f so the address of the function is 0x460c00), etc… These are the same symbols that we recover.

Once the EKANS symbols have been applied to the disassembled code, important similarities become apparent. Indeed, almost all the functions in the main package (package containing the main function in GB) have had their names and the path of the files containing them offended, transformed into a random string. Note, that the name of the main function of the main package, main.main (main_main in IDA) could not be changed since it is necessary for compilation (it is the entry point of the program) and their modifications take place before the compilation. In addition, the line number of several functions corresponds, for example the main function is on line 339 in both ransomwares. But again, the obfuscation of the file path is partial and shows important similarities, as we can see in the example below :

“Enel” : [{
“Name”:”main.cempcamllplldijidcni”,
“File”:”C:/Users/Admin3/go/src/nmhgfmidblhkfacdajkc/pbopnijdlnfbnimbiham.go”,
“Line”:254
}]
“Honda” : [{
“Name”:”main.jfplojgoheneeggeidee”,
“File”:”C:/Users/Admin3/go/src/cgillndadlcobliljlfo/nknejkdfponfiknchiad.go”,
“Line”:254
}]

Functions are located on the same line and are in the same package (main), are located in files whose paths start in the same way and are offended in the same way. We can therefore consider without taking too much risk that they are the same functions. This was already confirmed by the results of GLIMPS-Audit and that we can also see by a more precise analysis with a reverse engineering software (IDA). These observations allow in many cases to confirm the relevance of the results obtained with GLIMPS-Audit.

Another important similarity visible from the symbols concerns the names of the imported functions. Indeed, for both ransomwares, the same functions of the same packages are imported.

The search for functions to kill processes

Once the previously recovered symbols were loaded into a reverse engineering software we decided to search for the mechanism used by ransomwares to kill processes.

To do so, we searched for the different Go functions allowing to close a process. Unfortunately, its standard library does not provide a function performing such a task independently of the OS. So we looked at the Windows libraries (since ransomwares are PEs allowing to kill a process whose name and strings of executable names are known, usually targeted by ransomwares). These executables are, among others, antivirus (for example, kavshell.exe) and browsers (for example, firefox.exe). Only the TerminateProcess function was found. By tracing back the origin of its arguments we understood that the other functions, especially those allowing to list processes, were dynamically imported. Once the function allowing to perform dynamic imports was found NewLazyDll we realized that if we could not find function or process names it was because all the strings used by both ransomwares are encrypted. In fact, each of the string assignments was replaced by a call to a literal function that uses two other strings to obtain and return the original string. For example,<:P>

print(“Hello world\n”);
//devient
print(func () string {
var string1 = “\x21\x0d\xc3\xb5\x79\x7c\x2d\x9e\x38\x92\xb2\x99”
var string2 = “\x69\x6a\xab\xd7\xee\xa6\x4e\xc3\x3a\xc8\xa2\xa5”
var slice1 = []byte(string1)
var slice2 = []byte(string2)
var size = len(slice1)
var sliceRes = make([]byte, size)
for i := 0; i < size; i++ {
sliceRes[i] = byte((int(slice1[i]) + i*2) ^ int(slice2[i]))
}
return string(sliceRes)/*la valeur de retour est “Hello world\n”*/
}())

This method results in the creation of more than 1,000 almost identical literal functions and doubles the space taken up by strings in the data section. The encryption being relatively simple the following function in Go language allows to decrypt the original string from the two new corresponding strings :

func decode(a, b string) string{
var slice1 = []byte(a)
var slice2 = []byte(b)
var size = len(slice1)
var sliceRes = make([]byte, size)
for i := 0; i < size; i++ {
sliceRes[i] = byte((int(slice1[i]) + i*2) ^ int(slice2[i]))
}
return string(sliceRes)
}

Once the sequences were decoded we found, for each ransomware, the names of the dynamically imported functions and the names of the processes killed by the ransomware. We also observe that the vast majority of the decrypted strings obtained are present in each of the two ransomwares.

The encryption protocol

We then tried to understand the encryption mechanism of the program. To do this we started with the Go encryption libraries and looked at which ones are used. The first found was the AES-256. After studying the input and output paths of the AES encryption function and the surrounding documented function calls we were able to determine the encryption procedure, again the same for both ransomwares.

First a public key pair, private key that will be used to perform an RSA encryption (and later a decryption) is obtained. The public key is hard written into the program sources while the private key is kept by the ransomware designers.only the public key is present in the executable. Note that the ransomwares that targeted Honda and Enel have different public keys.

The second step is the listing of the files. The ransomwares parallel their calculation in order to encrypt several files simultaneously. Then, for each of the files found, a 256-bit key is randomly generated. This key is used to perform an AES-256 encryption on the file. It is then encrypted with an RSA using the public key mentioned above. Finally, the result of the RSA (the encrypted AES key) is formatted before being written to the end of the encrypted file.. Remember, since the RSA is an asymmetric encryption, it is with the private key held by the ransomware designer only that we will be able to decrypt the AES key present at the end of the file and thus decrypt the file. You will find below a diagram detailing the procedure for encrypting and decrypting the ransomware.

Conclusion

To conclude, we can say that the ransomwares are indeed two versions of the same program. Glimps Audit has successfully detected their important similarities. In addition, the Go symbol recovery tool proved to be efficient and greatly facilitated the reverse engineering work.

Email protection with GLIMPS Malware

GLIMPS — Tue, 09 Feb 2021 17:33:25 +0000

Email protection with GLIMPS Malware

In the last few weeks, following the covid-19 crisis and the generalization of teleworking, there has been a very strong resurgence of phishing attacks.

Concerning Coronavirus, there is little we can do except stay quietly at home behind our PC screens. Computer attacks on the other hand, it’s our job :-).

GLIMPS had until then left phishing aside: these attacks are mostly not very complex, and there are already many solutions to protect against them.

But we are forced to note in the news that phishing is currently doing a lot of damage, and that their detection can / should be improved.

GLIMPS-Malware adaptation to phishing

We took advantage of the Easter weekend to build a platform that adapts GLIMPS-Malware for the detection of phishing attacks.

The idea is to adapt and integrate GLIMPS-Malware in an environment like this one:

CSE-Assemblyline is a malware detection and analysis platform developed by the Canadian Cybersecurity Centre and released in late 2017. The strengths of CSE-Assemblyline are :

A high-performance orchestrator that allows to adjust the load and distribute it on several servers in a transparent way,
Many plugins present by default: antivirus, yaras modules, extractors…
The ability to add your own plugins easily, while integrating them with existing plugins, which we will discuss here.

It’s a really powerful tool, that’s why at GLIMPS, we use it a lot! The platform is integrated in GLIMPS-Malware, but another instance has also allowed us to analyze and categorize millions of malwares to build our datasets. We have also derived a version of it to mass-build our library concept code bases for the GLIMPS-Audit product.

Version 4 (currently in Beta) also brings many indispensable changes. In particular, each plugin now runs in a docker, and the old Riak database that was causing us some problems has been replaced by Elasticsearch, much easier to use.

So once again we decided to use AssemblyLine as the basis of an anti-phishing platform.

The concept: a connector in the mail server submits each received mail to AssemblyLine. The mail is analyzed, and in particular are extracted :

the attached documents,
URIs.

works like a Russian doll’s game: everything is recursive. Attachments are analyzed themselves: they are transmitted to GLIMPS-Malware, but also to Assemblyline’s standard modules (antivirus, frankenstrings, etc.). So if someone transmits in an e-mail an attachment in the form of a zip containing e-mails containing malicious URIs themselves… These URIs will be detected and analyzed. In the same way if an attachment is an Excel file containing links…

AssemblyLinev4 Beta was missing 2 plugins to build such a platform:

A new mail parsing plugin for ALv4. Godfried Meesters (Github link) proposed one on the AssemblyLine forum just before I made mine, I was able to reuse it with minor modifications (insertion of URIs in tags)A plugin that checks all detected URIs against a regularly updated blacklist.

On the tested examples, it works perfectly! The platform detects e-mails containing phishing links, either in the body of the e-mail or in Excel attachments for example. All executables are also scanned for potential malware.

In our example, each file is screened by the modules below:

Name	Type of files	Details
emlParser	files/email\|code/html\|text	Analyzes emails, extracts URIs and attachments, and shapes the output for a nice visualization.
Extract	*	Extracts files from a large number of container types (zip...)
Yara	*	Applies the yara rules...
GLIMPS-Malware	executable	GLIMPS-Malware generates concept-code from an executable and compares it to a classified malware database to identify and characterize malware.
Url-checker	tags	scans all URIs identified during the scan for phishing links
Unpacker	executable
ClamAV	*	Antivirus ClamAV
PDFId	files/pdf	Extract metadata from PDFs
PeePdf	(filest/email\|code/html\|text)
Characterize	*	Calculates the file entropy per partition.
PEFile	executable/windows
Beaver	*	compares hashes to the CCIRC database
ViperMonkey	(files/email\|code/html\|text)	Analyzes VBA macros

Of course, GLIMPS-Malware can also be used much more extensively within your company, including :

connected to the web proxy to scan downloaded files,
as a centralized gateway for file analysis,
as a tool for the company’s SOC to carry out doubt resolution.

The diagram below shows these possibilities for your company:

To conclude, the code of the url-checker plugin will be available by the end of April on the Github GLIMPS.

Detection and characterization of an unknown malware thanks to GLIMPS Malware

GLIMPS — Tue, 09 Feb 2021 17:16:20 +0000

Detection and characterization of an unknown malware thanks to GLIMPS Malware

As for the Threat-Intel use case, we have taken back our mirai source code, this time with some modifications :

In order to be detected with more difficulty, we have removed the most obvious strings,
We did not use the compilation script provided on Github, based on gcc. Instead, we rewrote our own script using clang.

The whole operation did not take more than 30 minutes.

We submitted the resulting binary to VirusTotal. No antivirus software detected this new sample of mirai.

We then submitted it to GLIMPS-Malware. The file was immediately detected as malware, with a good probability that it was from the mirai family.

At the time this test was conducted, we had never put clang compiled binaries in our learning base (this is an ongoing effort). Nevertheless, our conceptualization technology was able to extract the meaning accurately. We can see from the results that the closest sample identified is for an ARM architecture, while we had pushed a binary of type amd_64. Our technology is abstracted from the target architecture

What we’ve done with mirai is exactly what large groups of attackers do before launching a new campaign or targeted attack: they adjust the malware production chain to, by reusing the maximum amount of source code among their Intellectual Property (in order to minimize the cost of the attack), generate compiled code that is new enough to bypass current antivirus and detection chains.

Thanks to GLIMPS-Malware, you will be able to detect and stop these new attacks. You protect not only your traditional Information System, but also your Industrial System, your Production Systems or the Embedded Systems that you design.

Reverse-engineering with GLIMPS-Audit

GLIMPS — Tue, 09 Feb 2021 16:43:49 +0000

Reverse-engineering with GLIMPS-Audit

What could be more tedious, when starting the reverse engineering of a binary, whether for a vulnerability search or a malware scan for example, to have to start by finding the known code?

In some firmwares, where there are no debug symbols and the OS is proprietary, one can spend several months just to identify the essential functions (memcpy, print to uart…).

GLIMPS-Audit allows to pass this step in a few seconds. A binary pushed is immediately compared to millions of libraries and other binaries that we have collected and for which we have the symbols. In a few seconds, we see which code is included in the binary, and we can repatriate the documentation to our new analysis.

In our example, we have an elf with 14000 functions, of which only 2 are identified by IDA: “_init_proc” and “_term_proc”. Under normal circumstances, it looks like it’s going to be a long day…

The following screenshot shows the situation:

Now let’s run the binary in GLIMPS-Audit. We get the following list of nearby libraries:

libgcrypt.so.20.2.4
libsqlite3.so.0.8.6
glxtrace.so
RSQLite.so
libsqlcipher.so.0.8.6
libxml2.so.2.9.4
egltrace.so
libssl.so.1.1
libgnutls.so.30.23.2
libc-2.28.so
libinproctrace.so
libgcrypt.so.20.2.5
libgcrypt.so.20.1.6
libicuuc.so.63.2
libcrypto.so.1.1
libcrypto.so.1.0.0
libstdc++.so.6.0.25
libaria2.so.0.0.0

Now we know a little bit more about our binary ! The libc is present, the crypto, the xml, the sqlite, and the libaria2 We generate an idc for our binary. By applying the script, 5592 functions are immediately renamed among our 14000 functions. Of course, you still have some work to do, but with already named functions, as you can see below, it will be easier. Admit that you have gained a few weeks!

Threat-Intel with GLIMPS technology

GLIMPS — Tue, 09 Feb 2021 14:39:38 +0000

Threat-Intel with GLIMPS technology

You’ve probably already heard of Mirai: it’s a well-known and widespread botnet, the sources of which are publicly available on GitHub. There are versions of it for many architectures, and multiple variants. This makes it a very good case study for GLIMPS: we can recompile it ourselves for different architectures, compilers and compilation options, in order to measure the performance of our technology. Below you can see the result obtained when analyzing a file. It was an instance of Mirai for amd64, compiled with GCC.

By observing the results, we can see that this sample of Mirai was already present in the base (sha256 identical first ascended). Our sample has a 100% correlation with itself, which is quite reassuring ! But it is also correlated with other samples of mirai, which although different (the hash of the code is different from the analyzed file) are still 100% correlated. In fact, the GLIMPS technology allows us to free ourselves from the artifacts induced by the compilation process. From the concept-code point of view, we can see that the 2 samples are identical. Our binary would be detected as a mirai malware even if the first sample had not been present in the database. This is one of the interests of GLIMPS-Malware: it is not necessary to have the signatures of each variant of a malware to detect them: a few versions will be more than enough to detect all the variants, including those that have not yet been created or detected. You can also have a look at our Use Case “Detection and characterization of unknown malware” on this subject”.

What about Threat Intell

Firstly, our sample of Mirai has indeed been detected as an exemplar of the Mirai family… But what is also very interesting in this result is that we also see another family appearing: the correlation rate is of course lower (15%), but GLIMPS-Malware tells us that Mirai is also close to copies of the Bashlite family. Digging a little deeper, we find information in the documentation confirming that Bashlite was Mirai’s ancestor. It is therefore logical that the 2 have some code in common, which GLIMPS-Malware has detected. We wanted to find out for sure… time to use our favorite reverse engineering software… GLIMPS-Audit of course !

Fast analysis by reverse-engineering... with GLIMPS-Audit !

Our Mirai sample has no debug symbol. However, for bashlite, the attacker had forgotten to remove the debug symbols. First step, use GLIMPS-Audit! We will then be able to retrieve the bashlite documentation in our mirai sample.

Comparing our 2 binaries, we find 25 so-called “trusted” associations:

If we observe a random function in Ida, we can see that, even if in detail the assembler code is not identical, it is indeed the same code, and that both probably come from the same original source (in the specific case of this function that we have selected because it is particularly large, allowing the human eye to quickly see the similarities). Here, a hash-based technique would necessarily have failed: in a function of this size with different compiler versions, it is almost impossible that all the instructions are strictly identical.

In the specific case of Mirai, for which a version of the sources is available on Github, we can even go much further: whatever sample we want to analyze, it is easy to retrieve all the symbols from the public version by compiling it with the debug symbols. We could leave this exercise to the reader… But don’t worry, GLIMPS-Malware does it automatically for you !

Conclusion

We have seen how GLIMPS-Malware and GLIMPS-Audit could be used effectively in a complementary way in a Threat-Intel approach.

Bonjour tout le monde !

GLIMPS — Sun, 22 Sep 2019 14:25:46 +0000

Bienvenue sur WordPress. Ceci est votre premier article. Modifiez où supprimez-le, puis commencez à écrire !