Lord777
Professional
- Messages
- 2,576
- Reaction score
- 1,551
- Points
- 113
Content
On the eve of the holidays, we all plunge headlong into tasks that need to be completed, the vigilance of office workers is dulled, and this plays into the hands of hackers. We recently faced a series of cyberattacks against companies in the Russian financial sector, including Sberbank. At first glance, these were the usual phishing mailings to the addresses of bank employees. But detailed analysis and analysis revealed a constantly evolving targeted attack.
Chronology of attacks
How was the attack organized? General chronology of recorded attacks:
Why we have combined all events:
Parsing letters
Mailing of letters was carried out from the domains:
Phishing Agent Header
The structure of phishing emails is text / html, encoding is quoted-printable UTF-8.
Headers describing the structure of the phishing email
Malicious URL
All addresses indicated in the letters led to pages in the HTML code of which the download of the malicious Java applet signed.jar was initialized. In addition, the pages contained fragments of executable code encoded in Base64 designed to download malware. This functionality was also duplicated in the Java applet.
Base64 encoded fragment for downloading a malicious Java applet
In fact, when the victim followed the link, signed.jar was launched. Since the jar file is signed with a valid certificate issued by Comodo CA Ltd. / Digicert, Inc., it has been tested on the security settings of the Java machine. It's worth noting that when using the default Java options, user confirmation is required to run the applet. The easiest way to prevent applets from running in privileged mode is to disable the Allow user to grant permissions to signed content option in the Java settings.
The contents of the malicious jar file
Certificate issued to hackers
Dynamic link main.dll / main64.dll
The malware was developed using Java Native Interface (JNI) mechanisms to call native code from a Java machine and vice versa. During the execution of the jar applet, the bitness of the OS was determined, followed by the extraction of the required dynamic DLL:
Java_main_inject method in signed.jar
After extracting, main.dll / main64.dll is saved to disk and executed using the System.load () function in the context of the Java virtual machine. The code from main.dll / main64.dll dynamically receives the addresses of the Windows API functions for working with the HTTP protocol from the wininet.dll library, addresses the URL hxxps: // servicenetupdate [.] Com / yroyiuymsa, downloads and decrypts the file located at this address int.dll (for decryption, the XOR algorithm with feedback was used), after which control is transferred to the decrypted code.
main.dll - generating an HTTP request to get the module loader
Malicious email attachment
The malware spread through an email attachment, in some cases a direct URL to the RTF file hxxp: //oracle-russia.info/Oracle_RDBMS.rtf (3rd attack).
If the file was opened, but the necessary updates were not available, this led to the exploitation of a vulnerability known since November 2017 in the formula editor module (CVE-2017-11882). The malware component was executed in the form of a scr file containing a .NET script that loaded a PowerShell script.
In the course of a detailed analysis of the scr file, it was found that its contents were encrypted using the bitwise XOR algorithm with the byte key 0xA5.
Malicious PowerShell script after bitwise XOR with 0xA5 key
A snippet in Base64 format, modified to make it more difficult to parse
Base64-extracted binary that was responsible for getting the module loader
After executing the PowerShell script, an SSL connection was created to the hxxps: //teredo-update.com host (3rd attack) and then the int.dll module loader was downloaded.
Module loader
The int.dll file from both the first and second attack methods is a Windows PE32 executable file (DLL) designed to load other malware modules from the management server. The first attack used the URL hxxps: // help-desc-me [.] Com / <pseudo-random lowercase ASCII string> / as the address of the management server during the first attack.
With a frequency of one second, the module loader accessed the control server via the HTTP protocol using GET requests. If an HTTP response with a 200 code was received, encrypted modules were loaded and decrypted. The bootloader then ran them in the context of its process, a very common method to make it difficult to detect malware. The results of the modules were sent to the control server using the HTTP POST method.
The loader used a rather original encryption method - the binary data containing the loaded modules were presented in the human readable content format.
Human readable fragments containing an additional malware module
The part of the bootloader code responsible for decoding the received load
In the course of the dynamic analysis during the attacks, we managed to obtain three loadable modules:
Screenshot code
Code for getting a list of running processes
Attack via a malicious URL in an email leading to an executable jar file
General attack scheme
As a result of the analysis, a general scheme of attacks was established.
Attached file attack exploiting CVE-2017-11882 vulnerability
C&C # 1 servers were used by hackers to host a module loader that was downloaded during the second stage of the attack. C&C # 2 - Real C&C Servers for Remote Interaction. They were also used to transfer additional modules intended for further potential distribution on the victim's network.
List of C&C servers:
Changes in the course of re-launching attacks
First and second attacks:
Second and third attacks:
Total
Without such research, it is impossible to build a reliable defense system, since modern means cannot cope with targeted attacks. Within the Cybersecurity Service, we managed to build processes that allow for detailed analysis of cyber attacks and malware. The Security Operation Center has Threat Intelligence, Forensics and RedTeam. Inside the SOC, indicators of compromise are accumulated, obtained through interaction with partner organizations such as Bizone and GosSOPKA. And this system has already proven its effectiveness more than once.
At the end of last year, we witnessed the beginning of a new stage of attacks on financial institutions in Russia. It cannot be said that the number of attacks has increased sharply, but it can be clearly noted that their technical level is growing - published vulnerabilities are adopted by hackers in the shortest possible time. In addition, phishing emails are increasingly showing signs of targeted and well-planned actions, and updated tools and mechanics are replacing well-known and well-known methods of attackers.
(c) Yuri Doroshenko
- Chronology of attacks
- Parsing letters
- Malicious URL
- Dynamic link main.dll / main64.dll
- Malicious email attachment
- Module loader
- General scheme of the attack
- Changes in the course of re-launching attacks
- Total
On the eve of the holidays, we all plunge headlong into tasks that need to be completed, the vigilance of office workers is dulled, and this plays into the hands of hackers. We recently faced a series of cyberattacks against companies in the Russian financial sector, including Sberbank. At first glance, these were the usual phishing mailings to the addresses of bank employees. But detailed analysis and analysis revealed a constantly evolving targeted attack.
Chronology of attacks
How was the attack organized? General chronology of recorded attacks:
- all mailings were made at the height of the working day (time zone UTC + 3);
- first attack - last week of December 2017;
- second attack - second working week of 2018;
- third attack - third workweek of 2018.
Why we have combined all events:
- mailing lists matched with 85% accuracy;
- all letters were correctly written in Russian;
- the mechanisms and tools used in the attacks had minor differences;
- all letters had an identical structure and were sent using the Exim 4.80 mail server;
- used certificates issued by certification authorities Comodo CA Ltd., Digicert, Inc. Identified in the certificates of the companies to which they were issued: Dazzle Solutions Ltd., Bright Idea Enterprise Ltd .;
- two methods of distributing malware were used: a link in a letter leading to an executable jar file; file attachment exploiting published vulnerability CVE-2017-11882.
Parsing letters
Mailing of letters was carried out from the domains:
- billing-cbr [.] ru
- bankosantantder [.] com
- oracle-russia [.] info
- cards-nspk [.] ru
- regdommain [.] com
Phishing Agent Header
The structure of phishing emails is text / html, encoding is quoted-printable UTF-8.
Headers describing the structure of the phishing email
Malicious URL
All addresses indicated in the letters led to pages in the HTML code of which the download of the malicious Java applet signed.jar was initialized. In addition, the pages contained fragments of executable code encoded in Base64 designed to download malware. This functionality was also duplicated in the Java applet.
Base64 encoded fragment for downloading a malicious Java applet
In fact, when the victim followed the link, signed.jar was launched. Since the jar file is signed with a valid certificate issued by Comodo CA Ltd. / Digicert, Inc., it has been tested on the security settings of the Java machine. It's worth noting that when using the default Java options, user confirmation is required to run the applet. The easiest way to prevent applets from running in privileged mode is to disable the Allow user to grant permissions to signed content option in the Java settings.
The contents of the malicious jar file
Certificate issued to hackers
Dynamic link main.dll / main64.dll
The malware was developed using Java Native Interface (JNI) mechanisms to call native code from a Java machine and vice versa. During the execution of the jar applet, the bitness of the OS was determined, followed by the extraction of the required dynamic DLL:
- main.dll for x86-bit Windows OS;
- main64.dll for x64-based Windows OS.
Java_main_inject method in signed.jar
After extracting, main.dll / main64.dll is saved to disk and executed using the System.load () function in the context of the Java virtual machine. The code from main.dll / main64.dll dynamically receives the addresses of the Windows API functions for working with the HTTP protocol from the wininet.dll library, addresses the URL hxxps: // servicenetupdate [.] Com / yroyiuymsa, downloads and decrypts the file located at this address int.dll (for decryption, the XOR algorithm with feedback was used), after which control is transferred to the decrypted code.
main.dll - generating an HTTP request to get the module loader
Malicious email attachment
The malware spread through an email attachment, in some cases a direct URL to the RTF file hxxp: //oracle-russia.info/Oracle_RDBMS.rtf (3rd attack).
If the file was opened, but the necessary updates were not available, this led to the exploitation of a vulnerability known since November 2017 in the formula editor module (CVE-2017-11882). The malware component was executed in the form of a scr file containing a .NET script that loaded a PowerShell script.
In the course of a detailed analysis of the scr file, it was found that its contents were encrypted using the bitwise XOR algorithm with the byte key 0xA5.
Malicious PowerShell script after bitwise XOR with 0xA5 key
A snippet in Base64 format, modified to make it more difficult to parse
Base64-extracted binary that was responsible for getting the module loader
After executing the PowerShell script, an SSL connection was created to the hxxps: //teredo-update.com host (3rd attack) and then the int.dll module loader was downloaded.
Module loader
The int.dll file from both the first and second attack methods is a Windows PE32 executable file (DLL) designed to load other malware modules from the management server. The first attack used the URL hxxps: // help-desc-me [.] Com / <pseudo-random lowercase ASCII string> / as the address of the management server during the first attack.
With a frequency of one second, the module loader accessed the control server via the HTTP protocol using GET requests. If an HTTP response with a 200 code was received, encrypted modules were loaded and decrypted. The bootloader then ran them in the context of its process, a very common method to make it difficult to detect malware. The results of the modules were sent to the control server using the HTTP POST method.
The loader used a rather original encryption method - the binary data containing the loaded modules were presented in the human readable content format.
Human readable fragments containing an additional malware module
The part of the bootloader code responsible for decoding the received load
In the course of the dynamic analysis during the attacks, we managed to obtain three loadable modules:
- an executable file in Windows PE format (DLL) - a module for creating screenshots; it is loaded every time a task is received from the command and control server to take a screenshot;
- executable file of Windows PE format (DLL) - a module for obtaining a list of running processes (names of executable files and paths to them). After execution, it sends data back to the management server;
- payload Cobalt Strike Beacon version 3.8, issued only in case of a positive decision made by hackers based on the information received about the infected system.
Screenshot code
Code for getting a list of running processes
Attack via a malicious URL in an email leading to an executable jar file
General attack scheme
As a result of the analysis, a general scheme of attacks was established.
Attached file attack exploiting CVE-2017-11882 vulnerability
C&C # 1 servers were used by hackers to host a module loader that was downloaded during the second stage of the attack. C&C # 2 - Real C&C Servers for Remote Interaction. They were also used to transfer additional modules intended for further potential distribution on the victim's network.
List of C&C servers:
- servicenetupdate [.] com
- bankosantantder [.] com
- oracle-russia [.] info
- help-desc-me [.] com
- billing-cbr [.] ru
- teredo-update [.] com
- techupdateslive [.] com
- getfreshnews [.] com
Changes in the course of re-launching attacks
First and second attacks:
- Main.class - string constants wrapped in Base64;
- main.dll - the encoding key has been changed;
- int.dll - replaced payload and encryption key;
- a second distribution method was introduced via an RTF file (CVE-2017-11882).
Second and third attacks:
- int.dll - replaced payload and encryption key;
- a direct link to the scr file has been added to the body of the phishing email.
Total
Without such research, it is impossible to build a reliable defense system, since modern means cannot cope with targeted attacks. Within the Cybersecurity Service, we managed to build processes that allow for detailed analysis of cyber attacks and malware. The Security Operation Center has Threat Intelligence, Forensics and RedTeam. Inside the SOC, indicators of compromise are accumulated, obtained through interaction with partner organizations such as Bizone and GosSOPKA. And this system has already proven its effectiveness more than once.
At the end of last year, we witnessed the beginning of a new stage of attacks on financial institutions in Russia. It cannot be said that the number of attacks has increased sharply, but it can be clearly noted that their technical level is growing - published vulnerabilities are adopted by hackers in the shortest possible time. In addition, phishing emails are increasingly showing signs of targeted and well-planned actions, and updated tools and mechanics are replacing well-known and well-known methods of attackers.
(c) Yuri Doroshenko
